IAM・アクセス管理 - AWS

最終更新日: 2026-08-02

TOP(About this memo)) > 一覧(AWS) > IAM・アクセス管理

awsアカウント

AWSアカウント(1個。ルート権限)
  └ IAMユーザー(N個)

サインインURLの種類

AWSへのサインインにはユーザーの種類ごとに複数のURLパターンがあり、混同しやすい。

URL 対象 説明
https://console.aws.amazon.com/(実体はhttps://signin.aws.amazon.com/signin) ルートユーザー / IAMユーザー 汎用のサインインページ。ページ内で「ルートユーザー」か「IAMユーザー」かを選び、IAMユーザーの場合はアカウントID(またはエイリアス)も入力する
https://<アカウントIDまたはエイリアス>.signin.aws.amazon.com/console/ IAMユーザー アカウントIDの入力を省略できる、特定アカウント専用のIAMユーザー用サインインURL
https://{d-xxxxxxxxxx}.awsapps.com/start(またはカスタムサブドメイン) IAM Identity CenterのUser AWS access portal。詳細はOrganizations・IAM Identity Centerを参照
https://{リージョン}.signin.aws/platform/{d-xxxxxxxxxx}/login IAM Identity CenterのUser 2020年11月以降、AWS access portalのログイン処理の実体がこちらの新ドメインに移行した。上のURLへアクセスすると自動的にリダイレクトされる中継地点で、ブックマークすべきは.awsapps.com側のURL
https://{リージョン}.signin.aws.amazon.com/oauth等 ルートユーザー / IAMユーザー / フェデレーションID aws loginコマンド(2025年11月〜。aws_cli_iac.md参照)が使うOAuth 2.0認証フローの一部

(出典: Determine your sign-in URL、Get ready for upcoming changes in the AWS IAM Identity Center user sign-in process)

PassRole

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::*:role/example-mediaconvert-role",
  "Condition": {
    "StringEquals": { "iam:PassedToService": "mediaconvert.amazonaws.com" }
  }
}

IAM User/Group詳細

IAM Role詳細

IAMロールの機能

sts:AssumeRole

