4.8 Криптография и управление ключами

Обзор и мотивация

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

Эта глава написана для инженеров, которые не криптографы, а это почти все мы. Вам нужно достаточно понимания, чтобы делать здравые выборы, знать, что гарантирует каждый инструмент, и избегать ошибок, превращающих сильные алгоритмы в ложное утешение. Глава 4.3 (безопасность инфраструктуры и облака) упоминает шифрование и управление ключами мимоходом; здесь мы идём глубже в то, что шифровать, как и как вести жизненный цикл ключей, делающий это реальным.

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

Ключевые принципы

Не пишите собственную криптографию. Используйте проверенные, широко рецензируемые библиотеки и стандартные алгоритмы. Новые схемы отказывают способами, которые ловят только эксперты.
Алгоритмы лёгкая часть; ключи трудная часть. Жизненный цикл ключа то, где живёт большинство реальных отказов.
Знайте, что гарантирует каждый примитив. Конфиденциальность, целостность и подлинность разные свойства, требующие разных инструментов.
Шифруйте при передаче и в покое по умолчанию. Делайте защиту стандартом, а не выбором.
Разделяйте хранение ключей и доступ к данным. Тот, кто управляет ключом, не должен автоматически мочь читать защищаемые им данные.
Планируйте изменения. Алгоритмы слабеют, ключи утекают, стандарты эволюционируют. Стройте под ротацию и миграцию с первого дня.
Предпочитайте валидированные реализации там, где это важно. Для регулируемой и государственной работы выбирайте модули с признанной валидацией.

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

Не пишите собственную криптографию

Это золотое правило, и его стоит назвать первым. Никогда не проектируйте собственный алгоритм шифрования, не изобретайте собственный протокол и не реализуйте вручную примитив из статьи. Рабочая криптография выглядит просто и скрывает тонкие режимы отказа (побочные каналы по времени, оракулы дополнения, слабая случайность), которые выживают только годы экспертной рецензии. Используйте устоявшиеся библиотеки, такие как стандартный криптомодуль вашей платформы или уважаемая библиотека, и используйте их на наивысшем доступном уровне абстракции. Тянитесь к режимам аутентифицированного шифрования и «лёгким» интерфейсам, делающим безопасный выбор значением по умолчанию, а не собирайте низкоуровневые части сами.

Подбирайте примитив под нужную гарантию

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

Криптография с симметричным ключом использует один общий секретный ключ и для шифрования, и для расшифровки. Она быстра и защищает конфиденциальность, но обе стороны уже должны делить ключ. Стандартная рабочая лошадка AES.
Криптография с открытым ключом использует математически связанную пару ключей: открытый ключ, который может держать любой, и закрытый, который вы храните в секрете. Она решает распределение ключей и позволяет цифровые подписи, доказывающие подлинность (кто отправил) и целостность (что не изменено).
Криптографическая хэш-функция производит отпечаток данных фиксированного размера и обеспечивает проверку целостности. Хэширование односторонне и не шифрование. Для хранения паролей используйте медленную хэш-функцию паролей с солью, никогда простой быстрый хэш (см. главу 4.2 о безопасности приложений).

Практический урок: шифрование скрывает данные, но не доказывает, кто их отправил, а хэш обнаруживает подмену, но ничего не скрывает. Большинство реальных систем сочетают их, именно поэтому стоит опираться на библиотеки, правильно собирающие это вместе.

Шифруйте при передаче текущим TLS

Защищайте каждый сетевой переход безопасностью транспортного уровня (TLS), протоколом, защищающим данные при их движении между системами. Требуйте современные версии TLS, отключайте устаревшие, выбирайте сильные наборы шифров и правильно проверяйте сертификаты, а не отключайте проверки, «чтобы заработало». Шифруйте и внутренний трафик между сервисами, а не только публичный край, потому что позиция нулевого доверия предполагает враждебность внутренней сети. Автоматизируйте выпуск и продление сертификатов, чтобы TLS был лёгким значением по умолчанию повсюду.

Шифруйте в покое конвертным шифрованием

Шифруйте хранимые данные по умолчанию: базы данных, объектное хранилище, резервные копии и журналы. Стандартный шаблон конвертное шифрование (envelope encryption), когда ключ шифрования данных (DEK) шифрует сами данные, а ключ шифрования ключей (KEK), хранимый в службе управления ключами, шифрует DEK. Это позволяет ротировать главный ключ, не перешифровывая терабайты данных, и держит мощный корневой ключ внутри укреплённой границы. Храните рядом с данными только обёрнутый DEK и получайте и разворачивайте его во время использования.

