Security

VPC isolation

AuraDB Enterprise AuraDS Enterprise

AuraDB Enterprise and AuraDS Enterprise run within a Virtual Private Cloud (VPC) isolation for your deployment.

The VPC enables you to operate within an isolated section of the service, where your processing, networking, and storage are further protected.

Please note that the Aura Console runs in a separate VPC.

AWS Private endpoints

AuraDB Enterprise

AuraDB Enterprise supports private endpoints on AWS using AWS PrivateLink.

Once activated, you can create an endpoint in your VPC that connects to Aura.

privatelink
Figure 1. VPC connectivity with AWS PrivateLink

All applications running Neo4j workloads inside the VPC are routed directly to your isolated environment in Aura without traversing the public internet. You can then disable public traffic, ensuring all traffic to the instance remains private to your VPC.

  • PrivateLink applies to all instances in the region.

  • When activated, a Private Connection label, shield icon, and dedicated Private URI will appear on any instance tile using PrivateLink in the Aura Console.

  • If you disable public traffic, you must use a dedicated VPN to connect to your instance via Browser or Bloom.

  • Connections using private endpoints are one-way. Aura VPCs can’t initiate connections back to your VPCs.

  • In AWS region us-east-1, we do not support the Availability Zone with ID use1-az3 for private endpoints.

Browser and Bloom access over private endpoints

To connect to your instance via Browser or Bloom, you must use a dedicated VPN. This is because when you disable public access to your instance, this applies to all connections, including those from your computer when using Browser or Bloom.

Without private endpoints, you access Browser and Bloom over the internet:

privatelink 01 before enabling
Figure 2. Architecture overview before enabling private endpoints

When you have enabled private endpoints and disabled public internet access, you can no longer connect Browser or Bloom to your instances over the internet:

privatelink 02 enabled private traffic only
Figure 3. Architecture overview with private endpoints enabled and public traffic disabled

To continue accessing Browser and Bloom, you can configure a VPN (Virtual Private Network) in your VPC and connect to Browser and Bloom over the VPN.

To access Bloom and Browser over a VPN, you must ensure that:

  • The VPN server uses the VPC’s DNS servers.

  • You use the Private URI shown on the instance tile and in the instance details. It will be different from the Connection URI you used before.

privatelink 03 browser bloom over vpn
Figure 4. Accessing Browser and Bloom over a VPN

Enabling private endpoints

To enable private endpoints using AWS PrivateLink:

  1. Select Network Access from the sidebar menu of the Console.

  2. Select New network access configuration and follow the setup instructions.

You will need an AWS account with permissions to create, modify, describe and delete endpoints. Please see the AWS Documentation for more information.

GCP Private endpoints

AuraDB Enterprise AuraDS Enterprise

Aura Enterprise supports private endpoints on GCP using GCP Private Service Connect.

Once activated, you can create an endpoint in your VPC that connects to Aura.

privateserviceconnect
Figure 5. VPC connectivity with GCP Private Service Connect

All applications running Neo4j workloads inside the VPC are routed directly to your isolated environment in Aura without traversing the public internet. You can then disable public traffic, ensuring all traffic to the instance remains private to your VPC.

  • Private Service Connect applies to all instances in the region.

  • When activated, a Private Connection label, shield icon, and dedicated Private URI will appear on any instance tile using Private Service Connect in the Aura Console.

  • If you disable public traffic, you must use a dedicated VPN to connect to your instance via Browser or Bloom.

  • Connections using private endpoints are one-way. Aura VPCs can’t initiate connections back to your VPCs.

Browser and Bloom access over private endpoints

To connect to your instance via Browser or Bloom, you must use a dedicated VPN. This is because when you disable public access to your instance, this applies to all connections, including those from your computer when using Browser or Bloom.

Without private endpoints, you access Browser and Bloom over the internet:

privateserviceconnect 01 before enabling
Figure 6. Architecture overview before enabling private endpoints

When you have enabled private endpoints and disabled public internet access, you can no longer connect Browser or Bloom to your instances over the internet:

privateserviceconnect 02 enabled private traffic only
Figure 7. Architecture overview with private endpoints enabled and public traffic disabled

To continue accessing Browser and Bloom, you can configure a GCP Cloud VPN (Virtual Private Network) in your VPC and connect to Browser and Bloom over the VPN.

To access Bloom and Browser over a VPN, you must ensure that:

  • You have setup GCP Cloud DNS, or an equivalent DNS service, inside of the VPC.

  • You use the Private URI shown on the instance tile and in the instance details. It will be different from the Connection URI you used before.

