Руководство по развертыванию Device Guard

Microsoft Device Guard – это набор компонентов для защиты целостности аппаратного и программного обеспечения, который выводит на кардинально новый уровень безопасность оперативной системы Windows. В целях обеспечения современной всесторонней защиты в Windows 10 используется Device Guard, а также функции защиты целостности кода и расширенные аппаратные функции, например расширения виртуализации ЦП, доверенный платформенный модуль и преобразование адресов второго уровня. В этом руководстве описаны отдельные функции Device Guard, способы планирования, настройки и развертывания этих функций.

Введение в Device Guard

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

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

Помимо антивирусных решений доступны некоторые технологии добавления в «белый список», в том числе AppLocker. Эти технологии обрабатывают один экземпляр либо применяют правила полного разрешения или полного запрета для запущенных приложений. Хотя это способ позволяет более эффективно предотвращать заражение системы, чем способ на основе подписей, он требует постоянного обслуживания. В Windows 10 подобные программы более эффективны, если они развертываются вместе с Microsoft Device Guard.

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

Функции Device Guard кардинально меняют представления о безопасности операционной системы Windows за счет новых средств обеспечения безопасности на основе виртуализации (VBS) и модели операционной системы мобильного устройства, не доверяющей ничему, которые сильно усложняют проникновение вредоносных программ. С помощью изменяемых политик целостности кода организации могут выбирать, какие именно приложения можно будет запускать в их среде. Возможность настраивать целостность кода не ограничивается приложениями Магазина Windows и может быть применена по отношению к существующим подписанным и неподписанным приложениям Win32 без перепаковки приложения. Кроме того, функцию настраиваемой целостности кода можно развернуть отдельно, если в организации отсутствует необходимое аппаратное обеспечение для установки Device Guard. В целях обеспечения современной всесторонней защиты в Windows 10 наряду с целостностью кода используются дополнительные функции оборудования, например расширения виртуализации ЦП, модуль IOMMU, доверенный платформенный модуль (TPM) и преобразование адресов второго уровня (SLAT). Device Guard, развернутый вместе с функцией настраиваемой целостности кода и Credential Guard, является наиболее эффективным клиентским средством защиты, которое может реализовать организация на сегодняшний день. В этом руководстве вы узнаете об отдельных функциях Device Guard, а также о способах планирования, настройки и развертывания этих функций. Device Guard с настраиваемой целостностью кода предназначен для развертывания совместно с дополнительными компонентами Windows для уменьшения угроз, таких как Credential Guard и AppLocker.

Обзор Device Guard

Device Guard – это набор компонентов для защиты целостности аппаратного и программного обеспечения. Эти компоненты кардинально меняют представление о безопасности операционной системы Windows за счет новых средств обеспечения безопасности на основе виртуализации и модели операционной системы мобильного устройства, не доверяющей ничему. Основная функция, предусматриваемая данной моделью, называется настраиваемая целостность кода. Она позволяет организации выбирать, какое программное обеспечение или доверенные издатели программного обеспечения могут запускать код на ее клиентских компьютерах, что и обеспечивает столь успешную защиту мобильных телефонов. Кроме того, Device Guard дает возможность организациям подписывать существующие бизнес-приложения (LOB), чтобы их системы доверяли собственным кодам без перепаковки приложения. Такой метод подписывания также позволяет организациям доверять отдельным приложениям сторонних разработчиков. Device Guard, развернутый вместе с функцией настраиваемой целостности кода, Credential Guard и AppLocker, обеспечивает самую полную защиту безопасности, которую когда-либо мог предложить какой-либо продукт Майкрософт для клиента Windows.

Дополнительные компоненты оборудования, например расширения виртуализации ЦП, IOMMU и SLAT, позволяют реализовать эти новые функции безопасности клиента. Внедряя эти аппаратные компоненты далее в ядро операционной системы, Windows 10 использует их другими способами. Например, такая же технология низкоуровневой оболочки типа 1, используемая для запуска виртуальных компьютеров в Microsoft Hyper-V, применяется для изоляции основных служб Windows в защищенном контейнере на основе виртуализации. Это лишь один пример того, как Windows 10 внедряет расширенные функции глубже в операционную систему для обеспечения пользователям всесторонней современной защиты. Эти аппаратные компоненты в настоящее время представлены на потребительском и корпоративном рынках ПК и подробно описаны в разделе Рекомендации по оборудованию.

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

Настраиваемая целостность кода

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

Целостность кода является компонентом операционной системы Windows, который проверяет надежность и безопасность запускаемого Windows кода. Подобно операционной системе целостность кода Windows также содержит 2 основных компонента: целостность кода режима ядра (KMCI) и целостность кода пользовательского режима (UMCI). KMCI используется в последних версиях операционной системы Windows для защиты режима ядра от запуска неподписанных драйверов. Хотя драйверы и эффективны, они не единственный способ проникновения вредоносных программ в пространство режима ядра операционной системы. Однако в Windows 10 корпорация Майкрософт повысила стандарт встроенного кода режима ядра и предложила предприятиям возможность задавать свои собственные стандарты UMCI и KMCI. Корпорация Майкрософт сделала Windows 10 более безопасной, чем любая из предыдущих версий Windows, во всех отношениях, начиная от самой службы целостности кода и заканчивая политиками, которые клиент Windows использует для проверки в целях выдачи разрешения на запуск приложения. Раньше компонент UMCI был доступен только в Windows RT и на устройствах Windows Phone, что усложняло заражение данных устройств вирусами или проникновение вредоносных программ. В Windows 10 доступны такие же стандарты UMCI, доказавшие свою эффективность.

Как правило, большинство вредоносных программ не подписаны. Путем простого развертывания политик целостности кода организации смогут мгновенно защититься от неподписанных вредоносных программ, которые в 95 % случаев применяются в атаках на компьютеры. С помощью политик целостности кода предприятие может выбрать, какие именно двоичные файлы можно будет запускать в пользовательском режиме и в режиме ядра, от уровня подписанта до уровня хэш-значения. В случае полностью принудительного запуска пользовательский режим функционирует как мобильный телефон, позволяя запускать только конкретные приложения или конкретные подписи. Только одна эта функция фундаментально изменяет уровень безопасности на предприятии. Такая дополнительная защита распространяется не только на приложения Windows и не требует перезаписи приложения для обеспечения соответствия существующим неподписанным приложениям. Настраиваемую целостность кода можно применять и без Device Guard, но при наличии поддерживаемого оборудования предполагается, что данный компонент будет использоваться совместно с Device Guard. Дополнительные сведения о том, как настраивать, развертывать и управлять политиками целостности кода см. в разделе Политики целостности кода.

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

Основные функциональные возможности Device Guard и запуск защиты на аппаратном уровне. Устройства с процессорами, оснащенными технологиями SLAT и расширениями виртуализации, например Intel Virtualization Technology (VT-x) и AMD-V, будут способны использовать средства безопасности на основе виртуализации (VBS), которые повышают безопасность Windows. Device Guard использует VBS, чтобы изолировать основные службы Windows, имеющие критическое значение для безопасности и целостности операционной системы. Такая изоляция устраняет уязвимость этих служб как в пользовательском режиме, так и в режиме ядра, и служит непреодолимой преградой для большинства современных вредоносных программ. Одна из таких изолированных служб под названием Windows Code Integrity обеспечивает работу функции настраиваемой целостности кода в режиме ядра в Device Guard. Эта функция не позволяет проникшему в режиме ядра коду нанести вред службе целостности кода.

Еще одна функция Windows 10, использующая VBS, – это Credential Guard. Credential Guard обеспечивает дополнительную защиту пользователей домена Active Directory за счет хранения учетных данных домена в контейнере виртуализации, в котором размещены службы безопасности Windows, например целостность кода. Благодаря изоляции этих учетных данных домена от активного пользовательского режима и режима ядра, риск кражи данных существенно снижается. Дополнительные сведения о том, каким образом Credential Guard взаимодействует с Device Guard, см. в разделе Device Guard с Credential Guard. Сведения о том, как включить Credential Guard, см. в разделе Включение Credential Guard.

Device Guard с AppLocker

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

Примечание  Примером ситуации, в которой необходимо расширить функционал Device Guard с помощью AppLocker, может быть тот случай, когда вашей организации требуется ограничить использования универсальных приложений. Универсальные приложения проходят проверку Майкрософт на благонадежность, но организация может не захотеть, чтобы в ее среде запускались определенные универсальные приложения. Эту задачу можно выполнить с помощью правила AppLocker.
 

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

Device Guard с Credential Guard

Хотя Credential Guard не является функцией Device Guard, многие организации предпочтут развертывать ее совместно с Device Guard для обеспечения дополнительной защиты от кражи учетных данных. Подобно защите целостности кода в режиме ядра на основе виртуализации Credential Guard использует технологию низкоуровневой оболочки для защиты учетных данных домена. Такая защита ориентирована на недопущение применения техник атак «pass-the-hash» и «pass-the-ticket». Многофакторная проверка подлинности с помощью Credential Guard обеспечивает организациям дополнительную защиту от подобных угроз. Сведения о том, как развернуть Credential Guard для клиентов ОС Windows 10 Корпоративная, см. в разделе Включение Credential Guard. Помимо включения Credential Guard со стороны клиента организации также могут развертывать средства защиты как на уровне центра сертификации, так и на уровне контроллера домена для предотвращения кражи учетных данных. В будущем корпорация Майкрософт будет выпускать подробные сведения об этих дополнительных защитных компонентах.

Унифицированные возможности управления

Функциями Device Guard можно легко управлять с помощью хорошо знакомых клиентских и корпоративных средств управления, которые ИТ-специалисты используют каждый день. Ниже приведены средства управления, используемые для включения и управления Device Guard.

  • Групповая политика. Windows 10 предоставляет административный шаблон для настройки и развертывания настраиваемых политик целостности кода в вашей организации. Этот шаблон также позволяет указывать, какие аппаратные функции безопасности необходимо включить и развернуть. Вы можете изменять эти настройки вместе со своими существующими объектами групповой политики (GPO) в целях упрощения применения функций Device Guard. Помимо этих функций на основе целостности кода и аппаратных функций безопасности можно использовать групповую политику для управления файлами каталога. Дополнительные сведения о файлах каталога см. в разделе Файлы каталога.

  • Microsoft System Center Configuration Manager. С помощью System Center Configuration Manager можно упростить развертывание и управление файлами каталога, политиками целостности кода и аппаратными функциями безопасности, а также обеспечить управление версиями. Дополнительные сведения о развертывании файлов каталога с помощью System Center Configuration Manager см. в разделе Развертывание файлов каталога с помощью System Center Configuration Manager.

  • Microsoft Intune. В последующих выпусках Microsoft Intune организации смогут использовать Intune для развертывания и управления политиками целостности кода и файлами каталога.

  • Windows PowerShell. Windows PowerShell используется, в первую очередь, для создания и обслуживания политик целостности кода. Эти политики представляют собой наиболее значимый компонент Device Guard. Пошаговое руководство по созданию, контролю, обслуживанию, применению и развертыванию политик целостности кода см. в разделе Политики целостности кода.

