はじめに

皆様こんにちは、あかいけです。

EC2にアタッチされたIAMロールで、AmazonEC2RoleforSSMというマネージドポリシーに出会ったことはありますか?
私はあります。

このポリシーは非推奨化がアナウンスされており、AmazonSSMManagedInstanceCoreへの置き換えが推奨されているのですが、いざ切り替えるとなると「権限を絞る方向の変更だから、今動いているものが壊れないか不安…」という気持ちになりました。

そんなわけで今回は、両ポリシーの権限差分を整理したうえで、AmazonEC2RoleforSSMからAmazonSSMManagedInstanceCoreへ切り替えても問題ないかを確認する方法をまとめてみました。

AmazonEC2RoleforSSMとAmazonSSMManagedInstanceCore

本題に入る前に、そもそもこの2つのポリシーがどういう関係なのかを整理しておきます。

ざっくり言うと、次のような位置づけです。

• AmazonEC2RoleforSSM(旧)
  • Systems Managerのコア機能に加え、Session Manager・ドメイン参加・CloudWatch・S3へのコマンド出力など、幅広い権限を含む
• AmazonSSMManagedInstanceCore(新)
  • Systems Managerのコア機能に必要な最小限の権限のみを含む

AmazonEC2RoleforSSMは2019年時点でAWSから非推奨化がアナウンスされており、最小権限であるAmazonSSMManagedInstanceCoreへの置き換えが推奨されています。

https://dev.classmethod.jp/articles/not-recommended-amazonec2roleforssm/
https://dev.classmethod.jp/articles/check-amazonec2roleforssm-policy/
https://aws.amazon.com/blogs/mt/applying-managed-instance-policy-best-practices/

もちろん非推奨なだけなので、既にアタッチ済みのロールの権限がすぐに剥奪されるわけではありませんが、新規サーバーの構築時やOS更新に伴うサーバーの再構築時など、リソースを作り直すタイミングでAmazonSSMManagedInstanceCoreへの置き換えを進めておくと良いでしょう。

両方のポリシーの権限差分

前述のとおりAmazonSSMManagedInstanceCoreはコア機能とSession Managerだけをカバーしており、それ以外の機能を使っている場合は追加のポリシーが必要になります。ここが切り替え時の一番のポイントです。

実際のポリシーJSONを突き合わせると、切り替えによって発生する差分は以下のとおりです。

AmazonSSMManagedInstanceCore で追加される権限

ssm:GetParameter

AmazonSSMManagedInstanceCore で削除される権限

cloudwatch:PutMetricData

ec2:DescribeInstanceStatus

ds:CreateComputer
ds:DescribeDirectories

logs:CreateLogGroup
logs:CreateLogStream
logs:DescribeLogGroups
logs:DescribeLogStreams
logs:PutLogEvents

s3:GetBucketLocation
s3:PutObject
s3:GetObject
s3:GetEncryptionConfiguration
s3:AbortMultipartUpload
s3:ListMultipartUploadParts
s3:ListBucket
s3:ListBucketMultipartUploads

追加されるssm:GetParameterは影響を気にする必要はありませんが、
問題になり得るのは削除される側で、それぞれ次のような用途に対応しています。

• ds:*
  • Seamless Domain Join(EC2のActive Directoryドメイン参加)
• cloudwatch:PutMetricData / logs:*
  • CloudWatchエージェントによるメトリクス・ログ送信、およびSession Manager・Run CommandのログをCloudWatch Logsへ出力する機能
• s3:*
  • Session Managerのセッションログや、Run Commandの実行結果をS3バケットへ出力する機能
• ec2:DescribeInstanceStatus
  • インスタンスステータスの参照

これらの権限に依存した使い方をしていなければ、AmazonSSMManagedInstanceCoreへ切り替えても影響はありません。
逆に、上記機能を使っている場合は、切り替えと同時に対応するポリシー(AmazonSSMDirectoryServiceAccess・CloudWatchAgentServerPolicy・S3用のカスタムポリシーなど)を追加でアタッチする必要があります。

なお両ポリシーの中身は以下です。

• AmazonEC2RoleforSSM
• AmazonSSMManagedInstanceCore

調査方法

差分がわかったところで、「切り替えても問題ないか」を確認していきます。

やることはシンプルで、削除される権限(ds:*・cloudwatch:PutMetricData・logs:*・s3:*・ec2:DescribeInstanceStatus)を、対象のロールが実際に使っていないかを確認します。

確認のアプローチは大きく2つあります。

• コードベース
  • コードベース(IaCや設定)から、削除される権限に依存した機能を使っていないか静的に確認する
