前回は Blog への投稿文の訳でした。今回は Vault サイト https://www.vaultproject.io/ 上の導入ガイドであり、引き続き Vault 概要を掘り下げた内容になります。Vault の登場背景や他のツールとの違いの理解に繋がればと思っています。

次回余裕があれば、Getting Started Guide を予定しています。

—-

■  Introduction to Vault – Vault 入門

https://www.vaultproject.io/intro/index.html

Vault 入門ガイドへようこそ！ 当ガイドは Vault を使い始めるのにベストな場所です。ここでは、Vault とは何か、どのような問題を解決できるのか、既存のソフトウェアと比較するとどうなのか、そして、Vault のクイック・スタートに関してを扱います。

■ Vault とは何？

Vault は安全に「シークレット」（ secret；秘密・秘匿情報） を手に入れるためのツールです。シークレットとは、アクセスをしっかりと管理したいもの全てであり、例えば API 鍵、パスワード、certificate 等です。Vault は様々なシークレットに対する統一インターフェースを提供するだけでなく、堅牢なアクセス制御や、監査ログに詳細を記録する機能も提供します。

現代的なシステムでは、複数のシークレットを手に入れる必要があります。例えば、データベースの認証情報や、外部サービス向けの API 鍵、サービス指向アーキテクチャの通信における認証情報等です。既存の何のシークレットに対して誰がアクセスしているかを理解するのは非常に難しく、プラットフォーム固有のものです。さらに、キー・ローリング（key rolling；鍵の差し替え）、安全なストレージ、詳細な監査ログといった機能を追加するには、カスタム・ソリューションを使わずに殆ど実現できません。此処こそ、Vault が登場する場所なのです。

Vault の最適な使いどころは、使用例をご覧ください。

Vault の主な機能は以下の通りです：

* シークレットの安全な保管（ Secure secret storage ）：任意のキー・バリュー形式のシークレットを Vault に保管できます。Vault はシークレットを永続ストレージに書き込む前に暗号化します。そのため、これまでのように、シークレットを単なるストレージに保管するだけでは得られなかったシークレット入手方法を提供します。Vault はディスクだけでなく、Consul 等にも書き込めます。

* 動的なシークレット（ Dynamic Secrets ）：Vault は AWS や SQL データベースのような、複数のシステム向けにオンデマンドでシークレットを生成できます。例えば、アプリケーションが S3 バケットにアクセスする必要があるとき、Vault に credential を訊ねると、Vault は適切な権限を持つ AWS キーペアを直ぐに（オンデマンドで）作ります。また、動的なシークレットを生成後は、有効期限が切れると廃止も自動的にします。

* データ暗号化（ Data Encryption ）：Vault はデータを保存しなくても暗号化・復号化を行えます。この機能によって、セキュリティ・チームは暗号化するパラメータを決めます。開発者は自分自身によって暗号方式の設計し、暗号化されたデータを SQL のようなデータベースに保管します。

* 期限と更新（ Leasing and renewal ）：Vault 内にある全てのシークレットは「lease」（期限）を持ち、それらと結び付けられます。期限が切れると、Vault は自動的にシークレットを廃止します。クライアントは備え付けの更新 API ( renew APIs ) を使って期限を更新できます。

* 廃止（ Revocation ）：Vault はシークレットの廃止機能を持っています。Vault は単一のシークレットとを廃止するだけでなく、シークレットをツリー状に廃止もできます。例えば、全てのシークレットが特定の利用者により読み込み可能だったり、特定の種類のシークレット全てを指定する場合です。この廃止機能は、不正侵入時の復旧といったキー・ローリング（鍵の自動更新）の手助けにもなります。

■ 次のステップ

Vault use cases（使用例）のページを読むと、Vault の様々な使用方法が分かるでしょう。それから how Vault compares to other software（Vault と他のソフトウェアとの比較）のページでは、既存のインフラに対して、どのように適合させるか分かります。最終的に前に進むため、getting started guide（入門ガイド）で Vault を使った読み込み、書き込み、実際のシークレット作成や、それらが実際にどのように動作するかを見ていきます。

■ 使用例（ Use Cases ）

https://www.vaultproject.io/intro/use-cases.html

使用例を理解する前に、what Vault is （ Vault とは何か？ ）を知っておくことが役立ちます。このページは Vault の具体的な使い方を見ていきますが、ここで単純に扱えない使用例を扱っているからです。

■ 通常のシークレット・ストレージ ( General Secret Storage )

必要最小限の機能として、Vault は様々なシークレットを保管するために使えます。例えば、Vault は細心の注意を払うべき環境変数、データベースの認証情報、API 鍵等を優れた方法によって保管します。

