動的なアクセス制御：集中化されたアクセスルールとポリシーの操作

動的アクセス制御などの技術は長い間私の記事で検討されてきましたが、正直なところ、検討したいすべてのトピックの半分にも達していません。 しかし、それでも、この記事を読むと、この技術を習得し、動的アクセス制御の基盤全体に付随する次のブリックについて学ぶことができます。 比Fig的に言えば、この動的アクセス制御のブリックは、集中アクセスそのものに起因するものです。 中央アクセスは、本質的に、対応する許可ポリシーの中央メカニズムを実装することを可能にします。これにより、会社の権利の「スマート」な配布を自動化できます。 確かに、クレームを適切に生成し、ビジネスに合わせたすべてのリソースプロパティオブジェクトを計画および作成し、必要なリソースプロパティリストを構成し、美しく正確な分類を実装しますが、一元化されたルールまたはアクセスポリシーを操作するときに、すべての作業を意図しない些細な間違いを犯しますtartararaに飛ぶことができます。

このため、独自の集中型アクセスルールとポリシーの作成に十分な注意を払い、動的制御テクノロジーの実装後に発生する可能性のあるすべての状況を完全に予測するために必要な時間を費やすことが非常に重要です。実稼働環境へのアクセス。 ここでは、最初に実験室ですべてのテストを実行し、可能であればパイロットグループで実行することが非常に重要です。そうしないと、結果が最も予測不能になる可能性があります。 原則として、このシリーズの最後の記事の1つで動的アクセス制御の計画に戻るため、このトピックのこの段階について詳しく説明するのは無意味です。

今日は、集中型アクセスルール自体の指定や集中型アクセスポリシーなどの問題を検討します。 このようなルールとポリシーを作成、編集、削除する方法を学習します。 さらに、この記事では、集中アクセスポリシーの配布と適用について学習します。 このサイクルの4番目の記事の場合のように、この記事には多くの資料があるため、最初のセクションに進みます。

集中アクセスルール

集中型アクセスルールの作成を開始する前に、それが実際に何であり、そのようなオブジェクトが何のためであるかを決定する必要があります。 定義上、 セントラルアクセスルールは、ユーザーグループ、ユーザーとデバイスの要件、およびリソースプロパティに影響する1つ以上の条件を含めることができる承認ルールの表現です。 生成された一元化されたアクセスルールによって、リソースの特定の領域へのアクセスが誰に許可されるかが決まります。 動的アクセス制御のテクノロジーのすべてのオブジェクトと同様に、このようなルールには一意の名前と、もちろんオプションで明確な説明を含める必要があります。 さらに、すでに指摘したように、これらのルールには、SDDL言語（セキュリティ記述子定義言語）の条件式である特定の式も含まれています。

また、いくつかの集中型アクセスルールを組み合わせて、集中型アクセスポリシーを作成することもできます。 一般に、ドメインに対して1つ以上の集中型アクセスルールが定義されている場合、ファイルリソース管理者は便宜上、特定のルールを特定のリソースおよびビジネス要件にマッピングできます。

原則として、集中型アクセスルールに関する理論的な部分に関しては、本質的には何も言うことはないので、より興味深い部分である実用的な部分に移りましょう。 次に、集中アクセスルールの作成、編集、削除について説明します。 私たちは自然に始まります

中央のアクセスルールを作成する

まず第一に、デフォルトではサーバー上に集中ルールは作成されないことに注意する必要があります。 したがって、集中化されたアクセスルールをさらに使用し、さらに集中化されたアクセスポリシーを使用するには、それらを自分で作成する必要があります。 独自の集中型アクセスルールを作成すること自体は難しくありません。 このプロセスでは、Active Directoryサーバーの全体管理またはWindows PowerShellなどのツールを使用してこのタスクを実行できるため、このシリーズの以前のすべての記事で説明したすべてのオブジェクトを作成することを思い出させることができます。 もちろん、Active Directoryサーバーの全体管理センターのコンソールから開始します。 全体のプロセスは次のとおりです。

1. ドメインコントローラーで、 「Active Directory管理センター」コンソールを開く必要があります。ここで、移行ノード領域で「動的アクセス制御」ノードを選択し、 「中央アクセスルール」 （ 動的アクセス制御>中央アクセスルール ）を選択する必要があります。 このコンソールの初期画面の動的アクセス制御タイルでオプション番号3- 「集中アクセスルールの作成」を選択して、このノードに移動することもできます 。
2. この手順の2番目のステップでは、次の図に示すように、詳細ペインまたはタスクペインのコンテキストメニューから[ 作成 ]オプションまたはセントラルアクセスルール （ 新規>セントラルアクセスルール ）を選択する必要があります。 ：
   
   
   
   
   
   図 1.新しい中央アクセスルールを作成する
