アクセスポリシー （RBAC + ABAC）
Cockpit v2 の2つのアクセス制御レイヤー — ロールベースの管理と、鍵、Oracle TDE アプリ、DKE サービスを保護する ABAC アクセスポリシー。
Cockpit v2 には2つの異なるアクセス制御レイヤーがあります。両者を区別しておくことが重要です。
| レイヤー | 対象 | 適用範囲 |
|---|---|---|
| RBAC（ロールと権限） | Cockpit を誰が管理できるか | 管理 API（例: Oracle TDE アプリのデプロイ、DKE 鍵のローテーション） |
| ABAC アクセスポリシー | 誰が、どこから、いつランタイムの暗号操作を実行できるか | 鍵、アプリ（Oracle TDE を含む）、DKE サービスにバインドされ、復号 / 鍵アクセス時に評価される |
アクセスポリシーを作成し、それが適用される様子を示す簡単なデモ動画をここに追加予定です。
RBAC — 管理権限
管理操作（鍵、アプリ、DKE サービス、アクセスポリシーの管理）は、ロールベースアクセス制御によって統制されます。ロールはユーザーに割り当てられ、各ロールは一連の権限を付与し、組織単位（OU）にスコープを限定できます。管理者はすべてのチェックを通過します。
ABAC — アクセスポリシー
アクセスポリシーは、保護された鍵が使用されるたびに（例えば DKE の復号や Oracle TDE のマスター鍵操作の際に）評価される、テナントにスコープされたレコードです。これはレガシーの Cockpit のアクセスポリシーモデルを踏襲し、ポリシーエンジン上で再実装したものです。
ポリシーの構造
ポリシーは、名前と説明、全体のアクション（Allow、Block、または Bypass）、対象のアプリタイプ（例えば DKE 365、Oracle TDE、または汎用アプリ）、任意の組織単位スコープ（未指定の場合はテナント全体）、有効フラグ、そして以下の5つのアクセス次元それぞれのルールブロックを持ちます。
5つのアクセス次元
各次元はエントリのリストであり、各エントリはマッチモード（ホワイトリスト、ブラックリスト、または必須）と、該当する場合はマッチ演算子を持ちます。
| 次元 | マッチ対象 |
|---|---|
| ユーザー | UPN / 表示名 / メールアドレス（正規表現対応） |
| IP | 厳密なアドレス、CIDR 範囲、または開始～終了の範囲（IPv4/IPv6） |
| 場所 | ISO-3166 国コード |
| 時間 | 曜日 + 1日の分単位の時間範囲 |
| グループ | ID プロバイダーのグループメンバーシップ |
すべてのアプリタイプがすべての次元をサポートするわけではありません。Cockpit v2 は、各アプリタイプがどの5カテゴリを尊重できるかを宣言するケイパビリティマトリックスを公開しており、UI は該当しないルールタブをグレーアウトします。DKE 365 は5つすべてをサポートしますが、いくつかの汎用アプリタイプは IP / 場所 / 時間のみをサポートします。
ポリシーのバインド
| 対象 | バインド方法 |
|---|---|
| DKE サービス | サービスの access_policy_id — すべての復号時に適用 |
| 汎用アプリ（Oracle TDE を含む） | アプリの access_policy_id — アプリの暗号操作時に適用 |
| AWS XKS | エンドポイントごとの access_policy_id。XKS の復号パスで適用される |
適用の仕組み
バインドされたポリシーの参照
保護された操作が実行されると、Cockpit はバインドされたポリシーを参照します。何もアタッチされていない場合、またはポリシーが無効化されている場合、操作は許可されます（ポリシーなし = 制限なし）。
アクセスコンテキストの構築
Cockpit は、呼び出し元の ID とトランスポートからアクセスコンテキストを構築します。ユーザー（JWT から）、IP、国、現在時刻、グループメンバーシップです。JWT が正とみなされます。転送された / CDN のヘッダー（クライアント IP、国）はフォールバックおよびクロスチェックとしてのみ使用され、構成された信頼済みプロキシの CIDR リストに含まれる送信元アドレスからのものだけが信頼されます。
各次元の評価
各次元はポリシーエンジンによって評価されます。
決定の優先順位の適用
決定の優先順位: Bypass > Block > Allow > デフォルト拒否。
フェイルクローズ
有効なポリシーにルールが一つもない場合は拒否されます（暗黙のうちに許可されることはありません）。本番環境で allow の判定に対するセキュリティ監査レコードを書き込めない場合、操作は拒否されます。
決定の記録
すべての判定はフォレンジックなアクセスポリシー監査ログに記録され、アクティビティログに表示されます。
ポリシーの管理
ポリシーは Cockpit から作成・管理され、Cockpit はアプリタイプごとのケイパビリティマトリックス、グループルールで利用可能なグループ、そして適用の監査証跡も表示します。
ルールの例
アクセスポリシーは、単純なホワイトリスト / ブラックリスト / 必須のセマンティクスで5つの次元を組み合わせます。典型的なルールには次のようなものがあります。制裁対象国をブロックしつつ自社の対象国は許可する（場所）、特定のユーザーのみを許可する、またはあるパターンを除外する（ユーザー）、IP 範囲と業務時間に限定する（IP + 時間）、特定の ID プロバイダーグループへの所属を必須とする、など。
Oracle TDE アプリへのアクセスポリシーの適用
ポリシーを作成する
Oracle TDE アプリタイプを対象とし、必要なルールを設定したアクセスポリシーを作成します — 例えば、データベースのサブネットからのみ（IP 次元）、業務時間中に（時間次元）マスター鍵操作を許可します。
アプリにバインドする
アプリの access_policy_id を設定して、Oracle TDE アプリにバインドします。
適用と監査
そのアプリ上のすべてのマスター鍵管理操作はポリシーに照らして評価され、各判定はアクセスポリシー監査証跡に記録されます。
典型的な Oracle TDE ポリシーは、IP ルール（データベースホスト / サブネットのみ）と時間ルール（鍵ローテーションのためのメンテナンスウィンドウ）を組み合わせ、認証は access_guid ベアラートークンに、認可はポリシーに委ねます。