
目次
はじめに:なぜActive Directory監査が重要なのか
Active Directory(以下、AD)は、Microsoft社が提供するディレクトリサービスであり、企業のITインフラにおける「心臓部」とも言える存在です。ユーザー認証、アクセス制御、グループポリシーの配布など、組織のセキュリティ基盤を支える重要な役割を担っています。
しかし、その重要性ゆえに、ADは攻撃者にとっても格好の標的となっています。2023年の調査によれば、企業へのサイバー攻撃の約80%以上がActive Directoryを経由または標的としているとされています。一度ADが侵害されると、組織全体のシステムやデータが危険にさらされる可能性があります。
本記事では、IT監査担当者やセキュリティ実務者の方々を対象に、Active Directory監査を実施する際に「まず押さえるべき5つのチェックポイント」を詳しく解説します。これからAD監査に取り組む方はもちろん、既存の監査手順を見直したい方にも役立つ内容となっています。
Active Directory監査の背景と概要
Active Directoryとは何か
Active Directoryは、Windows Server上で動作するディレクトリサービスです。簡単に言えば、「組織内のユーザー、コンピュータ、リソースを一元管理するためのデータベース」と考えることができます。
ADの主な機能は以下の通りです:
- 認証(Authentication):ユーザーが本人であることを確認する
- 認可(Authorization):ユーザーがどのリソースにアクセスできるかを制御する
- ディレクトリサービス:組織内のオブジェクト(ユーザー、グループ、コンピュータなど)の情報を格納・管理する
- グループポリシー:組織全体のセキュリティ設定やソフトウェア配布を一括管理する
なぜ監査が必要なのか
AD監査が必要な理由は、大きく分けて3つあります。
1. セキュリティリスクの低減
設定ミスや不適切な権限付与は、内部不正や外部攻撃の入り口となります。定期的な監査により、これらのリスクを早期に発見・是正できます。
2. コンプライアンス要件への対応
J-SOX(内部統制報告制度)、ISMS(ISO 27001)、PCI DSSなど、多くのセキュリティ基準でアクセス管理の適切性が求められています。AD監査はこれらの要件を満たすための基本的な活動です。
3. インシデント対応能力の向上
監査を通じてAD環境の現状を把握しておくことで、セキュリティインシデント発生時の調査・対応がスムーズになります。
AD監査の全体像
AD監査は、以下のような観点から実施されます:
| 監査領域 | 主なチェック内容 |
|---|---|
| アカウント管理 | 不要アカウントの有無、パスワードポリシーの適切性 |
| 権限管理 | 特権アカウントの管理状況、過剰な権限付与の有無 |
| グループ管理 | グループメンバーシップの適切性、入れ子構造の複雑さ |
| 監査ログ | ログ設定の適切性、ログの保管・監視状況 |
| セキュリティ設定 | グループポリシーの設定内容、脆弱な設定の有無 |
それでは、具体的な5つのチェックポイントを見ていきましょう。
チェックポイント1:特権アカウントの棚卸しと管理状況
なぜ特権アカウントが最重要なのか
特権アカウントとは、システム全体に対して強力な権限を持つアカウントのことです。ADにおける代表的な特権グループには以下があります:
- Domain Admins:ドメイン全体の管理権限を持つ
- Enterprise Admins:フォレスト(複数ドメインの集合)全体の管理権限を持つ
- Schema Admins:ADスキーマ(構造定義)を変更できる
- Administrators(ビルトイン):ドメインコントローラーのローカル管理者
これらのアカウントが侵害されると、攻撃者は組織全体を掌握できてしまいます。そのため、特権アカウントの管理は最優先のチェック項目となります。
具体的なチェック手順
Step 1:特権グループのメンバー一覧を取得する
PowerShellを使用して、特権グループのメンバーを確認します:
# Domain Adminsグループのメンバーを取得
Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object Name, SamAccountName, ObjectClass
# Enterprise Adminsグループのメンバーを取得
Get-ADGroupMember -Identity "Enterprise Admins" -Recursive | Select-Object Name, SamAccountName, ObjectClass
Step 2:メンバーの妥当性を確認する
取得した一覧について、以下の観点で確認します:
- 各メンバーは業務上、本当に特権が必要か?
- 退職者や異動者のアカウントが含まれていないか?
- サービスアカウント(システム用アカウント)が不必要に含まれていないか?
- 命名規則に従っているか?
Step 3:適正なメンバー数の目安を把握する
一般的な目安として、以下の数値を参考にしてください:
| グループ名 | 推奨メンバー数 |
|---|---|
| Domain Admins | 5人以下 |
| Enterprise Admins | 3人以下(通常は0でも可) |
| Schema Admins | 通常は0人(必要時のみ追加) |
実務ポイント:多くの組織で、Domain Adminsのメンバーが10人以上存在するケースを見かけます。しかし、ベストプラクティスでは「最小権限の原則」に基づき、必要最小限に抑えることが推奨されています。
発見されやすい問題と対応策
| よくある問題 | リスク | 対応策 |
|---|---|---|
| 退職者のアカウントが残存 | 不正アクセスの可能性 | 即座に無効化または削除 |
| 過剰な人数が登録 | 攻撃対象の増加 | 権限の見直し、必要最小限に削減 |
| サービスアカウントの登録 | 侵害時の影響拡大 | 専用の権限委任を検討 |
チェックポイント2:休眠アカウント・不要アカウントの検出
休眠アカウントが危険な理由
休眠アカウントとは、長期間使用されていないアカウントのことです。これらのアカウントは以下の理由でセキュリティリスクとなります:
- 退職者や異動者のアカウントが放置されている可能性:不正利用の温床となる
- パスワードが古いまま:攻撃者が推測・解読しやすい
- 監視の目が届きにくい:不正使用されても気づきにくい
具体的なチェック手順
Step 1:最終ログオン日時を確認する
以下のPowerShellコマンドで、90日以上ログオンしていないアカウントを抽出します:
# 90日以上ログオンしていないユーザーアカウントを検出
$InactiveDays = 90
$CutoffDate = (Get-Date).AddDays(-$InactiveDays)
Get-ADUser -Filter {LastLogonDate -lt $CutoffDate -and Enabled -eq $true} -Properties LastLogonDate, Description, WhenCreated |
Select-Object Name, SamAccountName, LastLogonDate, Description, WhenCreated |
Sort-Object LastLogonDate |
Export-Csv -Path "C:\Audit\InactiveUsers.csv" -NoTypeInformation -Encoding UTF8
Step 2:コンピュータアカウントも確認する
ユーザーアカウントだけでなく、コンピュータアカウントも同様に確認が必要です:
# 90日以上通信していないコンピュータアカウントを検出
Get-ADComputer -Filter {LastLogonDate -lt $CutoffDate -and Enabled -eq $true} -Properties LastLogonDate, OperatingSystem |
Select-Object Name, LastLogonDate, OperatingSystem |
Sort-Object LastLogonDate |
Export-Csv -Path "C:\Audit\InactiveComputers.csv" -NoTypeInformation -Encoding UTF8
Step 3:対象アカウントの精査と対応
抽出されたアカウントについて、以下のフローで対応します:
[休眠アカウント検出]
↓
[所有者・管理者への確認]
↓
┌───┴───┐
必要 不要
↓ ↓
使用継続 無効化
↓ ↓
一定期間後
↓
削除
実務上の推奨基準
| 期間 | 推奨アクション |
|---|---|
| 30日以上未使用 | 所有者への確認通知 |
| 60日以上未使用 | アカウントの無効化を検討 |
| 90日以上未使用 | 原則として無効化 |
| 180日以上無効状態 | 削除を検討 |
実務ポイント:いきなり削除するのではなく、まず「無効化」してから一定期間様子を見ることをお勧めします。誤って無効化した場合でも、復旧が容易です。
チェックポイント3:パスワードポリシーの設定確認
パスワードポリシーの重要性
パスワードは認証の基本であり、不適切なパスワードポリシーは重大なセキュリティホールとなります。実際、多くのサイバー攻撃は「弱いパスワード」を突破口としています。
確認すべきパスワードポリシー項目
ADのデフォルトドメインポリシーで設定されるパスワードポリシーには、以下の項目があります:
| 設定項目 | 説明 | 推奨値 |
|---|---|---|
| パスワードの最小文字数 | パスワードに必要な最小の文字数 | 12文字以上(理想は14文字以上) |
| パスワードの有効期間 | パスワード変更までの最大日数 | 90日以下(ただし最近は長期化傾向) |
| パスワードの変更禁止期間 | パスワード変更後、次に変更できるまでの期間 | 1日以上 |
| パスワードの履歴 | 過去に使用したパスワードの再利用禁止数 | 24世代以上 |
| 複雑さの要件 | 大文字、小文字、数字、記号の組み合わせ要件 | 有効 |
| 暗号化を元に戻せる状態でパスワードを保存する | 平文でパスワードを保存するか | 無効(必須) |
具体的なチェック手順
Step 1:現在のポリシー設定を確認する
PowerShellで現在の設定を確認します:
# デフォルトドメインポリシーのパスワード設定を確認
Get-ADDefaultDomainPasswordPolicy | Format-List *
または、グループポリシー管理コンソール(GPMC)で「Default Domain Policy」を開き、以下のパスを確認します:
コンピューターの構成
→ ポリシー
→ Windowsの設定
→ セキュリティの設定
→ アカウントポリシー
→ パスワードのポリシー
Step 2:細かい粒度のパスワードポリシー(Fine-Grained Password Policy)の確認
Windows Server 2008以降では、ユーザーやグループごとに異なるパスワードポリシーを設定できます:
# すべてのFine-Grained Password Policyを取得
Get-ADFineGrainedPasswordPolicy -Filter * | Format-List Name, Precedence, MinPasswordLength, MaxPasswordAge, PasswordHistoryCount
Step 3:脆弱なパスワードの検出(高度な監査)
専用ツールを使用して、実際に脆弱なパスワードが使用されていないかを確認することも重要です。ただし、これには適切な承認と慎重な取り扱いが必要です。
最新のパスワードポリシー動向
従来は「短いパスワードを頻繁に変更する」アプローチが主流でしたが、現在は以下のような考え方が推奨されています:
NIST SP 800-63B(2017年改訂)の推奨事項:
- 最小8文字、できれば長いパスワード(パスフレーズ)を推奨
- 定期的な強制変更は必ずしも推奨しない
- 漏洩したパスワードリストとの照合を推奨
- 複雑さの要件より、長さを重視
実務ポイント:組織のセキュリティポリシーやコンプライアンス要件と照らし合わせて、適切なバランスを取ることが重要です。
チェックポイント4:グループポリシー(GPO)のセキュリティ設定
グループポリシーとは
グループポリシー(GPO:Group Policy Object)は、ADに参加しているコンピュータやユーザーに対して、一括でセキュリティ設定やソフトウェア配布を行う仕組みです。適切に設定されたGPOは組織のセキュリティレベルを向上させますが、不適切な設定は深刻な脆弱性となります。
確認すべき重要な設定項目
1. アカウントロックアウトポリシー
ブルートフォース攻撃(総当たり攻撃)への対策として重要です:
| 設定項目 | 説明 | 推奨値 |
|---|---|---|
| アカウントのロックアウトのしきい値 | ロックアウトまでの失敗回数 | 5〜10回 |
| ロックアウト期間 | ロックアウトが解除されるまでの時間 | 30分以上 |
| ロックアウトカウンターのリセット | 失敗カウンターがリセットされるまでの時間 | 30分以上 |
2. 監査ポリシー
セキュリティイベントを記録するための設定です:
推奨する監査設定(最低限):
- アカウントログオンイベントの監査:成功と失敗
- アカウント管理の監査:成功と失敗
- ログオンイベントの監査:成功と失敗
- オブジェクトアクセスの監査:失敗
- ポリシーの変更の監査:成功と失敗
- 特権使用の監査:失敗
- システムイベントの監査:成功と失敗
3. ユーザー権利の割り当て
特に注意が必要な設定:
| 設定項目 | 確認ポイント |
|---|---|
| ネットワーク経由でこのコンピュータにアクセス | 不要なユーザー・グループが含まれていないか |
| ローカルログオンを許可 | 必要最小限に制限されているか |
| サービスとしてログオン | 不要なアカウントが含まれていないか |
| バッチジョブとしてログオン | 不要なアカウントが含まれていないか |
4. セキュリティオプション
代表的な重要設定:
| 設定項目 | 推奨設定 |
|---|---|
| Administrator アカウントの名前を変更する | 有効(デフォルト名からの変更) |
| Guest アカウントの状態 | 無効 |
| LAN Manager認証レベル | NTLMv2応答のみ送信(可能であればNTLM拒否) |
| LDAP署名を要求 | 有効 |
具体的なチェック手順
Step 1:GPOの一覧を取得する
# ドメイン内の全GPOを取得
Get-GPO -All | Select-Object DisplayName, GpoStatus, CreationTime, ModificationTime |
Sort-Object DisplayName |
Export-Csv -Path "C:\Audit\GPOList.csv" -NoTypeInformation -Encoding UTF8
Step 2:重要な設定をエクスポートして確認する
# Default Domain Policyの設定をHTMLレポートで出力
Get-GPOReport -Name "Default Domain Policy" -ReportType Html -Path "C:\Audit\DefaultDomainPolicy.html"
Step 3:リンクされていないGPOの確認
未使用のGPOは整理の対象となります:
# リンクされていないGPOを検出
Get-GPO -All | Where-Object {
($_ | Get-GPOReport -ReportType XML | Select-String -Pattern "<LinksTo>") -eq $null
} | Select-Object DisplayName
セキュリティベースラインの活用
Microsoftは「Security Compliance Toolkit」を通じて、推奨されるセキュリティ設定のベースラインを公開しています。自組織の設定と比較することで、改善点を効率的に特定できます。
実務ポイント:GPOの変更は影響範囲が広いため、本番環境への適用前に必ずテスト環境で検証してください。
チェックポイント5:監査ログの設定と監視体制
なぜ監査ログが重要か
監査ログは、「何が起きたかを後から追跡するための記録」です。セキュリティインシデントの調査、不正行為の検知、コンプライアンス証跡として不可欠な要素です。
しかし、多くの組織で以下の問題が見られます:
- 必要なログが有効化されていない
- ログの保存期間が短すぎる
- ログを監視する仕組みがない
- ログが大量すぎて重要なイベントが埋もれている
確認すべき監査ログ設定
1. 高度な監査ポリシー(Advanced Audit Policy)の確認
Windows Server 2008 R2以降では、より詳細な監査設定が可能です:
# 現在の監査ポリシー設定を確認
auditpol /get /category:*
重要なカテゴリと推奨設定:
| カテゴリ | サブカテゴリ | 推奨設定 |
|---|---|---|
| アカウントログオン | Kerberos認証サービス | 成功、失敗 |
| アカウント管理 | ユーザーアカウント管理 | 成功、失敗 |
| アカウント管理 | セキュリティグループ管理 | 成功、失敗 |
| ログオン/ログオフ | ログオン | 成功、失敗 |
| ログオン/ログオフ | 特殊なログオン | 成功 |
| ポリシーの変更 | 認証ポリシーの変更 | 成功、失敗 |
| 特権の使用 | 機密性の高い特権の使用 | 成功、失敗 |
2. イベントログの最大サイズ設定
デフォルトのログサイズは小さいため、重要なイベントが上書きされる可能性があります:
| ログ名 | デフォルトサイズ | 推奨サイズ |
|---|---|---|
| Security | 20MB | 4GB以上 |
| System | 20MB | 1GB以上 |
| Application | 20MB | 1GB以上 |
PowerShellでの設定確認:
# セキュリティログの設定を確認
Get-WinEvent -ListLog Security | Select-Object LogName, MaximumSizeInBytes, LogMode
3. 重要な監視対象イベントID
特に注目すべきセキュリティイベントID:
| イベントID | 説明 | 重要度 |
|---|---|---|
| 4720 | ユーザーアカウントが作成された | 高 |
| 4726 | ユーザーアカウントが削除された | 高 |
| 4728 | セキュリティが有効なグローバルグループにメンバーが追加された | 高 |
| 4732 | セキュリティが有効なローカルグループにメンバーが追加された | 高 |
| 4740 | ユーザーアカウントがロックアウトされた | 中 |
| 4625 | アカウントがログオンに失敗した | 中 |
| 4648 | 明示的な資格情報を使用してログオンが試行された | 中 |
| 4672 | 特権が新しいログオンに割り当てられた | 高 |
| 4768 | Kerberos認証チケット(TGT)が要求された | 低 |
| 4769 | Kerberosサービスチケットが要求された | 低 |
監視体制の構築
1. SIEM(Security Information and Event Management)の活用
大量のログを効率的に分析するには、SIEMツールの導入が効果的です:
- 商用製品:Splunk、Microsoft Sentinel、IBM QRadar
- オープンソース:Elastic Stack(ELK)、Wazuh、Graylog
2. アラートルールの設定例
以下のようなルールを設定して、重要なイベントを即座に検知します:
ルール例1:Domain Adminsグループへのメンバー追加
条件:イベントID 4728 かつ グループ名に"Domain Admins"を含む
アクション:即座にメール通知
ルール例2:短時間での大量ログオン失敗
条件:イベントID 4625 が 同一ソースから5分間に10回以上
アクション:アラート生成
ルール例3:営業時間外の特権アカウント使用
条件:イベントID 4672 かつ 時間が22:00〜06:00
アクション:翌営業日に確認リストへ追加
実務ポイント:すべてのログを同じレベルで監視しようとすると、「アラート疲れ」を起こします。重要度に応じた段階的な対応フローを設計することが重要です。
よくある質問(FAQ)
Q1:AD監査の頻度はどのくらいが適切ですか?
A1:監査項目によって推奨頻度は異なります。以下を目安にしてください:
| 監査項目 | 推奨頻度 | 理由 |
|---|---|---|
| 特権アカウントの棚卸し | 月次 | 変更頻度は低いが、影響が大きいため |
| 休眠アカウントの検出 | 月次〜四半期 | 人事異動のサイクルに合わせる |
| パスワードポリシーの確認 | 四半期〜年次 | 頻繁な変更は想定されない |
| GPO設定の確認 | 四半期〜年次 | 変更時のレビューと定期確認 |
| 監査ログの確認 | 日次〜週次 | 継続的な監視が重要 |
また、以下のタイミングでは臨時の監査を実施することをお勧めします:
- システム管理者の退職・異動時
- セキュリティインシデント発生後
- 大規模なシステム変更の前後
- 外部監査・内部監査の前
Q2:監査ツールは何を使えばよいですか?
A2:目的と予算に応じて、以下のツールを検討してください:
無料・標準ツール:
- PowerShell + AD Module:基本的な情報収集に最適。本記事で紹介したスクリプトはすべて標準機能で実行可能
- イベントビューアー:ログの確認・分析
- PingCastle(無料版あり):ADのセキュリティ評価に特化した優れたツール。スコアリング機能付き
- Purple Knight(無料):Semperis社が提供するADセキュリティ評価ツール
商用ツール:
- Microsoft Defender for Identity:クラウドベースのAD監視・脅威検知
- Netwrix Auditor:変更監査に強み
- Quest Change Auditor:リアルタイム監視機能が充実
- Tenable.ad(旧Alsid):AD専門のセキュリティ評価
選定のポイント:
- まずは無料ツールで現状把握を行う
- 継続的な監視が必要な場合は商用ツールを検討
- 既存のセキュリティ投資(SIEMなど)との連携を考慮
Q3:監査で問題が見つかった場合、どのように報告・改善すればよいですか?
A3:以下のステップで進めることをお勧めします:
Step 1:リスク評価
発見された問題について、以下の観点で評価します:
- 影響度: 問題が顕在化した場合、どの程度の被害が発生するか(情報漏洩リスク、業務停止リスクなど)
- 発生可能性:現在の環境で実際に問題が起きる可能性はどの程度か
- 対応の緊急度:即時対応が必要か、計画的に対応できるか
| リスクレベル | 基準 | 対応期限の目安 |
|---|---|---|
| 高 | 影響度・発生可能性ともに高い | 発見後1週間以内 |
| 中 | どちらか一方が高い | 発見後1ヶ月以内 |
| 低 | 影響度・発生可能性ともに低い | 次回定期メンテナンス時 |
Step 2:改善提案の作成
単に「問題があります」と報告するだけでは、担当部門は何をすればよいかわかりません。以下の形式で改善提案を作成しましょう。
Step 3:経営層・管理職への報告
技術的な詳細が伝わりにくい相手には、ビジネスインパクトを中心に説明することが効果的です。
- ❌「Domain Adminsに不要なアカウントが5件あります」
- ✅「会社の全システムに管理者アクセスできるアカウントのうち、退職者のものが5件残っており、悪用された場合は全社のデータが危険にさらされます」
Step 4:改善状況のフォローアップ
報告して終わりにせず、改善の実施状況を追跡します。進捗管理表を作成し、次回監査時に改善が完了しているかを必ず確認しましょう。
まとめ
本記事では、Active Directory監査で最初に押さえるべき5つのチェックポイントを解説しました。
| # | チェックポイント | 主なリスク |
|---|---|---|
| ① | 特権アカウントの棚卸し | ドメイン全体の乗っ取り |
| ② | 休眠・不要アカウントの検出 | 不正アクセスの踏み台 |
| ③ | パスワードポリシーの確認 | 認証突破・総当たり攻撃 |
| ④ | グループポリシーのセキュリティ設定 | 設定ミスによる権限昇格 |
| ⑤ | 監査ログの設定と監視体制 | インシデントの見逃し・証跡不備 |
Active Directory監査は、一度実施して終わりではありません。人事異動、システム変更、新たな脅威の登場などに合わせて、継続的に実施することが重要です。まずは本記事で紹介したPowerShellコマンドを使って、自組織のAD環境の現状を把握するところから始めてみてください。
IT監査の現場では「問題がないことを証明する」のではなく、「問題を見つけて改善につなげる」姿勢が大切です。本記事がその第一歩として役立てば幸いです。
IT監査 セキュリティ