本記事には広告(アフィリエイトリンク)が含まれます。

WindowsServer 2025 総合ガイド 第11回

WindowsServer 2025 総合ガイド 第11回
セキュリティ設定の基礎 ― ローカルセキュリティポリシー

第10回では、Windows Serverの役割と機能の管理、Windows Updateの運用、そしてタスクスケジューラによる定期タスクの自動化を学びました。基礎編の最終回となる第11回では、サーバーを安全に運用するための土台となる「セキュリティ設定」について学びます。パスワードポリシーやアカウントロックアウト、監査ポリシーの設定方法、そしてセキュリティイベントログの分析方法を実践的に習得していきましょう。セキュリティの基礎を理解することは、あらゆるサーバー運用の前提となる重要なスキルです。

11.1 この記事で学ぶこと

  • セキュリティポリシーの概念と、ローカルセキュリティポリシーの役割を理解する
  • パスワードポリシーとアカウントロックアウトポリシーを確認・設定できる
  • secedit コマンドと auditpol コマンドを使って、CLIからセキュリティ設定を管理できる
  • 監査ポリシーの基本を理解し、セキュリティイベントログを分析できる
  • 主要なセキュリティイベントID(4624、4625、4720、4726 等)を理解する
  • Microsoft Defender Antivirusの状態をPowerShellで確認できる

11.2 前提条件

  • 第10回完了(役割・機能の管理とタスクスケジューラを理解している状態)
  • Windows Server 2025にリモートデスクトップ接続できる状態
  • PowerShell 7.4を管理者として起動できる状態
  • ローカルユーザーとグループの基礎を理解している状態(第3回の内容)

11.3 セキュリティポリシーとは

セキュリティポリシーとは、サーバーやネットワークにおけるセキュリティ上のルールを体系的に定義したものです。「誰がログインできるか」「パスワードはどのくらいの強度が必要か」「どのような操作を記録するか」といった設定を、個別に管理するのではなく、ポリシー(方針)として一元的に管理します。

11.3.1 セキュリティポリシーの役割

セキュリティポリシーには、大きく分けて以下の2つの役割があります。

  • システム全体のセキュリティルール定義: パスワードの強度、アカウントのロックアウト条件、監査対象のイベントなど、セキュリティに関するルールをシステム全体に対して統一的に適用します。管理者が個別のユーザーやサービスごとに設定する必要がないため、設定漏れを防ぐことができます。
  • 一貫したセキュリティ設定の適用: ポリシーとして定義することで、サーバーの再構築時やユーザーの追加時にも同じセキュリティ基準が自動的に適用されます。手動で設定する場合に起こりがちな「このサーバーだけ設定が違う」という状況を防ぎます。

11.3.2 ローカルセキュリティポリシーとグループポリシー

Windows Serverのセキュリティポリシーには、「ローカルセキュリティポリシー」と「グループポリシー」の2種類があります。本シリーズの学習環境はドメインに参加していないスタンドアロン環境のため、ローカルセキュリティポリシーを使用します。

項目 ローカルセキュリティポリシー グループポリシー
適用範囲 そのサーバー1台のみ ドメイン内の複数のサーバー・PC
管理ツール secpol.msc グループポリシー管理コンソール(GPMC)
使用環境 スタンドアロン環境、ワークグループ Active Directoryドメイン環境
優先度 グループポリシーが存在する場合は上書きされる ローカルポリシーより優先される

補足: 実務でActive Directory環境を運用する場合は、グループポリシーでセキュリティ設定を一括管理するのが一般的です。ただし、ローカルセキュリティポリシーの仕組みを理解しておくことは、グループポリシーを学ぶ際にも役立ちます。本記事では、スタンドアロン環境でのローカルセキュリティポリシーの設定方法を学びます。

11.3.3 secpol.msc の概要

secpol.msc は、ローカルセキュリティポリシーを管理するためのGUIツールです。Desktop Experience がインストールされたWindows Server 2025では、このツールを使ってセキュリティポリシーを視覚的に確認・変更できます。

起動方法は以下のとおりです。

[実行環境: PowerShell 7.4 (管理者)]

# ローカルセキュリティポリシーを起動
secpol.msc

secpol.msc を開くと、左ペインに以下のカテゴリが表示されます。

カテゴリ 内容
アカウントポリシー パスワードポリシー、アカウントロックアウトポリシー
ローカルポリシー 監査ポリシー、ユーザー権利の割り当て、セキュリティオプション
セキュリティが強化されたWindows Defenderファイアウォール ファイアウォール規則(第8回で学習済み)
公開キーのポリシー 証明書関連のポリシー
ソフトウェアの制限のポリシー 実行可能なソフトウェアの制限
IPセキュリティポリシー IPsec関連のポリシー

本記事では、この中から「アカウントポリシー」と「ローカルポリシー」を中心に学びます。なお、本シリーズの方針としてCLI操作を主軸としますが、GUIでの対応箇所も併せて示します。

11.4 アカウントポリシー

アカウントポリシーは、ユーザーアカウントのパスワードとロックアウトに関するルールを定義します。不正アクセスを防ぐための最も基本的な防御線です。

11.4.1 パスワードポリシー

パスワードポリシーは、ユーザーが設定するパスワードに対して、最低限の強度基準を強制するための設定です。

まず、現在のパスワードポリシーの状態を確認しましょう。secedit コマンドを使って、現在のセキュリティ設定をファイルにエクスポートし、その内容を確認します。

[実行環境: PowerShell 7.4 (管理者)]

# 現在のセキュリティ設定をエクスポート
secedit /export /cfg C:\Temp\secpol_export.inf

# エクスポートされたファイルからパスワードポリシー部分を確認
Get-Content -Path C:\Temp\secpol_export.inf |
    Select-String -Pattern "^(Minimum|Maximum|Password|LockoutBad|ResetLockout|LockoutDuration)"

