安全な廃棄のために使用すべきストレージの機能(1/2)

# はじめに
　もう昨年（2019年）の話になってしまいましたが、「個人情報が保存された自治体のHDDが、廃棄処理委託先業者の従業員によって、データ復元可能な状態のまま転売された」、という事件がありました。

　既に多くの方がそれぞれお持ちの知見からこの事件について解説されていますが、この手の話は時間が経過すると忘れられてしまうことが多いので、定期的に話題にすることで注意喚起する必要があると考えています。

　そこで今回は、この事件を題材に、ストレージを安全に廃棄するために使用すべきストレージの機能として**データ難読化**と**ロック**を挙げ、具体的なロックの方法を説明します。データ難読化は次回まとめる予定です。

　なお、ストレージに格納されたデータが流出する状況には、以下の2つがあります。

1. ストレージがオンライン（ホストに接続され通電状態、正規のアクセス権を持ったアカウントがデータにアクセス可能な状態）でのデータ流出
2. ストレージがオフライン（非通電状態）でのデータ流出（物品流出）

　この2つは構図が全く異なるので、適用すべき対策も大きく異なります。前者は、正規のアクセス権を持ったアカウントによる意図的なデータ流出、コンピュータウィルス、クラッキングなどによるデータ流出のことです。
　今回の事件は後者にあたりますので、この記事では後者に限定して説明します。

# サマリ
* 今回の事件の最も大きな原因は、**ストレージの内容が容易に解読できる状態（難読化なし）だった**こと
* それに加えて**ストレージの内容が読み出せる状態（ロックなし）だった**こと
* 「信用の範囲」が明確でなかった（定義されていても機能していなかった）ことも原因のひとつ

# 今回の事件と「あるべき姿」
## 事件の構図
　まず、今回の事件がどのような構図だったのかを改めて確認します。

　報道内容<sup>[1][2]</sup>や時系列でまとめられた記事<sup>[3]</sup>からは、今回の事件の構図は図1のようになります（一部簡略化と推測を含む）。
　なお、同一組織内に関係者を複数図示しているのは今後の説明のためです。

![今回の事件の構図（一部簡略化と推測を含む）](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/95bf191b-47eb-839c-07d2-9724459cdfa2.png "今回の事件の構図（一部簡略化と推測を含む）")
図1：今回の事件の構図（一部簡略化と推測を含む）

　引き渡された（売却された）HDDを本来廃棄する（少なくともデータを読めなくする；難読化する）契約だった業者の従業員（図1の「丙」）が、難読化（物理破壊やデータ消去）していない状態のHDDを横領してネットオークションで転売した、というのが事件の内容です。

## 「データ流出」の責任は「データの所有者」にある
　図1の「丙」が所属する会社の資産を横領できたことも原因のひとつですが、「データ流出」の原因は別にあります。**この記事では「データ流出（恐れ）の原因」に焦点を絞ります**。

　この「データ流出の原因」は、**「保存対象データを格納したストレージ」を運用していた（個人情報を保持し、そのストレージに個人情報を記録していた）組織にある**と言えます。

　これは、図1の「丙」が転売したストレージからデータを復元できたことから、以下の3点がわかるもしくは推測できるからです。

### (1) データが難読化されていなかったこと
　まず一つ目は、データを所有する組織の手を離れた時点で**ストレージの内容が難読化されていなかった**ことです。

　ストレージの内容が難読化さえされていれば、たとえ転売されてもデータは復元・解読できず、データ流出のおそれはなかったはずです。

　物理破壊も難読化の方法の一つですが、他にも難読化の方法はあります。少なくともストレージの（論理）フォーマットは難読化の方法ではありません。フォーマットは「使う準備をする処理」です。

　また、「暗号化」と「難読化」は同じことではありません。暗号化を解除（復号）するための情報（暗号鍵など）の適切な管理をして初めて「難読化」が実現できます。詳しくは次回まとめる予定です。

