Техническая справка по элементам управления шифрования, используемым в Configuration Manager

 

Применимо к:System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1

System_CAPS_noteПримечание

Этот раздел отображается в следующей документации: в руководстве Администрирование сайтов для System Center 2012 Configuration Manager и в руководстве Безопасность и конфиденциальность System Center 2012 Configuration Manager.

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

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

Для большинства криптографических операций в операционных системах Windows в Configuration Manager используются алгоритмы SHA-1, SHA-2, 3DES, AES и RSA из библиотеки Windows CryptoAPI rsaenh.dll.

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

  • Криптографические элементы управления для операций Configuration Manager

  • Сертификаты, используемые Configuration Manager

  • Элементы управления шифрования для обмена данными с сервером

  • Элементы управления шифрования для клиентов, использующих протокол HTTPS для обмена данными с системами сайта

  • Элементы управления шифрования для клиентов, которые используют протокол HTTP для обмена данными с системами сайта

System_CAPS_importantВажно

Сведения о рекомендуемых изменениях в ответ на уязвимости SSL см. в Сведения об уязвимостях SSL.

Криптографические элементы управления для операций Configuration Manager

Информацию в Configuration Manager можно подписывать и шифровать вне зависимости от того, используются ли с Configuration Manager PKI-сертификаты.

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

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

Политика шифруется по алгоритму 3DES, если она содержит конфиденциальные данные. Политика, содержащая конфиденциальные данные, рассылается только авторизованным клиентам. Политика, не содержит такие данные, не шифруется.

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

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

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

Для политики применяются алгоритмы хеширования SHA-1 и SHA-256.

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

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

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

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

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

  • Клиенты Windows Phone. Однако эти клиенты проверяют, подписано ли приложение надежным источником.

  • Клиенты Windows RT: Однако эти клиенты проверяют, подписано ли приложение надежным источником, а также выполняют проверку полного имени пакета (PFN).

  • iOS: Однако эти клиенты проверяют, подписано ли приложение сертификатом разработчика из надежного источника.

  • Клиенты Nokia: Однако эти клиенты проверяют, подписано ли приложение самозаверяющим сертификатом. Как вариант, приложения Nokia Symbian Installation Source (SIS) могут подписываться сертификатом из надежного источника или обычным сертификатом.

  • Android. Кроме того, эти устройства не проверяют подпись приложения при его установке.

  • Клиенты, работающие в версиях Linux и UNIX, которые не поддерживают SHA-256. Дополнительные сведения см. в разделе О Linux и операционных системах UNIX, выполнять не поддержки SHA-256 статьи Планирование развертывания клиента для серверов Linux и UNIX.

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

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

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

Данные, хранящиеся в точках миграции состояния развернутой операционной системы, всегда шифруются средством User State Migration Tool (USMT) с помощью 3DES.

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

Для каждого пакета развертывания операционной системы можно включить шифрование при многоадресной рассылке пакета на компьютеры. Для такого шифрования используется стандарт AES. Если включить шифрование, дополнительная настройка сертификата не потребуется. Точка распространения с поддержкой многоадресной рассылки автоматически генерирует симметричные ключи для шифрования пакета. Ключи шифрования всех пакетов отличаются. Ключ шифрования сохраняется в точке распространения с поддержкой многоадресной рассылки с использованием стандартных API Windows. Когда клиент подключается к сеансу многоадресной рассылки, обмен ключами производится по каналу, зашифрованному с использованием выданного PKI сертификата проверки подлинности клиента (когда клиент использует HTTPS) или самозаверяющего сертификата (когда клиент использует HTTP). Клиент хранит ключ в памяти только на время сеанса многоадресной рассылки.

Шифрование носителей для развертывания операционных систем

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

Шифрование содержимого, размещенного в облачных точках распространения

Начиная с System Center 2012 Configuration Manager с пакетом обновления 1 (SP1), при использовании облачных точек распространения загружаемое в них содержимое шифруется по алгоритму Advanced Encryption Standard (AES) с 256-битным ключом. При каждом обновлении содержимое шифруется повторно. Содержимое, которое загружают клиенты, шифруется и передается по защищенному HTTPS-соединению.

Подписывание обновлений программного обеспечения

