次の方法で共有

中央承認ポリシー規則

  • [アーティクル]

中央承認ポリシー規則 (CAPR) の目的は、organizationの承認ポリシーの分離された側面のドメイン全体の定義を提供することです。 管理者は CAPR を定義して、特定の承認要件のいずれかを適用します。 CAPR では承認ポリシーの特定の必要な要件が 1 つしか定義されていないので、organizationのすべての承認ポリシー要件が 1 つのポリシー定義にコンパイルされる場合よりも簡単に定義して理解できます。

CAPR には次の属性があります。

  • 名前 – 管理者に対する CAPR を識別します。
  • 説明 – CAPR の目的と、CAPR のコンシューマーが必要とする可能性がある情報を定義します。
  • 適用性の式 – ポリシーを適用するリソースまたは状況を定義します。
  • ID – CAPR への変更の監査に使用する識別子。
  • 有効なAccess Control ポリシー – 有効な承認ポリシーを定義する DACL を含む Windows セキュリティ記述子。
  • 例外式 – ポリシーをオーバーライドし、式の評価に従ってプリンシパルへのアクセスを許可する手段を提供する 1 つ以上の式。
  • ステージング ポリシー – 有効なポリシーに対してテストされるが適用されない、提案された承認ポリシー (アクセス制御エントリの一覧) を定義する DACL を含むオプションの Windows セキュリティ記述子。 有効なポリシーとステージング ポリシーの結果に違いがある場合、その違いは監査イベント ログに記録されます。
    • ステージングはシステム パフォーマンスに予測できない影響を及ぼす可能性があるため、グループ ポリシー管理者は、ステージングが有効になる特定のマシンを選択できる必要があります。 これにより、ステージングがマシンのサブセットで行われている間に、OU 内のほとんどのマシンに既存のポリシーを配置できます。
    • P2 – 特定のマシンのローカル管理者は、そのマシンでのステージングによってパフォーマンスの低下が多すぎる場合にステージングを無効にできる必要があります。
  • CAP へのバックリンク – この CAPR を参照している可能性があるすべての CAP へのバックリンクの一覧。

アクセスチェック中に、CAPR は適用性の式に基づいて適用性について評価されます。 CAPR が該当する場合は、特定されたリソースへの要求されたアクセスを要求ユーザーに提供するかどうかが評価されます。 その後、CAPE 評価の結果は AND によって論理的に結合され、リソースに対する DACL の結果と、リソースに対して有効なその他の該当する CAPR が結合されます。

CAPR の例:

[HBI-POLICY]
APPLIES-TO="(@resource.confidentiality == HBI"
SD ="D:(A;;FA;;;AU;(@memberOf("Smartcard Logon")))"
StagingSD = "D:(A;;FA;;;AU;(@memberOf("Smartcard Logon") AND memberOfAny(Resource.ProjectGroups)))"
description="Control access to sensitive information"
 
[RETENTION-POLICY]
Applies-To="@resource.retention == true"
SD ="D:(A;;;FA;;BA)(A;;FR;;;WD)"
description="If the document is marked for retention, then it is read-only for everyone however Local Admins have 
full control to them to put them out of retention when the time comes"
 
[TEST-FINANCE-POLICY]
Applies-To="@resource.label == 'finance'"
SD="D:(A;;FA;;;AU;(member_of(FinanceGroup))"
description="Department: Only employees of the finance department should be able to read documents labeled as finance"

CAPEs の ACE を拒否する

Windows 8では、CAPR では拒否 ACE はサポートされません。 CAPR オーサリング UX では、拒否 ACE の作成は許可されません。 さらに、LSA が Active Directory から CAP を取得すると、LSA は CAPR に拒否 ACE がないことを確認します。 CAPR で拒否 ACE が見つかった場合、CAP は無効として扱われ、レジストリまたは SRM にはコピーされません。

Note

アクセス チェックでは、拒否 ACE が存在しないことを強制しません。 CAPR の DENY ACE が適用されます。 作成ツールを使用すると、このようなことが起こらないようにすることが期待されます。

 

CAPE 定義

CAPR は、Active Directory 管理センター (ADAC) で提供される新しい UX を使用して作成されます。ADAC では、CAPR を作成するための新しいタスク オプションが提供されます。 このタスクを選択すると、ADAC はユーザーに CAPR 名と説明を求めるダイアログを表示します。 これらが指定されると、残りの CAPR 要素のいずれかを定義するコントロールが有効になります。 残りの CAPR 要素ごとに、UX は ACL-UI を呼び出して式や ACL の定義を許可します。

AccessCheck

動的Access Control (DAC) シナリオ