退職した社員のIDが半年後も有効なまま放置されていた――そんな話を「他社事例」として笑えない中小企業は多いはずです。情報セキュリティインシデントの原因として「元従業員による不正アクセス」「内部関係者の権限悪用」が繰り返し報告されており、特に人事異動が集中する3〜4月はID管理の穴が狙われやすい時期です。
「パスワード管理やウイルス対策はやっている。でもIDの棚卸しまでは手が回っていない」という情シス担当者は少なくありません。しかし、ID管理の甘さはファイアウォールを突破するより簡単に、組織の内側への扉を開けてしまいます。
この記事では、情シス1人体制の中小企業でも今日から動けるID管理の基礎から、退職者アカウントの確実な停止フロー、最小権限の原則の現場への落とし込み方まで、具体的なステップで解説します。

ID管理(アイデンティティ管理)とは?なぜ今すぐ取り組む必要があるのか
ID管理とは、社内外のシステムやサービスへのアクセス権を「誰が」「何の目的で」「どの範囲まで」持つかを適切に管理・制御することです。英語では「IAM(Identity and Access Management)」と呼ばれます。
なぜID管理が重要かというと、攻撃者がシステムに侵入する際の最も有効な手口が「正規アカウントの悪用」だからです。フィッシングで奪った認証情報、放置された退職者アカウント、パスワードが変更されていない共有IDなど、「正しいIDとパスワードでログイン」されてしまえば、多くのセキュリティ機器は警告を上げません。
特に中小企業では以下のリスクが重なりやすい状況があります。
・退職者アカウントの放置: 人事部門とIT部門の連携不足で、削除処理が漏れる
・権限の肥大化: 「とりあえず管理者権限を付与」が横行し、本来不要な権限が残り続ける
・共有アカウントの常態化: 誰がいつ何をしたか追跡できなくなる
・外部委託先IDの管理忘れ: 契約終了後も保守ベンダーのIDが生きている
こうしたリスクは「気をつけていれば防げる」レベルではなく、仕組みとして対応しないと必ず穴が残ります。
中小企業でよく見かける「危険なID管理」の実態
実際に中小企業の情シス担当者から聞く話の中で、特に危険度が高いパターンを紹介します。
【危険例1】退職してから3ヶ月後に「そういえば」と気づく
退職者が出るたびに「ITへの連絡」が後回しになるケースは珍しくありません。特に中途採用が多い企業や、人事担当者が兼任体制の場合、アカウント停止の通知がそもそもIT部門に届かないことがあります。
メールアカウント・VPNアクセス・業務システムのIDが退職後も生き続けているケースは、中小企業の情報漏洩事故の一因として実際に報告されています。不正利用される前に気づけたとしても、「いつからアクセス可能だったか」の追跡に膨大な工数がかかります。
【危険例2】「管理者権限を付けておけば問題ない」という発想
業務の効率化を優先するあまり、多くのメンバーに管理者権限を付与してしまうことがあります。権限が広すぎると、意図せず重要ファイルを削除したり、設定を誤って変更したりするリスクが高まります。また、そのアカウントが攻撃者に奪われた場合の被害範囲も格段に広がります。
「管理者でないと業務が止まる」と感じている場合、多くはシステム設計か運用フローの問題です。権限を絞ることで業務が止まるなら、そのシステムの権限設計を見直すべきタイミングです。
【危険例3】パスワードをメモ帳・Excelで共有している
「Excelや紙のメモに全員共通のパスワードを記載して共有している」という組織はいまだに存在します。この状態では誰が何をしたか追跡できず、パスワードが漏洩した場合の被害特定も困難です。共有アカウントは便利ですが、アクセスログとしての証跡が残らないため、インシデント発生後の調査を大幅に困難にします。
退職者アカウントを確実に停止するための手順
「退職が決まったら即削除」では業務引き継ぎに支障が出ることもあります。段階的に対応するフローを整備しておくことが重要です。
1. 退職確定時(退職日2週間前まで)にやること
・対象アカウントのリストアップ: メール・VPN・業務システム・クラウドサービス・Slack・共有ドライブなど、本人が使用しているすべてのIDを洗い出す
・業務引き継ぎアクセスの確認: 退職日まで必要なアクセス範囲を確認し、不要な権限は先に剥奪する
・引き継ぎ先の確認: 退職者が「管理者」「担当者」として登録されているシステムの引き継ぎ先を決める
2. 退職当日にやること
・全アカウントの無効化(削除ではなく無効化が安全): すぐに削除すると業務継続性に影響する場合があるため、まず無効化・ロックをかける
・会社支給デバイスの回収と初期化確認: スマートフォン・PCのリモートワイプや初期化確認も同日に実施する
・共有パスワードの変更: 退職者が知っていた可能性のある共有パスワード(Wi-Fiパスワード、共有ツールの認証情報など)をすべて変更する
3. 退職翌週(1週間以内)にやること
・アカウント削除の実行: 無効化から7日間問題がなければ削除処理を行う(メールは規定に従いアーカイブ)
・外部委託先IDの確認: 退職者経由で付与されていた外部ベンダーのアクセス権がないか確認する
・台帳の更新: ID管理台帳から退職者のエントリを削除または無効化済みに更新する
Windows環境でActive Directoryを使っている場合、以下のコマンドで無効化と削除を安全に行えます。
# ユーザーアカウントを無効化(削除はしない) Disable-ADAccount -Identity "yamada.taro" # 無効化後の状態確認 Get-ADUser -Identity "yamada.taro" | Select Name, Enabled # 7日後、問題がなければ削除する Remove-ADUser -Identity "yamada.taro"
Linux環境でローカルアカウントを管理している場合は次のように操作します。
# アカウントをロック(パスワードをロック状態にする) sudo usermod -L yamada # sudoersから除外されていることを確認 sudo grep yamada /etc/sudoers /etc/sudoers.d/* # 7日後に削除する(ホームディレクトリも削除する場合は -r を付ける) sudo userdel -r yamada
最小権限の原則を現場に落とし込む3ステップ
「最小権限の原則(Principle of Least Privilege)」とは、ユーザーが業務に必要な最低限の権限だけを持つべきという考え方です。シンプルに聞こえますが、実際に実装するには手順が必要です。
1. 権限台帳(IDリスト)を作る
まず、組織内のすべてのIDと権限を一覧化した台帳を作成します。Excelでも構いません。以下の項目を含めることを推奨します。
| 項目 | 記載内容の例 |
|---|---|
| 氏名・所属 | 山田太郎 / 営業部 |
| 雇用形態 | 正社員 / 派遣 / 外部委託 |
| 使用システム | AD, メール, kintone, Box, Slack など |
| 権限レベル | 一般ユーザー / 閲覧のみ / 管理者 |
| 権限付与日 | 2025-04-01 |
| 最終確認日 | 2025-10-01 |
| 備考 | 産休中のため一時停止中 など |
台帳は「完璧なものを作る」必要はありません。まず現状を見える化することが最優先です。システムの管理コンソールからユーザー一覧をエクスポートするだけでも、棚卸しの出発点になります。
2. 「本当に必要な権限だけ」を再設定する
台帳が完成したら、各ユーザーの業務内容と実際の権限レベルを照合します。以下の3つの問いに答えられない権限は、絞り込みの対象です。
・この人はなぜ管理者権限が必要なのか? 説明できない場合は一般ユーザーに降格する
・この権限は今も使われているか? 最終ログインが90日以上前なら棚卸し対象にする
・プロジェクト終了後も権限が残っていないか? 一時的に付与した権限の削除忘れは頻出ミス
「権限を絞ったら業務が止まった」という事態を防ぐため、変更前に当該ユーザーへの事前確認と、変更後72時間の監視期間を設けることをお勧めします。
3. 定期的な棚卸しを仕組みとして行う(年2回が目安)
権限棚卸しは一度やって終わりではありません。年2回(4月と10月)を目安に、台帳の内容を現状と照合する定例作業を設けましょう。
人事部門から毎月「入退社・異動者リスト」をIT部門に共有する仕組みを作るだけで、退職者アカウント放置の大半は防げます。フォーマットは問いません。メール1本でも構いません。「IT部門への連絡」を人事プロセスの一部として組み込むことが、最も低コストで効果の高い対策です。
低コストで使える主なID管理ツールの比較
中小企業が最初から専用のIAMツールを導入する必要はありません。すでに使っているツールの管理機能を活用するだけでも、大幅に改善できます。
| ツール | 費用 | 主な機能 | 向いているケース |
|---|---|---|---|
| Microsoft Entra ID(旧Azure AD) | Microsoft 365に含む | SSO、条件付きアクセス、ユーザー管理、MFA | Microsoft 365利用企業 |
| Google Workspace管理コンソール | Google Workspaceに含む | ユーザー一括管理、ログイン監査、2段階認証強制 | Google Workspace利用企業 |
| Okta(Free Tier) | 小規模は無料枠あり | シングルサインオン(SSO)、MFA統合 | 複数SaaSを利用する企業 |
| Excelベースの台帳 | 無料 | シンプルなID棚卸し | まず現状把握したい初期段階 |
Microsoft 365 または Google Workspace を使っている企業であれば、追加コストなしでかなりの部分をカバーできます。まずは管理コンソールの「ユーザー一覧」から全員のアカウント状態を確認するところから始めてみてください。
なお、Linuxサーバーの権限管理については、姉妹サイトLinuxMaster.JPでsudo・chownを使ったアクセス制御の実践的な方法を詳しく解説しています。
よくある誤解と注意点
【誤解1】「中小企業は狙われない」
規模が小さいほど防御が薄いため、標的にされやすいという現実があります。大企業に侵入するためのステップとして、取引先の中小企業を踏み台にするサプライチェーン攻撃も確認されています。「うちは狙われない」という前提は、リスクの過小評価につながる最も危険な思い込みです。
【誤解2】「アカウント削除すればすべて終わり」
退職者のアカウントを削除しても、そのメールアドレスや認証情報が外部サービス(個人利用のSaaSなど)に登録されたままになっているケースがあります。また、退職者がデータを持ち出した後のアカウント削除では手遅れです。退職プロセスの中でアクセスログの確認も組み込んでおくことが重要です。
【誤解3】「パスワードを複雑にすれば安全」
パスワードの強度だけでは、フィッシングや情報漏洩サイトからの流出には対応できません。多要素認証(MFA)との組み合わせが不可欠です。特に管理者権限を持つアカウントへのMFA適用は、他のどの対策よりも優先して実施してください。
【注意】アカウント削除は「不正アクセス禁止法」と無関係ではない
退職者が自分の旧アカウントに無断でアクセスした場合、不正アクセス禁止法の対象になります。ただし、「削除しなかった側に問題がある」とは法律上ならないものの、実務上のリスクを組織側で最小化する責任があります。詳細な法的判断は法律の専門家にご確認ください。
本記事のまとめ
| 課題 | 対策 | 優先度 |
|---|---|---|
| 退職者アカウントの放置 | 退職フロー内でIT通知を義務化・当日無効化 | 高(即対応) |
| 過剰な管理者権限 | 権限台帳を作成し、業務ベースで権限を再設定 | 高(今月中に) |
| 共有アカウントの常態化 | 個人アカウントへの移行・共有パスワード廃止 | 中(3ヶ月以内) |
| 外部委託先IDの管理漏れ | 台帳に委託先IDも含め、契約終了時に停止 | 中(次回棚卸し時) |
| 権限の長期放置 | 年2回(4月・10月)の定期棚卸しを定例化 | 中(仕組みとして整備) |
| 管理者アカウントへのMFA未適用 | 管理者アカウントから優先的にMFAを有効化 | 高(即対応) |
ID管理は「一度整備すれば完成」ではなく、人の出入りに合わせて継続的にメンテナンスが必要な仕組みです。完璧なシステムを目指すより、「退職者を見逃さない」「余分な権限を持たせない」この2点から始めることで、現場のリスクを大幅に下げられます。
まず今週中にできることとして、会社のActive DirectoryまたはGoogle Workspaceの管理コンソールを開き、「最終ログインが90日以上前のアカウント」を一覧化してみてください。そこから棚卸しは始まります。
ID管理の整備、どこから手をつければいいか迷っていませんか?
退職者アカウントの棚卸しから権限設計まで、情シス1人体制の中小企業が直面するセキュリティ課題に特化した実践的なノウハウをお届けしています。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。


コメント