情報畑でつかまえてロゴ
本サイトは NTTテクノクロスが旬の IT をキーワードに
IT 部門が今知っておきたい最新テクノロジーに関する情報をお届けするサイトです

セキュアなOpenStack構築のためのBarbican(鍵管理サービス)の紹介 

OpenStackを用いたプライベートクラウドの構築が盛んになっており、OpenStackのセキュリティにも関心が高まってます。OpenStackのセキュリティ強化の一環としてbarbican(鍵管理サービス)がインキュベーションとして開発がすすめられていますが、4月30日に提供されたOpenStack kiloで、ようやく鍵管理インタフェースが実装され利用可能になったとのことでしたので、barbicanの動作確認状況等を紹介いたします。

1. はじめに

 OpenStack はJuno版で、バグフィックスや既存機能の強化が図られて品質的にも安定化しており、今後、OpenStackを用いたプライベートクラウドの構築が加速することが期待されています。

OpenStackが成熟するにつれて、セキュリティ確保が優先事項となっており、「OpenStack Security Guide[*1]」が作られ、セキュリティの強化も進められています。

このOpenStackのセキュリティ強化の一環としてbarbicanと言われる鍵管理サービスの開発がインキュベーションとして進められています。

2015年4月30日に提供されたOpenStack kiloで、ようやくcinderやnovaの鍵管理インタフェースが実装されbarbicanとの内部連携が可能になったとのことでしたので、早速使って完成度を確認してみましたので、紹介いたします。

2. 鍵管理サービス[*2]とは

情報システムではセキュリティ確保のために随所で暗号技術が活用されています。この暗号を利用したシステムのセキュリティ要素である機密性・可用性・完全性を維持するためには、暗号鍵の管理が必要になります。この暗号鍵の管理が疎かであれば、下記の様な事象が発生し、システムのセキュリティを大きく損なう可能性があります。

・同一の暗号鍵を適切な利用期間を超えて使用し続ける。

・秘密鍵を誰でもアクセス可能な記録媒体に記録する。

・暗号鍵自体や、暗号鍵と暗号化した情報(秘匿や署名の対象となる情報)との関連付けに関する情報を失う。

・漏えい等の問題が疑われる暗号鍵を使い続け、新たな暗号化や署名を行う。

このようなことが起こらないように暗号鍵を安全に管理する機能を提供するものが「鍵管理サービス」で、次の様な機能が求められます。

a)暗号鍵などの機密情報を配布可能とする安全な保管場所の提供

b)全ての機密情報に対するポリシーの集中管理と適用(暗号鍵へのアクセスを限定し、取り扱うことが許された者のみが鍵を利用可能とする)

c)適切な乱数を用いた暗号鍵の生成

d)鍵のライフサイクル管理

これにより、暗号鍵と暗号データの分離管理も可能となります。

3. クラウドになぜ鍵管理サービスが必要なのか

セキュアなOpenStackでクラウドを構築する場合、「表1」に示すように多くのセキュリティ上の考慮点が「OpenStack Security Guide」では指摘されています。

表1. セキュアなOpenStackを構築するためのセキュリティ上の考慮点

OpenStackコンポーネント

セキュリティの考慮点

Compute(nova)

VMインスタンスの分離

OpenStackサブコンポーネント間のセキュアな通信。

利用者向けに公開されたAPIエンドポイントへの高可用性(resiliency)でセキュアな通信

Object Storage(swift)

データへのアクセス制御

転送時も含むデータの暗号化

データの不正アクセス(相互認証の中間者攻撃など)

Block Storage(cinder)

同上(Object Storage)

Networking(neutron)

 

テナント毎のネットワーク・トラフィックの分離

中断することなく通信できること(可用性)

通信データが破壊、改ざん又は消去されていないこと(完全性)

認められた者だけが、通信できること(機密性)

Dashboard(horizon)

webサービスに一般的に求められるセキュリティ対策

(アクセス制御、認証認可、XSS、バッファーオーバフロー等)

Identity (keystone)

アクセス制御(ID管理)

認可トークンの管理

セキュアな通信

Image (glance)

イメージのライフサイクル管理処理の信頼性

Data processing

(sahara)

データのプライバシー(テナントデータの分離)

提供されたクラスタへのセキュアな通信

Other:

メッセージキューのセキュアな通信

データベースのアクセス制御など

これらのセキュリティ上の考慮点は、OpenStackに限った問題ではなく、クラウドサービスに共通する考慮点で、「VM利用者間での利用環境の論理的な分割が不適切」など、多くの共通のセキュリティ上の考慮点が「クラウドセキュリティガイドライン活用ガイドブック(2013年度版)[*3]」でも取り上げられており、鍵の管理が煩雑になるため、「鍵管理サービス」を利用するこが推奨されています。

セキュアなOpenStackの構築の場合も、「鍵管理サービス」を利用することで鍵の管理が容易になり、暗号が利用し易くなるものと期待されます。

4. OpenSackの鍵管理サービスbarbicanを使ってみた!

