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

  • Статья

Планирование безопасности в 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.

Следующие разделы содержат сведения о планировании безопасности в Microsoft System Center 2012 Configuration Manager.

  • Планирование сертификатов (самозаверяющего и PKI-сертификата)

    • Планирование отзыва PKI-сертификата

    • Планирование доверенных корневых PKI-сертификатов и списка издателей сертификатов

    • Планирование выбора PKI-сертификата клиента

    • Планирование стратегии перехода для PKI-сертификатов и управления клиентами через Интернет

  • Планирование доверенного корневого ключа

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

  • Планирование ролевого администрирования

Кроме этих разделов также см. статью Безопасность и конфиденциальность администрирования сайтов в Configuration Manager.

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

Планирование сертификатов (самозаверяющего и PKI-сертификата)

Configuration Manager использует сочетание самозаверяющих сертификатов и сертификатов инфраструктуры открытых ключей (PKI).

По соображениям безопасности при любой возможности рекомендуется использовать PKI-сертификаты. Дополнительные сведения о требования к PKI-сертификату см. в разделе Требования к PKI-сертификатам для Configuration Manager. Если Configuration Manager запрашивает PKI-сертификаты, например во время регистрации мобильных устройств и подготовки AMT, необходимо использовать доменные службы Active Directory и центр сертификации предприятия. Развертывание всех остальных PKI-сертификатов и управление ими следует осуществлять независимо от Configuration Manager.

PKI-сертификаты также требуются при подключении клиентских компьютеров к системам сайта в Интернете и их рекомендуется использовать при подключении клиентов к системам сайта, на которых запущены службы Internet Information Services (IIS). Дополнительные сведения о взаимодействии клиентов см. в разделе Планирование обмена данными с клиентами в Configuration Manager.

При использовании PKI вы также можете использовать протокол IPsec для защиты межсерверного обмена данными между системами сайта на сайте и между сайтами, а также в любом другом случае при передаче данных между компьютерами. Настроить и реализовать IPsec необходимо независимо от Configuration Manager.

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

Планирование сертификата подписи сервера сайта (самозаверяющего)

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

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

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

    • Схема Active Directory не расширена для Configuration Manager.

    • Сайт клиента не публикуется в доменных службах Active Directory.

    • Клиент из ненадежного леса или рабочей группы.

  • Установка клиента выполняется, когда он находится в Интернете.

Следующая процедура используется для установки клиентов вместе с копией сертификата подписи сервера сайта.

Установка клиентов с копией сертификата подписи сервера сайта

  1. На сервере первичного сайта клиента найдите сертификат подписи сервера сайта. Этот сертификат находится в хранилище сертификатов SMS, ему задано имя субъекта Сервер сайта и понятное имя Сертификат подписи сервера сайта.

  2. Экспортируйте сертификат без закрытого ключа, сохраните файл в надежном месте и обращайтесь к нему только из защищенного канала (например, с помощью подписывания SMB или протокола IPsec).

  3. Установите клиент, используя свойство Client.msi SMSSIGNCERT=<полный_путь_к_файлу_и_имя_файла> и запустив CCMSetup.exe.

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

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

System_CAPS_importantВажно

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

По умолчанию службы IIS всегда проверяют список CRL для клиентских сертификатов. Изменить эту настройку в Configuration Manager нельзя. По умолчанию клиенты Configuration Manager всегда проверяют список CRL для систем сайта. Чтобы отключить этот параметр, нужно указать свойство сайта и свойство CCMSetup. Если управление компьютерами с поддержкой Intel AMT осуществляется с использованием аппаратного контроллера управления, проверку списка CRL можно также включить для точки обслуживания аппаратного контроллера управления и для компьютеров с консолью аппаратного контроллера управления

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

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

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

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

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

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

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

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

  • Вы используете клиентские PKI-сертификаты, которые не связаны с корневым сертификатом ЦС, имеющим доверие точек управления.

    System_CAPS_noteПримечание

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

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

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

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

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

  • Если у клиентов есть список издателей сертификата, при выборе PKI-сертификата они останавливаются на сертификате, который связан с доверенным корневым сертификатом в списке. Если такой сертификат отсутствует, клиент не выбирает PKI-сертификат. Дополнительные сведения о процессе сертификата клиента см. в разделе Планирование выбора PKI-сертификата клиента этой статьи.

