2.3 KiB
2.3 KiB
Secrets & Key Management Guidance
Document owner: [Owner/Role]
Approved by: [Steering Committee / CISO]
Effective date: [YYYY-MM-DD]
Review cadence: [Annually]
1. Purpose & Scope
Implementation guidance for the Secrets & Key Management Policy. Applies to engineering, IT/IAM, and system owners.
2. Approved Tooling Patterns
- Cloud-native: Azure Key Vault, AWS Secrets Manager/KMS, GCP Secret Manager — prefer platform-native over a bolted-on third party where the platform is already the trust boundary.
- Self-hosted/hybrid: HashiCorp Vault with auto-unseal via cloud KMS.
- CI/CD: Secrets injected at runtime via OIDC federation (no long-lived cloud credentials stored in the CI system) — see OWASP Secrets Management Cheat Sheet.
3. Split-Knowledge — How To (Kill-Chain Secrets)
Practical patterns for §2.5:
- Shamir's Secret Sharing (e.g., via HSM or
ssss) to split a root key across ≥3 custodians with a quorum (e.g., 2-of-3) to reconstruct. - Two named custodians each hold half a passphrase; both required to unseal.
- HSM-native M-of-N key ceremony (common for PKI root CA generation) — documented, witnessed, and recorded.
4. Secret Scanning
- Enable pre-commit and CI-time secret scanning (e.g., gitleaks, trufflehog, or platform-native scanning) on every repository.
- A detected secret must be rotated immediately, even if the commit is reverted — git history retains it.
5. Rotation Automation Checklist
✅ Service account secrets rotate automatically every ≤90 days, no manual step.
✅ TLS certificates auto-renew (ACME/cert-manager or equivalent) with alerting on renewal failure.
✅ Kill-chain secrets have a calendar-enforced annual rotation with two-person sign-off.
✅ Secret manager audit log retained and reviewed — see also Password Guidance §2.2 for blocklist/rotation cadence context.