1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@0h-n0

AWS IAM・Identity Center・Permission Boundaryで実現するマルチアカウント権限管理の実践ガイド

1
Last updated at Posted at 2026-03-16

AWS IAM・Identity Center・Permission Boundaryで実現するマルチアカウント権限管理の実践ガイド

「明日からAWS運用を任された」——そんな状況で最初にぶつかる壁が 権限管理 です。IAMユーザーを手動で作成し、アクセスキーを発行し、ポリシーをアタッチする……という運用は2026年ではアンチパターンとされています。本記事では、AWS公式が推奨する IAM Identity Center（旧AWS SSO）を中心に、Permission Boundary と SCP（Service Control Policy）を組み合わせたマルチアカウント権限管理の設計と運用を、MLEの視点からゼロベースで解説します。

この記事でわかること

  • AWS IAMの基本概念と2026年時点で推奨される認証・認可の全体像
  • IAM Identity Centerを使った一時認証情報ベースのアクセス管理の設計・設定方法
  • Permission Boundaryによる開発者への権限委譲パターンの実装
  • SCP・Permission Boundary・Identity Policyの3層構造による有効権限の計算方法
  • マルチアカウント環境（AWS Organizations + Control Tower）のOU設計と権限管理のベストプラクティス

対象読者

  • 想定読者: AWSのIAM管理を初めて担当するエンジニア、または既存のIAMユーザー運用からIdentity Centerへの移行を検討しているチーム
  • 必要な前提知識:
    • AWSアカウントの基本操作（マネジメントコンソールへのログイン）
    • JSONの基本的な読み書き
    • 「認証」と「認可」の違いの理解（ML/データサイエンスでのAPI認証経験があれば十分）

結論・成果

IAM Identity Center + Permission Boundary + SCPの3層構造を導入することで、以下の成果が報告されています。

  • アクセスキー流出リスクの排除: 一時認証情報（最大12時間有効）への完全移行により、長期クレデンシャルの管理が不要に（AWS IAMベストプラクティス）
  • 権限管理の工数を約60%削減: Permission Setの集中管理により、アカウントごとの個別IAMユーザー管理が不要に（AWS Prescriptive Guidanceによる推奨パターン）
  • 権限昇格インシデントの防止: Permission Boundaryで開発者が自分自身の権限を超えるIAMロールを作成することを構造的に防止
  • 障害時のアクセス継続: 2026年2月にGAとなったIAM Identity Centerマルチリージョンレプリケーションにより、プライマリリージョン障害時もアクセス可能（AWS公式ブログ）

IAMの基本概念を整理する

AWSの権限管理を理解するには、まず 認証（Authentication: 「誰であるか」の確認）と 認可（Authorization: 「何ができるか」の判定）を区別することが重要です。ML/データサイエンスでいえば、APIキーでのモデルエンドポイント認証と、そのキーに紐づく呼び出し権限の違いに相当します。

IAMの主要コンポーネント

AWSのIAMは以下の要素で構成されています。

コンポーネント 役割 ML/DSでの類推
IAMユーザー 長期クレデンシャルを持つ永続的なID APIキーが永続的に有効な状態
IAMロール 一時クレデンシャルを発行する仮の身分証 OAuth2のアクセストークン（有効期限あり）
IAMポリシー 「何に対して何ができるか」のJSON定義 MLflowの権限設定ファイル
IAMグループ ユーザーをまとめてポリシーを適用 チーム単位のアクセス制御

2026年のIAM: 何が変わったのか

AWS公式のセキュリティベストプラクティスでは、以下が明確に推奨されています。

  1. 人間ユーザーにはIAM Identity Center経由の一時認証情報を使用する（IAMユーザーの新規作成は非推奨）
  2. ワークロードにはIAMロールを使用する（EC2、Lambda等のコンピューティングサービス）
  3. MFAはフィッシング耐性のある方式（パスキー、セキュリティキー）を優先
  4. IAM Access Analyzerで未使用の権限を定期的に棚卸し

注意: 2026年時点で、IAMユーザー + アクセスキーの運用は「レガシーパターン」です。新規環境では必ずIAM Identity Centerを使いましょう。既存環境の移行も計画的に進めることが推奨されています。

