AS400権限申請・承認フローの作り方|過剰権限と退職者IDを増やさない

AS400 / IBM i の権限は、一度付けるとそのまま残りがちです。申請理由、対象業務、承認者、期限、退職時削除を決めずに権限を増やすと、退職者IDや過剰権限が残り、監査で説明しにくくなります。

権限申請で決める項目

項目確認すること理由
申請理由どの業務に必要か不要な権限を防ぐ
対象ユーザー、ライブラリ、ファイル、メニュー範囲を限定する
承認者業務責任者、保守責任者誰が許可したか残す
期限一時権限か恒久権限か残りっぱなしを防ぐ
削除異動・退職時の削除退職者IDを残さない

特殊権限は別扱いにする

*ALLOBJ のような強い権限は、通常のメニュー権限とは別に扱います。理由、期限、作業ログ、承認者を残し、作業後に外せるか確認します。便利だから付ける、は監査上の説明が難しくなります。

権限監査は AS400権限・監査チェックリスト、セキュリティ点検は AS400セキュリティ点検チェックリスト、退職時の確認は 引き継ぎチェックリスト を参照してください。

関連: AS400ユーザーIDロック・パスワード期限切れの確認手順|WRKUSRPRFで見るポイントもあわせて確認してください。

関連: AS400特殊権限・*ALLOBJ棚卸チェックリスト|過剰権限を放置しない確認順もあわせて確認してください。

関連するAS400確認ルート

権限申請は、作業を通すためだけでなく、過剰権限、退職者ID、監査対応を増やさないための運用です。WRKUSRPRFや特殊権限の確認と合わせて見る必要があります。

権限申請は「作業内容」と「期限」を先に決める

AS400の権限申請で危ないのは、「とりあえず見られるようにしてほしい」という依頼をそのまま通すことです。販売管理や在庫、請求に関わる画面では、参照だけなのか、更新まで必要なのかでリスクが変わります。申請時点で作業内容、対象メニュー、対象ライブラリ、必要期間を分けておくと、過剰権限を減らせます。

  • 参照だけでよい作業か、更新が必要な作業かを分ける
  • 本番・検証・開発のどの環境かを明記する
  • 一時権限なら終了日と戻し担当を決める
  • 退職者IDや異動者IDの棚卸しとセットで見る

私が現場で見てきた失敗は、申請時よりも「終わった後に戻していない」ケースです。一時的な障害対応や移行作業で強い権限を付けた場合は、作業完了後の戻し確認までを申請フローに含めるのが現実的です。

権限申請テンプレートに入れる項目

権限申請書や依頼メールには、最低限、対象者、対象業務、必要な操作、対象環境、期限、承認者を入れます。AS400 / IBM i では、ライブラリ、ファイル、メニュー、ジョブ実行、スプール参照など、必要な権限の粒度が分かれます。依頼内容が曖昧なまま進めると、結果的に広すぎる権限を付けがちです。

項目書き方の例避けたい書き方
対象業務請求締め処理の照会、在庫差異調査業務で使うため
操作範囲参照のみ、更新あり、実行のみ使えるようにする
対象環境本番、検証、開発を明記AS400全体
期限作業完了日、棚卸日、解除予定日期限なし
承認業務責任者と保守責任者を分ける担当者判断のみ

承認後の戻し確認までをフローに含める

障害対応や移行作業では、一時的に強い権限が必要になることがあります。その場合は、付与した時点で終わりにせず、作業完了後に戻したことを確認する手順まで含めます。戻し担当、確認日、確認方法を残しておくと、退職者IDや過剰権限が増えにくくなります。

定期棚卸では権限を四つに分ける

権限一覧を眺めるだけでは棚卸になりません。業務責任者へ利用目的を確認し、各権限を次の四区分に分けると、解除判断を進めやすくなります。

  • 継続:現在の担当業務で必要で、範囲も適切
  • 縮小:更新権限は不要で、参照または限定メニューだけで足りる
  • 終了:異動、退職、作業完了、期限切れで不要
  • 要確認:利用実績や承認記録がなく、その場で判断できない

要確認を自動的に継続扱いにせず、回答期限と確認者を決めます。解除前にはバッチ所有者、共有ID、外部連携など人のログイン以外で使われていないかを確認し、業務停止を避けます。