プロンプトとコンテキスト
あるSaaS製品では、サポート担当者、アナリスト、管理者が顧客レコードを閲覧できます。セキュリティ部門は、サポートには連絡先データの一部のみを表示し、アナリストには不可逆マスクを表示し、コンプライアンスを満たす一部のロールにのみ完全な値を表示することを求めています。現在の製品はテーブル全体に対して権限を付与しているため、顧客はエクスポート機能を使って画面上の制限を回避しています。
フィールドレベルの動的マスキングを提供すべきかを判断し、ポリシー、ロール、監査、エクスポートにおける最小限の実用的な体験を定義してください。BigQueryとSnowflakeはいずれもクエリ実行時のカラムレベルマスキングポリシーを文書化しています。面接では、その機能を明確な顧客価値とリスク境界へ転換できるかが試されます。
面接官が評価するポイント
顧客の業務（JTBD）と脅威モデル、機密フィールドの分類、ロールと条件に基づくポリシー、可逆変換と不可逆変換、クエリとキャッシュのパフォーマンス、エクスポート/APIの一貫性、ポリシー設定ミス、監査、および商業的な検証を網羅できているかを評価します。
尋ねるべき確認質問
- どのフィールドとロールでマスキングが必要ですか？また、リージョン、テナント、利用目的の制約は関係しますか？
- 顧客が必要としているのは、部分表示、ハッシュ照合、フォーマット保持、それとも完全な非表示ですか？
- ポリシーを適用すべきUI、API、エクスポート、検索インデックス、キャッシュのパスはどれですか？
- マスキング処理が失敗した場合、デフォルトは拒否（deny）、null、それともクエリの中断にすべきですか？
- 既存の分類タクソノミー、権限ディレクトリ、監査イベントのベースラインは存在しますか？
30秒での回答
「まずは高リスクなフィールドと具体的な業務を検証し、その上で組み合わせ可能なロール・目的別ポリシーの小さなセットを提供します。デフォルトは最小限の開示とし、クエリ実行時に適用します。エクスポートとAPIも同一のエンジンを再利用します。可逆的な開示には追加の承認と監査を必須とし、不可逆マスクは分析用途に提供します。露出度、拒否件数、クエリのp95、エクスポートの一貫性、有料プランの採用率を測定します。」
ステップごとの詳細解説
ステップ1：業務、フィールド、リスクの特定
セキュリティ、サポート、アナリティクス、コンプライアンスの各ロールにヒアリングを行い、データの閲覧、検索、照合、エクスポート、修正について把握します。単一のグローバルな機密フラグを使うのではなく、フィールドを公開、社内限定、個人情報、極秘情報に分類します。
ポリシーをサブジェクト、リソース、目的、環境にバインドします。リージョン、テナント、デバイスの信頼性、チケットのステータスが判断に影響を与える場合がありますが、最初のバージョンでは説明可能で小規模な条件セットをサポートすべきです。
ステップ2：変換処理とデフォルト設定の設計
完全非表示、部分表示、ハッシュ化、フォーマット保持マスキング、制御されたカスタム関数など、明確に定義された変換を提供します。可逆性、順序や照合の維持可否、最大入力長を明記します。
デフォルトは最小限の開示とします。ポリシーが存在しない場合や評価に失敗した場合は、平文を拒否します。可逆的な値の開示には、有効期限の短い権限、確認、理由が必要です。不可逆マスクは集計や重複排除をサポートできますが、暗号化ではありません。
ステップ3：UI、API、エクスポート、キャッシュの統合
マスキングを共通のポリシー判断とし、UIはその結果を描画するだけにします。API、一括エクスポート、検索インデックス、非同期ジョブ、キャッシュには、サブジェクト、テナント、ポリシーバージョン、目的のコンテキストを含める必要があります。画面上のフィールドを隠しても、ダウンロードエンドポイントから露出してはなりません。
下位権限のサブジェクトに対して、平文のキャッシュエントリを再利用してはなりません。ポリシーの更新時には影響を受けるキャッシュを無効化し、旧バージョンと新バージョンの影響を記録します。
ステップ4：パフォーマンスと障害の制御
行ごとにパースするのではなく、一般的なポリシーをキャッシュ可能な決定プランにコンパイルします。大規模なエクスポートにはチャンク処理、レート制限、非同期ジョブを使用します。ポリシー評価、基盤となるクエリ、変換関数のレイテンシを個別に測定します。
ポリシーサービスが利用できない場合、低リスクの非機密フィールドには短期のスナップショットを提供できますが、高機密フィールドでは平文を拒否します。タイムアウトした変換が元の値をサイレントに返してはなりません。リカバリ可能なエラーとサポートパスを提供します。
ステップ5：監査とガバナンスのループを閉じる
監査ログに平文を書き込むことなく、ポリシーバージョン、サブジェクト、フィールドラベル、目的、決定、変換タイプ、エクスポート範囲を記録します。高機密データの開示は、別のアラート、承認、レビューをトリガーします。
リリース前に、コンフリクトチェック、サンプル再生、2人承認を実行します。「誰がどのような条件で何を閲覧できるか」を表示し、顧客が権限設定による非表示をデータの消失と誤認しないようにします。
ステップ6：価値とガードレールの検証
実際の顧客業務でテストします（サポートによるチケット対応、アナリストによる重複照合、監査人による証拠エクスポートなど）。平文の露出、正当なリクエストの拒否、クエリのp95、エクスポートの一貫性、ポリシー変更後の古いキャッシュによる露出を測定します。
規制業界での採用率、エクスパンション収益、サポートチケットの削減、セキュリティイベントを比較します。セルフサービスでのポリシー編集を開放する前に、限定的なセールスでパイロット運用を行います。1社の複雑な条件が全テナントの負担になってはなりません。
優れた模範回答
高リスクなフィールドと業務を検証した上で、ロール、目的、環境に関する限定的な条件を提供します。デフォルトを最小限の開示とし、UI、API、エクスポート、検索、キャッシュ全体で1つのポリシーエンジンを共有します。可逆的な平文表示には短期的な承認と監査を必須とし、不可逆マスクは分析用途をサポートします。ポリシーのバージョン管理と説明可能性を確保し、サービス障害時には機密平文を拒否し、露出度、拒否件数、クエリのp95、エクスポートの一貫性、有料プランの採用率を測定した後にのみ機能を拡張します。
よくある間違い
- 画面上のフィールドのみを隠す → APIやエクスポートから依然として漏洩する → すべての出力パスに単一のポリシーを適用する。
- マスキングを暗号化と呼ぶ → 顧客が可逆性を誤解する → 変換と鍵の境界を明確に記述する。
- 評価失敗時に平文を返す → 障害が情報漏洩につながる → デフォルトで機密平文を拒否する。
- ポリシーバージョンなしでキャッシュする → 低権限ユーザーが古い平文を受け取ってしまう → サブジェクト、バージョン、目的によって分離する。
- 任意の条件をサポートする → 説明、テスト、課金が不可能になる → 限定的で組み合わせ可能な条件から始める。
フォローアップの質問と回答
フォローアップ1：部分表示とハッシュ化はどのように使い分けますか？
部分表示は人間による認識や折り返し連絡をサポートし、ハッシュ化は照合や重複排除をサポートします。衝突、推論、フォーマット漏洩のリスクを説明し、どちらもアクセス制御そのものとして扱ってはなりません。
フォローアップ2：サポートが一時的に完全な値を閲覧するにはどうすればよいですか？
チケットまたはビジネス上の理由、短期の権限付与、確認操作、完全な監査ログを必須とします。自動的に権限を失効させ、一括エクスポートやコピーを制限します。
フォローアップ3：ポリシー評価によってレポートの速度が低下しませんか？
コンパイル済みプランをキャッシュし、クエリバッチごとにサブジェクトと目的を評価し、大規模なジョブは非同期化します。ポリシー、クエリ、変換関数の個別のp95を監視します。
フォローアップ4：バイパス（回避）経路が存在しないことをどう証明しますか？
UI、API、エクスポート、検索、キャッシュ、非同期ジョブを網羅的にリストアップし、権限マトリクスとロール間リプレイテストを実行して、すべてのパスでポリシーバージョン、結果の形式、監査記録を検証します。