これと、現在テキスト形式のファイルや、設定管理、データベース等に保管されるかもしれない手法を比較しましょう。これらの手法よりも、「vault read」コマンドや API を使って確認するほうが遙かに安全ではないでしょうか。シークレットのバージョン管理をテキスト形式のファイル上で行う必要はなく、Vault の監査ログ（ audit log ）上の記録を参照できます。

■  社員向け認証ストレージ ( Employee Credential Storage )

通常のシークレット・ストレージと重複しますが、Vault は社内でウェブサービスへのアクセスを共有するときに使えるよう、強力な認証機構を持ちます。監査ログの仕組みにより、社員が何のシークレットにアクセスしているか知ったり、社員が離職するとき、鍵の入れ替えを簡単にしたり、どの鍵の入れ替えが必要か、あるいは必要でないかを理解したりできます。

■ スクリプト向けの API 鍵を生成 ( API Key Generation for Script )

Vault の「動的なシークレット」機能はスクリプトにとっても理想的です。例えば、AWS アクセスキーをスクリプト中で生成し、その後で廃止できます。スクリプト実行前・実行後のどちらもキーペアを使わずに、作成されたキーの情報は完全にログ化されます。

Amazon IAM のような何かを用い、様々な場所でハードコーディングされた制限付きアクセストークンを扱うよりも、Vault の手法のほうが進んでいます。

■ データ暗号化 ( Data Encryption )

さらに、シークレットを保管するにあたり、Vault はデータ保管場所とは別の場所で暗号化・復号化します。これにより、アプリケーションが各々のデータを既存のデータストアに保存するとしても、データの暗号化のために一時利用できるようになります。

この利便性によって、開発者は適切なデータ暗号化をどのように行うべきか心配する必要はありません。暗号化に関する責任は Vault が持つため、セキュリティ・チームが Vault を管理し、開発者は必要に応じてデータの暗号化・復号化を行うだけです。

■ Vault vs. 他のソフトウェア

https://www.vaultproject.io/intro/vs/index.html

現時点の市場において、安全に保管できると同様な立場で主張する、様々な選択肢があります。このセクションでは Vault と他のソフトウェアを比較します。

Vault ウェブサイトで比較するにあたり、偏見を避けるため、私達は事実のみを扱います。比較に於いて正しくない点や、古い情報があれば、GitHub で issue をオープンしてください。私達は可能な限り早く対応します。

■ Vault 対 Chef・ Puppet 等

https://www.vaultproject.io/intro/vs/chef-puppet-etc.html

ソフトウェアの設定において重要な部分はシークレットの設置です。例えば、ウェブ・アプリケーションがサービスと会話する時や、データベースの認証を設定する時などです。そのため、全ての設定管理システム（ configuration management system）が安全に各々のシークレットを保管するかという問題に直面しています。

Chef や Puppet 等では、これら全てを似たような手法で解決します。それは単一鍵によって暗号化されたストレージを使う方法です。Chef には暗号化された data bags があり、Puppet には暗号化された Hiera 等があります。暗号化データは常に単一のシークレット（パスワードや鍵など）ですが、復号化は避けており、ここでのシークレットは伸縮する環境において一般的に守られていないため、不正侵入時に何者かが何のデータにアクセスしたかを明確にできません。

あらゆる特定の設定管理システムに対し Vault は依存していません。設定管理を通してシークレットを読めるだけでなく、アプリケーションが API を直接使うこともできます。つまり設定管理においてシークレットを必要としないことを意味し、多くのケースにおいてシークレットをディスクに書き込む必要はありません。

Vault の暗号化データは物理ストレージ上に置かれ、読み込みだけでも複数の鍵を必要とします。攻撃者が物理的な暗号化ストレージにアクセスできるようになっても、データは読めません。読むためには複数の分散された環境で生成された複数の鍵が必要になるからです。これは「unsealing」（アンシーリング）と呼ばれるもので、Vault 起動時に一度だけのものです。

アンシール（ unsealed ）された Vault は、全ての相互関係が監査バックエンドを通して記録されます。間違ったリクエストがあれば（例えば、無効なアクセストークンを使う）、それらは記録されます。あらゆるデータへのアクセスには、アクセストークンが必要です。このトークンとは GitHub や LDAP などのようなシステムとの同一性 ( identity )を結び付けるものです。この同一性もまた監査ログに記録されます。

アクセストークンを使って特定のシークレットがどこにアクセスできるのかを、きめ細かく管理できるようになります。単一の鍵によって全てのシークレットにアクセスできるのは稀です。これによって、Vault 利用者に対するきめ細かなアクセス管理を、簡単に行えるようにします。

■ Vault vs. HSM

https://www.vaultproject.io/intro/vs/hsm.html

ハードウェア・セキュリティ・モジュール ( HSM ) は、様々なシークレットを安全にするよう意図されたハードウェア装置です。一般的に強力なセキュリティ・モデルを持っており、様々なコンプライアンス基準に従っています。

