- Security & Firewall on server side
- Security & Firewall on Connector Box side
- Technical Users
- Load Balancing / Gateway
- External Interfaces
Every request sent to the server originates from either a web browser client, a Connector Box or a third- party application via API.
As shown in the Figure below, the architecture of the system allows a high level of security by design to prevent attacks and intruders on software side. Furthermore, all traffic is encrypted with industry standard encryption algorithms to ensure a highest level of privacy.
Security & Firewall on server side
Every incoming request to the server is using port 443, and the first instance, which is the load balancing service, accepts the request. Under no circumstance, a connection attempt from the server to a Connector Box or the web browser is performed, as the incoming requests, especially incoming websocket requests, allow a bidirectional exchange of data packages. The firewall settings for the Laboperator platform thus only require the allowance of incoming port 443. Commercially available deep packet inspection firewalls are compatible with the traffic, which allows a high level of security as industry standards are followed. As no other open ports on server side are required for regular operation, the possible attack opportunities are highly limited. For remote maintenance, further considerations could require other ports to be available, but in combination with VPN tunnels a very high level of security can be obtained. The internal network which allows the individual server instances to synchronize between databases and the event bus is completely separated from the outside network and is at no point bridged between the segments.
Security & Firewall on Connector Box side
Every Connector Box establishes a connection to the server. As this is an outgoing connection from the Connector Box perspective, no open ports for incoming connections on the Connector Box or in the segment firewall are required.
To the outside, HTTP is used as communication protocol. For websocket connections, the protocol is upgraded transparently and is treated as a regular HTTP connection. For intra-server communication, regular TCP connections are established between the cluster components, which depend in their nature on the corresponding service and the individual implementation.
As all outside web traffic is encrypted by TLS, the web server needs to have a valid server certificate. The load balancing / gateway components act as encryption endpoints. There are three possibilities to get a valid server certificate:
Configuration option 1: Custom Root Certificate Authority
The Laboperator server acts as Root Certificate Authority, which allows to create self-signed certificates. This is easy to implement but requires importing and trusting of the Root Certificate on every user end device, such as PC, tablet or mobile phone. End users need administrator permissions on their respective devices.
Configuration option 2: Corporate Certificate Authority
In an enterprise scenario, usually a Certificate Authority already exists which issues trusted certificates. This CA can be used to process a certificate request and issue web server certificates for the Laboperator platform. As the corporate policy includes the root certificate, and end user devices are managed by the enterprise, the issued web server certificates will already be trusted on user end devices.
Configuration option 2: External Certificate Authority
Commercial providers offer web server certificates but require a valid DNS entry which belongs to the requester and which is available from the public internet. The root certificates of those providers are usually shipped with the web browsers by default, and allow a simple user experience, as no manual trust step is required on end user side. This scenario is only possible if the Laboperator platform is run in a cloud setup.
Every server instance has a root user, and a “server” user account which is the context in which the application services are invoked.
For certain services, additional user accounts are generated and used. The following services are authenticated with separate sets of credentials:
- Database connection
- Cache connection
- Messaging Service connection
Load Balancing / Gateway
The traffic to the Laboperator server is encrypted by TLS, a transport encryption layer, based on certificates. Nginx as the front-end web server encrypts all outgoing and decrypts all incoming web traffic and forwards the unencrypted traffic to the underlying individual services.
While all external connections are passed through the Load Balancer Service no traffic going over these connections is inspected or altered in any way. Nginx acts as a transparent proxy to the individual underlying services.
Every successful and unsuccessful request is logged by the system, but user login passwords are not included in log files and thus not readable by administrators.
Third-party applications use the Laboperator API to read and write information. The API is following a RESTful implementation and is using the OAUTH2 authentication scheme.
For certain use cases, a webhook routine sends outgoing requests from the server to the third-party application. Webhook events are linked to predefined internal events such as new data points. The target URL can be defined by administrators inside the Laboperator application. For more information click here.