実行結果の例:

MinimumPasswordAge = 0
MaximumPasswordAge = 42
MinimumPasswordLength = 0
PasswordComplexity = 0
PasswordHistorySize = 0

各設定項目の意味は以下のとおりです。

設定項目 INFファイルのキー デフォルト値 説明
パスワードの履歴を記録する PasswordHistorySize 0 過去に使用したパスワードの再使用を禁止する数。0 = 制限なし
パスワードの有効期間 MaximumPasswordAge 42日 パスワードを変更するまでの最大日数
パスワードの変更禁止期間 MinimumPasswordAge 0日 パスワード変更後、次に変更できるようになるまでの最小日数
パスワードの長さ MinimumPasswordLength 0文字 パスワードに必要な最小文字数。0 = 制限なし
複雑さの要件 PasswordComplexity 0(無効) 大文字・小文字・数字・記号のうち3種類以上を要求するか

GUIでの確認方法:secpol.msc → アカウントポリシー → パスワードのポリシー

Microsoftの最新パスワードポリシーガイドライン

パスワードポリシーを設定する前に、Microsoftおよび米国国立標準技術研究所(NIST)の最新ガイドラインを確認しておくことが重要です。従来の「定期的にパスワードを変更させる」「複雑さを強制する」というアプローチは見直されており、現在は以下の方針が推奨されています。

項目 従来の推奨 現在の推奨(Microsoft / NIST)
パスワードの長さ 8文字以上 14文字以上(長いほど効果的)
複雑さの要件 大文字・小文字・数字・記号を強制 強制しない(予測可能なパターンを助長するため)
パスワードの有効期間 60〜90日で強制変更 定期変更を強制しない(侵害の証拠がある場合のみ変更)
多要素認証(MFA) 推奨 強く推奨(パスワードのみの認証は不十分)
よく使われるパスワードの禁止 言及なし 「password」「123456」などの一般的なパスワードを禁止

補足: 定期的なパスワード変更を強制すると、ユーザーは覚えやすいパスワードを使い回したり、「Spring2025!」→「Summer2025!」のような予測可能なパターンで変更したりする傾向があります。Microsoftの分析によると、この行為はセキュリティを弱体化させるため、現在では定期変更の強制は推奨されていません。ただし、ローカルセキュリティポリシーの設定としては定期変更の機能が残っており、組織のポリシーに応じて使い分ける必要があります。

パスワードポリシーの推奨設定例

以下は、現在のベストプラクティスに基づいた推奨設定例です。組織のセキュリティ要件に応じて調整してください。

設定項目 推奨値 理由
パスワードの長さ 14文字以上 CIS(Center for Internet Security)ベンチマーク推奨
複雑さの要件 有効 ローカル環境ではMFA導入が難しいため、複雑さで補完
パスワードの履歴 24 過去24回分のパスワード再使用を防止
パスワードの有効期間 0(無期限)または 365日 最新ガイドラインに基づく。MFAがない場合は365日を検討
パスワードの変更禁止期間 1日 パスワード履歴をすり抜けるための連続変更を防止

11.4.2 アカウントロックアウトポリシー

アカウントロックアウトポリシーは、パスワードの入力を一定回数間違えた場合に、そのアカウントを一時的にロックする(ログインできなくする)設定です。ブルートフォース攻撃(総当たり攻撃)への基本的な防御手段となります。

現在のロックアウトポリシーを確認するには、先ほどエクスポートした設定ファイルを参照します。

[実行環境: PowerShell 7.4 (管理者)]

# エクスポート済みのファイルからロックアウトポリシーを確認
Get-Content -Path C:\Temp\secpol_export.inf |
    Select-String -Pattern "^(LockoutBad|ResetLockout|LockoutDuration)"

実行結果の例:

LockoutBadCount = 0
ResetLockoutCount = 30
LockoutDuration = 30
設定項目 INFファイルのキー デフォルト値 説明
アカウントのロックアウトのしきい値 LockoutBadCount 0(無効) ロックアウトが発動するまでの失敗回数。0 = ロックアウト無効
ロックアウト期間 LockoutDuration 30分 ロックアウトされたアカウントが自動解除されるまでの時間(分)
ロックアウトカウンターのリセット ResetLockoutCount 30分 失敗回数のカウンターが0にリセットされるまでの時間(分)

GUIでの確認方法:secpol.msc → アカウントポリシー → アカウントロックアウトのポリシー

警告: ロックアウトポリシーの設定は慎重に行ってください。しきい値を低く設定しすぎると、正規ユーザーが少しのタイプミスでロックアウトされてしまい、業務に支障をきたす可能性があります。特にリモート環境では、自分自身がロックアウトされるとサーバーに接続できなくなる危険があります。ConoHa VPSの場合はコンソール機能から直接アクセスできますが、設定変更前にロックアウトされた場合の復旧手段を確認しておきましょう。

アカウントロックアウトポリシーの推奨設定例

設定項目 推奨値 理由
ロックアウトのしきい値 5回 ブルートフォース攻撃を抑止しつつ、正規ユーザーの利便性を維持
ロックアウト期間 30分 自動解除により管理者の手動対応を削減
カウンターのリセット 30分 ロックアウト期間以下に設定する必要がある

11.5 ポリシーの確認と設定(CLI)

セキュリティポリシーをCLIで管理するには、secedit コマンドを使用します。secedit は、セキュリティ設定のエクスポート、インポート、適用を行うコマンドラインツールです。PowerShellネイティブのコマンドレットではありませんが、Windows Server 2025でも引き続きサポートされており、ローカルセキュリティポリシーの管理に広く使用されています。

11.5.1 secedit コマンドの基本操作

現在の設定のエクスポート

現在のセキュリティ設定をINFファイル(セキュリティテンプレート)にエクスポートします。