Вы сможете использовать привычный порядок, который вы использовали для работы с существующими инструментами для управления предприятием. Дополнительные сведения о том, как управлять и развертывать аппаратные средства и функции целостности кода Device Guard в своей организации см. в разделе Развертывание Device Guard.

Планирование для Device Guard

В этом разделе рассмотрены следующие темы.

  • Подход к развертыванию целостности кода предприятия. Развертывание Device Guard в вашей организации требует продуманного подхода. В этом разделе вы получите общие рекомендации в отношении подхода к развертыванию целостности кода предприятия в вашей организации.

  • Сценарии развертывания Device Guard. При планировании развертывания Device Guard Майкрософт рекомендует распределить все устройства в вашей организации по категориям в сценарии развертывания. Эти сценарии послужат схемой для развертывания Device Guard.

  • Принятие подписывания кода. Подписывание кода имеет большое значение для обеспечения безопасности Device Guard. В этом разделе описаны параметры подписывания кода, а также преимущества и недоставки каждого метода.

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

Подход к развертыванию целостности кода предприятия

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

  1. Сгруппируйте устройства по функциям. Выполните классификацию компьютеров по группам в соответствии с описанием, приведенным в разделе Сценарии развертывания Device Guard. Это послужит вам в качестве схемы для развертывания Device Guard, и вы сможете работать с группами простых и более сложных для развертывания компонентов. На этом этапе необходимо определить необходимое количество политик Device Guard. Самое простое решение – блокировка всего предприятия, однако это может противоречить требованиям отдельных отделов.

    Чтобы определить нужное количество политик для своей организации, попробуйте разделить созданные группы на отделы или по функциям. Затем задайте себе несколько вопросов: какое программное обеспечение требуется каждому отделу или сотруднику для выполнения своей работы? Должны ли они иметь возможность устанавливать и запускать программное обеспечение других отделов? Нужно ли нам создать базовую политику целостности кода, соответствующую нашему каталогу приложений? Должны ли пользователи иметь возможность устанавливать любое приложение или же они будут выбирать из списка разрешенных приложений? Разрешаем ли мы пользователи использовать собственные периферийные устройства? Эти вопросы помогут вам определить необходимое количество политик для вашей организации. И, наконец, проанализируйте, для каких сотрудников или отделов потребуется дополнительный уровень привилегий. Например, должна ли у отдела x быть возможность устанавливать и запускать приложение xyz, в то время как у других отделов такой возможности нет? Если ответ будет положительный и обоснованный, вам понадобится дополнительная политика целостности кода для этой группы. Если нет, вы, вероятно, сможете объединить несколько политик для упрощения управления. Дополнительные сведения о настраиваемых политиках целостности кода см. в разделе Политики целостности кода.

  2. Создание политик целостности кода из «золотых» компьютеров. После создания группы устройств можно создать политики целостности кода для сопоставления с этими группами, точно так же, как вы бы управляли корпоративными образами. После разделения этих групп и настройки «золотых» компьютеров, имитирующих программное и аппаратное обеспечение, требуемое для этих отдельных групп, создайте политики целостности кода из каждого из них. После создания политики целостности кода можно либо объединить для создания главной политики либо управлять и развертывать их по отдельности. Пошаговые инструкции по созданию политик целостности кода см. в разделе Создание политик целостности кода из «золотых» компьютеров.

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

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

  5. Включение нужных аппаратных функций безопасности. Для каждого типа устройств, описанного в разделе Сценарии развертывания Device Guard, используются различные конфигурации целостности программного и аппаратного обеспечения. Аппаратные функции безопасности следует оценивать отдельно от политик целостности кода, так как они обеспечивают дополнительный функционал. Сведения о том, как настроить аппаратные функции безопасности Device Guard см. в разделе Настройка аппаратных функций безопасности.

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

Сценарии развертывания Device Guard

Для упрощения развертывания Device Guard в вашей организации корпорация Майкрософт рекомендует группировать устройства по сценариями развертывания, описанным в данном разделе. Device Guard – это не просто функция, которую можно «включить». Здесь требуется поэтапный метод внедрения. Чтобы узнать, каким образом сценарии вписываются в общий подход к развертыванию Device Guard, см. раздел Подход к развертыванию целостности кода предприятия.

Устройства с фиксированной нагрузкой

Списки утвержденных приложений на устройствах с фиксированной нагрузкой редко изменяются, поскольку такие устройства выполняют ежедневно одни и те же задачи. Это могут быть такие устройства, как киоски, системы кассовых терминалов и компьютеры в центрах обработки вызовов. Эти устройства могут легко использовать все функции Device Guard, не требуя особого контроля или изменения политик. Развертывание Device Guard на таких устройствах проходит легко, после чего устройство требует лишь минимального текущего обслуживания. После полного развертывания Device Guard пользователи могут запускать только те приложения, которые устанавливает, администрирует и которым доверяет ИТ-отдел.

Device Guard включает следующие компоненты, поддерживаемые устройствами с фиксированной нагрузкой:

  • защита KMCI VBS;

  • принудительная политика UMCI.

Полностью управляемые устройства

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

Device Guard включает следующие компоненты, поддерживаемые полностью управляемыми устройствами:

  • защита KMCI VBS;

  • принудительная политика UMCI.

В этом сценарии предоставляется список доверенных приложений; при этом политика постоянно переоценивается, когда пользователь запрашивает новое приложение. Если какое-либо приложение является доверенным на всех подобных устройствах, запрос пользователя на установку такого приложения не требует обновления политики (согласования с каталогом приложений). Кроме того, данный процесс можно объединить с процессом адаптации для новых приложений, которые необходимо добавить в центральный каталог приложений. Первоначальное развертывание Device Guard на полностью управляемых устройствах не составляет труда, но требует больше административного контроля для управления доверенными подписями новых запрошенных и утвержденных приложений.

Частично управляемые устройства

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

Device Guard включает следующие компоненты, поддерживаемые частично управляемыми устройствами:

  • защита KMCI VBS;

  • политика UMCI в режиме аудита.

Модель «Принеси свое устройство»

Device Guard не очень подходит для управления устройствами, если в организации принята модель «Принеси свое устройство» (BYOD). Если сотрудникам разрешается приносить собственные устройства, управление установленными на них приложениями в пользовательском режиме может усложнить использование этих устройств, когда пользователи не на работе. Кроме того, в этом случае администратору трудно обеспечить работоспособность Device Guard. Для устройств, находящихся в этой группе, следует рассмотреть другие функции защиты и обеспечения безопасности с помощью решений условного доступа на основе MDM, таких как Microsoft Intune.

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

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

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

Существующие бизнес-приложения

До недавнего времени, существующие бизнес-приложения было сложно добавить в список доверия, если они были подписаны не Магазином Windows или не были подписаны вообще. В Windows 10 подписывание существующих бизнес-приложений и неподписанных приложений сторонних разработчиков упрощено. Этот новый метод подписывание не предусматривает перепаковки приложений. С файлами каталога администраторы могут легко подписывать такие неподписанные приложения с помощью данных, полученных в процессе наблюдения за установкой и первоначальным запуском. Используя данные наблюдений, администратор может создать файл каталога. Файлы каталога представляют собой простые списки хэширования алгоритма SHA-2 обнаруженных двоичных файлов. Хэш-значения этих двоичных файлов обновляются при каждом обновлении приложения, и поэтому требуется обновленный файл каталога. Для упрощения администрирования следует рассмотреть возможность включения в процесс разработки приложений подписывания встроенного кода. Дополнительные сведения о том, как создавать файлы каталога см. в разделе Файлы каталога.

Примечание  

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

 

При создании файла каталога вам необходимо подписать его с помощью инфраструктуры открытых ключей предприятия (PKI) или приобретенного сертификата подписи кода. В случае подписывания файлов политики целостности кода смогут доверять средству или сертификату подписи этих файлов. Сведения о подписывании файлов каталога см. в разделе Файлы каталога.

Разработка приложений

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

Рекомендации по оборудованию

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

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

ТребованиеОписание

Windows 10 Корпоративная

Компьютер должен работать под управлением ОС Windows 10 Корпоративная.

Микропрограммное обеспечение UEFI версии 2.3.1 или старше и поддержка безопасной загрузки

Чтобы убедиться, что микропрограммное обеспечение использует UEFI 2.3.1 или более поздней версии и безопасную загрузку, можно выполнить проверку на соответствие требованиям Программы совместимости оборудования для Windows, воспользовавшись следующей ссылкой: System.Fundamentals.Firmware.CS.UE FISecureBoot.ConnectedStandby.

Расширения виртуализации

Для поддержки безопасности на основе виртуализации необходимы указанные ниже расширения виртуализации.

  • Intel VT-x или AMD-V
  • Преобразование адресов второго уровня

Блокировка встроенного ПО

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

Архитектура x64

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

Модуль IOMMU (модуль управления памятью для операций ввода-вывода) VT-d или AMD-Vi

В Windows 10 модуль IOMMU повышает устойчивость системы к атакам на память. ¹

Процесс безопасного обновления встроенного ПО

Чтобы убедиться, что встроенное ПО поддерживает процесс безопасного обновления, можно проверить его на соответствие требованиям Программы совместимости оборудования для Windows, перейдя по ссылке System.Fundamentals.Firmware.UEFISecureBoot.

 

Развертывание Device Guard

В этом разделе рассматриваются следующие темы.

  • Настройка аппаратных функций безопасности. В этом разделе объясняется, как подключать аппаратные функции безопасности в Device Guard. Кроме того, необходимо убедиться, что функции включены, с помощью инфраструктуры управления Windows (WMI) и Msinfo32.exe.

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

  • Политики целостности кода. В этом разделе содержится информация о том, как создавать, проверять, объединять, развертывать и удалять подписанные и неподписанные политики настраиваемой целостности кода.

Настройка аппаратных функций безопасности

