「アーキテクチャ」

Vault は、多くの異なる部分を持つ複雑なシステムです。 Vault のユーザーと開発者の両方が、Vault がどのように動作するかのメンタル モデルを構築できるように、このページでは、システム アーキテクチャを説明します。 このページでは、Vault の技術的な詳細について説明します。 Vault を効果的に使用するために、これらの詳細を理解する必要はありません。 詳細は、ソース コードをゴスペルすることなく、それらについて学びたい人のためにここに文書化されています。

アーキテクチャを説明する前に、何を議論しているかを明確にするために、用語集を提供します：

• Storage Backend – Storage Backend は、暗号化データの耐久性のあるストレージに責任を負います。 バックエンドは、Vaultによって信頼されておらず、耐久性を提供することだけが期待されています。

• バリア – バリアは、Vaultの周囲の暗号化された鋼鉄とコンクリートです。 Vault とストレージ バックエンドの間を流れるすべてのデータは、バリアーを通過します。 バリアは、暗号化されたデータのみが書き出され、データが検証され、入るときに復号化されることを保証します。 銀行金庫のように、バリアは中のものにアクセスする前に「開封」されなければなりません。

• Secrets Engine – Secret Engine は秘密を管理する責任を負います。 いくつかのsecretsエンジンは、クエリされるたびに動的に秘密を生成するポリシーの使用をサポートしています。 これにより、ユニークな秘密を使用することができ、Vaultはきめ細かな取り消しやポリシーの更新を行うことができます。 例として、MySQLのシークレットエンジンに “web “ポリシーを設定することができます。 Web” シークレットが読み込まれると、新しい MySQL ユーザー/パスワード ペアが、Web サーバーの限定された特権セットで生成されます。

• Audit Device – 監査デバイスは、監査ログの管理を担当します。 これは、異なるタイプの複数の監査ロギング先とVaultを統合する簡単な方法を提供します。

• Auth Method – Authメソッドは、Vaultに接続しているユーザーまたはアプリケーションを認証するために使用されます。 認証されると、auth メソッドは、適用されるべき適用可能なポリシーのリストを返します。 Vault は、認証されたユーザーを受け取り、今後のリクエストに使用できるクライアント トークンを返します。 例として、userpass auth メソッドは、ユーザ名とパスワードを使用してユーザを認証します。

• Client Token – クライアント トークン (別名 “Vault Token”) は、Web サイト上のセッション クッキーに概念的に似ています。 ユーザーが認証されると、Vaultは、今後のリクエストに使用されるクライアント トークンを返します。 このトークンは、Vaultがクライアントの身元を確認し、適用されるACLpoliciesを実施するために使用されます。

• Secret – シークレットとは、Vaultが返すもののうち、機密または暗号の材料を含むもののことを指します。 例えば、システム構成、ステータス情報、またはポリシーは秘密とみなされません。 これは、クライアントが秘密の内容を無期限に使用できると仮定できないことを意味します。 Vaultはリースが終了した時点で秘密を破棄します。また、操作者が介入して、リースが終了する前に秘密を破棄することもできます。 Vault とそのクライアントの間のこの契約は、手動で介入することなく、キーとポリシーの変更を可能にするため、重要です。

• Server – Vault は、サーバーとして動作する長時間実行インスタンスに依存します。 Vault サーバーは、クライアントが対話する API を提供し、すべての秘密エンジン間の対話、ACL の実施、および秘密リースの失効を管理します。 サーバー ベースのアーキテクチャを持つことで、クライアントとセキュリティ キーおよびポリシーが切り離され、集中型監査ロギングが可能になり、オペレータの管理が簡素化されます。

「ハイレベルな概要」

Vault の非常に高いレベルの概要は、次のようになります。 セキュリティ バリアの内側または外側にあるコンポーネントは、明確に分離されています。 ストレージ バックエンドと HTTP API だけが外部にあり、他のすべてのコンポーネントはバリアの内部にあります。

