暗号化だけでは情報は守れない

by

記録媒体の流出事故を読むとき、最初に目に入るのは「廃棄されるはずの HDD が外部に流れた」という異常さである。診療用端末の更新に伴って不要になった HDD が、破砕されずに外部へ出る。しかも、その媒体に患者情報が残っていた可能性がある。これは直感的に重大な事故だと分かる。しかし、この事故を単に「廃棄業者が処理に失敗した」とだけ捉えると、問題の半分しか見えない。

より重要なのは、管理の外へ出た媒体が、読める状態だったのか、読めない状態だったのかである。記録媒体は、端末の内部にある間は、 OS、アカウント、アプリケーション、ネットワーク、職員権限によって守られているように見える。しかし、媒体が端末から外れ、廃棄工程へ移り、さらに第三者の手に渡れば、元の端末で働いていた制御は失われる。そのとき媒体全体が暗号化されていなければ、HDD は「古い機械の部品」ではなく、情報を保持したまま外へ出た容器になる。

本稿では、北海道医療センターなどで発生した廃棄 HDD 流出事故を入口に、暗号化、スマートフォン解析、クラウド同期、バックアップ、廃棄工程をつないで整理する。目的は、個別事故の責任追及ではない。情報を守るとは、単に暗号をかけることなのか。それとも、情報が保存され、利用され、複製され、移行され、廃棄されるまでの境界を管理することなのか。この問いを、具体例から順に考える。

中心命題は単純である。暗号化は、情報漏洩を完全に防ぐ技術ではない。暗号化された情報も、利用されるときには復号される。画面に表示され、アプリケーションに処理され、バックアップされ、クラウドへ同期され、紙に印刷され、メールで送られることがある。したがって、暗号化だけで情報の全経路を守れるわけではない。しかし、記録媒体が盗まれ、紛失し、誤って売却され、破砕されずに流通したときに、情報を読める状態で外へ出さないためには、暗号化は決定的な境界になる。

したがって、本稿で確認するのは、暗号化を万能視しないことと、暗号化を軽視しないことを同時に満たす視点である。暗号化していても情報は漏れうる。しかし、暗号化していない媒体が管理外へ出れば、漏洩可能性は別の段階へ進む。情報を守るとは、暗号の強さだけを見ることではない。情報がどこに存在し、どこで平文になり、どこへ複製され、どの境界を越え、最後にどのように閉じられるのかを管理することである。

1. 破砕されるはずの HDD が外部へ出た

独立行政法人国立病院機構北海道医療センターは、電子カルテ更新に伴って廃棄対象となった診療用端末の記録媒体の一部が、適切に処理されないまま外部流通していたと公表した。同様に北海道がんセンターも、患者情報を含む HDD が外部流通していたことを公表している[1][2]。報道によれば、発覚のきっかけは、インターネットオークションで HDD を入手した人からの連絡だった[3]。患者情報を含む HDD が破砕されず外部に流通し、氏名、患者番号、生年月日、住所、電話番号、診療日、診療科、病名、検査結果、アレルギー情報、看護記録の一部などが含まれていた可能性があると報じられている[4]。

この事故は、外部から病院システムへ侵入された事件ではない。電子カルテの稼働中システムを攻撃して、ネットワーク越しに患者情報を盗み出したという話ではない。問題になったのは、使われなくなった診療用端末、廃棄されるはずだった HDD、破砕処分の委託、そして外部流通である。つまり、情報は稼働中の電子カルテだけに存在していたのではない。更新によって不要になった端末の内部にも、過去に使われた情報が残っていた可能性がある。

ここで重要なのは、「使わなくなった端末」と「情報を持たない端末」は同じではないという点である。業務担当者から見れば、電子カルテ更新後の古い端末は、もう使わない機械である。処分対象であり、保管しておく意味も乏しい。しかし、情報管理の観点では、内部の HDD に診療情報が残っている限り、その端末は情報資産であり続ける。業務上の役目を終えたことと、情報管理上の責任を終えたことは一致しない。

このずれは、廃棄工程で事故を生む。現役システムであれば、端末の利用者、ログイン権限、ネットワーク接続、アプリケーション権限、監査ログによって、誰が情報へアクセスできるかをある程度管理できる。しかし、廃棄工程へ入った媒体は、現役システムの通常管理から外れていく。端末は取り外され、搬出され、委託先に渡り、保管され、破砕される予定になる。その途中で媒体が残ったり、取り違えられたり、外部へ出たりすれば、情報は別の経路で社会へ出る。

段階 見えている現象 情報管理上の意味
電子カルテ更新 古い診療用端末が不要になる。 業務上は不要になっても、端末内媒体に診療情報が残る可能性がある。
利用停止 端末が現役の業務端末ではなくなる。 通常業務のアクセス制御から外れ始めるが、内部媒体は情報を保持している可能性がある。
廃棄委託 媒体の破砕処分が外部業者に委託される。 情報の管理境界が、病院内から委託先工程へ移る。
破砕未実施 一部の HDD が破砕されないまま残る。 物理破壊を前提にした防御が失敗する。
外部流通 HDD がオークションなどの市場へ出る。 媒体が本来の管理主体から完全に離れ、第三者が内容を確認できる状態になる。

この表で確認すべきことは、事故が最後の「外部流通」だけで発生するわけではないということである。電子カルテ更新の時点で、古い端末は業務上の主役ではなくなる。利用停止の時点で、通常の監視や運用から外れやすくなる。廃棄委託の時点で、管理境界は組織の外へ広がる。破砕未実施の時点で、最後の物理的な防御が失敗する。そして外部流通の時点で、情報を保持した媒体が第三者の手に渡る。つまり、事故は一瞬で起きるのではなく、複数の境界が順に弱くなる中で起きる。

この構造を理解すると、廃棄 HDD 流出事故の危険性は、単に「媒体が外へ出たこと」だけではないと分かる。もちろん、媒体が外へ出ること自体が重大な管理事故である。しかし、情報漏洩の観点では、もう一つの問いが必要になる。外へ出た媒体は、第三者に読める状態だったのか。それとも、鍵なしでは読めない状態だったのか。この違いが、事故の被害を大きく変える。

この導入から分かるのは、情報漏洩は攻撃だけで起きるのではないということである。情報は、作成、保存、利用、複製、移行、廃棄のどの段階でも漏れる。とくに廃棄工程では、組織内の通常のアクセス制御がすでに働きにくくなっている。だからこそ、媒体を捨てる段階は、情報管理の終わりではない。むしろ、情報を保持していた媒体が本当に読めない状態になったのかを確認する、最後の境界確認の段階である。

本稿の出発点はここにある。廃棄されるはずの HDD が外部に出たことは、直接には廃棄工程の失敗である。しかし、より深い問題は、廃棄工程が失敗したときに、媒体上の情報を読める状態で外へ出してしまう設計である。次章では、この事故を「破砕されなかった」という現象だけでなく、「破砕されなかった媒体が読める状態だった」という構造から捉え直す。

2. 問題は廃棄に失敗したことだけではない

破砕を依頼した HDD が破砕されずに外へ出た、と聞くと、まず「廃棄業者がきちんと処理しなかったこと」が問題に見える。この理解は間違っていない。記録媒体を廃棄する業務では、回収、搬出、保管、破砕、証明、記録という手順があり、そのどこかが崩れれば媒体は本来の管理経路から外れる。したがって、破砕されるべき HDD が破砕されなかったことは、直接の事故原因である。しかし、情報漏洩の問題として見るなら、そこで考察を止めるべきではない。

なぜなら、廃棄処理の失敗と、情報が読める状態で外へ出ることは、同じではないからである。廃棄工程に失敗しても、媒体上のデータが第三者に読めない状態であれば、事故の性質は大きく変わる。逆に、廃棄工程に失敗した媒体がそのまま読める状態であれば、破砕の失敗は直ちに情報漏洩へ近づく。ここで分けるべきなのは、「媒体が外へ出たこと」と「外へ出た媒体から情報を読めること」である。

この違いは、封筒に入った書類を考えるとわかりやすい。書類を処分業者へ渡したあと、処分されずに外へ出たとする。その書類が開いた紙束のままであれば、拾った人はすぐに読める。一方、書類が開けられない強固な金庫に入っており、鍵も失われていれば、金庫そのものが流出しても中身を読む難度は大きく変わる。もちろん、金庫が流出してよいわけではない。しかし、流出したときに読めるかどうかは、被害の大きさを左右する。

HDD でも同じである。端末の中に入っているあいだ、その HDD は業務システム、ログイン、ネットワーク制限、職員権限、運用規則によって間接的に守られているように見える。しかし、HDD が端末から取り外され、廃棄工程へ渡り、さらに外部へ流通すると、元の端末上で働いていた制御は失われる。そこで媒体全体が暗号化されていなければ、別の計算機に接続するだけで、ファイルシステムや残存データへ到達できる可能性が生じる。

個人情報保護法の枠組みでは、個人データは取得した時点だけでなく、利用、保存、第三者提供、委託、漏洩対応まで含めて管理される対象である[5]。医療情報については、さらに重い意味を持つ。診療情報は、氏名や住所のような識別情報だけでなく、病名、検査結果、処方、アレルギー、看護記録のように、本人の身体、生活、将来の治療に関わる情報を含みうる。厚生労働省の医療情報システム安全管理ガイドラインも、医療情報システムを安全に管理するための考え方を示している[6]。したがって、業務上不要になった端末や媒体であっても、そこに診療情報が残っている限り、管理対象から外れたとは言えない。

ここで重要なのは、管理対象が「現役で使っているシステム」だけではないという点である。電子カルテ端末を更新すれば、古い端末は業務の中心から外れる。利用者から見れば、もう使わない機械である。しかし、古い端末の HDD に患者情報が残っていれば、その媒体は依然として情報を保持している。業務上の役目を終えたことと、情報管理上の責任を終えたことは一致しない。

観点 業務上の見え方 情報管理上の見え方
古い端末 電子カルテ更新によって不要になった機器である。 内部媒体に診療情報が残っていれば、なお管理すべき情報資産である。
廃棄依頼 業者へ処分を依頼した時点で、業務担当者の手元から離れる。 処分が完了し、対象媒体と処分記録が対応して確認されるまで、漏洩リスクは残る。
破砕処分 物理的に壊せばデータは読めなくなると考えられる。 破砕されなかった媒体、取り違えられた媒体、記録から漏れた媒体があれば、保護は成立しない。
暗号化 通常業務では利用者から見えにくく、直接の作業効率に結びつきにくい。 媒体が盗難、紛失、転売、破砕漏れによって管理外へ出たとき、内容を読める状態で流出させない境界になる。

この表で最も重要なのは、業務上の終了と、情報管理上の終了がずれることである。端末更新、廃棄依頼、搬出、破砕予定は、いずれも業務の区切りである。しかし、患者情報が媒体に残っている限り、情報管理上の区切りにはならない。情報管理上の終了とは、媒体上の情報が復元困難な形で消去されるか、物理的に破壊されるか、強固な暗号化の鍵が失われて内容を読めなくなるかによって初めて成立する。

この構造は、過去の HDD 転売事件とも重なる。ブロードリンクは、神奈川県庁に関連する HDD 流出を含む盗難事件について、経緯と再発防止を公表している[7]。同事件は、廃棄または処分されるはずだった記録媒体が中古市場へ出ることの危険を広く知らしめた事例である。ここでも問題は、媒体が外へ出たことだけではない。処分されたはずの媒体が実際には残り、現物確認と処分記録の対応が崩れ、中古市場で第三者の手に渡ったことが問題だった。リース、廃棄、委託、証明書、現物確認がつながらなければ、組織は「廃棄したつもり」の媒体を実際には管理できない[8]。

つまり、廃棄工程には複数の失敗点がある。対象媒体の台数を取り違えることがある。搬出後の保管で管理が緩むことがある。破砕前の媒体が別の流通経路に乗ることがある。証明書が発行されても、証明書に書かれた媒体と実際の媒体が正しく対応していないことがある。委託先の作業が正しくても、委託元が現物確認を省略すれば、処分が本当に完了したかを自分では確認できない。したがって、廃棄媒体の安全性は、単一の手順や単一の証明に依存させるべきではない。

IPA は組織向けの情報セキュリティ脅威や対策の中で、情報漏洩、内部不正、委託先管理、記録媒体の廃棄などを継続的な管理課題として扱っている[9]。中小企業向けの対策ガイドラインでも、情報の重要度に応じた管理、委託先管理、媒体管理、廃棄時の漏洩防止が基本的な対策として位置づけられている[10]。これは、大規模病院だけの特殊な問題ではない。顧客情報、従業員情報、取引先情報、研究データ、会計資料、認証情報を持つ組織であれば、不要になった媒体をどう扱うかは常に問題になる。

この章で確認したい結論は、破砕が不要だということではない。物理破壊は重要である。消去も重要である。委託先管理も重要である。搬出記録や処分証明も重要である。しかし、それらはどれも失敗しうる。だから、安全な運用は、手順が必ず正しく実行されることを前提にしてはならない。ある層が失敗しても、次の層で情報を守る設計にしておく必要がある。

その意味で、問題は廃棄に失敗したことだけではない。より深い問題は、廃棄に失敗したとき、媒体上の情報が読める状態で外へ出てしまうことである。ここから、保存媒体そのものを暗号化することの意味が見えてくる。暗号化は、日常業務の便利な付属機能ではなく、媒体が管理境界を越えてしまったときに、情報を読める状態で流出させないための防御層である。

3. 端末から外れた HDD は OS の権限管理から離れる

業務端末の中にある HDD は、ふだんは単独の記録媒体として意識されにくい。利用者は端末にログインし、電子カルテや業務アプリケーションを開き、必要な情報を見る。そのため、情報はログイン画面、職員アカウント、アプリケーションの権限、院内ネットワーク、端末の設定によって守られているように見える。この見え方は、稼働中の端末を通常の手順で使っている限りでは正しい。OS が起動し、アカウント認証が行われ、アプリケーションが権限を確認しているからである。

しかし、この保護は「元の端末が、元の OS で、通常の起動状態にある」ことを前提にしている。HDD が端末から取り外されると、その前提が崩れる。別の計算機に接続された HDD は、もはや元の電子カルテ端末の一部ではない。元のログイン画面も、元のアプリケーション認証も、元の院内ネットワーク制限も、その HDD を直接読む別環境ではそのまま働かない。ここに、取り外された HDD 特有の危険がある。

たとえば、業務端末の中では、ある職員が特定のファイルや患者情報を見られないように設定されていたとする。この制御は、OS やアプリケーションが「この職員に読ませてよいか」を判断しているから成立する。ところが、HDD を取り外して別の計算機に接続すると、攻撃者や第三者は元の職員アカウントとしてログインしようとしているわけではない。媒体上のファイルシステムや残存データを、別の OS から直接見ようとしている。このとき、元の端末上での権限設定は、期待した形では防御にならない。

ここで混同しやすいのが、アカウント権限と媒体暗号化である。アカウント権限は、稼働中の OS が「誰に何を読ませるか」を判断する仕組みである。媒体暗号化は、媒体上のデータそのものを、鍵なしでは意味のある形に読めなくする仕組みである。前者は、端末が正しく起動し、その OS の管理下で使われているときに効く。後者は、媒体が抜き取られ、盗まれ、紛失し、売却され、廃棄工程で流出したときにも効く。

この違いは、建物の入館管理と書類そのものの封印の違いに近い。建物の入口で身分証を確認していれば、通常の来訪者は勝手に書庫へ入れない。しかし、書庫の書類が箱ごと外へ運び出され、その箱が別の場所で開かれたなら、建物入口の入館管理はもう効かない。建物内での入館管理が不要だという意味ではない。問題は、書類が建物の外へ出たときにも中身を読ませない仕組みが別に必要だという点である。HDD における媒体暗号化は、この「外へ出たときにも読めない状態」を作るための防御である。

保護方法 何を守っているか 効く条件 限界
OS の権限管理 稼働中の OS 上で、利用者ごとに読めるファイルや操作を制限する。 元の OS が起動し、その OS の管理下でアクセスされている場合に効く。 HDD を取り外して別環境から読む場合、元の OS による制御はそのまま働かない。
アプリケーション認証 電子カルテなどのアプリケーション内部で、利用者ごとの閲覧範囲や操作範囲を制限する。 利用者がそのアプリケーションを通じて情報にアクセスしている場合に効く。 アプリケーションを起動せず、媒体上のデータへ直接到達する経路を防ぐものではない。
ネットワーク制限 院内 LAN や特定端末からしかシステムへ接続できないようにする。 情報がネットワーク上のサービスとして利用されている場合に効く。 取り外された HDD が単体で外部に出た場合、ネットワーク境界の内外という考え方だけでは守れない。
媒体暗号化 媒体上のデータを、鍵なしでは意味のある形に読めない状態にする。 媒体が紛失、盗難、転売、破砕漏れなどで管理外へ出た場合にも効く。 正規に復号された後の表示、印刷、転送、クラウド同期、バックアップまでは自動的には守らない。
物理破壊 媒体を物理的に壊し、記録されたデータへ到達できない状態にする。 対象媒体が正しく特定され、実際に破壊され、その事実が確認された場合に効く。 破壊前の保管、搬出、台数確認、委託先管理に失敗すると、破壊されない媒体が残る。

この表で確認できるように、保護方法ごとに効く場面は異なる。OS の権限管理やアプリケーション認証は、通常業務の中では重要である。職員ごとの閲覧範囲を制御し、不必要な情報へ触れさせないために必要である。ネットワーク制限も、外部から業務システムへ不用意に接続されることを防ぐために必要である。しかし、これらは主に「端末やシステムが通常の形で使われている場面」を守る仕組みである。

廃棄 HDD 流出事故で問題になるのは、まさに通常の形で使われていない場面である。端末は更新され、HDD は取り外され、廃棄工程へ渡り、場合によっては外部市場へ流れる。この時点で、HDD は元の業務システムの一部ではなくなる。だから、通常業務の中で効いていた権限管理だけでは足りない。媒体が管理外へ出る可能性を前提にするなら、媒体そのものを読めない状態にしておく必要がある。

NIST の媒体サニタイズ指針は、媒体の処分や再利用において、データを現実的に復元できない状態へするための考え方を示している。そこでは、消去、暗号鍵の破棄、物理破壊などが、媒体や利用形態に応じて選ばれる処理として扱われる[11]。また、NIST のストレージ暗号化技術ガイドは、フルディスク暗号化、ボリューム暗号化、ファイル単位の暗号化を区別し、それぞれが守る範囲を整理している[12]。重要なのは、どの方法が万能かではなく、どの局面でどの方法が効くかを取り違えないことである。

暗号化されていない HDD は、端末の中にある間だけ安全そうに見える。実際には、その安全性の多くは、端末、OS、アプリケーション、ネットワークという周囲の仕組みに依存している。媒体が端末から外れれば、その周囲の仕組みは剥がれ落ちる。そこで媒体暗号化がなければ、HDD は情報を保持したまま、別の環境から読まれる可能性を持つ物体になる。

したがって、端末から外れた HDD を考えるときには、「その端末にログインできるか」ではなく、「その媒体だけを手に入れた第三者が読めるか」を問わなければならない。廃棄、紛失、盗難、転売、委託先での取り違えは、いずれも媒体が元の OS の権限管理から離れる局面である。この局面を守るためには、OS の権限管理ではなく、媒体そのものを鍵なしでは読めない状態にする設計が必要になる。

