秘密をソース管理の外に保つ-問題を解決するだけですか？

App.configおよび同様のファイルでシークレットがソース管理されているいくつかのプロジェクトを継承しました。幸い、それは公開リポジトリではないため、リスクはそれほど深刻ではありませんでした。Azure KeyVaultなど、これを管理するためのより良い方法を検討しています。（しかし、この質問がその解決策に固有であるとは思わない。）

一般に、問題を解決するだけではないですか？たとえば、Azure KeyVaultでは、アプリIDとアプリシークレットが、ソース管理の対象外にしておく必要があるものになります。残念ながらこれがうまくいかない傾向の典型的な例を次に示します。他のアプローチも同様になり、APIキーまたはキーストアファイルを保護する必要があります。

Azure KeyVaultのような製品は、シークレットを個別の構成ファイルに保存し、それが.gitignoreまたは同等のものに含まれていることを確認するよりも優れており、意味のないほど複雑であるように思えます。このファイルは、必要に応じてサイドチャネルを介して共有する必要があります。もちろん、人々はおそらく安全にお互いにそれを電子メールで送信しません...

問題を解決するだけでなく、秘密を管理する方法はありますか？この質問には、明確に定義された単一の答えがあると思います。類推して、HTTPSが問題を解決するだけではないのかと尋ねると、答えはCAキーがOSと共に配布され、OSの配布方法を信頼しているので、私たちはそれらを信頼しているということです。（別の質問にする必要があるかどうか...）

あなたは単に問題を解決していると言えます。最終的には、パスワード、SSHキーなどを取得するために、アプリがアクセスできる場所にシーク​​レットを保存する必要があります。

しかし、正しく実行すると、問題を適切に保護することが困難な場所から、より適切に保護できる場所に移動できます。たとえば、公開githubリポジトリにシークレットを配置することは、家の鍵を正面玄関にテープで留めておくのとほとんど同じです。それらを望んでいる誰もがそれらを見つけるのに苦労しません。しかし、外部ネットワークに接続されていない内部ネットワークのキーストアに移動すると、パスワードを安全に保つ可能性が高くなります。それは、鍵をポケットに入れておくようなものです。それらを紛失することは不可能ではありません（たとえば、Azureのパスワードを提供するのと同じです）。

暗号化キーや資格情報などのシークレットは、いくつかの理由でソース管理にチェックインすべきではありません。1つ目は、暗号化キーと資格情報は常に知る必要があるということであり、ソース管理は情報を開示から保護する信頼できる方法ではありません。ソースコントロールでこのようなシークレットを望まないもう1つの理由は、通常、シークレットはアプリケーションが実行される環境の特定の属性に固有（常にではない）であるためです（たとえば、デジタルを作成するための秘密キーの取得Webサービス認証に必要な署名、そのWebサービスの特定のエンドポイントは、QA署名を必要とするQA環境で実行されている場合があります。

環境（またはグローバルシークレット）を処理する正しい方法は、他の環境構成属性と同じように扱うことであり、適切な対策のために追加のセキュリティ制御を備えています。適切に設計された、独立したバージョン管理可能なコードモジュールは、アプリケーション全体に属性（データベース接続の詳細、資格情報、Webサービスエンドポイント、ファイルパスなど）を通知するためにデプロイされる環境など、環境全体で同一である必要があります。アプリケーションにとって重要な構成の詳細は外部化され、環境の構成パラメーターになります。

次に、いくつかの引数に対処します。

一般に、問題を解決するだけではないですか？

完璧なセキュリティなどというものはありませんが、追加の対策や制御を配置できる領域に問題を「移動」することで、困難が改善され、秘密の偶発的または悪意のある開示の可能性が減少します。機密データを保護する必要のあるシステムを設計する際に従うべき良い経験則は、常に2で管理することです。つまり、機密情報やセキュリティインシデントの偶発的または悪意のある開示が発生した場合、障害が発生したり、2つ以上の制御が行われたりする必要があります。

