web-dev-qa-db-ja.com

ゼロからセキュリティグループを作成する-ベストプラクティス

ADでセキュリティグループを作成する必要があります。必要なグループを特定できます。たとえば、管理、財務、セールス、エンジニアリングです。また、各グループがアクセスする必要のあるリソースを特定できます(ただし、これは面倒な作業になる可能性があります)。そして、必要なアクセスのレベルを特定できます。

ほとんどの企業は、必要に応じてセキュリティグループを追加します。しかし、これは会社がすでに成熟しているが、これまでセキュリティグループを使用したことがない状況です。セキュリティグループを実装するためのベストプラクティスはありますか?ヒントはありますか?または避けるべき落とし穴?そして、グループ->リソースマッピングプロセスをスピードアップできるツールを知っている人はいますか?

3
Rory

Windows Server 2003に関するMicrosoftの推奨事項に基づいて実装した方法(試験用のMCSE Self-Paced Training Kitにあります70-294:Microsoft Windows Server 2003 Active Directoryインフラストラクチャの計画、実装、および保守)は:

  • 組織内の各役職(CEO、セールスディレクターなど)にグローバルセキュリティグループを作成します。
  • リソースごとにドメインローカルセキュリティグループを作成します(または、一部のユーザーに読み取り専用の権限を付与し、他のユーザーに変更権限を付与する場合は2つのグループ)(例:Sales File Modifiers、Marketing Data Readers)
  • ドメインのローカルセキュリティグループを使用して、リソースに権限を割り当てます(たとえば、SalesFilesのModify権限をSalesFiles Modifiersグループに付与します)
  • 関連するグローバルセキュリティグループにユーザーを割り当てます(たとえば、CEOをCEOセキュリティグループのメンバーにします)
  • グローバルセキュリティグループを関連するドメインのローカルセキュリティグループに追加します(たとえば、SalesDirectorグループをSalesFiles Modifiersグループに追加します)。

つまり、ユーザーアカウント->ジョブロールセキュリティグループ->リソース権限セキュリティグループ->リソース権限

このようにすると、多くのリソースがある場合、多くのグループ、特にドメインローカルグループになってしまう可能性がありますが、比較的シンプルで保守しやすくなります。賢くなり、ネストされたグループの複数のレベルを持つことは、複雑さと災害のレシピです、私を信じてください!

また、管理者以外の誰もがファイルを完全に制御できないようにすることもお勧めします。これにより、ユーザーが賢くなりすぎて独自の権限を構成しようとするのを防ぐことができます。

6
hmallett

環境を知らずに具体的なアドバイスをするのは難しいですが、可能な限り広いブラシでペイントするには、すべての許可の委任において 最小特権のポリシー に従うことをお勧めします。

hmallettのアドバイスと最小特権のポリシーの背後にある考え方を組み合わせると、非常に柔軟でありながらかなり安全な環境が得られます。

0
voretaq7