Все обновления программного обеспечения должны быть подписаны надежным издателем, чтобы защитить их от подделки. На клиентских компьютерах агент обновления Windows (WUA) сканирует каталог на предмет обновлений, но не устанавливает обновление, если не может найти соответствующий цифровой сертификат в хранилище надежных издателей на локальном компьютере. Если для публикации каталога обновления использовался самозаверяющий сертификат, например "WSUS Publishers Self-signed", этот сертификат должен также присутствовать в хранилище "Доверенные корневые центры сертификации" на локальном компьютере, чтобы можно было проверить действительность этого сертификата. WUA также проверяет, включен ли на локальном компьютере параметр групповой политики Разрешить прием содержимого с подписью из службы обновления Майкрософт в интрасети. Этот параметр политики должен быть включен, чтобы агент обновления Windows искал обновления, созданные и опубликованные с помощью Updates Publisher.

Когда обновления программного обеспечения публикуются в System Center Updates Publisher, они подписываются цифровым сертификатом при публикации на сервере обновлений. Можно указать PKI-сертификат или настроить Updates Publisher для генерации самозаверяющего сертификата, которым будет подписываться обновление программного обеспечения.

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

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

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

При использовании клиентских уведомлений все сеансы связи работают на основе TLS и шифруются настолько надежно, насколько позволяют операционные системы сервера и клиента. Например, если клиентский компьютер работает под Windows 7, а на точке управления установлена ОС Windows Server 2008 R2 с поддержкой 128-битного шифрования AES, то при подключении клиента с ОС Vista эта же точка управления будет использовать более слабое шифрование 3DES. То же самое верно и для хэширования пакетов, передаваемых при уведомлении клиента, — используется либо SHA-1, либо SHA-2.

Сертификаты, используемые Configuration Manager

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

System_CAPS_noteПримечание

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

Сертификаты PKI необходимы в следующих сценариях:

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

  • управление клиентами Configuration Manager на мобильных устройствах;.

  • Управление компьютерами Mac.

  • Если используются облачные точки распространения.

  • использование аппаратного контроллера управления с компьютерами на базе технологии Intel AMT.

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

Configuration Manager не использует PKI-сертификаты при управлении мобильными устройствами через соединитель Exchange Server.

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

Если мобильное устройство не заблокировано оператором мобильной связи, можно использовать Configuration Manager или Microsoft Intune для запроса и установки сертификата клиента. Этот сертификат обеспечивает взаимную проверку подлинности между клиентом на мобильном устройстве и системами сайтов Configuration Manager или службами Microsoft Intune. Если мобильное устройство заблокировано, нельзя использовать Configuration Manager или Intune для развертывания сертификатов. Дополнительные сведения см. в статье Установка клиентов на устройства Windows Mobile и Nokia Symbian с помощью Configuration Manager.

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

Использование аппаратного контроллера управления и PKI-сертификаты

При использовании аппаратного контроллера управления для компьютеров на базе технологии Intel AMT применяются по меньшей мере два типа PKI-сертификатов: сертификат инициализации AMT и сертификат веб-сервера.

Точка обслуживания аппаратного контроллера управления пользуется сертификатом инициализации AMT для подготовки компьютеров к управлению с использованием аппаратного контроллера. Компьютеры на базе технологии AMT, которые будут инициализироваться, должны доверять сертификаты, предоставленному точкой управления с использованием аппаратного контроллера. По умолчанию компьютеры на базе технологии AMT настраиваются производителем для использования внешних центров сертификации (ЦС), таких как VeriSign, Go Daddy, Comodo и Starfield. Если вы приобрели сертификат инициализации у одного из внешних ЦС и настроили Configuration Manager для использования этого сертификата, компьютеры на базе технологии AMT будут доверять ЦС сертификата инициализации, и инициализация завершится успешно. Однако рекомендуемой мерой безопасности является использование собственного внутреннего ЦС для выдачи сертификата инициализации AMT. Дополнительные сведения см. в статье Рекомендации по безопасности при использовании аппаратного контроллера управления.

Во встроенном ПО компьютеров на базе технологии AMT работает компонент веб-сервера, который шифрует канал связи с точкой обслуживания аппаратного контроллера управления по протоколу TLS. В BIOS компьютеров на базе технологии AMT отсутствует графический интерфейс для ручной настройки сертификата, поэтому необходимо иметь центр сертификации предприятия (Майкрософт), который будет автоматически утверждать запросы от таких компьютеров. Такие запросы используют формат PKCS#10, который, в свою очередь, использует PKCS#7 для передачи сведений о сертификате компьютеру на базе технологии AMT.

