AS400 / IBM i の特殊権限は、便利な一方で監査上のリスクになります。特に *ALLOBJ のような強い権限は、誰に、なぜ、いつまで付与しているのかを説明できる状態にしておく必要があります。
棚卸で見る順番
| 確認 | 見るもの | 判断 |
|---|---|---|
| 対象ID | 個人ID、共有ID、作業用ID | 利用者を特定できるか |
| 特殊権限 | *ALLOBJ、*SECADM、*JOBCTLなど | 業務上必要か |
| グループ | グループプロファイル | 間接的に過剰権限がないか |
| 退職・異動 | 退職者ID、異動者ID | 無効化や権限削除済みか |
| 証跡 | 承認者、理由、期限 | 監査で説明できるか |
特殊権限を外す時は、いきなり削除せず、対象業務、夜間バッチ、保守作業、外部連携、障害対応への影響を確認します。不要な権限は減らすべきですが、業務停止を起こさない順番で進めます。
権限の基礎は AS400機密保護・権限確認チェックリスト、棚卸は AS400権限・監査チェックリスト、権限付与の流れは AS400権限申請・承認フロー を確認してください。
*ALLOBJは「持っている人」より「なぜ必要か」を棚卸しします
AS400 / IBM i の特殊権限で一番注意したいのが *ALLOBJ です。全オブジェクトに触れる権限なので、担当者が長年同じだから、保守会社だから、昔から付いているから、という理由だけで残すと監査でも運用でも説明が難しくなります。棚卸では「誰が持っているか」だけでなく、どの作業のために必要か、期限はあるか、代替手段はないかを確認します。
現場では、障害対応や夜間作業のために一時的な強い権限が必要になることがあります。その場合でも、申請・承認・作業記録・解除確認をセットにしておくと、あとで「なぜこの人に強い権限が残っていたのか」を追いやすくなります。退職者ID、共用ID、外部パートナー用IDは特に残りやすいので、月次点検や保守会議の確認項目に入れておくのが安全です。
| 棚卸で見る観点 | 確認する理由 | 関連ページ |
|---|---|---|
| 申請・承認 | *ALLOBJを付けた理由と承認者を残す | AS400権限申請・承認フロー |
| 監査観点 | 退職者ID、共用ID、過剰権限をまとめて確認する | AS400権限・監査チェックリスト |
| パスワード運用 | 強い権限ほどサインオン失敗や期限切れも見ておく | AS400パスワードポリシー確認手順 |
| 月次点検 | 強い権限が残りっぱなしになっていないかを定期確認する | AS400月次点検チェックリスト |
担当交代時に*ALLOBJを棚卸しする例
担当者が異動する時は、ユーザープロファイルの直接設定だけでなく、グループや運用用IDを通じた広い権限も確認します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 付与元 | 本人、グループ、運用ID、ジョブ記述など権限の利用経路を確認する | 直接付与だけを見て完了にしない |
| 利用目的 | 必要業務、利用頻度、承認者、代替手段を確認する | 過去に必要だったという理由だけで残さない |
| 変更 | 検証、実施日時、緊急時手順、戻し条件を決める | 影響を確認せず一括削除しない |
例外として残す権限には期限と再確認日を付けます。棚卸し後は、必要な定常処理と障害対応が動き、不要な操作が許可されていないことを確認します。
関連するAS400確認ルート
*ALLOBJなどの特殊権限は、便利さよりリスクを優先して棚卸しします。誰が、なぜ、いつまで必要なのかを確認し、退職者IDや共有IDを残さない運用にします。
特殊権限の確認は画面と理由をセットで見る
*ALLOBJ の棚卸では、WRKUSRPRF や DSPUSRPRF で権限の有無を見るだけでは不十分です。実際には、なぜ必要なのか、いつ付与したのか、作業が終わった後も残してよいのかを確認します。特に共有IDや保守会社用IDは、担当者が変わっても権限だけ残りやすいため注意します。
| 確認対象 | 見るポイント | 判断例 |
|---|---|---|
| 個人ID | 本人の業務範囲と一致しているか | 通常業務に不要なら権限縮小を検討 |
| 共有ID | 誰が使ったか追える運用か | 作業記録が残らないなら利用方法を見直す |
| 保守用ID | 契約範囲、利用期限、作業承認があるか | 常時有効ではなく作業時だけ有効化する |
| 退職・異動者ID | 無効化、権限削除、所有物の引き継ぎが済んでいるか | 棚卸の最優先対象にする |
削除ではなく段階的な縮小で進める
強い権限をいきなり外すと、夜間バッチ、障害対応、保守作業が止まることがあります。まずは利用実態、対象業務、代替権限を確認し、一時権限化、作業時だけ有効化、承認制への変更など、段階的にリスクを下げる方が現実的です。