IAM Identity Centerを設計・設定する

IAM Identity Center（旧AWS SSO）は、AWS Organizationsと統合された 一元的なアクセス管理サービス です。Pythonでいえば、各プロジェクトごとに .env ファイルでAPIキーを管理していた状態から、HashiCorp Vaultのような中央集権型のシークレット管理に移行するイメージです。

IAM Identity Centerが解決する3つの課題

IAM Identity Centerを導入すると、従来のIAMユーザー運用で発生していた以下の問題が解消されます。

1. アクセスキーの氾濫

従来のIAMユーザー運用では、開発者ごとにアクセスキーを発行し、ローカルの ~/.aws/credentials に保存します。このキーは明示的にローテーションしない限り永続的に有効で、流出時のリスクが非常に高い状態です。

IAM Identity Centerでは、aws sso login コマンドでブラウザ認証を行い、最大12時間有効な一時認証情報を自動取得します。

# IAM Identity Center経由のログイン
aws configure sso
# SSO session name: my-org
# SSO start URL: https://my-org.awsapps.com/start
# SSO region: ap-northeast-1
# SSO registration scopes: sso:account:access

# ログイン（ブラウザが開く）
aws sso login --profile dev-account

# 一時認証情報で操作（12時間有効）
aws s3 ls --profile dev-account

2. アカウントごとの権限管理の分散

10個のAWSアカウントがある場合、従来は各アカウントにIAMユーザーを作成し、個別にポリシーを管理する必要がありました。IAM Identity Centerでは Permission Set（権限セット）を一度定義すれば、複数アカウントに一括適用できます。

3. 退職・異動時の権限剥奪の遅延

IAMユーザーの削除忘れは、セキュリティインシデントの主要な原因です。IAM Identity Centerは外部IdP（Microsoft Entra ID、Okta等）と連携し、IdP側でユーザーを無効化すれば即座にAWSアクセスも停止されます。

Permission Setの設計パターン

Permission Setは、IAM Identity Centerでユーザーやグループに割り当てる権限テンプレートです。以下に実務で使われる代表的な設計パターンを示します。

Permission Set名 用途 ベースポリシー カスタマイズ例
AdministratorAccess フルアクセス（運用チーム） AWS管理ポリシー セッション時間を4時間に制限
DeveloperAccess 開発用（読み取り + CloudFormation経由のデプロイ） ReadOnlyAccess + インラインポリシー IAMロール作成はPermission Boundary付きのみ
DataScientistAccess ML/データ分析用 カスタムポリシー SageMaker, S3, Athena, Glueへのアクセス
ReadOnlyAccess 監査・閲覧用 AWS管理ポリシー CloudTrail, Config, GuardDutyのダッシュボード閲覧

なぜこの設計を選んだか:

  • AWS管理ポリシーをベースにすることで、AWSの新サービス追加時に自動的に権限が更新される
  • カスタムポリシーはML/データ分析のような特化型ワークロードのみに使用し、管理コストを最小化
  • セッション時間の制限により、万が一の一時認証情報流出時の影響を軽減

注意: AdministratorAccessのPermission Setは、本番アカウントへの割り当てを慎重に検討してください。可能であればBreak Glass用の緊急アクセスに限定し、通常運用では権限を絞ったPermission Setを使用します。

ABAC（属性ベースアクセス制御）の活用

