Вопросы и ответы по Сервису управления ключами AWS

Информация, приведенная в этом разделе вопросов и ответов, не применима к Сервису управления ключами AWS (AWS KMS) в регионе AWS Китай (Пекин) под управлением компании Sinnet и регионе AWS Китай (Нинся) под управлением компании NWCD. Ответы на вопросы по этим двум регионам в Китае см. по ссылке.

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

Если вы несете ответственность за защиту данных в сервисах AWS, рекомендуем использовать этот сервис для централизованного управления ключами шифрования, которые контролируют доступ к вашим данным. Если вы разработчик, которому требуется шифрование данных в приложениях, можно использовать при работе с кодом пакет AWS Шифрование SDK с поддержкой AWS KMS для упрощения генерации, применения и защиты симметричных ключей шифрования. Если вы разработчик, которому требуется цифровая подпись или проверка данных с использованием асимметричных ключей шифрования, рекомендуем использовать AWS KMS для создания необходимых закрытых ключей и управления ими. Если вы ИТ‑администратор, которому нужна масштабируемая инфраструктура управления ключами, позволяющая обеспечить поддержку разработчиков и растущего арсенала создаваемых ими приложений, можно использовать сервис AWS KMS, чтобы снизить рабочую нагрузку и расходы на лицензирование. Если вы несете ответственность за подтверждение защищенности данных для регулируемых отраслей или обеспечения соответствия требованиям, рекомендуем использовать сервис AWS KMS, который упростит проверку стандартов защиты вверенных вам данных. Кроме того, этот сервис соответствует многим отраслевым и региональным нормативным требованиям.

Самый простой способ начать работу с сервисом AWS KMS – зашифровать данные в поддерживаемом сервисе AWS с помощью управляемых корневых ключей, создаваемых в аккаунте для каждого сервиса. Если требуется полный контроль над используемыми ключами, включая возможность предоставления совместного доступа к ним из разных аккаунтов или сервисов, можно создать в AWS KMS управляемые клиентом ключи AWS KMS. Как вариант, можно использовать ключи KMS, созданные непосредственно из приложений. К сервису AWS KMS можно получить доступ из консоли KMS, которая находится в разделе Security, Identity and Compliance («Безопасность, идентификация и соответствие требованиям») на главной странице сервисов AWS в Консоли AWS KMS. API KMS можно вызвать напрямую из интерфейса командной строки KMS (CLI); доступ к API программными средствами реализуется с помощью AWS SDK. API KMS также можно использовать для шифрования данных в собственных приложениях с помощью AWS Шифрование SDK. Подробнее см. на странице Начало работы.

Доступность сервиса в мировом масштабе можно проверить на нашей странице Продукты и сервисы по регионам.

В AWS KMS можно выполнять следующие задачи управления ключами.

• Создавать симметричные и асимметричные ключи, а также ключи HMAC, материал которых будет использоваться только в пределах сервиса
• Создавать симметричные ключи, где ключевой материал генерируется и применяется в пользовательском хранилище ключей под вашим контролем и поддерживается либо AWS CloudHSM, либо вашим собственным внешним менеджером ключей вне AWS
• Импортировать собственные симметричные, асимметричные и ключевые материалы HMAC для использования в поддерживаемых сервисах AWS и собственном приложении
• Определять, какие пользователи и роли Управления идентификацией и доступом AWS (AWS IAM) могут распоряжаться ключами
• Устанавливать, какие пользователи и роли IAM могут использовать ключи для шифрования и дешифрования данных
• Организовывать ежегодную автоматическую ротацию сгенерированных сервисом ключей
• Временно деактивировать ключи, чтобы никто не мог их использовать
• Повторно активировать деактивированные ключи
• Назначать время удаления ключей, которые уже не используются
• Проводить аудит использования ключей путем анализа журналов AWS CloudTrail

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

AWS KMS интегрирован инструментарием на стороне клиента и с сервисами AWS, в которых для защиты данных применяется метод, называемый шифрованием конвертов. В соответствии с этим методом AWS KMS создает ключи, которые используются для локального шифрования данных в сервисе AWS или приложении. При этом сами ключи шифруются с использованием указанного ключа AWS KMS. Для хранения ключей данных или управления ими сервис AWS KMS не используется. Сервисы AWS шифруют данные и хранят зашифрованную копию ключа данных вместе с этими данными. Когда сервису необходимо расшифровать определенные данные, он запрашивает у сервиса AWS KMS расшифровку ключа данных с помощью соответствующего ключа KMS. Если пользователь, запросивший данные из сервиса AWS, имеет право выполнять дешифрование с помощью вашего ключа KMS, соответствующий сервис получит из AWS KMS расшифрованный ключ данных. Затем сервис AWS выполнит дешифрование данных и вернет их в расшифрованном виде. Все запросы на использование ваших ключей KMS регистрируются в CloudTrail, что позволяет понять, кто, когда и при каких обстоятельствах применял тот или иной ключ.

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

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

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

У вас есть возможность выбрать определенный ключ KMS, который будет использоваться, когда сервису AWS потребуется зашифровать данные от вашего имени. Такие ключи называются KMS под управлением клиента: полный контроль над ними сохраняется за владельцем аккаунта. Можно установить политику использования каждого ключа и контроля доступа к нему, при этом сервис позволяет предоставлять разрешения на использование таких ключей другим аккаунтам и сервисам. В дополнение к ключам, управляемым клиентами, AWS KMS также предоставляет два типа ключей, управляемых AWS: (1) ключи AWS под управлением KMS – это ключи, созданные в вашем аккаунте, но управляемые AWS, и (2) ключи, принадлежащие AWS, – это ключи, полностью принадлежащие и управляемые аккаунтами AWS. Сервис позволяет отслеживать управляемые ключи AWS в своем аккаунте, их использование также регистрируется в сервисе CloudTrail, однако прямого контроля над самими ключами у владельца аккаунта нет. Ключи, принадлежащие AWS, являются наиболее автоматизированными и обеспечивают шифрование ваших данных в AWS, но не предоставляют контроля политики или журналов CloudTrail об активности ключей.

Создав собственный ключ KMS в сервисе AWS KMS, вы обеспечите больший контроль, чем в случае использования ключей, созданных под управлением AWS. При создании управляемого клиентом симметричного ключа KMS можно использовать материал ключа, сгенерированный AWS KMS, сгенерированный в кластере AWS CloudHSM или внешнем менеджере ключей (собственном хранилище ключей) или импортировать для этих целей собственный материал. Можно указать псевдоним и дать описание ключа, а также включить автоматическую ротацию ключа один раз в год, если ключ был сгенерирован сервисом AWS KMS. Владелец аккаунта определяет права доступа к такому ключу, указывая, кто может использовать CMK и управлять им. В случае применения асимметричных ключей KMS, управляемых клиентами, следует учесть несколько нюансов: материал ключа может быть сгенерирован только внутри модулей безопасности HSM сервиса AWS KMS; для него невозможно организовать автоматическую ротацию.

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

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

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

Да. Можно запланировать удаление ключа AWS KMS и связанных с ним метаданных, созданных в AWS KMS, выбрав период ожидания от 7 до 30 дней. Этот период ожидания позволяет проверить воздействие удаления ключа на ваши приложения и на пользователей, которые зависят от него. Период ожидания по умолчанию составляет 30 дней. В течение периода ожидания удаление ключа можно отменить. Ключ, запланированный к удалению, нельзя продолжать использовать, если удаление не будет отменено в течение периода ожидания. Ключ, удаление которого не было отменено, будет удален в конце заданного периода ожидания. После удаления ключа использовать его будет невозможно. Все данные, которые были защищены с помощью удаленного корневого ключа, станут недоступными.

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

Да. Поддержка сервиса AWS KMS существует в пакетах AWS SDK, AWS Шифрование SDK, шифрование на стороне клиента Amazon DynamoDB и Клиент шифрования простого сервиса хранения данных Amazon (Amazon S3), что упрощает процедуру шифрования данных в приложениях, где бы они ни работали. Дополнительную информацию см. на страницах AWS Crypto Tools и Разработка на AWS.

Сервис позволяет создавать до 100 000 ключей KMS для каждого аккаунта в каждом регионе. Поскольку учету подлежат как используемые, так и деактивированные ключи KMS, мы рекомендуем удалять деактивированные ключи, которые больше не используются. Управляемые AWS ключи KMS, созданные от вашего имени для использования в поддерживаемых сервисах AWS, в этом ограничении не учитываются. Количество ключей данных, которые можно получить с помощью ключа KMS и использовать в своем приложении или сервисах AWS для шифрования данных от своего имени, не ограничено. Запрос на повышение лимита для ключей KMS можно отправить, обратившись в Центр Поддержки AWS.

Нет. Ключ KMS или закрытую часть асимметричного ключа KMS нельзя экспортировать из модуля HSM в незашифрованном виде. Только открытую часть асимметричного ключа KMS можно экспортировать через консоль или с помощью вызова API GetPublicKey.

Да. Симметричные ключи данных можно экспортировать с помощью вызова API GenerateDataKey или API GenerateDataKeyWithoutPlaintext. И открытую, и закрытую части пары асимметричных ключей данных можно экспортировать из AWS KMS с помощью вызова API GenerateDataKeyPair или API GenerateDataKeypairWithoutPlaintext.

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

Основной причиной использовать Частный центр сертификации AWS (частный ЦС AWS) является возможность предоставления инфраструктуры открытого ключа (PKI) для идентификации сущностей и защиты сетевых подключений. PKI предоставляет процессы и механизмы, в основном использующие сертификаты X.509, для структурирования криптографических операций с открытым ключом. Сертификаты позволяют установить связь между сущностью и открытым ключом. Процесс сертификации (то есть процесс выпуска сертификата центром сертификации) позволяет доверенному центру сертификации заверить подлинность другого объекта путем подписания соответствующего сертификата. PKI обеспечивает подтверждение подлинности, распределенное доверие, управление жизненным циклом ключей и поддержание статуса сертификатов с возможностью отзыва. Такие функции добавляют важные процессы и инфраструктуру к базовым асимметричным криптографическим ключам и алгоритмам, предоставляемым AWS KMS.

Частный ЦС AWS позволяет выпускать сертификаты для идентификации веб‑серверов и серверов приложений, сервисных сетей, пользователей VPN, внутренних адресов API и устройств AWS IoT Core. Сертификаты позволяют устанавливать подлинность этих ресурсов и создавать зашифрованные каналы связи TLS / SSL. Если вы планируете использовать асимметричные ключи для терминации TLS на веб‑серверах или серверах приложений, эластичных балансировщиках нагрузки, адресах шлюза API, инстансах Эластичного вычислительного облака Amazon (Amazon EC2) или контейнерах, следует рассмотреть возможность использования частного ЦС AWS для выдачи сертификатов и предоставления необходимой инфраструктуры PKI.

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

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

Да. Соглашение об уровне обслуживания AWS KMS (SLA) предусматривает компенсацию в случае, если уровень бесперебойной работы за любой учетный период был ниже согласованного.

Сервис AWS KMS принудительно применяет политики использования и управления, которые определены вами. Пользователям и ролям сервиса IAM в рамках собственного или других аккаунтов можно разрешить или запретить использовать ключи и управлять ими.

Сервис AWS KMS устроен таким образом, что никто, включая сотрудников AWS, не может извлечь из него ваши незашифрованные ключи KMS. AWS KMS использует аппаратные модули безопасности (HSM), которые прошли проверку в соответствии с FIPS 140-2 или находятся в процессе проверки, для защиты конфиденциальности и целостности ваших ключей. Незашифрованные ключи KMS никогда не передаются за пределы модулей HSM, никогда не записываются на диск и используются только в энергозависимой памяти модуля HSM в течение времени, необходимого для выполнения запрошенной криптографической операции. Обновление программного обеспечения на узлах сервиса и обновление встроенного ПО модулей HSM в AWS KMS управляется системой многостороннего контроля доступа, за проверку и корректировку которой отвечает независимая группа в составе Amazon и лаборатория, прошедшая сертификацию NIST, как того требует стандарт FIPS 140‑2.

Дополнительную информацию о порядке обеспечения безопасности в данном отношении см. в техническом описании Сведения о криптографии в сервисе AWS KMS. Чтобы подробнее узнать об обеспечении соответствия требованиям безопасности FIPS 140‑2 для модулей HSM сервиса AWS KMS, ознакомьтесь с сертификатом FIPS 140‑2 для модулей HSM в AWS KMS и соответствующей политикой безопасности. Кроме того, в AWS Artifact можно получить копию отчета Систем и средств управления сервисной организацией (SOC), чтобы ознакомиться со средствами обеспечения безопасности, которые сервис использует для защиты ключей KMS.

Вам не нужно ничего делать. Все ключи AWS KMS, независимо от времени и места их создания, автоматически защищены модулями HSM, проверенными на соответствие стандарту FIPS 140‑2 третьего уровня безопасности.

Модули HSM, проверенные на соответствие FIPS 140‑2 третьего уровня безопасности, доступны во всех регионах AWS, где предлагается сервис AWS KMS.
ПРИМЕЧАНИЕ. По правилам, AWS KMS в регионах Китая не может использовать модули NIST FIPS HSM и вместо них использует сертифицированные модули HSM Управления государственной коммерческой криптографической администрации Китая (OSCCA).

