Технический справочник по средствам управления шифрованием

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

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

Основным алгоритмом хэширования, который Configuration Manager использует для подписывания, является SHA-256. Когда два Configuration Manager сайтов взаимодействуют друг с другом, они подписывают свои сообщения с помощью SHA-256.

Начиная с версии 2107 основным алгоритмом шифрования, который Configuration Manager используется, является AES-256. Шифрование в основном происходит в следующих двух областях:

• Если для сайта включен параметр Использовать шифрование, клиент шифрует данные инвентаризации и сообщения о состоянии, отправляемые в точку управления.

• Когда клиент загружает политики секретов, точка управления всегда шифрует эти политики. Например, последовательность задач развертывания ОС, которая включает пароли.

При использовании взаимодействия с клиентом по протоколу HTTPS настройте инфраструктуру открытых ключей (PKI) для использования сертификатов с максимальными алгоритмами хэширования и длиной ключей. При использовании сертификатов CNG версии 3 клиенты Configuration Manager поддерживают только сертификаты, использующие алгоритм шифрования RSA. Дополнительные сведения см. в разделах Требования к PKI-сертификатам и Общие сведения о сертификатах CNG версии 3.

Для обеспечения безопасности транспорта все, что использует TLS, поддерживает AES-256. Эта поддержка включает в себя настройку сайта для расширенного HTTP (E-HTTP) или HTTPS. Для локальных систем сайта можно управлять наборами шифров TLS. Для облачных ролей, таких как шлюз управления облачными клиентами (CMG), если включен протокол TLS 1.2, Configuration Manager настраивает наборы шифров.

Для большинства криптографических операций с операционными системами Windows Configuration Manager использует эти алгоритмы из библиотеки Windows CryptoAPI rsaenh.dll.

Дополнительные сведения о конкретных функциях см. в разделе Операции сайта.

Операции сайта

Сведения в Configuration Manager могут быть подписаны и зашифрованы. Он поддерживает эти операции с PKI-сертификатами или без них.

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

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

Если политика содержит конфиденциальные данные, начиная с версии 2107, точка управления шифрует их с помощью AES-256. Политика, содержащая конфиденциальные данные, отправляется только авторизованным клиентам. Сайт не шифрует политику без конфиденциальных данных.

Когда клиент хранит политику, он шифрует политику с помощью программного интерфейса приложения защиты данных Windows (DPAPI).

Хэширование политик

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

Алгоритм хэширования для политики — SHA-256.

Хэширование содержимого

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

Алгоритм хэширования содержимого по умолчанию — SHA-256.

Не все устройства поддерживают хэширование содержимого. К исключениям относятся:

• Клиенты Windows при потоковой передаче содержимого App-V.

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

Когда клиент отправляет инвентаризацию оборудования или программного обеспечения в точку управления, он всегда подписывает инвентаризацию. Не имеет значения, взаимодействует ли клиент с точкой управления по протоколу E-HTTP или HTTPS. Если они используют E-HTTP, вы также можете зашифровать эти данные, что рекомендуется.

Шифрование миграции состояния

Когда последовательность задач записывает данные из клиента для развертывания ОС, она всегда шифрует эти данные. В версии 2103 и более поздних последовательность задач запускает средство миграции пользовательской среды (USMT) с алгоритмом шифрования AES-256 .

Шифрование пакетов многоадресной рассылки

Для каждого пакета развертывания ОС можно включить шифрование при использовании многоадресной рассылки. В этом шифровании используется алгоритм AES-256 . Если вы включите шифрование, другая настройка сертификата не требуется. Точка распространения с поддержкой многоадресной рассылки автоматически создает симметричные ключи для шифрования пакета. Каждый пакет имеет свой ключ шифрования. Ключ хранится в точке распространения с поддержкой многоадресной рассылки с помощью стандартных API Windows.

Когда клиент подключается к сеансу многоадресной рассылки, обмен ключами происходит через зашифрованный канал. Если клиент использует ПРОТОКОЛ HTTPS, он использует сертификат проверки подлинности клиента, выданный PKI. Если клиент использует E-HTTP, он использует самозаверяющий сертификат. Клиент сохраняет ключ шифрования только в памяти во время сеанса многоадресной рассылки.

Шифрование для носителя развертывания ОС

При использовании носителя для развертывания операционных систем всегда следует указывать пароль для защиты носителя. С помощью пароля переменные среды последовательности задач шифруются с помощью AES-128. Другие данные на носителе, включая пакеты и содержимое для приложений, не шифруются.

Шифрование облачного содержимого

