ホストFSにプレーンテキストでシークレットを保存するのに安全でないことはありますか？

Question

このウェブサイトとインターネットには、ファイルシステムにプレーンテキストで認証情報（特定のウェブアプリケーションが使用しているデータベースへのログイン/パスワード、または非AWSインスタンスのS3アクセスキーなど）を保存しないことを推奨する推奨事項があります。どうやらディスクからパスワードを回復する可能性が原因です。

代替案は、ネットワーク経由でリモートシークレットマネージャーのようなものからシークレットを送信することをお勧めします。このモデルでは、対応するシークレットを使用してメモリに格納するアプリケーションを想定しています。このスキームのバリエーションでは、ターゲットホストのファイルシステム上の暗号化されたファイルにシークレットを保存し、ネットワーク経由で安全な方法でアプリケーションに暗号化キーを送信することもできます。

資格情報を暗号化せずにローカルファイルシステムに保存したい場合（たとえば、一部のローカルファイルに暗号化されていないパスワードを期待するフレームワークの制限により）、シークレットを特定のファイルにプレーンテキストで保存し、次の方法でリスクを軽減できます。：

暗号化されたファイルシステムの使用-ディスクを盗む悪意のある俳優は、暗号化されたパーティションのシークレットを読み取ることができません。
Ramを使用するFS（最初はシークレットを送信する必要があることを忘れましょう）。
1または2に加えて、アプリケーションの実行に使用される特定のユーザーにファイルへのアクセスを制限します。

追伸この問題について同様の質問があります。データベースパスワードをプレーンテキストで保存しますか？（これは多分曖昧すぎるため、明確な回答が得られませんでした）および APIシークレットをプレーンテキストで保存または復号化しても問題ありませんか？ -able？（より広い範囲ですが、答えは私が求めている特定の側面を扱っていませんでした）。

さらに、（1）パスワードISアプリケーション構成に保存されていません。アプリケーションの展開中に、何らかの安全なメカニズムを介してホストに配布されるとしましょう;（2）終了私が言及しているWebアプリケーションを使用するユーザーは、ホストにアクセスできません。

私の主な質問は、ファイルシステムに本質的に安全でない何かがあり、ファイルシステムに暗号化されていない（アプリケーションから他のサービスにアクセスするための）資格情報を保存しないことを期待するオプションを本質的に残しているかどうかです。範囲を絞り込むために、この質問を最新のLinux OSに限定しましょう。

LTPCGO · Accepted Answer

このような質問については、リスクの軽減と使いやすさがすべてです。

最初に受け入れることは、サードパーティがハードウェアに無制限にアクセスできる場合、それらを停止することができないということです。同じことは、ルートアクセスを持っている場合にも当てはまります。ある時点で、シークレットは暗号化されていない状態でメモリに存在する必要があり、その時点でそれを取得することができます。それでは、サーバーにアクセスでき、コマンドを実行できるが、管理者ではないユーザーがいる場合を考えてみましょう。どのようにして秘密を保存しますか？

理想的には、サーバーに保存しないでください。シークレット管理システムを利用して、定期的にその方法でローテーションされるシークレットを引き出すことができ、それを保管することをまったく心配する必要はありません。これは、AWS Secrets ManagerやAzure Key Vaultなどのクラウドで広く使用およびデプロイされています。このシナリオでは、セキュリティはホスト外で処理されるため、Webホストのセキュリティについてはある程度問題ではありません。

なんらかの理由で同じサーバー上に存在している必要があるとしましょう。コードにハードコードされていないことを確認しました。次に、Webアプリケーションはそれを読み取る必要があります。ただし、他のユーザーができることを意味しているわけではありません。機密ファイルには、理想的にはWebルート外の別のフォルダーに400のアクセス許可が必要です。 Webルートの下に配置する必要がある場合は、.htaccessなどを使用して、表示されないようにします。

誰かがサーバーを盗んだ場合はどうなりますか？ええ、そうです、すべてが暗号化されているのは良いことですが、破壊される可能性がある十分な計算能力と時間が与えられています。それまでにオフサイトのバックアップを復元していて、私たちの担当者がすべてのキーを持っている場合はどうなりますか？これが最後で最も重要なビットです。一意のシークレットを定期的にローテーションするため、たとえそれらが侵害されたとしても、その侵害が有効である時間は少なくなります。

最後に行うべきことは、シークレットを完全に排除することかもしれません-パスワードではなく証明書の提示を介してデータベースに接続し、内部サービスへのアクセスをローカルマシンのみからのアクセスに制限するなど。

ファイルシステムは、ハードディスク上のバイナリの束をカタログ化し、エンドユーザーにとって有用なものに編成する方法です。探しているもの（速度、冗長性、またはセキュリティ）に応じて、良いファイルシステムと悪いファイルシステムがあります。原則はすべて同じであり、ユーザーがホストではなくWebアプリケーションにのみアクセスできるシナリオでは、そのアプリケーションが安全に設計されている限り、ファイルシステムのセキュリティは考慮されません。

Brad Schoening · Answer

OWASPは、TomcatのWebサーバーデータベースの資格情報を管理するコンテキストで CATALINA_HOMEのクリアテキストパスワードでこれについてコメントしています。彼らの見解は

ベストプラクティスは、クリアテキストのパスワードを保存しないことですが、回避することは非常に困難です

主な推奨事項は、ファイルシステムのセキュリティを使用して資格情報ファイルを保護し、データベースユーザーのアクセス許可を必要最小限に制限することです。

「カメはずっと奥にある」という表現を聞いた場合、別の場所でパスワードを非表示にしても実際には重要な問題が解決されず、問題が解決されたという見当違いの信頼をもたらす可能性があるというOWASPの見解をうまくまとめています。

エンタープライズセキュリティチームは、時として滑稽で、カメや無限回帰の問題を含む哲学的議論に対する認識が欠けている場合があります。したがって、 Tomcat Vault 、OracleWallet、CyberArkなど、Webサーバーの統合を備えたいくつかのパスワードボールトソリューションがあります。