【参考訳】 Vault 0.2.0 | Pocketstudio.jp log3

Vault 0.2.0 がリリースされたという Blog への投稿がありました。例によって、内容把握の参考用に翻訳しました。興味がありましたら、どうぞ。

■ Vault 0.2

原文：Vault 0.2 – HashiCorp
https://www.hashicorp.com/blog/vault-0-2.html

私達は Vault 0.2.0 リリースの発表を誇りに思います。Vault とはシークレット（secret、訳者注；パスワードやAPIトークンなど、セキュリティ上の取り扱いに慎重な情報）を管理するためのツールです。Vault は証明書や API 鍵を保管し、機密に関わるデータを暗号化しますので、全てのシークレット管理に必要となる解決策になり得ます。

Vault の初期リリースは、ほぼ２ヶ月前でした。その後、中心的な機能の拡張に注力することで、新しいシークレットやストレージ・バックエンドの追加や、ユーザ経験の改善、バグの修正を行いました。

Vault 0.2.0 には、多くの新機能が組み込まれています。鍵のローテーション（訳者注；定期的な入れ替えの意味）、rekeying（訳者注：以下、鍵再作成と表記）、動的な証明書生成用の PKI シークレット・バックエンド、Cassandra シークレット・バックエンド、多くの新しいストレージ・バックエンド、トランジット（transit）・バックエンドのためのトランザクション毎のユニークな鍵の抽出といったものです。ここで全てを紹介出来ないほど多くの素晴らしい機能がありますので、詳細については Vault 0.2.0 CHANGELOG をご覧ください。

Vault 0.2 はプロジェクトのウェブサイトからダウンロード出来ます。

Vault 0.2 の主な新機能について知りたい場合は、このまま読み進めてください。

■ 鍵ローテーション（Key Rotation）と鍵再作成（Rekeying）

Vault サーバの初回起動時は、「vault init」コマンドでシステムを初期化します。この作業により、データ保護を確実なものにするため、暗号化鍵を保護するために使うマスタ鍵を生成します。そして鍵は共有されますが、これらはマスタ鍵を分割したものを使います。

Vault 0.1 では、これらの鍵全てが固定されたものであり、作成後の変更はできませんでした。Vault 0.2 から、全てを更新出来るようになります。変更するには新しいコマンド「rotate」と「rekey」を使います。

１つめの「rotate」コマンドは、データ保護を確実にする暗号化鍵を変更するものです。実行すると（CLIを使うか、APIでも直接操作出来ます）、新しいランダム鍵を生成し、鍵リング（keyring）がインストールされます。新しい鍵を使う全てのデータには一貫性がありますので、古い鍵の下で暗号化された鍵も復号出来ます。Vault 0.2 においては、古い鍵は自動的に再暗号化されませんが、将来的には拡張を考えています。

$ vault key-status
Key Term: 1
Installation Time: 2015-07-14 20:46:31 +1000 AEST

$ vault rotate
Key Term: 2
Installation Time: 2015-07-14 20:46:36 +1000 AEST

$ vault key-status
Key Term: 2
Installation Time: 2015-07-14 20:46:36 +1000 AEST

２つめの「rekey」はマスタ鍵の変更や鍵共有のパラメータの変更に使います。「init」コマンドによって、共有数（key shares）や閾値（key threshold）の設定を行います。「rekey」コマンドを使うことにより、これらのパラメータを変更出来ます。これにより、もし以前の鍵の所有者が組織を離れる場合に、鍵共有の方法を変更することができます。

「rekey」の手順は、既存の鍵所有者が実行しなくてはいけないため、少々複雑です。作業は、新しい共有数と閾値（同じではいけません）を指定してから始めます。閾値に到達すると、マスタ鍵は再生成され、新しい共有鍵が提供されます。

$ vault rekey -init
Started: true
Key Shares: 5
Key Threshold: 3
Rekey Progress: 0
Required Keys: 1

$ vault rekey
Rekey already in progress
Key Shares: 5
Key Threshold: 3

Key (will be hidden):
Key 1: 9de4b5732ad06ca5c982ebc189d100763e0dfa88afc44ebfe2d707237cde17c001
Key 2: 54cc5de89f2731e46eaac690b3b017fa6173acab9375285bfb360c6b6c6bc15902
Key 3: 2f216b05195ae4b454f98c23ed0aa9a966cb4e187f54a71a1253ab975b0f1d6403
Key 4: 9288da985a7956255b7e8ee75220e27fcaa0dc99b4bb953314822aeb3a674dfb04
Key 5: e965ec75dc048375612dc4540c9a5c2ccd183e2a589a1a72fde78d170d0391c605

