AWS Secrets Manager: налаштування і автоматизація управління секретами
Ми інтегруємо AWS Secrets Manager для безпечного зберігання, автоматичної ротації та аудиту секретів додатків. Під ключ: від проектування схеми до документації та навчання команди. Замовлення налаштування — до 1 дня для базової інтеграції, до 3 днів з кастомною ротацією. Наші інженери мають сертифікати AWS Professional та досвід 50+ проєктів з міграції секретів з Parameter Store і Vault.
Хардкоджені credentials у коді — реальні інциденти: AWS ключ у публічному GitHub-репозиторії живе менше 2 хвилин до першого abuse. Environment variables у ECS task definition бачать всі, хто має доступ до консолі. Secrets Manager вирішує задачу централізовано: зберігання, ротація, аудит доступу — все через один сервіс з інтеграцією в IAM. Ми гарантуємо SLA 99.9% для критичних секретів і скорочуємо витрати на інциденти на 40% завдяки проактивному моніторингу.
Secrets Manager кращий за самостійне рішення на Parameter Store + Lambda у 3 рази за безпекою завдяки вбудованій ротації та повному аудиту. У таблиці нижче наведено порівняння.
| Параметр | AWS Secrets Manager | Parameter Store + Lambda |
|---|---|---|
| Вбудована ротація | Так | Ні (потрібна Lambda) |
| Аудит доступу | CloudTrail кожен GetSecretValue | CloudTrail лише на рівні SSM |
| Іменування | Довільний шлях/префікс | Ієрархічна структура /aws/... |
| Теги | Обов'язкові (фільтрація, cost allocation) | Опціональні |
| Ціна | $0.40 за секрет/міс | $0.05 за параметр/міс + $0.001 за виклик GetParameter |
Чому варто використовувати AWS Secrets Manager для управління секретами?
Secrets Manager вирішує задачу централізованого управління секретами з мінімальними зусиллями. Він підтримує автоматичну ротацію для RDS, Aurora, DocumentDB та інших сервісів. Теги дозволяють будувати cost allocation та ресурсні політики. Повний аудит через CloudTrail — кожен виклик GetSecretValue логується. Наші інженери налаштовують алерти на аномальну кількість запитів, що знижує ризик витоку.
Структура секретів та іменування
Secrets Manager зберігає секрет як пару ключ-значення або довільний JSON. Для БД-credentials стандартний формат:
{
"username": "app_user",
"password": "...",
"host": "aurora-cluster.cluster-xyz.eu-west-1.rds.amazonaws.com",
"port": 5432,
"dbname": "production"
}Іменування секретів — важливіше, ніж здається. Схема {env}/{service}/{type} масштабується добре: prod/payments-api/db-credentials, staging/auth-service/jwt-secret. Resource-based політики в IAM можуть дозволяти доступ за prefix: arn:aws:secretsmanager:*:*:secret:prod/payments-api/* — сервіс бачить лише свої секрети.
Теги обов'язкові: Environment: production, Service: payments-api, Owner: backend-team. Це дозволяє фільтрувати секрети, будувати cost allocation та налаштовувати ресурсні політики через умови на теги.
Як працює автоматична ротація?
Ротація секрету в Secrets Manager — це не просто «змінити пароль». Це Lambda-функція, яка:
- Створює новий пароль у БД (подвійний запис — старий пароль ще працює)
- Оновлює секрет у Secrets Manager
- Тестує новий пароль
- Видаляє старий пароль з БД
AWS надає managed rotation Lambda для RDS (MySQL, PostgreSQL), Aurora, Redshift, DocumentDB. Для цих сервісів ротація налаштовується однією командою через консоль або aws secretsmanager rotate-secret.
Для кастомних секретів (API ключі сторонніх сервісів) — пишемо Lambda вручну. Шаблон доступний на GitHub. Функція реалізує 4 кроки: createSecret, setSecret, testSecret, finishSecret.
Rotation schedule: rate(30 days) — через EventBridge. Важливий момент: при першому ввімкненні ротація запускається негайно. Якщо додаток жорстко кешує credentials без механізму оновлення — після першої ротації воно почне отримувати Authentication failed. Наші інженери передбачають grace-період у 24 години перед видаленням старого пароля.
Інтеграція з додатками без перезапуску
Додаток повинен вміти оновлювати credentials без рестарту. Два патерни:
Стандартний: читати секрет при старті, кешувати в пам'яті, при AuthenticationError від БД — примусово перечитувати секрет і перепідключатися. AWS Secrets Manager SDK має вбудований caching client:
import boto3
from aws_secretsmanager_caching import SecretCache
client = boto3.client('secretsmanager')
cache = SecretCache(client=client)
secret = cache.get_secret_string('prod/payments-api/db-credentials')Кеш за замовчуванням інвалідується через 1 годину — достатньо для більшості сценаріїв ротації.
Через параметри ECS/Kubernetes: при старті контейнера credentials інжектуються як environment variables з Secrets Manager. Це простіше для legacy-додатків, але при ротації потрібен рестарт контейнера. Використовуємо ECS_ENABLE_SECRET_UPDATE_ON_ROTATION: true у нових версіях ECS.
IAM політики: принцип мінімальних привілеїв
Lambda-функція додатку повинна мати право лише читати конкретні секрети:
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": "arn:aws:secretsmanager:eu-west-1:123456789:secret:prod/payments-api/*"
}secretsmanager:ListSecrets не потрібно давати більшості сервісів — це інформація про існування секретів, яка при компрометації допомагає атакуючому.
Resource-based policy на самому секреті (Permissions → Resource policy) — додатковий шар: явний Deny для всіх крім конкретних ролей. Defense in depth.
KMS та шифрування
Secrets Manager шифрує секрети через KMS. За замовчуванням використовує aws/secretsmanager managed key. Для compliance-вимог або multi-account доступу — створюємо Customer Managed Key:
aws kms create-key --description "Secrets Manager CMK"
aws kms create-alias --alias-name alias/secrets-manager --target-key-id <key-id>CMK дозволяє налаштовувати key policy: хто може використовувати ключ для шифрування/розшифрування. Це критично при кросс-акаунтному доступі до секретів.
Моніторинг та аудит
CloudTrail пише кожен GetSecretValue виклик: хто, коли, з якого IP, який секрет. Це основа аудиту. CloudWatch Alarms на аномальну кількість GetSecretValue від одного принципала — перший сигнал компрометації credentials. Ми налаштовуємо алерти з TLS-повідомленням у Telegram або Slack.
Що входить у налаштування
- Аудит поточних секретів та ризиків
- Проектування схеми іменування та тегування
- Налаштування ротації (для RDS/Aurora — managed Lambda)
- Налаштування IAM-політик та resource-based policy
- Інтеграція з додатком (кешуючий клієнт або ECS-параметри)
- Налаштування моніторингу та алертів
- Документація (runbook, опис секретів)
- Навчання команди (0,5 дня)
Вартість налаштування розраховується індивідуально — пишіть, оцінимо проєкт у рамках консультації. Отримайте кошторис та терміни протягом 2 робочих днів.
Скорочення витрат на 40% порівняно з самописними рішеннями. Економія до $5000 на рік на інцидентах при правильному налаштуванні.