AWS KMS – это двухуровневый сервис. Адреса API получают клиентские запросы через соединение HTTPS, используя только комплекты шифров TLS, обеспечивающие полную безопасность пересылки. Эти адреса API выполняют аутентификацию и авторизуют запрос перед тем, как передать его на криптографическую операцию в модули HSM сервиса AWS KMS или в кластер AWS CloudHSM, если в KMS используется собственное хранилище ключей.

Необходимо настроить приложения на подключение к уникальным региональным адресам HTTPS, проверенным на соответствие FIPS 140-2. Проверенные на соответствие FIPS 140-2 адреса HTTPS сервиса AWS KMS работают на базе OpenSSL FIPS Object Module. Вы можете ознакомиться с политикой безопасности модуля OpenSSL здесь. Адреса API, проверенные на соответствие FIPS 140‑2, доступны во всех коммерческих регионах, где предлагается сервис AWS KMS.

Да. Сервис AWS KMS прошел проверку на наличие функциональных возможностей и средств обеспечения безопасности, которые необходимы для выполнения требований PCI DSS 3.2.1 к шифрованию и управлению ключами (перечисленных главным образом в разделах 3.5 и 3.6).

Подробнее о соответствии сервисов AWS стандарту PCI DSS см. на странице вопросов и ответов по PCI DSS.

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

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

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

В журналах AWS CloudTrail отображаются все запросы API в AWS KMS, включая как запросы, связанные с операциями управления (например, создание, ротация, деактивация, изменение политики), так и криптографические запросы (например, шифрование / дешифрование). Включите сервис CloudTrail для своего аккаунта, чтобы просматривать эти журналы.

CloudHSM предоставляет для хранения и использования ключей проверенный на соответствие требованиям однопользовательский кластер модулей HSM в рамках виртуального частного облака Amazon (VPC). Пользователь получает эксклюзивный контроль над тем, как используются его ключи, через механизм аутентификации, независимый от AWS. Пользователь взаимодействует с ключами в своем кластере CloudHSM подобно тому, как он взаимодействует со своими приложениями, работающими в Amazon EC2. CloudHSM подходит для различных примеров использования, таких как технические средства защиты авторских прав (DRM), инфраструктура открытых ключей (PKI), подпись документов и криптографические функции с использованием интерфейсов PKCS 11, Java JCE или Microsoft CNG.

Сервис AWS KMS предоставляет единую консоль для создания ключей шифрования и управления ими. При этом ключи можно использовать в приложениях и поддерживаемых сервисах AWS во множестве регионов по всему миру. Защита ключей обеспечивается с помощью модуля FIPS HSM, который проверили или проверяют на соответствие стандарту FIPS 140‑2. Централизованное управление всеми ключами в сервисе AWS KMS позволяет определять, кто и при каких условиях может использовать ключи и управлять ими, а также когда происходит их ротация. Интеграция сервиса AWS KMS с CloudTrail позволяет проводить аудит использования ключей с целью соблюдения применимых нормативных требований. Взаимодействовать с AWS KMS из приложений можно с помощью AWS SDK, если необходимо напрямую вызывать сервисные API, через другие сервисы AWS, которые интегрированы с AWS KMS, или с помощью AWS Шифрование SDK, если требуется выполнять шифрование на стороне клиента.

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

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

Сведения о действующих ценах см. на странице цен на AWS KMS.

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

* Выполнение запросов API, связанных с асимметричными ключами KMS, а также запросов API GenerateDataKeyPair и GenerateDataKeyPairWithoutPlaintext в уровень бесплатного пользования не входит.

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

Да. Можно импортировать в AWS KMS копию ключа из собственной инфраструктуры управления ключами и использовать ее с любым интегрированным сервисом AWS или собственными приложениями.

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

Можно импортировать симметричные, асимметричные ключи (RSA и эллиптическая кривая) и ключи HMAC.

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

Есть два основных отличия.

1. Вы несете ответственность за хранение копии импортированных ключей в собственной инфраструктуре управления ключами, чтобы их можно было в любой момент импортировать повторно. AWS при этом обеспечивает доступность, безопасность и надежность ключей, сгенерированных AWS KMS от вашего имени, пока вы не запланируете их удаление.
2. Для импортированного ключа можно установить окончание срока действия. AWS KMS автоматически удалит данные ключа, как только его срок действия будет окончен. Удалить данные импортированного ключа также можно по требованию. В обоих случаях сами данные ключа удаляются, но сохраняется ссылка ключа KMS в AWS KMS и связанные метаданные, что позволяет повторно импортировать данные ключа в будущем. Ключи, сгенерированные AWS KMS, не имеют срока действия и не могут быть удалены немедленно; предусмотрен обязательный период ожидания от 7 до 30 дней. Все управляемые клиентом ключи KMS (независимо от того, были ли импортированы данные этих ключей) могут быть заблокированы вручную или запланированы на удаление. В этом случае удаляется сам ключ KMS, а не только данные, лежащие в его основе.

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

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