Аппаратные функции представляют собой одну из ключевых частей предлагаемой системы безопасности Device Guard. VBS усиливает самую важную функцию Device Guard – настраиваемую целостность кода. Настройка аппаратных функций безопасности в Device Guard выполняется в 3 этапа.

  1. Проверка соблюдения требований к оборудованию и статуса оборудования. Убедитесь, что ваши клиентские компьютеры оснащены необходимым оборудованием для использования данных функций. Список требований к оборудованию для использования аппаратных функций безопасности приведен в разделе с Рекомендации по оборудованию. Кроме того, если вам необходимо новое оборудование, обратите внимание на устройства, описанные в разделе Устройства, готовые к установке Device Guard.

  2. Включение необходимых функций Windows. Существует несколько способов включения функций Windows, необходимых для использования аппаратных функций безопасности. Дополнительные сведения о том, какие необходимы функции Windows, см. в разделе Требования к функциям Windows для обеспечения безопасности на основе виртуализации.

  3. Включение необходимых функций. Включив необходимые аппаратные функции и функции Windows, вы сможете включить нужные аппаратные функции безопасности. Сведения о безопасной загрузке UEFI см. в разделе Включение безопасной загрузки UEFI. Сведения о том, как включить защиту VBS службы KMCI см. в разделе Включение защиты целостности кода в режиме ядра на основе виртуализации. И, наконец, сведения о том, как включить Credential Guard, см. в разделе Включение Credential Guard.

Требования к функциям Windows для обеспечения безопасности на основе виртуализации

Помимо выполнения требований к аппаратному обеспечению, указанных в разделе Рекомендации по оборудованию, необходимо также включить определенные функции операционной системы, прежде чем вы сможете включить VBS: Microsoft Hyper-V и изолированный пользовательский режим (показаны на рисунке 1).

Примечание  

Эти функции можно настроить вручную с помощью Windows PowerShell или системы обслуживания образов развертывания и управления ими (DISM). Подробные сведения об этих методах см. в документации Credential Guard.

 
Рисунок 1

Рисунок 1. Включение компонентов операционной системы для VBS

Включив данные компоненты, вы сможете настраивать все необходимые аппаратные функции безопасности. Сведения о том, как включать защиту на основании виртуализации в режиме ядра, см. в разделе Включение защиты целостности кода в режиме ядра на основе виртуализации. Сведения о том, как включить безопасную загрузку UEFI см. в разделе Включение безопасной загрузки UEFI (единый интерфейс EFI). И, наконец, дополнительные сведения о том, как включить Credential Guard, см. в разделе Включение Credential Guard.

Включение безопасной загрузки единого интерфейса EFI

Перед началом этого процесса убедитесь, что целевое устройство соответствует требованиям к оборудованию для безопасной загрузки UEFI, приведенными в разделе Рекомендации по оборудованию. Предусмотрено два варианта настройки безопасной загрузки UEFI: ручная настройка конфигурации соответствующих разделов реестра и развертывание групповой политики. Выполните следующие действия, чтобы вручную настроить безопасную загрузку UEFI на компьютере под управлением Windows 10.

Примечание  

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

 
  1. Перейдите к подразделу реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.

  2. Установите для параметра EnableVirtualizationBasedSecurity DWORD значение 1.

  3. Задайте соответствующее значение для параметра RequirePlatformSecurityFeatures DWORD.

    • Установите значение 1, чтобы включить параметр Безопасная загрузка.

    • Установить значение 2, чтобы включить параметр Безопасная загрузка с защитой DMA.

  4. Перезапустите клиентский компьютер.

К сожалению, если выполнять этот процесс вручную на каждом защищенном компьютере вашей организации, это занимает много времени. Групповая политика существенно упрощает процесс развертывания безопасной загрузки UEFI в вашей организации. В этом примере создается тестовое подразделение под названием DG Enabled PCs. Если для вас предпочтительнее привязать политику к существующему подразделению, а затем определить область GPO, используя группы компьютерной безопасности с соответствующими именами, вы, конечно, можете так поступить.

Примечание  

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

 

Использование групповой политики для развертывания функции безопасной загрузки

  1. Для создания нового объекта групповой политики, щелкните правой кнопкой мыши название подразделения, к которому следует привязать объект групповой политики, а затем щелкните Создать объект групповой политики в этом домене и связать его.

    Рисунок 2

    Рисунок 2. Создание нового объекта групповой политики, привязанного к подразделению

  2. Назовите новый объект групповой политики Тестовый GPO безопасной загрузки Contoso. В этом примере используется имя объекта групповой политики Contoso Secure Boot GPO Test. Вы можете выбрать любое имя для данного примера. В идеале имя должно соответствовать существующему контексту именования объектов групповой политики.

  3. Чтобы открыть редактор «Управление групповыми политиками», щелкните правой кнопкой мыши новый объект групповой политики, а затем щелкните Изменить.

  4. В выбранном объекте групповой политики перейдите по следующему пути: Конфигурация компьютера\Административные шаблоны\Система\Device Guard. Затем щелкните правой кнопкой мыши Включить средство обеспечения безопасности на основе виртуализации, а затем щелкните Изменить.

    Рисунок 3

    Рисунок 3. Включение VBS

  5. Установите значение Включено, а затем выберите пункт Безопасная загрузка и защита DMA из списка Выберите уровень безопасности платформы.

    Рисунок 4

    Рисунок 4. Включение безопасной загрузки

    Примечание  

    Функция безопасной загрузки Device Guard максимально эффективна в сочетании с защитой DMA. Если ваше оборудования включает IOMMU, необходимые для защиты DMA, обязательно выбирайте уровень безопасности платформы Безопасная загрузка и защита DMA. Если ваше оборудования не включает IOMMU, есть несколько уровней защиты, доступных при использовании безопасной загрузки без защиты DMA.

     
  6. Закройте редактор «Управление групповыми политиками» и перезапустите тестовый компьютер под управлением Windows 10. После настройки этого параметра функция безопасной загрузки UEFI включится, когда вы перезагрузите компьютер.

  7. Проверьте журнал событий тестового компьютера для объектов групповой политики Device Guard.

    Обработанные политики Device Guard записываются в средстве просмотра событий в разделе Журналы приложения и служб\Microsoft\Windows\DeviceGuard-GPEXT\Операционные. После успешной обработки политики Включить средство обеспечения безопасности на основе виртуализации в журнал записывается событие под номером 7000, в котором содержатся данные о выбранных параметрах политики.

Включение средства обеспечения безопасности целостности кода в режиме ядра на основе виртуализации

Перед началом этого процесса убедитесь, что нужный компьютер соответствует требованиям к оборудованию для VBS, приведенным в разделе Рекомендации по оборудованию и включите функции Windows, описанные в разделе Требования к функциям Windows для обеспечения безопасности на основе виртуализации. После такой проверки можно включить защиту KMCI на основе виртуализации одним из следующих способов: ручная настройка соответствующих подразделов реестра и развертывание групповой политики.

Примечание  

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

 

Ниже описан порядок ручной настройки защиты KMCI на основе виртуализации.

  1. Перейдите к подразделу реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.

  2. Установите для параметра HypervisorEnforcedCodeIntegrity DWORD значение 1.

  3. Перезапустите клиентский компьютер.

Если выполнять этот процесс вручную на каждом защищенном компьютере вашей организации, это займет много времени. Вместо этого используйте групповую политику для развертывания защиты KMCI на основе виртуализации. В этом примере создается тестовое подразделение под названием DG Enabled PCs, которое можно использовать для привязки GPO. Кроме того, вместо создания тестового подразделения можно привязать политику к существующему подразделению, а затем определить область GPO, используя группы компьютерной безопасности с соответствующими именами.

Примечание  

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

 

Порядок применения групповой политики для настройки VBS KMCI

  1. Создайте новый объект групповой политики: щелкните правой кнопкой мыши название подразделения, к которому следует привязать объект групповой политики, а затем щелкните Создать объект групповой политики в этом домене и связать его.

    Рисунок 5

    Рисунок 5. Создание нового объекта групповой политики, привязанного к подразделению

  2. Назовите новый объект групповой политики Тестовый GPO защиты целостности кода VBS Contoso.

    В этом примере используется имя объекта групповой политики Contoso VBS CI Protection GPO Test. Можно выбрать любое другое имя для этого примера. В идеале это имя должно соответствовать существующей концепции именования объектов групповой политики.

  3. Откройте редактор «Управление групповыми политиками»: щелкните правой кнопкой мыши новый объект групповой политики, а затем щелкните Изменить.

  4. В выбранном объекте групповой политики перейдите по следующему пути: Конфигурация компьютера\Административные шаблоны\Система\Device Guard. Затем щелкните правой кнопкой мыши Включить средство обеспечения безопасности на основе виртуализации, а затем щелкните Изменить.

    Рисунок 6

    Рисунок 6. Включение VBS

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

    Рисунок 7

    Рисунок 7. Включение VBS KMCI

  6. Закройте редактор «Управление групповыми политиками» и перезапустите тестовый компьютер под управлением Windows 10. После настройки данного параметра VBS KMCI включится, когда вы перезагрузите компьютер.

  7. Проверьте журнал событий тестового клиента для объектов групповой политики Device Guard.

    Обработанные политики Device Guard записываются в средстве просмотра событий в разделе Журналы приложения и служб\Microsoft\Windows\DeviceGuard-GPEXT\Операционные. После успешной обработки политики Включить средство обеспечения безопасности на основе виртуализации в журнал записывается событие под номером 7000, в котором содержатся данные о выбранных параметрах политики.

Включение Credential Guard

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

Перед началом этого процесса убедитесь, что нужный компьютер соответствует требованиям к оборудованию для VBS, приведенным в разделе Рекомендации по оборудованию и что включены функции Windows, приведенные в разделе Требования к функциям Windows для обеспечения безопасности на основе виртуализации. После проверки вы можете вручную включить Credential Guard, настроив соответствующие подразделы реестра или путем развертывания групповой политики.

Порядок ручной настройки VBS Credential Guard

  1. Перейдите к подразделу реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\\Control\Lsa.

  2. Установите для параметра LsaCfgFlags DWORD значение 1.

  3. Перезапустите клиентский компьютер.

Чтобы не терять лишнего времени на ручное развертывание, используйте групповую политику для развертывания Credential Guard в вашей организации. В этом примере создается тестовое подразделение под названием DG Enabled PCs. Для включения Credential Guard можно установить привязку к любому подразделению, а затем определить область применения объектов групповой политики с помощью групп безопасности.

Примечание  

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

 