4. 暗号は正攻法では破れにくいが、守る範囲は限定される

暗号化について考えるとき、まず避けるべきなのは、「暗号は破れるのか、破れないのか」という二分法である。この言い方は直感的にはわかりやすいが、実際の安全性を説明するには粗すぎる。強い暗号は、正しい鍵が存在しないから安全なのではない。正しい鍵は存在する。問題は、その鍵を知らない第三者が、候補を一つずつ試して現実的な時間内に正解へ到達できるかどうかである。

たとえば、鍵の候補が少なければ、攻撃者は総当たりで試せる。短い暗証番号や弱いパスワードが危険なのは、このためである。一方、十分に長く、十分に複雑な鍵やパスフレーズが使われていれば、候補空間は巨大になる。候補空間とは、攻撃者が試さなければならない可能性の集合である。候補が多すぎれば、正解がどこかに存在していても、現在の計算資源では現実的な時間内にたどり着けない。この点は、暗号の強さを探索空間と計算時間の問題として整理した既稿でも扱った[13]。

この意味で、よく設計された媒体暗号化を正面から破るのは難しい。攻撃者が暗号鍵を総当たりで探すしかないなら、防御の本質は「絶対に破れない」ことではなく、「破るために必要な時間と計算量を現実の外へ押し出す」ことにある。これは、暗号化を過小評価しないために重要である。強い暗号化が施された媒体は、鍵なしで読もうとする相手に対して、非常に強い障壁になる。

Linux では、dm-crypt がブロックデバイスを透過的に暗号化するカーネル側の仕組みを提供する。ここでいうブロックデバイスとは、HDD、SSD、パーティション、仮想ディスクのように、一定の単位で読み書きされる記録領域である。dm-crypt は、その記録領域へ書き込む前にデータを暗号化し、読み出すときに復号する。利用者やファイルシステムからは通常のディスクのように見えても、媒体上には暗号化されたデータが保存される[14]。

cryptsetup は、LUKS を含む暗号化ブロックデバイスを扱う主要なユーザー空間ツールとして使われる。LUKS は、暗号化されたデータ領域だけでなく、鍵スロットやメタデータを含む形式であり、パスフレーズ変更、複数鍵の管理、復旧設計を行いやすくする。Red Hat の文書でも、LUKS によるブロックデバイス暗号化は、保存媒体を保護するための実務的な仕組みとして整理されている[15][16]。

しかし、ここで重要なのは、暗号が正攻法では破れにくいことと、情報が絶対に漏れないことは同じではない、という点である。暗号化は、主に保存中のデータを守る。電源が落ち、鍵がなく、媒体だけが第三者の手元にあるなら、暗号化は非常に強く効く。暗号化されていない HDD であれば、別の計算機に接続してファイルシステムを読むことができるかもしれない。しかし、強く暗号化された HDD では、媒体上に残っているのは鍵なしでは意味のある形に読めないデータである。

一方で、情報は使われるときには復号される。暗号化されたディスクも、マウントされている間は OS から通常のファイルシステムとして見える。電子カルテ端末であれば、正規の利用者がログインし、アプリケーションが診療情報を表示し、OS が必要なファイルを読み書きする。その瞬間、情報は業務に使える形になっている。攻撃者や事故は、暗号鍵を総当たりで探すのではなく、この「すでに使える状態」を狙うことがある。

これは金庫の比喩で考えるとわかりやすい。閉じた金庫を外からこじ開けるのは難しい。しかし、金庫の持ち主が鍵で開け、中の書類を机の上に広げた後であれば、泥棒は金庫を破る必要がない。金庫が弱いのではない。金庫が守っているのは、閉じている間の中身である。開けられた後の書類、コピーされた書類、写真に撮られた書類、郵送された書類は、別の管理対象になる。暗号化された媒体でも同じである。

状態 暗号化の効き方 残るリスク
電源断かつ鍵なしの媒体 媒体上のデータは、鍵なしでは意味のある形に読めない。 強いパスフレーズ、鍵管理、ヘッダー保全が前提になる。
起動前または未解除の端末 保存領域が暗号化されていれば、正規の解除手順なしにローカルデータへ到達することは難しい。 弱い認証、古い実装、既知脆弱性、別経路のバックアップが問題になりうる。
マウント中の暗号化ディスク ストレージ上は暗号化されていても、OS からは通常のファイルとして見える。 侵入済みの OS、管理者権限、誤操作、同期処理、バックアップ処理から情報が出る可能性がある。
ログイン済みの業務端末 媒体暗号化は保存領域を守るが、正規利用中の画面表示やアプリケーション処理は利用可能な状態になる。 画面の覗き見、誤送信、権限設定ミス、内部不正、端末の乗っ取りが漏洩経路になる。
クラウド同期済みデータ ローカル媒体が暗号化されていても、同期先では別の保護方式に依存する。 端末ではなく、アカウント、共有設定、バックアップ、クラウド側の管理が漏洩経路になる。
印刷またはメール送信済み情報 元の暗号化媒体とは別の形で情報が複製されている。 元データを暗号化しても、紙、添付ファイル、転送先、受信者側の管理が弱ければ漏れる。

この表からわかるのは、暗号化の価値が場面によって変わることではない。むしろ、暗号化が効く場面と効かない場面を取り違えると、過大評価にも過小評価にもなる、ということである。電源断かつ鍵なしの媒体に対しては、暗号化は非常に強い。一方、マウント中のディスク、ログイン済みの端末、クラウド同期済みのデータ、印刷物、メール添付に対しては、それぞれ別の管理が必要になる。

したがって、「暗号化していても情報は漏れる」という言い方だけでは不十分である。その言い方だけを聞くと、暗号化はあまり意味がないように見えてしまう。しかし、それは誤解である。暗号化は、すべての漏洩経路をふさぐ万能な仕組みではないが、媒体が管理外へ出たときに、読める媒体と読めない媒体の差を作る。この差は、廃棄 HDD 流出事故では決定的である。

逆に、「暗号化していれば安全」という言い方も不十分である。暗号化されたディスクをマウントしたまま侵入されれば、OS から見えるファイルは読まれる可能性がある。復号された情報をクラウドへ同期すれば、次はクラウドアカウントの管理が問題になる。診療情報を印刷すれば、紙の保管と廃棄が問題になる。メールで送れば、送信先、添付ファイル、受信者側の管理が問題になる。暗号化が強いほど、攻撃や事故は暗号そのものではなく、暗号の外側へ回り込む。

この章の結論は、暗号化を万能視しないことと、暗号化を軽視しないことを同時に満たす必要がある、ということである。強い暗号は、正攻法では現実的に破れにくい。だから、媒体が電源断かつ鍵なしで流出した場合には、強い防御層になる。しかし、情報が利用され、表示され、複製され、送信され、同期される場面では、暗号化とは別の管理が必要になる。暗号化は情報管理の全体ではないが、情報媒体が管理境界を越えたときに被害を大きく変える中核的な防御である。

5. スマートフォンはなぜ暗号化されていても解析されるのか

スマートフォンは、暗号化の効く範囲と限界を理解するためのよい補助例である。現在の iPhone や Android 端末では、ローカルストレージの暗号化が標準的な前提になっている。端末を落としたり、盗まれたり、電源が切れた状態で第三者の手に渡ったりした場合、保存領域をそのまま読み出されないようにするためである。Apple は、暗号化とデータ保護機構によって、端末紛失時や他の安全機構が侵害された場合にも利用者データを保護する設計を説明している[17]。つまり、スマートフォンは「暗号化されていない HDD」とはかなり違う前提で設計されている。

ただし、スマートフォンの暗号化は、単純に「端末全体が閉じているか、開いているか」という仕組みではない。iOS にはファイル保護クラスがあり、ファイルごとに、いつ読めるか、どの状態で守られるかが異なる[18]。再起動直後でまだ一度もロック解除されていない状態、利用者が一度ロック解除した後に画面だけがロックされている状態、端末が完全に解除されて操作されている状態では、同じ端末でもデータの利用可能性が変わる。また、Secure Enclave は鍵や認証に関わる処理を隔離するハードウェア上の重要な構成要素として説明されている[19]。

Android でも同様に、暗号化は単純な一枚岩ではない。Android 7.0 以降ではファイルベース暗号化が導入され、異なるファイルを異なる鍵で独立に扱える仕組みが説明されている[20]。Direct Boot は、端末がロック解除される前でもアラームや一部の通知のような機能を使えるようにしつつ、利用者の資格情報で保護されるデータとは区別する仕組みである[21]。これは、端末が起動していても、すべてのデータが同じ条件で読めるわけではないことを示している。

ここで読者が抱きやすい疑問は、「それなら、なぜ事件の調査でスマートフォンの内容が解析されることがあるのか」という点である。端末が暗号化されているなら、保存された写真、メッセージ、位置情報、アプリデータは読めないはずだ、と思える。しかし、この疑問は「暗号化された保存領域を正面から破ること」と、「端末や周辺システムが情報を利用できる状態から情報へ到達すること」を混同している。

多くの場合、解析とは暗号そのものを数学的に破ることではない。端末がロック解除済みだった場合、OS やアプリケーションはすでに情報を利用できる状態にある。一度解除された後の画面ロック状態であれば、再起動直後とは保護状態が異なる場合がある。パスコードが正規に入力された場合、端末は利用者本人が開いたときと同じように復号処理を行う。クラウドバックアップがあれば、端末本体ではなく同期先やバックアップから情報が得られる場合もある。古い OS や既知脆弱性が残っていれば、端末の保護機構を回避される可能性もある。

