プロンプトと適用範囲
ビジネスデータはオブジェクトストレージ、レイクハウステーブル、ウェアハウスに存在し、アナリストはSQL、Spark、BIツールを使用しています。アクセス管理は手動チケットとローカルエンジンアカウントで行われています。オフボーディングは遅く、監査時にアカウントをまたぐクエリを再構築することができません。目標は、セルフサービスでのリクエスト、最小権限の原則、行・列レベルの保護、緊急アクセス、および単一の監査証跡を実現することです。
ガバナンスレイヤーの設計：分類、承認者、ポリシー決定ポイント（PDP）およびポリシー適用ポイント（PEP）、マルチエンジンのカバー範囲、ブレークグラス（緊急アクセス）、アクセス権の取り消し（revocation）、キャッシュ、エクスポート、そして認可と実際の読み取りの両方が監査可能であることの証明。コアスキルはデータプラットフォームのガバナンスと運用であるため、これはデータに関する質問です。
面接官が評価するポイント
面接官は、「単にRBACを追加する」ことではなく、カタログ、ポリシー、適用、証拠、運用のループを求めています。優れた回答では、アイデンティティ、目的、リソースラベル、行/列フィルター、マスキングを区別し、決定と適用の境界を説明します。
また、サービス間の一貫性にも対処します。同じユーザーがAthena、Spark、BI、またはエクスポートジョブにアクセスする際、認可コンテキストや監査フィールドが失われてはなりません。ログは改ざん防止され、検索可能で、計画的に保持され、成功したクエリだけでなく、拒否（denial）、管理者による変更、緊急アクセスも含まれている必要があります。
最初に明確にすべき質問
- どのようなデータソース、エンジン、アイデンティティプロバイダー、クロスアカウントの境界が存在するか？
- どのカラムが個人情報、財務情報、または契約上制限されたものであり、誰が分類を管理しているか？
- アクセスは、ロール、属性、目的、テナント、行/列フィルター、またはそれらの組み合わせによって決定されるか？
- 承認は1回限りか、更新可能か、それともクエリごとに必要か？
- 緊急アクセスの最大期間、承認者、レビュープロセスはどのようになっているか？
- システムはスキャンされた範囲、返された行数、エクスポート先、サービスアイデンティティを記録できるか？
30秒での回答
「所有者が明確なカタログと機密性ラベルを作成し、アイデンティティ、チーム、目的、リージョン、リソースラベルをポリシー決定ポイントに送信します。各エンジンまたはデータプロキシでの適用により、期限付きの権限付与とともに行/列フィルターおよびマスキングを適用します。許可、拒否、ポリシーバージョン、クエリリソース、サービスアイデンティティ、およびエクスポートイベントは、一元化された改ざん防止ストリームに入力されます。ブレークグラスアクセスは期限切れとなり、レビューをトリガーします。取り消し、クロスアカウントコンテキスト、キャッシュ、ポリシードリフトをテストして、実際の読み取りが監査証跡と一致することを証明します。」
ステップバイステップの解決策
テーブル、カラム、パス、トピック、テナント、および派生データのアセットインベントリを構築します。各アセットには、所有者、分類、ソース、保持期間、および承認された目的が必要です。分類は1回限りのスキャンでは不十分です。スキーマの変更、新しいカラム、ビジネスルールの変更によってレビューがトリガーされます。不確実な機密フィールドは、レビューされるまで保守的なラベルを付与する必要があります。
決定と適用を分離します。決定の入力には、サブジェクトのアイデンティティ、グループ、属性、目的、デバイスまたはネットワークの状態、リソースラベル、環境が含まれます。出力には、許可または拒否、フィルター、マスキング、ポリシーバージョン、有効期限が含まれます。適用はプロキシ、エンジンプラグイン、またはテーブルフィルター内で行われますが、クエリエンジンをバイパスしてもオブジェクトストレージの生のファイルが公開されてはなりません。
セルフサービスのリクエストには、目的、フィールド、期間、所有者を表示します。低リスクで事前承認された用途には短期間のロールを自動的に付与できます。機密性の高いアクセスには、データ所有者またはコンプライアンスの承認が必要です。付与された権限は速やかに期限切れとなり、計画的に更新されます。オフボーディング、チーム変更、プロジェクトの完了によって取り消しがトリガーされます。承認の証拠を、実際に適用されたポリシーバージョンとリンクさせます。
行と列のセマンティクスを説明します。アナリストはマスキングされたメールアドレスや集計結果を閲覧できますが、結合（join）、エクスポート、エラーメッセージを通じて元のデータを復元できてはなりません。テナントの述語は、ユーザー指定のテナントIDではなく、信頼できるアイデンティティから取得します。保護されたソースから保護されていないコピーが作成されないように、エクスポート、一時テーブル、キャッシュ、マテリアライズドビューにも同等の制御を適用します。
監査イベントには、サブジェクト、アイデンティティチェーン、目的、リソース、行/列の決定、ポリシーバージョン、エンジン、クエリまたはジョブID、時間、送信元アカウント、スキャンまたは返されたサイズ、エクスポート先、許可または拒否を含める必要があります。不変（immutable）ストレージ内の低権限の追記専用パスと制御された読み取りユーザーに書き込みます。削除や改ざんを検出するためにチェックサムまたはバージョンチェーンを使用します。拒否やポリシー編集は、成功したクエリと同様に重要です。
エンジンやアカウントをまたいでも、元のユーザーおよびサービスのアイデンティティを保持します。ユーザーの代理として機能するサービスは、その委任チェーンを維持します。クロスアカウントイベントはリソース所有者にコピーされます。コンテキストを伝達できないレガシーエンジンは、隔離するか、事前フィルタリングされたビューに制限するか、コンプライアンス準拠と見なすのではなく監査ギャップとしてマークします。
ブレークグラスは、強力に認証された少人数のグループ向けに設計します。理由の入力、短い自動有効期限、即時アラート、レビューを必須とします。緊急アクセスであっても監査をバイパスすることはできません。ポリシーバージョンはカナリアリリースとロールバック機能を用いてリリースします。拒否、権限昇格の試行、取り消しのレイテンシ、所有者のいないアセット、監査ギャップ、高リスクのエクスポートを監視します。合成アイデンティティとハニーカラムを使用して、データが読み取れるかどうか、およびその読み取りが記録されているかどうかをテストします。
模範解答
「ソース、派生データ、オブジェクトパス、エクスポートを網羅する、所有者が明確なカタログと機密性ラベルを作成します。ポリシー決定ポイントはアイデンティティ、チーム、目的、リージョン、リソースラベルを受け取り、許可、拒否、行/列フィルター、マスキング、ポリシーバージョン、有効期限を返します。適用はプロキシまたはエンジンプラグインに配置し、生のオブジェクトパスにはアクセスできない状態を維持します。
リクエストには目的、範囲、期間、所有者を明記させます。機密性の高いアクセスには承認が必要であり、権限付与はオフボーディングやプロジェクト完了時に期限切れとなります。一時テーブル、キャッシュ、エクスポートにも同じ行/列ポリシーを適用し、ユーザーがコピーを介して値を復元できないようにします。
監査イベントは、ユーザーおよびサービスのアイデンティティチェーン、リソース、ポリシーバージョン、エンジン、クエリID、フィルタリング結果、サイズ、エクスポート先、許可/拒否の結果を不変ストレージに保持します。ブレークグラスアクセスは期限切れとなり、アラートを発報し、レビューを必要とします。クロスアカウントコンテキスト、取り消し、レガシーエンジン、キャッシュ、エクスポート、ハニーカラムをテストして、実際の読み取りが証跡と一致することを証明します。」
よくある間違い
- RBACのみを設計する → 目的、リージョン、列の制限が欠落する → アイデンティティ、属性、ラベル、フィルターを組み合わせる。
- クエリエンジンのみを保護する → ユーザーがオブジェクトストレージ経由でバイパスする → 生のパスを保護し、単一のアクセス境界を適用する。
- 共有ETLアカウントのみをログに記録する → ユーザーの責任追跡性が失われる → 委任チェーンを保持する。
- 成功したクエリのみを記録する → 拒否やドリフトが見落とされる → 拒否、ポリシー編集、緊急使用を記録する。
- 恒久的な権限付与 → プロジェクトアクセス権が永久に残る → 短い有効期限、更新、および取り消しを行う。
- ソーステーブルのみを保護する → キャッシュ、エクスポート、マテリアライゼーションから漏洩する → すべての派生パスにポリシーを適用する。
- ブレークグラスが監査をバイパスする → 緊急パスがバックドアになる → 強力な認証、理由の提示、有効期限、アラート、レビューを行う。
- ポリシーの出力のみをテストする → フィルターがバイパスされる可能性がある → 実際の読み取り、エクスポート、合成アイデンティティ、ハニーカラムをテストする。
フォローアップの質問と回答
フォローアップ1：RBACかABACか？
安定したチーム境界にはロールを使用し、動的な目的、リージョン、ラベル、時間には属性を使用します。実際の多くのシステムでは、ポリシーの複雑さを抑えながら両方を組み合わせています。
フォローアップ2：集計を通じたデータ復元をどのように防ぐか？
小さな母集団、結合、差分クエリ、エクスポート頻度を制限します。必要に応じてしきい値やノイズ（差分プライバシーなど）を使用します。機密性と精度の要件に照らしてルールを検証します。
フォローアップ3：キャッシュの読み取りをどのように監査するか？
キャッシュキーをサブジェクトおよびポリシーバージョンにバインドし、生成（fill）および読み取りのアイデンティティチェーンを記録し、取り消しやポリシー変更時に無効化します。ユーザーコンテキストのない共有キャッシュに機密性の高い結果を保持してはなりません。
フォローアップ4：監査ログに機密性の高いSQLが含まれている場合はどうするか？
完全なSQL、パラメータ、または生データの代わりに、構造化されたリソース識別子と安全な要約を保存します。監査フィールドを慎重に暗号化、制限、保持します。
フォローアップ5：レガシーエンジンが行または列のポリシーを適用できない場合はどうするか？
それを隔離し、事前フィルタリングされたビューのみを公開するか、プロキシの背後に移行し、残りの監査ギャップをマークします。チーム内の申し合わせ（運用ルール）は強制力のある適用ではありません。
フォローアップ6：ガバナンスが分析の速度を低下させないことをどのように証明するか？
決定のレイテンシ、クエリのp95、誤検知による拒否（false denials）、キャッシュヒット率、承認時間を追跡します。アイデンティティまたはポリシーバージョンの変更時には、キャッシュされた決定を即座に無効化します。
フォローアップ7：なぜポリシーバージョンを記録するのか？
同じクエリであっても、ポリシー更新の前後で異なる結果を返す可能性があります。バージョンを記録することで、アクセスが許可、拒否、またはフィルタリングされた理由が説明可能になり、ロールバックやインシデントレビューをサポートします。