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