経路 何が起きているか 暗号との関係
解除済み端末 端末がすでに情報を利用できる状態にあり、アプリや OS がデータを読める。 暗号を破っているのではなく、正規に復号された状態を利用している。
一度解除後のロック状態 再起動直後とは異なり、一部のデータや機能が利用可能な状態に残ることがある。 暗号化されていても、端末状態によって保護の強さが変わる。
パスコード入力 正しい認証情報によって端末が解除され、通常の利用と同じ経路で情報へアクセスする。 暗号を突破したのではなく、鍵を使って正規に開いている。
クラウドバックアップ 端末本体ではなく、同期先、バックアップ、アカウント上の情報から内容を得る。 ローカル媒体の暗号化とは別の保護境界が問題になる。
既知脆弱性 古い OS、未修正の実装、特定端末の弱点を利用して保護機構を迂回する。 暗号方式そのものではなく、端末実装や運用状態の弱点を突いている。

この表で重要なのは、どの経路でも「強い暗号を正面から総当たりで破っている」とは限らないことである。閉じた金庫を力ずくで壊すのではなく、持ち主が開けた瞬間に中を見たり、別の場所に保管されたコピーを見たり、鍵の管理が弱い場所を探したりしている。暗号化されたスマートフォンの解析も、これに近い構造を持つ。端末の暗号が弱いというより、情報へ到達する道が、暗号化された保存領域そのもの以外にも存在するのである。

NIST のモバイルフォレンジック指針も、モバイル端末からデジタル証拠を取得、保全、分析、報告する領域が、端末状態や技術変化に強く依存することを示している[22]。モバイル端末は、単なる記録媒体ではない。通信し、同期し、通知を受け取り、アプリを動かし、クラウドサービスと結びつく小さな計算機である。そのため、解析可能性は、ストレージ暗号化の有無だけでは決まらない。電源状態、解除状態、 OS のバージョン、アプリの設計、クラウド同期、バックアップ、アカウント管理が重なって決まる。

また、スマートフォンのデータ保護については、再起動直後と一度解除された後で保護状態が異なることなど、実装上の課題が研究でも整理されている[23]。これは、暗号化が単一の壁ではなく、状態に応じて開閉する複数の扉に近いことを示している。端末が完全に停止し、まだ解除されておらず、パスコードも不明で、クラウド側にも取得可能なコピーがない場合、ローカルデータへ正面から到達することは非常に難しい。一方で、どこかの扉がすでに開いていれば、攻撃者や調査者はその扉を使う。

この話は、廃棄 HDD の問題と対照的である。スマートフォンでは、暗号化、端末状態、認証、ハードウェア保護、クラウド同期が複雑に絡む。一方、暗号化されていない HDD は、端末から取り外されると、単なる記録媒体として扱われる。そこには、Secure Enclave のような認証専用ハードウェアも、解除状態に応じたファイル保護クラスも、端末と一体化した認証処理もない。媒体上に読めるデータが残っていれば、別の計算機から直接読まれる可能性がある。

したがって、スマートフォンの例から導くべき結論は、「暗号化していても意味がない」ではない。むしろ逆である。暗号化は、電源断、未解除、鍵なしのローカルデータに対して非常に強い。しかし、情報が利用される端末、同期先のクラウド、バックアップ、アプリ、アカウント、解除済み状態には、それぞれ別の到達経路がある。暗号の強度と、情報へ到達できる経路の多さは別問題である。

この補助例によって、本稿の主題はより明確になる。暗号は、保存媒体だけを見れば非常に強い防御になりうる。しかし、情報は端末、利用者、アプリケーション、クラウド、バックアップ、廃棄工程の中を移動する。だから、暗号化の有無だけで安全性を判断するのではなく、情報がどの状態で、どの経路から読めるのかを見なければならない。次に必要なのは、情報が利用される以上、どこかで必ず平文になるという事実を確認することである。

6. 情報は使うために、どこかで平文になる

ここで、議論を一段抽象化できる。暗号化された情報は、保存されているだけなら読めない状態にできる。しかし、情報を使うためには、どこかで必ず読める状態に戻さなければならない。平文とは、暗号化されておらず、人間やアプリケーションが意味のある内容として読める状態の情報である。暗号化されたファイルも、編集するときには復号される。暗号化されたディスクも、マウント中は OS から通常のファイルシステムとして見える。暗号化されたスマートフォンも、ロック解除後はアプリが写真、メッセージ、位置情報、認証済みセッションを利用できる。

ここで重要なのは、平文になること自体が異常ではないという点である。情報が平文にならなければ、人間は読めず、アプリケーションは処理できず、業務は成立しない。医師が診療情報を確認する、会計担当者が請求処理を行う、バックアップシステムが復旧用コピーを作る、移行作業で旧環境から新環境へデータを移す。これらはすべて正当な業務である。しかし、正当な業務であるからこそ、情報は暗号化された保存媒体の中だけに閉じ込められず、利用可能な形で複数の場所に現れる。

この点を誤解すると、「暗号化しているのになぜ漏れるのか」という疑問が生じる。答えは、暗号化された媒体を正面から破らなくても、情報がすでに平文になっている場所へ到達できる場合があるからである。暗号化ディスクをマウントした後に侵入されれば、攻撃者は暗号を総当たりしなくても、OS から見えているファイルを読む可能性がある。診療情報を画面に表示すれば、画面の覗き見や撮影が問題になる。メールで送れば、送信先と添付ファイルの管理が問題になる。バックアップを作れば、バックアップ先の暗号化、保持期間、アクセス権が問題になる。

つまり、暗号化は情報を使えなくする技術ではない。正しい鍵や正しい認証を持つ主体には、情報を使えるようにする技術である。だから、情報を守るという問題は、暗号化された保存状態だけを見ても完結しない。情報がいつ復号され、誰に読めるようになり、どのアプリケーションが扱い、どこへ複製され、いつ削除され、どの媒体に残るのかを追わなければならない。

医療情報では、この構造が特に見えやすい。診療情報は、医師が診察し、看護師が記録し、検査部門が結果を返し、薬剤部門が処方を扱い、会計が処理し、紹介状が作成され、必要に応じて印刷され、バックアップされ、システム更新時に移行される。その過程で、情報は保存媒体の上だけに存在するのではない。画面、帳票、ログ、キャッシュ、一時ファイル、バックアップ、移行先、検証環境、保守作業用のコピー、廃棄端末の中に現れる。

利用場面 平文になる理由 漏洩につながる条件
画面表示 人間が読むためには、情報が画面上で意味のある形に表示される。 覗き見、画面撮影、共有画面、端末放置、ロック忘れによって情報が外へ出る。
アプリ処理 アプリケーションは復号済みデータを読み、検索、集計、編集、表示を行う。 権限過大なアプリ、侵害済み端末、ログ出力、キャッシュ保存、設定ミスから情報が漏れる。
認証済みセッション 一度ログインすると、利用者が毎回鍵やパスワードを入力しなくても処理を継続できる。 端末放置、セッション乗っ取り、共有端末の運用不備により、正規利用中の状態が悪用される。
バックアップ 障害や誤削除から復旧するために、元データとは別の場所へ複製が作られる。 バックアップ先の暗号化、保持期間、アクセス権、削除同期、廃棄手順が管理されていないと漏れる。
移行作業 システム更新時には、旧環境から新環境へデータを移し、変換し、検証する必要がある。 一時領域、旧端末、検証用コピー、移行後の残置データ、作業委託先の管理が弱いと漏れる。
印刷と帳票 説明、確認、署名、院内手続き、紹介、保管のために情報が紙へ出力される。 置き忘れ、誤配布、回収漏れ、廃棄箱の管理不備により、デジタル媒体の外で情報が漏れる。
メールと共有 組織内外の関係者へ情報を渡すために、添付ファイルや共有リンクが使われる。 宛先誤り、共有範囲の広げすぎ、転送、受信者側の管理不備によって情報が制御外へ出る。
廃棄工程 業務上不要になった端末や媒体にも、過去に利用されたデータが残っている場合がある。 消去、暗号鍵破棄、物理破壊、台数確認、委託先管理が失敗すると、古い媒体から情報が流出する。

この表で示したいのは、漏洩経路が一つではないということではない。より重要なのは、情報が平文になる場所が一つではないということである。情報は、保存媒体の上にだけあるのではない。利用されるたびに、画面、メモリ、アプリケーション処理、ログ、帳票、バックアップ、移行用コピー、廃棄端末へ姿を変えて現れる。そのどこかで管理が弱ければ、暗号化された元媒体を破らなくても情報は漏れる。

ここから、「暗号化していれば安全」という理解が不十分である理由がわかる。暗号化は、保存中の媒体を守るためには非常に強い。しかし、情報が復号され、利用され、複製され、移動した後のすべてを自動的に守るわけではない。暗号化されたディスクから読み出された情報が、暗号化されていない一時ファイルに残ることがある。画面に表示された情報が撮影されることがある。クラウドへ同期された情報が、別のアカウント管理の問題になることがある。紙に印刷された情報は、もはやディスク暗号化とは別の管理対象になる。

同時に、「暗号化していても漏れるなら暗号化は意味がない」という理解も間違っている。媒体が電源断かつ鍵なしで流出した場合、暗号化は情報を読める状態で外へ出さないための強い防御になる。廃棄 HDD のように、媒体そのものが管理外へ出る事故では、この差は決定的である。暗号化は、すべての漏洩経路を消すものではないが、媒体流出という経路に対しては、読める媒体と読めない媒体の境界を作る。

したがって、核心は「暗号化するかどうか」だけではない。核心は、情報がどの状態で、どこに存在し、誰に読めるのかを管理することである。保存中の情報には暗号化が必要になる。利用中の情報には認証、権限管理、端末管理、ログ管理が必要になる。複製された情報にはバックアップ管理、共有管理、保持期間管理が必要になる。紙に出た情報には物理的な保管と廃棄が必要になる。廃棄媒体には鍵破棄、消去、物理破壊、現物確認が必要になる。

