Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

For Datafari 5.1

The documentation below is valid from Datafari v5.1 CE and EE

There are many ways to secure an application.

We can either secure each component of Datafari : Solr, Tomcat but it needs more work to manage the security at the level of every component : management of the certificates, configuration specific for each 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 :

Architecture Apache reverse proxy monoserver

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.


 For Datafari 4.3 EE

For Datafari 4.3 EE

The documentation below is valid from Datafari v4.3 only EE version

There are many ways to secure an application.

We can either secure each component of Datafari : Solr, Tomcat but it needs more work to manage the security at the level of every component : management of the certificates, configuration specific for each 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 :

Architecture Apache reverse proxy monoserver

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.

  • No labels