現在は、まだ、OpenStackのインキュベーションサービスですが、クラウドサービスのためにテナント毎の暗号鍵を管理する鍵管理サービスがBarbian[*4/5]です。

これまでは、cinderやnovaとの連携が図られておらず、実際に利用することはできませんでしたが、4月30日にリリースされたkilo版で、内部連携が実装されたとのことでしたので、早速、barbicanを使ってみました。

4.1. インストール

 既にDevstackで構築したOpenStack kilo環境がありましたので、下記の手順でbarbicanを追加インストールしました[*6]

$ git clone https://github.com/openstack/barbican.git

$ mv barbican/contrib/devstack/lib/barbican devstack/lib/

$ mv barbican/contrib/devstack/extras.d/70-barbican.sh devstack/extras.d/

また、barbicanを有効にするために、既にあるlocalrcファイルに、次の行を追加しました。

...

enable_service barbican

...

BARBICAN_BRANCH=stable/kilo

...

これでインストールの準備が整いましたので、barbicanを含むOpenStackのインストールをDevstackを用いて実施しました。

$ cd devstack

$ ./stack.sh

一方、barbicanの呼出にはcinder(<installed path>/cinder/keymgr/barbican.py)やnova(<installed path>/nova/keymgr/barbican.py)のソースコードを見ると、barbicanのpythonクライアントが用いられていますので、pipを用いてpython-barbicanclientをインストールしました。

$ sudo pip install python-barbicanclient

barbicanが正しくインストールされたのか確認するために、CLI[*7]で動作確認しました。ここでは、公開鍵暗号(RSA)鍵の生成をbarbicanに依頼し、その結果を参照しています。

$ source openrc

$ export OS_REGION_NAME=RegionOne

$ export BARBICAN_ENDPOINT=http://127.0.0.1:9311

$ barbican --debug order create --name "rsa key" --type "asymmetric" --algorithm "rsa" \

--bit-length 2048 --mode "cbc" --payload-content-type "application/octet-stream"

...

$ barbican order list -f yaml

- {Container href: 'http://localhost:9311/v1/containers/7feb852e-1dad-488f-a06b-2d853f71d09e',

Created: !!timestamp '2015-05-20 04:12:23+00:00', Error code: null, Error message: null,

Order href: 'http://localhost:9311/v1/orders/1432de16-ab5c-4b04-87b3-07d6d9fafbfc',

Secret href: N/A, Status: ACTIVE, Type: Asymmetric}

$

4.2. 環境設定

次に、Devstackでインストールされた状態のcinderとnovaの設定(コンフィグファイル)は、デフォルトで鍵管理(keymgr)に固定鍵を利用する設定となっています。この鍵管理(keymgr)の設定をbarbican利用にするため、cinderとnovaの設定変更と再起動を行う必要があります[*8]

具体的には、cinderの場合は、設定ファイル(/etc/cinder/cinder.conf)の末尾に、下記を追記して、cinderを再起動します。

...

[keymgr]

api_class=cinder.keymgr.barbican.BarbicanKeyManager

encryption_auth_url=http://localhost:5000/v3

encryption_api_url=http://localhost:9311/v1

novaの設定ファイル(/etc/cinder/cinder.conf)の場合は、なぜか固定鍵(fixed_key)が設定されていましたのでコメントアウトし、以降に鍵管理(keymgr)の設定だけでなくbarbican等の設定追加を下記の様に行い、novaを再起動しました。

...

[keymgr]

#fixed_key= fa4b60c1979b677c964d91a1438167eb6f7b9fb4cda0444482b03f6e9b7ec9ff

api_class =nova.keymgr.barbican.BarbicanKeyManager

[barbican]

catalog_info = key-manager:barbican:public

endpoint_template = http://localhost:9311/v1

insecure = False

os_region_name = RegionOne

[ephemeral_storage_encryption_opts]

enabled = True

4.3. VMの作成

「OpenStack Configuration Reference[*8]」の「2.Block Storage」の固定鍵によるボリューム暗号化(Volume encryption)を参考に、barbicanを用いてテナント毎に鍵を生成した暗号化ボリュームと、比較のために暗号化を行っていないボリュームを組込んだVMの作成を、以下の手順で実施しました。

volume type "LUKS"の作成

$ cinder type-list

cinder type-listの結果(1)

$ cinder type-create LUKS

$ cinder type-list

cinder type-list(2)

②volune type "LUKS"に、暗号アルゴリズムや鍵長など暗号化属性を付与

$ cinder encryption-type-create --cipher aes-xts-plain64 --key_size 512 --control_location front-end LUKS nova.volume.encryptors.luks.LuksEncryptor

cinder encryption-type-create

③暗号化ボリュームの作成

$ cinder create --display-name 'encrypted volume' --volume-type LUKS 1

cinder create

このとき、内部的にcinderからbarbicanが呼出され、新たに鍵が生成されたことが、barbican鍵生成依頼(order)した結果を参照することで確認できます。

$ barbican order list -f yaml