ストレージ バックエンドは信頼されず、暗号化されたデータを永続的に保存するために使用されます。 HTTP API も同様に、クライアントがそれと対話できるように、起動時に Vault サーバーによって開始される必要があります。 任意の操作が Vault で実行される前に、それは密封を解除する必要があります。 これは unsealkeys を提供することによって行われます。 Vaultが初期化されるとき、それはすべてのデータを保護するために使用される暗号化キーを生成します。 この鍵は、マスターキーによって保護されています。 デフォルトでは、Vault は Shamir の秘密分散アルゴリズムとして知られる技術を使用して、マスター キーを 5 つの共有に分割し、そのうちの任意の 3 つはマスターキーを再構築するために必要とされます。 Vaultが暗号化キーを取得すると、ストレージバックエンド内のデータを復号化することができ、非密封状態になります。

これらの監査デバイス、認証方法、および秘密エンジンの構成は、セキュリティ機密であるため、Vaultに格納する必要があります。 正しい権限を持つユーザーのみがそれらを変更できるはずで、バリアの外側でそれらを指定することはできません。 Vault に格納することにより、それらへの変更は ACL システムで保護され、監査ログで追跡されます。

Vault が封印解除されると、要求は HTTP API から TheCore に処理されます。 コアは、システムを介した要求の流れを管理し、ACL を実施し、監査ログが行われることを確認するために使用されます。

クライアントが最初に Vault に接続すると、認証する必要があります。 Vault は、設定可能な認証方法を提供し、使用される認証メカニズムに柔軟性を与えます。 ユーザー名/パスワードやGitHubのような人に優しいメカニズムがオペレータに使用されるかもしれませんし、アプリケーションが認証するために公開鍵/秘密鍵やトークンを使用するかもしれません。 認証要求は core を経て authmethod に流れ、authmethod は要求が有効かどうかを判断し、関連するポリシーのリストを返します。 たとえば、”root” ポリシーは組み込みで、すべてのリソースへのアクセスを許可します。 名前付きポリシーはいくつでも作成でき、パスを細かく制御することができます。 Vaultは、ホワイトリストモードでのみ動作します。つまり、ポリシーによって明示的にアクセスが許可されない限り、そのアクションは許可されません。 ユーザは複数のポリシーを関連付けることができるため、いずれかのポリシーで許可されていれば、そのアクションは許可されます。 ポリシーは、内部ポリシーストアによって保存および管理されます。 この内部ストアは、常に sys/ にマウントされているシステム バックエンドを介して操作されます。

認証が行われ、認証メソッドが適用可能なポリシーのセットを提供すると、新しいクライアント トークンが生成され、トークン ストアが管理します。 このクライアントトークンはクライアントに返送され、今後のリクエストに使用されます。これは、ユーザーがログインした後にウェブサイトから送信されるクッキーに似ています。 クライアントトークンは、認証方法の設定によってリースを持つことがあります。

一度認証されると、リクエストはクライアントトークンを提供して行われます。 トークンは、クライアントが認証されていることを確認し、関連するポリシーをロードするために使用されます。 ポリシーはクライアントリクエストを承認するために使用されます。 リクエストはsecretsエンジンに送られ、そのタイプに応じて処理される。 secretsengineが秘密を返した場合、コアはそれをexpiration managerに登録し、リースIDを付けます。 リースIDはクライアントが秘密を更新したり取り消したりするのに使われる。

コアは監査ブローカーへのリクエストとレスポンスのロギングを処理し、構成されたすべての監査デバイスにリクエストを送出します。 リクエストフロー以外では、コアは特定のバックグラウンドアクティビティを実行します。 リース管理は、期限切れのクライアントトークンまたはシークレットを自動的に取り消すことができるため、非常に重要です。 さらに、Vaultは、ロールバックマネージャを備えた書き込み先行のロギングを使用することで、特定の部分的な障害ケースを処理する。 これは、コア内で透過的に管理され、ユーザーには見えません。

“詳しく見る

これは、Vault のアーキテクチャの簡単な高レベルの概要でした。 その他の詳細については、コードを参照するか、IRC で質問するか、メーリングリストに連絡してください。