概要

機密情報の管理はいつも悩みのタネです。
その管理に僕はHashiCorp Vaultを推してますが、その理由を含めて説明します。

管理方法の課題

機密情報の管理で考えなければいけないことはたくさんあります。

データの暗号化
どこに保存するか
認証
アクセス権限
ローテーション
鍵の共有自体を防ぐ仕組み
デプロイ時などの鍵配送
Audit(監査)ログ
漏洩の検知
漏洩時のインシデントインパクトの最小化

最初の２つはすぐ浮かぶと思いますが、残りは多くのケースで十分な対応がされてないです。

スケーラビリティ

次に問題となるのがスケーラビリティです。

システムのスケール
組織のスケール

のそれぞれで考えてみます。

システムのスケール

システムがスケールしていき、複数のクラウドを使用する場合になると以下のような問題が発生してきます。

各クラウドでマネージドサービスはあれど、それぞれで対応するコスト
各サービスによる対応クオリティの差

それぞれで対応するコスト

マルチクラウドの場合、それぞれで

アクセス権限
ローテーション
Auditログ、漏洩検知

を管理していくのは非常に大変です。

全クラウドに精通した人物がいて、その人が統一的に仕組みを作ってくれれば良いですが現実はそんな都合良くありません。

そうなると各クラウドで管理方法が変わっていき、結果考慮漏れが発生してインシデントへと発展します。

対応クオリティの差

またマネージドは各サービスによって機能が異なり、片方にはあるがもう片方にはない、といったケースに悩まされることもしばしばあります。
そしてそこを手運用や自作ツールに頼って負債化していく、ということもよくあります。

人

組織がスケールしていき、人の流入・流出が増えたときに出てくる課題が以下です。

手運用やルールは負債化、知見の消失が起きる
漏洩経路の拡大

手運用やルールは負債化、知見の消失が起きる

秘密情報に限らずですが、手運用やルールは確実に負債化するのでシステム化は絶対に必要です。
「ドキュメントで頑張る」という選択肢もありますが、その多くがメンテナンスされずに古く間違った情報になっていきます。

漏洩経路の拡大

また扱う人が増えると漏洩する可能性も増えるため、

認証
アクセス権限
漏洩検知
漏洩時のインシデントインパクトの最小化

の重要性が非常に高まります。

つまり

このようにスケール性も考慮すると、その場その場で対応することは負債を生み出す一方であり、秘密情報はシステム化された場所で一元管理する必要性があることが分かります。

なぜHashiCorp Vaultを推すのか

気づいたら17記事も書いているほどVault推しな自分です。

f:id:quoll00:20190828075517p:plain

ではなぜそれを推すのかというと、先程挙げた課題を解決でき、かつ一元管理できるからです。

データの暗号化

Vaultを通して保存されたデータはストレージに書き込む前に全て暗号化されます。
なのでストレージにアクセスしても機密情報を取得することは出来ません。

またTransit Secrets Engineという、データ自体は保存せず暗号化する機能も提供しています。

どこに保存するか

上記の通り暗号化されるので基本的にどんなストレージでも扱えます。
エンジニア側で自由に選択ができるようプラグイン機構になっています。

Consul
DynamoDB
Etcd
MySQL
S3
etc...

ref: Storage Backends - Configuration - Vault by HashiCorp

認証

機密情報へアクセスする際の認証についてもプラグイン機構になっており、

IAMユーザを持っていたらVaultにログインできるようにする - Carpe Diem

や

LDAP
Okta
GCP IAM

などに関連付けることで独自にログインのためのID&PWを用意することなく認証する事が可能です。
なので退職者が出ても上記アカウントを削除することで認証させないようにできます。

アクセス権限

Policyによって柔軟なアクセス制限が可能です。

HashiCorp VaultのPolicyを使った運用 - Carpe Diem

Vaultでは全権限を持つroot keyは基本的に存在させない（＝使ったらすぐ消す）ため、影響範囲を限定できます。

ローテーション

VaultのTokenとLease - Carpe Diem

で紹介したように、Vaultに対するtokenには基本的に期限が付いています。

ただしKVに保存する機密情報については自分でローテーションする必要があります。そこで

HashiCorp VaultのDynamic Secrets - Carpe Diem

を使うことで動的に機密情報を生成して、自動で失効する仕組みを用意すると良いです。

鍵の共有自体を防ぐ仕組み

先に説明したように

HashiCorp VaultのDynamic Secrets - Carpe Diem

を使うことで動的に機密情報を生成して、自動で失効する仕組みを用意すると良いです。
そうすれば共有されることもなくなります。

デプロイ時などの鍵配送

HashiCorp VaultのAppRoleを使ってトークン取得 - Carpe Diem

というアプリケーションに向いた認証方法があり、特定のIP Rangeのアクセスの時のみトークンを発行するといった形で安全に鍵の配送が可能になります。

Audit(監査)ログ

HashiCorp VaultのAudit Devicesでオペレーションをロギング - Carpe Diem

VaultのAuditログでは

authで認証した人（＝操作した人）
request.operationでどんな操作をしたか
request.pathでどのデータにアクセスしたか

が分かるので、それを使えば誰がいつアクセスしたかがすぐに分かります。

漏洩の検知

先程のAuditログをslackに流してチェックするようにしたり、

VaultのCubbyhole Response Wrapping - Carpe Diem

によって一度しか使えないtokenを用いることで漏洩したかどうか検知することが可能です。

漏洩時のインシデントインパクトの最小化

Vaultのtokenはlease機能に加えて手動でもrevokeができるので、漏洩が確認できた際に即座にrevokeすることで影響を減らせます。また