序章

バージョン管理ソフトウェア(VCS)は、最新のソフトウェア開発手法の重要な部分です。 他の利点の中でも、Git、Mercurial、Bazaar、Perforce、CVS、Subversionなどのソフトウェアを使用すると、開発者はプロジェクト履歴のスナップショットを保存して、コラボレーションを改善し、以前の状態に戻して意図しないコード変更から回復し、同じバージョンの複数のバージョンを管理できます。コードベース。 これらのツールを使用すると、複数の開発者が同じプロジェクトで安全に作業でき、他の人と作業を共有する予定がない場合でも、大きなメリットが得られます。

コードをソース管理に保存することは重要ですが、一部のプロジェクトアセットをリポジトリから除外することも同様に重要です。 バイナリブロブや構成ファイルなどの特定のデータは、パフォーマンスと使いやすさの理由から、ソース管理から除外するのが最適です。 ただし、さらに重要なのは、セキュリティ上の理由から、パスワード、シークレット、秘密鍵などの機密データを保護されていないリポジトリにチェックインしないことです。

このガイドでは、最初に、リポジトリにすでにコミットされている機密データをチェックする方法について説明し、資料が見つかった場合にいくつかの軽減戦略を紹介します。 その後、リポジトリへのシークレットの追加を防ぐためのいくつかのツールとテクニック、コミットする前に機密データを暗号化する方法、および安全なシークレットストレージの代替方法について説明します。

機密データについてGitリポジトリを確認する

機密データを管理するシステムを設定する前に、プロジェクトファイルに秘密の資料がすでに存在するかどうかを確認することをお勧めします。

プロジェクトをスキャンする

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

  1. git grep my_secret $(git rev-list --all)

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

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

緩和オプション

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

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

侵害されたクレデンシャルはすべての場合にローテーションする必要がありますが、漏洩したクレデンシャルまたはファイルをVCS履歴から完全に削除することもできます。 これは、意図せずにコミットされたユーザーデータなど、変更できない機密データにとって特に重要です。 リポジトリからデータを削除するには、VCS履歴を書き換えて、以前のコミットからファイルを削除する必要があります。 これは、ネイティブのgitコマンドを使用するか、いくつかの専用ツールを使用して実行できます。 リポジトリ内のデータのすべてのレコードを削除した場合でも、以前にコードベースをコピーしたことがある人は、機密資料にアクセスできる可能性があることに注意してください。 影響の程度を評価するときは、このことに注意してください。

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

秘密のコミットを回避するためのVCS機能の使用

外部ツールを検討する前に、VCSツールに固有の機能のいくつかを理解して、不要なデータがリポジトリにコミットされるのを防ぐことをお勧めします。

機密ファイルを無視する

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

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

コミットする前にVCSフックを使用してファイルをチェックする

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

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

ステージング領域へのファイルの明示的な追加

スコープはよりローカライズされていますが、コミットをより意識するのに役立つ可能性のある1つの簡単な戦略は、名前で明示的にアイテムをVCSステージング領域に追加することだけです。 ワイルドカードまたは拡張によってファイルを追加すると時間を節約できますが、追加する各ファイルを意図的に指定することで、他の方法で含まれる可能性のある偶発的な追加を防ぐことができます。 これの有益な副作用は、一般的に、より焦点を絞った一貫性のあるコミットを作成できることです。これは、共同作業の他の多くの側面に役立ちます。

暗号化されたシークレットをリポジトリに保存する

多くの場合、機密データをコードリポジトリから完全に削除することをお勧めしますが、他の特権ユーザーがアクセスできるように、リポジトリ内に機密データを含めることが必要または役立つ場合があります。 そのために、さまざまなツールを使用して、リポジトリ内の機密ファイルを暗号化しながら、ファイルの大部分に誰もがアクセスできるようにします。

実装

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

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

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

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

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

利点

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

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

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

短所

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

基本的に、シークレットは構成データであり、コードではありません。 さまざまな環境にデプロイされたコードは同じである可能性がありますが、構成はかなり異なる可能性があります。 リポジトリ内のコードに秘密を保持することにより、異なる環境間で構成を維持することがより困難になり、セキュリティに悪影響を与える方法でクレデンシャルの再利用を促進します。

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

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

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

シークレット管理のための構成管理システムの使用

より集中化されたシークレット管理に関する多くのユーザーの最初の経験は、構成管理ツールを使用することです。 これらのツールは、一元化された場所から多くの異なるマシンの構成を調整する役割を果たしているため、ノードが必要な値にのみアクセスできるようにするには、ある程度の秘密管理が必要です。

実装

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

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

Saltstackは、 Pillars を使用して、特定のマシン用に指定されたデータを保存します。 これらのアイテムを保護するために、ユーザーはGPGを使用してYAML値を暗号化し、GPGレンダラーを構成してSaltが実行時に値を復号化できるようにすることができます。 Hiera eyamlと同様に、このシステムでは、ファイル全体ではなく機密データのみを暗号化する必要があり、通常のファイル編集および差分ツールが正しく動作できるようになります。

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

利点

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

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

短所

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

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

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

外部シークレット管理サービスの使用

暗号化されたシークレットをコードと一緒に、または構成管理システムに保存する代わりに、専用サービスを使用してインフラストラクチャの機密データを管理することもできます。 これらのサービスは、機密データを暗号化して保存し、復号化された値を使用して許可された要求に応答します。 これにより、開発者は機密資料をリポジトリから移動して、人間のユーザーとアプリケーションの両方の暗号化、承認、認証を調整するように設計されたシステムに移動できます。

実装

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

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

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

利点

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

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

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

短所

一元化されたシークレット管理システムの主な欠点は、インフラストラクチャと管理の両方の観点から、追加のオーバーヘッドが必要になることです。

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

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

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

まとめ

機密データを保護し、展開中に必要なアクセスを調整するさまざまな方法を評価するときは、セキュリティ、使いやすさ、およびプロジェクトのニーズの間のバランスを考慮することが重要です。 上記のソリューションは幅広いユースケースにまたがり、さまざまな程度のスケーラビリティと保護を提供します。

プロジェクトまたは組織に最適な選択は、保護する必要のある機密データの量、チームの規模、およびさまざまなソリューションを管理するために利用できるリソースによって異なる可能性があります。 ほとんどの場合、小規模から始めて、状況の変化に応じて秘密の管理ニーズを再評価することは理にかなっています。 現在、いくつかの秘密を保護し、小さなチームと協力する必要があるだけかもしれませんが、将来的には、専用ソリューションのトレードオフがより説得力のあるものになる可能性があります。