Now that you have gained experience managing a Neo4j instance and database , as well as managing Neo4j Causal Clusters, you will be introduced to how to secure a Neo4j application.
At the end of this module, you should be able to:
Many applications today are distributed and provide services and data over the Internet. Users include customers, partners, and off-site employees. In this interconnected world, security is a major concern. There are malicious actors who will attempt to access your application’s data, causing disruption and financial loss to your business. There are numerous ways that can be used to attack the data via the Internet, intranet, and even the ‘human’ back door. Fixing a security breach may require significant updates to your application, especially if the application was not written or implemented to be secure. Deploying a newer version of your application means additional testing and possible down time, both costly to the enterprise.
In addition, your business may need to meet regulatory security requirements or security requirements promised in a customer contract. If it is discovered that your application does not meet these requirements, you could face fines or other serious consequences.
To secure your application, you need to be concerned about 3 things:
Some information in an application is private must be protected. Exposing a customer’s private information could ruin the reputation of your enterprise, which could take years to recover from. Here are some examples of the types of private data your application needs to secure:
Controlling who accesses your application and what they have access to is very important to the business. You want to ensure that only valid users can use the application and malicious actors are kept out. In addition, you want to control which users can access specific application functionality and monitor what users do.
Another concern in applications that extend to the Internet is user privacy. When a Web or mobile app requests data from your application, you need to ensure that only the required data is retrieved and sent to the app. That is, if the app requests personal information, such as a driver’s license ID, the data returned to the app contains only the ID for the user requested and not the IDs of multiple users that the app, then has to filter for display.
Neo4j applications consist of many parts, including databases, static files like images and document scans, application code, application servers and Web servers. These all need to be secured and you use different techniques and technologies to secure them.
There are many things you can do to make your Neo4j application secure. At the highest level, there are 2 areas you must address:
The primary facets of building security into your Neo4j application include:
At a high level, the implementation of how your application performs authentication, authorization, and auditing can be configured by you as an administrator. However, there are aspects of security that may cross into application code. For example, there may be a specific procedure written that can only be executed by certain users. The procedure must be annotated and configured as such. In addition, code may be written to check roles at runtime for authorization.
Securing a deployed Neo4j application and its infrastructure includes securing Neo4j instances and non-Neo4j server processes they communicate with, filesystems, networks, etc. This can include:
In this module, you will be introduced to how you as an administrator can secure those parts of the application related to Neo4j. This module will not cover tasks related to securing non-Neo4j resources, networks, and filesystems.
As an administrator, you must be aware of all software on your production systems and keep up-to-date with the software. In particular, you must ensure that the Neo4j version you are using has the the latest versions and patches, especially those that address security.
There are three types of authentication frameworks supported by Neo4j:
Native user authentication means that users are created in the Neo4j database and authentication is performed based upon those values. Most enterprise applications do not use native user authentication in their deployed application.
Your application developers could write a custom authentication plugin. Although this is possible, the underlying internal procedures called by the custom authentication plugin could change in future releases of Neo4j so it is best to avoid this type of authentication for a deployed, secure application that will survive upgrades of Neo4j.
A SPA is highly recommended by Neo4j because it is easier to maintain and is more secure than an enterprise that uses multiple sources of user accounts. Examples of a SPA are Lightweight Directory Access Protocol (LDAP), Active Directory (AD), and Kerberos which can be used for single sign-on. The SPA is the only service in your enterprise that stores user names and passwords. For training purposes, we will use an LDAP provider for authentication, but in your real application, you will need to configure Neo4j for whatever provider your application uses for user authentication.
You will use OpenLDAP for the hands-on Exercises of this module.
If you will be using a different LDAP or authentication provider in your real application, you should consult the Neo4j Operations Manual.
A secure Neo4j instance should always have authentication enabled. By default, authentication is enabled for a Neo4j instance. You can explicitly set it in neo4j.conf as follows:
Even though roles are not required for authentication, they are for authorization to access Neo4j. Roles must be built into the configuration of a SPA, for example LDAP. Roles are used at runtime to authorize how the current user can access Neo4j resources (data or procedures).
Refer to this table in the Neo4j Operations Manual that describes Neo4j native roles. One of these pre-defined, native roles must be associated with any user that will be connecting to the Neo4j instance for general access. So for example, the user with the role of reader will only have read access to the database while a user with the role of publisher will be able to create data in the database.
In addition, you can define custom roles that are application-specific and used together with specific custom procedures.
Users “in the building”, such as employees can access the application from an internal network. These networks are secure. In addition, “off site” employees typically access the application using a Virtual Private Network (VPN) which is also secure. Customers or other users who access the application over the Internet, by default, do not use a secure connection. If these customers send private data like pass-phrases and credit card numbers, it can be examined, stolen, or altered by a malicious actor somewhere on the Internet. To secure their connection, you must provide SSL/TLS access your application. SSL/TLS is a software layer that encrypts data sent and received over the Internet.
If your application has users that access the application over the Internet, you should implement SSL/TLS by doing the following.
A digital certificate is used by client applications when they communicate with the server processes using SSL/TLS. A digital certificate must have an expiration date.
|You must ensure that the version of SSL/TLS software your application uses is up-to-date and that it supports all the types of clients that will be accessing your application. For example, not all browsers are compatible with the latest SSL/TLS versions.|
You should recommend that external users store the following artifacts securely:
Because the use of certificates is secure and requires a domain that you own as well as certificates from a trusted Certificate Authority (CA), you will learn how to configure a Neo4j instance, but will not perform the steps in your training environment. The creation of certificates and keys should be used in your real production environment.
Here are the steps you should take for your production system.
Your Neo4j instance can only provide SSL if you have installed JCE. On Linux/Debian, you can confirm that your specific ports of the running Neo4j instance are SSL-capable by executing one of the following commands:
Suppose we have installed JCE for use with our Neo4j instance. Here is an example where we see that the HTTPS port uses these ciphers and the HTTP port does not:
Determine how many security policies you will use. For example, you may have policies for clients, backups, and cluster communications. Each policy will have its own private key (private.key) and public certificate (public.crt). You must obtain the certificates from a trusted Certificate Authority in PEM format. If your application requires multiple certificates, they can be combined into a single file.
To obtain a certificate you must first have a domain name that you own. You can buy a fixed domain name or you can buy a more flexible one from a site such as dyn.com. There are many providers of certificates you can use. Here is an article that explains how to use LetsEncrypt which works well with Neo4j instances.
The default location for certificates is defined in neo4j.conf with the dbms.directories.certificates property.
In this location, create a folder for each security policy your application requires, for example client_policy, backup_policy, cluster_policy. Then, in each of these folders, create the revoked and trusted sub-folders.
Place the .key and .cert files in the top-level folder for the security policy. Place a copy of the .cert file in the trusted folder for the security policy.
|If you are using LetsEncrypt, follow the instructions in the article regarding links to the certificates and keys rather than copying them.|
Here is an example of recommended settings to configure SSL for a Neo4j instance that will support SSL for all clients:
The directory client_policy is where the certificate and key is available to the Neo4j instance. All bolt communication must use tls_level, which ensures that all credentials used for authentication and clear-text data are encrypted. Additionally, we ensure that all Web access for the Neo4j Browser must be via HTTPS.
For each Neo4j instance that will serve as a core server or read replica, you should configure SSL as you do for a stand-alone Neo4j instance. You must configure a separate policy for the cluster, for example cluster_policy. Each server will use both the client_policy and the cluster_policy.
Here is an example of the SSL configuration for a member of a cluster that you add to the Neo4j configuration in addition to the SSL configuration settings you saw earlier for the client policy:
Whether you are using Neo4j stand-alone or in a cluster, a best practice is to also ensure that SSL is used for backups. To do so, you can create and configure a policy, for example backup_policy, for backups that also requires a certificate.
You should work with your security administrator to come up with a set of guidelines for developers of your application to ensure that data-in-transit is secure. For example, developers should never include private data in a Cypher statement, but use parameters to avoid Cypher injections at runtime.
Securing data-at-rest means securing private data in a Neo4j installation including databases and backups.
An enterprise database typically contains private customer, personal, and financial data. If you do not secure the private data in the database, a malicious actor could access or steal the database and the private data would be exposed.
OS-level security restricts access to application files such as:
The system administrator is responsible for setting the access permissions for all files stored in the filesystem. If a malicious actor can access a directory in a filesystem that contains application files, they can steal, modify, or delete files in that directory. In addition, if the files in that directory contain private information, this information could be exposed.
Using a non-privileged, dedicated service account restricts the database from accessing the critical areas of the operating system that are not required by the Neo4j instance. This will also mitigate the potential for unauthorized access via a compromised, privileged account on the operating system.
You can determine which processes are owned by neo4j using:
ps -ef |grep -E “neo4j”
By default the user, neo4j owns the processes running that are related to the Neo4j instance.
The following directories should be read-only:
The following directories should be read/write:
And the bin directory should be execute.
You should also set the log files to only be writable by neo4j and readable by root.
You must have a plan for analyzing a suspected security breach so you can respond quickly and effectively. As part of that plan, you should implement a security audit trail that captures which users logged in successfully and those that failed.
Implementing an audit trail does not secure your application against malicious actors, but the information that is captured can be used to alert you of a potential security breach or to aid in the investigation of a suspected security breach.
Here are some recommended settings for security auditing in Neo4j:
In a troubleshooting situation or if you want to more closely monitor access, you would set the level to DEBUG.
In this Exercise, you will modify the security auditing configuration for the stand-alone Neo4j instance that you have worked earlier in this module.
Before you begin
MATCH (n) RETURN count(n);. You should receive an error because this user does not have the reader role.
MATCH (n) RETURN count(n);.
So as you have seen, you can audit for logins and failed logins, even with the default security level of INFO.
You may want to consider not using any default ports for your Neo4j instances. Hackers frequently scan IP addresses for commonly used ports, so it’s not uncommon to use a different port to “fly under the radar”.
neo4j-shell utility has been deprecated and you should not allow any users to use it. By default, it is not enabled in a Neo4j instance.
JMX is sometimes used for monitoring system activity. JMX is not secure and by default is disabled in Neo4j.
You should work closely with Neo4j Professional Services and Technical Support to ensure that your production system is secure. See this Security Checklist will also help you to determine if you have set up your systems correctly.
Suppose you will be using an enterprise LDAP provider and you must work with the LDAP administrator to ensure that all users who will be accessing the Neo4j database will have read or write access. What needs to be added to the LDAP?
Select the correct answer.
Suppose that you want to ensure that all data in or out of a Neo4j instance is secure (data-in-transit). What must you configure?
Select the correct answers.
In order to configure a security policy for SSL in Neo4j, what must you obtain?
Select the correct answers.
You should now be able to: