AWS 管理ポリシー CloudWatchFullAccess が非推奨となるため CloudWatchFullAccessV2 への置き換えが推奨されています

AWS 管理ポリシー CloudWatchFullAccess が近いうちに非推奨となります。代替となる AWS 管理ポリシー CloudWatchFullAccessV2 への置き換えを行いましょう。

コンバンハ、千葉(幸)です。

AWS 管理ポリシーCloudWatchFullAccessの廃止(非推奨化)が予定されていること、およびその代替としてCloudWatchFullAccessV2の使用を推奨することが AWS ドキュメントに示されています。

CloudWatchFullAccessV2

AWS recently added the CloudWatchFullAccessV2 manged IAM policy. This policy grants full access to CloudWatch actions and resources and also more properly scopes the permissions granted for other services such as Amazon SNS and Amazon EC2 Auto Scaling. We recommend that you begin using this policy instead of using CloudWatchFullAccess. AWS plans to deprecate CloudWatchFullAccess in the near future.(中略)

CloudWatchFullAccess

The CloudWatchFullAccess policy is on the path to deprecation. We recommend that you stop using it, and use CloudWatchFullAccessV2 instead.

CloudWatchFullAccessの廃止が近づいてきたことで、以下の手段で通知を受け取った方もいるでしょう。

  • [Action Required] Changes to AWS Managed Policy [AWS Account: 000000000000]という件名のメール
  • Cloudwatch security notificationというタイトルの AWS Health イベント

これらの通知の内容を整理します。

何が起こるのか

2023年12月8日以降、近い将来、AWS 管理ポリシーCloudWatchFullAccessが非推奨となります。

2023/10/26追記
通知にあった「After December 7, 2023, "CloudWatchFullAccess" will no longer be supported.」の文言を「非推奨になる」意で誤って捉えていました。実際には、非推奨になる時期は現時点で明確にはなっていません。

非推奨となることでどんな影響があるのか

全体を整理すると以下のイメージとなります。

Deprecated Policy

非推奨のポリシーで継続してできること

  • アタッチ済みのエンティティ(IAMユーザー/グループ/ロール)がある場合、それらのエンティティへのポリシーの効力の発揮
  • アタッチ済みのエンティティがある AWS アカウントからのポリシーの参照
  • アタッチ済みのエンティティからのデタッチ(デタッチした後の再アタッチは不可)

非推奨のポリシーでできなくなること

  • 新規のエンティティへのアタッチ
  • アタッチ済みのエンティティがない AWS アカウントからのポリシーの参照

非推奨となっても、アタッチ済みのエンティティにおいては引き続き有効なポリシーとして機能することを押さえておいてください。

とは言え、非推奨となった後も継続して使い続けることはリスクを伴い、代替ポリシーに置き換えること以外にリスクを軽減する術はない、とされています。

AWS 管理ポリシーが非推奨となるきっかけとしては、広く持たせすぎていた権限を絞る、というものがほとんどです。「使い続けることによるリスク」とは、広すぎる権限を有していることを表します。

何をすべきなのか

今回通知を受け取った AWS アカウントには、CloudWatchFullAccessがアタッチされたエンティティが 1 つ以上あります。

当該エンティティからCloudWatchFullAccessをデタッチし、代わりにCloudWatchFullAccessV2をアタッチしてください。(実際の作業の順番としてはV2をアタッチしてからV1をデタッチ、で問題ありません。)

CloudWatchFullAccess がアタッチされたエンティティの確認の仕方

方法をふたつご紹介します。

  • AWS Health Dashboard から確認する
  • IAM コンソールから確認する

AWS Health Dashboard から確認する

AWS Health Dashboard でCloudwatch security notificationというタイトルの通知を確認します。

「影響を受けるリソース」タブを確認することで、CloudWatchFullAccessがアタッチされたエンティティを確認できます。

AWS_Health_Dashboard___Global

IAM コンソールから確認する

AWS マネジメントコンソールの IAM の画面で、ポリシー一覧を確認することでアタッチされたエンティティの有無を確認できます。

IAM_Policy_global

さらにポリシーの詳細画面から「アタッチされたエンティティ」タブを確認することで、一覧を確認できます。

CloudWatchFullAccess___IAM___Global

(下記のリンクからコンソールの該当画面に遷移できます。)

CloudWatchFullAccess と CloudWatchFullAccessV2で何が変わったのか

両者の差分を確認します。

CloudWatchFullAccessのポリシーの中身を v1.json、CloudWatchFullAccessV2の中身を v2.json に格納した上で diff をとった結果が以下です。

% diff v1.json v2.json
4a5
>             "Sid": "CloudWatchFullAccessPermissions",
7c8,10
<                 "autoscaling:Describe*",
---
>                 "application-autoscaling:DescribeScalingPolicies",
>                 "autoscaling:DescribeAutoScalingGroups",
>                 "autoscaling:DescribePolicies",
10c13,17
<                 "sns:*",
---
>                 "sns:CreateTopic",
>                 "sns:ListSubscriptions",
>                 "sns:ListSubscriptionsByTopic",
>                 "sns:ListTopics",
>                 "sns:Subscribe",
18a26
>             "Sid": "EventsServicePermissions",
28a37
>             "Sid": "OAMReadPermissions",

比較画像は以下のとおりです。右が V2 です。

CloudWatchFullAccess_diff