Ведите жизненный цикл ключей намеренно

Жизненный цикл ключа по-настоящему трудная часть криптографии и то место, откуда исходит большинство взломов и отказов. Управляйте каждой стадией намеренно:

Генерация: создавайте ключи из сильного источника случайности соответствующей стойкости.
Распространение: доставляйте ключи системам, которым они нужны, не раскрывая их в коде, файлах конфигурации или чате.
Ротация: заменяйте ключи по расписанию и умейте быстро ротировать при подозрении на компрометацию.
Отзыв: быстро аннулируйте скомпрометированный ключ или сертификат и убедитесь, что системы соблюдают отзыв.
Уничтожение: безопасно выводите старый ключевой материал так, чтобы его нельзя было восстановить.

Используйте службу управления ключами (KMS) для централизации этого и используйте аппаратный модуль безопасности (HSM), защищённое от вскрытия устройство, генерирующее и охраняющее ключи так, что они никогда не покидают его открытым текстом, для ключей наивысшей гарантии. Разделяйте тех, кто может управлять ключами, и тех, кто может читать защищаемые данные, чтобы хранение ключей принуждало к разделению обязанностей. Это прямо связано с классификацией данных и правилами хранения в главе 4.5 (приватность и защита данных).

Различайте управление секретами и управление ключами

Они пересекаются, но не одно и то же. Управление ключами управляет криптографическими ключами и их жизненным циклом, обычно внутри KMS или HSM, выполняющего криптографические операции за вас, чтобы сырой ключ никогда не уходил. Управление секретами управляет учётными данными приложений (пароли баз данных, токены API, сертификаты), которые сервисам нужно получать и использовать открытым текстом, обычно из хранилища секретов с краткоживущим проверяемым доступом. Используйте KMS для ключей, менеджер секретов для учётных данных и никогда не вставляйте ни то, ни другое в исходный код или файлы среды, помещённые под контроль версий.

Автоматизируйте PKI и жизненные циклы сертификатов

Инфраструктура открытых ключей (PKI) это система центров сертификации, сертификатов и цепочек доверия, привязывающая открытые ключи к идентичностям. В масштабе доминирующий риск PKI неожиданное истечение сертификата, выводящее сервис из строя. Ведите опись каждого сертификата, мониторьте истечения и автоматизируйте выпуск и продление, чтобы никому не приходилось помнить. Краткоживущие автоматически продлеваемые сертификаты безопаснее долгоживущих, выхаживаемых вручную, потому что автоматизация убирает человеческую единую точку отказа. Стандартные протоколы здесь поддерживают совместимость между поставщиками (глава 3.8 о совместимости и открытых стандартах).

Стройте под криптографическую гибкость и постквантовую миграцию

Алгоритмы со временем слабеют, а стандарты движутся. Криптографическая гибкость (agility) означает проектирование систем так, чтобы можно было менять алгоритмы и размеры ключей без болезненной переписи: абстрагируйте криптографию за небольшим интерфейсом, версионируйте ваши шифрованные данные, чтобы знать, какой алгоритм их произвёл, и ведите криптографическую опись того, что вы где используете. Это важно сейчас из-за постквантовой криптографии, нового семейства алгоритмов, разработанных для устойчивости к будущим квантовым компьютерам. Противники могут собирать шифрованные данные сегодня, чтобы расшифровать позже, поэтому долгоживущим секретам нужен план миграции. Паниковать не нужно, но следует знать свою опись и быть готовым принять стандартизированные постквантовые алгоритмы по мере их поставки платформами.

Предпочитайте валидированные реализации там, где это требуется

