Apama 10.7.2 | Developing Apama Applications | Protecting Personal Data in Apama Applications | Handling personal data "at rest" in log files | Recommendations for logging by Apama application code
 
Recommendations for logging by Apama application code
If you are developing EPL applications, connectivity plug-ins or EPL plug-ins, you will need to make your own choices about what information to log and at what level from the code you write. To comply with the principle of data minimization, it is best to avoid unnecessarily including personal data in log output. So where possible, avoid logging details such as username, IP address or the contents of messages, unless needed for security auditing or for legitimate interests such as diagnosing and resolving application errors. In some cases, pseudonymization will be possible. That is, when logging personal data, use an application-generated globally unique identifier (GUID) instead of a username, or an IP address that could be used to link the data to an individual person, and protect the mapping between GUIDs and usernames.
It is important to select an appropriate log level for application-generated log messages. It is possible to select different log levels for individual packages within your EPL application, and to direct the output to different log files. See Setting EPL log files and log levels dynamically for more details. If using multiple log files, ensure that the same file system permissions and secure rotation policies are applied to all of them.
You may wish to gather together all the security audit logging from your EPL application into a single file, or perhaps all of the logging that may include personal data. As EPL log statements are written to a category based on the event definition where they exist, these use cases can be addressed by defining a dedicated Apama event definition to perform the logging. For example:
package com.mycompany;
event SecurityAuditLogging
{
action logModification(string username, string resource)
{
log "Security event: user '"+username+"' modified resource: "
+resource at INFO;
}
}
...
SecurityAuditLogging.logModification("myuserid", "resource");
The log level and log file for this could then be configured in the correlator's YAML configuration file as described in Setting EPL log files and log levels in a YAML configuration file. For example:
eplLogging:
com.mycompany.SecurityAuditLogging:
file: apama-security-auditing.log
level: INFO