環境変数を介してプログラムにパスワード（パスワード）を渡すことは、次のように「非常に安全ではない」と見なされます。MySQLドキュメント（セキュリティの観点から）良くない選択です。その他のリソース。
なぜかと思います。私が何を見逃しているのでしょうか？言及されたMySQLマニュアル（私はこれを例として使用しています）で-pコマンドラインのオプションを介してパスワードを渡すことは」不安定「そして環境変数を次のように渡します」非常に不安」、太いイタリック体。
私は専門家ではありませんが、基本は知っています。ps権限のないユーザーが実行した場合でも、単純なコマンドはすべてのプログラムとコマンド引数を読み取ります。そして同じユーザーだけ（もちろんルートも）プロセス環境を読むことができます。したがって、プロセスが開始された環境のみをroot読み取ることができますが、ハッカースクリプトはすべてを読み取ります。johndoejohndoewww-dataps
ここに私が逃した何か大きなものがあるでしょう。それでは、私が見逃したものが何であるかを説明してください。
私の目標は、通常、非対話型の方法であるプログラムから別のプログラムに秘密を転送する方法を見つけることです。
答え1
非常に安全ではないため、使用しないでください。psの一部のバージョンには、実行中のプロセスの環境を表示するオプションが含まれています。一部のシステムでは、MYSQL_PWDを設定すると、psを実行している他のユーザーにパスワードが公開されます。
背景：このプロセスでは、イメージargv []とenvp []は同じ方法で並べて保存されます。 「クラシック」UNIXでは、/ usr / bin / psは通常setgid "kmem"（または同様のグループ）であり、これによりアクティブプロセスに関する情報を読むために/ dev / kmemを掘り下げることができます。これには、システム内のすべてのユーザーのプロセスパラメータと環境を読み取る機能が含まれます。
この「権威のあるpsハッキング」は基本的に最近のことです。 UNIXシステムはすべて、これらの情報を照会するさまざまな方法（Linuxの/ procなど）を提示します。したがって、環境内のパスワードなどのセキュリティに敏感なデータは漏えいしません。
しかし、既存の方法が100％消えるわけではありません。例えば、以下は、私がアクセスできるAIX 5.2システムでroot以外のユーザーとして実行される例です。
[AIX 5.2は2009年に寿命が終了しました。 AIX (少なくとも 6100-09 以降) および 7.2 で確認され、非 root ユーザーは「ps ewwwax」コマンドを使用して他のユーザーのプロセス環境を表示できなくなりました。 ]
...
記録によると、私たちはしばらく前にOpenBSD 5.2に他のローカルユーザーに環境を公開するセキュリティ脆弱性があることを発見しました（しかし、この問題はリリース直後に修正されました）。
[2012年にリリースされたOpenBSD 5.2]
これは、MySQLのマニュアルで環境変数を使用することが考えられる理由を説明しません。極度にコマンドラインパラメータと比較して安全ではありません。この質問に対する他の回答をご覧ください。簡単に言えば、マニュアルが混乱しているか、環境変数が誤って簡単に「流出」します。
答え2
MySQLドキュメントのこのアドバイスは誤った表現です。
逆に、環境変数にパスワードを渡すことは、コマンドラインにパスワードを渡すよりも安全ではありません。ほとんどの最新のユニークは、psコマンドや他の同様のソフトウェアを介してすべてのユーザーにプロセスのコマンドラインパラメータを公開しますが、その環境は公開しません。例外もありますが、その逆（環境は公開しますがパラメータは公開しません）を実行するシステムについては聞いたことがありません。
対話型シェルに入力するコマンドにパスワードを含めることはお勧めできません。なぜなら、パスワードは最終的にシェルレコードに表示されるからです。シェルの記録をオフにしても大丈夫ですが、そうする必要があることを覚えておく必要があります。これは、パスワードがパラメータとして渡されるのか環境に渡されるのかによって異なります。
環境変数は、変数が別のプロセスに渡されるとより危険です。たとえば、データベースパスワードを設定すると、.profileすべてのプログラムに表示されるため、非常に悪い考えです。また、export MYSQL_PWD=…その範囲外の多くのコマンドを実行するスクリプトを上部近くで実行するmysqlことはお勧めできません。ただし、環境変数がmysqlコマンドにのみ渡される場合は問題ありません。
MySQLドキュメントでは、環境変数を介してパスワードを渡すことは、コマンドラインパラメータを介してパスワードを渡すよりも安全性が低いと見なす言語を使用しないでください。正反対。 （環境設定がmysqlコマンドの範囲を超えない限り、文書に記載されているシナリオではありません。）
答え3
環境変数に秘密を渡す際の主な問題は、その環境の範囲を秘密を使用するプロセスとして適切に指定し、秘密が存在しないプロセスに提供しないことです。
その環境変数を使用する特定のプロセスを開始するためだけに環境変数を設定することは安全です。
ただし、シェルのグローバル環境（現在のセッションに対して）でシークレットを設定することは安全ではありません（シェルのグローバルスタートアップファイル（.bash_profile、、、）では悪い）。なぜなら、そのシェルで開始されたすべてのプロセスはそのプロセスにこの秘密を持っているからです。秘密の。環境。一部は、意図的に（悪意のあるプログラム）または意図せずに（シェルコマンドの履歴または環境の全内容をログファイルまたはリモートサーバーのクラッシュレポートモジュールにダンプすることを考えてみてください）、漏洩する可能性があります。.bashrc.profile
残念ながら、アプリケーション開発者の観点からは、アプリケーションユーザーが環境の範囲を正しく指定することを強制することは不可能です。私はその中にあまりにも多くの秘密が含まれていることを私の目で直接見ました~/.profile。
したがって、ユーザーが環境を誤って使用するのを防ぐために、環境に直接パスワードをロードするのではなく（漏れの影響を減らすために）、環境変数を使用してパスワードが実際に保存されている場所へのリンクを渡す方が安全です。間接指定の追加レイヤー。
答え4
次のシナリオを考えてみましょう。
- php/ruby/whatever + mysqlアプリケーションを構築しました。
- アプリケーション/サーバーでエラー500が発生するようにしました。特定の設定は私のブラウザにENVとあらゆる種類のスタックトレースを生成します。
- 私は楽しさと利益のために秘密にmysqlやsmtpを使用します。
また、これについて考えてみてください。
- apache/nginx フォルダを正しく構成できませんでしたが、.env ファイル自体にアクセスできました。
- 繰り返しますが、私は楽しさと利益のためにmysqlやsmtp秘密を使用します。
結論：秘密のプロバイダを使用してください（使いやすく、費用がかからない）。ただし、余裕がない場合は、Webサーバーの公開など、設定の他の点で最大セキュリティを正しく設定していることを確認してください。 .envファイルまたはenv変数の公開。