企業で利用するクラウドサービスや業務システムが増えるにつれて、従業員一人ひとりが持つIDやアカウントも増えています。
メール、ファイル共有、チャット、会計ソフト、顧客管理システム、勤怠管理など、業務ごとに異なるサービスを使っている企業も少なくありません。
こうした環境で、次のような状況はないでしょうか。
✖️ 社員がどのクラウドサービスを利用しているのか、すべて把握できていない
✖️ 異動した社員が、以前の部署のファイルを引き続き閲覧できる
✖️ 退職者のアカウントが、複数のサービスに残っている
✖️ 誰が管理者権限を持っているのか分からない
✖️ アカウントの発行や削除を、担当者の記憶や個別の連絡に頼っている
一つひとつは小さな管理上の問題に見えても、積み重なると情報漏えいや不正アクセスにつながるおそれがあります。
そこで重要になるのが、「ID管理（IDM）」と「IGA（Identity Governance and Administration）」 という考え方です。
今回は、これらの違いや、入社・異動・退職時に必要な管理、中小企業が無理なく取り組むための方法を解説します。
以前は、社内のパソコンやファイルサーバーなど、管理するシステムが比較的限られていた企業も多かったのではないでしょうか。
しかし現在では、Google WorkspaceやMicrosoft 365をはじめ、さまざまなクラウドサービスが日常業務に利用されています。
例えば、営業担当者一人を考えてみても、メール、オンライン会議、顧客管理、ファイル共有、経費精算、勤怠管理など、複数のサービスにアクセスする必要があります。
さらに、部署ごとに導入したサービスや、無料で利用できるWebツールまで含めると、会社全体でどれだけのアカウントが存在するのか把握しきれない場合もあります。
本当に注意したいのは、IDが増えるにつれて、管理の責任や手続きが曖昧になることです。
新入社員が入ればアカウントを追加し、担当業務が変われば新しい権限を付与します。しかし、その際に以前の権限を削除するとは限りません。
また、退職時にメールのアカウントは停止しても、営業部門が利用しているクラウドサービスや、社外とのファイル共有設定までは確認されないことがあります。
このような状態を防ぐためには、アカウントを一つずつ管理するだけでなく、社員の入社から退職までを通して、IDとアクセス権を管理する仕組み が必要になります。
なお、退職者IDや共用ID、管理者権限の基本的なリスクについては、以前のコラム「アカウント管理とは？退職者ID・共用ID・管理者権限を放置するリスク」で詳しく解説しています。
ID管理（IDM：Identity Management）とは、企業のシステムやサービスを利用する人のIDを、作成から変更、停止、削除まで管理することです。
例えば、次のような業務が含まれます。
✳️ 新入社員に必要なアカウントを発行する
✳️ 部署や役職の変更に合わせてID情報を更新する
✳️ 業務に必要なサービスの利用権限を設定する
✳️ 退職者や契約終了者のアカウントを停止・削除する
✳️ 利用されていないアカウントを確認する
これらを個別に手作業で行う場合もあれば、ID管理システムを利用して、複数のサービスに対する登録や変更を効率化する場合もあります。
ID管理に関連して、「IAM」や「SSO」という用語もよく使われます。
| 用語 | 主な役割 |
| IDM（ID管理） | IDの作成・変更・停止・削除などを管理する |
| IAM（ID・アクセス管理）；（Identity and Access Management） | 誰が本人で、どのシステムや情報にアクセスできるかを管理する |
| SSO（シングルサインオン） | 一度の認証で複数のサービスにログインできるようにする |
これらは独立したものではなく、互いに関係しています。実際の製品やサービスでは、複数の機能がまとめて提供されることもあります。
ただし、ここで注意したいのは、SSOを導入しただけで、すべてのアカウントや権限を適切に管理できるわけではない という点です。
例えば、会社の共通IDで複数のクラウドサービスにログインできても、サービス側に個別のアカウントが残っていたり、過去に与えた権限がそのままになっていたりする場合があります。
ID管理を効率化することと、権限が適切かどうかを判断することは、必ずしも同じではありません。
そこで登場するのが「IGA」です。
IGAとは、Identity Governance and Administration（アイデンティティ・ガバナンス・アンド・アドミニストレーション） の略です。
日本語では「IDガバナンス・管理」などと表現されます。
少し難しい名称ですが、簡単に言えば、IDやアクセス権を管理するだけでなく、「その権限を与えてよいのか」「今も必要なのか」を組織として判断し、確認し続ける考え方 です。
例えば、営業担当者が新しい顧客管理システムを利用する場合を考えてみましょう。
ID管理では、その社員のアカウントを作成し、システムを利用できるようにします。
一方、IGAでは、それに加えて次のような点も管理します。
✅ その社員にアクセス権を与える必要があるか
✅ 誰が権限の付与を承認するか
✅ 閲覧だけでよいのか、編集や削除まで認めるのか
✅ 担当業務が変わったとき、権限を見直しているか
✅ 定期的に権限の必要性を確認しているか
✅ 承認や変更の記録が残っているか
つまり、ID管理が「アカウントを適切に管理する」ことを中心とするのに対し、IGAでは「そのアクセス権が妥当であることを継続的に確認する」という視点が加わります。
| ① 最小権限の原則 |
従業員には、業務に必要な範囲の権限だけを付与します。
例えば、資料の閲覧だけでよい社員に、編集・削除や管理者設定の変更まで許可する必要はありません。
この「最小権限の原則」の徹底により、万が一IDが乗っ取られても被害を最小限に食い止められます。また、退職者のアカウント消し忘れ（ゴーストアカウント）による不正アクセスや、従業員による内部不正の防止にも絶大な効果を発揮します。
| ② 権限の承認と定期的な見直し |
新しく権限を付与するときには、業務上の必要性を確認し、責任者が承認します。
また、一度付与した権限も、その後の異動や担当変更によって不要になることがあります。権限を定期的に見直すことを「アクセスレビュー」と呼びます。
| ③ 管理の記録を残す |
誰が、いつ、どの権限を申請し、誰が承認したのか。後から確認できるようにしておくことも重要です。
特に、支払い処理や重要データの変更などでは、申請者と承認者を分ける「職務分掌」の考え方も必要になります。
IGAは単なるITシステムの機能ではなく、こうした社内の管理ルールとも密接に関係しています。
ID管理やIGAを考えるうえで重要なのが、従業員の入社・異動・退職に伴う管理です。
これを「IDライフサイクル管理」と呼びます。
英語では、それぞれをJoiner（入社）、Mover（異動）、Leaver（退職）と呼び、頭文字を取って「JML」と表すこともあります。
| ① 入社時｜必要な権限だけを与える |
|
このとき、設定が面倒だからといって、前任者と同じ権限をそのまま与えたり、最初から広いアクセス権を設定したりしないことが重要です。 所属部署や担当業務に応じて、必要な権限を決める仕組みを整えておきましょう。 |
| ② 異動時｜新しい権限を「追加するだけ」にしない |
|
例えば、営業部から管理部門へ異動した社員に、新しい部署のファイルへのアクセス権を追加したとします。 しかし、以前の営業部の顧客情報や営業資料へのアクセス権を削除しなければ、その社員は両方の部署の情報を閲覧できる状態になります。 このように、業務の変化に伴って不要な権限が蓄積していくことを「権限の肥大化」と呼びます。 異動時には、新しい権限を付与するだけでなく、以前の権限を残す必要があるかを必ず確認する ことが大切です。 |
| ③ 退職時｜一つのアカウント停止だけで終わらせない |
|
✴️ メールやグループウェア さらに、外部との共有設定、ログイン中のセッション、認証用のトークンなどについても、必要に応じて失効や見直しを行います。 退職時は、適切なタイミングでアクセスを停止したうえで、業務データの引き継ぎや必要な記録の保存を確認し、アカウントの削除を進めます。（デプロビジョニング） また、従業員だけでなく、外部委託先や契約社員などについても、契約終了時に同じような確認が必要です。 IPAの「中小企業の情報セキュリティ対策ガイドライン 第4.0版」でも、ユーザーID・管理者IDの発行から削除までの手続きや、異動・退職時のアクセス権の見直しが重要な対策として示されています。 |
IGAの基本になるのは、会社としてアクセス権の全体像を把握することです。
例えば、次のような状況はないでしょうか。
❎ 営業担当者が、給与情報を閲覧できる
❎ 外部委託先が、契約終了後も共有フォルダにアクセスできる
❎ 担当者が変わったのに、以前の管理者権限が残っている
❎ 必要以上に多くの社員が、顧客情報をダウンロードできる
こうした状態が必ずしも不正アクセスを意味するわけではありません。
しかし、業務上不要なアクセス権が残っていると、アカウントが乗っ取られた場合に、被害が広がる原因にもなります。
まずは、重要なシステムやクラウドサービスについて、次の項目を整理してみましょう。
| 確認項目 | 確認する内容 |
| 利用者 | 誰のアカウントか |
| 対象システム | どのサービスや情報にアクセスできるか |
| 権限の種類 | 閲覧・編集・削除・管理者など |
| 付与理由 | どの業務のために必要か |
| 承認者 | 誰が権限を認めたか |
| 最終確認日 | いつ必要性を確認したか |
すべてのシステムを一度に整理するのが難しい場合は、顧客情報、個人情報、会計情報など、重要な情報を扱うシステムから確認するとよいでしょう。
Google WorkspaceやMicrosoft 365を利用している場合には、ユーザーアカウントだけでなく、管理者権限、グループのメンバー、共有フォルダ、外部ユーザーなども確認対象になります。
具体的な設定確認については、「クラウドグループウェアのセキュリティ設定とは？中小企業が確認したい10のポイント」も参考にしてください。
ID管理やIGAは、単独で考えるセキュリティ対策ではありません。
クラウド利用やテレワーク、私物端末の業務利用が広がる中で、ほかのセキュリティ対策を適切に機能させるための土台にもなっています。
BYODとは、従業員が私物のスマートフォンやパソコンを業務に利用することです。
例えば、社員が私物スマホで会社のメールや顧客管理システムを利用している場合を考えてみましょう。
この社員が別の部署へ異動したり、退職したりした際に、適切にアクセス権を変更・停止できなければ、会社が管理していない端末から重要な情報にアクセスできる状態が残るおそれがあります。
そのため、BYOD対策では、端末の安全性だけでなく、「誰のIDで」「どの情報に」「どこまでアクセスできるか」を管理することが重要です。
ただし、ID管理だけで私物端末の安全性まで保証できるわけではありません。端末側の管理や利用ルールも組み合わせる必要があります。
詳しくは、「BYOD対策とは？私物スマホ・私物PCの業務利用をどこまで認めるべきか」で解説しています。
🔵SASE｜アクセスを制御するためのID情報が必要
SASE（Secure Access Service Edge）は、ネットワークとセキュリティの機能をクラウドなどで統合的に提供する考え方です。
例えば、社外から業務システムに接続する際、利用者や端末の状態などに応じてアクセスを制御することができます。
しかし、そもそもユーザーに不要な権限が与えられていたり、退職者のアカウントが残っていたりすれば、適切なアクセス制御を行ううえで問題になります。
IGAによって、利用者の業務に応じた適切な権限を維持することは、SASEによるアクセス制御の効果を高めることにもつながります。
SASEの基本的な仕組みについては、「SASEとは？VPNやUTMと何が違う？中小企業が知っておきたい次世代のセキュリティ対策」をご覧ください。
ゼロトラストは、社内・社外という場所だけで安全性を判断せず、アクセスの際に利用者や端末などの条件を確認する考え方です。
ここで重要になるのが、本人確認とアクセス権の管理を分けて考えることです。
多要素認証（MFA）などによって本人であることを確認できたとしても、その人が必要以上の権限を持っていれば、アクセス範囲が適切とは限りません。
「本人であることを確認する」ことと、「その人に必要な権限だけを与える」ことは、どちらも重要です。
IGAは、こうしたゼロトラストの考え方を実現するうえでも役立ちます。
ここまで読むと、「IGAを導入するには、専用のシステムを購入しなければならないのか」と感じるかもしれません。
しかし、すべての中小企業にIGA専用製品が必要というわけではありません。
IGAという考え方と、それを支援する製品の導入は分けて考えることが大切です。
例えば、従業員数が少なく、利用するサービスも限られている企業であれば、次のような方法から始めることができます。
| Excelなどでアカウント・権限管理台帳を作成する | |
| アカウント発行・変更・削除の申請と承認の手続きを決める | |
| 入社・異動・退職時のチェックリストを作成する | |
| 定期的に管理者権限や不要なアカウントを確認する | |
| 確認結果や変更履歴を記録しておく |
ただし、台帳に記載するだけでなく、実際のシステム上の権限と一致しているかを確認することが必要です。
また、Google WorkspaceやMicrosoft 365など、すでに利用しているサービスに備わっている管理機能を活用できる場合もあります。利用可能な機能は契約プランや設定によって異なります。
一方で、次のような企業では、ID管理・IGA製品による自動化を検討する価値があります。
❇️ 従業員や外部委託先が多く、アカウントの管理対象が増えている
❇️ 複数のクラウドサービスを利用し、手作業での管理が負担になっている
❇️ 入社・異動・退職が多く、権限変更の漏れが発生しやすい
❇️ 管理者権限や重要情報へのアクセスを厳格に管理したい
❇️ 監査や取引先からのセキュリティチェックに対応する必要がある
例えば、Microsoftでは「Microsoft Entra ID Governance」というサービスを提供しており、IDライフサイクル管理やアクセス権の定期レビューなどの機能が用意されています。
ただし、実際に自動化できる範囲は対象システムとの連携やライセンスによって異なります。
重要なのは、「IGA製品を導入したか」ではなく、「自社のアカウントと権限を適切に管理できているか」 ということです。
ID管理・IGAに取り組む場合、最初からすべてのシステムを統合管理する必要はありません。
まずは、現状を把握し、重要なところから段階的に整備していくことをおすすめします。
| ステップ1｜利用しているサービスを洗い出す |
|
メール、グループウェア、会計、顧客管理、勤怠管理、ファイル共有など、会社で利用しているサービスを一覧化します。 部署ごとに契約しているものや、無料サービスも確認します。 |
| ステップ2｜誰が利用しているかを確認する |
|
各サービスの利用者を確認し、退職者や利用実態のないアカウント、外部委託先のアカウントなどを洗い出します。 また、管理者権限を持つ人については、特に重点的に確認します。 |
| ステップ3｜権限が適切かを見直す |
|
業務に不要な権限が付与されていないか、異動前の権限が残っていないかなどを確認します。 権限の必要性は、IT担当者だけで判断するのではなく、業務内容を把握している部門責任者などと確認することが重要です。 |
| ステップ4｜入社・異動・退職時の手続きを決める |
|
人事担当者からIT担当者への連絡、権限付与の承認、退職時の停止・削除確認など、誰が何を行うかを明確にします。 専任の情報システム担当者がいない企業では、管理部門や経営者が役割を分担する方法も考えられます。 |
| ステップ5｜定期的な棚卸しを習慣にする |
|
アカウントや権限は、一度整理して終わりではありません。 例えば、半年に一度の全体点検を基本とし、重要なシステムや管理者権限については、より短い間隔で確認するなど、自社のリスクに応じて頻度を決めます。 異動や退職などの変更が発生した際には、定期点検を待たずに対応します。 点検を行った日、確認者、見つかった問題、実施した対応を記録しておくことで、社内の管理状況も把握しやすくなります。 |
企業のセキュリティ対策では、パスワードの強化や多要素認証、不正アクセス対策などが注目されがちです。
もちろん、それらも重要です。
しかし、本人確認が適切に行われていても、不要なアカウントや過剰なアクセス権が残っていれば、十分な対策とはいえません。
ID管理（IDM）は、アカウントを発行・変更・停止・削除するための重要な仕組みです。
そしてIGAは、さらに一歩進んで、誰にどの権限が必要なのかを判断し、承認し、継続的に見直す考え方です。
中小企業では、必ずしも高機能な製品を最初から導入する必要はありません。
まずは、現在利用しているサービスとアカウントを把握し、「誰が、何に、どこまでアクセスできるのか」を確認することから始めましょう。
大切なのは、IDや権限を増やすことだけでなく、不要になったら適切に見直し、減らせる仕組みをつくることです。
それが、クラウド利用やBYOD、SASE、ゼロトラストなどの対策を支える基盤となり、中小企業が「守れる会社」をつくるための一歩になります。
LYSTでは、中小企業の実情に合わせて、アカウント・権限管理の現状把握、社内ルールの整備、クラウドサービスのセキュリティ設定確認などをご支援しています。
「どのアカウントから確認すればよいか分からない」
「入退社時の管理手順を整備したい」
「セキュリティ対策をどこから始めるべきか迷っている」
といった段階からでもご相談いただけます。
まずは自社の管理状況を整理し、無理なく続けられる対策から始めてみてはいかがでしょうか。