Во время регистрации мобильных устройств и компьютеров Mac или подготовки компьютеров с поддержкой Intel AMT для использования в беспроводных сетях может потребоваться импортировать корневой сертификат центра сертификации независимо от конфигурации сайта.

Планирование выбора PKI-сертификата клиента

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

System_CAPS_noteПримечание

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

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

  1. Список издателей сертификатов. Сертификат связан с корневым ЦС, доверенным для точки управления.

  2. Сертификат находится в хранилище сертификатов по умолчанию Личные.

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

  4. Сертификат может выполнять проверку подлинности клиента или выдается по имени компьютера.

  5. Сертификат имеет наибольший срок действия.

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

  • Список публикуется в качестве данных сайта Configuration Manager в доменных службах Active Directory.

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

  • Клиенты загружают список из точки управления после своего успешного назначения сайту.

  • Во время установки клиента список указывается как свойство CCMSetup client.msi "CCMCERTISSUERS".

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

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

  • Частичное совпадение строки с именем субъекта сертификата клиента. Это совпадение без учета регистра подходит, если в поле субъекта используется полное доменное имя (FQDN) компьютера, и требуется выбирать сертификат на основе суффикса домена, например contoso.com. Однако этот способ выбора можно использовать для идентификации любой цепочки последовательных символов в имени субъекта сертификата, которая отличает сертификат от других сертификатов в хранилище сертификатов клиента.

    System_CAPS_noteПримечание

    Частичное совпадение строки с дополнительным именем субъекта сертификата (SAN) нельзя использовать в качестве параметра сайта. Несмотря на то, что частичное совпадение строки для SAN можно указать с помощью CCMSetup, оно будет перезаписано свойствами сайта в следующих случаях.

    • Клиенты получают данные сайта, которые опубликованы в доменных службах Active Directory.

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

    Частичное совпадение строки с SAN следует использовать только при установке клиентов вручную или если они не получают данные сайта из доменных служб Active Directory. Например, эти условия применимы только к интернет-клиентам.

  • Совпадение значений атрибута имени субъекта или значений атрибута альтернативного имени субъекта сертификата клиента. Это совпадение с учетом регистра подходит, если в поле субъекта используется различающееся имя X500 или эквивалентные идентификаторы OID (идентификаторы объектов) в соответствии со стандартом RFC 3280, и требуется выбирать сертификат на основе значений этих атрибутов. Можно задать только те атрибуты и значения, которые требуются для уникальной идентификации или проверки сертификата и для отличия этого сертификата от других сертификатов в хранилище сертификатов.

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

Атрибут OID

Атрибут различающегося имени

Определение атрибута

0.9.2342.19200300.100.1.25

DC

Компонент домена

1.2.840.113549.1.9.1

E или E-mail

Адрес электронной почты

2.5.4.3

CN

Общее имя

2.5.4.4

SN

Имя субъекта

2.5.4.5

SERIALNUMBER

Серийный номер

2.5.4.6

В

Код страны

2.5.4.7

L

Местонахождение

2.5.4.8

S или ST

Название штата или провинции

2.5.4.9

STREET

Адрес по улице

2.5.4.10

O

Название организации

2.5.4.11

OU

Подразделение

2.5.4.12

T или Title

Название

2.5.4.42

G или GN или GivenName

Имя

2.5.4.43

I или Initials

Инициалы

2.5.29.17

(без значения)

Альтернативное имя субъекта

