第11回
【記入例つき】SCS評価制度 4-1-1 ユーザーIDの管理
退職した社員のIDが残っていても、たいてい誰も気づきません。4-1-1は、IDの発行・変更・削除を申請・承認制にし、1人1つを原則として、使われなくなったIDと権限をすぐ閉じる項目です。IDaaSを入れても、申請と承認の手続きそのものは自前で決めることになります。
目次
4-1-1-1 自社の役員、従業員、派遣社員及び受け入れ出向者に対するユーザIDの付与・変更・削除は申請・承認制にすること。
4-1-1-2 ユーザIDの共有について、以下のいずれかを適用すること。
・ユーザIDを共有しない
・やむを得ず共有IDが必要な場合（例えば、システムの仕様により、使用人数分のユーザIDを発行することができない場合）は、共有IDを利用したユーザを特定できるようにする。
4-1-1-3 ユーザIDが不要になった場合（例えば、ユーザが組織を退職した場合又はユーザIDが一定期間使用されなかった場合）、速やかにユーザIDを削除または無効化すること。
4-1-1-4 ユーザ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
なぜ必要か
今回は、社員などが使うユーザIDの管理を扱います。
ユーザIDは、システムや情報に入るための「鍵」です。退職した社員のIDが残っていたり、1つのIDを複数人で使い回していたりすると、不正にログインされても気づけず、誰が操作したのかも分かりません。退職者のIDを悪用した不正アクセスは、内部不正の代表的な手口の一つです。
そこで、IDの付与・変更・削除を申請・承認制にして記録を残し（4-1-1-1）、IDは1人1つを原則とし（4-1-1-2）、不要になったIDやアクセス権はすぐに削除・無効化する（4-1-1-3、4-1-1-4）ことが求められています。
文書・体制強化orツール導入のどちらに該当するか
文書・体制強化とツール導入の、どちらでも対応できます。
ツールでは、IDaaS（IDの管理やシングルサインオンをまとめて行うクラウドサービス）が使えます。IDaaSでIDを一元管理すると、退職時にIDaaSのアカウントを止めるだけで、連携しているクラウドサービスにまとめてログインできなくなるため、4-1-1-3の対応に役立ちます。詳しくは販売店にお問い合わせください。
- 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/
なお、IDaaSと連携していないシステム（社内のファイルサーバーなど）は、個別に削除・無効化が必要です。また、申請・承認の手続（4-1-1-1）や共有IDの扱い（4-1-1-2）は、ツールを導入した場合でも文書・体制として整備する必要があります。
用意するモノ
- 一般ユーザID管理台帳（独自のひな形）
- 一般共有ID利用者特定台帳（独自のひな形）
- 情報セキュリティ関連規定（IPA付録5）
https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_5.docx
実際の実施手順
4-1-1-1、4-1-1-2、4-1-1-3、4-1-1-4
①情報セキュリティ関連規定の確認と追記
情報セキュリティ関連規定5〜6ページ「6. アクセス制御及び認証」を確認します。4-1-1の各要求事項は、次の箇所に対応しています。
- 4-1-1-1（申請・承認制）：6.3 利用者アカウントの登録、6.4 利用者アカウントの管理
- 4-1-1-2（IDの共有）：6.2.1 認証に関する基本方針
- 4-1-1-3（不要なIDの削除）：6.4 利用者アカウントの管理
- 4-1-1-4（不要なアクセス権の削除）：6.1 アクセス制御方針
※情報セキュリティ関連規定の例文では「社外秘又は極秘の情報資産を扱う社内情報システム」となっていますが、4-1-1-2では対象を限定していないため、「業務で利用する情報システム（クラウドサービスを含む）」に修正します。
ただし、IPAの規定のままでは、IDの「変更」の申請・承認、一定期間使われていないIDの扱い、不要になったアクセス権の削除が書かれていません。以下のとおり追記・修正しましょう。
【6.1 アクセス制御方針】に追記
●異動等によりアクセス権が不要になった場合は、速やかに当該アクセス権を削除又は無効化する。
【6.2.1 認証に関する基本方針】の括弧書きを修正
（やむを得ず共有IDが必要な場合は、「一般共有ID利用者特定台帳」により、共有IDを利用したユーザーを特定できるようにする）
【6.3 利用者アカウントの登録】に追記
●利用者アカウントの付与・変更・削除は申請・承認制とし、その記録を「一般ユーザID管理台帳」に残す。
【6.4 利用者アカウントの管理】に追記
●退職・異動のほか、●日以上使用されていないアカウントも不要と判断する。
「●日」は、90日など、自社で実際に確認できる期間にしましょう。
4-1-1-1、4-1-1-3、4-1-1-4
②一般ユーザID管理台帳への記入
社員ごとに、利用しているシステムのユーザIDとアクセス権を「一般ユーザID管理台帳」に記入し、付与・変更・削除のたびに申請日と承認者を記録します。この記録が、申請・承認制で運用していることの証跡になります。役員や派遣社員、受け入れ出向者のIDも対象です。
退職や異動のときは、この台帳で対象者のIDとアクセス権を洗い出し、削除・無効化します。退職時は、規定22ページ「2. 人的対策」の「3. 雇用の終了」にある退職時のチェックリストで、ID（アクセス権）の返却まで確認しましょう。
一定期間使われていないIDは、Microsoft 365やActive Directoryなどの管理画面で最終ログイン日を確認すると洗い出せます。
4-1-1-2
③一般共有ID利用者特定台帳への記入
IDは1人1つが原則です。システムの仕様で人数分のIDを発行できないなど、やむを得ず共有IDを使う場合は、「一般共有ID利用者特定台帳」に共有IDの名前、共有が必要な理由、利用者、利用日時などを記録し、誰が使ったかを特定できるようにします。
最後に
今回から「攻撃等の防御」に入ります。SCS評価制度☆3の26項目のうち、半分の13項目を占める分野です。長くなりますが、一緒に頑張りましょう。