Для регулируемых и государственных систем сильного алгоритма недостаточно; реализация должна быть валидирована. FIPS 140 (Federal Information Processing Standard 140) американский стандарт валидации криптографических модулей, и многие контракты требуют криптографии, валидированной по FIPS. Государственная работа может также следовать национальному руководству, например набору Commercial National Security Algorithm (CNSA) Агентства национальной безопасности для секретных систем. Проверьте, какой режим применим, до построения, потому что дооснащение валидированными модулями поздно дорого. Это связано со свидетельствами соответствия и управлением (глава 4.6).

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
KMS под управлением провайдера	Легко, интегрировано, малое эксплуатационное бремя	Провайдер хранит ключи; меньше прямого контроля
Ключи под управлением клиента / HSM	Полное хранение, соответствует строгим мандатам	Эксплуатационные накладные расходы, риск потери ключей
Автоматические краткоживущие сертификаты	Нет неожиданных истечений, быстрый отзыв	Требуют вложений в автоматизацию заранее
Долгоживущие сертификаты	Просто, меньше подвижных частей	Истечения, управляемые людьми, вызывают отказы
Конвертное шифрование	Дешёвая ротация ключей, защищает главный ключ	Больше подвижных частей для понимания
Криптографическая гибкость заранее	Дешёвые будущие миграции	Дополнительная абстракция и проектные усилия сейчас
Раннее принятие постквантовой криптографии	Защищает долгоживущие секреты	Незрелые инструменты, большие ключи, некоторый риск

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

Вопросы для обсуждения с командой

Есть ли у вас полная опись ваших ключей, сертификатов и алгоритмов, на которые вы опираетесь? Нельзя ротировать, мигрировать или проверять то, чего не видишь, а большинство организаций обнаруживают, что у них гораздо больше криптографического материала, разбросанного по сервисам, чем кто-либо отслеживает. Опись предпосылка каждого последующего решения: мониторинг истечения сертификатов, ротация ключей, охват FIPS и постквантовое планирование все зависят от неё. Принесите список ваших текущих сертификатов и дат их истечения и спросите, кто владеет каждым и что ломается, когда он истекает. Для большого хозяйства честный ответ обычно в том, что единого источника истины нет, а его построение первый шаг наибольшего рычага. Если вы не можете перечислить вашу криптографию сегодня, гибкость и ротация пожелания, а не возможности.
Можете ли вы быстро ротировать или отозвать скомпрометированный ключ и практиковали ли вы это когда-нибудь? Ротация и отзыв части жизненного цикла ключа, важные только под давлением, и команды регулярно обнаруживают во время инцидента, что ключ зашит в дюжине мест или что отзыв на самом деле не распространяется. Решите вашу цель по времени ротации ключа и отзыва сертификата, затем репетируйте до того, как это понадобится. Принесите историю вашего последнего раскрытия учётных данных и пройдите по тому, чего ротация потребовала на практике. Для корпоративных и государственных систем нерепетированная ротация может означать выбор между затянувшейся экспозицией и самонанесённым отказом. Если ротация ни разу не тестировалась, считайте, что она не работает.
Где находится хранение ключей и принуждает ли оно к разделению обязанностей? Тот, кто может управлять ключом, и тот, кто может читать защищаемые им данные, не должны быть одним человеком, потому что слияние этих полномочий тихо разрушает смысл шифрования в покое. Этот выбор также определяет, используете ли вы ключи под управлением провайдера, ключи под управлением клиента или HSM, у каждого свой контроль и свой эксплуатационный риск. Принесите ваши текущие политики ключей и проверьте, может ли какая-либо одна идентичность и администрировать ключ, и получать доступ к открытому тексту за ним, что частый молчаливый пробел. Для регулируемых и секретных данных правила хранения могут диктоваться классификацией данных (глава 4.5) и мандатом. Если хранение и доступ не разделены, ваше шифрование защищает вас меньше, чем предполагает панель.
Как вы восстановились бы, если бы главный ключ, защищающий ваше конвертное шифрование, был потерян или уничтожен? Ключи под управлением клиента и HSM дают вам хранение, но вручают новый катастрофический режим отказа: потеряйте ключ шифрования ключей, и каждый обёрнутый им ключ шифрования данных, а с ними и данные за ними, становятся навсегда нечитаемыми. Взвесьте это против противоположного риска чрезмерно широкой резервной копии, тихо воссоздающей ту самую проблему хранения, которую вы пытались решить. Принесите ваши текущие договорённости о резервном копировании и депонировании ключей, радиус поражения каждого главного ключа и свидетельство, что восстановление было действительно выполнено, а не просто задокументировано. Для корпоративных и государственных хозяйств привяжите это к вашим правилам классификации данных: самые чувствительные ключи нередко запрещают случайные копии, поэтому восстановление нужно проектировать намеренно, тестировать по расписанию и согласовывать с любым регуляторным требованием доказать уничтожение выведенного ключевого материала.
Насколько ваши системы готовы к постквантовой миграции и какие долгоживущие секреты вы мигрировали бы первыми? Противники могут собирать шифрованный трафик и архивы сегодня и расшифровать их, когда квантовые компьютеры созреют, поэтому любой секрет, который должен оставаться конфиденциальным годами, уже экспонирован будущему, которого вы не видите. Конкурирующее давление в том, что постквантовые инструменты ещё молоды, ключи больше, а слишком ранний переход рискует поставить на алгоритм, который сместится до того, как осядет. Принесите вашу криптографическую опись, список секретов, ранжированных по тому, как долго они должны оставаться конфиденциальными, и честную оценку того, может ли ваша архитектура сменить алгоритмы без переписи. Для государственной и регулируемой работы записи с мандатами конфиденциальности на десятилетия делают это конкретным, а не теоретическим, а закупки вскоре могут требовать документированного плана миграции и поддержки стандартизированных постквантовых алгоритмов.
Когда регулирование требует валидированной криптографии, знаете ли вы точно, какие модули в охвате и подходят ли они? Использование сильного алгоритма не то же самое, что использование валидированной реализации, и команды регулярно обнаруживают поздно, что библиотека, среда выполнения языка или облачный сервис не входят в границу FIPS 140, которой требует контракт. Напряжение в том, что валидированные модули могут отставать от современных библиотек по функциям и скорости, поэтому их выбор ограничивает ваш стек способами, важными для инженерии. Принесите список криптографических модулей, которые каждая регулируемая система фактически вызывает, покрывающие их сертификаты валидации и конкретный мандат (FIPS 140, CNSA или отраслевое правило), который применяется. Для корпоративных и государственных программ решите это до построения, потому что дооснащение валидированными модулями и повторная авторизация системы постфактум дороги, медленны и нередко вынуждают переделать как раз те компоненты, что вы считали законченными.