Если после применения условия выбора сертификата найдено несколько подходящих сертификатов, можно переопределить конфигурацию по умолчанию для выбора сертификата с наибольшим сроком действия, указав, что сертификат не выбран. В этом случае клиент не сможет связываться со службами IIS систем сайта, используя PKI-сертификат. Клиент передает назначенной ему резервной точке состояния сообщение об ошибке для предупреждения о сбое выбора сертификата, чтобы пользователь мог изменить или уточнить критерии выбора сертификата. Затем действия клиента зависят от используемого при неудавшемся подключении протокола (HTTPS или HTTP).

  • Если не удалось подключиться по протоколу HTTPS: клиент пытается подключиться по протоколу HTTP и использует самозаверяющий сертификат клиента.

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

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

Сведения о настройке параметров для клиентских сертификатов см. в разделе Настройка параметров для PKI-сертификатов клиентов статьи Настройка параметров безопасности Configuration Manager.

Планирование стратегии перехода для PKI-сертификатов и управления клиентами через Интернет

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

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

  1. Установите сайт Configuration Manager и настройте его для приема подключений клиентов по протоколам HTTPS и HTTP.

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

  3. Выполните пробное внедрение сертификатов PKI клиента. Пример развертывания см. в разделе Развертывание сертификата клиента для компьютеров Windows статьи Пошаговый пример развертывания сертификатов PKI для Configuration Manager. Центр сертификации Windows Server 2008.

  4. Установите клиенты с помощью принудительной установки. Дополнительные сведения см. в разделе Принудительная установка клиентов Configuration Manager статьи Установка клиентов на компьютерах под управлением Windows в Configuration Manager.

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

  6. Отслеживайте, сколько клиентов используют сертификаты PKI, с помощью столбца Сертификат клиента рабочей области Активы и соответствие в узле Устройства.

    Можно также развернуть средство Configuration Manager HTTPS Communication Readiness Tool (cmHttpsReadiness.exe) на компьютерах и использовать отчеты для контроля числа компьютеров, способных использовать сертификаты PKI клиента в Configuration Manager.

    System_CAPS_noteПримечание

    При установке Configuration Manager на клиентских компьютерах средство cmHttpsReadiness.exe устанавливается в папку %windir%\CCM. При запуске этого средства на клиентах можно использовать следующие параметры.

    • /Store:<имя>

    • /Issuers:<список>

    • /Criteria:<условия>

    • /SelectFirstCert

    Эти параметры относятся к свойствам Client.msi CCMCERTSTORE, CCMCERTISSUERS, CCMCERTSEL и CCMFIRSTCERT в указанном порядке. Дополнительные сведения об этих параметрах см. в разделе О свойствах установки клиента в Configuration Manager.

  7. Когда есть уверенность, что достаточное количество клиентов успешно используют PKI-сертификаты клиентов для проверки подлинности по протоколу HTTP, выполните следующие действия.

    1. Разверните PKI-сертификат веб-сервера на рядовом сервере, который будет использоваться как дополнительная точка управления для сайта, и настройте этот сертификат в службах IIS. Дополнительные сведения см. в разделе Развертывание сертификата веб-сервера для систем сайта с запущенными службами IIS статьи Пошаговый пример развертывания сертификатов PKI для Configuration Manager. Центр сертификации Windows Server 2008.

    2. Установите роль точки управления на этот сервер и настройте параметр Подключения клиента в свойствах точки управления для использования протокола HTTPS.

  8. Проверьте и убедитесь, что клиенты, имеющие PKI-сертификат, используют эту новую точку управления, подключаясь по протоколу HTTPS. Для контроля можно использовать журналы служб IIS или счетчики производительности.

  9. Настройте другие роли системы сайта для подключения клиентов по протоколу HTTPS. Если необходимо управлять клиентами, подключенными через Интернет, убедитесь, что системы сайта имеют полное доменное имя в Интернете, и настройте отдельные точки управления и точки распространения для приема подключений клиентов через Интернет.

    System_CAPS_importantВажно

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

  10. Расширьте зону развертывания PKI-сертификатов для клиентов и систем сайт, использующих службы IIS, и настройте роли системы сайта для подключения клиентов по протоколу HTTPS и подключения через Интернет в соответствии с требованиями.

  11. Меры для повышения безопасности. Если есть уверенность, что все клиенты используют PKI-сертификаты клиента для проверки подлинности и подключения и шифрования, измените свойства сайта для использования только протокола HTTPS.

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