このように見ると、情報漏洩対策は「暗号化しているか」だけでは完結しない。情報を完全に閉じ込めれば安全に見えるが、それでは業務に使えない。情報を使えるようにすると、情報は平文になり、複製され、表示され、移動する。セキュリティとは、この緊張関係を管理することである。情報を使える状態にしながら、使える主体、使える場所、使える時間、複製される範囲、廃棄される条件を設計することが、情報を守るということである。

本稿の主題である廃棄 HDD の問題も、この構造の中に位置づけられる。廃棄 HDD は、現役の業務システムから外れた後に残った情報の容器である。そこに過去の平文データや復元可能なデータが残っていれば、端末更新や廃棄依頼によって業務上の役割を終えていても、情報管理上のリスクは残る。だから、次に考えるべきなのは、暗号そのものではなく、暗号の外側でどのように漏洩が起きるのかである。

7. 漏洩は暗号の外側で起きる

前章では、情報は使うためにどこかで平文になることを確認した。ここから、さらに重要な結論が出てくる。現実の漏洩は、暗号方式そのものを正面から破ることで起きるとは限らない。むしろ多くの場合、漏洩は暗号の外側で起きる。ここでいう暗号の外側とは、暗号化された保存媒体そのものではなく、情報が復号された後に現れる場所、複製された場所、転送された場所、利用者やアプリケーションが情報を扱う場所のことである。

この点は、暗号化を過小評価する話ではない。強い暗号化が施された媒体は、鍵なしで直接読むことが非常に難しい。だからこそ、攻撃や事故はしばしば別の経路へ向かう。閉じた金庫を壊すより、金庫から取り出された書類、書類のコピー、書類を撮影した画像、書類を郵送した封筒、書類を捨てたごみ箱を狙うほうが簡単な場合がある。暗号化された情報でも同じである。元の媒体が守られていても、情報が別の形で外へ出れば、そこが新しい漏洩経路になる。

たとえば、クラウドバックアップに同期されたデータ、共有フォルダに置かれたファイル、メール添付、印刷物、スクリーンショット、保守作業用コピー、検証環境、廃棄端末の残置データは、元の暗号化媒体とは別の場所に現れた情報である。元の HDD が暗号化されていたとしても、復号後に作られたコピーや、別サービスへ同期されたデータが同じ強さで守られているとは限らない。ここで問題になるのは、暗号の強度ではなく、情報が移った先の管理である。

クラウドは、この構造を理解するうえでわかりやすい例である。Apple は iCloud のデータセキュリティについて、データ種別ごとの暗号化やエンドツーエンド暗号化の範囲を説明している[24]。これは、クラウド上のデータも一定の保護を受けることを示す一方で、データ種別や設定によって保護の範囲が異なることも示している。Android 開発者向け文書でも、バックアップ時のセキュリティ推奨事項が示されている[25]。ここから分かるのは、バックアップは復旧のために必要な仕組みであると同時に、ローカル媒体とは別の管理境界を作るということである。

管理境界とは、誰が、どこから、どの条件で情報へ到達できるかを分ける線である。ローカル HDD の境界は、端末、OS、暗号鍵、物理的な保管によって作られる。クラウドの境界は、アカウント、認証、共有設定、サービス側の暗号化、復旧手段、管理者権限によって作られる。印刷物の境界は、保管場所、持ち出しルール、回収手順、廃棄箱の管理によって作られる。同じ情報であっても、置かれる場所が変われば、守るための境界も変わる。

経路 なぜ暗号の外側になるか 必要な管理
クラウド同期 ローカル媒体とは別のアカウント、サービス、データセンター上に情報が複製される。 認証、共有設定、バックアップ暗号化、復旧手段、管理者権限、削除保持期間を管理する。
バックアップ 復旧のために、元データとは別の媒体や別の場所に情報が保存される。 保存先の暗号化、保持期間、アクセス権、世代管理、廃棄手順、復元権限を管理する。
共有フォルダ 特定の端末や利用者だけでなく、共有範囲に含まれる複数の主体が情報へ到達できる。 共有範囲、読み書き権限、外部共有、リンク公開、棚卸し、不要共有の削除を管理する。
メール添付 元データが送信先のメールボックス、端末、バックアップ、転送先に複製される。 送信先確認、添付制限、暗号化、誤送信対策、転送制御、保存期間を管理する。
印刷物 情報がデジタル暗号化の外へ出て、紙として読める状態になる。 印刷権限、放置防止、持ち出し、回収、保管、廃棄、複合機内ストレージを管理する。
スクリーンショット 画面に表示された情報が画像として再保存され、元システムの権限管理から離れる。 撮影制限、端末管理、共有先確認、画像ファイルの保存場所、削除手順を管理する。
保守用コピー 障害対応、調査、移行、検証のために、一時的な複製が作られる。 作成理由、保存場所、アクセス権、委託先、削除確認、作業記録を管理する。
検証環境 本番データがテストや移行確認のために別環境へ移される。 匿名化、データ最小化、環境分離、アクセス権、利用後削除、外部接続制限を管理する。
廃棄媒体 業務利用が終わった媒体が、通常の監視やアクセス制御の外へ出る。 暗号化、鍵破棄、消去、物理破壊、台帳照合、複数人確認、委託先管理を管理する。

この表で重要なのは、経路ごとに守るべきものが変わることである。クラウド同期では、ローカルディスクの暗号化ではなく、アカウントと共有設定が問題になる。メール添付では、送信元のディスクではなく、送信先と転送先が問題になる。印刷物では、暗号鍵ではなく、紙の置き場所と廃棄方法が問題になる。保守用コピーや検証環境では、本番環境の厳密な権限管理が、そのまま別環境にも再現されているかが問題になる。

ここに、情報が物理物と異なる難しさがある。鍵をかけた部屋から紙を一枚持ち出せば、部屋の中の紙は一枚減る。しかし、データをコピーしても元データは減らない。コピー元にも残り、コピー先にも残る。さらに、そのコピーがバックアップされ、添付され、共有され、別の端末に同期されれば、情報の所在は増えていく。情報漏洩対策で難しいのは、最初の一つのファイルを守ることだけではなく、その情報が増殖した先を追うことである。

この性質は、暗号化された媒体の扱いにも直接関係する。暗号化された HDD をマウントして作業している間、情報は OS から読める。作業中に一時ファイルが作られることがある。ログに一部情報が残ることがある。バックアップが走ることがある。移行作業で検証用コピーが作られることがある。これらはすべて、業務上は自然な処理である。しかし、元の暗号化媒体だけを見ていると、そこから派生した情報の所在を見落とす。

したがって、漏洩は暗号の外側で起きる、という命題は、暗号化を否定する命題ではない。むしろ、暗号化の役割を正確に置き直すための命題である。暗号化は、保存媒体が鍵なしで読まれることを防ぐ。しかし、暗号化された媒体から正規に取り出され、利用され、複製され、送信され、印刷され、バックアップされた情報は、それぞれの場所で別の管理を必要とする。暗号化は最初の境界であって、最後の管理ではない。

ここで、北海道の廃棄 HDD 流出事故に戻ると、問題の見え方が変わる。廃棄 HDD は、単に「古い機械の部品」ではない。そこには、過去に平文として使われ、保存され、場合によっては移行後にも残った情報が入っている可能性がある。現役システムの利用が終わっても、媒体上の情報が消えたわけではない。もし媒体が暗号化されておらず、消去や破壊にも失敗すれば、現役時代には OS やアプリケーションの内側にあった情報が、暗号の外側どころか、組織の管理境界の外へそのまま出ることになる。

この章の結論は、守るべき対象を「元のファイル」や「元の HDD」だけに限定してはならないということである。守るべき対象は、情報そのものであり、情報が移ったすべての場所である。元の媒体、復号済み端末、画面、印刷物、バックアップ、クラウド、保守用コピー、検証環境、廃棄媒体は、同じ情報の異なる現れ方である。情報を守るには、それぞれの現れ方に応じた境界を設計しなければならない。

8. 情報セキュリティは境界管理である

ここまでの議論を一般化すると、情報セキュリティとは、情報を絶対に外へ出さないことではない。情報を完全に外へ出さないなら、情報は安全に見えるかもしれない。しかし、その状態では診療も、会計も、検査も、紹介も、バックアップも、システム移行もできない。情報は、必要な人が、必要な場所で、必要な時に使えるから価値を持つ。したがって、情報セキュリティの中心は、情報の移動をすべて止めることではなく、どの境界を越えてよいか、誰が越えてよいか、越えた後にどう管理するかを設計することである。

ここでいう境界とは、単なる壁ではない。端末のログイン画面、アカウントの認証、アプリケーションの権限、院内ネットワーク、クラウドの共有設定、バックアップ基盤、委託先との契約、記録媒体の保管場所、廃棄工程の台帳確認は、いずれも情報が通過する境界である。境界は、情報を永久に閉じ込めるためだけにあるのではない。正当な利用者を通し、不正な利用者を止め、通った後の責任範囲を明確にするためにある。

医療情報を例にすると、この構造ははっきり見える。診療情報は、医師、看護師、検査部門、薬剤部門、会計、紹介先、保守業者、バックアップ基盤、システム移行担当、廃棄工程の間を移動する。医師だけが情報を見られればよいわけではない。検査部門が結果を返せなければ診療は進まない。会計が必要な情報を扱えなければ請求処理はできない。バックアップがなければ障害時に復旧できない。保守や移行ができなければシステムは維持できない。問題は、情報が移動することではなく、移動の条件が設計されていないことである。

この意味で、情報セキュリティは道路交通に近い。道路をすべて封鎖すれば事故は減るかもしれないが、人も物も動けなくなる。必要なのは、信号、標識、車線、通行許可、速度制限、監視、事故時の対応である。情報も同じである。完全に止めるのではなく、どの道を通し、誰に通行を許し、どの記録を残し、事故が起きたときにどこで止めるかを設計しなければならない。

