MongoDB Doesn’t Encrypt Audit Data ?!!
If you’re looking at MongoDB native auditing and though all your MongoDB environments enforce network encryption using SSL and signed certificates and wanted to know if the transmission of the audit data to a JSON/BSON file or the syslog file will be encrypted by default.
If not, how can this be configured?
Here comes the answer :
Please note that all audit destinations namely syslog, console, json or bson are local to the node that is running the mongodb instance which means that no network transmission is involved. Thus, the network encryption doesn’t apply here.
Though communication in this case is local, but this does not mean that there is no risk of sensitive data being captured.
For example we still use SSL for client/server MongoDB connections even if the the access is local (i.e. the client and the server are the same).
The concern here is that a privileged user (e.g. an SA logged in as root) could sniff clear text traffic (e.g. audit data directed at a JSON/BSON file or syslog) and pick out sensitive information.
From MongoDB Inc., what can be done ?
The current At Rest Encryption feature in MongoDB Enterprise 3.2 only handles the encryption of the actual data files, as well as situations where the server may need to write this data to disk (for example, during replica set rollback events). Neither log files nor audit files are encrypted by this feature.
However, some environments this poses a problem, and MongoDB inc., have some early plans to add a feature for redacting sensitive information from log and audit files before it is written to disk. For example, see SERVER-17959 (although the comments on that ticket suggest that it may not apply to auditing, further internal discussion on the ticket suggests that it may). Unfortunately, at this stage there are no definite plans for when or how this feature may be implemented.
In addition, that this log redaction feature is not necessarily aimed preventing System Administrators from accessing encrypted data, just to make it harder.
It’s usually impossible for the Unix security model to protect against a threat model which includes a malicious root user, even when encryption and redaction are in use. This is because of the wide-ranging and thorough access to all areas of the system that root users have.
However, root or admin is not secure in Linux/Unix systems
For example, a root user could easily restart the mongod process with log/audit file encryption disabled, or with authentication disabled, or with SSL made optional, and so on.
They also have access to the entire contents of memory in the server, as well as all network traffic in and out (despite SSL, if it is in use, because they can access the server’s SSL credentials). There are a multitude of attacks that root can be perform to access sensitive data, and the all-or-nothing nature of the Unix security model means that once an attacker has obtained root access, there are (generally) no further protections that can be afforded.
The conclusion of this is that on Unix systems it is generally necessary to trust System Administrators as if they can access any data (because given sufficient effort, they can).