DKE 365 のアクセスポリシー （RBAC + ABAC）

DKE 365 に対する Cockpit v2 のアクセス制御モデル — 管理のための RBAC と、復号時に適用される ABAC アクセスポリシー。

Five dimensions feed the policy engine; the effective decision follows a fixed precedence — Bypass > Block > Allow > default-deny — and is fail-closed.

適用対象:

DuoKey Cockpit v2DKE 365RBAC + ABAC

Cockpit v2 には2つの異なるアクセス制御レイヤーがあります。DKE 365 において、これらは2つの異なる問いに答えます。

レイヤー	対象	DKE における意味
RBAC（ロールと権限）	Cockpit を誰が管理できるか	DKE サービスをデプロイ / 有効化 / ローテーションできるのは誰か
ABAC アクセスポリシー	誰が、どこから、いつランタイムの暗号操作を実行できるか	DKE で保護されたコンテンツを、どの IP / 国 / 時間 / グループから復号できるか

v1 ページとの関係

既存の RBAC および ゼロトラストアクセス制御 ページは、Cockpit v1 におけるアクセス制御を説明しています。Cockpit v2 では、同じ意図が以下で説明するポリシーエンジンによって実装され、access_policy_id を介して DKE サービスにバインドされます。

ブロックされたリクエスト — ポリシーによるアクセス拒否

RBAC — 管理権限

管理操作（DKE サービスのデプロイ、有効化、ローテーション、アクセスポリシーの管理）は、ロールベースアクセス制御によって統制されます。ロールはユーザーに割り当てられ、組織単位（OU）にスコープを限定できます。管理者はすべてのチェックを通過します。

ABAC — DKE サービスにバインドされたアクセスポリシー

アクセスポリシーは、DKE の復号のたびに評価される、テナントにスコープされたレコードです。サービスの access_policy_id を設定することでサービスにバインドします（DKE 構成 を参照）。

v2 の ACL モジュールがより強力である理由

Cockpit v2 のアクセス制御レイヤーは、静的な許可リストではなく、本格的なポリシーエンジンです。単一のポリシーは5つの独立した次元（ユーザー、IP、場所、時間、グループ）を組み合わせ、それぞれがホワイトリスト / ブラックリスト / 必須（require）のセマンティクスを持ち、3種類のポリシーアクション（Allow / Block / Bypass）のいずれかのもとで、決定論的な優先順位に従って評価されます。これはフェイルクローズであり、テナントスコープ、任意でOU スコープ、アプリタイプごとのケイパビリティマトリックスによって駆動され、すべての判定はフォレンジック監査証跡に記録されます — これらすべてが復号パス上でサーバー側で適用されるため、ラベルの保護はクライアントではなくデータとともに移動します。

ポリシーの構造

ポリシーは、名前と説明、全体のアクション（Allow、Block、または Bypass）、任意の組織単位スコープ（未指定の場合はテナント全体）、有効フラグ、そして以下の5つのアクセス次元それぞれのルールブロックを持ちます。

5つのアクセス次元

各次元のエントリはマッチモード（ホワイトリスト、ブラックリスト、または必須）と、該当する場合はマッチ演算子を持ちます。DKE 365 は5つすべての次元をサポートします。

次元	マッチ対象
ユーザー	UPN / 表示名 / メールアドレス（正規表現対応）
IP	厳密なアドレス、CIDR 範囲、または開始～終了の範囲（IPv4/IPv6）
場所	ISO-3166 国コード
時間	曜日 + 1日の分単位の時間範囲
グループ	ID プロバイダーのグループメンバーシップ

適用の仕組み（復号時）

1

ポリシーがなければ制限なし

ポリシーが何もアタッチされていない（または無効化されている）場合、復号は許可されます（ポリシーなし = 制限なし）。

2

アクセスコンテキストの構築

Cockpit v2 は呼び出し元からアクセスコンテキストを構築します。ユーザー、IP、国、現在時刻、グループメンバーシップです。Azure AD JWT が正とみなされます。転送された / CDN のヘッダー（クライアント IP、国）はフォールバックおよびクロスチェックとしてのみ使用され、構成された信頼済みプロキシの CIDR リストに含まれる送信元アドレスからのものだけが信頼されます。

3

各次元の評価

各次元はポリシーエンジンによって評価されます。

4

決定の優先順位の適用

決定の優先順位: Bypass > Block > Allow > デフォルト拒否。

5

フェイルクローズ

有効なポリシーにルールが一つもない場合は拒否されます。本番環境で allow に対するセキュリティ監査レコードを書き込めない場合、復号は拒否されます。

6

決定の記録

すべての判定はフォレンジックなアクセスポリシー監査ログに記録され、アクティビティログに表示されます。

アクセスポリシー — ルール、効果、ステータス

ポリシーは Cockpit から作成・管理され、すべての適用判定はアクティビティログに表示される監査証跡として利用できます。

API リファレンス

詳細な API エンドポイントは、Developer Docs → Administration API に別途記載されています。

監査ログの詳細 — 記録された復号判定

例: DKE の復号ポリシー

典型的な DKE 復号ポリシーは、特定の ID プロバイダーグループのメンバー（例えば、ラベルの対象者）に対してのみ、自社の対象国から、業務時間内に復号を許可し、制裁対象国は一律にブロックします。グループルールを場所ルールおよび時間ルールと組み合わせ、ポリシーを DKE サービス（access_policy_id）にバインドすれば、以降のすべての復号がそのポリシーに照らして評価され、各判定が監査証跡に記録されます。

DKE + ゼロトラスト

アクセスポリシーは、Cockpit v2 上で DKE 365 がゼロトラスト復号を実現する仕組みです。認証は Azure AD トークンが担い、認可 — 誰が / どこから / いつ / どのグループか — はアクセスポリシーが担います。グループルール（ラベルの対象者のみ）を場所ルールおよび時間ルールと組み合わせることで、厳格な姿勢を実現できます。