The Neo4j BI Connector: Security

Graph data platform adoption is on the rise. But does this mean that people have to give up their favorite BI tools? The answer is a resounding no.

The Neo4j BI Connector delivers direct access to Neo4j graph data from business intelligence (BI) tools such as Tableau, Looker, TIBCO Spotfire Server and Microstrategy. It’s the first enterprise-ready, supported product to deliver connected data results to BI users avoiding coding, custom scripting and ungoverned access.

In this fourth blog of our five-part series on the BI Connector, we cover the important topic of data security, ensuring only the right people have access to graph data, whether queried directly or through a BI tool.

Security

In January 2020, Neo4j released the biggest set of improvements to the product ever with version 4.0. This release included a powerful set of new security features, including multitenancy and fine-grained access control within a graph.

Neo4j 4.0 Security Controls

Users can now segregate data into multiple, separated graphs to control access and further control access within a specific graph by granting or denying read access down to the individual label, property and relationship.

Restricting Access for BI Users

Remember that the BI Connector functions as a regular client of the database by using regular user credentials and the Bolt protocol. And so, all of this security configuration immediately applies to the BI Connector. Users are able to see the schema the Neo4j graph contains, but queries for data will be subject to the security rules enforced by the database.

Access Control Example

To give a concrete example of these recommendations, an appendix provides a simple scenario of users with address information, phone and social security number. We create a sample user marketing_analyst who has the security role bi_user. That user is permitted to read and traverse the data in the Neo4j database, but is specifically disallowed from accessing the following information:

• Traversing relationships that connect a user to their social security number
• Reading the SSN attribute, which provides the actual user social security number

All of this is done in pure system commands to Neo4j, which handles enforcement for us.

At the BI Connector layer, all we need to do is connect to the database as the marketing_ analyst user. The result is that the SSN table appears empty except for a node ID. It isn’t actually empty, this user simply isn’t permitted to see the single attribute that is there – the actual social security number.

Key Recommendations

• External users of the BI Connector should be given their own user accounts and passwords
• Graph administrators should grant appropriate privileges to only the databases necessary
• Centralize access management using existing Neo4j techniques to secure access to your graph data

Conclusion

Ensuring data security is a critical topic for everyone these days, especially with increasing data privacy regulations. The Neo4j Graph Data Platform offers an intuitive and robust way to ensure that users have access only to the data they are permitted to see.

Next week, in the final blog of our five-part series on the BI Connector, we will discuss how to ensure the best possible performance for BI users and how to troubleshoot any difficulties you may encounter.