Azure security baseline for Azure Database for PostgreSQL - Single Server

  • Article
  • 30 minutes to read

This security baseline applies guidance from the Azure Security Benchmark version 1.0 to Azure Database for PostgreSQL - Single Server. 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 - Single Server.

You can monitor this security baseline and its recommendations using Microsoft Defender for Cloud. Azure Policy definitions will be listed in the Regulatory Compliance section of the Microsoft Defender for Cloud dashboard.

When a section has relevant Azure Policy Definitions, they are listed in this baseline to help you measure compliance to the Azure Security Benchmark controls and recommendations. Some recommendations may require a paid Microsoft Defender plan to enable certain security scenarios.

Note

Controls not applicable to Azure Database for PostgreSQL - Single Server, or for which the responsibility is Microsoft's, have been excluded. To see how Azure Database for PostgreSQL - Single Server completely maps to the Azure Security Benchmark, see the full Azure Database for PostgreSQL - Single Server 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: Configure Private Link for Azure Database for PostgreSQL with Private Endpoints. Private Link allows you to connect to various PaaS services in Azure via a private endpoint. Azure Private Link essentially brings Azure services inside your private Virtual Network (VNet). Traffic between your virtual network and PostgreSQL instance travels the Microsoft backbone network.

Alternatively, you may use Virtual Network Service Endpoints to protect and limit network access to your Azure Database for PostgreSQL implementations. Virtual network rules are one firewall security feature that controls whether your Azure Database for PostgreSQL server accepts communications that are sent from particular subnets in virtual networks.

You may also secure your Azure Database for PostgreSQL server with firewall rules. The server firewall prevents all access to your database server until you specify which computers have permission. 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

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require a Microsoft 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.2: Monitor and log the configuration and traffic of virtual networks, subnets, and network interfaces

Guidance: When your Azure Database for PostgreSQL instance is secured to a private endpoint, you can deploy virtual machines in the same virtual network. You can use a network security group (NSG) to reduce the risk of data exfiltration. Enable NSG flow logs and send logs into a Storage Account for traffic audit. You may also send NSG flow logs to a Log Analytics workspace and use Traffic Analytics to provide insights into traffic flow in your Azure cloud. Some advantages of Traffic Analytics are the ability to visualize network activity and identify hot spots, identify security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

Responsibility: Customer

1.4: Deny communications with known-malicious IP addresses

Guidance: Use Advanced Threat Protection for Azure Database for PostgreSQL. Advanced Threat Protection detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.

Enable DDoS Protection Standard on the virtual networks associated with your Azure Database for PostgreSQL instances to guard against DDoS attacks. Use Microsoft Defender for Cloud Integrated Threat Intelligence to deny communications with known malicious or unused Internet IP addresses.

Responsibility: Customer

1.5: Record network packets

Guidance: When your Azure Database for PostgreSQL instance is secured to a private endpoint, you can deploy virtual machines in the same virtual network. You can then configure a network security group (NSG) to reduce the risk of data exfiltration. Enable NSG flow logs and send logs into a Storage Account for traffic audit. You may also send NSG flow logs to a Log Analytics workspace and use Traffic Analytics to provide insights into traffic flow in your Azure cloud. Some advantages of Traffic Analytics are the ability to visualize network activity and identify hot spots, identify security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

Responsibility: Customer

1.6: Deploy network-based intrusion detection/intrusion prevention systems (IDS/IPS)

Guidance: Use Advanced Threat Protection for Azure Database for PostgreSQL. Advanced Threat Protection detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.

Responsibility: Customer

1.8: Minimize complexity and administrative overhead of network security rules

Guidance: For resources that need access to your Azure Database for PostgreSQL instances, use virtual network service tags to define network access controls on network security groups or Azure Firewall. You can use service tags in place of specific IP addresses when creating security rules. By specifying the service tag name (e.g., SQL.WestUs) in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change.

Note: Azure Database for PostgreSQL uses the "Microsoft.Sql" service tag.

Responsibility: Customer

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.DBforPostgreSQL" and "Microsoft.Network" namespaces to create custom policies to audit or enforce the network configuration of your Azure Database for PostgreSQL instances. You may also make use of built-in policy definitions related to networking or your Azure Database for PostgreSQL instances, such as:

  • DDoS Protection Standard should be enabled

  • Enforce TLS connection should be enabled for PostgreSQL database servers

For more information, see the reference links below.

Responsibility: Customer

1.10: Document traffic configuration rules

Guidance: Use tags for resources related to network security and traffic flow for your Azure Database for PostgreSQL instances to provide metadata and logical organization.