Взгляд по секторам

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

Малый бизнес. У вас нет криптографа и мало желания эксплуатировать HSM, поэтому покупайте хранение, а не стройте его: используйте KMS и менеджер секретов под управлением провайдера, идущие с вашими облачными или SaaS-инструментами. Формулируйте работу как гигиену: нет ключей в коде, шифрование везде включено по умолчанию, и истечения сертификатов мониторятся, чтобы ничто не лопнуло внезапно. Оставляйте ключи под управлением клиента для редких данных, для которых их действительно требуют договор или регулятор.

Крупная организация. Проблема масштаб и согласованность по тысячам сервисов, сертификатов и ключей. Ведите централизованную KMS с конвертным шифрованием, автоматизируйте весь жизненный цикл сертификатов, чтобы ни одно истечение не выхаживалось вручную, и поддерживайте единую криптографическую опись, питающую ротацию, охват FIPS и постквантовое планирование. Разделяйте хранение ключей и доступ к данным как организационное средство контроля и делайте шифрование платформенной возможностью, которую наследует каждая команда, а не задачей, изобретаемой каждой заново.

Государственный сектор. Закупки, валидация и аудит определяют каждый выбор. Используйте криптографические модули, валидированные по FIPS 140, и следуйте национальному руководству, такому как CNSA для секретных систем, привязывайте хранение ключей к классификации данных, чтобы самые чувствительные ключи оказывались у допущенного персонала при строгом разделении обязанностей, и порождайте непрерывные свидетельства валидированной криптографии для продолжающейся авторизации. Документируйте план постквантовой миграции для записей, которые должны оставаться конфиденциальными десятилетиями, и требуйте от поставщиков раскрывать, какие модули валидированы, прежде чем вы свяжете себя обязательствами.

Примеры

Стартап. Небольшая команда, строящая приложение для отслеживания здоровья, опирается целиком на проверенные умолчания. Она завершает TLS с автоматически продлеваемыми сертификатами, включает шифрование в покое для управляемой базы данных и объектного хранилища через KMS провайдера и хэширует пароли медленной функцией с солью из стандартной библиотеки. Вместо того чтобы писать какую-либо криптографию самой, она использует высокоуровневый вызов аутентифицированного шифрования для единственного поля, которое должна шифровать в приложении. Секреты живут в менеджере секретов платформы, никогда в репозитории. Это стоит несколько дней и убирает целую категорию катастрофических ошибок.

