Apama 10.15.4 | Deploying and Managing Apama Applications | Security Requirements for Apama
 
Security Requirements for Apama
Security model
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.
Security requirements
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 using the Universal Messaging connectivity plug-in, set appropriate permissions on all channels, and use authentication and a certification authority. For more information, see Configuring the connection to Universal Messaging (dynamicChainManagers).
*If using the HTTP server connectivity plug-in, note that it exposes an additional port on the correlator. If deployed in any context where access is not restricted to only trusted users, the HTTP server connectivity plug-in must be configured to use TLS and HTTP basic authentication. It should not be directly connected to the internet. If internet access is required, then the plug-in must be deployed in a DMZ behind a reverse proxy such as Apache or Nginx. For more information, see Configuring the HTTP server transport.
*If using the HTTP client connectivity plug-in, configure it to use TLS and HTTP basic authentication. For more information, see Configuring the HTTP client transport.
*If using the MQTT connectivity plug-in, configure it to use SSL/TLS. For more information, see Configuring the connection to MQTT.
*If using the Kafka connectivity plug-in, configure the Kafka clients to use SSL. For more information, see Configuring the connection to Kafka (dynamicChainManagers) and the Kafka documentation at https://kafka.apache.org/.
*If using the Digital Event Services connectivity plug-in, see Using Digital Event Services to Communicate between Software AG Products for information on how to use SSL with Digital Event Services.
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.
Important: 
Ensure that you regularly install the latest Apama fixes, and keep your operating system fully patched to ensure the latest security fixes are present.
Dashboards
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:
Diagram showing the recommended dashboard deployment options
Authentication for the display server is done via JAAS and your authentication mechanism of choice.
Important: 
You must customize your own JAAS modules. The out-of-the-box authentication/authorization modules for dashboards cannot be used. This means that there is no authentication by default, and the basic authorization mechanism is shipped. For details on how to configure your own JAAS modules, see Administering Dashboard Security.
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.
Docker and Kubernetes
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.
Personal data
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.