Use any of the built-in Azure Policy definitions related to tagging, such as, "Require tag and its value," to ensure that all resources are created with tags and to notify you of existing untagged resources.

You may use Azure PowerShell or Azure CLI to look up or perform actions on resources based on their tags.

Responsibility: Customer

1.11: Use automated tools to monitor network resource configurations and detect changes

Guidance: Use Azure Activity Log to monitor network resource configurations and detect changes for network resources related to your Azure Database for PostgreSQL instances. Create alerts within Azure Monitor that will trigger when changes to critical network resources take place.

Responsibility: Customer

Logging and Monitoring

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

2.2: Configure central security log management

Guidance: Enable Diagnostic Settings and Server Logs and ingest logs to aggregate security data generated by your Azure Database for PostgreSQL instances. Within Azure Monitor, use Log Analytics Workspace(s) to query and perform analytics, and use Azure Storage Accounts for long-term/archival storage. Alternatively, you may enable and on-board data to Microsoft Sentinel or a third-party SIEM.

Responsibility: Customer

2.3: Enable audit logging for Azure resources

Guidance: Enable Diagnostic Settings on your Azure Database for PostgreSQL instances for access to audit, security, and resource logs. Ensure that you specifically enable the PostgreSQL Audit log. Activity logs, which are automatically available, include event source, date, user, timestamp, source addresses, destination addresses, and other useful elements. You may also enable Azure Activity Log Diagnostic Settings and send the logs to the same Log Analytics workspace or Storage Account.

Responsibility: Customer

2.5: Configure security log storage retention

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

Responsibility: Customer

2.6: Monitor and review logs

Guidance: Analyze and monitor logs from your Azure Database for PostgreSQL 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 Microsoft Sentinel or a third-party SIEM.

Responsibility: Customer

2.7: Enable alerts for anomalous activities

Guidance: Enable Advanced Threat Protection for Azure Database for PostgreSQL. Advanced Threat Protection detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.

In addition, you may enable Server Logs and Diagnostic Settings for PostgreSQL and send logs to a Log Analytics Workspace. Onboard your Log Analytics Workspace to Microsoft 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

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 Azure Database for PostgreSQL instances. In addition, maintain an inventory of the administrative accounts that have access to the data plane (within the database itself) of your Azure Database for PostgreSQL instances. (When creating the PostgreSQL server, you provide credentials for an administrator user. This administrator can be used to create additional PostgreSQL users.)

Azure Database for PostgreSQL does not support built-in role-based access control, but you can create custom roles based on specific resource provider operations.

Responsibility: Customer

3.2: Change default passwords where applicable

Guidance: Azure Active Directory (Azure AD) and Azure Database for PostgreSQL do not have the concept of default passwords.

Upon creation of the Azure Database for PostgreSQL resource itself, Azure forces the creation of an administrative user with a strong password. However, once the PostgreSQL instance has been created, you may use the first server admin account you created account to create additional users and grant administrative access to them. When creating these accounts, ensure you configure a different, strong password for each account.

Responsibility: Customer

3.3: Use dedicated administrative accounts

Guidance: Create standard operating procedures around the use of dedicated administrative accounts that have access to your Azure Database for PostgreSQL instances. Use Microsoft Defender for Cloud Identity and access management to monitor the number of administrative accounts.

Responsibility: Customer

3.4: Use Azure Active Directory single sign-on (SSO)

Guidance: Signing into Azure Database for PostgreSQL is supported both using username/password configured directly in the database, as well as using an Azure Active Directory (Azure AD) identity and utilizing an Azure AD token to connect. When using an Azure AD token, different methods are supported, such as an Azure AD user, an Azure AD group, or an Azure AD application connecting to the database.

Separately, control plane access for PostgreSQL is available via REST API and supports SSO. To authenticate, set the Authorization header for your requests to a JSON Web Token that you obtain from Azure AD.

Responsibility: Customer

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

Guidance: Enable Azure Active Directory (Azure AD) multifactor authentication and follow Microsoft Defender for Cloud Identity and Access Management recommendations. When utilizing Azure AD tokens for signing into your database, this allows you to require multifactor authentication for database sign-ins.

Responsibility: Customer

3.6: Use secure, Azure-managed workstations for administrative tasks

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

Responsibility: Customer

3.7: Log and alert on suspicious activities from administrative accounts

Guidance: Enable Advanced Threat Protection for Azure Database for PostgreSQL to generate alerts for suspicious activity.

In addition, you may 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

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

3.9: Use Azure Active Directory

