Azure security baseline for Azure Database for PostgreSQL - Hyperscale

This security baseline applies guidance from the Azure Security Benchmark version1.0 to Azure Database for PostgreSQL - Hyperscale. The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to Azure Database for PostgreSQL - Hyperscale.

Note

Controls not applicable to Azure Database for PostgreSQL - Hyperscale, or for which the responsibility is Microsoft's, have been excluded. To see how Azure Database for PostgreSQL - Hyperscale completely maps to the Azure Security Benchmark, see the full Azure Database for PostgreSQL - Hyperscale security baseline mapping file.

Network Security

For more information, see the Azure Security Benchmark: Network Security.

1.1: Protect Azure resources within virtual networks

Guidance: Azure Database for PostgreSQL server firewall prevents all access to your Hyperscale (Citus) coordinator node until you specify which computers have permission. The firewall grants access to the server based on the originating IP address of each request. To configure your firewall, you create firewall rules that specify ranges of acceptable IP addresses. You can create firewall rules at the server level.

Responsibility: Customer

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.DBforPostgreSQL:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Private endpoint should be enabled for PostgreSQL servers Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for PostgreSQL. Configure a private endpoint connection to enable access to traffic coming only from known networks and prevent access from all other IP addresses, including within Azure. AuditIfNotExists, Disabled 1.0.2

1.9: Maintain standard security configurations for network devices

Guidance: Define and implement standard security configurations for network settings and network resources associated with your Azure Database for PostgreSQL instances with Azure Policy. Use Azure Policy aliases in the "Microsoft.Network" namespace to create custom policies to audit or enforce the network configuration of your Azure Database for PostgreSQL instances.

Responsibility: Customer

Azure Security Center monitoring: None

Logging and Monitoring

For more information, see the Azure Security Benchmark: Logging and Monitoring.

2.2: Configure central security log management

Guidance: For control plane audit logging, enable Azure Activity Log diagnostic settings and send the logs to a Log Analytics workspace, Azure event hub, or Azure storage account for archive. Using Azure Activity Log data, you can determine the "what, who, and when" for any write operations (PUT, POST, DELETE) performed at the control plane level for your Azure resources.

Also, ingest logs via Azure Monitor to aggregate security data generated by Hyperscale (Citus). Within the Azure Monitor, use Log Analytics workspace(s) to query and perform analytics, and use storage accounts for long-term/archival storage. Alternatively, you may enable, and on-board data to Azure Sentinel or a third-party Security Incident and Event Management (SIEM).

Responsibility: Customer

Azure Security Center monitoring: None

2.3: Enable audit logging for Azure resources

Guidance: Hyperscale (Citus) provides metrics for each node in a server group. The metrics give insight into the behavior of supporting resources. Each metric is emitted at a one-minute frequency, and has up to 30 days of history.

For control plane audit logging, enable Azure Activity Log diagnostic settings and send the logs to a Log Analytics workspace, Azure event hub, or Azure storage account for archive. Using Azure Activity Log data, you can determine the "what, who, and when" for any write operations (PUT, POST, DELETE) performed at the control plane level for your Azure resources.

Also, ingest logs via Azure Monitor to aggregate security data generated by Hyperscale (Citus). Within the Azure Monitor, use Log Analytics workspace(s) to query and perform analytics, and use storage accounts for long-term/archival storage. Alternatively, you may enable, and on-board data to Azure Sentinel or a third-party Security Incident and Event Management (SIEM).

Responsibility: Customer

Azure Security Center monitoring: None

2.5: Configure security log storage retention

Guidance: Within Azure Monitor, for the Log Analytics workspace being used to hold your Hyperscale (Citus) logs, set the retention period according to your organization's compliance regulations. Use Azure Storage Accounts for long-term/archival storage.

Responsibility: Customer

Azure Security Center monitoring: None

2.6: Monitor and review logs

Guidance: Analyze and monitor logs from your Hyperscale (Citus) instances for anomalous behavior. Use Azure Monitor's Log Analytics to review logs and perform queries on log data. Alternatively, you may enable and on-board data to Azure Sentinel or a third-party SIEM.

Responsibility: Customer

Azure Security Center monitoring: None

2.7: Enable alerts for anomalous activities

Guidance: You may enable diagnostic settings for Hyperscale (Citus) and send logs to a Log Analytics workspace. You can configure and receive an alert based on monitoring metrics for your Azure services. Use Azure Monitor's Log Analytics to review logs and perform queries on log data. Alternatively, you may enable and on-board data to Azure Sentinel or a third-party SIEM.

