「いま誰が何に入れるか」を答えようとして、メール、会計、クラウドストレージ、Webサイト管理の一覧が別々にあると、利用者や管理者を追いにくくなります。まずサービスとアカウントの担当・用途・権限・最終確認日を一枚の台帳で見渡します。この記事は現在利用するアカウントの継続確認に絞り、退職時の停止や多要素認証の設定手順は別記事へ分けます。
IPAの中小企業の情報セキュリティ対策ガイドライン第4.0版は、ユーザーID・管理者IDの発行、変更、削除の手順と、必要最小限の割り当てを求めています。共有IDはなるべく避け、やむを得ず使う場合は利用者を特定できる運用を示しています。以下の台帳項目は、その考え方を小規模組織で実施するための本記事の提案であり、IPAの指定様式ではありません。
1. サービスを先に列挙し、担当を決める
最初に業務で使うサービスを洗い出します。請求、顧客対応、社内文書、サイト公開など、止まると影響が大きいものから始めます。利用部門だけでなく、管理者、外部委託先、復旧窓口があるかも記します。組織で承認された管理画面や契約台帳と照合し、記憶だけで「全件」としません。
| 台帳の列 | 記入する内容 |
|---|---|
| サービス・用途 | 何の業務に使うか。製品名だけで終えない |
| アカウント区分 | 個人用、管理用、サービス用など |
| 責任者 | 確認と承認をする担当者 |
| 利用者・委託先 | 現在使う人・委託先の管理担当 |
| 権限と必要理由 | 管理権限の要否を説明できる範囲で記す |
| 状態 | 利用中、要確認、停止候補など。未確認を利用中と断定しない |
| 最終確認日・次回確認日 | 台帳と管理画面を照合した日付、次回の予定 |
パスワード、回復コード、秘密鍵、認証用QRコードは台帳に書きません。 人名やアカウント名を含む実台帳は公開せず、組織のアクセス制御がある場所へ保管します。
2. 管理者と休眠候補を分けて確認する
管理者アカウントは一般利用者と分け、誰が承認して使うか、業務上必要かを確認します。最終ログイン日時だけで休眠・不要とは判断しません。定期処理や障害対応に使うアカウントは、利用頻度が低くても必要な場合があります。対象システムの所有者に用途を確認し、停止は影響を調べた後、承認された変更手順で行います。
退職や異動に伴う停止確認は退職者アカウントの確認表を利用してください。多要素認証の対象や復旧担当を決める場合は導入前確認表へ進みます。本記事の台帳は、その両方へ渡す前の現状整理です。
3. 未確認を隠さず、次の担当へ渡す
次は説明用の架空の台帳例です。実在企業のアカウントや監査結果ではありません。
| サービス | 区分 | 状態 | 次の担当・期限 |
|---|---|---|---|
| 業務用クラウドA | 個人用 | 利用者の在籍と権限を要確認 | 業務責任者が確認日を決める |
| 運用管理サービスB | 管理用 | 用途を確認済み、予備担当は未確認 | システム責任者へ照会する |
| 自動処理C | サービス用 | 利用頻度が低い。停止判断は保留 | 運用担当が依存先を調べる |
「要確認」を残すことは失敗ではありません。誰がいつ管理画面や契約情報で確かめるかを決めれば、台帳は次の作業に使えます。外部の相談先へ共有する場合も、実際のアカウント一覧ではなく課題の要約と共有範囲を検討します。セキュリティ相談準備シートには、確認できた範囲と未決事項を整理できます。
まとめ
最初から完璧な台帳を目指すより、重要なサービスから責任者・用途・権限・確認日を揃えます。休眠候補は推測で削除せず、管理者と利用者の確認を経て扱います。未確認項目が残ったらセキュリティ相談準備シートへまとめ、次の担当を決めてください。