Планирование доверенного корневого ключа

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

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

Клиенты могут автоматически получать открытую копию корневого ключа доверия двумя способами.

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

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

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

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

  • Заранее предоставьте корневой ключ доверия клиенту в виде файла.

  • Заранее предоставьте корневой ключ доверия клиенту, не используя файл.

  • Проверьте корневой ключ доверия на клиенте.

System_CAPS_noteПримечание

Нет необходимости заранее предоставлять клиентам корневой ключ доверия, если они могут получить его из доменных служб Active Directory или если они установлены с использованием принудительной установки. Кроме того, нет необходимости заранее предоставлять клиентам корневой ключ доверия, если они подключаются к точкам управления по протоколу HTTPS, поскольку в данном случае доверие обеспечивается посредством PKI-сертификатов.

Для удаления корневого ключа доверия с клиента используйте свойство Client.msi RESETKEYINFORMATION = TRUE совместно с CCMSetup.exe. Для замены корневого ключа доверия переустановите клиент с новым корневым ключом доверия, используя, например, принудительную установку клиента или свойство Client.msi SMSPublicRootKey совместно с CCMSetup.exe.

Предоставление корневого ключа доверия клиенту в виде файла

  1. В текстовом редакторе откройте файл <каталог_Configuration_Manager>\bin\mobileclient.tcf.

  2. Найдите запись SMSPublicRootKey=, скопируйте ключ из этой строки и закройте файл, не сохраняя изменения.

  3. Создайте новый текстовый файл и вставьте данные ключа, скопированные из файла mobileclient.tcf.

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

  5. Установите клиент одним из способов, поддерживающих свойства Client.msi, и укажите свойство Client.msi SMSROOTKEYPATH=<полный_путь_к_файлу_и_имя_файла>.

    System_CAPS_importantВажно

    При указании корневого ключа доверия для дополнительной защиты во время установки клиента необходимо также указать код сайта с помощью свойства Client.msi: SMSSITECODE=<код_сайта>.

Предоставление корневого ключа доверия клиенту без использования файла

  1. В текстовом редакторе откройте файл <каталог_Configuration_Manager>\bin\mobileclient.tcf.

  2. Найдите запись SMSPublicRootKey=, запишите ключ в из этой строки или скопируйте его в буфер обмена и закройте файл, не сохраняя изменения.

  3. Установите клиент одним из способов, поддерживающих свойства Client.msi, и укажите свойство Client.msi SMSPublicRootKey=<ключ>, где <ключ> — это строка, скопированная из файла mobileclient.tcf.

    System_CAPS_importantВажно

    При указании корневого ключа доверия для дополнительной защиты во время установки клиента необходимо также указать код сайта с помощью свойства Client.msi: SMSSITECODE=<код_сайта>.

Проверка корневого ключа доверия на клиентах

  1. В меню Пуск выберите пункт Выполнить и введите команду Wbemtest.

  2. В диалоговом окне Тестер инструментария управления Windows нажмите кнопку Подключить.

  3. В диалоговом окне подключение в поле Пространство имен введите Rootroot\ccm\locationservices и нажмите кнопку Подключить.

  4. В диалоговом окне Тестер инструментария управления Windows в разделе IWbemServices нажмите кнопку Классы.

  5. В диалоговом окне Сведения о суперклассе выберите Рекурсивно и нажмите кнопку ОК.

  6. В окне Результаты запроса прокрутите список до конца и дважды щелкните запись TrustedRootKey ().

  7. В диалоговом окне Редактор объекта TrustedRootKey нажмите кнопку Экземпляры.

  8. В новом окне Результаты запроса, где будут показаны экземпляры объекта TrustedRootKey, дважды щелкните TrustedRootKey=@

  9. В диалоговом окне Редактор объекта TrustedRootKey=@ в раздел Свойства прокрутите вниз до свойства TrustedRootKey CIM_STRING. Строка в правом столбце — это корневой ключ доверия. Убедитесь, что он совпадает со значением SMSPublicRootKey в файле <каталог_Configuration_Manager>\bin\mobileclient.tcf.

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

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

