データプライバシ関連¶

データの所在¶

データのプライバシーと分割は、ここ数年クラウド採用の最初の障壁としてずっと言及されてきました。クラウド中でデータを所有するのは誰か、このデータの管理人としてクラウドオペレータは結局信用できるのか否かという事は、これまで重要な問題でした。

多数の OpenStack サービス群は、テナントやテナント情報の所在に属するデータとメタデータを管理します。

OpenStack クラウドに保存されたテナントデータは以下の項目を含まれます：

Object Storage オブジェクト
Compute のインスタンスの一時的ファイルシステムストレージ
Compute インスタンスのメモリ
ブロックストレージボリュームデータ
Comptue アクセス用パブリックキー
Image service 内の仮想マシンイメージ
マシンのスナップショット
OpenStack Compute の設定用ドライブ拡張に渡されたデータ

以下の不完全な一覧を含む、OpenStack クラウドが保存したメタデータ:

組織名
ユーザの「実名」
実行中のインスタンスのサイズ、バケット、オブジェクト、ボリューム、その他クォータ関連の項目
実行中のインスタンス又は保存されたデータの経過時間
ユーザの IP アドレス
Compute イメージ作成用に内部で生成されたプライベートキー

データの処分¶

OpenStack オペレータは、ある一定レベルのテナントデータ破棄保証が提供できるよう努力しなければんりません。ベストプラクティスは、クラウドシステムメディア (デジタル・非デジタル) を破棄、組織コントロール外へのリリース、再利用の為の開放より前にオペレータがメディアをクリアする事を推奨しています。メディアのクリア方法は、特定のセキュリティドメインと情報のデリケートさが与えられた、適切なレベルの強度と完全性を実装すべきです。

"The sanitization process removes information from the media such that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, cryptographic erase, and destruction, prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal." NIST Special Publication 800-53 Revision 4

NIST が採用した汎用のデータ破棄とサニタイズのガイドラインは、セキュリティ制御を推奨しています。クラウドオペレータは以下のことをすべきです。

媒体サニタイズと破棄行為の追跡・文書化・検証を行うこと。
適切なパフォーマンスを検証する為、サニタイズ設備と過程の評価を行うこと。
持ち運び可能なリムーバルストレージデバイスをクラウドインフラに接続する前にサニタイズすること。
サニタイズできないクラウドシステム媒体を破壊すること。

OpenStack デプロイでは、以下の事も実施する必要があるでしょう。

安全なデータの消去
インスタンスメモリの消去
ブロックストレージボリュームデータ
Compute インスタンスの一時ストレージ
物理サーバのサニタイズ

安全に消去されなかったデータ¶

OpenStack 中でいくつかのデータは削除されるかも知れませんが、上記で触れた NIST 標準の文脈における安全な消去ではありません。これは一般に、データベースに保存された上記で定義したメタデータと情報の大半又は全てに当てはまります。これは、データベースとシステム設定のどちらか又は両方で、自動バキュームと定期的な空き領域のクリアを実施する事で解決する事ができるかも知れません。

インスタンスメモリの消去¶

Specific to various hypervisors is the treatment of instance memory. This behavior is not defined in OpenStack Compute, although it is generally expected of hypervisors that they will make a best effort to scrub memory either upon deletion of an instance, upon creation of an instance, or both.

Xen は、専用のメモリ範囲をインスタンスに明確に割り当て、インスタンス (又は Xen の用語でドメイン) 破棄時にそのデータをクリンアップします。KVM はより大いに Linux のページ管理に依存しています。 KVM のページングに関する複雑なルールセットは、 KVM documentation で定義されています。

Xen のメモリバルーン機能の使用は情報漏えいの結果になりかねないという事への注意は重要です。

これらや他のハイパーバイザでは、ハイパーバイザ毎のドキュメントを参照すると良いでしょう。

Cinder のボリュームデータ¶

Use of the OpenStack volume encryption feature is highly encouraged. This is discussed below in the Data Encryption section under Volume Encryption. When this feature is used, destruction of data is accomplished by securely deleting the encryption key. The end user can select this feature while creating a volume, but note that an admin must perform a one-time set up of the volume encryption feature first. Instructions for this setup are in the block storage section of the Configuration Reference , under volume encryption.

If the OpenStack volume encryption feature is not used, then other approaches generally would be more difficult to enable. If a back-end plug-in is being used, there may be independent ways of doing encryption or non-standard overwrite solutions. Plug-ins to OpenStack Block Storage will store data in a variety of ways. Many plug-ins are specific to a vendor or technology, whereas others are more DIY solutions around filesystems such as LVM or ZFS. Methods to securely destroy data will vary from one plug-in to another, from one vendor's solution to another, and from one filesystem to another.

Some back-ends such as ZFS will support copy-on-write to prevent data exposure. In these cases, reads from unwritten blocks will always return zero. Other back ends such as LVM may not natively support this, thus the Block Storage plug-in takes the responsibility to override previously written blocks before handing them to users. It is important to review what assurances your chosen volume back-end provides and to see what mediations may be available for those assurances not provided.

Image service の遅延削除機能¶

OpenStack Image service has a delayed delete feature, which will pend the deletion of an image for a defined time period. It is recommended to disable this feature if it is a security concern, by editing the etc/glance/glance-api.conf file and setting the delayed_delete option as False.

Compute のソフト削除機能¶

OpenStack Compute has a soft-delete feature, which enables an instance that is deleted to be in a soft-delete state for a defined time period. The instance can be restored during this time period. To disable the soft-delete feature, edit the etc/nova/nova.conf file and leave the reclaim_instance_interval option empty.

Compute インスタンスの一時ストレージ¶

Note that the OpenStack Ephemeral disk encryption feature provides a means of improving ephemeral storage privacy and isolation, during both active use as well as when the data is to be destroyed. As in the case of encrypted block storage, one can simply delete the encryption key to effectively destroy the data.

Alternate measures to provide data privacy, in the creation and destruction of ephemeral storage, will be somewhat dependent on the chosen hypervisor and the OpenStack Compute plug-in.

compute 用の libvirt プラグインは、ファイルシステム又は LVM 上の一時ストレージを直接管理出来ます。ファイルシステムストレージは一般にデータを削除する際に上書きはしませんが、ユーザに対して汚れたエクステンドが用意されないという保証があります。

ブロックデバイスベースである LVM をバックエンドにした一時ストレージを使用する場合、OpenStack Compute は情報漏えいを防ぐために、安全にブロックを削除する必要があります。これらには、過去において、不適切な一時ブロックストレージデバイスの削除に関連する情報漏洩の脆弱性がありました。

Filesystem storage is a more secure solution for ephemeral block storage devices than LVM as dirty extents cannot be provisioned to users. However, it is important to be mindful that user data is not destroyed, so it is suggested to encrypt the backing filesystem.

物理サーバのサニタイズ¶

Compute の物理サーバドライバは開発中だったのですが、ironic と呼ばれる独立したプロジェクトに移管される事になりました。この文書の執筆時点では、ironic には物理ハードウェア上にあるテナントデータのサニタイズ機能はまだありません。

Additionally, it is possible for tenants of a bare metal system to modify system firmware. TPM technology, described in セキュアブートストラップ, provides a solution for detecting unauthorized firmware changes.

データプライバシ関連