web-dev-qa-db-ja.com

秘密データに環境変数を使用するのは危険ですか?

このブログ投稿 を読んだ後、作者がシークレットを格納するために環境変数を使用することに反対する引数を示した後、アプリケーションのデプロイを続行する方法がわかりません。

彼の主な議論は次のとおりです。

  • 環境が暗黙的にプロセスで利用可能であることを考えると、アクセスを追跡し、コンテンツがどのように公開されるかを追跡することは不可能ではないにしても困難です(ps -eww)。

  • アプリケーションで環境全体を取得し、デバッグまたはエラー報告のために出力するのが一般的です。非常に多くの秘密がPagerDutyに漏えいしており、インフラストラクチャからそれらをスクラブするための十分に油を塗った内部プロセスを持っています。

  • 環境変数は子プロセスに渡されるため、意図しないアクセスが可能になります。これは、最小特権の原則を破ります。アプリケーションの一部として、サードパーティのツールを呼び出して何らかのアクションを実行するとします。突然、サードパーティのツールが環境にアクセスできるようになり、神はそれで何ができるかを知っています。

  • アプリケーションがクラッシュした場合、後でデバッグするために、環境変数をログファイルに保存するのが一般的です。これは、ディスク上の平文の秘密を意味します。

  • ENV変数に秘密を設定すると、すぐに部族の知識に変わります。特定の環境変数のデリケートな性質を認識していない新しいエンジニアは、それらを適切に(注意深く(サブプロセスにフィルタリングするなど))処理しません。

これらは私には合理的に思えますが、私はセキュリティの専門家ではありません。彼の別の提案はDockerの秘密保持機能を使用することですが、それはDockerを使用していることを前提としています。 Herokuにいます。だから、私はこれについてはちょっとわかりません。 HerokuでのVaultの使用はサポートされていないようです。

8

一般に、ディオゴが彼の投稿で述べているように、シークレットを環境変数に格納することにはいくつかの欠点があります。

一般的に、Herokuのようなプラットフォームの場合、またはアプリケーションが一時的であることが予想されるDockerのようなテクノロジーを使用する場合は、専用のシークレット管理ツールが最適です。アイデアは、暗号化された形式で秘密を保持し、実行時にアプリケーションにそれを提供するツールがあるべきであるということです。

シークレットはアプリケーション内に、通常はファイルとして保存でき、必要に応じてそのファイルから読み取ることができます。

この領域のツールの2つの例は、 Hashicorp Vault および Square's Keywhiz です。

これに加えて、クラウドにデプロイする場合、通常、クラウドプロバイダーには、何らかの秘密管理機能( AWS Secrets Manager など)が必要です。

Herokuでのシークレット管理の経験はあまりありませんが、この領域で動作する ice というアドオンがあるようです。

2
Rory McCune