Identity & Access Management

Identity & Access Management

IAM概論(ID・アクセス管理)

Category: Identity & Access Management / Updated: 2026-05-26

📖

Overview

IAM(Identity & Access Management:ID・アクセス管理)とは、組織において「誰が」「どのリソースに」「どのような条件で」アクセスできるかを体系的に管理するためのフレームワークです。ユーザーのデジタルIDの作成・管理・削除から、適切なアクセス権限の付与・制御・監視までを包括的にカバーし、情報セキュリティの根幹を支える基盤技術として位置づけられています。

IAMの中核を成すのがAAA(Authentication・Authorization・Accounting)の3要素です。Authentication(認証)はユーザーが本人であることを確認するプロセス、Authorization(認可)は認証済みユーザーに適切な権限を付与するプロセス、Accounting(アカウンティング)はユーザーの行動を記録・追跡するプロセスです。この3つが連携することで、セキュアなアクセス制御が実現されます。

近年ではクラウド環境の普及やリモートワークの拡大により、IAMの重要性はますます高まっています。従来の境界防御型セキュリティでは対応困難な環境において、ゼロトラストセキュリティの概念と結びつき、すべてのアクセスを検証するアーキテクチャの実現にIAMが不可欠な要素となっています。

🔬

Details

認証・認可・アカウンティング(AAA)

認証(Authentication)は、ユーザーが主張するIDが正当であることを検証するプロセスです。パスワード認証、多要素認証(MFA)、生体認証、証明書認証など多様な方式があり、セキュリティレベルに応じて適切な方式を選択します。認証は「あなたは誰ですか?」という問いに答えるステップです。

認可(Authorization)は、認証済みユーザーに対して「何ができるか」を決定するプロセスです。RBAC(ロールベースアクセス制御)、ABAC(属性ベースアクセス制御)、PBAC(ポリシーベースアクセス制御)などのモデルを用いて、最小権限の原則に基づいたアクセス制御を実現します。

アカウンティング(Accounting)は、ユーザーのアクセス行動を記録・監視するプロセスです。ログイン履歴、リソースへのアクセス記録、権限変更の履歴などを記録し、セキュリティ監査やインシデント調査に活用されます。

IAMアーキテクチャの構成要素

IAMアーキテクチャは複数のコンポーネントで構成されます。IDプロバイダー(IdP)はユーザー認証とID情報の管理を担当し、ディレクトリサービスはユーザー情報やグループ情報を格納するデータストアとして機能します。アクセス管理エンジンはポリシーに基づいてアクセス可否を判定し、IDガバナンスはIDライフサイクル全体の管理と監査を行います。

これらのコンポーネントは、SAML、OAuth 2.0、OpenID Connect(OIDC)などの標準プロトコルを通じて相互連携し、シングルサインオン(SSO)やフェデレーション認証を実現します。

クラウドIAMの進化

クラウドコンピューティングの普及により、IAMは大きな変革を遂げています。AWS IAMAzure Active Directory(Entra ID)Google Cloud IAMといったクラウドネイティブのIAMサービスが登場し、クラウドリソースへのきめ細かなアクセス制御が可能になりました。

クラウドIAMでは、ユーザーIDだけでなく、サービスアカウント、ロール、ポリシーを組み合わせた柔軟なアクセス制御が特徴です。また、IDaaS(Identity as a Service)として、Okta、Auth0、OneLoginなどのクラウドベースのID管理サービスも普及しており、マルチクラウド環境やSaaSアプリケーションを横断した統合的なID管理が実現されています。

ゼロトラストとIAM

ゼロトラストは「決して信頼せず、常に検証する」という原則に基づくセキュリティモデルです。従来の境界防御型モデルでは、社内ネットワーク内のユーザーを暗黙的に信頼していましたが、ゼロトラストではネットワークの場所に関わらずすべてのアクセスを検証します。

IAMはゼロトラストアーキテクチャの中核を担います。継続的な認証と認可、コンテキストベースのアクセス制御(デバイスの状態、ユーザーの行動パターン、アクセス元のリスクスコアなど)、最小権限の原則の徹底が求められ、IAMの成熟度がゼロトラストの実現度に直結します。

IDライフサイクル管理

IAMにおけるIDライフサイクル管理は、デジタルIDの生成から廃止までの全工程を体系的に管理するプロセスです。入社時のアカウント作成(プロビジョニング)、異動時の権限変更、休職時のアカウント無効化、退職時のアカウント削除(デプロビジョニング)を適切に管理することで、不要なアカウントの残存や過剰な権限の蓄積を防ぎます。

