IAM（アイデンティティ・アクセス管理）とは？仕組み・構成要素・中小企業での実践ガイド

「退職した社員のアカウントが3ヶ月後も残っていた」「どの社員がどのシステムにアクセスできるか、誰も正確に把握していない」――こうした状況を放置したまま、攻撃者に突かれた事例は国内外で後を絶ちません。

アカウントの管理が甘い組織は、外部からの攻撃だけでなく、内部不正のリスクも高くなります。しかし「どこから手をつければいいかわからない」という情シス担当者が多いのも現実です。

この記事では、IAM（Identity and Access Management：アイデンティティ・アクセス管理）の基本概念から仕組み、中小企業が今日から取り組める実践的な対策まで、現場目線で解説します。

IAM（アイデンティティ・アクセス管理）とは？

IAMとは、「誰が」「何に」「どこまで」アクセスできるかを一元管理する仕組みの総称です。日本語では「アイデンティティ・アクセス管理」と呼ばれます。

具体的には、以下のような問いに答えるためのフレームワークです。

・誰が（Who）: 社員Aさん、外部委託先のBさん、システムCというサービスアカウント
・何に（What）: 社内ファイルサーバー、クラウドサービス、業務アプリケーション
・どの操作を（How）: 閲覧のみ、編集可能、削除権限あり
・いつ・どこから（When/Where）: 業務時間内のみ、社内ネットワークからのみ

IAMは単一の製品を指すのではなく、認証・認可・アカウント管理・監査ログといった複数の仕組みを組み合わせた概念です。

なぜ今、IAMが重要なのか

クラウドサービスやリモートワークが普及する以前は、「社内ネットワークに入れた人は信頼できる」という前提が一定機能していました。しかし今は違います。

・クラウドサービスの増加: SaaSが増えるほど、誰がどのサービスに入れるかの管理が複雑化する
・退職・異動時のアカウント残置: 手動管理では削除漏れが発生しやすく、攻撃者に悪用される
・ゼロトラストへの移行: 「場所ではなくアイデンティティで信頼を判断する」設計が求められる

実際、IPA「情報セキュリティ10大脅威 2026」においても、認証情報の管理不備を突いた攻撃が上位を占めています。

IAMが防ぐ脅威——攻撃者の視点から理解する

IAMが不十分な組織に対して、攻撃者はどんな手口を使うのでしょうか。防御のために知っておきましょう。

【手口1】不要アカウントへのパスワードリスト攻撃

退職者のアカウントが削除されていない場合、攻撃者はダークウェブで入手したパスワードリストを使って自動的にログイン試行します（パスワードリスト攻撃）。本人がすでに退職しているため誰も気づかないまま、長期間アクセスが続くケースがあります。

【手口2】過剰権限アカウントの横移動

「全システムに管理者権限」で設定されたアカウントが一つでも侵害されると、攻撃者はそこを起点に社内システム全体へ広がります（ラテラルムーブメント）。適切なIAMがあれば、被害は権限範囲内に封じ込められます。

【手口3】サービスアカウントの悪用

アプリケーションが自動処理に使う「サービスアカウント」は、ローテーションが放置されがちで、攻撃者の格好の標的です。人が使うアカウント以外も、IAMの管理対象に含める必要があります。

【手口4】フィッシングによる認証情報窃取

社員のIDとパスワードをフィッシングで入手した攻撃者は、そのまま業務システムにログインしようとします。IAMに多要素認証（MFA）が組み込まれていれば、パスワードだけでは侵入できません。

IAMの構成要素と仕組み

IAMは大きく5つの機能で成り立っています。

1. 識別（Identification）——「あなたは誰か」を宣言する

システムに「自分はAさんです」と名乗る行為が識別です。IDやユーザー名がこれにあたります。識別だけでは本人確認はできません。次の「認証」と組み合わせて初めて意味を持ちます。

2. 認証（Authentication）——「本当にあなたか」を確認する

