はじめに
前回の記事では、AWS Systems Manager の Session Manager を利用することで、
踏み台サーバーを必要とせずに EC2 インスタンスへアクセスできる仕組みをご紹介しました。
しかし、Session Manager を導入すればそれで終わりというわけではありません。
実際の運用においては、単に接続できるだけでは不十分です。セッションアクセスについては、
以下の点を確実に満たす必要があります。
- 明示的に制御されていること （誰が、どのインスタンスへ接続できるのか）
- 一貫性があること （セッションの挙動が標準化されていること）
- 追跡可能であること （セッション内のすべての操作が監査可能であること）
本記事では次のステップとして、AWS のベストプラクティスを適用しながら、
日常運用に向けて Session Manager を強化し、制御可能で標準化され、かつ監査可能なセッションアクセスを実現することに焦点を当てます。
目次
構成図
本記事では、前回の記事でご紹介したベース環境がすでに構築されていることを前提としています。
以下の構成図は、その環境に対して追加で適用する構成を示したもので、主に次の点に焦点を当てています。
- アクセス制御
- セッション動作の標準化
- 監査ログの取得
【前提条件】
本記事では、前回の記事までに構築した環境が すでに整っていることを前提としています。
ワークフロー
- アクセス制御設計
- Part A：Session Manager セッションを開始できるユーザーの定義
- Part B：アクセス可能な EC2 インスタンスの制限
- セッション動作の標準化
- 監査向け可視化の設定
- 動作確認
アクセス制御設計
Part A: Session Manager セッションを開始できるユーザーの定義
手順 1：ロールにアタッチするSession Manager アクセスポリシーの作成
コンソール画面から IAM を選択します。
ポリシー → 【ポリシーの作成】 に移動します。
JSON タブを選択します。
以下に示す Session Manager 用のアクセスポリシーを貼り付けます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "StartSessionToAnyInstance",
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": "arn:aws:ec2:<REGION>:<ACCOUNT_ID>:instance/*"
},
{
"Sid": "StartSessionWithRunShellDocument",
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": "arn:aws:ssm:<REGION>:<ACCOUNT_ID>:document/SSM-SessionManagerRunShell"
},
{
"Sid": "OpenDataChannelForOwnSessions",
"Effect": "Allow",
"Action": "ssmmessages:OpenDataChannel",
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
},
{
"Sid": "ResumeAndTerminateOwnSessions",
"Effect": "Allow",
"Action": [
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
},
{
"Sid": "ReadOnlyVisibilityForConsoleStatus",
"Effect": "Allow",
"Action": [
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation",
"ssm:DescribeSessions"
],
"Resource": "*"
}
]
}
※ 以下のプレースホルダーは、実際の環境に合わせて置き換えてください。
REGION：EC2 インスタンスが存在する AWS リージョン
（例：ap-northeast-1）ACCOUNT_ID：対象となる EC2 インスタンスを所有する AWS アカウント ID
ポリシーの設定内容を確認し、［ポリシーの作成］を選択します。
手順 2：ユーザー用の Session Manager アクセスロールの作成
コンソール画面から IAM を選択します。
ロールの作成に進みます。
信頼されたエンティティタイプ：AWS アカウント
アカウント：このアカウント
次に、手順 1 で作成したポリシーを選択します。
次に、信頼ポリシーを編集します。
ロール作成時（または作成直後）に、信頼ポリシーを以下のように更新します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:user/<USERNAME>"
},
"Action": "sts:AssumeRole"
}
]
}
※ 以下の値は環境に応じて置き換えてください。
- ACCOUNT_ID：前の画面で選択した現在の AWS アカウント ID
- USERNAME：Session Manager の利用を許可する IAM ユーザー
そのほかのデフォルト設定は変更せず、［ロールを作成］を選択して作成します。
※ 注意点
- 本記事では、ユーザーに対するロール引き受け（AssumeRole）権限の設定については扱いません。
Part B: アクセス可能な EC2 インスタンスの制限
本パートでは、Session Manager でアクセス可能な EC2 インスタンス を制御することで、アクセス範囲をさらに限定します。
手順 1：アクセスを許可する EC2 インスタンスにタグを付与
コンソール画面から EC2 を選択します。
インスタンス に移動します。
Session Manager でのアクセスを許可する EC2 インスタンスを選択します。
タグ タブを開きます。
タグを管理 を選択し、以下のタグを追加します。
- Key：SSMAccess
- Value：enabled
※ 注意点
- タグの [Key] および [Value] の名称は自由に設定できますが、
IAM ポリシーの条件でも同じ値を使用するようにしてください。
手順 2：タグベースのアクセス制御を適用するため IAM ポリシーを更新
IAM コンソールから、Part A(手順 1) で作成した Session Manager アクセスポリシー を選択します。
ポリシーを編集 → JSON を選択します。
ssm:StartSession のステートメントに、EC2 タグを条件とした制御を追加します。
{
"Sid": "StartSessionOnlyToTaggedInstances",
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": "arn:aws:ec2:<REGION>:<ACCOUNT_ID>:instance/*",
"Condition": {
"StringEquals": {
"ssm:resourceTag/SSMAccess": "enabled"
}
}
}
※ 以下のプレースホルダーは、実際の環境に合わせて置き換えてください。
REGION：EC2 インスタンスが存在する AWS リージョン
（例：ap-northeast-1）ACCOUNT_ID：対象となる EC2 インスタンスを所有する AWS アカウント ID
変更内容を保存します。
セッション動作の標準化
ユーザーや EC2 インスタンス間で一貫性があり、予測可能なセッション動作を実現するために、 Session Manager の 設定 をアカウントレベルで構成します。
これらの設定は、構成を更新した 以降に開始されるすべてのセッション に適用されます。
コンソール画面から Systems Manager を選択します。
[セッションマネージャー] を選択し、[設定] タブを開きます。
[編集] を選択します。
アイドルタイムアウトの時間（例：20 分）を指定します。
設定を [保存] します。
監査向け可視化の設定
手順 1：S3 ゲートウェイ VPC エンドポイントの作成
プライベートサブネット内の EC2 インスタンスから
Session Manager のログを Amazon S3 に書き込めるようにするため、
S3 ゲートウェイ VPC エンドポイントを作成します。
コンソール画面のVPCから、
エンドポイントの作成を選択します。
今回は S3 用のエンドポイント を作成します。 使用するサービスは以下のとおりです。
- ［com.amazonaws.ap-northeast-1.s3］
エンドポイントの設定をします。
- 名前：任意
- タイプ：AWS サービス
次に、
- サービス名：com.amazonaws.ap-northeast-1.s3
- タイプ：Gateway
ネットワークの設定を行います。
- ［VPC］：対象のVPCを選択
- ［ルートテーブル］：対象のルートテーブルを選択
今回は、［フルアクセス］でエンドポイントを作成します。
設定内容を確認し、［エンドポイントを作成］を実行して完了します。
※ 注意点
次の手順に進む前に、Amazon S3 バケットがすでに作成されていることを確認してください。
インスタンスロールに、以下の権限が付与されていることを確認してください。
s3:GetEncryptionConfiguration：S3 バケットの暗号化設定を確認するため
s3:PutObject：セッションログファイルをアップロードするため
手順 2：Session Manager のセッションログを Amazon S3 に出力する設定
セッションログは、セッション終了後に生成され、
EC2 インスタンスプロファイルロールを使用して Amazon S3 に書き込まれます。
コンソール画面から Systems Manager を選択します。
[セッションマネージャー] を選択し、[設定] タブを開きます。
[編集] を選択します。
[S3 ログ記録]で、以下を設定します。
[有効にする］にチェックします。
リストからバケット名を選択します。
設定を [保存] します。
動作確認
1. Session Manager アクセスロールを引き受ける
Session Manager セッションの開始を試行します。
必要なタグが付与された EC2 インスタンスの場合
- セッションは正常に開始されます
タグが付与されていない EC2 インスタンスの場合
- セッションの開始は拒否されます
これにより、EC2 タグに基づいてアクセス制御が正しく適用されていることを確認できます。
2. セッションのアイドルタイムアウト動作の確認
Session Manager セッションを開始します。
アイドルタイムアウトに達すると、
非アクティブ状態によりセッションが終了したことを示すエラーメッセージが
Session Manager に表示され、セッションが自動的に終了します。
3. S3 にセッションログが出力されていることの確認
Session Manager セッションを、
アクセスが許可された EC2 インスタンスに対して開始します。
以下のような簡単なコマンドをいくつか実行します。
whoami uname -n date
セッションを終了します。
設定した S3 バケット を開き、
セッションログのオブジェクトが作成されていることを確認します。
よくある落とし穴
以下のポイントを確認することで、セットアップ時によくある誤設定を防ぐことができます。
1. セッションを開始できない場合
Session Manager へのアクセスは IAM ロール を通じて付与されます。
ユーザーには、このロールを引き受けるための権限が必要です。
ロール引き受けが設定されていない場合、
ロールやポリシーが存在していても、セッションを開始することはできません。
2. セッションログが Amazon S3 に出力されない場合
Amazon S3 にセッションログが出力されない場合は、
［監査向け可視化の設定］の手順 1 の注意点 で触れているとおり、
EC2 インスタンスプロファイルロールに必要な権限が付与されていることを確認してください。
また、S3 Gateway VPC エンドポイント が、
対象の EC2 インスタンスが配置されているサブネットで使用されている
ルートテーブル に正しく関連付けられていることも確認してください。
まとめ
本記事では、最小権限の考え方に基づき、
AWS Systems Manager Session Manager を強化することで、
踏み台レスアクセスの構成をさらに堅牢化しました。
アクセス可能なユーザーや EC2 インスタンスを明示的に制御し、
セッション動作を標準化し、監査ログを有効化することで、
環境を問わず、Session Manager を安全かつ一貫して運用できるようになります。
すでに踏み台レスアクセスのために Session Manager を利用している場合も、
本記事を機に、アクセス制御や運用面のセキュリティを見直し、強化する良い機会となります。
おまけ
これらの構成は、踏み台レス環境や踏み台サーバーを利用した構成に限定されるものではありません。
ネットワークの公開状態（パブリック／プライベート）に依存せず、
Session Manager に対して適用することができ、
アクセス制御、セッションの一貫性、監査可視性の向上に役立ちます。