[実行環境: PowerShell 7.4 (管理者)]

# 作業ディレクトリの作成
New-Item -Path C:\SecurityConfig -ItemType Directory -Force

# 現在のセキュリティ設定を全カテゴリでエクスポート
secedit /export /cfg C:\SecurityConfig\current_policy.inf

実行結果の例:

タスクは正常に完了しました。

エクスポートされたINFファイルの内容を確認しましょう。

# エクスポートされたファイルの内容を確認
Get-Content -Path C:\SecurityConfig\current_policy.inf

INFファイルにはセクション単位でセキュリティ設定が記載されています。主なセクションは以下のとおりです。

セクション 内容
[System Access] パスワードポリシー、アカウントロックアウトポリシー
[Event Audit] 基本監査ポリシー
[Privilege Rights] ユーザー権利の割り当て
[Registry Values] セキュリティオプション(レジストリベースの設定)
[Service General Setting] サービスのセキュリティ設定

特定のカテゴリのみエクスポート

/areas パラメータを使って、特定のカテゴリだけをエクスポートすることもできます。

[実行環境: PowerShell 7.4 (管理者)]

# アカウントポリシーとセキュリティオプションのみエクスポート
secedit /export /cfg C:\SecurityConfig\securitypolicy.inf /areas SECURITYPOLICY

# ユーザー権利の割り当てのみエクスポート
secedit /export /cfg C:\SecurityConfig\userrights.inf /areas USER_RIGHTS

/areas パラメータに指定できるカテゴリは以下のとおりです。

カテゴリ名 対象
SECURITYPOLICY アカウントポリシー、監査ポリシー、イベントログ設定、セキュリティオプション
USER_RIGHTS ユーザー権利の割り当て
GROUP_MGMT 制限されたグループの設定
REGKEYS レジストリのアクセス許可
FILESTORE ファイルシステムのアクセス許可
SERVICES システムサービスの設定

設定の変更と適用

secedit でセキュリティポリシーを変更するには、エクスポートしたINFファイルを編集し、それをインポート(適用)するという手順を踏みます。

警告: セキュリティポリシーの変更はシステム全体に影響します。変更前に必ず現在の設定をバックアップし、変更内容を十分に理解してから適用してください。特にパスワードポリシーやロックアウトポリシーの変更は、自分自身のログインにも影響する可能性があります。

以下の例では、パスワードポリシーを推奨設定に変更します。

手順1: 現在の設定をバックアップ

[実行環境: PowerShell 7.4 (管理者)]

# バックアップ用ディレクトリの作成
New-Item -Path C:\SecurityConfig\Backup -ItemType Directory -Force

# 現在の設定をバックアップ
secedit /export /cfg C:\SecurityConfig\Backup\policy_backup.inf

手順2: 適用する設定ファイルの作成

パスワードポリシーを変更するためのINFファイルを作成します。

# パスワードポリシー設定用のINFファイルを作成
$policyContent = @"
[Unicode]
Unicode=yes

[System Access]
MinimumPasswordAge = 1
MaximumPasswordAge = 0
MinimumPasswordLength = 14
PasswordComplexity = 1
PasswordHistorySize = 24
LockoutBadCount = 5
ResetLockoutCount = 30
LockoutDuration = 30

[Version]
signature="`$CHICAGO`$"
Revision=1
"@

# ファイルに出力
$policyContent | Out-File -FilePath C:\SecurityConfig\password_policy.inf -Encoding Unicode

注意: INFファイルはUnicodeエンコーディングで保存する必要があります。-Encoding Unicode を指定してください。また、MaximumPasswordAge = 0 はパスワードの有効期限を無期限にする設定です。組織のポリシーで定期変更が必要な場合は、適切な日数(例: 365)に変更してください。

手順3: 設定ファイルの検証

[実行環境: PowerShell 7.4 (管理者)]

# 設定ファイルの構文を検証(値の正しさではなく、ファイル構造を検証)
secedit /validate C:\SecurityConfig\password_policy.inf

実行結果の例:

ファイルは有効です。

手順4: 設定の適用

[実行環境: PowerShell 7.4 (管理者)]

# セキュリティポリシーを適用
secedit /configure /db C:\SecurityConfig\secpol.sdb /cfg C:\SecurityConfig\password_policy.inf /overwrite /areas SECURITYPOLICY /log C:\SecurityConfig\apply_log.log

実行結果の例:

タスクは正常に完了しました。
詳細については、ログ C:\SecurityConfig\apply_log.log を参照してください。

このコマンドの各パラメータの意味は以下のとおりです。

パラメータ 説明
/configure 設定を適用するサブコマンド
/db セキュリティデータベースファイル(中間ファイルとして必要)
/cfg 適用する設定が記述されたINFファイル
/overwrite データベースを上書きする(既存データを破棄)
/areas 適用するカテゴリの指定
/log ログファイルの出力先

手順5: 適用結果の確認

# 適用後の設定を確認
secedit /export /cfg C:\SecurityConfig\after_apply.inf /areas SECURITYPOLICY

# パスワードポリシーの設定値を確認
Get-Content -Path C:\SecurityConfig\after_apply.inf |
    Select-String -Pattern "^(Minimum|Maximum|Password|LockoutBad|ResetLockout|LockoutDuration)"

実行結果の例:

MinimumPasswordAge = 1
MaximumPasswordAge = 0
MinimumPasswordLength = 14
PasswordComplexity = 1
PasswordHistorySize = 24
LockoutBadCount = 5
ResetLockoutCount = 30
LockoutDuration = 30

11.5.2 セキュリティテンプレートの概念