### (2) ストレージがロックされていなかったこと
　二つ目は、データを所有する組織の手を離れた時点で**ストレージがロックされていなかった**ことです。

　ロックはあくまで「権限を持った人（アカウント）しか内容にアクセスできないようにする」という「アクセス制御」の方法です。難読化せずにロックのみ適用した状態のストレージは、ロックを回避されるとストレージに記録されたデータに容易にアクセスできてしまいます。つまり、ロックという手段はデータ流出を防止する手段としては不十分です。

　しかし、**ロックすらしていない状態で第三者の手に渡すということは、その第三者にデータを見られても構わないと言っていることと同じ**です。

　以上の2点から、データ流出の原因は、転売されたストレージに個人情報を保存していた組織にあると言えます。

　たとえ廃棄業者が「物理破壊した証拠写真」を提出しても、廃棄業者が物理破壊前にデータを読み出した可能性や「証拠写真」が捏造である可能性は残り、このような運用ではこれらのケースに対応できません。

### (3) 「信用の範囲」が定義されていなかったのでは？
　上記2点からは、図1の「組織」において、「信用の範囲」（図2）が定義されていなかった（されていたとしても機能していなかった）のではないか、と推測できます。

![明確にすべき「信用の範囲」](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/649c9ff4-c46c-2ea9-27a2-184ed6942083.png "明確にすべき「信用の範囲」")
図2：明確にすべき「信用の範囲」

　既にお気づきの方も多いと思いますが、図1の「丙」が受け取った時点でHDD内のデータが復元可能だったということは、「乙」が悪意を持って試みれば同じことができたことになります。

　例えば、「丙」に引き渡す予定のストレージ台数を「乙」が改竄できた場合、「乙」が悪意を持って横領・転売すれば今回の事件と同じことが起こり得ます（図3）。

![起こり得た事態の構図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/f32f3227-b2ef-c3d9-102f-451aab537a14.png "起こり得た事態の構図")
図3：起こり得た事態の構図

　昨今の個人情報漏洩・流出事案では、データを所有していた組織は、たとえ法を犯していなかったとしても、何らかの責任を追及されています<sup>[4]</sup>。これは、クラッキング等により運用中の媒体から漏洩した場合でも、今回のような形で運用を終了した媒体から漏洩した場合でも同じです。

　つまり、図1のように組織外の人間が漏洩した場合でも、図3のように組織内の人間が漏洩した場合でも、結果として**データの所有者である「組織」が責任をとることになる**わけです。

　なのに、データ難読化を施さずましてやロックもしていないストレージを第三者に渡した、という時点で、**データの所有者は「誰を信用して誰を信用しないか」をきちんと定義・対策していなかった**、と言わざるを得ません。

## あるべき姿
　データ所有者に責任がある理由として、「難読化」と「ロック」の2つが適用されていなかったことを挙げました。

　ここで、「難読化」と「ロック」の違いを改めて確認しておきます。難読化とロックの違いをまとめたものが図4です。

![難読化とロックの違い](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/a2aec45f-e88d-9367-5ffd-6039ed3f9861.png "難読化とロックの違い")
図4：難読化とロックの違い

　難読化が直接「データ保護」を目的とした方法であるのに対して、ロックはあくまでもアクセス制御が目的の方法です。その違いは、記録する・されているデータもしくは記憶媒体に手を加えるかどうかです。難読化は手を加えますが、ロックは手を加えません。

　ロックの有無は「誰がデータにアクセス可能か」を明確にする方法でありデータ所有者による意思表示です。ロックされていないストレージは、「データ所有者が、誰でもデータにアクセスしても良いと認めたストレージ」と同然です。したがって、正規のアクセス権を持たない人（アカウント）にストレージが渡る時点でロックされているべきです。

　したがって、今回の事件での運用の姿とあるべき廃棄時の運用の姿を対比すると、図5のようになります。

