Logging Sensitive Data

[Senay-Ersen]

Hi @jongpie ,
First of all, I would like to express my gratitude to you and the other contributors for bringing this wonderful project to life. It's great to see such collaboration and innovation in action.

Our company aims to integrate an error logging framework into our operations using Nebula Logger. We are currently seeking guidance on the best practices for logging sensitive data. While we explored the possibility of using data masking, it is not a viable option for us as it operates at the database level. Instead, we are looking for a solution that allows us to log errors with specific fields in the related record that contain sensitive data. It is crucial that only authorized profiles or users have access to this sensitive information so they can effectively address and investigate the error. If you require any additional information to provide more tailored advice, please let me know. We appreciate your assistance.

Thanks,
Senay

[jongpie]

Hi @Senay-Ersen, thanks for the kind words, it's a very fun project to work on, and it's amazing to be able to collaborate with others on it 🥳

And just for clarification, when you say that data masking operates at the database level, it sounds like you're referring to the data masking that the platform offers (please let me know if I'm mistaken!). Nebula Logger also has some features built-in that might work for your use case:

1. Nebula Logger has its own data masking capabilities built-in, which operates as soon as you log something (in-memory, before it even reaches the database). It automatically obfuscates any sensitive data in the Message__c field, as well as any sensitive data in any related SObject records that you log (stored in the RecordJson__c field)
   • If you have not seen it before, there is a page in the wiki for "Configuring Data Mask Rules". There are a few rules provided out-of-the-box (for some credit card formats and US social security numbers), and you can you configure additional "data mask rules" in your org, using regex in the object LogEntryDataMaskRule__mdt.
2. Nebula Logger also has the ability to strip inaccessible fields when logging SObject records - this also operates as soon as you log something (in-memory, before it even reaches the database). This is controlled by the field, LoggerSettings__c.IsRecordFieldStrippingEnabled__c, When logging SObject records, it automatically removes from the JSON any fields where the current user does have read access to the field.

Hope this helps, please let me know if you have follow-up questions!

[Senay-Ersen]

Hi @jongpie,
Thank you very much for the quick response.

I was referring to built-in data masking feature in Nebula Logger, sorry for the confusion. Even If I create a new data mask rule, the sensitive data will be saved to database as masked. What we need is that the sensitive data to be masked for some users on the UI level. We want the sensitive data to be seen only by the user that will be tracking the errors. Is there a way to achieve this with Nebula Logger?

Thanks,
Senay

[jongpie]

Hi @Senay-Ersen, thanks for the clarification! In that case, data masking at the UI level is not currently supported, but I think that's a great idea. I'll do some research to see if there is a good way to add this as a future enhancement. I'm thinking that there would possibly be a new LWC that manages displaying the data, with a custom permission to control if users can see the data unmasked in the UI.

[Senay-Ersen]

Hi @jongpie ,

Thanks for your answer. We will be looking forward to seeing this feature in a future release.