AWS踏み台サーバーに適用するIAMロール設計|最小権限で制御するアクセス管理構成パターン

運営:リナックスマスター.JP(代表 宮崎智広)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > AWS(Amazon Linux) > AWS踏み台サーバーに適用するIAMロール設計|最小権限で制御するアクセス管理構成パターン
「AWSに踏み台サーバーを置いたけど、IAMロールは何を設定すればいいのかわからない」
「とりあえずAdministratorAccessをアタッチしてしまったが、権限が広すぎるのでは?」

踏み台サーバー(Bastion Host)は、プライベートサブネット内のEC2インスタンスへ安全にアクセスするための中継サーバーです。セキュリティの要であるはずの踏み台が、IAM設定の甘さが原因で攻撃の足がかりになるケースは少なくありません。

この記事では、AWS踏み台サーバーに適用するIAMロールを最小権限の原則で設計する方法を解説します。踏み台専用ロールの作成から、Session Manager連携・MFA必須条件・CloudTrailによる操作監査まで、実際のポリシーJSONを使って説明します。

この記事のポイント

・踏み台EC2にはIAMユーザーのアクセスキーではなくIAMロールを割り当てるのが鉄則
・ロールのアクセス許可はSSM Session Manager最低限+必要なポリシーのみに絞る
・MFA必須条件(aws:MultiFactorAuthPresent)でなりすましリスクを下げる
・CloudTrailで踏み台操作ログを残し、いつ誰が何をしたかを追跡可能にする


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

踏み台サーバーにIAMロールが必要な理由

IAMユーザーのアクセスキー(ACCESS_KEY_ID / SECRET_ACCESS_KEY)をEC2インスタンス上に直接配置する運用が、古い教材や古い現場に残っています。この方法には深刻なリスクがあります。

・アクセスキーは平文で ~/.aws/credentials に保存されるため、サーバー侵害時にそのまま漏洩する
・アクセスキーのローテーションを怠ると、退職者のキーが何年も残り続ける
・どのEC2がどのキーを使っているかの管理が複数台になると煩雑になる

IAMロールはEC2インスタンスに直接アタッチする仕組みです。一時認証情報(STSトークン)が自動発行・自動更新されるため、アクセスキーの漏洩リスクと管理コストを同時に排除できます。

踏み台サーバーは「外から内部ネットワークへの玄関口」であり、ここに広すぎる権限を持つIAMが紐付くと、侵害された瞬間にAWS環境全体が危険にさらされます。だからこそ、最小権限の設計が最も重要なサーバーのひとつです。

踏み台EC2に割り当てるIAMロールの設計手順

1. 踏み台専用IAMロールを作成する

まず、EC2インスタンスがロールを引き受けられるよう、信頼ポリシー(Trust Policy)でプリンシパルを ec2.amazonaws.com に設定します。

# 踏み台サーバー用IAMロールを作成する aws iam create-role \ --role-name BastionRole \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }'

ロールを作成したら aws iam get-role で確認します。以下は実際のAWS環境での出力例です(アカウントIDはマスク済み)。

$ aws iam get-role --role-name BastionRole { "Role": { "Path": "/", "RoleName": "BastionRole", "RoleId": "AROAXXXXXXXXXXXXXXXXX", "Arn": "arn:aws:iam::123456789012:role/BastionRole", "CreateDate": "2026-10-10T05:00:00+00:00", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "MaxSessionDuration": 3600 } }

AssumeRolePolicyDocument の Principal.Service が ec2.amazonaws.com になっていることを確認してください。

2. 最小権限のポリシーをアタッチする

踏み台サーバーが担う役割を整理すると、必要な権限の範囲が見えてきます。踏み台EC2に必要なAWS操作は主に以下の2系統です。

・自分自身の管理:Session Managerを使ったログ送信、パッチ適用のためのSSMエージェント動作
・接続先の管理:SSHの中継または対象インスタンスへのSession Manager経由での接続開始

まずSSMエージェントの動作に必要なAWSマネージドポリシー AmazonSSMManagedInstanceCore をアタッチします。

