【 IAM Identity Center × Terraform 】によるAWS権限管理アーキテクチャ

皆さんこんにちは。 DX Solution 事業本部 Dev の山本です。

AWSの権限管理、皆さんの組織ではうまくいっていますか？

複数のAWSアカウントを扱う環境では、ユーザーや権限の管理に手間がかかりがちです。社内でGoogle Workspaceを利用しているなら、AWSへのログインもGoogleアカウントに統一できれば便利ですよね。さらに、Terraformで権限管理をコード化できれば、運用効率やセキュリティも格段に向上します。本記事では、そのような要望を実現する方法をご紹介します。

TL;DR
はじめに
従来の構成と課題
IAMユーザー運用とIdentity Center構成の比較
IAM Identity Centerを活用した新規アーキテクチャ
まとめ
We're hiring

TL;DR

Google Workspace × AWS IAM Identity Centerの連携とTerraform × GitHub ActionsによるAWS権限管理

今回構築したアーキテクチャがこちらです。

社内認証基盤であるGoogle WorkspaceとAWS IAM Identity Centerを連携し、複数AWSアカウントへのアクセス権を一元管理しました。また、ユーザーや権限（ロール）はTerraform管理のコードで定義し、GitHub ActionsでTerraformをCI/CD実行することで、アカウント作成から権限管理までを完全自動化しています。

主な利点:

Google Workspaceによるユーザー管理の一元化
全AWSアカウントへのSSO実現
IAMユーザーアクセスキー運用の廃止
Terraformによる権限のコード化（一貫性、監査性、バージョン管理）
安全な自動デプロイメントパイプライン

はじめに

多くの企業では、社員のID管理に Google Workspace（旧G Suite）やMicrosoft Entra ID（旧Azure AD）などのクラウドIdP（Identity Provider）を利用しています。しかし、AWS環境を運用する際には、IAMユーザーや権限をAWS側で個別に管理する必要がありました。特に複数アカウントを運用する場合には、この二重管理が大きな負担となっていました。

この二重管理の課題は、まさに燈でも直面していた問題でした。

燈は圧倒的なスピードで事業と組織が拡大しており、それに伴って社員数やプロジェクト数が急増しています。一方、管理すべきAWSアカウントやユーザー数も飛躍的に増加しており、従来のIAMユーザーによるアクセス管理では次第に限界が見え始め、権限設定の煩雑さや管理負荷の増大が大きな課題となっていました。

私たちのチームではこの課題を解決するため、AWS IAM Identity Center（旧AWS SSO）とGoogle Workspaceを連携し、Terraformで権限設定をコード化する構成を導入しました。

これにより、GoogleアカウントによるAWSへのシングルサインオン（SSO）とユーザー情報の自動同期が可能となり、アクセス権限の管理を一元化できるようになりました。また、権限設定やアカウントへの権限割り当てをTerraformでコード管理することで、変更履歴の追跡や環境の再現性が向上しました。

本記事では、AWS IAM Identity Centerを利用するメリットと、Terraformを使ったAWS権限のコード管理について、具体的な構成とともに解説します。

従来の構成と課題

従来は、エンジニアごとにIAMユーザーを個別作成し、各アカウントへのアクセスにはスイッチロールを利用していました。この方法は小規模な運用には適していましたが、事業や組織の成長とともに、以下のような課題が顕在化していきました。

ユーザー追加・削除の運用負荷:

新入社員ごとにIAMユーザーを作成する必要がある
退職者の削除漏れリスク（各アカウントへの対応が必要）

アクセスキーの管理課題:

長期間利用されるアクセスキーが存在する可能性
キーのローテーション漏れや、コード内への埋め込みによるセキュリティリスク

権限設定のばらつきと属人化:

スイッチロール先依存による権限設定
Terraform外での変更が発生し、設定の一貫性が失われやすい

マルチアカウント対応の煩雑さ:

アカウントごとのIAMユーザー重複作成、またはスイッチロール設定の複雑化と制限

