証明書を使用して必要な状態の構成で資格情報を保護する


8

私はDSCを使い始めたばかりで、それがどのように機能するかを理解しようとしています。

私が行き詰まっているのは、資格情報が実際に保護される方法です。私の現在の理解は、それはそれほど素晴らしいものではないということです。

大きな3つの問題はこれらです。公開鍵を復号化ソースとして使用すると、これらの資格情報を実際にどのように保護できますか?プッシュシナリオとプルシナリオで証明書が必要なのはどのコンピューターですか?これらの問題に照らして資格情報を処理するためのベストプラクティスは何ですか?

証明書の公開鍵を使用すると、送信元の認証に役立ちます。ただし、これを復号化キーとして使用すると、証明書の公開キーへのアクセスによってパスワードへのアクセスが決定されます。

MOFファイルを復号化する必要があるすべてのコンピューターに証明書をプッシュする必要がある場合、平均的なユーザーが証明書にアクセスしてMOFを復号化できないようにする方法はありますか?Active Directoryのセキュリティとは、プレーンテキストのままにして、ADのセキュリティに依存することもできることを意味します。

誰かがこれを回避するのを手伝ってくれる?

回答:


11

基本的な考え方

  1. 構成するホストには、証明書(秘密鍵付き)がインストールされている必要があります。
  2. ターゲットノードのローカル構成マネージャー(LCM)を設定するときは、証明書そのものの拇印を指定する必要があります。これにより、資格情報の暗号化解除に使用されるローカル証明書(より正確には、どの証明書の秘密鍵)がLCMに通知されます。
  3. DSC構成は、同じ証明書の証明書(公開鍵)のみを含むファイルを指す必要があります。これは構成データで行われるため、それぞれに同じ構成を使用する場合は、ノードごとに異なる証明書を指定できます。
  4. MOFが生成されると、MOFを生成するマシンが公開鍵を使用して、資格情報を暗号化します。
  5. ターゲットノードのLCMがプルサーバーから(MOF形式で)構成を取得すると、拇印で識別された証明書の秘密キーを使用して、資格情報オブジェクトを復号化します。

少し詳しく

公開鍵を使用して復号化することはできず、秘密鍵を構成生成マシンや配布マシンと共有していません。

すべての資格情報に単一の証明書が使用されているかのようにワークフローを検討しているようです。あなたはそれを行うことができますが、考えは各ノードが独自のキーペアを持っているということだと思います。

「平均的なユーザー」とは、管理者以外のユーザーを意味し、証明書の秘密キーをエクスポートできません(アクセス許可が付与されていない場合)。このキーを移動しないため、ほとんどの可能性はありません。それが公開されています。ユーザーが管理者である場合は、もちろんアクセスできます。

プレーンテキストの認証情報を設定に保存すると、未処理のpowershell設定または生成されたMOFのどちらを経由しても公開される可能性がはるかに高くなります。暗号化されていない場合は、セキュリティで保護する必要があります。

  • 設定が保存されているファイルシステム/ネットワーク共有の場所
  • 生成されたMOFが保存されるfs / share
  • プルサーバーにMOFを保存するfs / share
  • プルサーバーがSSLで実行されていることを確認します(とにかくこれを行う必要があります)
  • プルサーバーで認証が行われていることを確認してください。そうでない場合、匿名のクエリが公開された資格情報で構成を取得する可能性があります。

DSCのセキュリティで保護された資格情報はかなり上手く処理されていると思いますが、最初にそれを設定するのは少し大変なことです。

AD PKIはこれを簡単にします

AD環境でエンタープライズPKIを使用している場合は、各マシンがCAへの自動登録用に設定されている可能性が高いため、マシン自体に更新するマシン固有の証明書すでにあります。この目的で使用する必要のある設定があります。

これを実装する方法

現在のところ、DSCのツールはそれほど必要ではないので、構成を生成してスクリプトを作成するための独自のワークフローを作成していると思われます。

私の場合、LCMメタMOFを生成するためと、ノードの実際の構成を生成するための別々のスクリプトを用意しているため、資格情報を保護するための手順は両方に分かれています。

LCM生成スクリプトでは、実際にCAにドメインを照会して、構成中のマシンのホスト名に対応する証明書を見つけています。証明書を取得し(CAには秘密鍵がなく、公開鍵しかありません)、後で使用するためにパスに保存します。メタMOFは、証明書の拇印を使用するように構成されます。

ノード構成スクリプトで、証明書ファイルを使用するように構成データを設定します(ここでも公開鍵のみ)。MOFが生成されると、資格情報はその証明書で暗号化され、特定のノードの秘密鍵でのみ復号化できます。

参照

私は上記で自分の経験を参照しましたが、この記事は途中で大きな助けとなりました:https : //devblogs.microsoft.com/powershell/want-to-secure-credentials-in-windows-powershell-desired-state-構成

自分でいくつかの穴を埋める必要がありました。それらが示す例で注意すべきことの1つThumprintは、ノード構成でを提供することです。これはノード構成には必要ありません。構成とLCMメタ構成を同時に生成し、構成データを使用してそこに使用するサムプリントを格納しているだけです。

最後の段落はわかりにくいかもしれませんが、記事の文脈ではより理にかなっています。両方の設定を同時に生成しない場合、それらの例は奇妙に見えます。私はそれをテストしました。Thumbprint資格情報を暗号化するための構成データには必要ありません。CertificateFileただし、これは必須であり、構成データに含まれている必要があるため、以前に構成データを使用していなかった場合は、今です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.