Использование групповой политики для включения Credential Guard

  1. Создайте новый объект групповой политики: щелкните правой кнопкой мыши название подразделения, к которому следует привязать объект групповой политики, а затем щелкните Создать объект групповой политики в этом домене и связать его.

    Рисунок 8

    Рисунок 8. Создание нового объекта групповой политики, привязанного к подразделению

  2. Назовите новый объект групповой политики Тестовый GPO Credential Guard Contoso.

    В этом примере используется имя объекта групповой политики Contoso Credential Guard GPO Test. Можно выбрать любое другое имя для этого примера. В идеале это имя должно соответствовать существующей концепции именования объектов групповой политики.

  3. Откройте редактор «Управление групповыми политиками»: щелкните правой кнопкой мыши новый объект групповой политики, а затем щелкните Изменить.

  4. В выбранном объекте групповой политики перейдите по следующему пути: Конфигурация компьютера\Административные шаблоны\Система\Device Guard. Щелкните правой кнопкой мыши Включить средство обеспечения безопасности на основе виртуализации, а затем щелкните Изменить.

    Рисунок 9

    Рисунок 9. Включение VBS

  5. Выберите вариант Включено, а затем установите флажок Включить Credential Guard.

    Рисунок 10

    Рисунок 10. Включение Credential Guard

  6. Закройте редактор «Управление групповыми политиками» и перезапустите тестовый компьютер под управлением Windows 10.

    Примечание  

    Уровень безопасности платформы по умолчанию – безопасная загрузка. Если в защищенных компьютерах имеются IOMMU, рекомендуется выбрать Безопасная загрузка и защита DMA для обеспечения максимально эффективной защиты с помощью Credential Guard.

     
  7. Проверьте журнал событий тестового клиента для объектов групповой политики Device Guard.

Примечание  

Все обработанные политики Device Guard записываются в средстве просмотра событий в разделе Журналы приложения и служб\Microsoft\Windows\DeviceGuard-GPEXT\Операционные.

 

Дополнительные сведения о принципе работы Credential Guard, а также дополнительные параметры конфигурации см. в документации Credential Guard.

Проверка включенных аппаратных функций безопасности Device Guard

Windows 10 и Windows Server 2016 и более поздних версий имеют класс WMI по свойствам и функциям, связанным с Device Guard: Win32_DeviceGuard. Этот класс можно запросить из одного из сеансов Windows PowerShell с повышенными правами с помощью следующей команды:

Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard

Примечание  

Класс WMI Win32_DeviceGuard доступен только в версии Windows 10 Корпоративная.

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

 

Таблица 1. Свойства Win32_DeviceGuard

СвойстваОписаниеДопустимые значения
AvailableSecurityPropertiesЭто поле позволят регистрировать и сообщать о состоянии соответствующих свойств безопасности Device Guard.
  • 0. Означает, что на устройстве отсутствуют соответствующие свойства.

  • 1. Означает, что предусмотрена поддержка низкоуровневой оболочки.

  • 2. Означает, что доступна безопасная загрузка.

  • 3. Означает, что доступна защита DMA.

InstanceIdentifierСтрока, уникальная для конкретного устройства.Определено WMI.
RequiredSecurityPropertiesВ этом поле содержится описание свойств безопасности, необходимых для включения средства обеспечения безопасности на основе виртуализации.
  • 0. Ничего не требуется.

  • 1. Означает, что требуется безопасная загрузка.

  • 2. Означает, что требуется защита DMA.

  • 3. Означает, что требуются и безопасная загрузка и защита DMA.

SecurityServicesConfiguredВ этом поле указано, настроен ли Credential Guard или служба HVCI.
  • 0. Никакие службы не настроены.

  • 1. Означает, что настроен Credential Guard.

  • 2. Означает. что настроена служба HVCI.

SecurityServicesRunningВ этом поле указано, работает ли Credential Guard или служба HVCI.
  • 0. Никакие службы не выполняются.

  • 1. Означает, что запущен Credential Guard.

  • 2. Означает, что запущена служба HVCI.

VersionВ этом поле указана версия данного класса WMI.Единственным допустимым значением на данный момент является 1.0.
VirtualizationBasedSecurityStatusВ этом поле содержатся сведении о включении и выполнении VBS.
  • 0. VBS не включен.

  • 1. VBS включен, но не работает.

  • 2. VBS включен и работает.

PSComputerNameВ этом поле указано имя компьютера.Все допустимые значения имени компьютера.

 

Другим методом определения доступных и включенных функций Device Guard является запуск msinfo32.exe из одного из сеансов PowerShell высшего уровня. При запуске этой программы свойства Device Guard отображаются в нижней части раздела Сведения о системе, как показано на рисунке 11.

Рисунок 11

Рисунок 11. Свойства Device Guard в сведениях о системе

Файлы каталога

Для успешного применения Device Guard в системе необходимо, чтобы у каждого доверенного приложения была подпись, либо чтобы их двоичные хэш-значения были добавлены в политику целостности кода. Для многих организаций это может стать проблемой в случае использования неподписанных бизнес-приложений. Чтобы организациям не нужно было перепаковывать и подписывать эти приложения, в Windows 10 предусмотрено средство под названием Package Inspector, которое контролирует процесс установки любых развертываемых и выполняемых двоичных файлов. Если средство обнаруживает такие файлы, оно заносит их в файл каталога. Эти файлы каталога дают возможность добавить в список доверия ваши существующие неподписанные приложения, разработанные вашей организацией или приобретенные у сторонних разработчиков, а также подписанные приложения в том случае, если следует доверять конкретному приложению, а не подписи. После создания эти файлы можно подписать, добавить сертификаты подписи в ваши существующие политики целостности кода, а сами файлы каталога передать клиентам.

Примечание  

Для создания и использования файлов каталога должна быть установлена ОС Windows 10 Корпоративная или Windows Server 2016.

 

Создание файлов каталога

Создание файлов каталога – это первый этап процесса добавления неподписанного приложения в политику целостности кода. Для создания файла каталога скопируйте каждую из указанных ниже команд в сеанс Windows PowerShell с повышенными правами, а затем выполните описанные ниже действия.

Примечание  

Если создать контекст именования, вам будет легче обнаруживать развернутые файлы каталога в будущем. В этом руководстве в качестве контекста именования используется *-Contoso.cat. Дополнительные сведения об эффективном использовании данной методики для инвентаризации или выявления файлов каталога см. в разделе Учет файлов каталога с помощью System Center Configuration Manager.

 
  1. Убедитесь, что политика целостности в данный момент выполняется в режиме аудита.

    Package Inspector не всегда выявляет установочные файлы, удаленные с компьютера в процессе установки. Для того чтобы эти двоичные файлы также добавлялись в список доверия, необходимо развернуть политику целостности кода, которая была создана и проверялась в разделах Создание политик целостности кода из «золотых» компьютеров и Аудит политик целостности кода, в режиме аудита в системе, на которой запущен Package Inspector.

    Примечание  

    Этот процесс не должен выполняться в системе, на которой запущена и используется политика Device Guard; это должно происходить только при запущенной в режиме аудита политике. Если политика в данный момент используется, вы не сможете установить и запустить приложение.

     
  2. Запустите Package Inspector и выполните сканирование диска C.

    PackageInspector.exe Start C:

    Примечание  

    Package Inspector может контролировать установки на любом локальном диске. В этом примере мы устанавливаем приложение на диск C, но вы можете выбрать любой другой диск.

     
  3. Скопируйте установочные носитель на диск C.

    Копирование установочного носителя на диск C позволяет Package Inspector обнаружить и внести в каталог фактический установщик. Если вы пропустите этот шаг, будущая политика целостности кода может разрешить запуск приложения и запретить установку.

  4. Установите и запустите приложение.

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

    Примечание  

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

     
  5. Остановите сканирование, а затем создайте файлы определения и каталога. После завершения установки и первоначальной настройки остановите сканирование Package Inspector и создайте файлы каталога и определения на рабочем столе с помощью следующих команд:

    $ExamplePath=$env:userprofile+"\Desktop"

    $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"

    $CatDefName=$ExamplePath+"\LOBApp.cdf"

    PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName

Примечание  

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

 

После завершения файлы будут сохранены на рабочий стол. Чтобы этот файл каталога был добавлен в список доверия политики целостности кода, каталог должен быть вначале подписан. Затем сертификат подписи можно включить в политику целостности кода, а файл каталога можно передать на отдельные клиентские компьютеры. Файлы каталога можно подписать с помощью сертификата и SignTool.exe, бесплатного средства, включенного в Windows SDK. Дополнительные сведения о подписывании файлов каталога с помощью SignTool.exe см. в разделе Подписывание каталога с помощью SignTool.exe.

Подписывание каталога с помощью SignTool.exe

С помощью Device Guard организации могут легко подписывать и добавлять в список доверия имеющиеся у них бизнес-приложения. В этом разделе вы подпишете файл каталога, созданный в предыдущем разделе с помощью PackageInspector.exe. Сведения о том, как создавать файлы каталога, см. в разделе Создание файлов каталога. В этом примере вам потребуется следующее:

  • SignTool.exe, который находится в пакете средств разработки программного обеспечения для Windows (SDK – Windows 7 или более поздней версии);

  • файл каталога, созданный в разделе, Создание файлов каталога, или другой созданный вами файл каталога;

  • сертификат подписи кода из внутреннего центра сертификации или купленный сертификат подписи кода.

Если у вас нет сертификат подписи кода, в разделе Создание сертификата подписи кода Device Guard приведено пошаговое руководство по его созданию. Помимо использования сертификата, созданного в разделе Создание сертификата подписи кода Device Guard, этот пример предполагает подписывание файла каталога, созданного в разделе Создание файлов каталога. Если вы используете другие сертификат или файл каталога, указывайте на последующих этапах соответствующие переменные и сертификат. Для подписания существующего файла скопируйте каждую из следующих команд в сеанс Windows PowerShell с повышенными правами:

  1. Инициализируйте переменные, которые будут использоваться:

    
    $ExamplePath=$env:userprofile+"\Desktop"
    
    
    
    $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
    
    
    Примечание  

    В этом примере вы используете файл каталога, созданный в разделе Создание файлов каталога. Если вы подпишете другой файл каталога, обязательно обновите переменные $ExamplePath и $CatFileName, указав правильные значения.

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

  3. Подпишите файл каталога с помощью Signtool.exe:

    
    <Path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
    
    
    Примечание  

    Переменная <Path to signtool.exe> должна представлять собой полный путь к служебной программе Signtool.exe. ContosoDGSigningCert – это имя субъекта сертификата, используемого для подписывания файла каталога. Этот сертификат необходимо импортировать в ваше личное хранилище сертификатов на компьютере, с помощью которого вы пытаетесь подписать файл каталога.

     
    Примечание  

    Дополнительные сведения о служебной программе Signtool.exe и всех дополнительных настройках см. на странице средства подписывания MSDN.

     
  4. Проверка цифровой подписи файла каталога. Правой кнопкой мыши щелкните файл каталога и выберите Свойства. На вкладке Цифровые подписи убедитесь в наличии вашего сертификата с алгоритмом sha256, как показано на рисунке 12.

    Рисунок 12

    Рисунок 12. Проверка наличия сертификата подписи

  5. Скопируйте файл каталога в папку C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.

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