# SSMエージェント動作に必要なマネージドポリシーをアタッチ aws iam attach-role-policy \ --role-name BastionRole \ --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

踏み台から接続先EC2へSession Manager経由でセッションを開始する場合は、接続先インスタンスIDを条件に絞ったカスタムポリシーを追加します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:StartSession" ], "Resource": [ "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abcdef1234567890", "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0fedcba9876543210" ] }, { "Effect": "Allow", "Action": [ "ssm:TerminateSession", "ssm:ResumeSession" ], "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*" } ] }

ssm:StartSession のリソースを特定インスタンスIDに絞ることで、踏み台から接続できる対象サーバーを限定します。ワイルドカード * を使うと全インスタンスへの接続が可能になってしまうため、本番環境では避けてください。

3. EC2インスタンスプロファイルにロールを関連付ける

IAMロールをEC2インスタンスに割り当てるには、インスタンスプロファイルを経由します。コンソールから起動する場合は「IAMインスタンスプロファイル」欄で選択するだけですが、AWS CLIで操作する場合は以下の手順になります。

# インスタンスプロファイルを作成してロールを追加 aws iam create-instance-profile \ --instance-profile-name BastionInstanceProfile aws iam add-role-to-instance-profile \ --instance-profile-name BastionInstanceProfile \ --role-name BastionRole # 実行中の踏み台EC2にアタッチ(インスタンスID例: i-0bastion12345) aws ec2 associate-iam-instance-profile \ --instance-id i-0bastion12345 \ --iam-instance-profile Name=BastionInstanceProfile

アタッチ後は踏み台EC2上から aws sts get-caller-identity を実行し、IAMロールが正しく引き受けられていることを確認してください。AWSサーバー構築をVPCの基礎から体系的に学びたい方は、Amazon Linux 2023によるAWSサーバー構築セミナーで踏み台・IAM・セキュリティグループの全体設計を整理できます。

アクセス制御を強化する3つの構成パターン

踏み台サーバーのIAMロールにより強固なアクセス制御を加える場合、以下の3パターンを状況に応じて組み合わせるのが実務の定番です。

パターン1:MFA必須条件でロール引き受けを強化する

踏み台へのアクセスに使うIAMユーザー(オペレーターのアカウント)がロールを sts:AssumeRole で引き受ける際に、MFA認証済みのセッションだけを許可する条件を信頼ポリシーに追加します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole", "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" }, "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" } } } ] }

aws:MultiFactorAuthPresent: true はMFAデバイスで認証済みであること、aws:MultiFactorAuthAge: 3600 はMFA認証から3,600秒(1時間)以内のセッションだけを許可することを意味します。

セッションが切れると再度MFA認証が必要になるため、パスワードだけで侵害されたアカウントからの不正ロールの引き受けを防止できます。

パターン2:IPアドレス条件で踏み台からのみAPI操作を許可する

踏み台EC2にElastic IPを固定し、そのIPからのAPI呼び出しのみを許可する条件をカスタムポリシーに追加します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:StartSession", "ssm:DescribeSessions" ], "Resource": "*", "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.10/32" } } } ] }

aws:SourceIp には踏み台EC2のElastic IPを設定します。セキュリティグループによるネットワーク制御とセットで運用することが重要です。踏み台EC2へのSSH接続は22番ポートに限定し、接続元をオペレーターPCのIPアドレスのみに絞るのが鉄則です。Linux ポート確認の全コマンドを使えば、踏み台での接続状況をリアルタイムで確認できます。

パターン3:CloudTrailで踏み台操作ログを監査する

IAMロールを設定しても、「誰がいつ踏み台からどの操作をしたか」を記録しなければ、インシデント発生後の調査ができません。CloudTrailを有効化し、踏み台EC2上のAWS CLI操作を全てS3に保存します。