上記で作成したINFファイルは「セキュリティテンプレート」と呼ばれます。セキュリティテンプレートは、セキュリティ設定を定義したテキストファイルで、以下のような用途に使います。

  • 設定のバックアップと復元: 現在の設定をエクスポートし、問題が発生した場合に復元できる
  • 設定の標準化: 複数のサーバーに同じセキュリティ設定を適用できる
  • 設定の比較: 異なるサーバー間のセキュリティ設定の差分を確認できる

Tips: セキュリティテンプレートの管理は、応用編で学ぶDSC v3の「構成ファイル」と概念が似ています。「あるべき状態を定義したファイルを作成し、それをシステムに適用する」というアプローチは、Infrastructure as Code(IaC)の基本的な考え方です。

設定をデフォルトに戻す方法

変更した設定をデフォルトに戻したい場合は、以下のコマンドを実行します。

[実行環境: PowerShell 7.4 (管理者)]

# デフォルトのセキュリティ設定に戻す
secedit /configure /cfg "$env:windir\inf\defltbase.inf" /db C:\SecurityConfig\defltbase.sdb /verbose

注意: この操作はセキュリティ設定をOSのデフォルト値にリセットします。カスタマイズした設定もすべてリセットされるため、実行前にバックアップを取っておいてください。

11.5.3 よくあるエラーと対処法

エラー 原因 対処法
「アクセスが拒否されました」 管理者権限で実行していない 管理者としてPowerShellを起動し直す
「構成ファイルが無効です」 INFファイルの構文エラー secedit /validate で構文を検証し、修正する
「データベースを作成できません」 出力先ディレクトリが存在しない 事前にディレクトリを作成する
設定が反映されない エンコーディングの問題 INFファイルがUnicodeで保存されているか確認する

11.6 ローカルポリシー

ローカルポリシーは、「ユーザー権利の割り当て」と「セキュリティオプション」の2つのサブカテゴリで構成されています。ここでは、実務で特に重要な設定項目を紹介します。

11.6.1 ユーザー権利の割り当て

ユーザー権利の割り当ては、特定の操作を実行する権限をユーザーやグループに付与する設定です。先ほどエクスポートしたINFファイルの [Privilege Rights] セクションに記載されています。

[実行環境: PowerShell 7.4 (管理者)]

# ユーザー権利の割り当てをエクスポートして確認
secedit /export /cfg C:\SecurityConfig\userrights.inf /areas USER_RIGHTS

# 内容を確認(Privilege Rights セクションを抽出)
Get-Content -Path C:\SecurityConfig\userrights.inf |
    Where-Object { $_ -match "^Se" }

実行結果の例(一部抜粋):

SeInteractiveLogonRight = *S-1-5-32-544,*S-1-5-32-545
SeRemoteInteractiveLogonRight = *S-1-5-32-544,*S-1-5-32-555
SeShutdownPrivilege = *S-1-5-32-544
SeBackupPrivilege = *S-1-5-32-544,*S-1-5-32-551
SeRestorePrivilege = *S-1-5-32-544,*S-1-5-32-551

出力に含まれる *S-1-5-32-544 のような文字列はSID(セキュリティ識別子)です。主要なSIDとグループ名の対応は以下のとおりです。

SID グループ名
S-1-5-32-544 Administrators
S-1-5-32-545 Users
S-1-5-32-551 Backup Operators
S-1-5-32-555 Remote Desktop Users

主要なユーザー権利とその意味は以下のとおりです。

権利名(内部名) 説明 デフォルトの付与先
SeInteractiveLogonRight ローカルログオンの許可 Administrators, Users
SeRemoteInteractiveLogonRight リモートデスクトップでのログオン許可 Administrators, Remote Desktop Users
SeShutdownPrivilege システムのシャットダウン権限 Administrators
SeBackupPrivilege ファイルとディレクトリのバックアップ権限 Administrators, Backup Operators
SeServiceLogonRight サービスとしてログオンする権限 (サービスアカウントに付与)

GUIでの確認方法:secpol.msc → ローカルポリシー → ユーザー権利の割り当て

11.6.2 セキュリティオプション

セキュリティオプションは、システム全体のセキュリティ動作を制御する詳細な設定項目です。ここでは、初学者が知っておくべき主要な設定項目を紹介します。

管理者アカウントの名前変更

Windows Serverでは、デフォルトの管理者アカウント名「Administrator」がそのまま使用されていることが多いですが、セキュリティの観点から名前を変更することが推奨されます。攻撃者は「Administrator」というアカウント名を前提としたブルートフォース攻撃を行うことがあるためです。

[実行環境: PowerShell 7.4 (管理者)]

# 現在の管理者アカウント名を確認
Get-LocalUser | Where-Object { $_.SID -like "*-500" } |
    Select-Object -Property Name, SID, Enabled

実行結果の例:

Name          SID                                           Enabled
----          ---                                           -------
Administrator S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-500    True
# 管理者アカウントの名前を変更
Rename-LocalUser -Name "Administrator" -NewName "ServerAdmin"

# 変更を確認
Get-LocalUser | Where-Object { $_.SID -like "*-500" } |
    Select-Object -Property Name, SID, Enabled

実行結果の例:

Name        SID                                           Enabled
----        ---                                           -------
ServerAdmin S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-500    True

注意: 管理者アカウント名を変更した場合、次回のログイン時には新しい名前を使用する必要があります。変更した名前を忘れないように記録しておいてください。なお、SID(セキュリティ識別子)はアカウント名を変更しても変わりません。SID「*-500」は常にビルトインの管理者アカウントを指します。

GUIでの確認方法:secpol.msc → ローカルポリシー → セキュリティオプション → 「アカウント: Administrator アカウント名の変更」

ゲストアカウントの状態

ゲストアカウントは、Windows Serverにデフォルトで存在する制限付きのアカウントです。セキュリティ上の理由から、無効化された状態を維持することが推奨されます。

[実行環境: PowerShell 7.4 (管理者)]