IAMユーザー運用とIdentity Center構成の比較

IAM Identity Center + Terraform の構成は、従来のIAMユーザー運用と比べて運用性・セキュリティ・拡張性の面で大きな改善がありました。

観点	Before：IAMユーザー運用	After：IAM Identity Center構成
ユーザー管理	各アカウントに手動で作成・削除	Google Workspaceで一元管理（SCIM連携）
ログイン方法	AWSアカウントごとにID/PWまたはアクセスキー	GoogleアカウントでSSOログイン（SAML）
権限設定の管理	ばらつきあり、属人化	Terraformでコード化、一貫性・追跡性あり
マルチアカウント対応	スイッチロール運用（設定・管理の煩雑化）	グループと許可セットをアカウント単位で割当
セキュリティ	長期アクセスキー使用、ローテーション漏れリスク	一時的な認証情報、自動破棄

IAM Identity Centerを活用した新規アーキテクチャ

従来の課題を解決するため、AWS IAM Identity CenterとGoogle Workspaceを連携し、TerraformとGitHub Actionsを活用することで、アクセス権限の一元管理と自動化を実現しました。

（再掲）Google Workspace × AWS IAM Identity Centerの連携とTerraform × GitHub ActionsによるAWS権限管理

1. AWS IAM Identity Center の役割と Google Workspace との連携

AWS IAM Identity Centerは複数AWSアカウントやアプリケーションへのアクセスを一元管理するハブの役割を持ちます。また、グループや許可セットを設定でき、柔軟な権限設定を構築できます。

グループの割当
- IAM Identity Centerで「開発者」「管理者」などのグループを定義します。
許可セットを割当
- 例として、開発者グループにはPowerUserAccess、管理者グループにはAdministratorAccessといった許可セットを割り当てます。
マルチアカウント対応
- 同じグループに対し、複数のAWSアカウントの権限をまとめて割り当て可能です。

AWS IAM Identity Center をハブとし、Google Workspace をIdPとして連携させることで、ID管理の一元化とSSOを実現します。

SAMLによるSSO
- ユーザーはGoogleアカウントで一度ログインすれば、割り当てられたAWSアカウントやロールへアクセス可能になります。これにより、パスワード管理の負担軽減やMFA強制によるセキュリティ向上に繋がります。
SCIMによるユーザープロビジョニング
- ユーザー情報のライフサイクル管理を自動化し、Google WorkspaceからIAM Identity Centerへユーザー属性を同期します。

※Google Workspace と AWS IAM Identity Center の連携は下記を参照

docs.aws.amazon.com

2. Terraformによる権限管理とCI/CD構成

IAM Identity Centerの設定（許可セット、アカウント割り当て等）をTerraformでコード化し、バージョン管理、監査可能性、再現性を持たせています。

├── module/                         # 再利用可能なTerraformモジュール群
│   ├── organization_account/            # AWSアカウント生成
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── idc_group_permission_assignment/  # IAM Identity Centerのグループ作成、ユーザー追加、単一権限割り当てを行うサブモジュール
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   └── project_standard_access_roles/      # 標準的な複数ロール(admin,write,read)をまとめて割り当てるモジュール
│       ├── main.tf                         
│       ├── variables.tf
│       └── outputs.tf
├── projects/                       # 各AWSアカウントやチーム単位のTerraform定義
│   ├── project_A/                      
│   │   ├── main.tf                 # PJごとにModuleを呼び出しアカウントや権限設定
│   │   └── provider.tf        # providerを各PJで分離させることで影響範囲を最小化
│   └── project_B/ 
└── README.md

アカウント作成:

# modules/organization_account/main.tf

resource "aws_organizations_account" "new_account" {
  name              = var.account_name
  email             = "dx-infra+${var.account_name}@example.com" # 任意アドレスを指定
  close_on_deletion = true
  role_name         = "OrganizationAccountAccessRole"
}

