個人情報を扱う既存DBの管理を見直すチェック

「うちのDB、どのテーブルに何の個人情報が入ってるか、正確に答えられる人います?」と聞くと、多くの現場で一瞬沈黙が起きます。取引先からのセキュリティ確認や、プライバシーマークの更新、あるいは「個人情報保護法まわり、大丈夫だよね?」という一言をきっかけに、既存プロダクトのDBを初めて棚卸しする、という相談を私たちはよく受けます。この記事では、既存のRails/Node/PythonアプリケーションのDBに眠る個人情報をどう洗い出し、何がリスクで、どう直すかを発注者向けに整理します。

まず「どこに何があるか」を棚卸しする

改善以前に、多くの現場は自社DBの個人情報の所在を正確に把握できていません。数年運用されたプロダクトほど、機能追加のたびにカラムが足され、把握が追いつかなくなっています。

• 氏名・住所・電話番号・メールアドレスといった直接的な個人情報が入っているテーブル・カラムを列挙する
• クレジットカード番号・銀行口座・マイナンバーなど、法令上さらに厳格な扱いが求められる項目が混ざっていないか
• usersテーブルのような主要テーブルだけでなく、問い合わせフォームの保存内容・CSVインポート履歴・バッチ処理の中間テーブル・管理画面のメモ欄など、副次的な場所にも個人情報が漏れ込んでいないか
• 本番DBのダンプがローカル開発環境やステージング環境にそのままコピーされていないか(これも個人情報の「所在」の一つです)

棚卸しはinformation_schemaからカラム名を機械的に抽出するところまでは自動化できますが、「このJSONカラムの中に実は住所が入っている」といった構造化されていないデータは人が中身を見て判断する必要があります。ここを飛ばして対策だけ進めると、対策漏れの箇所が必ず残ります。

よくあるリスクのパターン

棚卸しをすると、たいてい次のどれか(あるいは複数)が見つかります。

• 平文保存。パスワードはハッシュ化されていても、氏名・住所・電話番号はもちろん平文でよいものの、クレジットカード番号やマイナンバーのような本来DBに保持すべきでない情報まで平文カラムに残っているケースがあります。決済情報は自社DBに持たず決済代行側に委ねる(非保持化)のが原則ですが、古い実装では自前保存が残っていることがあります。
• 過剰保持。退会済みユーザーの個人情報が論理削除(deleted_at)のまま何年も物理的にDBに残り続けている。利用目的を終えたデータを消さずに持ち続けること自体がリスクであり、保有期間が長いほど漏洩時の被害範囲も広がります。
• アクセス制御なし。管理画面から誰でも全ユーザーの個人情報を閲覧・エクスポートできる。退職した元従業員のアカウントが無効化されておらず、管理画面に今もログインできる状態になっていることも珍しくありません。
• ログへの混入。アプリケーションログやAPMツール(New Relic、Datadog等)に、リクエストパラメータがそのまま出力され、フォーム送信内容(氏名・メールアドレス・場合によってはパスワード)がログに残っている。ログは開発者全員が閲覧できることが多く、DB本体よりアクセス制御が緩いまま個人情報を保持している場合が多いです。
• バックアップ・エクスポートファイルの野放し。定期バックアップやCSVエクスポート機能で生成されたファイルが、アクセス制御のないS3バケットや共有ドライブに置かれている。

これらは機能には影響しないため、発覚するまで誰も気づかない点が共通しています。取引先の審査や監査で初めて発覚し、そこから急いで対応する、という順番になりがちです。

改善の進め方

一気に全部直そうとすると業務が止まるので、リスクの高いものから段階的に着手します。

1. 暗号化

DBに保持する必要がある機微情報(マイナンバー、必要最小限の決済関連情報など)は、カラムレベルでの暗号化(RailsならActiveRecord::Encryption、あるいはアプリケーション層での暗号化)を検討します。DB自体のディスク暗号化(at-rest暗号化、AWS RDSなら標準機能)はほぼコストゼロで効果があるため、未設定なら真っ先に有効化します。ただし暗号化は「盗まれても読めなくする」対策であって、「そもそも持たない」に勝る対策はない、という前提は崩しません。