Крупная организация. Международный банк ведёт централизованную KMS и парк HSM с криптографической описью, отслеживающей каждый ключ и сертификат по тысячам сервисов. Конвертное шифрование защищает данные клиентов, а ключи данных обёрнуты главными ключами, ротируемыми по расписанию, пока данные остаются на месте. Выпуск и продление сертификатов полностью автоматизированы после того, как публичный отказ научил их цене одного истёкшего сертификата. Администраторы ключей отдельная команда от инженеров приложений, так что хранение принуждает к разделению обязанностей, а слой криптографической гибкости позволяет им начать пилотировать постквантовые алгоритмы для долгоживущих архивов.

Государственный сектор. Национальное ведомство, работающее с секретными записями, использует только криптографические модули, валидированные по FIPS 140, и следует руководству CNSA АНБ для систем наивысшей классификации. Ключи генерируются и хранятся в HSM, никогда не выпускающих ключевой материал открытым текстом, а хранение привязано к классификации данных, так что самые чувствительные ключи оказываются у допущенного персонала при строгом разделении обязанностей. Сертификаты работают на управляемой внутренней PKI с автоматизированными жизненными циклами, а непрерывные свидетельства валидированной криптографии питают продолжающуюся авторизацию ведомства. Документированный план постквантовой миграции защищает записи, которые должны оставаться конфиденциальными десятилетиями.

Бизнес-обоснование: мотивы, ROI и TCO

Криптография ещё одна область, где скромное вложение предотвращает катастрофические потери уровня заголовков. Совокупная стоимость владения включает KMS или HSM, инструменты управления секретами и сертификатами и инженерное время на проектирование жизненных циклов и поддержание описи актуальной. Эти затраты реальны, но ограничены. Цена пропуска взлом нешифрованных данных, многочасовой отказ из-за истёкшего сертификата или безвозвратная потеря данных от неверного обращения с ключом, каждое несёт регуляторные штрафы, затраты на уведомление и длительный репутационный вред.

Сильнейший ROI приходит от автоматизации и повторного использования. Автоматизированные жизненные циклы сертификатов устраняют самый частый самонанесённый отказ. Централизованное управление ключами с разумными умолчаниями означает, что каждый новый сервис наследует шифрование при передаче и в покое без усилий на команду, превращая криптографию из повторяющегося налога в платформенную возможность. Для регулируемой и государственной работы валидированные модули и автоматические свидетельства также снижают стоимость аудитов и авторизации. Обосновывая это перед руководством, формулируйте прямо: алгоритмы бесплатны и проверены, риск живёт в управлении ключами и операциях с сертификатами, а небольшое автоматизированное вложение туда предотвращает дорогие отказы.

Антипаттерны и ловушки

Собственная криптография. Заказные алгоритмы или самодельные протоколы, отказывающие тонкими, доступными лишь экспертам способами.
Зашитые ключи и секреты. Учётные данные, вставленные в исходный код, файлы конфигурации или чат, где они утекают и не могут быть ротированы.
Шифрование без дисциплины ключей. Включение шифрования, но широко открытый доступ к ключам или их никогда не выполняемая ротация.
Смешение хэширования и шифрования. Воспринимание хэша как обратимого или хранение паролей быстрым хэшем вместо медленного с солью.
Рулетка сертификатов. Нет описи, нет мониторинга истечения и периодические неожиданные отказы, когда сертификат лопается.
Слитые хранение ключей и доступ к данным. Одна идентичность, способная и управлять ключом, и читать защищаемые им данные.
Нет плана ротации. Ключи, никогда не ротировавшиеся и не способные быть быстро ротированными под давлением.
Криптография без гибкости. Алгоритмы, вшитые так глубоко, что их замена требует переписи, блокируя любую будущую миграцию.
Игнорирование мандатов валидации. Сильные алгоритмы в невалидированных модулях там, где требуется FIPS или подобная валидация.

Модель зрелости

