Microsoft AZ-801: Шифрование, сертификаты и PKI — Руководство по подготовке

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Часть Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Шифрование и инфраструктура открытых ключей (PKI) формируют основу доверия в гибридной среде, ориентированной на Windows Server. Администраторы должны уметь защищать неактивные данные с помощью BitLocker и EFS, создавать и эксплуатировать корпоративную PKI с помощью AD CS и Online Responder, автоматизировать жизненный цикл сертификатов с помощью шаблонов и автоматической регистрации, а также интегрировать облачное управление сертификатами через Azure Key Vault. В следующих разделах подробно рассматриваются архитектура, предварительные требования, шаблоны развертывания и операционные элементы управления, которые постоянно встречаются в реальных гибридных средах на базе Windows Server.

BitLocker и EFS в Windows Server

BitLocker Drive Encryption защищает тома, используя комбинацию TPM и средств защиты ключей. TPM 2.0 является текущей базовой рекомендацией; TPM 1.2 по-прежнему поддерживается, но TPM 2.0 с UEFI и Secure Boot обеспечивает более надежную привязку цепочки загрузки к регистрам конфигурации платформы (PCR) TPM. Для серверов требуйте использования TPM+PIN на томах с операционной системой, чтобы добавить онлайн-фактор, снижающий риски атак методом холодной перезагрузки и офлайн-атак. Это настраивается через групповую политику в разделе BitLocker Drive Encryption (Требовать дополнительную проверку подлинности при запуске; Разрешить использование расширенных PIN-кодов при запуске). При отсутствии TPM возможно использование USB-ключа для запуска, но это менее удобно в эксплуатации и менее безопасно.

Управление ключами восстановления является обязательным. В средах AD DS сохраняйте информацию для восстановления в объектах-компьютерах (msFVE-RecoveryInformation) с помощью групповой политики (Выберите способы восстановления дисков операционной системы, защищенных BitLocker; Сохранять пароли восстановления и пакеты ключей в AD DS). В сценариях с присоединением к Azure AD ключи восстановления сохраняются в объекте устройства Azure AD и доступны авторизованным администраторам в колонке Devices; политики Intune могут требовать обязательного сохранения в Azure AD. Проверяйте работоспособность сохранения ключей перед массовым включением шифрования.

Network Unlock устраняет необходимость ручного ввода PIN-кода для присоединенных к домену серверов в защищенных подсетях ЦОД во время автоматических перезагрузок. Предварительные требования включают тома ОС, защищенные TPM, прошивку UEFI, проводное подключение без блокировки по 802.1X на этапе предварительной загрузки, доступность широковещательных запросов DHCP и сервер Windows Deployment Services с функцией Network Unlock и сертификатом проверки подлинности сервера, выданным корпоративным ЦС с использованием шаблона Network Unlock. Настройте GPO для BitLocker, чтобы включить Network Unlock, и убедитесь, что OCSP/CRL центра сертификации доступны для сервера WDS. Network Unlock не применяется к мобильным или беспроводным хостам.

Предварительная подготовка (Pre-provisioning) ускоряет крупномасштабные развертывания за счет шифрования используемого пространства на раннем этапе, еще в среде Windows PE во время создания образа. В последовательностях задач MDT/Configuration Manager используйте шаг Pre-provision BitLocker (

undefined

), чтобы начать шифрование до полного развертывания ОС; переключитесь на полную защиту после присоединения к домену и применения политик.

Централизованно управляйте BitLocker с помощью Microsoft Endpoint Manager. Intune (MDM) принудительно включает фоновое шифрование с защитниками только на базе TPM для устройств, присоединенных к Azure AD, и сохраняет ключи в Azure AD; требование PIN-кода при запуске исключает фоновое шифрование и требует взаимодействия с пользователем. Для серверов, присоединенных к домену, и смешанных сред используйте Configuration Manager BitLocker Management (преемник MBAM) для отчетности о соответствии, сохранения ключей, порталов и ротации ключей. Всегда проектируйте систему с возможностью аудита сохранения ключей и сопоставления с владельцами.

EFS — это пофайловое шифрование, привязанное к EFS-сертификатам пользователя. Для каждого файла генерируется ключ шифрования файла (FEK), который шифруется открытым ключом EFS пользователя. При отсутствии корпоративного ЦС Windows выпускает самоподписанный EFS-сертификат, что затрудняет восстановление и централизованное управление. В корпоративных развертываниях выпускайте EFS-сертификаты из AD CS, используя шаблон Basic EFS, и назначайте агентов восстановления данных (DRA) через GPO (Политики открытого ключа, Шифрующая файловая система), чтобы обеспечить возможность восстановления зашифрованных пользователями файлов. Утилита командной строки cipher остается незаменимой:

undefined

шифруют или расшифровывают;

undefined

генерирует пары ключей DRA;

undefined

обновляет зашифрованные файлы для использования текущего EFS-сертификата. Используйте BitLocker для защиты на уровне тома, а EFS — только когда требуется разделение на уровне пользователя или файла, помня, что для EFS необходим вход пользователя в систему и доступность сертификата.

Иерархия AD CS и Online Responder

