プレーンテキストの資格情報を公開せずにNginxを使用してUbuntuでWebサーバーの秘密キーを保護する方法
私は、官僚制のレベルが高く、多くのことについて厳密な正式なルールを持っている顧客向けの一連の内部Webサイトとサービスを開発しています。そのうちの1つは「プレーンテキストでパスワードを保存しない」ことです。
そのため、私のシステム構成マニュアルを調べたところ、Nginxが起動時に読み込むテキストファイルへの秘密鍵のパスワードの保存を受け入れることができないことをすぐに指摘しました。 rootだけがファイルを読み取れることは問題ではありません。
「誰かがサーバーへのrootアクセス権を持っていると、漏洩した秘密鍵よりも大きな問題が発生する」などの私の主張は、「攻撃者はサーバープロセスからキーを抽出する可能性があるRAMとにかく、暗号化が使用されています」、「パスワードファイルを暗号化すると、Nginxはパスワードを解読してパスワードを解読するためにパスワードが必要になるため、再帰的な問題です」は機能しませんでした。
お客様は、IISの仕組みに慣れているようです。秘密キーはCNGメカニズムによって保護されており、プレーンテキストのパスワードやキー、APIトークンをどこにでも保存する必要はありません。
面倒になりすぎずに、UbuntuとNginxでそれを実現するにはどうすればよいですか？
すべてをWindowsに移行したくないので、最初のアイデアが無料のUbuntuサーバーを使用することだったのに、なぜもう1つのWindowsサーバーライセンスが必要なのかを説明します。
両方の当事者にとって受け入れ可能な解決策であるように、要件とは何か、どのように満たすことができるかを正確に理解することが重要です。誰もがいつも言うように、セキュリティは妥協についてです。
Pvtキーを暗号化すると、nginxは起動するたびにパスワードを要求します。これはセキュリティ上は問題ありませんが、まったく実用的ではありません。
Pvtキーを暗号化して、nginxにファイルからパスワードを読み取らせることができます。個人的にパスワードファイルをファイルシステムに保存する場合、セキュリティ上の利点がないと思います特にrootユーザーに対して、pvtキーを解読して公開するための十分な情報があるためです。これは単なる追加のステップです。
ブートごとにカーネルのキーリングにパスフレーズを入力し、それを使用してnginxパスワードファイルの暗号化を制御するシステムを使用できます。繰り返しになりますパスフレーズはルートによってキーリングから抽出できますなので、これはファイルを読み取るだけではなく、妥協するのが難しい追加の手順です。さらに、パスワードファイルの一時的な復号化を処理する必要があります：考えられる解決策は、パスワードファイルをRAMに復号化し、nginxを起動して、デーモンの起動直後にRAMからスクラブします。
- キーを含むか、コンテンツの復号化に必要な素材を含むカーネルキーリングの代わりにハードウェアデバイスを使用して、パスワードファイルを一時的に公開することもできます。これにより、キーを危険にさらすことがより困難になります。利用可能なハードウェアデバイスには依存しません。
Linuxの男なので、Microsoft IISについてはあまり知りません。しかし、 https://docs.Microsoft.com/en-us/mem/configmgr/core/plan-design/network/cng-certificates-overview を読むと、「CNG」のように見えますあなたの質問と次のコメントで言及するのは、ハードウェアセキュリティモジュール（HSM）を使用したSSL/TLSキー管理ソリューションです。 NGINXでSSL/TLSのハードウェアセキュリティモジュールを使用することもできます-参照 https://www.nginx.com/blog/protecting-ssl-private-keys-nginx-hashicorp-vault/#hsm 。