Управление секретами и безопасное хранение конфигурации

Hardcoded passwords, API keys, and tokens are one of the most common security misconfigurations. Once a secret lands in source control, it must be considered compromised forever.

This lesson covers how to keep secrets out of code and store configuration safely.

The first rule: secrets never live in your repository. Use a .gitignore to exclude files like .env, and prefer injected configuration over baked-in values.

• No passwords in source code
• No keys in config files committed to git
• No secrets in container images

Environment variables are the simplest way to inject secrets at runtime. The application reads them from the process environment instead of a tracked file.

Env vars are better than hardcoding but have weaknesses: they can leak through crash dumps, child processes, debug endpoints, and logging of the whole environment.

For high-value secrets, prefer a dedicated secrets manager.

Tools like HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault store secrets encrypted at rest, control access via fine-grained policies, and provide an audit trail of every read.

• Centralized storage with access control
• Automatic encryption at rest and in transit
• Audit logs of who fetched what and when

Applications request secrets at startup using a short-lived identity token instead of a static key.

Rotation means changing secrets regularly and immediately after suspected exposure. Short-lived, automatically rotated credentials limit the window an attacker can use a stolen key.

Design apps to reload credentials without a full restart so rotation is painless.

Each service should only be able to read the secrets it needs. Scope vault policies and cloud IAM roles tightly so a compromised service cannot harvest unrelated credentials.

Use secret-scanning tools in CI to block commits that contain credential patterns. Catching a leak before it merges is far cheaper than rotating after exposure.

When config must be stored as files, encrypt them. Tools like SOPS or sealed-secrets let you commit encrypted values safely, decrypting only at deploy time with a managed key.

• Encrypt before storing
• Keep the decryption key in a managed KMS
• Never store the key alongside the data

Log and review every secret access. Anomalies, like a service reading a secret it never used before, are strong indicators of compromise and feed your monitoring pipeline.

You learned to keep secrets out of code, inject them via env vars or a vault, apply rotation and least privilege, scan for leaks in CI, and audit every access. Proper secrets management closes one of the biggest misconfiguration gaps in backend systems.