privateserviceconnect 03 browser bloom over vpn
Figure 8. Accessing Browser and Bloom over a VPN

Enabling private endpoints

To enable private endpoints using GCP Private Service Connect:

  1. Select Network Access from the sidebar menu of the Console.

  2. Select New network access configuration and follow the setup instructions.

Please see the GCP Documentation for required roles and permissions.

Azure Private endpoints

AuraDB Enterprise

Aura Enterprise supports private endpoints on Azure using Azure Private Link.

Once activated, you can create an endpoint in your Virtual Network (VNet) that connects to Aura.

azure privatelink
Figure 9. VNet connectivity with Azure Private Link

All applications running Neo4j workloads inside the VNet are routed directly to your isolated environment in Aura without traversing the public internet. You can then disable public traffic, ensuring all traffic to the instance remains private to your VNet.

  • Private Link applies to all instances in the region.

  • When activated, a Private Connection label, shield icon, and dedicated Private URI will appear on any instance tile using Private Link in the Aura Console.

  • If you disable public traffic, you must use a dedicated VPN to connect to your instance via Browser or Bloom.

  • Connections using private endpoints are one-way. Aura VNets can’t initiate connections back to your VNets.

Browser and Bloom access over private endpoints

To connect to your instance via Browser or Bloom, you must use a dedicated VPN. This is because when you disable public access to your instance, this applies to all connections, including those from your computer when using Browser or Bloom.

Without private endpoints, you access Browser and Bloom over the internet:

azure privatelink 01 before enabling
Figure 10. Architecture overview before enabling private endpoints

When you have enabled private endpoints and disabled public internet access, you can no longer connect Browser or Bloom to your instances over the internet:

azure privatelink 02 enabled private traffic only
Figure 11. Architecture overview with private endpoints enabled and public traffic disabled

To continue accessing Browser and Bloom, you can configure a VPN (Virtual Private Network) in your VNet and connect to Browser and Bloom over the VPN.

To access Bloom and Browser over a VPN, you must ensure that:

  • You have setup Azure Private DNS, or an equivalent DNS service, inside of the VNet.

  • You use the Private URI shown on the instance tile and in the instance details. It will be different from the Connection URI you used before.

azure privatelink 03 browser bloom over vpn
Figure 12. Accessing Browser and Bloom over a VPN

Enabling private endpoints

To enable private endpoints using Azure Private Link:

  1. Select Network Access from the sidebar menu of the Console.

  2. Select New network access configuration and follow the setup instructions.

Please see the Azure Documentation for required roles and permissions.

Single Sign-On

AuraDB Enterprise AuraDS Enterprise

Aura Enterprise supports Single Sign-On (SSO) at both the Console level and for accessing Workspace, Bloom and Browser clients directly at the instance level.

Accessing Aura with SSO requires:

  • Authorization Code Flow with PKCE.

  • A publicly accessible Identity Provider (IdP) server.

Console SSO

Console SSO allows users to log in to the Aura Console using their company IdP credentials and grants Public Access privileges to all instances in the tenant.

The following OpenID Connect (OIDC) certified Identity Providers (IdPs) are currently supported for Console-level Authentication:

  • Microsoft Azure Active Directory (AAD)

  • Okta

To enable Console SSO on your Aura Enterprise tenant(s), please raise a support ticket including the following information:

  1. The Tenant ID of the tenant(s) you want to use SSO. See Tenants for more information on how to find your Tenant ID.

  2. The name of your IdP.

Instance SSO

Instance SSO allows you to directly map groups of users (as defined in your IdP) to DBMS RBAC roles when launching Workspace, Bloom and Browser clients from an Aura instance.

The following OIDC certified IdPs are currently supported for instance-level Authentication:

  • Microsoft Azure Active Directory (AAD)

  • Okta

  • Keycloak

  • Google Authentication

To add SSO for Workspace, Bloom, and Browser to your Aura Enterprise instances, please raise a support ticket including the following information:

  1. The Connection URI of the instance(s) you want to use SSO.

  2. Whether or not you want Workspace, Bloom, Browser, or a combination of them enabled.

  3. The name of your IdP.

If you have to specify an application type when configuring your client, Neo4j is a Single-page application. For more information on configuring your client, see Neo4j Single Sign-On (SSO) Configuration.

Supported TLS cipher suites

For additional security, client communications are carried via TLS v1.2 and TLS v1.3.

AuraDB has a restricted list of cipher suites accepted during the TLS handshake, and does not accept all of the available cipher suites. The following list conforms to safety recommendations from IANA, the OpenSSL, and GnuTLS library.

