☰

プロセスの環境変数が公開されないように保護

tag-icon • tag-icon permissions security configuration environment-variables
プロセスの環境変数が公開されないように保護

Webアプリケーション開発の現在のベストプラクティスを読みました（例：12の要素ガイド) 構成データを保存する推奨方法は次のとおりです。環境変数。これは、プロジェクトのリポジトリに誤ってチェックインして「コード/構成」の分離を破り、潜在的に秘密（たとえばAPIキー、ソルトなど）を公開する設定ファイルに保存するのとは対照的です。

しかし、私が解決しなかったのは、偶発的な暴露を防ぐ問題です。構成ファイルを使用する場合、特定のユーザーを除く誰もが秘密の構成を読み取らないようにファイル権限を適切に設定できます。しかし、Unixシステムはプロセスの環境変数に対してこれらの保護を提供していないようです。プロセスが他のユーザーによって開始された場合も同様です。

$ sudo -u root x=5 sleep 30
$ ps au -E | grep sleep  # in different terminal
root 53814 s003  S+     0:00.01 sudo -u root x=5 sleep 30

変数に機密データが含まれている場合は、x任意のユーザー（ルートまたはスヌーピングしたいプロセスを開始したユーザーである必要はありません）でログインしたシステムにアクセスして簡単に読み取ることができます。したがって、この構成方法は、環境変数を何らかの方法で保護できない限り、構成ファイルよりも安全性が低くなります（深いPoVの観点からは、当然、マシンは不正アクセスから保護される必要があります）。

ps a -Eだから私の質問は：同じUnixシステムの他のユーザーが（および他の可能な手段を介して）プロセスの環境変数を見ないようにする方法はありますか？

ベストアンサー1

まず、良い質問です！

この-Eスイッチはプロセスの開始時にのみ環境を表示するため、変更はこのメソッドには表示されません。したがって、プロセスの開始後に環境にデータがロードされると、この方法では取得されません。ただし、IMHOは以下の理由で実行可能な戦略ではない可能性があります。

私は環境変数のトリックが良い方法であるというTwelve Factorのコメントに同意します。ただし、12の要素ガイドに記載されていないいくつかの重要な考慮事項、およびこの目標を達成するためのいくつかの実質的な考慮事項と技術があります。

まず、環境変数は揮発性（非持続的）です。再起動すると、すべてのデータが失われます。つまり、構成するといいえどこかに残っていると、システム管理者のメモリにない限り、サーバーを再起動しても回復できません/dev/brain0（128ビットキーでギャンブルしません）。これがサーバーの秘密鍵であれば、せいぜい大きな問題があり、最悪の場合は致命的な問題になります（CAで鍵を再発行する必要があるかもしれません）。これはどこかに設定を書く必要がある良い例です。しかし重要なのはどこに/どのように保存されるかです。

Twelve Factorアプリは直接的な方法ではありませんが、この問題を解決します。 「アプリケーションがコードからすべての構成を正しく抽出したかどうかについてのリトマステストは、コードベースが資格情報を損なうことなく簡単にオープンソース化できるかどうかです。」どこかに、構成をコードベースに入れることはできません。 「別の構成方法は、バージョン管理にチェックインされていない構成ファイルを使用することです。」

Twelve Factor Appsは、「誤って設定ファイルをリポジトリにチェックインするのは簡単です」と言います。この問題を解決するには、本番構成（秘密鍵など）が開発およびテスト構成と異なる必要があります。彼らもそうしなければならない厳しく制御。一部のバージョン管理システムには、特定のファイルがチェックインされないようにブロックするgitブラックリスト（ファイルなど）があります。.gitignoreこれらも使用する必要があります。 「構成ファイルはさまざまな場所とさまざまな形式に散在する傾向があるため、1つの場所ですべての構成を表示および管理することは困難です。また、これらの形式は言語またはフレームワークによって異なります。」 「環境変数」を使用すると、この問題を解決できます。その後、サーバーは起動時に環境にロードできます。

私は何をしますか：

  1. 本番サーバーの構成情報（サーバーの秘密鍵など）を、主記憶域とは別の別々の記憶域に保管します。
  2. 本番構成ファイルを保護します。チーム内のすべての開発者ではなく、少数の人だけがアクセスできます。たとえば、QA/DevOps/システム管理者/などです。このファイルはおそらくそこにあるので、サーバーのキーだと思います。開発およびテスト環境には、本番環境とは異なる資格情報とキーが必要です。その後、より緩く保存することができます。
  3. サーバーのinitルーチンが構成ファイル情報を実際の環境変数にロードするようにします。
  4. アプリケーションが実行時に環境変数から必要な構成情報をロードできるようにする

おすすめ記事