5.5 KiB
Secrets & Key Management Policy
Document owner: [Owner/Role]
Approved by: [Steering Committee / CISO]
Effective date: [YYYY-MM-DD]
Review cadence: [Annually]
1. Purpose & Scope
This policy establishes mandatory requirements for the generation, storage, access, rotation, and retirement of secrets and cryptographic keys — API keys, service credentials, TLS certificates, encryption keys, and signing keys — across [Organization] systems. It applies to all employees, contractors, and systems that create or consume secrets.
This policy is the canonical source for cryptographic algorithm/parameter standards and kill-chain secret handling referenced elsewhere in this repository (e.g., Password Policy §2.13, Password Policy (M365/AD) §2.13).
2. Policy Statements
2.1 Secret Inventory & Ownership
- Every secret must have a named owner and a documented purpose.
- An inventory of active secrets must be maintained in the approved secret manager; secrets with no identifiable owner must be rotated and reassigned or retired within 30 days of discovery.
2.2 Storage
- Secrets must be stored only in an approved secret manager, key vault, or HSM.
- Secrets must not be stored in source code, config files committed to version control, tickets, chat messages, or shared documents.
- Any secret found outside an approved store must be treated as compromised: rotated immediately, not just relocated.
2.3 Cryptographic Standards
| Purpose | Approved | Minimum Parameters |
|---|---|---|
| Password hashing | Argon2id (preferred), bcrypt, PBKDF2 | Argon2id: memory ≥19 MiB, iterations ≥2; per-credential unique salt ≥128 bits |
| Symmetric encryption at rest | AES-256-GCM | Unique IV/nonce per operation |
| Transport encryption | TLS 1.2 minimum, TLS 1.3 preferred | Modern cipher suites only; disable TLS 1.0/1.1 |
| Asymmetric keys | RSA ≥3072-bit, ECDSA P-256 or higher | — |
| Signing | Ed25519 or ECDSA P-256+ | — |
| Legacy/weak algorithms (MD5, SHA-1 for integrity, DES/3DES, RC4, NTLMv1) | Prohibited for new use; existing use tracked as a remediation item | — |
2.4 Access Control
- Access to secrets must follow least privilege and, where supported, just-in-time elevation.
- All secret retrieval must be logged (who, what, when).
- Human access to production secrets should be exceptional and time-bound; services must authenticate via managed identity/certificate rather than a retrieved static secret where the platform supports it.
2.5 Kill-Chain Secrets (Barbell Principle)
Secrets gating existential systems — PKI/CA root passphrases, backup/DR encryption master keys, break-glass vault master credentials, HSM activation secrets — must receive protection disproportionate to ordinary secrets:
- Split-knowledge / dual control: no single person holds the complete secret.
- Physical or HSM-backed storage, not a general-purpose secret manager.
- Real-time alerting on access; access requires a second approver.
- Do not spread equivalent extra effort across low-value secrets — concentrate paranoia here; keep §2.2–§2.4 lean everywhere else.
2.6 Rotation & Expiry
| Secret Type | Rotation Cadence |
|---|---|
| Human-facing passwords | Incident-driven only (no scheduled expiry, per Password Policy §2.3) |
| Service account secrets / API keys | Automated, ≤90 days |
| TLS certificates | Before expiry, automated renewal preferred |
| Kill-chain secrets (§2.5) | Annually, or immediately after any custodian change |
| Any secret suspected compromised | Immediately |
2.7 Secret Compromise Response
- A suspected or confirmed secret compromise must trigger immediate rotation, revocation of derived sessions/tokens, and a structural post-mortem per Authentication Policy §2.12.
2.8 Enforcement
- Violations may result in disciplinary action or revocation of access.
- Secrets discovered in version control history must be rotated even after removal from the current commit — history does not un-leak a secret.
3. Antifragility Alignment
This policy is built to the five pillars of the organization's internal Antifragile Enterprise Manifest.
| Pillar | Applied In | How |
|---|---|---|
| 1. Structural Decoupling | §2.4 | Services authenticate via managed identity/certificate rather than a portable static secret where possible — removes a class of dependency entirely |
| 2. Optionality Preservation | §2.3 | Standardized, non-proprietary algorithms (AES, Argon2id, ECDSA) avoid lock-in to a single vendor's crypto scheme |
| 3. Stress-to-Signal Conversion | §2.7 | Every compromised secret forces a structural post-mortem, not just a quiet rotation |
| 4. Sovereign Intelligence | §2.1 | Named owner per secret; inventory is owned and current, not tribal knowledge of "whoever set it up" |
| 5. Asymmetric Payoff Design (Barbell) | §2.5 | Split-knowledge/HSM concentrated on kill-chain secrets; ordinary secrets get the lean baseline — nothing moderate spread everywhere |