家の鍵を何重にする？「保存時暗号化」で泥棒に勝つための設計術
こんにちは。セキュリティの現場に長くいると、よく「完璧な金庫を作れば、もう安心ですよね？」という質問を受けます。でも、現実はそう甘くありません。
泥棒は「正面玄関の鍵（データベース全体）」をこじ開けようとすることもありますし、あるいは「家の壁を突き破って、特定の宝箱だけ（個人のクレジットカード情報など）」を盗もうとすることもあります。
今日は、そんなデータという「大切な宝物」をどう守るか、保存時暗号化（Encryption at Rest）の基本と実践を、泥棒の視点を交えて一緒に紐解いていきましょう。
—
1. 泥棒から宝物を守る：TDE（透過的暗号化）の役割
まず、データベースそのものに鍵をかけるTDE（Transparent Data Encryption）について考えてみましょう。
これは、例えるなら「家全体を頑丈なシャッターで覆うこと」です。
HDDやSSDという「物理的な土地」からハードディスクが抜き取られたり、データベースファイルそのものがコピーされたりしても、中身は暗号化されているので読めません。
- メリット: 設定が簡単。アプリケーション側は何も気にせず、いつも通りにデータを読み書きできます。
- 盲点: データベースの中にログインできる権限（SQLインジェクションなど）を持った泥棒には、シャッターが閉まっていても無意味です。泥棒は「家の中（データベースの中）」にいるのですから。
2. 宝箱に個別の鍵を：フィールドレベル暗号化
次に、特定のデータ項目（マイナンバーや電話番号など）を暗号化するフィールドレベル暗号化です。これは「宝箱一つ一つに個別の鍵をかけること」です。
たとえ泥棒が家の中に侵入してきても、宝箱の鍵（暗号化キー）がアプリケーション側にあり、データベース側には渡されていなければ、泥棒は中身を盗めません。
- メリット: データベース管理者がデータの中身を覗き見ることができません（特権IDの悪用対策）。
- 盲点: どこで暗号化・復号化を行うか、キーの管理はどうするかという実装の複雑さが増します。
—
3. 実践！アプリケーション層での暗号化（PHPの例）
「難しそう……」と感じるかもしれませんが、まずは基本の仕組みを見てみましょう。PHPで特定の文字列をAES-256で暗号化するサンプルです。
<?php
// 暗号化アルゴリズム（AES-256-CBC）
$method = 'aes-256-cbc';
// 本来は環境変数などで厳重に管理すべき「秘密の鍵」
$secret_key = 'your-very-secret-key-that-no-one-knows';
// 初期化ベクトル（IV）は暗号化するたびにランダムに生成するのが鉄則！
$iv = openssl_random_pseudo_bytes(openssl_cipher_iv_length($method));
$data = "秘密のマイナンバー";
// 暗号化を実行
$encrypted = openssl_encrypt($data, $method, $secret_key, 0, $iv);
// データベースには「暗号化されたデータ」と「IV（復号に必要）」をセットで保存します
// IVは暗号化の「味付け」のようなもので、毎回変えることでパターン攻撃を防ぎます
echo "保存するデータ: " . base64_encode($encrypted) . ":" . base64_encode($iv);
?>ここがポイント：なぜ「キー」を分けるのか？
コード内の $secret_key をソースコードに直書きしてGitにアップロードするのは、「家の鍵を玄関マットの下に置く」のと同じです。
必ず、クラウドのキー管理サービス（AWS KMSやGoogle Cloud KMSなど）を利用して、コードと鍵を分離する運用を徹底してください。
—
4. 泥棒を寄せ付けないための「鉄則」
最後に、現場でよく見る「失敗のパターン」を回避するためのアドバイスです。
1. 「鍵（キー）」と「データ」を同じ場所に置かない
- データベースのバックアップと一緒に鍵もバックアップしていませんか？ 鍵を失えばデータはゴミ屑になり、鍵が盗まれれば一発でアウトです。
2. 暗号化の「粒度」を考える
- 全てをフィールドレベルで暗号化すると、検索や並び替えができなくなります。「名前」は検索したいから暗号化しない、でも「メールアドレス」は暗号化する、といったバランスが重要です。
3. HTTPヘッダーの意識
- Webアプリケーションであれば、
Strict-Transport-Security（HSTS）ヘッダーを有効にし、通信経路（移動中）の暗号化も忘れないでください。保存時だけ固くしても、輸送中に横取りされては意味がありません。
—
まとめ：一歩ずつ、確実に
セキュリティは「これ一つで全部解決！」という魔法はありません。
- 家全体を守る（TDE）
- 大切な宝箱だけさらに鍵をかける（フィールドレベル暗号化）
- 鍵の置き場所を隠す（KMSの活用）
この多層防御の考え方こそが、プロのエンジニアが信頼を寄せる「泥臭くも確実な守り」です。
最初から完璧を目指す必要はありません。まずは「このデータが漏れたら誰が困るか？」を想像することから始めてみてください。それが、最強のセキュリティへの第一歩になりますよ。
それでは、また次回のブログでお会いしましょう。ハッピー・コーディング！
コメント