Для защиты данных, отправляемых клиентом точкам управления, можно задействовать их обязательное подписывание. Кроме того, можно задействовать обязательное подписывание подписанных данных, передаваемых по протоколу HTTP, с использованием алгоритма SHA-256. Несмотря на то что это более безопасный параметр, не следует включать его, если не все клиенты поддерживают алгоритм SHA-256. Многие операционные системы изначально поддерживают алгоритм SHA-256, однако для более старых операционных систем может потребоваться установка обновления или исправления. Например, на компьютерах под управлением Windows Server 2003 SP2 необходимо установить исправление, описанное в статье базы знаний 938397.

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

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

Планирование ролевого администрирования

Ролевое администрирование позволяет спланировать и внедрить план безопасного администрирования иерархии System Center 2012 Configuration Manager с использованием одного или всех перечисленных методов:

  • Роли безопасности

  • Коллекции

  • Области безопасности

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

System_CAPS_importantВажно

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

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

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

В System Center 2012 Configuration Manager есть несколько встроенных ролей безопасности, позволяющих выполнять стандартные административные задачи; также можно создавать свои собственные роли безопасности, соответствующие определенным бизнес-требованиям. Примеры встроенных ролей безопасности.

  • Полный администратор. Эта роль безопасности предоставляет все разрешения, предусмотренные в Configuration Manager.

  • Аналитик активов. Эта роль безопасности позволяет административным пользователям просматривать данные, собранные с помощью средства аналитики активов, инвентаризации программного обеспечения, инвентаризации оборудования и отслеживания использования программного обеспечения. Административные пользователи могут создавать категории, семейства и метки для правил отслеживания использования и аналитики активов.

  • Диспетчер обновления программного обеспечения Эта роль безопасности предоставляет разрешения, позволяющие определять и развертывать обновления программного обеспечения. Административные пользователи, связанные с этой ролью, могут создавать коллекции, группы обновления программного обеспечения, развертывания, шаблоны и включать поддержку защиты доступа к сети (NAP) для обновлений программного обеспечения.

System_CAPS_tipСовет

В консоли Configuration Manager можно просмотреть список встроенных и пользовательских ролей безопасности, включая их описания. Для этого в рабочей области Администрирование разверните узел Безопасность и выберите Роли безопасности.

Каждая роль безопасности включает определенные разрешения для различных типов объектов. Например, роль безопасности Администратор приложения имеет следующие разрешения для приложений. Утверждение, Создание, Удаление, Изменение, Изменение папок, Перемещение объектов, Чтение/развертывание, Настройка области безопасности. Разрешения для встроенных ролей безопасности изменить нельзя, однако можно скопировать роль, внести в нее изменения и сохранить в качестве новой пользовательской роли безопасности. Также можно импортировать роли безопасности, которые были ранее экспортированы из другой иерархии (например, из тестовой сети). Просмотрите роли безопасности и их разрешения, чтобы определить, подходят ли для рассматриваемой среды встроенные роли, или потребуется создать пользовательские роли безопасности.

