はじめに
目的
本記事は、AWSでのユーザーへロールを割り当てる仕組みと実践手順をやさしく解説します。IAMロールの意味や作り方、ユーザーへ権限を付与する方法、複数アカウントで便利なスイッチロール機能まで網羅します。現場で使えるポイントも盛り込みます。
対象読者
クラウド運用の初心者から中級者を想定します。AWSのコンソールに触れたことがある方は理解が速く、未経験の方も具体例で学べます。
本記事の構成と読み方
第2章で基本概念、第3章でロール作成手順、第4章でユーザーへの権限付与方法、第5・6章でスイッチロールの考え方と設定手順、第7章で導入時の注意点を説明します。章ごとに手順と考え方を分けているので、必要な章だけ読んでも実務に役立ちます。
前提知識
AWSアカウントを持ち、管理者権限でコンソールにログインできることを前提にします。コマンド操作は後半で簡単に触れますが、基本はコンソール操作で説明します。
IAMロールの基本概念と役割
概要
IAMロールは、ある主体(サービス、他アカウント、フェデレーションユーザー、IAMユーザーなど)が一時的に引き受けて使える権限の集合です。ロール自体は人やリソースではなく、権限を与えるための「肩書き」のようなものです。
主な構成要素
- 信頼ポリシー(誰がロールを引き受けられるかを定義)
- 権限ポリシー(ロールが何をできるかを定義)
- セッショントークン(引き受け時に発行される一時的な認証情報)
利用シーン(具体例)
- EC2がS3にアクセスする場合にEC2にロールを割り当てる。これで長期的なキーは不要です。
- 別アカウントの管理者が自分のアカウントから操作するためにクロスアカウントロールを使う。
ユーザーとの違い
IAMユーザーは恒久的な認証情報を持ちますが、ロールは一時的で再利用可能です。柔軟に権限を切り替えられる点が利点です。
セキュリティ上のポイント
最小権限の原則を守り、信頼ポリシーを厳格に設定してください。ロールの使用履歴をログで監査すると不正検出に役立ちます。
運用のヒント
用途ごとにロールを分け、名前付けと説明を明確にしてください。期限付きのセッションを活用してリスクを下げます。
ロール作成の実装手順
概要
IAMでロールを作成する流れを、実際の操作手順に沿ってわかりやすく説明します。ここではAWS管理コンソールを使った例を中心にします。
手順(コンソール)
- IAMダッシュボードを開き、左メニューの「Roles」をクリックします。
- 「Create role」を押します。
- 信頼するエンティティのタイプを選択します。例:
- AWS service(EC2などのサービスが引き受ける場合)
- Another AWS account(別アカウントから引き受ける場合)
- Web identity / SAML(フェデレーション時)
- 該当するサービスやアカウントIDを指定します(例:EC2を選択)。
- ポリシーを選んで権限を付与します。必要最小限のポリシーを選びます。マネージドポリシーかカスタムポリシーを選べます。
- (任意)Permissions boundaryを設定して権限上限を決めます。
- タグを追加し、ロール名と説明を入力します。
- 内容を確認して「Create role」をクリックします。
実例
EC2がS3にアクセスする場合は、信頼エンティティにEC2を指定し、S3アクセス用のポリシー(例:S3ReadOnly)をアタッチします。EC2にロールを割り当てることで、インスタンスから安全にS3へアクセスできます。
注意点
- 信頼ポリシー(AssumeRoleの設定)とアクセス権限ポリシーは別です。どちらも確認してください。
- 最小権限の原則を守り、不要な権限は付与しないでください。
IAMユーザーへの権限付与方法
概要
IAMユーザーをプリンシパルとして特定リソースへのアクセスを許可するには、ポリシーを作成して割り当てます。効率的な管理のために、ユーザーをグループに入れ、グループにポリシーを付与して継承させる方法を推奨します。
手順(簡単な流れ)
- ポリシーを作成します。必要な操作(Actions)、対象リソース(Resources)、許可か拒否か(Effect)を定義します。
- グループを作成し、作成したポリシーをグループに割り当てます。
- 対象のユーザーをグループに追加します。これでユーザーはグループの権限を継承します。
- 必要に応じて、個別ユーザーにポリシーを直接付与できますが、管理負荷が増えるため最小限にします。
ポリシー例(簡易)
下は特定のS3バケットからオブジェクトを取得する権限を与える例です。バケット名は実際の名前に置き換えてください。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::my-bucket/*"]
}]
}
注意点と運用のコツ
- 最小権限の原則を守り、必要な操作だけを許可します。
- グループを使うとユーザー追加・削除が簡単になり、ミスが減ります。
- ポリシーをテストするツール(ポリシーシミュレーター)で動作確認してください。
- 機密操作には多要素認証(MFA)を併用すると安全性が高まります。
以上が基本的な権限付与の流れと注意点です。運用規模に合わせてグループ設計とポリシー分割を検討してください。
スイッチロール機能の活用
概要
スイッチロールは、1つの認証情報で別のアカウントや役割に切り替えて作業できる機能です。複数のAWSアカウントを運用する現場では、各アカウントに個別ログインする手間を省けます。
主な利点
- ログイン情報を増やさずにアクセスでき、管理が楽になります。
- ロール単位で細かく権限を分けられ、安全性が高まります。
活用例(具体例)
- 開発者が自分のアカウントでログインし、本番アカウントのロールに切り替えて一時作業する。
- 監査担当が監査用ロールに切り替え、操作履歴を残しながら確認する。
使い方の流れ(概略)
- マスターアカウントで通常ログインします。
- コンソールの「スイッチロール」を選び、対象アカウントIDとロール名を入力します。
- 表示名や色を設定すると見分けやすくなります。
運用のコツと注意点
- ロール名・表示名は慣例に沿って分かりやすく付けてください。
- 最小権限の原則を守り、必要な権限だけ与えます。
- セッション時間を短めに設定して、不正利用のリスクを減らします。
- MFAやログ監査を併用し、誰がいつ切り替えたか記録を残します。
- 長期的に頻繁に使う組み合わせはブックマークや専用URLで効率化すると便利です。
運用を工夫すれば、スイッチロールは複数アカウント管理を簡単にします。
スイッチロール設定の具体的手順
前提
- ターゲット(ロールを置く)アカウントIDと、ソース(切り替える)アカウントの情報を用意します。\
- ターゲット側でロール作成権限を持つユーザーが必要です。\
ターゲットアカウント側(ロール作成)
- AWSコンソールで「IAM」→「ロール」→「ロールの作成」を選びます。\
- 信頼されたエンティティで「別のAWSアカウント」を選び、ソースのアカウントIDを入力します(例: 222233334444)。\
- 必要なら「外部ID」を設定します(第三者連携で推奨)。\
- 権限ポリシーを割り当てます。頻繁な例: AmazonS3ReadOnlyAccess やカスタムポリシー。\
- ロール名を入力して作成します(例: CrossAccountReadRole)。作成後、ロールのARN(例: arn:aws:iam::111122223333:role/CrossAccountReadRole)を控えます。\
信頼関係の簡単な例(JSON):
{
“Version”:”2012-10-17″,
“Statement”:[{ “Effect”:”Allow”,”Principal”:{“AWS”:”arn:aws:iam::222233334444:root”},”Action”:”sts:AssumeRole” }]
}
ソースアカウント側(コンソールで切り替え)
- コンソール右上のアカウント名をクリックし「ロールの切り替え」を選びます。\
- 「別のアカウントに切り替え」欄にターゲットのアカウントID(例: 111122223333)とロール名(CrossAccountReadRole)を入力します。もしくはロールARNを直接入力できます。\
- 「切り替え」を押すと、ターゲットロールでのセッションが開始します。上部に切り替え先のアカウント名が表示されるので確認します。\
検証と留意点
- アクセスできるリソース(例: S3バケット一覧)で権限を確認します。\
- ロールが想定通り動かない場合は、ターゲット側の信頼ポリシーにソースのアカウントIDが正しく記載されているか確認します。\
- セッション期間やMFA要件はロール作成時に設定できます。必要に応じて短めのセッションにしてください。
実装時の重要なポイント
信頼ポリシー(Principal と MFA 条件)
スイッチ元アカウントの特定ユーザーやロールを Principal に指定します。MFA を必須にする条件(例:aws:MultiFactorAuthPresent が true)を加えると、不正な利用を防げます。
権限は必要最小限に
ロールには実行に必要な最小の操作(アクション)と対象(リソース)だけを与えます。ワイルドカード(*)を安易に使わず、具体的な API やリソースを指定してください。
セッション制限と有効期限
MaxSessionDuration を短めに設定して、長時間のセッションを避けます。重要操作にはより短い許可時間を設定し、再認証を促します。
ロギングと監査
ロールの引き受け(AssumeRole)や権限変更をログに残し、定期的に監査します。異常なアクセスは早期に検知して対応してください。
運用上の注意点
ロール設定後は実環境でテストを行い、不要になった権限は速やかに削除します。定期的に設定と利用状況を見直し、最小権限の原則を維持してください。