IAM Identity CenterはABAC（Attribute-Based Access Control）をサポートしています。RBACでは「データサイエンティストロール」に対してポリシーを定義しますが、ABACではユーザーの 属性（部署、プロジェクト、コストセンター等）に基づいてアクセスを制御します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::project-*/*",
      "Condition": {
        "StringEquals": {
          "s3:ExistingObjectTag/project": "${aws:PrincipalTag/project}"
        }
      }
    }
  ]
}

このポリシーでは、ユーザーの project タグと一致するS3オブジェクトのみアクセスを許可しています。ABACを使うと、プロジェクトが増えるたびにPermission Setを作り直す必要がなくなります。

ABACのトレードオフ:

  • メリット: Permission Setの数を削減（10プロジェクト × 4ロール = 40セットが、タグベースで数セットに）
  • デメリット: タグの命名規則と運用ルールの整備が必要。タグ付け漏れがアクセス不能を引き起こす

Permission Boundaryで開発者に権限を委譲する

Permission Boundaryは、IAMエンティティ（ユーザー・ロール）に設定できる 権限の上限 です。ML/データサイエンスでいえば、Jupyter Notebookのリソース制限（GPUメモリ上限、ディスククォータ）に似た概念です。ユーザーに「IAMロールを自由に作ってよい」と権限を与えつつ、「ただしこの範囲内で」という制約を構造的に強制します。

有効権限の計算方法

AWSにおける有効権限は、複数のポリシータイプの 交差（intersection）で計算されます。

有効権限 = Identity Policy ∩ Permission Boundary ∩ SCP ∩ Resource Policy

具体例で見てみましょう。

この例では:

  • Identity Policyで iam:* が許可されていても、Permission Boundaryに iam:* がないため IAM操作は拒否
  • Identity Policyに lambda:* がなくても、Permission Boundaryで許可されているだけでは Lambda操作は拒否（Identity Policyでの許可も必要）
  • SCPのリージョン制限により、すべての操作が ap-northeast-1 に限定

Permission Boundaryの実装例

以下は、開発者にIAMロール作成を委譲しつつ、権限昇格を防止するPermission Boundaryの実装例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCommonServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "lambda:*",
        "apigateway:*",
        "dynamodb:*",
        "logs:*",
        "cloudwatch:*",
        "events:*",
        "sqs:*",
        "sns:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowIAMRoleCreationWithBoundary",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy",
        "iam:DetachRolePolicy",
        "iam:DeleteRolePolicy",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "arn:aws:iam::*:role/app/*",
      "Condition": {
        "ArnEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::*:policy/DeveloperBoundary"
        }
      }
    },
    {
      "Sid": "AllowRoleManagement",
      "Effect": "Allow",
      "Action": [
        "iam:DeleteRole",
        "iam:TagRole",
        "iam:UntagRole",
        "iam:UpdateAssumeRolePolicy",
        "iam:UpdateRole",
        "iam:UpdateRoleDescription",
        "iam:GetRole",
        "iam:ListRoles",
        "iam:PassRole"
      ],
      "Resource": "arn:aws:iam::*:role/app/*"
    },
    {
      "Sid": "DenyBoundaryModification",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRolePermissionsBoundary",
        "iam:DeletePolicy",
        "iam:DeletePolicyVersion",
        "iam:CreatePolicyVersion"
      ],
      "Resource": "arn:aws:iam::*:policy/DeveloperBoundary"
    }
  ]
}

このポリシーのポイント:

  1. AllowIAMRoleCreationWithBoundary: 開発者がIAMロールを作成できるが、必ず DeveloperBoundary をPermission Boundaryとしてアタッチする条件付き。これにより、新しく作られたロールも同じ権限上限の制約を受ける
  2. Resource: "arn:aws:iam::*:role/app/*": 作成できるロールの名前を app/ プレフィックス付きに限定。管理者ロールの改ざんを防止
  3. DenyBoundaryModification: Permission Boundary自体の変更・削除を明示的に拒否。これがないと、開発者がBoundaryを外して権限昇格できてしまう

よくある間違い: Permission Boundaryを設定しただけで安心してしまうケースがあります。iam:DeleteRolePermissionsBoundary アクションを明示的にDenyしなければ、開発者が自分でBoundaryを外すことが可能です。これは実際に発生しやすいセキュリティ上の見落としです。

CloudFormation StackSetsでOrganization全体に展開

Permission BoundaryをOrganization内の全アカウントに一括展開するには、CloudFormation StackSetsが適しています。

# permission-boundary-stackset.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: "Permission Boundary for developer delegation"

Resources:
  DeveloperBoundary:
    Type: "AWS::IAM::ManagedPolicy"
    Properties:
      ManagedPolicyName: "DeveloperBoundary"
      Description: "Permission boundary for developer-created roles"
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Sid: AllowCommonServices
            Effect: Allow
            Action:
              - "s3:*"
              - "lambda:*"
              - "apigateway:*"
              - "dynamodb:*"
              - "logs:*"
              - "cloudwatch:*"
              - "events:*"
            Resource: "*"
          - Sid: DenySecurityServices
            Effect: Deny
            Action:
              - "iam:CreateUser"
              - "iam:CreateAccessKey"
              - "organizations:*"
              - "account:*"
            Resource: "*"

  CloudFormationRole:
    Type: "AWS::IAM::Role"
    Properties:
      RoleName: "CloudFormationRole"
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: !Sub "cloudformation.${AWS::URLSuffix}"
            Action: "sts:AssumeRole"
      ManagedPolicyArns:
        - !Sub "arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess"
      PermissionsBoundary: !Ref DeveloperBoundary

# StackSetsでOrganization全体にデプロイ
aws cloudformation create-stack-set \
  --stack-set-name permission-boundary \
  --template-body file://permission-boundary-stackset.yaml \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false

# 全OUに展開
aws cloudformation create-stack-instances \
  --stack-set-name permission-boundary \
  --deployment-targets OrganizationalUnitIds='["ou-xxxx-yyyyyyyy"]' \
  --regions '["ap-northeast-1"]'

注意: StackSetsの SERVICE_MANAGED 権限モデルを使用する場合、AWS Organizationsの信頼されたアクセスが有効化されている必要があります。SELF_MANAGED モデルでは各アカウントに管理ロールを手動で作成する必要があり、スケーラビリティに劣ります。

SCPとPermission Boundaryを使い分ける

SCP（Service Control Policy）とPermission Boundaryは、どちらも「権限の上限を設定する」という点で似ていますが、適用レベルと用途が異なります。

3つのガードレールの比較

項目 SCP Permission Boundary Identity Policy
適用レベル Organization / OU / アカウント IAMユーザー / IAMロール IAMユーザー / IAMロール / グループ
権限の付与 しない（制限のみ） しない（制限のみ） する
管理者 Organization管理者 アカウント管理者 アカウント管理者 / 委譲された開発者
適用範囲 全メンバーアカウント（管理アカウントは対象外） 指定されたエンティティのみ 指定されたエンティティのみ
主な用途 組織全体のコンプライアンス 開発者への権限委譲 実際の権限付与

SCPの実装例: リージョン制限とセキュリティガードレール

以下は、日本リージョン以外の利用を禁止し、セキュリティサービスの無効化を防止するSCPの例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "us-east-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
        }
      }
    },
    {
      "Sid": "DenyDisablingSecurityServices",
      "Effect": "Deny",
      "Action": [
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "config:StopConfigurationRecorder",
        "config:DeleteConfigurationRecorder",
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    }
  ]
}

なぜ us-east-1 を許可しているか: IAMやRoute 53など、グローバルサービスの一部は us-east-1 でのみ操作が可能です。完全にブロックすると正常な運用に支障をきたします。

制約条件: SCPは管理アカウント自体には適用されません。管理アカウントのセキュリティは、SCPではなくIAMポリシーで直接制御する必要があります。

使い分けの判断フロー

マルチアカウント環境のOU設計を構築する

AWS Organizationsでは、OU（Organizational Unit）を使ってアカウントを論理的にグループ化し、SCPを階層的に適用します。ML/データサイエンスでいえば、実験管理ツール（MLflow）でのプロジェクト・実験・ランの階層構造に似た概念です。

推奨OU構成

AWS Control Towerのランディングゾーンガイドで推奨されている構成を基に、実務で使われるOU構成を示します。

Root
├── Security OU（基盤OU: 必須）
│   ├── Log Archive アカウント
│   └── Audit アカウント
├── Infrastructure OU（基盤OU: 推奨）
│   ├── Shared Services アカウント
│   └── Network アカウント
├── Sandbox OU
│   └── 個人実験用アカウント群
├── Workloads OU
│   ├── Dev OU
│   │   └── 開発アカウント群
│   ├── Staging OU
│   │   └── ステージングアカウント群
│   └── Prod OU
│       └── 本番アカウント群
└── Suspended OU
    └── 利用停止アカウント群

各OUに適用するSCPの例:

OU 適用SCP 目的
Security 変更制限SCP ログ・監査設定の改ざん防止
Sandbox コスト制限SCP + リージョン制限SCP 実験費用の暴走防止
Workloads/Dev 開発者向けSCP（緩め） 開発の柔軟性を確保
Workloads/Prod 本番SCP（厳格） セキュリティサービス無効化の防止、リージョン制限
Suspended 全拒否SCP アカウント内の全操作をブロック

ハマりポイント: OUのネスト（入れ子）を深くしすぎると、SCPの継承関係が複雑になり、意図しない権限拒否が発生します。AWS Control TowerではネストされたOU機能をサポートしていますが、3階層以内 に収めることが推奨されています。

IAM Identity Center + OU構成の統合

IAM Identity CenterのPermission Setは、ユーザーグループとアカウントの組み合わせに割り当てます。

# 概念的な権限マッピング（実際はAWSコンソールまたはCLIで設定）
permission_mapping = {
    "DevelopersGroup": {
        "dev-account": "DeveloperAccess",      # 開発: フル開発権限
        "stg-account": "DeveloperAccess",      # ステージング: 同上
        "prod-account": "ReadOnlyAccess",      # 本番: 読み取りのみ
    },
    "DataTeamGroup": {
        "dev-account": "DataScientistAccess",  # 開発: ML/データ権限
        "data-account": "DataScientistAccess", # データ: ML/データ権限
        "prod-account": "ReadOnlyAccess",      # 本番: 読み取りのみ
    },
    "OpsTeamGroup": {
        "dev-account": "AdministratorAccess",  # 全環境: フルアクセス
        "stg-account": "AdministratorAccess",
        "prod-account": "AdministratorAccess",
    },
    "AuditGroup": {
        "all-accounts": "ReadOnlyAccess",      # 全環境: 読み取りのみ
    },
}

# CLI での Permission Set 割り当て例
aws sso-admin create-account-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxx \
  --target-id 123456789012 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxx/ps-yyyy \
  --principal-type GROUP \
  --principal-id "group-id-developers"

よくある問題と解決方法

IAM権限管理で遭遇しやすい問題と対処法をまとめます。

問題 原因 解決方法
Permission Boundaryを設定したのにアクセスが拒否される Identity Policyでアクションが許可されていない Boundaryは上限設定のみ。実際の権限付与にはIdentity Policyも必要
SCPで許可したはずのアクションが拒否される SCPは許可ではなく「許可の上限」 SCPに Allow を書くだけでは権限は付与されない。別途Identity Policyが必要
IAMロールを作成できない（AccessDenied） Permission Boundary条件が不一致 iam:PermissionsBoundary 条件で指定したARNとアタッチしようとしているBoundaryのARNを確認
us-east-1 リージョンのSCP制限でグローバルサービスが使えない IAM等はグローバルサービスだが操作は us-east-1 経由 SCPのリージョン制限で us-east-1 を許可リストに含める
Permission SetのカスタムポリシーがPermission Boundaryを参照できない 各アカウントにBoundaryポリシーが存在しない StackSetsで全メンバーアカウントにBoundaryポリシーを事前デプロイ
管理アカウントにSCPが適用されない SCPの仕様（管理アカウントは対象外） 管理アカウントのルートユーザーとIAMには直接ポリシーを設定

まとめと次のステップ

まとめ:

  • IAM Identity Center が2026年のAWSにおける人間ユーザーの認証・認可の標準。IAMユーザー + アクセスキーの運用は非推奨
  • Permission Boundary は開発者への権限委譲を安全に実現する仕組み。有効権限は Identity Policy ∩ Boundary ∩ SCP の交差で決まる
  • SCP はOrganization全体のガードレール、Permission Boundary はアカウント内の個別エンティティの権限上限
  • OU設計 は3階層以内に収め、環境（Dev/Stg/Prod）ごとに異なるSCPを適用
  • 2026年2月にGAとなった IAM Identity Centerマルチリージョンレプリケーション により、リージョン障害時のアクセス継続が可能に

次にやるべきこと:

  1. IAM Identity Centerの有効化: AWS Organizationsで有効化し、既存のIAMユーザーからの移行計画を策定する
  2. Permission Boundaryの定義とStackSets展開: 自社の開発者が利用するAWSサービスを洗い出し、Boundaryポリシーを作成。StackSetsで全アカウントにデプロイ
  3. IAM Access Analyzerの導入: 未使用の権限を定期的に棚卸しし、最小権限の原則を継続的に適用する

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?