Microsoft Azure のデータ セキュリティ (データ クレンジングおよびデータの漏えい)
このポストは、5 月 5 日に投稿された Microsoft Azure Data Security (Data Cleansing and Leakage) (著者: Walter Myers III) の翻訳です。
免責: このドキュメントに記載されている手順は 2014 年 5 月時点で最新のものであり、予告なしに変更されることがあります。
Microsoft Azure へのアプリケーションのデプロイを検討している企業ユーザー (すべてのユーザー) にとって最も大きな心配の種となっているのがデータのセキュリティです。データ保護の見過ごされやすい点として、ディスク領域が解放され他のユーザーに割り当てられた場合、そのユーザーはその領域の解放時にそこにあったデータを読み取ることはできない、ということが保証されています。その極端な例は、廃棄または他の用途に使用するためにデータ センターからドライブが取り除かれるケースです。これを保証する最も正当な方法は、ディスク領域を解放する前にゼロまたはその他のパターンで上書きすることです。このような上書き処理はパフォーマンスに大きな影響を及ぼすので、(他の多くのシステムと同様に) Azure では、より複雑でありながらも効率的な手法を使用します。
この記事では、データの漏えいまたは Microsoft Azure Virtual Machine Instance、Microsoft Azure Virtual Machine Drives、Microsoft Azure Drives、Microsoft Azure Storage、SQL Database のデータ、または SQL Database インスタンス自体を削除した後に、顧客データが他の利用者に公開されてしまう可能性を防ぐために Microsoft Azure および SQL Azure ソフトウェアに実装されている対策について説明します。細かい点は異なりますが、どれもその概念は同じで、ユーザーが過去に自分で書き込みしていないディスク領域は読み取ることができない、というものです。
今回の記事の詳細は、Microsoft Azure のプリンシパル ソフトウェア エンジニアを務めるセキュリティ アーキテクトの Charlie Kaufman が執筆しました。彼が手がけた仕事には、こちらとこちらもあります。ぜひご参照ください。
データ保護の概念
実際のところ、ディスクは「わずか」しか割り当てられません。つまり、仮想ディスクが作成されてもすべての容量が割り当てられるわけではなく、仮想ディスクのアドレスを物理ディスク上の領域にマッピングするテーブルが作成されます。このテーブルは最初は空の状態で、利用者がデータを仮想ディスクに書き込むと物理ディスクの領域が割り当てられ、そのポインターがテーブルに格納されます。この概念的な流れを示したものが下の図です。
図 1: データ ブロックのユーザーへの割り当て
図 1 では、2 人のユーザーに書き込み要求に応じてそれぞれディスク上の 2 つのデータ ブロックを割り当てています。
図 2: ユーザーがデータ ブロックを解放
図 2 では、1 人のユーザーがデータを「削除」して、データ ブロックを解放しています。データ ブロックが解放されるだけで、それ以外の影響はありません。
図 3: 最近解放されたデータ ブロックをユーザーに割り当て
図 3 では、書き込み要求に対し、最近解放されたデータ ブロックおよび過去に割り当てられていないデータ ブロックが新しいユーザーに割り当てられています。過去に解放されたデータ ブロックにはまだ影響はありません。基本的なプロセスとしては、ユーザーがディスクへの書き込み要求を行うと、そのユーザーに割り当てられている既存のデータ ブロックに新しいデータを保存できる領域があるのかを確かめることが必要になります。領域がある場合は、新しいデータを既存のブロックのデータに上書きします。領域がない場合は、新しいデータ ブロックが割り当てられ、その新しいブロックにデータが書き込まれます。下の図はそのロジックを示しています。
図 4: ユーザーがディスクへのデータの書き込みを要求
ここで、ある利用者が削除したデータを別の利用者が読み取ってしまったり、ある利用者が削除したデータを Azure 管理者が読み取ってしまったりする可能性がないか、という問題があります。仮想ディスクのまだ書き込みのない領域を読み取ろうとすると、その領域にはまだ物理領域が割り当てられていないのでゼロが返されます。このロジックとその結果を示したものが下の図です。解放されたブロックは Azure 管理者のみ読み取ることができます。管理者がそのブロックの以前の所有者を特定できるようなユーティリティは存在しません。
図 5: ユーザーが読み取りを要求
概念的には、読み取り、書き込みを追跡するソフトウェアに関係なくこれが当てはまります。SQL Azure の場合は、この処理を実行する SQL ソフトウェアになります。Microsoft Azure Storage の場合は Microsoft Azure Storage ソフトウェアです。仮想マシンの永続性のないドライブの場合は、VHD がホスト OS のコードを処理します。カスタマー ソフトウェアは仮想ディスクにのみ対応 (仮想アドレスから物理アドレスへのマッピングは利用者の仮想マシン外部で行われる) するので、別の利用者に割り当てられている物理アドレスまたは解放された物理アドレスに対する読み取りまたは書き込みを要求する手段はありません。
メモ: 書き込みのロジック (図 4 を参照) が修正されている場合があり、その場合はブロックへの 2 回目の書き込みの際にデータはディスクに上書きされず、代わりに新しいブロックが割り当てられ、そこにデータが書き込まれます。古いブロックは空き領域とみなされます。このアプローチは「ログベースのファイル システム」と呼ばれます。非効率なようでもありますが、データの書き込みの多くが物理ディスク上の連続した場所で行われるため、シーク時間が短縮し、パフォーマンスが向上します。こうした細かい点は利用者には明示されませんが、仮想ディスクのブロックを解放する前にすべて明示的にゼロで上書きしたとしても、利用者のデータが物理ディスクから消えたということは保証されない、ということであるため、この情報は知っておく必要があります。
データの破壊および漏えいの防止
サブスクリプション全体、ストレージ、仮想マシン、データベースなど、破壊するデータ オブジェクトの種類によってデータの破壊手法は異なります。Microsoft Azure のようなマルチテナント環境では、データが他の利用者のデータに「漏えい」しないように、また削除したデータに他の利用者 (多くの場合、データを過去に所有していた利用者も含む) がアクセスできないようにするために十分な注意を払っています。
サブスクリプション
サブスクリプションが解約されると、関連するすべてのメタデータ (ストレージ アカウントも含む) は、誤って解約してしまった場合のために一定期間保持された後、削除されます。この猶予期間は 60 ～ 90 日間です。既存のサブスクリプションのストレージ アカウントを削除した場合 (またはサブスクリプションの削除の期限に達した場合)、実際にはそれからさらに 2 週間にわたって保持されます (これも、削除が誤りだった場合に元に戻せるようにするためです)。ストレージ アカウントが最終的に削除されると、あるいは BLOB やテーブル データがストレージ アカウントの削除とは別に削除されると、ディスク上のセクターがすぐに再利用可能になります。サーバーの空き状況や利用状況によって異なりますが、上書きされるまでに 2 日以上かかるようなことはほとんどありません。NTFS などのファイル システムではこれとは大きく異なり、ファイルを削除すると領域をすぐに再割り当てすることができますが、実際には数か月もそのままデータが残る可能性があります。ログ構造化ファイル システムの特性として、ログのコピーや圧縮によって、ディスクのすべての未割り当てセクターが定期的に上書きされます。
メモ: ストレージ データをもっと早く復元不可能にしたい場合は、ストレージ アカウントやサブスクリプションを削除する前にテーブルや BLOB を個別に削除します。削除される確実な日数は提示できませんが、これで 60 ～ 90 日ほど早く削除されるようになります。
Microsoft Azure Storage
前述のとおり、Microsoft Azure Storage はログ構造化ファイル システムを基盤としており、ディスクへの書き込みはすべてシーケンシャルに行われます。ディスクの「シーク」の回数が抑えられるため、従来のファイル システムよりも効率的ですが、小さな代償として、書き込みのたびにオブジェクトへのポインターを更新する必要があります。更新された新しいバージョンのポインターもディスクにシーケンシャルに書き込まれます。ディスクの読み取りはランダム アクセスですが、キャッシュを賢く利用することで読み取り処理の負荷を軽減できます。ただし、このシステムでは、ディスクに機密情報が記録されている場合、他のデータを上書きすることでその情報を消去できるという確証はありません。元のデータがディスクに残ったまま、新しい値がシーケンシャルに書き込まれます。ポインターが更新されるので、削除した値を見つける手段がなくなるということです。
ディスクが満杯になると、古いデータの削除によって解放されたディスク領域に新しいログが書き込まれます。ディスク セクターからログ ファイルを直接割り当てる代わりに、ログ ファイルが NTFS が稼働するファイル システムに作成されます。Azure Storage ノードで実行されているバックグラウンドのスレッドは一番古いログ ファイルをチェックし、一番古いログ ファイルから参照されているブロックを最新のログ ファイルにコピー (およびすべてのポインターを更新) して領域を解放します。そして最も古いログ ファイルを削除します。ディスクには 2 種類の空き領域があります。1 つは NTFS が空き領域だと認識しており、このプールから新しいログ ファイルを割り当てる領域であり、もう 1 つはポインターが存在しないため Azure Storage が空き領域だと認識しているログ ファイル内の領域です。
ここで、ユーザーから「削除したデータはまだディスクから復元できてしまうのではないか?」と問われるかもしれません。これは、次の 2 つのいずれかの意味として受け取れます。
- 1 つは、「賢いユーザーなら、正しい BLOB 名とオフセットがわかれば、ディスク分析ツールを使って BLOB に保存されていた値を見つけてしまうのでは?」という意味です。そのとおり、データとポインターがまだログ ファイルに残っている場合は可能です。
- もう 1 つは、「ディスクを 1 トラックずつチェックすることでデータを見つけることができるが、だれがそこにデータを保存したのかはわからないのではないか? (データの内容から推測できない限りは)」という意味で、ログ ファイルの削除によって空いた領域にまだ新しいログ ファイルに割り当てられておらず、上書きもされていない場合は可能になります。
この場合、一定の有効期限はなく、むしろ「半減期」に似ており、X 日後もディスク上に残っている確率は 50%、2X 日後は 25%、というように減っていきます。確率がゼロになることはなく、また特定のデータが削除されるという保証もありませんが、マイクロソフトは利用者のデータを不正なアクセスから保護することを約束しています。
Microsoft Azure Virtual Machines
仮想マシンは Microsoft Azure Storage に BLOB として保存されているので、上記で説明した削除時のルールが当てはまります。仮想マシンが削除されると、ローカルの仮想ディスクのコンテンツを保持していたディスク領域が空き領域とみなされます。ただし、ゼロで埋められてはいません。この領域はいずれ別のオブジェクトのデータを格納するのに利用されますが、不要になったコンテンツが削除されないままでいる時間の上限はありません。ただし、仮想化では、データが再び書き込まれるまでディスクの特定箇所を別の利用者 (または同じ利用者) が読み出せないようになっており、データ漏えいのおそれはありません。新しい仮想ディスクが仮想マシン用に作成されると、仮想マシンではゼロ埋めされているように見えますが、これは、仮想ディスクに書き込みをする前に読み取りを行った場合にバッファーが明示的にゼロ埋めされるため、そう見えるのです。仮想マシンのインスタンスの再初期化は、新しいハードウェアに移動した場合と同じ結果になります。
Microsoft Azure VM Drives および Microsoft Azure Drives (“X-Drives”)
Microsoft Azure の仮想マシン インスタンスがアクセス可能な仮想ドライブは 2 種類あります。Web ロールおよび Worker ロール用の C:、D: および E: ドライブはコンピューティング ノードのローカル ディスクでバックアップされています。データは冗長保存されていないので、一時的なデータです。ハードウェア障害が起こると、仮想マシン インスタンスは別のノードに移動され、仮想ディスクのコンテンツは初期値にリセットされます。仮想マシンのインスタンスが再初期化されると、C:、D:、E: の各ドライブは初期の状態に戻ります。新しいハードウェアに移動した場合と同じです。
Microsoft Azure Drives (別名 “X-Drives”) も Microsoft Azure Storage の BLOB として実装されています。X-Drive は永続的で、利用者が明示的にリプレースするよう措置を講じた場合を除き、リセットされることはありません。このデータは冗長保存されるため、ハードウェア障害が発生しても消えてなくなることはありません。仮想マシンのインスタンスを削除しても、関連する X-Drive のデータは削除されません。BLOB 自体を削除すると (または BLOB を格納しているストレージ アカウントを削除すると) X-Drive が削除されます。
Azure SQL Database
Azure SQL Database では削除されたデータは削除されたとみなされますが、ゼロ埋めされてはいません。データベース全体の削除は、そのコンテンツ全体を削除したのと同じです。SQL Database の実装は、SQL Database API の使用を除き、ストレージへのアクセスを一切禁止することで使用されたデータの漏えいを防いでいます。この API を使ってデータの読み取り、書き込み、削除を行うことが可能ですが、自分が以前に書き込んだものではないデータを読み取ることはできません。
自動バックアップおよびフォレンジック
一般に求められるのは、データに不正にアクセスできないように保護することですが、削除されたデータへの正規のアクセスもできないようにして欲しいと求められる場合もあります。データは一度削除または変更されると、利用者に公開されているインターフェイスから取得することはできません。データはディスク上に一定期間保存され、理論的には内部フォレンジック ツールで復元することが可能です (ただし、削除されたデータが存在する可能性は実際は時間の経過と共に小さくなります)。最終的には、物理ディスクは本番環境から取り除かれた後、完全に消去または破壊されます。
マイクロソフトでは、利用者が明示的にバックアップしなくても、削除されたデータの復元 (および変更されたデータの復元) を一定期間、許可する機能を検討中です。こうしたツールを使えば、データを削除した後すぐに正規ユーザーでもそのデータにアクセスできないようになるという保証はありません。このようなツールは、削除されたデータを 30 日未満の一定期間、取得可能にする設計になるです (利用者がこれよりも長いバックアップ期間を選択した場合を除く)。この記事を執筆している現時点でも、Azure SQL Database から削除されたデータの復元を 14 ～ 21 日間許可する未公開ツールがあります。Azure Storage や Azure Compute の一時ディスク向けのこのようなツールは存在しません。