特にジョイナー・ムーバー・リーバー(JML)プロセスと呼ばれる入社・異動・退職に連動したID管理の自動化が重要です。人事システムとIAMの連携により、人事イベントに基づいた自動的なプロビジョニング・デプロビジョニングを実現し、人的ミスによるセキュリティリスクを低減します。

🛡️

Security Measures

  • 01
    最小権限の原則を徹底する:すべてのユーザーとサービスアカウントに対して、業務遂行に必要最小限の権限のみを付与してください。過剰な権限は定期的に棚卸しを行い、不要な権限は速やかに剥奪します。特に管理者権限の付与は厳格に制限し、常用アカウントとは分離して運用しましょう。
  • 02
    多要素認証(MFA)を全ユーザーに適用:パスワード認証のみに依存せず、MFAをすべてのユーザーアカウントに必須化してください。特に管理者アカウント、VPNアクセス、クラウドサービスへのログインにはハードウェアトークンやFIDO2対応の認証器を使用し、フィッシング耐性のある認証方式を導入しましょう。
  • 03
    IDライフサイクルの自動化:入社・異動・退職に伴うアカウントのプロビジョニング・デプロビジョニングを自動化してください。人事システムとIAMの連携により、退職者のアカウントが放置されるリスクを排除し、異動時の権限の自動更新により権限の蓄積を防止します。
  • 04
    特権アクセス管理(PAM)の導入:システム管理者やデータベース管理者などの特権アカウントには、PAMソリューションを導入してください。特権セッションの録画、ジャストインタイム(JIT)アクセス、パスワードボールティングにより、特権アカウントの悪用リスクを大幅に低減できます。
  • 05
    アクセス権限の定期的な棚卸し:最低でも四半期に一度、すべてのユーザーのアクセス権限を棚卸し(アクセスレビュー)してください。業務上不要になった権限、過去の異動で残存した権限、一時的に付与された権限の期限切れ確認などを行い、権限の肥大化を防止します。
  • 06
    IAMログの統合監視と異常検知:認証ログ、認可ログ、権限変更ログを統合的に収集・分析し、異常なアクセスパターンを検知する仕組みを構築してください。深夜の大量データアクセス、通常と異なる地域からのログイン、短時間での権限昇格などの異常を自動検知し、即座にアラートを発報する体制を整えましょう。
⚠️

Incidents

📋 SolarWinds サプライチェーン攻撃におけるIAM侵害(2020年)

2020年に発覚したSolarWinds事件では、攻撃者がOrion製品のアップデートにバックドアを仕込み、導入企業のネットワークに侵入しました。侵入後、攻撃者はActive DirectoryのSAMLトークン署名証明書を窃取し、ゴールデンSAMLトークンを偽造することで、任意のユーザーになりすましてクラウドサービスにアクセスしました。

この攻撃は、IAMインフラストラクチャそのものが攻撃対象となり得ることを示した重大な事例です。米国政府機関を含む18,000以上の組織が影響を受け、IAMの信頼チェーン全体を検証する重要性が改めて認識されました。

📋 退職者アカウントの放置による不正アクセス事件(2022年)

国内の大手製造業において、退職した元従業員のVPNアカウントが半年以上にわたり無効化されずに放置されていた事例が報告されました。元従業員は退職後もこのアカウントを使用して社内ネットワークに不正にアクセスし、開発中の製品設計データや顧客情報を持ち出していました。

調査の結果、人事システムとIAMシステムが連携しておらず、退職処理が手動で行われていたことが原因と判明しました。この事件を受け、同社はIDライフサイクル管理の自動化と退職時の即時アカウント無効化プロセスを導入しました。

📋 クラウドIAM設定ミスによる大規模データ漏洩(2023年)

海外の大手SaaS企業において、AWS IAMの設定ミスにより数百万件の顧客データが漏洩した事件が発生しました。開発環境で使用していたIAMロールに本番環境のS3バケットへのフルアクセス権限が付与されており、開発者のアクセスキーが漏洩したことで攻撃者が本番データにアクセスできる状態になっていました。

この事件の根本原因は、最小権限の原則が守られていなかったことと、環境間のIAMポリシーが適切に分離されていなかったことです。クラウドIAMの設定は複雑であり、Infrastructure as Code(IaC)による管理と定期的なポリシーレビューの必要性が再認識されました。

🔗

Related Terms