Хотя AMT-компьютер проходит проверку подлинности на компьютере, который им управляет, на управляющем компьютере нет соответствующего клиентского PKI-сертификата. Вместо этого при таких взаимодействиях применяется проверка подлинности Kerberos или дайджест-проверка подлинности HTTP. Если используется дайджест-проверка подлинности HTTP, она шифруется по протоколу TLS.

Для управления компьютерами на базе технологии AMT с использованием аппаратного контроллера может потребоваться еще один тип сертификата: необязательный сертификат клиента для проводных сетей с проверкой подлинности 802.1X и беспроводных сетей. AMT-компьютер может потребовать этот сертификат клиента для проверки подлинности на RADIUS-сервере. Если RADIUS-сервер настроен для проверки подлинности EAP-TLS, сертификат клиента требуется всегда. Если же RADIUS-сервер настроен для проверки подлинности EAP-TTLS/MSCHAPv2 или PEAPv0/EAP-MSCHAPv2, то сведения о том, необходим ли сертификат клиента, содержатся в настройках RADIUS. Этот сертификат запрашивается компьютером на базе технологии AMT с использованием тех же процессов, что и при запросе сертификата веб-сервера.

Развертывание операционных систем и PKI-сертификаты

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

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

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

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

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

Прокси-серверы независимых поставщиков ПО и PKI-сертификаты

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

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

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

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

Этот сертификат содержит ключ длиной 1024 бит.

Облачные точки распространения и сертификаты

Начиная с System Center 2012 Configuration Manager с пакетом обновления 1 (SP1), для облачных точек распространения требуется сертификат управления (самозаверяющий или PKI), который загружен в Microsoft Azure. Для сертификата управления, в свою очередь, нужна возможность аутентификации на сервере и 2048-битный ключ. Кроме того, для каждой облачной точки распространения следует настроить служебный сертификат (не самозаверяющий) с возможностью аутентификации на сервере и ключом длиной не менее 2048 бит.

System_CAPS_noteПримечание

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

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

Соединитель Microsoft Intune и сертификаты

После регистрации мобильных устройств в Microsoft Intune вы можете управлять этими мобильными устройствами в Configuration Manager, создав соединитель Microsoft Intune. Этот соединитель использует PKI-сертификат с возможностью проверки подлинности клиента для проверки подлинности Configuration Manager в Microsoft Intune и передачи всей информации между ними с использованием SSL. В сертификате применяется 2048-битный ключ и алгоритм хеширования SHA-1.

При установке соединителя создаются сертификат подписи, который сохраняется на сервере сайта для ключей загрузки неопубликованных приложений, и сертификат шифрования, который сохраняется в точке регистрации сертификатов и используется для шифрования запросов SCEP. В этих сертификатах также применяется 2048-битный ключ и алгоритм хеширования SHA-1.

Когда Intune регистрирует мобильное устройство, на это мобильное устройство устанавливается PKI-сертификат. Этот сертификат поддерживает аутентификацию клиента, а также использует 2048-битный ключ и алгоритм хеширования SHA-1.

Microsoft Intune автоматически запрашивает, создает и устанавливает эти PKI-сертификаты.

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

Список отзыва PKI-сертификатов (CRL) увеличивает затраты на администрирование и обработку, однако обеспечивает более высокий уровень безопасности. Однако если проверка списка отзыва сертификатов включена, но сам список недоступен, происходит сбой подключения инфраструктуры открытых ключей. Дополнительные сведения см. в разделе Планирование отзыва PKI-сертификата статьи Планирование безопасности в Configuration Manager.

Проверка списка отзыва сертификатов (CRL) включена в службах IIS по умолчанию, поэтому, если для развертывания инфраструктуры открытых ключей используется CRL, для большинства систем сайта Configuration Manager, в которых выполняются службы IIS, не требуется вносить какие-либо изменения. Исключением являются обновления программного обеспечения, для которых проверку списка отзыва сертификатов необходимо включить вручную, чтобы выполнять проверку подписей для файлов обновления программного обеспечения.