各権限ごとにユーザーとグループを紐付け:

# modules/idc_group_permission_assignment/main.tf

## IAM Identity Centerのインスタンス情報を取得
data "aws_ssoadmin_instances" "main" {}

## 指定されたEメールアドレス(ユーザー名)に基づいてIAM Identity Centerのユーザー情報を取得
data "aws_identitystore_user" "target_users" {
  for_each          = toset(var.users)
  identity_store_id = tolist(data.aws_ssoadmin_instances.main.identity_store_ids)[0]

  alternate_identifier {
    unique_attribute {
      attribute_path  = "UserName"
      attribute_value = each.value
    }
  }
}

## 既存権限セットを取得
data "aws_ssoadmin_permission_set" "target_permission_set" {
  instance_arn = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  name         = var.permission_name
}


## IAM Identity Center内にグループを作成
resource "aws_identitystore_group" "assignment_group" {
  identity_store_id = tolist(data.aws_ssoadmin_instances.main.identity_store_ids)[0]
  display_name      = "${var.account_name}-${var.group_name}"
  description       = "${var.account_name} ${var.group_name} group"
}

## 作成したグループにメンバーを設定
resource "aws_identitystore_group_membership" "group_members" {
  for_each          = data.aws_identitystore_user.target_users
  identity_store_id = tolist(data.aws_ssoadmin_instances.main.identity_store_ids)[0]
  group_id          = aws_identitystore_group.assignment_group.group_id
  member_id         = each.value.user_id
}

## 作成したグループに対し、指定された許可セットを指定AWSアカウントに割り当て
resource "aws_ssoadmin_account_assignment" "account_assignment" {
  instance_arn       = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  permission_set_arn = data.aws_ssoadmin_permission_set.target_permission_set.arn
  principal_id       = aws_identitystore_group.assignment_group.group_id
  principal_type     = "GROUP"
  target_id          = var.aws_account_id
  target_type        = "AWS_ACCOUNT"
}

各種権限の割り当て:

# modules/project_standard_access_roles/main.tf

## 管理者権限の割り当て
module "admin" {
  source = "../idc_group_permission_assignment"

  group_name      = "admin"
  permission_name = "AdministratorAccess"
  account_name    = var.account_name
  aws_account_id  = var.aws_account_id
  users           = tolist(setunion(var.admin_users))
}

## 書き込み権限の割り当て
module "write" {
  source = "../idc_group_permission_assignment"

  group_name      = "write"
  permission_name = "PowerUserAccess"
  account_name    = var.account_name
  aws_account_id  = var.aws_account_id
  users           = tolist(setunion(var.admin_users, var.write_users)) # 管理者ユーザーは書き込み権限も設定
}

## 読み取り権限の割り当て
module "read" {
  source = "../idc_group_permission_assignment"

  group_name      = "read"
  permission_name = "ReadOnlyAccess"
  account_name    = var.account_name
  aws_account_id  = var.aws_account_id
  users           = tolist(setunion(var.admin_users, var.write_users, var.read_users))   # 管理者, 書き込みユーザーは読み取り権限も設定
}

PJごとのModule呼び出し:

# projects/project_A/main.tf

## アカウント作成
module "aws_account" {
  source = "../../modules/organization_account" 

  account_name = "ProjectA"
}

## 権限設定
module "a_access_roles" {
  source = "../../modules/project_standard_access_roles"

  account_name    = "ProjectA"
  aws_account_id = module.aws_account.account_id # 作成したアカウントのID

  admin_users = [
    "user_1@example.com",
    "user_2@example.com",
  ]

  write_users = [
    "user_3@example.com",
  ]

  read_users = [
    "user_4@example.com",
  ]
}

3. GitHub Actionsによる完全自動化

権限設定の変更管理とデプロイは、GitHub Actions のCI/CDパイプラインで自動化しています。 PR作成時に terraform plan を、マージ時に terraform apply を実行し、AWSへの認証にはOIDCを利用することで、静的なアクセスキーを排除してセキュリティを向上させています。