3. 図番号2に示すように、表示されるダイアログボックスで、3つの異なるグループで必要なコントロール要素の値を決定する必要があります。新しいルールを作成するには、全体として、上位グループの最初のコントロールのみを入力するだけで十分です。 しかし、まず最初に：
   
   
   • グループ「一般」 （ 一般 ）。 このグループには、ダイナミックアクセスコントロールテクノロジーの作成されたオブジェクトのほとんどについて、ほぼ標準のパラメーターセットがあります。 このグループでは、次の3つの主要なパラメーターを定義できます。
     
     
     • お名前 ここではすべてが明確です。そのような各ルールを識別するには、必ずその名前を示す必要があります。 名前は一意で、英数字形式で示されている必要があります。このパラメータを入力することは、アクセスルールを作成するための前提条件と見なされます。 ちなみに、中央アクセスルールを計画するときは、ルール名の最大文字数が64文字であることに注意してください。 つまり、この制限を超えないようにする必要があります。 たとえば、この例では、ルールの名前を「 アフィリエイトのリソースを中央マーケティング担当者に読み取る権限 」と呼びます。 オフィス 」;
     • 説明 オプションのテキストフィールドですが、説明があれば、数十またはそれ以上の集中アクセスルールが生成される場合に役立ちます。 名前と同様に、このフィールドの文字数も制限されています。 ルールの説明を最大1024文字に収める必要があります。そうしないと、そのようなルールを作成できません。 説明では、「 会社の支店のターゲットリソースについて、本社のマーケティングリソースへの読み取りアクセスを許可する 」と記述しています。
     • 誤った削除に対する保護（誤った削除から保護する） 。 ドメイン管理者とエンタープライズ管理者のセキュリティグループの管理者のみがそのようなルールを作成、変更、または削除できることを考慮しても、ルール作成者以外の全員が現在のルールを削除できないようにするActive Directoryサーバーの全体管理オブジェクトの標準チェックボックス。
   • ターゲットリソースグループ このダイアログボックスの2番目のグループは、集中型アクセスルールのいわゆるスコープを決定するために使用されます。 このようなスコープは、以前に作成されたリソースプロパティオブジェクトをいわゆる条件式として定義することで作成されます。 したがって、作成するルールについて、ほとんどすべての可能な範囲を決定できます。 集中アクセスルールを同じディスク領域の小さなグループにのみ適用することがしばしば受け入れられているという事実にもかかわらず、デフォルト値のままにしておくことができるため、ルールはすべての可能なターゲットリソースに適用されます。 標準のANDまたはOR演算子を使用して、このような条件式をグループ化できます。 さらに、より複雑なシナリオを作成するために、複数の条件式を同時にグループ化して、そのような結果の範囲を組み合わせることができます。 つまり、ルールのデフォルトスコープを変更する場合は、[ 編集 ]ボタンをクリックします。
   • 権限グループ 。 パラメーターのこの最後のグループのおかげで、次の2つの異なる機能を使用して、作成するルールのアクセス許可を事前に定義できます。
     
     
     • 次の権限を提案された権限として使用します 。 公式の定義によれば、このパラメーターを使用すると、システムの動作に影響を与えることなく、ターゲットオブジェクトへのアクセス要求の結果を監査できます。 つまり、このオプションを選択することで、対応するリストの許可エントリを、作成した集中型アクセスルールの提案された許可エントリのリストに追加できます。 提案されたアクセス許可のリストを監査ファイルシステムと組み合わせて、現在のアクセス許可のリストにあるアクセス許可を変更せずに、ユーザーがリソースに対して受ける効果的なアクセスをシミュレートできます。 提案されたアクセス許可は、イベントログで確認できる特別な監査イベントを生成します。イベントログでは、ユーザーが行ったすべてのアクセス試行をより詳細に確認できます。
     • 現在の権限として次の権限を使用します 。 このオプションを選択することにより、このようなルールが表示される集中アクセスポリシーの公開後にターゲットリソースへのアクセスを提供できます。 つまり、現在のアクセス許可のリストは、ファイルサーバーに中央アクセスルールを展開するときにWindowsオペレーティングシステムが読み取る追加のアクセス許可を表します。 既に述べたように、集中型アクセスルールは既存のセキュリティ設定に置き換わるものではありません。承認を決定する際、Windowsは集中型アクセスルールのアクセス許可、NTFSアクセス許可の現在のリスト、および共有リソースのアクセス許可のリストを必ず評価します。
     
     
     この場合、2番目のオプションで停止し、多くのセキュリティオプションに既に慣れているダイアログの[ 編集 ]ボタンをクリックした後、 「読み取りと実行」権限が割り当てられる「 ロサンゼルスマーケター 」などの必要なグループを追加します、ならびに通常の「読書」 。
     
     
     
     
     
     図 2.新しい中央アクセスルールを作成するためのダイアログボックス