# ゲストアカウントの状態を確認
Get-LocalUser -Name "Guest" | Select-Object -Property Name, Enabled, Description

実行結果の例:

Name  Enabled Description
----  ------- -----------
Guest   False Built-in account for guest access to the computer/domain

EnabledFalse であれば、ゲストアカウントは無効化されています。有効になっている場合は以下のコマンドで無効化してください。

# ゲストアカウントを無効化
Disable-LocalUser -Name "Guest"

UAC(ユーザーアカウント制御)設定

UAC(User Account Control)は、管理者権限が必要な操作を実行する際に確認ダイアログを表示する機能です。意図しない管理者権限での操作や、マルウェアによる権限昇格を防ぐ効果があります。

UACの状態はレジストリから確認できます。

[実行環境: PowerShell 7.4 (管理者)]

# UACの設定を確認
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" |
    Select-Object -Property EnableLUA, ConsentPromptBehaviorAdmin, PromptOnSecureDesktop

実行結果の例:

EnableLUA                    : 1
ConsentPromptBehaviorAdmin   : 5
PromptOnSecureDesktop        : 1
プロパティ 説明
EnableLUA 1 = 有効 UACの有効/無効
ConsentPromptBehaviorAdmin 5 = 同意を求める 管理者に対するプロンプトの動作
PromptOnSecureDesktop 1 = 有効 セキュアデスクトップでプロンプトを表示するか

GUIでの確認方法:secpol.msc → ローカルポリシー → セキュリティオプション → 「ユーザーアカウント制御:」で始まる項目

推奨: サーバー環境ではUACを無効化したくなることがありますが、セキュリティの観点から有効のままにしておくことを推奨します。自動化スクリプトを実行する場合は、UACを無効化するのではなく、「管理者として実行」でスクリプトを起動する方法を使いましょう。

11.7 監査ポリシーの基本

監査ポリシーは、「システム上で何が起こったかを記録する」ための設定です。セキュリティインシデントの検知、原因究明、コンプライアンス要件への対応において欠かせない機能です。

11.7.1 監査とは

監査(Audit)とは、セキュリティに関連するイベント(ログオン、ファイルアクセス、ポリシー変更など)を記録する仕組みです。監査を有効にすることで、以下のことが可能になります。

  • セキュリティイベントの記録: 誰がいつサーバーにログオンしたか、どのファイルにアクセスしたかを追跡できる
  • 不正アクセスの検知: 認証の失敗や不審な操作を検出し、攻撃の兆候を早期に発見できる
  • コンプライアンス要件への対応: PCI DSS、ISO 27001などのセキュリティ規格で要求される監査ログを生成できる
  • トラブルシューティング: 問題発生時に、何が起こったかを時系列で追跡できる

11.7.2 基本監査ポリシーと詳細監査ポリシー

Windows Serverには、2種類の監査ポリシーがあります。

種類 設定方法 特徴
基本監査ポリシー secpol.msc → ローカルポリシー → 監査ポリシー 9つの大カテゴリで設定。シンプルだが粒度が粗い
詳細監査ポリシー(Advanced Audit Policy) auditpol コマンド、GPO 50以上のサブカテゴリで細かく設定可能。推奨

重要: 基本監査ポリシーと詳細監査ポリシーは同時に使用しないでください。両方を設定すると予期しない動作が発生する可能性があります。本記事では、より細かい制御が可能な詳細監査ポリシー(auditpol コマンド)の使用を推奨します。

11.7.3 現在の監査ポリシーの確認

auditpol コマンドを使って、現在の詳細監査ポリシーの設定状況を確認します。

[実行環境: PowerShell 7.4 (管理者)]

# すべての監査ポリシーカテゴリの現在の設定を表示
auditpol /get /category:*

実行結果の例(一部抜粋):

System audit policy
Category/Subcategory                      Setting
System
  Security State Change                   No Auditing
  Security System Extension               No Auditing
  System Integrity                        Success and Failure
  IPsec Driver                            No Auditing
  Other System Events                     No Auditing
Logon/Logoff
  Logon                                   Success
  Logoff                                  Success
  Account Lockout                         Success
  IPsec Main Mode                         No Auditing
  Special Logon                           Success
Account Management
  User Account Management                 No Auditing
  Computer Account Management             No Auditing
  Security Group Management               No Auditing

各サブカテゴリの「Setting」列には、以下の値が表示されます。

設定値 意味
No Auditing 監査を行わない
Success 成功した操作のみ記録
Failure 失敗した操作のみ記録
Success and Failure 成功と失敗の両方を記録

11.7.4 監査ポリシーの設定

実務で特に重要な監査カテゴリを有効化しましょう。以下は、サーバー運用において最低限有効にすべき推奨設定です。

[実行環境: PowerShell 7.4 (管理者)]

# ログオン/ログオフの監査(成功と失敗)
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable /failure:enable

# アカウントロックアウトの監査(成功と失敗)
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable

# ユーザーアカウント管理の監査(成功と失敗)
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable

# セキュリティグループ管理の監査(成功と失敗)
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable

# セキュリティ状態の変更の監査(成功と失敗)
auditpol /set /subcategory:"Security State Change" /success:enable /failure:enable

# 監査ポリシーの変更の監査(成功と失敗)
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable

# 認証ポリシーの変更の監査(成功と失敗)
auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:enable

各コマンドの実行結果の例:

コマンドは正常に実行されました。

設定後、変更が反映されたことを確認します。

# 設定結果を確認(ログオン/ログオフカテゴリ)
auditpol /get /category:"Logon/Logoff"

実行結果の例:

System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logon                                   Success and Failure
  Logoff                                  Success and Failure
  Account Lockout                         Success and Failure
  IPsec Main Mode                         No Auditing
  IPsec Quick Mode                        No Auditing
  IPsec Extended Mode                     No Auditing
  Special Logon                           Success
  Other Logon/Logoff Events               No Auditing
  Network Policy Server                   No Auditing

