[SERVER-16212] Auditing should use hash-chaining for tamper-resistance Created: 18/Nov/14 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Adam Midvidy | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | Auditing, platforms-re-triaged | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Security
|
| Participants: | |
| Case: | (copied to CRM) |
| Description |
|
Currently mongodb's audit log is vulnerable to tampering by a malicious administrator. i.e, given a mongodb audit log there is no way to tell if any entries have been added, removed or modified. Roughly speaking, we could store a hash in each audit entry. Each hash would be computed from a combination that includes (but not limited to) the content of the current entry and the hash of the previous entry. The hashes form a chain that can be used to verify the integrity of the audit log. Note that there is a lot more detail required for a secure implementation |