Security in Azure Cosmos DB for PostgreSQL
APPLIES TO: PostgreSQL
This page outlines the multiple layers of security available to protect the data in your cluster.
Information protection and encryption
Whenever data is ingested into a node, Azure Cosmos DB for PostgreSQL secures your data by encrypting it in-transit with Transport Layer Security 1.2. Encryption (SSL/TLS) is always enforced, and can’t be disabled.
The Azure Cosmos DB for PostgreSQL service uses the FIPS 140-2 validated cryptographic module for storage encryption of data at-rest. Data, including backups, are encrypted on disk, including the temporary files created while running queries. The service uses the AES 256-bit cipher included in Azure storage encryption, and the keys are system-managed. Storage encryption is always on, and can't be disabled.
Azure Cosmos DB for PostgreSQL supports three networking options:
- No access
- This is the default for a newly created cluster if public or private access is not enabled. No computers, whether inside or outside of Azure, can connect to the database nodes.
- Public access
- A public IP address is assigned to the coordinator node.
- Access to the coordinator node is protected by firewall.
- Optionally, access to all worker nodes can be enabled. In this case, public IP addresses are assigned to the worker nodes and are secured by the same firewall.
- Private access
- Only private IP addresses are assigned to the cluster’s nodes.
- Each node requires a private endpoint to allow hosts in the selected virtual network to access the nodes.
- Security features of Azure virtual networks such as network security groups can be used for access control.
When you create a cluster, you may enable public or private access, or opt for the default of no access. Once the cluster is created, you can choose to switch between public or private access, or activate them both at once.
Limits and limitations
See Azure Cosmos DB for PostgreSQL limits and limitations page.