AS400権限・監査チェックリスト｜ユーザープロファイル・オブジェクト権限・退職者IDを確認する

2026.06.11

AS400 / IBM i は長く使われることが多く、業務は安定していても、ユーザープロファイル、オブジェクト権限、退職者ID、共用IDの運用が古いまま残っていることがあります。障害が起きてから見るのではなく、保守の棚卸しとして定期的に確認したい領域です。

権限確認の観点

確認見るものリスク
ユーザープロファイル使用停止、最終使用日、特殊権限退職者IDや過剰権限の残存
共用ID利用者、用途、パスワード管理誰が操作したか追えない
オブジェクト権限ライブラリ、ファイル、プログラム本番データの誤更新や参照漏れ
バッチ実行ユーザーJOBD、SBMJOB、運用手順人のIDで夜間処理が動く
監査ログ操作記録、変更履歴事故後に説明できない

特殊権限は理由と期限を持つ

*ALLOBJ のような強い権限は、持っていること自体が悪いのではなく、理由、対象者、利用場面、期限、代替策が説明できない状態が危険です。保守会社や開発担当者に付与した権限も、プロジェクト終了後に残っていないか確認します。

退職者IDと共用IDは監査で見られやすい

現場では「昔からあるIDだから」という理由で退職者IDや共用IDが残っていることがあります。障害時には便利でも、監査やインシデント時には説明が難しくなります。廃止できない場合も、用途、責任者、保管場所、利用記録を明確にします。

担当者退職時の引き継ぎは AS400後任者への引き継ぎチェックリスト、属人化対策は AS400保守会社に相談する前のチェックリスト にまとめています。保守会社を選ぶ時も、権限管理をどう扱うかは重要な確認ポイントです。

Codexに渡す情報は匿名化する

権限や監査の相談でCodexを使う場合は、ユーザー名、会社名、IP、取引先、実データを入れず、権限種別や運用パターンだけに匿名化します。AIは棚卸し観点の整理には使えますが、最終判断と権限付与は必ず人が行います。

権限棚卸しで見る項目

権限確認は、ユーザー単位ではなく業務と承認で見る

AS400の権限監査では、誰に何の権限があるかだけでなく、そのユーザーがどの業務を担当し、なぜ本番環境の権限が必要なのかを確認します。退職者、異動者、外部エンジニア、共有ユーザーは、承認と棚卸しの記録を残すべき対象です。

権限監査は退職者IDだけを見れば終わりではない

AS400 / IBM iの権限監査では、退職者IDの有無だけでなく、ユーザープロファイル、グループプロファイル、特殊権限、オブジェクト権限、ライブラリ権限、システム値をあわせて確認します。長く使っている環境ほど、過去の例外対応が残っていることがあります。

保守会社や外部パートナーへ依頼する場合も、誰にどの権限を渡すか、作業後に戻すか、監査ログを残すかを先に決めます。障害対応を急ぐ時ほど、権限を広げたままにしない運用が重要です。

退職者IDを含む権限棚卸しの例

退職者のユーザーIDを無効化するだけでなく、グループ、認可リスト、共有運用ID、スケジュールジョブへの影響を確認します。

確認点確認内容判断
利用者在籍、役割、最終利用、状態、グループ所属を確認する不要IDと休職・非常用IDを区別する
権限特殊権限、重要オブジェクト、認可リスト、共有IDの利用を確認する役割に対して過剰な権限を例外のまま残さない
運用バッチ、ジョブ記述、外部接続、所有オブジェクトへの影響を確認する停止後に定常処理が失敗しないよう事前に移管する

残す例外には理由、承認者、期限、再確認日を付けます。棚卸し後は変更一覧と業務テストを確認し、単に一覧表を更新して終わらせません。

棚卸で見る順番

確認見るもの判断
対象ID個人ID、共有ID、作業用ID利用者を特定できるか
特殊権限*ALLOBJ、*SECADM、*JOBCTLなど業務上必要か
グループグループプロファイル間接的に過剰権限がないか
退職・異動退職者ID、異動者ID無効化や権限削除済みか
証跡承認者、理由、期限監査で説明できるか

特殊権限を外す時は、いきなり削除せず、対象業務、夜間バッチ、保守作業、外部連携、障害対応への影響を確認します。不要な権限は減らすべきですが、業務停止を起こさない順番で進めます。

権限不足で処理が止まっている場合はCPF9802の確認手順、期限切れやサインオン失敗はパスワードポリシー確認手順へ進んでください。定期的な棚卸しと、個別障害への権限変更は分けて判断します。

*ALLOBJは「持っている人」より「なぜ必要か」を棚卸しします

