GLU.Engine have robust data security measures, encompassing both data masking and encryption to protect sensitive information across all system interactions—including logging, JMX API calls, and internal JVM processes.
• Data Masking: This technique involves obscuring sensitive data within outputs to ensure that the data cannot be reconstructed or retrieved in its original form. Masking is applied to logs and JMX API responses to prevent sensitive information from being exposed. For instance, a masked credit card number might appear as ************* in logs.
• Data Encryption: In addition to masking, the GLU.Engine employs encryption to protect data at rest and in transit. Encryption involves converting data into a coded format that can only be read or processed after being decrypted with a key. This ensures that even if data is intercepted, it remains unreadable without the corresponding decryption key.
• JMX API Data Protection: Enhanced security measures are also applied to data accessed through JMX API calls. This includes both masking and encrypting data to ensure robust security against unauthorized access.
• Comprehensive JVM Data Security: The security measures extend throughout the JVM, safeguarding data involved in various processes and stored in memory spaces within the GLU.Engine. This integrated approach ensures that all sensitive data handled by the system is thoroughly protected.
• Flexible Tagging for Data Protection: Administrators can define specific security rules for data handling and protection in the ‘Mask PAYLOAD Values in Logs’ section of the Transaction Manager Panel. This allows for targeted application of masking and encryption rules across different data types and system interactions.
This strategic implementation of data masking and encryption within the GLU.Engine not only shields sensitive data from unauthorized access but also ensures the integrity and confidentiality of data across the platform’s operational framework.
In situations where the parameters in the messages may contain sensitive information that could pose a security risk if displayed in the logs, the GLU.Engine generates two types of logs that require controlled value representation:
- logs that include parameters in the ‘PAYLOAD’ and
- logs that print parameters as ‘PARAM’.
The masking of sensitive data in log entries can be controlled by configuring the PAYLOAD and PARAM log masking.
The PAYLOAD log masking is managed at the transaction level, while the PARAM log masking is managed at the parameter configuration level. It is important to note that while the PAYLOAD log masks only parameters in the PAYLOAD when printed in the log, the mask does not affect the unmarshalled value.
To mask the unmarshalled value, a mask for the full string as it appears in the logs must be added.
Then the PARAM log will be masked in the values when un-marshalled.
To mask PAYLOAD values, the ‘Mask PAYLOAD Values in Logs‘ field in the Transaction Manager Panel can be used to define the ‘tags‘ for any values that need to be masked, along with the GLU reserved word “GLU_MASK” (e.g. “username”:”GLU_MASK”).
This will replace the value for “username” with “**********”.
Since tags are used, any payload value can be masked, not just the parameter values within the payload.
The tags to be masked can be copied from the payload template configuration and will vary depending on the payload type (e.g. XML, JSON, SQL call, etc.).
NOTE: the GLU_MASK value used is the full line, so if you complete the line entry with “username”: “GLU_MASK”, the value will also be included in the masking of username – e.g. “**********”.
To mask PARAM values, the “Mask PARAM Value in Logs“ checkbox (which by default is ‘checked’) must be unchecked.
Any payload tag (PAYLOAD logs) or parameter name (PARAM logs) that is configured to be masked will be masked in in all logs (INFO, WARN, DEBUG etc.) for all logs associated with a particular transaction.
