Использование собственного ключа (BYOK) для существующих развертываний Elastic Cloud

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

Функция использования собственного ключа (BYOK) для существующих развертываний теперь общедоступна в Elastic Cloud Hosted. Вы можете добавить управляемый клиентом ключ шифрования в уже работающее развертывание через консоль Elastic Cloud или API, при этом развертывание останется доступным в процессе выполнения операции. Ранее ключ можно было задать только при создании развертывания, что означало, что требование по управлению ключами, возникшее позже, превращалось в миграцию развертывания.

Ранее в этой серии мы рассмотрели фундаментальные концепции шифрования данных в состоянии покоя и разобрали, как использовать собственный ключ в развертываниях Elastic Cloud Hosted с помощью AWS KMS, Azure Key Vault и Google Cloud KMS. Область применения была ограничена новыми развертываниями. Теперь мы расширили ее, чтобы повысить удобство использования, включив существующие развертывания. В этом блоге рассказывается о том, что изменилось, как работает процесс перехода «на месте» и что следует учесть перед шифрованием производственного развертывания.

Почему до сих пор для BYOK требовалось новое развертывание

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

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

Таким образом, BYOK был эффективен, но имел ограниченное влияние.

Как работает BYOK в существующем развертывании

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

Службы управления ключами, поддерживаемые для новых развертываний, работают и здесь: AWS KMS, Azure Key Vault и Google Cloud KMS. Как только переход завершится, развертывание будет вести себя точно так же, как если бы оно было создано с BYOK с самого начала. Ротации ключей, которые вы выполняете в своем KMS, подхватываются автоматически, а отзыв ключа остается вашим экстренным средством контроля. Отзовите его, и Elastic Cloud заблокирует каталоги данных развертывания максимум в течение 30 минут. Пока он заблокирован, развертывание сохраняет все свои данные, но они недоступны для чтения или записи, а восстановление доступа к ключу в вашем KMS возвращает его в онлайн. Если доступ так и не будет восстановлен, данные фактически будут криптографически уничтожены, как и ожидалось.

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

Предварительные требования

• Ключ, который вы контролируете в KMS вашего облачного провайдера, настроенный с политикой доступа, позволяющей Elastic Cloud использовать его. В предыдущих блогах этой серии этот шаг подробно описан для AWS KMS, Azure Key Vault и Google Cloud KMS. Ничего в процессе создания ключа для существующих развертываний не меняется.

Ключ, который вы контролируете в KMS вашего облачного провайдера, настроенный с политикой доступа, позволяющей Elastic Cloud использовать его. В предыдущих блогах этой серии этот шаг подробно описан для AWS KMS, Azure Key Vault и Google Cloud KMS. Ничего в процессе создания ключа для существующих развертываний не меняется.

• Подписка Enterprise — те же условия соответствия, что и для BYOK в новых развертываниях. Если опция не отображается для вашего развертывания, обратитесь в службу поддержки Elastic.

Подписка Enterprise — те же условия соответствия, что и для BYOK в новых развертываниях. Если опция не отображается для вашего развертывания, обратитесь в службу поддержки Elastic.

• Ключ в том же облачном провайдере, что и ваше развертывание, доступный в каждом регионе, где работает развертывание. Для развертывания в AWS нужен ключ AWS KMS, для развертывания в Azure — ключ Azure Key Vault, а для развертывания в Google Cloud — ключ Cloud KMS в однорегиональном кольце ключей в регионе развертывания. Многорегиональные кольца ключей отклоняются.

Ключ в том же облачном провайдере, что и ваше развертывание, доступный в каждом регионе, где работает развертывание. Для развертывания в AWS нужен ключ AWS KMS, для развертывания в Azure — ключ Azure Key Vault, а для развертывания в Google Cloud — ключ Cloud KMS в однорегиональном кольце ключей в регионе развертывания. Многорегиональные кольца ключей отклоняются.

• Отсутствие политики управления жизненным циклом индекса (ILM), которая называет found-snapshots репозиторием снимков в холодной (cold) или замороженной (frozen) фазе. Если такая политика существует, миграция будет отклонена еще до начала, и поскольку found-snapshots — это репозиторий, который получает каждый кластер Elastic Cloud Hosted по умолчанию, это затрагивает больше развертываний, чем вы могли бы ожидать. Проверка считывает сами политики, а не индексы, использующие их, поэтому определенная, но неиспользуемая политика все равно заблокирует вас. Выполните GET _ilm/policy и найдите phases.cold.actions.searchable_snapshot.snapshot_repository или аналогичный параметр для замороженной фазы, чтобы узнать текущее состояние.

Отсутствие политики управления жизненным циклом индекса (ILM), которая называет found-snapshots репозиторием снимков в холодной (cold) или замороженной (frozen) фазе. Если такая политика существует, миграция будет отклонена еще до начала, и поскольку found-snapshots — это репозиторий, который получает каждый кластер Elastic Cloud Hosted по умолчанию, это затрагивает больше развертываний, чем вы могли бы ожидать. Проверка считывает сами политики, а не индексы, использующие их, поэтому определенная, но неиспользуемая политика все равно заблокирует вас. Выполните GET _ilm/policy и найдите phases.cold.actions.searchable_snapshot.snapshot_repository или аналогичный параметр для замороженной фазы, чтобы узнать текущее состояние.

