Секреты в разработке: хранение, доступ и ротация

Прямой ответ

Секреты хранятся в защищённом хранилище с ограниченным доступом, поэтому утечка ключа не приводит к компрометации всех окружений.

# Kubernetes Secret
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  database-password: <base64>

Хранилище секретов ограничивает доступ, поэтому ключ не попадает в систему контроля версий и не доступен всем разработчикам. Об управлении конфигурацией — в статье про управление конфигурацией.

Хранилища, доступ и ротация

Хранилище секретов определяет место хранения и способ доступа, поэтому ключ получается приложением без хранения в коде.

Хранилище. Секреты хранятся в защищённом хранилище, поэтому доступ к ним ограничивается настройкой прав.

Доступ. Приложение получает секрет при запуске, поэтому ключ не хранится в коде и не попадает в систему контроля версий.

Ротация. Ключ периодически меняется, поэтому компрометация старого ключа не даёт доступ к текущим данным.

Практическое следствие: секрет в коде попадает в систему контроля версий, поэтому доступ к нему получают все, кто имеет доступ к репозиторию.

Отдельный аспект — проверка утечек. Скан истории репозитория обнаруживает секреты, попавшие в коммиты, поэтому утечка выявляется до компрометации.

Три признака некорректного хранения секретов.

Секрет в коде. Ключ попадает в систему контроля версий, поэтому доступ к нему не ограничивается.

Отсутствие ротации. Ключ не меняется, поэтому компрометация даёт доступ на неопределённый срок.

Отсутствие проверки утечек. Секрет в истории репозитория не обнаруживается, поэтому утечка остаётся незамеченной.

О ротации ключей — в статье про ротацию ключей; о 12‑factor подходе — в статье про конфигурацию 12‑factor.

Проверка утечек и контроль доступа

Проверка истории репозитория обнаруживает секреты, попавшие в коммиты, поэтому утечка выявляется до компрометации.

Скан истории. Скан истории репозитория обнаруживает ключи, попавшие в коммиты, поэтому утечка выявляется.

Контроль доступа. Доступ к секретам ограничивается настройкой прав, поэтому не все разработчики получают ключ продакшена.

Фиксация получения. Запись получения секрета позволяет определить, кто и когда получил ключ.

Практическое следствие: отсутствие проверки утечек приводит к тому, что секрет в истории репозитория не обнаруживается.

Практика: настройка хранения секретов

1. Используйте защищённое хранилище. Доступ к секретам ограничивается настройкой прав, поэтому ключ не доступен всем.

2. Не храните секреты в коде. Ключ в коде попадает в систему контроля версий, поэтому доступ к нему не ограничивается.

3. Настройте ротацию ключей. Периодическая смена ключа ограничивает срок действия скомпрометированного ключа.

4. Проверяйте историю репозитория на утечки. Скан обнаруживает секреты, попавшие в коммиты, поэтому утечка выявляется.

5. Ограничивайте доступ к секретам продакшена. Доступ к ключам продакшена ограничивается, поэтому изменение выполняется контролируемо.

6. Фиксируйте получение секрета в логе. Запись получения позволяет определить, кто и когда получил ключ.

7. Разделяйте секреты по окружениям. Ключи разработки, тестирования и продакшена различаются, поэтому компрометация одного не затрагивает другие.

Рекомендации:

1. Не храните секреты в файле конфигурации. Секреты в файле попадают в систему контроля версий, поэтому доступ к ним не ограничивается.
2. Учитывайте ротацию при планировании. Периодическая смена ключа требует настройки, поэтому компрометация ограничивается сроком.
3. Сопоставляйте доступ с ролью. Доступ к секрету определяется ролью, поэтому не все разработчики получают ключ продакшена.
4. Фиксируйте получение секрета в ошибке. Признак в записи ошибки позволяет определить, кто получил ключ.
5. Пересматриваем доступ при изменении команды. Новый разработчик требует настройки прав доступа к секретам.

Практический сценарий: секрет попал в историю репозитория

Контекст: проверка истории репозитория обнаружила ключ в коммите, поэтому доступ к нему получили все, кто имеет доступ к репозиторию.

1. Диагностика. Скан истории репозитория показал, что ключ был добавлен в файл конфигурации и попал в коммит. Файл был удалён в последующем коммите, но ключ остался в истории, поэтому доступ к нему сохранился.
2. Причина. Секрет хранился в файле конфигурации, который попал в систему контроля версий, поэтому ключ стал доступен всем.
3. Действия. (а) Сменили скомпрометированный ключ, чтобы ограничить срок действия; (б) перенесли секрет в защищённое хранилище, чтобы ключ не попадал в репозиторий; (в) настроили проверку истории репозитория на утечки, чтобы обнаруживать секреты в коммитах; (г) ограничили доступ к секретам продакшена, чтобы не все разработчики получали ключ; (д) настроили ротацию ключей, чтобы компрометация ограничивалась сроком.
4. Результат. Секреты хранятся в защищённом хранилище, поэтому доступ к ним ограничивается настройкой прав.

Вывод: секрет в файле конфигурации попадает в систему контроля версий, поэтому доступ к нему получают все, кто имеет доступ к репозиторию. Хранение в защищённом хранилище и проверка истории репозитория обеспечивают контроль доступа.

Практический сценарий: секрет попал в историю репозитория

Контекст: проверка истории репозитория обнаружила ключ в коммите, поэтому доступ к нему получили все, кто имеет доступ к репозиторию.

1. Диагностика. Скан истории репозитория показал, что ключ был добавлен в файл конфигурации и попал в коммит. Файл был удалён в последующем коммите, но ключ остался в истории, поэтому доступ к нему сохранился.
2. Причина. Секрет хранился в файле конфигурации, который попал в систему контроля версий, поэтому ключ стал доступен всем.
3. Действия. (а) Сменили скомпрометированный ключ, чтобы ограничить срок действия; (б) перенесли секрет в защищённое хранилище, чтобы ключ не попадал в репозиторий; (в) настроили проверку истории репозитория на утечки, чтобы обнаруживать секреты в коммитах; (г) ограничили доступ к секретам продакшена, чтобы не все разработчики получали ключ; (д) настроили ротацию ключей, чтобы компрометация ограничивалась сроком.
4. Результат. Секреты хранятся в защищённом хранилище, поэтому доступ к ним ограничивается настройкой прав.

Вывод: секрет в файле конфигурации попадает в систему контроля версий, поэтому доступ к нему получают все, кто имеет доступ к репозиторию. Хранение в защищённом хранилище и проверка истории репозитория обеспечивают контроль доступа.

FAQ

Где хранить секреты в разработке? В защищённом хранилище с ограниченным доступом. Секрет в коде попадает в систему контроля версий, поэтому доступ к нему не ограничивается.

Зачем нужна ротация ключей? Периодическая смена ключа ограничивает срок действия скомпрометированного ключа, поэтому компрометация не даёт доступ на неопределённый срок.

Как проверяются утечки секретов? Скан истории репозитория обнаруживает секреты, попавшие в коммиты. Проверка выполняется периодически, поэтому утечка выявляется до компрометации.

Как ограничивается доступ к секретам? Через настройку прав в хранилище. Доступ к секрету определяется ролью, поэтому не все разработчики получают ключ продакшена.

Источники: HashiCorp Vault, Kubernetes Secrets, 12factor.net — ссылки в шапке.