Cloud KMS, BYOK и HYOK как управлять ключами шифрования в облаке

Данные в AWS, Google Cloud или Microsoft Azure часто шифруются по умолчанию. Но для аудита и регулируемых данных этого ответа обычно недостаточно. Важнее понять не только “зашифровано ли”, а кто управляет ключом, кто может разрешить расшифрование, где находится ключевой материал и что произойдёт при ошибке с ключом.

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

Выбор модели обычно строится вокруг четырёх вариантов:

• Provider-managed keys — ключами в основном управляет облачный провайдер, а клиент получает базовое шифрование с минимальной операционной нагрузкой.
  
• Customer-managed keys / CMK / CMEK — клиент управляет объектом ключа, политиками, ротацией и состоянием в облачном KMS.
  
• BYOK (Bring Your Own Key) — клиент создаёт ключевой материал вне облака и импортирует его в KMS или защищённый модуль провайдера.
  
• HYOK / EKM (Hold Your Own Key / External Key Manager) — ключевой материал остаётся вне облака, а облачные сервисы обращаются к внешнему менеджеру ключей.

Главный компромисс простой: чем больше контроля над ключом, тем выше требования к эксплуатации. BYOK и HYOK помогают с разделением обязанностей, аудитом, происхождением ключей и юридическими требованиями. Но ошибка в политике доступа, ротации, удалении или проблем с внешним KMS может сделать данные недоступными.

Поэтому модель управления ключами нужно выбирать не по принципу “самая строгая — значит лучшая”, а по ответственности, которую компания реально готова поддерживать: кто управляет ключом, кто утверждает изменения, какие события попадают в аудит, как выполняется восстановление и что будет при отказе KMS.

Что делает Cloud KMS и почему шифрования по умолчанию бывает недостаточно

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

Упрощённо KMS похож не на сейф со всеми данными, а на систему контроля над “главными ключами”, можно провести аналогию с портье в гостинице, который выдаёт нужные ключи только нужным людям. Без разрешённой операции с ключом сервис может видеть зашифрованные данные в хранилище, но не сможет нормально их расшифровать и использовать.

Обычно Cloud KMS закрывает несколько задач:

После этого ключ становится не скрытой технической деталью, а объектом с жизненным циклом: именем, идентификатором, версиями, состоянием, политиками доступа, метаданными и журналом событий. Отдельно стоит различать объект ключа и ключевой материал — криптографическую основу, которая может быть создана внутри KMS, импортирована по BYOK или оставаться вне облака в более строгих схемах.

В облачных сервисах часто используется envelope encryption, или конвертное шифрование. Упрощённо схема такая:

• Данные шифруются отдельными ключами данных;
• Ключи данных защищаются ключом верхнего уровня;
• Cloud KMS управляет этим верхним уровнем и доступом к операциям с ним;
• Если операция с ключом запрещена или недоступна, сервис не сможет расшифровать данные.

Поэтому доступ к данным определяется не только правами на базу, bucket или диск. Сервису нужна ещё разрешённая операция с ключом. Если политика запрещает вызов, ключ отключён или KMS недоступен, данные могут остаться физически сохранёнными, но практически недоступными.

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

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

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

Четыре модели управления ключами: от ключей провайдера до внешнего KMS

Если ключ становится отдельной точкой доступа к данным, следующий вопрос — кто управляет этой точкой. Здесь удобно смотреть на модели как на лестницу контроля: каждый следующий уровень даёт клиенту больше влияния на ключевой материал и решения по ключу, но добавляет операционные обязанности.

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

Provider-managed keys

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

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

Customer-managed keys / CMK / CMEK

Customer-managed keys, или CMK/CMEK, дают клиенту больше контроля. Ключевой материал находится в облачном KMS провайдера, но клиент управляет объектом ключа: выбирает политики доступа, состояние, ротацию, версии, отключение и удаление.

Эта модель часто подходит для корпоративных баз, персональных данных и критичных рабочих систем, где важно отделить права на данные от прав на ключ. Важно не путать CMK/CMEK с BYOK: ключ, управляемый клиентом, может быть создан прямо внутри облачного KMS и не обязательно импортируется извне.

BYOK

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

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

HYOK / EKM

HYOK, или внешний менеджер ключей, переносит границу контроля ещё дальше. Ключевой материал остаётся вне облака, а облачные сервисы обращаются к внешнему KMS для разрешённых операций. В документации такая схема может называться EKM — external key manager.

