課題とコンテキスト
あるB2Bプラットフォームには多数のビジネスサービスが存在し、それぞれが「このユーザーはこのリソースにアクセスできるか？」というロジックを再実装しています。ロール、リソース関係、属性条件をサポートする、共有型のマルチテナント認可ポリシーサービスを構築してください。ポリシーの更新にはバージョン管理が必要であり、中心的なサービスの一時的な障害によってテナント間の不正アクセスが発生してはなりません。
焦点となるのは認可決定パスとその一貫性境界です。単にポリシーデータベースを描くだけでなく、リクエストコンテキスト、ポリシーの配信、キャッシュの無効化、および拒否やタイムアウトが呼び出し元に与える影響について説明してください。
面接官がテストしていること
ビジネスサービスにおけるポリシー決定ポイント（PDP）とポリシー適用ポイント（PEP）を分離し、テナント分離、バージョン伝播、説明可能な監査を設計できるかが問われています。OPAはポリシー決定と適用の分離を文書化しており、Zanzibarの論文はグローバルな認可スケールにおける因果的一貫性と低レイテンシのトレードオフを示しています。
最初に明確にすべき質問
リクエスト量、レイテンシ目標、ポリシーの複雑さ、テナント数、関係の深さ、および一貫性の要件について質問します。ポリシーの作成者、承認ワークフロー、失効期限、オフライン評価、決定ログ内の機密フィールド、および呼び出し元が安全にフェイルクローズできるかどうかを確認します。
30秒の回答構成
認可モデルと「テナント間アクセスの禁止」という不変条件を定義し、PEP、PDP、ポリシーストレージ、配信、監査を図示します。ポリシーはテナントごとにバージョン管理され、PDPは承認されたバージョンをローカルまたは同一ゾーン内にキャッシュします。リクエストにはサブジェクト、アクション、リソース、および必要なコンテキストが含まれます。リスクの高い失効にはバージョン確認が必要であり、PDPが利用できない場合、機密アクションは拒否されます。p99レイテンシ、伝播遅延、誤拒否、および監査の完全性を測定します。
ステップバイステップ分析
ステップ 1: 認可オブジェクトとポリシー入力の定義
一貫したリクエスト形式（サブジェクト、アクション、リソース、コンテキスト）を使用し、テナントとリソースの名前空間を明確にします。RBACはロール付与を処理し、ABACは部署、デバイス、時間などの属性を処理し、関係ベースの認可は「このユーザーはこのドキュメントの共同作業者である」といった関係を処理します。ポリシー言語は、各サービスが独自のルールを組み立てることなく、許可、拒否、優先順位、および条件を表現できる必要があります。
ステップ 2: PEP、PDP、およびポリシー管理の分離
PEPはAPIゲートウェイまたはビジネスサービス内に配置され、信頼できるアイデンティティを収集し、許可または拒否を適用します。PDPは評価を行い、決定、ポリシーバージョン、およびオプションの理由を返します。管理プレーンはポリシーの編集、検証、承認、公開、およびロールバックを行います。OPAは決定を適用から分離し、ローカルまたはネットワークのデプロイをサポートします。レイテンシと可用性に基づいて選択します。
ステップ 3: テナントストレージとバージョン管理された公開の設計
ポリシー、リソース関係、および属性には tenant_id が付与され、読み取りごとにチェックされます。公開時には不変のバージョンとダイジェストが作成され、サンドボックスで評価された後、PDPにバッチで配信されます。作成者、承認者、時間、およびスコープを記録します。失効ポリシーやセキュリティポリシーを優先させ、古いバージョンを一定期間内に失効させることができます。
ステップ 4: 一貫性、キャッシュ、および失効の処理
キャッシュキーにはテナント、サブジェクト、アクション、リソース、および policy_version を含めます。ユーザーIDのみを使用するのは安全ではありません。リスクの低い許可は測定されたTTLでキャッシュしますが、失効、管理者による変更、および機密リソースについては、短いTTLまたは強制的なバージョンチェックを使用します。PDPは使用したバージョンを返し、ビジネスサービスは古いバージョンを拒否できます。マルチリージョンデプロイでは、同時無効化を前提とせず、バージョンのウォーターマークを伝播させます。
ステップ 5: 障害モードと安全なデフォルトの設計
PDPのタイムアウト、ポリシー配信の遅延、属性ソースの利用不可、および監査パイプラインの混雑に対する動作を定義します。機密性の高い書き込み、権限の変更、およびエクスポートはフェイルクローズします。リスクの低い読み取りは、承認された期限付きキャッシュを使用できます。呼び出し元は、ネットワークエラーを決して許可（allow）に変換してはなりません。ポリシー評価がDoS（サービス拒否）の攻撃ベクトルにならないよう、ポリシーサイズ、関係の再帰深度、およびテナントごとのQPSを制限します。
ステップ 6: 監査、説明可能性、および可観測性
decision_id、テナント、サブジェクトの概要、アクション、リソースの概要、結果、ポリシーバージョン、およびレイテンシを記録し、機密性の高い入力はマスキングまたはハッシュ化します。ログは、新たなデータ漏洩経路となることなく、「誰が、いつ、どのバージョンのもとで、何に対して許可されたか」を回答できる必要があります。p50/p95/p99、キャッシュヒット率、バージョン伝播、拒否率、タイムアウト、およびリトライを監視し、異常な拒否やロールバックが発生した場合はアラートを発報します。
高品質な回答例
システムをビジネスサービス内のPEP、ゾーン内PDPクラスター、および独立した管理プレーンに分割します。リクエストにはサブジェクト、アクション、リソース、および信頼できるコンテキストが含まれます。PDPはテナントごとに分離されたRBAC、関係、および属性ポリシーを評価し、許可または拒否、decisionid、および policyversion を返します。ポリシーの編集内容は検証およびテストされ、不変のバージョンとなり、テナントおよびリージョンごとに配信され、ロールバックをサポートします。
キャッシュキーにはテナント、サブジェクト、アクション、リソース、およびバージョンを含めます。通常の読み取りでは短いTTLの許可キャッシュを使用できますが、失効、権限の変更、およびデータエクスポートではバージョン確認が必要です。呼び出し元は、必要なウォーターマークよりも古いPDPの結果を拒否します。機密アクションでは、PDPのタイムアウトや属性の欠落時にフェイルクローズします。
各決定ログには、マスキングされた入力とともにテナント、サブジェクトの概要、アクション、リソースの概要、結果、バージョン、およびレイテンシが記録されます。コアメトリクスは、p99レイテンシ、ヒット率、伝播遅延、古いバージョンによる拒否、エラー、および監査の完全性です。これにより、ポリシー管理を一元化しつつ、適用はサービスの境界に維持されます。
よくある間違いと改善策
- 単一の「認可マイクロサービス」を描くこと：PEP、PDP、管理、および配信パスを追加してください。
- RBACのみに言及すること：属性や関係がどのように決定に反映されるかを説明してください。
- ユーザーのみでキャッシュすること：テナント、リソース、アクション、およびポリシーバージョンを含めてください。
- タイムアウト時に許可すること：機密操作はフェイルクローズし、リスクの低いキャッシュの使用を明示してください。
- リクエスト全体をログに記録すること：追跡可能な decision_id とバージョンを保持しながら、入力をマスキングしてください。
フォローアップの質問と回答
失効はどのくらい迅速に有効になる必要がありますか？
リスクに応じて失効を分類します。管理者、エクスポート、および機密データのアクションについては、最新のポリシーバージョンまたは短く制限された伝播ウィンドウを要求します。リスクの低い読み取りは、測定されたTTLを使用できます。目標を設定し、それを監視してください。
PDPはローカルで実行すべきですか、それとも共有サービスとして実行すべきですか？
レイテンシと障害の分離のためにローカルまたは同一ゾーンのPDPを使用し、ポリシー配信には共有管理プレーンを使用します。中央のネットワークPDPは更新を簡素化できますが、すべてのリクエストに依存関係を追加します。ワークロードごとに選択し、障害モードをテストしてください。
あるテナントが別のテナントのポリシーを読み取るのをどのように防ぎますか？
認証されたリクエスト内にテナントアイデンティティを含め、ストレージおよびキャッシュキーでそれを強制し、リリースのゲート条件としてクロス・テナント・クエリをテストします。呼び出し元のペイロードのみから提供されるテナント識別子を決して信頼しないでください。
予期しない拒否はどのようにデバッグしますか？
decision_id とポリシーバージョンを返し、マスキングされた入力、一致したルール、属性の鮮度、および伝播状態を調査します。エンドユーザーに機密性の高いポリシーの内部情報を開示してはなりません。オペレーターには制御された説明ビューを提供してください。