識別した主体が本物かどうかを確認する仕組みです。パスワード・ICカード・生体認証・ワンタイムパスワードなど複数の認証要素を組み合わせることで、なりすましリスクを大幅に下げられます。

認証の基礎については認証と認可の違いで詳しく解説しています。

認証の強度を上げる多要素認証（MFA）

パスワードだけの認証は、フィッシングやリスト攻撃で突破されやすい現状があります。多要素認証（MFA）を導入することで、仮にパスワードが漏洩しても不正ログインを防げます。主要なクラウドサービスでは無償で設定できるため、最優先で対応すべき対策の一つです。

3. 認可（Authorization）——「何をしていいか」を決める

認証が成功した後、そのユーザーがどのリソースにどんな操作ができるかを制御するのが認可です。役割ベースアクセス制御（RBAC）は最も普及した認可方式で、「営業職には営業システムのみ閲覧権限」「システム管理者には全システムの管理権限」のように役割単位で権限を割り当てます。

アクセス制御の設計モデルについてはアクセス制御モデル（DAC・MAC・RBAC）を参照してください。

4. プロビジョニングとデプロビジョニング——アカウントの作成と削除

入社時にアカウントを作成し（プロビジョニング）、退職・異動時に削除または権限変更すること（デプロビジョニング）です。この工程を手動で行うと、削除漏れ・権限の引き継ぎ忘れが発生します。

理想は自動化：人事システムと連携して、入退社・異動時に自動でアカウント状態を更新できる仕組みを目指しましょう。小規模であれば、少なくとも「退職翌日には必ずアカウントを無効化する」手順書を整備するだけでも大きな違いがあります。

5. 監査・ログ管理——「誰が何をしたか」を記録する

誰がいつ何にアクセスしたかのログを記録・保管することで、インシデント発生時の調査や内部不正の抑止につながります。ログは改ざんされないよう、アクセスした本人が操作できない場所に保管することが重要です。

IAMの実装パターン——現場での選択肢

1. ディレクトリサービス（Active Directory / LDAP）

WindowsベースのオンプレミスIT環境では、Microsoft Active Directory（AD）がユーザー管理の中心になることが多いです。グループポリシーでPCの設定を一元管理しながら、ユーザーの権限も制御できます。

一方、LDAPはADに限らずLinux環境でも使える汎用プロトコルです。既存のディレクトリに対してLDAPで認証させる設計は、オンプレミス中心の環境では今でも現役です。

2. クラウドIAM（AWS IAM・Azure AD・Google Workspace）

クラウドサービスを使っている場合、各プラットフォームが提供するIAM機能を活用します。

・AWS IAM: AWSリソースへのアクセス権をユーザー・グループ・ロールで細かく制御できる
・Microsoft Entra ID（旧Azure AD）: Microsoft 365との統合が強く、条件付きアクセスでリスクベースの認証が可能
・Google Workspace管理コンソール: GoogleサービスのユーザーとグループをGUI管理できる

クラウドIAMの詳細設計については、姉妹サイトクラウドマスターズ.TOKYOで解説しています。

3. フェデレーションとSSO（シングルサインオン）

複数のサービスに同一のID・パスワードでログインできる仕組みがSSOです。IDプロバイダー（IdP）が認証を一括管理し、各サービス（サービスプロバイダー：SP）に「認証済み」の情報を連携します。

SSOの実装にはSAMLやOIDC（OpenID Connect）というプロトコルが使われます。社員が使うSaaSが増えるほど、SSOの導入効果は高まります。

シングルサインオン（SSO）の詳細な仕組みと注意点もあわせて確認してください。

最近注目のパスキー（Passkey）：パスワード自体を廃止するパスキー（FIDO2）も普及が進んでいます。フィッシング耐性が高く、IAMの認証層を抜本的に強化できます。

中小企業でも今日からできること

「IAMって大企業向けの話では？」と思われるかもしれませんが、そんなことはありません。情シス1人でも今日から始められる対策を優先度順に紹介します。

