Active Directoryセキュリティ

Active Directoryのセキュリティは規制コンプライアンスに密接に関連していますが、この2つは同じではないことを理解することが重要です。多くのコンプライアンス規制には、ADのセキュリティポリシーと手順に直接影響する要件が含まれますが、これらの義務は、オフィスビルへの物理的な入場、従業員のトレーニング、役員の説明責任など、他の多くの分野にも及ぶことがよくあります。一方、ADの包括的なセキュリティは、単に1つ以上の規制へのコンプライアンスを達成することだけではありません。

Active Directoryのセキュリティは、GDPR、CCPA、HIPAA、SOX、PCI-DSSなど、数多くのコンプライアンス規制の根幹です。Active Directoryをセキュリティで適切に保護しないと、規制当局からの高額の罰金、役員の懲役刑、クレジットカード取引の処理不能、顧客の信頼の喪失など、さまざまな不快な結果を招くことになります。

Active Directoryのセキュリティリスクは、3つの重要要素に対する洞察と制御が欠如していることから発生します。つまり、誰がネットワークに入るのか、中に入ったら何をすることが許可されるのか、そして実際にどのようなアクティビティが行われるのかについてです。これらのセキュリティリスクの中には、インサイダー脅威、スピアフィッシング、権限昇格、ラテラルムーブメントなど、具体的な名前が付いているものもあります。しかしながら、ADのセキュリティリスクに対処する最善の方法は、それぞれ個別に戦わないことです。このような手当たり次第の手法は、コストを押し上げ、ITシステムがさらに複雑になるだけであり、問題を解決するどころか、悪化させます。

そうではなく、最善の戦略は、Active Directoryをクリーンアップして整然とした状態を保ち、IT環境全体のアクティビティを明確に可視化することです。ネイティブツールには必要な機能のごく一部が用意されているだけで、使用するには膨大な時間と労力が必要です。そのため、賢明なのは、強力なActive Directoryセキュリティに必要なコアプロセスを自動化および簡素化する包括的なソリューションに投資することです。

前述したように、最小特権の原則は、ITセキュリティの最も基本的なベストプラクティスです。ユーザの権限を各リソースに個別に手動で割り当て、現れては消えていくユーザや、組織内での役割の変更に応じて、権限を最新の状態に維持しなければならないとしたら、あっという間に手に負えなくなり、組織はデータ漏洩やコンプライアンス違反のリスクが高くなるでしょう。

ADセキュリティグループを作成し、同様のユーザの権限を一緒に管理できると、負荷が軽減されます。ユーザをプロジェクトベースのグループなど、複数のADグループのメンバーに設定できます。また、通常その状態になっています。例えば、新しい営業マネージャが任命されたら、営業と営業マネージャの両方のセキュリティグループに追加するだけで、適切なすべてのリソースにアクセスできるようになります。同様に、すべての営業担当者がアクセスする必要がある新しいフォルダまたはファイル共有が存在する場合は、営業グループにアクセス権を付与するだけでよく、個々のユーザアカウントに1つずつ追加する必要がありません。逆に、あるユーザが営業職から組織内の別の地位に移動する場合は、そのユーザを営業グループから削除するだけで、すべての営業リソースへのアクセス権を素早く削除できます。そのユーザが使用権限を持つ各リソースを苦労して確認し、そのアクセス権がまだ正当であるかどうかを判断する必要はありません。

ADセキュリティグループの使用は、管理者にとってただ単に便利なだけではありません。プロビジョニングとプロビジョニング解除におけるエラーを減らし、権限構造の複雑さを最小限に抑えることで、セキュリティを向上させ、誰が何にアクセスできるかを確信を持って容易に判断できるようになります。

特に懸念されるのは、非常に強力なEnterprise Admins、Domain Admins、Schema Adminsグループなどの管理者レベルの権限を付与するActive Directoryセキュリティグループと、Windowsのインストール時に作成され、ローカルコンピューター上のファイル、ディレクトリ、サービスなどのリソースを完全に制御する、ローカルのAdministratorアカウントです。組織は、これらの特権アクセスグループのメンバーを厳密に制御し、メンバーシップの変更に注意する必要があります。攻撃者または悪意のある内部関係者が自分の権限を昇格させ、追加のシステムやデータへのアクセス権を得ようとしていることを示している可能性があるからです。

サービスアカウントは、アプリケーションとサービスがIT環境でログオンを使用してアクションを実行する特別なユーザアカウントです。残念ながら、サービスアカウントには、実際に必要とされる権限よりもはるかに多くの権限が付与されていることが多く、セキュリティリスクを高めています。オーバープロビジョニングのよくある理由には、アプリケーションベンダーが指定した要件をそのまま受け入れる、運用上の課題を適切に対処できない、適切な権限セットを使用して時間をかけて新しいサービスを作成せずに、単に既存のサービスのクローンを作成することなどがあります。

ベストプラクティスは、もちろん、すべてのサービスアカウントが最小特権の原則に準拠するように保証することです。また、サービスアカウントに管理者権限が必要な場合は必ず、特別な注意を払う必要があります。サービスアカウントを、ローカルのAdministratorグループやDomain Adminsグループなど、標準の管理者グループのメンバーにしてはいけません。サービスをLocalSystemアカウントで実行するか、サービスアカウント用のカスタムグループを作成し、そのグループの他のアカウントへのアクセスを明示的に拒否することをお勧めします。さらに、可能な限り、1日の特定の時間帯にのみログオンできるようにサービスアカウントを設定するのが賢明です。