Active Directory(AD)を導入していればドメインアカウント管理は一元化できる、と考えられがちですが、実際には基盤があることと運用が回っていることは別の問題です。この記事では、ADを既に使っている前提で、グループ設計・権限の継承・無効化漏れといった運用上の落とし穴と、その対処法を整理します。なお、ローカルアカウント・AD・Entra IDのどれを選ぶかという方式選定についてはローカル・ドメイン・Entra IDの違いで扱っています。
ADを入れれば一元管理できるとは限らない
ADは認証とアカウント情報を集約する仕組みであり、集約された情報が正しい状態に保たれるかどうかは運用側の設計に依存します。入社・異動・退職のたびに誰がどの操作を行うのか、その結果を誰が確認するのかが決まっていなければ、ADの中身は実態から少しずつずれていきます。台帳運用と同じく、ルールがなければ形骸化するという点は変わりません。運用ルールの組み立て方そのものはアカウント管理システムの基本で解説しています。
グループ設計でつまずきやすい点
AD運用で最も影響が大きいのがグループ設計です。実務で問題になりやすいのは次のようなパターンです。
- 組織図をそのままグループにしてしまう — 部署構成が変わるたびにグループ構成の作り直しが必要になり、異動が続くうちに実態と合わなくなります
- 目的が曖昧なグループが増える — 一時的な用途で作ったグループが残り続け、何のためのグループなのか誰も説明できない状態になります
- 個人に直接権限を付けてしまう — 急ぎの対応でユーザー個人にアクセス権を付与すると、グループ設計を見ても実際の権限が分からなくなり、設計そのものが意味を失います
グループは組織構造ではなく、業務上の役割や共有したいリソース単位で設計しておくと変化に耐えやすくなります。最小権限の考え方そのものは権限管理の基本で扱っているため、ここではAD固有の設計面に絞ります。
権限の継承と入れ子が生む見えにくさ
グループの中にグループを入れる入れ子の構成は、うまく使えば管理負荷を下げられますが、階層が深くなると副作用が出ます。あるグループにユーザーを一人追加しただけで、上位のグループを経由して意図しない範囲までアクセス権が広がることがあります。階層が数段になると、特定のユーザーが最終的にどのリソースへアクセスできるのかを担当者が説明できなくなり、権限の棚卸しも困難になります。
対策としては、入れ子の階層数に上限の目安を決めておく、権限を持つグループは入れ子の親にしない、といった運用上の制約を設けることが有効です。実際にどのような権限が広がっているかを確認する手順はID棚卸しの進め方も参考になります。
無効化・削除の漏れは残り続ける
退職や契約終了に伴う無効化が漏れると、ADの中に休眠アカウントが残ります。ログインされていないため気づきにくく、外部からの侵入時に狙われやすい状態が長く続きます。また、人のアカウントは無効化されていても、システム連携やバッチ処理のために作られたサービスアカウントが有効なまま残っているケースもあります。担当者が変わると、そのアカウントが何のために存在するのか分からず、止めてよいか判断できないまま放置されがちです。
棚卸しの際は、人のアカウントとサービスアカウントを分けて扱い、後者には用途と管理者を記録しておくことをおすすめします。休眠アカウントの整理の考え方は退職者アカウントの棚卸しで詳しく扱っています。
ADのアカウントとは別に、各PCのローカルアカウントにも同じ漏れが起きます。アプリップリキーなら、全PC・サーバーのログイン記録を1画面で見られ、PCのローカルアカウントは席まで行かずにその場で無効にできます（ドメインのアカウントはADの側で止めます）。さらに、PC及びサーバーのログインを本人のスマホを鍵にしたワンタッチログインにでき、ADがあってもなくても導入できます（PC版・サーバー版）。
ADは侵入後の横展開の足場にもなる
ADは組織内の認証を集約しているため、管理者権限を持つアカウントが奪われた場合、影響範囲が組織全体に及びやすい構造になっています。VPN機器の脆弱性やランサムウェアによる侵入をきっかけに、認証情報を足がかりとして横方向に展開されるという流れは、実際のインシデントでも見られる形です(ランサムウェア対策の基本、VPN機器の脆弱性も参照)。社内のWi-Fiも、VPNと同じく社内への入口です。
だからこそ、管理者権限を持つアカウントの認証強化は優先度が高い施策になります。多要素認証の基本やWindows OSログインの2要素認証を踏まえ、少なくとも管理者アカウントから対応を進める考え方が現実的です。特権アカウントそのものの扱いについてはWindows Serverの特権アカウント管理を参照してください。
運用を形骸化させないために決めておくこと
- グループの命名と作成の申請ルール — 誰が何のために作ったグループか後から追えるようにします
- 権限付与はグループ経由に限定 — 個人への直接付与を例外扱いとし、例外を作る場合は期限と理由を残します
- 定期的な突合 — ADの登録内容と在籍状況、サービスアカウントの用途を定期的に照合します
- 管理者アカウントの認証強化 — 影響範囲が大きいアカウントから優先して対策します
ADの棚卸しが楽になると何が変わるか
ADの定期的な突合で手間がかかるのは、「このアカウントは今も使われているか」「このPCは今も社内で動いているか」を確かめる作業です。ADの画面だけでは、実際の使われ方までは分かりにくいことがあります。
アプリップリキーでは、アプリップリキーを入れたPC・サーバーについて、ログイン記録（日時・利用者・接続元のPC名とIPアドレス）を利用者で絞り込み、CSVで出せます。突合のときに「最近ログインがあるか」をPCを1台ずつ開かずに確かめられます。7日以上連絡のないPCも一覧で分かるので、ADに残ったままの古いPCを見つける手がかりになります。監査や取引先のチェックシートで聞かれたときも、その日のうちに記録を出せます。
いまの運用を棚卸ししてみる
ADを使っていても、グループ設計や棚卸しの運用が伴っているかは組織によって差があります。applippliの無料棚卸しでは、10問・約3分で、自社のID・アカウント管理の対応状況を「解決済み／一部解決／人手で対応／未解決」に仕分けた一覧にできます。侵入の検知と防御のような他の観点とあわせて、優先度を整理する材料としてご利用ください。