注意 — ログ増加とディスク容量への影響: 監査ポリシーを有効にすると、セキュリティイベントログにイベントが記録されるようになります。監査対象が多いほど大量のログが生成されるため、ディスク容量を圧迫する可能性があります。特に「オブジェクトアクセス」の監査は大量のイベントが生成されるため、必要な場合のみ有効にしてください。セキュリティイベントログのサイズは、イベントビューアーのログプロパティまたは以下のコマンドで確認・変更できます。

[実行環境: PowerShell 7.4 (管理者)]

# セキュリティログの現在の設定を確認
Get-WinEvent -ListLog Security |
    Select-Object -Property LogName, MaximumSizeInBytes,
        @{Name='MaxSizeMB'; Expression={[math]::Round($_.MaximumSizeInBytes / 1MB, 2)}},
        RecordCount, LogMode

実行結果の例:

LogName              : Security
MaximumSizeInBytes   : 20971520
MaxSizeMB            : 20
RecordCount          : 1523
LogMode              : Circular
# セキュリティログの最大サイズを拡張する場合(例: 100MBに変更)
wevtutil sl Security /ms:104857600

11.7.5 監査ポリシーのバックアップと復元

設定した監査ポリシーは、auditpol のバックアップ機能を使って保存・復元できます。

[実行環境: PowerShell 7.4 (管理者)]

# 現在の監査ポリシーをバックアップ
auditpol /backup /file:C:\SecurityConfig\auditpol_backup.csv

# バックアップからの復元が必要な場合
# auditpol /restore /file:C:\SecurityConfig\auditpol_backup.csv

11.8 セキュリティログの確認

監査ポリシーを有効にすると、セキュリティに関連するイベントがWindowsのセキュリティイベントログに記録されます。このログを分析することで、不正アクセスの試行や不審な操作を検出できます。

11.8.1 セキュリティイベントログの基本

セキュリティイベントログは、Get-WinEvent コマンドレットで取得できます。

[実行環境: PowerShell 7.4 (管理者)]

# セキュリティログの最新10件を取得
Get-WinEvent -LogName Security -MaxEvents 10 |
    Select-Object -Property TimeCreated, Id, LevelDisplayName, Message |
    Format-List

実行結果の例:

TimeCreated      : 2026/02/08 14:32:15
Id               : 4624
LevelDisplayName : Information
Message          : アカウントが正常にログオンしました。
                   ...

TimeCreated      : 2026/02/08 14:32:15
Id               : 4672
LevelDisplayName : Information
Message          : 新しいログオンに特権が割り当てられました。
                   ...

11.8.2 主要なセキュリティイベントID

セキュリティイベントログを分析する際に、以下のイベントIDを知っておくことが重要です。これらのIDはWindows Server 2025でも変更されておらず、Windows Serverシリーズ共通で使用されています。

イベントID カテゴリ 説明 注目度
4624 ログオン アカウントが正常にログオンしました ★★
4625 ログオン アカウントがログオンに失敗しました ★★★
4634 ログオフ アカウントがログオフしました
4647 ログオフ ユーザーがログオフを開始しました
4720 アカウント管理 ユーザーアカウントが作成されました ★★★
4722 アカウント管理 ユーザーアカウントが有効化されました ★★
4725 アカウント管理 ユーザーアカウントが無効化されました ★★
4726 アカウント管理 ユーザーアカウントが削除されました ★★★
4732 グループ管理 セキュリティグループにメンバーが追加されました ★★★
4733 グループ管理 セキュリティグループからメンバーが削除されました ★★
4740 アカウント管理 ユーザーアカウントがロックアウトされました ★★★
4776 認証 資格情報の検証が試行されました ★★

注目度の目安:★★★ = 要注意(不正アクセスの兆候の可能性)、★★ = 定期的に確認、★ = 参考情報

11.8.3 特定のイベントを検索する

実務では、特定のイベントIDに絞り込んでログを検索することが多いです。Get-WinEvent-FilterHashtable パラメータを使うと、効率的に検索できます。

ログオン失敗イベントの検索

[実行環境: PowerShell 7.4 (管理者)]

# ログオン失敗イベント(ID: 4625)を検索
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
} -MaxEvents 10 -ErrorAction SilentlyContinue |
    Select-Object -Property TimeCreated, Id,
        @{Name='Account'; Expression={$_.Properties[5].Value}},
        @{Name='SourceIP'; Expression={$_.Properties[19].Value}},
        @{Name='FailureReason'; Expression={$_.Properties[8].Value}} |
    Format-Table -AutoSize

実行結果の例:

TimeCreated              Id Account       SourceIP      FailureReason
-----------              -- -------       --------      -------------
2026/02/08 14:15:30    4625 Administrator 192.168.1.100 %%2313
2026/02/08 13:42:10    4625 admin         203.0.113.50  %%2313
2026/02/08 12:30:55    4625 test          198.51.100.25 %%2313

読み方のポイント: ログオン失敗イベントの FailureReason に含まれる %%2313 は「不明なユーザー名またはパスワードの誤り」を意味します。短時間に同じIPアドレスから多数の失敗イベントが記録されている場合、ブルートフォース攻撃の可能性があります。

ユーザーアカウントの作成・削除イベントの検索

# ユーザー作成(4720)と削除(4726)のイベントを検索
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4720, 4726
} -MaxEvents 20 -ErrorAction SilentlyContinue |
    Select-Object -Property TimeCreated, Id,
        @{Name='TargetAccount'; Expression={$_.Properties[0].Value}},
        @{Name='PerformedBy'; Expression={$_.Properties[4].Value}} |
    Format-Table -AutoSize

特定の時間範囲でのイベント検索

