メインコンテンツまでスキップ

Vaultのアーキテクチャを理解する為に、公式サイトのArchitectureを読んだ結果をまとめる。（拙い和訳に近い）

Glossary

用語の定義は、現在は公式ドキュメントのGlossaryにまとまっている。

Storage Backend​

  • Storage Backendは、暗号化されたデータの恒久的な保存に責務を持つ。
  • バックエンドは信頼されず、耐久性を求められる。
  • ストレージバックエンドは、Vault serverを開始したときに設定される。

Barrier​

  • Barrierは、Vaultの周りの、暗号化されたスチール＆コンクリートである。
  • VaultとStorageBackendの間を流れる全てのデータは、Barrierを経由する。
  • Barrierは、StorageBackendに書き出すデータを暗号化し、読み込んだデータを検証・復号化する。
    • つまり、StorageBackendに保存されるデータは、基本的に暗号化されたデータになる。（unsealに必要なseal設定など、一部の例外を除く）
  • 銀行の金庫室のように、内部のものにアクセスする際には、Barrierをunsealする必要がある。

Secrets Engine​

  • Secrets Engineは、機密情報を管理することに責務を持つ。
  • いくつかのSecrets Engineは、クエリを投げるたびに、動的に機密情報を生成することをサポートする。
  • ポリシーに対するきめ細かい失効と更新を実行することで、ユニークな機密情報を使用させることが出来る。
  • 例えば、Webサーバからのリクエストをもとに、読み取り専用のMySQLのユーザ・パスワードを一時的に発行し、期限が来たら無効化、みたいなことができる。

Audit Device​

  • Audit Deviceは、audit logsの管理に責務を持つ。
  • Vaultへの全てのリクエストとレスポンスは、Audit Deviceを経由する。
  • これにより、「Vault」と、「様々な種類の複数の監査ログ記録サービス」を統合する、シンプルな方法が提供される。

Auth Method​

  • Auth Methodは、ユーザ及びアプリケーションが、Vaultに対して接続する時の認証に使われる。
  • 一度認証されると、Auth Methodは（適用されるべき？）適用可能なポリシーのリストを返す
  • Vaultは認証されたユーザを引き受け、次のリクエストに使用するClient Tokenを返す
  • 例えば、userpassAuthMethodはユーザの認証にユーザ名とパスワードを使う
  • あるういは、github auth methodはGitHubを通じてユーザ認証をおこなう

Client Token​

  • Vault Tokenと呼ばれるClient Tokenは、概念的にはWebSiteにおけるsession cookieと類似している。
  • 一度ユーザ認証が行われると、Vaultは次のリクエストの為のClient Tokenを返す。
  • Client Tokenは、Vaultによって、クライアントを検証すること及び該当するACL Policiesを適用することに使われる。
  • Client Tokenは、HTTP headersを通して、クライアントに渡される。

Secret​

  • Secrettは、機密情報あるいは暗号化された構成要素を含む、Vaultによって返却されるあらゆるもののこと。
  • Vaultによって返される全てのものが"機密情報"ではない。例えば、システム構成情報、Statusの情報、ポリシーは、"機密情報"としては捉えられないだろう。
  • 動的シークレット（Dynamic Secret）は、常にリース期間を持つ。これは、クライアントは動的シークレットを永続的に使用できないことを意味する。静的シークレットはリース期間を持たない。
  • Vaultはリース期間が終わると、動的シークレットをRevokeする。

Server​

  • Vaultはサーバとして動作する長時間稼働するインスタンスに依存する。
  • Vault serverは、クライアントによる、Secret Engine、ACL、SecretのRevokeの管理及びやり取りをする為のAPIを提供する。
  • サーバベースのアーキテクチャを持つことで、クライアントとセキュリティキー・ポリシーを切り離し、監査ログの集中管理と、管理者のオペレーションの簡素化を実現する。

High-Level Overview

  • Storage BackendとHTTP/S APIだけがBarrierの外側のコンポーネントで、他にコンポーネントはBarrierの内側にある
  • Storage Backendは信頼されず、暗号化されたデータを堅牢に保存する為に使われる
    • Vault serverの起動時に、Storage Backend及びHTTP APIは提供される（データの永続化とクライアントがVault serverとやり取りするために）

