ハイブリッド環境（オンプレミス Active Directory と Microsoft Entra ID の併用）で定期的なパスワード変更を義務付けても、実際には「末尾の数字だけ変える」「1文字だけ変える」といった“形だけ更新”が起きがちです。本記事では、Entra ID のパスワード ハッシュ同期（PHS）の仕様上なぜそれを技術的に止められないのかを整理しつつ、現場で効果が出やすい代替策を具体的にまとめます。
「1文字だけ変える」パスワード変更が起きる背景
定期変更の運用を続けると、多くのユーザーは「覚えやすさ」「業務影響の少なさ」を優先し、次のようなパターンに収束しやすくなります。
- パスワード本体は固定で、末尾の年号や連番だけを更新する（例：2024→2025）
- 記号を 1 つだけ入れ替える、最後の 1 文字だけ変える
- 「前回と違う」条件を満たすためだけに最小限の変更をする
セキュリティ担当者の視点では「実質ほぼ同じでは？」と感じますが、これを“システムが自動判定して拒否できるか”は別問題です。結論から言うと、Entra ID / PHS の仕組みだけで「変更量（何文字変えたか）」を理由に拒否することはできません。
まず整理：ハイブリッド環境の「パスワードの正本」はどこか
ハイブリッド環境では、ユーザーがどこでパスワードを変更するか（どこが正本か）によって、適用されるポリシーと制御範囲が変わります。特に“同期ユーザー”か“クラウド専用ユーザー”かで話がズレやすいので、最初に押さえておきます。
| ユーザー種別 | パスワードの正本（主に管理される場所） | 主なパスワード変更経路 | 主に効くポリシー | PHS（パスワード ハッシュ同期）の位置づけ |
|---|---|---|---|---|
| 同期ユーザー（オンプレ AD 由来） | オンプレ AD | Ctrl+Alt+Del / AD ドメイン参加端末 / VPN / SSPR＋書き戻し（構成次第） | オンプレ AD のパスワードポリシー（ドメイン/FGPP 等） | オンプレで変更された結果を Entra ID に“反映するための同期機構” |
| クラウド専用ユーザー（Entra ID で作成） | Entra ID | Entra 管理ポータル / SSPR など | Entra ID 側のパスワードポリシー | 通常は関係しない（オンプレ正本がないため） |
今回の悩みは多くの場合、同期ユーザーで発生します。つまり「ユーザーがオンプレ AD で変更 → その結果が PHS で Entra ID に同期される」という流れです。このとき重要なのは、PHS は“ポリシーを強制する装置”ではなく、“結果を同期する装置”である点です。
パスワード ハッシュ同期（PHS）の役割と、ポリシーとの独立性
PHS（Password Hash Synchronization）は、オンプレ AD のパスワード変更結果を、Entra ID 側でも利用できるようにするための仕組みです（一般的には Microsoft Entra Connect Sync（旧 Azure AD Connect）を通じて動作します）。
PHS は「ハッシュの同期」であり、「パスワードの類似判定」ではない
PHS が扱うのは、あくまでパスワードそのもの（平文）ではなく、パスワードから生成されたハッシュ情報です。ここで大事なポイントは次のとおりです。
- ポリシー変更＝既存ハッシュの作り直しではない
- ポリシー変更＝既存パスワードの自動失効ではない
- ハッシュ同期の仕組みと、パスワードポリシー（長さ/複雑さ/履歴など）の“適用”は別レイヤー
- ユーザーが実際にパスワードを変更したタイミングでのみ、新しいパスワードに対応するハッシュが生成・反映される
つまり「ポリシーを厳しくしたから、今のパスワードも自動で NG にしてほしい」「過去パスワードとの“似ている度”を判定してほしい」といった期待は、PHS の役割の範囲外です。
なぜ「1文字だけ変更」でも“完全に別物”として扱われるのか
「1文字しか変えていないのに、どうして止められないの？」という疑問の核心は、ハッシュの性質にあります。
ハッシュは“雪崩効果”で、少しの違いでも全く別の値になる
一般的な暗号学的ハッシュ（パスワードハッシュも同様の考え方を前提に設計されます）は、入力が少し変わるだけで出力が大きく変化する性質（いわゆる雪崩効果）を持ちます。たとえば、次のようなケースを想像してください。
| 見た目の差 | パスワード（例） | 人間の感覚 | ハッシュの世界 |
|---|---|---|---|
| 末尾 1 文字だけ変更 | P@ssw0rd2025! → P@ssw0rd2025? | ほぼ同じ | 完全に別の値（別パスワード） |
| 年号だけ変更 | Company2024# → Company2025# | パターンが同じ | 完全に別の値（別パスワード） |
| 大幅に変更 | SpringCoffeeTrain! → 7&vQn…（全く別） | 別物 | もちろん別の値（別パスワード） |
このため、ハッシュ値だけを見ても「前回と似ている」かどうかは分かりません。似ている概念が存在しないというより、そもそも比較の材料がありません。
「じゃあ平文で比較すれば？」が成立しにくい理由
「変更時に平文が入力されるなら、前回の平文と比較して似ていたら拒否できるのでは？」と思うかもしれません。しかし、一般的に認証基盤は次のような設計思想で作られています。
- 平文パスワードは保存しない（保存した時点で事故の影響が壊滅的になる）
- 保存するのはハッシュ（またはそれに準ずる検証情報）だけ
- 「前回と一致しない」などの判定は、履歴（過去ハッシュ）との“完全一致”チェックで行う
- 「編集距離（何文字違うか）」のような類似判定は、一般的な標準機能としては提供されにくい
結果として、Entra ID / PHS の標準機能の範囲では「1文字だけ変えたから拒否」という制御は実装されていません。
結論：「何文字変えなければならない」は Entra ID / PHS では制御できない
要点を整理すると、次の結論になります。
- PHS はパスワードの“強さ”や“変更量”を評価する仕組みではない
- ハッシュは 1 文字違うだけで完全に別値になるため、「ほぼ同じ」を区別できない
- Entra ID / PHS の標準機能として「前回から何文字以上変更」ルールは提供されていない
つまり、「1文字だけ変更」を技術的にピンポイントでブロックするのではなく、別の角度から“形だけ更新が意味を持ちにくい状態”を作るのが現実的な戦い方です。
現実解：形だけ更新を“割に合わなくする”対策
「1文字変更」を直接止められない以上、狙うべきは次のどちらか（または両方）です。
- そもそも弱いパスワードに収束しない（長さ・辞書対策・再利用対策）
- パスワードが破られても守れる（MFA、条件付きアクセス、リスクベース）
ここからは、ハイブリッド環境で効きやすい順に、具体策を紹介します。
パスワードポリシーは「変更量」ではなく「長さ」と「再利用禁止」に寄せる
「複雑さ（大文字小文字/数字/記号）」は一定の効果がありますが、ユーザーが“覚え方”を工夫しない限り、結局「規則的な置換（a→@、i→1）」に寄りやすいのが難点です。形だけ更新を減らすには、長さ（文字数）と再利用禁止（履歴）、そしてすぐ変更し直せない（最短変更間隔）が効きます。
| 設定項目 | 狙い | おすすめの方向性（例） | 注意点 |
|---|---|---|---|
| 最小パスワード長 | 総当たり/推測耐性を上げる | 12文字以上（可能なら 14〜16 以上） | 既存文化との摩擦が出やすい。パスフレーズ推奨とセットにする |
| パスワード履歴 | 使い回しを防ぐ | 10〜24 など多め | 履歴だけだと「A→B→A」循環を狙われるため最短変更間隔も重要 |
| 最短変更間隔（Minimum password age） | 履歴回避の連続変更を防ぐ | 1日など（運用に合わせて） | ヘルプデスク運用（誤入力/ロック解除）と衝突しない値にする |
| 複雑さ要件 | 単純パターンを減らす | 有効のままでもよいが「長さ優先」で設計 | 複雑さだけ上げると“規則置換”に寄る |
ポイントは「1文字だけ変える」を止めるのではなく、1文字だけ変える程度では強度が上がりにくいルール設計にすることです。たとえば、最低 12 文字を要求し、履歴も長く、さらに最短変更間隔を設けると、ユーザーは“短期での小手先変更”がやりにくくなります。
「よくある弱いパスワード」をブロックする（辞書・漏えい対策）
形だけ更新の最大の問題は、“パターンが読める”ことです。攻撃者は「社名＋年号」「季節＋連番」といった候補を作りやすく、漏えい済みパスワード辞書とも組み合わせられます。
この対策として有効なのが、禁止パスワード（バンリスト）の考え方です。たとえば「Password」「P@ssw0rd」「Company2025」など、推測されやすい・辞書に載りやすいものを拒否します。
- クラウド側（Entra ID）では、弱いパスワードの利用を抑止する仕組みが用意されています。
- 同期ユーザー主体の環境では、オンプレ AD 側のパスワード検証で同様の発想を取り込めるように設計します。
ここでの狙いは「1文字変更」そのものではなく、1文字変更で生まれやすい“弱い系列”をまとめて排除することです。
MFA（多要素認証）と条件付きアクセスで、パスワード依存を下げる
現場の体感として、形だけ更新を“根絶”するのは難しいです。だからこそ、パスワードが突破されても侵入が成立しにくい設計を先に固めるのが効果的です。
- MFA を必須化（特に管理者・特権アカウントは最優先）
- 条件付きアクセスで、未知の場所・未知の端末・高リスクサインインをブロック/追加認証
- レガシー認証（基本認証など）を段階的に無効化し、回避経路を減らす
「1文字変更でもハッシュ的には別物」という現実を変えられないなら、侵害の成立条件を増やす（パスワード＋もう一つ）方が、運用上の費用対効果が高くなります。
可能なら「パスワード定期変更」自体を見直す（運用の最適化）
ここは組織ポリシー次第ですが、近年は「定期変更は、かえって弱いパスワードのパターン化を生む」という考え方も浸透しています。実際、形だけ更新が常態化しているなら、定期変更で得たいはずのセキュリティ効果が十分に出ていない可能性があります。
代替として検討されやすい方針は次のとおりです。
- 期限切れ強制を撤廃し、侵害が疑われる場合のみ変更
- その代わり、長いパスフレーズ＋MFA＋条件付きアクセスを必須化
- リスク検知（不審なサインイン、漏えいパスワードの疑い）をトリガーに追加対応
「定期変更を続ける」場合でも、少なくとも長さ・禁止パスワード・MFAの3点セットがないと、形だけ更新に負けやすくなります。
オンプレ AD 側でできること：同期ユーザーの“入口”を締める
同期ユーザーのパスワード強度は、基本的にオンプレ AD のポリシー設計で決まります。ここでは「導入しやすく効果が出る順」に並べます。
ドメインパスワードポリシーの見直し（基本）
- 最小パスワード長（長さ優先）
- パスワード履歴（再利用禁止）
- 最短変更間隔（履歴回避を抑止）
- アカウントロックアウト（総当たりの抑止）
ここでのコツは、「複雑さ」より「長さ」を主軸にすることです。複雑さを強くすると、ユーザーはルールを満たすために記号を 1 個足すだけ…になりがちで、結果として“規則的で推測しやすい系列”が量産されます。
Fine-Grained Password Policy（FGPP）で“守りたい層”を先に強化
全社一律で厳しくすると反発が強い場合、まずは優先順位を付けて段階導入するのが現実的です。
- 管理者・特権アカウント：最も厳しい長さ、履歴、ロックアウト
- 外部公開に近い業務（営業/カスタマー対応など）：MFA とセットで強化
- 一般ユーザー：教育・パスフレーズ推奨とセットで段階的に引き上げ
FGPP を使えば、部署や役割に応じた“落としどころ”を作りやすく、結果として組織としての到達点も上げやすくなります。
「履歴があるのに A→B→A で戻される」問題を潰す
パスワード履歴だけを増やしても、ユーザーが「A（普段使い）→B（一時的）→A（戻す）」のように回避するケースがあります。ここで効くのが最短変更間隔です。
たとえば最短変更間隔を 1 日にすると、短時間に何回も変えて履歴を“回転”させることが難しくなります。ヘルプデスクのリセット運用や、初回サインイン時変更のフローとぶつからないように、例外運用（管理者によるリセット時の扱い）を含めて設計してください。
Entra ID 側でできること：認証を強くする・リスクで止める
同期ユーザーであっても、クラウド利用が前提なら Entra ID 側の制御が効きます。特に「パスワードの強度」ではなく「侵入を成立させない」方向で強力です。
MFA 必須化の実務ポイント
- 全社一律が難しい場合でも、管理者・特権は最優先で必須化する
- 例外（ブレークグラス）アカウントを最小限にして、監査と保護を徹底する
- ユーザー体験を損ねないよう、信頼できる場所/端末では追加認証頻度を調整する（ただし緩めすぎない）
条件付きアクセスで「パスワードが合っても通さない」を作る
形だけ更新でも、パスワードが漏えいすれば攻撃者はログインを試みます。条件付きアクセスは、そこに“追加条件”を課せます。
- 国/地域、IP、デバイス準拠、アプリ、サインインリスクで制御
- 高リスク時はブロック、または MFA 強制
- 管理者操作や重要アプリはより厳しく
これにより「パスワードが同系列で推測されやすい」問題のダメージを、実害に繋がりにくくできます。
「1文字変更」対策としてよく検討される案と、可否の整理
現場でよく出るアイデアを「できる/できない」で整理します。これを見ると、議論が早く収束します。
| やりたいこと | 標準機能で実現 | 理由 | 代替案（現実解） |
|---|---|---|---|
| 前回から「N文字以上」変えないと拒否 | 不可 | PHS/ハッシュは類似度を扱わない。標準ポリシーに変更量判定がない | 最小長の引き上げ、履歴＋最短変更間隔、禁止パスワード |
| 末尾の年号だけ更新を禁止 | 基本的に不可 | “年号だけ”という意味判定を標準では行わない | 辞書対策（禁止語/社名/年度の禁止）、パスフレーズ推奨 |
| 過去のパスワードを再利用させない | 可 | 履歴（完全一致）で判定できる | 履歴を十分に取り、最短変更間隔で回避を防ぐ |
| 漏えい済み・推測されやすいパスワードを拒否 | 可（設計次第） | 禁止パスワード/弱いパスワードの検出で抑止できる | 禁止語の設計、導入範囲（オンプレ/クラウド）を整理する |
| パスワードが漏れてもログインさせない | 可 | MFA/条件付きアクセスで成立条件を増やせる | 優先順位を付けて段階導入（特権→重要アプリ→全社） |
運用で差が出る：ユーザー教育は「禁止」より「型」を与える
「1文字だけ変えるな」と注意しても、代替の作り方が分からなければ改善しません。教育は抽象論ではなく、“型（テンプレ）”を渡すのが効果的です。
おすすめ：長いパスフレーズの作り方を具体例で示す
- 単語を 4〜5 個つなぐ（意味のある文章でもよい）
- 社名・部署名・年度・自分の名前など、推測材料になりやすい要素は避ける
- 区切り文字（- や _）を使って覚えやすくする
例としては「季節_飲み物_乗り物_感情_記号」のように“自分だけの語彙”で作るなどです。重要なのは、攻撃者が組織情報から推測しやすい素材（社名、製品名、年度、所在地、電話番号、部署名）を避けることです。
実装・見直しのチェックリスト（ハイブリッド向け）
最後に、現場で抜け漏れが起きやすいポイントをチェックリスト化します。
| チェック項目 | 確認すること | 狙い |
|---|---|---|
| 同期ユーザーのパスワード変更経路 | オンプレ変更が正本か、SSPR 書き戻しを使うか | どのポリシーが最終的に効くかを明確化 |
| 最小パスワード長 | 現状の文字数と引き上げ余地 | 形だけ更新でも強度が落ちにくい設計にする |
| 履歴＋最短変更間隔 | 履歴回転で抜けられない値になっているか | A→B→A 回避の抑止 |
| 禁止パスワード/辞書対策 | 社名・年度・よくある単語の扱い、導入範囲 | 推測されやすい系列をまとめて排除 |
| MFA の必須化 | 特権→重要アプリ→全社の順に導入できているか | パスワード単独依存を下げる |
| 条件付きアクセス | 高リスク/未知端末/未知場所の制御、レガシー認証の遮断 | 漏えい時の侵入成立を防ぐ |
| 監査と例外運用 | 例外アカウントの棚卸し、定期監査、運用手順の整備 | “穴”が運用で増えないようにする |
よくある質問
同期ユーザーでも Entra ID 側のパスワードポリシーで「変更量」を制御できますか？
できません。同期ユーザーのパスワード検証は基本的にオンプレ AD のルールに従い、PHS はその結果を同期する仕組みです。「前回から何文字変えたか」を標準機能で判定して拒否することはできません。
「1文字変更」自体は危険なのに、なぜ製品として止める機能がないのですか？
“危険になりやすい”のは事実ですが、システムがそれを一般化して判定するのは難しく、誤検知や運用コストも増えます。また、パスワードは平文で保存しない前提のため、類似度判定を標準化しにくい背景もあります。その代わりに、長さ・禁止パスワード・MFA など「より確実に効く防御」が整備されています。
パスワードを強くしても、ユーザーが覚えられず付箋管理になりませんか？
この問題は“複雑さ”を上げたときに起きやすく、“長いパスフレーズ”に寄せると改善しやすいです。意味のある語を複数つないだ長い文字列は、短くて複雑な文字列より覚えやすいことが多く、入力ミスも減ります。
最短変更間隔を入れると、ヘルプデスク対応が面倒になりませんか？
運用設計次第です。ユーザー自身が短時間に何度も変えて履歴を回避するのを防ぐのが目的なので、ヘルプデスクの“リセット運用”や初回ログオン時のフローと衝突しないよう、手順と例外の扱いをセットで整備するのがポイントです。
結局、最優先でやるべきことは何ですか？
優先順位は次の順が現実的です。
- 特権アカウントの MFA 必須化と条件付きアクセス強化
- 最小パスワード長の引き上げ（可能なら 12 以上）
- 履歴＋最短変更間隔で“履歴回避”を封じる
- 禁止パスワード（辞書・社名・年度など）の導入
まとめ
ハイブリッド環境で「1文字だけ変える」パスワード変更を技術的に拒否したい、という悩みは非常に現実的です。しかし、Microsoft Entra ID のパスワード ハッシュ同期（PHS）は“結果を同期する仕組み”であり、ハッシュの性質上も「似ているパスワード」を判定する前提ではありません。そのため、標準機能で“変更量”を条件にブロックすることはできません。
だからこそ、対策の軸は変更量の取り締まりではなく、長さ・再利用禁止・禁止パスワード・MFA/条件付きアクセスへ寄せるのが最短ルートです。形だけ更新が起きても侵害が成立しにくい状態を作り、ユーザーには“作り方の型”を渡す。これが、現場でセキュリティと運用の両方を前に進める現実解になります。
コメント