Суверенитет ключей, доступность, производительность и масштабируемость в управляемом HSM
Криптографические ключи являются корнем доверия для защиты современных компьютерных систем, будь то локальные или в облаке. Таким образом, контроль над тем, кто имеет полномочия над этими ключами, критически важен для создания безопасных и совместимых приложений.
В Azure наше видение того, как следует выполнять управление ключами в облаке, является ключевым суверенитетом. Суверенитет ключей означает, что организация клиента имеет полный и эксклюзивный контроль над тем, кто может получить доступ к ключам и изменить политики управления ключами, а также о том, какие службы Azure используют эти ключи. После принятия этих решений сотрудники Корпорации Майкрософт не могут изменять эти решения техническими средствами. Код службы управления ключами выполняет решения клиента до тех пор, пока клиент не сообщит ему об этом, и персонал Майкрософт не сможет вмешиваться.
В то же время мы считаем, что каждая служба в облаке должна полностью управляться. Служба должна обеспечить необходимую доступность, устойчивость, безопасность и фундаментальные обещания облака, поддерживаемые соглашениями об уровне обслуживания (SLA). Чтобы обеспечить управляемую службу, корпорация Майкрософт должна исправить серверы управления ключами, обновить встроенное ПО аппаратного модуля безопасности (HSM), исцелить оборудование, выполнить отработку отказа и выполнить другие операции с высоким уровнем привилегий. Как известно большинству специалистов по безопасности, отказ от кого-то с высоким уровнем привилегий или физическим доступом к системе доступа к данным в этой системе является сложной проблемой.
В этой статье объясняется, как решить эту проблему в управляемой службе HSM в Azure Key Vault, предоставляя клиентам полный суверенитет ключей и полностью управляемые соглашения об уровне обслуживания, используя технологии конфиденциальных вычислений, сопряженные с HSM.
Управляемая среда оборудования HSM
Управляемый пул HSM клиента в любом регионе Azure находится в защищенном центре обработки данных Azure. Три экземпляра распределяются по нескольким серверам. Каждый экземпляр развертывается в разной стойке, чтобы обеспечить избыточность. Каждый сервер имеет FIPS 140-2 уровня 3 , проверенный адаптер Marvell LiquidSecurity HSM с несколькими криптографическими ядрами. Ядра используются для создания полностью изолированных секций HSM, включая полностью изолированные учетные данные, хранилище данных и управление доступом.
Физическое разделение экземпляров в центре обработки данных имеет решающее значение для обеспечения потери одного компонента (например, коммутатора верхнего уровня или блока управления питанием в стойке) не может повлиять на все экземпляры пула. Эти серверы выделены команде HSM безопасности Azure. Серверы не совместно используются другими командами Azure, а рабочие нагрузки клиентов не развертываются на этих серверах. Средства управления физическим доступом, включая заблокированные стойки, используются для предотвращения несанкционированного доступа к серверам. Эти элементы управления соответствуют fedRAMP-High, PCI, SOC 1/2/3, ISO 270x и другим стандартам безопасности и конфиденциальности, и регулярно проверяются в рамках программы соответствия Требованиям Azure. HSM имеют улучшенную физическую безопасность, проверенную в соответствии с требованиями FIPS 140-2 уровня 3. Вся служба управляемого устройства HSM построена на основе стандартной защищенной платформы Azure, включая доверенный запуск, который защищает от сложных постоянных угроз.
Адаптеры HSM могут поддерживать десятки изолированных секций HSM. Выполнение на каждом сервере — это процесс управления с именем "Служба узлов". Служба узлов владеет каждым адаптером и устанавливает учетные данные для владельца адаптера, в этом случае Корпорация Майкрософт. Модуль HSM разработан таким образом, чтобы владение адаптером не предоставило корпорации Майкрософт доступ к данным, хранящимся в разделах клиентов. Она позволяет только корпорации Майкрософт создавать, изменять размер и удалять секции клиентов. Она поддерживает выполнение слепых резервных копий любой секции для клиента. В слепой резервной копии резервная копия упаковывается клиентом с помощью ключа, который можно восстановить с помощью кода службы только в управляемом экземпляре HSM, принадлежащее клиенту, и содержимое которого недоступно для чтения корпорацией Майкрософт.
Архитектура управляемого пула HSM
На рисунке 1 показана архитектура пула HSM, состоящего из трех виртуальных машин Linux, каждый из которых работает на сервере HSM в собственной стойке центра обработки данных для поддержки доступности. Важные компоненты:
- Контроллер структуры HSM (HFC) — это плоскость управления для службы. HFC управляет автоматическим исправлением и ремонтом пула.
- Граница шифрования, совместимая с FIPS 140-2 уровня 3, исключаемая для каждого клиента, включая три конфиденциальных анклава Intel Secure Guard (Intel SGX), каждый из которых подключен к экземпляру HSM. Корневые ключи для этой границы создаются и хранятся в трех виртуальных машинах HSM. Как описано далее в этой статье, ни пользователь, связанный с Корпорацией Майкрософт, не имеет доступа к данным, которые находится в пределах этой границы. Только код службы, работающий в анклаве Intel SGX (включая агент службы узлов), действующий от имени клиента, имеет доступ.
Надежная среда выполнения (TEE)
Управляемый пул HSM состоит из трех экземпляров службы. Каждый экземпляр службы реализуется в виде доверенной среды выполнения (TEE), которая использует возможности Intel SGX и пакет SDK Open Enclave. Выполнение в TEE гарантирует, что ни один пользователь на виртуальной машине, на котором размещена служба, или сервер узла виртуальной машины имеет доступ к секретам клиента, данным или секции HSM. Каждый TEE предназначен для конкретного клиента, и он выполняет управление TLS, обработку запросов и управление доступом к секции HSM. Учетные данные или ключи шифрования данных, относящиеся к клиенту, не существуют в чистом тексте за пределами этого TEE, кроме как часть пакета домена безопасности. Этот пакет шифруется с ключом, предоставленным клиентом, и загружается при первом создании пула.
TEEs взаимодействуют между собой с помощью подтвержденного TLS. Аттестация TLS объединяет возможности удаленной аттестации платформы Intel SGX с TLS 1.2. Это позволяет управляемому коду HSM в TEE ограничить обмен данными только с другим кодом, подписанным тем же ключом подписывания кода управляемой службы HSM, чтобы предотвратить атаки в середине. Ключ подписи кода управляемой службы HSM хранится в выпуске и службе безопасности Microsoft Product (которая также используется для хранения ключа подписи кода Windows). Ключ управляется командой управляемого HSM. В рамках наших обязательств по регулированию и соответствию требованиям по управлению изменениями этот ключ не может использоваться любой другой командой Майкрософт для подписания своего кода.
Сертификаты TLS, используемые для обмена данными TEE-to-TEE, самостоятельно выдаются кодом службы внутри TEE. Сертификаты содержат отчет платформы, созданный анклавом Intel SGX на сервере. Отчет платформы подписывается ключами, производными от ключей, которые объединяются Intel в ЦП при его изготовлении. Отчет определяет код, загруженный в анклав Intel SGX своим ключом подписывания кода и двоичным хэшом. В этом отчете о платформе экземпляры служб могут определить, что одноранговый узел также подписан ключом подписывания кода управляемой службы HSM, и при использовании некоторых криптографических связей через отчет платформы он также может определить, что самозаверяющий ключ подписи сертификатов также должен быть создан внутри TEE, чтобы предотвратить внешнюю олицетворение.
Соглашения об уровне обслуживания доступности предложения с полным контролем ключей, управляемым клиентом
Чтобы обеспечить высокий уровень доступности, служба HFC создает три пула в выбранном клиентом регионе Azure.
Создание управляемого пула HSM
Свойства высокого уровня доступности управляемых пулов HSM приходят из автоматически управляемых, тройных избыточных экземпляров HSM, которые всегда хранятся в синхронизации (или, если вы используете многорегиональный реплика tion, от сохранения всех шести экземпляров в синхронизации). Создание пула управляется службой HFC, которая выделяет пулы между доступным оборудованием в регионе Azure, который выбирает клиент.
При запросе нового пула HFC выбирает три сервера на нескольких стойках, имеющих доступное пространство на адаптерах HSM, а затем начинает создавать пул:
HFC указывает агентам службы узлов на каждом из трех TEEs запустить новый экземпляр кода службы с помощью набора параметров. Параметры определяют клиент Microsoft Entra клиента, IP-адреса внутренней виртуальной сети всех трех экземпляров и некоторые другие конфигурации служб. Одна секция назначается случайным образом в качестве первичной.
Запуск трех экземпляров. Каждый экземпляр подключается к секции на локальном адаптере HSM, а затем инициализирует и инициализирует секцию с помощью случайно созданных имен пользователей и учетных данных (чтобы обеспечить доступ к секции с помощью оператора человека или другого экземпляра TEE).
Основной экземпляр создает корневой сертификат владельца секции с помощью закрытого ключа, созданного в HSM. Он устанавливает владение пулом путем подписывания сертификата уровня секции для секции HSM с помощью этого корневого сертификата. Основной также создает ключ шифрования данных, который используется для защиты всех неактивных данных клиента внутри службы. Для материала ключа используется двойная оболочка, так как HSM также защищает сам материал ключа.
Затем эти данные владения синхронизируются с двумя вторичными экземплярами. Каждый вторичный контакт основной с помощью подтвержденного TLS. Основной источник использует корневой сертификат владельца секции с закрытым ключом и ключом шифрования данных. Теперь вторичные файлы используют корневой сертификат секции для выдачи сертификата секции собственным секциям HSM. После этого у вас есть секции HSM на трех отдельных серверах, принадлежащих одному корневому сертификату секции.
По подтвержденной ссылке TLS основной секции HSM с созданными ключами-оболочками данных (используется для шифрования сообщений между тремя HSM) с помощью защищенного API, предоставленного поставщиком HSM. Во время этого обмена виртуальные машины HSM подтверждают, что они имеют один и тот же сертификат владельца секции, а затем используют схему Diffie-Hellman для шифрования сообщений, чтобы код службы Майкрософт не мог прочитать их. Все, что может сделать код службы, — это непрозрачные большие двоичные объекты между виртуальными машинами HSM.
На этом этапе все три экземпляра готовы предоставляться в виде пула в виртуальной сети клиента. Они используют один и тот же сертификат владельца секции и закрытый ключ, один и тот же ключ шифрования данных и общий ключ упаковки данных. Однако каждый экземпляр имеет уникальные учетные данные для секций HSM. Теперь завершаемые шаги завершены.
Каждый экземпляр создает пару ключей RSA и запрос на подписывание сертификатов (CSR) для его открытого сертификата TLS. CSR подписан системой инфраструктуры открытых ключей (PKI) Майкрософт с помощью общедоступного корневого каталога Майкрософт, а результирующий сертификат TLS возвращается экземпляру.
Все три экземпляра получают собственный ключ запечатывания Intel SGX из локального ЦП. Ключ создается с помощью собственного уникального ключа ЦП и ключа подписывания кода TEE.
Пул получает уникальный ключ пула от ключей запечатывания Intel SGX, шифрует все секреты с помощью этого ключа пула, а затем записывает зашифрованные BLOB-объекты на диск. Эти большие двоичные объекты можно расшифровать только с помощью кода, подписанного тем же ключом запечатывания Intel SGX, который работает на одном физическом ЦП. Секреты привязаны к конкретному экземпляру.
Теперь процесс безопасной начальной загрузки завершен. Этот процесс позволил как созданию пула HSM с тройным избыточным устройством HSM, так и созданию криптографической гарантии суверенитета данных клиента.
Обслуживание соглашений об уровне обслуживания доступности во время выполнения с помощью восстановления конфиденциальной службы
История создания пула, описанная в этой статье, может объяснить, как управляемая служба HSM может обеспечить высокий уровень обслуживания, безопасно управляя серверами, лежащими в основе службы. Представьте, что сервер, адаптер HSM или даже питание в стойку завершается ошибкой. Цель управляемой службы HSM — без вмешательства клиента или возможности предоставления секретов в чистом тексте за пределами TEE, чтобы восстановить пул до трех здоровых экземпляров. Это достигается путем восстановления конфиденциальной службы.
Он начинается с HFC, определяющее, какие пулы имели экземпляры на сервере сбоем. HFC находит новые, работоспособные серверы в регионе пула для развертывания экземпляров замены. Он запускает новые экземпляры, которые затем обрабатываются именно как вторичные во время начального этапа подготовки: инициализация HSM, поиск его основного, безопасного обмена секретами по протоколу TLS, подписывание HSM в иерархию владения, а затем запечатывание данных службы на новый ЦП. Служба теперь исцеляется, полностью автоматически и полностью конфиденциально.
Восстановление после аварии с помощью домена безопасности
Домен безопасности — это защищенный большой двоичный объект, содержащий все учетные данные, необходимые для перестроения секции HSM с нуля: ключ владельца секции, учетные данные секции, ключ упаковки данных, а также начальная резервная копия HSM. Прежде чем служба станет активной, клиент должен скачать домен безопасности, предоставив набор ключей шифрования RSA для его защиты. Данные домена безопасности создаются в TEEs и защищаются созданным симметричным ключом и реализацией алгоритма совместного использования секретов Шамира, который разделяет ключевые папки по открытым ключам RSA, предоставленным клиентом, в соответствии с параметрами кворума, выбранными клиентом. В ходе этого процесса ни один из ключей службы или учетных данных никогда не предоставляется в виде открытого текста за пределами кода службы, работающего в TEEs. Только клиент, предоставив кворум ключей RSA в TEE, может расшифровать домен безопасности во время сценария восстановления.
Домен безопасности необходим только в том случае, если из-за какой-то катастрофы весь регион Azure теряется, и корпорация Майкрософт теряет все три экземпляра пула одновременно. Если только один экземпляр или даже два экземпляра потеряны, то восстановление конфиденциальной службы будет тихо восстановлено до трех здоровых экземпляров без вмешательства клиента. Если весь регион потерян, так как ключи запечатывания Intel SGX уникальны для каждого ЦП, корпорация Майкрософт не может восстановить учетные данные HSM и ключи владельца секции. Они существуют только в контексте экземпляров.
В крайне маловероятном случае, что эта катастрофа, клиент может восстановить свое предыдущее состояние пула и данные, создав пустой пул, введя его в домен безопасности, а затем представить свой кворум ключа RSA, чтобы доказать владение доменом безопасности. Если клиент включил многорегионное реплика tion, то еще более маловероятной катастрофой обоих регионов, испытывающей одновременный, полный сбой должен произойти, прежде чем вмешательство клиента потребуется для восстановления пула из домена безопасности.
Управление доступом к службе
Как описано, наш код службы в TEE является единственной сущностью, которая имеет доступ к самому HSM, так как необходимые учетные данные не предоставлены клиенту или кому-либо другому. Вместо этого пул клиента привязан к экземпляру Microsoft Entra, и он используется для проверки подлинности и авторизации. При первоначальной подготовке клиент может выбрать начальный набор сотрудников, чтобы назначить роль Администратор istrator для пула. Эти лица и сотрудники в роли глобального Администратор istrator клиента клиента Microsoft Entra могут задавать политики управления доступом в пуле. Все политики управления доступом хранятся службой в той же базе данных, что и маскированные ключи, которые также шифруются. Только код службы в TEE имеет доступ к этим политикам управления доступом.
Итоги
Управляемый модуль HSM устраняет потребность клиентов в компромиссах между доступностью и контролем над криптографическими ключами с помощью передовых, аппаратных, конфиденциальных технологий анклава. Как описано в этой статье, в этой реализации сотрудники Майкрософт или представитель не могут получить доступ к материалу, управляемому клиентом, или связанным секретам, даже с физическим доступом к управляемым компьютерам hSM и HSM. Эта безопасность позволила нашим клиентам в финансовых услугах, производстве, государственном секторе, обороне и других вертикали ускорить миграцию в облако с полной уверенностью.