Вопросы и ответы по AWS Key Management Service

Сервис 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).

При использовании типов ключей с эллиптическими кривыми AWS KMS поддерживает алгоритмы согласования ключей ECDH.

Для ключей типа 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 настроен вами для шифрования данных внутри сервиса.