はじめに
Linuxエンジニアなら /etc/login.defs や pam_pwquality.conf で最小文字数や有効期限を設定した経験があるでしょう。Windows（Active Directory）でも同様の設定が可能ですが、現在はNIST（米国国立標準技術研究所）やIPA（情報処理推進機構）のガイドラインにより、その「常識」が劇的に変化しています。
「パスワードは3ヶ月に一度変更し、英大文字・小文字・数字・記号をすべて混ぜること」
かつて鉄則だったこのルールは、現在では 「逆にセキュリティを低下させる」 として推奨されていません。
無理な定期変更は「Password01!」を「Password02!」にするだけの推測しやすい運用を招き、複雑すぎるルールは付箋へのメモを誘発するからです。今回は、モダンなWindows環境で設定すべき「攻めのパスワードポリシー」を解説します。
1. 新旧ガイドラインの比較（NIST SP 800-63B基準）
Linuxの chage -M 90（最大有効日数の設定）のような運用は、現代のベストプラクティスではどう変わったのでしょうか。
| 設定項目 | 従来の常識（レガシー） | 現在の基準（NIST/IPA） |
|---|---|---|
| 定期変更 | 30〜90日ごとに強制変更 | 原則不要（侵害が疑われる場合のみ変更） |
| 最小文字数 | 8文字以上 | 12〜15文字以上（長さを優先）※1 |
| 複雑さ（文字種の強制） | 記号・数字の混在を強制 | 強制しない（パスフレーズを推奨） |
| パスワード履歴 | 過去5回分は使用不可 | 漏洩リスト・辞書との照合を優先 |
| 多要素認証（MFA） | 補助的なもの | 必須（パスワード単体に頼らない設計） |
※1 NIST SP 800-63B（2024年改定版）では最低8文字以上かつ最大64文字以上を許容することを要件とし、15文字以上を推奨しています。IPAの「パスワードの長さ」に関する基準でも同様に長さを重視する方向性を示しています。ガイドラインはバージョンによって更新されるため、常に一次ソースを参照してください。
- NIST SP 800-63B: https://pages.nist.gov/800-63-4/
- IPA「パスワードの長さや複雑さに関する指針」: https://www.ipa.go.jp/security/
なぜ定期変更が「逆効果」なのか？
マイクロソフト自身も2019年にWindows Server / Windows 10のセキュリティベースラインから定期パスワード変更の要件を削除しています。ユーザーは変更を強制されると最小限の変更（末尾の数字をインクリメントなど）で対応する傾向があり、実質的な安全性向上につながらないことが研究で示されているためです。
2. Active Directory での設定：FGPP の活用
Windowsのパスワードポリシーには大きな制約がありました。Windows Server 2003以前は「1つのドメインに1つのポリシー」しか設定できなかったのです。現在は FGPP（Fine-Grained Password Policies：細粒度のパスワードポリシー） を使うことで、グループや特定のユーザーごとにポリシーを使い分けられます。
前提： FGPPはWindows Server 2008以降のドメイン機能レベルが必要です。
設定例（Tier別ポリシー）
| 対象 | 最小文字数 | 有効期間 | MFA |
|---|---|---|---|
| 一般社員（Tier 2） | 12文字以上 | 無期限 | 必須 |
| 特権管理者（Tier 0/1） | 15文字以上 | 無期限 | 必須（FIDO2/スマートカード推奨） |
FGPPは「セキュリティグループ」または「特定のユーザーアカウント」に対して適用できます（OUには直接リンクできないことに注意）。Linuxでいうところの、特定のグループだけに pam_pwquality の条件を厳しくする設定に近い運用が可能です。
# FGPPを新規作成する例（管理者向けポリシー）
New-ADFineGrainedPasswordPolicy `
-Name "TierZeroAdminPolicy" `
-Precedence 10 `
-MinPasswordLength 15 `
-PasswordHistoryCount 24 `
-MaxPasswordAge "0" `
-MinPasswordAge "1" `
-ComplexityEnabled $false `
-ReversibleEncryptionEnabled $false
# セキュリティグループに適用
Add-ADFineGrainedPasswordPolicySubject `
-Identity "TierZeroAdminPolicy" `
-Subjects "TierZeroAdmins"
注意： ComplexityEnabled $false は文字種混在の「強制」を外すだけです。「複雑なパスワードを禁止する」わけではありません。長さ（MinPasswordLength）とMFAでカバーする設計に移行します。
3. 「禁止パスワード」をどう防ぐか？（Azure AD Password Protection）
Windows標準のGPOだけでは、「Password123」や「会社名+2026」といった、ルールには適合しているが推測されやすいパスワードを防ぐのが困難です。
そこで現代のWindowsセキュリティでは、Microsoft Entra ID Password Protection（旧称：Azure AD Password Protection）for Windows Server AD を導入します。
- グローバル禁止リスト： Microsoftが管理する、世界中で漏洩が確認されているパスワードを自動でブロック。
- カスタム禁止リスト： 「社名」「製品名」「地名」など、自社固有のキーワードを含むパスワードを禁止。オンプレミスのADに対しても適用可能。
注意： オンプレミスADへの適用にはMicrosoft Entra IDライセンス（旧Azure AD P1以上）が必要です。クラウドのみの環境（Entra ID）では追加コストなしで利用可能。
これはLinuxでいうところの cracklib の辞書ファイルを、クラウドの最新知見で常にアップデートし続けるような仕組みです。
4. 実践：現在の設定をPowerShellで確認する
自分のドメインやマシンのパスワード設定がどうなっているか、以下のコマンドで確認してみましょう。
# ドメインのデフォルトパスワードポリシーを確認
Get-ADDefaultDomainPasswordPolicy
# 特定ユーザーに実際に適用されているポリシーを確認（FGPPが優先されているか含む）
Get-ADUserResultantPasswordPolicy -Identity "username"
# FGPP一覧を表示
Get-ADFineGrainedPasswordPolicy -Filter *
# ローカルマシンのポリシーを確認（非ドメイン環境）
net accounts
Get-ADDefaultDomainPasswordPolicy の出力で確認すべき主なパラメーター：
| パラメーター | 意味 | 見直しの目安 |
|---|---|---|
MaxPasswordAge |
パスワード有効期間 | 365日以上 or 0（無期限）に |
MinPasswordLength |
最小文字数 | 12以上に |
PasswordHistoryCount |
履歴で使用不可にする件数 | 24以上を推奨 |
ComplexityEnabled |
文字種の複雑さ強制 | 長さで担保するなら$falseも選択肢 |
おわりに
第1部では、Windowsセキュリティの「基礎・認証基盤」を駆け足で見てきました。Linuxとの違いはあれど、「アイデンティティ（ID）を守る」 という目的は共通していることがお分かりいただけたかと思います。
次回からは 第2部：ネットワーク・通信制御編 に突入します。
まずは 第11回「Windows Firewall —— iptables派に贈る『詳細設定』の攻略法」 です。
「WindowsのFWは使いにくい」という先入観を、エンジニアらしいCLI操作で打破していきましょう。
今回の「エンジニアの知恵」
パスワードを長くする（パスフレーズ化する）ことは、ハッシュの「エントロピー」を高める最も効果的な方法です。P@ssw0rd123!（11文字）よりも I-love-CentOS-and-Windows-2026（31文字）の方が、計算上は圧倒的に解読が困難になります。
さらに進んだセキュリティを目指すなら、パスワードそのものへの依存を減らす FIDO2/パスキー（Passkey） による「パスワードレス認証」への移行が、現在のWindows環境では現実的な選択肢になっています。Windows Helloと組み合わせることで、フィッシング耐性の高い認証基盤を構築できます。