PR作成時 terraform plan 実行:

#... (on: pull_request, permissions: id-token: write など)...
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Aws Setup Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: ap-northeast-1
          # OIDC連携用のIAMロール
          role-to-assume: arn:aws:iam::ACCOUNT_ID:role/YOUR_ACTIONS_ROLE
 
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: x.x.x

      - name: Terraform Format
        run: terraform fmt -check

      - name: Terraform Init
        run: terraform init

      - name: Commit lock file
        uses: EndBug/add-and-commit@v9
        with:
          add: '.terraform.lock.hcl'
          message: '[GitHub Actions] Add .terraform.lock.hcl'
          default_author: github_actions
          pull: '--autostash'

      - name: Terraform Plan
        id: terraform_plan
        run: terraform plan -no-color -detailed-exitcode

      - name: Comment on Terraform Plan Result
        # カスタムアクションでPRに結果をコメント
        uses:./.github/actions/comment_terraform_plan
        #... (with: github_token, exitcode, stdout, stderr)...

PRマージ時に terraform apply 実行:

#... (on: pull_request, permissions: id-token: write など)...
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Aws Setup Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: ap-northeast-1
          # OIDC連携用のIAMロール
          role-to-assume: arn:aws:iam::ACCOUNT_ID:role/YOUR_ACTIONS_ROLE
 
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: x.x.x

      - name: Terraform Init
        run: terraform init

      - name: Terraform Apply
        id: terraform_apply
        run: terraform apply -auto-approve -no-color

      - name: Comment on Terraform Apply Result
        # カスタムアクションでPRに結果をコメント
        uses:./.github/actions/comment_terraform_apply
        #... (with: github_token, exitcode, stdout, stderr)...

まとめ

AWS IAM Identity Center、Google Workspace連携、Terraform、GitHub Actionsを組み合わせた新しいアクセス管理アーキテクチャにより、セキュリティ、運用効率、開発者エクスペリエンス、監査・コンプライアンスの各面で大きな効果を得ることができました。

管理工数の削減
- ユーザー・権限の一元化により、追加・削除・変更の対応が大幅に効率化されました。
属人化の解消
- 設定はすべてTerraformによりコード化され、チームでレビュー可能になりました。
セキュリティの強化
- アクセスキーを使わず、Google認証と一時トークンによる運用が可能になりました。
監査・可視性の向上
- 誰がどの権限をいつ追加・変更したかがGit上で追跡可能になりました。

この取り組みは、スケーラブルで安全、かつ管理しやすいAWS環境の基盤を構築する上で非常に有効でした。今後も改善と自動化を重ねつつ、運用効率とセキュリティの両立を目指していきます。

We're hiring

燈では、今回のような開発環境や全社基盤の構築を行うソフトウェアエンジニアを募集しています！少しでも興味を持っていただけたらカジュアル面談をしていただけると嬉しいです！

akariinc.co.jp

AKARI Tech Blog

燈株式会社のエンジニア・開発メンバーによる技術ブログです

【 IAM Identity Center × Terraform 】によるAWS権限管理アーキテクチャ

TL;DR

はじめに

従来の構成と課題

IAMユーザー運用とIdentity Center構成の比較

IAM Identity Centerを活用した新規アーキテクチャ

1. AWS IAM Identity Center の役割と Google Workspace との連携

2. Terraformによる権限管理とCI/CD構成

3. GitHub Actionsによる完全自動化

まとめ

We're hiring

TL;DR

はじめに

従来の構成と課題

IAMユーザー運用とIdentity Center構成の比較

IAM Identity Centerを活用した新規アーキテクチャ

1. AWS IAM Identity Center の役割 と Google Workspace との連携

2. Terraformによる権限管理とCI/CD構成

3. GitHub Actionsによる完全自動化

まとめ

We're hiring

1. AWS IAM Identity Center の役割と Google Workspace との連携