NIST のインシデント対応指針は、証拠の取得、保全、分析、報告を含むフォレンジック手法を、インシデント対応の中に位置づけている[26]。これは、事故が起きた後に、どの情報がどこを通り、どこで失われ、どこに残っているかを追跡するための考え方でもある。NIST SP 800-53 は、アクセス制御、監査、構成管理、媒体保護、システム保護など、多数の管理策を体系として扱う[27]。CIS Controls も、データ保護、アクセス制御、監査ログ、バックアップ、インシデント対応を組織的な防御項目として整理している[28]。これらはいずれも、暗号だけで安全を達成するという発想ではなく、複数の境界を組み合わせてリスクを下げる発想に立っている。

国際標準の観点でも同じである。ISO/IEC 27001 は、情報セキュリティマネジメントシステムとして、組織がリスクを識別し、管理策を選び、継続的に改善する枠組みを示している[29]。ここで重要なのは、情報セキュリティが一度設定して終わる技術項目ではなく、組織として継続的に管理する対象だという点である。また、ISO/IEC 27040 はストレージセキュリティを対象とし、保存、アクセス、管理、保護、廃棄を含むストレージ環境の安全性を扱う[30]。つまり、保存媒体を守る話は、暗号方式だけでなく、運用、管理、移行、退役まで含む。

境界 何を分けているか 管理すべき通過条件 失敗したときに起きること
端末の境界 端末を操作できる主体と、端末内の情報に触れられない主体を分ける。 ログイン、画面ロック、端末管理、アプリ制御、マルウェア対策、持ち出しルールを管理する。 端末放置、盗難、マルウェア、権限過大なアプリから情報が漏れる。
アカウントの境界 本人または正当な担当者と、第三者を分ける。 認証、二要素認証、権限、復旧手段、共有設定、退職時の無効化を管理する。 クラウド、メール、バックアップ、同期データへ第三者が到達する。
アプリケーションの境界 業務上必要な閲覧や操作と、不必要な閲覧や操作を分ける。 ロール、閲覧範囲、操作権限、監査ログ、権限棚卸し、例外処理を管理する。 本来見る必要のない情報を閲覧でき、内部不正や誤操作の被害が広がる。
ネットワークの境界 院内や社内の管理領域と、外部ネットワークを分ける。 接続元、 VPN、ファイアウォール、セグメント分離、リモート保守経路を管理する。 外部から業務システムへ到達されたり、侵害後に横展開されたりする。
クラウドの境界 ローカル端末上の情報と、外部サービス上に複製された情報を分ける。 アカウント保護、共有範囲、同期対象、バックアップ設定、復旧手段、管理者権限を管理する。 ローカル媒体が安全でも、クラウド側の共有やアカウント侵害から情報が漏れる。
組織の境界 自組織の管理下にある情報と、委託先や外部サービスへ渡った情報を分ける。 委託契約、作業範囲、再委託、持ち出し、作業記録、削除確認、責任分界を管理する。 外部工程で作られたコピーや持ち出された媒体を追跡できなくなる。
媒体の境界 管理された端末や保管場所の内側にある媒体と、外へ出た媒体を分ける。 暗号化、鍵管理、媒体台帳、保管場所、搬出記録、貸出記録、廃棄確認を管理する。 媒体が管理外へ出たときに、内部データが読める状態で残る。
退役の境界 現役で使う情報資産と、使わなくなった端末や媒体を分ける。 利用停止、データ移行、残置確認、鍵破棄、消去、物理破壊、台帳照合を管理する。 業務上は不要になった媒体が、情報を持ったまま保管され、紛失し、市場へ出る。

この表で確認すべきことは、境界が一つではないという点である。端末の境界を強くしても、クラウドアカウントが弱ければ情報は漏れる。アカウントを強くしても、印刷物の管理が弱ければ情報は漏れる。業務システムを厳密に管理しても、保守用コピーや検証環境が緩ければ情報は漏れる。廃棄媒体を台帳で管理しても、媒体が暗号化されておらず、破砕確認も不十分であれば、媒体流出時に情報が読める状態で残る。

暗号化は、この複数の境界の中で、媒体の境界に強く効く。HDD、SSD、外付けディスク、バックアップ媒体が盗難、紛失、転売、破砕漏れによって管理外へ出たとき、暗号化は内容を読める状態で流出させないための境界になる。一方で、暗号化は端末にログイン済みの利用者を区別するものではない。クラウド共有の範囲を自動的に正すものでもない。印刷物を回収するものでもない。委託先の作業記録を保証するものでもない。したがって、暗号化は重要だが、暗号化だけで情報セキュリティ全体を代表させてはならない。

ここで必要になるのが、境界ごとに「通過条件」と「失敗時の被害限定策」を置く発想である。通過条件とは、誰が、どの理由で、どの手段で、どこまで情報へ到達してよいかを定めることである。失敗時の被害限定策とは、その条件が破られたときに、被害をどこで止めるかを決めることである。たとえば、端末が盗まれても媒体暗号化で止める。アカウントが漏れても二要素認証で止める。誤共有が起きても棚卸しで発見する。廃棄工程が失敗しても、鍵破棄や媒体暗号化によって内容を読めない状態にしておく。

設計観点 問い 具体例
通過主体 誰がその境界を越えて情報へ到達してよいのかを決める。 医師、看護師、検査担当、会計担当、保守業者、外部委託先の権限を分ける。
通過理由 どの業務目的なら情報へ到達してよいのかを決める。 診療、検査、請求、紹介、保守、移行、監査、バックアップの目的を区別する。
通過範囲 どの情報まで見せ、どの情報は見せないのかを決める。 患者単位、診療科単位、期間単位、業務ロール単位で閲覧範囲を制限する。
通過記録 誰が、いつ、何にアクセスしたかを後から確認できるようにする。 監査ログ、操作ログ、搬出記録、廃棄証明、台帳照合を残す。
通過後管理 境界を越えた後の情報をどこまで追跡し、いつ閉じるかを決める。 保守用コピーの削除、バックアップの保持期間、共有リンクの失効、旧媒体の破壊確認を行う。
失敗時制限 境界管理が失敗したとき、被害をどこで止めるかを決める。 媒体暗号化、鍵破棄、二要素認証、権限分離、ネットワーク分離、インシデント対応手順を用意する。

この発想に立つと、廃棄 HDD 流出事故の意味も整理できる。廃棄工程は、情報ライフサイクルの最後にある境界である。現役端末から外れた媒体が、組織の管理下から離れ、廃棄業者、破砕工程、証明書、最終処分へ進む。その途中で媒体が外部へ出たなら、退役の境界が破れたことになる。もし媒体が暗号化されておらず、消去や破壊もされていなければ、媒体の境界も同時に破れている。結果として、現役時代には端末やアプリケーションの内側にあった情報が、組織の外で読める状態になってしまう。

逆に、境界が重ねられていれば、事故の性質は変わる。廃棄工程で台数確認に失敗しても、媒体が暗号化されていれば第三者が内容を読む難度は上がる。暗号鍵がすでに破棄されていれば、媒体が残っていても内容へ到達しにくくなる。物理破壊が確実に行われていれば、媒体そのものが読めなくなる。廃棄証明と現物台帳が対応していれば、処分漏れを検知しやすくなる。どれか一つが完全である必要はない。重要なのは、どれか一つが失敗しても、別の境界で止められるようにすることである。

したがって、情報セキュリティは、強い壁を一つ作ることではない。情報が通る境界を洗い出し、それぞれに通過条件、記録、責任、失敗時の被害限定策を置くことである。暗号化は、その中でも媒体流出時に強く効く重要な境界である。しかし、端末境界、アカウント境界、アプリケーション境界、クラウド境界、組織境界、退役境界は、別に設計しなければならない。情報を守るとは、情報を閉じ込めることではなく、情報が通る道を設計し、通った後の責任まで閉じることである。

9. 廃棄媒体には多層防御が必要である

ここまでの議論を実務へ戻すと、廃棄媒体の安全性は、物理破壊だけでも、暗号化だけでも、消去証明だけでも十分ではない。物理破壊は強い対策である。しかし、破壊前に媒体が持ち出されれば効かない。暗号化も強い対策である。しかし、鍵が同じ媒体に残っていたり、復号可能な状態のまま搬出されたりすれば、防御としての意味は弱まる。消去証明も必要である。しかし、証明書に書かれた媒体と実際の媒体が正しく対応していなければ、証明書は管理の根拠にならない。

したがって、廃棄媒体の管理では、「最後に壊せばよい」という考え方を捨てる必要がある。安全な廃棄とは、媒体が最後にどう処理されたかだけではなく、媒体が現役で使われていた時期から、利用停止、搬出、保管、消去、鍵破棄、破壊、証明、台帳閉鎖までを一つの流れとして管理することである。廃棄は、情報ライフサイクルの最後に突然発生する作業ではない。運用開始時から、退役時にどう閉じるかを考えておくべき工程である。

実務でまず重要になるのは、媒体が管理外へ出ても読めない状態を最初から作っておくことである。これは、廃棄時の物理破壊を不要にするという意味ではない。物理破壊は依然として重要である。しかし、物理破壊だけに依存すると、破壊漏れ、取り違え、搬出中の紛失、委託先での不正が起きたときに、媒体上の情報が読める状態で外へ出る。最初から全ディスク暗号化しておけば、この失敗がそのまま情報漏洩になる可能性を下げられる。

NIST の媒体サニタイズ指針では、媒体を再利用または廃棄する際に、情報を現実的に復元できない状態へ近づける考え方が整理されている。そこでは、消去、暗号鍵の破棄、物理破壊などが、媒体の種類や利用目的に応じて選ばれる処理として扱われる[11]。この考え方から見ると、廃棄媒体管理の本質は、単に「壊したかどうか」ではない。媒体上の情報に、第三者が現実的に到達できない状態を作ったかどうかである。

