Security
Suggest editsCloud Service runs on EDB's Cloud Service account or Your Cloud Account. Every Cloud Service cluster is logically isolated from other Cloud Service clusters, but the security properties of the system are different in each deployment option. The key security features are:
Data isolation
Data isolation: With both deployment options, data is fully isolated between separate clusters. No two Cloud Service clusters share a Postgres process, virtual machine, or storage volume. The implementation of this isolation depends on the deployment option.
Your Own Cloud Account: Clusters are installed and managed on virtual machines and storage volumes deployed by Cloud Service on your behalf in your cloud environment. Complete segregation of your data is assured. Your data never leaves your cloud account, and your clusters don't share network segments with other customers' clusters.
Cloud Service's cloud account: Cloud Service deploys cloud infrastructure in accounts owned by Cloud Service. Every cluster is assigned a dedicated set of virtual machines and storage volumes, and these resources are never reused by Cloud Service across multiple clusters. Two clusters can share the same network segment, but access to the system is limited to prevent communication between clusters in the Cloud Service infrastructure.
Granular access control
With both deployment options, you can use single sign-on (SSO) and define your own sets of roles and role-based access control (RBAC) policies to manage your individual cloud environments. See Managing portal access for more information.
Data encryption
Cloud Service's encryption
All data in Cloud Service is encrypted in motion and at rest. Network traffic is encrypted using Transport Layer Security (TLS) v1.2 or greater. Data at rest is encrypted using AES with 256-bit keys. Data encryption keys are envelope encrypted, and the wrapped data encryption keys are securely stored in a key management system. When you use your own cloud account, encryption keys never leave your cloud environment.
Your own encryption key - Transparent Data Encryption (TDE)
Optionally enable Transparent Data Encryption (TDE) at the database level on Cloud Service's cloud account, AWS, GCP, or Azure. TDE encrypts all data files, the write-ahead log (WAL), and temporary files used during query processing and database system operations.
You can't enable nor disable TDE on existing clusters. To enable TDE, first connect the encryption keys to Cloud Service at the project level, and then select those keys while creating a cluster.
EDB supports enabling TDE with your own encryption key on single-node and primary/standby high-availability deployments running EDB Postgres Advanced Server or EDB Postgres Extended Server versions 15 and later. Both the key and cluster must be in the same region and hosted by the same underlying cloud provider.
This overview shows the supported cluster-to-key combinations.
| AWS cluster (BYOA) | AWS cluster (EHCS) | GCP cluster (BYOA) | GCP cluster (EHCS) | Azure cluster (BYOA) | Azure cluster (BAH) | |
|---|---|---|---|---|---|---|
| AWS Key Management Service | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ |
| Google Cloud Key Management | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ |
| Azure Key Vault | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ |
BYOA or bring-your-own-account: Cloud Service deploys the cluster on Your Cloud Account.
EHCS or EDB Hosted: Cloud Service deploys the cluster on a cloud provider account owned and managed by EDB.
Note
The process of encryption and decryption adds overhead in terms of CPU and RAM consumption, performance, and for managing keys for faraway replicas.
To enable TDE:
Before you create a TDE-enabled cluster, you must add a TDE key.
See Creating a new cluster - Security to enable a TDE key during the cluster creation.
Portal audit logging
Activities in the portal, such as those related to user roles, organization updates, and cluster creation and deletion, are tracked and viewed in the activity log.
Database logging and auditing
Functionality to track and analyze database activities is enabled automatically. For PostgreSQL, the PostgreSQL Audit Extension (pgAudit) is enabled for you when deploying a Postgres cluster. For EDB Postgres Advanced Server and EDB Postgres Extended Server, the EDB Audit extension (edb_audit) is enabled for you.
- pgAudit: The classes of statements being logged for pgAudit are set globally on a cluster with
pgaudit.log = 'write,ddl'. The following statements made on tables are logged by default when the cluster type is PostgreSQL:INSERT,UPDATE,DELETE,TRUNCATE, ANDCOPY. AllDDLis logged.
Database cluster permissions
With both deployment options, managing database cluster permissions is your responsibility. The edb_admin user created during the cluster creation process is granted superuser-like permissions, including the CREATEDB and CREATEROLE database roles. We recommend using the edb_admin user to create a new application user and new application database for further isolation. See Managing Postgres access for more information.
See also
Could this page be better? Report a problem or suggest an addition!