При включении шлюза управления облаком (CMG) для хранения содержимого содержимое шифруется с помощью AES-256. Содержимое шифруется при каждом обновлении. Когда клиенты скачивают содержимое, оно шифруется и защищено HTTPS-подключением.

Вход в обновления программного обеспечения

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

При публикации обновлений программного обеспечения в System Center Обновления Publisher они подписывается цифровым сертификатом. Вы можете указать PKI-сертификат или настроить Обновления Publisher для создания самозаверяющего сертификата для подписи обновления программного обеспечения. Если для публикации каталога обновлений используется самозаверяющий сертификат, например самозаверяющий сертификат издателей WSUS, сертификат также должен находиться в хранилище сертификатов доверенных корневых центров сертификации на локальном компьютере. WUA также проверяет, включен ли параметр групповой политики "Разрешить подписанное содержимое из интрасети " Расположение службы обновления Майкрософт " на локальном компьютере. Этот параметр политики должен быть включен, чтобы WUA проверял наличие обновлений, созданных и опубликованных с помощью System Center Обновления Publisher.

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

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

Шифрование и хэширование уведомлений клиента

Если вы используете уведомление клиента, во всем обмене данными используется ПРОТОКОЛ TLS и самые высокие алгоритмы, которые могут согласовать сервер и клиент. То же согласование происходит для хэширования пакетов, передаваемых во время уведомления клиента, при котором используется SHA-2.

Сертификаты

Список сертификатов инфраструктуры открытых ключей (PKI), которые могут использоваться Configuration Manager, любых особых требований или ограничений, а также способов использования сертификатов см. в разделе Требования к PKI-сертификатам. Этот список включает поддерживаемые хэш-алгоритмы и длины ключей. Большинство сертификатов поддерживают длину ключа SHA-256 и 2048 бит.

Большинство Configuration Manager операций, использующих сертификаты, также поддерживают сертификаты версии 3. Дополнительные сведения см. в статье Обзор сертификатов CNG версии 3.

Configuration Manager требуются PKI-сертификаты для следующих сценариев:

• При управлении клиентами Configuration Manager в Интернете

• При использовании шлюза управления облаком (CMG)

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

Управление мобильными устройствами и PKI-сертификаты

Развертывание ОС и PKI-сертификаты

Если для развертывания операционных систем используется Configuration Manager, а точка управления требует клиентских подключений HTTPS, клиенту требуется сертификат для связи с точкой управления. Это требование применяется даже в том случае, если клиент находится на переходном этапе, например при загрузке с носителя последовательности задач или с точки распространения с поддержкой PXE. Для поддержки этого сценария создайте сертификат проверки подлинности PKI-клиента и экспортируйте его с закрытым ключом. Затем импортируйте его в свойства сервера сайта, а также добавьте доверенный сертификат корневого ЦС точки управления.

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

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

Если любой из этих сертификатов проверки подлинности клиента скомпрометирован, заблокируйте сертификаты в узле Сертификаты рабочей области Администрирование , узел Безопасность . Для управления этими сертификатами требуется разрешение на управление сертификатом развертывания операционной системы.

После Configuration Manager развертывания ОС устанавливает клиент, клиенту требуется собственный сертификат проверки подлинности PKI-клиента для обмена данными с клиентом HTTPS.

Решения прокси-сервера isv и PKI-сертификаты

Независимые поставщики программного обеспечения могут создавать приложения, расширяющие Configuration Manager. Например, isV может создавать расширения для поддержки клиентских платформ, отличных от Windows. Однако если система сайта требует клиентских подключений ПО HTTPS, эти клиенты также должны использовать PKI-сертификаты для связи с сайтом. Configuration Manager включает возможность назначения сертификата прокси-серверу isv, который обеспечивает обмен данными между прокси-клиентами isV и точкой управления. Если вы используете расширения, для которых требуются сертификаты прокси-сервера isV, обратитесь к документации для этого продукта.

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

Копирование GUID для сертификата прокси-сервера поставщика программного обеспечения

Начиная с версии 2111, для упрощения управления этими сертификатами прокси-сервера ISV теперь можно скопировать его GUID в консоли Configuration Manager.

1. В консоли Configuration Manager перейдите в рабочую область Администрирование.

2. Разверните узел Безопасность и выберите узел Сертификаты .

3. Отсортируйте список сертификатов по столбцу Тип .

4. Выберите сертификат типа IsV Proxy.

5. На ленте выберите Копировать GUID сертификата.

Это действие копирует GUID этого сертификата, например: aa05bf38-5cd6-43ea-ac61-ab101f943987

Аналитика активов и сертификаты

С ноября 2021 г. мы не рекомендуем использовать аналитику активов и рекомендуем клиентам удалить эту роль.

Службы и сертификаты Azure

