...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
| Info |
|---|
For Datafari 5.1The documentation below is valid from Datafari v5.1 CE and EE |
There are many ways to secure an application.
...
Another way of securing the application is to use SSL Offloading. It is the security that we chose into Datafari. Basically we delegate the functions required for SSL/TLS, namely the handshake and the encryption/decryption to a dedicated component in front of the user. So all the servers behind the reverse proxy communicate as usual.
More precisely it is called SSL Termination in this case :
...
The proxy server/load balancer we use for the SSL offloading acts as the SSL terminator. When a client attempts to connect to Datafari, the client still has a secure connection with the SSL terminator, which is acting as a pass-through.
The Datafari architecture is like this for monoserver and multiservers :
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Architecture Apache reverse proxy monoserver
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Architecture Apache reverse proxy multiserver
This solution is a good compromise between the secuirty and the maintenance. The network part between the load balancer and the Datafari servers can be more secured by isolating the servers by their own VLAN or IPSEC tunneling for example.
By using VLAN, we avoid all broadcast attacks like ARP cache poisoning, DHCP spoofing, smurf attack,, MAC table overflow, etc …)
According to section 4.1 of
...
the PCI Data Security Standard
...
any merchant handling credit card data should:
"...use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”
This means that Front End SSL is allowed, as once the data reaches the load balancer, it is considered to have entered a secure private network.
...
| Info |
|---|
For Datafari 4.3The documentation below is valid from Datafari v4.3 only EE version |
There are many ways to secure an application.
...
Another way of securing the application is to use SSL Offloading. Basically we delegate the functions required for SSL/TLS, namely the handshake and the encryption/decryption to a dedicated component in front of the user. So all the servers behind the reverse proxy communicate as usual.
More precisely it is called SSL Termination in this case :
...
The proxy server/load balancer we use for the SSL offloading acts as the SSL terminator. When a client attempts to connect to Datafari, the client still has a secure connection with the SSL terminator, which is acting as a pass-through.
The Datafari architecture is like this for monoserver and multiservers :
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Architecture Apache reverse proxy monoserver
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Architecture Apache reverse proxy multiserver
This solution is a good compromise between the secuirty and the maintenance. The network part between the load balancer and the Datafari servers can be more secured by isolating the servers by their own VLAN or IPSEC tunneling for example.
By using VLAN, we avoid all broadcast attacks like ARP cache poisoning, DHCP spoofing, smurf attack,, MAC table overflow, etc …)
According to section 4.1 of
...
the PCI Data Security Standard
...
any merchant handling credit card data should:
"...use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”
This means that Front End SSL is allowed, as once the data reaches the load balancer, it is considered to have entered a secure private network.