# 過去24時間のログオン成功イベントを検索
$startTime = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624
    StartTime = $startTime
} -ErrorAction SilentlyContinue |
    Select-Object -Property TimeCreated,
        @{Name='Account'; Expression={$_.Properties[5].Value}},
        @{Name='LogonType'; Expression={$_.Properties[8].Value}},
        @{Name='SourceIP'; Expression={$_.Properties[18].Value}} |
    Format-Table -AutoSize

ログオンタイプの値は以下の意味を持ちます。

ログオンタイプ 説明
2 対話型ログオン(コンソールからのログイン)
3 ネットワークログオン(ファイル共有アクセスなど)
5 サービスログオン
7 画面ロック解除
10 リモートデスクトップ(RDP)ログオン

11.8.4 不正アクセス試行の検出

実務では、不正アクセスの兆候を定期的にチェックすることが重要です。以下のスクリプトは、直近のログオン失敗を送信元IPアドレスごとに集計し、疑わしいアクセスを検出します。

[実行環境: PowerShell 7.4 (管理者)]

# 過去24時間のログオン失敗をIPアドレスごとに集計
$startTime = (Get-Date).AddHours(-24)

$failedLogons = Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = $startTime
} -ErrorAction SilentlyContinue

if ($failedLogons) {
    Write-Host "=== 過去24時間のログオン失敗 集計レポート ===" -ForegroundColor Yellow
    Write-Host "集計期間: $($startTime.ToString('yyyy/MM/dd HH:mm')) ~ $(Get-Date -Format 'yyyy/MM/dd HH:mm')" -ForegroundColor Yellow
    Write-Host ""

    # IPアドレスごとに集計
    $failedLogons |
        ForEach-Object {
            [PSCustomObject]@{
                SourceIP = $_.Properties[19].Value
                Account  = $_.Properties[5].Value
                Time     = $_.TimeCreated
            }
        } |
        Group-Object -Property SourceIP |
        Sort-Object -Property Count -Descending |
        Select-Object -Property Count,
            @{Name='SourceIP'; Expression={$_.Name}},
            @{Name='Accounts'; Expression={($_.Group.Account | Sort-Object -Unique) -join ', '}} |
        Format-Table -AutoSize

    Write-Host "合計失敗回数: $($failedLogons.Count)" -ForegroundColor Red
} else {
    Write-Host "過去24時間にログオン失敗イベントはありませんでした。" -ForegroundColor Green
}

実行結果の例:

=== 過去24時間のログオン失敗 集計レポート ===
集計期間: 2026/02/07 14:30 ~ 2026/02/08 14:30

Count SourceIP       Accounts
----- --------       --------
   45 203.0.113.50   admin, administrator, root
   12 198.51.100.25  test, user1
    3 192.168.1.100  Administrator

合計失敗回数: 60

分析のポイント: 同じIPアドレスから多数のログオン失敗が記録されている場合は、ブルートフォース攻撃の可能性があります。特に「admin」「root」「test」など、一般的なアカウント名で試行されている場合は攻撃の兆候として注視してください。このような場合は、ファイアウォールで該当IPアドレスからのアクセスをブロックすることも検討しましょう(第8回で学んだ New-NetFirewallRule を使用)。

11.9 セキュリティ設定のベストプラクティス

ここまで学んだ内容を踏まえ、Windows Serverを安全に運用するための基本的なベストプラクティスをまとめます。

11.9.1 最小権限の原則

最小権限の原則(Principle of Least Privilege)とは、「ユーザーやプロセスに対して、業務に必要な最低限の権限だけを付与する」という考え方です。

  • 日常の管理作業には、Administratorsグループのアカウントではなく、必要な権限だけを持つ管理用アカウントを使用する
  • サービスアカウントには最小限の権限のみを付与する
  • 不要になったユーザーアカウントは速やかに無効化または削除する

11.9.2 不要なサービスの無効化

使用していないサービスが動作していると、攻撃対象となる面(アタックサーフェス)が広がります。第5回で学んだ Get-ServiceSet-Service を使って、不要なサービスを特定し、無効化しましょう。

11.9.3 パスワード管理の実践

  • 本記事で設定したパスワードポリシーを維持する
  • 複数のサーバーで同じパスワードを使い回さない
  • 侵害の疑いがある場合は速やかにパスワードを変更する
  • 可能であれば多要素認証(MFA)を導入する

11.9.4 監査ログの定期確認

  • セキュリティイベントログを定期的に(最低でも週1回)確認する
  • 第10回で学んだタスクスケジューラを使って、ログオン失敗の集計レポートを自動的に生成・保存する仕組みを構築する
  • セキュリティログのサイズと保存期間を適切に設定する

11.9.5 セキュリティ更新の適用

  • 第10回で学んだWindows Updateの管理手法を使い、セキュリティ更新プログラムを定期的に適用する
  • 緊急のセキュリティパッチは速やかに適用する
  • 更新適用前にバックアップを取得し、問題が発生した場合に復旧できるようにする

11.10 Microsoft Defender Antivirusの確認

Windows Server 2025には、Microsoft Defender Antivirus(旧称: Windows Defender)が標準で搭載されています。サーバーのセキュリティ設定の一環として、Defenderの状態を確認し、適切に動作していることを確認しましょう。

11.10.1 Defenderの状態確認

Get-MpComputerStatus コマンドレットを使って、Microsoft Defender Antivirusの状態を確認します。

注意: Get-MpComputerStatus はWindows PowerShell 5.1の Defender モジュールに含まれるコマンドレットです。PowerShell 7.4からも互換性レイヤーを通じて使用できますが、一部の環境では Windows PowerShell 5.1(powershell.exe)で実行する必要がある場合があります。

[実行環境: PowerShell 7.4 (管理者)]

