Skip to main content

🛡️ Azure Non-RBAC Key Vault stores Secrets without expiration date🟢

  • Contextual name: 🛡️ Non-RBAC Key Vault stores Secrets without expiration date🟢
  • ID: /ce/ca/azure/key-vault/non-rbac-key-vault-secrets-expiration-date
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: SECURITY

Logic​

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-82ca41272

Description​

Open File

Description​

Ensure that all secrets in non-role-based access control (RBAC) Azure Key Vaults have an expiration date set.

Rationale​

The Azure Key Vault enables users to store and keep secrets within the Microsoft Azure environment. Secrets in the Azure Key Vault are octet sequences with a maximum size of 25k bytes each. The exp (expiration date) attribute identifies the expiration date on or after which the secret MUST NOT be used. By default, secrets never expire. It is recommended to rotate secrets in the Key Vault and set an explicit expiration date for all secrets. This ensures that the secrets cannot be used beyond their assigned lifetimes.

Impact​

Secrets cannot be used beyond their assigned expiration dates. Secrets must be rotated periodically wherever they are used.

Audit​

This policy flags an Azure Key Vault as INCOMPLIANT if any related Azure Key Vault Secret has an empty Expiration Date.

A Key Vault is marked as INAPPLICABLE if RBAC Authorization is set to Enabled.

Default Value​

... see more

Remediation​

Open File

Remediation​

From Azure Portal​

  1. Go to Key Vaults.
  2. For each Key Vault, select Secrets.
  3. In the main pane, ensure that the status of the secret is Enabled.
  4. Set an appropriate Expiration date on all secrets.

From Azure CLI​

Update the Expiration date for the secret using the following command. Use a UTC timestamp in ISO 8601 format.

az keyvault secret set-attributes \
    --name {{secret-name}} \
    --vault-name {{vault-name}} \
    --expires {{expiration-date-time-utc}}

Note: To view the expiration date on all secrets in a Key Vault using Microsoft API, the List permission for secrets is required.

To update the expiration date for the secrets:

  1. Go to the Key Vault and select Access policies.
  2. Click on Create and add an access policy with the Update permission (in the Secret Permissions - Secret Management Operations section).

From PowerShell​

For each Key Vault with the EnableRbacAuthorization setting set to False or empty, run the following command:

Set-AzKeyVaultSecret `

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

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 APRA CPG 234 → 💼 44c loss of, or unauthorised access to, encryption keys safeguarding extremely critical or sensitive information assets.810no 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
💼 APRA CPG 234 → 💼 d. predefined activation and deactivation dates for cryptographic keys, limiting the period of time they remain valid for use. The period of time a cryptographic key remains valid would be commensurate with the risk;34no data
💼 CIS Azure v5.0.0 → 💼 8.3.4 Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults (Automated)1no data
💼 Cloudaware Framework → 💼 Expiration Management15no data
💼 FedRAMP High Security Controls → 💼 AC-2(1) Automated System Account Management (M)(H)26no data
💼 FedRAMP High Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)61437no data
💼 FedRAMP High Security Controls → 💼 SC-12 Cryptographic Key Establishment and Management (L)(M)(H)1912no data
💼 FedRAMP Low Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)137no data
💼 FedRAMP Low Security Controls → 💼 SC-12 Cryptographic Key Establishment and Management (L)(M)(H)12no data
💼 FedRAMP Moderate Security Controls → 💼 AC-2(1) Automated System Account Management (M)(H)26no data
💼 FedRAMP Moderate Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)437no data
💼 FedRAMP Moderate Security Controls → 💼 SC-12 Cryptographic Key Establishment and Management (L)(M)(H)12no data
💼 ISO/IEC 27001:2013 → 💼 A.9.2.4 Management of secret authentication information of users810no data
💼 ISO/IEC 27001:2013 → 💼 A.10.1.2 Key management912no data
💼 ISO/IEC 27001:2022 → 💼 5.9 Inventory of information and36no data
💼 ISO/IEC 27001:2022 → 💼 5.10 Acceptable use of information and other associated assets1127no data
💼 ISO/IEC 27001:2022 → 💼 5.16 Identity management24no data
💼 ISO/IEC 27001:2022 → 💼 5.18 Access rights46no data
💼 ISO/IEC 27001:2022 → 💼 6.5 Responsibilities after termination or change of employment24no data
💼 ISO/IEC 27001:2022 → 💼 8.1 User end point devices813no data
💼 NIST CSF v1.1 → 💼 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes1934no data
💼 NIST CSF v1.1 → 💼 PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals' security and privacy risks and other organizational risks)1923no data
💼 NIST CSF v1.1 → 💼 PR.DS-1: Data-at-rest is protected1530no data
💼 NIST CSF v1.1 → 💼 PR.DS-2: Data-in-transit is protected1653no data
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization43no data
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated53no 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 SP 800-53 Revision 5 → 💼 AC-2(1) Account Management _ Automated System Account Management426no data
💼 SOC 2 → 💼 CC6.1-11 Protects Encryption Keys69no data