Рекомендации по обеспечению безопасности ключей

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

Общие рекомендацииОбщие рекомендации

1. Обеспечьте безопасное хранение ключей. Не сохраняйте ключи в коде, конфигурационных файлах или базе знаний.
2. Ограничьте доступ к ключам до необходимого минимума сотрудников.
3. Заводите для нового подрядчика отдельную точку интеграции. Если это невозможно, заведите подрядчику индивидуальный ключ.
4. Заведите реестр ключей. В реестре важно указать информацию:
   • ID ключа. Именно идентификатор ключа, по которому можно определить ключ, а не сам ключ;
   • Владелец ключа. Рекомендуем указывать двух ответственных (основной владелец и резервный);
   • Контакты владельца ключа;
   • Где используется ключ;
   • Дата генерации ключа;
   • Срок действия ключа;
5. Введите процесс контроля смены должности или увольнения сотрудников/подрядчиков, имеющих доступ к ключу. Важно производить ротацию ключа при увольнении сотрудника/подрядчика, имеющего доступ к ключу.
6. Передавайте ключи с помощью специальных сервисов хранения секретов — менеджеров секретов.
7. Если передаете ключи по открытым каналам (например, через email), используйте зашифрованный архив. Пароль от архива передавайте другим каналом (например, в мессенджере). Архив можно отправить на нескольких получателей, а пароль передать только одному человеку. Таким способом можно разграничить ответственность в команде.

Процесс смены ключаПроцесс смены ключа

Как поменять секретный ключ в точке интеграции — рассказываем в инструкции.

В каждой точке интеграции на замену каждому ротируемому ключу необходимо добавить новый ключ. У одной точки интеграции может быть несколько ключей.

После создания нового ключа:

1. Новый ключ отправляется подрядчику.
2. ID нового ключа (открытые данные) вносятся в реестр.
3. У ID старого ключа ставится пометка, что ключ находится в стадии блокировки.
4. Определяется срок, в течение которого ключ будет заменен подрядчиком.
5. Подрядчик тестирует вызовы с новым ключом:
   • Заказчик убеждается, что вызовы с новым ключом обрабатываются: ключ передан верно, настройки в Mindbox внесены корректно.
   • Если вызовы не проходят — заказчик проверяет настройки ключа (при необходимости подключает менеджера Mindbox). Повторяется тест ключа.
6. При приближении истечения срока замены заказчик проверяет логи интеграции по старому и новому ID ключей:
   • Появились ли вызовы с новым ключом?
     • Нет → ротация не состоялась. Нужно убедится, что запросы с новым ключом попадают в логи интеграции.
   • Остались ли вызовы со старым ключом?
     • Да → ротация не состоялась. Нужно убедиться, что вызовы со старым ключом больше не приходят.
     • Нет → можно считать, что ротация состоялась. Некоторые операции могут вызываться редко, поэтому стоит дополнительно перепроверять, не осталось ли старых вызовов.
7. После того, как ротация состоялась, старый ключ блокируется и вносится запись в реестр, что ключ заблокирован.