Onboard your Log Analytics workspace to Azure Sentinel as it provides a security orchestration automated response (SOAR) solution. This allows for playbooks (automated solutions) to be created and used to remediate security issues.

Responsibility: Customer

Azure Security Center monitoring: None

Identity and Access Control

For more information, see the Azure Security Benchmark: Identity and Access Control.

3.1: Maintain an inventory of administrative accounts

Guidance: Maintain an inventory of the user accounts that have administrative access to the control plane (e.g. Azure portal) of your Hyperscale (Citus) instances. In addition, maintain an inventory of the administrative accounts that have access to the data plane (within the database itself) of your Hyperscale (Citus) instances.

Hyperscale (Citus) does not support built-in role-based access control, but you can create custom roles based on specific resource provider operations.

Additionally, The PostgreSQL engine uses roles to control access to database objects, and a newly created Hyperscale (Citus) server group comes with several roles pre-defined. To modify user privileges, use standard PostgreSQL commands, using a tool such as PgAdmin or psql.

Responsibility: Customer

Azure Security Center monitoring: None

3.2: Change default passwords where applicable

Guidance: Azure Active Directory (Azure AD) does not have the concept of default passwords. Other Azure resources requiring a password forces a password to be created with complexity requirements and a minimum password length, which differs depending on the service. You are responsible for third-party applications and marketplace services that may use default passwords.

Responsibility: Customer

Azure Security Center monitoring: None

3.3: Use dedicated administrative accounts

Guidance: Create standard operating procedures around the use of dedicated administrative accounts that are used to access your Hyperscale (Citus) instances. The admin accounts for managing the Azure resource are tied to Azure Active Directory (Azure AD), there are also local server admin accounts that exist within the Hyperscale (Citus) server group for managing database access permissions. Use Azure Security Center Identity and access management to monitor the number of administrative accounts within Azure AD.

Responsibility: Customer

Azure Security Center monitoring: None

3.5: Use multi-factor authentication for all Azure Active Directory based access

Guidance: For access to the Azure portal enable Azure Active Directory (Azure AD) multifactor authentication and follow Azure Security Center Identity and Access Management recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

3.6: Use dedicated machines (Privileged Access Workstations) for all administrative tasks

Guidance: Use Privileged Access Workstations (PAWs) with multifactor authentication configured to log into and configure Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

3.7: Alert on account login behavior deviation

Guidance: Use Azure Active Directory (Azure AD) Privileged Identity Management (PIM) for generation of logs and alerts when suspicious or unsafe activity occurs in the environment.

Use Azure AD Risk Detections to view alerts and reports on risky user behavior.

Responsibility: Customer

Azure Security Center monitoring: None

3.8: Manage Azure resources from only approved locations

Guidance: Use Conditional Access Named Locations to allow portal and Azure Resource Manager access from only specific logical groupings of IP address ranges or countries/regions.

Responsibility: Customer

Azure Security Center monitoring: None

3.9: Use Azure Active Directory

Guidance: Use Azure Active Directory (Azure AD) as the central authentication and authorization system to manage PostgreSQL resources. Azure AD protects data by using strong encryption for data at rest and in transit. Azure AD also salts, hashes, and securely stores user credentials.

Users within a Hyperscale (Citus) server group cannot be tied directly to Azure AD accounts. To modify user privileges for database object access use standard PostgreSQL commands with tools such as PgAdmin or psql.

Responsibility: Customer

Azure Security Center monitoring: None

3.10: Regularly review and reconcile user access

Guidance: Review and reconcile access for both users who have access to the local database as well as through Azure Active Directory (Azure AD) to manage PostgreSQL resources.

For users with access to manage database Azure resources, review the Azure AD logs to help discover stale accounts. In addition, use Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications that may be used to access Hyperscale (Citus), and role assignments. User access should be reviewed on a regular basis such as every 90 days to make sure only the right users have continued access.

Responsibility: Customer

Azure Security Center monitoring: None

3.11: Monitor attempts to access deactivated credentials

Guidance: Within Azure Active Directory (Azure AD), you have access to Azure AD Sign-in Activity, Audit and Risk Event log sources, which allow you to integrate with any SIEM/Monitoring tool.

You can streamline this process by creating Diagnostic Settings for Azure AD user accounts and sending the audit logs and sign-in logs to a Log Analytics Workspace. You can configure desired Alerts within Log Analytics Workspace.

Responsibility: Customer

Azure Security Center monitoring: None