多層防御とは、同じ目的の手順を無意味に重ねることではない。異なる失敗に備える層を重ねることである。暗号化は、媒体が外へ出たときに効く。鍵破棄は、暗号化された媒体を復号できる条件を断つ。媒体消去は、再利用や移管の前に残存データを減らす。物理破壊は、媒体そのものを読めない状態へ近づける。台帳照合は、処理漏れや取り違えを見つける。複数人確認は、単独作業者のミスや不正を見つけやすくする。委託先管理は、自組織の外へ出た工程を追跡可能にする。

防御層 目的 防げる失敗 必要な確認
全ディスク暗号化 媒体が管理外へ出ても、鍵なしでは内容を読めない状態にする。 破砕漏れ、紛失、盗難、転売、搬出中の流出が起きても、媒体単体からの読み取りを困難にする。 対象媒体が暗号化されていること、暗号化対象から除外された領域がないこと、鍵管理が別に行われていることを確認する。
鍵管理 暗号化媒体を復号できる主体、場所、条件を制御する。 暗号化されていても鍵が同じ媒体、同じ保管箱、同じ委託先に残ることで復号される事態を防ぐ。 鍵の保管場所、利用権限、バックアップ、共有範囲、退役時の破棄方法を確認する。
鍵破棄 廃棄対象媒体を復号できる条件を失わせる。 媒体本体が残存しても、復号条件を断つことで内容へ到達しにくくする。 破棄対象の鍵、鍵スロット、バックアップ鍵、復旧用情報が残っていないことを確認する。
媒体消去 再利用、返却、移管、廃棄の前に、残存データを復元困難にする。 暗号化されていない媒体、暗号化状態が不明な媒体、鍵管理に不安がある媒体に追加防御を与える。 消去方式、対象媒体、実行結果、失敗時の扱い、再試行または物理破壊への切り替えを確認する。
物理破壊 媒体そのものを読み取り不能な状態へ近づける。 暗号鍵や消去手順に不備があっても、物理的な読み取りを妨げる。 対象媒体が正しく特定され、実際に破壊され、破壊後の現物または記録で確認できることを確認する。
台帳照合 対象媒体、シリアル番号、台数、所在、処理結果を対応づける。 処理漏れ、取り違え、未破壊媒体の残存、証明書と現物の不一致を検知しやすくする。 搬出前、処理前、処理後、証明書受領時に、同じ媒体を追跡できることを確認する。
複数人確認 単独作業者のミス、不正、思い込みを発見しやすくする。 台数確認の省略、媒体のすり替え、記録だけの処理、破壊漏れを見逃しにくくする。 確認者、確認時刻、確認対象、例外の有無、未処理媒体の扱いを記録する。
委託先管理 自組織の外へ出る廃棄工程を、追跡可能な管理対象として扱う。 委託後の保管不備、再委託、転売、不正持ち出し、処理証跡の不足を検知しやすくする。 委託範囲、再委託条件、搬出記録、処理証跡、破壊証明、例外報告、監査可能性を確認する。

この表で重要なのは、それぞれの防御層が別の失敗に備えていることである。全ディスク暗号化は、媒体が外へ出た後に効く。鍵破棄は、暗号化された媒体を将来読めなくするために効く。物理破壊は、媒体そのものを読めなくするために効く。台帳照合は、そもそも対象媒体が正しく処理されたかを確かめるために効く。複数人確認は、作業者一人の判断や記録だけに依存しないために効く。したがって、どれか一つを選べばよいのではなく、失敗の種類に応じて層を重ねる必要がある。

特に注意すべきなのは、暗号化と鍵破棄を混同しないことである。暗号化された媒体であっても、復号鍵が同じ管理境界に残っていれば、第三者が鍵ごと入手する可能性がある。たとえば、廃棄対象端末の中に自動解除用の情報が残っている、復旧用の鍵が同じ保管場所にある、作業委託先へ鍵情報も一緒に渡している、といった運用では、媒体暗号化の効果は弱まる。暗号化は鍵管理と一体で初めて意味を持つ。

また、物理破壊は「最後の処理」であるため、そこへ至るまでの保管と移動が弱いと事故が起きる。破壊装置に入る前の一時保管、廃棄業者への搬出、処理待ちの保管、台数確認、シリアル番号確認、破壊後の証明書発行までのどこかで媒体が抜け落ちれば、破壊されない媒体が残る。だから、破砕証明書だけを見て安心するのではなく、どの媒体が、いつ、誰によって、どの処理を受けたのかを現物と記録で結びつける必要がある。

実務では、媒体の状態ごとに処理を分ける必要がある。現役媒体、利用停止直後の媒体、再利用する媒体、返却する媒体、破壊する媒体、暗号化状態が不明な媒体では、必要な確認が異なる。すべてを同じ手順で処理しようとすると、例外が見落とされる。とくに、古い端末、リース返却品、保守交換品、検証用ディスク、外付けバックアップ媒体、複合機内ストレージのような周辺媒体は、管理台帳から漏れやすい。

媒体状態 実務上の判断 注意点
現役媒体 利用中の時点から、暗号化、鍵管理、台帳登録、バックアップ方針を決めておく。 退役時だけでなく、運用開始時点で廃棄時の閉じ方を設計しておく必要がある。
利用停止直後の媒体 業務上不要になった直後に、情報管理上の対象として隔離し、所在を固定する。 使わなくなったから安全なのではなく、残存データがある限り管理対象である。
再利用する媒体 再利用前に消去または再暗号化を行い、旧データへ到達できない状態にする。 単なるフォーマットやファイル削除だけでは、残存データ対策として不十分な場合がある。
返却する媒体 リース返却や保守交換では、返却前に消去、暗号鍵破棄、台帳照合を行う。 所有権が自組織から離れるため、返却後に自組織の通常管理を及ぼせない。
破壊する媒体 対象媒体を特定し、搬出前後、破壊前後、証明書受領時に照合する。 破壊予定であることと、実際に破壊されたことは別である。
暗号化状態が不明な媒体 安全側に倒し、読めるデータが残っている可能性を前提に処理する。 暗号化されていたはず、消去済みのはず、空のはず、という推測で扱わない。
周辺媒体 外付け HDD、USB メモリ、バックアップ媒体、複合機内ストレージも台帳対象に含める。 主サーバーや業務端末だけを管理していると、周辺に作られたコピーが残る。

この整理からわかるのは、廃棄媒体管理が単なる廃棄担当者の作業ではないということである。システムを導入する人、運用する人、バックアップを設計する人、保守交換を依頼する人、リース返却を管理する人、廃棄を委託する人が、同じ媒体を別々の局面で扱う。どこかの局面で「これはもう不要な機器だから」と判断されると、情報が残った媒体が管理対象から落ちる。したがって、媒体は機器としてではなく、情報を保持しうる容器として扱う必要がある。

廃棄工程では、例外管理も重要である。台帳上は 20 台あるはずなのに 19 台しかない。シリアル番号が読めない。破壊装置に入らない媒体がある。処理証明書の台数が搬出台数と一致しない。委託先から一部処理不能の連絡がある。こうした例外を、現場判断で流してはならない。例外は事故の前兆であり、そこで止めなければ、未処理媒体が外へ出る可能性がある。

例外 意味 取るべき対応
台数不一致 搬出、保管、処理、証明のどこかで媒体が抜け落ちている可能性がある。 処理を完了扱いにせず、所在確認、作業記録、搬出記録、委託先記録を照合する。
シリアル番号不一致 対象媒体の取り違え、記録誤り、別媒体の混入が起きている可能性がある。 現物確認をやり直し、対象外媒体が処理されていないか、対象媒体が残っていないかを確認する。
処理不能媒体 消去や破壊の標準手順に乗らない媒体が残っている可能性がある。 代替処理、物理破壊、専門処理への切り替えを記録し、未処理のまま返却または放置しない。
証明書不足 処理が完了したことを後から確認できない状態である。 証明書の再発行、対象媒体一覧、処理日時、処理方法、処理者の確認を求める。
委託先変更 再委託や処理場所変更により、管理境界が広がっている可能性がある。 再委託条件、責任分界、搬送経路、保管条件、処理証跡を確認する。

このような手順は、面倒に見える。しかし、面倒さは理由なく増えているのではない。廃棄媒体事故では、媒体が現役のシステムから外れ、通常の監視やアクセス制御の外へ移動する。しかも、利用者からは不要な機器に見えるため、注意が下がりやすい。そこに、委託、搬出、保管、破壊、証明、台帳閉鎖が重なる。工程が増えれば、失敗点も増える。多層防御は、この失敗点の多さに対応するための設計である。

安全な廃棄とは、媒体を壊すことだけではない。壊し損ねても情報が読めない状態を作ることである。消去に失敗しても暗号化で止める。暗号化に不備があっても物理破壊で止める。物理破壊に漏れがあっても台帳照合で見つける。台帳照合に例外が出たら完了扱いにしない。委託先に渡す場合でも、自組織の責任が消えるわけではない。情報を保持する媒体が、最終的にどの状態で閉じられたかを確認して初めて、退役工程は終わる。

廃棄 HDD 流出事故では、物理破壊の失敗がそのまま漏洩可能性になった。もし媒体が最初から暗号化され、鍵が適切に管理され、退役時に鍵破棄が行われ、台帳と現物が照合されていれば、事故の意味は大きく変わっていたはずである。媒体が外部へ出ること自体は重大な管理事故である。しかし、外へ出た媒体が読めるか、読めないかは、被害の大きさを左右する。