Развертывайте файлов каталога с групповой политикой

Для упрощения управления файлами каталога можно использовать предпочтения групповой политики для развертывания файлов каталога на соответствующих компьютерах вашей организации. Далее приведено описание процедуры развертывания подписанного файла каталога под названием LOBApp-Contoso.cat в тестовых подразделениях, которые называются «ПК с поддержкой DG», с объектами групповой политики под названием Тестовый GPO файла каталога DG Contoso.

Примечание  

Это пошаговое руководство предполагает предварительное создание подписанного файла каталога и наличие клиентского ПК с ОС Windows 10, на котором будет выполняться пробное развертывание групповой политики. Дополнительные сведения о создании и подписывании файла каталога см. в разделе Файлы каталога.

 

Порядок развертывания файла каталога с групповой политикой.

  1. Откройте консоль управления групповыми политиками (GPMC) на контроллере домена или клиентском компьютере с установленными средствами удаленного администрирования сервера (RSAT), запустив файл GPMC.MSC или выполнив поиск по запросу «управление групповыми политиками».

  2. Создайте новый объект групповой политики: щелкните правой кнопкой мыши подразделение «ПК с поддержкой DG» и выберите Создать объект групповой политики в этом домене и связать его, как показано на рисунке 13.

    Примечание  

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

     
    Рисунок 13

    Рисунок 13. Создание нового объекта групповой политики

  3. Назовите новый объект групповой политики Тестовый GPO файла каталога DG Contoso.

    В этом примере используется имя объекта групповой политики Contoso DG Catalog File GPO Test . Можно выбрать любое другое имя для этого примера.

  4. Откройте редактор «Управление групповыми политиками»: щелкните правой кнопкой мыши новый объект групповой политики, а затем щелкните Изменить.

  5. В выбранном объекте групповой политики перейдите в папку Конфигурация компьютера\Параметры\Параметры Windows\Файлы. Щелкните правой кнопкой мыши Файлы, наведите указатель на пункт Создать, а затем щелкните Файл, как показано на рисунке 14.

    Рисунок 14

    Рисунок 14. Создание нового файла

  6. Настройка общего доступа к файлу каталога.

    Для того чтобы можно было использовать этот параметр для последовательного развертывания файла каталога LOBApp-Contoso.cat, исходный файл должен находиться на общем ресурсе, доступном для учетной записи каждого компьютера, на котором будет выполняться развертывание. В этом используется общий ресурс на клиентском компьютере под управлением ОС Windows 10 с именем \\Contoso-Win10\Share. Развертываемый файл каталога копируется на этот общий ресурс.

  7. Для согласования версий в диалоговом окне Свойства нового файла (рис. 15) выберите пункт Заменить из списка Действие, чтобы всегда использовалась самая новая версия.

    Рисунок 15

    Рисунок 15. Настройка свойств нового файла

  8. В поле Исходные файлы введите имя доступного общего ресурса, которое включает имя файла каталога (например, \\Contoso-Win10\share\LOBApp-Contoso.cat).

  9. В поле Конечный файл введите C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-Contoso.cat.

    Примечание  

    Каталог не обязательно должен называться именно LOBApp-Contoso.cat. Это имя было использовано в разделе Создание файлов каталога, поэтому мы использовали его и в этом случае.

     
  10. На вкладке Общие диалогового окна Свойства нового файла выберите Удалить этот элемент, если он больше не применяется. В этом случае данный файл каталога будет удален из каждой системы в том случае, если вы захотите удалить это приложение из списка доверия.

  11. Щелкните ОК для завершения процедуры создания файла.

  12. Закройте редактор «Управление групповыми политиками» и обновите политику на тестовом компьютере с Windows 10, запустив файл GPUpdate.exe. В случае обновления политики убедитесь в существовании файла каталога в папке C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} на компьютере с ОС Windows 10.

Развертывание файлов каталога с помощью System Center Configuration Manager

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

Примечание  

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

 
  1. Откройте консоль Configuration Manager и выберите рабочее пространство библиотеки программного обеспечения.

  2. Перейдите к разделу Обзор\Управление приложениями, щелкните правой кнопкой мыши Пакеты, а затем щелкните Создать пакет.

  3. Назовите пакет, укажите свою организацию в качестве изготовителя и введите соответствующий номер версии (рис. 16).

    Рисунок 16

    Рисунок 16. Добавление сведений о новом пакете

  4. Щелкните Далее, а затем выберите в списке типов программы Стандартная программа.

  5. На странице Стандартная программа выберите имя и укажите в поле Командная строка значение XCopy \\Shares\CatalogShare C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y.

  6. На странице Стандартная программа выберите следующие параметры (рис. 17):

    • в поле Имя введите Contoso Catalog File Copy Program;

    • в области Командная строка перейдите к месту расположения программы;

    • в поле Папка автозагрузки введите C\Windows\System32;

    • из списка Запуск выберите пункт Скрытый;

    • из списка Требования для запуска выберите В любом случае;

    • из списка Режим диска выберите Работать с UNC-именем.

    Рисунок 17

    Рисунок 17. Добавление сведений о стандартной программе

  7. Примите значения по умолчанию, предложенные мастером, и закройте его.

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

  1. В рабочем пространстве библиотеки программного обеспечения перейдите к папке Обзор\Управление приложениями\Пакеты, щелкните правой кнопкой мыши пакет файла каталога и выберите Развертывать.

  2. На странице Общие выберите тестовую коллекцию, в которой будут развернуты файлы каталога, и нажмите кнопку Далее.

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

  4. На странице Параметры развертывания в окне Цель выберите Обязательно.

  5. На странице Планирование щелкните Новый.

  6. В диалоговом окне Расписание установки выберите Назначить сразу после этого события, установите значение Как можно скорее, а затем нажмите ОК.

  7. На странице Планирование нажмите кнопку Далее.

  8. На странице Взаимодействие с пользователем (рис. 18) задайте следующие параметры и нажмите кнопку Далее:

    • установите флажок Установка программного обеспечения;

    • установите флажок Применить изменения при наступлении крайнего срока или во время периода обслуживания (требуется перезагрузка).

    Рисунок 18

    Рисунок 18. Определение взаимодействия с пользователем

  9. На странице Точки распространения в окне Параметры развертывания выберите Запустить программу из точки распространения, а затем нажмите кнопку Далее.

  10. На странице Сводка просмотрите выбранные параметры и нажмите кнопку Далее.

  11. Закройте мастер.

Инвентаризация файлов каталога с помощью System Center Configuration Manager

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

Примечание  

Применение стандартного контекста именования файлов каталога значительно упрощает процесс инвентаризации файлов каталога. В этом примере ко всем именам файлов каталога добавлено -Contoso.

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

  2. Перейдите в раздел Обзор\Параметры клиенты, щелкните правой кнопкой мыши Параметры клиента, а затем щелкните Определить настраиваемые параметры для устройств.

  3. Назовите новую политику и установите флажок Инвентаризация программного обеспечения в списке Выберите, а затем настройте пользовательские параметры для устройств., как показано на рисунке 19.

    Рисунок 19

    Рисунок 19. Выбор собственных параметров

  4. В области навигации щелкните Инвентаризация программного обеспечения, а затем нажмите кнопку Задать типы, как показано на рисунке 20.

    Рисунок 20

    Рисунок 20. Настройка инвентаризации программного обеспечения

  5. В диалоговом окне Настройка параметра клиента нажмите кнопку Пуск для открытия диалогового окна Свойства файла инвентаризации.

  6. В поле Имя введите *Contoso.cat и нажмите Установить.

    Примечание  

    *Contoso.cat в данном примере представляет собой контекст именования. Он должен соответствовать контексту именования, который вы используете для своих файлов каталога.

     
  7. В диалоговом окне Свойства пути выберите Имя переменной или пути, а затем введите в поле C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}, как показано на рисунке 21.

    Рисунок 21

    Рисунок 21. Установка свойств пути

  8. Нажмите кнопку ОК.

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

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

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

  2. Перейдите в раздел Обзор\Устройства и выполните поиск устройства, на котором необходимо просмотреть инвентаризованные файлы.

  3. Щелкните правой кнопкой мыши нужный компьютер, наведите указатель на Пуск, а затем щелкните Обозреватель ресурсов.

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

Примечание  

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

 

Политики целостности кода

Политики целостности кода включают стандарты, в соответствии с которыми компьютер под управлением Windows 10 определяет, можно ли доверять приложению и запускать его. Обзор функции целостности кода см. в разделе Настраиваемая целостность кода.

Общепринятым методом работы с образом системы в современных ИТ-организациях является создание «золотого» образа в качестве эталона идеальной системы и использование этого образа для клонирования дополнительных ресурсов компании. Политики целостности кода создаются по тому же принципу, начиная с создания эталонного ПК. Как и при создании образа, у вас может быть несколько компьютеров-эталонов в зависимости от модели, отдела, набора приложений и т.д. Хотя процесс создания политик целостности кода аналогичен процессу создания образов, политики должны обрабатываться независимо. Проанализируйте необходимость дополнительных политик целостности кода на основании того, что должно быть разрешено к установке и запуску и на каких компьютерах.

Примечание  

Каждый компьютер может иметь только одну политику целостности кода за раз. Каким бы способом не развертывалась эта политика, ей присваивается имя SIPolicy.p7b и она копируется в папку C: \Windows\System32\CodeIntegrity. Помните об этом при создании политик целостности кода.

 

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

Примечание  

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

 

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

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

Для изменения правил существующей политики целостности кода используйте командлет Windows PowerShell Set-RuleOption . Обратите внимание на приведенные ниже примеры использования данного командлета для добавления или удаления какого-либо правила в существующей политике целостности кода.

  • Чтобы включить UMCI добавьте правило 0 для существующей политики с помощью следующей команды:

    Set-RuleOption -Option 0 -FilePath <Path to policy>

  • Чтобы отключить UMCI в существующей политике целостности кода, удалите правило 0 с помощью следующей команды:

    Set-RuleOption -Option 0 -FilePath <Path to policy> -Delete