この良い例は、暗号化されたファイルをサーバーに保存することです。また、別のファイルで機密を保持する必要がある秘密の復号化キーも持っています。

• キーと暗号化されたファイルを同じサーバーに保存します（0コントロール、サーバーにアクセスできる人なら誰でも簡単に機密情報を取得できます）
• 上記の手順を実行し、両方のファイルへのファイルアクセスを保護して、OSのアプリケーションランタイムユーザーのみが読み取ることができるようにします（1コントロール、rootユーザーまたはアプリケーションランタイムユーザーのパスワードを危険にさらすことにより、攻撃者は機密情報を取得できます）
• 外部キーコンテナーにキーを保存し、IPアドレスのホワイトリスト、証明書認証、およびファイルシステム上の暗号化されたファイルにアクセスできるアプリケーションに対するその他の手段など、複数のセキュリティ手段でキーを取得します。（複数のコントロール、機密データが危険にさらされるにはセキュリティコントロールの複数の障害が発生する必要があります）

繰り返しになりますが、完璧なセキュリティなどというものはありませんが、複数のコントロールを持つという目標は、開示が発生するために複数の障害が発生する必要があることを保証します。

私には、Azure KeyVaultのような製品はより良くなく、無意味に複雑であるように思えます。

複雑なはい、無意味は完全に主観的です。機密データが公開されることの深刻さを現実的に考慮せずに、追加のセキュリティの無意味さについて議論することはできません。機密データを使用して不正な電信送金を金融機関から送信できるとしたら、鍵保管室のようなものは無意味なものから最も遠いものです。

シークレットを別の構成ファイルに保存し、それが.gitignoreまたは同等のものに含まれていることを確認するよりも。

誰かが誤ってソース管理にチェックインするまで、秘密はソース管理の履歴に永久に埋め込まれます。

もちろん、人々はおそらく安全にお互いにそれを電子メールで送信しません...

セキュリティは単なる技術的な問題ではなく、人間の問題でもあります。それはトピック外ですが、私はこの時点で、あなたは必要なことをすることから自分自身を語ろうとしていると感じます。

問題を解決するだけでなく、秘密を管理する方法はありますか？この質問には、明確に定義された単一の答えがあると思います。類推して、HTTPSが問題を解決するだけではないのかと尋ねると、答えはCAキーがOSと共に配布され、OSの配布方法を信頼しているので、私たちはそれらを信頼しているということです。

セキュリティは常に問題をなくすわけではなく、多くの場合、問題を制御します。たとえそれが実際に公開鍵と秘密鍵の暗号化とまったく同じだから、アナロジーは簡潔です。私たちは、CAに完全な信頼を置き、公開証明書を所有するエンティティのIDを保証することにより、CAに「問題を移します」。基本的に、致命的な一連の障害（たとえば、CAへの信頼を失う）以外に、セキュリティの問題につながることはありません。

多くのことと同様に、セキュリティは主観的な基準、データの性質、開示の結果、リスク選好度、予算などに基づいて描く必要がある線です...

秘密鍵ファイルを非対称キーで暗号化されたgit repoに保持するために、git secretプロジェクト（http://git-secret.io/）を検討することは価値があります。公開鍵もリポジトリにありますが、秘密鍵はありません。

このアプローチの特徴は次のとおりです。

• 新しいユーザー/マシンが保護されたファイルを解読する必要があるとき-彼は彼の公開gpg（gnuプライバシーガードaka pgp）キーを公開/送信します。保護されたファイルをすでに復号化できるユーザーは、新しい追加の鍵でそれらを再暗号化できます-その後、新しいユーザーは自分の秘密鍵で保護されたファイルを復号化できます。
• もちろん、誰がgitリポジトリにcommit / pushできるかを制御する必要があります。それ以外の場合、攻撃者は自分の公開鍵をコミットし、承認された誰かがこの新しい侵害された公開鍵で保護されたファイルを再暗号化するまで待つことができます。