パスワードポリシーは、アカウントの侵害を困難にしつつも、セキュアな行動の実践が不必要に難しくならないようにするべきです。 最適なポリシーは明確で実用的であり、実際の業務に即しています。長く、ユニークなパスワードの推奨、パスワードマネージャーの利用促進、適切な場合の多要素認証（MFA）の必須化、そして利用者を予測可能な行動へと導いてしまう古いルールの撤廃を行います。
この記事では、現代的なパスワードポリシーのやるべきこと、避けるべきこと、守るべきベストプラクティス、そして組織でそのまま使えるコピペ用テンプレートを解説します。
パスワードポリシーとは？
パスワードポリシーとは、パスワードの作成・保存・利用・共有・変更・保護に関するルールを定めたものです。 対象は従業員、契約社員、管理者、サービスアカウント、場合によっては顧客などシステムの範囲によります。
良いパスワードポリシーは以下の実践的な疑問に答えます：
- パスワードはどれくらいの長さが必要か？
- パスフレーズは許可されるのか？
- パスワードマネージャーからパスワードを貼り付けて良いか？
- パスワードはいつ変更する必要があるか？
- 多要素認証（MFA）は必須か？
- 共有認証情報はどう扱うか？
- パスワードが漏洩した疑いがあるときはどうするか？
目的は最も複雑なルールを作ることではなく、実際のリスクを減らすことです。
現代的なパスワードポリシーのやるべきこと
必要な長さを要求する
長いパスワードは推測や総当たり攻撃への強力な防御となります。組織全体で一律の最小長を設けることで、利用者にわかりやすく、IT 部門も管理しやすくなります。実用的なデフォルトとして、人間が使うすべてのアカウントに 16 文字以上を要求しましょう。パスワードマネージャーやランダム生成パスフレーズを使う場合はさらに長い方が望ましいです。
長いパスワードやパスフレーズを許可する
ユーザーは最小要件以上の長いパスワードを作成できるべきです。16 文字や 20 文字など低めの最大長は避けましょう。64 文字以上を許容するのが妥当な基準で、多くのシステムはそれ以上も安全にサポートできます。
パスフレーズも、十分長くあり、一般的な引用文や歌詞、社名、予測可能なフレーズに基づかない場合には許可しましょう。例えば、いくつかのランダムな単語を組み合わせたパスフレーズは、強制的な置換を使った短いパスワードより優れています。
ユニーク性を要求する
すべてのアカウントは一意のパスワードを持つべきです。パスワードの使い回しは、一つのサービスでの漏洩から他のアカウント乗っ取りに繋がる主な要因の一つです。パスワードマネージャーの利用を推奨し、全ての認証情報を記憶しなくてもよいようにしましょう。
パスワードマネージャーをサポートする
ポリシーには、承認されたパスワードマネージャーの利用を明記し、推奨しましょう。ユーザーがパスワードを貼り付けたり、自動入力やランダムなパスワード生成ができるようにします。「貼り付け禁止」は一見安全そうですが、強力なパスワードマネージャー活用を妨げます。
既知の漏洩パスワードと照合する
パスワードが既知の漏洩リストや一般的なパスワードリスト、組織固有の禁止リストに含まれていた場合は拒否します。大文字・数字・記号を強制するよりも遥かに有効です。
技術的に可能な限り MFA を必須化する
多要素認証（MFA）は、技術的に可能な限りすべての用途で有効にしましょう。特に管理者、リモートアクセス、クラウドサービス、メール、パスワードマネージャー、財務システム等の重要システムでは必須です。MFA は強力なパスワードの代用ではありませんが、認証情報流出の影響を大幅に減らします。
可能な場合は、パスキーやハードウェア認証キー、プラットフォーム認証器など、フィッシング耐性の高い MFA を推奨します。アプリベース認証器は SMS より望ましいです。SMS ベースの MFA は他の MFA 方法が技術的に利用可能な場合は使用してはいけません。携帯番号はハイジャック、SIM スワップ、ポートアウト、復旧プロセスによる悪用のリスクがあるためです。
これは理論ではありません。2018 年、Reddit は SMS ベースの 2 要素認証が傍受され、システムが侵害されたことを公表しました：https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/。2021 年には Coinbase が、認証情報と SMS アカウント復旧の脆弱性を突かれて 6,000 名以上の顧客の暗号資産が不正送金されたことを報告しています：https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/。
漏洩時にはパスワードを変更する
パスワードが侵害された証拠や合理的な疑いがあるときは速やかに変更しましょう。例：フィッシング、ユーザー端末でのマルウェア、漏洩で認証情報が公開された場合、不審なログイン、誤って公開した場合など。
共有認証情報を適切に保護する
個別アカウント利用が可能ならば、共有パスワードは避けましょう。どうしても共有が必要な場合、承認されたパスワードマネージャーで保管し、権限あるユーザーのみにアクセスを制限し、可能なら共有操作を記録します。
パスワードリセットプロセスを保護する
パスワードリセットはアカウントセキュリティの最も弱いポイントです。リセットフローでは本人確認を行い、リンクは短時間で失効し、使い捨てトークンを利用し、パスワードが変更された際はユーザーに通知しましょう。
現代的なパスワードポリシーのやってはいけないこと
理由もなく頻繁なパスワード変更を強要しない
30 日、60 日、90 日ごとの義務的な変更はしばしばパスワードの弱体化を招きます。利用者はわずかな、類型的な変化（数字の追加や季節の変更）をしがちです。米国 NIST のデジタルアイデンティティガイドラインでも、定期的な強制変更は廃止され、「侵害した証拠がある場合」にのみ変更を必須としています。セクション 3.1.1.2 参照：https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver。侵害疑い、権限の異動、アカウント復旧、またはポリシー不適合時のみ変更を要求します。
複雑さルールだけに頼らない
「大文字・小文字・数字・記号を含んでいること」のようなルールだけでは強度は保証できません。例えば Password1! は多くの複雑性ルールを満たしますが弱いままです。長さ、ユニークさ、ランダム性、漏洩リストとの照合を優先しましょう。
コピー＆ペーストを禁止しない
貼り付け禁止はパスワードマネージャーの利用を難しくします。短く入力しやすいパスワードへの誘導にもなります。特段の明確な理由がない限り、貼り付けや自動入力を許可しましょう。
パスワードヒントを許可しない
パスワードヒントはしばしば情報を漏らしすぎます。利用者がヒントを見て思い出せるものは、攻撃者にも推測される可能性があります。代わりに安全なリセットプロセスを利用しましょう。
パスワードを平文で保存しない
パスワードを平文や可逆暗号で保存してはいけません。パスワードは Argon2id、bcrypt、scrypt、PBKDF2 など、最新で遅いソルト付きハッシュ化アルゴリズムで保存すべきです。（システム性能や法規制により選択）
MD5、SHA-1、SHA-256、SHA-512 等の高速汎用ハッシュは、それだけでは適切なパスワードハッシュではありません。高速設計のため漏洩時の総当たり攻撃が容易です。詳しくは弊社パスワードハッシュ進化論の記事をご覧ください。
チャットやメールでパスワードを共有しない
パスワードをメール、チャット、チケット、ドキュメント、スクリーンショット経由で送ってはいけません。安全な共有・アクセス制御のできるパスワードマネージャーを利用しましょう。
個人情報や予測可能なパターンを使わない
パスワードに名前、誕生日、会社名、キーボードパターン、繰り返し文字、@ を a に、0 を o にするようなよく使われる置換などは禁止です。攻撃者はこれらのパターンを最初に試します。
組織向けベストプラクティス
明確な最小要件を定める
覚えやすい要件を設定しましょう：
- 例えば「すべての人間アカウントで 16 文字以上」など一つの最小長
- 64 文字以上の許可
- スペースと一般的な記号の許可
- パスフレーズとパスワードマネージャーの許可
- 漏洩済み・よく使われるパスワードの拒否
特権アカウントは個別対応
管理者アカウント、サービスアカウント、本番アクセスは強力な制御が必要です。より強いパスワード、MFA、アクセス制限、監視、権限変更時の即時パスワード回転を要求しましょう。
ロールベースアクセスと最小権限を徹底
強いパスワードは過剰な権限を補いません。必要最小限のシステムや機密情報だけにアクセスを制御しましょう。
不審な活動を監視
異常なログインパターン、不可能な移動、連続失敗、新しい国からのアクセス、勤務時間外のアクセスの検知などが重要です。パスワードポリシーだけでなく、モニタリングやインシデント対応体制と組み合わせましょう。
現実的な脅威を踏まえた利用者教育
教育ではパスワードの再利用、フィッシング、偽のログインページ、MFA 疲労、共有方法、侵害疑い時の報告手順などに焦点を当てましょう。利用者を責めず、安全な行動が簡単にできる仕組みを構築します。
ポリシーは守りやすい長さにする
パスワードポリシーは理解できなければなりません。長過ぎ、曖昧、厳しすぎると利用者は抜け道を探します。実現可能で従いやすい内容が最良です。
コピペ用パスワードポリシーテンプレート
下記テンプレートをご利用ください。[] 内の部分を貴組織やシステム、リスク水準、法令要件に合わせて調整してください。
パスワードポリシー
バージョン: [1.0]
所有者: [情報セキュリティ部門／IT部門]
施行日: [YYYY-MM-DD]
見直し周期: [12ヶ月ごと]
1. 目的
本ポリシーは、[組織名]におけるパスワードの作成、利用、保存、共有、変更に関する要件を定め、無許可アクセス、認証情報窃取、アカウント乗っ取り、データ損失のリスクを低減することを目的とします。
2. 適用範囲
本ポリシーは、[組織名]のシステム、アプリケーション、ネットワーク、クラウドサービス、またはデータへアクセスする全ての従業員、業務委託者、派遣社員、サービスプロバイダー、その他の利用者に適用されます。
対象は標準ユーザーアカウント、特権アカウント、サービスアカウント、共有アカウント、およびパスワード認証が用いられる全てのシステムです。
3. パスワード作成要件
すべてのパスワードは次の要件を満たさなければなりません：
- 人間利用者アカウントは16文字以上を使用すること。
- パスワードは一意であり、業務・個人問わず他アカウントと使い回してはならない。
- パスワードに氏名、ユーザー名、会社名、誕生日、キーボードパターン、繰り返し文字、その他容易に推測できる情報を含めてはならない。
- パスワードは一般的なフレーズ、引用、歌詞、予測可能な置換に基づいてはならない。
- パスワードは既知の漏洩リストや一般的なリストに含まれてはならない。
- パスワードにはスペース、記号、数字、大文字・小文字が利用可能。
- パスフレーズは長くユニークで、予測可能あるいは公開されたフレーズに基づかない場合に限り許可する。
4. パスワードマネージャー
[組織名] はパスワードマネージャーの利用を必須または強く推奨します。
ユーザーは承認されたパスワードマネージャーで生成・自動入力・コピー&ペーストを行うことができます。パスワードをブラウザ、スプレッドシート、ドキュメント、ノートアプリ、メール、チャット、スクリーンショット、未承認のツールで保存してはいけません。
5. 多要素認証
技術的に可能な全ての場面で多要素認証（MFA）を有効にしなければなりません。例：
- メールアカウント
- リモートアクセスシステム
- パスワードマネージャーアカウント
- クラウドサービス
- 管理者アカウント
- 財務・人事その他ハイリスクシステム
- [機密／重要]と分類された全てのシステム
利用可能な場合はパスキー、ハードウェア認証キー、プラットフォーム認証器等のフィッシング耐性MFAを利用してください。認証アプリはSMSより優先されます。SMS認証は他方式が可能な場合は許可されません。どうしても強力な方法が無理な場合のみ例外とします。
6. パスワード変更
以下の場合、速やかにパスワードを変更しなければなりません：
- パスワードが漏洩または疑いがある場合
- フィッシングサイトにパスワードを入力した場合
- 許可されていない者とパスワードを共有した場合
- マルウェアや不正アクセスが端末で検出された場合
- パスワードが漏洩データに含まれていた場合
- 特権ユーザーの役割や雇用状態が変わった場合
- ITまたはセキュリティが指示した場合
法律・規制・契約、またはシステム制限による義務を除き、定期的なパスワード有効期限の強制は不要です。前のパスワードから予測できるような小さな変更のみでの更新は禁止します。
7. パスワード共有
パスワードはメール、チャット、チケット、ドキュメント、スクリーンショット、電話、口頭で共有してはなりません。
個別アカウントが技術的に利用不可能、または[情報セキュリティ／IT部門]の明確な承認がある場合のみ、共有認証情報が許可されます。承認済みパスワードマネージャーを使い、権限ある者のみにアクセスを制限します。
8. 特権アカウント
特権アカウントは標準アカウントと異なる一意的なパスワードを使用しなければなりません。利用可能な場合は必ずMFAを利用し、定期的に見直しを行います。
管理者が離職・異動・不要なった場合や、侵害疑いが生じた場合、特権パスワードはすぐに変更（ローテーション）してください。
9. サービスアカウントおよびアプリケーションシークレット
サービスアカウント用パスワード、APIキー、トークン、シークレット等は承認済みシークレット管理システムまたはパスワードマネージャーで保存します。
サービスアカウントの認証情報は、保護されたプロセスでない限り、ソースコード、設定ファイル、イメージ、ドキュメント、スクリプトに埋め込んではなりません。
10. パスワードリセット・アカウント復旧
パスワードリセット時はユーザーの本人確認を必須とします。リセットリンクや一時パスワードは使い捨て・短期間有効にし、承認済みの経路で送信します。
パスワード変更やリセットが行われた際はユーザーへ通知します。一時パスワードは初回ログイン時に変更しなければなりません。
11. 技術的コントロール
パスワードを保存・処理するシステムは下記を満たすこと：
- パスワードを平文保存しない
- PBKDF2、scrypt、bcrypt、Argon2など承認済みのソルト付きハッシュを使用する
- MD5、SHA-1、SHA-256、SHA-512などの高速ハッシュアルゴリズム単体は使わない
- 認証エンドポイントにレート制御等の防御策を実装
- 弱い、または既知の漏洩パスワードを拒否
- パスワードマネージャーからの貼り付けを許可
- 技術的に可能なら64文字以上の長さをサポート
- セキュリティ関連の認証イベントを記録
12. 侵害疑い時の報告
パスワードの侵害やフィッシング、不審なログインやMFAプロンプト、誤って開示した場合は直ちに[情報セキュリティ／IT連絡先]へ報告しなければなりません。
13. 例外
本ポリシーの例外は文書化され、リスク評価され、期間限定かつ[情報セキュリティ／IT管理者]による承認が必要です。可能な場合は代替策を適用します。
14. 執行
このポリシーに反した場合、アクセス権の剥奪、セキュリティ研修の義務付け、懲戒、その他[組織名]規定および法令に基づく措置となる場合があります。
15. 見直し
本ポリシーは、少なくとも年1回またはシステム・脅威・法令・事業運営の大きな変更時に見直しを行います。
最後に
強いパスワードポリシーの目的は、ユーザーを苦しめることではありません。弱い習慣の排除、パスワードマネージャーの推奨、MFA の活用、認証情報漏洩時の迅速な対応のためにあります。実践的で強制可能で、フィッシングやリスト型攻撃、パスワード再利用、アカウント乗っ取りなど現実の攻撃に焦点を当てて策定しましょう。
