Skip to main content

🛡️ Azure Cosmos DB Entra ID Client Authentication is not used🟢⚪

Similar Policies​

  • Internal: dec-x-b4d3d9dc

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-b4d3d9dc2

Description​

Open File

Description​

Cosmos DB can use tokens or Entra ID for client authentication, which in turn uses Azure RBAC for authorization. Using Entra ID is significantly more secure because Entra ID handles credentials, enables MFA and centralized management, and Azure RBAC is better integrated with the rest of Azure.

Rationale​

Entra ID client authentication is considerably more secure than token-based authentication because tokens must be stored on the client. Entra ID does not require this.

Audit​

From PowerShell​
$cosmosDbName = "{{cosmos-db-account-name}}"
$resourceGroup = "{{resource-group-name}}"
az cosmosdb show --name $cosmosDbName --resource-group $resourceGroup | ConvertFrom-Json

In the resulting output, disableLocalAuth should be true.

Default Value​

The default is to use tokens/keys for client authentication.

References​

  1. https://learn.microsoft.com/en-us/azure/cosmos-db/role-based-access-control

Remediation​

Open File

Remediation​

Map all resources that currently access the Azure Cosmos DB account using keys or access tokens.

Create an Entra ID identity for each of these resources:

  • For Azure resources, you can create a managed identity. You may choose between system-assigned and user-assigned managed identities.
  • For non-Azure resources, create an Entra ID identity. Grant each Entra ID identity the minimum permission it requires. When possible, we recommend you use one of the 2 built-in role definitions: Cosmos DB Built-in Data Reader or Cosmos DB Built-in Data Contributor. Validate that the new resource is functioning correctly. After new permissions are granted to identities, it may take a few hours until they propagate. When all resources are working correctly with the new identities, continue to the next step.

From PowerShell​

$cosmosDbName = "{{cosmos-db-account-name}}"
$resourceGroup = "{{resource-group-name}}"
$cosmosDb = az cosmosdb show --name $cosmosDbName --resource-group $resourceGroup | ConvertFrom-Json
az resource update --ids $cosmosDb.id --set properties.disableLocalAuth=true --latest-include-preview

... [see more](remediation.md)

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 APRA CPG 234 → 💼 36f network design — to ensure authorised network traffic flows and to reduce the impact of security compromises;2930no data
💼 APRA CPG 234 → 💼 45 An understanding of plausible worst case scenarios can help regulated entities identify and implement additional controls to prevent or reduce the impact of such scenarios. One example is malware that infects computers and encrypts data, both on the infected computer and any connected storage, including (corporate) networks and cloud storage. Such attacks reinforce the importance of protecting the backup environment in the event that the production environment is compromised. Common techniques to achieve this include network segmentation, highly restricted and segregated access controls and network traffic flow restrictions.3537no data
💼 CIS Azure v2.1.0 → 💼 4.5.3 Use Entra ID Client Authentication and Azure RBAC where possible. - Level 1 (Manual)1no data
💼 CIS Azure v3.0.0 → 💼 5.4.3 Use Entra ID Client Authentication and Azure RBAC where possible (Manual)1no data
💼 Cloudaware Framework → 💼 Secure Access53no data
💼 FedRAMP High Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)3784no data
💼 FedRAMP High Security Controls → 💼 AC-4(21) Physical or Logical Separation of Information Flows (M)(H)1163no data
💼 FedRAMP Low Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)84no data
💼 FedRAMP Moderate Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)84no data
💼 FedRAMP Moderate Security Controls → 💼 AC-4(21) Physical or Logical Separation of Information Flows (M)(H)63no data
💼 ISO/IEC 27001:2013 → 💼 A.9.1.2 Access to networks and network services1718no data
💼 ISO/IEC 27001:2013 → 💼 A.9.4.1 Information access restriction1920no data
💼 NIST CSF v1.1 → 💼 PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties1756no data
💼 NIST CSF v1.1 → 💼 PR.DS-5: Protections against data leaks are implemented4791no data
💼 NIST CSF v1.1 → 💼 PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities2130no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties133no data
💼 NIST CSF v2.0 → 💼 PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected187no data
💼 NIST CSF v2.0 → 💼 PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected160no data
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected184no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-4(21) Information Flow Enforcement _ Physical or Logical Separation of Information Flows3763no data
💼 PCI DSS v3.2.1 → 💼 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.7842no data
💼 PCI DSS v4.0.1 → 💼 1.4.1 NSCs are implemented between trusted and untrusted networks.19no data
💼 PCI DSS v4.0 → 💼 1.4.1 NSCs are implemented between trusted and untrusted networks.719no data
💼 SOC 2 → 💼 CC6.1-6 Manages Points of Access57no data
💼 SOC 2 → 💼 CC6.1-8 Manages Identification and Authentication1824no data
💼 UK Cyber Essentials → 💼 1.2 Prevent access to the administrative interface from the internet3638no data