Armon Dadgar氏がQCon New Yorkで，最新の生産システムにおけるセキュリティ要件をテーマとした，情報豊富なプレゼンテーションを行った。InfoQはプレゼンテーション後のDadgar氏に面会する機会を得て，大規模システムでシークレット(secret, 秘匿情報)を管理するためのオープンソースツールである，HashiCorpのVaultに関して聞くことにした。
HashiCorpは今年4月，最新方式のデータセンタ内のシークレットを安全に管理し，転送されるデータを暗号化する，オープンソースツールのVaultをリリースすると発表した。同社のブログによると，最新の運用システムにおいては，シークレット管理に複雑な要件を伴うことが少なくない。データベースの資格情報や外部サービス用のAPIキー，通信認証などといったシークレットは，アプリケーションのさまざまなスタックに存在する。静的な機密データ保存や通常のキーローリング(鍵情報の更新)機能といった，包括的な監査機能も一般的には必要だ。Valultは，これらの問題すべての解決を目標とする。
InfoQは，HashiCorpの共同創業者でCTOのArmon Dadgar氏と話をする機会を得て，Vaultの使用方法とシークレットの保管，最新鋭のデータセンタにおけるセキュリティ実装などについて聞くことにした。
InfoQ: Armonさん，ようこそ。 HashiCorpのVaultを簡単に紹介して頂けますか？このツールが解決しようとしている問題についても，説明をお願いします。
Dadgar: Danielさん，お招き頂いてありがとう。最初Vaultを考え始めた頃は，シークレットの配信を主なテーマとして捉えていました。具体的には，APIキーやデータベースのユーザ名とパスワード，ユーザアプリケーションに対するTLS証明といったものです。シークレットを安全かつ容易に，さらにクラウドフレンドリに保管し，配信することのできる手段が欲しかったのです。
Vaultが完成すると，もっと別の使い道があることに気付きました。HashiCorpには，最新のインフラストラクチャを対象として，サービスディスカバリとコンフィギュレーション，コーディネーションに関するソリューションを備えたデータセンタランタイムを提供する，Consulという別プロジェクトがあります。Vaultを使えば，それをセキュリティランタイムに仕立てられると思ったのです。私たちは，コミュニティのコントリビューションを組み合わせて，Vaultを内部認証局として動作するようにしました。認証を発行したり，アプリケーション間で相互TLSを使用したりできるようにしたのです。現在ではたくさんのグループが，Vaultを“エンクリプション・アズ・ア・サービス”として利用しています。暗号化の微妙な違いに煩わされることなく，アプリケーションをよりセキュアにすることが可能になりました。
Vaultはシークレットの配信を目的として始まりましたが，その目的に対して十分な機能を持つだけに留まっていません。監査や証明書管理，キーローテーションや暗号化といった，セキュリティに関する問題に対しても，完全なソリューションも提供しています。
InfoQ: Vaultでは，どのような規模の運用を想定しているのでしょう？例えばスタートアップやSME，あるいは大企業で運用した場合，どのようなメリットが期待できるのでしょうか？
Dadgar: 一般論として言うなら，インフラストラクチャに関する問題は，組織の規模に対して指数関数的に増加すると思います。スタートアップではお互いがお互いを知っていますから，ちょうど開拓時代の西部のようなもので，チーム全体を信頼することで万事がうまくいきます。組織が大きくなるにつれ，この信頼モデルが崩壊を始めるのです。すべてのアプリケーション，すべてのサーバ，すべての人たちを知ることは，もはや不可能です。 攻撃者はそれを知っていて，それを利用します。そのため，信頼性を管理してアクセスコントロールを実現する上で，Vaultのようなツールの利用がより重要になるのです。
Vaultの価値は，それが監査やアクセス制御，キー管理，シークレットの配信で果たす役割の大きさにあります。これらはいずれも，解決を必要とする難しい問題である上に，組織が大規模になるほど重要になります。小規模な組織でのVaultは，エンクリプション・アズ・ア・サービスのような多彩な機能を備えることによって，開発チームが暗号化処理の確認などに煩わされることなく，自分たちの製品に注力できるようにします。小チームがVaultを採用した場合，それまでの組織的信頼モデルを反映した緩いアクセス管理は失われるかも知れません。ですが，チームの規模が大きくなった時には，Vaultのアクセス制御を強化することが可能ですから，セキュリティ強化のためにアプリケーション全体のアーキテクチャを再構築する必要はなくなります。
InfoQ: VaultのダイナミックシークレットとACLサポートについて，詳しく説明して頂けますか？クラウドベンダのプラットフォームの作業をどのように支援してくれるのか，独自のセキュリティソリューションとしてアピールするのはどのような部分なのかを知りたいと思います。
Dadgar: シークレットを配信する上で厄介な問題のひとつは，相手にシークレットを“忘れる”ように強要できないことです。例えば，データベースのユーザ名とパスワードを一度提供してしまえば，それらの認証情報をアプリケーションに忘れさせるのは非常に困難です。アプリケーションの不注意によって，それらの情報がネットワーク越しにディスクにログ記録されてしまうと，その時点で，シークレットの監査やアクセス制御はほぼ不可能になります。
ダイナミックシークレットはこの問題に，エレガントなソリューションを提供します。クライアントからアクセスを要求された場合，Vaultは，アプリケーションにデータベースのユーザ名とパスワードを渡して共有するのではなく，新たな資格情報を生成します。生成された資格情報はクライアントに提供されて，リース形式で管理されます。クライアントが終了するか，あるいはリースが取り消されると，Vaultはその資格情報を削除します。ダイナミックシークレットはオンデマンドで生成され，クライアント単位で監査され，簡単に取り消すことができます。これで資格情報がアプリケーションの不注意でログに記載されたり，リークしたりする心配がなくなるのです。Vaultのこの方法は，資格情報のリークによる影響を軽減するだけでなく，リーク発生時の迅速な修正も可能にします。
ご質問にもあった通り，ダイナミックシークレットは，クラウドプラットフォームのさまざまなアクセス制御APIを扱うために，この上なく便利です。この種のAPIには標準がないため，開発者やオペレータはそのAPIを直接扱わなくてはなりません。これがACLの共通化を難しいものにしているのです。Vaultは，クライアント用のインターフェースを一本化して，クラウドベンダやデータベンダ，その他アプリケーション間の違いを隠すことで，この問題の解決を支援します。VaultのACLシステムは下位APIに依存しないため，ACLを集中的かつ統一的に管理することが可能となります。ツールやベンダサービスを新たに導入する度に，同じレベルのアクセス制御を行う方法を探す必要はありません。
InfoQ: Vaultは資格情報のリースと更新をサポートする，ということでしたが，開発者あるいはオペレータがこの機能を取り入れるには，一般的なワークフローをどの程度変更する必要があるのでしょうか？
Dadgar: 基本的には２つの選択肢しかありません。アプリケーションでVaultを意識するか，あるいはしないかです。一番簡単なのはVaultを意識しないで，Vaultとインターフェースするコプロセス(co-process)に依存する方法です。アプリケーションがVaultを意識すれば，より多くのVaultの機能を活用して，最大限のセキュリティを達成することができますが，コードの変更が必要となるので，対応が難しくなるかも知れません。コプロセスを使用する方法でもシークレットの受信は可能ですし，リース管理を処理する必要はありません。
コプロセスのアプローチを採用する場合には，Consulテンプレートツールを利用するように勧めています。これはConsulのデータをベースとするテンプレートを生成するためのツールですが，Vaultもサポートしています。このツールはシークレットを，Vaultを意識しないアプリケーションが読み込み可能なファイルに書き出します。ファイルの書き込み先には，tempfsなどの揮発性RAMディスクが適切です。Consulテンプレートはリースを管理します。また，シークレットのいずれかが変更されると，ツールはすぐにテンプレートを更新した上で，アプリケーションを再ロードして認証情報を更新します。
InfoQ: 監査についてはどうでしょう。多くの組織のセキュリティポリシ上，重要なコンポーネントなのは明らかですが，この分野でVaultは，どのような役割を果たるのでしょうか？
Dadgar: 監査機能はVaultのコアに組み込まれているので，すべての要求と応答を監査できます。Vaultにはプラグイン可能なバックエンドという概念があり，機能拡張が簡単にできます。今のところディスク書き込みとsyslogへの監査ログ送信をサポートしていますが，SplunkやELKとの統合も計画中です。
Vaultはセキュリティを対象としたツールですので，フェールクローズ(fail closed)に設計されています。つまり，監査ログが有効になっていて，要求または応答の監査に失敗した場合，Vaultはクライアントの要求を拒否します。事後に監査不可能な要求に対するサービスの提供は望まない，という発想です。このようなリスクを回避するため，Vaultでは，単一の監査バックエンドに可用性の責務が集中しないように，複数の監査バックエンドの指定が可能になっています。
InfoQ: Vault自体のセキュリティについては，ツール内でどのような暗号化を使用しているのでしょう？外部の専門家による監査を受けていますか？
Dadgar: iSECとNCC Groupによる外部コード監査が，ちょうど先日完了したばかりです。暗号化の利用を中心に，Vaultのコードベースの完全な監査を実施しました。完璧なシステムというものはありませんが，iSECとNCCが評価した部分に関しては，Vaultは非常に高いレベルのセキュリティ保証を達成しています。プロジェクトはGoで記述されています。Goはメモリセーフなので，開発者の不適切なエラーチェックに起因するセキュリティ脆弱性といったものを防止できます。Vaultでは，データ安全性のためには最先端の技術とされるAES-GCM-256を，クライアント通信データにはTLS 1.2を使用しています。
私たちは今後もValutに注力していきます。プロジェクトの進行中にセキュリティ脆弱性が混入することを防ぐために，セキュリティ監査人による評価の実施も計画しています。Vaultのユーザには，フルタイムの開発作業や有償サードパーティのコード監査による高いレベルのセキュリティ保証に加えて，オープンソースコミュニティによる“たくさんの目”というメリットもあります。
InfoQ: Vaultはオンラインシステムなので，クライアントからシークレットを要求する必要がありますが，Vaultの停止がダウンタイムを引き起こすというリスクはないのでしょうか？
Dadgar: HashiCorpは数年前からデータセンタの自動化に取り組んでいるので，最近のインフラストラクチャが備えている高可用性については理解しています。設計の時点から，高可用性は設計上の重要な部分でした。後から取り付けるようなものではありません。VaultはConsulやZookeeperと同じように，リーダ選出(leader election)を行うためのコーディネーションサービスを利用します。これはつまり，複数のVaultインスタンスをデプロイ可能だということです。ひとつがフェールすれば，正常なインスタンスに自動的にフェールオーバします。一般的には，単一のインスタンスに障害が発生した場合の影響緩和のため，少なくとも２つのVaultサーバをデプロイするように推奨します。
InfoQ: お時間を頂き，ありがとうございました。他に何か，InfoQ読者に伝えておきたいことはありますか？
Dadgar: ネットワーク境界は，最初で最後，そして最高の防御ラインだと長く考えられてきました。最も有名な例は，Googleの“Aurora”攻撃でしょう。この時，攻撃者はプライベートネットワークに潜入していて，データを盗み出すために高信頼環境の利用が可能な状態でした。その時のターゲットが先日，内部ネットワークにたまたま繋がっていたHVACシステム経由でハックされたのです。ナタンズのイラン核施設は地下に建築されて，インターネットから隔離されていましたが，インターネットにアクセス可能なウィルスによって攻撃されました。セキュリティ専門家がそのアプローチを再評価する理由となった，最近の攻撃に関する長いリストには，Neiman MarcusやHome Depotなどの名前も挙がっています。
結論として重要なのは，内部ネットワークは安全だとは決していえない，ということです。ファイアウォール，VPN，あるいは空気中にさえ，攻撃の隙はあるのです。ネットワーク境界は防衛ラインとして適切ですが，それだけであってはなりません。Vaultの目標のひとつは，ユーザの“ゼロトラスト(zero trust)”ネットワークへの移行を可能にすることです。そこでは，ネットワーク上にあるということが，特別なアクセスレベルを意味しません。特に重要なのは，マイクロサービスを採用している組織です。モノリシックなアプリケーションでは数える程に過ぎなかった潜在的な攻撃面が，独立したサービス単位の数百，あるいは数千という数に増大するからです。
Vaultはこれからも前進を続けます。私たちの目標は，マイクロサービス間の相互TLSのサポートやSSHのワンタイムパスワード，適切な粒度のサービス・トゥ・サービスのアクセス管理といったものを通じて，そのような環境を手にするための支援にあります。セキュリティは後付けであることも多いのですが，攻撃者はますます高度になっていますから，開発者やオペレータはそれに先んじなくてはなりません。
Vaultに関する詳細はVaultのホームページやHashiCorpのブログ，同プロジェクトのGitHubリポジトリなどで確認することができる。