持っていないデータは漏れない — 保存しない設計と、オンラインに置かないバックアップ
ランサムウェアの被害が公表されると、「何件の個人情報が流出したおそれがあるか」が必ず報じられます。その数字の中には、使う予定のないまま保存されていたデータも含まれています。退会したユーザーの登録情報、何年分もたまったアクセスログ、問い合わせに添付された書類、テスト用に複製した本番データ。どれも「念のため」に残したものです。
保存していなければ、確認も通知も要らない
2022年4月に施行された改正個人情報保護法で、一定の漏えいが起きた場合には個人情報保護委員会への報告と本人への通知が義務になりました。侵害を受けた企業は、どのデータが、誰の分、どこまで見られたのかを調べなければなりません。保存している量が多いほど、この調査は長く、高くつきます。
同じ法律は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることも求めています。義務ではなく努力義務ですが、侵害を前提にすると意味が変わります。消しておいたデータは、漏れようがありません。
保存しない設計
データを減らす作業は、運用で頑張るより設計に組み込むほうが確実です。
- 集めない。入力フォームの項目を見直し、使い道の決まっていない項目は最初から取りません。生年月日が年齢確認のためだけなら、確認結果だけを残す方法もあります。
- 期限を決めて自動で消す。データの種類ごとに保存期間を決め、期限が来たら削除するジョブを最初から用意します。ログも同じです。
- ログに個人情報を書かない。メールアドレスやトークンをログに出さないよう、出力の段階でマスキングします。
- 本番データを開発環境に持ち込まない。テストには加工したデータか合成データを使います。開発環境は本番より守りが薄いことが多いからです。
- 他社に預けられるものは預ける。クレジットカード番号は、決済代行会社のトークンに置き換えれば自社で保持せずに済みます。
分析に使いたいデータは、集計してから保存すれば、個人を特定できる形で持ち続ける必要はありません。
バックアップを、侵入者の手の届かない場所へ
10月の大阪公立大学の事例では、サーバーとともにバックアップの多くも暗号化されたと報じられました。本番と同じネットワーク上にあり、同じ管理権限で操作できるバックアップは、攻撃者にとっても操作できる場所です。
昔から言われる「3-2-1」の考え方（3つのコピーを、2種類の媒体に、1つは別の場所に）に、最近は「1つはオフラインか書き換え不能な状態に」という条件を足すのが一般的になっています。具体的には次のような方法があります。
- Amazon S3 の Object Lock のような、一定期間は削除も上書きもできない保存先を使う
- バックアップ用の環境を、本番の管理者アカウントとは別の認証で管理する
- テープや切り離したストレージなど、普段はネットワークにつながっていない媒体に定期的に退避する
もう一つ大事なのは、戻せることを確かめておくことです。復元を試したことのないバックアップは、いざというときに使えるかどうか分かりません。
重要な記録ほど、オンラインに置きっぱなしにしない
契約書、会計記録、過去の取引履歴のように、長く保管する必要はあっても毎日は見ない記録があります。こうしたアーカイブを、業務システムと同じ場所に置き続ける理由はあまりありません。取り出すのに少し手間がかかる場所へ移しておけば、侵入されても届く範囲から外れます。
もちろん、手間とのトレードオフはあります。どのデータを、どのくらいの頻度で、誰が取り出すのかを整理したうえで、置き場所を決めるのが現実的です。
関連するサービス
- 侵害を前提にしたセキュリティ設計：データの保存方針、オフライン／イミュータブルなバックアップ、復旧手順の設計
- クラウド移行と運用基盤：クラウド上のバックアップと権限の設計
背景にある被害の状況は、侵害が続く背景と、被害が大きくなる理由で整理しています。