AWS KMS поддерживает 256-битные ключи во время создания ключа KMS для шифрования и расшифровки. Сгенерированные для оператора ключи данных могут быть 256‑битными, 128‑битными или иметь произвольную длину до 1024 бит. Когда сервис AWS KMS использует 256‑битный ключ KMS от вашего имени для шифрования и расшифровки, применяется алгоритм AES с счетчиком аутентификации Галуа (AES‑GCM).

AWS KMS поддерживает следующие типы асимметричных ключей: RSA 2048, RSA 3072, RSA 4096, ECC NIST P‑256, ECC NIST P‑384, ECC NIST‑521 и ECC SECG P‑256k1. AWS KMS поддерживает алгоритмы RSAES_OAEP_SHA_1 и RSAES_OAEP_SHA_256 с ключами RSA 2048, RSA 3072 и RSA 4096. Не поддерживаются алгоритмы шифрования с ключами на эллиптических кривых (ECC NIST P‑256, ECC NIST P‑384, ECC NIST‑521 и ECC SECG P‑256k1).

Для ключей типа RSA сервис AWS KMS поддерживает алгоритмы цифровой подписи RSASSA_PSS_SHA_256, RSASSA_PSS_SHA_384, RSASSA_PSS_SHA_512, RSASSA_PKCS1_V1_5_SHA_256, RSASSA_PKCS1_V1_5_SHA_384 и RSASSA_PKCS1_V1_5_SHA_512. Для ключей на эллиптических кривых AWS KMS поддерживает алгоритмы цифровой подписи ECDSA_SHA_256, ECDSA_SHA_384 и ECDSA_SHA_512.

Открытая часть материала асимметричного ключа генерируется сервисом AWS KMS. Ее можно использовать для проверки цифровых подписей с помощью вызова API Verify или для шифрования с открытым ключом с помощью вызова API Encrypt. Открытый ключ можно использовать вне сервиса AWS KMS для проверки или шифрования. Получить открытую часть асимметричного ключа KMS можно с помощью вызова API GetPublicKey.

Ограничение по размеру составляет 4 КБ. Если необходимо подписать данные размером более 4 КБ, можно создать профиль сообщения данных и отправить его в AWS KMS. Цифровая подпись составляется по присланному профилю и возвращается. При запросе API Sign нужно указать с помощью соответствующего параметра, отправляется полное сообщение или его профиль. Любые данные в вызовах API Encrypt, Decrypt или Re‑Encrypt, требующие использования асимметричных операций, также должны иметь размер менее 4 КБ.

В консоли у каждого ключа есть поле Key Type («Тип ключа»). Его значение указывает тип ключа: Asymmetric Key («Асимметричный ключ») или Symmetric Key («Симметричный ключ»). Вызов API DescribeKey возвращает поле KeyUsage, где указано, для чего можно использовать ключ: для шифрования, создания HMAC или для подписи.

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

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

Да. Уровень запросов в секунду отличается в зависимости от типа ключа и алгоритма. Дополнительную информацию см. на странице лимитов сервиса AWS KMS.

Нет. Асимметричные ключи нельзя использовать с возможностями собственного хранилища.

Прямая поддержка не предусмотрена. AWS KMS не хранит и не связывает цифровые сертификаты с асимметричными KMS, которые создает. По решению клиента центр сертификации, например AWS Private Certificate Authority, может выпустить сертификат для открытой части асимметричного KMS. Это позволит сущностям, использующим этот открытый ключ, проверять, действительно ли он принадлежит вам.

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

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

Поскольку кластер CloudHSM находится под вашим контролем, это позволяет управлять жизненным циклом ключей KMS независимо от KMS. Есть три случая, в которых собственное хранилище ключей может оказаться полезным. Во‑первых, когда используются ключи, которые должны быть явно защищены в однопользовательском модуле HSM или в модуле HSM под непосредственным контролем владельца. Во‑вторых, когда может потребоваться возможность немедленного удаления материала ключа из KMS и независимого подтверждения, что удаление выполнено. В-третьих, когда требуется возможность проводить аудит любого использования ключей независимо от KMS или CloudTrail.

