データベースのデータ保護機微データ。ゲートし、マスクする。

データベースのデータ保護ガイド

順番に読む。

• 01

  原則から始める

  すべてのアクセス制御システムが答えるべき 4 つの問いと、Postgres、MySQL、SQL Server、Oracle のエンジン固有 GRANT 構文。

• 02

  Just-in-Time でアクセスをゲートする

  JIT ワークフローを end-to-end で辿る — 申請、承認ルール、時間ウィンドウ、自動失効。常設アクセスがなぜ間違ったデフォルトか。

• 03

  見せてはならないものをマスクする

  実用的なプリミティブとしての DDM — クエリ時マスキングが何を変換し、静的マスキングとどう違い、誰が何を見るかを律するポリシーパターン。

• 04

  アクセス経路ごとに実装する

  DDM を実装する 5 つの方法 — エンジンネイティブ、データベース内、アプリケーション、BI、ワークフロー型ゲートウェイ — と、それぞれがどの呼び出し元をマスクするか。アプリの経路にはネイティブ、人間にはゲートウェイ。

データベースのデータ保護に関する質問

よくある質問。

データベースのデータ保護とは？

データベースのデータ保護とは、機微な値が持つべきでない人やシステムに届かないようにするすべての仕掛けです。大きな括りは、暗号化 (保存時・通信時)、アクセス制御 (そもそも誰が接続できるか)、結果集合の制御 (接続できた人が実際に何を見るか) です。本シリーズは後者 2 つに焦点を当てます — 本番インシデントのリスクが最も集まる場所です。前者は通常、クラウドプロバイダーやアプリケーションスタックがインフラ層で解決します。

ゲートとマスクの両方が必要なのは？片方で済むのは？

ゲートだけで足りるのは、承認されたすべてのユーザーが、クエリするカラムのすべての値を見てよい場合です — ロール自体が信頼を表すバックオフィスツールが典型。マスクが上乗せで必要になるのは、異なるユーザーが同じカラムをクエリしてよいが、見えるべきものが違うとき — アナリストにはハッシュ化されたメール、サポートには末尾 4 桁、調査官にはフル値。JIT のゲートと DDM は補完的: JIT は常設アクセスをゼロ近くに保ち、DDM は付与されたアクセスが実際に返すものをフィルタする。

行レベルセキュリティ (RLS) とは何が違うか？

RLS はポリシーに基づいて行全体を隠します。マスキングは行を隠さずに特定のカラム値を変換します。Postgres、SQL Server、Oracle は RLS をネイティブに備えますが、エンジンネイティブの RLS は性能の地雷とバイパスのリスクを伴います (リンク先の Postgres RLS 記事を参照)。ワークフロー型ゲートウェイは DB の前段に立ち、エンジン横断で同じように動くマスキングとゲートのポリシーを、中央集約の監査証跡とともに適用します。