Keeping secrets out of logs (2024)
allan.reyes.sh
Keeping secrets out of logs (2024)
1–10 of 56 posts
Re: Keeping secrets out of logs (2024)
#2Great read.
> And while people will write the code that accidentally introduces sensitive data into logs, they’re also the ones that will report, respond, and fix them.
This should probably be the first point and not the last.
Re: Keeping secrets out of logs (2024)
#3This is an excellent excellent resource regardless of whether you agree/disagree with the author's conclusions, simply by virtue of being a great list of broken down problems, well described, & accompanied by good technical descriptions of proposed fixes (again independent of your opinion on those fixes).
Just an excellent example of how to approach & elucidate a problem domain.
Re: Keeping secrets out of logs (2024)
#4With java theres a GuardedString implementation https://docs.oracle.com/en/middleware/idm/identity-governanc...
Re: Keeping secrets out of logs (2024)
#5eazy
secrets.forEach(secret => logMessage = logMessage.replaceAll(secret, '**'))
Re: Keeping secrets out of logs (2024)
#6Just excellent. Lots of (common from my experience) examples, potential fixes and self-contained explanations. Nice.
Re: Keeping secrets out of logs (2024)
#7Great article!
I will definitely reference it in my upcoming discussions. I had some hard time defending having an EU based o11y stack for our EU based infra. I found it hard to articulate on the spot that there are myriads of places where sensitive/personal data can get in the logs and cause leaks, or make GDPR angry.
Re: Keeping secrets out of logs (2024)
#8I certainly agree with the desire to keep secrets out of logs, but isn’t the entire log itself also considered to be secret? Even a perfectly sanitized log probably contains lots of data about your production environment that you wouldn’t want to share with adversaries (e.g. peak usage hours).
Re: Keeping secrets out of logs (2024)
#9I certainly agree with the desire to keep secrets out of logs, but isn’t the entire log itself also considered to be secret? Even a perfectly sanitized log probably contains lots of data about your production environment that you wouldn’t want to share with adversaries (e.g. peak usage hours).
Logs probably need to be exposed to support teams, oncalls for sister-teams (if you are a large org), all your devs etc. That is many MANY more people than need access to secrets. Secrets in logs therefore puts you are much wider risk of internal threats and makes it MUCH easier for an attacker who phishes someone to pivot to higher credentials.
Also if you have audit records, you want accessing a secret to be logged separately from accessing logs.
Re: Keeping secrets out of logs (2024)
#10I certainly agree with the desire to keep secrets out of logs, but isn’t the entire log itself also considered to be secret? Even a perfectly sanitized log probably contains lots of data about your production environment that you wouldn’t want to share with adversaries (e.g. peak usage hours).
Yes, but think defense in depth. Your team member who leaves for a competitor could tell them your peak usage hours, but he shouldn't be able to tell them all your customers' passwords.