アクセスポリシー (RBAC + ABAC)
DuoKey Cockpit の二つのアクセス制御レイヤー — ロールベースの管理と、すべてのランタイム暗号操作を統制する属性ベース（ABAC）のアクセスポリシー。
Cockpit には二つの異なるアクセス制御レイヤーがあります。それぞれ異なる問いに答え、異なる箇所で適用されるため、両者を明確に分けておくことが重要です。
| レイヤー | 統制対象 | 適用箇所 |
|---|---|---|
| RBAC（ロールと権限） | 誰が Cockpit を管理できるか | 管理 API — アプリのデプロイ、鍵のローテーション、ポリシーの編集 |
| ABAC アクセスポリシー | 誰が、どこから、いつランタイム暗号操作を実行できるか | DKE サービス、アプリ、XKS エンドポイントに紐付けられ、復号／鍵アクセス時に評価される |
アクセスポリシーの作成とその適用を確認する短いウォークスルーは、後日ここに追加予定です。
RBAC — 管理権限
管理アクションは、きめ細かく階層化されたロールベースの権限によって保護されており、誰が各アクションを実行できるかを統制します。ユーザーは、該当する権限またはそれを暗黙的に含む親権限を保持していればそのアクションを許可されます。管理者はすべてのチェックを通過します。
権限
階層的にネストされたきめ細かい権限 — 親の権限は配下のすべてを暗黙的に付与します。
ロール
各ロールは権限の集合をまとめてユーザーに割り当てられます。ロールは組織単位（OU）にスコープでき、その場合付与はそのブランチ内のみに適用されます。
OU スコープ
OU スコープされたロール割り当ては、権限をその組織単位のリソースに限定し、委任管理をサポートします。
ロール、その権限セット、組織単位スコープは、Cockpit の管理コンソールから作成・管理します。
ABAC — アクセスポリシー
アクセスポリシーは、保護対象の鍵が使用されるたびに評価されるテナントスコープのレコードです — 例えば DKE の復号、汎用アプリの暗号操作、AWS XKS の復号などです。ポリシーはプラットフォームのポリシーエンジンによって適用され、呼び出し元を認証したベアラートークンの上に位置する認可レイヤーです。
ポリシーの構造
| 属性 | 意味 |
|---|---|
| 名前 | 人が読めるポリシー名 |
| 説明 | 自由記述の説明 |
| アクション | ポリシー全体のアクション — Allow、Block、または Bypass |
| アプリタイプ | 対象アプリタイプ — 例：DKE365、Oracle TDE、AWS XKS |
| OU スコープ | 任意の組織単位スコープ（未設定の場合はテナント全体） |
| 有効 | ポリシーが有効かどうか |
| ルールとグループ | 4 種類の型付きルールブロック — ユーザー、デバイス（IP）、場所、時間 — に加えてアイデンティティプロバイダーのグループ |
5 つのアクセスディメンション
各ディメンションはエントリのリストです。各エントリはマッチモード（Include = ホワイトリスト、Exclude = ブラックリスト、Require）と、該当する場合はマッチ演算子（any-of、contains）を持ちます。
| ディメンション | マッチ対象 |
|---|---|
| ユーザー | UPN / 表示名 / メールアドレス（正規表現対応） |
| IP | 正確なアドレス、CIDR 範囲、または開始-終了範囲（IPv4/IPv6） |
| 場所 | ISO-3166 国コード |
| 時間 | 曜日 + 分単位の時間範囲 |
| グループ | アイデンティティプロバイダーのグループメンバーシップ |
すべてのアプリタイプがすべてのディメンションをサポートしているわけではありません。Cockpit は、各アプリタイプが 5 つのカテゴリのうちどれをサポートするかを宣言するケーパビリティマトリクスを公開しており、UI は該当しないルールタブをグレーアウトします。DKE365 は 5 つのディメンションすべてをサポートしますが、いくつかの汎用アプリタイプは IP／場所／時間のみをサポートします。
ポリシーのバインド
ポリシーはリソースに紐付けられるまで効果を持ちません。バインドはポリシーを対象に結び付けます。
| 対象 | バインド方法 |
|---|---|
| DKE サービス | サービスに紐付けられ、すべての復号時に適用 |
| 汎用アプリ（Oracle TDE を含む） | アプリに紐付けられ、そのアプリの暗号操作時に適用 |
| AWS XKS エンドポイント | エンドポイント単位で紐付けられ、XKS 復号パスで適用 |
適用の仕組み
紐付けられたポリシーを検索
保護された操作が実行されると、Cockpit はそのリソースに紐付けられたポリシーを検索します。何も紐付けられていない、またはポリシーが無効な場合、操作は許可されます — ポリシーがないことはリソースが制限されていないことを意味します。
アクセスコンテキストを構築
Cockpit は呼び出し元のアイデンティティとトランスポートからアクセスコンテキストを構築します：ユーザー（JWT から）、IP、国、現在時刻、グループメンバーシップ。JWT が正となります。 転送元／CDN ヘッダー（クライアント IP、国）はフォールバックおよびクロスチェックとしてのみ使用され、かつ設定された信頼済みプロキシの CIDR リストに含まれる送信元アドレスから届いた場合のみ使用されます。
各ディメンションを評価
サポートされている各ディメンションが、ポリシーエンジンによりコンテキストと照合されて評価されます。
判定の優先順位を適用
判定は優先順位で解決されます：Bypass > Block > Allow > デフォルト拒否。
フェイルクローズ
ルールを持たない有効化されたポリシーは拒否します — 黙って許可することはありません。本番環境で allow 判定に対してセキュリティ監査レコードを書き込めない場合、操作は拒否されます。
判定を記録
すべての判定はフォレンジック用のアクセスポリシー監査ログに書き込まれ、アクティビティログに表示されます。
デフォルトは拒否です。有効化された空のポリシーを紐付けると、少なくとも一つの Include/Allow ルールが呼び出し元にマッチするまで、そのリソースへのすべてのアクセスがブロックされます。本番リソースに紐付ける前に、ポリシーをエンドツーエンドで検証してください。
アクセスポリシー API
アクセスポリシーは、Cockpit コンソールとその管理 API を通じて作成、一覧表示、更新、リソースへのバインド、監査が行われます。同じインターフェースが、アプリタイプごとのケーパビリティマトリクスと、グループルールで利用可能なグループも公開します。
ルールの例
5 つのディメンションを組み合わせることで、次のようなルールを表現できます。
- 特定の国をブロックする — 特定の ISO-3166 国コードを発信元とする操作を拒否する。
- 特定のユーザーのみを許可する — 名前付きユーザー（メールまたは UPN）を許可し、それ以外を除外する。
- IP と時間で制限する — 既知のサブネットのみを許可し、決められた日次の時間帯のみ（例：月曜 08:00 から 18:00）許可する。
- アイデンティティプロバイダーグループで制限する — 特定の IdP グループへの所属を要求する。
組み合わせて使う
ポリシーを作成する
目的のルールを付けて、正しいアプリタイプ向けにポリシーを作成します — 例えば、既知のサブネットからの操作のみ（IP ディメンション）、かつ営業時間中のみ（時間ディメンション）許可する。
リソースに紐付ける
対象 — DKE サービス、汎用アプリ、または AWS XKS エンドポイント — にアタッチします。
適用と監査
そのリソース上のすべての暗号操作はポリシーと照合して評価され、各判定はアクセスポリシー監査証跡に記録されます。
典型的な堅牢化されたポリシーは、IP ルール（想定されるクライアントホスト／サブネットのみ）と時間 ルール（許可された運用または保守時間帯）を組み合わせ、ベアラートークンを認証、ポリシーを認可として位置付けます。呼び出し元のアイデンティティが判明している場合は、その上にユーザーまたはグループルールを重ねます。