Query Management & Security Event Logging in Neo4j Enterprise [Security Series, Part 4]


No matter the size or scope of your graph database, it’s vital to maintain secure control of your data and to keep a record of security events.

Starting in Neo4j 3.1 and all future releases, users will have increased control over database query management (with particular emphasis on admin controls). In addition, the 3.1 release also introduced security event logging to ensure you have a record of all critical security and access control events for the life of your graph database.

In this series on graph database security and access control, we’ll explore all of the different facets and features available in Neo4j Enterprise Edition to keep your data secure. In past weeks, we’ve looked at role-based access control in Neo4j, administering native user security and authorization, and using the LDAP protocol.

This week, we’ll take a closer look at administrative query management and security event logging.

Query Management


Neo4j 3.1 introduces the ability to list and terminate all currently executing queries visible to the user. In particular, admin can see and terminate any currently running query.

To simplify cluster topology management, Neo4j 3.1 introduces the Neo4j Browser widget, which is invoked with :queries and lists all currently running queries in the cluster.

Learn more about query management and security event logging in Neo4j Enterprise Edition


You can also use System Procedures: dbms.listQueries and dbms.killQuery both list queries on the currently connected instance.

Neo4j query management: list queries


Kill database queries with Neo4j query management


Security Event Logging


Neo4j 3.1 introduces a security event log that records all login attempts. To disable security event logging of successful attempts, use this setting:

dbms.security.log_successful_authentication=false

For native users, a broader set of user management functionality is available, so the security event log also records the following actions:
    • Change password for user and manual password resets
    • Creation and deletion of users including failed attempts (e.g., trying to create a user that already exists)
    • Creation and deletion of roles
    • Assigning and removing roles for users
    • Suspending and activating users
    • Failed attempts to call procedures that list users and roles (non-admin users)
Neo4j rotates the security event log every 20MB, if at least five minutes has passed and keeps the most recent seven logs. You can configure this behavior in the neo4j.conf configuration file. Use these settings to customize log rotation:

Setting Effect
dbms.logs.security.rotation.size Sets the file size at which the security event log will autorotate. Default is 20MB.
dbms.logs.security.rotation.delay Sets minimum time interval after last rotation of the security event log before may be rotated again. Default is 300sec.
dbms.logs.security.rotation.keep_number Sets number of historical security event log files kept. Default is 7.

Conclusion


This has been a brief overview of the administrative query management capabilities in Neo4j allowing graph database users to both list and kill currently running database queries. We also took a closer look at security event logging in Neo4j, including the more detailed security event log settings for native users.

Next week, we’ll take a closer look at custom authentication and authorization plugins, user-defined procedures and database security best practices. In the meantime, download the enterprise security white paper below to dive into more details.


Discover how to protect your graph data with enterprise-ready security and access control: Download this white paper, Why Intelligent Applications Need a Graph Database with Granular Securityn, and get started on securing your graph database today.

Read the White Paper


Catch up with the rest of the Neo4j graph database security series: