バージョン管理システムによる秘密の安全な管理の概要

検索する正確な文字列がわかっている場合は、VCSツールのネイティブ検索機能を使用して、提供された値がコミットに存在するかどうかを確認できます。 たとえば、gitを使用すると、次のようなコマンドで特定のパスワードを検索できます。

これにより、指定した文字列のプロジェクト履歴全体が検索されます。

多くの専用ツールは、秘密をより広く明らかにするのに役立ちます。 gitrobなどのツールは、GitHub組織の各リポジトリをスキャンして、事前定義されたリストのファイル名と一致するファイル名を探すことができます。 git-secretsプロジェクトは、ファイルパスとコンテンツの両方のパターンに基づいて、定義されたシークレットについてリポジトリをローカルでスキャンできます。 truffleHogツールは、アプリケーションで使用される生成されたシークレットを表す可能性が高い高エントロピー文字列をリポジトリで検索することにより、異なるアプローチを使用します。 この機能の一部を単一のツールに組み合わせるために、git-all-secretsは、統合されたインターフェイスで上記のツールを接着または再実装します。

コミットされるべきではないファイルやデータを発見した場合、適切に対応して、漏洩したデータの影響を軽減することが重要です。 適切な行動方針は、リポジトリがどれだけ広く共有されているか、公開されている素材の性質、および漏洩したコンテンツの言及をすべて削除するか、単に無効にするかによって異なります。

資格情報がプロジェクトリポジトリにコミットされる場合、最初の手順は、パスワードまたはシークレットをすぐに変更して、以前の値を無効にすることです。 このステップは、いくつかの理由でリポジトリが共有されているかどうか、またはどれだけ広く共有されているかにかかわらず完了する必要があります。 コラボレーションの要件は、プロジェクトの存続期間を通じて変化する可能性があり、これまで予想されていたよりも大きな露出につながります。 プロジェクトを意図的に共有することは決してないと知っていても、セキュリティインシデントは意図しない関係者にデータを漏洩させる可能性があるため、現在の値を積極的に変更することが最善です。

侵害された認証情報をすべての場合にローテーションする必要がありますが、漏えいした認証情報またはファイルをVCS履歴から完全に削除することもできます。 これは、意図せずにコミットされたユーザーデータなど、変更できない機密データにとって特に重要です。 リポジトリからデータを削除するには、VCS履歴を書き換えて、以前のコミットからファイルを削除する必要があります。 これはusing native git commands or with the help of some dedicated toolsで実行できます。 リポジトリ内のデータのすべてのレコードを削除しても、以前にコードベースをコピーしたことがある人は、依然として機密資料にアクセスできる可能性があることに注意することが重要です。 影響の範囲を評価するときは、このことに留意してください。

シークレットが侵害された疑いがある場合は、それらのプログラムまたはサービスに関連するログデータを確認して、異常なアクセスまたは動作があったかどうかを判断することをお勧めします。 これは、通常は管理していないアドレスから送信される内部ネットワーク内で発生する異常なアクティビティやリクエストの形をとることがあります。 この調査は、インフラストラクチャとデータを保護するための適切な次の手順を決定するのに役立ちます。

機密データを含むファイルをリポジトリに残さない最も基本的な方法は、VCSの無視機能を最初から活用することです。 VCSの「無視」ファイル（.gitignoreなど）は、リポジトリから除外する必要のあるパターン、ディレクトリ、またはファイルを定義します。 これらは、誤ってデータを公開することに対する優れた防御の第一線です。 この戦略は、外部ツールに依存せず、除外アイテムのリストが共同編集者用に自動的に構成され、セットアップが簡単であるため便利です。

VCSの無視機能はベースラインとして役立ちますが、無視定義を最新に保つことに依存しています。 ignoreファイルを更新または実装する前に、機密データを誤ってコミットするのは簡単です。 パターンを無視するのはファイルレベルの粒度のみであるため、コミットする必要のあるコードやその他のデータに秘密が混ざっている場合は、プロジェクトの一部をリファクタリングする必要があります。

最新のVCS実装のほとんどには、リポジトリ内で特定のアクションが実行される前または後にスクリプトを実行するための「フック」と呼ばれるシステムが含まれています。 この機能を使用して、機密資料の保留中の変更の内容を確認するスクリプトを実行できます。 前述のgit-secretsツールには、評価するコンテンツのタイプの自動チェックを実装するpre-commitフックをインストールする機能があります。 独自のcustom scriptsを追加して、防御したいパターンを確認できます。

リポジトリフックは、コミット時に機密データを検索して保護するための、はるかに柔軟なメカニズムを提供します。 この柔軟性の向上には、実装するすべての動作をスクリプト化するという犠牲が伴います。これは、確認するデータの種類によっては困難なプロセスになる可能性があります。 追加の考慮事項は、フックは他の開発者がコピーするリポジトリの一部ではないため、ファイルを無視するほど簡単には共有されないことです。 各貢献者は、自分のマシンにフックを設定する必要があります。これにより、施行がより困難な問題になります。

スコープはよりローカライズされていますが、コミットをより意識させるのに役立つ単純な戦略の1つは、名前でVCSステージング領域に明示的にアイテムを追加することです。 ワイルドカードまたは展開によってファイルを追加すると時間を節約できますが、追加する各ファイルについて意図的に設定することで、誤って追加されることを防ぐことができます。 これの有益な副作用は、通常、より集中的で一貫性のあるコミットを作成できることです。これは、共同作業の他の多くの側面に役立ちます。

リポジトリの部分的な暗号化を簡素化するさまざまなソフトウェアがいくつかあります。 ほとんどは同じ基本原則で機能しますが、それぞれが独自の実装を提供し、プロジェクトのニーズに応じていくつかの魅力的な利点を提供できます。

git-secretと呼ばれるプロジェクト（前述のgit-secretsツールと混同しないでください）は、信頼できる共同作業者のGPGキーを使用して秘密ファイルの内容を暗号化できます。 git-secretユーザーは、既存の信頼のWebを活用することで、各アイテムを復号化できるユーザーを指定することで、ファイルへのアクセスを管理できます。 ユーザーが公開鍵を鍵サーバーに公開している場合、鍵を直接要求することなく、暗号化されたコンテンツへのアクセスを提供できます。

git-cryptツールはgit-secretと同様に機能し、リポジトリの一部を暗号化してコミットし、GPGキーを使用して他の寄稿者へのアクセスを規制できます。 チームがGPGを使用していない場合、またはその管理パターンがユースケースに対して複雑すぎる場合は、git-cryptプロジェクトで対称鍵暗号化を使用することもできます。 さらに、git-cryptは、コミット時に自動的に暗号化され、gitフィルターおよびdiff属性を使用してクローンで復号化されるため、管理が簡素化されます。

BlackBox projectは、コンテンツを共同で暗号化するためにGPGに依存するさらに別のソリューションです。 以前のツールとは異なり、BlackBoxはさまざまなバージョン管理システムで動作するため、さまざまなプロジェクトで使用できます。 もともとはPuppetエコシステム用のツールとして設計されていましたが、よりオープンなプラグインベースのシステムをサポートするためにリファクタリングされました。 BlackBoxは、個々のファイルを自由に暗号化および復号化できますが、ファイルを復号化してエディターを開き、保存時に再暗号化するテキストエディターを透過的に呼び出すメカニズムも提供します。

上記の一般的なソリューションのほかに、特定のタイプのリポジトリで動作するように構築されたソリューションもあります。 たとえば、バージョン5.1以降、Ruby on Railsプロジェクトでは、リポジトリの外部にマスターキーを設定するシステムを使用してencrypted secrets within the repositoryを含めることができます。

秘密データを暗号化してリポジトリにコミットすると、資格情報を最新の状態に保ち、コードが使用する方法と同期させることができます。 これにより、機密データ形式またはラベル付けの変更と、コードがそれを使用またはアクセスする方法との間のドリフトを回避できます。 外部リソースを参照せずにコードベースを変更できます。

さらに、コードに秘密を保持することで、展開を大幅に簡素化できます。 複数の場所から情報を引き出して完全に機能するシステムを取得するのではなく、情報はすべて単一のユニットにパッケージ化され、一部のコンポーネントは復号化を必要とします。 これは、外部の秘密ストアをサポートするためのインフラストラクチャがセットアップされていない場合、またはプロジェクトの展開に必要な調整の量を最小限にしたい場合に非常に役立ちます。

ツールを使用してリポジトリ内の機密情報を暗号化することの全体的な利点は、追加のインフラストラクチャや計画なしで暗号化を簡単に実装できることです。 ユーザーは、シークレットをプレーンテキストデータとして保存することから、数分で安全な暗号化されたシステムに移行できます。 単一の開発者または小規模で静的なチームを含むプロジェクトの場合、これらのツールは、複雑さを大幅に増やすことなく、すべての秘密管理要件を満たす可能性があります。

他のソリューションと同様に、このスタイルの秘密管理にはいくつかのトレードオフがあります。

基本的に、秘密は構成データであり、コードではありません。 さまざまな環境にデプロイされたコードは同じである可能性が高いですが、構成はかなり異なる可能性があります。 リポジトリ内のコードで秘密を保持することにより、異なる環境間で構成を維持することがより難しくなり、セキュリティに悪影響を及ぼす方法で資格情報の再利用が促進されます。

同様に、リポジトリ内の暗号化されたシークレットへのきめ細かいマルチレベルアクセスを構成することは、多くの場合困難です。 必要なアクセス制御のレベルは、特に大規模なチームやプロジェクトの場合、VCSで秘密を暗号化するために使用されるツールで簡単にモデル化されるレベルよりもはるかに複雑になることがよくあります。 プロジェクトから協力者を追加したり、貢献者をプロジェクトから削除したりするには、リポジトリ内の機密データですべてのファイルを再暗号化します。 これらのユーティリティを使用すると、通常、ファイルの保護に使用される暗号化を簡単に変更できますが、これらの状況では、これらのファイル内のシークレットをalsoローテーションする必要があります。

しばしば見落とされがちな重要な点は、データを復号化するために使用されるキーが、暗号化されたコンテンツとともに保存されることが多いということです。 開発者のラップトップには、多くの場合、機密データを復号化できるGPGキーが存在し、それ以上入力しなくても使用できます。 GPGパスフレーズを使用してこれを多少軽減できますが、大規模なチームに適用するのは困難です。 チームメンバーのラップトップが危険にさらされた場合、プロジェクト内の最も機密性の高いデータへのアクセスは、プレーンテキストであるかのようにアクセスできる可能性があります。

一般に、リポジトリ内の秘密を長期間にわたって保護することは困難です。 コード変更のロールバックなどの単純な操作は、以前に削除されたアクセスを誤って再導入する可能性があります。 秘密鍵が公開された場合、履歴値はリポジトリの履歴から復元および復号化できます。 VCS履歴は暗号化の変更のログを提供しますが、通常とは異なるアクセスを判断するのに役立つシークレットアクセスを監査する方法はありません。

Chef encrypted data bagsとchef-vaultは、Chefが管理するインフラストラクチャに統合された秘密管理機能を提供します。 暗号化されたデータバッグは、変更履歴や共有シークレットを使用する他のマシンに機密値が表示されないようにするために使用されます。 Chef-vaultでは、代わりにターゲットマシンの公開鍵を使用してシークレットを暗号化できます。これにより、復号化機能を目的の受信者に分離するさらなるセキュリティが提供されます。

同様に、Puppet’s Hiera Key-ValueストレージシステムをHiera eyamlとともに使用して、特定のインフラストラクチャコンポーネントのシークレットを安全に管理できます。 他のシステムとは異なり、Hiera eyamlは、Hieraが使用するデータシリアル化形式であるYAMLの構文と構造を認識しており、ファイル全体ではなく機密値のみを暗号化できます。 これにより、ほとんどのタスクで通常のツールを使用して、暗号化されたデータを含むファイルを操作できます。 バックエンドはプラグイン可能なため、チームはGPG暗号化を実装してアクセスを簡単に管理できます。

Saltstackは、Pillarsを使用して、特定のマシン用に指定されたデータを格納します。 これらのアイテムを保護するために、ユーザーはGPGを使用してYAML値を暗号化し、実行時にSaltが値を復号化できるようにGPG rendererを構成できます。 Hiera eyamlのように、このシステムは完全なファイルではなく機密データのみを暗号化し、通常のファイル編集ツールとdiffツールが正しく動作するようにします。

Ansibleには、Playbook構造内の機密性の高いYAMLファイルを暗号化するための暗号化システムおよびコマンドラインツールであるAnsible Vaultが含まれています。 Ansibleは、実行時にシークレットファイルを透過的に解読して、特定のタスクを実行するために必要なシークレットデータと非シークレットデータを結合できます。 Ansible vaultは値ではなくファイル全体を暗号化するため、編集には復号化が必要で、diffツールは正確な変更情報を表示できません。 ただし、Ansible 2.3以降、single variables can be encrypted in variable filesにより、ユーザーは機密値を暗号化する方法を選択できます。

これらのソリューションは、構成管理コンテキストでの秘密の管理に伴ういくつかの課題に適しています。 既存のインフラストラクチャインベントリシステムと、各マシンが必要とするアクセスのタイプを定義する役割指定を活用することで、シークレットへのアクセスを調整できます。 各マシンが正しい構成を取得することを保証する同じメカニズムにより、シークレットはそれらを必要とするホストにのみ配信されることが保証されます。

既存のインフラストラクチャ管理および展開システムに固有のツールを使用すると、暗号化を実装する運用コストが最小限に抑えられます。 環境固有のツールを使用すると、シークレットを暗号化に移行するのが簡単になり、追加の手順なしでシークレットの実行時復号化を組み込むのが簡単になります。 すでに構成管理システムを使用している場合、含まれる秘密管理メカニズムを使用することが、おそらく機密データを保護するための最も簡単な最初のステップになります。

緊密な統合は、ユーザーが既存のシステムを使用して秘密を管理できることを意味しますが、これらのソリューションはそれぞれの構成管理ツールにロックされていることを意味します。 他のコンテキストでこれらの戦略のほとんどを使用することは困難または不可能です。つまり、構成管理ツール自体への依存関係を追加することになります。 単一プラットフォームへの緊密な統合は、データへのアクセスを必要とする外部システムにとっても問題になる可能性があります。 外部APIまたは呼び出し可能なコマンドがない場合、構成管理システムを介してアクセスしない限り、シークレットを効果的に「トラップ」できます。

暗号化されたシークレットをアプリケーションリポジトリに保存することの欠点の多くは、構成管理システムでシークレットを保存する場合にも当てはまります。 アプリケーションリポジトリを備えたラップトップを侵害の媒介にする代わりに、構成管理リポジトリを備えたラップトップまたはコンピュータも同様に脆弱になります。 基本的に、暗号化された値と復号化キーの両方を持つシステムは、このタイプの侵害に対して脆弱です。

関連する懸念は、構成管理システムは正しいマシンのみが秘密にアクセスできるようにすることですが、チームメンバーを制限するためのきめの細かいアクセス制御を定義することは、しばしば困難です。 一部のシステムは、単一のパスワードまたはキーでのみ暗号化できるため、チームメンバーの秘密へのアクセスを分割する機能が制限されます。

HashiCorp’s Vaultのような専用の秘密管理サービスは、使いやすさを犠牲にすることなく機密資料を保護するための優れた柔軟性と強力な機能を提供します。 Vaultは、保存中および転送中のデータを保護し、さまざまな「バックエンド」を使用してさまざまな機能を公開し、暗号化、ストレージ、認証の複雑さを管理するように設計されています。 いくつかの主要な機能には、動的なシークレット（オンザフライで接続されたサービスの短期資格情報）を構成する機能、サービスとしてのデータ暗号化（外部サービスからのデータの暗号化と保存、および要求された場合の復号化されたコンテンツの再提供）が含まれます（許可された当事者）、およびリースベースの秘密管理（一定期間アクセスを提供し、その後アクセスが自動的に取り消される）。 Vaultのプラグ可能なアーキテクチャとは、ストレージバックエンド、認証メカニズムなどを意味します。 ビジネスニーズの変化に応じてすべて交換可能です。

SquareのKeywhizシークレット管理システムは、機密データの一般的なセキュリティを提供するために使用されるもう1つの専用サービスです。 Vaultと同様に、Keywhizはクライアントとユーザーがシークレットの保存とアクセスに使用できるAPIを公開しています。 Keywhizが提供するユニークな機能の1つは、FUSEファイルシステムを使用して秘密を公開する機能です。FUSEファイルシステムは、クライアントがマウントできる仮想ファイルシステムであり、機密ファイルに擬似ファイルとしてアクセスできます。 このメカニズムにより、さまざまな種類のプログラムが、エージェントやラッパーの助けを借りずに必要なデータにアクセスでき、管理者は通常のUnixファイルシステムのアクセス許可を使用してアクセスをロックダウンできます。

PinterestのKnoxは、秘密を管理するためのもう1つのサービスです。 VaultおよびKeywhizと同じ機能の多くを提供します。 他のシステムにはない機能の1つは、キーバージョンの明示的な状態を提供することにより、時間の経過とともにキーを回転させる機能です。 キーバージョンは、現在の優先シークレットであることを示すためにプライマリとしてマークでき、バージョンがまだ使用できることを示すためにアクティブであるか、バージョンを無効にするために非アクティブであることができます。 このシステムにより、管理者はサービスを中断することなく、時間の経過とともにマシン群全体でキーをロールできます。

専用の秘密管理サービスには、他のシステムよりも多くの魅力的な利点があります。 機密データの保護と管理の複雑さをスタンドアロンシステムに任せることで、アプリケーションおよび構成管理リポジトリ内でこれらの懸念に対処する必要がなくなります。 この責任の分離は、秘密ストレージを集中化し、厳密に制御されたインターフェースを介してアクセスを管理することにより、運用セキュリティモデルを簡素化します。 システムと対話するための汎用インターフェースを提供することにより、使用されている構成管理システムまたはVCSに関係なく、許可されたユーザーまたはクライアントはシークレットにアクセスできます。

管理の観点から、シークレット管理システムは、他のツールでは利用できない多くのユニークな機能を提供します。 暗号化キーの簡単なローテーションと、それらが保護する基礎となる秘密は、多くの異なる機密値を調整する必要がある大規模な展開や複雑なシステムに非常に役立ちます。 コードをデプロイしたり、フリート全体に変更を加えたりすることなく、アクセスを簡単に規制および取り消しできます。 ダイナミックシークレットなどの機能により、シークレット管理サーバーはデータベースなどの外部サービスにアクセスして、オンデマンドで使用ごとの資格情報を作成できます。 シークレットへの短期リースベースのアクセスは、明示的な失効を必要とせずにアクセスを制限または期限切れにする自動メカニズムとして機能します。

一元化された秘密管理が提供する最も重要な改善点の1つは、監査可能性です。 上記の各システムは、秘密が追加、要求、アクセス、または変更されたときの広範な記録を保持しています。 これは、異常を見つけて疑わしい動作を検出するのに役立ち、また、侵害が発生した場合のアクセスの範囲を評価するのにも役立ちます。 組織の機密データの全体的なビュー、アクセスを制御するように設定されたポリシー、および成功または試行されたすべての変更または取得に関する情報により、チームはインフラストラクチャセキュリティに関する十分な情報に基づいた意思決定を行うことができます。

一元化された秘密管理システムの主な欠点は、インフラストラクチャと管理の両方の面で必要な追加のオーバーヘッドです。

集中システムをセットアップするには、実稼働環境に展開する前に、十分な計画、テスト、および調整が必要です。 インフラストラクチャが稼働したら、クライアントを更新してシークレット管理サーバーのAPIを照会するか、それを必要とするプロセスに代わってシークレットを取得するようにエージェントプロセスを設定する必要があります。 どのアプリケーション、インフラストラクチャ、およびチームメンバーが保護された各値にアクセスする必要があるかを決定するポリシーを確立する必要があります。

保護するデータの価値により、シークレット管理サーバーは管理する最も重要なセキュリティ環境の1つになります。 集中化により、保護する必要のある表面積が最小限に抑えられますが、システム自体が悪意のある攻撃者にとって価値の高い標的になります。 多くのソリューションには、ロックダウンモード、キーベースの再起動、監査ログなどの機能が含まれていますが、アクティブな復号化されたシークレットストアへの不正アクセスには、大規模な修復が必要です。

構成とセキュリティ要素の初期コストを超えて、単一のサービスからすべての機密データを提供すると、インフラストラクチャに追加のミッションクリティカルなコンポーネントが導入されます。 多くの場合、新しいアプリケーションのブートストラップや定期的な操作にはシークレットが必要であるため、シークレット管理のダウンタイムにより、サービスが復元できるまで解決できない重大な中断が発生する可能性があります。 可用性は、非常に多くの異なるコンポーネント間の調整を担当するシステムにとって重要です。