# CloudTrailの証跡設定を確認する $ aws cloudtrail describe-trails --include-shadow-trails false { "trailList": [ { "Name": "management-events-trail", "S3BucketName": "cloudtrail-logs-123456789012", "IncludeGlobalServiceEvents": true, "IsMultiRegionTrail": true, "HomeRegion": "ap-northeast-1", "TrailARN": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/management-events-trail", "LogFileValidationEnabled": true, "HasCustomEventSelectors": false, "IsOrganizationTrail": false } ] }

踏み台EC2上で aws ssm start-session や aws ec2 describe-instances を実行すると、その操作がCloudTrailに記録されます。 userAgent フィールドでAWS CLI経由の操作と管理コンソールからの操作を区別できるため、インシデント調査時に「手動操作か自動化スクリプトか」を特定しやすくなります。

トラブルシュート|よくあるIAMエラーと対処法

「An error occurred (AccessDenied)」が出た時の対処法

踏み台EC2上でAWS CLIを実行したときに AccessDenied が出る場合は、以下の順番で確認します。

# 踏み台EC2に割り当てられたロールとアカウント情報を確認 $ aws sts get-caller-identity { "UserId": "AROAXXXXXXXXXXXXXXXXX:i-0bastion12345", "Account": "123456789012", "Arn": "arn:aws:sts::123456789012:assumed-role/BastionRole/i-0bastion12345" }

Arn に assumed-role/BastionRole が含まれていれば、IAMロールは正しくアタッチされています。それでも AccessDenied が出る場合は、ポリシーのリソースARNが正しいか(インスタンスIDやリージョンのtypo)を確認します。

・原因1:インスタンスプロファイルが未アタッチ:aws sts get-caller-identity で UserId が AKID...(アクセスキーID)で始まる場合は、インスタンスプロファイルが正しく設定されていません
・原因2:リソースARNのリージョン不一致:ポリシーのARNに us-east-1 を書いたまま、東京リージョン(ap-northeast-1)で使おうとすると AccessDenied になります
・原因3:SCP(Service Control Policy)による制限:AWS Organizationsを使っている場合、親アカウントのSCPがアクション全体を拒否している可能性があります。SCPと個別ポリシーの両方をチェックしてください

Session Managerで「TargetNotConnected」が出た時の対処法

踏み台からSSMセッションを開始しようとして TargetNotConnected が出る場合、接続先EC2のSSMエージェントが停止しているか、エージェントがSSMエンドポイントと通信できていない状態です。

・確認1:接続先EC2にも AmazonSSMManagedInstanceCore ポリシーがアタッチされたIAMロールが割り当てられているか確認する
・確認2:接続先EC2がプライベートサブネットにある場合、SSMのVPCエンドポイント(ssm・ssmmessages・ec2messages)が設定されているか確認する
・確認3:接続先EC2上で sudo systemctl status amazon-ssm-agent を実行し、エージェントが active (running) 状態かを確認する

本記事のまとめ

設計ポイント 内容
IAMユーザーのキー配置禁止 踏み台EC2にはIAMロール(インスタンスプロファイル)を使う。~/.aws/credentialsへのキー配置は厳禁
最小権限のロール設計 AmazonSSMManagedInstanceCore+接続先インスタンスIDを絞ったssm:StartSessionポリシーのみをアタッチ
MFA必須条件 信頼ポリシーにaws:MultiFactorAuthPresent条件を追加し、MFA認証済みセッションだけを許可
IP条件による制限 踏み台のElastic IPをaws:SourceIp条件に設定し、踏み台からのAPI呼び出しだけを許可
CloudTrail監査ログ 全リージョンの管理イベントをS3に保存し、誰がいつ何の操作をしたか追跡できる状態にする
踏み台サーバーのIAMロールは「最小権限・MFA・監査ログ」の3点を押さえることで、AWS環境のアクセス管理を安全に運用できます。IAMロールの設計は一度整えると長期間有効な設計資産になります。定期的に不要なポリシーが追加されていないかをAWS IAM Access Analyzerで確認する習慣もつけておきましょう。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、Amazon Linux 2023を使ったAWSサーバー構築セミナーの詳細はこちら>>
VPC設計・IAMロール・セキュリティグループの設計パターンを、ハンズオン形式で体系的に学べます。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。