AS400 / IBM i のパスワードポリシーは、ログインできない問い合わせだけでなく、監査や退職者ID管理にも関わります。パスワード期限、サインオン失敗、ユーザーIDロック、初期パスワード運用、共有IDの有無を定期的に確認します。
確認する項目
| 項目 | 見ること | 注意点 |
|---|---|---|
| 期限 | パスワード期限切れ、変更周期 | 期限切れ対応の手順を決める |
| 失敗 | サインオン失敗回数、ロック | 攻撃か入力ミスかを見る |
| 初期値 | 初期パスワード、再発行手順 | 本人確認なしで戻さない |
| 共有ID | 部署共用、作業用ID | 責任の所在が曖昧になる |
| システム値 | DSPSYSVAL/WRKSYSVALで確認 | 変更は影響範囲を確認してから |
パスワードポリシーは、厳しくすればよいというものではありません。締め処理や夜間対応で必要なID、外部連携で使うID、退職者IDの停止ルールを合わせて整備します。特に本番作業用IDは、利用者、承認者、利用日時を残す運用が必要です。
ログインできない時は AS400ユーザーIDロック・パスワード期限切れの確認手順、システム値は AS400システム値の確認ポイント、監査観点は AS400セキュリティ点検チェックリスト を確認してください。
関連するAS400確認ルート
パスワードポリシーは、システム値だけでなく、利用者運用、ロック時対応、監査ログ、例外IDまで含めて点検します。セキュリティと業務継続を両立させる視点が必要です。
問い合わせ内容とシステム値を分けて確認する
パスワード関連の問い合わせでは、「ログインできない」という一言だけでは原因を決められません。期限切れ、入力ミス、ユーザー無効化、端末側の接続問題、プロファイルの権限変更が混ざります。私はまず、利用者の申告内容とAS400側のシステム値を分けて確認します。
| 確認すること | 見る観点 | 注意点 |
|---|---|---|
| 期限切れ | 最終変更日、期限設定、利用者の申告時刻 | 期限切れと入力ミスを混同しない |
| サインオン失敗 | 失敗回数、端末、時間帯 | 同じ端末だけなら接続設定も見る |
| ユーザー無効化 | 退職者ID、長期未使用、承認有無 | 復活前に所属部署と利用目的を確認する |
| 権限変更 | 直近の変更作業、承認履歴 | 一時対応で強い権限を付けっぱなしにしない |
現場では、パスワードを再設定して終わりにすると、同じ問い合わせが繰り返されます。誰が、いつ、どの端末で、どの業務をするために入れなかったのかまで残すと、運用改善や権限棚卸しにつなげやすくなります。
パスワードポリシー確認時の見る順番
AS400のパスワード運用は、ユーザープロファイルだけでなくシステム値と運用ルールを合わせて確認します。厳しすぎても現場が回らず、緩すぎても監査で説明できません。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| システム値 | QPWDMINLEN、QPWDEXPITV、QPWDRQDDIFなどの設定方針を確認する | 変更前に現行値と変更理由を記録する |
| 利用者影響 | 期限切れ、初期パスワード、ロック解除依頼の件数を確認する | 問い合わせ増加が見込まれる場合は周知日を決める |
| 例外管理 | バッチ用、連携用、緊急用のプロファイルを分けて確認する | 人が使うIDとシステム用IDを同じ基準で扱わない |
パスワードポリシーは設定値の正しさだけでなく、例外IDを説明できるかが実務上のポイントです。
パスワード関連は、ユーザー個別とシステム値を分けて確認する
AS400 / IBM i でログインできない、パスワード期限が短い、すぐ無効になる、といった相談が出た時は、ユーザープロファイルだけでなくシステム値も確認します。全社共通のポリシーなのか、特定ユーザーだけの問題なのかを分けないと、不要な権限変更や一時対応が増えてしまいます。
| 確認対象 | 見る内容 | 注意点 |
|---|---|---|
| ユーザープロファイル | 無効化、パスワード期限、前回サインオン、特殊権限 | 共用IDの扱いは特に慎重にする |
| システム値 | パスワード有効期限、最小桁数、失敗時の動作 | 変更は全ユーザーへ影響する |
| サインオン失敗 | 失敗回数、失敗時刻、端末、接続経路 | 攻撃か入力ミスかを分ける |
| 運用ルール | 退職者ID、長期未使用ID、権限棚卸 | 棚卸記録を残す |
| 説明資料 | 利用者向けの変更理由、期限、問い合わせ先 | 急な変更で業務を止めない |
パスワードポリシーはセキュリティ対策ですが、現場運用と合っていないと問い合わせが増えます。設定値を変える前に、現在のルール、影響する利用者、夜間バッチや外部連携で使うユーザー、例外扱いの有無を確認します。若手に任せる場合は、ユーザー個別対応と全体ポリシー変更を混同しないよう、確認表にしておくと安全です。