Guidance: Use Azure Active Directory (Azure AD) as the central authentication and authorization system. 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.

For signing into Azure Database for PostgreSQL, it is recommended to use Azure AD and use an Azure AD token to connect. When using an Azure AD token, different methods are supported, such as an Azure AD user, an Azure AD group, or an Azure AD application connecting to the database.

Azure AD credentials may also be used for administration at the management plane level (e.g. the Azure portal) to control PostgreSQL admin accounts.

Responsibility: Customer

3.10: Regularly review and reconcile user access

Guidance: Review the Azure Active Directory (Azure AD) logs to help discover stale accounts which can include those with Azure Database for PostgreSQL administrative roles. In addition, use Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications that may be used to access Azure Database for PostgreSQL, 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

3.11: Monitor attempts to access deactivated credentials

Guidance: Enable Diagnostic Settings for Azure Database for PostgreSQL and Azure Active Directory (Azure AD), sending all logs to a Log Analytics workspace. Configure desired alerts (such as failed authentication attempts) within Log Analytics.

Responsibility: Customer

3.12: Alert on account sign-in behavior deviation

Guidance: Enable Advanced Threat Protection for Azure Database for PostgreSQL to generate alerts for suspicious activity.

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

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

Responsibility: Customer

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

Guidance: Currently not available; Customer Lockbox is not yet supported for Azure Database for PostgreSQL.

Responsibility: Customer

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 Azure Database for PostgreSQL instances or related resources that store or process sensitive information.

Responsibility: Customer

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 Private Link, Service Endpoints, and/or firewall rules to isolate and limit network access to your Azure Database for PostgreSQL instances.

Responsibility: Customer

4.3: Monitor and block unauthorized transfer of sensitive information

Guidance: When using Azure Virtual machines to access Azure Database for PostgreSQL instances, make use of Private Link, PostgreSQL network configurations, network security groups, and service tags to mitigate the possibility of data exfiltration.

Microsoft manages the underlying infrastructure for Azure Database for PostgreSQL and has implemented strict controls to prevent the loss or exposure of customer data.

Responsibility: Shared

4.4: Encrypt all sensitive information in transit

Guidance: Azure Database for PostgreSQL supports connecting your PostgreSQL server to client applications using Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL). 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. In the Azure portal, ensure "Enforce SSL connection" is enabled for all of your Azure Database for PostgreSQL instances by default.

Currently the TLS versions supported for Azure Database for PostgreSQL are TLS 1.0, TLS 1.1, TLS 1.2.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require a Microsoft 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.5: Use an active discovery tool to identify sensitive data

Guidance: Data identification, classification, and loss prevention features are not yet available for Azure Database for PostgreSQL. Implement third-party solution if required for compliance purposes.

For the underlying platform which is managed by Microsoft, Microsoft treats all customer content as sensitive and goes to great lengths to guard against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft has implemented and maintains a suite of robust data protection controls and capabilities.

Responsibility: Shared

4.6: Use Azure RBAC to control access to resources

Guidance: Use Azure role-based access control (Azure RBAC) to control access to the Azure Database for PostgreSQL control plane (e.g. Azure portal). For data plane access (within the database itself), use SQL queries to create users and configure user permissions. Azure RBAC does not affect user permissions within the database.

Responsibility: Customer

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 Azure Database for PostgreSQL and other critical or related resources.

Responsibility: Customer

Vulnerability Management

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

5.1: Run automated vulnerability scanning tools

Guidance: Follow recommendations from Microsoft Defender for Cloud on securing your Azure Database for PostgreSQL and related resources.

Microsoft performs vulnerability management on the underlying systems that support Azure Database for PostgreSQL.

Responsibility: Shared

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 Azure Database for PostgreSQL instances) within your subscriptions. 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

6.2: Maintain asset metadata

Guidance: Apply tags to Azure Database for PostgreSQL instances and other related resources giving metadata to logically organize them into a taxonomy.

Responsibility: Customer

6.3: Delete unauthorized Azure resources

Guidance: Use tagging, management groups, and separate subscriptions, where appropriate, to organize and track Azure Database for PostgreSQL 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

6.4: Define and maintain inventory of approved Azure resources

Guidance: Not applicable; this recommendation is intended for compute resources and Azure as a whole.

Responsibility: Customer

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

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:

  • Not allowed resource types
  • Allowed resource types

For more information, see the reference links below.

Responsibility: Customer

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 Azure Database for PostgreSQL containing sensitive information.