4. すべての設定を定義したら、アクセスルールを安全に保存できます。

ご覧のとおり、複雑なことは何もありません。 ここで、おそらく、少し異なる方法を使用して、またはより正確にはWindows PowerShellなどの強力な管理ツールを使用して、一元化されたアクセスルールを作成することを検討します。 このようなポリシーを管理するPowerShellコマンドレットを完全に要約すると、このシリーズの前の記事で説明したリソースプロパティリストを管理する場合と同様に、3つの異なるコマンドレット、つまりNew-ADCentralAccessRuleを区別できます。新しい一元化されたアクセスポリシーSet-ADCentralAccessRuleを作成できます。これにより、既存のルールを編集できます。また、 Remove-ADCentralAccessRuleを作成できます。これは、後者の削除をそれぞれ担当します。 PowerShellを使用した既存のアクセスルールの編集と削除は非常に簡単であるため、これらの操作は現在の記事では単純に省略されます。 そして、新しい集中アクセスポリシーの作成を開始します。

たとえば、 「 マーケティングユニットに分類されたすべてのリソースへのマーケティング担当者のアクセスを許可するポリシー 」という説明とともに、「 ロサンゼルスマーケティング担当者のマーケティングリソースへのアクセス 」というポリシーを作成する必要があります。分類。 この場合、PowerShellコマンドは次のようになります。



New-ADCentralAccessRule -CurrentAcl:"O:SYG:SYD:AR(A;;FA;;;S-1-5-21-3046794806-2660339953-3139999740-1107)" -description:", , Marketing" -Name:" - " -ProposedAcl:$null -ProtectedFromAccidentalDeletion:$true -ResourceCondition:"(@RESOURCE.Department_MS == `"Marketing`")" -Server:"DC.biopharmaceutic.local"







ここで：

• Nameパラメーターは、作成されたオブジェクトの名前を担当します。 この設定の目的と制限は、サーバーの全体管理コンソールの機能と完全に一致しています。
• Descriptionパラメーターは、作成しているルールの説明を示すことを目的としています。
• CurrentACLパラメーターを使用すると、作成しているアクセスルールのアクセス許可の現在のリストを定義できます 。 このパラメーターの値の最も難しい部分は、ここですべてのアクセス許可をSDDLで記述された短い形式で指定する必要があることです。 このオプションを使用する場合、最も重要なことは、 ACE StringsおよびSID Stringsドキュメントを注意深く調べることです。 一般に、このパラメーターに関連するエラーは決定的なものになる可能性があるため、このパラメーターの指示の正確さを常に再確認してください。
• ProposedAclパラメーターは、提案されたアクセス許可を定義します。これは、前のパラメーターと同じ形式で指定され、この記事の次のサブセクションで詳しく説明します。
• ProtectedFromAccidentalDeletionパラメーターは、集中アクセスルールを作成するためのダイアログボックスの一般的なグループの標準パラメーターであり、誤って削除されないように保護します。
• ResourceConditionパラメーターは、値がこのルールの条件であるパラメーターです。 この例（ @ RESOURCE.Department_MS == `` Marketing` " ）では、すべてが声に出して発音されるのと同じ方法で指定されます。つまり、部門（Department_MS）のリソース（@RESOURCE）は、Marketingの値（` `Marketing` "）。 このような条件を正しく構成する方法を学ぶには多くの練習が必要です。また、必要に応じて、ルールを作成した後、定期的にWindows PowerShellログを手動で調べることができます。
• Serverパラメーターは、単純にルールを作成するサーバーの名前です。 この特定のケースでは、サーバー名はドメインdiopharmaceutic.localのDCであるため、このパラメーターに対応する値を取得します。

このコマンドの出力は非常に単純です。エラーが表示されない場合は、すべてが正常であり、集中アクセスルールが作成されています。 このコマンドの出力例を以下に示します。





図 3. Windows PowerShellを使用して集中型アクセスルールを作成する

既存の中央アクセスルールを変更する

