お疲れ様です！IT業界で働くアライグマです！
「IAMユーザーのアクセスキーを発行してはダメと言われたけど、じゃあどうすればいいの？」「AssumeRoleって聞いたことはあるけど、実際どう使うの？」——AWSを使い始めた開発者が最初にぶつかる壁の一つが、IAMの認証設計です。
この記事では、IAMユーザーの永続的な認証情報を使わず、AssumeRoleによる一時認証情報でAWSリソースにアクセスする方法を解説します。クロスアカウントアクセスやCI/CDパイプラインなど、実務でよく使うパターンを中心に説明します。
AssumeRoleとは何か：IAMの基本概念を整理する
まず、AssumeRoleを理解するために必要な基本概念を整理します。
IAMユーザーとIAMロールの違い
- IAMユーザー：永続的な認証情報（アクセスキー/シークレットキー）を持つ。「社員証」のようなもの。漏洩すると、削除するまで不正アクセスされ続ける
- IAMロール：永続的な認証情報を持たない。「一時的に被る帽子」のようなもの。必要なときだけ権限を借りる
AssumeRoleとは
AssumeRoleは、IAMロールを引き受ける（Assume）ためのAPIアクションです。AssumeRoleを実行すると、一時的な認証情報（STS Token）が発行され、そのロールに付与された権限を使えるようになります。
一時的な認証情報には以下の特徴があります。
- 有効期限がある：デフォルト1時間、最大12時間で自動失効
- 取り消し不要：漏洩しても有効期限が切れれば使えなくなる
- ローテーション不要：毎回新しい認証情報が発行される
AWSセキュリティの基本については、NIST SP 800-63 パスワードガイドライン解説：定期変更不要・複雑性ルール廃止の根拠と実装のポイントも参考になります。
IT女子 アラ美
ITアライグマAssumeRoleの仕組み：信頼ポリシーと権限ポリシー
AssumeRoleを設定するには、信頼ポリシー（Trust Policy）と権限ポリシー（Permission Policy）の2つを理解する必要があります。
信頼ポリシー（Trust Policy）
信頼ポリシーは、「誰がこのロールを引き受けられるか」を定義します。ロールに直接アタッチするJSON形式のポリシーです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "sts:AssumeRole"
}
]
}
この例では、AWSアカウント123456789012からのAssumeRoleを許可しています。
権限ポリシー（Permission Policy）
権限ポリシーは、「ロールを引き受けた後に何ができるか」を定義します。通常のIAMポリシーと同じ形式です。
AssumeRoleの流れ
- 呼び出し側が
sts:AssumeRoleを実行 - AWSのSTSが信頼ポリシーをチェック
- 許可されていれば一時認証情報を発行
- 呼び出し側が一時認証情報でAWSリソースにアクセス
IAMポリシーの設計については、Pythonデータ処理によるAWSコスト削減術：計算リソース最適化とAthenaスキャン量節約の実践ガイドも参考になります。
IT女子 アラ美ITアライグマステップ1：クロスアカウントアクセスの設定
ここでは、最も一般的なユースケースであるクロスアカウントアクセスの設定手順を解説します。
シナリオ
- アカウントA（開発アカウント）のEC2インスタンスから
- アカウントB（本番アカウント）のS3バケットにアクセスしたい
手順1：アカウントBでIAMロールを作成
アカウントBで、アカウントAからのAssumeRoleを許可するロールを作成します。
# AWS CLIでロールを作成
aws iam create-role \
--role-name CrossAccountS3ReadRole \
--assume-role-policy-document file://trust-policy.json
trust-policy.jsonの内容：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/EC2InstanceRole"
},
"Action": "sts:AssumeRole"
}
]
}
手順2：権限ポリシーをアタッチ
# S3読み取り権限をアタッチ
aws iam attach-role-policy \
--role-name CrossAccountS3ReadRole \
--policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
手順3：アカウントAからAssumeRoleを実行
import boto3
# STSクライアントを作成
sts_client = boto3.client('sts')
# AssumeRoleを実行
response = sts_client.assume_role(
RoleArn='arn:aws:iam::222222222222:role/CrossAccountS3ReadRole',
RoleSessionName='CrossAccountSession'
)
# 一時認証情報を取得
credentials = response['Credentials']
# 一時認証情報でS3クライアントを作成
s3_client = boto3.client(
's3',
aws_access_key_id=credentials['AccessKeyId'],
aws_secret_access_key=credentials['SecretAccessKey'],
aws_session_token=credentials['SessionToken']
)
# S3バケットの一覧を取得
buckets = s3_client.list_buckets()
print(buckets)
EC2インスタンスからの実行については、オンプレエンジニアがクラウドネイティブ環境に移行するためのスキルギャップ解消戦略も参考になります。
IT女子 アラ美ITアライグマステップ2：CI/CDパイプラインでのOIDC連携
GitHub ActionsやGitLab CIなどのCI/CDパイプラインでは、OIDC（OpenID Connect）連携を使うことで、アクセスキーを一切使わずにAWSリソースにアクセスできます。
GitHub ActionsでのOIDC連携
手順1：IDプロバイダーを作成
# GitHub Actions用のIDプロバイダーを作成
aws iam create-open-id-connect-provider \
--url https://token.actions.githubusercontent.com \
--client-id-list sts.amazonaws.com \
--thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1
手順2：信頼ポリシーを設定
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:*"
}
}
}
]
}
手順3：GitHub Actionsワークフローで使用
name: Deploy to AWS
on:
push:
branches: [main]
permissions:
id-token: write
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
aws-region: ap-northeast-1
- name: Deploy
run: aws s3 sync ./dist s3://my-bucket/
CI/CDパイプラインの設計については、GitHub Copilotを極める：エージェントモードとカスタム命令で開発生産性を最大化する実践ガイドも参考になります。
IT女子 アラ美ITアライグマケーススタディ：マルチアカウント環境のIAM設計を導入した事例
状況（Before）
都内のSaaS企業で、AWS Organizationsを使ったマルチアカウント環境を運用していました。
- アカウント数：開発・ステージング・本番の3アカウント
- 開発者数：10名
- 課題：各アカウントにIAMユーザーを作成し、アクセスキーを発行していた。30個以上のアクセスキーが存在し、ローテーション管理が破綻
- リスク：退職者のアクセスキーが残っている可能性があり、セキュリティ監査で指摘
行動（Action）
IAM Identity Center（旧AWS SSO）とAssumeRoleを導入し、IAMユーザーのアクセスキーを廃止しました。
- IAM Identity Centerを設定（1週間目）：AWS Organizationsの管理アカウントでIAM Identity Centerを有効化。Googleワークスペースと連携し、既存の社員アカウントでログインできるように設定
- PermissionSetを設計（2週間目）：開発者用（
DeveloperAccess）、運用者用（OperatorAccess）、管理者用（AdminAccess）の3種類を作成。それぞれの権限を最小権限の原則に基づいて設計 - 既存アクセスキーの棚卸し（3週間目）：
aws iam list-access-keysで全アカウントのアクセスキーを洗い出し。180日以上未使用のキーを削除。アクティブなキーは担当者に確認し、AssumeRole方式への移行を依頼 - CI/CDパイプラインをOIDC連携に移行（4週間目）：GitHub ActionsとGitLab CIのパイプラインを、アクセスキーからOIDC連携に切り替え。シークレットからアクセスキーを削除
結果（After）
- アクセスキー削減：30個 → 0個（100%削減）
- 運用工数削減：アクセスキーのローテーション作業（月2時間 × 12ヶ月 = 年24時間）がゼロに
- セキュリティ監査：指摘事項ゼロでクリア
- 開発者体験：Googleアカウントでログインするだけで各アカウントにアクセスでき、認証情報の管理が不要に
ハマりポイント
移行中に既存のCI/CDパイプラインが動かなくなる問題が発生。原因は、OIDC連携への移行中に旧アクセスキーを先に削除してしまったこと。移行手順を「新方式を先に設定 → 動作確認 → 旧方式を削除」に修正することで解決しました。
セキュリティ監査の対策については、Trail of Bits skillsでClaude Codeにセキュリティ監査を任せる：脆弱性検出・コードレビュー自動化の実践ガイドも参考になります。
IT女子 アラ美ITアライグマさらなる実践・活用に向けて
AssumeRoleをさらに活用するためのステップを紹介します。
ステップ1：AWS CLIでプロファイルを設定
~/.aws/configにAssumeRole用のプロファイルを設定すると、コマンドラインから簡単にロールを切り替えられます。
[profile dev]
region = ap-northeast-1
[profile prod]
region = ap-northeast-1
role_arn = arn:aws:iam::222222222222:role/ProdReadRole
source_profile = dev
ステップ2：セッションポリシーで権限を絞る
AssumeRole時にセッションポリシーを指定すると、ロールの権限をさらに絞り込めます。
ステップ3：CloudTrailでAssumeRoleを監査
CloudTrailでAssumeRoleの実行履歴を記録し、誰が・いつ・どのロールを引き受けたかを監査できるようにしておきましょう。
AWSのインフラ設計については、仕様駆動開発入門：AIエージェントで設計8割・開発2割を実現するシステム開発手法の実践ガイドも参考になります。
さらなる年収アップやキャリアアップを目指すなら、ハイクラス向けの求人に特化した以下のサービスがおすすめです。
| 比較項目 | TechGo | レバテックダイレクト | ビズリーチ |
|---|---|---|---|
| 年収レンジ | 800万〜1,500万円ハイクラス特化 | 600万〜1,000万円IT専門スカウト | 700万〜2,000万円全業界・管理職含む |
| 技術スタック | モダン環境中心 | Web系に強い | 企業によりバラバラ |
| リモート率 | フルリモート前提多数 | 条件検索可能 | 原則出社も多い |
| おすすめ度 | 技術で稼ぐならここ | A受身で探すなら | Bマネジメント層向け |
| 公式サイト | 無料登録する | - | - |
IT女子 アラ美ITアライグマまとめ
AWSのAssumeRoleを使った認証設計のポイントを振り返ります。
- IAMユーザーのアクセスキーは漏洩リスクが高い。AssumeRoleによる一時認証情報を使うのがベストプラクティス
- AssumeRoleには信頼ポリシー（誰がAssume可能か）と権限ポリシー（何ができるか）の2つが必要
- クロスアカウントアクセスやCI/CDパイプラインでは、OIDC連携を活用してアクセスキーをゼロにできる
- IAM Identity Centerを使うと、マルチアカウント環境でも統一的なアクセス管理が可能
AssumeRoleは、AWSセキュリティの基本中の基本です。まずは小さなスコープから導入し、徐々に範囲を広げていくのがおすすめです。
IT女子 アラ美ITアライグマ
