Edit

Best practices for protecting secrets

This article provides guidance for protecting secrets and reducing the risk of unauthorized access. Follow this guidance to help ensure that you do not store sensitive information, such as credentials, in code, GitHub repositories, logs, or continuous integration/continuous deployment (CI/CD) pipelines. The guidance in this article comes from individual service recommendations and the Microsoft Cloud Security Benchmark (MCSB).

This article aligns with Microsoft's Zero Trust security model, which requires explicit verification, least-privilege access, and the assumption of breach. For prescriptive security controls that include Azure Policy enforcement, see Microsoft Cloud Security Benchmark v2: Privileged Access and MCSB v2: Data Protection.

Secret discovery and prevention

Before you can secure your secrets, you need visibility into where they exist. You also need controls that prevent exposure before it occurs.

  • Conduct an audit to identify secrets: Audit your systems and applications to identify sensitive information that needs protection, such as passwords, API keys, connection strings, and other credentials. Regular audits help ensure that new secrets are accounted for and that existing secrets are properly managed. Safeguard dynamically created secrets, such as temporary OAuth tokens, with the same rigor as long-term secrets.

  • Avoid hardcoding secrets: Embedding secrets directly into code or configuration files creates a significant security risk. If your codebase is compromised, your secrets are also compromised. Instead, use environment variables or configuration management tools that keep secrets out of source code. This practice minimizes the risk of accidental exposure and simplifies secret updates. Integrate secret retrieval into your automated deployment pipeline, and use secret injection patterns to help prevent accidental exposure in logs or version control. For more information, see Recommendations for protecting application secrets.

  • Implement secret scanning tools: Regularly scan your codebase for embedded secrets to help prevent accidental exposure. Tools such as Azure DevOps Credential Scanner and GitHub secret scanning can automatically detect and alert you to secrets in repositories. Integrate these tools into your CI/CD pipeline for continuous monitoring. Treat any secret found by scanning tools as compromised. Immediately revoke and replace it to maintain the integrity of your security posture.

Secure storage and encryption

Protecting secrets requires secure storage mechanisms and proper encryption at all stages.

  • Use secure key stores: Services such as Azure Key Vault and Azure Key Vault Managed HSM provide robust security features, including access control, logging, and automatic rotation. This approach centralizes secret management and reduces the risk of unauthorized access. For highly sensitive or critical secrets, use a hardware security module (HSM)-backed key store for enhanced protection compared to software-based secret stores. For customer-managed key scenarios, use the Azure Key Vault Premium tier, which is HSM-backed, at minimum. Use Azure Key Vault Managed HSM for key sovereignty requirements. For an overview of Azure key management offerings and guidance on which to choose, see Key management in Azure and How to choose the right key management solution.

  • Encrypt secrets at rest and in transit: Azure Key Vault securely stores secrets through envelope encryption, where data encryption keys are encrypted by key encryption keys to provide another layer of security. Use secure communication protocols such as HTTPS to encrypt data in transit between your applications and the key vault. In Azure, encryption at rest is implemented across various services by using AES 256 encryption. Data in transit is secured through TLS and MACsec. For more information, see Encryption at rest and in transit.

  • Implement network isolation: Configure firewalls and network security groups to restrict access to your key vaults. Allow only trusted applications and services to access your secrets. This approach minimizes the attack surface and helps prevent unauthorized access. Consider using multiple key vaults to create isolation boundaries for different components. If one component is compromised, the component cannot gain control of other secrets or the entire workload.

Access control and identity

Managing who and what can access secrets is critical for maintaining security.

  • Use managed identities: Managed identities in Azure provide a secure way for applications to authenticate to Azure services without storing credentials in code. Enable managed identities for Azure resources to securely access Azure Key Vault and other services, reducing the need to handle secrets manually. This approach minimizes secret creation and reduces the surface area for potential breaches because the platform manages the credentials.

  • Apply granular access control: Follow the principle of least privilege by applying granular access control to your secrets. Use Azure role-based access control (Azure RBAC) to ensure that only authorized entities have access to specific secrets. Regularly review and update access permissions to prevent unauthorized access. Implement distinct roles such as user, administrator, and auditor to manage access to secrets. This practice helps ensure that only trusted identities have the appropriate level of permission. For more information, see the Azure Key Vault RBAC guide.

Secret lifecycle management

Secrets require ongoing management throughout their lifecycle, from creation to retirement.

  • Rotate secrets regularly: Secrets are susceptible to leakage or exposure over time. Regularly rotate your secrets to reduce the risk of unauthorized access. You can rotate secrets in Azure Key Vault for certain secrets. For secrets that cannot be automatically rotated, establish a manual rotation process and ensure that they are purged when they are no longer in use. Automate secret rotation and build redundancy into your secret management to help ensure that rotation does not disrupt service availability. Implement retry logic and concurrent access patterns in your code to help minimize issues during the rotation window.

  • Distribute secrets safely: When you distribute secrets, share them securely within and outside the organization. Use tools designed for secure sharing, and include secret recovery procedures in your disaster recovery plans. If a key is compromised or leaked, regenerate it immediately. Use distinct keys for each consumer rather than sharing keys, even if consumers have similar access patterns. This practice simplifies key management and revocation, ensuring that compromised keys can be revoked without affecting other consumers.

Monitoring and logging

Continuous monitoring enables detection of suspicious activity and supports compliance requirements.

  • Monitor and log access: Enable logging and monitoring for your secret management system to track access and usage. Use Key Vault logging, Azure Monitor, or Azure Event Grid to monitor all activities related to your secrets. Monitoring provides visibility into who accessed your secrets and helps detect suspicious behavior or potential security incidents. Maintain detailed audit trails for inspecting and validating access to secrets, which can help prevent identity theft, avoid repudiation, and reduce unnecessary exposure.

Service-specific guidance for secrets handling

Individual services may have additional best practices and guidance for protecting secrets. Here are some examples:

Next steps

Minimizing security risk is a shared responsibility. Proactively take steps to secure your workloads. For more information, see Shared responsibility in the cloud.

  • Last updated on