新しいオブジェクトを作成した後、それを変更することが必要になる状況は常にあります。 作成中に間違いが発生したか、必要な解像度を追加するのを忘れたか、指定された条件が十分に包括的ではなかったなど、多くのオプションがあります。 しかし、最も重要なことは、必要な情報が不足している場合、作成されたオブジェクトを変更する必要があるということです。 もちろん、このような状況には通常、集中型アクセスルールが適用され、既存のオブジェクトを変更するために超自然的なアクションは必要ありません。 大まかに言えば、ルール自体が作成された同じノードに移動し（ ダイナミックアクセス制御>セントラルアクセスルール ）、詳細ペインのリストでそのようなルールを見つけてから、[ プロパティ” （ プロパティ ）。

作成したルールを変更するために表示されるダイアログボックスでは、次の3つの点を除き、そのようなルールを作成するときとほぼ同じ機会が提供されます。

• まず、ルールの名前を変更することはできません。 あなたにはそのような機会はありません。それだけです。
• 第二に、現在のアクセス許可の編集に加えて、 提案されたアクセス許可を構成する機会も与えられます。これは、Windows PowerShellを使用した集中アクセスルールの作成中に渡すことで言及しました。 これらの提案された許可は何ですか？ まず、 現在のアクセス許可と提案されたアクセス許可の違いを理解する必要があります。 現在の権限のリストは、中央アクセスルールのリソースへのアクセスを定義するエントリです。 これらのアクセス許可は、集中アクセスポリシーを使用して集中アクセスルールを展開した後に有効になります。これについては、この記事の後半で学習します。 次に、 提案されたアクセス許可は、プロパティを表示するか、既存のアクセスルールを変更する場合にのみ検出できます。 提案されたアクセス許可のリストでは、提案されたアクセス許可のリストを使用して、現在のセキュリティ参加者間のアクセス許可のすべての可能な変更を表示できます。 しかし、それにもかかわらず、提案されたアクセス許可のこのようなリストは、ユーザーの現在のアクセス許可にまったく影響を与えないという事実に注意を払う価値があります。 また、このような中間のアクセス許可を表示および分析できるようにするには、 「 アクセス許可のステージング構成を有効にする 」チェックボックスをアクティブにする必要があることに注意してください。 さらに、提案された権限を使用する場合は、次の機能に注意してください。
  
  
  • パラメータ「変更」（編集） 。 明らかなように、このボタンをクリックすると、追加のセキュリティ設定用のダイアログボックスが表示され、提案された権限のグループに対して権限を変更または追加できます。
  • 提案されたパラメータの適用 。 このオプションを使用すると、現在の権限を、提案された権限のグループで定義した権限に置き換えることができます。
  • 現在のオプションからコピー 。 同様に、このパラメーターを使用すると、反対のアクションを実行できます。つまり、このアクションは、提案されたアクセス許可のリストのアクセス許可を、現在のアクセス許可のリストのアクセス許可に単純に置き換えます。
• 第三に、最初に一度設定されたアクセス許可を変更した後、変更された中央アクセスルールのプロパティダイアログボックスを開くたびに、別のグループの機能（ 以前のアクセス許可グループ）が使用可能になります。 ルールを変更するとどうなりますか？ 一元化されたアクセスルールのアクセス許可を変更した後、オペレーティングシステムは初期の現在のアクセス許可を以前のアクセス許可グループのリストにコピーし、提案されたアクセス許可から更新された現在のアクセス許可のリストと以前のアクセス許可のリストを保存します。 覚えておくべき主なことは、このリストには以前のアクセス許可のレコードのコピーが1つだけ含まれることです。 つまり、Active Directoryサーバーの全体管理の機能は、現在のアクセス許可リストのアクセス許可のすべての変更の完全な履歴をサポートしていません。

次の図で、変更された集中型アクセスルールのプロパティダイアログボックスを確認できます。





図 4.変更された集中型アクセスルールの[プロパティ]ダイアログボックス

既存の中央アクセスルールを削除する

既存の集中型アクセスルールを削除する操作は、実行できる最も単純な操作である可能性が高くなります。 これを行うには、Active Directory管理センターの[ ダイナミックアクセス制御]> [中央アクセスルール]ノードで、不要なアクセスルールを選択し、コンテキストメニューまたはタスクバーから[ 削除]コマンドを選択します。 表示される確認確認ダイアログボックスで、 「はい」ボタンをクリックする必要があります。これは、選択を決定したことを意味します。 それだけです、ルールは即座に削除されます。

権限がないことを示すダイアログボックスが表示された場合は、削除するルールのプロパティダイアログボックスを開き、[ 誤って削除しないように保護する ]オプションをオフにします。 その後、手順を繰り返してルールを削除します。

中央アクセスポリシーの管理

すでに集中型アクセスルールを扱っているので、集中型アクセスポリシーに特化したこの記事の次のトピックに移る価値があります。 集中アクセスポリシーは、Windows Server 2012サーバーオペレーティングシステムに最初に登場した承認ポリシーであり、条件式が含まれています。 原則として、そのようなポリシーは、集中アクセスルールのオブジェクトのコレクションです。 Active Directoryサーバーの全体管理センターを使用してこれらのポリシーを作成し、その後グループポリシー機能を使用してそれらを配布できます。 たとえば、組織のビジネス要件に、ファイルの所有者と、個人情報の表示を許可されている一部の部門（人事部門など）のメンバーによるファイルの個人情報へのアクセスの制限が含まれる場合、これは個人情報ファイルに適用される一般的な組織ポリシーです。配置された組織ファイルサーバー。 前述したように、集中型アクセスポリシーには1つ以上の集中型アクセスルールを含めることができ、集中型アクセスルールはいくつかの異なる集中型アクセスポリシーのメンバーになることができます。

ここで、前述したように、集中化されたアクセスポリシーが専用ファイルサーバーにあるファイルとフォルダーへのアクセスのセキュリティを高めるという事実に注意を払う必要がありますが 、ローカルアクセスポリシーや選択的管理テーブルを置き換えるものではありません同じファイルまたはフォルダーに既に適用されているアクセス（DACL）。 言い換えれば、彼らは調和してそして一緒に働く。 最も単純な例を考えてみましょう。集中アクセスポリシーでは、ユーザーはファイルサーバーにある特定のドキュメントを使用できることが明確に示されていますが、DACLはファイルへのアクセスが拒否されていると判断します。 したがって、ユーザーはそのようなドキュメントにアクセスできません。 このような制限は、ファイルまたはフォルダー自体へのアクセスを禁止または許可したテクノロジに関係なく、禁止規則が許可規則よりも常に優先されるために発生する可能性があります。

集中型アクセスポリシーを指定したことで少し理解できましたが、組織に集中型アクセスポリシーを実装する前に満たす必要がある予備的な要件を知っておくこともお勧めします。 これらの要件には、次の事実が含まれます。

1. 適切な属性を使用して、ユーザーアカウントまたはコンピューターのオブジェクトに接続されるクレームを作成する必要があります。
2. また、ファイルプロパティ定義を作成する必要があります。
3. もちろん、ビジネス要件に応じて、1つ以上の集中アクセスルールを作成する必要があります。
4. 少なくとも1つの集中型アクセスポリシーオブジェクトを作成し、その結果、そのパラメーターを定義する必要があります。
5. グループポリシーの機能を使用して、これらのポリシーをファイルサーバーに拡張する必要があります。 したがって、Windows Server 2012/2012 R2オペレーティングシステムを実行しているファイルサーバーは、動的アクセス制御の存在と、組織内で集中アクセスポリシーが作成されていることを既に知っています。
6. 最後に、移行先サーバーで、これらのポリシーを選択したパブリックフォルダーに適用する必要があります。

このセクションの実際の部分に移り、Active Directoryサーバーの全体管理コンソールとツールを使用して、そのようなオブジェクトに対する集中型アクセスルールを作成、編集、追加、削除する方法、および集中型アクセスポリシーオブジェクトを削除する方法を見てみましょうWindows PowerShell

中央アクセスポリシーを作成する

集中アクセスポリシーの管理に関連するタスクは、集中アクセスルールの実装に関連するタスクと非常に似ています。 次の例は、この記事で作成した最初のアクセスルールに基づいた集中型アクセスポリシーの作成を示しています。 そのため、このようなポリシーを作成するには、次の手順を実行する必要があります。

1. Active Directoryサーバーの全体管理コンソールで、今度は[ダイナミックアクセス制御]> [中央アクセスポリシー]ノード（[ ダイナミックアクセス制御]> [中央アクセスポリシー] ）に移動するか、タイルで[中央アクセスポリシーの 作成 ]現在のコンソールのホーム画面での動的アクセス制御。 次の図に示すように、このノードから、詳細ペインからコンテキストメニューを呼び出すか、詳細ペインから新規および中央アクセスポリシーオプションを選択します。
   
   
   
   
   
   図 5.集中アクセスポリシーの作成
2. その後、 「 中央アクセスポリシーの作成 」ダイアログボックスで、将来のアクセスポリシーに必要なすべてのパラメーターを定義できます。 集中型アクセスルールを作成または変更するためのダイアログボックスとは異なり、このようなポリシーを作成する場合、次の2つのグループのパラメーターのみを編集できます。
   
   
   • グループ「一般」 （ 一般 ）。 前のケースと同様に、これらはポリシーを適切に特徴付けることができる一般的なパラメーターです。 ここでは、長い間知られ理解されてきた3つのパラメーターを定義できます。
     
     
     • お名前 作成しているポリシーのわかりやすい名前を指定できます。 この例では、このルールは「 Los Angeles Marketers 」と呼ばれます。
     • 説明 作成中のダイナミックアクセス制御オブジェクトの一般的な説明。 このフィールドには、「 Los Angeles Marketers Access Rulesを使用した累積ポリシー 」が表示されます。
     • 誤った削除に対する保護（誤った削除から保護する） 。 知らない間に作成した集中アクセスポリシーの削除を禁止するパラメーター。 これまでのすべてのケースと同様に、このボックスのチェックを外すことはせず、次のパラメーターのグループを検討します。
   • グループ「メンバー」 。 作成された中央集中型アクセスポリシーのこのグループでは、このポリシーのメンバーになる中央集中型アクセスルールを指定できます。 [ 追加 ]ボタンをクリックすると、集中型アクセスルールを追加するためのダイアログボックスが目の前に表示されます。左側の対応するリストから1つ以上のルールを選択する必要があります（下図を参照）。 必要なルールを選択したら、二重山括弧付きの一番上のボタンをクリックして、そのようなルールを追加されたアクセスルールのリストに移動します。 ところで、このダイアログボックスから直接、ウィザード（より正確にはダイアログボックス）を呼び出して、新しい中央アクセスルールを追加できます。
   
   
   ちなみに、参加者の集中型アクセスルールのグループの[ 権限状態 ]列には、このルールに適用される集中型アクセスルールで使用される権限のリストがあります。 次の図でわかるように、「 Proposed 」および「 Current 」（ Proposed、Current ）の値は、このような許可の有効な値として機能します。
   
   
   
   
   
   図 6.集中型アクセスポリシーを作成するためのダイアログボックス
3. [ OK]ボタンをクリックして、作成された集中型アクセスポリシーを保存します。

GUIメソッドでは、すべてが明確であるため、より複雑なメソッド、つまりWindows PowerShellを使用して集中型アクセスポリシーを作成する方法に進みましょう。 基本的に、集中型アクセスポリシーの機能と連携するコマンドレットは、Windows PowerShellを使用してリソースプロパティリストを管理する方法に似ています。 つまり、1つのコマンドレットの助けを借りて、そのすべてのメンバーで集中アクセスポリシーを完全に作成することはできません。 最初に、オブジェクト自体を作成し、次に2番目のコマンドレットを使用して、作成したポリシーに必要なアクセスルールを追加する必要があります。

次の5つのWindows PowerShellコマンドレットを使用して、これらのオブジェクトを操作できることがわかりました。New-ADCentralAccessPolicy。これにより、集中アクセスポリシーオブジェクト自体を作成できます。Set-ADCentralAccessPolicy、既存のポリシーの変更を担当。Remove-ADCentralAccessPolicy、これにより、実際には、不要なアクセスポリシーと、Add-ADCentralAccessPolicyMemberおよびRemove-ADCentralAccessPolicyMemberコマンドレットを削除します。選択したポリシーに集中アクセスルールを追加または削除するように設計されています。次の例では、新しい集中型アクセスポリシーを追加し、それに1つのアクセスルールを追加できる2つのコマンドレットのみが考慮されます。そのため、まず最初に、次のコマンドレットを使用する必要があります。ご覧のとおり、このコマンドレットに問題はないはずです。ここで、Nameパラメーターはルールの名前を、Description-説明はServerパラメーターを使用して作成されたルールのターゲットサーバーを指定でき、ProtectedFromAccidentalDeletionパラメーターを使用すると作成したオブジェクトのそれ以上の削除を禁止します。



New-ADCentralAccessPolicy -description:"Just another CAP" -Name:"Test CAP" -Server:"DC.biopharmaceutic.local" -ProtectedFromAccidentalDeletion:$true









最も興味深い部分は、作成したルールに一元化されたアクセスルールを追加する段階から始まります。2番目のコマンドでは、ポリシーに追加される中央アクセスルールを指定する必要があります。このようなコマンドは次のようになります：ここには2つのパラメーターのみが表示されます。つまり、以前に作成したルールを指定できるIdentityパラメーターと、必要なすべての集中アクセスルールをコンマで区切って指定する必要があるMembersパラメーターです。通常どおり、コマンドの実行後に警告が表示されない場合、すべてが正しく作成されています。これらのコマンドの出力例を以下に示します。



Add-ADCentralAccessPolicyMember -Identity:"CN=Test CAP,CN=Central Access Policies,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local" -Members:"CN= - ,CN=Central Access Rules,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local" -Server:"DC.biopharmaceutic.local"













図 7. Windows PowerShellを使用して集中型アクセスルールを作成する

既存の集中型アクセスポリシーの変更と削除は、この記事で説明するすべてのタスクの中で最も簡単な操作である可能性があります。この結論は、プロパティ変更コマンドの助けを借りて、およびポリシーの削除中に新しいパラメータまたはプロパティに遭遇しないという理由で作成できます。編集既存のアクセスポリシーに、あなたは、Active Directory管理センターに必要な、サイトにアクセスダイナミックアクセス制御>中央アクセスポリシー、所望のアクセスポリシーを選択し、いずれかのコンテキストメニューから、またはパネルから「課題」（タスク）コマンドを選択し、「プロパティ」を（プロパティ）。

あなたは、同じコンテキストメニューやタスクバーから既存の集中新しいアクセスルールアクセスポリシーに追加する必要がある場合はまた、クリック»集中アクセスルールを追加」（追加中央アクセスルール）。このオプションを選択すると、集中アクセスポリシーを作成する手順の第2段階で説明した集中アクセスルールを追加するためのダイアログボックスが表示されます。

不要な集中型アクセスポリシーを削除することで、問題も発生しなくなります。同じノードでこれを行うには、中央アクセスポリシー、目的のオブジェクトを選択し、コマンドを実行し、「削除»（削除し、コンテキストメニューから）。

中央アクセスポリシーを配布する

もちろん、中央集権的な政治家だけでは何も得られません。運用ファイルサーバーでそれらの使用を開始するには、最初に一元的に配布する必要があります。Windowsオペレーティングシステムのほとんどすべての設定の配布を自動化する最良の方法は、グループポリシーの機能を使用することです。現時点では、グループポリシーの助けを借りて、システムのカスタマイズに関して想像できるほとんどすべてのことができます。これらがグラフィカルインターフェイスにある特定のシステムパラメータである場合は、何千もの管理用テンプレートが開発されています。アプリケーションをインストールする必要があります-これにはCSE GPSI拡張があります、パスワードポリシーの定義、システムサービスの構成、システムレジストリへのアクセスの制限、またはプログラムへのアクセスを制限するポリシーの構成など、WindowsファイアウォールまたはIPSECのルール-Windows構成ノードからの既存のパラメーターが役立ちます。特定のソフトウェア製品の集中構成を実行する必要がある場合、ベンダーは、製品の管理用テンプレートをリリースすることにより、すでに多くの作業を行っている可能性があります。目的のポリシー設定が見つからない場合でも、グループポリシーの設定をいつでも利用できます。これにより、ミスを犯しやすい面倒なスクリプトを書く必要がなくなります。

そして、もちろん、ダイナミックアクセス制御などの技術は、グループポリシーのクライアント側を拡大することなくしてはできません。作成するすべてのルールとポリシーは概してActive Directoryドメインサービスに保存されるため、必要なコンテナーからそのようなオブジェクトを削除し、それらで指定されたパラメーターを特定のコンピューターに配布するだけです。言葉で言えば、これは非常に単純に聞こえますが、そのような手順が実際に何であるかを見てみましょう。

そのため、以前に作成した集中型アクセスポリシーをファイルサーバーに配布するには、次の手順を実行する必要があります。

1. « » ( Group Policy Management ), , « Dynamic Access Control 01 », ;
2. CSE . \\ Windows\ \ ( Computer Configuration \ Policies\Windows Settings \ Security Settings\File System ). Microsoft, , , « . 6: , , ». , Windows Server 2012, , « » ( Central Access Policy ) . , , , , « » ( Manage Central Access Policies… ):
   
   
   
   
   
   図 8. GPME
3. « » ( Central Access Policies Configuration ), . , , « » ( Available Central Access Policies ) ( , CTRL ), , « » ( Add ), « » ( Applicable Central Access Policies ):
   
   
   
   
   
   図 9.
4. , .

原則として、集中アクセスポリシーを管理できるグループポリシーの機能のランクにクライアント側の拡張機能が追加されているため、構成するポリシーは、レプリケーションに参加するすべてのドメインコントローラーのSYSVOLフォルダーに何らかの形式で保存する必要があります。たとえば、生成されたポリシー設定をドメインコントローラーでローカライズするには、フォルダーCに移動する必要があります。\ Windows \ SYSVOL \ domain \ Policies \ {6DF180BA-22E3-4D52-A34F-158633E56956} \ Machine \ Microsoft \ Windows NT \ Cap、ここでC ：\ Windows \ SYSVOL \ domain \ Policiesは、ドメインで作成されたすべてのGPOがあるディレクトリへのパス{6DF180BA-22E3-4D52-A34F-158633E56956}です。作成および構成されたばかりのGPO自体のGUID（グループポリシー管理エディターから直接トップノードのプロパティダイアログを呼び出すことで確認できます）、およびMachine \ Microsoft \ Windows NT \ Capは既に指定されたポリシー設定が決定されるファイルが置かれているフォルダー。

このディレクトリには、cap.infと呼ばれる単一の.infファイルがあります（Central Access Policyの略）。このファイルは暗号化されていないため、必要に応じてその内容を表示できます。たとえば、私の場合、このようなファイルには次の行が含まれます。



[Version]

Signature = "$ Windows NT $"

[CAPS]

「CN =テストCAP、CN =セントラルアクセスポリシー、CN =クレーム構成、CN =サービス、CN =構成、DC =バイオ医薬品、DC =ローカル」

"CN =ロサンゼルスマーケター、CN =セントラルアクセスポリシー、CN =クレーム構成、CN =サービス、CN =構成、DC =バイオ医薬品、DC =ローカル»



このようなファイルの内容からすべてが明確であり、これ以上詳細に検討すべきではないと考えています。大まかに言うと、ご覧のとおり、Active Directoryドメインサービスに格納されている集中アクセスポリシーの名前と場所を決定する識別名をここで見つけることができます。

このINFファイルでは、ポリシーの名前とその場所のみを見つけることができます。つまり、このようなファイルを受信した後、アクションがまったく実行されない場合、この場合、クライアントはルールは言うまでもなく、そのようなポリシーが何であるかを単に知りません。このため、オペレーティングシステムは、「これらのポリシーの目的とポリシーでできることを正しく理解する」ために、何らかのアクションを取り、メカニズムを実装する必要があります。幸いなことに、Windows Server 2012/2012 R2では、すべてがすぐに実装されています。グループポリシー設定を更新した後、auditse.dllシステムライブラリは、集中管理されたアクセスポリシーに関する必要な情報をINFファイルから読み取り、そして、LDAPクエリを通じて、クライアントサイドの拡張により、システムに必要なすべてのデータがドメインサービスから受信され、ターゲットコンピューターのシステムレジストリに書き込まれます。

このようなパラメーターをローカライズおよび調査する場合は、レジストリエディターを使用し、regerditウィンドウでHKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ CentralizedAccessPoliciesセクションに移動する必要があります。また、CAPEセクションには集中型アクセスルールがあり、CAPセクションには集中型アクセスポリシーを担当するパラメーターがあることに注意してください。たとえば、ルールとアクセスポリシーの両方について、NameパラメーターとDescriptionパラメーターを見つけることができます、特定のオブジェクトの名前と説明をそれぞれ担当します。次の図でわかるように、レジストリのこのセクションでは、パラメーターと共に配布するすべての集中型アクセスポリシーを含むサブキーを見つけることができます。





図 10.集中型アクセスポリシーおよびルールの特定のパラメーターを含むレジストリセクション

原則として、これら2つのセクションの各パラメーターについて説明することにはあまり意味がないので、この記事では単純に検討しません。

中央アクセスポリシーの適用

集中型アクセスルールの作成、集中型アクセスポリシーの設定、ルールへの追加、グループポリシー機能を使用した集中型アクセスポリシーの配布など、上記のすべての手順が完了したら、この手順の最後の部分を完了できます。つまり、ファイルサーバーでホストされているターゲットフォルダーまたはファイルへの集中アクセスポリシーの適用です。レジストリにパラメーターを作成した直後に、オペレーティングシステムは特定の集中アクセスルールとポリシーをローカルセキュリティシステムに配布します。

集中型アクセスポリシーを適用するには、次の手順を完了する必要があります。

1. Windows , . « » ( Properties );
2. «» ( Security ), , , «» ( Advanced );
3. , «» , «» « » ( Permissions, Auditing, Effective Access ) « » ( Central Policy ), . .
   
   , . , . , « -», , . , , , Active Directory . , . :
   
   
   
   
   
   図 11.
4. , . , , SACL . , S-1-17, , , .

おわりに

そのため、この記事では、動的アクセス制御について引き続き説明しました。 Active Directoryサーバーの全体管理コンソールとWindows PowerShellの機能の両方を使用して、集中型アクセスルールとは何か、そのようなルールを管理する方法を学習しました。さらに、この記事では、アクセスルールの運命、つまり、一元化されたアクセスポリシーのメンバーシップについて詳しく説明しました。また、これらのポリシーを管理する方法も学びました。また、グループポリシーを使用してこのようなアクセスポリシーの配布について学ぶこともできます。また、この記事の最後の小さなセクションでは、生成および配布された集中アクセスポリシーをファイルサーバーでホストされるターゲットフォルダーおよびファイルに適用する方法について説明しました。

このシリーズの次回の記事では、動的アクセス制御技術の詳細を引き続き検討し、条件式と提案されたアクセス許可、集中型アクセスポリシーの使用のいくつかの「実際の」例、および議論する時間がなかった他の多くの興味深い点について詳しく説明しますこのサイクルの最初の5つの記事で言及してください。