%20%E3%82%88%E3%82%8A%E3%82%82%E5%AE%89%E5%85%A8%E6%80%A7%E3%81%8C%E4%BD%8E%E3%81%8F%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%99%E3%81%8B%3F.png)
私はずっと、ファイル共有 (\\serverName\share) などを使用してリモート マシンにアクセスし、-ComputerName パラメーターを使用する Powershell コマンドを使用してきました。リモート ドメインのマシンでこれを行う場合は、-Credential 引数を指定する必要があります。そして、それはすべて正常に機能します。これは DCOM と呼ばれるものだと思います。WMI にも同じようにアクセスできます。ただし、リモート マシンに enter-pssession を使用しようとすると、何らかの Kerberos の問題で機能しません。おそらく、違いは Kerberos がマシンの相互認証を提供することです。ただし、リモート ドメインのマシンにアクセスしている場合、DCOM スタイルのトランザクションにはいずれにしても Kerberos は使用されません。したがって、証明書インフラストラクチャを設定する代わりに (したがってマシン認証がないため)、リモート マシンを Winrm TrustedHosts に配置して (IP アドレスで名前を付けて) pssession を機能させると、ずっと実行してきた DCOM コマンドよりも本当に悪いのでしょうか。 --接続が暗号化されていないため、「実稼働環境ではなくテスト マシンでのみ使用してください」などと書いている人を見かけます。しかし、資格情報のトランザクションは暗号化されているはずです。-ComputerName と -Credential を他のコマンドで使用しても問題ない場合、違いは何ですか?
答え1
はい、安全性は低くなります。
NTLM (使用される認証プロトコル) は技術的に安全性が低くなります。ホストに資格情報を提示します。また、NTLM はクライアントにホストの認証を提供しません。攻撃者がその IP アドレスでそのホストになりすますのは簡単です。
Kerberos 環境では、ホストに資格情報を提示するのではなく、別の認証サーバーに資格情報を提示します。サーバーはトークンを提供し、そのトークンが認証のために提示されます。資格情報は、一般的なサーバーよりも安全な少数のホストに提示されます。
ネゴシエート/NTLM の代わりに基本認証が有効になっている場合、それらの資格情報は暗号化されずにネットワーク経由で送信されますが、これは明らかに問題です。ただし、認証後は、HTTP/HTTPS トランスポート スキームに関係なく、セッションはメッセージ レベルで暗号化されます。基本 + HTTP およびダイジェスト認証方法は、決して有効にしたり使用したりしないでください。
ほとんどの組織では、監査に合格しないため、これを行いません。ワークグループのシナリオでは、証明書がほぼ常に使用されます。
https://devblogs.microsoft.com/powershell/compromising-yourself-with-winrms-allowunencrypted-true/