Responsibility: Customer

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 Azure Database for PostgreSQL instances with Azure Policy. Use Azure Policy aliases in the "Microsoft.DBforPostgreSQL" namespace to create custom policies to audit or enforce the network configuration of your Azure Database for PostgreSQL instances. You may also make use of built-in policy definitions related to your Azure Database for PostgreSQL instances, such as:

  • Enforce TLS connection should be enabled for PostgreSQL database servers
  • Log connections should be enabled for PostgreSQL database servers

For more information, see the reference links below.

Responsibility: Customer

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.

Responsibility: Customer

7.5: Securely store configuration of Azure resources

Guidance: If using custom Azure Policy definitions for your Azure Database for PostgreSQL instances and related resources, use Azure Repos to securely store and manage your code.

Responsibility: Customer

7.7: Deploy configuration management tools for Azure resources

Guidance: Use Azure Policy aliases in the "Microsoft.DBforPostgreSQL" namespace to create custom policies to alert, audit, and enforce system configurations. Additionally, develop a process and pipeline for managing policy exceptions.

Responsibility: Customer

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

7.11: Manage Azure secrets securely

Guidance: For Azure Virtual Machines or web applications running on Azure App Service being used to access your Azure Database for PostgreSQL instances, use Managed Service Identity in conjunction with Azure Key Vault to simplify and secure Azure Database for PostgreSQL secret management. Ensure Key Vault Soft Delete is enabled.

Responsibility: Customer

7.12: Manage identities securely and automatically

Guidance: Azure Database for PostgreSQL server supports Azure Active Directory (Azure AD) authentication to access databases. While creating the Azure Database for PostgreSQL server, you provide credentials for an administrator user. This administrator can be used to create additional database users.

For Azure Virtual Machines or web applications running on Azure App Service being used to access your Azure Database for PostgreSQL server, use Managed Service Identity in conjunction with Azure Key Vault to store and retrieve credentials for Azure Database for PostgreSQL server. Ensure Key Vault Soft Delete is enabled.

Use Managed Identities to provide Azure services with an automatically managed identity in Azure AD. Managed Identities allows you to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials in your code.

Responsibility: Customer

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

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, Azure Database for PostgreSQL), 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: Shared

Data Recovery

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

9.1: Ensure regular automated back-ups

Guidance: Azure Database for PostgreSQL takes backups of the data files and the transaction log. Depending on the supported maximum storage size, we either take full and differential backups (4 TB max storage servers) or snapshot backups (up to 16 TB max storage servers). These backups allow you to restore a server to any point-in-time within your configured backup retention period. The default backup retention period is seven days. You can optionally configure it up to 35 days. All backups are encrypted using AES 256-bit encryption.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require a Microsoft 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: Azure Database for PostgreSQL automatically creates server backups and stores them in either locally-redundant or geo-redundant storage, according to the user's choice. Backups can be used to restore your server to a point-in-time. Backup and restore are an essential part of any business continuity strategy because they protect your data from accidental corruption or deletion.

If using Azure Key Vault to store credentials for your Azure Database for PostgreSQL instances, ensure regular automated backups of your keys.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require a Microsoft 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, performing a restore creates a new server from the original server's backups. There are two types of restore available: Point-in-time restore and Geo-restore. Point-in-time restore is available with either backup redundancy option and creates a new server in the same region as your original server. Geo-restore is available only if you configured your server for geo-redundant storage and it allows you to restore your server to a different region.

The estimated time of recovery depends on several factors including the database sizes, the transaction log size, the network bandwidth, and the total number of databases recovering in the same region at the same time. The recovery time is usually less than 12 hours.

Periodically test restoration of your Azure Database for PostgreSQL instances.

Responsibility: Customer

9.4: Ensure protection of backups and customer-managed keys

Guidance: Azure Database for PostgreSQL takes full, differential, and transaction log backups. These backups allow you to restore a server to any point-in-time within your configured backup retention period. The default backup retention period is seven days. You can optionally configure it up to 35 days. All backups are encrypted using AES 256-bit encryption.

Responsibility: Customer

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

10.2: Create an incident scoring and prioritization procedure

Guidance: Microsoft Defender for Cloud assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Microsoft Defender for Cloud 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

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

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

10.5: Incorporate security alerts into your incident response system

Guidance: Export your Microsoft Defender for Cloud 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 Microsoft Defender for Cloud data connector to stream the alerts Microsoft Sentinel.

Responsibility: Customer

10.6: Automate the response to security alerts

Guidance: Use the Workflow Automation feature in Microsoft Defender for Cloud to automatically trigger responses via "Logic Apps" on security alerts and recommendations.

Responsibility: Customer

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

Next steps