[SERVER-47108] Support automatic redaction of Status and DBException by the logging system Created: 25/Mar/20 Updated: 11/Jan/23 Resolved: 11/Jan/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Logging |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Backlog - Security Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Security
|
| Sprint: | Security 2020-04-20, Security 2020-05-04, Security 2020-05-18, Security 2020-06-01, Security 2020-06-29 |
| Participants: |
| Description |
|
We are supposed to redact a Status or DBException prior to logging it, if it is possible that this entry may contain some sensitive information (e.g., unencrypted user data). This is a bit error prone, because it requires engineers to remember to add redact. It would be nice if the new V2 logging system automatically did this. With a disclaimer that I only thought about this for 15 seconds, where is what I am imagining: Somehow change the traits of CustomAttributeValue to check whether it is of type Status or DBException and instead of calling T::toString to actually call redact(T::toString()). My reasoning was that if this framework knows that there's a method toString it must also know that there is a specific type. |
| Comments |
| Comment by Andy Schwerin [ 01/Jun/20 ] |
|
I think that's a smart idea, sara.golemon! |
| Comment by Sara Golemon [ 01/Jun/20 ] |
|
Redacting full statuses in all log messages is going to be too aggressive, but I'd like to pivot this ticket into a larger project (possibly an epic?) of structuring Status (to fit in with structured logs). Naïvely, I think we can redesign Status to have a fixed message (and possibly ID) with a bag of attributes similar to our LOGV2 structure. A status propagated to a log message could then have its attribute bag (optionally) redacted while leaving the message text (and ID) in place. We could also provide a no-redact mechanism for data which are known to not be sensitive. This is a conversation which deserves to have a number of other stakeholders in the room before we move forward on it in any way. |