{
  "Version" : "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [ "ec2.amazonaws.com" ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

フェデレーション(Federated Identity)

上記のような「外部の認証結果を信頼してロールを引き受けさせる」仕組みを一般に**フェデレーション(ID連携)と呼ぶ。フェデレーションで認証された主体をフェデレーテッドユーザー(Federated User)**と呼び、IAMユーザーとは別の概念。

つまりフェデレーションは「IAMユーザーを作らずに、外部の認証結果をIAM Roleの一時クレデンシャルに変換する」仕組み。IAMユーザーの管理(作成・削除・パスワードローテーション等)から解放される点が最大のメリット。

主な2方式

方式 対象IdP STS API
SAML 2.0 Active Directory Federation Services(AD FS)、Okta、Azure AD等の企業向けIdP sts:AssumeRoleWithSAML
OIDC(Web Identity Federation) Google/Amazon/FacebookなどのソーシャルログインID、GitHub ActionsなどOIDC対応の外部システム sts:AssumeRoleWithWebIdentity

どちらも流れは同じ。

外部IdPで認証
    ↓
IdPがSAMLアサーション/OIDCトークンを発行
    ↓
AWS STSへ AssumeRoleWithSAML / AssumeRoleWithWebIdentity
    ↓
IAM Roleの一時クレデンシャルを取得

事前にIAM側で、その外部IdPを信頼する「IDプロバイダー」リソースを登録し、IAM Roleの信頼ポリシー(AssumeRolePolicyDocument)のPrincipalにそのIdPを指定しておく必要がある。

IAM Identity Centerとの関係

IAM Identity CenterのUserも、実体としてはこのフェデレーションの仕組みの上に成り立っている。Identity Center自体が「内蔵IdP」または「外部IdPとの連携ブローカー」として機能し、Permission Setの割り当てから裏側でIAM Roleの一時クレデンシャルを発行している。Identity Centerは、フェデレーションを複数AWSアカウント横断で扱いやすくするためのAWSのマネージドな実装、と捉えられる(IMO)。

実務でよくある例: GitHub ActionsのOIDC連携

Terraform等のCI/CDパイプラインでGitHub ActionsからAWSリソースを操作したい場合、GitHubのSecretsにIAMユーザーのアクセスキーを保存する方法は長期キーの管理・漏洩リスクがある。代わりにGitHub ActionsのOIDC機能を使うと、アクセスキーを一切使わずワークフロー実行時だけ一時クレデンシャルを取得できる。

  1. IAMでhttps://token.actions.githubusercontent.comを発行者とするOIDC IDプロバイダーを登録
  2. IAM Roleの信頼ポリシーで、対象リポジトリ・ブランチのみを許可する条件を設定(例: token.actions.githubusercontent.com:subがrepo:<org>/<repo>:ref:refs/heads/mainと一致する場合のみ許可)
  3. ワークフロー側でaws-actions/configure-aws-credentialsアクションを使い、role-to-assumeにそのロールのARNを指定

これにより、GitHub Actions実行時にIAMユーザーのアクセスキーを一切保存せずにTerraformを実行できる。

aws loginの「フェデレーションID」

aws_cli_iac.mdで紹介したaws loginコマンドが対応する3種類目の認証方式「フェデレーションID」は、IAM Identity Centerを介さず、AWSアカウントに直接SAML等でフェデレーション設定されている場合のサインイン情報を指す(Identity Center経由のログインとは別経路)。

(参考) https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html

ポリシー

(例) AmazonS3ReadOnlyAccess: S3のリソースに対する参照操作を許可。 このポリシーをEC2インスタンスに関連づけると(正確にはIAMロールを経由して関連づける)、そのEC2インスタンス上のプログラム(AWS CLI、AWS SDKを利用したプログラム)からS3リソースに対する参照操作(Get、List)が可能になる。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

ポリシーの分類

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"},
    "Action": [
      "s3:PutObject",
      "s3:PutObjectAcl"
    ],
    "Resource": "arn:aws:s3:::example-bucket/*"
  }
}

ポリシーでIAMユーザーの操作を制限する具体例(2022/1/24時点でのメモ)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "route53:ListTagsForResources",
                "route53:GetHostedZone",
                "route53:ChangeResourceRecordSets",
                "route53:ListResourceRecordSets",
                "route53:ListTagsForResource"
            ],
            "Resource": "arn:aws:route53:::hostedzone/ZXXXXXXXXXXXXX"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "route53:ListHostedZones",
                "route53:GetHostedZoneCount",
                "route53:ListHostedZonesByName"
            ],
            "Resource": "*"
        }
    ]
}

セキュリティグループ(EC2などの仮想ファイアウォール)についてはセキュリティグループを参照。

ARN(Amazon Resource Name)

Amazon リソースネーム(ARN)は、AWSリソースを一意に識別する。IAMポリシー、Amazon RDSのタグ、APIコールなど、AWS全体に渡るリソースを指定する必要がある場合にARNが必要になる。

arn:partition:service:region:account-id:resource
arn:partition:service:region:account-id:resourcetype/resource
arn:partition:service:region:account-id:resourcetype:resource

EC2構文例:

arn:aws:ec2:region:account-id:instance/instance-id
arn:aws:ec2:region:account-id:volume/volume-id

S3構文例:

arn:aws:s3:::bucket_name
arn:aws:s3:::bucket_name/key_name

S3はリージョン・アカウントIDが不要。そのためバケット名がグローバルに一意である必要がある(?)。

RDS構文例:

arn:aws:rds:region:account-id:db:db-instance-name
arn:aws:rds:region:account-id:cluster:db-cluster-name

AWS CLI、RDS APIを使用する際に利用する。その際にはタグと共に使用する。

This site is open source. Improve this page.