Эта модель может быть нужна финансовым организациям, госсектору или компаниям с жёсткими требованиями к юрисдикции ключей. Но HYOK не стоит воспринимать как автоматический “самый безопасный” вариант. Он добавляет зависимость от внешнего KMS, сети, интеграции, мониторинга и процедур восстановления.

Общую разницу можно свести так:

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

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

Что меняется на практике: ротация, аудит, доступность и потеря ключа

После сравнения моделей важно перевести контроль в эксплуатацию. Ключ — это не только место хранения ключевого материала, но и набор процедур: ротация, аудит, отключение, удаление, восстановление и проверка доступа.

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

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

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

• Изменение политик доступа и ролей;
• Импорт и повторный импорт ключевого материала;
• Отключение, удаление и ротацию ключа;
• Неуспешные попытки доступа;
• Действия сервисных аккаунтов и автоматических процессов.

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

Доступность работает по тому же принципу. Компания может управляемо отключить ключ конкретного клиента и предсказуемо заблокировать доступ к его данным, например при расторжении договора. Это контролируемое действие: оно документируется, согласуется и может быть отменено.

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

Поэтому управление ключом — это управление не только шифрованием, но и границей доверия. Дальше важно отдельно разобрать, где эта граница проходит в BYOK и HYOK.

Где проходит граница контроля в BYOK и HYOK

BYOK: клиент контролирует происхождение ключа

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

Но после импорта граница меняется. Ключевой материал или его защищённая форма начинает использоваться внутри облачной инфраструктуры, а криптографические операции выполняются средствами провайдера. Поэтому BYOK хорошо закрывает требование “ключ создан под нашим контролем”, но обычно не закрывает требование “ключевой материал никогда не передавался облачному провайдеру”.

HYOK: ключ остаётся вне облака

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

Практическая разница между BYOK и HYOK особенно заметна при сбоях и аудите:

Поэтому выбор между BYOK и HYOK нельзя сводить к формуле «HYOK безопаснее». HYOK даёт более жёсткую границу контроля, но требует зрелой эксплуатации внешней криптографической инфраструктуры. Если организация не может обеспечить отказоустойчивость, мониторинг, процедуры восстановления и доказуемый аудит внешнего KMS, HYOK может повысить риск недоступности данных сильнее, чем снизить риск несанкционированного доступа. 

Юридические и регуляторные требования: что влияет на выбор модели

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

Контроль ключевого материала

Если достаточно доказать, что ключи управляются в Cloud KMS с отдельными ролями и журналами, обычно подходят customer-managed keys. Если требуется, чтобы ключ был сгенерирован в контролируемой среде клиента, появляется аргумент в пользу BYOK. Если прямо запрещена передача ключевого материала провайдеру, нужно рассматривать HYOK или внешний менеджер ключей.

Здесь важно не подменять требование более сложной схемой “на всякий случай”. Иногда аудит закрывается ролями, журналами и управляемым жизненным циклом в Cloud KMS. А иногда формулировка договора или регуляторного требования действительно требует, чтобы ключевой материал оставался вне облака.

Юрисдикция и место хранения

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

В таких случаях provider-managed keys часто недостаточно прозрачны. CMK/CMEK могут закрывать часть требований по региону и администрированию, BYOK помогает подтвердить происхождение ключа, а HYOK используется там, где ключ должен физически и административно оставаться вне облачной платформы.

Аудит, роли и доказуемое удаление

Многие стандарты и отраслевые требования не говорят буквально “используйте BYOK” или “используйте HYOK”. Чаще они требуют контролей: минимальных прав, журналирования, процедуры изменения политик, защиты ключей, управляемого удаления и возможности восстановить ход событий при инциденте.

Поэтому важно заранее описать:

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

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

Итог простой: юридический выбор модели — это не выбор самого строгого варианта, а сопоставление требований с операционной способностью компании. Если требование можно закрыть управляемыми ключами, ролями и журналами в Cloud KMS, HYOK может быть избыточным. Если же требование прямо касается непередачи ключевого материала провайдеру или независимой юрисдикции ключей, без HYOK или внешнего KMS обойтись трудно.

Сценарии для регулируемых данных