HSM における重大な問題は、それらが高価であるのと、クラウド・フレンドリーではないことです。Amazon は CloudHSM を提供しますが、CloudHSM を使い始めるために必要な最小費用は、数千米国ドルです。

HSM を導入して使うにあたり、設定は非常に退屈なものです。そして、「API」を使ったシークレットのリクエストも大変です。例えば、CloudHSM は SSH を必要とし、様々なキーペアを手動で設定します。自動化は難しいでしょう。

Vault は HSM を置き換えるものではありません。もし HSM 手に入れられる余裕があるのであれば、多くの利点を得られます。それどころか、HSM は Vault におけるシークレットのバックエンドとして素晴らしい潜在性を持っています。Vault を使えば、HSM データに対して Vault API を通してアクセスできるようになり、HSM の利用を極めて簡単にし、さらに監査ログの機能も提供します。その上、Vault と同様に HSM に対する複数の監査ログをもたらします。

動的なシークレットの生成など、Vault は現時点で HSM では行えないような多くのこともできます。Vault を使わず AWS アクセスキーを直接保管する方法よりも、Vault であれば特定のポリシーに従って迅速にアクセスキーを生成します。シークレットのバックエンド・システムを使うあらゆるシステムに対して、Vault は潜在性を持っています。

多くの企業において、HSM はオーバーキル（やり過ぎ）であり、Vault で十分でしょう。HSM を導入できる企業であれば、Vault を使うことで双方の利便を得られます。

■ Vault vs. Dropbox

https://www.vaultproject.io/intro/vs/dropbox.html

大小を問わず多くの組織において、Dropbox をシークレット保管の仕組みとして用いられているのは嘆かわしい事実です。私達がカスタムソリューションのページではなく、敢えてこのページを作ろうと決めたのは、あまりにも多いからです。

Dropbox は秘匿情報を保管するためには作られていません。たとえ Dropbox 内部で暗号化ディスクイメージが用いられていたとしても、本来のシークレット保管サーバーとしては基準以下です。

Vault のような本来のシークレット管理ツールは強力なセキュリティ・モデルを持っており、複数の異なった認証サーバ、ストア、監査ログを統合することで、動的なシークレットの生成などができるようになります。

そして、「vault」CLI のおかげで、「vault」コマンドを使うだけであり、開発者のマシンはシンプルです！

■ Vault vs. Consul

https://www.vaultproject.io/intro/vs/consul.html

Consul はサービス検出や監視や設定を行うために、高い可用性を持つ分散システムです。Consul も鍵へのアクセスやサービス情報に対する制限を行うアクセス制限システム（ ACL ）をサポートします。

Consul は秘匿情報の保管や ACL を用いる制御に利用できますが、そのような目的のために設計されていません。つまり、Consul のデータは通信中も保管中も暗号化されませんし、プラグ的な認証機構もなく、リクエスト単位で認証する仕組みもありません。

Vault はシークレットの管理ソリューションを築くために設計されています。つまり、通信中も保管中も秘匿情報を守ります。複数の認証方式を持っており、監査ログ機構もあります。動的な秘匿情報の生成によって、Vault はクライアントが root 権限を根底のシステムで使うのを回避し、鍵のローリング（付け替え）や廃止機能を実現しました。

Consul の強みは耐障害性と高い可用性です。Vault のバックエンドに Consul を使うことによって、両方の利便性が得られます。Consul を暗号化データの永続的な保管のためのストレージとして使い、調整することで、Vault が高い可用性と耐障害性を持てるようになります。Vault は高いレベルのポリシー管理、秘匿情報の期限設定、監査ログ、自動廃止を提供します。

■ Vault vs. カスタム・ソリューション

https://www.vaultproject.io/intro/vs/custom.html

多くの組織において、秘匿情報の保管に何らかのカスタムソリューションを必要としています。それは Dropbox かもしれませんし、暗号化ディスクイメージかもしれませんし、暗号化 SQL カラム等でしょう。

これらのシステムは、構築と維持のために時間とリソースを必要とします。また秘匿情報の保管は、インフラにおける非常に重要な部品であり、正確に行わなくてはいけません。それによって、内部システムを維持するためのプレッシャーが増えます。

Vault は秘匿情報の保管のために設計されました。シークレット・ストレージが必要とする強力なセキュリティモデル上で、Vault はシンプルなインターフェースを提供します。

その上、Vault はオープンソースのツールです。つまりツールはコミュニティ全体を通し、改良に取り組んでいくことを意味します。単なる機能やバグフィックス、潜在的なセキュリティ・ホールだけではありません。付け加えて、オープンソースなので、あなた自身のセキュリティ・チームで Vault をレビューや貢献し、セキュリティ標準の確認をもたらします。

—-