Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Относится к 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 ID см. в документации по 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.