パスワードポリシーを社内で定めようとすると、「何か月ごとに変更させるか」「記号を必須にするか」といった論点から議論が始まりがちです。しかし近年は、こうした要件を厳しくすればするほど安全になる、という考え方は見直されつつあります。この記事では、有効期限・複雑性要件・長さをどう決めるかという実務的な整理と、ポリシーの設計だけでは対応しきれない領域について解説します。
定期変更を一律に義務づける運用の副作用
「90日ごとに変更」のようなパスワードの有効期限を全社一律で設定すると、現場では次のような行動が起こりやすくなります。
- 末尾の数字を1つ増やすだけの変更 — 規則性が読まれやすく、実質的な強度は上がりません
- 覚えきれないための使い回し — 社内システムと外部サービスで同じパスワードを使う運用につながります
- 付箋やメモへの記録 — 記憶できない要件を課すと、物理的な記録に頼らざるを得なくなります
- 問い合わせ工数の増加 — 変更直後のロックアウトやリセット依頼が定期的に発生します
こうした副作用が知られてきたことから、パスワードの定期変更を一律に求めない考え方が公的な指針になっています。米国NIST(米国立標準技術研究所)は2017年のガイドライン(SP800-63B)で、サービスを提供する側が定期的な変更を要求すべきではないとしました。日本でも、総務省の「国民のためのサイバーセキュリティサイト」が、流出した事実がなければ変更する必要はなく、定期的な変更によってパスワードがパターン化することや使い回しのほうが問題だと説明しています。内閣サイバーセキュリティセンター(NISC)も、定期変更は不要で、流出時に速やかに変更するという考え方を示しています。
ではいつパスワードを変更すべきか
定期変更を外すということは、「変更しない」という意味ではありません。変更すべき理由が発生したときに、確実に変更するという運用に切り替えるという整理です。具体的には次のような場面が該当します。
- 漏洩の兆候があったとき — 見覚えのないログイン通知、他社サービスからの流出の連絡などがあった場合(パスワード漏洩時の影響と初動対応で扱っています)
- 共有していたアカウントの利用者が変わったとき — 退職・異動のタイミングで必ず変更します(そもそも共有をやめる観点は共有アカウントの廃止を参照)
- 初期パスワードから初めて使うとき — 発行時のパスワードをそのまま使い続けない運用にします
複雑性要件の限界と、長さという考え方
そもそもパスワードが機械的に破られる仕組み（総当たり攻撃・辞書攻撃）を踏まえると、文字種を増やすことと長さを確保することのどちらが効くのかが判断しやすくなります。
大文字・小文字・数字・記号をすべて必須にする複雑性要件にも、似た副作用があります。要件を満たそうとした結果、先頭を大文字にして末尾に記号と数字を付けるといった、人間が思いつきやすいパターンに収束しがちです。また、覚えられない文字列は結局どこかに記録されることになります。
そのため近年は、文字種の強制よりも長さを確保するほうが効きやすい、という考え方が広く共有されています。複数の単語をつないだ長い文字列(パスフレーズ)のように、本人は覚えやすく、機械的な推測には強い形を許容する方向です。最低文字数については一般に10文字以上、可能であればより長く、と言われていますが、どの水準を採るかは自社のシステムが許容する設定と現場の運用負荷を見て決めるべき事項です。
定期変更をやめる設定の手順
方針を決めたら、実際の設定を変えます。規程だけ変えて設定を残すと、期限切れの画面は出続けます。
Active Directory（ドメイン参加PC）
- 「グループ ポリシーの管理」で、ドメインに適用しているポリシー（通常は Default Domain Policy）を編集します。
- 「コンピューターの構成」→「ポリシー」→「Windows の設定」→「セキュリティの設定」→「アカウント ポリシー」→「パスワードのポリシー」を開きます。
- 「パスワードの有効期間」を 0 にします。0 は「期限なし」の意味です。
いまの設定値は、PowerShellの Get-ADDefaultDomainPasswordPolicy で確認できます。部署ごとに別のポリシー（細かい設定のパスワード ポリシー）を使っている場合は、そちらも見直します。確認の手順はActive Directoryのパスワードポリシーを確認するコマンドで扱っています。
ドメインに参加していないPC
PCごとに、管理者として開いたコマンドプロンプトで net accounts /maxpwage:unlimited と入力します。net accounts だけを入力すると、いまの設定を確認できます。
Microsoft 365（Entra ID）
Microsoft 365 管理センターの「設定」→「組織設定」→「セキュリティとプライバシー」→「パスワードの有効期限ポリシー」で、パスワードを無期限にします。比較的新しく契約した組織では、すでに無期限になっていることもあります。
期限を残す場合でも、有効期限が切れる前に通知する設定をしておくと、期限切れで業務が止まる事故は防げます。
社内と取引先への説明の仕方
定期変更をやめるときに止まりやすいのは、設定ではなく説明です。「セキュリティを弱めるのか」と聞かれたときは、次の3点で答えられます。
- 公的な指針が変わっている：総務省・NISC・NISTが、定期変更は不要で流出時に変更するという考え方を示しています。
- 取引先の基準でも求められていない：経済産業省のSCS評価制度の★3の要求事項には、パスワードの定期変更の項目はありません。求められているのは、推測されやすいパスワードの禁止、長さ、使い回しの禁止、そして漏えいが分かったときに速やかに変更する手順です（4-1-5、4-1-6）。詳しくはSCS評価制度とはで整理しています。
- 手間が減る：変更期限の直後や連休明けに集中する「パスワードを忘れました」の問い合わせが減ります。問い合わせ全体の減らし方はPCのログインパスワードを忘れた社員への対応で扱っています。
取引先のチェックシートで「定期的に変更していますか」と聞かれた場合は、「いいえ」だけで終わらせず、代わりに行っていること（長さの基準、使い回しの禁止、漏えい時の変更手順）を書き添えます。書き方はセキュリティチェックシートの答え方を参照してください。
ポリシーとして決めておくべき項目
文書として整えるべき項目を整理すると、次のようになります。項目を絞ったほうが、現場で守られやすいポリシーになります。
- 最低の長さ — 数字の根拠を含めて明記します
- 使い回しの禁止 — 特に社内システムと外部サービスの間での使い回しを禁じます
- 初期パスワードの扱い — 発行方法、受け渡し方法、初回変更の扱いを決めます
- 漏洩が疑われる場合の変更手順 — 誰に連絡し、どの範囲を変更するかを事前に決めておきます
- 管理者アカウントの扱い — 一般利用者より厳しい要件を分けて定義します(管理者権限の棚卸しと権限管理を参照)
ポリシーだけでは防げない領域
ここが最も重要な点です。パスワードポリシーは、推測されにくいパスワードを作らせるための仕組みであり、パスワードそのものが攻撃者の手に渡るケースには効きません。代表的なのは次の2つです。
- 他社サービスからの流出 — 利用者が別のサービスで使っていたパスワードが流出し、同じものを社内システムでも使っていた場合、そのパスワードは正しい文字列として通用してしまいます(パスワード漏洩の事例も参照)
- フィッシング — 本人が偽サイトに自ら入力してしまった場合、文字数や複雑性は関係ありません
いずれも、正しいパスワードが入力されている状態です。この領域に対応するには、パスワード以外の要素を認証に加えるしかありません。多要素認証の基本やWindows OSログインの2要素認証を、ポリシー見直しとあわせて検討することをおすすめします。
ポリシーを運用に落とすときの注意
決めた内容は、システム側で強制できる範囲と運用ルールで補う範囲に分けて整理してください。最低文字数や履歴の再利用禁止のようにシステム設定で担保できるものは設定で固定し、初期パスワードの受け渡し方法や漏洩時の連絡経路のように設定では表現できないものは、手順として文書化して周知します。この線引きが曖昧なまま文書だけを作ると、実際には守られていない項目が残ります。中小企業の場合は中小企業向けセキュリティチェックリストのような形で、確認項目を絞って運用するほうが定着しやすいでしょう。
プライバシーマークを取得している場合、規程に何を書き、どの記録を残すかという観点が加わります。 JIS Q 15001のパスワード管理で具体的に扱っています。
規則を厳しくすると、紙に書き留める行為が増えます。この副作用と対処は パスワードを付箋で管理している状態の危険で扱っています。使い回しの有無を確認する手段は 使い回しを確認する方法を参照してください。
有効期限を設ける場合、期限切れに気づけない状態が業務を止めます。通知の設定は パスワードの有効期限が切れる前に通知する設定を参照してください。
いまの運用を棚卸ししてみる
自社のパスワードポリシーが現在の考え方に沿っているか、またポリシー以外の対策がどこまで整っているかは、あわせて確認したい点です。applippliの無料棚卸しでは、10問・約3分で、自社のパスワード・アカウント管理の対応状況を「解決済み／一部解決／人手で対応／未解決」に仕分けた一覧にできます。