Seal / Unseal​

  • Vault serverが起動されるとsealedというステータスになる
    • Key-Valueの値を取得することができないなど、この状態では基本何も出来ない。（Barrierによってプロテクトされている）
  • Vaultに対するあらゆるオペレーションを行う際には、Vaultはunsealedというステータスである必要がある。
    • これは、unseal keysを提供することによって行われる。
    • Vaultが初期される時に、encryption keyを生成する。（全てのデータを保護する為に使用される。Storage Backendで管理される）
    • このencryption keyは、root key（以前の名称はmaster key）によって更に暗号化されている。root keyもStorage Backendに保存されるが、unseal keyによって暗号化されている。
      • unseal keyでroot keyを、root keyでencryption keyを復号するので、データにアクセスする（Vaultをunsealed状態にする）為にはunseal keyが必要になる。
  • デフォルト設定（Shamir seal）だと、Vaultはunseal keyを分割している。
    • シャミアの秘密分散法
    • 共有数と必要な閾値の最小数は、両方指定することができる。
    • シャミアの秘密分散法は無効化することが出来て、unsealingにroot keyを直接使うことも可能。
    • Shamir sealの代わりに、クラウドのKMSやHSMを使ってauto unsealすることもできる。
  • 一度Vaultがencryption keyを受け取ったら、StorageBackend内のデータを復号化し、unseled状態になる。
  • 一度unsealed状態になると、VaultはAudit Device・Auth methods・Secrets Engineをロードする。

Storage Backend(store configulation)​

  • Audit Device、Auth Method、Secrets Engineの設定は、Vaultにて保管される。（セキュリティ的にsensitiveなため）
  • 正しく許可されたユーザのみ、これらの設定を変更する事ができる。（Barrierの外側では、設定を変更できない）
  • Vaultにこれらの設定を保管することにより、あらゆる変更はACLおよびaudit Logsによって保護・管理される。

Core​

  • Vaultがunsealed状態になった後、リクエストはHTTP APIからCoreまで処理することが出来る。
  • Coreは、システム間のリクエストフローをマネージしたり、ACLを適用したり、audit logsを保証したりするのに使われる。

Auth Method​

  • Vaultにクライアントが接続するときは、認証が必要である。
    • Hunam friendlyなユーザID/パスワードやGithubといったものだったり、アプリケーションにとってはおそらくpublic/privatekey,tokensが良いだろう。
  • 認証リクエストはコアからAuthMethodへと流れる。もしリクエストが有効なら、関連付けられているACL Policyを返す。

Policy Store(ACL Policy)​

  • ACL Policyは、単なる名前付きのアクセスコントロールのルールである。
    • 例えば、"root"policyは組み込みで全てのリソースへのアクセスを許可する。
    • パスを細かく制御して、任意の数の名前付きポリシーを作成することもできる。
  • Vaultはallowed-access mode（許可リスト方式）で動作する。これは、はっきりと認められたポリシーでない場合は、そのActionは許可されないことを意味する。
    • ユーザは複数のポリシーを関連付けられているだろうから、何らかのポリシーが許可していれば、Actionは許可される。
  • ポリシーはPolicy Storeにて保存及び管理される。常にsys/にマウントされているSystem Backendを通して操作される。

Token Store(Cluent Token)​

  • 一度認証が行われると、Auth Methodは、適用可能なポリシーを付与した新しいClient Tokenを生成し、Token Storeで管理する。
    • Client Tokenはリクエスト元のクライアントに送られ、次回以降のリクエストを生成する為に使用される。
    • これは、ユーザがログインした後に、Websiteから送られるCookieに似ている。
  • Auth Methodの設定によっては、Client Tokenはリース期間を持つ。
    • その場合、Client Tokenは無効化を避ける為に、定期的に更新する必要がある。

Secret Engine / Expiration Manager​

  • 一度認証が行われると、Client Tokenを用いてリクエストを生成する。
    • Client Tokenは、「クライアントが認可されたことを検証する」及び「関連のポリシーをロードする」ことに使用される。
    • ポリシーはクライアントのリクエストを認可する為に使用される。
  • その後、リクエストはSecret Engineにルーティングされ、Secret Engineの種類に応じて処理される。
  • もし、Secret EngineがSecretを返したら、Coreは、それにlease IDをアタッチして、Expiration Managerに登録する
  • lease IDは、Secretを更新/廃棄する為に使用される。
  • もしクライアントがリースの期限切れを許可した場合、Expirtation Managerは自動的にSecretを廃棄する。

Audit Broker / Audit Device​

  • CoreはAudit Brokerへのリクエスト/レスポンスのロギングを処理し、Audit Brokerにリクエストを送る。
  • Audit Brokerは、リクエストを、設定された全てのAudit Deviceに送り出す。
  • リクエストのフロー外では、Coreは特定のバックグラウンドアクティビティを実行する。
  • リースマネジメントは期限切れのClient TokenまたはSecretを自動的に取り消すことができるため、かなりクリティカルである。

Rollback Manager​

  • 加えて、Vaultは、Rollback Managerというコンポーネントが先行書き込みログ記録を使用することによって、一部のfailureをハンドルする。
    • これはCoreでは透過的に管理され、ユーザーに見えることはない。