В политике целостности кода можно задать несколько правил. В таблице 2 указано каждое правило и его значение.

Таблица 2. Политика целостности кода – правила политики

ПравилоОписание
0 Enabled:UMCI (0 включено:UMCI)Политики целостности кода предполагают ограниченное использование двоичных файлов в режиме ядра и пользовательском режиме. По умолчанию ограничено использование только двоичных файлов в режиме ядра. Если это правило активно, выполняется проверка исполняемых файлов и скриптов в пользовательском режиме.
1 Enabled:Boot Menu Protection (1 включено: защита меню загрузки)Этот параметр в данный момент не поддерживается.
2 Required:WHQL (2 Требуется:WHQL)По умолчанию устаревшие драйверы, не подписанные лабораториями WHQL, можно запускать. Если это правило активно, каждый выполняемый драйвер должен иметь подпись WHQL; поддержка устаревших драйверов прекращается. В перспективе каждый новый драйвер, совместимый с Windows 10, должен будет пройти сертификацию WHQL.
3 Enabled:Audit Mode (Default) (3 Включено: режим аудита (по умолчанию))Разрешается выполнение двоичных файлов вне политики целостности кода, но при этом каждое появление такого файла регистрируется в журнале событий CodeIntegrity, который можно использовать для обновления существующей политики перед применением. Чтобы применить политику целостности кода, удалите этот параметр.
4 Disabled:Flight Signing (4 отключено: подпись тестовых пакетов)Если правило активно, политики целостности кода не будут доверять двоичным файлам с подписью flightroot. Это можно использовать в сценарии, в котором организации необходимо только запускать выпущенные двоичные файлы, а не тестовые сборки.
5 Enabled:Inherent Default Policy (5 включено: политика по умолчанию)Этот параметр в данный момент не поддерживается.
6 Enabled:Unsigned System Integrity Policy (Default) (6 включено: неподписанная политика целостности системы (по умолчанию))Позволяет политике оставаться неподписанной. Если удалить это правило, политику нужно будет подписывать и добавлять к ней UpdatePolicySigners, чтобы можно было в будущем ее изменять.
7 Allowed:Debug Policy Augmented (7 разрешено: расширенная политика отладки)Этот параметр в данный момент не поддерживается.
8 Required:EV Signers (8 требуется: подписанты EV)Помимо подписи WHQL данное правило предусматривает, чтобы драйверы предоставлялись партнером, имеющим сертификат расширенной проверки (EV). Все будущие драйверы Windows 10 и последующих версий будут соответствовать этому требованию.
9 Enabled:Advanced Boot Options Menu (9 включено: меню расширенных параметров загрузки)Предзагрузочное меню F8 отключено по умолчанию для всех политик целостности кода. В случае активации этого правила меню F8 будет отображаться физически присутствующим пользователям.
10 Enabled:Boot Audit on Failure (10 включено: аудит при загрузке в случае сбоя)Используется в том случае, если политика целостности кода находится в режиме применения политик. В случае сбоя драйвера во время запуска политика целостности кода будет переведена в режим аудита, чтобы можно было загрузить Windows. Администраторы могут проверить причину сбоя в журнале событий CodeIntegrity.

 

Уровни правил файлов позволяют администраторам определять уровень доверия для своих приложений. Этот уровень доверия может варьироваться от хэш-значения каждого двоичного файла до сертификата PCA. Уровни правил файлов определяются как при создании новой политики целостности кода на основе сканирования, так и при создании политики на основе событий аудита. Кроме того, можно группировать уровни правил, обнаруженные в различных политиках, путем объединения этих политик. В случае объединения политик целостности кода их правила файлов также объединяются. Каждый уровень правил файлов имеет свои преимущества и недостатки. В таблице 3 можно выбрать соответствующий уровень защиты для своих доступных административных ресурсов и сценария развертывания Device Guard.

Таблица 3. Политика целостности кода – уровни правила файла

Уровень правилаОписание
ХэшУстанавливает отдельные хэш-значения для каждого обнаруженного двоичного файла. Хотя этот уровень является специальным, он может вызвать дополнительные административные затраты на поддержку хэш-значений текущих версий продукта. При каждом обновлении двоичного файла изменяется хэш-значение, в связи с чем требуется обновление политики.
FileName (Имя файла)Определяет имена отдельных двоичных файлов. При обновлении хэш-значения для приложения изменяются, а имена файлов, как правило, нет. В связи с этим защита будет менее направленная, чем в случае хэш-уровня, но она обычно не требует обновления политики при изменении любого двоичного файла.
SignedVersion (Подписанная версия)Правило издателя в сочетании с номером версии файла. Это правило позволяет выполнять запуск всех файлов заданной или более поздней версии от конкретного издателя.
Publisher (Издатель)Это сочетание сертификата PCA и общего имени (CN) на некорневом сертификате. В сценарии, предполагающем использование сертификата PCA для подписывания приложений от нескольких компаний (например, VeriSign), этот уровень правила обеспечивает доверие сертификату PCA, но только для компании, имя которой указано в некорневом сертификате (например, Intel для драйверов устройств). Этот уровень обеспечивает доверие сертификату с длинным сроком действия, но только в сочетании с доверенным некорневым сертификатом.
FilePublisher (Издатель файла)Это сочетание уровня правил файлов и издателя и уровня правил SignedVersion. Любой подписанный файл от доверенного издателя заданной версии или более новый является доверенным.
LeafCertificate (Некорневой сертификат)Добавляет доверенных подписантов на индивидуальном уровне сертификата подписи. Преимущество использования этого уровня в сравнении с уровнем отдельных хэш-значений заключается в том, что новые версии продукта будут иметь другие хэш-значения, но, как правило, тот же сертификат подписи. При использовании этого уровня для запуска новой версии приложения обновление политики не понадобится. Однако срок действия некорневых сертификатов гораздо короче, чем у сертификатов PCA, поэтому по истечении срока действия для обновления политики целостности кода потребуются дополнительные административные издержки.
PcaCertificate (Сертификат PCA)Добавляет наивысший сертификат в предоставленную цепочку сертификатов для подписантов. Обычно это единственный сертификат под корневым сертификатом, поскольку при сканировании не проверяются объекты выше представленной подписи путем подключения к Интернету или проверки локальных корневых хранилищ.
RootCertificate (Корневой сертификат)В настоящее время не поддерживается.
WHQLОбеспечивает доверие двоичным файлом, если они прошли проверку и подписаны WHQL. Это касается, в первую очередь, двоичных файлов ядра.
WHQLPublisher (Издатель WHQL)Это сочетание WHQL и CN в некорневом сертификате; касается, в первую очередь, двоичных файлов ядра.
WHQLFilePublisher (Издатель файла WHQL)Указывает, что двоичные файлы проверены и подписаны WHQL, имеют определенного издателя (издателя WHQL) и что данный двоичный файл имеет заданную или более новую версию. Это касается, в первую очередь, двоичных файлов ядра.

 

Примечание  

При создании политик целостности кода с помощью командлета Новый-CIPolicy можно указать уровень правила основного файла путем включения параметра –Level (уровень). Для обнаруженных двоичных файлов, которые не могут быть включены в список доверия на основании критерий правила основного файла используется параметр –Fallback (резервный). Например, если уровень правила основного файла – PCACertificate, а вам необходимо доверять также неподписанным приложениям, используйте уровень правила хэш-значения в качестве резервного для добавления хэш-значений двоичных файлов, не имевших сертификата подписи.

 

Создание политик целостности кода из «золотых» компьютеров.

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

Примечание  

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

 

Для создания политики целостности кода скопируйте каждую из следующих команд в сеанс Windows PowerShell с повышенными правами в таком порядке:

  1. Инициализация переменных, которые будут использоваться:

    $CIPolicyPath=$env:userprofile+"\Desktop\"

    $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

    $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

  2. Создание новой политики целостности кода путем сканирования установленных в системе приложений:

    New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt

    Примечание  

    В случае установки параметра –UserPEs параметр правила 0 Enabled:UMCI (0 включено:UMCI) автоматически добавляется к политике целостности кода. Если не задавать этот параметр, UMCI можно включить с помощью следующей команды:

    Set-RuleOption -Option 0 -FilePath $InitialCIPolicy

     
    Примечание  

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

     
    Примечание  

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

     
  3. Преобразование политики целостности кода в двоичный формат:

    ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

После выполнения этих действий двоичный файл Device Guard (DeviceGuardPolicy.bin) и первоначальный XML-файл (IntialScan.xml) будут доступны на рабочем столе. Версию двоичного файла можно использовать в качестве политики целостности кода или подписать файл для обеспечения дополнительной безопасности.

Примечание  

Майкрософт рекомендует оставить первоначальный XML-файл политики для использования в случае, если нужно объединить эту политику целостности кода с другой политикой или обновить параметры правил политики. Или же вам придется создавать новую политику на основании нового сканировании в целях обслуживания. Дополнительные сведения о том, как объединять политики целостности кода см. в разделе Объединение политик целостности кода.

 

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

Аудит политик целостности кода

Применение политик целостности кода в режиме аудита позволяет администраторам обнаруживать приложения, пропущенные ранее при первоначальном сканировании политики, и выявлять новые приложения, установленные и запущенные уже после создания исходной политики. В то время, пока политика целостности кода выполняется в режиме аудита, любой двоичный файл, который выполняется и который был бы запрещен в случае применения политики, записывается в журнал событий в разделе Журналы приложений и служб\Microsoft\CodeIntegrity\Операционные. После успешной проверки внесенных в журнал двоичных файлов их можно будет легко добавить в новую политику целостности кода. При создании новой политики исключений можно объединить ее с существующими политиками целостности кода.

