質問と適したシナリオ
プラットフォームチームが、「データベースをパブリックにしてはならない」、「署名されたイメージのみ実行可能」、「あるロールは自身のテナントのみ読み取り可能」といったルールを、テスト可能、レビュー可能、かつ自動的に強制できるようにしたいと考えています。面接官は、あなたにPolicy as Codeについて説明し、ポリシー決定とビジネス実行の間の境界を引くことを求めています。
リクエストはAPI、CI/CD、またはインフラストラクチャの変更から届くものとし、ポリシー入力は構造化されたJSONであり、ポリシーにはバージョン管理、ロールバック、および監査可能性が必要であると想定します。この質問は境界と論理的思考に関するものであり、OPA、Rego、または特定のベンダーへのコミットメントを問うものではありません。
面接官が評価している点
- ポリシー定義、決定計算、および強制（Enforcement）の責任を分離しているかどうか。
- ポリシーエンジンがブール値だけでなく構造化された結果を返せることを理解しているかどうか。
- ポリシーと入力バージョンの整合性、タイムアウト、キャッシュ、およびデフォルト拒否（Default Deny）を処理しているかどうか。
- ポリシーコードを、単にコピーされた設定ではなく、レビュー、テスト、リリース、および監査が必要なソフトウェアとして扱っているかどうか。
不十分な回答は「認可にはOPAを使用します」と答えるだけです。優れた回答は、リクエストの境界にPolicy Enforcement Pointを配置し、Policy Decision Pointを計算に集中させ、各決定を説明可能、再生可能、かつ追跡可能にします。
回答前に明確にすべき質問
- その決定はランタイムアクセス向けですか、それともデプロイ前のコンプライアンス向けですか？ランタイムの決定ではレイテンシと可用性が重視され、デプロイチェックではフィードバックとブロックが重視されます。
- アイデンティティ、テナント、リソースラベル、および環境状態は誰が提供し、それらのフィールドは信頼できますか？入力の欠落が暗黙的に許可になってはなりません。
- 障害発生時、システムはデフォルト拒否、許可への縮退、または人間の承認の要求のいずれを行うべきですか？答えはアクションの影響度と可用性の目標によって異なります。
- ポリシーの配信はアプリケーションのリリースから独立できますか？独立したリリースには、バージョンのバインド、互換性チェック、および迅速なロールバックが必要です。
- 監査レコードには何を含める必要がありますか？入力に個人情報や機密データが含まれている場合、ログを保存またはアップロードする前にマスキング（Redaction）する必要があります。
30秒の回答フレームワーク
「Policy as Codeは、実行可能なルールをバージョン管理、レビュー、およびテストの対象とします。リクエストはPEPに到達し、PEPはサブジェクト、アクション、リソース、およびコンテキストを収集・正規化して、正規化された入力とポリシーバージョンを指定してPDPを呼び出します。PDPは許可、拒否、理由、義務（Obligations）などの構造化された決定を返し、PEPが実際にアクションをブロックまたは継続します。私はデフォルト拒否、範囲とバージョンが限定されたキャッシュ、およびマスキングされた決定ログを使用します。リリース前にはリプレイチェックやカナリアチェックを実行し、緊急例外は期限付き、承認済み、かつ監査可能にします」
ステップごとの詳細な回答
1. ポリシーオブジェクトと境界の定義
自然言語のルールをサブジェクト、アクション、リソース、条件、および結果に変換します。「サービスは暗号化されていないパブリックポートを公開してはならない」というルールは、サブジェクトがデプロイパイプライン、アクションがサービスの作成、リソースがサービス設定、条件がポートとネットワークの属性、結果が修復メッセージ付きの拒否を意味します。
PDPは正規化された入力とポリシーを読み取り、allow、deny、warn、またはより豊富な構造化データを返します。PEPはAPI、アドミッションコントローラー、CIジョブ、またはサービス呼び出しの境界に配置され、結果をブロック、継続、変更（Mutate）、または人間へのエスカレーションに変換します。
caller -> PEP: subject, action, resource, context
PEP -> PDP: normalized input + policy version
PDP -> PEP: decision, reasons, obligations, decision_id
PEP -> target: enforce decision or stop request
PEP -> audit: redacted decision recordOPAのドキュメントでは意思決定と強制が明示的に分離されており、AWSのガイダンスでもAPI上のPEPとともにPDPが説明されています。その境界により、ポリシーエンジンがビジネストランザクションを実行しているかのように見せかけることなく、1つのルールセットで複数のエントリポイントに対応できます。
2. 入力の正規化と欠落フィールドの処理
生データの形式はエントリポイントによって異なります。CIはYAMLプランを提供し、APIはHTTPリクエストを、サービス呼び出しはオブジェクトを提供する場合があります。PEPまたは認可レイヤーは、これらを安定した内部形状に変換し、ソース、タイムスタンプ、およびデータバージョンのメタデータを付与する必要があります。
テナント、所有者、または環境状態が欠落している場合、推測するよりもデフォルト拒否の方が安全です。ポリシーは明示的な拒否と「決定不能」を区別し、PEPが承認を要求したり再試行したりできるようにする必要があります。未定義が許可として扱われてはなりません。
{
"subject": {"id": "u-17", "tenant": "t-3", "roles": ["reader"]},
"action": "read",
"resource": {"type": "invoice", "id": "inv-9", "tenant": "t-3"},
"context": {"environment": "prod", "authn_level": "mfa"},
"policy_version": "2026-06-18.4"
}3. ポリシーをテスト可能なソフトウェアとして扱う
ポリシーファイルはGitに属し、構文チェック、単体テスト、敵対的ケース、およびコードレビューを通過する必要があります。テストでは、許可パスのほか、隣接テナント、欠落フィールド、期限切れのアイデンティティ、競合するルール、およびデフォルトのパスをカバーする必要があります。
package invoices
default allow := false
allow if {
input.action == "read"
input.subject.tenant == input.resource.tenant
"reader" in input.subject.roles
}テストではポリシーバージョンとデータスナップショットを固定します。ルールがライブのディレクトリやネットワーク呼び出しに依存している場合は、ローカルキャッシュが許容されるかどうかを判断する前に、タイムアウトと古さの制限を定義します。
4. 配信、キャッシュ、およびロールバックの設計
ポリシーのリリースには、サービスのリリースと同様に、バージョン、互換性チェック、およびロールバックが必要です。PDPはローカルサイドカー、ライブラリ、または集中型サービスとして実行できます。ローカル実行はネットワークレイテンシを削減し、集中化は管理を簡素化します。選択は更新速度、影響範囲、および整合性の要件に依存します。
サブジェクト、リソース、ポリシーバージョン、および認可データバージョンをバインドし、明示的な有効期間を持つ決定のみをキャッシュします。権限の取り消し、テナント移行、および高リスクなアクションでは、迅速に無効化できない長いキャッシュを使用してはなりません。PDPがタイムアウトした場合、PEPはアクションのリスクに応じて拒否、承認、または事前に承認された狭いパスを選択します。
5. 説明可能でマスキングされた決定の記録
インシデントの再現のため、各決定には少なくともポリシーバージョン、入力の要約、結果、理由、決定ID、およびPEPアイデンティティが必要です。入力にはユーザー名、トークン、またはシークレットが含まれる場合があるため、ログ記録レイヤーは保存またはアップロードの前に機密フィールドを削除またはマスキングする必要があります。
許可には、監査イベントの書き込み、フィールドの制限、またはステップアップ確認の要求などの義務（Obligations）が付随する場合もあります。PDPが義務を返し、PEPがそれを実行し、実行できない場合は拒否またはエスカレーションします。
質の高い模範回答
私はPolicy as Codeを、セキュリティ、コンプライアンス、および運用上の制約を、バージョニングされ、テスト可能で機械可読なルールとして表現することと定義します。リクエストはPEPに到達し、PEPはサブジェクトを認証し、サブジェクト、アクション、リソース、およびコンテキストを正規化してから、ポリシーバージョンとともにPDPに送信します。PDPは決定を計算し、許可、拒否、理由、義務、および決定IDを返します。PDPではなくPEPが、リクエストをブロックするか、ビジネスアクションを継続するか、あるいは人間の承認を開始します。
私はポリシーと入力データをバージョン管理し、Gitでポリシーをレビューし、再現可能なスナップショットを用いてテストします。ランタイムの動作はデフォルト拒否とし、キャッシュはポリシーと認可データのバージョンにバインドします。取り消しが発生した場合は、高リスクな決定を迅速に無効化します。PDPの停止が自動的に許可になってはならないため、アクションのリスクに応じて障害モードを選択します。最後に、監査とロールバックのためにマスキングされた決定ログを書き込みます。これにより、各エントリポイントが強制の責任を維持したまま、同じルールセットでAPI、CI、およびインフラストラクチャのエントリポイントに対応できます。
よくある間違い
- 間違い → PDPにデータベースの更新やインフラのデプロイを実行させる → 失敗する理由 → 決定と副作用が切り離せなくなり、再試行や監査が困難になる → 修正策 → PDPからは決定と義務のみを返し、PEPまたはビジネスサービスに影響を実行させる。
- 間違い → PDPがタイムアウトした際にデフォルトで許可にする → 失敗する理由 → ネットワーク障害が権限のバイパスにつながる → 修正策 → アクションのリスクに応じて拒否、承認、または事前に承認された短いパスを選択する。
- 間違い → 許可または拒否のみをログに記録する → 失敗する理由 → どのルールと入力がその結果を生成したのか誰も説明できなくなる → 修正策 → ポリシーバージョン、理由、決定ID、およびマスキングされた入力要約を記録する。
- 間違い → ポリシーキャッシュを永続的な真実として扱う → 失敗する理由 → 権限の取り消しやテナント変更を迅速に反映できなくなる → 修正策 → バージョンと有効期限をバインドし、重大なイベント時に無効化する。
フォローアップの質問と回答
集中型PDPが利用できない場合、すべての読み取りを失敗させる必要がありますか？
まずアクションを分類します。権限の変更、データ転送、およびテナント間読み取りはデフォルト拒否とする必要があります。低リスクな読み取りは、短時間有効でバージョンにバインドされたローカルの決定を使用し、復旧後にキャッシュの使用を記録・監査できます。可用性は無条件に許可するための理由にはなりません。
ポリシーとアイデンティティディレクトリが同時に更新された場合はどうなりますか？
決定にポリシーとアイデンティティデータのバージョンを含め、PEPに強制前にバージョンまたはリースを確認させます。取り消しイベントによってキャッシュは無効化されます。バージョンが確認できない場合は拒否するか再評価します。古い決定が書き戻されないよう、同時更新と遅延メッセージをテストします。
あるルールが許可し、別のルールが拒否した場合、どちらが優先されますか？
ファイルの順序に依存することなく、優先順位を明示的に定義します。明示的な拒否を優先するデフォルト拒否を使用するか、ルールを集約して理由とリスクを含む決定を生成します。異なるエントリポイントが異なる解釈をしないよう、競合にはテストとリリースゲートが必要です。
監査可能性を損なわずに緊急許可をサポートするにはどうすればよいですか？
承認者、スコープ、理由、開始時刻、および有効期限を含む一時的なポリシーまたは義務としてモデル化します。PEPがすべての使用を記録し、自動失効によってそれが取り消され、リプレイによってその例外と通常のルールが区別されます。データベースを手動で編集してポリシーバージョンをバイパスすることは絶対に避けてください。