It's time for me to add authentication and authorization to my growing list of applications. I am so far using only Neo4J Enterprise. My understanding of current best practices is to ensure that plain-text personal information should never be "at rest" in a secure system. I plan to create a "user_information" database. My question is whether to build this new database in Neo4J Enterprise or to use a database technology that's more familiar to me (such as MySQL).
All of the following is in the context of a robust AWS EC2 instance running an up-to-date Rocky Linux v8.6 system. I'm using Neo4J Enterprise v4.4.11 with the most recent apoc core package installed.
I believe that the current Cypher API does not include encrypt/decrypt/hash -- that's fine.
Consider the SSN of a user. I contemplate having a property named "ssnCipher" on some new labelled node. I also contemplate a second property named "ssnDigest" containing a strongly-hashed digest (with salt). I contemplate creating the value of these properties using the usual security tools, with strong secured key, encryption and hash algorithms performed using reasonable nodejs packages (I will not be rolling my own!).
I think I understand how to load and store these properties in Neo4J using the usual tools.
I expect to restrict my Cypher queries to use only "ssnCipher" and "ssnDigest" and their analogs.
Just to keep the recursive wheel turning, I expect to store per-user neo4j access credentials in this new database, and those will of course be encrypted (and perhaps hashed). I can't avoid offering the plaintext credentials when establishing user access to Neo4J.
How safe is my assumption that the above approach will avoid having any personal information in plaintext at rest in Neo4J? For example, does Neo4J itself avoid storing access credentials in plaintext in the various logs, transaction records, and so on?
I invite the guidance of this community about how to effectively avoid having plain-text personal information at rest anywhere in Neo4J. I'm particularly interested in hearing from anyone whose been through a security audit from one of the several third-party firms that do such audits for large companies like Experian and IBM.