![今回の事件での運用の姿とあるべき運用の姿](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/91c7ba89-4e46-587d-106f-813c120d35cf.png "今回の事件での運用の姿とあるべき運用の姿")
図5：今回の事件での運用の姿とあるべき運用の姿

　今回の事件では、ロックも難読化も適用されていなかったので、組織外の第三者でもストレージの内容を「意味のある情報」として取得することが可能でした。

　これに対して「あるべき運用」では、ストレージが正規のアクセス権を持たない人に渡る際に、難読化とロックを施します。

　このようにすることで、もし何らかの方法でロックを回避できたとしても、データは難読化されているので、読み出せたデータ（断片）から意味のある情報を取得するのは非常に困難です。

　難読化を物理破壊で実現する場合、ストレージが甲の手を離れる時点で、データが復元できないほどに物理的に破壊する必要があります。

　難読化を暗号化で実現する場合、ストレージが正規のアクセス権を持たない人に渡る時点で、データを書き込んだ時に使用した暗号鍵に関する情報がストレージに残らないような措置を施す必要があります。

　具体的には、復号鍵の作成に十分な情報をストレージ自身が持たない、もしくは持っていても取り出せない（復号鍵をストレージが持たない情報で暗号化する）仕組みの製品を使う、ストレージが正規のアクセス権を持たない人に渡る前にストレージが持つ復号鍵に関する情報を消す（変える）、などが必要です。

　このような情報の適切な管理（処理）ができて初めて「暗号化」機能を使用した「難読化」が実現できます。

# ストレージのロック
**＜機構と実行は簡潔だがストレージ内のデータが難読化されないことに注意＞**

　前述の通り、ストレージの廃棄時などに正規アクセス権を持たない人にストレージ（装置）が渡る場合、ストレージをロックすることで、格納されているデータにアクセスできないようにするべきです。

　データ復元ソフトウェアなどでは、ストレージ内のファイルシステムの情報（残骸）を読み出すことで、例えばファイルシステムの（論理）フォーマット前状態の復元やファイルのサルベージが行われます。

　しかし、上記の方法ではあくまでも「ストレージからデータが読み出せること」が前提条件ですから、ロックされていてデータが読み出せないストレージに対しては手も足も出ません。

　再度の説明になりますが、ロックという機構はあくまで利用者が正しいロック解除情報を持っていることを認証するだけであって、ストレージに記録されているデータを難読化するわけではありません<sup>[5]</sup>。

　最も一般的なロックの方法である「パスワードロック」の場合、「ロック解除に必要なパスワードが失われるとデータにアクセスできなくなる」、「起動時に毎回ロック解除パスワードの入力を求められるのは煩雑」、という点がデメリットとして良く挙げられます。

　ただ、**「廃棄」というケースに限定すれば、廃棄後はストレージ内のデータを読み出すことはない（読み出せては困る）わけですから、ランダムに作成した、誰も覚えられない（「甲」ですら思い出せない、容易に再生成できない）パスワードを使っても構わないはずです**。

　**逆に言えば、仕様上許された最強のパスワード（ランダムに作成した、仕様が許す最長文字数のパスワード）を使ってでもロックするべきです**。

　それではSATAストレージとNVMeストレージについて、具体的なロックの方法を説明します。

