Effective as of March 27, 2023
Security is a top priority at GrapheneDB and we understand how important your data is to you and those who depend on you. GrapheneDB realizes that it has been entrusted with a significant variety and amount of sensitive application and user data and we do not take our responsibility lightly; we work diligently to continuously improve security processes and controls, as well as provide our customers the right features to secure data as necessary.
GrapheneDB handles data with the utmost care and integrity, designing our systems to reduce the chance of errors from human factors, employing industry-standard information security best practices, and continuously testing to find and fix vulnerabilities. Whether it’s encrypting your data from end to end, or providing you with important access control features, we want customers to have confidence in the systems and services handling sensitive workloads as they are transported, processed, and stored.
This document contains abstracts of our internal Security Information Policy and is meant to show the processes that are followed and the efforts around security at GrapheneDB.
GrapheneDB Security Controls
Data Centers and Physical Storage
GrapheneDB runs on AWS, which is responsible for the security of its data centers, which are compliant with a number of physical security and information security standards detailed here https://aws.amazon.com/security/
In addition, you control the region where your GrapheneDB databases are deployed. This gives you the flexibility to decide where your Customer Data is physically stored, and you may choose to deploy your Customer Data in a specific geographic region (for example, only within the European Union or only within the United States).
Encryption in Transit
All GrapheneDB network traffic is protected by Transport Layer Security (TLS), which is enabled by default and cannot be disabled. Customer Data that you transmit to GrapheneDB is encrypted in transit using TLS.
TLS certificates are obtained from a major, widely trusted third-party public certificate authority. In the course of standard TLS key negotiation for active sessions, ephemeral session keys are generated which are never persisted to disk, as per the design of the TLS protocol.
Encryption at Rest
Upon creation of a GrapheneDB Deployment, by default, Customer Data is encrypted at rest using AES-256 to secure all data. That process is automated by AWS, which fully manages the encryption keys.
Network Isolation
All GrapheneDB databases are deployed into Environments, dedicated virtual private cloud within AWS (VPC), fully isolating your Customer Data and configured to prevent unwanted inbound network access from the internet.
Each such Environment utilizes security groups within dedicated networks that act as a virtual firewall for your dedicated GrapheneDB deployments.
GrapheneDB IP Access List
In order to allow inbound network access to your deployments, you can configure an IP Access List to enable connection to specific Environments. Environments, by default, have all access disabled. Unless the GrapheneDB IP Access List includes a specific network's IP addresses or CIDR ranges(or a peering has been established), external network traffic is prevented from accessing your GrapheneDB deployments.
Virtual Private Cloud Peering
You may enable peering between your GrapheneDB Environment to your own application tier VPC in AWS. Peering permits you to route encrypted traffic between your databases within a GrapheneDB Environment and your own application tier VPC privately, rather than traversing the public internet.
Access Controls
Customer Access
GrapheneDB supports multiple authentication options and methods to give you the flexibility to meet your individualized requirements and needs. You are responsible for understanding the security configuration options available to you and the impact of your selected configurations on your GrapheneDB Private Networks, which consists of a web application administrative interface (“GrapheneDB Console”) and any GrapheneDB deployments.
GrapheneDB Console and API Authentication and Authorization
GrapheneDB implements a customer identity and access management (CIAM) service that aligns with multiple security and compliance requirements, including those for highly regulated organizations such as healthcare companies and merchants. It is HIPAA eligible and PCI DSS, SOC, and ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, and ISO 9001 compliant.
Furthermore, you can add an additional layer of security by enabling MFA to your account and get your identity verified using SMS or a Time-based One-time Password (TOTP) generator.
For API access GraphneDB uses the Client Credentials Flow (defined in OAuth 2.0 RFC 6749, section 4.4), in which Client ID and Client Secret is passed along to authenticate and get a temporary token. You can manage API clients from our Console and revoke Credentials if needed.
GrapheneDB Deployments Authentication and Authorization
Authentication control for a GrapheneDB deployment is enabled by default using the native database auth provider.
GrapheneDB Staff Access to Deployments
As a general matter, GrapheneDB staff does not have the authorization to access your GrapheneDB deployments, nor the instances where the deployments are hosted. Only a small group of Privileged Users are authorized to access servers in rare cases where it is required to investigate and restore critical services. GrapheneDB adheres to the principle of “least privilege” with respect to those accesses.
Privileged Users and any access is limited to the minimum time and extent necessary to repair the critical issue. Privileged Users may only access the server where your GrapheneDB deployments are hosted via a secure bi-directional communication channel with traffic encrypted using TLS 1.2, without opening any new ports and under full audit. Access requires approval by GrapheneDB senior management.
GrapheneDB monitors the health and performance of the Service without needing to access your deployments. GrapheneDB maintains a centralized log management system for the collection, storage, and analysis of log and server data for our GrapheneDB infrastructure and your deployments. We use this information for health monitoring, troubleshooting, and security purposes.
Data security
Access to databases
At GrapheneDB we don’t have access to the credentials of your deployments. Authentication to deployments is natively managed by Neo4j and GrapheneDB staff doesn’t have access to credentials to databases. You are responsible for managing those credentials and storing them securely.
Only if we have specific authorization to access Customer Data and only in special cases to resolve a support request, for example, GrapheneDB support team might access Customer Data by restoring it into a test database and removing the authorization.
Customers can always decide if access to databases from GrapheneDB Team should be allowed or not during a support request by opting-in or -out in the New Support Request form.
Credit card security
GrapheneDB is PCI compliant under "PCI validation: SAQ A". We utilize Stripe Elements technology which has financial input fields that are done securely in Stripe's iframe. Stripe is certified as a PCI Level 1 Service Provider. This is the most stringent level of certification available in the payments industry.
For additional information on Stripe's security please visit https://stripe.com/help/security.
About GDPR
GrapheneDB as a processor of your Data is complying with the provisions of the Article 28.3 of Regulation (EU) 2016/679 (hereinafter, "the Regulation") and ensuring the security of Personal Data.
We will obtain assurances that all third-party service providers will safeguard your personal data in accordance with this policy and the European privacy laws.
We’re offering a Data Processing Agreement (DPA), which enables our customers to comply with their GDPR obligations. You can find our DPA here.
At GrapheneDB we’re not only committed to complying with GDPR but also aware that you will need to comply if you’re a business in the EU. We offer the following tools to help you with that:
- You can anytime modify, export or delete any record from the database using the available endpoints.
- You can permanently delete the content of a database by using the “empty database” feature. We’re going to very soon release a soft-delete feature for providing a clear and transparent policy on the permanent deletion of backups and datasets.
- You can export complete datasets using the export database feature.
- We offer a wide range of regions where you can host your data.
- We offer strong security measures to protect the data in your databases, meeting the GDPR requirements.
Contingency Planning
High Availability and Failover
Every GrapheneDB Cluster provides automatic failover in the event of a failure.
Clusters are deployed across multiple availability zones within a region, providing resilience to zonal outages within a region.
Snapshots
GrapheneDB offers Snapshots, which use the native snapshot functionality of AWS to locally back up your Customer Data. All Snapshots are encrypted at rest and live in the same region of your deployment.
You may enable Snapshots when you create or modify a deployment, and you have control over how often a Snapshot is captured and the length of time for which Snapshots are retained via managing the Snapshots policies.
Business Continuity and Disaster Recovery
GrapheneDB creates and configures dedicated deployments on infrastructure provided by AWS. Data availability also is subject to the infrastructure provider service Business Continuity Plans (BCP) and Disaster Recovery (DR) processes. AWS holds a number of certifications and audit reports for these controls.
For more information, please see here => https://aws.amazon.com/compliance/
For customer data, GrapheneDB allows users to select the region for the deployments. In case of cluster deployments a minimum of 3 nodes are created across different AWS AZs for continuous application uptime in the event of outages and maintenance.
Additionally, GrapheneDB provides a way to automate the creation of a new deployment in case of an outage or data corruption out of the last backup via the Public API.
Incident Response and Communications
Security Incident Response Plan
As part of the Security Program, GrapheneDB maintains an established Data Breach Response Plan. In the event that GrapheneDB becomes aware of a Data Breach or other security incident, GrapheneDB will follow the Data Breach Plan, which includes: (i) clearly defined roles and responsibilities, including designation of a security incident task force; (ii) reporting mechanisms; (iii) procedures for assessing, classifying, containing, eradicating, and recovering from security incidents; (iv) procedures and timeframes for required notifications to relevant authorities and customers; (v) procedures for forensic investigation and preservation of event and system log data; and (vi) a process for post-incident and resolution analysis designed to prevent future similar incidents.
The Data Breach Plan is reviewed, updated, and tested annually, including a security tabletop exercise at least once per year.
Customer Communications
GrapheneDB will notify you without undue delay if we become aware of any Data Breach. Taking into account the information available to us, such notice will include a description of the nature and cause of the Data Breach and the expected resolution time. To the extent possible, we will subsequently update you with information regarding the evaluation of the root cause, potential impact, remediation actions taken, and actions planned to prevent a future similar event.