SCS評価制度の要求事項4-1-2「管理者IDの管理手続」とは：管理者を絞り、最小限の権限にして、持っている人を把握する8項目

4-1-2は何を求めているか：評価基準8項目の中身

要求事項4-1-2の原文は、「管理者IDの発行・変更・削除の手続を定めること。」の1文です。何をすれば満たしたことになるかは、8つの評価基準に分けて書かれています（ ★3・★4 要求事項・評価基準 、経済産業省・IPA、2026年3月27日版）。

8項目とも★3の段階から求められ、★4で増える項目はありません。内容を要約すると次のとおりです。

大分類「攻撃等の防御」の中分類「アイデンティティ管理、認証、アクセス制御」に含まれます。★3と★4の違い、取引先に何を確認するかは SCS評価制度とは にまとめています。

この項目で用意するもの（★3）

4-1-2で用意するものは、2つの一覧と1つの手続です。

• 一覧：サーバとネットワーク機器（ルーターなど）ごとの、システム管理者と責任者（4-1-2-1）
• 一覧：管理者ID（機器やサーバの設定を変えられるアカウント）を持っている人と、その権限の範囲（4-1-2-3、4-1-2-5）
• 文書：管理者IDの付与・変更・削除の申請と承認の手続（4-1-2-6、4-1-2-7）

8項目と数は多いものの、中身は「誰が管理者か決める」「権限を絞る」「持っている人を把握する」「要らなくなったら消す」の4つにまとまります（編集部の整理）。

落とし穴1：管理者でも、すべての権限を持たせない

管理者IDを持つ人にも、仕事に必要な分の権限だけを渡します。

4-1-2-3（最小限の権限）は、各管理者IDに用途に応じた必要最低限の権限だけを付与することを求めています。たとえば、バックアップの担当にはバックアップの権限だけを与える形です（編集部の記入例）。

権限を持つ人が長く同じ立場にいることも、リスクとして扱われています。顧客情報の不正持ち出しを公表した NTT西日本グループ は、再発防止策として、特権アカウントを持つ長期配置者の人事異動や権限削除を進めていると報告しています。

落とし穴2：共有の管理者IDは、使った人を特定できるようにする

管理者IDは、使う人ごとに分けるのが原則です。

4-1-2-2（管理者を絞り、IDを共有しない）は、管理者権限を持つ人を限定したうえで、管理者IDを共有しないことを求めています。やむを得ず共有する場合は、共有の管理者IDを使ったユーザーを特定できるようにします。

社外の保守会社に作業を頼む場合も、保守会社の担当者ごとにIDを発行すれば、誰が何をしたかを追えます（編集部の記入例）。

落とし穴3：開発環境がない会社では、4-1-2-4は当てはまらない

自社でシステムを開発していない会社なら、4-1-2-4は気にしなくてかまいません。

4-1-2-4（開発環境と本番環境の分離）は、開発環境を使う人が、本番環境で開発環境の管理者権限を使えないようにすることを求めています。開発環境を持たない会社では、この項目に当てはまる操作がありません（編集部の読み方）。

進め方（30人規模の記入例）

編集部の記入例です。数字や名称は、自社で決めます。

1. サーバ・ネットワーク機器ごとに、システム管理者と責任者の氏名を一覧にする
2. 管理者権限を持つ人を決める（例：IT担当2名と、社外の保守会社1名。いずれも個人ごとのID）
3. IDごとに、用途に必要な最小限の権限を書く
4. 付与・変更・削除は申請と承認を経る
5. 管理者IDの一覧を年1回以上見直し、退職者や使っていないIDを削除する（削除は「速やかに」。日数は自社で決める）