### SATAストレージの場合
　SATAストレージの場合、ロックの方法には2通りあります。
　ひとつはSATAストレージが準拠する"ATA Command Set"という仕様の機能を使う方法で、もうひとつは[Trusted Computing Group (TCG)](https://trustedcomputinggroup.org/)が定めた機能を使う方法です。

　後者についてはNVMeストレージの方で説明することとして、ここではATA Command Setが定める機能を使う方法について説明します。

　ATA Command Setには、"ATA Security Feature Set"という機能が定義されていて、この機能をサポートしているSATAストレージであれば「ATAパスワードロック」という機能が利用可能です。

　パスワードは、BIOSで設定する方法<sup>[6][7]</sup>や、専用アプリケーションソフトで設定する方法<sup>[8][9]</sup>があります。

　BIOSで設定する場合、ストレージに対して明示的にパスワードを設定しなくてもATAパスワードロックのためのパスワードを設定できる場合もあります。

　また`hdparm`コマンドでもこのパスワードを設定できます<sup>[10]</sup>。

　ATA Security Feature Setのパスワードロックに関する仕様は、図6の簡易状態遷移図のようになっています。

![ATA Security Feature（パスワードロック関連）簡易状態遷移図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/7168e726-cf94-616a-db4a-750860d68dd8.png "ATA Security Feature（パスワードロック関連）簡易状態遷移図")
図6：ATA Security Feature（パスワードロック関連）簡易状態遷移図（[11]より作成）

　図6の通り、パスワードを設定して一旦ストレージの電源を切ると、以降は電源を入れるたびにロックされた状態になり、正しいパスワードによってロックを解除しない限りストレージにはアクセスできません。

### NVMeストレージの場合
　実は、NVMeの仕様には、SATAのATAパスワードロックのような「ストレージをロックする機能」は**存在しません**。したがって、NVMe以外の仕様が定める機能と組み合わせて実現します。

　標準化された方法には、Trusted Computing Group (TCG)が定めた機能を使用する方法があります。この方法は、ストレージが対応していれば、SATAストレージでも使用可能です。

　TCGが定めたセキュリティに関する機能群(Security Subsystem Class; SSC)には様々な機能があり、その機能を利用することでSATAのパスワードロックと同等の機能を実現できます。

　以下の図7は、TCGのSSC (Opal SSC)で設定可能なアクセス制御のイメージです（[12][13]から作成）。

　TCG Opal SSCは、図7 (A)のように細かいLBA領域（"Locking Range"と呼ばれる）単位でアクセス制御可能です。これを応用すれば、図7 (B)のようにATAのパスワードロック相当（ストレージ全体をロックする）の設定が可能です。

![TCG SSCによるアクセス制御（イメージ）](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/8b7d71ab-625f-7ec2-a6f8-8547ef36f803.png "TCG SSCによるアクセス制御（イメージ）")
図7：TCGのSSCによるアクセス制御（イメージ）

　TCGは、Opal SSCのサブセットとしてOpalite SSCとPyrite SSCを定めています。
　Opalite SSCはOpal SSCを簡略化したもので、Pyrite SSCはOpalite SSCから暗号化に関する仕様を抜いたものです<sup>[14]</sup>。

　このOpalite SSCもPyrite SSCも、図8中のLBA Rangeとして少なくとも"Global"を定義していますので、図7 (B)の設定が可能です。

　実際に、TCG Opal SSC（またはOpalite SSC、Pyrite SSC）を使用してNVMeストレージをロックするには、**対象のNVMeストレージがTCG Opal SSC（またはOpalite SSC、Pyrite SSC）に対応していることと、ストレージを操作するソフトウェアが必要**です。

　ストレージを操作するソフトウェアには、単独のソフトウェア製品<sup>[15][16][17]</sup>や、Microsoft Windows 10のProfessional以上のエディションで利用できるBitLocker、などがあります。たいていは、暗号化に関する機能と一緒になっています。

# まとめ
　この記事では、ストレージ廃棄時のような、ストレージがオフライン（非通電状態）でのデータ流出（物品流出）に論点を絞り、ストレージを安全に廃棄するために使用すべきストレージの機能としてデータ難読化とロックを挙げ、ロックについて説明しました。

　HDDもSSDも大容量化の一途をたどっていて、今回の事件を見るまでもなく廃棄時のデータ流出対策は喫緊の課題です。「信用の範囲」を適切に設定し、セキュリティ関連機能の目的と効果を正しく把握して、適切な対策を講じることが必要です。

　次回は「データ難読化」について説明する予定です。

# Reference
[1] ITmedia NEWS、「[個人情報が保存された神奈川県庁のHDD計54TB、転売される　処理会社の従業員が横領](https://www.itmedia.co.jp/news/articles/1912/06/news099.html)」、2019年12月06日（2020年1月9日閲覧）
[2] 朝日新聞デジタル、「[富士通リース、ＨＤＤ処理を丸投げ　データ消去確認せず](https://www.asahi.com/articles/ASMDC52K9MDCUTIL01J.html)」、2019年12月11日（2020年1月9日閲覧）
[3] piyolog、「[「世界最悪級の流出」と報じられた廃棄ハードディスク転売事案についてまとめてみた](https://piyolog.hatenadiary.jp/entry/2019/12/07/091332)」（2020年1月9日閲覧）
[4] 杉 研也、「[「なぜIT機器の転売事故は繰り返されるのか」を過去の事例から読み解く](https://www.keyman.or.jp/kn/articles/1912/20/news029.html)」、キーマンズネット、2019年12月20日（2020年1月14日閲覧）
[5] Curtis E. Stevens, _"ATA Password Security Standard for Flash Media"_, Flash Memory Summit 2007, August 2007
[6] Dell Technologies、「[BIOSで設定できるパスワードについて](https://www.dell.com/community/%E4%B8%80%E8%88%AC-%E3%83%8E%E3%83%BC%E3%83%88%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3/BIOS%E3%81%A7%E8%A8%AD%E5%AE%9A%E3%81%A7%E3%81%8D%E3%82%8B%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/td-p/6225663)」、2018年11月29日（2020年1月16日閲覧）
[7] ロジテックINAソリューションズ、「[HDD/SSDやパソコンの盗難・紛失に備える「ATAパスワードロック」とは](https://www.pro.logitec.co.jp/about_hdd/hddssd/20180726/)」、2020年1月16日閲覧
[8] Sillicon Power、「[SP HDD Lock Utility Software](https://www.silicon-power.com/web/jp/download-HDDlock)」、2020年1月16日閲覧
[9] 東芝デバイス&ストレージ、「[CANVIO™ SLIM / CANVIO™ PREMIUM Windows 用パスワードツール（Ver.1.20.6620） ダウンロード](http://www.canvio.jp/support/download/password/password_win.htm)」、2020年1月16日閲覧
[10] @nvsofts、「[SSDをSecure Erase機能で安全に消去する](https://qiita.com/nvsofts/items/f46c8a1b3541894ad382)」、2016年08月12日（2020年1月17日閲覧）
[11] T13, _"Information technology - AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS)"_, Revision 4a, May 21, 2007
[12] 渡部 善寿、「TCG Opalの特徴と仕様の概要」、[TCG日本支部](https://trustedcomputinggroup.org/work-groups/regional-forums/japan/) 第2回公開ワークショップ、2010年11月4日
[13] 小谷 誠剛、「TCG関連から見る鍵管理」、[NPO日本ネットワークセキュリティ協会](https://www.jnsa.org/) 鍵管理勉強会 第2回鍵管理勉強会、2012年7月3日
[14] _"[Trusted Computing Group and NVM Express Joint White Paper: TCG Storage, Opal, and NVMe](http://nvmexpress.org/wp-content/uploads/TCGandNVMe_Joint_White_Paper-TCG_Storage_Opal_and_NVMe_FINAL.pdf)"_ [PDF], August 2015（2020年1月17日閲覧）
[15] [McAfee Drive Encryption](https://www.mcafee.com/enterprise/ja-jp/products/technologies/drive-encryption.html)、2020年1月21日閲覧
[16] [Wave Self-Encrypting Drive Management](https://www.wavesys.com/products/wave-self-encrypting-drive-management)、2020年1月21日閲覧
[17] [WinMagic SecureDoc](https://www.winmagic.com/jp/products/features/self-encrypting-hard-drives)、2020年1月21日閲覧

# ライセンス表記
<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="クリエイティブ・コモンズ・ライセンス" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br />この 作品 は <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンス</a>の下に提供されています。