TLS v1.3:

  • TLS_CHACHA20_POLY1305_SHA256 (RFC8446)

  • TLS_AES_128_GCM_SHA256 (RFC8446)

  • TLS_AES_256_GCM_SHA384 (RFC8446)

TLS v1.2:

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (RFC5288)

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (RFC5289)

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC5289)

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (RFC7905)

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (RFC5288)

Encryption

All data stored in Neo4j Aura is encrypted using intra-cluster encryption between the various nodes comprising your instance and encrypted at rest using the underlying cloud provider’s encryption mechanism.

By default, each cloud provider encrypts all backup buckets (including the objects stored inside) using either Google-managed encryption, AWS SSE-S3 encryption, or Azure Storage encryption.

Customer Managed Keys

AuraDB Enterprise AuraDS Enterprise

This feature has been released as a public GA for AuraDB Enterprise and AuraDS Enterprise for AWS managed keys. GCP’s Cloud Key Management and Azure’s Key Vault are coming soon.

For more control over key operations than the standard Neo4j encryption, use a Customer Managed Key (CMK). Create and manage keys using a supported cloud key management service (KMS). Externally, Customer Managed Keys are also known as Customer Managed Encryption Keys (CMEK).

When using a Customer Managed Key, all data at rest is encrypted with the key. You can encrypt new Aura v5 instances using Customer Managed Keys. The feature is not supported for existing instances or v4.x instances.

When using Customer Managed Keys, you give Aura permission to encrypt and decrypt using the key, but Aura has no access to the key’s material. Aura has no control over the availability of your externally managed key in the KMS. If you lose keys that are managed outside of Aura, Aura can’t recover your data.

The loss of a Customer Managed Key, through deletion, disabling, or expiration, renders all data encrypted with that key unrecoverable. Neo4j cannot administer database instances when keys are disabled, deleted, or permissions revoked.

There is a limit of one key for AuraDB and one key for AuraDS per region. Depending on the KMS, there may be a delay between disabling a key, and when it can no longer be used to encrypt and decrypt data.

AWS key

  • Create a key in the AWS KMS ensuring the region matches your Aura database instance. Copy the generated ARN. You need it in the next step.

  • Go to security settings in the Aura Console, create a Customer Managed Key and copy the JSON code that is generated in the Aura Console when you add a key.

  • In the AWS KMS, edit the key policy to include the JSON code.

Editing the key policy

After you have initially created a key in the AWS KMS, you can edit the key policy. In the AWS key policy, "Statement" is an array that consists of one or more objects. Each object in the array describes a security identifier (SID). The objects in the AWS code array are comma-separated, e.g. {[{'a'}, {'b'}, {'c'}]}

Add a comma after the curly brace in the final SID, and then paste the JSON code that was generated in the Aura Console, e.g. {[{'a'}, {'b'}, {'c'}, add code here ]}

Regionality

When creating a Customer Managed Key in the AWS KMS, you can create a single-region key in a single AWS region, or create a multi-region key that you can replicate into multiple AWS regions. Aura only supports AWS Customer Managed Keys that reside in the same region as the instance.

In Aura, you can use AWS single-region keys, multi-region keys or replica keys as long as the key resides in the same region as the Aura instace.

Key rotation

In your KMS platform, you can either configure automatic rotation for the Customer Managed Key, or you can perform a manual rotation.

Although automatic rotation is not enforced by Aura, it is best practice to rotate keys regularly. Manual key rotation is not recommended.

AWS automatic key rotation

Aura supports automatic key rotation via the AWS KMS. To enable automatic key rotation in the AWS KMS, tick the Key rotation checkbox after initially creating a key, to automatically rotate the key once a year.

Deleting a key

In the Aura Console, if a Customer Managed Key is being used to encrypt one or more Aura instances, it cannot be deleted. To delete a Customer Managed Key in the Aura Console, first delete the Aura database instances encrypted with the key, then delete the Customer Managed Key.

Cloning an instance protected by CMK

To clone an instance protected by a Customer Managed Key, the key must be valid and available to Aura. The cloned instance, by default, uses the available Customer Managed Key for that region and product.

You can override this behavior by selecting the Neo4j Managed Key when cloning the database. If there is no valid CMK for the destination region and product, the Neo4j Managed Key is used to encrypt the cloned instance.

Importing an existing database

To upload a database greater than 4GB to instances encrypted with Customer Managed Keys in Neo4j 5, use neo4j-admin database upload. The neo4j-admin push-to-cloud command in Neo4j v4.4 and earlier is not supported for instances encrypted with Customer Managed Keys. For more information see the Neo4j Admin database upload documentation.