Introduction
At GrapheneDB, we prioritize security and recognize the significance of your data to you and those who depend on you. We acknowledge the responsibility entrusted to us in safeguarding a wide range of sensitive application and user data, and we are committed to fulfilling this responsibility diligently. Our continuous efforts revolve around enhancing security processes and controls while equipping our customers with essential features to ensure data security as required.
We handle data at GrapheneDB with the utmost caution and integrity. Our systems are designed to minimize the possibility of errors resulting from human factors. We adhere to industry-standard information security best practices and conduct regular testing to identify and rectify vulnerabilities. We employ measures such as end-to-end data encryption and provide essential access control features to instill confidence in our customers regarding the security of their sensitive workloads during transportation, processing, and storage.
This article represents an overview of our internal Security Information Policy, highlighting the processes followed and the efforts undertaken to uphold security at 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 in this document here.
Moreover, as a user of GrapheneDB, you have the authority to choose the region in which your databases are deployed. This grants you the flexibility to determine the physical storage location of your Customer Data. You have the option to deploy your Customer Data in a specific geographic region, such as exclusively within the European Union or solely within the United States, based on your preferences and requirements.
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.
- Data in Disk. This is encrypted by AWS by using an encrypted file system. More details can be found here.
- Data in Snapshots. This is similar to the above. Snapshots are also encrypted at rest using the same mechanism. Keys are managed by AWS when it has to decrypt. More details can be found here.
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 Environments, which consists of a web application administrative interface (GrapheneDB Console) and any GrapheneDB deployments.
GrapheneDB Console 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 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 opting-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 this link.
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. Please contact our support team if you require the additional info on Data Processing Agreement (DPA).
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 terminating the database.
- 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 follow this link.
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.