Для шлюза управления облаком (CMG) требуются сертификаты проверки подлинности сервера. Эти сертификаты позволяют службе обеспечивать обмен данными по протоколу HTTPS с клиентами через Интернет. Дополнительные сведения см. в разделе Сертификат проверки подлинности сервера CMG.

Клиентам требуется другой тип проверки подлинности для взаимодействия с CMG и локальной точкой управления. Они могут использовать Microsoft Entra ID, PKI-сертификат или маркер сайта. Дополнительные сведения см. в разделе Настройка проверки подлинности клиента для шлюза управления облаком.

Клиентам не требуется PKI-сертификат клиента для использования облачного хранилища. После проверки подлинности в точке управления точка управления выдает клиенту маркер доступа Configuration Manager. Клиент предоставляет этот токен cmg для доступа к содержимому. Маркер действителен в течение восьми часов.

Проверка CRL для PKI-сертификатов

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

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

Когда клиент использует ПРОТОКОЛ HTTPS, он по умолчанию включает проверку списка отзыва сертификатов.

Следующие подключения не поддерживают возврат списка отзыва сертификатов в Configuration Manager:

• Подключения между серверами

Взаимодействие с сервером

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

Взаимодействие с сервером в пределах сайта

Каждый сервер системы сайта использует сертификат для передачи данных в другие системы сайта на том же Configuration Manager сайте. Некоторые роли системы сайта также используют сертификаты для проверки подлинности. Например, если установить прокси-точку регистрации на одном сервере и точку регистрации на другом сервере, они могут пройти проверку подлинности друг друга с помощью этого сертификата удостоверения.

Если Configuration Manager использует сертификат для этого взаимодействия, если есть PKI-сертификат, доступный с возможностью проверки подлинности сервера, Configuration Manager автоматически использует его. В противном случае Configuration Manager создает самозаверяющий сертификат. Этот самозаверяющий сертификат имеет возможность проверки подлинности сервера, использует SHA-256 и имеет длину ключа 2048 бит. Configuration Manager копирует сертификат в доверенный Люди хранить на других серверах системы сайта, которым может потребоваться доверять системе сайта. Затем системы сайта могут доверять друг другу, используя эти сертификаты и PeerTrust.

Помимо этого сертификата для каждого сервера системы сайта, Configuration Manager создает самозаверяющий сертификат для большинства ролей системы сайта. Если на одном сайте имеется несколько экземпляров роли системы сайта, они совместно используют один и тот же сертификат. Например, на одном сайте может быть несколько точек управления. Этот самозаверяющий сертификат использует SHA-256 и имеет длину ключа 2048 бит. Он копируется в доверенное хранилище Люди на серверах системы сайта, которым может потребоваться доверие. Следующие роли системы сайта создают этот сертификат:

• Точка синхронизации аналитики активов

• Точка Endpoint Protection

• Резервная точка состояния

• Точка управления

• Точка распространения с поддержкой многоадресной рассылки

• Точка служб Reporting Services

• Точка обновления программного обеспечения

• Точка миграции состояния

Configuration Manager автоматически создает эти сертификаты и управляет ими.

Для отправки сообщений о состоянии из точки распространения в точку управления Configuration Manager использует сертификат проверки подлинности клиента. При настройке точки управления для HTTPS требуется PKI-сертификат. Если точка управления принимает подключения E-HTTP, можно использовать PKI-сертификат. Он также может использовать самозаверяющий сертификат с возможностью проверки подлинности клиента, использует SHA-256 и имеет длину ключа 2048 бит.

Обмен данными между серверами между сайтами

Configuration Manager передает данные между сайтами с помощью репликации базы данных и репликации на основе файлов. Дополнительные сведения см. в разделах Передача данных между сайтами и Связь между конечными точками.

Configuration Manager автоматически настраивает репликацию базы данных между сайтами. Если доступно, он использует PKI-сертификаты с возможностью проверки подлинности сервера. Если они недоступны, Configuration Manager создает самозаверяемые сертификаты для проверки подлинности сервера. В обоих случаях он выполняет проверку подлинности между сайтами с помощью сертификатов в хранилище доверенных Люди, использующего PeerTrust. Оно использует это хранилище сертификатов, чтобы убедиться, что в репликации "сеть — сеть" участвуют только серверы SQL Server Configuration Manager иерархии.

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

Репликация базы данных в Configuration Manager использует SQL Server Service Broker для передачи данных между сайтами. В нем используются следующие механизмы:

• SQL Server для SQL Server. Это подключение использует учетные данные Windows для проверки подлинности сервера и самозаверяемые сертификаты с 1024 битами для подписи и шифрования данных с помощью алгоритма AES. Если доступно, он использует PKI-сертификаты с возможностью проверки подлинности сервера. В нем используются только сертификаты в личном хранилище сертификатов компьютера.