После юридической рамки полезно посмотреть на типовые сценарии. Они не заменяют анализ конкретного закона, стандарта или договора, но показывают общий принцип: чем строже требование к независимому контролю ключевого материала, тем дальше модель смещается от provider-managed keys к CMK/CMEK, BYOK и HYOK.

Финансовая организация и платёжные данные

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

Часто базовой моделью становятся customer-managed keys: они позволяют отделить администраторов инфраструктуры от администраторов ключей, фиксировать изменение политик и управлять отключением доступа.

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

Медицинские данные и PHI

Для медицинских данных важны минимизация прав, журналы доступа, контроль административных действий и возможность расследовать несанкционированный доступ. Во многих случаях достаточно customer-managed keys в облачном KMS, если правильно настроены роли, аудит, ротация и удаление.

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

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

Государственные данные и подрядчики госсектора

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

Provider-managed keys обычно подходят только для низкорисковых или публичных данных. Customer-managed keys могут быть достаточны, если облачный регион, роли, журналы и процедуры соответствуют требованиям программы или контракта.

BYOK добавляет контроль над генерацией ключей и помогает встроить облако в уже существующие процедуры управления криптографическими материалами. HYOK рассматривается, если ключи должны оставаться в отдельной инфраструктуре ведомства, подрядчика или доверенного оператора.

Персональные данные с требованиями к юрисдикции

Международная компания может хранить персональные данные в разных регионах и одновременно учитывать локализацию, трансграничную передачу и административный доступ к KMS. Здесь важно разделять регион данных, регион ключа и юридическое лицо, которое управляет ключом.

Для умеренных требований часто подходят customer-managed keys с региональной привязкой и строгими ролями. BYOK помогает подтвердить, что ключ создан в контролируемой среде компании до ввода в облако.

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

Многоарендный облачный сервис

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

Customer-managed keys позволяют дать крупным клиентам больше контроля: отдельный ключ, отдельные журналы, управляемое отключение доступа при завершении договора. BYOK подходит для клиентов, которые требуют импортировать собственный ключевой материал.

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

Общий вывод простой: регулируемые данные не всегда требуют HYOK. Часто достаточно customer-managed keys, ролей, журналов, ротации и понятных процедур. BYOK нужен, когда важно происхождение ключевого материала. HYOK оправдан там, где ключ не должен покидать внешний контур контроля, но компания готова принять операционную сложность такой модели.

Заключение

Модель управления ключами в облаке стоит выбирать не по принципу “самая строгая — значит лучшая”, а по ответственности, которую компания реально готова поддерживать процессами. Шифрование по умолчанию закрывает базовый уровень, но не всегда даёт нужный контроль над ключами, аудитом, юрисдикцией и разделением обязанностей.

Cloud KMS и customer-managed keys подходят там, где нужен управляемый жизненный цикл ключа внутри облака. BYOK нужен, когда важно происхождение ключевого материала и генерация в собственной среде. HYOK оправдан при требовании не передавать ключевой материал облачному провайдеру, но требует зрелой эксплуатации: отказоустойчивости, мониторинга, восстановления, контроля удаления и регулярных проверок.

FAQ

Чем customer-managed keys отличаются от BYOK?

Customer-managed keys означают, что клиент управляет объектом ключа в облачном KMS: политиками, ротацией, отключением и удалением. При этом ключевой материал может быть создан самим облачным KMS.

BYOK — частный случай с дополнительным требованием: ключевой материал создаётся клиентом вне облака и затем импортируется в KMS или HSM провайдера.

Почему BYOK не равно HYOK?

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

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

Когда достаточно ключей, управляемых провайдером?

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

Если аудит требует показать, кто управлял ключом, кто менял политики доступа и как выполнялась ротация, обычно нужны customer-managed keys, BYOK или HYOK.

Что произойдёт, если ключ удалить или отключить?

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

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

Какие события нужно логировать для аудита KMS?

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

Для расследований важно видеть не только фактическое чтение данных, но и изменения, которые могли создать возможность для расшифрования.

Когда HYOK действительно оправдан?

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

Если такого требования нет, HYOK может создать избыточную сложность. Внешний KMS становится критической зависимостью, и его сбой способен нарушить доступ к данным в облаке.

Список источников

1. Google Cloud — Customer-managed encryption keys

2. Google Cloud — Cloud External Key Manager

3. AWS KMS — Importing key material

4. NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management