Есть два отличия между управлением ключами в собственном хранилище ключей при поддержке CloudHSM и хранилище ключей AWS KMS по умолчанию. В собственное хранилище ключей нельзя импортировать материалы ключей. Кроме того, вы не сможете использовать KMS для выполнения автоматической ротации ключей. Во всех прочих аспектах (включая типы ключей, которые могут быть сгенерированы, способ использования ключами псевдонимов и способ задания политик) управление ключами, которые хранятся в собственном хранилище ключей, осуществляется так же, как и управление любым другим ключом KMS под управлением клиента KMS.

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

Нет. Запросы API к AWS KMS на использование ключа KMS для шифрования и дешифрования данных обрабатываются стандартным образом. Процессы аутентификации и авторизации работают независимо от того, где хранится ключ. Все действия, связанные с использованием ключа в собственном хранилище ключей при поддержке CloudHSM, также стандартным образом регистрируются в сервисе CloudTrail. Однако сами криптографические операции однозначно выполняются либо в собственном хранилище ключей, либо в хранилище ключей AWS KMS по умолчанию.

В дополнение к действиям, которые регистрируются AWS KMS в сервисе CloudTrail, при использовании собственного хранилища ключей предоставляются три дополнительных механизма аудита. Во-первых, CloudHSM также регистрирует всю активность API в CloudTrail, например создание кластеров, добавление или удаление HSM. Во‑вторых, каждый кластер ведет свои собственные локальные журналы для записи действий пользователей и действий, связанных с управлением ключами. В‑третьих, каждый инстанс CloudHSM копирует локальные журналы действий пользователей и действий, связанных с управлением ключами, в AWS CloudWatch.

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

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

Использование собственного хранилища ключей не влияет на стоимость AWS KMS. Однако при использовании каждого собственного хранилища ключей необходимо, чтобы соответствующий кластер AWS CloudHSM включал не менее двух модулей HSM. Эти модули HSM оплачиваются по стандартным тарифам AWS CloudHSM. Дополнительная плата за использование собственного хранилища ключей не взимается.

Пользователям AWS KMS, которые хотят использовать собственное хранилище ключей, требуется настраивать кластер AWS CloudHSM, добавлять модули HSM, управлять пользователями HSM и, возможно, восстанавливать HSM из резервной копии. От выполнения этих задач серьезно зависит безопасность, поэтому стоит убедиться, что у вас есть соответствующие ресурсы и организационные средства управления.

Нет. Возможность импорта своих данных ключей в собственное хранилище ключей AWS KMS не поддерживается. Ключи, находящиеся в собственном хранилище ключей, могут быть сгенерированы только в модулях HSM, которые входят в принадлежащий клиенту кластер CloudHSM.

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

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

Да. AWS KMS не требует эксклюзивного доступа к кластеру CloudHSM, принадлежащему клиенту. Если у вас уже есть кластер, его можно использовать как собственное хранилище ключей и продолжать использовать для других приложений. Однако если такой кластер поддерживает обработку больших рабочих нагрузок, не связанных с AWS KMS, вы можете столкнуться со снижением производительности при выполнении операций, использующих ключи KMS в собственном хранилище ключей. Аналогичным образом высокая частота запросов AWS KMS к собственному хранилищу ключей может повлиять на работу других приложений.

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

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

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

Запросы к AWS KMS от интегрированных сервисов AWS от вашего имени или от ваших собственных приложений направляются компоненту в вашей сети, называемому XKS Proxy. XKS Proxy – это спецификация API с открытым исходным кодом, которая поможет вам и вашему поставщику сервисов управления ключами создать сервис, принимающий эти запросы и направляющий их в вашу инфраструктуру управления ключами для использования ее ключей для шифрования и дешифрования.

Thales, Entrust, Atos, Fortanix, DuoKey, Securonix, Utimaco, Salesforce, T-Systems и HashiCorp предлагают решения, интегрированные со спецификацией XKS Proxy. Информацию о доступности, ценах и о том, как использовать решения этих поставщиков, см. в соответствующей документации. Мы призываем вас и вашего партнера по инфраструктуре управления ключами использовать спецификацию XKS Proxy с открытым исходным кодом для создания решения, отвечающего вашим потребностям. Спецификация API для XKS Proxy опубликована здесь.

Внешние ключи поддерживают следующие операции симметричного шифрования: Encrypt, ReEncrypt, Decrypt и GenerateDataKey.