Шифрование существующего развертывания с помощью вашего ключа

Как только ваш ключ готов, переход в консоли Elastic Cloud выполняется в три этапа:

• Перейдите на страницу безопасности (Security) вашего развертывания.

Перейдите на страницу безопасности (Security) вашего развертывания.

• В разделе «Шифрование данных в состоянии покоя» (Encryption at rest) выберите «Управление ключом шифрования» (Manage encryption key).

В разделе «Шифрование данных в состоянии покоя» (Encryption at rest) выберите «Управление ключом шифрования» (Manage encryption key).

• Введите идентификатор вашего ключа (ARN для AWS, идентификатор ключа для Azure или идентификатор ресурса для Google Cloud) и сохраните изменения.

Введите идентификатор вашего ключа (ARN для AWS, идентификатор ключа для Azure или идентификатор ресурса для Google Cloud) и сохраните изменения.

Затем Elastic Cloud применяет изменение плана для шифрования ваших данных и снимков состояния. Страница обзора (Overview) вашего развертывания отслеживает процесс во время его выполнения, сообщая, сколько экземпляров было повторно зашифровано, а отдельные экземпляры получают маркер «Зашифровано» (Encrypted) по мере завершения. Если вы хотите увидеть базовые шаги плана, баннер содержит ссылку на страницу активности (Activity).

Вы также можете сделать это через Elastic Cloud API, что является лучшим вариантом, если вы внедряете BYOK для большого количества развертываний. Существующие развертывания используют выделенную конечную точку POST /api/v1/deployments/{deployment_id}/byok-migration с идентификатором вашего ключа в теле запроса. В документации к продукту описаны необходимые роли, возвращаемые ошибки и способы опроса для проверки завершения.

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

Рекомендации перед началом работы

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

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

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

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

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

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

• Дождитесь завершения процесса шифрования. Отмена изменений на полпути приведет к тому, что развертывание останется частично зашифрованным, и вам потребуется связаться со службой поддержки Elastic для завершения процесса.

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

• Учитывайте, что для очень крупных развертываний процесс может занять время — от нескольких часов до более чем полных суток, особенно при объеме данных свыше 1 ТБ.

Учитывайте, что для очень крупных развертываний процесс может занять время — от нескольких часов до более чем полных суток, особенно при объеме данных свыше 1 ТБ.

• Заложите бюджет на расходы по передаче данных в вашем аккаунте облачного провайдера. Ожидается, что для развертываний Elasticsearch 8.x и более поздних версий эти расходы будут низкими.

Заложите бюджет на расходы по передаче данных в вашем аккаунте облачного провайдера. Ожидается, что для развертываний Elasticsearch 8.x и более поздних версий эти расходы будут низкими.

Проверка и устранение неполадок

Вы можете подтвердить состояние шифрования на странице безопасности (Security) развертывания. Выберите «Управление ключом шифрования» (Manage encryption key) в разделе «Шифрование данных в состоянии покоя» (Encryption at rest), и там должен быть указан идентификатор вашего ключа.

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

Начало работы с BYOK в ваших развертываниях

BYOK больше не является решением, которое нужно принимать в первый же день. Если у вас есть развертывания Elastic Cloud Hosted с подпиской Enterprise, вы можете зашифровать их с помощью собственного ключа уже сегодня, на месте, без необходимости что-либо воссоздавать.

Начните со страницы безопасности (Security) вашего развертывания и ознакомьтесь с документацией к продукту для получения полной информации. Если вы настраиваете ключ впервые, в предыдущих публикациях этой серии подробно описаны процессы для AWS KMS, Azure Key Vault и Google Cloud KMS.

Часто задаваемые вопросы

Можно ли включить BYOK для существующего развертывания Elastic Cloud? Да. Вы можете добавить ключ шифрования, управляемый клиентом, к работающему развертыванию Elastic Cloud Hosted со страницы безопасности развертывания или через Elastic Cloud API. Ранее BYOK можно было настроить только при создании нового развертывания. Эта возможность является общедоступной и требует подписки Enterprise.

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

Какие службы управления ключами поддерживаются? AWS KMS, Azure Key Vault и Google Cloud KMS. KMS должен соответствовать облачному провайдеру, на котором работает ваше развертывание, а ключ должен быть доступен в каждом регионе, используемом развертыванием. Например, для развертывания, размещенного в AWS, требуется ключ AWS KMS.

Что происходит с существующими снимками состояния при включении BYOK? Новые снимки шифруются вашим ключом. Существующие снимки не переносятся: после перехода found-snapshots указывает на новый зашифрованный бакет, а снимки, сделанные до этого, больше не доступны через этот репозиторий. По завершении план автоматически создает новый снимок в зашифрованном бакете. Если у вас есть обязательства по хранению или соблюдению нормативных требований в отношении снимков до миграции, разберитесь с ними до начала процесса.

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

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