When we designed Qlik Sense one important aspects was to start using standard security components where possible to solve different aspects of security. Protecting communication is a good example of this, as we used standard components to protect against adding rogue servers and eavesdropping.

 

If you interested in understanding how we achieved this in Qlik Sense then continue reading…

 

When Qlik Sense needs to exchange information between different services, a couple of things need to be in place. The services need to trust each other and they need a way to talk without other listening in to the conversation.

 

In Qlik Sense all communication between services and clients use web protocols. With these we get the option of using a widely deployed standard for building trust and protecting the communication from eavesdropping. The way of achieving secure communication is tightly knit together by two components:

• TLS (Transport Layer Security), the protocol for how encryption and exchange of information/keys works

• Certificates for authentication of the servers that need to communicate

 

What TLS supplies is a way to build protected tunnels between two identified servers using encryption. The identification of the servers that communicate is done using certificates. Each tunnel needs two certificates, one to prove to the one starting the communication that they talk to the correct recipient and one to prove to the recipient that the one wanting to communicate is allowed to do so, i.e. mutual authentication.

 

So how do we know if the certificates are valid for communication between the servers? All certificates that belong to a trust zone are signed by the same signature (root certificate) and only if this signature exists will they be accepted as proof that you belong to the trust zone.

 

When these protected tunnels are in place and we have the right certificates in place we are able to build a trust zone for all Qlik Sense services to work within. Within the Qlik Sense trust zone only the services belonging to that specific Qlik Sense installation can communicate.

SecureCommunicationQlikSense.png

 

Outside this trust zone we have the clients (Qlik Management Console and the Client). These components are running on less trusted end user devices; therefore we do not allow them to be part of the Qlik Sense trust zone. The only component that can bridge the two zones is the proxy (but there may exist more than one bridge in an installation). The criteria for being allowed to cross the bridge and communicate in a controlled way with the servers in the trust zone is that you can authenticate (show who you are) to the system so it can determine if you are allowed to cross the bridge.

 

Even though the clients are not part of the Qlik Sense trust zone, protected tunnels (TLS) play a vital role in securing the communication between the client and the proxy, as sensitive information is sent across this connection. But as this is a different trust zone a certificate with a different signature should be used for client communication.