Проверка списка отзыва сертификатов по умолчанию включена для клиентских компьютеров, если они используют клиентские подключения по протоколу HTTPS. Если консоль управления аппаратного контроллера управления используется для подключения к компьютерам, основанным на AMT, проверка списка отзыва сертификатов не включена по умолчанию, однако ее можно включить. Проверку списка отзыва сертификатов для клиентов Mac в Configuration Manager с пакетом обновления 1 (SP1) или более поздней версии отключить нельзя.

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

  • Подключения "сервер-сервер".

  • мобильные устройства, зарегистрированные с помощью Configuration Manager.

  • мобильные устройства, зарегистрированные с помощью Microsoft Intune.

Элементы управления шифрования для обмена данными с сервером

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

Обмен данными с сервером в пределах сайта

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

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

  • Точка веб-службы каталога приложений

  • Точка веб-сайта каталога приложений.

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

  • Точка регистрации сертификатов

  • Точка Endpoint Protection

  • Точка регистрации

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

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

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

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

  • Точка служб отчетов

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

  • Точка миграции среды

  • Точка проверки работоспособности систем

  • Соединитель Microsoft Intune

Эти сертификаты поддерживают автоматическое управление с помощью Configuration Manager и, при необходимости, автоматическое создание.

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

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

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

Configuration Manager автоматически настраивает PKI-сертификаты репликации баз данных между сайтами и использует PKI-сертификаты с возможностью проверки подлинности сервера (при наличии); в противном случае Configuration Manager создает самозаверяющие сертификаты для проверки подлинности серверов. В любом случае проверка подлинности между сайтами устанавливается с использованием сертификатов из хранилища доверенных лиц, которые используют доверие одноранговой группы. Это хранилище сертификатов используется, чтобы гарантировать, что только компьютеры под управлением 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-шифрования. Сертификат должен размещаться в базе данных master SQL Server.

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

Элементы управления шифрования для клиентов, использующих протокол HTTPS для обмена данными с системами сайта

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

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

System_CAPS_importantВажно

PKI-сертификаты, используемые для обмена данными с клиентами, защищают подключения только между клиентом и некоторыми системами сайта. Они не обеспечивают защиту канала обмена данными между сервером сайта и системами сайта или между серверами сайта.

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

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

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

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

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

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

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

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

Элементы управления шифрования для клиентов, которые используют протокол HTTP для обмена данными с системами сайта

Если клиенты используют протокол HTTP для обмена данными с ролями системы сайта, для проверки подлинности они могут использовать PKI-сертификаты или самозаверяющие сертификаты, создаваемые Configuration Manager. Когда Configuration Manager создает самозаверяющие сертификаты, они имеют настраиваемый идентификатор объекта для подписывания и шифрования и используются для однозначной идентификации клиента. Для всех поддерживаемых операционных систем, кроме Windows Server 2003, в этих самозаверяющих сертификатах применяется алгоритм хеширования SHA-256 и 2048-битный ключ. Для Windows Server 2003 применяется алгоритм хеширования SHA-1 и 1024-битный ключ.

Развертывание операционной системы и самозаверяющие сертификаты

Когда Configuration Manager используется для развертывания операционных систем с помощью самозаверяющих сертификатов, клиентский компьютер также должен также иметь сертификат для взаимодействия с точкой управления, даже если он находится на промежуточном этапе — например, загружается с носителя последовательности задач или точки распространения с поддержкой PXE. Чтобы обеспечить поддержку этого сценария для клиентских HTTP-подключений, Configuration Manager создает самозаверяющие сертификаты, которые имеют настраиваемый идентификатор объекта для подписывания и шифрования и используются для однозначной идентификации клиента. Для всех поддерживаемых операционных систем, кроме Windows Server 2003, в этих самозаверяющих сертификатах применяется алгоритм хеширования SHA-256 и 2048-битный ключ. Для Windows Server 2003 применяется алгоритм хеширования SHA-1 и 1024-битный ключ. Если эти самозаверяющие сертификаты будут скомпрометированы, заблокируйте их в узле Сертификаты рабочей области Администрирование (узел Безопасность), чтобы предотвратить их использование злоумышленниками для олицетворения доверенных клиентов.

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

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

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

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

Для повышения безопасности серверов Configuration Manager рекомендуется отключить SSL 3.0, включить TLS 1.1 и 1.2, а также изменить порядок комплектов шифров TLS. Сведения о выполнении этих действий см. в этой статье в базе знаний. Это действие не повлияет на функциональные возможности Configuration Manager.