Active DirectoryのID管理運用|グループ設計と見落としがちな運用の穴

2026年8月公開株式会社アプリップリ編集部

Windowsのログインまわりのソフトを開発・提供している会社が、中小企業の情シス・総務担当の方に向けて書いています。

目次(タップで開く)

    Active Directory(AD)を導入していればドメインアカウント管理は一元化できる、と考えられがちですが、実際には基盤があることと運用が回っていることは別の問題です。この記事では、ADを既に使っている前提で、グループ設計・権限の継承・無効化漏れといった運用上の落とし穴と、その防ぎ方を整理します。なお、ローカルアカウント・AD・Entra IDのどれを選ぶかという方式選定についてはローカル・ドメイン・Entra IDの違いで扱っています。

    ADを入れれば一元管理できる、とは限らない

    ADは認証とアカウント情報を集約する仕組みであり、集約された情報が正しい状態に保たれるかどうかは運用側の設計に依存します。入社・異動・退職のたびに誰がどの操作を行うのか、その結果を誰が確認するのかが決まっていなければ、ADの中身は実態から少しずつずれていきます。台帳運用と同じく、ルールがなければ形骸化するという点は変わりません。運用ルールの組み立て方そのものはアカウント管理システムの基本で解説しています。

    グループ設計でつまずきやすい点

    AD運用で最も影響が大きいのがグループ設計です。実務で問題になりやすいのは次のようなパターンです。

    • 組織図をそのままグループにしてしまう — 部署構成が変わるたびにグループ構成の作り直しが必要になり、異動が続くうちに実態と合わなくなります
    • 目的が曖昧なグループが増える — 一時的な用途で作ったグループが残り続け、何のためのグループなのか誰も説明できない状態になります
    • 個人に直接権限を付けてしまう — 急ぎの対応でユーザー個人にアクセス権を付与すると、グループ設計を見ても実際の権限が分からなくなり、設計そのものが意味を失います

    グループは組織構造ではなく、業務上の役割や共有したいリソース単位で設計しておくと変化に耐えやすくなります。最小権限の考え方そのものは権限管理の基本で扱っているため、ここではAD固有の設計面に絞ります。

    権限の継承と入れ子が生む見えにくさ

    グループの中にグループを入れる入れ子の構成は、うまく使えば管理負荷を下げられますが、階層が深くなると副作用が出ます。あるグループにユーザーを一人追加しただけで、上位のグループを経由して意図しない範囲までアクセス権が広がることがあります。階層が数段になると、特定のユーザーが最終的にどのリソースへアクセスできるのかを担当者が説明できなくなり、権限の棚卸しも困難になります。

    対策としては、入れ子の階層数に上限の目安を決めておく、権限を持つグループは入れ子の親にしない、といった運用上の制約を設けることが有効です。実際にどのような権限が広がっているかを確認する手順はID棚卸しの進め方も参考になります。

    無効化・削除の漏れは残り続ける

    退職や契約終了に伴う無効化が漏れると、ADの中に休眠アカウントが残ります。ログインされていないため気づきにくく、外部からの侵入時に狙われやすい状態が長く続きます。また、人のアカウントは無効化されていても、システム連携やバッチ処理のために作られたサービスアカウントが有効なまま残っているケースもあります。担当者が変わると、そのアカウントが何のために存在するのか分からず、止めてよいか判断できないまま放置されがちです。

    棚卸しの際は、人のアカウントとサービスアカウントを分けて扱い、後者には用途と管理者を記録しておくことをおすすめします。休眠アカウントの整理の考え方は退職者アカウントの棚卸しで詳しく扱っています。

    ADは侵入後の横展開の足場にもなる

    ADは組織内の認証を集約しているため、管理者権限を持つアカウントが奪われた場合、影響範囲が組織全体に及びやすい構造になっています。VPN機器の脆弱性やランサムウェアによる侵入をきっかけに、認証情報を足がかりとして横方向に展開されるという流れは、実際のインシデントでも見られる形です(ランサムウェア対策の基本、VPN機器の脆弱性も参照)。

    だからこそ、管理者権限を持つアカウントの認証強化は優先度が高い施策になります。多要素認証の基本やWindows OSログインの2要素認証を踏まえ、少なくとも管理者アカウントから対応を進める考え方が現実的です。特権アカウントそのものの扱いについてはWindows Serverの特権アカウント管理を参照してください。

    運用を形骸化させないために決めておくこと

    • グループの命名と作成の申請ルール — 誰が何のために作ったグループか後から追えるようにします
    • 権限付与はグループ経由に限定 — 個人への直接付与を例外扱いとし、例外を作る場合は期限と理由を残します
    • 定期的な突合 — ADの登録内容と在籍状況、サービスアカウントの用途を定期的に照合します
    • 管理者アカウントの認証強化 — 影響範囲が大きいアカウントから優先して対策します

    いまの運用を棚卸ししてみる

    ADを使っていても、グループ設計や棚卸しの運用が伴っているかは組織によって差があります。applippliの無料棚卸しでは、10問・約3分で、自社のID・アカウント管理の対応状況を「解決済み/一部解決/人手で対応/未解決」に仕分けた一覧にできます。侵入の検知と防御のような他の観点とあわせて、優先度を整理する材料としてご利用ください。

    この記事を社内で共有する

    運用の要点は分かりました。ADで管理しきれず人手で補っている箇所(PCごとのローカルIDや共有IDなど)がどこかを、10問で一覧にできます。

    入力必須の項目はありません。会社名も任意、会員登録も不要で、電話番号もお伺いしません。

    この記事を書いた会社

    株式会社アプリップリ / アプリップリキー

    アプリップリキーは、Windowsのログインをスマートフォンのワンタッチにする国産ソフトです。パスワードを覚えて打つ運用をなくし、誰がいつPCを使ったかを記録に残します。

    製品サイトを見る
    © 2026 株式会社アプリップリ