• API実行履歴
  • CloudTrailから、そのロールが実際に該当APIを呼び出していないか確認する

どちらか一方だけでは見落としが発生し得るので、両方を組み合わせて確認するのがおすすめです。

コードベース

まずはコードベースや設定から、削除される権限に関わる機能を使っていないかを確認します。
具体的には次のような観点でチェックします。

• IaC(CloudFormation・Terraform等)やEC2起動テンプレートでAmazonEC2RoleforSSMを直接参照していないか
  • 参照している場合は、切り替え時に参照先の更新も必要になります
• Session Managerのセッションログ、またはRun Commandの実行結果をS3バケットやCloudWatch Logsへ出力する設定になっていないか
  • Session Managerの設定(Preferences)や、Run Command実行時のログ出力先設定を確認します
  • 出力している場合、s3:*やlogs:*が必要になります
• CloudWatchエージェントを導入していないか
  • 導入している場合、cloudwatch:PutMetricDataやlogs:*が必要になります
• EC2の Active Directoryドメイン参加(Seamless Domain Join) を利用していないか
  • 利用している場合、ds:*が必要になります

ここで「使っている」と判明した機能については、切り替えと同時に対応するポリシー(CloudWatchAgentServerPolicy・AmazonSSMDirectoryServiceAccess・S3用のカスタムポリシー)を追加すればOKです。

API実行履歴

コードベースからの確認と合わせて、実際のAPI実行履歴からも裏取りをしておくと安心です。

ここではCloudTrailを利用して、対象のインスタンスが、削除される権限に該当するAPIを過去に呼び出していないかを、イベント履歴から確認します。

CloudTrailのイベント履歴画面で、ユーザー名にロールセッション名を指定したり、イベント名にAPI名を指定したりして絞り込むと確認しやすいです。
CLIから確認する場合は以下のようなコマンドで、特定のAPIの呼び出し履歴を検索できます。

# 例: ds:CreateComputer(ドメイン参加)の呼び出し履歴を検索(直近90日・管理イベント)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateComputer \
  --start-time "$(date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --query 'Events[].{Time:EventTime,User:Username,Event:EventName}' \
  --output table

# 例: 特定のEC2(インスタンスID)からのAPI呼び出しを検索
#     EC2ロールのセッション名にはインスタンスIDが入るため、そこで絞り込む
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=i-0123456789abcdef0 \
  --start-time "$(date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --query 'Events[].{Time:EventTime,User:Username,Event:EventName}' \
  --output table

該当APIの呼び出しが見つからなければ、その権限は使われていない可能性が高い、と判断できます。

注意事項

CloudTrailでの確認にあたり、以下2点だけ注意です。

• S3のオブジェクト操作(s3:PutObjectなど)はデータイベントに分類され、デフォルトでは記録されません。S3への出力有無はコードベース側の確認を主として判断しましょう。
• aws cloudtrail lookup-events(イベント履歴)で遡れるのは直近90日分の管理イベントのみです。より長い期間を対象にしたい場合は証跡(Trail)やCloudTrail Lakeを検討してください。

詳細はCloudTrailの管理イベントとデータイベントを参照してください。

補足: IAM Access Advisorも活用する

確認の補助としてIAMのアクセス許可の最終アクセス情報(Access Advisor)も便利です。

これはIAMロールがどのサービスに最後にアクセスしたかを表示してくれる機能で、対象ロールでAWSサービスへのアクセス実績がなければ、それらの権限は使われていないと判断する材料になります。

CloudTrailと違ってサービス単位の粒度ではありますが、追加設定なしですぐに確認できるため、最初のあたりを付けるのに向いています。

対象ロールにアタッチされたポリシーの詳細画面から、最終アクセス日時タブを開くと、そのポリシーが許可するサービスごとに最後にアクセスした日時を一覧で確認できます。

上の画面はAmazonEC2RoleforSSMのものです。CloudWatch・Directory Service・S3・CloudWatch Logsなど、切り替えで削除される権限に対応するサービスがいずれも追跡期間中はアクセスされていませんとなっており、これらの機能が使われていないことの裏付けになります。

さらにサービス名をクリックすると、そのサービスにどのロール(エンティティ)がいつアクセスしたかまで掘り下げて確認できます。

こちらはAWS Systems Managerのメンバーによるアクセスを開いた画面です。
ロール単位で最終アクセス日数(この例では343日前・390日前・450日前)が表示されるため、どのロールが実際に利用しているかを個別に把握できます。

さいごに

以上、AmazonEC2RoleforSSMからAmazonSSMManagedInstanceCoreへ切り替えても問題ないか確認する方法でした。
今後ポリシーの移行を進める方の参考になれば幸いです。