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

前書き

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

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

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

Gitリポジトリで機密データを確認する

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

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

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

git grep  $(git rev-list --all)

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

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

軽減オプション

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

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

侵害された認証情報をすべての場合にローテーションする必要がありますが、漏えいした認証情報またはファイルをVCS履歴から完全に削除することもできます。 これは、意図せずにコミットされたユーザーデータなど、変更できない機密データにとって特に重要です。 リポジトリからデータを削除するには、VCS履歴を書き換えて、以前のコミットからファイルを削除する必要があります。 これはhttps://help.github.com/articles/removing-sensitive-data-from-a-repository/ [ネイティブの `+ git +`コマンドを使用するか、いくつかの専用ツールを使用して]で実行できます。 リポジトリ内のデータのすべてのレコードを削除しても、以前にコードベースをコピーしたことがある人は、依然として機密資料にアクセスできる可能性があることに注意することが重要です。 影響の範囲を評価するときは、このことに留意してください。

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

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

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

機密ファイルを無視する

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

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

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

最新のVCS実装のほとんどには、リポジトリ内で特定のアクションが実行される前または後にスクリプトを実行するための「フック」と呼ばれるシステムが含まれています。 この機能を使用して、機密資料の保留中の変更の内容を確認するスクリプトを実行できます。 前述のhttps://github.com/awslabs/git-secrets[git-secrets]ツールには、評価するコンテンツのタイプの自動チェックを実装する `+ pre-commit +`フックをインストールする機能があります。 独自のhttps://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks [カスタムスクリプト]を追加して、パターンを確認できますから守りたい。

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

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

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

暗号化された秘密をリポジトリに保存する

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

実装

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

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

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

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

上記の一般的なソリューションのほかに、特定のタイプのリポジトリで動作するように構築されたソリューションもあります。 たとえば、バージョン5.1以降では、Ruby on Railsプロジェクトは、倉庫。

利点

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

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

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

デメリット

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

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

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

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

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

秘密管理のための構成管理システムの使用

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

実装

https://docs.chef.io/data_bags.html#encrypt-a-data-bag-item [シェフ暗号化データバッグ]およびhttps://docs.chef.io/chef_vault.html[chef-vault]はいくつか提供しますChefが管理するインフラストラクチャの統合された秘密管理機能。 暗号化されたデータバッグは、変更履歴や共有シークレットを使用する他のマシンに機密値が表示されないようにするために使用されます。 Chef-vaultでは、代わりにターゲットマシンの公開鍵を使用してシークレットを暗号化できます。これにより、復号化機能を目的の受信者に分離するさらなるセキュリティが提供されます。

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

Saltstackはhttps://docs.saltstack.com/en/latest/topics/pillar/[Pillars]を使用して、特定のマシンに指定されたデータを保存します。 これらのアイテムを保護するために、ユーザーはGPGを使用してYAML値を暗号化し、https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.gpg.html [GPGレンダラー]を設定して、実行時に値を復号化するソルト。 Hiera eyamlと同様に、このシステムでは、ファイル全体ではなく機密データのみを暗号化するため、通常のファイル編集ツールとdiffツールが正しく動作します。

Ansibleには、http://docs.ansible.com/ansible/latest/playbooks_vault.html [Ansible Vault]、暗号化システム、およびプレイブック構造内の機密YAMLファイルを暗号化するコマンドラインツールが含まれています。 Ansibleは、実行時にシークレットファイルを透過的に解読して、特定のタスクを実行するために必要なシークレットデータと非シークレットデータを結合できます。 Ansible vaultは値ではなくファイル全体を暗号化するため、編集には復号化が必要で、diffツールは正確な変更情報を表示できません。 ただし、Ansible 2.3の時点では、http://docs.ansible.com/ansible/latest/playbooks_vault.html#single-encrypted-variable [変数ファイルで単一変数を暗号化できる]を使用して、ユーザーが希望する方法を選択できます。機密値を暗号化します。

利点

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

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

デメリット

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

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

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

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

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

実装

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

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

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

利点

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

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

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

デメリット

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

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

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

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

まとめ

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

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

前の投稿:Ubuntu 16.04にMosquitto MQTT Messaging Brokerをインストールして保護する方法
次の投稿:Doctlを使用してDigitalOceanブロックストレージを操作する方法