Надежность управляемого HSM в Azure Key Vault

Azure Key Vault Managed HSM — это полностью управляемая, высокодоступная, однотенантная облачная служба, совместимая со стандартами, которая позволяет защитить криптографические ключи для облачных приложений с помощью аппаратных модулей безопасности (HSM), которые проверяются на fiPS 140-3 уровня 3. Управляемый модуль HSM предоставляет ряд встроенных функций надежности, которые помогут обеспечить доступность ключей.

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

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

Рекомендации по развертыванию в производственной среде

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

• Скачайте и надежно сохраните домен безопасности сразу после создания управляемого HSM. Вам нужен домен безопасности для аварийного восстановления.
• Установите многосторонний кворум для домена безопасности как минимум с тремя держателями ключей.
• Включите защиту очистки , чтобы предотвратить случайное или вредоносное удаление.
• Реализуйте регулярные резервные копии в учетную запись хранения Azure и используйте геоизбыточное хранилище в поддерживаемых регионах.
• Включите многорегионную репликацию для критически важных рабочих нагрузок, требующих более высокого уровня обслуживания.

Обзор архитектуры надежности

Когда вы используете управляемый модуль HSM, вы развертываете экземпляр, который также иногда называют пулом.

Архитектура Managed HSM разработана для обеспечения высокой доступности и отказоустойчивости.

• Изоляция одного клиента: Каждый управляемый экземпляр HSM предназначен для одного клиента и состоит из кластера нескольких секций HSM, которые криптографически изолированы.

• Разделы с тройным резервированием: Управляемый пул HSM состоит из трех разделов HSM с балансировкой нагрузки, размещенных в отдельных стойках в пределах одного центра обработки данных. Это распределение обеспечивает избыточность при сбоях оборудования и гарантирует, что потеря одного компонента, например питания стойки или сетевого коммутатора, не влияет на все секции.

• Конфиденциальные вычисления: Каждый экземпляр службы выполняется в доверенной среде выполнения (TEE), которая использует анклавы Intel SGX. Сотрудники Microsoft, в том числе сотрудники, имеющие физический доступ к серверам, не могут получить доступ к вашим ключевым материалам.

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

Сведения о том, как управляемый модуль HSM реализует эти возможности, см. в статье "Основные суверенитет", "Доступность", "Производительность" и масштабируемость в управляемом HSM.

Домен безопасности

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

Important

Без домена безопасности аварийное восстановление невозможно. Корпорация Майкрософт не может восстановить домен безопасности и не может получить доступ к вашим ключам без него.

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

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

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

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

Для получения дополнительной информации см. раздел «Обзор управляемых HSM: Домен безопасности».

Устойчивость к временным сбоям

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

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

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

Если вы создаете пользовательские приложения, которые интегрируются с управляемым HSM, рассмотрите следующие рекомендации по обработке временных сбоев, которые могут возникнуть:

• Используйте предоставленные Корпорацией Майкрософт пакеты SDK для Azure Key Vault, которые включают встроенные механизмы повторных попыток. Пакеты SDK доступны для .NET, Python и JavaScript.

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

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

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

Чтобы масштабировать шифрование больших томов данных, используйте иерархию ключей. Храните только ключ шифрования ключей (KEK) в управляемом HSM и используйте его для упаковки ключей шифрования данных нижнего уровня, хранящихся в другом месте в защищенном хранилище ключей.

Дополнительные сведения о показателях производительности и планировании ресурсов см. в руководстве по масштабированию Azure Managed HSM.

Устойчивость к разделению сети

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

В верхней части схемы находится контроллер структуры HSM. Три стрелки с подписью «операции восстановления службы», каждая из которых указывает вниз на одну из трех физических серверных стоек. Под тремя блоками физических серверов расположена большая замкнутая область, занимающая всю ширину схемы. Эта область помечена криптографической границей клиента. Внутри этой границы три контейнера расположены по горизонтали, каждый расположен непосредственно под одним из физических ящиков сервера. Каждый контейнер содержит экземпляр HSM, сертифицированный по стандарту FIPS 140-2 на уровне 3, а также анклав TEE SGX. Три блока TEE попарно соединены двунаправленными стрелками с меткой «attested TLS».

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

Cost

Встроенная в Managed HSM функция высокой доступности не влечет дополнительных затрат. Цены основаны на количестве пулов HSM и количестве выполняемых операций. Дополнительные сведения см. в статье о ценах на управляемый HSM в Azure.

Поведение, когда все разделы исправны

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

• Маршрутизация трафика: Управляемый модуль HSM автоматически управляет маршрутизацией трафика в трех разделах. Во время обычных операций он прозрачно распределяет запросы между секциями.

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

Поведение во время сбоя раздела

В этом разделе описывается, что ожидать, когда один или несколько разделов становятся недоступными.

• Обнаружение и ответ: Управляемая служба HSM обнаруживает сбои секций и автоматически реагирует на них. Во время сбоя раздела не нужно предпринимать никаких действий.

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

• Ожидаемая потеря данных: Потеря данных не ожидается во время сбоя секции из-за синхронной репликации между секциями.

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

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

Восстановление разделов

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

1. Создает новый экземпляр службы на работоспособном оборудовании.
2. Устанавливает подтвержденное подключение TLS к первичной секции.
3. Безопасно обменивают учетные данные и криптографические материалы.
4. Привязывает данные службы к новому ЦП.

Платформа Azure полностью управляет этим процессом и не требует вмешательства клиента.

Устойчивость к сбоям зоны доступности

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