Примечание  

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

 

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

  1. Скопируйте файл DeviceGuardPolicy.bin, созданный в разделе Создание политик целостности кода из «золотых», в папку C: \Windows\System32\CodeIntegrity.

  2. В системе, в которой необходимо включить режим аудита, откройте редактор локальной групповой политики, запустив файл GPEdit.msc.

  3. Перейдите к разделу Конфигурация компьютера\Административные шаблоны\Система\Device Guard, а затем выберите Развертывание политики проверки целостности кода. Включите эту настройку, указав путь к файлу C: \Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, как показано на рисунке 22.

    Примечание  

    DeviceGuardPolicy.bin не является обязательным именем политики. Это имя использовалось в разделе Создание политик целостности кода из «золотых» компьютеров, поэтому мы указали его и здесь. Кроме того, этот файл политики не нужно копировать в каждую систему. Вы можете скопировать политики целостности кода в общую папку, к которой имеют доступ все компьютеры.

     
    Примечание  

    Любая выбранная на данном этапе политика преобразовывается в SIPolicy.p7b при развертывании на отдельных компьютерах.

     
    Рисунок 22

    Рисунок 22. Развертывание вашей политики целостности кода

    Примечание  

    Возможно, вы заметили, что параметр GPO ссылается на файл .p7b, а данная политика использует файл .bin. Независимо от типа политики, которую вы развертываете (.bin, .p7b или .p7), они все преобразовываются в SIPolicy.p7b при передаче на компьютеры под управлением Windows 10. Майкрософт рекомендует делать политики целостности кода совместимыми и разрешать системе самостоятельно преобразовывать имена политик. Это позволит легко различать политики при просмотре в общей папке или любом другом централизованном хранилище.

     
  4. Перезагрузите исходную систему, чтобы политика целостности кода вступила в силу.

  5. Следите за журналом событий CodeIntegrity. В режиме аудита все исключения из развернутой политики целостности кода заносятся в журнал событий в разделе Журналы служб и приложений\Microsoft\CodeIntegrity\Операционные, как показано на рисунке 23.

    Рисунок 23

    Рисунок 23. Исключения из развернутой политики целостности кода

  6. Проверьте все исключения из политики целостности кода.

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

  7. Создайте политику целостности кода из событий аудита.

    Сведения о том, как создавать политики целостности кода из событий аудита см. в разделе Создание политик целостности кода из «золотых» компьютеров.

Примечание  

Альтернативным методом проверки политики является переименование тестового файла в SIPolicy.p7b и помещение его в папку C: \Windows\System32\CodeIntegrity вместо развертывания его с политикой локального компьютера.

 

Создание политики целостности кода аудита

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

  1. Инициализируйте переменные, которые будут использоваться:

    $CIPolicyPath=$env:userprofile+"\Desktop\"

    $CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

  2. Проанализируйте результаты аудита.

    Перед созданием политики целостности кода из событий аудита Майкрософт рекомендует проанализировать каждое исключение, как описано в пунктах 5 и 6 раздела Аудит политик целостности кода.

  3. Создайте новую политику целостности кода из записанных в журнал событий аудита:

    New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt

Примечание  

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

 

После выполнения этих действий XML-файл политики аудита Device Guard (DeviceGuardAuditPolicy.xml) будет доступен на рабочем столе. Вы можете использовать этот файл для обновления существующей политики целостности кода, запущенную в режиме аудита, путем объединения двух политик. Инструкции по объединению данной политики аудита с существующей политики целостности кода см. в разделе Объединение политик целостности кода.

Примечание  

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

 

Объединение политик целостности кода

В процессе разработки политик целостности кода вам может понадобиться объединить две политики. Чаще всего это требуется в случае первоначального создания и аудита политики целостности кода. Также это может потребоваться при создании одной основной политики с помощью нескольких политик целостности кода, ранее созданных с помощью «золотых» компьютеров. Учитывая, что на каждом компьютере под управлением Windows 10 может быть только одна политика целостности кода, очень важно правильно организовать эти политики. В этом примере события аудита были сохранены во вспомогательную политику целостности кода, которая впоследствии объединяется с исходной политикой целостности кода.

Примечание  

В следующем примере используются XML-файлы политики целостности кода, созданные в разделах Создание политик целостности кода из «золотых» компьютеров и Аудит политик целостности кода. При этом данную процедуру можно выполнять с любыми двумя политиками целостности кода, которые необходимо объединить.

 

Для объединения двух политик целостности кода выполните описанные ниже действия в сеансе Windows PowerShell с повышенными правами.

  1. Инициализируйте переменные, которые будут использоваться:

    $CIPolicyPath=$env:userprofile+"\Desktop\"

    $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

    $AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

    $MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"

    $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"

    Примечание  

    Переменные в этом разделе ожидают найти на вашем рабочем столе исходную политику под названием InitialScan.xml и политику целостности кода аудита под названием DeviceGuardAuditPolicy.xml. Если необходимо объединить другие политики целостности кода, обновите соответствующим образом переменные.

     
  2. Объедините две политики для создания новой политики целостности кода:

    Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy

  3. Преобразуйте объединенную политику целостности кода в двоичный формат:

    ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin

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

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

Каждая политика целостности кода создается при активном режиме аудита. После успешного развертывания и испытания политики целостности кода в режиме аудита, когда вы будете готовы к испытанию политики в принудительном режиме, выполните описанные ниже действия в сеансе Windows PowerShell с повышенными правами.

Примечание  

Каждую политику целостности кода вначале необходимо проверить в режиме аудита. Сведения о том, как проверять политики целостности кода в режиме аудита см. в разделе Аудит политик целостности кода.

 
  1. Инициализируйте переменные, которые будут использоваться:

    $CIPolicyPath=$env:userprofile+"\Desktop\"

    $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

    $EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"

    $CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"

    Примечание  

    Исходная политика целостности кода, рассматриваемая в этом разделе, была создана в разделе Создание политик целостности кода из «золотых» компьютеров. Если используется другая политика целостности кода, обновите переменные CIPolicyPath и InitialCIPolicy.

     
  2. Скопируйте исходный файл для сохранения оригинального экземпляра:

    cp $InitialCIPolicy $EnforcedCIPolicy

  3. Удалите параметр правила режима аудита:

    Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete

    Примечание  

    Вместо добавления параметра Принудительно политики целостности кода применяются неявно в случае отсутствия параметра Включен режим аудита.

     
  4. Преобразуйте новую политику целостности кода в двоичный формат:

    ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin

    Примечание  

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

     

После принудительного применения данной политики можно развертывать ее на тестовых компьютерах. Переименуйте политику в SIPolicy.p7b и скопируйте ее в папку C: \Windows\System32\CodeIntegrity для тестирования или разверните ее с помощью групповой политики, следуя инструкциям в разделе Развертывание и управление политиками целостности кода с помощью групповой политики, либо с помощью программы для управления клиентам, следуя инструкциям в разделе «Развертывание и управление политиками целостности кода с помощью решений для управления клиентами Майкрософт».

Подписывание политик целостности кода с помощью SignTool.exe

Подписанные политики целостности кода предоставляют организациям высший уровень защиты от вредоносных программ, доступный для Windows 10. Помимо ограничений, накладываемых правилами применяемой политики, также не предусмотрено изменение или удаление с компьютера подписанных политик пользователем или администратором. Эти политики предназначены для предотвращения мошенничества со стороны администратора и несанкционированного доступа к режиму ядра. За счет этого удалить подписанные политики целостности кода намного труднее, чем неподписанные. Перед подписыванием и развертыванием подписанной политики целостности кода Майкрософт рекомендует выполнить аудит политики для выявления заблокированных приложений, которые должны запускаться. Дополнительные сведения о том, как проверять политики целостности кода в режиме аудита см. в разделе Аудит политик целостности кода.

Подписывание политик целостности кода с помощью локального сертификата из центра сертификации или приобретенного сертификата подписи кода выполняется очень просто. Если у вас нет сертификата подписи кода, экспортированного в формат PFX (содержащего закрытые ключи, расширения и корневые сертификаты), создайте его с помощью вашего локального центра сертификации, следуя инструкциям в разделе Создание сертификата подписи кода Device Guard. Перед первым подписыванием политик целостности кода не забудьте включить параметры правил 9 и 10, чтобы администраторы, которые будут выполнять тестирование, смогли искать и устранять неполадки. Выполнив проверку и подготовив все для развертывания на предприятии, вы можете удалить эти параметры. Сведения о том, как добавлять параметры правил, см. в разделе Правила политики целостности кода.

Примечание  

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

Для подписания политики целостности кода с помощью SignTool.exe необходимы следующие компоненты:

  • файл SignTool.exe, который находится в Windows SDK (Windows 7 или более поздней версии);

  • политика целостности кода двоичного формата, созданная в разделе Создание политик целостности кода из «золотых» компьютеров или другая созданная вами политика целостности кода;

  • внутренний сертификат подписи кода из ЦС или приобретенный сертификат подписи кода.

 

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

  1. Инициализируйте переменные, которые будут использоваться:

    $CIPolicyPath=$env:userprofile+"\Desktop\" $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

    Примечание  

    В этом примере используется политика целостности кода, созданная в разделе Создание политик целостности кода из «золотых» компьютеров. Если вы подписываете другую политику, не забудьте подставить соответствующие значения для переменных CIPolicyPath и CIPolicyBin.

     
  2. Импортируйте сертификат подписи кода .pfx. Импортируйте сертификат подписи кода, который будет использоваться для подписывания политики целостности кода, в личное хранилище подписывающего пользователя на компьютере, с помощью которого будет осуществляться подписывание. В данном примере вы используете сертификат, созданный в разделе Создание сертификата подписи кода Device Guard.

  3. Экспортируйте сертификат подписи кода .cer. После импорта сертификата подписи кода экспортируйте версию .cer на свой рабочий стол. Эта версия будет добавлена к политике, чтобы ее можно было впоследствии обновить.

  4. Перейдите на рабочий стол, который послужит в качестве рабочей папки

    cd $env:USERPROFILE\Desktop

  5. Добавьте сертификат подписантов обновления в политику целостности кода:

    Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update

    Примечание  

    Значение <Path to exported .cer certificate> должно представлять собой полный путь к сертификату, экспортированному в шаге 3.

     
    Примечание  

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

     
  6. Удалите параметр правил неподписанной политики:

    Set-RuleOption -Option 6 -FilePath $InitialCIPolicy -Delete

  7. Преобразуйте политику в двоичный формат:

    ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

  8. Подпишите политику целостности кода с помощью SignTool.exe:

    <Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin

    Примечание  

    Переменная <Path to signtool.exe> должна представлять собой полный путь к служебной программе SignTool.exe. ContosoDGSigningCert – это имя субъекта сертификата, который будет использоваться для подписания политики целостности кода. Этот сертификат необходимо импортировать в ваше личное хранилище сертификатов на компьютере, который используется для подписывания политики.

     
  9. Проверьте подписанный файл. После завершения команды должны вывести файл подписанной политики с именем DeviceGuardPolicy.bin.p7 на ваш рабочий стол. Этот файл можно развернуть точно так же, как вы развертываете принудительную или не принудительную политику. Сведения о том, как развернуть политики целостности кода, см. в разделе Развертывание и управление политиками целостности кода с помощью групповой политики.

Отключение неподписанных политик целостности кода

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

  • <системный раздел EFI>\Microsoft\Boot\

  • <Том с операционной системой>\Windows\System32\CodeIntegrity\

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

Отключение подписанных политик целостности кода в Windows

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

