パスワードを Windows サービスに送信する最良の方法は何ですか? アプリケーションを開始するには、パスワードが必要です。サービスが「通常」ユーザーの操作なしで実行されることになっていることは気にしません。オペレーターがアプリケーションを起動してからログオフできることは、私たちにとっては十分なことです。
UNIX システムでは、stdin を介してパスワードをエコーするだけですが、サービスには stdin がありません。
現在、DPAPI を使用して、CryptProtectData を使用してパスワードを保存するだけです。これは機能しますが、厄介になり始めている他の問題を提示します。
パスワードを送信しているサービスとアプリケーションの間で何らかの形式の IPC を使用する必要があると推測していますが、どの方法が適切かはわかりません。
ありがとう
Two main options:
You could listen on a socket on startup and wait for the required password to be supplied (maybe embed an SSH server in there, so that the password cannot be snooped over the wire)
My preferred option would be to read the password from a configuration file (that can be secured to the minimum readership) or registry setting (again, sufficiently secure such that only your service and administrators can read/change it)
Thanks for responding Rowland.
You could listen on a socket on startup and wait for the required password to be supplied (maybe embed an SSH server in there, so that the password cannot be snooped over the wire)
I considered that but without certificate verification, wouldn't that leave us open to a man in the middle attack?
My preferred option would be to read the password from a configuration file (that can be secured to the minimum readership) or registry setting (again, sufficiently secure such that only your service and administrators can read/change it)
We're trying to follow "defense in depth" as much as possible such that if an attacker compromised the machine, he would not able to access our application.
UserMode の DPAPI は実際には最適なオプションであり、暗号化されたデータを保護された場所 (制限付きの ACL を持つレジストリ キーなど) に保存します。
煩わしくなり始めた問題とは、具体的にはどのようなものだったのでしょうか。多分私たちはそれらを解決することができます...
Kerberos 相互認証を使用できます。そこにはいくつかのオプションと例があります。
しかし、不思議に思うだけです。侵害されたマシンには、キーロガーが存在する可能性があります。したがって、この環境でセキュリティを維持したい場合、パスワードの入力は決して安全ではありません。UNIX端末にも同じ問題が存在します。
システム アカウントで実行されているサービスからリモート ドライブにアクセスできます。ただし、リモート マシンに接続するには、資格情報と共有情報が必要です。API wnetaddconnection を使用してアクセスできます。おそらく、暗号化されたファイルにもこの資格情報を保存できます。
面倒になり始めた問題とは、具体的にはどのようなものだったのでしょうか。多分私たちはそれらを解決することができます...
現在、アプリケーションはローカル システム アカウントとして実行されます。
私たちのアプリケーションは、暗号化されたファイルに多数の資格情報を保存し、暗号化に DPAPI (UserMode) を使用します。
したがって、アプリケーションがインストールされると、インストーラーはローカル システム アカウントとして実行されます。また、アプリケーションに同梱されている一連のツールもあります。一部のツールは、この暗号化されたファイルにアクセスする必要があるため、ローカル システム アカウントとして実行する必要があります。
アプリケーションをインストールして起動するまでには、そのアカウントに大きく依存しています。
ユーザーの 1 人がアプリケーションを使用して共有ネットワーク ドライブにアクセスしようとしているため、問題が発生しています。ローカル システム アカウントにはそのような権限はなく、暗号化された情報はローカル システム アカウントで保護されているため、単に別のユーザーとしてサービスを実行することはできません。
私たちのアプリケーション専用のユーザー アカウントを設定するプロセスは避けようとしました。これは、アプリケーションがさまざまな顧客や環境にインストールされており、そのすべてが非常に異なるセキュリティ ポリシーを持っているためです。