В устойчивой корпоративной PKI используется многоуровневая иерархия центров сертификации (ЦС). Автономный корневой ЦС является якорем доверия и должен быть физически и логически изолирован. Его включают только для подписания запросов от подчиненных ЦС и публикации списков отзыва сертификатов (CRL). Используйте длительный срок действия (например, 10–20 лет), большие размеры ключей RSA (не менее 4096, где это возможно) и публикуйте CDP/AIA на высокодоступные URL-адреса с постоянными путями. Никогда не выпускайте сертификаты конечных субъектов из корневого ЦС.

Подчиненные (выпускающие) ЦС присоединены к домену, находятся в сети и имеют короткий срок действия (например, 3–5 лет) с ограниченным использованием ключей и EKU. Они выпускают сертификаты для компьютеров, пользователей и служб и публикуют частые CRL с периодом перекрытия, чтобы избежать сбоев при задержках публикации. На выпускающих ЦС предпочтительно использовать приватные ключи, защищенные HSM, чтобы снизить риск утечки ключей. Настройте ограничения на основе реестра или политик для шаблонов и выпуска сертификатов, чтобы обеспечить соблюдение принципа наименьших привилегий.

Проверка отзыва сертификатов должна быть быстрой и надежной. Online Responder (OCSP) снижает задержку для клиентов, отвечая на запросы о статусе отдельных сертификатов вместо загрузки полных CRL. Установите службу роли Online Responder, зарегистрируйте для ответчиков сертификат OCSP Response Signing через специальный шаблон v3 и настройте конфигурацию отзыва (Revocation Configuration), которая указывает на выпускающий ЦС и его CRL, используя поставщик Microsoft CRL-based Revocation Provider. Убедитесь, что ЦС включает URL-адрес OCSP в расширение Authority Information Access, чтобы клиенты знали, куда отправлять запросы.

Для масштабируемости и отказоустойчивости разверните массив OCSP. Назначьте контроллер массива для репликации конфигураций отзыва на ответчики-члены массива. Выполняйте балансировку нагрузки на массив с помощью Windows NLB или внешнего балансировщика нагрузки с проверкой работоспособности, которая подтверждает отзывчивость OCSP и актуальность подписывающих сертификатов. Устанавливайте короткие сроки действия для сертификатов подписи OCSP и настройте автоматическую регистрацию для их продления, чтобы минимизировать подверженность рискам. Отслеживайте актуальность CRL и время жизни кэша OCSP, чтобы предотвратить отправку устаревших ответов.

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

Шаблоны сертификатов определяют ограничения для запросов, имя субъекта, варианты использования ключа и требования к выпуску. Шаблоны версии 2 (появились в Windows Server 2003 Enterprise) позволяют выполнять настройку и поддерживают автоматическую регистрацию с ключами на основе CSP. Шаблоны версии 3 (Windows Server 2008 и новее) добавляют поддержку CNG, ECC и алгоритмов Suite B. Выбирайте v3, если вам нужна поддержка CNG/ECC; выбирайте v2 для максимальной совместимости с устаревшими системами. Привязывайте шаблоны к одному набору выпускающих ЦС, чтобы ограничить радиус поражения в случае инцидента.

Автоматическая регистрация (Autoenrollment) превращает жизненный цикл сертификата в автоматизированный процесс, управляемый политиками. Настройте групповую политику в разделе Конфигурация компьютера или Конфигурация пользователя, Параметры Windows, Параметры безопасности, Политики открытого ключа, Клиент служб сертификации – автоматическая регистрация. Включите ее с опциями «Обновлять сертификаты с истекшим сроком действия», «Обновлять сертификаты, использующие шаблоны сертификатов» и «Удалять отозванные/просроченные сертификаты». Для автоматической регистрации требуются разрешения на шаблон: субъекты безопасности должны иметь права «Чтение» и «Авторегистрация»; права «Регистрация» достаточно только для ручной регистрации. Ограничивайте область действия с помощью групп безопасности, чтобы избежать неожиданного выпуска сертификатов и контролировать их количество.

Архивация ключей защищает данные в случае утери приватного ключа. Включите опцию «Архивировать закрытый ключ шифрования субъекта» в шаблоне для сертификатов, предназначенных только для шифрования (например, EFS, S/MIME). Назначьте агентов восстановления ключей (KRA), выдав им сертификаты KRA из шаблона Key Recovery Agent, и настройте ЦС на архивацию ключей. Восстановление ограничено типами ключей, подлежащими архивации; традиционно поддерживается RSA Key Exchange (устаревший CSP), в то время как архивация приватных ключей CNG/ECC не поддерживается функцией архивации ключей AD CS. Не включайте архивацию для шаблонов, предназначенных только для подписи.

Перемещение учетных данных (Credential Roaming) синхронизирует сертификаты пользователя, приватные ключи и главные ключи DPAPI между устройствами, присоединенными к домену, сохраняя их в AD. Включите эту функцию через групповую политику в разделе Конфигурация пользователя, Административные шаблоны, Система, Перемещение учетных данных и ограничьте область действия доверенными пользователями. Это улучшает пользовательский опыт при работе с EFS, S/MIME и сертификатами аутентификации клиента на нескольких компьютерах без использования перемещаемых профилей. Проверьте поддержку схемы каталога и спланируйте взаимодействие с Windows Hello для бизнеса и сторонними менеджерами учетных данных, чтобы избежать конфликтов или дублирования.

← Azure Arc и управление гибридными серверами · Все домены · Управление обновлениями и исправлениями Windows Server →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →