applippli
applippli
診断トップへ

2026年8月

グループポリシーでできるアカウント保護設定|設定できる項目とGPOでは埋まらない穴

Active Directoryを運用している環境では、アカウント保護の多くをグループポリシー(GPO)で一括して適用できます。追加のコストがかからないため、まずここを固めるのが実務上の出発点になります。一方でGPOでは構造的に扱えない領域があり、そこを認識せずに「ポリシーは設定済み」と判断すると穴が残ります。この記事では、GPOで設定できる項目と、GPOの外に出る領域を分けて整理します。

なお、有効期限や複雑性といった要件の決め方そのものは企業のパスワードポリシーの決め方で扱っています。本記事はGPOという手段で何がどこまでできるかに絞ります。

GPOで設定できるアカウント保護の項目

1. パスワードポリシー

ドメイン全体のパスワード要件を強制できます。設定できるのは、最短・最長の有効期間、最小文字数、複雑性の要求、過去のパスワードの再利用禁止(履歴)といった項目です。

注意点は、これがドメイン単位の設定であることです。従来は「ドメインに1つのパスワードポリシー」が原則で、部署や役職ごとに異なる要件を適用したい場合は、細かい粒度でポリシーを分ける仕組み(きめ細かいパスワードポリシー)を別に設計する必要があります。管理者アカウントだけ要件を厳しくしたい、という要望はここに該当します。

2. アカウントロックアウト

ログオンの失敗が一定回数続いたアカウントを一時的に使えなくする設定です。しきい値、ロックの継続時間、失敗回数のカウントをリセットする間隔を指定します。総当たり攻撃への基本的な対策になります。

ただしこの設定には副作用があります。しきい値を厳しくすると、攻撃者が意図的に失敗を繰り返して正規利用者を業務から締め出すことが可能になります。また、盗まれた正しいID・パスワードでログインしてくるリスト型攻撃は失敗が発生しないため、ロックアウトでは検知も阻止もできません。

3. ユーザー権利の割り当て(ログオン制限)

「どのアカウントがどの方法でログオンできるか」を制御できます。実務でよく使われるのは次の形です。

  • リモートデスクトップでのログオンを許可するアカウントを限定する — RDPで入れる範囲を絞る
  • ローカルログオンを拒否する対象を指定する — サービス専用のアカウントが対話的にログオンできないようにする
  • ネットワーク経由のアクセスを制限する — 侵害された1台から他の端末への横移動を抑える

特に2つ目は、システム連携やバッチ処理のために作られたアカウントの悪用を抑えるうえで効果があります。対象の洗い出しはサービスアカウントの管理を参照してください。

4. 管理者権限に関わる設定

管理者グループの構成員をGPOで固定し、勝手に追加された管理者を次回の適用時に元へ戻すことができます。また、管理者としての操作時に確認を求める挙動の水準も制御できます。過剰な権限付与が定着している環境では、まずここを固定して増殖を止めるのが有効です。権限設計そのものはアカウントの権限管理とはで扱っています。

5. 監査ポリシー

ログオンの成功・失敗、アカウントの作成や変更、権限の使用などをイベントとして記録させる設定です。ここを有効にしていなければ、事故が起きたときに追跡の材料が残りません。何を残せば使えるログになるかはログイン履歴・操作ログは何を残せばよいかで整理しています。

GPOでは埋まらない4つの穴

1. 各PCのローカルアカウント

ドメインのパスワードポリシーはドメインアカウントに適用されるもので、各PCの中に個別に存在するローカルアカウントには及びません。各端末のローカルAdministratorが弱いパスワードのまま、あるいは全台で同じパスワードのまま残っているケースは珍しくなく、これは1台の侵害が全台に広がる経路になります。この問題への対処はローカル管理者パスワードの管理で扱っています。

2. ドメインに参加していない端末

GPOはドメインに参加している端末に配られる仕組みです。私物端末、独立して運用している工場や店舗のPC、ドメイン参加をしていないサーバーには適用されません。「ポリシーを設定した」という認識と、実際に適用されている端末の範囲が一致しているかは、台数を突き合わせて確認する必要があります。

3. クラウドサービスのアカウント

社内のADで管理していても、各SaaSに個別に作られたアカウントはGPOの管理外です。ID連携を行っていない限り、退職時にADのアカウントを無効化してもクラウド側は生き残ります。連携の手段と一元化できる範囲はアカウント一元管理の方法を参照してください。

4. 認証要素そのもの

これがもっとも本質的な限界です。GPOで制御できるのはパスワードという1つの要素の運用ルールであって、要素を追加することはできません。文字数を増やし、有効期限を設け、履歴を残しても、盗まれたID・パスワードで正規にログインされる経路は閉じません。フィッシングや他サービスからの流出で資格情報が渡った時点で、パスワードの強度は無関係になります。

つまりGPOは、パスワード運用を整えるための道具としては十分だが、パスワード以外の要素を足す手段ではないという位置づけです。要素を追加する話はWindows/Windows Server OSログインの二要素認証で扱っています。

確認の手順

GPOによるアカウント保護の状況は、次の順で棚卸しすると穴が見えます。

  • 適用対象の台数と実台数を突き合わせる — ドメイン参加していない端末が何台あるかを数える
  • 各端末のローカルアカウントを一覧化する — ローカルAdministratorのパスワードが個別になっているかを確認する
  • クラウドサービスのアカウントを洗い出す — ADと連携しているもの・していないものを分ける
  • パスワード以外の要素があるかを確認する — なければ、上記をすべて整えてもパスワード1要素であることを認識しておく

自社の設定でどこまで守れているかを確認する

GPOで整えられる範囲と、その外に残っている範囲を切り分けることが対策の出発点になります。applippliの無料診断では、約3分の質問に回答するだけで、自社のアカウント管理・認証の対応状況を確認できます。

自社の状況を無料で診断してみませんか?

約3分の質問に答えるだけで、ID・パスワード窃取リスクとSCS評価制度への対応状況がわかります。会社名の入力は診断のあとで、会員登録は不要です。

© 2026 株式会社アプリップリ