2. マスキング

開発環境やステージング環境に本番DBのダンプをそのまま流用しているケースは特に多く見られます。氏名・メールアドレス・電話番号をダミーデータに置き換えるマスキングスクリプトを、DBコピーの手順に組み込みます。これを整備するだけで、開発メンバーや委託先の人数が増えても個人情報の露出範囲を増やさずに済みます。

3. アクセス制御

管理画面での個人情報閲覧・エクスポート機能に、権限ロールを設ける(誰でも全件エクスポートできる状態をなくす)。誰がいつどの個人情報を閲覧したかの操作ログを残す。退職者・契約終了した委託先のアカウントを無効化する運用を、都度対応ではなくチェックリスト化しておきます。

4. 保持ポリシーの策定と削除対応

「退会後何年でデータを削除するか」を利用目的に照らして定め、定期バッチで物理削除(または匿名化)を自動実行する仕組みを作ります。あわせて、本人からの開示・削除請求が来た場合に、どのテーブルのどのレコードを削除すればよいかを棚卸し結果から即座に特定できる状態にしておきます。棚卸しをせずにこの対応をしようとすると、削除漏れのテーブルが必ず出ます。

段階対応の優先順位

すべて同時にはできないので、私たちは通常この順で提案します。

1. 棚卸しでリスクの全体像を可視化する(ここが不十分だと以降の優先順位付けが的外れになる)
2. 決済情報・マイナンバー等、法令上の要求が厳しい項目の平文保存を最優先で解消する
3. ログ・バックアップ・開発環境への個人情報の漏れ込みを止める(コストが低く即効性が高い)
4. アクセス制御・保持ポリシーを仕組み化し、属人対応から抜け出す

棚卸しだけで着手できる範囲も多く、必ずしも大規模改修から始める必要はありません。まず現状を正確に把握することが、過剰投資も過小対応も避ける一番の近道です。

外注する場合の進め方

個人情報の扱いの見直しを外部に依頼する場合、次を確認すると失敗を避けやすくなります。

• DBの中身を実際に見て棚卸しから始めるか。ヒアリングだけで「たぶんこう」と進める提案は、対策漏れが出やすいので避けます。
• 「暗号化すれば終わり」で終わらせず、保持ポリシーとアクセス制御まで踏み込むか。技術対策だけでは、退職者アクセスや過剰保持といった運用面のリスクは残ります。
• 段階的な優先順位を示せるか。法令上の要求が厳しい項目から着手する現実的なロードマップになっているかを見極めます。

torcheees ではデータベース領域でRDSやPostgreSQLの設計・運用を数多く手がけており、既存プロダクトの改善、外部チームが最初に見る観点で紹介している引き継ぎ調査の一部として、個人情報の棚卸しも実施します。あわせて、本番のAPIキーやDBパスワードの管理がずさんな場合は本番の秘密情報管理を見直すための改善チェックも参考にしてください。

まとめ

• 個人情報保護の見直しは、まず「DBのどこに何の個人情報があるか」を正確に棚卸しするところから始まる。ここが曖昧なままだと対策の優先順位も削除対応も的外れになる
• リスクは平文保存・過剰保持・アクセス制御なし・ログやバックアップへの混入といった形で現れ、機能に影響しないため発覚するまで放置されがち
• 改善は暗号化・マスキング・アクセス制御・保持ポリシーを法令上の要求が厳しい項目から段階的に着手するのが現実的で、全面改修から始める必要はない

「個人情報の扱いが不安だが、何から手をつければいいか分からない」という段階でも構いません。torcheees では既存プロダクトの診断から、継続的な改善支援まで、実際のDB構造を確認した上で優先順位と概算費用をご提示します。お問い合わせフォームからご相談ください。