したがって、廃棄媒体に必要なのは、最後の破壊作業だけではない。現役時代の暗号化、鍵管理、利用停止時の隔離、廃棄前の台帳照合、消去または鍵破棄、物理破壊、複数人確認、委託先管理、例外時の停止判断をつなげることである。これは、過剰な手続きではない。情報を保持する媒体が、業務の外へ出る最後の局面で、情報を読める状態のまま社会へ流出させないための最低限の設計である。

10. 暗号化ディスク運用は退役まで含めて設計する

ここで、既稿で扱ってきた暗号化ディスク運用へ戻る。物理媒体管理については、媒体の健康状態そのものではなく、必要な時点で必要なデータを復元できることが本質であると整理した[31]。LUKS 暗号化の手順と運用では、暗号化対象の確認、鍵管理、ヘッダーバックアップ、媒体台帳、復元確認までを一つの運用として扱う必要を確認した[32]。TrueCrypt 資産の保全では、古い暗号化資産を単純に捨てるのではなく、読み出し可能性、移行、役割、履歴を管理する必要を扱った[33]。

さらに、暗号化ディスクの長期運用では、暗号化方式、LUKS ヘッダー、key slot、パスフレーズ、keyfile、対応ソフトウェア、マウント手順、媒体の役割を、将来開ける条件として残す必要を整理した[34]。運用手順の整理では、暗号化領域を作ることではなく、将来の時点でも正しく開き、読み取り、点検し、移行し、退役できる条件を維持することが主題になった[35]。また、自由ソフトウェアだけで暗号化媒体を扱う範囲を検討した既稿では、形式、実装、カーネル機能、運用上の限界を分けて確認した[36]。

本稿は、その系列の続きに位置づく。既稿では主に、暗号化媒体をどう作り、どう開き、どう保全し、どう復元可能に保つかを扱ってきた。本稿ではさらに、なぜ最初から暗号化しておく必要があるのか、そして暗号化していてもなぜ情報が漏れうるのかを、事故、スマートフォン、クラウド、廃棄工程へ広げて整理した。つまり、本稿の焦点は、暗号化ディスクを「使える状態で維持する」ことから、「最後に安全に閉じる」ことへ移っている。

暗号化ディスク運用は、暗号化領域を作成した時点では完成しない。むしろ、作成は運用の開始にすぎない。媒体は、作られ、使われ、複製され、バックアップされ、移行され、保管され、やがて退役する。そのどこかで情報は平文になり、どこかで別の媒体へ移り、どこかで管理境界を越える。だから、暗号化ディスクを作るだけで満足する運用は不十分である。退役時に何を消し、どの鍵を破棄し、どの媒体を破壊し、どの台帳を閉じ、どの例外を止めるのかまで決めて初めて、暗号化ディスク運用は閉じる。

廃棄 HDD 流出事故が示したのは、廃棄工程の失敗だけではない。より深刻なのは、業務上不要になった媒体が、情報を読める状態のまま社会へ出てしまうことである。端末が更新されても、媒体に残った情報は消えない。廃棄を依頼しても、破壊が完了したことにはならない。証明書を受け取っても、現物と対応していなければ管理は閉じない。暗号化されていない媒体を、消去、鍵破棄、物理破壊、台帳照合なしに外へ出すことは、情報管理の最後の境界を開いたままにすることである。

ここで、暗号化の位置づけを誤ってはならない。暗号化は、情報漏洩を完全に防ぐ魔法ではない。復号済みの端末、クラウド同期、バックアップ、印刷物、メール添付、保守用コピー、検証環境から情報が漏れることはある。しかし、その事実は暗号化の価値を下げない。むしろ、暗号化の役割を明確にする。暗号化は、媒体が盗まれ、紛失し、転売され、破砕されずに流通したときに、情報を読める状態で外へ出さないための境界である。

したがって、暗号化ディスク運用の結論は明確である。保存媒体は、現役時代から暗号化しておくべきである。鍵は、媒体とは別の管理境界で扱うべきである。バックアップ、移行用コピー、保守用コピーも、元媒体と同じ情報を持つものとして管理すべきである。退役時には、鍵破棄、消去、物理破壊、台帳照合、複数人確認、委託先管理をつなげるべきである。どれか一つの対策に依存するのではなく、どれか一つが失敗しても情報を読ませない構造を作るべきである。

情報を守る設計は、保存を始めるときではなく、捨てるときまで含めて初めて完成する。暗号化ディスクを作ることは重要である。しかし、作った媒体をどう使い、どう複製し、どう移行し、どう保管し、最後にどう閉じるのかを設計しなければ、その運用は未完成である。廃棄媒体が管理外へ出たときに、情報を読める状態で社会へ流出させないこと。これが、暗号化ディスク運用を退役まで含めて設計しなければならない理由である。

参考文献

  1. 独立行政法人国立病院機構北海道医療センター, 個人情報の取扱いに関するお詫びとご報告（2026-06-08）. https://hokkaido-mc.hosp.go.jp/common/img/index/202608.pdf
  2. 独立行政法人国立病院機構北海道がんセンター, 個人情報の取扱いに関するお詫びとご報告（2026-06-08）. https://hokkaido-cc.hosp.go.jp/news/nw1_00021.html
  3. HTB北海道ニュース, 北海道医療センターなど患者約19万人分個人情報含む廃棄HDDが流出 オークションの落札者から連絡（2026-06-08）. https://www.htb.co.jp/news/archives_38021.html
  4. INTERNET Watch, 北海道医療センター・北海道がんセンターで、患者の個人情報を含むHDDが外部に流通。廃棄処理業者が破砕せず（2026-06-09）. https://internet.watch.impress.co.jp/docs/news/2115720.html
  5. 個人情報保護委員会, 個人情報の保護に関する法律についてのガイドライン（通則編）. https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
  6. 厚生労働省, 医療情報システムの安全管理に関するガイドライン 第6.0版（令和5年5月）. https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html
  7. ブロードリンク, 盗難事件の経緯と再発防止について. https://www.broadlink.co.jp/safety/incident/overview/
  8. IT Leaders, 神奈川県庁のHDD流出事件からの教訓 リース契約時の注意点とは（2019-12-13）. https://it.impress.co.jp/articles/-/19011
  9. IPA, 情報セキュリティ10大脅威 2025 組織編（2025-02-28）. https://www.ipa.go.jp/security/10threats/eid2eo0000005231-att/kaisetsu_2025_soshiki.pdf
  10. IPA, 中小企業の情報セキュリティ対策ガイドライン 第4.0版. https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf
  11. NIST, Guidelines for Media Sanitization, NIST Special Publication 800-88 Revision 2（2025）. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf
  12. NIST, Guide to Storage Encryption Technologies for End User Devices, NIST Special Publication 800-111（2007）. https://csrc.nist.gov/pubs/sp/800/111/final
  13. id774, 暗号はいずれ破られる（2026-06-01）. https://blog.id774.net/entry/2026/06/01/4831/
  14. Linux Kernel Documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
  15. Michael Kerrisk, cryptsetup(8) – Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup.8.html
  16. Red Hat, Encrypting block devices using LUKS. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening
  17. Apple, Encryption and Data Protection overview（2024-12-19）. https://support.apple.com/guide/security/encryption-and-data-protection-overview-sece3bee0835/web
  18. Apple, Data Protection classes（2024-12-19）. https://support.apple.com/guide/security/data-protection-classes-secb010e978a/web
  19. Apple, The Secure Enclave（2024-12-19）. https://support.apple.com/guide/security/the-secure-enclave-sec59b0b31ff/web
  20. Android Open Source Project, File-based encryption. https://source.android.com/docs/security/features/encryption/file-based
  21. Android Developers, Support Direct Boot mode. https://developer.android.com/privacy-and-security/direct-boot
  22. NIST, Guidelines on Mobile Device Forensics, NIST Special Publication 800-101 Revision 1（2014）. https://csrc.nist.gov/pubs/sp/800/101/r1/final
  23. Maximilian Zinkus, Tushar M. Jois, Matthew Green, Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions（2021-05-26）. https://arxiv.org/abs/2105.12613
  24. Apple, iCloud data security overview（2026-01-05）. https://support.apple.com/en-us/102651
  25. Android Developers, Security recommendations for backups（2024-10-25）. https://developer.android.com/privacy-and-security/risks/backup-best-practices
  26. NIST, Guide to Integrating Forensic Techniques into Incident Response, NIST Special Publication 800-86（2006）. https://csrc.nist.gov/pubs/sp/800/86/final
  27. NIST, Security and Privacy Controls for Information Systems and Organizations, NIST Special Publication 800-53 Revision 5（2020）. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
  28. Center for Internet Security, CIS Controls Navigator v8.1, Control 3: Data Protection. https://www.cisecurity.org/controls/cis-controls-navigator
  29. ISO, ISO/IEC 27001:2022 Information security management systems. https://www.iso.org/standard/27001
  30. ISO, ISO/IEC 27040:2024 Storage security. https://www.iso.org/standard/80194.html
  31. id774, バックアップ・リカバリー戦略における物理媒体管理（2026-05-10）. https://blog.id774.net/entry/2026/05/10/4743/
  32. id774, LUKS 暗号化の手順と運用（2026-05-11）. https://blog.id774.net/entry/2026/05/11/4746/
  33. id774, TrueCrypt 資産を GNU/Linux で保全する（2026-05-16）. https://blog.id774.net/entry/2026/05/16/4773/
  34. id774, 暗号化ディスクを長期運用するための設計（2026-05-30）. https://blog.id774.net/entry/2026/05/30/4818/
  35. id774, 暗号化ディスク運用手順を整理する（2026-05-31）. https://blog.id774.net/entry/2026/05/31/4829/
  36. id774, 自由ソフトウェアだけで暗号化媒体をどこまで扱えるか（2026-06-03）. https://blog.id774.net/entry/2026/06/03/4849/