Zenn
🙆‍♀️

AWS学びなおし(+TF)_iam identity center

2025/03/10に公開
AWS
tech

AWS IAM Identity Center (旧 AWS Single Sign-On) は、複数のAWSアカウントおよびクラウドアプリケーションへのアクセスを一元的に管理するサービスです。組織内のユーザーが、単一の場所からすべての割り当てられたAWSアカウントとアプリケーションにシングルサインオン (SSO) できるようにします。

主要な機能と概念:

  • シングルサインオン (SSO): ユーザーは一度認証を受けるだけで、複数のAWSアカウントやSaaSアプリケーションにアクセスできます。これにより、ユーザーは複数の認証情報を覚える必要がなくなり、利便性が向上します。
  • IDプロバイダー連携: 既存のIDプロバイダー (Microsoft Entra ID, Okta, Google Workspace など) と連携できます。これにより、既存のユーザーディレクトリをそのまま利用でき、ユーザー管理の重複を避けることができます。IAM Identity Center自体もIDプロバイダーとして機能し、独自のユーザーディレクトリを持つことも可能です。
  • 一元的なアクセス管理: AWS Organizationsと連携することで、組織内のすべてのアカウントに対するアクセス権限をIAM Identity Centerで一元的に管理できます。アカウントごとに個別にIAMユーザーを作成・管理する必要がなくなり、管理負荷が大幅に軽減されます。
  • 認可 (Permission Sets): IAM Identity Centerでは、Permission Setsと呼ばれる権限セットを定義し、ユーザーまたはグループに割り当てることで、各AWSアカウントへのアクセス権限を制御します。Permission SetsはIAMポリシーをベースに作成され、きめ細かい権限管理が可能です。
  • プロビジョニング: IDプロバイダーと連携している場合、ユーザーやグループの情報を自動的にIAM Identity Centerに同期 (プロビジョニング) できます。これにより、ユーザーの追加や削除、属性変更などを手動で行う必要がなくなり、運用効率が向上します。
  • 多要素認証 (MFA): セキュリティを強化するために、多要素認証を強制できます。これにより、パスワードが漏洩した場合でも不正アクセスを防ぐことができます。
  • 監査ログ: ユーザーのログイン、アクセス許可の変更など、IAM Identity Centerで行われたすべてのアクションは監査ログとして記録されます。これにより、セキュリティ監査やコンプライアンス対応を容易に行うことができます。

IAM (IAM Roles, IAM Users) との違い:

IAMはAWSリソースへのアクセス管理に特化したサービスで、主にAWSアカウント内での認証・認可を行います。一方、IAM Identity Centerは、複数アカウントおよびクラウドアプリケーションへのアクセス管理を組織全体で一元的に行うためのサービスです。

IAM Identity CenterはIAMの上に構築されており、Permission SetsはIAM Roleを裏側で作成・管理しています。IAM Identity Centerを利用することで、IAM Roleを直接管理する手間を大幅に削減し、より組織全体でのアクセス管理を効率化できます。

メリット:

  • セキュリティ向上: 一元的なアクセス管理、多要素認証の強制、監査ログなどにより、セキュリティを大幅に向上させることができます。
  • 運用効率の向上: ユーザー管理、アクセス権限管理、SSO設定などを一元化することで、運用負荷を大幅に軽減できます。
  • ユーザー利便性の向上: SSOにより、ユーザーは複数の認証情報を覚える必要がなくなり、AWS環境へのアクセスが容易になります。
  • コンプライアンス対応の強化: 監査ログにより、アクセス状況を容易に把握でき、コンプライアンス要件への対応を強化できます。

【実務レベルの内容と重要事項】

  • 組織構造との整合性: IAM Identity Centerの設計は、組織の構造 (事業部、チームなど) と整合性を持たせる必要があります。Permission Setsの設計、グループ設計、アカウント構成などを組織構造に合わせて最適化することで、運用効率とセキュリティを両立できます。
  • Permission Sets の設計: Permission Setsは、最小権限の原則に基づいて設計する必要があります。ユーザーに必要な権限のみを付与し、不要な権限は付与しないようにすることで、セキュリティリスクを低減できます。
  • IDプロバイダー連携の検討: 既存のIDプロバイダーとの連携は、ユーザー管理の効率化に大きく貢献します。ただし、連携するIDプロバイダーの選定、プロビジョニング設定、認証方式などを慎重に検討する必要があります。
  • 多要素認証 (MFA) の強制: 多要素認証は必須と考えるべきです。特に管理者権限を持つユーザーには、必ず多要素認証を強制するように設定してください。
  • 監査ログの活用: 監査ログは、セキュリティインシデントの早期発見や原因究明、コンプライアンス監査などに不可欠です。監査ログを定期的に確認し、異常なアクティビティがないか監視する必要があります。
  • 委任管理: IAM Identity Centerの管理権限を特定のユーザーまたはグループに委任できます。これにより、管理負荷を分散し、運用効率を向上させることができます。委任管理の範囲と権限は慎重に検討する必要があります。
  • 属性ベースアクセスコントロール (ABAC): Permission Setsに加えて、属性ベースアクセスコントロール (ABAC) を利用することで、よりきめ細かいアクセス制御を実現できます。ユーザー属性やリソース属性に基づいてアクセス権限を制御することで、動的なアクセス管理が可能になります。
  • セッション期間の設定: IAM Identity Centerのセッション期間を適切に設定することで、セキュリティと利便性のバランスを取ることができます。セッション期間が長すぎるとセキュリティリスクが高まり、短すぎるとユーザーの利便性が損なわれます。
  • フェデレーション設定の検証: IDプロバイダー連携 (フェデレーション) を行う場合、設定ミスにより認証が失敗する可能性があります。設定後は必ず検証を行い、正常に認証できることを確認してください。
  • DR (災害対策) 考慮: IAM Identity Centerは可用性の高いサービスですが、万が一の障害に備えてDR (災害対策) を考慮しておく必要があります。バックアップ、リストア手順、フェイルオーバー手順などを事前に検討しておくことが重要です。

重要事項:

  • セキュリティ: IAM Identity Centerは、組織全体のAWS環境のセキュリティ基盤となる重要なサービスです。セキュリティ設定は慎重に行い、定期的に見直す必要があります。
  • 運用設計: IAM Identity Centerの運用設計は、長期的な視点で検討する必要があります。組織規模の拡大やビジネスの変化に対応できるように、柔軟性のある設計を心がけてください。
  • 初期設定の重要性: IAM Identity Centerの初期設定は、その後の運用に大きな影響を与えます。初期設定を誤ると、後から修正するのが困難になる場合があります。初期設定は慎重に行い、AWSのベストプラクティスに従うようにしてください。

【実務でどの程度使用されるのか】

IAM Identity Centerは、実務で非常に広く使用されています。 特に、複数AWSアカウントを運用している組織や、SaaSアプリケーションを多数利用している組織にとっては、ほぼ必須のサービスと言えるでしょう。

利用シーン:

  • 大規模組織: 多数のAWSアカウントとユーザーを抱える大規模組織では、IAM Identity Centerによる一元的なアクセス管理は不可欠です。運用効率の向上、セキュリティ強化、コンプライアンス対応など、多くのメリットを享受できます。
  • 中規模組織: 中規模組織でも、AWSアカウント数やユーザー数が増加するにつれて、IAM Identity Centerの導入効果が高まります。特に、セキュリティ意識の高い組織や、監査要件が厳しい組織では、積極的に導入されています。
  • 中小企業・スタートアップ: 中小企業やスタートアップでも、AWS利用が拡大するにつれて、IAM Identity Centerの導入を検討するケースが増えています。初期段階ではIAMユーザーで管理していたアクセス権限を、IAM Identity Centerに移行することで、より安全で効率的なアクセス管理を実現できます。
  • SaaSアプリケーションとの連携: AWSだけでなく、Salesforce, Google Workspace, Microsoft 365などのSaaSアプリケーションへのSSOを実現するために、IAM Identity Centerが利用されています。これにより、社内全体のID管理基盤を統合し、ユーザーエクスペリエンスを向上させることができます。
  • DevOps環境: DevOps環境では、開発者や運用担当者が頻繁にAWS環境にアクセスする必要があります。IAM Identity Centerを導入することで、開発者や運用担当者のAWSアクセスを効率化し、セキュリティを確保しながら開発サイクルを加速できます。

普及度:

AWSを利用している組織の多くが、IAM Identity Centerまたは同様のID管理ソリューションを利用しています。特に、セキュリティと運用効率を重視する企業ほど、IAM Identity Centerの導入率は高い傾向にあります。AWSの推奨サービスとしても位置づけられており、今後ますます普及が進むと予想されます。