Sidはステートメントを表すタイトルのようなものであり効力に影響を及ぼさないので、実質的に差分は以下となります。

  • application-autoscaling:DescribeScalingPoliciesが増えた
  • autoscaling:Describe*が以下に限定された
    • autoscaling:DescribeAutoScalingGroups
    • autoscaling:DescribePolicies
  • sns:*が以下に限定された
    • sns:CreateTopic
    • sns:ListSubscriptions
    • sns:ListSubscriptionsByTopic
    • sns:ListTopics
    • sns:Subscribe

V2 になることで制限を受けるのはautoscalingsnsのアクションなので、それらを使用している場合には置き換えの際の影響を考慮するよいでしょう。

どんなアクションがあるかは、以下を参照してください。

CloudWatchFullAccess がアタッチされたエンティティがどんなアクションを呼び出していたか確認したい

ポリシー置き換えの影響を確認するために、CloudWatchFullAccessがアタッチされたエンティティがどんなアクションを呼び出していたかを確認したいケースを考えます。

詳細は CloudTrail に頼るほかないのですが、大枠として押さえるのであれば「アクセスアドバイザー」が便利です。

以下のように確認できます。

CloudWatchFullAccess___IAM___Global_Access_Advisor

(下記のリンクからコンソールの該当画面に遷移できます。)

ここではまずサービス単位で、どのエンティティからいつアクセスがあったかを確認できます。ここでの「アクセス」とは、当該サービスのいずれかのアクションを呼び出したことを表します。

サービスがリンクになっているものについては、アクションレベルで確認できます。例えば Amazon CloudWatch の詳細を確認するとこのようにアクションレベルで表示されます。

CloudWatchFullAccess___IAM___Global_Advisor2

↑一点注意点として、ここで確認できるアクションは全量ではありません。参考程度に止めるとよいでしょう。 *1

ここでの追跡期間(アクセスの有無を遡って確認する期間)は最大400日です。 *2 *3

V2 になることで制限を受けるautoscalingsnsについてはアクションレベルの確認ができないため、おおまかにサービス単位でアクセスしたエンティティを確認したのち、CloudTrail などで詳細を確認していく、とすると良いでしょう。

まとめ

  • CloudWatchFullAccessが非推奨となる
  • 非推奨となった AWS 管理ポリシーで継続してできること
    • アタッチ済みのエンティティ(IAMユーザー/グループ/ロール)がある場合、それらのエンティティへのポリシーの効力の発揮
    • アタッチ済みのエンティティがある AWS アカウントからのポリシーの参照
    • アタッチ済みのエンティティからのデタッチ(デタッチした後の再アタッチは不可)
  • 非推奨となった AWS 管理ポリシーでできなくなること
    • 新規のエンティティへのアタッチ
    • アタッチ済みのエンティティがない AWS アカウントからのポリシーの参照
  • CloudWatchFullAccessからCloudWatchFullAccessV2に置き換えることで影響を受けるのはautoscalingsnsのアクション

よくありそうなQ&A

ここまでの話で取り上げた内容と被りますが、疑問に思う方が多そうなトピックをまとめました。

Q. 非推奨となったポリシーは使えなくなりますか?

アタッチ済みのエンティティに対しては変わらず効力を発揮します。そういった観点では引き続き使えます。

新規にエンティティにアタッチすることはできません。そういった観点では使えなくなります。

Q. アタッチ済みのポリシーは自動的にV2に置き換わりますか?

いいえ、自身で「V1のデタッチ」「V2のアタッチ」の操作を行う必要があります。

Q. 非推奨となった後もポリシーを使い続けていいですか?

即時に影響が出るわけではありませんが、以下観点からV2に置き換えることを推奨します。

  • 権限が広めに取られているリスクがあること
  • 今後のポリシーの更新が期待できないこと
  • アタッチ済みでないエンティティには使用できないこと

Q. アタッチ済みのエンティティがある場合、非推奨となったポリシーはどのように見えますか?

AWS マネジメントコンソールでは変わらず一覧に出てきますが、警告のマークがつきます。

ポリシーの詳細画面では、例えば以下のように見えます。(ちょうどいい画像が見繕えなかったので古いコンソールデザインのものを引用します。)

deprecated_policy

AWS CLI の以下コマンドなどでは、当該ポリシーのIsAttachableというパラメータがfalseになります。

Q. アタッチ済みのエンティティがない場合、非推奨となったポリシーはどのように見えますか?

AWS マネジメントコンソールでも、AWS CLI などのプログラムアクセスであっても参照することはできません。

終わりに

AWS 管理ポリシーCloudWatchFullAccessが非推奨となり、CloudWatchFullAccessV2への置き換えが推奨されていることをまとめました。

対応の参考になれば幸いです。

以上、 チバユキ (@batchicchi) がお送りしました。

脚注

  1. サービスごとの追跡可能なアクションは以下にまとまっています。 IAM アクションの最終アクセス情報サービスとアクション - AWS Identity and Access Management
  2. リージョンや、アクションレベルの追跡によってはもっと短くなる場合があります。東京リージョンのSNS、AutoScalingであれば400日まで遡れます。最終アクセス情報を使用した AWS のアクセス許可の調整 - AWS Identity and Access Management
  3. コンソール上の表示では400日より古い日付が表示されることもあるため、過去400日分より古い記録が切り捨てられる、という仕様ではないようです。