Вы можете использовать ключи XKS для шифрования данных в любом сервисе AWS, который интегрируется с AWS KMS, используя управляемые клиентом ключи. Список поддерживаемых сервисов см. здесь. Сервисы AWS вызывают AWS KMS GenerateDataKey API для запроса уникального ключа данных в виде простого текста для шифрования ваших данных. Ключ данных в открытом виде возвращается в сервис вместе с зашифрованной копией ключа данных, которая будет храниться вместе с вашими зашифрованными данными. Чтобы создать зашифрованную копию ключа данных, ключ данных в открытом виде сначала шифруется ключом, хранящимся в AWS KMS, уникальным для вашего аккаунта AWS. Этот зашифрованный ключ данных затем передается в вашу реализацию XKS Proxy, подключенную к внешнему менеджеру ключей, чтобы быть зашифрованным во второй раз под ключом, который вы определяете в вашем внешнем менеджере ключей. Полученный ключ данных с двойным шифрованием возвращается в ответе на запрос API GenerateDataKey.

Сетевое соединение между AWS KMS, вашей реализацией XKS Proxy и внешним менеджером ключей должно быть защищено протоколом шифрования «точка–точка», например TLS. Однако, чтобы защитить ваши данные, покидающие AWS KMS, пока они не достигнут вашего внешнего менеджера ключей, AWS KMS сначала шифрует их внутренне управляемым ключом KMS в вашем аккаунте, определенным для каждого ключа KMS, определенного в вашем внешнем хранилище ключей. Полученный зашифрованный текст передается внешнему менеджеру ключей, который шифрует его с помощью ключа, находящегося в вашем внешнем менеджере ключей. Двойное шифрование обеспечивает контроль безопасности, что ни один зашифрованный текст не может быть расшифрован без использования ключевого материала во внешнем менеджере ключей. Оно также обеспечивает контроль безопасности, что зашифрованный текст, покидающий сеть AWS, шифруется с помощью модулей HSM AWS KMS, сертифицированных по стандарту FIPS 140. Поскольку внешний менеджер ключей должен использоваться для расшифровки данных, если вы отмените доступ к AWS KMS, ваши основные зашифрованные данные станут недоступны.

Да. Ключи XKS также могут использоваться из ваших собственных приложений при использовании решения симметричного шифрования на стороне клиента, которое использует AWS KMS в качестве поставщика ключей. Решения AWS для шифрования на стороне клиента с открытым исходным кодом, такие как AWS Шифрование SDK, Клиент шифрования S3 и Клиент шифрования Amazon DynamoDB, поддерживают ключи XKS.

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

Вы можете повторно зашифровать существующие данные под вновь созданные ключи XKS, если сервис AWS или ваше собственное приложение поддерживает это действие. Многие сервисы AWS помогут вам скопировать зашифрованный ресурс и назначить новый ключ KMS, который будет использоваться для шифрования копии. Вы можете настроить ключ XKS в команде COPY, предоставляемой сервисом AWS. Вы можете повторно зашифровать данные на стороне клиента в собственных приложениях, вызвав KMS ReEncrypt API и настроив ключ XKS.

Принцип оплаты для ключей XKS, как и для всех ключей под управлением клиента, – 1 USD в месяц за каждый ключ до тех пор, пока они не будут удалены. Запросы с ключами XKS оплачиваются по той же ставке, что и с любым другим симметричным ключом AWS KMS. Подробнее о стоимости см. на странице цен AWS KMS.

Да. Автоматическая ротация ключей предусмотрена спецификацией XKS и обеспечивается большинством производителей, поддерживающих XKS. Автоматическая ротация ключей XKS происходит полностью во внешнем менеджере ключей и работает аналогично автоматической ротации ключей AWS KMS, созданных в KMS и управляемых им. При использовании подвергшегося ротации ключа KMS XKS для шифрования данных внешний менеджер ключей использует текущий материал ключа. Когда вы используете подвергшийся ротации ключ XKS для расшифровки зашифрованного текста, ваш внешний менеджер ключей применяет ту версию материала ключа, которая была использована для его шифрования. До тех пор, пока предыдущие ключи XKS, использованные для создания предыдущих зашифрованных текстов, все еще доступны в вашем внешнем менеджере ключей, вы сможете успешно выполнить запрос Decrypt API с этими версиями ключей XKS.

Для сервисов, которые не кэшируют ключи, следующий вызов API с использованием этого ключа XKS KMS будет неудачным. Некоторые сервисы реализуют кэширование ключей данных или другие схемы получения ключей для обеспечения производительности, задержки или управления расходами KMS. Кэширование этих ключей может варьироваться от 5 минут до 24 часов. Любой защищенный ресурс, который используется в данный момент (например, база данных RDS или инстанс EC2), будет реагировать по-разному после того, как вы запретите доступ к ключу. Подробности см. в документации соответствующего сервиса AWS.

