Поделиться через

Планирование безопасности в Configuration Manager

  • Статья

Относится к Configuration Manager (Current Branch)

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

  • Сертификаты (самозаверяющий и PKI)

  • Доверенный корневой ключ

  • Подписывание и шифрование

  • Администрирование на основе ролей

  • Microsoft Entra ID

  • Проверка подлинности поставщика SMS

Перед началом работы убедитесь, что вы знакомы с основами безопасности в Configuration Manager.

Сертификаты

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

Дополнительные сведения см. в разделе Планирование сертификатов.

Доверенный корневой ключ

Доверенный корневой ключ Configuration Manager предоставляет клиентам Configuration Manager механизм проверки принадлежности систем сайта к их иерархии. Каждый сервер сайта создает ключ обмена сайтом для связи с другими сайтами. Ключ обмена сайтом с сайта верхнего уровня в иерархии называется доверенным корневым ключом.

Функция доверенного корневого ключа в Configuration Manager похожа на корневой сертификат в инфраструктуре открытых ключей. Все, что подписано закрытым ключом доверенного корневого ключа, является доверенным дальше по иерархии. Клиенты хранят копию доверенного корневого ключа сайта в root\ccm\locationservices пространстве имен WMI.

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

Клиенты автоматически получают общедоступную копию доверенного корневого ключа с помощью двух механизмов:

  • Вы расширяете схему Active Directory для Configuration Manager и публикуете сайт в доменных службах Active Directory. Затем клиенты получают эти сведения о сайте с сервера глобального каталога. Дополнительные сведения см. в статье Подготовка Active Directory к публикации сайта.

  • При установке клиентов с помощью метода принудительной установки клиента. Дополнительные сведения см. в разделе Принудительная установка клиента.

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

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

Подписывание и шифрование

При использовании PKI-сертификатов для всех клиентских подключений вам не нужно планировать подписывание и шифрование, чтобы защитить обмен данными клиента. Если вы настроили какие-либо системы сайта, на которые запущены СЛУЖБЫ IIS, чтобы разрешить подключения клиентов HTTP, решите, как защитить обмен данными между клиентами для сайта.

Важно!

Начиная с Configuration Manager версии 2103, сайты, которые разрешают обмен данными с клиентом HTTP, не рекомендуется использовать. Настройте сайт для HTTPS или расширенного HTTP. Дополнительные сведения см. в статье Включение сайта только для HTTPS или расширенного HTTP.

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

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

Примечание.

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

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

Дополнительные сведения о настройке параметров подписывания и шифрования см. в разделе Настройка подписывания и шифрования.

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

Администрирование на основе ролей

В Configuration Manager вы используете администрирование на основе ролей, чтобы защитить доступ, необходимый администраторам для использования Configuration Manager. Вы также обеспечиваете безопасный доступ к управляемым объектам, таким как коллекции, развертывания и сайты.

Сочетание ролей безопасности, областей безопасности и коллекций позволяет разделить административные назначения, соответствующие требованиям вашей организации. Они, используемые вместе, определяют административную область пользователя. Эта область администрирования управляет объектами, которые пользователь просматривает в консоли Configuration Manager, и разрешениями, которые пользователь имеет для этих объектов.

Дополнительные сведения см. в разделе Основы ролевого администрирования.

Microsoft Entra ID

Configuration Manager интегрируется с Microsoft Entra ID, чтобы сайт и клиенты могли использовать современную проверку подлинности.

Дополнительные сведения об идентификаторе Microsoft Entra см. в документации по Microsoft Entra.

Подключение сайта с помощью Microsoft Entra ID поддерживает следующие сценарии Configuration Manager:

Сценарии клиента

Сценарии сервера

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

Вы можете указать минимальный уровень проверки подлинности для доступа администраторов к сайтам Configuration Manager. Эта функция позволяет администраторам входить в Windows с необходимым уровнем, прежде чем они смогут получить доступ к Configuration Manager. Он применяется ко всем компонентам, которые обращаются к поставщику SMS. Например, консоль Configuration Manager, методы пакета SDK и командлеты Windows PowerShell.

Configuration Manager поддерживает следующие уровни проверки подлинности:

  • Проверка подлинности Windows. Требуется проверка подлинности с учетными данными домена Active Directory. Этот параметр является предыдущим поведением и текущим параметром по умолчанию.

  • Проверка подлинности с помощью сертификата. Требуется проверка подлинности с помощью действительного сертификата, выданного доверенным центром сертификации PKI. Этот сертификат не настраивают в Configuration Manager. Configuration Manager требует, чтобы администратор вошел в Windows с помощью PKI.

  • Проверка подлинности Windows Hello для бизнеса. Требуется проверка подлинности со строгой двухфакторной проверкой подлинности, привязанной к устройству и использующим биометрические данные или ПИН-код. Дополнительные сведения см. в статье Windows Hello для бизнеса.

    Важно!

    При выборе этого параметра поставщик SMS и служба администрирования требуют, чтобы маркер проверки подлинности пользователя содержал утверждение многофакторной проверки подлинности (MFA) из Windows Hello для бизнеса. Иными словами, пользователь консоли, пакета SDK, PowerShell или службы администрирования должен пройти проверку подлинности в Windows с помощью ПИН-кода Windows Hello для бизнеса или биометрических данных. В противном случае сайт отклоняет действие пользователя.

    Это поведение предназначено для Windows Hello для бизнеса, а не Для Windows Hello.

Дополнительные сведения о настройке этого параметра см. в разделе Настройка проверки подлинности поставщика SMS.

Дальнейшие действия