The Apama security model for correlator and IAF components is that untrusted users must not be given access to any related files or to send or receive data on any of the correlator or IAF network ports. For dashboards, the same applies to the display server's management and data ports, and the data server's management port - although the data server's data port might need to be exposed to end-users if the thick Dashboard Viewer client is used. It is assumed that any user able to access these files or ports is trusted and has permission to make arbitrary changes and read arbitrary data. Such users are also permitted to inject arbitrary code into a correlator and execute it with the permissions of the correlator process.

You must use standard operating system and network tools/configuration to restrict access to the IAF and correlator components to only trusted users. For the dashboard servers, this applies except to the data server's data port.

You must use standard operating system tools to restrict access to all configuration and data files to only trusted users.

You must restrict access to changing the process environment when starting the server processes to only trusted users.

You must not set the correlator, IAF or dashboard server logging to a level higher than INFO to have all security-relevant events logged to the log files.

Setting the correlator, IAF or dashboard server logging to a level lower than INFO could include security-sensitive information in the log files.

Remember to also fully configure all connected systems to perform adequate authentication and authorization. Select connectivity plug-ins that support authentication and authorization where possible, and make sure these settings are enabled. For example:

If components must connect across an untrusted network, then either use a standard overlay tool such as a VPN or use a plug-in that supports TLS and authentication.

For access from untrusted hosts, you should deploy your dashboards to the web server using the display server deployment option. The dashboard server or display server processes should be running behind a firewall, just like the correlators. When accessing the dashboard server by using a standalone Dashboard Viewer outside the firewall, make sure to run the dashboard server with the --ssl option, which will ensure secure sockets for client communication using the data port. You must also ensure that the management ports of both servers are not exposed to end users.

The following diagram depicts the recommended dashboard deployment options:

Authentication for the display server is done via JAAS and your authentication mechanism of choice.

For a dashboard audit trail, you must load the Dashboard Support bundle into the correlator processing audit events and handle the DashboardClientConnected and DashboardClientDisconnected events, logging them in an appropriate manner.

Both Docker and Kubernetes offer methods of passing secrets to the correlator. This can be used to securely provide credentials to the correlator. For more information, see the corresponding samples that are mentioned in Apama samples for Docker and Apama samples for Kubernetes.

You need to secure log files, input logs and the persistence database, especially if they contain personal data. On Windows, this would mean setting an inheritable Access Control List (ACL) limiting read access to the contained files. On UNIX systems, this would involve restricting read and execute permissions to only the owning user (that is, "700") and if possible also setting a umask of 0077 on the correlator process to ensure files created by the correlator also have locked down permissions.

See Protecting Personal Data in Apama Applications for suggestions to help with identifying how personal data can be protected when building applications on the Apama platform.