Avoiding Leaks: Secure Key Rotation and Access Controls

Secure Keys: A Practical Guide for Developers

What “secure keys” means

Secure keys are cryptographic secrets (API keys, SSH keys, TLS private keys, encryption keys, signing keys) used to authenticate, encrypt, or sign data. Protecting them prevents unauthorized access, data leaks, impersonation, and supply-chain attacks.

Threats to watch for

• Accidental exposure (commits, logs, config files)
• Improper storage (plain text, shared drives)
• Insecure transmission (email, unencrypted channels)
• Insufficient access control (overbroad permissions)
• No rotation or revocation (stale keys after device loss)
• Weak generation (predictable or low-entropy keys)

Principles to follow

1. Least privilege: Keys should grant only required permissions and scope.
2. Separation of duties: Use different keys for different roles/environments.
3. Rotation and revocation: Rotate regularly and have revocation procedures.
4. Defense in depth: Combine encryption, access control, auditing, and network controls.
5. Auditability: Log key creation, usage, rotation, and revocation events.
6. Automation: Automate provisioning, rotation, and secret injection to reduce human error.

Practical steps for developers

1. Generate keys securely
   • Use OS or library cryptographic RNG (e.g., libsodium, OpenSSL, platform KDFs).
   • Prefer modern algorithms (e.g., AEAD ciphers, Ed25519, ECDSA with recommended curves).
2. Never store in source control
   • Use .gitignore, pre-commit hooks, and secret scanning tools (Git hooks, GitGuardian, truffleHog).
3. Use a secrets manager
   • Centralize secrets in vaults (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager).
   • Enforce access policies and audit logs.
4. Inject secrets at runtime
   • Use environment variables via secure pipelines, sidecar containers, or cloud provider secret mounts.
5. Protect keys at rest
   • Encrypt keys using KMS-backed wrapping keys; store only ciphertext in persistent storage.
6. Limit scope and lifetime
   • Create short-lived tokens where possible (STS tokens, OAuth access tokens).
7. Use hardware-backed protection
   • Leverage HSMs or cloud KMS with hardware protection for high-value keys.
8. Implement strong access controls
   • Use IAM roles, least privilege, multi-factor authentication for key management consoles.
9. Monitor and alert
   • Detect anomalous key use (geolocation anomalies, unusual client IDs) and alert/rotate on suspicious activity.
10. Plan for compromise
    • Maintain an incident playbook: identify affected keys, revoke, rotate, notify stakeholders, and root-cause fix.

Example workflow (CI/CD + runtime)

• Developer requests secret via internal approval.
• Secrets manager creates a short-lived secret and records audit entry.
• CI pulls secret at build/deploy time using an ephemeral credential (OIDC or service principal).
• Deployed app retrieves secret at startup from the secrets manager or via mounted volume.
• Rotation automated monthly or on-demand; old credentials revoked immediately.

Common pitfalls and fixes

• Pitfall: embedding keys in config files. Fix: move to secrets manager and inject at runtime.
• Pitfall: long-lived service account keys. Fix: use short-lived tokens and role-assumption.
• Pitfall: overbroad key permissions. Fix: split roles and apply least privilege.

Quick checklist before production

• Keys generated with secure RNG and algorithms
• Secrets manager in place with audit logs
• No secrets in source control or build artifacts
• Short-lived credentials where possible
• Automated rotation and emergency revocation process
• Monitoring and alerting for anomalous use

Further reading (recommended)

• NIST SP 800-57 (key management)
• Cloud provider KMS docs (AWS, GCP, Azure)
• HashiCorp Vault best practices