Vault rekeyed with 5 keys and a key threshold of 3. Please
securely distribute the above keys. When the Vault is re-sealed,
restarted, or stopped, you must provide at least 3 of these keys
to unseal it again.

Vault does not store the master key. Without at least 3 keys,
your Vault will remain permanently sealed.

（Vault は５つの鍵を再作成し、鍵閾値は３です。
　上の鍵を安全な場所に分散してください。Vauls を再度シールしたり、
　再起動や停止するときには少なくとも３つの鍵を使ってシール解除(unseal)が必要です。

　Vault はマスタ鍵を保管しません。少なくとも３つの鍵がなければ、
　Vault はシールされたままです）

「rekey」と「rotate」コマンドいずれも、オンラインでサービスの中断なしに行わなくてはいけません。また、複数の Vault インスタンスを使った HA 環境でも動作します。

■ PKI シークレット・バックエンド

Vault の新しい「pki」バックエンドを使うことにより、Vaul を内部の認証局（internal certificate authority）として使えるようになりまます。クライアントから要求があれば、バックエンドは x509 証明書を生成するために、Vault の動的なシークレット機能を使います。

内部 PKI のセットアップとは、自動的に証明書を生成し、それらを配布し、適切に管理や更新・無効化の必要があったため、これまでは挑戦的な手法でした。そのため、多くの組織で長期間の証明書を使い続けたり、それらを管理システム上の設定で配布し続けなくてはいけないという問題を引き起こしていました。これにより大きな露出（訳者注；セキュリティ上の問題）に直面し、長期間にわたる証明書の使用という妥協により、CRL や OCSP の使用を制限する傾向にあります。

※訳者注：
・ CRL = Certificate Revocation List = 証明書失効リスト
・ OCSP = Online Certificate Status Protocol ）

Vault の「pki」バックエンドを使えば、この手順をより簡単に、より安全にします。オペレータは Vault から root または中間証明書を簡単に入手出来るので、証明書が必要な役割に応じて様々な定義ができます。Vault のクライアントは、必要に応じて証明書をリクエストすることができ、都度オンデマンドで生成されたものを受け取れます。長期間にわたる証明書を使い続ける代わりに、Vault であれば直近１分だけの証明書を作成したり、定期的に更新したりも可能となります。そうすることで、妥協によって露出するのを制限し、自動的に CRL（証明書失効リスト）と組み合わせることで、証明書の発行をより確実なものとします。

$ vault write pki/issue/common common_name=www.hashicorp.com
Key             Value
lease_id        pki/issue/common/819393b5-e1a1-9efd-b72f-4dc3a1972e31
lease_duration  259200
lease_renewable false
certificate     -----BEGIN CERTIFICATE-----
MIIECDCCAvKgAwIBAgIUXmLrLkTdBIOOIYg2/BXO7docKfUwCwYJKoZIhvcNAQEL
...
az3gfwlOqVTdgi/ZVAtIzhSEJ0OY136bq4NOaw==
-----END CERTIFICATE-----
issuing_ca      -----BEGIN CERTIFICATE-----
MIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV
...
-----END CERTIFICATE-----
private_key     -----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA0cczc7Y2yIu7aD/IaDi23Io+tvvDS9XaXXDUFW1kqd58P83r
...
3xhCNnZ3CMQaM2I48sloVK/XoikMLb5MZwOUQn/V+TrhWP4Lu7qD
-----END RSA PRIVATE KEY-----
serial          5e:62:eb:2e:44:dd:04:83:8e:21:88:36:fc:15:ce:ed:da:1c:29:f5

この「pki」バックエンドこそが、 Vault を単にシークレット・データを保管する以上に、セキュリティ基盤として利用する別の例なのです。「pki」バックエンドを使うことにより、組織間で相互な TLS の受け入れを簡単にし、全く信頼出来ないデータセンタ（訳者注；ネットワークの意味）からの移行を始められます。このバックエンドに関する貢献と Akamai のスポンサリングにおいて、Jeff Mitchell に大きな感謝を表明します。

■ トランザクション毎に鍵生成（Per-Transaction Derived Keys）

「transit」シークレット・バックエンドは Vault の初期リリースから利用可能でした。Vault のバックエンドに transit を使うことで、暗号化と複合化を楽にします。私達は以前のブログで、Atlas に保管された機密性の高いデータを保護するために、どのように Vault を使っているかを書きました。

根底となるのは、transit バックエンドが名前付けされた鍵のセットを管理することです。鍵は Vault の中に保持され、Vault の中でプレーンテキスト（文字列）は暗号化されて送信するか、あるいは暗号化テキストを復号化して送信します。これにより、クライアントは暗号化鍵を持たなくても、データを操作することができます。つまり、ウェブ・ブラウザにおける PII 情報（訳者注；Personal Identifiable infomation＝個人識別情報）の管理を簡単にし、その一方で、スケーラブルなストレージとして RDBMS も使い続けられるのです。

