Security
BigAnimal runs in your own cloud account or BigAnimal's cloud account. Every BigAnimal cluster is logically isolated from other BigAnimal clusters, but the security properties of the system are different in each deployment option. The key security features are:
Data isolation: With both deployment options, data is fully isolated between separate clusters. No two BigAnimal 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 BigAnimal 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.
- BigAnimal's cloud account: BigAnimal deploys cloud infrastructure in accounts owned by BigAnimal. Every cluster is assigned a dedicated set of virtual machines and storage volumes, and these resources are never reused by BigAnimal 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 BigAnimal 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: All data in BigAnimal 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.
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
. AllDDL
is logged.
- pgAudit: The classes of statements being logged for pgAudit are set globally on a cluster with
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
- On this page
- See also