1. アカウント棚卸しを実施する（最優先）

まず現状を可視化することが最初の一歩です。

# Active Directoryがある場合：無効化されていないアカウント一覧
Get-ADUser -Filter {Enabled -eq $True} | Select-Object Name, LastLogonDate | Sort-Object LastLogonDate

# 最終ログインが90日以上前のアカウントを洗い出す
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $True -and LastLogonDate -lt $cutoff} | Select-Object Name, LastLogonDate

クラウドサービスのみの場合は、管理コンソールの「ユーザー一覧」を人事名簿と照合する作業から始めましょう。

2. 全員にMFAを適用する

Microsoft 365・Google Workspace・AWS・GitHubなど、主要なサービスはMFAを無償で提供しています。特にメール・ファイルサーバー・クラウドへのアクセスには必須で設定しましょう。管理者アカウントはさらに強度の高い認証（ハードウェアキーや条件付きアクセス）を検討します。

3. 最小権限の原則を徹底する

「とりあえず管理者権限を渡しておけば楽」は危険な発想です。業務に必要な最小限の権限だけを付与する「最小権限の原則」を守ることで、アカウント侵害時の被害範囲を限定できます。

・やること: 全員に管理者権限を与えていないか確認し、一般ユーザー権限に降格する
・やること: IT管理作業は専用の管理者アカウントを別途用意し、日常業務と使い分ける
・やること: SaaS利用権限も「閲覧のみ」「編集可能」「管理者」の3段階を意識して割り当てる

4. 入退社・異動のアカウント変更フローを文書化する

「退職者のアカウントをいつ誰が無効化するか」を明文化します。ITチームだけでなく、人事部門との連携ルールを決めておくことが重要です。

入退社時の理想のフロー：
・退職確定日 → 人事が情シスに通知 → 退職当日にアカウント無効化（削除は30日後）
・異動確定日 → 異動後の権限に変更し、旧権限は削除
・委託先スタッフ → 契約終了日を事前に把握し、終了日当日に無効化

5. ゼロトラストの視点を取り入れる

「社内ネットワークにいるから安全」という前提を捨て、「常に検証する」設計に移行しましょう。ゼロトラストの考え方では、IAMが最も重要な防御の柱の一つです。

まずはクラウドサービスの「条件付きアクセス（会社端末からのみアクセス許可、特定国からのアクセスを拒否）」などから始めると、コストをかけずにゼロトラスト的な制御を実現できます。

よくある誤解と注意点

【誤解1】「IDとパスワードを管理していればIAMはできている」

アカウントを作成・削除する管理だけがIAMではありません。認証の強度（MFAの有無）・権限の適切さ・ログの保管まで含めて初めてIAMです。

【誤解2】「大企業向けのIdP製品を買わないとIAMはできない」

大企業向けのIAMソリューション（Okta・SailPoint等）は確かに高機能ですが、中小企業はMicrosoft Entra IDやGoogle Workspaceの管理コンソールを使い込むだけでも、IAMの多くの要件を満たせます。まず無償・低コストの手段から始めましょう。

【誤解3】「一度設定すればメンテナンス不要」

IAMは生き物です。入退社・組織変更・新規SaaS導入のたびに見直しが必要です。定期的な棚卸し（最低でも半年に1回）をスケジュール化しておきましょう。

【注意】SaaS乱立によるシャドーIAM問題

部署ごとに勝手にSaaSを契約すると（シャドーIT）、情シスが把握していないアカウントが大量に発生します。SaaSの新規契約を情シス承認制にするルールを整備することが、IAMを機能させる前提条件の一つです。

本記事のまとめ

IAMの要点を整理します。

IAMは「完璧なシステムを導入してから始める」ものではありません。アカウント棚卸しとMFA適用から始め、組織の成長とともに仕組みを育てていくことが現実的なアプローチです。

中小企業のID管理の具体的な運用については中小企業のID管理入門もあわせて参考にしてください。