3.12: Alert on account sign-in behavior deviation

Guidance: Use Azure Active Directory (Azure AD)'s Identity Protection and risk detection features to configure automated responses to detected suspicious actions at the Azure AD level. You may enable automated responses through Azure Sentinel to implement your organization's security responses.

You can also ingest logs into Azure Sentinel for further investigation.

Responsibility: Customer

Azure Security Center monitoring: None

3.13: Provide Microsoft with access to relevant customer data during support scenarios

Guidance: Currently not available; Customer Lockbox is not yet supported for Hyperscale (Citus).

Responsibility: Customer

Azure Security Center monitoring: None

Data Protection

For more information, see the Azure Security Benchmark: Data Protection.

4.1: Maintain an inventory of sensitive Information

Guidance: Use tags to assist in tracking Hyperscale (Citus) instances or related resources that store or process sensitive information.

Responsibility: Customer

Azure Security Center monitoring: None

4.2: Isolate systems storing or processing sensitive information

Guidance: Implement separate subscriptions and/or management groups for development, test, and production. Use a combination of administrative roles and firewall rules to isolate and limit network access to your Azure Database for PostgreSQL instances.

Responsibility: Customer

Azure Security Center monitoring: None

4.4: Encrypt all sensitive information in transit

Guidance: Client application connections to the Hyperscale (Citus) coordinator node require Transport Layer Security (TLS) 1.2. Enforcing TLS connections between your database server and your client applications helps protect against "man-in-the-middle" attacks by encrypting the data stream between the server and your application.

For all Azure Database for PostgreSQL servers provisioned through the Azure portal, enforcement of TLS connections is enabled by default.

In some cases, third-party applications require a local certificate file generated from a trusted Certificate Authority (CA) certificate file (.cer) to connect securely.

Responsibility: Shared

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.DBforPostgreSQL:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Enforce SSL connection should be enabled for PostgreSQL database servers Azure Database for PostgreSQL supports connecting your Azure Database for PostgreSQL server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and your application. This configuration enforces that SSL is always enabled for accessing your database server. Audit, Disabled 1.0.1

4.6: Use Azure RBAC to control access to resources

Guidance: Use Azure role-based access control (Azure RBAC) to control access to the Hyperscale (Citus) control plane (e.g. Azure portal). Azure RBAC does not affect user permissions within the database.

To modify user privileges at the database level, use standard PostgreSQL commands, using a tool such as PgAdmin or psql.

Responsibility: Customer

Azure Security Center monitoring: None

4.8: Encrypt sensitive information at rest

Guidance: At least once a day, Azure Database for PostgreSQL Hyperscale (Citus) takes snapshot backups of data files and the database transaction log. The backups allow you to restore a server to any point in time within the retention period. (The retention period is currently 35 days for all clusters.) All backups are encrypted using AES 256-bit encryption. The PostgreSQL Hyperscale (Citus) offering uses Microsoft-managed keys for encryption.

Responsibility: Shared

Azure Security Center monitoring: None

4.9: Log and alert on changes to critical Azure resources

Guidance: Use Azure Monitor with the Azure Activity Log to create alerts for when changes take place to production instances of Hyperscale (Citus) and other critical or related resources.

Responsibility: Customer

Azure Security Center monitoring: None

Vulnerability Management

For more information, see the Azure Security Benchmark: Vulnerability Management.

5.1: Run automated vulnerability scanning tools

Guidance: Currently not available; Azure Security Center does not yet support vulnerability assessment for Azure Database for PostgreSQL - Hyperscale (Citus).

Responsibility: Shared

Azure Security Center monitoring: None

Inventory and Asset Management

For more information, see the Azure Security Benchmark: Inventory and Asset Management.

6.1: Use automated asset discovery solution

Guidance: Use Azure Resource Graph to query and discover all resources (including Hyperscale (Citus) instances) within your subscription(s). Ensure you have appropriate (read) permissions in your tenant and are able to enumerate all Azure subscriptions as well as resources within your subscriptions.

Responsibility: Customer

Azure Security Center monitoring: None

6.2: Maintain asset metadata

Guidance: Apply tags to Hyperscale (Citus) instances and other related resources giving metadata to logically organize them into a taxonomy.

Responsibility: Customer

Azure Security Center monitoring: None

6.3: Delete unauthorized Azure resources

Guidance: Use tagging, management groups, and separate subscriptions, where appropriate, to organize and track Hyperscale (Citus) instances and related resources. Reconcile inventory on a regular basis and ensure unauthorized resources are deleted from the subscription in a timely manner.

