Introduction
Security logs provide a complete audit trail of authentication, authorization, and session events in your Aura database. They help you identify security threats, debug permission issues, and maintain compliance with audit requirements.
In this lesson, you will learn how to use security logs to monitor database access and investigate security incidents.
Accessing Security Logs
To access security logs, navigate to your Aura instance, click Operations, select Logs, and choose the Security tab.
Security logs are available for 30 days, and each request can retrieve up to 24 hours of data.
Security Log Interface
The security log interface provides filters to narrow your search and two views to analyze security events.
You can filter security logs by:
-
Status: Info, Warning, Error
-
Executing user: Database user who performed the action
-
Authenticated user: User whose credentials were used to authenticate the session
-
Driver: Client driver used to connect
-
Message text: Search within log messages (case-insensitive)
Summary and Details Views
The Summary tab shows aggregated security events grouped by status and executing user. This view displays the count, time range, and users involved for each event pattern.
The Details tab shows individual security event records with specific timestamps, users, databases, and driver information.
Understanding Security Events
Security logs track three main categories of events.
-
Authentication Events
-
Authorization Events
-
Session Events
Authentication Events
Successful authentication events have an Info status and the message "Successful authentication". These indicate normal login activity.
Failed authentication events have a Warning or Error status and the message "Authentication failed". These may indicate credential issues, expired passwords, or attack attempts.
Authorization Events
Permission denied events have a Warning status and indicate a user attempted an operation they’re not authorized to perform. These help identify role configuration issues or application misconfiguration.
Role change events have an Info status and track administrative actions that modify user permissions.
Session Events
Logged in and Logged out events have an Info status and track the session lifecycle. These help you understand user activity patterns and session duration.
Common Security Monitoring Scenarios
You can use security logs to monitor for:
-
Failed logins
-
Permission issues
-
Audit compliance
-
Suspicious activity
Monitoring Failed Logins
To identify potential security threats, filter by Status: Error or Warning and Message text: "authentication failed".
Look for repeated failures from the same user, failures for non-existent users, or patterns suggesting brute force attacks. Check the Driver field to see if attempts come from known applications.
Debugging Permission Issues
To troubleshoot authorization problems, filter by Status: Warning and Message text: "permission" or "denied".
Identify which users lack necessary permissions and which operations they attempted. Check if recent permission changes caused the issues.
Audit Compliance
To track all database access for compliance requirements, set the time period to your audit period (e.g., last 30 days) without additional filters.
Export the logs using the download option for compliance reporting.
Investigating Suspicious Activity
Review security logs for logins at unusual times, access from unexpected drivers, privilege escalation attempts, or unusual user activity patterns.
Correlate security events with query logs to identify failed authentication followed by queries or permission denials with specific query patterns.
Security Log Best Practices
Review security logs periodically to establish baseline patterns. You should filter for repeated failed authentication attempts, which may indicate attacks or configuration issues.
Retain logs according to your compliance requirements and maintain an audit trail for regulatory purposes.
Check your understanding
Filtering for Suspicious Driver Activity
Your production Java application uses the app_service database user and always connects with the neo4j-java/5.x driver.
While reviewing security logs, you notice several successful login entries for the app_service user from a neo4j-python/5.x driver—which your application never uses.
You want to filter the security logs to show only these suspicious Python driver connections for further investigation.
Which combination of filters would display exactly this suspicious activity?
Hint
You’re looking for successful logins from a specific user using an unexpected driver. What filters would show exactly that?
Solution
Executing user: "app_service" and Driver: "neo4j-python" are both correct.
This combination isolates exactly the suspicious activity: the app_service account connecting from an unexpected Python driver. These two filters are sufficient to show all instances of this specific security concern.
Status: Error - This wouldn’t help because the scenario mentions successful logins. Successful authentications have Info status, so filtering for Error would exclude the suspicious activity you’re trying to find.
Database: "neo4j" - Database is not available as a filter option in the security logs interface. The available filters are Status, Executing User, Authenticated User, Driver, and Message text.
The key insight: Use the minimum filters needed to isolate the anomaly—in this case, the specific user account and the unexpected driver that’s connecting.
Authenticated vs Executing User
What is the difference between the Authenticated User and Executing User fields in security logs?
-
❏ Authenticated User shows who ran the query, Executing User shows who owns the database
-
❏ They always show the same user and are redundant fields
-
✓ Authenticated User shows whose credentials were used, Executing User shows who performed the action
-
❏ Authenticated User is for console access, Executing User is for database access
Hint
These fields can differ when impersonation is used.
Solution
Authenticated User shows whose credentials were used, Executing User shows who performed the action is correct.
These fields differ when impersonation is used. Authenticated User is who logged in, while Executing User is who actually performed the action. This distinction is critical for audit trails when investigating security incidents.
Summary
In this lesson, you learned how to use security logs to monitor database access and investigate security incidents.
Security logs track authentication, authorization, and session events with filters for status, executing user, authenticated user, driver, and message text. The Summary view shows aggregated patterns while the Details view shows individual events.
Common use cases include monitoring failed logins for security threats, debugging permission issues, maintaining audit compliance, and investigating suspicious activity patterns.
In the next module, you will learn about monitoring instance-level resources including heap memory, storage, and connections.