# Microsoft Defender Antivirusの状態を確認
Get-MpComputerStatus |
    Select-Object -Property AMRunningMode, AMServiceEnabled,
        AntivirusEnabled, RealTimeProtectionEnabled,
        BehaviorMonitorEnabled, IoavProtectionEnabled,
        AntivirusSignatureLastUpdated, AntivirusSignatureVersion

実行結果の例:

AMRunningMode                : Normal
AMServiceEnabled             : True
AntivirusEnabled             : True
RealTimeProtectionEnabled    : True
BehaviorMonitorEnabled       : True
IoavProtectionEnabled        : True
AntivirusSignatureLastUpdated : 2026/02/08 6:15:30
AntivirusSignatureVersion    : 1.XXX.XXXX.0

各プロパティの意味は以下のとおりです。

プロパティ 望ましい値 説明
AMRunningMode Normal 動作モード(Normal = アクティブに保護中)
AMServiceEnabled True マルウェア対策サービスが有効
AntivirusEnabled True ウイルス対策機能が有効
RealTimeProtectionEnabled True リアルタイム保護が有効
BehaviorMonitorEnabled True 動作の監視が有効
IoavProtectionEnabled True ダウンロードファイルのスキャンが有効
AntivirusSignatureLastUpdated 直近の日時 ウイルス定義ファイルの最終更新日時

11.10.2 ウイルス定義の更新

ウイルス定義ファイルが古い場合は、手動で更新できます。

[実行環境: PowerShell 7.4 (管理者)]

# ウイルス定義ファイルを更新
Update-MpSignature

# 更新後の状態を確認
Get-MpComputerStatus |
    Select-Object -Property AntivirusSignatureLastUpdated, AntivirusSignatureVersion

11.10.3 スキャンの実行

手動でウイルススキャンを実行する方法です。

[実行環境: PowerShell 7.4 (管理者)]

# クイックスキャンの実行
Start-MpScan -ScanType QuickScan

# フルスキャンの実行(時間がかかります)
# Start-MpScan -ScanType FullScan

# 特定のフォルダをスキャン
Start-MpScan -ScanType CustomScan -ScanPath "C:\Temp"
# スキャン結果の確認(検出された脅威の一覧)
Get-MpThreatDetection | Select-Object -Property DetectionID, 
    @{Name='ThreatName'; Expression={(Get-MpThreat -ThreatID $_.ThreatID).ThreatName}},
    InitialDetectionTime, ActionSuccess

11.10.4 Defender設定の確認

Defenderの詳細設定は Get-MpPreference で確認できます。

# 除外設定やスキャンスケジュールの確認
Get-MpPreference |
    Select-Object -Property ExclusionPath, ExclusionExtension,
        ScanScheduleDay, ScanScheduleTime, DisableRealtimeMonitoring

推奨: サーバー環境では、パフォーマンスに影響する場合にデータベースファイルやログファイルのディレクトリを除外設定に追加することがあります。ただし、除外設定はセキュリティリスクを伴うため、必要最小限に留めてください。

11.11 まとめ

第11回では、Windows Serverのセキュリティ設定の基礎として、ローカルセキュリティポリシーの管理方法を学びました。以下に、本記事で学んだ内容を整理します。

  • セキュリティポリシーの概念
    • セキュリティポリシーは、システム全体のセキュリティルールを一元管理する仕組み
    • スタンドアロン環境ではローカルセキュリティポリシー(secpol.msc)を使用
  • アカウントポリシー
    • パスワードポリシーでは、最新のガイドラインに基づき14文字以上の長さと履歴管理を推奨
    • アカウントロックアウトポリシーはブルートフォース攻撃への基本的な防御策
    • ロックアウト設定は自分自身のアクセスにも影響するため、慎重に設定する
  • CLIによるポリシー管理
    • secedit コマンドでセキュリティ設定のエクスポート・インポート・適用が可能
    • INFファイル(セキュリティテンプレート)で設定を管理・再利用できる
  • ローカルポリシー
    • ユーザー権利の割り当てでログオン権限やシャットダウン権限を制御
    • 管理者アカウントの名前変更やゲストアカウントの無効化が推奨される
  • 監査ポリシー
    • auditpol コマンドで詳細な監査ポリシーを管理
    • ログオンイベント、アカウント管理、ポリシー変更の監査を有効にすることを推奨
    • 監査ログの増加によるディスク容量への影響に注意する
  • セキュリティイベントログ
    • 主要なイベントID(4624、4625、4720、4726 等)を理解し、Get-WinEvent で検索・分析できる
    • ログオン失敗の集計による不正アクセス検出が実務で重要
  • Microsoft Defender Antivirus
    • Get-MpComputerStatus でDefenderの状態を確認
    • ウイルス定義の更新とスキャン実行をPowerShellで管理できる

以上で基礎編(第1回〜第11回)が完了しました。入門編で環境を構築し、基礎編でサーバー管理の基本スキルを習得してきました。ファイルシステム管理、ユーザー管理、スクリプティング、サービス管理、ネットワーク設定、ファイアウォール、イベントログ、リモート管理、役割と機能の管理、そしてセキュリティ設定と、Windows Serverの運用に必要な一通りの知識を身につけることができました。

次回からの応用編では、これらの手動設定をDSC v3(Desired State Configuration version 3)で自動化する方法を学びます。「あるべき状態をコードで定義し、自動的にその状態を維持する」という Infrastructure as Code(IaC)の世界に踏み出しましょう。

11.12 次回予告

第12回では「DSC v3 入門 ― 宣言的構成管理の世界へ」と題して、応用編の最初のテーマに取り組みます。Infrastructure as Code(IaC)の概念、DSCの「宣言的」と「命令的」の違い、DSC v3のインストール方法、そして基本コマンド(dsc resource listdsc resource get)の使い方を学びます。基礎編で手動で行ってきたサーバー設定を、コードで自動化する第一歩を踏み出しましょう。

11.13 参考リンク