Уровень 1, Начальный: Шифрование непоследовательно и нередко отсутствует, применяется реактивно, когда кто-то замечает пробел. Ключи и секреты зашиты или неформально передаются в чате и файлах конфигурации. Нет описи, нет ротации, сертификаты истекают неожиданно, а команды порой пишут собственную криптографию.
Уровень 2, Развитие: TLS и шифрование в покое включены для основных систем, и существует KMS или менеджер секретов, но принятие неравномерно и различается по командам. Одни сертификаты мониторятся, другие нет, ротация ручная и редкая, и нет полной криптографической описи, связывающей это.
Уровень 3, Стандартизация: Шифрование при передаче и в покое документированное значение по умолчанию, принуждаемое по организации. Ключи живут в KMS с плановой ротацией и конвертным шифрованием, хранение ключей отделено от доступа к данным, жизненные циклы сертификатов автоматизированы, ведётся криптографическая опись, а валидированные модули используются везде, где этого требует регулирование.
Уровень 4, Управление: Криптографическое хозяйство измеряется и контролируется относительно базовых значений. Вы отслеживаете запас времени до истечения сертификатов, процент ключей, ротированных по расписанию, среднее время отзыва скомпрометированного ключа, обнаружения секретов в коде за период и покрытие описи и пересматриваете эти метрики относительно целей. Ротация и отзыв репетируются по ритму с записанными временами, а отклонения запускают корректирующее действие, а не остаются незамеченными.
Уровень 5, Оркестрация: Криптография платформенная возможность, которую каждый сервис наследует по умолчанию, непрерывно улучшаемая и интегрированная по организации. Ротация и отзыв быстры и регулярно упражняются, HSM защищают ключи наивысшей гарантии, а криптографическая гибкость плюс активный план постквантовой миграции сохраняют хозяйство адаптивным по мере сдвигов алгоритмов и мандатов. Свидетельства соответствия производятся автоматически и питают продолжающуюся авторизацию.

Идеи для обсуждения

Какие системы вашего хозяйства оправдывают ключи под управлением клиента или HSM с учётом их эксплуатационной цены и риска катастрофической потери?
Как вы построили бы и поддерживали единый источник истины по каждому ключу и сертификату, которыми владеете?
Каково ваше реалистичное время ротации скомпрометированного ключа сегодня и что его замедляет?
Где ваша архитектура затрудняет замену криптографического алгоритма и как вы исправили бы это до вынужденной миграции?
Какие из ваших долгоживущих секретов имели бы значение, если бы противник собрал их сейчас и расшифровал годы спустя?
Оказываются ли секреты и ключи когда-либо в коде, конфигурации или журналах и как бы вы об этом узнали?

Главные выводы

Не пишите собственную криптографию. Используйте проверенные библиотеки и стандартные алгоритмы на наивысшей безопасной абстракции.
Алгоритмы легки; управление ключами трудно. Жизненный цикл ключа (генерация, распространение, ротация, отзыв, уничтожение) то место, где живут реальные отказы.
Знайте свои гарантии: симметричное шифрование и шифрование с открытым ключом защищают конфиденциальность, подписи доказывают подлинность и целостность, а хэширование обнаруживает подмену, но не является шифрованием.
Шифруйте при передаче текущим TLS и в покое конвертным шифрованием как значение по умолчанию для каждой системы.
Разделяйте хранение ключей и доступ к данным, используйте KMS для ключей и менеджер секретов для учётных данных и никогда не зашивайте ни то, ни другое.
Автоматизируйте жизненные циклы сертификатов, чтобы убить отказ от неожиданного истечения, и ведите криптографическую опись.
Стройте под криптографическую гибкость и начните план постквантовой миграции для долгоживущих секретов.
Предпочитайте валидированные реализации (FIPS 140 и применимое национальное руководство) там, где этого требуют регулирование или классификация.

Источники и дополнительное чтение

National Institute of Standards and Technology, FIPS 140-3: Security Requirements for Cryptographic Modules.
National Institute of Standards and Technology, SP 800-57: Recommendation for Key Management.
National Institute of Standards and Technology, SP 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths.
National Institute of Standards and Technology, post-quantum cryptography standards (FIPS 203, 204, and 205).
Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno, Cryptography Engineering.
Jean-Philippe Aumasson, Serious Cryptography.
David Wong, Real-World Cryptography.
Internet Engineering Task Force, RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3.
Open Web Application Security Project, Cryptographic Storage Cheat Sheet and Transport Layer Protection Cheat Sheet.
National Security Agency, Commercial National Security Algorithm (CNSA) Suite guidance.