Защита учетных данных в конфигурации требуемого состояния с помощью сертификатов

Я новичок в DSC и пытаюсь понять, как заставить его работать на нас.

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

Это три большие проблемы. Как использование открытого ключа в качестве источника расшифровки действительно защищает эти учетные данные? Каким компьютерам нужен сертификат в сценариях push и pull? Каковы лучшие методы для работы с полномочиями в свете этих проблем?

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

Если вам нужно отправить сертификат на каждый компьютер, который должен расшифровать файлы MOF, что может помешать обычным пользователям получить доступ к сертификату и иметь возможность расшифровывать MOF? Говоря о безопасности активного каталога, вы также можете оставить его открытым текстом и просто положиться на безопасность AD.

Может ли кто-нибудь помочь мне разобраться с этим?

Основная мысль

1. На хосте, который необходимо настроить, должен быть установлен сертификат (с закрытым ключом).
2. При настройке локального менеджера конфигурации целевого узла (LCM) необходимо указать отпечаток этого самого сертификата. Это сообщает LCM, какой локальный сертификат (или, точнее, закрытый ключ этого сертификата) будет использоваться для расшифровки учетных данных.
3. Ваша конфигурация DSC должна указывать на файл, который содержит только сертификат (открытый ключ) того же сертификата. Это делается в данных конфигурации, поэтому вы можете указать разные сертификаты для каждого узла, если вы собираетесь использовать одну и ту же конфигурацию для каждого узла.
4. Когда MOF генерируется, открытый ключ используется машиной, генерирующей MOF, для шифрования учетных данных.
5. Когда LCM на целевом узле получает конфигурацию с сервера извлечения (в форме MOF), он использует закрытый ключ сертификата, идентифицированного по отпечатку, для расшифровки объекта учетных данных.

В некоторых деталях

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

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

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

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

• Расположение файловой системы / общего сетевого ресурса, где хранится конфигурация
• Fs / share, где хранятся сгенерированные MOF
• Fs / share, где вы храните MOF на сервере извлечения
• Убедитесь, что пул-сервер работает по протоколу SSL (вы должны сделать это в любом случае)
• Убедитесь, что на сервере Pull есть проверка подлинности, в противном случае любой анонимный запрос может получить конфигурацию с предоставленными учетными данными.

Я думаю, что безопасные учетные данные в DSC сделаны довольно хорошо, но это немного тяжелое испытание, чтобы настроить их изначально.

AD PKI делает это проще

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

Как я это реализую

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

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

В сценарии создания LCM я фактически запрашиваю у ЦС домен, чтобы найти сертификат, соответствующий имени хоста настраиваемой машины. Я извлекаю сертификат (у CA нет личного ключа, только открытый) и сохраняю его в путь для дальнейшего использования. Мета MOF настраивается на использование отпечатка сертификата.

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

Ссылка

Я ссылался на свой собственный опыт в вышеприведенном, но эта статья мне очень помогла: https://devblogs.microsoft.com/powershell/want-to-secure-credentials-in-windows-powershell-desired-state- конфигурация

Я должен был заполнить некоторые отверстия самостоятельно. В примерах, которые они показывают, следует отметить, что они предоставляют Thumprintконфигурацию узла. Это не обязательно для конфигурации узла; они просто генерируют config и LCM meta config одновременно и используют данные конфигурации для хранения отпечатка для использования там.

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