はじめに
目的
本記事は、AWS（IAM）で管理するユーザーのパスワードポリシーについて、分かりやすく解説することを目的としています。設定項目やその意味、リスク、実際の設定手順や運用のコツまで丁寧に説明します。
対象読者
- AWSを使っている管理者や開発者の方
- セキュリティ運用を始めたばかりの方
- 既存の設定を見直したい方
難しい前提知識は不要です。実務で使える具体例を中心に説明します。
本記事で学べること
- パスワード強度や有効期限など主要なポリシー項目の意味
- デフォルト設定のリスクと改善方法
- IAMコンソールでの設定手順（図や手順付きで解説）
- 再利用禁止や期限運用の実務的な注意点
- Amplifyやカスタム環境での取り扱い方
- 実務で使える推奨設定例
読み方のヒント
まず第2章で基本を押さえ、第5章の手順に沿ってテスト環境で設定を確認してください。運用上は第6〜9章の注意点を参照すると安全に運用できます。章ごとに実例を載せますので、必要な箇所だけ読むことも可能です。
AWSパスワードポリシーとは
概要
AWSパスワードポリシーは、AWSアカウント内のIAMユーザーが使うパスワードに対して強度や運用ルールを強制するための設定です。組織のセキュリティ要件に合わせて、最小長や文字種の条件、有効期限、過去のパスワードの再利用禁止などをまとめて管理できます。
適用対象
このポリシーはアカウント単位で設定され、主にIAMユーザーのコンソールログイン用パスワードに適用されます。ルートアカウントや外部のIdP（フェデレーション）で管理される認証情報は別管理になります。
主な制御項目（例）
- 最小文字数（例：12文字以上）
- 大文字・小文字・数字・記号の必須化
- パスワードの有効期限（日数で設定）
- 過去パスワードの再利用禁止（直近のn件）
実際の効果
ポリシーはユーザーがパスワードを新規作成・変更する際に適用されます。例えば「最小12文字・数字と記号を必須・過去5回を禁止」にすれば、ユーザーはその条件を満たすパスワードでないと設定できません。
ひと言
パスワードポリシーは簡単に強度を引き上げられる有効な手段です。組織の運用とバランスを取りつつ、必ず設定を検討してください。
デフォルトのパスワードポリシーとそのリスク
現状
AWSアカウントを作成した直後、IAMのパスワードポリシーは設定されていません。既定のままだと短く単純なパスワードでも作成可能です。管理者が何も対策しなければ、そのまま運用される危険があります。
具体的なリスク
- 短く単純なパスワードは総当たり攻撃や辞書攻撃で破られやすいです。
- 流出した認証情報があればコンソールやAPIに不正アクセスされ、リソース操作や課金被害に繋がります。
- 同じパスワードの使い回しは、他サービスの侵害が波及する原因になります。
簡単な事例
例：Password123 のような推測しやすい文字列が許容されると、攻撃者は短時間でアカウントを奪う可能性があります。
対策の方向性
AWSは強いパスワードポリシーの導入を推奨します。まずは文字数の最低値を上げ、文字種を組み合わせる設定に変更してください。加えて、多要素認証（MFA）を全員に必須化すると被害を大きく減らせます。
設定できる主なポリシー項目
以下では、AWS IAMで設定できる主要なパスワードポリシー項目をわかりやすく説明します。具体例を交えて、何を設定すればよいかイメージしやすくまとめました。
最小パスワード長
パスワードの長さを8〜128文字の間で指定できます。短いほど覚えやすい反面、総当たり攻撃に弱くなります。実務では12文字以上を推奨することが多く、例：”Sakura2025!”は12文字前後で複雑さもあります。
文字種の必須設定（大文字・小文字・数字・記号）
大文字・小文字・数字・記号のいずれを必須にするか選べます。全部を必須にすると強度が上がります。例：大文字1、数字1、記号1を必須にすると”Tokyo#1Pass”のようになります。
パスワードの有効期限
パスワードを何日ごとに変更させるかを設定できます（例：90日）。頻繁な変更は安全性向上につながりますが、ユーザーの負担も増えます。利用状況に合わせて調整してください。
過去のパスワードの再利用禁止
過去に使ったパスワードを何回分まで拒否するか設定可能です（履歴数）。例えば過去10回を禁止にすると、短期的な再利用を防げます。
初回サインイン時の変更強制
管理者が作成した初期パスワードを、初回ログイン時に変更させるか設定できます。新規ユーザーの安全性を高める基本的な項目です。
ユーザーによるパスワード変更可否
ユーザー自身がパスワードを変更できるかどうかをオン／オフできます。オンにしておくと、忘れたときや漏洩が疑われるときに利用者が自分で対処できます。管理運用の方針に合わせて設定してください。
実務での注意点（簡潔に）
- 長さと文字種を組み合わせると効果的です。例：最小12文字＋全種類必須。
- 再利用禁止は履歴数を設定しておくと安全です（例：10）。
- 有効期限は運用負荷と相談して決めます。
設定手順（IAMコンソールからの例）
前提
ルートアカウント、またはIAM管理者権限を持つユーザーでAWSマネジメントコンソールにサインインします。IAMダッシュボードへのアクセス権が必要です。
手順（画面操作）
- コンソール上部のサービス検索で「IAM」と入力し、IAMダッシュボードを開きます。
- 左メニューから「アカウント設定（Account settings）」を選択します。
- 「パスワードポリシー（Password policy）」欄で「編集（Edit）」をクリックします。
- 必要なチェックボックスや項目を設定します（下の説明参照）。
- 設定が終わったら「保存（Save）」をクリックします。
画面で設定できる主な項目（簡単な説明）
- 最小文字数：パスワードの長さを決めます（例：12文字以上）。
- 大文字／小文字／数字／記号の必須化：例として「数字を必須」にすると1文字以上数字が必要になります。
- ユーザーによるパスワード変更の許可：ユーザーが自身で変更できるようにします。
- パスワードの有効期限：日数を設定すると期限切れで変更を促します。
- 再利用禁止（履歴保存）：過去N回分のパスワードを再利用不可にします。
保存後の確認
保存後は代表的なユーザーでサインインを試し、ポリシーが適用されているか確認してください。CLI（aws iam update-account-password-policy）やCloudFormationでも同様の設定が可能です。
パスワードの有効期限と運用オプション
パスワードの有効期限と運用オプション
概要
パスワードに有効期限を設定すると、期限切れ時の対処を運用で決める必要があります。ユーザー自身で期限切れパスワードを変更できる方法と、管理者がリセットして一時パスワードを発行する方法があります。一般的にはユーザーに変更を許可し、90日や110日などで定期変更を促します。
ユーザーによる変更の流れ
- 期限切れでログイン時にパスワード変更画面へ誘導します。
- メールやSMSなどで本人確認を行い、新しいパスワードを設定します。
- 変更完了の通知を送付して履歴を残します。
管理者によるリセットの流れ
- 管理者がアカウントをリセットして一時パスワードを発行します。
- ユーザーは受け取った一時パスワードでログインし、初回ログイン時に新しいパスワードへ変更します。
- 管理者は作業を記録し、必要に応じてサポートを提供します。
運用のポイント
- 推奨設定：ユーザーによる変更を許可、期限は90〜110日。
- 猶予期間やリマインダーを設定してサポート負荷を下げます。
- 自動化（通知やローテーション）と監査ログで運用を楽にし、可視化します。
- 多要素認証や強いパスワードルールと組み合わせて運用すると安全性が上がります。
パスワードの再利用禁止設定
概要
IAMパスワードポリシーでは、過去に使ったパスワードを再利用できないよう履歴の件数を設定できます。使い回しを防ぎ、アカウント乗っ取りリスクを下げます。
なぜ重要か
同じパスワードを繰り返すと、流出時に複数のサービスで被害が広がります。履歴を保持することで新しいパスワードを強制し、攻撃の効果を減らせます。
履歴数の意味と目安
履歴数は「何回分の過去パスワードを禁止するか」です。一般的な目安は5〜24件。短い有効期間と組み合わせるなら5〜10で十分です。長めにすると使い勝手は下がりますが安全性は高まります。
設定方法（簡単な例）
- コンソール：IAMの「パスワードポリシー」から「以前のパスワードを再利用できない回数」を設定します。
- AWS CLI例：aws iam update-account-password-policy –password-reuse-prevention 12
運用上の注意点
- 利用者が頻繁にパスワードを忘れる原因になるため、事前告知やパスワードマネージャの導入を検討してください。
- 履歴はIAMが管理するため、自前の認証基盤と連携する場合は別途対応が必要です。
よくある疑問
Q: 過去のパスワードが何件まで保存されますか？
A: 設定した件数分が保存されます。既に同じパスワードを使っている場合、変更直後に制約が適用されます。
Amplifyやカスタム環境でのパスワードポリシー
概要
AmplifyはCognito User Poolを使うため、パスワードポリシーをコードから指定できます。TypeScriptやCDKで直接設定すると、例えば「6文字以上・小文字と数字必須・記号や大文字不要」のように柔軟にカスタマイズできます。
Amplify(Cognito)での設定例（TypeScript/CDK）
以下はAWS CDKのTypeScript例です。UserPoolのpasswordPolicyで細かく指定できます。
new UserPool(this, 'UserPool', {
passwordPolicy: {
minLength: 6,
requireLowercase: true,
requireDigits: true,
requireUppercase: false,
requireSymbols: false,
}
});
Amplify CLIやバックエンド編集
Amplifyプロジェクトでは、amplify add authで設定するか、amplify/backend/auth/<リソース名>/parameters.jsonやCloudFormationテンプレートを直接編集してカスタマイズします。編集後はamplify pushで適用します。直接コンソールで変更すると設定が差分として扱われるため注意してください。
カスタム認証環境での実装ポイント
自前の認証サーバーやLambdaを使う場合、Cognitoを使わないとポリシーは自分で検証する必要があります。サインアップ・パスワード変更時にサーバー側で必須条件をチェックしてください。クライアントでのチェックは利便性向上に役立ちますが、必ずサーバー検証を行ってください。
テストと運用上の注意
ポリシー変更は既存ユーザーの挙動に影響します。パスワード強度判定やリセットフローが期待通り動くか、ステージングで十分に確認してから本番反映してください。ドリフト管理のため、コードでの定義を推奨します。
ベストプラクティスと運用上の注意点
1. 基本方針
パスワードポリシーは強さと利便性のバランスを重視します。過度に複雑だと利用者の回避行動（メモの常用や使い回し）を招きます。実務では「長さを優先し、複雑さはほどほどに」を目安にしてください。
2. 実践的な設定例
- 最低長さ：12文字以上を推奨。
- 英字（大文字・小文字）＋数字＋記号の混在を促すが、必須にするかは組織のリスクに応じて決めます。
- 再利用禁止は直近5回程度を設定すると効果的です。
3. 運用上の注意点
パスワードのみで守る設計はリスクが高いです。多要素認証（MFA）を必須にしてください。パスワードの有効期限は短くしすぎると逆効果になるため、リスクに応じて設定します。
4. 監査と見直し
少なくとも年1回はポリシーと運用ログを見直してください。インシデントや組織変更があれば臨時レビューを行います。
5. ユーザー教育とサポート
定期的に安全なパスワードの作り方やMFAの利用方法を周知します。パスワードリセットの手順は簡潔で安全に保ち、サポートに依存しすぎない仕組みを用意します。
6. 緊急時対応
漏えい疑い時は直ちにパスワード無効化・MFAリセットを行い、影響範囲を限定します。ログ調査と再発防止を迅速に実施してください。
まとめと推奨設定例
AWS環境の安全性は、パスワードポリシーの適切な設定と日々の運用で大きく向上します。本章では実務で使いやすい推奨設定例と運用の注意点を簡潔にまとめます。
推奨設定例
- 最小文字数：12文字
- 文字種：大文字・小文字・数字・記号を必須
- 有効期限：90日（長すぎず短すぎない目安）
- 再利用禁止：過去5回分を保持
- アカウントロック：一定回数の失敗でロック（例：5回）
- MFA：すべての管理者と重要な利用者に必須
設定の意図と運用ポイント
- 長さと複雑性で総当たり攻撃に強くします。短いパスワードは弱点になります。
- 有効期限は頻度と負担のバランスを取ります。自動リマインドを設定してください。
- 再利用禁止とロックで同一パスワードの繰り返しや総当たりの成功を防ぎます。
- MFAは最も有効な補完対策です。可能ならハードウェアトークンを推奨します。
日常の運用で気を付けること
- ログとアラートを常時監視し、不審な試行を早期に検知する
- 管理者権限は最小限に限定する
- ユーザー教育を行い、パスワード管理ツールの利用を推奨する
この設定例をベースに、自組織のリスクや業務負荷を見て調整してください。安全性と利便性の両立を意識して運用すると効果が高まります。