• Sql Service Broker. Эта служба использует самозаверяемые сертификаты с 2048 битами для проверки подлинности, а также для подписи и шифрования данных с помощью алгоритма AES. Он использует только сертификаты в базе данных SQL Server master.

Репликация на основе файлов использует протокол SMB. Он использует SHA-256 для подписывания данных, которые не зашифрованы и не содержат конфиденциальных данных. Чтобы зашифровать эти данные, используйте протокол IPsec, который реализуется независимо от Configuration Manager.

Клиенты, использующие HTTPS

Когда роли системы сайта принимают клиентские подключения, их можно настроить для приема подключений HTTPS и HTTP или только подключений HTTPS. Роли системы сайта, принимаюющие подключения из Интернета, принимают только клиентские подключения по протоколу HTTPS.

Клиентские подключения по протоколу HTTPS обеспечивают более высокий уровень безопасности за счет интеграции с инфраструктурой открытых ключей (PKI) для защиты обмена данными между клиентом и сервером. Однако настройка клиентских подключений HTTPS без тщательного понимания планирования, развертывания и операций PKI может по-прежнему сделать вас уязвимыми. Например, если не защитить корневой центр сертификации (ЦС), злоумышленники могут поставить под угрозу доверие ко всей инфраструктуре PKI. Не удалось развернуть PKI-сертификаты и управлять ими с помощью управляемых и защищенных процессов, что может привести к тому, что неуправляемые клиенты не могут получать критически важные обновления или пакеты программного обеспечения.

Незашифрованное взаимодействие, когда клиенты используют HTTPS

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

• Клиенту не удается установить HTTPS-подключение в интрасети и вернуться к использованию HTTP, если системы сайта разрешают эту конфигурацию.

• Обмен данными со следующими ролями системы сайта:

  • Клиент отправляет сообщения о состоянии в резервную точку состояния.

  • Клиент отправляет PXE-запросы в точку распространения с поддержкой PXE.

  • Клиент отправляет данные уведомлений в точку управления.

Вы настраиваете точки служб отчетов для использования HTTP или HTTPS независимо от режима связи клиента.

Клиенты, использующие E-HTTP

Когда клиенты используют E-HTTP-связь с ролями системы сайта, они могут использовать PKI-сертификаты для проверки подлинности клиента или самозаверяющие сертификаты, которые Configuration Manager создавать. Когда Configuration Manager создает самозаверяющие сертификаты, они имеют пользовательский идентификатор объекта для подписывания и шифрования. Эти сертификаты используются для уникальной идентификации клиента. Эти самозаверяемые сертификаты используют SHA-256 и имеют длину ключа 2048 бит.

Развертывание ОС и самозаверяемые сертификаты

При использовании Configuration Manager для развертывания операционных систем с самозаверяющих сертификатов клиент также должен иметь сертификат для связи с точкой управления. Это требование применяется даже в том случае, если компьютер находится на переходном этапе, например с носителя последовательности задач или точки распространения с поддержкой PXE. Для поддержки этого сценария для клиентских подключений E-HTTP Configuration Manager создает самозаверяющие сертификаты с пользовательским идентификатором объекта для подписывания и шифрования. Эти сертификаты используются для уникальной идентификации клиента. Эти самозаверяемые сертификаты используют SHA-256 и имеют длину ключа 2048 бит. Если эти самозаверяющие сертификаты скомпрометируются, запретите злоумышленникам использовать их для олицетворения доверенных клиентов. Заблокируйте сертификаты в узле Сертификаты в рабочей области Администрирование узел Безопасность .

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

Когда клиенты подключаются по протоколу E-HTTP, они проверяют подлинность точек управления с помощью доменные службы Active Directory или Configuration Manager доверенного корневого ключа. Клиенты не проходят проверку подлинности других ролей системы сайта, таких как точки миграции состояния или точки обновления программного обеспечения.

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

Сведения об уязвимостях SSL

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

• Включите TLS 1.2 на всех устройствах и службах. Сведения о включении TLS 1.2 для Configuration Manager см. в статье Включение TLS 1.2 для Configuration Manager.

• Отключите SSL 3.0, TLS 1.0 и TLS 1.1.

• Переупоряет порядок наборов шифров, связанных с TLS.

Дополнительные сведения см. в следующих статьях:

• Ограничение использования определенных криптографических алгоритмов и протоколов в Schannel.dll.
• Расстановка приоритетов наборов шифров Schannel

Эти процедуры не влияют на функциональность Configuration Manager.