Windows / IISは証明書をどのように保護しますか、またはWindowsサーバーでApache Webserverを実行しないでください。
私が同僚の推論に従っている場合、https証明書を安全に保ちたいのであれば、Apache WebserverまたはTomcatをWindowsサーバーで実行してはいけないようです。
この質問がWindows対Linuxのトロールバトルに発展する前に説明しましょう。
たとえば、Apache Tomcatをhttps Webサイトに使用する場合、秘密鍵はキーストアに格納されます。 Tomcatがこのキーを使用できるようにするには、3つのオプションがあります。
- キーストアでパスワードを使用しないでください。
- Tomcatサービスを開始するときに、キーストアのパスワードを入力する必要があります。
- キーストアのパスワードは、設定ファイルにプレーンテキストで設定されます。
オプション3の使用が最も実践されているようです。ただし、このファイルとキーストアにアクセスできる人は誰でも秘密鍵を抽出できます。もちろん、ファイルシステムでキーストアと構成ファイルを保護できます。しかし、Linuxは異なるプロセスのためにこれらのファイルへのアクセスを分離するためのより多くのオプションを提供しているようです。この推論が私が始めた結論につながりました。
私はWindowsまたはIISがこれを処理する方法に精通していませんが、これが内部で何とか同じように機能することを期待します。私の問題は確実にわかりません。IIS誰もパスワードを入力しなくてもWindowsで証明書を使用できますか？または、構成ファイルの代わりにレジストリに保存されていますか？オプション2と同等の高い証明書セキュリティを設定していますか？
誰もがこれがどのように機能するかを私に説明できますか？
ところでHSMには興味がありません。今のところ、オプション3を使用しないでWindows/IISが証明書または秘密キーを保護するかどうか、またどのように保護するかを知りたいと思っています。
検索しましたが、決定的な答えは見つかりませんでした。 「certificates」のタグが付けられた30ページを閲覧し、googleを使用しました。彼らから決定的な答えを抽出するのは難しいと思います。以下で、私が見つけたいくつかのヘルプのソースについて述べます。私があなたを助けてくれるか、適切な情報源を教えてくれることを本当に願っています。
StackExchangeのセキュリティ：
- Windowsデジタル証明書ストアの秘密キーはどの程度安全ですか？
- SSLキーをサーバーに保存するにはどうすればよいですか？
- アプリケーションのRSA秘密鍵を保存する方法は？
- クロスプラットフォームの証明書を保存するための優れた設計プラクティスは何ですか？
マイクロソフト：
- [TechNetブログ] Windowsの強力なキー保護とは何ですか？
- [TechNet、EFS]秘密キーの格納方法
さまざまなサイト：
- [ServerFault] WebサーバーのSSL秘密鍵保護を管理する方法（パスワードとパスワードなし）
- [CodingHorror]秘密鍵を秘密に保つ
- [SecurityInnovation]安全でないキーストアの脆弱性をテストする方法
- [RootSecurity] Microsoft証明書ストアから「エクスポートできない」証明書をエクスポートする方法
- [Symantec]攻撃者がデジタル証明書から秘密キーを盗む方法
一般的な注釈は次のとおりです。ifマシンを再起動でき、サーバーは自動的に再び操作可能になり、それ以上の人間の介入は必要ありません。マシンが秘密鍵にアクセスするために必要なすべてのもの。これに対応して、マシンへのフルアクセス（Linuxの場合は「root」、Windowsの場合は「Administrator」）を取得したユーザーも、秘密鍵を回復できます。
Windowsでは、ソフトウェアベースの秘密鍵は [〜＃〜] dpapi [〜＃〜] に格納されます。話を簡潔にするために、秘密鍵はアカウント（「ローカルマシン」ストア用のマシン自身のアカウント）にリンクされ、保護は最終的にアカウントのパスワードをキーとして使用した暗号化に依存します。自動的に開始するIISの場合、対応するパスワードはシステムの内臓のどこかに書き込む必要があります。暗号化と間接化の層が存在する可能性がありますが、十分な権限を持つ人なら解読できます。実際にそれを行う方法については、 この答え を参照してください。
また、誰かがライブマシンで管理者権限を取得した場合、実行中のWebサーバープロセスに接続して、そのRAMコンテンツを直接 ReadProcessMemory（） で略奪することができます。 。
したがって、保護は、最終的には、オペレーティングシステムが権限のないユーザーが管理者特権を取得するのをどの程度防止するかに対して相対的になります。その観点から見ると、Apache/TomcatとIISの間に大きな違いはありません。Apacheの秘密鍵をファイルに格納し、いくつかのACLを設定して、Apacheを実行する特定のユーザーからのみこのファイルを読み取り可能にすることができます。管理者権限を持つユーザーはそれをバイパスできますが、上記で説明したように、マシン上で何でも実行できます。
現在、量的な微妙な問題があります。マシンのコアまで、カーネルがあります。カーネルコードは、本質的には神です。すべてのRAMの読み取りと書き込み、すべてのハードウェアへのアクセスが可能です。カーネルは、誰が何を実行できるかを決定するゲートキーパーでもあります。カーネルの観点では、各アプリケーションコードは、コードが実行できることを正確に説明する一連の特権で実行されます。いくつかの特権は神と同等です。つまり、その特権を持つプロセスは、カーネルと同じ力を得るために、多かれ少なかれ直接調整できます。従来のLinuxシステムでは、rootはカーネルモジュール、つまりカスタムコードをカーネル自体に直接作成してロードできるため、どのrootプロセスも神と同等です。推移性により、神と同等の特権を持つプロセスを制御できるすべてのプロセスも、神と同等です。
神と同等のプロセスは、攻撃者にとってジューシーなターゲットです。このようなプロセスが多いほど、攻撃者が神格を獲得できる悪用可能な脆弱性がそれらの1つにある可能性が高くなります。したがって、神と同等のプロセスのサイズと範囲を縮小することは、実際的なセキュリティの向上に役立ちます。マシンの奥深くには、いくつかの神と同等のコード（カーネル自体だけの場合）がまだありますが、微調整によってそのコードを小さく保つことができます。
LinuxとWindowsは、デフォルトでは、その点ではほぼ同じですが（root /システムアカウントとして実行される多くのプロセス）、それを削減するためのさまざまなツールを提供しています。 Linuxでは、 chroot 、より一般的には SELinux を使用します。 Windowsでは、グループポリシーを使用して多くの調整と制限を行うことができます。どちらの場合も、自分をロックアウトするのは非常に簡単なので、注意してください。
概要：Windows上のApache/Tomcatには何の問題もありません。 IISによって使用される秘密鍵に適用される保護は、ファイルへのアクセス権と定性的に異なるか、または強力です。優れたシステム管理者は、同じマシン上で、どちらの場合も同様のセキュリティレベル。
いかなる場合でも、権限のないユーザーが機密データを含むサーバー上で任意のコードを実行できないようにすることをお勧めします。経験によれば、攻撃者が非特権コードをローカルで実行することを許可されると、悪用可能なホールの数が急激に増加します。