第12回
【記入例つき】SCS評価制度 4-1-2 管理者IDの管理
管理者IDは、設定の変更もデータの削除も新しいIDの発行もできる、いわばマスターキーです。攻撃者が侵入したあとに狙うのもここ。4-1-2は、持つ人を絞り、権限を絞り、誰が持っているかを台帳で把握しておく項目です。やること自体は前回とほぼ同じです。
目次
4-1-2-1 すべてのサーバ及びネットワーク機器について、システム管理者及び責任者を定めること。
4-1-2-2 管理者権限を付与する役員、従業員、派遣社員及び受入出向者を限定したうえで、管理者IDについて以下のいずれかを適用すること。
・管理者IDを共有しない。
・やむを得ず管理者IDの共有が必要な場合(例えば、システムの仕様により、使用人数分のIDを発行することができない場合)は、共有の管理者IDを利用したユーザを特定できるようにすること。
4-1-2-3 各管理者IDに対して当該IDの用途に応じた必要最低限の権限のみを付与すること。
4-1-2-4 開発環境を利用する役員、従業員、派遣社員及び受入出向者が本番環境において、開発環境における管理者権限で操作できないようにすること。
4-1-2-5 組織内でどの役員、従業員、派遣社員及び受入出向者が管理者IDを持っているかを把握するための仕組みを整備すること。
4-1-2-6 管理者IDが不要になった場合(例えば、管理者が組織を退職した場合及び管理者IDが一定期間使用されなかった場合)、速やかに管理者IDを削除又は無効化すること。
4-1-2-7 管理者IDの付与・変更・削除は申請・承認制にすること。
4-1-2-8 管理者IDの付与・変更・削除並びにサーバ及びネットワーク機器の設定内容の変更を行う権限を業務上必要な役員、従業員、派遣社員及び受入出向者に限定すること。
https://www.ipa.go.jp/security/scs/rcu1hd0000007a2i-att/20260327001-c.xlsx(2026年9月時点)
はじめに
本解説記事では、IPA(独立行政法人 情報処理推進機構)が公開する「中小企業の情報セキュリティ対策ガイドライン 第4.0版」の付録をベースに、各要求事項を満たすことを基本方針とします。
ただし、付録だけでは満たせない要求事項については、その項目に限り付録の拡張、または独自のひな形の新規作成によって対応します。
なお、すでに自社で情報セキュリティ関連の規程や台帳をお持ちの場合は、ゼロから作り直す必要はありません。
本記事で解説する各要求事項と照らし合わせながら、既存の文書に不足している記載を追記・修正していただければ十分です。
https://www.ipa.go.jp/security/guide/sme/about.html
なぜ必要か
前回(第11回)は、社員などが使う一般ユーザIDの管理を扱いました。今回は、サーバやネットワーク機器、クラウドサービスの設定を変更できる「管理者ID」(管理者権限を持つアカウント)を扱います。
管理者IDは、設定の変更やデータの削除、新しいIDの作成まで何でもできる、いわば「マスターキー」です。攻撃者は侵入した後、管理者IDを奪って被害を広げようとします。退職した担当者の管理者IDや、皆で使い回している「admin」が残っていると、悪用されても誰の操作か分かりません。
やることは前回とほぼ同じで、管理者IDを申請・承認制で付与し(4-1-2-7)、共有せず(4-1-2-2)、不要になったら削除・無効化します(4-1-2-6)。そのうえで、管理者IDを持つ人と権限を必要最低限に絞り(4-1-2-2、4-1-2-3、4-1-2-8)、誰が持っているかを把握する(4-1-2-5)ことが求められています。
文書・体制強化orツール導入のどちらに該当するか
文書・体制強化とツール導入の、どちらでも対応できます。
ツールでは、IDaaS(IDの管理やシングルサインオンをまとめて行うクラウドサービス)が使えます。IDaaSと連携しているクラウドサービスであれば、管理者が退職したときにIDaaSのアカウントを止めるだけで管理画面にもログインできなくなるため、4-1-2-6の対応に役立ちます。詳しくは販売店にお問い合わせください。
- LANSCOPE IDアクセスマネージャー
https://www.lanscope.jp/id-access-manager/ - HENNGE One
https://hennge.com/jp/service/one/ - Soliton OneGate
https://www.soliton.co.jp/products/onegate/
なお、サーバやネットワーク機器の管理者ID(administratorやadminなど、機器ごとに作るID)は、IDaaSでは管理できないことが多いため、台帳での管理が必要です。また、申請・承認の手続(4-1-2-7)や、管理者権限を持つ人の限定(4-1-2-2、4-1-2-8)は、ツールを導入した場合でも文書・体制として整備する必要があります。
用意するモノ
- 情報資産管理台帳(IPA付録6)+拡張版
- 情報セキュリティ関連規定(IPA付録5)
https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_5.docx
情報資産管理台帳(拡張版)は、tetsato氏のnote『ゼロから作る脆弱性管理台帳』および『サプライチェーンセキュリティ(SCS)評価制度★3対応、資産管理台帳の拡張手順』に掲載されている台帳を使用します。作り方は氏のnoteをご参照ください。
ゼロから作る脆弱性管理台帳
https://note.com/tetsato/n/ne381cade25d2
サプライチェーンセキュリティ(SCS)評価制度☆3対応、あと8か月。まず何から始めるか
https://note.com/tetsato/n/necee450e60bf
tetsato氏はCISSP・情報処理安全確保支援士として、SCS以外にもサイバーセキュリティに関する記事を発信していますので、あわせて一読をおすすめします。
https://www.msgks.com/
実際の実施手順
4-1-2-1
①サーバ・ネットワーク機器の管理者と責任者の確認
4-1-2-1では、すべてのサーバとネットワーク機器について、システム管理者と責任者を決めることが求められています。第7回・第8回で作成したハードウェア台帳・ネットワーク機器台帳に、機器ごとの管理者と責任者を記入していれば満たせます。まだの場合は、第7回・第8回を参考に記入しておきましょう。
情報セキュリティ関連規定でも、41ページ「3.1 管理体制」で、IT基盤(サーバやネットワーク機器など)の担当者をシステム管理者、責任者を情報セキュリティ責任者と定めています。
4-1-2-2〜4-1-2-8
②情報セキュリティ関連規定の確認と追記
情報セキュリティ関連規定7ページ「6.7 特権アカウント」を確認します。特権アカウントとは管理者IDのことで、4-1-2の各要求事項は次の箇所に対応しています。
- 4-1-2-2、4-1-2-3(付与する人の限定、必要最低限の権限):「付与対象を業務上必要な従業員および従業員以外の者に限定し、役割に応じた必要最低限の権限のみを付与する」
- 4-1-2-5、4-1-2-8(保有者の把握、設定変更権限の限定):「組織内で特権アカウントを保有する者を一覧化して正確に把握し、特権アカウントや、サーバーやネットワーク機器の設定変更権限を必要最低限の者に限定する」
- 4-1-2-4(開発担当者の本番環境での操作):「システム開発を担当する者が本番環境において特権/管理者権限で操作を行うことを禁止する」
- 4-1-2-7(申請・承認制):「特権アカウントの付与・変更・削除は情報セキュリティ責任者及びシステム管理者の承認を必要とする」
- 4-1-2-6(不要な管理者IDの削除):「特権アカウントが不要になった場合(中略)、速やかに特権アカウントを削除又は無効化する」
ただし、IPAの規定のままでは、申請と記録の残し方(4-1-2-7)と、「一定期間」の具体的な日数(4-1-2-6)が書かれていません。また、管理者IDの共有(4-1-2-2)は、6.10の表(「1つの特権アカウント名を2名以上で共用しない」)と6.2.2(共有アカウントはアクセスログで使用者を特定する)に分かれて書かれており、6.2.2は社外秘・極秘の情報を扱うシステムに限られています。以下のとおり、6.7に追記・修正しましょう。
【6.7 特権アカウント】に追記
●特権アカウントは共有しない。やむを得ず共有する場合は、「管理者ID台帳」に使用者を特定する方法を記録し、共有の特権アカウントを使用した者を特定できるようにする。
【6.7 特権アカウント】の付与・変更・削除の項目を修正
●特権アカウントの付与・変更・削除は申請・承認制とし、情報セキュリティ責任者及びシステム管理者の承認を得て、その記録を「管理者ID台帳」に残す。
【6.7 特権アカウント】の「一定期間」を日数に修正
●特権アカウントが不要になった場合(例えば、管理者が組織を退職した場合及びIDが●日以上使用されなかった場合)、速やかに特権アカウントを削除又は無効化する。
「●日」は、第11回で一般ユーザIDに決めた日数とそろえておくと管理しやすくなります。
なお、4-1-2-4は、自社でシステム開発を行っていない場合は対象となる開発環境がありません。開発を行っている場合は、開発担当者に本番環境の管理者IDを付与しないようにしましょう。
4-1-2-2、4-1-2-3、4-1-2-5、4-1-2-6、4-1-2-7
③管理者ID台帳への記入
情報資産管理台帳(拡張版)の「管理者ID台帳」に、サーバやネットワーク機器、クラウドサービスなどの管理者IDを1つずつ記入します。この台帳が、誰が管理者IDを持っているかを把握する仕組み(4-1-2-5)になります。機器を導入したときから設定されている管理者ID(adminなど)も対象です。
記入のポイントは次のとおりです。
- 権限内容:IDの用途に必要な権限だけを付与し、その内容を記入します(4-1-2-3)。例えば、Microsoft 365でユーザーの追加・削除だけを担当する人には、全体管理者ではなくユーザー管理者の権限を付与します。
- アカウント種別・個人特定方法:共有の管理者IDは「共有アカウント」とし、誰が使ったかを特定する方法を記入します(4-1-2-2)。専用ツールがない場合は、第11回の「一般共有ID利用者特定台帳」と同じように利用記録を残しましょう。
- 付与日・申請内容・承認者:付与や変更のたびに記録します。この記録が、申請・承認制で運用している証跡になります(4-1-2-7)。
- 無効化日・無効化根拠・無効化承認者:退職や異動、一定期間使われていない管理者IDは削除・無効化し、記録します(4-1-2-6)。最終ログイン日は、各システムの管理画面で確認できます。
台帳の行は削除せず、無効化したときはステータスと無効化の情報だけを更新します。
最後に
管理者IDは、乗っ取られると被害が社内全体に広がるアカウントです。まずは今ある管理者IDを管理者ID台帳に洗い出し、使っていないIDや共有しているIDがないかを確認するところから始めてみてください。