Linuxでのアプリケーションシークレットの安全な保管
一部のデータを復号化するためにシークレットを読み取る必要があるLinuxアプリケーションがあります。アプリケーションでは、ユーザーが実行時に暗号化パスワードを変更することもできます。アプリケーションは別のユーザーアカウントで実行され、シークレットは現在そのユーザーが所有するファイルにあります。パスワードはファイル内で平文なので、この状況を改善する方法を考えています。
アプリケーションをrootとして起動してから、特権をアプリケーションユーザーにドロップできます。このように、シークレットファイルはrootが所有できますが、別のデーモンをrootとして実行している場合を除いて、パスワード変更シナリオは機能しません。
私は基本的に秘密がディスク上に平文であることを防ぐために探しています、そしてbootstrap暗号化プロセスへのループに人間がいない場合、実行できる最善のことはそれをより困難にすることです誰かがコードを実行したとしても秘密に達する。
現在の状況をどのように改善できるかについて誰かが何か提案を共有できますか？ keyctlはここで適用できるものですか、それとも通常はカーネルシークレットを格納するためだけに使用されるものですか？
どんな提案も歓迎されます！
サービス通常、rootとして実行しないでください。シークレットを格納するために別のユーザーを使用することは賢明な予防策ですが、rootの所有権でファイルを格納することは、このために別の専用ユーザーを使用することよりも機密性に優れています。シークレットファイルに権限がある限り600以下であれば、他のrootユーザーからは安全です。とにかくrootを実行しているものはすべてフルアクセスできます。 （いくつかの複雑なSELinuxセットアップを実行している場合を除きます）
この単一のアプリケーションでシークレット管理を通常の操作から分離するには、2人のユーザーを使用が役立つ場合があります。 2つのデーモンをリアルタイム通信で実行するか、シークレットを操作するユーティリティコマンドを使用して、Sudoを介して必要な特権（ユーザーまたはグループベース）を取得します。
潜在的な攻撃ベクトルを考慮する必要があります。
SQLiが適切に構成されている場合、ファイルシステムへのアクセスは許可されませんが、パストラバーサル攻撃は可能です。他にも保護する必要のあるアプリケーションに対する攻撃の種類があります。
Cライブラリのエクスプロイト（つまり、HTTPS暗号化、画像処理などを実行するOpenSSL）が可能性があります。ネットワークに公開されたプロセスで分離されたユーザーを使用すると、スコープを制限したり、攻撃を困難にすることができます。
その他の攻撃ベクトルからの侵入–問題になる可能性があります。 （SSH、マシン上のその他のサービス）
rootアクセスの可能性があるものはすべて十分に保護されていることを確認してください。
これらの考慮事項はすべて、秘密自体を保護するのに役立ちます。さて、問題は次のとおりですシークレットはプレーンな形式で保存する必要がありますか？
最も基本的なレベルでは、はい。シークレットを使用するには、どこかに保存する必要があります。少なくともメモリに保存する必要がありますが、何らかの永続的なストレージも必要です。
これまでに説明したユーザーの分離を超えて、シークレットを別のハードウェアセキュリティモジュールに、または別のミニコンピュータにオフロードすることは有用です。 （つまり、Raspberry Pi）ここでは物理的な分離について 議論があります 。
シークレット自体を永続的なストレージで暗号化できるケースはほとんどありません。
ハードドライブの盗難が懸念される場合は（マシンの残りの部分を残します）、起動スクリプト他のハードウェアのいくつかに一意の識別子を問い合わせますを使用し、次を使用して暗号化キーを取得します。優れたパスワードベースのキー導出関数。秘密を復号化します。
クライアントが秘密の一部を提供できる場合、それは役に立ちます。ここでは、ユーザーパスワードとセッショントークンから復号化キーを 導出する方法の概要を説明しました 。これは精巧でありながら効果的なシステムであり、シークレットがメモリに保存される時間を制限することに重点を置いています。 （パスワードの自動リセットが不要であると想定）
あなたが持っているものは物事を行う伝統的な方法です。たとえば、TomcatはOWASP concurring を使用してそれを行うことを推奨しています。だから、あなたが持っているものは悪くありません。
ただし、他にも方法があります。ハードウェアセキュリティモジュールは、キーストレージ用に設計されたアクセス制限付きストレージです。 HashicorpのVault、KeyWhiz、および同様のテクノロジーは秘密の管理システムであり、基本的にソフトウェアHSMを目指しています。もちろん、これらのテクノロジーはすべて、プロセスを認証できる必要があります。その利点は、そのためのさまざまなメカニズムがあることです。 rootを使用して、メモリにWebユーザーのみに提供されるキーへのアクセスを取得できます。そのキーを使用してHSM/Vault/KeyWhizにアクセスし、実際のキーにアクセスして変更できます。他のメカニズムもあります-EC2キーを使用するAWS固有のメカニズム、その他のメカニズム。あなたはうまくメッシュする何かを見つけることができるかもしれません。
私の個人的な意見では、試された真の制限付きユーザー（この目的でのみ使用）とそのユーザーのみにファイルを制限することは悪い方法ではありません。しかし、他のオプションがそうであるかもしれない場所では、それはうまくスケーリングしません。
シークレットが、人間の介入なしにアプリケーションによって読み取り可能な方法でサーバーに格納されている場合、そのマシンの少なくともrootによって読み取り可能です。
ファイルがプレーンテキストであることは問題ではありません。権限によってのみ保護でき、rootはそれらの権限をバイパスできます。ファイル（またはファイルが置かれているファイルシステム）の暗号化は、暗号化キーがファイルを読み取るためのプロセスでのみ利用可能であり、外部からの介入（および検証）が必要な場合にのみ役立ちます。秘密へのアクセスの問題をどこかに移動しているだけです。
システム上のすべてのアカウントの制御を保持している場合でも、アプライアンスとして構築しますが、それでもシステムへの物理的なアクセスの問題が残ります。物理的な整合性を確保できることに満足している場合、システムをアプライアンスとして維持するという問題があります。パッチはどのようにインストールするのですか？
Hsmは、ハードウェアであっても、通常のアクセスを過度に複雑にするのではなく、完全に安全なソリューションを提供するとはほど遠い（複雑であるが、不正なアクセスを防止しない）。
ソリューションが期待に反するものである場合、脅威モデルの詳細とともに、制約（開発コスト、ユニットコスト、予想ボリューム）についてより具体的にする必要があります。