Responsibility: Customer

Azure Security Center monitoring: None

6.4: Define and maintain inventory of approved Azure resources

Guidance: Use Azure policy to put restrictions on the type of resources that can be created in customer subscription(s) using the following built-in policy definitions:

  • Not allowed resource types

  • Allowed resource types

In addition, use the Azure Resource Graph to query/discover resources within the subscription(s).

Responsibility: Customer

Azure Security Center monitoring: None

6.5: Monitor for unapproved Azure resources

Guidance: Use Azure policy to put restrictions on the type of resources that can be created in customer subscription(s) using the following built-in policy definitions:

  • Not allowed resource types
  • Allowed resource types

In addition, use the Azure Resource Graph to query/discover resources within the subscription(s).

Responsibility: Customer

Azure Security Center monitoring: None

6.9: Use only approved Azure services

Guidance: Use Azure policy to put restrictions on the type of resources that can be created in customer subscription(s) using the following built-in policy definitions:

Responsibility: Customer

Azure Security Center monitoring: None

6.11: Limit users' ability to interact with Azure Resource Manager

Guidance: Use the Azure Conditional Access to limit users' ability to interact with Azure Resource Manager by configuring "Block access" for the "Microsoft Azure Management" App. This can prevent the creation and changes to resources within a high security environment, such as instances of Hyperscale (Citus) containing sensitive information.

Responsibility: Customer

Azure Security Center monitoring: None

Secure Configuration

For more information, see the Azure Security Benchmark: Secure Configuration.

7.1: Establish secure configurations for all Azure resources

Guidance: Define and implement standard security configurations for your Hyperscale (Citus) instances with Azure Policy. Use Azure Policy to create custom policies to audit or enforce the network configuration of your Azure Database for PostgreSQL instances.

Also, Azure Resource Manager has the ability to export the template in JavaScript Object Notation (JSON), which should be reviewed to ensure that the configurations meet / exceed the security requirements for your organization.

Responsibility: Customer

Azure Security Center monitoring: None

7.3: Maintain secure Azure resource configurations

Guidance: Use Azure policy [deny] and [deploy if not exist] to enforce secure settings across your Azure resources. In addition, you may use Azure Resource Manager templates to maintain the security configuration of your Azure resources required by your organization.

Responsibility: Customer

Azure Security Center monitoring: None

7.5: Securely store configuration of Azure resources

Guidance: If using custom Azure policy definitions for your Hyperscale (Citus) instances and related resources, use Azure Repos to securely store and manage your code.

Responsibility: Customer

Azure Security Center monitoring: None

7.7: Deploy configuration management tools for Azure resources

Guidance: Use Azure policy [deny] and [deploy if not exist] to enforce secure settings across your Azure resources. In addition, you may use Azure Resource Manager templates to maintain the security configuration of your Azure resources required by your organization.

Responsibility: Customer

Azure Security Center monitoring: None

7.9: Implement automated configuration monitoring for Azure resources

Guidance: Use Azure Policy aliases in the "Microsoft.DBforPostgreSQL" namespace to create custom policies to alert, audit, and enforce system configurations. Use Azure policy [audit], [deny], and [deploy if not exist] to automatically enforce configurations for your Azure Database for PostgreSQL instances and related resources.

Responsibility: Customer

Azure Security Center monitoring: None

7.12: Manage identities securely and automatically

Guidance: Azure Database for PostgreSQL - Hyperscale (Citus) currently does not directly support managed identities. While creating the Azure Database for PostgreSQL server, you must provide credentials for an administrator user. You can create additional user roles in the Azure portal interface.

Responsibility: Customer

Azure Security Center monitoring: None

7.13: Eliminate unintended credential exposure

Guidance: Implement Credential Scanner to identify credentials within code. Credential Scanner will also encourage moving discovered credentials to more secure locations such as Azure Key Vault.

Responsibility: Customer

Azure Security Center monitoring: None

Malware Defense

For more information, see the Azure Security Benchmark: Malware Defense.

8.2: Pre-scan files to be uploaded to non-compute Azure resources

Guidance: Microsoft anti-malware is enabled on the underlying host that supports Azure services -- for example, Hyperscale (Citus) -- however, it does not run on customer content.

Pre-scan any content being uploaded to non-compute Azure resources, such as App Service, Data Lake Storage, Blob Storage, Azure Database for PostgreSQL, etc. Microsoft cannot access your data in these instances.

Responsibility: Customer