Следующие действия помогут осуществить планирование ролей безопасности.

  1. Определите задачи, которые выполняют административные пользователи в System Center 2012 Configuration Manager. Эти задачи могут быть связаны с одной или несколькими группами задач управления, например с развертыванием приложений и пакетов, развертыванием операционных систем и параметров соответствия, настройкой сайтов и параметров безопасности, аудитом, удаленным управлением компьютерами и сбором данных инвентаризации.

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

  3. Если некоторые административные пользователи выполняют задачи, относящиеся к нескольким ролям безопасности, назначьте этим пользователям несколько ролей, но не создавайте новую роль безопасности, объединяющую в себе данные задачи.

  4. Если требуемые задачи не связаны ни с одной из встроенных ролей безопасности, создайте и протестируйте новые роли безопасности.

Сведения о том, как создать и настроить роли безопасности для ролевого администрирования см. в разделах Создание настраиваемых ролей безопасности и Настройка ролей безопасности статьи Настройка параметров безопасности Configuration Manager.

Планирование для коллекций

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

Дополнительные сведения о коллекциях см. в разделе Introduction to Collections in Configuration Manager (Введение в коллекции в Configuration Manager).

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

  • Функциональная организация. Например, могут иметь место отдельные коллекции серверов и рабочих станций.

  • Объединение по географическому расположению. Например, можно создать различные коллекции для Северной Америки и Европы.

  • Требования безопасности и бизнес-процессы. Например, можно создать отдельные коллекции для компьютеров в производственной среде и тестовых компьютеров.

  • Соответствие структуре организации. Например, можно создать отдельные коллекции для каждого филиала компании.

Сведения о настройке коллекций для ролевого администрирования см. в разделе Настройка коллекций для управления безопасностью статьи Настройка параметров безопасности Configuration Manager.

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

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

  • Все. Эта встроенная область безопасности предоставляет доступ ко всем областям действия. Этой области безопасности нельзя назначать объекты.

  • По умолчанию. Эта встроенная область безопасности используется по умолчанию для всех объектов. При первой установке System Center 2012 Configuration Manager все объекты относятся к это области безопасности.

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

  • Подписки на оповещения

  • Приложения

  • загрузочные образы,

  • Группы границ

  • элементы конфигурации,

  • Пользовательские параметры клиента

  • Точки распространения и группы точек распространения

  • пакеты драйверов,

  • Глобальные условия

  • Задания миграции

  • Образы операционной системы

  • Пакеты установки операционных систем

  • пакеты,

  • Запросы

  • Сайты

  • правила отслеживания использования программного обеспечения.

  • Группы обновлений программного обеспечения

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

  • Пакеты последовательности задач

  • Настройка элементов и пакетов для устройства Windows CE

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

Объекты, не ограничиваемые областями безопасности, включают:

  • Леса Active Directory

  • Административные пользователи

  • Предупреждения

  • Политики защиты от вредоносных программ

  • границы,

  • Связи с компьютерами

  • Параметры клиента, используемые по умолчанию

  • Шаблоны развертывания

  • Драйверы устройств

  • Соединитель Exchange Server

  • Сопоставления для миграции между сайтами

  • Профили регистрации мобильных устройств

  • Роли безопасности

  • Области безопасности

  • Адреса сайтов

  • Роли систем сайта

  • Названия программных продуктов

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

  • Сообщения о состоянии

  • Сопоставления пользователей и устройств

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

  • Имеется группа административных пользователей, которые должны видеть приложения, находящиеся в производственной среде; тестовые приложения должны оставаться для них невидимыми. Следует создать одну область безопасности для производственных приложений, а другую – для тестовых приложений.

  • Различным административным пользователям требуется различный уровень доступа к некоторым экземплярам типа объектов. Например, одной группе административных пользователей требуется разрешение Чтение в отношении определенных групп обновления программного обеспечения, а другой группе административных пользователей необходимы разрешения Изменение и Удаление для других групп обновления программного обеспечения. Создание различных областей безопасности для этих групп обновления программного обеспечения.

Сведения о настройке областей безопасности для ролевого администрирования см. в разделе Настройка областей безопасности для объекта статьи Настройка параметров безопасности Configuration Manager.