質問: 環境変数を介して秘密を渡すことが「非常に安全でない」と考えられているのはなぜですか? 環境変数を介してシークレット(パスワード)をプログラムに渡すことは mysql docs に従って「非常に安全でない」と見なされ、 その他のリソース では(セキュリティの観点から)不十分な選択と見なされます。理由を知りたいのですが、何が欠けているのですか?前述のmysqlマニュアルでは(例としてこれを使用しています)、コマンドラインの-pオプションを介してパスワードを渡すと、「insecure」と見なされ、env var 「extlyly insecure」のように、太字の斜体フォント。私はエキスパートではありませんが、基本的なことは知っています。権限のないユーザーが発行した単純なpsコマンドは、コマンドパラメータとともにすべてのプログラムを読み取ります同じユーザーのみ(およびroot、もちろん)プロセスの環境を読むかもしれません。したがって、ハッキングされたwww-dataスクリプトがrootを介してすべてを読み取る一方で、johndoeとjohndoeのみがps-開始されたプロセスの環境を読み取ることができます。ここで私が見逃している大きな問題があるに違いありません-何が足りないのか説明してください。私の目的は、あるプログラムから別のプログラムにシークレットを転送する手段を持つことです。一般的には、非インタラクティブです。
回答: 環境変数でシークレットを渡す場合の主な問題は、このシークレットを使用するプロセスにその環境を適切にスコープすることと、シークレットを持たないはずのプロセスにそれを与えないことです。環境変数を使用する特定のプロセスを開始するためにのみ、環境変数を設定しても安全です。ただし、シェルでグローバルに(現在のセッションの)環境にシークレットを設定することは安全ではありません(さらに悪いことに、シェルのグローバルスタートアップファイル(.bash_profile、.bashrc、.profile ))そのシェルから起動されたすべてのプロセスは、環境にこの秘密を持っているためです。一部は、意図的(マルウェア)であるかどうかにかかわらず、それらをリークする可能性があります(シェルコマンドの履歴、またはログファイルまたはリモートサーバーの環境の全内容をダンプするクラッシュレポートモジュールについて考えてください)。残念ながら、アプリケーション開発者の観点からは、アプリケーションのユーザーが環境を適切にスコープすることを強制することは不可能です。私は個人的に~/.profileに保存されている非常に多くの秘密を見てきました。したがって、ユーザーによる環境の悪用を回避するには、環境に直接シークレットを読み込まない方が(リークの影響を減らすため)、代わりに環境変数を使用して、シークレットが実際に格納されている場所へのリンクを渡します。インダイレクションの追加レイヤー。