「パスワード有効期限＝90日」が常識だった時代は終わりました。NISTの最新版（SP 800‑63B‑4）やCIS Controlsは、定期的な強制変更をやめ、長さ・禁止リスト・MFA・リスクベース制御へ軸足を移しています。本記事は、CISA・CIS・NISTに沿って「パスワード無期限（期限なし）」を安全に採用するための実務ガイドです。Microsoft Entra ID（旧Azure AD）での設定手順・運用チェックリスト・社内規程サンプルまで、貼り付けて使える形でまとめました。
質問の要点
パスワードに有効期限を設けず「無期限」にしたい。その場合に必要な追加のセキュリティ対策（ガードレール／補完統制）と、CISA・CIS・NIST（SP 800‑63B）に整合した設計・運用の実務上の勘所は何か。
結論：「期限なし」はガードレールとセットで成立する（パスワード単体に依存しない）
結論から言うと、期限なし自体は推奨可能です。ただし必須の前提は、パスワード単体に依存しない設計に切り替えること。NIST SP 800‑63B‑4は「パスワードの定期変更を要求しない。侵害の兆候がある場合のみ変更を強制する」「長さを重視し、複雑性の細かい強制は行わない」「禁止リスト（漏えい済／よくある／推測されやすい）との照合」を明確に規定しています。単要素として使うなら最小15文字、MFAと併用なら最小8文字を許容、かつ「ヒントや秘密の質問の禁止」なども必須です。
基準の根拠（要点だけ）：NIST / CIS / CISA
- NIST SP 800‑63B‑4（2025年7月最終版）：
「パスワードの定期的な強制変更はしない（侵害時のみ強制）」「禁止リストとの照合」「ASCII/Unicode/スペース許容」「複雑性の細分（文字種ミックス等）を課さない」「ヒント/KBA（秘密の質問）禁止」を明記。単要素利用は15文字以上、MFA前提なら8文字以上。 - CIS Controls v8：
アカウント管理（Control 5）とアクセス制御（Control 6）でMFAの広範適用（外部公開アプリ、リモートアクセス、管理者アクセス）とユニークなパスワード、休眠アカウントの無効化、中央集権的なアカウント管理を要求。 - CISA：
「フィッシング耐性MFA（FIDO2/WebAuthnやPKI）が最も強固（ゴールドスタンダード）」とするファクトシートを公開し、段階的な移行を推奨。
「期限なし」運用の8つの設計原則（推奨アーキテクチャ）
1. 全社MFAの徹底 ― できれば「フィッシング耐性MFA」
標準ユーザーを含む全アカウントにMFAを必須化し、可能な限りFIDO2/パスキー、Windows Hello for Business、証明書ベースなどのフィッシング耐性MFAを優先します。CISAのガイダンスは、フィッシング耐性要素（FIDO2/PKI）を最も強力な選択肢として提示しています。
Entra IDでは、パスキー（FIDO2）を認証方法ポリシーで有効化し、必要に応じてAuthentication strengthsでパスキー必須を強制する設計が可能です。
2. 強固なパスワード方針（長さ＋禁止リスト、KBA禁止）
- 長さ重視：単要素で使うパスワードは15文字以上、MFA併用なら8文字以上（NIST）。
ASCII/Unicode/スペースを許容し、複雑性の細かい強制は行わない。 - 禁止パスワード（ブロックリスト）との照合：
過去漏えい・辞書語・自社に関係する語（社名、サービス名、年度等）を含めて拒否。Entra IDのグローバル＋カスタム禁止リストを使用。 - パスワードヒント／秘密の質問（KBA）は禁止（NIST）。
3. 漏えい・不正利用の検知と自動対処（Identity Protection＋CA）
資格情報漏えい・不審サインイン・異常行動を検知したら、自動でパスワード変更を強制またはブロック／追加認証。Entra ID Protectionのユーザーリスク／サインインリスクポリシーで、「リスク時はMFA／安全なパスワード変更を必須」に設定します。
4. 最小特権と一時昇格（JIT）＋分離端末（PAW）
管理者ロールの常設付与をやめ、必要時だけ短時間付与（PIM）。特権操作はPrivileged Access Workstation（PAW）等の分離端末で実施して攻撃面を縮小します。
5. パスワードレス（パスキー等）への段階的移行
FIDO2/パスキーやWindows Hello for Businessを有効化して、「パスワードに戻らない」運用へ段階的にシフトします。Windows Hello for BusinessはEntra IDネイティブのフィッシング耐性FIDO2プラットフォーム認証として機能します。
6. 条件付きアクセスとデバイス準拠、レガシー認証の遮断
- リスク高サインインはブロック／MFA追加。
- 準拠デバイス・既知ネットワークのみ許可などのアクセス制御。
- レガシー認証の遮断（Basic/IMAP/POP/SMTP AUTH等）は必須。Exchange OnlineではBasic認証が既に廃止されており、Conditional Accessでもプロトコル単位でブロック可能。
7. ログ・監査・模擬演習（フィッシング訓練含む）
サインイン・監査ログをSIEMに集約し、しきい値アラートや自動応答を運用。四半期～半期で方針やルールを見直し、フィッシング訓練でユーザー行動の改善を継続します。
8. アカウント・ライフサイクル管理とSSPR
- 休眠アカウントの自動無効化、退職・異動時の即時停止（CIS Control 5：Account Management）。
- SSPRは安全な登録（MFAと同時登録）と二次要素の棚卸しをセットに。Entra IDのCombined registrationでMFA/SSPRの一元登録・強い再認証を使います。
NISTとCISの要件を“読む”ための早見表
| テーマ | NIST SP 800‑63B‑4（要点） | CIS Controls v8（要点） |
|---|---|---|
| パスワード長 | 単要素で使用：15文字以上。MFA併用：8文字以上を許容。 | 「ユニークなパスワード」を要求。実装ガイダンスではMFA併用時8文字/非MFA時14文字の目安が掲示。 |
| 複雑性 | 細かい構成ルール（大文字・記号の義務等）は不要。ASCII/Unicode/スペース許容。 | ― |
| 禁止リスト | 漏えい・辞書・推測されやすい語のブロックリスト必須。 | ―（実装上は推奨。Entra Password Protectionで実現可能） |
| 定期変更 | 定期的な強制変更は不可。侵害の証拠がある場合のみ強制変更。 | ― |
| MFA | 強固な認証要素の適用（文書全体）。 | 外部公開アプリ・リモートアクセス・管理者アクセスのMFA必須。 |
| 秘密の質問 | ヒント/KBAは禁止。 | ― |
Microsoft Entra IDでの実装チェックリスト
- 条件付きアクセス：リスク高サインインはブロック/追加MFA。レガシー認証クライアントは一括遮断。
- Password Protection：グローバル＋カスタム禁止パスワードを適用（自社ワード・年度等）。
- Identity Protection：ユーザー/サインインリスクポリシーで安全なパスワード変更またはブロックを自動化。
- 認証方法ポリシー：FIDO2/パスキー/Windows Helloを有効化し、必要に応じてAuthentication strengthsで必須化。
- PIM（JIT）：管理者ロールは一時昇格に限定。
- レガシー認証遮断：IMAP/POP/SMTP AUTH/BASIC等は完全遮断（Exchange Onlineは既に廃止済み）。
- SSPR：Combined registrationでMFAと同時登録。登録・変更時の強い再認証を有効化。
- PAW：特権作業は分離端末からのみ。
Entra ID：設定ナビ（どこで何を触る？）
| 設定/目的 | 場所（ポータル） | ポイント |
|---|---|---|
| レガシー認証遮断 | Entra ID > セキュリティ > 条件付きアクセス > クライアントアプリ | 「その他のクライアント」「レガシー認証クライアント」を除外／ブロック。必要に応じて段階導入。 |
| 禁止パスワード | Entra ID > セキュリティ > 認証方法 > Password protection | カスタム禁止語は最大1,000語。自社名・部門名・季節・年度などを「語幹」で登録。 |
| リスクベース制御 | Entra ID > Identity Protection > ポリシー | ユーザーリスク/サインインリスクに応じてMFA/パスワード変更/ブロックを自動適用。 |
| パスキー（FIDO2） | Entra ID > セキュリティ > 認証方法 | 認証方法ポリシーでFIDO2/パスキーを許可し、Authentication strengthsで強制。 |
| SSPR＋MFA一元登録 | Entra ID > セキュリティ情報（Combined registration） | 登録/変更時に強い再認証を要求。 |
| JIT（PIM） | Entra ID > ID ガバナンス > Privileged Identity Management | 管理者ロールは「対象候補（Eligible）」のみ付与し、必要時に短時間有効化。 |
運用でハマりやすい点と対処
- 「長寿命の資格情報」リスク：期限なしは、漏えい時の影響が長引く。
→ 漏えい検知→自動強制変更、MFA、トークン失効で即時遮断。 - レガシープロトコル：IMAP/POP/SMTP AUTH、BASIC等はMFAを回避する抜け道。
→ 全面遮断＋代替手段の整備を先に。 - 監査・規制対応：業務/規制でパスワード期限が必要なケース。
→ 特権・共有・対外接続アカウントのみ期限ありなどの例外設計（CIS Control 6のMFA要件で補強）。 - ユーザー負担：過度な複雑性や頻繁な変更は逆効果（メモ・再利用を誘発）。
→ 長さ重視＋禁止リストに統一。ヒントやKBAは禁止。
期待できる効果（メリット）
- 期限切れ対応が消え、ユーザー体験・生産性が向上。
- ヘルプデスクのパスワードリセット件数が減少（SSPR・Combined登録で自助化）。
- 実害の多いフィッシング・再利用・漏えいに、MFAとリスクベース制御で実効防御。
監査・KPIテンプレート（例）
| KPI | 定義 | 目標 |
|---|---|---|
| MFA適用率 | 全アカウントのうちMFA必須の割合 | ≧ 99% |
| フィッシング耐性MFA比率 | MFA利用のうちFIDO2/WHfB/証明書 | 段階目標（四半期ごとに+20%） |
| レガシー認証遮断率 | レガシー認証イベントのゼロ化 | 100%遮断（移行計画に従い期日厳守） |
| 禁止リスト検知率 | 変更時に拒否した弱いパスの割合 | モニタ指標（上昇時は教育実施） |
| 自動リメディエーション率 | リスク検知→自動強制変更/ブロックの実施率 | ≧ 95%（手動対応の最小化） |
現場で使える具体策（抜粋レシピ）
- 「禁止パスワード」を作る：社名、プロダクト名、拠点名、年度（
2025、R07など）、季節、イベント名を語幹で登録（例：<Brand>、<Dept>、<City>）。 - 「MFA登録の安全化」：Combined registrationを有効化し、登録/変更は強い再認証・社内ネットワークのみ許可（CA）。
- 「不正ログインの足止め」：サインインリスク高＝MFA要求→失敗継続でブロック、ユーザーリスク高＝安全なパスワード変更必須。
- 「特権はJIT＋PAW」：PIMで有効化申請＆承認フロー、PAWで管理作業を分離。
規制・例外設計の考え方
一部規制や委託先要件で期限設定が必要な場合、対象を限定（例：特権・共有・外部公開・B2B・高リスク連携）し、MFA/リスク制御/ログ監査を重ねて補強します。CIS Control 6（MFAの義務化対象）と整合する例外管理台帳を整備しましょう。
なぜ「期限なし」が現代的なのか（補足の根拠）
- NISTは明確に方針転換：「定期変更はしない」「ブロックリスト」「長さ重視」へ。
- Microsoftのベースライン：Windows 10/Serverのセキュリティベースラインからパスワード有効期限の推奨を撤廃。有効期限は「時代遅れで価値が低い」ため。
- CIS Controls：MFA適用対象を具体的に規定（外部公開/リモート/特権）。
- CISA：フィッシング耐性MFA（FIDO2/PKI）をゴールドスタンダードとして提示。
社内ポリシー記述サンプル（コピペ可）
（認証方針）
1) ユーザー用パスワードは原則として有効期限を設定しない。既知の漏えい、侵害の疑い、職務変更等の事由が発生した場合に限り、直ちに変更を義務付ける。
2) 全アカウントに多要素認証を適用する。可能な限りフィッシング耐性要素（FIDO2/パスキー、証明書、Windows Hello for Business）を用いる。
3) パスワードは長さを重視し、禁止パスワードとの照合を行う。ヒントおよび秘密の質問は使用しない。
4) レガシー認証（Basic/IMAP/POP/SMTP AUTH等）は不許可とする。アクセス制御は条件付きアクセスおよびデバイス準拠で実施する。
5) 特権操作は常設付与を避け、Just-In-Timeで短時間付与（PIM）し、分離端末（PAW）から実行する。
6) サインイン／監査ログを常時監視し、四半期以上の頻度で見直しと教育（含むフィッシング訓練）を行う。よくある反論への短答
- 「期限なしは怖い」：期限は“時間”の対策であって、侵害の有無を見ていません。NISTは侵害の兆候時に即変更を要求し、日々の検知・阻止（MFA／リスク制御）を重視しています。
- 「複雑性ルールは？」：記号や大文字の強制は予測可能な“定型”を生み逆効果。長さ＋禁止リストでより強固にできます。
- 「利用者が困る」：むしろ期限廃止で混乱が減り、SSPRとMFAの統合登録で自己解決率が上がります。
参考：NIST 800‑63（Rev.4）への移行注記
本記事で参照したSP 800‑63B‑4（2025年7月）はRev.4の最終版です。画面仕様や用語がRev.3系の記事と一部異なる点に注意してください（Rev.4はパスキー等の同期型認証を正式に取り込み）。
まとめ
「期限なし」＝放置ではありません。MFA（できればフィッシング耐性）・長さ重視＋禁止リスト・レガシー遮断・リスク自動対処・JIT特権・ログ監視・SSPR安全登録というガードレールが揃って初めて、「期限なし」は現代的で実効性の高い方針になります。NIST/CIS/CISAの基準を土台に、Microsoft Entra IDの機能で愚直に実装していきましょう。
コメント