Vault 0.2 では、「transit」バックエンドは名前鍵（named key）のプロパティで「derived」の設定をサポートしています。鍵をプロパティ付きで生成すると、あらゆる暗号化や複合化の作業に、必ずプレーンテキストや暗号文と一緒に「context」の提供も必要です。

この「context」は派生鍵（derived key）を作成するための raw 暗号鍵として使われます。このトランザクション鍵とは、安全な高暗号化鍵から派生したもので、与えられたデータの暗号化や複合化に使います。これにより、各々のトランザクションで名前鍵が同じだとしても、異なった暗号鍵を使えます。あるトランザクションに対する妥協をしてしまっても、異なったコンテキストや raw 暗号化鍵を用いている、ほかのトランザクションのデータが晒されないようにします。

$ vault write transit/keys/foo derived=true
Success! Data written to: transit/keys/foo

$ CTX=`echo -n foo | base64`
$ vault write transit/encrypt/foo context=$CTX plaintext=`echo -n bar | base64`
Key           Value
ciphertext    vault:v0:DykggPIDCMz+vqrWsqa309HtQs2c3Y2BxedNCTlQQQ==

$ vault write transit/decrypt/foo context=$CTX ciphertext="vault:v0:DykggPIDCMz+vqrWsqa309HtQs2c3Y2BxedNCTlQQQ=="
Key          Value
plaintext    YmFy

$ echo YmFy | base64 -D
bar

鍵の生成を実装するにあたり、NIST SP 800-108 における推奨をベースとしています。

■ ACL ポリシーの改良

Vault のポリシー言語は、Consul ACL ポリシー言語による影響を受けています。Vault 0.1 でのポリシーは次のようなものでした：

path "sys/" {
    policy = "read"
}

path "secret/" {
    policy = "write"
}

このバージョンの時点では、全ての「path」節に含まれるパスは、デフォルトではリクエストするパスを塊で指定する必要がありました。そのため、完全一致のポリシーを指定出来ませんでした。これを完全一致ポリシーの指定ができるようにしました。Vault 0.2 では、「*」ワイルドカードを使って範囲を明示するようにしました。

path "sys/*" {
    policy = "read"
}

path "secret/*" {
    policy = "write"
}

# 'foo' キーだけを許可
path "transit/encrypt/foo" {
    policy = "write"
}

次に、Vault は常に deny （拒否）するシステムのため、権限を指定しない場合は ACL は拒否になります。しかし、Vault 0.1 のポリシー言語では「deny」の優先度が低く、ブラックリストのようなパスの指定をするのが大変でした。Vault 0.2.0 では優先度が上がっています。そのため、次のような記述ができるようになります：

path "secret/*" {
    policy = "read"
}

path "secret/super-secret" {
    policy = "deny"
}

Vault 0.2.0 では１番目のルールによってあらかじめ許可されていたとしても、「secret/super-secret」パスに対する操作を拒否します。そのため、既存のポリシーファイルの変更が必要かもしれませんので、ご注意ください。

■ アップグレードの詳細

Vault 0.2 では「rekey」と「rotate」コマンドのような、内部の大きな変更を導入しました。ポリシー言語による指定・実施に関する変更も同様に実施しています。

あらゆるアップグレードを行うには、新しいバージョンの Vault がアンシールされた状態で、オンラインで行います。既存の暗号化鍵は、keyring（鍵リング）の場所へ更新されます。既存のポリシーは、これまでの節における指定方法が暗黙のまま動作するように更新されます。

Vault 0.2 固有の新しいポリシーを使おうとする場合は、あらかじめ全てのポリシーを更新しなくてはいけません。プロジェクトはまだ若く、仕様が変更したため、古い設定を使い続けることはできません。

■ ロードマップ

Vault 0.2.0 は、機能を拡張して多くの主な操作性や安定性に関する問題を修正したメジャーリリースです。そのため、新しい問題も発生するかもしれませんが、リリースの度に修正を続けます。私達はまもなく Vault の外部コード監査を開始予定です。

Vault 0.2 は「vault ssh」のサポートに集中していきます。これはワンタイム鍵やワンタイムパスワードによって、共有鍵の問題を解決します。ほかにも、新しいシークレット、認証方式、credential バックエンド、利便性の改善やバグ修正に取り組みます。

いつものように、当リリースにおけるアップグレードやテストを行う場合、異なった環境での実施を推奨します。問題がある場合は、Vault GitHub issue tracker に登録するか、Vault メーリングリストに投稿ください。

■参考

Vault 0.2 – HashiCorp
https://www.hashicorp.com/blog/vault-0-2.html