Примечание  

Подписанные политики целостности кода должны быть заменены и удалены из следующих папок:

  • <системный раздел EFI>\Microsoft\Boot\

  • <Том с операционной системой>\Windows\System32\CodeIntegrity\

 
  1. Замените существующую политику другой подписанной политикой, для которой включено правило 6 Enabled:Unsigned System Integrity Policy (Default) (6 включено: неподписанная политика целостности системы (по умолчанию)).

    Примечание  

    Чтобы эта политика вступила в силу, она должна быть подписана сертификатом, ранее добавленным в раздел UpdatePolicySigners исходной подписанной политики, которую нужно заменить.

     
  2. Перезапустите клиентский компьютер.

  3. Убедитесь, что новая подписанная политика находится на компьютере клиента.

    Примечание  

    Если подписанная политика, содержащая правило 6 не была обработана на клиенте, при добавлении неподписанной политики могут возникнуть ошибки при загрузке.

     
  4. Удалите новую политику.

  5. Перезапустите клиентский компьютер.

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

  1. Замените существующую политику в объекте групповой политики другой подписанной политикой, для которой включено правило 6 Enabled:Unsigned System Integrity Policy (Default) (6 включено: неподписанная политика целостности системы (по умолчанию)).

    Примечание  

    Чтобы эта политика вступила в силу, она должна быть подписана сертификатом, ранее добавленным в раздел UpdatePolicySigners исходной подписанной политики, которую нужно заменить.

     
  2. Перезапустите клиентский компьютер.

  3. Убедитесь, что новая подписанная политика находится на компьютере клиента.

    Примечание  

    Если подписанная политика, содержащая правило 6 не была обработана на клиенте, при добавлении неподписанной политики могут возникнуть ошибки при загрузке.

     
  4. Отключите объект групповой политики.

  5. Удалите новую политику.

  6. Перезапустите клиентский компьютер.

Отключение подписанных политик целостности кода в BIOS

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

  • <системный раздел EFI>\Microsoft\Boot\

  • <Том с операционной системой>\Windows\System32\CodeIntegrity\

Развертывание и управление политиками целостности кода с помощью групповой политики

Групповая политика позволяет легко развертывать политики целостности кода и управлять ими. В Windows Server 2016 будет доступен административный шаблон, упрощающий развертывание аппаратных функций безопасности Device Guard и политик целостности кода. Ниже описана процедура развертывания политики целостности кода с именем DeviceGuardPolicy.bin в тестовом подразделении под названием DG Enabled PCs с помощью объекта групповой политики Contoso GPO Test.

Примечание  

Для выполнения этой процедуры вам необходимо предварительно создать политику целостности кода и иметь под рукой клиентский компьютер под управлением Windows 10, на котором вы будете тестировать развертывание групповой политики. Дополнительные сведения о создании политики целостности кода см. в разделе Создание политик целостности кода из «золотых» компьютеров.

 
Примечание  

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

 

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

  1. В контроллере домена на клиентском компьютере, на котором установлены средства удаленного администрирования сервера, откройте консоль управления групповыми политиками, запустив файл GPMC.MSC или выполнив поиск по запросу «управление групповой политикой» в Windows Search.

  2. Создайте новый объект групповой политики: щелкните правой кнопкой мыши подразделение «ПК с поддержкой DG» и выберите Создать объект групповой политики в этом домене и связать его, как показано на рисунке 24.

    Примечание  

    Подразделение «ПК с поддержкой DG» – это просто пример, показывающий, где необходимо привязывать тестовый объект групповой политики, созданный в этом разделе. Можно выбрать любое имя подразделения. Кроме того, при выборе параметров секционирования политики можно выполнить фильтрацию группы безопасности в соответствии с концепцией, описанной в разделе Подход к развертыванию целостности кода предприятия.

     
    Рисунок 24

    Рисунок 24. Создание объекта групповой политики

  3. Назовите новый объект групповой политики Contoso GPO Test. В этом примере имя объекта групповой политики – Contoso GPO Test. Можно выбрать любое другое имя для этого примера.

  4. Откройте редактор «Управление групповыми политиками»: щелкните правой кнопкой мыши новый объект групповой политики, а затем щелкните Изменить.

  5. В выбранном объекте групповой политики перейдите по следующему пути: Конфигурация компьютера\Административные шаблоны\Система\Device Guard. Затем щелкните правой кнопкой мыши Развертывание политики проверки целостности кода и выберите Изменить.

    Рисунок 25

    Рисунок 25. Изменение политики целостности кода

  6. В диалоговом окне Отображать политику целостности кода выберите параметр Включено и укажите путь развертывания политики целостности кода.

    При настройке данного параметра политики необходимо указать либо локальный путь к местоположению на клиентском компьютере, где будет размещаться политика, либо UNC-путь, по которому клиентские компьютеры будут запрашивать последнюю версию политики. В этом примере файл DeviceGuardPolicy.bin копируется на тестовый компьютер, данный параметр включается и используется путь к файлу C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, как показано на рисунке 26.

    Примечание  

    DeviceGuardPolicy.bin не является обязательным именем политики. Это имя использовалось в разделе Создание политик целостности кода из «золотых» компьютеров, поэтому мы указали его и здесь. Кроме того, этот файл политики не нужно копировать на каждый компьютер. Вы можете скопировать политики целостности кода в общую папку, к которой имеют доступ нужные компьютеры. Любая выбранная на данном этапе политика преобразовывается в SIPolicy.p7b при развертывании на отдельных клиентских компьютерах.

     
    Рисунок 26

    Рисунок 26. Включение политики целостности кода

    Примечание  

    Возможно, вы заметили, что параметр GPO ссылается на файл .p7b, а в данном примере используется файл политики .bin. Независимо от типа политики, которую вы развертываете (.bin, .p7b или .p7), они все преобразовываются в SIPolicy.p7b при передаче на клиентские компьютеры под управлением Windows 10. Сделайте свои политики целостности кода совместимыми и позвольте системе самостоятельно преобразовывать имена политик. В этом случае политики будет легко различать при просмотре в общей папке или любом другом централизованном хранилище.

     
  7. Закройте редактор «Управление групповыми политиками» и перезапустите тестовый компьютер под управлением Windows 10. При перезагрузке происходит обновление политики целостности кода. Сведения о том, как проверять политики целостности кода в режиме аудита см. в разделе Аудит политик целостности кода.

Создание сертификата подписи кода Device Guard

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

  1. Откройте оснастку консоли управления MMC ЦС и выберите ваш центр сертификации, выдающий сертификаты подписи.

  2. Выполнив подключение, щелкните правой кнопкой мыши Шаблоны сертификатов и выберите Управление, чтобы открыть консоль шаблонов сертификации.

    Рисунок 27

    Рисунок 27. Управление шаблонами сертификатов

  3. В области навигации щелкните правой кнопкой мыши «Сертификат подписи кода» и выберите Скопировать шаблон.

  4. На вкладке Совместимость снимите флажок Показать последующие изменения. Выберите Windows Server 2012 в списке Центр сертификации, а затем выберите Windows 8 / Windows Server 2012 в списке Получатель сертификата.

  5. На вкладке Общие укажите Отображаемое имя шаблона и Имя шаблона. В этом примере используется Сертификат подписи каталога DG.

  6. На вкладке Обработка запроса установите флажок Разрешить экспортировать закрытый ключ.

  7. На вкладке Расширения установите флажок Основные ограничения и щелкните Изменить.

  8. В диалоговом окне Расширение "Изменение основных ограничений" установите флажок Включить это расширение, как показано на рисунке 28.

    Рисунок 28

    Рисунок 28. Включение ограничений в новом шаблоне

  9. Если для утверждения выданных сертификатов требуется диспетчер сертификатов, установите флажок Одобрения диспетчера сертификатов ЦС на вкладке Требования выдачи.

  10. На вкладке Имя субъекта выберите Предоставляется в запросе.

  11. На вкладке Безопасность убедитесь, что все учетные записи, которые будут использоваться для запроса сертификата, имеют право на регистрацию сертификата.

  12. Щелкните в ОК, чтобы создать шаблон, и закройте консоль шаблонов сертификатов.

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

  1. В оснастке MMC центра сертификации щелкните правой кнопкой мыши Шаблоны сертификации, наведите указатель на пункт Создать, а затем нажмите Выдаваемый шаблон сертификата, как показано на рисунке 29.

    Появится список доступных выдаваемых шаблонов, включая только что созданный шаблон.

    Рисунок 29

    Рисунок 29. Выбор нового выдаваемого шаблона сертификата

  2. Выберите сертификат подписи каталога DG и нажмите кнопку ОК.

Как только шаблон станет доступным для выдачи, вам необходимо запросить его из компьютера под управлением Windows 10, с помощью которого создаются и подписываются файлы каталога. Откройте консоль MMC и выполните описанные ниже действия.

  1. На консоли управления (MMC) в меню Файл щелкните Добавить или удалить оснастку. Дважды щелкните Сертификаты и выберите Моя учетная запись пользователя.

  2. В оснастке сертификатов щелкните правой кнопкой мыши папку «Личное хранилище», наведите указатель на пункт Все задачи и выберите Запросить новый сертификат.

  3. Дважды щелкните Далее, чтобы открыть список выбора сертификата.

  4. В списке Запросить сертификат выберите только что созданный сертификат подписи, а затем щелкните голубую надпись, предлагающую ознакомиться с дополнительными сведениями (см. рис. 30).

    Рисунок 30

    Рисунок 30. Получение дополнительных сведений о сертификате подписи кода

  5. В диалоговом окне Свойства сертификата для параметра Тип выберите значение Общее имя. Для параметра Значение укажите ContosoDGSigningCert, а затем щелкните Добавить. Добавив элемент, нажмите кнопку ОК

  6. В завершение выполните регистрацию.

Примечание  

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

 

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

  1. Щелкните правой кнопкой мыши сертификат, наведите указатель на пункт Все задачи и выберите Экспорт.

  2. Щелкните Далее, а затем выберите Да, экспортировать закрытый ключ.

  3. Выберите параметры по умолчанию, а затем выберите Экспортировать все расширенные свойства.

  4. Задайте пароль, выберите путь для экспорта, а затем укажите в качестве имени файла DGCatSigningCert.pfx.

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

Связанные разделы

Обзор AppLocker
Целостность кода
Credential Guard
Device Guard: сертификация и обеспечение соответствия нормативным требованиям
Совместимость драйвера с Device Guard в Windows 10
Радикальные меры по защите от вредоносных программ с Device Guard для Windows 10

 

 

Показ: