Azure provides multiple options and services to help you secure your data and applications. The Enterprise Azure OpenAI Hub is designed to provide a secure and compliant environment for your AI workloads, and to help you meet your security and compliance requirements.
- Overview
- Enterprise requirements and control mapping
- Service Enablement Framework
- Recommended Azure policies for the Enterprise Azure OpenAI Hub
- Deploy recommended Azure policies for the Enterprise Azure OpenAI Hub
- Next steps
Enterprise organizations regardless of industry are increasingly adopting AI to drive innovation and growth, and the pace of innovation in AI is accelerating to the extent that it is becoming a competitive differentiator. This may ultimately cause that security, governance, and compliance requirements becomes an afterthought, where it's either exempted or not fully addressed which can introduce one or more risks to the organization.
To that end, we have designed the Enterprise Azure OpenAI Hub to lead with the principles of "secure by-default", where we can ensure you are following best-practices and are compliant with your organization's security and compliance requirements in terms of data protection, identity and access management, logging and threat detection, and more, aligned with Microsoft Cloud Security Benchmark. In addition, to conform to all the recommended best practices, Azure OpenAI will require additional services, such as Key Vault to store and rotate the customer-managed keys, and Storage Account to store the data, which will also require encryption at rest and in transit.
The configuration of all the Azure services included in the Enterprise Azure OpenAI Hub will default to our recommendations, such as disabling public network access and enabling private endpoints, and more. However, you may need to customize the configuration to meet your specific requirements, and to ensure that you are compliant with your organization's security and compliance requirements. The important thing in case you should configure anything differently, is that you are making an informed decision, and that you are aware of the potential risks and trade-offs.
To get a better understanding on how to assess Azure services to meet your organization's security and compliance requirements, we are providing a Service Enablement Framework below that helps to put on the critical lens to assess the Azure services in the context of the Enterprise Azure OpenAI Hub. When using the framework, you can assess the readiness of the Azure services to meet your organization's security and compliance requirements, and to identify any gaps that need to be addressed.
The Service Enablement Framework encompass the requisite sequence, activities, and artifacts required to enable the Azure platform and services for a specific customer. The framework is designed to be used by architects, engineers and cybersecurity experts, and is a holistic approach to enable the Azure platform and services, and ensure that the platform is compliant with the required controls.
From a high-level perspective, the Service Enablement Framework is composed of the following activities:
- The first phase is to recognize and distinguish between what is a control and responsibility by Microsoft, and what the explicit customer responsibilities are, as well as the shared responsibilities. This is important to understand as it will help to accelerate the process and simplify the subsequent enablements the organization will perform.
- Once this has been generally understood and established, it simplifies the process and accelerates the implementation of the controls, as the organization can focus on the controls that are within their responsibility, and the shared responsibilities.
For Service Enablement, it is key to understand how to distinguish between the controls that Microsoft is responsible for for the Azure platform and services.
Examples:
-
"Ensure data in-transit encryption for data plane for Cosmos DB is enabled", is a Microsoft control and responsibility as this cannot be disabled by the customer.
-
"Ensure customer-managed key is used for encrypting data at for Azure OpenAI", is a customer responsibility as they must provide the key - and the life-cycle management of it, and a KeyVault in a subscription to meet this requirement.
In addition, sometimes the responsibility is shared between Microsoft and the customer, such as "Ensure Customer Lockbox is used to review, approve, or reject Microsoft data access requests". In this case, the customer is responsible for enabling Customer Lockbox, and Microsoft is responsible for using it.
To review service by service per Microsoft Cloud security benchmark and baselines individually, please refer to the Microsoft Cloud security benchmark and baselines documentation.
An example of how the benchmark is assessing each service to contextualize the responsibility and to meet the control requirement can be seen below:
Azure AD Authentication Required for Data Plane Access
Description: Service supports using Azure AD authentication for data plane access.
| Supported | Enabled By Default | Configuration Responsibility |
|---|---|---|
| True | False | Customer |
Feature notes: Azure AD authentication is only supported on the Core (SQL) API. Other APIs only support key-based authentication.
Configuration Guidance: There is no current Microsoft guidance for this feature configuration. Please review and determine if your organization wants to configure this security feature.
Local Authentication Methods for Data Plane Access
Description: Local authentication methods supported for data plane access, such as a local username and password.
| Supported | Enabled By Default | Configuration Responsibility |
|---|---|---|
| True | True | Microsoft |
Further, Azure compliance for the platform and services as a whole are based on various types of assurances, including formal certifications, attestations, validations, authorizations, and assessments produced by independent third-party auditing firms, as well as contractual amendments, self-assessments, and customer guidance documents provided by Microsoft.
Each offering description in this document provides an up to date scope statement indicating which Azure customer-facing services are in scope for the assessment, as well as links to downloadable resources to assist customers with their own compliance obligations. Azure compliance offerings are grouped into four segments: globally applicable, US government, industry specific, and region/country specific.
This section provides a mapping of the controls to the Enterprise Azure OpenAI Hub services. The mapping is based on the Azure services documentation and the Microsoft Cloud Security Baseline. The mapping is not exhaustive and is intended to provide a starting point for your security assessment.
With Microsoft Cloud Security Benchmark, we have consolidated security controls and baselines and how it maps to guidance like Center for Internet Security (CIS) Controls, National Institute of Standards and Technology (NIST), and the Payment Card Industry Data Security Standard (PCI-DSS) framework, which makes it easier to map the controls to the Azure services.
The following table provides a framework to assess enterprise security readiness of Azure services used by the Enterprise Azure OpenAI Hub, and you can map the criteria to the recommended configuration as viewed in the Azure Portal.
| Assessment | Category | Criteria |
|---|---|---|
| Security | Network endpoint | Does the service have a public endpoint that is accessible outside of a VNet? |
| Does it support VNet Service Endpoints? | ||
| Can Azure services interact directly with the service endpoint? | ||
| Does it support Private Link Endpoints? | ||
| Can it be deployed within a VNet? | ||
| Data Exfiltration Prevention | Does the PaaS service have a separate BGP community in ExpressRoute Microsoft Peering? (i.e. does ER expose a Route Filter for the service?) | |
| Does the service support Private Link Endpoints? | ||
| Enforce Network Traffic Flow for management and data plane operations | Is it possible to inspect traffic entering/exiting the service? Can traffic be force tunnelled with UDRs? | |
| Do management operations use Azure shared public ip ranges? | ||
| Is management traffic directed via a link-local endpoint exposed on the host? | ||
| Data Encryption at-rest | Is encryption applied by default? | |
| Can encryption be disabled? | ||
| Is encryption performed using Microsoft Managed Keys (MMK) or Customer Managed Keys (CMK)? | ||
| Data Encryption in-transit | Is traffic to the service encrypted at a protocol level (SSL/TLS)? | |
| Are there any HTTP endpoints and can the be disabled? | ||
| Is underlying service communication also encrypted? | ||
| Is encryption performed using MMK or CMK? (is BYoK supported?) | ||
| Software Deployment | Can application software or third party products be deployed to the service? | |
| How is software deployment performed and managed? | ||
| Can policies enforced to control source or code integrity? | ||
| If software is deployable, can antimalware, vulnerability management and security monitoring tools be used? | ||
| Does the service provide such capabilities natively? (e.g., AKS) | ||
| Identity & Access Management | Authentication & Access Control | Are all Control plane operations governed by Azure AD? (i.e. is there a nested control plane, such as for Kubernetes) |
| What methods exist to provide access to the Data plane? | ||
| Does the Data plane integrate with Azure AD? | ||
| Does Azure to Azure (service to service) authentication use a MSI/Service Principal? | ||
| Is Azure to IaaS (Service to VNet) authentication via Azure AD? | ||
| How are any applicable keys/SAS managed? | ||
| How can access be revoked? | ||
| Segregation of Duties | Does the service separate Control plane and Data plane operations within Azure AD? | |
| MFA and conditional access | Is MFA enforced for user to service interactions? | |
| Governance | Data Export & Import | Does service allow you to import and export data securely and encrypted? |
| Data Privacy & Usage | Can Microsoft engineers access the data? | |
| Is any Microsoft support interaction with the service audited? | ||
| Data Residency | Is data contained to the service deployment region? | |
| Operations | Monitoring | Does the service integrate with Azure Monitor? |
| Backup Management | Which workload data need to be backed? | |
| How are backups captured? | ||
| How frequently can backups be taken? | ||
| How long can backups be retained for? | ||
| Are backups encrypted? | ||
| Is backup encryption performed using MMK or CMK? | ||
| Disaster Recovery | How can the service be used in a regional redundant fashion? | |
| What is the attainable RTO and RPO? | ||
| SKU | What SKUs are available? and how do they differ? | |
| Are there any features related to security for premium SKU? | ||
| Capacity Management | How is capacity monitored? | |
| What is the unit of horizontal scale? | ||
| Patch & Update Management | Does the service require patching or is it abstracted by the service? | |
| How frequently are patches applied and can they be automated? | ||
| Audit | Are nested Control plane operations captured? (e.g., AKS or Databricks) | |
| Are key Data plane activities recorded? | ||
| Configuration Management | Does it support Tags and provide a PUT schema for all resources? | |
| Azure Service Compliance | Service Attestation, Certification and External Audits | Is the service PCI/ISO/SOC compliant? |
| Service Availability | Is the service Private Preview/Public Preview/GA? | |
| In what regions is the service available? | ||
| What is the deployment scope of the service? (i.e. is it a regional or global service?) | ||
| Service Level Agreements | What is the SLA for service availability? | |
| If applicable, what is the SLA for performance? |
When deploying the Enterprise Azure OpenAI Hub into your subscription, there will be no policies included in the deployment, as we would highly recommend that you implement Azure policies at the management group scope targeting uniformed subscriptions from a networking, security, management, and governance perspective.
However, we have provided a set of recommended Azure policies that you can use to ensure that the Azure services included in the Enterprise Azure OpenAI Hub are deployed with the right configuration, and that the configuration is maintained over time. The recommended Azure policies are based on the Microsoft Cloud Security Benchmark and the Azure Security Benchmark, and are designed to help you meet your security and compliance requirements.
The recommended Azure policies are organized by service, and include the following services:
- Azure Key Vault
- Azure Networking
- Azure OpenAI
- Azure Storage Account
- API Management
- Azure AI Search
- App Service
| PolicySetDefinition | PolicyDefinition DisplayName | PolicyDefinition Description |
|---|---|---|
| Enforce secure-by-default Key Vault for Enterprises | [Preview]: Certificates should not expire within the specified number of days | Manage certificates that will expire within a specified number of days to ensure your organization has sufficient time to rotate the certificate prior to expiration. |
| Enforce secure-by-default Key Vault for Enterprises | [Preview]: Azure Key Vault Managed HSM keys using elliptic curve cryptography should have the specified curve names | To use this policy in preview, you must first follow these instructions at https://aka.ms/mhsmgovernance. Keys backed by elliptic curve cryptography can have different curve names. Some applications are only compatible with specific elliptic curve keys. Enforce the types of elliptic curve keys that are allowed to be created in your environment. |
| Enforce secure-by-default Key Vault for Enterprises | [Preview]: Azure Key Vault Managed HSM Keys should have more than the specified number of days before expiration | To use this policy in preview, you must first follow these instructions at https://aka.ms/mhsmgovernance. If a key is too close to expiration, an organizational delay to rotate the key may result in an outage. Keys should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. |
| Enforce secure-by-default Key Vault for Enterprises | Certificates should be issued by the specified integrated certificate authority | Manage your organizational compliance requirements by specifying the Azure integrated certificate authorities that can issue certificates in your key vault such as Digicert or GlobalSign. |
| Enforce secure-by-default Key Vault for Enterprises | Certificates should be issued by the specified non-integrated certificate authority | Manage your organizational compliance requirements by specifying the custom or internal certificate authorities that can issue certificates in your key vault. |
| Enforce secure-by-default Key Vault for Enterprises | Secrets should have content type set | A content type tag helps identify whether a secret is a password, connection string, etc. Different secrets have different rotation requirements. Content type tag should be set on secrets. |
| Enforce secure-by-default Key Vault for Enterprises | Enable logging by category group for Managed HSMs (microsoft.keyvault/managedhsms) to Log Analytics | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Log Analytics workspace for Managed HSMs (microsoft.keyvault/managedhsms). |
| Enforce secure-by-default Key Vault for Enterprises | Secrets should not be active for longer than the specified number of days | If your secrets were created with an activation date set in the future, you must ensure that your secrets have not been active for longer than the specified duration. |
| Enforce secure-by-default Key Vault for Enterprises | Secrets should have more than the specified number of days before expiration | If a secret is too close to expiration, an organizational delay to rotate the secret may result in an outage. Secrets should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. |
| Enforce secure-by-default Key Vault for Enterprises | Keys using elliptic curve cryptography should have the specified curve names | Keys backed by elliptic curve cryptography can have different curve names. Some applications are only compatible with specific elliptic curve keys. Enforce the types of elliptic curve keys that are allowed to be created in your environment. |
| Enforce secure-by-default Key Vault for Enterprises | Keys should not be active for longer than the specified number of days | Specify the number of days that a key should be active. Keys that are used for an extended period of time increase the probability that an attacker could compromise the key. As a good security practice, make sure that your keys have not been active longer than two years. |
| Enforce secure-by-default Key Vault for Enterprises | Keys should have more than the specified number of days before expiration | If a key is too close to expiration, an organizational delay to rotate the key may result in an outage. Keys should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. |
| Enforce secure-by-default Key Vault for Enterprises | Keys should be the specified cryptographic type RSA or EC | Some applications require the use of keys backed by a specific cryptographic type. Enforce a particular cryptographic key type, RSA or EC, in your environment. |
| Enforce secure-by-default Key Vault for Enterprises | Configure key vaults to enable firewall | Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: https://docs.microsoft.com/azure/key-vault/general/network-security |
| Enforce secure-by-default Key Vault for Enterprises | Certificates using elliptic curve cryptography should have allowed curve names | Manage the allowed elliptic curve names for ECC Certificates stored in key vault. More information can be found at https://aka.ms/akvpolicy. |
| Enforce secure-by-default Key Vault for Enterprises | Certificates should use allowed key types | Manage your organizational compliance requirements by restricting the key types allowed for certificates. |
| Enforce secure-by-default Key Vault for Enterprises | Azure Key Vault should have firewall enabled | Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. Optionally, you can configure specific IP ranges to limit access to those networks. Learn more at: https://docs.microsoft.com/azure/key-vault/general/network-security |
| Enforce secure-by-default Key Vault for Enterprises | Secrets should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a secret can be valid within your key vault. |
| Enforce secure-by-default Key Vault for Enterprises | Keys should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a key can be valid within your key vault. |
| Enforce secure-by-default Key Vault for Enterprises | Key Vault secrets should have an expiration date | Secrets should have a defined expiration date and not be permanent. Secrets that are valid forever provide a potential attacker with more time to compromise them. It is a recommended security practice to set expiration dates on secrets. |
| Enforce secure-by-default Key Vault for Enterprises | [Preview]: Azure Key Vault Managed HSM keys should have an expiration date | To use this policy in preview, you must first follow these instructions at https://aka.ms/mhsmgovernance. Cryptographic keys should have a defined expiration date and not be permanent. Keys that are valid forever provide a potential attacker with more time to compromise the key. It is a recommended security practice to set expiration dates on cryptographic keys. |
| Enforce secure-by-default Key Vault for Enterprises | Key Vault keys should have an expiration date | Cryptographic keys should have a defined expiration date and not be permanent. Keys that are valid forever provide a potential attacker with more time to compromise the key. It is a recommended security practice to set expiration dates on cryptographic keys. |
| Enforce secure-by-default Key Vault for Enterprises | [Preview]: Certificates should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |
| Enforce secure-by-default Key Vault for Enterprises | Azure Key Vault Managed HSM should have purge protection enabled | Malicious deletion of an Azure Key Vault Managed HSM can lead to permanent data loss. A malicious insider in your organization can potentially delete and purge Azure Key Vault Managed HSM. Purge protection protects you from insider attacks by enforcing a mandatory retention period for soft deleted Azure Key Vault Managed HSM. No one inside your organization or Microsoft will be able to purge your Azure Key Vault Managed HSM during the soft delete retention period. |
| Enforce secure-by-default Key Vault for Enterprises | Deploy - Configure diagnostic settings for Azure Key Vault to Log Analytics workspace | Deploys the diagnostic settings for Azure Key Vault to stream resource logs to a Log Analytics workspace when any Key Vault which is missing this diagnostic settings is created or updated. |
| Enforce secure-by-default Key Vault for Enterprises | [Preview]: Configure Azure Key Vault Managed HSM to disable public network access | Disable public network access for your Azure Key Vault Managed HSM so that it's not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://docs.microsoft.com/azure/key-vault/managed-hsm/private-link#allow-trusted-services-to-access-managed-hsm. |
| Enforce secure-by-default Key Vault for Enterprises | Azure Key Vault should disable public network access | Disable public network access for your key vault so that it's not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://aka.ms/akvprivatelink. |
| Enforce secure-by-default Key Vault for Enterprises | Key vaults should have soft delete enabled | Deleting a key vault without soft delete enabled permanently deletes all secrets, keys, and certificates stored in the key vault. Accidental deletion of a key vault can lead to permanent data loss. Soft delete allows you to recover an accidentally deleted key vault for a configurable retention period. |
| Enforce secure-by-default Key Vault for Enterprises | [Preview]: Azure Key Vault Managed HSM should disable public network access | Disable public network access for your Azure Key Vault Managed HSM so that it's not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://docs.microsoft.com/azure/key-vault/managed-hsm/private-link#allow-trusted-services-to-access-managed-hsm. |
| Enforce secure-by-default Key Vault for Enterprises | [Preview]: Azure Key Vault should use RBAC permission model | Enable RBAC permission model across Key Vaults. Learn more at: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-migration |
| Enforce secure-by-default Key Vault for Enterprises | Key vaults should have deletion protection enabled | Malicious deletion of a key vault can lead to permanent data loss. You can prevent permanent data loss by enabling purge protection and soft delete. Purge protection protects you from insider attacks by enforcing a mandatory retention period for soft deleted key vaults. No one inside your organization or Microsoft will be able to purge your key vaults during the soft delete retention period. Keep in mind that key vaults created after September 1st 2019 have soft-delete enabled by default. |
| Enforce secure-by-default Key Vault for Enterprises | Certificates should have the specified lifetime action triggers | Manage your organizational compliance requirements by specifying whether a certificate lifetime action is triggered at a specific percentage of its lifetime or at a certain number of days prior to its expiration. |
| Enforce secure-by-default Key Vault for Enterprises | Keys using RSA cryptography should have a specified minimum key size | Set the minimum allowed key size for use with your key vaults. Use of RSA keys with small key sizes is not a secure practice and doesn't meet many industry certification requirements. |
| Enforce secure-by-default Key Vault for Enterprises | [Preview]: Azure Key Vault Managed HSM keys using RSA cryptography should have a specified minimum key size | To use this policy in preview, you must first follow these instructions at https://aka.ms/mhsmgovernance. Set the minimum allowed key size for use with your key vaults. Use of RSA keys with small key sizes is not a secure practice and doesn't meet many industry certification requirements. |
| Enforce secure-by-default Key Vault for Enterprises | Certificates using RSA cryptography should have the specified minimum key size | Manage your organizational compliance requirements by specifying a minimum key size for RSA certificates stored in your key vault. |
| PolicySetDefinition | PolicyDefinition DisplayName | PolicyDefinition Description |
|---|---|---|
| Enforce secure-by-default Network and Networking services for Enterprises | Azure Web Application Firewall should be enabled for Azure Front Door entry-points | Deploy Azure Web Application Firewall (WAF) in front of public facing web applications for additional inspection of incoming traffic. Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities such as SQL injections, Cross-Site Scripting, local and remote file executions. You can also restrict access to your web applications by countries, IP address ranges, and other http(s) parameters via custom rules. |
| Enforce secure-by-default Network and Networking services for Enterprises | Enable logging by category group for Public IP addresses (microsoft.network/publicipaddresses) to Log Analytics | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Log Analytics workspace for Public IP addresses (microsoft.network/publicipaddresses). |
| Enforce secure-by-default Network and Networking services for Enterprises | Enable logging by category group for Front Door and CDN profiles (microsoft.cdn/profiles) to Log Analytics | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Log Analytics workspace for Front Door and CDN profiles (microsoft.cdn/profiles). |
| Enforce secure-by-default Network and Networking services for Enterprises | Enable logging by category group for Bastions (microsoft.network/bastionhosts) to Log Analytics | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Log Analytics workspace for Bastions (microsoft.network/bastionhosts). |
| Enforce secure-by-default Network and Networking services for Enterprises | Web Application Firewall (WAF) should use the specified mode for Application Gateway | Mandates the use of 'Detection' or 'Prevention' mode to be active on all Web Application Firewall policies for Application Gateway. |
| Enforce secure-by-default Network and Networking services for Enterprises | Web Application Firewall (WAF) should enable all firewall rules for Application Gateway | Enabling all Web Application Firewall (WAF) rules strengthens your application security and protects your web applications against common vulnerabilities. To learn more about Web Application Firewall (WAF) with Application Gateway, visit https://aka.ms/waf-ag |
| Enforce secure-by-default Network and Networking services for Enterprises | Web Application Firewall (WAF) should use the specified mode for Azure Front Door Service | Mandates the use of 'Detection' or 'Prevention' mode to be active on all Web Application Firewall policies for Azure Front Door Service. |
| Enforce secure-by-default Network and Networking services for Enterprises | Configure diagnostic settings for Azure Network Security Groups to Log Analytics workspace | Deploy diagnostic settings to Azure Network Security Groups to stream resource logs to a Log Analytics workspace. |
| Enforce secure-by-default Network and Networking services for Enterprises | Virtual networks should be protected by Azure DDoS Protection Standard | Protect your virtual networks against volumetric and protocol attacks with Azure DDoS Protection Standard. For more information, visit https://aka.ms/ddosprotectiondocs. |
| Enforce secure-by-default Network and Networking services for Enterprises | Network interfaces should disable IP forwarding | This policy denies the network interfaces which enabled IP forwarding. The setting of IP forwarding disables Azure's check of the source and destination for a network interface. This should be reviewed by the network security team. |
| Enforce secure-by-default Network and Networking services for Enterprises | Network interfaces should not have public IPs | This policy denies the network interfaces which are configured with any public IP. Public IP addresses allow internet resources to communicate inbound to Azure resources, and Azure resources to communicate outbound to the internet. This should be reviewed by the network security team. |
| Enforce secure-by-default Network and Networking services for Enterprises | Web Application Firewall (WAF) should be enabled for Application Gateway | Deploy Azure Web Application Firewall (WAF) in front of public facing web applications for additional inspection of incoming traffic. Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities such as SQL injections, Cross-Site Scripting, local and remote file executions. You can also restrict access to your web applications by countries, IP address ranges, and other http(s) parameters via custom rules. |
| Enforce secure-by-default Network and Networking services for Enterprises | Prevent creation of subnets without Route Table | This policy prevents creation of subnets without a UDR attached to them. |
| Enforce secure-by-default Network and Networking services for Enterprises | Subnets should have a Network Security Group | This policy denies the creation of a subnet without a Network Security Group. NSG help to protect traffic across subnet-level. |
| Enforce secure-by-default Network and Networking services for Enterprises | Prevent NSG rule changes that allow all inbound traffic | Prevent the creation of network security group rules that allow all inbound traffic |
| Enforce secure-by-default Network and Networking services for Enterprises | Deny or Audit service endpoints on subnets | This Policy will deny/audit Service Endpoints on subnets. Service Endpoints allows the network traffic to bypass Network appliances, such as the Azure Firewall. |
| Enforce secure-by-default Network and Networking services for Enterprises | Deploy Diagnostic Settings for Load Balancer to Log Analytics workspace | Deploys the diagnostic settings for Load Balancer to stream to a Log Analytics workspace when any Load Balancer which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all metrics and category enabled |
| Enforce secure-by-default Network and Networking services for Enterprises | Deploy Diagnostic Settings for Front Door to Log Analytics workspace | Deploys the diagnostic settings for Front Door to stream to a Log Analytics workspace when any Front Door which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all metrics and category enabled |
| Enforce secure-by-default Network and Networking services for Enterprises | Deploy Diagnostic Settings for Traffic Manager to Log Analytics workspace | Deploys the diagnostic settings for Traffic Manager to stream to a Log Analytics workspace when any Traffic Manager which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all metrics and category enabled |
| Enforce secure-by-default Network and Networking services for Enterprises | Deploy Diagnostic Settings for Virtual Network to Log Analytics workspace | Deploys the diagnostic settings for Virtual Network to stream to a Log Analytics workspace when any Virtual Network which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all metrics and category enabled |
| Enforce secure-by-default Network and Networking services for Enterprises | RDP access from the internet should be blocked | This policy denies any network security rule that allows RDP access from internet |
| Enforce secure-by-default Network and Networking services for Enterprises | SSH access from the internet should be blocked | This policy denies any network security rule that allows SSH access from internet |
| Enforce secure-by-default Network and Networking services for Enterprises | Deploy Diagnostic Settings for Application Gateway to Log Analytics workspace | Deploys the diagnostic settings for Application Gateway to stream to a Log Analytics workspace when any Application Gateway which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all metrics and category enabled |
| Enforce secure-by-default Network and Networking services for Enterprises | Application Gateway should be deployed with predefined Microsoft policy that is using TLS version 1.2 | This policy enables you to restrict that Application Gateways is always deployed with predefined Microsoft policy that is using TLS version 1.2 |
| Enforce secure-by-default Network and Networking services for Enterprises | Enforce specific configuration of User-Defined Routes (UDR) | This policy enforces the configuration of User-Defined Routes (UDR) within a subnet. |
| Enforce secure-by-default Network and Networking services for Enterprises | Enforce specific configuration of Network Security Groups (NSG) | This policy enforces the configuration of Network Security Groups (NSG). |
| PolicySetDefinition | PolicyDefinition DisplayName | PolicyDefinition Description |
|---|---|---|
| Enforce secure-by-default Storage Account for Enterprises | Storage accounts should use customer-managed key for encryption | Secure your blob and file storage account with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. |
| Enforce secure-by-default Storage Account for Enterprises | Allowed Copy scope should be restricted for Storage Accounts | Azure Storage accounts should restrict the allowed copy scope. Enforce this for increased data exfiltration protection. |
| Enforce secure-by-default Storage Account for Enterprises | Encryption for storage services should be enforced for Storage Accounts | Azure Storage accounts should enforce encryption for all storage services. Enforce this for increased encryption scope. |
| Enforce secure-by-default Storage Account for Enterprises | Local users should be restricted for Storage Accounts | Azure Storage accounts should disable local users for features like SFTP. Enforce this for increased data exfiltration protection. |
| Enforce secure-by-default Storage Account for Enterprises | SFTP should be restricted for Storage Accounts | Azure Storage accounts should disable SFTP. Enforce this for increased data exfiltration protection. |
| Enforce secure-by-default Storage Account for Enterprises | Network ACL bypass option should be restricted for Storage Accounts | Azure Storage accounts should restrict the bypass option for service-level network ACLs. Enforce this for increased data exfiltration protection. |
| Enforce secure-by-default Storage Account for Enterprises | Resource Access Rules Tenants should be restricted for Storage Accounts | Azure Storage accounts should restrict the resource access rule for service-level network ACLs to service from the same AAD tenant. Enforce this for increased data exfiltration protection. |
| Enforce secure-by-default Storage Account for Enterprises | Resource Access Rules resource IDs should be restricted for Storage Accounts | Azure Storage accounts should restrict the resource access rule for service-level network ACLs to services from a specific Azure subscription. Enforce this for increased data exfiltration protection. |
| Enforce secure-by-default Storage Account for Enterprises | Virtual network rules should be restricted for Storage Accounts | Azure Storage accounts should restrict the virtual network service-level network ACLs. Enforce this for increased data exfiltration protection. |
| Enforce secure-by-default Storage Account for Enterprises | Public blob access should be restricted for Storage Accounts | Azure Storage accounts should restrict blob access to private. Enforce this for increased data exfiltration protection. |
| Enforce secure-by-default Storage Account for Enterprises | Storage Accounts should use a container delete retention policy | Enforce container delete retention policies larger than seven days for storage account. Enable this for increased data loss protection |
| Enforce secure-by-default Storage Account for Enterprises | Storage Accounts should restrict CORS rules | Deny cors rules for storage account for increased data exfiltration protection and endpoint protection. |
| Enforce secure-by-default Storage Account for Enterprises | Configure diagnostic settings for Blob Services to Log Analytics workspace | Deploys the diagnostic settings for Blob Services to stream resource logs to a Log Analytics workspace when any blob Service which is missing this diagnostic settings is created or updated. |
| Enforce secure-by-default Storage Account for Enterprises | Storage account encryption scopes should use customer-managed keys to encrypt data at rest | Use customer-managed keys to manage the encryption at rest of your storage account encryption scopes. Customer-managed keys enable the data to be encrypted with an Azure key-vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about storage account encryption scopes at https://aka.ms/encryption-scopes-overview. |
| Enforce secure-by-default Storage Account for Enterprises | Storage accounts should have the specified minimum TLS version | Configure a minimum TLS version for secure communication between the client application and the storage account. To minimize security risk, the recommended minimum TLS version is the latest released version, which is currently TLS 1.2. |
| Enforce secure-by-default Storage Account for Enterprises | Queue Storage should use customer-managed key for encryption | Secure your queue storage with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. |
| Enforce secure-by-default Storage Account for Enterprises | Storage account encryption scopes should use double encryption for data at rest | Enable infrastructure encryption for encryption at rest of your storage account encryption scopes for added security. Infrastructure encryption ensures that your data is encrypted twice. |
| Enforce secure-by-default Storage Account for Enterprises | Storage accounts should disable public network access | To improve the security of Storage Accounts, ensure that they aren't exposed to the public internet and can only be accessed from a private endpoint. Disable the public network access property as described in https://aka.ms/storageaccountpublicnetworkaccess. This option disables access from any public address space outside the Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. This reduces data leakage risks. |
| Enforce secure-by-default Storage Account for Enterprises | Configure storage accounts to disable public network access | To improve the security of Storage Accounts, ensure that they aren't exposed to the public internet and can only be accessed from a private endpoint. Disable the public network access property as described in https://aka.ms/storageaccountpublicnetworkaccess. This option disables access from any public address space outside the Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. This reduces data leakage risks. |
| Enforce secure-by-default Storage Account for Enterprises | Storage accounts should prevent cross tenant object replication | Audit restriction of object replication for your storage account. By default, users can configure object replication with a source storage account in one Azure AD tenant and a destination account in a different tenant. It is a security concern because customer's data can be replicated to a storage account that is owned by the customer. By setting allowCrossTenantReplication to false, objects replication can be configured only if both source and destination accounts are in the same Azure AD tenant. |
| Enforce secure-by-default Storage Account for Enterprises | Storage accounts should prevent shared key access | Audit requirement of Azure Active Directory (Azure AD) to authorize requests for your storage account. By default, requests can be authorized with either Azure Active Directory credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Azure AD provides superior security and ease of use over Shared Key, and is recommended by Microsoft. |
| Enforce secure-by-default Storage Account for Enterprises | Table Storage should use customer-managed key for encryption | Secure your table storage with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. |
| Enforce secure-by-default Storage Account for Enterprises | Configure diagnostic settings for Queue Services to Log Analytics workspace | Deploys the diagnostic settings for Queue Services to stream resource logs to a Log Analytics workspace when any queue Service which is missing this diagnostic settings is created or updated. Note: This policy is not triggered upon Storage Account creation and requires creation of a remediation task in order to update for the account. |
| Enforce secure-by-default Storage Account for Enterprises | Configure a private DNS Zone ID for blob groupID | Configure private DNS zone group to override the DNS resolution for a blob groupID private endpoint. |
| Enforce secure-by-default Storage Account for Enterprises | Configure a private DNS Zone ID for blob_secondary groupID | Configure private DNS zone group to override the DNS resolution for a blob_secondary groupID private endpoint. |
| Enforce secure-by-default Storage Account for Enterprises | Configure a private DNS Zone ID for dfs groupID | Configure private DNS zone group to override the DNS resolution for a dfs groupID private endpoint. |
| Enforce secure-by-default Storage Account for Enterprises | Configure a private DNS Zone ID for dfs_secondary groupID | Configure private DNS zone group to override the DNS resolution for a dfs_secondary groupID private endpoint. |
| Enforce secure-by-default Storage Account for Enterprises | Configure a private DNS Zone ID for queue groupID | Configure private DNS zone group to override the DNS resolution for a queue groupID private endpoint. |
| Enforce secure-by-default Storage Account for Enterprises | Configure a private DNS Zone ID for queue_secondary groupID | Configure private DNS zone group to override the DNS resolution for a queue_secondary groupID private endpoint. |
| Enforce secure-by-default Storage Account for Enterprises | Configure a private DNS Zone ID for web groupID | Configure private DNS zone group to override the DNS resolution for a web groupID private endpoint. |
| Enforce secure-by-default Storage Account for Enterprises | Configure a private DNS Zone ID for web_secondary groupID | Configure private DNS zone group to override the DNS resolution for a web_secondary groupID private endpoint. |
| Enforce secure-by-default Storage Account for Enterprises | Configure diagnostic settings for Storage Accounts to Log Analytics workspace | Deploys the diagnostic settings for Storage accounts to stream resource logs to a Log Analytics workspace when any storage accounts which is missing this diagnostic settings is created or updated. |
| Enforce secure-by-default Storage Account for Enterprises | [Preview]: Storage account public access should be disallowed | Anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but might present security risks. To prevent data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it. |
| Enforce secure-by-default Storage Account for Enterprises | Storage accounts should have infrastructure encryption | Enable infrastructure encryption for higher level of assurance that the data is secure. When infrastructure encryption is enabled, data in a storage account is encrypted twice. |
| Enforce secure-by-default Storage Account for Enterprises | Secure transfer to storage accounts should be enabled | Audit requirement of Secure transfer in your storage account. Secure transfer is an option that forces your storage account to accept requests only from secure connections (HTTPS). Use of HTTPS ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking |
| Enforce secure-by-default Storage Account for Enterprises | Storage accounts should be migrated to new Azure Resource Manager resources | Use new Azure Resource Manager for your storage accounts to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management |
| Enforce secure-by-default Storage Account for Enterprises | Deploy Defender for Storage (Classic) on storage accounts | This policy enables Defender for Storage (Classic) on storage accounts. |
| Enforce secure-by-default Storage Account for Enterprises | Storage accounts should restrict network access | Network access to storage accounts should be restricted. Configure network rules so only applications from allowed networks can access the storage account. To allow connections from specific internet or on-premises clients, access can be granted to traffic from specific Azure virtual networks or to public internet IP address ranges |
| Enforce secure-by-default Storage Account for Enterprises | Configure diagnostic settings for Table Services to Log Analytics workspace | Deploys the diagnostic settings for Table Services to stream resource logs to a Log Analytics workspace when any table Service which is missing this diagnostic settings is created or updated. Note: This policy is not triggered upon Storage Account creation and requires creation of a remediation task in order to update for the account. |
| Enforce secure-by-default Storage Account for Enterprises | Storage accounts should restrict network access using virtual network rules | Protect your storage accounts from potential threats using virtual network rules as a preferred method instead of IP-based filtering. Disabling IP-based filtering prevents public IPs from accessing your storage accounts. |
| Enforce secure-by-default Storage Account for Enterprises | Configure diagnostic settings for File Services to Log Analytics workspace | Deploys the diagnostic settings for File Services to stream resource logs to a Log Analytics workspace when any file Service which is missing this diagnostic settings is created or updated. |
| Enforce secure-by-default Storage Account for Enterprises | Public network access should be disabled for Azure File Sync | Disabling the public endpoint allows you to restrict access to your Storage Sync Service resource to requests destined to approved private endpoints on your organization's network. There is nothing inherently insecure about allowing requests to the public endpoint, however, you may wish to disable it to meet regulatory, legal, or organizational policy requirements. You can disable the public endpoint for a Storage Sync Service by setting the incomingTrafficPolicy of the resource to AllowVirtualNetworksOnly. |
| Enforce secure-by-default Storage Account for Enterprises | Configure your Storage account public access to be disallowed | Anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but might present security risks. To prevent data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it. |
| Enforce secure-by-default Storage Account for Enterprises | Modify - Configure Azure File Sync to disable public network access | The Azure File Sync's internet-accessible public endpoint are disabled by your organizational policy. You may still access the Storage Sync Service via its private endpoint(s). |
| Enforce secure-by-default Storage Account for Enterprises | Storage account keys should not be expired | Ensure the user storage account keys are not expired when key expiration policy is set, for improving security of account keys by taking action when the keys are expired. |
Note: The Azure Resource Provider for Azure OpenAI is Microsoft.CognitiveServices and is empowering several of the other Azure AI services, such as Document Intelligence, Computer Vision and more, and will apply broadly to all the service kinds for the Resource Provider.
| PolicySetDefinition | PolicyDefinition DisplayName | PolicyDefinition Description |
|---|---|---|
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Outbound network access should be restricted for Cognitive Services | Azure Cognitive Services allow restricting outbound network access. Enable this to limit outbound connectivity for the service. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Network ACLs should be restricted for Cognitive Services | Azure Cognitive Services should not allow adding individual IPs or virtual network rules to the service-level firewall. Enable this to restrict inbound network access and enforce the usage of private endpoints. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Deploy Diagnostic Settings for Azure OpenAI (Cognitive Services) to Log Analytics workspace | Deploys the diagnostic settings for Azure OpenAI (Cognitive Services) to stream to a Log Analytics workspace when any Azure OpenAI which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all and categorys enabled. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Cognitive Services accounts should use a managed identity | Assigning a managed identity to your Cognitive Service account helps ensure secure authentication. This identity is used by this Cognitive service account to communicate with other Azure services, like Azure Key Vault, in a secure way without you having to manage any credentials. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Cognitive Services accounts should have local authentication methods disabled | Disabling local authentication methods improves security by ensuring that Cognitive Services accounts require Azure Active Directory identities exclusively for authentication. Learn more at: https://aka.ms/cs/auth. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Cognitive Services accounts should enable data encryption with a customer-managed key | Customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data stored in Cognitive Services to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about customer-managed keys at https://go.microsoft.com/fwlink/?linkid=2121321. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Configure Cognitive Services accounts to disable public network access | Disable public network access for your Cognitive Services resource so that it's not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://go.microsoft.com/fwlink/?linkid=2129800. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Cognitive Services accounts should use customer owned storage | Use customer owned storage to control the data stored at rest in Cognitive Services. To learn more about customer owned storage, visit https://aka.ms/cogsvc-cmk. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Configure Cognitive Services accounts to disable local authentication methods | Disable local authentication methods so that your Cognitive Services accounts require Azure Active Directory identities exclusively for authentication. Learn more at: https://aka.ms/cs/auth. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Cognitive Services accounts should disable public network access | To improve the security of Cognitive Services accounts, ensure that it isn't exposed to the public internet and can only be accessed from a private endpoint. Disable the public network access property as described in https://go.microsoft.com/fwlink/?linkid=2129800. This option disables access from any public address space outside the Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. This reduces data leakage risks. |
| Enforce secure-by-default Azure OpenAI (Cognitive Service) for Enterprises | Cognitive Services accounts should restrict network access | Network access to Cognitive Services accounts should be restricted. Configure network rules so only applications from allowed networks can access the Cognitive Services account. To allow connections from specific internet or on-premises clients, access can be granted to traffic from specific Azure virtual networks or to public internet IP address ranges. |
| PolicySetDefinition | PolicyDefinition DisplayName | PolicyDefinition Description |
|---|---|---|
| Enforce secure-by-default Azure AI Search for Enterprises | Deploy Diagnostic Settings for Azure AI Search to Log Analytics workspace | Deploys the diagnostic settings for Azure AI Search to stream to a Log Analytics workspace when any Open Ai which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all and categorys enabled. |
| Enforce secure-by-default Azure AI Search for Enterprises | Azure Azure AI Search service should use a SKU that supports private link | With supported SKUs of Azure Azure AI Search, Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Search service, data leakage risks are reduced. Learn more at: https://aka.ms/azure-cognitive-search/inbound-private-endpoints. |
| Enforce secure-by-default Azure AI Search for Enterprises | Azure Azure AI Search services should disable public network access | Disabling public network access improves security by ensuring that your Azure Azure AI Search service is not exposed on the public internet. Creating private endpoints can limit exposure of your Search service. Learn more at: https://aka.ms/azure-cognitive-search/inbound-private-endpoints. |
| Enforce secure-by-default Azure AI Search for Enterprises | Azure Azure AI Search services should have local authentication methods disabled | Disabling local authentication methods improves security by ensuring that Azure Azure AI Search services exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/azure-cognitive-search/rbac. Note that while the disable local authentication parameter is still in preview, the deny effect for this policy may result in limited Azure Azure AI Search portal functionality since some features of the Portal use the GA API which does not support the parameter. |
| Enforce secure-by-default Azure AI Search for Enterprises | Azure Azure AI Search services should use customer-managed keys to encrypt data at rest | Enabling encryption at rest using a customer-managed key on your Azure Azure AI Search services provides additional control over the key used to encrypt data at rest. This feature is often applicable to customers with special compliance requirements to manage data encryption keys using a key vault. |
| Enforce secure-by-default Azure AI Search for Enterprises | Configure Azure Azure AI Search services to disable local authentication | Disable local authentication methods so that your Azure Azure AI Search services exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/azure-cognitive-search/rbac. |
| Enforce secure-by-default Azure AI Search for Enterprises | Configure Azure Azure AI Search services to disable public network access | Disable public network access for your Azure Azure AI Search service so that it is not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://aka.ms/azure-cognitive-search/inbound-private-endpoints. |
Note: Recommended when deploying the Sample App for 'On Your Data' use case.
| PolicySetDefinition | PolicyDefinition DisplayName | PolicyDefinition Description |
|---|---|---|
| Enforce secure-by-default App Service for Enterprises | Deploy Diagnostic Settings for App Service Web App to Log Analytics workspace | Deploys the diagnostic settings for Web App to stream to a Log Analytics workspace when any Web App which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all metrics and category enabled |
| Enforce secure-by-default App Service for Enterprises | Deploy Diagnostic Settings for Azure Function App to Log Analytics workspace | Deploys the diagnostic settings for Azure Function App to stream to a Log Analytics workspace when any function app which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all metrics and category enabled |
| Enforce secure-by-default App Service for Enterprises | API App should only be accessible over HTTPS | Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. |
| Enforce secure-by-default App Service for Enterprises | Logic apps should disable public network access | Disabling public network access improves security by ensuring that the Logic App is not exposed on the public internet. Creating private endpoints can limit exposure of a Logic App. Learn more at: https://aka.ms/app-service-private-endpoint. |
| Enforce secure-by-default App Service for Enterprises | Logic app should only be accessible over HTTPS | Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. |
| Enforce secure-by-default App Service for Enterprises | Configure Logic apps to use the latest TLS version | Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for Function apps to take advantage of security fixes, if any, and/or new functionalities of the latest version. |
| Enforce secure-by-default App Service for Enterprises | Deploy Diagnostic Settings for Azure Logic App to Log Analytics workspace | Deploys the diagnostic settings for Azure Logic App to stream to a Log Analytics workspace when any function app which is missing this diagnostic settings is created or updated. The Policy will set the diagnostic with all metrics and category enabled |
| Enforce secure-by-default App Service for Enterprises | App Service certificates must be stored in Key Vault | App Service (including Logic apps and Function apps) must use certificates stored in Key Vault |
| Enforce secure-by-default App Service for Enterprises | Configure Function app slots to use the latest TLS version | Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for Function apps to take advantage of security fixes, if any, and/or new functionalities of the latest version. |
| Enforce secure-by-default App Service for Enterprises | Configure Function app slots to only be accessible over HTTPS | Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. |
| Enforce secure-by-default App Service for Enterprises | Configure Function app slots to disable public network access | Disable public network access for your Function apps so that it is not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://aka.ms/app-service-private-endpoint. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service apps to use the latest TLS version | Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for App Service apps to take advantage of security fixes, if any, and/or new functionalities of the latest version. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service apps to turn off remote debugging | Remote debugging requires inbound ports to be opened on an App Service app. Remote debugging should be turned off. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service apps to disable public network access | Disable public network access for your App Services so that it is not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://aka.ms/app-service-private-endpoint. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service app slots to disable public network access | Disable public network access for your App Services so that it is not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://aka.ms/app-service-private-endpoint. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service app slots to turn off remote debugging | Remote debugging requires inbound ports to be opened on an App Service app. Remote debugging should be turned off. |
| Enforce secure-by-default App Service for Enterprises | App Service Environment should be provisioned with latest versions | Only allow App Service Environment version 2 or version 3 to be provisioned. Older versions of App Service Environment require manual management of Azure resources and have greater scaling limitations. |
| Enforce secure-by-default App Service for Enterprises | App Service apps should only be accessible over HTTPS | Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. |
| Enforce secure-by-default App Service for Enterprises | App Service apps should enable configuration routing to Azure Virtual Network | By default, app configuration such as pulling container images and mounting content storage will not be routed through the regional virtual network integration. Using the API to set routing options to true enables configuration traffic through the Azure Virtual Network. These settings allow features like network security groups and user defined routes to be used, and service endpoints to be private. For more information, visit https://aka.ms/appservice-vnet-configuration-routing. |
| Enforce secure-by-default App Service for Enterprises | App Service app slots should only be accessible over HTTPS | Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. |
| Enforce secure-by-default App Service for Enterprises | App Service app slots should enable outbound non-RFC 1918 traffic to Azure Virtual Network | By default, if one uses regional Azure Virtual Network (VNET) integration, the app only routes RFC1918 traffic into that respective virtual network. Using the API to set 'vnetRouteAllEnabled' to true enables all outbound traffic into the Azure Virtual Network. This setting allows features like network security groups and user defined routes to be used for all outbound traffic from the App Service app. |
| Enforce secure-by-default App Service for Enterprises | App Service apps should enable outbound non-RFC 1918 traffic to Azure Virtual Network | By default, if one uses regional Azure Virtual Network (VNET) integration, the app only routes RFC1918 traffic into that respective virtual network. Using the API to set 'vnetRouteAllEnabled' to true enables all outbound traffic into the Azure Virtual Network. This setting allows features like network security groups and user defined routes to be used for all outbound traffic from the App Service app. |
| Enforce secure-by-default App Service for Enterprises | App Service Environment should have TLS 1.0 and 1.1 disabled | TLS 1.0 and 1.1 are out-of-date protocols that do not support modern cryptographic algorithms. Disabling inbound TLS 1.0 and 1.1 traffic helps secure apps in an App Service Environment. |
| Enforce secure-by-default App Service for Enterprises | Function apps should disable public network access | Disabling public network access improves security by ensuring that the Function app is not exposed on the public internet. Creating private endpoints can limit exposure of a Function App. Learn more at: https://aka.ms/app-service-private-endpoint. |
| Enforce secure-by-default App Service for Enterprises | Configure Function app slots to turn off remote debugging | Remote debugging requires inbound ports to be opened on a Function app. Remote debugging should be turned off. |
| Enforce secure-by-default App Service for Enterprises | App Service app slots should disable public network access | Disabling public network access improves security by ensuring that the App Service is not exposed on the public internet. Creating private endpoints can limit exposure of an App Service. Learn more at: https://aka.ms/app-service-private-endpoint. |
| Enforce secure-by-default App Service for Enterprises | Function apps should only be accessible over HTTPS | Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service apps to disable local authentication for SCM sites | Disabling local authentication methods for SCM sites improves security by ensuring that App Services exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/app-service-disable-basic-auth. |
| Enforce secure-by-default App Service for Enterprises | Function app slots should only be accessible over HTTPS | Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. |
| Enforce secure-by-default App Service for Enterprises | App Service app slots should enable configuration routing to Azure Virtual Network | By default, app configuration such as pulling container images and mounting content storage will not be routed through the regional virtual network integration. Using the API to set routing options to true enables configuration traffic through the Azure Virtual Network. These settings allow features like network security groups and user defined routes to be used, and service endpoints to be private. For more information, visit https://aka.ms/appservice-vnet-configuration-routing. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service apps to disable local authentication for FTP deployments | Disabling local authentication methods for FTP deployments improves security by ensuring that App Services exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/app-service-disable-basic-auth. |
| Enforce secure-by-default App Service for Enterprises | App Service apps should use a SKU that supports private link | With supported SKUs, Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to apps, you can reduce data leakage risks. Learn more about private links at: https://aka.ms/private-link. |
| Enforce secure-by-default App Service for Enterprises | App Service Environment apps should not be reachable over public internet | To ensure apps deployed in an App Service Environment are not accessible over public internet, one should deploy App Service Environment with an IP address in virtual network. To set the IP address to a virtual network IP, the App Service Environment must be deployed with an internal load balancer. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service app slots to disable local authentication for SCM sites | Disabling local authentication methods for SCM sites improves security by ensuring that App Service slots exclusively require Azure Active Directory identities for authentication. Learn more at: https://aka.ms/app-service-disable-basic-auth. |
| Enforce secure-by-default App Service for Enterprises | Configure Function apps to turn off remote debugging | Remote debugging requires inbound ports to be opened on Function apps. Remote debugging should be turned off. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service app slots to use the latest TLS version | Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for App Service apps to take advantage of security fixes, if any, and/or new functionalities of the latest version. |
| Enforce secure-by-default App Service for Enterprises | Configure App Service apps to only be accessible over HTTPS | Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks. |
| Enforce secure-by-default App Service for Enterprises | Function app slots should disable public network access | Disabling public network access improves security by ensuring that the Function app is not exposed on the public internet. Creating private endpoints can limit exposure of a Function App. Learn more at: https://aka.ms/app-service-private-endpoint. |
| Enforce secure-by-default App Service for Enterprises | Function app slots should disable public network access | Disabling public network access improves security by ensuring that the Function app is not exposed on the public internet. Creating private endpoints can limit exposure of a Function App. Learn more at: https://aka.ms/app-service-private-endpoint. |
| Enforce secure-by-default App Service for Enterprises | App Service apps should disable public network access | Disabling public network access improves security by ensuring that the App Service is not exposed on the public internet. Creating private endpoints can limit exposure of an App Service. Learn more at: https://aka.ms/app-service-private-endpoint. |
| Enforce secure-by-default App Service for Enterprises | Configure Function apps to use the latest TLS version | Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for Function apps to take advantage of security fixes, if any, and/or new functionalities of the latest version. |
Note: Recomennded when deploying as 'Proof of Concept' to multiple Azure regions
| PolicySetDefinition | PolicyDefinition DisplayName | PolicyDefinition Description |
|---|---|---|
| Enforce secure-by-default API Management for Enterprises | Enable logging by category group for API Management services (microsoft.apimanagement/service) to Log Analytics | Resource logs should be enabled to track activities and events that take place on your resources and give you visibility and insights into any changes that occur. This policy deploys a diagnostic setting using a category group to route logs to a Log Analytics workspace for API Management services (microsoft.apimanagement/service). |
| Enforce secure-by-default API Management for Enterprises | API Management secret named values should be stored in Azure Key Vault | Named values are a collection of name and value pairs in each API Management service. Secret values can be stored either as encrypted text in API Management (custom secrets) or by referencing secrets in Azure Key Vault. To improve security of API Management and secrets, reference secret named values from Azure Key Vault. Azure Key Vault supports granular access management and secret rotation policies. |
| Enforce secure-by-default API Management for Enterprises | API Management services should use a virtual network | Azure Virtual Network deployment provides enhanced security, isolation and allows you to place your API Management service in a non-internet routable network that you control access to. These networks can then be connected to your on-premises networks using various VPN technologies, which enables access to your backend services within the network and/or on-premises. The developer portal and API gateway, can be configured to be accessible either from the internet or only within the virtual network. |
| Enforce secure-by-default API Management for Enterprises | API Management services should use TLS version 1.2 | Azure API Management service should use TLS version 1.2 |
| Enforce secure-by-default API Management for Enterprises | API Management APIs should use only encrypted protocols | To ensure security of data in transit, APIs should be available only through encrypted protocols, like HTTPS or WSS. Avoid using unsecured protocols, such as HTTP or WS. |
| Enforce secure-by-default API Management for Enterprises | API Management calls to API backends should be authenticated | Calls from API Management to backends should use some form of authentication, whether via certificates or credentials. Does not apply to Service Fabric backends. |
| Enforce secure-by-default API Management for Enterprises | API Management direct management endpoint should not be enabled | The direct management REST API in Azure API Management bypasses Azure Resource Manager role-based access control, authorization, and throttling mechanisms, thus increasing the vulnerability of your service. |
| Enforce secure-by-default API Management for Enterprises | API Management calls to API backends should not bypass certificate thumbprint or name validation | To improve the API security, API Management should validate the backend server certificate for all API calls. Enable SSL certificate thumbprint and name validation. |
| Enforce secure-by-default API Management for Enterprises | Configure API Management services to disable access to API Management public service configuration endpoints | To improve the security of API Management services, restrict connectivity to service configuration endpoints, like direct access management API, Git configuration management endpoint, or self-hosted gateways configuration endpoint. |
| Enforce secure-by-default API Management for Enterprises | API Management service should use a SKU that supports virtual networks | With supported SKUs of API Management, deploying service into a virtual network unlocks advanced API Management networking and security features which provides you greater control over your network security configuration. Learn more at: https://aka.ms/apimvnet. |
| Enforce secure-by-default API Management for Enterprises | API Management minimum API version should be set to 2019-12-01 or higher | To prevent service secrets from being shared with read-only users, the minimum API version should be set to 2019-12-01 or higher. |
| Enforce secure-by-default API Management for Enterprises | API Management subscriptions should not be scoped to all APIs | API Management subscriptions should be scoped to a product or an individual API instead of all APIs, which could result in an excessive data exposure. |
Deploy one or more of the recommended Azure policies suited for the Enterprise Azure OpenAI Hub enabelment from here.