メリットとデメリット:

  • メリット: 上記【分かりやすく「網羅的」に解説】および【実務レベルの内容と重要事項】で述べた通り、セキュリティ向上、運用効率向上、ユーザー利便性向上、コンプライアンス対応強化など、多くのメリットがあります。
  • デメリット:
    • 初期設定の複雑さ: 特にIDプロバイダー連携やPermission Setsの設計など、初期設定にはある程度の専門知識と時間が必要です。
    • 運用コスト: IAM Identity Center自体は無料ですが、連携するIDプロバイダーやSaaSアプリケーションによっては、別途費用が発生する場合があります。
    • 依存性の増加: IAM Identity Centerにアクセス管理を依存するため、IAM Identity Centerに障害が発生した場合、AWS環境全体へのアクセスに影響が出る可能性があります。可用性対策は必須です。

総合的に見て、IAM Identity Centerは実務において非常に有用なサービスであり、多くの組織で導入されています。デメリットも存在するものの、メリットがそれを上回ると考えられます。特に、複数アカウントを運用している組織や、セキュリティを重視する組織にとっては、導入を強く推奨できるサービスです。

【terraformのコードで記述する場合の基本的内容と実務レベルの内容】

Terraform 基本コード:

IAM Identity Center を Terraform で記述する場合、主に以下のリソースを使用します。

  • aws_identitystore_group: Identity Store のグループを作成します。
  • aws_identitystore_user: Identity Store のユーザーを作成します。
  • aws_ssoadmin_permission_set: Permission Set (権限セット) を作成します。
  • aws_ssoadmin_account_assignment: ユーザーまたはグループに Permission Set を AWS アカウントに割り当てます。
  • aws_ssoadmin_instance: IAM Identity Center インスタンスを作成します (通常は初回のみ)。
  • aws_ssoadmin_customer_managed_policy_attachment: Permission Set にカスタマー管理ポリシーをアタッチします。
  • aws_ssoadmin_aws_managed_policy_attachment: Permission Set に AWS マネージドポリシーをアタッチします。

基本的な Terraform コード例:

resource "aws_identitystore_group" "example" {
  display_name = "example-group"
}

resource "aws_identitystore_user" "example" {
  user_principal_name = "user@example.com"
  display_name      = "Example User"
  family_name       = "User"
  given_name        = "Example"
}

resource "aws_ssoadmin_permission_set" "example" {
  name             = "ExamplePermissionSet"
  instance_arn = data.aws_ssoadmin_instances.example.arns[0] # データソースでインスタンスARNを取得
  description      = "Example Permission Set"
  session_duration = "PT1H" # セッション期間を1時間に設定

  relay_state = "/console" # ログイン後のリダイレクト先

  inline_policy = jsonencode({ # インラインポリシー (JSON形式)
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "ec2:Describe*",
        ]
        Effect   = "Allow"
        Resource = "*"
      },
    ]
  })
}


resource "aws_ssoadmin_account_assignment" "example" {
  instance_arn       = data.aws_ssoadmin_instances.example.arns[0] # データソースでインスタンスARNを取得
  permission_set_arn = aws_ssoadmin_permission_set.example.arn
  principal_id       = aws_identitystore_user.example.id
  principal_type     = "USER"
  target_id          = "123456789012" # AWSアカウントID
  target_type        = "AWS_ACCOUNT"
}

data "aws_ssoadmin_instances" "example" {} # IAM Identity Center インスタンスのデータソース

実務レベルの Terraform コード:

