Цель модуля
Научить разработчика хранить и использовать секреты так, чтобы они не попадали в хранилище кода, историю изменений, журналы и переписку, и действовать по правильному порядку при утечке секрета.
Что считается секретом
- пароли учётных записей служб и баз данных;
- ключи доступа к внешним службам и облачным хранилищам;
- маркеры доступа к средствам разработки и сборочным системам;
- строки подключения, содержащие пароль;
- закрытые ключи подписи и сертификаты;
- файлы настроек промышленной среды с учётными данными.
Почему секрет нельзя фиксировать в хранилище кода
История изменений хранится целиком и почти всегда доступна шире, чем текущая версия: к ней имеют доступ все, у кого есть копия хранилища, включая бывших работников, подрядчиков и внешние сборочные системы. Даже если удалить строку новым изменением, прежнее значение остаётся в истории и извлекается одной командой.
Секрет, попавший в хранилище, нельзя считать тайной. Единственный правильный выход — считать его раскрытым и заменить.
Как работать с секретами правильно
- Храните секреты в отдельной службе управления секретами или в переменных окружения, которые подставляются при запуске.
- Выдавайте каждому приложению и каждому разработчику собственный секрет: общий секрет нельзя отозвать точечно.
- Ограничивайте срок жизни секрета и меняйте его по расписанию.
- Разделяйте секреты сред: ключ от промышленной среды не используется на тестовой и наоборот.
- Не выводите секреты в журналы и сообщения об ошибке, маскируйте значения перед записью.
- Добавьте защитный список в настройках хранилища кода, чтобы файлы настроек и ключи не загружались по невнимательности.
Типовые ошибки
- Файл настроек с паролем загружен в хранилище «на минуту» и удалён новым изменением — значение осталось в истории.
- Один общий секрет на все среды и на всех разработчиков.
- Секрет передан в переписке или в задаче системы учёта.
- Значение секрета попало в журнал сборки или в текст исключения.
- Личный ключ без парольной защиты лежит на рабочей машине в открытом виде.
- Секрет вставлен в пример кода или в учебную документацию продукта.
Если секрет раскрыт
- Немедленно сообщите руководителю и в службу информационной безопасности.
- Замените секрет: сначала выпустите новый, затем отзовите старый после переключения служб.
- Проверьте журналы работы службы на обращения с этим секретом за период, пока он был доступен.
- Убедитесь, что значение удалено из переменных, настроек, журналов сборки и переписки.
- Зафиксируйте случай в журнале происшествий: повторяющиеся причины устраняются отдельной задачей.
Проверочный список перед выходом на работу
- В коде, настройках и документации нет значений секретов.
- Секреты берутся из службы управления секретами или переменных окружения.
- Для каждой среды и каждого приложения используется отдельный секрет.
- Секреты не выводятся в журналы и сообщения об ошибке.
- В хранилище кода включён запрет на загрузку файлов с секретами.
- Порядок замены раскрытого секрета известен и проверен.
Вопросы для самопроверки
- Разработчик удалил файл с паролем следующим изменением. Секрет в безопасности? Нет. Значение остаётся в истории хранилища, поэтому секрет считается раскрытым и подлежит замене.
- Почему общий секрет на всех разработчиков — плохо? Его нельзя отозвать у одного человека; при уходе сотрудника приходится менять ключ у всех и во всех службах.
- Чем опасен вывод секрета в журнал? Журналы читает широкий круг специалистов, они копируются и хранятся дольше, чем нужен сам секрет.
Основание и что делать при сомнении
Модуль опирается на: ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения», приказ ФСТЭК России от 11.02.2013 № 17.
Если ситуация не описана в модуле и вы не уверены в правильном действии, не принимайте решение самостоятельно: обратитесь к руководителю и в службу информационной безопасности до того, как выполнить операцию с данными или доступами.