バージョン管理にパスワードを保存することはなぜ悪い考えですか？
私の友人は私にちょうど尋ねました：「私たちが私たちのプライベートGitサーバーにのみ保存するときに、さまざまなパスワードをプログラムのソースコードに直接入れるのが実際にそんなに悪いのですか？」
私はいくつかの点を強調した答えを彼に与えましたが、それは十分に組織化されていないと感じ、これが正準の質問を作成するのに意味があるかもしれないと判断しました。
また、ソースコードにパスワードを保存しないことは、最小特権の原則や情報セキュリティの他の基盤とどのように関連していませんか？
Git（または他のバージョン管理）にパスワードを保存しないのは、規約です。それをさまざまな結果で強制しないことを決定できると思いますが、これは一般的にこれが嫌われる理由です：
- Gitを使用すると、ソースコードの履歴からパスワードを削除するのが面倒になり、現在のバージョンではパスワードが既に削除されているという誤った考えを人々に与える可能性があります。
- パスワードをソース管理に置くことで、基本的に、将来のユーザーを含め、リポジトリにアクセスできるすべての人とパスワードを共有することを決定します。これは、異なる権限を持つ可能性のある開発者チーム内での役割の確立を複雑にします。
- ソース管理ソフトウェアは、特に「オールインワン」システムではかなり複雑になる傾向があります。つまり、このシステムが最終的に危険にさらされ、パスワードの漏洩につながる可能性があるというリスクがあります。
- 他の開発者は、パスワードが保存されていることに気づかず、リポジトリを誤って処理する可能性があります。ソースにキーがあると、コードを共有するときにさらに注意が必要になります（社内でも、これにより暗号化されたチャネルが必要になる場合があります）。
私 infosecに関連するすべてのパターンが良いとは言えません ですが、それらを壊す前に、脅威モデルと攻撃ベクトルを検討することは常に良い考えです。この特定のパスワードが漏洩した場合、攻撃者がこのパスワードを使用して会社に害を及ぼすことはどの程度困難ですか？
まず、セキュリティ以外の理由：
パスワード変更ワークフロー
パスワードは、ソフトウェアアプリケーションコードとは無関係に変更されます。 DBAがデータベースのパスワードを変更した場合、開発者がコードを更新し、新しいビルドを取得して本番環境にリリースし、すべての時間を計る必要があるのは理にかなっていますか？パスワードはランタイム構成アーティファクトであり、開発アーティファクトではありません。これらは、構成ファイル、環境変数、または使用している構成パラダイムを介して注入する必要があります。
認可スコープ
一般に、バージョン管理システムは承認管理を提供するため、承認されたユーザーのみがそれにアクセスできます。しかし、リポジトリ内では、アクセス許可は通常、読み取り/書き込み、または読み取り専用のいずれか、あるいはGitHubが提供するようないくつかの標準的なものです。開発者がソースコードを取得できるようにするセキュリティ制約を見つけることはほとんどありませんが、パスワードではありません。リポジトリを複製できる場合は、リポジトリを複製できます。限目。多くの環境では、開発者は本番環境への完全なアクセス権を持っていません。運用データベースへの読み取り専用アクセス権がある場合もあれば、アクセス権がない場合もあります。開発者が一般的にアクセス権を持っているが、すべてのインターン、新入社員などにアクセス権を与えたくない場合はどうなりますか？
環境
開発環境、QA環境、ステージング、本番などの複数の環境がある場合はどうなりますか？すべてのパスワードをバージョン管理に保存しますか？アプリはどの方法を使用するかをどのようにして知るのでしょうか？アプリには環境を知る方法が必要であり、それが構成設定になります。 環境名を構成設定にできる場合は、データベースパスワードを構成設定にすることができます（接続文字列、ユーザー名などとともに）
履歴
他の人が述べたように、バージョン管理は履歴を保持するように設計されています。そのため、古いパスワードは引き続き取得できますが、これは最善の方法ではない可能性があります。
妥協
一部の製品のソースコードが世界中に漏れているというニュースの見出しを何回目にしましたか？ソースコードは、バージョン管理されているものであれば何でもかまいません。これが、パスワードをバージョン管理に入れない最大の理由です。
ただし...
つまり、パスワードはどこかに保存する必要がありますどこか。上記の懸念が示唆していることは、それらがバージョン管理にまったく保存されるべきではないということではなく、製品のソースコードリポジトリに保存されるべきではないバージョン管理。構成管理、操作などのために別のリポジトリを持つことは非常に合理的です。重要なのは、セキュリティ資格情報に関して、操作と開発を分割することであり、必ずしもバージョン管理を完全に回避する必要はありません。
また、非本番環境では、外部システムのパスワードとAPIキーをデフォルトで製品のソースコード内の構成ファイルに保存しました。どうして？開発者がコードをチェックアウトするときにそれを簡単にするために、彼らはそれをビルドして実行するだけでよく、余分な設定ファイルをフェッチする必要はありません。これらはめったに変更されない信用証明書であり、企業秘密にはつながりません。しかし、私はプロダクションシークレットを使用してこれを行うことはありません。
つまり、最終的には...状況によって異なります。
提案は、ユースケースに合わせて調整する必要があることを常に心に留めておくことが重要です。たとえば、NSAが雨の日のために維持するゼロデイを保護するために講じられたセキュリティ保護策は、猫の賛成票を保護するために講じられたセキュリティ保護策よりもはるかに厳格であるべきです。画像投稿サイト。極端な例として、パスワードやトークンなどをプライベートgitリポジトリに保存するのが妥当な例を考えることができます。
そのリポジトリへのアクセスが1人のユーザーであり、アプリケーションが価値のある情報を保存していない場合。
その場合は、町へ行こう！ @ d33tahが彼の答えで言ったことを覚えておいてください-gitリポジトリからのものをスクラブするのは驚くほど難しい場合があります（結局のところ、すべての履歴を永遠に保持することです）。より多くの人とコラボレーションしますが、彼らがすべてのシステムに完全にアクセスできるようにしたくない場合は、少し頭痛の種になります。
それが本当に重要なことです。コードリポジトリは、たとえ共同編集者とのみ共有されていても、何らかの方法で「公開」されています。誰かと共同作業をしたいからといって、インフラストラクチャへのフルアクセスを許可したいというわけではありません（これは、パスワード/トークンをコードリポジトリに配置すると実際に起こることです）。 「はい、でも私は私が協力している人々を信頼します！」と考えるのは簡単ですが、それは単に、シナリオを見るには間違った方法です。理由の：
- 実際の業務では、データ漏洩の大部分は内部関係者（共同作業者、従業員）から始まります。一人で study データ侵害の約43％は内部のアクターから始まりました。それらの半分は意図的であり、半分は偶然でした。
- その最後のポイントは重要であり、これが信頼だけではない理由です。データ漏えいの約20％は偶発的であり、内部の人々が原因です。私は、常にすべてを正しくするほど賢くないということを知っているほど賢いです。リポジトリを公開して楽しい統合ツールのためのスペースを作り、そこに資格情報があることを忘れた場合はどうなりますか？暗号化を忘れたバックアップハードドライブがあり、オフィスの外に出てしまった場合はどうなりますか？パスワードの1つが漏洩し、誰かがそれを使用してgitリポジトリ（cough gentoo github repository cough）へのアカウントのパスワードを推測した場合はどうなりますか？ [〜＃〜] i [〜＃〜]が偶然のミスをいくつも引き起こす可能性があり、私のgitリポジトリが公開される可能性があり、それが発生した場合and私はそこに資格情報を持っていますand彼らを見つけた人は彼らが何を見ているかを知っています。これはandのように聞こえますが、実際にはこれが違反の発生方法です。
- 私が誰かを信頼しても、それは私が彼らにすべてへの完全なアクセス権を与える必要があることを意味しません[力がどのように腐敗するかについての安っぽい引用を挿入する]。繰り返しになりますが、資格情報をgitリポジトリに配置するということは、すべてのインフラストラクチャへの完全なアクセス権をすべての共同編集者に与える可能性があることを意味します。あなたがその人を知っているだけでなく、あなたもその人を知らない可能性は常にあり、彼らは彼らがしてはいけないことをすることに決めるかもしれません。あなたが自分の人生で協力者の1人を個人的に知っていて信頼しているとしても、それが誤ってあなたを解放するために上記の間違い（または私が言及しなかった無限のオプション）のいくつかをしないということではありませんコード。
つまり、優れたセキュリティとは、多層防御を実現することです。ほとんどのハッキングは、ハッカーが1つの領域の弱点を見つけて別の領域の弱点を悪用することを可能にするために発生します。これにより、どこか他の場所につながり、最終的にbigペイオフになります。状況に応じて適切な数のセキュリティ対策を講じることが、全体を安全に保つためのものです。このようにして、バックアップハードドライブがオフィスの外に出て、暗号化されていないことに気付いた場合、「これは標的型攻撃でしたか？それらはすべて、そのバックアップドライブのgitリポジトリにありましたか？」繰り返しになりますが、状況によってはこれが当てはまらない場合がありますが、うまくいけば、これがどのようなシナリオで問題になるかを説明するのに役立ちます。
シークレット（パスワード、証明書、キー）をソースコードから分離すると、さまざまなポリシーに従ってソースとシークレットを管理できます。同様に、すべてのエンジニアがソースコードを読み取ることができます。シークレットにアクセスできるのは、運用サーバーを直接担当する人だけです。
シークレットを保護するために必要な厳格なセキュリティポリシーに縛られないため、開発者はこれにより生活が楽になります。ソース管理ポリシーを使用すると、はるかに便利になります。
この規則は、他の多くのセキュリティ「ベストプラクティス」と同様に、悪い習慣や習慣が原因で問題が発生しないようにするための便利な方法です。
If機密性の高いパスワードがバージョン管理システムにあることを常に覚えており、ifレポジトリへのパスワードアクセスを許可してはいけない人には決して与えないifあなたのリポジトリはこれらの秘密が要求するのと同じくらい安全に保管され、if同様にあなたの配備プロセスは安全で、安全で無許可の人々から保護されていますifリポジトリのすべてのバックアップとコピーは次のとおりです。おそらく、コンテキストに固有の「if」をさらに追加できます。
...その後、バージョン管理システムにパスワードを保存できます。
ほとんどの状況では、これらの「if」の少なくとも1つが条件に十分に準拠していないか、制御不能です。
たとえば、多くの設定では、開発者は本番データベースにアクセスできません。または、バックアップシステムを別の部門に外部委託しています。または、ビルドプロセスはクラウドに外部委託されます。
それが一般的にであり、バージョン管理システムにパスワードを保存しないことがベストプラクティスであり、それらを考慮していなかったためにこれらのトラップの1つに陥らないようにします。 「gitにパスワードなし」は、バージョン管理下でパスワードを安全に保存するために満たす必要のある条件の長いリストよりも覚えやすいです。
他の答えは素晴らしいですが、バックアップの問題も考慮してください。サーバーまたは管理者アカウントへのアクセス方法に関する機密情報が含まれていない場合、コードリポジトリのバックアップをどこに、どのように、どのくらいの期間保存するかについて、はるかに柔軟性があります。
セキュリティに重点を置いた別の角度から見ると、コードのバックアップmightは、ビジネスの非倫理的な競合他社にとって興味深いターゲットになります。あなたのビジネスにもよりますが、「法の支配」の国のほとんどの競争相手は、とにかくそれに触れません。コードのバックアップwithパスワードは、ユーザーのデータに関心がある、または会社を脅迫することに関心がある犯罪組織のターゲットになります。
コードリポジトリ違反による被害は、同様の理由でパスワードの方が大きくなります。ソースコードを盗んで公開したり、すべてのユーザーに個人情報の盗難を知らせたり、個人データの保護に失敗したり（GDPRを考慮して）訴訟を起こしたり、刑事訴訟を起こす可能性はありますか？
「私たちが文明から遠く離れて住んでいるときに、鍵を玄関のドアに直接置くのが実際にそれほど悪いのはなぜですか。」
悪いことをしたい人は簡単にやるし、彼らのために一生懸命やることのコストは高すぎないからです。ドアの隣ではなく、鍵を携帯してください。常識。
プライベートレポ？ダウンロードするためにアクセスできる人は何人ですか？そして、何人の人がそのコンピュータに接続していますか？そして...彼らはすべて危険から解放されていますか？
また、ソースコード管理システムにも依存します。
Gitは、ソースコード管理システムがプロジェクトの信頼できる履歴を提供するべきであるという姿勢を持っています。これは悪い態度ではありません。しかし、gitにパスワードをチェックインした場合、リポジトリからパスワードを削除するのが非常に難しいという影響があります。
PERFORCEには、そのためのコマンド「obliterate」があります。パスワードをチェックインしたか、8ギガバイトの非圧縮ビデオファイルをチェックインしたか、誰かが著作権を侵害していてチェックインすべきではないサードパーティのコードをチェックインしたか、解雇された人が大量のポルノをチェックインしたか彼らの仕事の最終日、あなたはそれを「消滅」させることができます。リポジトリや履歴から完全に削除されました。