Чтобы защититься от сбоев на уровне всей зоны обработки данных или доступности, используйте один из подходов, описанных в статье " Устойчивость к сбоям на уровне региона".

Устойчивость к сбоям на уровне региона

Управляемые ресурсы HSM развертываются в одном регионе Azure. Если регион становится недоступным, управляемый HSM также недоступен. Однако существуют подходы, которые можно использовать для обеспечения устойчивости к сбоям регионов.

Репликация с несколькими агрегатами

Управляемый модуль HSM поддерживает необязательную многорегионную репликацию, которую можно использовать для расширения пула управляемого модуля HSM из одного Azure региона (основного региона) до второго Azure региона (расширенный регион). При настройке этой функции:

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

Requirements

• Поддержка региона: Все регионы, поддерживающие управляемый HSM, можно использовать в качестве основных регионов. Нет зависимости от пар регионов Azure.

  Управляемый модуль HSM не поддерживает все регионы как расширенные регионы. Дополнительные сведения см. в разделе поддержки региона Azure.

• Максимальное число регионов: Можно добавить один расширенный регион не более двух регионов в общей сложности.

Cost

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

Настройка многорегионной репликации

• Добавьте расширенный регион: Дополнительные сведения о добавлении расширенного региона в существующий основной регион см. в разделе "Расширение основного устройства HSM" в расширенный регион.

  Расширение управляемого модуля HSM в другом регионе может занять до 30 минут.

• Удалите расширенный регион: Дополнительные сведения об удалении расширенного региона из существующего основного региона см. в разделе "Удаление расширенного региона" из основного устройства HSM.

Поведение, когда все регионы работоспособны

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

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

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

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

Поведение во время сбоя региона

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

• Обнаружение и ответ: Диспетчер трафика Azure обнаруживает неработоспособный регион и направляет будущие запросы в здоровый регион. Записи DNS имеют TTL 5 секунд, хотя клиенты, кэширующие результаты DNS-запросов, могут столкнуться с немного более длительным временем переключения при отказе.

• Уведомление: Microsoft не уведомляет вас автоматически об отключении региона. Однако вы можете использовать Работоспособность служб Azure, чтобы понять общее состояние службы, включая сбои в любом регионе, и настроить оповещения Service Health для уведомления о проблемах.

• Активные запросы: Выполняющиеся запросы в затронутом регионе могут завершиться ошибкой, и их потребуется повторить.

• Ожидаемая потеря данных: Изменения, внесенные в течение шести минут до сбоя региона, могут не реплицироваться в расширенный регион. Эти изменения могут быть потеряны, если основной регион неустраним.

• Ожидаемое время простоя: Операции чтения и записи сохраняются доступными в исправном регионе во время переключения на резерв.

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

• Перенаправление: Диспетчер трафика Azure автоматически перенаправляет запросы в здоровый регион.

Восстановление региона

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

Проверка сбоев в регионе

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

Кастомные многорегиональные решения для повышения отказоустойчивости

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

• Домен безопасности исходного HSM.
• Закрытые ключи (по крайней мере номер кворума), которые шифруют домен безопасности.
• Последняя полная резервная копия HSM из исходного HSM .

Чтобы выполнить аварийное восстановление:

1. Создайте новый управляемый экземпляр HSM в другом регионе.
2. Активируйте режим восстановления домена безопасности и отправьте домен безопасности.
3. Создайте резервную копию нового устройства HSM (требуется перед восстановлением).
4. Восстановите резервную копию из исходного HSM.

Important

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

Подробные процедуры аварийного восстановления см. в разделе "Управляемое аварийное восстановление HSM".

Резервное копирование и восстановление

Управляемый HSM поддерживает полное резервное копирование и восстановление всех ключей, версий, атрибутов, тегов и назначений ролей. Резервные копии хранятся в учетной записи хранения Azure. Если это поддерживается в вашем регионе, мы рекомендуем создать резервную копию управляемого модуля HSM в учетной записи служба хранилища Azure с включённым геоизбыточным хранилищем (GRS).

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

Управляемый модуль HSM не поддерживает планирование резервных копий, но вы можете создать собственный планировщик с помощью службы, такой как Функции Azure или служба автоматизации Azure.

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

Подробные процедуры резервного копирования и восстановления см. в разделе "Полное резервное копирование и восстановление".

Устойчивость к случайному удалению

Управляемый модуль HSM предоставляет две функции восстановления ключей, чтобы предотвратить случайное или вредоносное удаление.

• Обратимое удаление: Удаленные HSM и ключи не сразу очищаются. Они остаются восстанавливаемыми для настраиваемого периода хранения от 7 до 90 дней (по умолчанию: 90 дней). Мягкое удаление всегда включено и не может быть отключено.

  Замечание

  Мягко удаленные управляемые ресурсы HSM продолжают его начисление до тех пор, пока они не будут удалены.

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

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

Устойчивость к обслуживанию служб

Управляемый модуль HSM обрабатывает обслуживание служб, включая обновления встроенного ПО, исправление и восстановление оборудования без вмешательства клиента. Во время обслуживания:

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

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

Соглашение об уровне обслуживания

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

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

Связанный контент

• Что такое управляемый HSM в Azure Key Vault?
• Включение многорегионной репликации
• Аварийное восстановление управляемого устройства HSM
• Полное резервное копирование и восстановление
• Общие сведения о домене безопасности в управляемом HSM
• Защита от обратимого удаления и очистки управляемого устройства HSM
• Руководство по масштабированию управляемого устройства HSM в Azure
• Что такое документация по надежности Azure?