- {Container href: N/A, Created: !!timestamp '2015-05-20 08:04:13+00:00', Error code: null,

Error message: null, Order href: 'http://localhost:9311/v1/orders/16e6ab4b-c5f6-4858-ac45-c5881c3d65a2',

Secret href: 'http://localhost:9311/v1/secrets/7e3bd800-4b34-49fc-80c2-6c9a6ef64cd2',

Status: ACTIVE, Type: Key}

④比較のために暗号化を行っていないボリュームを作成

$ cinder create --display-name 'unencrypted volume' 1

$ cinder list

cinder list

⑤動作確認を行うためのVMを起動

$ nova boot --flavor m1.tiny --image cirros-0.3.2-x86_64-uec vm-test

$ nova list

nova list


⑥起動したVMに、上記③で作成した暗号化ボリームの組込

$ nova volume-attach vm-test 0c6e29ba-2be4-45e1-8c29-0f41fba998c4 /dev/vdc

nova volume-attach(1)

⑦起動したVMに、比較のために上記④で作成した暗号化していないボリームの組込

$ nova volume-attach vm-test c7464b83-29e4-4a58-8806-027c733630a4 /dev/vdb

nova volume-attach(2)

4.4. 内部連携の確認

動作環境の構築は一見、正常に動作したように見えるのですが、もともとあった「固定鍵による暗号化ボリーム」との違いを明確にするため、cinderとnovaのコンフィグファイルに下記の設定を追加してログを分析することにしました。

connection_debug = 100

この設定を追加することで、データベースへのアクセスなどがログとして出力されるため、ログの分析が容易になります。

barbican、cinderおよびnovaのログから、VMの作成の過程での内部連携の状況を分析した結果を「図2」に示します。これから、暗号化ボリュームの生成(cinder create)時にcinderからbarbicanへ(共通)鍵の生成依頼(order)が行われ、novaに指定したVMへ作成した暗号化ボリュームの組込(nova volume-attach)を依頼した契機で、novaが先ほど作成された(共通)鍵をbarbicanから取得していることが確認でき、内部連携していることが確認できました。

図2. barbican、cinderおよびnovaの連携

図2. barbican、cinderおよびnovaの連携

4.5. 動作確認

暗号化ボリュームの動作を確認するために、起動したVMにログインして暗号化ボリューム/暗号化していなボリュームにデータの書き込み/読み出しを実施しました。

まず、当然のことながら暗号化していなボリュームに対して支障なくデータの書き込み/読み出しができることを確認しました。

$ sudo chmod 777 /dev/vdb

$ echo "Hello, world!" >> /dev/vdb

$ strings /dev/vdb | grep Hello

Hello, world!

$

暗号化ボリュームへのデータの書き込み/読み出しはどうでしょうか?

$ sudo chmod 777 /dev/vdc

$ echo "Hello, hoge!" >> /exdev/vdc

$ strings /dev/vdc | grep Hello

Hello, hoge!

$

これも、問題なく書き込み/読み出しが行い、利用者から見た場合は、暗号化ボリュームであることを意識ぜずに、暗号化していなボリュームと同様にアクセスできることが確認できました。

次に、第三者からはどの様に見えるかを確認するために、Devstack上で該当のボリュームの読み出しを行ってみなした。

$ sudo strings /dev/stack-volumes-lvmdriver-1/volume-* | grep Hello

Hello, world!

$

第三者からは、暗号化していなボリュームに書き込んだ「Hello, world!」は参照することはできましたが、暗号化ボリュームに書き込んだ「Hello, hoge!」が暗号化されて参照できないことが確認できました。

5. 今後について

今回、性能等の影響は対象外としていますが、機能的には、思っていた以上のレベルまで到達しており、今後は、実際のユースケースに基づいたSSL証明書の生成/更新/再発行/失効/取り消しなど証明書に関する機能拡張などが計画[*9]されており、早くインキュベーションを卒業してインテグレーションになることを期待して、継続してウォッチしていきたいと考えています。

【参考文献】

[*1] openstack‐security‐guide

(http://docs.openstack.org/security-guide/content/)

[*2] IPA 鍵管理ガイドライン(2008年7月)

(https://www.ipa.go.jp/files/000013895.pdf)

[*3]クラウドサービス利用のための情報セキュリティマネジメントガイドライン(2013年度版)

(http://www.meti.go.jp/press/2013/03/20140314004/20140314004-2.pdf)

[*4]Welcome to Barbican's developer Documentation

(http://docs.openstack.org/developer/barbican/)

[*5]cloudkeep/barbican ‐ Home

(https://github.com/cloudkeep/barbican/wiki)

[*6]BarbicanDevStack

(https://wiki.openstack.org/wiki/BarbicanDevStack)

[*7]python-barbicanclient 3.1.1

(https://pypi.python.org/pypi/python-barbicanclient)

[*8]OpenStack Configuration Reference

(http://docs.openstack.org/kilo/config-reference/content/)

[*9]Blueprints for OpenStack - barbican

(https://blueprints.launchpad.net/openstack?searchtext=barbican)

連載シリーズ
テクノロジーコラム
著者プロフィール
水町 肇
水町 肇

クラウド事業ユニット