Для аутентификации на прокси-сервере внешнего хранилища ключей AWS KMS подписывает все запросы к прокси, используя учетные данные AWS SigV4, которые вы настраиваете на прокси и предоставляете KMS. AWS KMS проверяет подлинность прокси-сервера внешнего хранилища ключей с помощью TLS-сертификатов на стороне сервера. По желанию, ваш прокси-сервер может включить взаимный TLS для дополнительной гарантии того, что он принимает запросы только от AWS KMS.

Все обычные механизмы авторизации AWS KMS (политики IAM, политики ключей AWS KMS и гранты), которые вы используете с другими ключами KMS, работают так же и для ключей KMS во внешних хранилищах ключей.

Кроме того, вы и (или) ваши внешние партнеры по управлению ключами имеют возможность реализовать вторичный уровень контроля авторизации на основе метаданных запроса, включенных в каждый запрос, отправленный из AWS KMS в XKS Proxy. Эти метаданные включают вызывающего пользователя/роль AWS, ARN ключа KMS и конкретный API KMS, который был запрошен. Это позволяет вам применять тонкую политику авторизации для использования ключа в вашем внешнем менеджере ключей, не ограничиваясь простым доверием любому запросу от AWS KMS. Выбор применения политики с использованием этих атрибутов запроса остается на усмотрение вашей индивидуальной реализации XKS Proxy.

Уникальный идентификатор, генерируемый для каждого запроса, поступающего в AWS KMS с использованием ключей XKS, также передается прокси-серверу XKS. Вы можете использовать данные журнала (если они доступны) от XKS Proxy или внешнего менеджера ключей для сверки запросов, сделанных к AWS KMS, с запросами, сделанными к вашему внешнему менеджеру ключей. Эта функция позволяет вам проверить, что все запросы на использование ключей в вашем внешнем менеджере ключей исходят от звонка, инициированного вами в AWS KMS напрямую или через интегрированный сервис AWS.

Риск доступности. Вы несете ответственность за доступность XKS Proxy и внешних материалов ключей. Эта система должна обладать высокой доступностью для проверки того, что всякий раз, когда вам понадобится ключ XKS для расшифровки зашифрованного ресурса или шифрования новых данных, AWS KMS сможет успешно подключиться к XKS Proxy, который, в свою очередь, сможет подключиться к вашему внешнему менеджеру ключей для выполнения необходимой криптографической операции с использованием ключа. Например, предположим, что вы зашифровали том EBS с помощью ключа XKS и теперь хотите запустить инстанс EC2 и подключить этот зашифрованный том. Сервис EC2 передаст уникальный зашифрованный ключ данных для этого тома в AWS KMS для расшифровки, чтобы его можно было разместить в энергозависимой памяти карты Nitro для расшифровки и шифрования операций чтения/записи к этому тому. Если XKS Proxy или внешний менеджер ключей недоступен для расшифровки ключа тома, ваш инстанс EC2 не запустится. В таких случаях AWS KMS возвращает исключение KMSInvalidStateException о том, что сервер XKS Proxy недоступен. Теперь вам предстоит определить, почему XKS Proxy и менеджер ключей недоступны, основываясь на сообщениях об ошибках, предоставленных KMS.

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

Риск производительности. Вы несете ответственность за проверку того, что ваша инфраструктура XKS Proxy и инфраструктура внешнего хранилища ключей разработана с достаточными характеристиками производительности для удовлетворения ваших потребностей. Поскольку каждый запрос с использованием ключей XKS требует соединения с вашим внешним хранилищем ключей, XKS Proxy может стать уязвимым местом, если скорость запросов от AWS KMS превысит скорость запросов, которую может поддерживать ваш XKS Proxy или внешний менеджер ключей. Кроме того, если время выполнения одного запроса (включая одну повторную попытку) от AWS KMS к XKS Proxy занимает более 500 мс*, AWS KMS вернет вызывающему клиенту ошибку 400, фактически сообщая, что ваш XKS-ключ недоступен и вызывающему клиенту не следует повторять попытку. Такое поведение призвано минимизировать риск того, что вышестоящие сервисы AWS или ваши собственные приложения будут вынуждены реагировать на спорадические чрезмерные задержки, вызванные проблемами с подключением к вашей инфраструктуре.

* AWS KMS будет пытаться выполнить одну повторную попытку для любого запроса, который занимает 250 мс. Если повторный запрос также занимает более 250 мс, вызывающему клиенту будет возвращена ошибка 400.

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