セキュリティ対策におけるクレデンシャル情報の課題をVaultで解決
grasysは創業4年目の、Google Cloud Platform（GCP）などクラウドを主体としたシステムの設計、構築、安定した運用を手掛けるMSP事業者である。ゲームシステムやWebシステムのインフラ、サービスのバックエンドを担当するほか、最近ではBigQueryへのデータフロー設計・管理・運用などの分析基盤システム系の業務も増えているという。
守永氏は2015年にgrasysへ入社。現在は某グローバル通信ゲームのインフラ環境をGCP上に構築・運用し、監視プログラムの設計・開発などを担当。Google Certified Professional（認定プロフェッショナル）のクラウドアーキテクトとデータエンジニアの認定資格も取得しており、「それなりにできる人」と笑いながら自己紹介をし、Vaultの紹介とその使い方について解説を始めた。
「セキュリティ対策におけるクレデンシャル管理に課題を感じている人も多いのでは」と参加者に語りかける守永氏。この課題のソリューションとして守永氏がお勧めするのが米HashiCorp社の「Vault」である。
grasysでは「設立当初の2014年からHashiCorp社のOSS製品をよく使ってきた」と守永氏は言う。オーケストレーション製品の「Serf」、サービスディスカバリーおよびサービスの監視製品「Consul」、プロビジョニング製品の「Terraform」などはその一例だという。「ずっとHashiCorp社の製品はいいなと片思いし続けていたが、晴れて7月27日にHashiCorp社とパートナー契約を結ぶことができた」と喜びを表す。
Vaultは煩雑になってきているクレデンシャル管理の問題を解決するソリューションを提供するソフトウェア。日本ではまだそれほど知名度はないかもしれないが、海外ではAdobeをはじめ有名企業で使われているという。「特に金融系やSNSなどでよく使われている」と守永氏。機密情報の管理や暗号化サービス、アイデンティティ・アクセス管理などのユースケースが多数、登場している。
「システムにおいて、クレデンシャル管理はつきものだ」と守永氏は説明を続ける。クレデンシャル管理における課題は主に5つある。第一はパーミッション。適切なサーバやスプレッドシート、Git、Dropboxなど、権限が与えられたユーザーのみが触れるようになっているのかなど、適切に管理できているのかといった課題だ。
第二は保存場所。「クレデンシャル情報をローカル、サーバ、クラウドに置くなどしていろいろなところで保存していると思うが、両方に存在していてどちらが新しいかわからなくなり、困ることも多いのでは」と守永氏は指摘する。
第三はデプロイ方法。「一貫性のあるデプロイ方法を使っているか。例えばJenkinsを使っている際、環境変数に人が介在するとミスになることもある。そこが課題になる」と守永氏。
第四は生成方法。適当な乱数、文字と特殊文字で構成された強力な長いパスワードを使っているか、適切に定期的に変更できているかなどの課題がある。
第五は暗号化/復号。「クレデンシャル自体が難しいポリシーになる」と守永氏。クレデンシャルを保存している場所は本当に暗号化されているのか、それを復号する際はシームレスにできているのかといった課題がある。
「このようなクレデンシャル情報にまつわる煩雑な課題を解消するのが、Vaultである。Vaultはクレデンシャル管理におけるパラダイムシフトを起こしてくれるソフトウェアだ」と守永氏は力強く語り、Vaultの主な機能の解説に移った。
まずは「Secure Secret Storage」。VaultはSecretをストレージに保存する前に暗号化するので、ストレージに直接アクセスしても内容は読み取れないようになっているのだ。さらにVaultはさまざまなストレージに暗号化されたSecretを書き込むことができるようになっている。
第二の機能は「Dynamic Secrets」。VaultはオンデマンドでMySQLやGCP APIのSecretを生成することができる。一時的にMySQLのアカウントが必要になると、Vaultに要求すればUser/Passを自動生成して新しいアカウントを発行してくれるのだ。「発行したアカウントはリースが切れたタイミングで削除できる」と守永氏。
第三の機能は「Data Encryption」。Vaultはデータを保存せずに暗号化・復号できるので、利用者はあまり意識することなくシームレスに暗号化されたデータを扱うことができるようになる。
第四の機能は「Lease＆Renewal」。VaultのSecretにはリースIDがひも付いている。従ってTTLが切れるとSecretは利用できなくなる。そしてTTLをリセットするためのRenew機能も用意されているのだ。
第五の機能は「Revocation」。VaultにはSecretをRevoke（取り消す）するための機能が備わっている。Seal機構によりシステムロックすることもできる上、Key Rollingの機能も備わっている。
Vaultを使ってMySQLアカウントのダイナミック発行の仕組みを構築
ではVaultを使うとどんなことが可能になるのか。それを説明するため守永氏はMySQLアカウントのダイナミック発行の方法を例にとって紹介した。この仕組みのターゲットは次の通りだ。
- 毎日実行するバッチ処理でMySQLにアクセスするシステムで、バッチ処理はLL言語で記述されている。
- MySQLの接続情報が環境変数に書かれている。
- 調査時以外は誰もMy SQLにアクセスできないようにしたい。
- MySQLのクレデンシャルは定期的に変更したい。
Vaultを使うと、下図のようになる。
まずアプリケーションがVaultにMySQLのクレデンシャルを要求する。するとVaultがMySQLのアカウントを発行して、アプリケーションはMySQLにログインできる。そしてリースが切れたら、Vaultはアクセスできないようにアカウントを削除するという仕組みだ。これは、次の要素で構成することができる。
Actor
- Applicationサーバ
- MySQLサーバ
- Vaultサーバ
Application
- Vault Token（埋め込み）
MySQL
- Vault用アカウント
Vault
- Application Token Policy
- Database Secret Engine / Role
「ポイントはアプリケーションが直接Vaultにアクセスするので、アプリケーションにはVaultのTokenが必要な点。またVaultがMySQLアカウントを発行するので、MySQLにはVault用のアカウントが必要となる。Vaultの要素としては、Database Secret Engineが使われるということがわかればよい」と守永氏は説明する。
構築方法は次の通りだ。まずアプリケーションサーバがVaultにログインするためのTokenを作成する。次にアプリケーションサーバが利用するVault Tokenを発行し、アプリケーションサーバに配置する。そしてMySQLのアカウントをVaultが発行できるようにするために、Database Secret Engineを有効化し、Database Secret Engine Config、Database Secret Engine Roleを設定する。このような仕組みにすることで、アプリケーションがMySQLにアクセスしたいタイミングでVaultがアカウントをマネジメントしてくれるというわけだ。
「だが、この仕組みには課題がある」と守永氏。というのもMySQLでTTLを設定し、消してくれるのはよいが、アプリケーションサーバに入れる人は誰もがMySQLに入れることになるからだ。つまりVault用のMySQLアカウントもセキュリティホールになるという懸念がある。それを解決する仕組みが以下だ。
CIサーバを設置し、VaultにログインするためのSecret IDを取得するようにするのである。
「CIサーバはAppRoleログインのためのSecret IDをアプリケーションに送る。Secret IDはラップした状態でアプリケーションに渡されるので、それをアンラップする。次にアプリケーションサーバがAppRoleと言う機能を使ってVaultにログインする。そうするとVaultのTokenが返ってくるので、そのTokenを使ってMySQLアカウント発行の命令を実行する。その後のシーケンスは前回と同じだ」（守永氏）
構成要素
Actor
- Applicationサーバ
- CIサーバ
- MySQLサーバ
- Vaultサーバ
Application
- Role ID for App Role
- Vault Token for Unwrap
- Vault Token for AppRole Login
CI
- Vault Token for obtain wrapped Secret ID
- MySQL
- Vault Account
Vault
- AppRole
- Unwrap Token Policy
- Obtain Wrapped Token Policy
- Database Secret Engine / Role
「今回の構成要素で注目なのは、Auth MethodのためのAppRoleというものだ」と守永氏は説明する。構築するためにまず実施することはAppRole Auth Methodを使って、AppRole Auth Methodを有効化し、アンラップおよびAppRole用のポリシーを作成する。次にToken（Secret IDをアンラップするためのVault TokenとAuth MethodでログインするためのToken、CI用のVault Token）を発行する。この後の構築方法は前回同様となる。
この構成にすることによって、アプリケーションサーバにログインできても、MySQLアカウントは発行できなくなることはもちろん、CIサーバにログインできてもMySQLアカウントは発行できなくなる。「VaultがMySQLにログインするためのアカウントは、二度とログインできないくらいの状態にすることができる。それぐらい強力にクレデンシャル情報を管理できる」と守永氏は言い切る。
GCP上にVaultクラスタを構築する方法についても解説した。必要となるリソースは各種API（GCP用）、KMS、GCS、GCE VMインスタンス、GCE サービスアカウント、GCE IAM、HashiCorp Terraform。Vaultはバックエンドが選定できるので、High availability（HA）連携のバックエンドにはConsul、記憶容量用にはGCSを選定した。手順は次の通り。
- 各種API有効化
- KMS設定
- GCS Bucket作成
- IAMカスタムRole作成
- サービスアカウント作成
- VMインスタンス構築
- Consulセットアップ
- Vaultセットアップ
守永氏はさらに、Vaultの便利な機能の解説を行った。最初に紹介したのは「Storage Stanza」。つまり「利用できるストレージがたくさんあるということだ」と守永氏は語る。
次にSeal機構を持っていること。「この機能によってVaultへのAPIアクセスをコントロールすることができる。Sealed Statusだとほぼ何もリクエストできない状態になる」と守永氏は言う。
サーバ起動時はシール状態。アンシールにするには、アンシールコマンドを使うのだが、5つ用意されているキーのうち、3つを利用することでようやくアンシールできる仕組みになっているのだ。一方、シールする際は一発でできるという。「情報漏えいが発覚した際は、sealと打つだけで、誰もアクセスできなくなる。最悪の時に使える機能だと思う」と守永氏。
Auth Methodも複数ある。また、Vaultを使う主要因であり、同期のメイン機能となる「Secret Engine」を使うと、VaultのTokenとTokenにひも付いたポリシーを利用して機能させることができるようになる。Secret Engineも複数用意されているという。
「Vaultを使うとかえって面倒くさそうだなと思ったかもしれない。確かに私もVaultを扱うのは難しいと感じている。だが、Vaultがあると、クレデンシャル管理にまつわる課題の多くが解決できると考えている。Vaultがもっと注目される日が近々くると感じている。興味のある人はぜひ、試してほしい」
最後に守永氏はこう会場の参加者に呼びかけ、セッションを締めくくった。
お問い合わせ
株式会社grasys