実務レベルでは、上記の基本コードに加えて、以下の要素を考慮する必要があります。

  • モジュール化: IAM Identity Center の設定をモジュール化することで、コードの再利用性、可読性、保守性を向上させることができます。
  • 変数化: 環境 (開発環境、本番環境など) や組織構造に合わせて変更する必要がある設定値 (アカウントID, グループ名, Permission Set 名など) は、変数として定義することで、コードの柔軟性を高めることができます。
  • データソースの活用: 既存のリソース (例: IAM Identity Center インスタンス ARN) をデータソースで取得することで、ハードコーディングを避け、コードの可読性と保守性を向上させることができます。
  • 外部IDプロバイダー連携: 外部IDプロバイダー (Microsoft Entra ID など) と連携する場合、Terraform で ID プロバイダーの設定を記述することも可能です (例: aws_ssoadmin_identity_provider, aws_ssoadmin_identity_provider_attribute_mapping). ただし、IDプロバイダー側の設定も別途必要になります。
  • プロビジョニング設定: SCIM (System for Cross-domain Identity Management) を利用した自動プロビジョニング設定は、Terraform では直接的にサポートされていません。AWS Management Console または AWS CLI/SDK を利用して設定する必要があります。
  • ABAC (属性ベースアクセスコントロール) の実装: Permission Sets のインラインポリシーまたはカスタマー管理ポリシーで、ユーザー属性やリソース属性に基づいた条件を設定することで、ABAC を実装できます。Terraform コードでポリシーを JSON または YAML 形式で記述し、inline_policy または customer_managed_policy_attachment リソースで適用します。
  • 監査ログ設定: CloudTrail と連携して監査ログを有効化し、S3 バケットや CloudWatch Logs に保存する設定も Terraform で記述可能です (例: aws_cloudtrail).
  • 状態管理: Terraform の状態ファイル (terraform.tfstate) を適切に管理することが重要です。リモートバックエンド (S3, Terraform Cloud など) を利用し、状態ファイルのロック機構を有効にすることで、複数人での安全な Terraform 運用を実現できます。
  • テスト: Terraform コードの変更を適用する前に、必ず terraform plan コマンドで変更内容を確認し、必要に応じて terraform apply を実行する前にテスト環境で検証を行うようにしてください。

実務レベルの Terraform コード例 (モジュール化、変数化、データソース活用):

# modules/iam_identity_center/main.tf
resource "aws_identitystore_group" "example" {
  display_name = var.group_name
}

resource "aws_identitystore_user" "example" {
  user_principal_name = var.user_email
  display_name      = var.user_display_name
  family_name       = var.user_family_name
  given_name        = var.user_given_name
}

resource "aws_ssoadmin_permission_set" "example" {
  name             = var.permission_set_name
  instance_arn = data.aws_ssoadmin_instances.example.arns[0]
  description      = var.permission_set_description
  session_duration = "PT1H"

  inline_policy = jsonencode(var.permission_set_policy)
}

resource "aws_ssoadmin_account_assignment" "example" {
  instance_arn       = data.aws_ssoadmin_instances.example.arns[0]
  permission_set_arn = aws_ssoadmin_permission_set.example.arn
  principal_id       = aws_identitystore_user.example.id
  principal_type     = "USER"
  target_id          = var.aws_account_id
  target_type        = "AWS_ACCOUNT"
}

data "aws_ssoadmin_instances" "example" {}


# modules/iam_identity_center/variables.tf
variable "group_name" {
  type = string
  description = "IAM Identity Center Group Name"
}

variable "user_email" {
  type = string
  description = "IAM Identity Center User Email"
}

variable "user_display_name" {
  type = string
  description = "IAM Identity Center User Display Name"
}

variable "user_family_name" {
  type = string
  description = "IAM Identity Center User Family Name"
}

variable "user_given_name" {
  type = string
  description = "IAM Identity Center User Given Name"
}


variable "permission_set_name" {
  type = string
  description = "Permission Set Name"
}

variable "permission_set_description" {
  type = string
  description = "Permission Set Description"
}

variable "permission_set_policy" {
  type = object({
    Version = string
    Statement = list(object({
      Action   = list(string)
      Effect   = string
      Resource = string
    }))
  })
  description = "Permission Set Inline Policy (JSON Object)"
}


variable "aws_account_id" {
  type = string
  description = "AWS Account ID to assign Permission Set"
}


# main.tf (root module)
module "iam_id_center_example" {
  source = "./modules/iam_identity_center"

  group_name = "developers"
  user_email = "dev-user@example.com"
  user_display_name = "Developer User"
  user_family_name = "User"
  user_given_name = "Developer"

  permission_set_name        = "ReadOnlyAccess"
  permission_set_description = "Read-only access to AWS resources"
  permission_set_policy = {
    Version = "2012-10-17"
    Statement = [
      {
        Action   = ["ec2:Describe*", "s3:ListBucket"]
        Effect   = "Allow"
        Resource = "*"
      },
    ]
  }
  aws_account_id = "123456789012"
}

上記の例は、モジュール化、変数化、データソース活用を取り入れた実務レベルの Terraform コードの基本的な構成例です。実際の運用では、組織の要件に合わせて、より複雑な設定やリソースを Terraform で記述する必要があります。 Terraform のベストプラクティス (状態管理、テスト、CI/CD パイプラインへの組み込みなど) も合わせて実践することで、より安全で効率的な IAM Identity Center の Infrastructure as Code (IaC) を実現できます。

Discussion