Azure Security Center monitoring: None

Data Recovery

For more information, see the Azure Security Benchmark: Data Recovery.

9.1: Ensure regular automated back ups

Guidance: Azure Database for PostgreSQL – Hyperscale (Citus) automatically creates backups of each node and stores them in locally redundant storage. Backups can be used to restore your Hyperscale (Citus) cluster to a specified time.

Responsibility: Customer

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.DBforPostgreSQL:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Geo-redundant backup should be enabled for Azure Database for PostgreSQL Azure Database for PostgreSQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create. Audit, Disabled 1.0.1

9.2: Perform complete system backups and backup any customer-managed keys

Guidance: At least once a day, Azure Database for PostgreSQL takes snapshot backups of data files and the database transaction log. The backups allow you to restore a server to any point in time within the retention period. The retention period is currently 35 days for all clusters. All backups are encrypted using AES 256-bit encryption.

In Azure regions that support availability zones, backup snapshots are stored in three availability zones. As long as at least one availability zone is online, the Hyperscale (Citus) cluster is restorable.

Responsibility: Customer

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.DBforPostgreSQL:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Geo-redundant backup should be enabled for Azure Database for PostgreSQL Azure Database for PostgreSQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create. Audit, Disabled 1.0.1

9.3: Validate all backups including customer-managed keys

Guidance: In Azure Database for PostgreSQL, restoring a Hyperscale (Citus) cluster creates a new cluster from the original nodes' backups. You can restore a cluster to any point in time within the last 35 days. The restore process creates a new cluster in the same Azure region, subscription, and resource group as the original. The new cluster configuration is the same as the original cluster configuration: the same number of nodes, number of vCores, storage size, and user roles.

Firewall settings and PostgreSQL server parameters are not preserved from the original server group; they are reset to default values. The firewall will prevent all connections. You will need to manually adjust these settings after restore.

Responsibility: Customer

Azure Security Center monitoring: None

9.4: Ensure protection of backups and customer-managed keys

Guidance: Deleted Hyperscale (Citus) clusters can't be restored. If you delete the cluster, all nodes that belong to the cluster are deleted and can't be recovered. To protect cluster resources post-deployment from accidental deletion or unexpected changes, administrators can leverage management locks.

Responsibility: Customer

Azure Security Center monitoring: None

Incident Response

For more information, see the Azure Security Benchmark: Incident Response.

10.1: Create an incident response guide

Guidance: Build out an incident response guide for your organization. Ensure that there are written incident response plans that define all roles of personnel as well as phases of incident handling/management from detection to post-incident review.

Responsibility: Customer

Azure Security Center monitoring: None

10.2: Create an incident scoring and prioritization procedure

Guidance: Security Center assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Security Center is in the finding or the metric used to issue the alert as well as the confidence level that there was malicious intent behind the activity that led to the alert.

Additionally, clearly mark subscriptions (for ex. production, non-prod) and create a naming system to clearly identify and categorize Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

10.3: Test security response procedures

Guidance: Conduct exercises to test your systems’ incident response capabilities on a regular cadence. Identify weak points and gaps and revise plan as needed.

Responsibility: Customer

Azure Security Center monitoring: None

10.4: Provide security incident contact details and configure alert notifications for security incidents

Guidance: Security incident contact information will be used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that the customer's data has been accessed by an unlawful or unauthorized party. Review incidents after the fact to ensure that issues are resolved.

Responsibility: Customer

Azure Security Center monitoring: None

10.5: Incorporate security alerts into your incident response system

Guidance: Export your Azure Security Center alerts and recommendations using the Continuous Export feature. Continuous Export allows you to export alerts and recommendations either manually or in an ongoing, continuous fashion. You may use the Azure Security Center data connector to stream the alerts to Azure Sentinel.

Responsibility: Customer

Azure Security Center monitoring: None

10.6: Automate the response to security alerts

Guidance: Use the Workflow Automation feature in Azure Security Center to automatically trigger responses via "Logic Apps" on security alerts and recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

Penetration Tests and Red Team Exercises

For more information, see the Azure Security Benchmark: Penetration Tests and Red Team Exercises.

11.1: Conduct regular penetration testing of your Azure resources and ensure remediation of all critical security findings

Guidance: Follow the Microsoft Rules of Engagement to ensure your Penetration Tests are not in violation of Microsoft policies: https://www.microsoft.com/msrc/pentest-rules-of-engagement?rtc=1

Responsibility: Shared

Azure Security Center monitoring: None

Next steps