AS400 / IBM i の特殊権限で一番注意したいのが *ALLOBJ です。全オブジェクトに触れる権限なので、担当者が長年同じだから、保守会社だから、昔から付いているから、という理由だけで残すと監査でも運用でも説明が難しくなります。棚卸では「誰が持っているか」だけでなく、どの作業のために必要か、期限はあるか、代替手段はないかを確認します。

現場では、障害対応や夜間作業のために一時的な強い権限が必要になることがあります。その場合でも、申請・承認・作業記録・解除確認をセットにしておくと、あとで「なぜこの人に強い権限が残っていたのか」を追いやすくなります。退職者ID、共用ID、外部パートナー用IDは特に残りやすいので、月次点検や保守会議の確認項目に入れておくのが安全です。

棚卸で見る観点確認する理由確認先・記録
申請・承認*ALLOBJを付けた理由と承認者を残す自社の権限申請書・承認記録
監査観点退職者ID、共用ID、過剰権限をまとめて確認するこの記事の退職者ID・共有IDの確認表
パスワード運用強い権限ほどサインオン失敗や期限切れも見ておくパスワードポリシー確認手順
月次点検強い権限が残りっぱなしになっていないかを定期確認するAS400月次点検チェックリスト

担当交代時に*ALLOBJを棚卸しする例

担当者が異動する時は、ユーザープロファイルの直接設定だけでなく、グループや運用用IDを通じた広い権限も確認します。

確認点確認内容判断
付与元本人、グループ、運用ID、ジョブ記述など権限の利用経路を確認する直接付与だけを見て完了にしない
利用目的必要業務、利用頻度、承認者、代替手段を確認する過去に必要だったという理由だけで残さない
変更検証、実施日時、緊急時手順、戻し条件を決める影響を確認せず一括削除しない

例外として残す権限には期限と再確認日を付けます。棚卸し後は、必要な定常処理と障害対応が動き、不要な操作が許可されていないことを確認します。

最初に見る権限まわり

AS400の権限確認では、ユーザープロファイル、グループプロファイル、特殊権限、オブジェクト権限、ライブラリ権限を分けて考えます。初心者がいきなり権限を変更するのは危険なので、まず現状を確認し、変更が必要な場合は責任者とレビューします。

確認対象見る理由注意点
ユーザープロファイル退職者、異動者、共用ユーザーが残っていないか削除前にジョブ、所有オブジェクト、運用影響を確認する
特殊権限*ALLOBJ、*SECADM、*JOBCTLなどが強すぎないか理由なく広げない。棚卸し対象にする
ライブラリ権限本番ライブラリに誰が入れるかテスト担当が本番更新できないよう確認する
オブジェクト権限重要ファイルやプログラムへの権限業務影響が大きいため変更は慎重に行う
データ出力CSV、スプール、IFS、PC転送の扱い個人情報や金額を外へ出す時はマスキングを検討する

本番でやってはいけないこと

  • 理由なく*ALLOBJを付ける
  • 共用ユーザーで本番更新する
  • 退職者ユーザーを放置する
  • 権限エラーを避けるために全員へ強い権限を与える
  • 顧客情報を含むCSVをそのままメール添付する
  • AIや外部サービスへ本番データをそのまま渡す

本番作業全体の注意点は、AS400本番対応チェックリスト も合わせて確認してください。

データ抽出と機密情報

AS400の機密保護で見落としやすいのがデータ抽出です。画面で見るだけなら問題が小さく見えても、CSV、Excel、スプール、IFS（統合ファイルシステム）、PC転送で外へ出した時点で、情報管理の対象になります。

データ抽出をする時は、対象項目、利用目的、保存先、削除日、マスキング要否を確認します。詳しくは AS400データ抽出ガイド を参照してください。

AIに読ませる前に伏せるもの

RPGソース、CL、ジョブログ、DSPFFD結果、SQL抽出結果をAIに読ませる場合は、会社名、顧客名、ユーザー名、ライブラリ名、実データ、金額、住所、電話番号、メールアドレスを確認します。必要に応じて、サンプル名や伏せ字に置き換えます。

AI活用の注意点は、AS400のRPGソースをAIに読ませる時の注意点 にまとめています。

権限変更前のチェック

チェック内容
変更理由誰が何の作業をするために必要か
期間一時的か恒久的か、戻す日を決めたか
対象ユーザー、グループ、ライブラリ、オブジェクト
影響本番更新、データ閲覧、帳票出力、外部連携への影響
承認業務責任者、システム責任者、保守担当の確認
記録変更前、変更後、作業者、時刻、戻し手順

権限・監査とあわせて確認したい手順

権限・監査点検は、退職者IDや過剰権限だけでなく、障害時に誰が何を確認できるかまで含めて見ます。

スポンサーリンク