Я новичок в DSC и пытаюсь понять, как заставить его работать для нас.
Я застрял на том, как на самом деле защищены учетные данные. На данный момент я понимаю, что это не так уж и хорошо.
Вот основные три проблемы. Как использование открытого ключа в качестве источника дешифрования действительно защищает эти учетные данные? Какие компьютеры нуждаются в сертификате в сценариях push и pull? Каковы наилучшие методы работы с учетными данными в свете этих проблем?
Использование открытого ключа сертификата хорошо для аутентификации источника передачи. Но использование его в качестве ключа дешифрования означает, что доступ к открытому ключу сертификата определяет доступ к паролю.
Если вам нужно отправить сертификат на каждый компьютер, который должен расшифровать файлы MOF, что может помешать обычным пользователям получить доступ к сертификату и расшифровать MOF? Сказать, что безопасность активного каталога означает, что вы можете оставить его в виде обычного текста и просто положиться на безопасность AD.
Может ли кто-нибудь помочь мне разобраться в этом?
Открытый ключ не может использоваться для расшифровки, и вы не передаете закрытый ключ машинам для генерации конфигурации или распространению.
Похоже, вы рассматриваете рабочий процесс так, как будто для всех учетных данных используется один сертификат. Вы могли бы это сделать, но я думаю, что идея в том, что каждый узел имеет свою пару ключей.
«Обычные пользователи», которые я понимаю как пользователей без прав администратора, не могут экспортировать закрытый ключ сертификата (если не предоставлены разрешения), и, поскольку вы не будете перемещать этот ключ, вероятность это подвергается разоблачению. Если пользователь является администратором, то, конечно, у него есть доступ.
Гораздо более вероятно, что хранение учетных данных в виде простого текста в конфигурации будет отображаться, будь то через необработанную конфигурацию powershell или сгенерированный MOF. Если он не зашифрован, вам нужно будет защитить:
Я думаю, что безопасные учетные данные в DSC выполнены довольно хорошо, но сначала настроить их - это немного тяжелое испытание.
Если вы используете Enterprise PKI в среде AD, велика вероятность, что каждая машина настроена для автоматической регистрации в ЦС, поэтому уже есть машинно-зависимый сертификат который обновляется. В нем есть необходимые настройки, которые можно использовать для этой цели.
Поскольку инструменты для DSC сейчас настолько просты, вполне вероятно, что вы в любом случае создадите свой собственный рабочий процесс для создания конфигураций и написания сценариев для помощи.
В моем случае у меня есть отдельные сценарии для генерации мета-MOF LCM и для генерации фактической конфигурации узла, поэтому мои шаги по защите учетных данных разделены между обоими.
В сценарии генерации LCM я фактически запрашиваю CA для домена, чтобы найти сертификат, который соответствует имени хоста настраиваемой машины. Я получаю сертификат (у ЦС нет закрытого ключа, только общедоступный) и сохраняю его в пути для дальнейшего использования. Мета-MOF настраивается на использование отпечатка сертификата.
В сценарии конфигурации узла я установил данные конфигурации для использования файла сертификата (опять же, только с открытым ключом). Когда создается MOF, учетные данные зашифровываются с помощью этого сертификата и могут быть расшифрованы только с помощью закрытого ключа на определенном узле.
Я ссылался на свой собственный опыт выше, но эта статья мне очень помогла: https://devblogs.microsoft.com/powershell/want-to-secure-credentials-in-windows-powershell-desired-state-configuration
Пришлось самому заполнить некоторые дыры. В показанных ими примерах следует отметить, что они обеспечивают Thumprint в конфигурации узла. Это не обязательно для конфигурации узла; они просто генерируют конфигурацию и мета-конфигурацию LCM одновременно и используют данные конфигурации для хранения отпечатка для использования там.
Этот последний абзац может сбивать с толку, но он имеет больше смысла в контексте статьи. Если вы не создаете обе конфигурации одновременно, их пример покажется странным. Я это тестировал; Thumbprint не требуется в данных конфигурации для шифрования учетных данных. CertificateFile Однако требуется, и он должен быть в данных конфигурации, поэтому, если вы не использовали данные конфигурации раньше, вы будете использовать их сейчас.