[アップデート] IAM Access Analyzer のポリシーチェック項目が増えました (ABAC 関連が多めだよ)

コンバンハ、千葉（幸）です。

IAM Access Analyzer のポリシーチェックが拡張され、新たなチェック項目が追加されました。

• IAM Access Analyzer adds new policy checks to help validate conditions during IAM policy authoring

IAM ポリシーの編集時にリアルタイムでチェックしてくれる便利機能がさらにパワーアップしました。

何が変わったのか

IAM Access Analyzer のポリシーチェックとは

IAM Access Analyzer のポリシーチェックは、ValidatePolicy という API を使用して JSON ポリシードキュメントの内容を検証・チェックしてくれる機能です。

マネジメントコンソールでは、 IAM ポリシーの編集時に以下のようにチェック・サジェストをしてくれます。

機能を使用するために特別な設定変更は必要ありませんし、利用料もかかりません。

チェック項目は「セキュリティ」「エラー」「警告」「提案」のカテゴリに分かれ、100 個以上用意されています。

ポリシーチェックは 2021年3月に追加された機能です。詳細は以下を参照してください。

追加されたチェック項目

チェック項目の一覧は以下にあります。数えると 114 個ありました。

• Access Analyzer policy check reference - AWS Identity and Access Management

前回との差分から、アップデートにより追加された項目は以下の 7 個であることが分かりました。

分類	項目	概要
Error	Invalid service principal format	無効なサービスプリンシパルフォーマット
Error	Missing tag key in condition	条件内のタグキーが不足している
Security Warning	Deny NotAction with unsupported tag condition key for service	タグ条件キーをサポートしていないサービスで Deny と NotAction の組み合わせを使用している
Security Warning	Deny with unsupported tag condition key for service	タグ条件キーをサポートしていないサービスで Deny を使用している
Security Warning	Missing paired condition keys	組み合わせて使用する条件キーが不足している
Suggestion	Allow NotAction with unsupported tag condition key for service	タグ条件キーをサポートしていないサービスで Allow と NotAction の組み合わせを使用している
Suggestion	Allow with unsupported tag condition key for service	タグ条件キーをサポートしていないサービスで Allow を使用している

「タグ条件キーをサポートしていないサービスで〜」が多いですね。これはタグベースのコントロールを行いたい時に助かる機能です。

各項目を少し深掘りしてみよう

Error - Invalid service principal format

サービスプリンシパルのフォーマットが正しくない場合に発生するエラーです。

Invalid service principal format: The service principal does not match the expected format. Use the format.

サービスプリンシパルとは、プリンシパル（平たく言えばリクエストの実行元）として AWS サービスを指定する時の id です。

S3 バケットに対して CloudTrail からのログ出力を許可したい場合、S3 バケットポリシーのプリンシパルとしてサービスプリンシパルcloudtrail.amazonaws.comを指定します。

IAM ポリシーにおいては、サービスプリンシパルは条件キーの中で登場する場合があります。その際に誤ったフォーマットで記載した場合、この項目により検知されます。

正しいフォーマットは以下のいずれかです。

• service-name.amazonaws.com
• service-name.AWS_region.amazonaws.com

Error – Missing tag key in condition

条件キーにおいてタグキーの指定が不足している場合に発生するエラーです。

Missing tag key in condition: The condition key must include a tag key to control access based on tags. Use the format tag-key and specify a key name for tag-key.

例えば以下のような条件ブロックがあったとします。

"Condition": {
    "StringEquals": {"ec2:ResourceTag/owner": "JaneDoe"}
}

これは「リクエスト対象のリソースに以下のタグが付与されていた場合に許可/拒否する」という条件の設定を行うものです。

• タグキー：owner
• タグ値：JaneDoe

ec2:ResourceTag/タグキーのように、タグキーの指定が必要となる条件キーはいくつかあります。そこで正しくタグキーが指定されていないとこの項目により検知されます。

Security Warning – Missing paired condition keys

組み合わせて使用するべき条件キーの片方のみが使用されている場合に出る警告です。

Missing paired condition keys: Using the condition key can be overly permissive without also using the following condition keys:. Condition keys like this one are more secure when paired with a related key. We recommend that you add the related condition keys to the same condition block.

例えばaws:VpcSourceIp条件キーを使用すると、 VPC エンドポイント経由でサービスにアクセスする際の送信元 IP アドレスに基づいた条件の設定ができます。さらにaws:SourceVpcと組み合わせることで、送信元の VPC ID に基づいた条件が設定でき、よりセキュアとなります。

いずれか一方しか指定しなかった場合、この項目により警告が行われるため、よりセキュリティレベルの高い設定を実現できます。

~ with unsupported tag condition key for service

以下 4 つをまとめて扱います。

• Security Warning - Deny NotAction with unsupported tag condition key for service
• Security Warning - Deny with unsupported tag condition key for service
• Suggestion - Allow NotAction with unsupported tag condition key for service
• Suggestion - Allow with unsupported tag condition key for service

Deny の場合は警告、Allow の場合は提案です。

平たく言えば、「Deny が効かず権限を与えすぎることになる」「Allow が効かず権限が与えられない」という事象に対するチェックです。

リソースに付与されたタグに基づく条件キーを指定する際にチェックが行われます。これは ABAC と関わりが深いものです。

ABAC の細かい説明はここでは省きますが、分かりやすいところで S3 バケットを例に取ります。

「バケットに特定のタグが付与されていた場合のみアクションを許可する」という制御の仕方が可能かどうか、皆さんはわかるでしょうか。

正解は「できない」です。理由は、リソースタイプbucketは条件キーに対応していないし、タグベースの制御を実現するための条件キーs3:ExistingObjectTagはオブジェクトに対するアクションでのみ対応しているからです。

前者はここから、

後者は例えばここから確認できます。

「特定のタグが付与されたオブジェクトのみ Get を許可する」というコントロールであれば実現できます。

これらは以下リファレンスから詳細を確認できます。

• Amazon S3 のアクション、リソース、条件キー - サービス認証リファレンス

リファレンスの見方は以下を参考にしてください。

ともかく「このサービス、アクションってタグベースの条件キー使用できる……？」というのを調べるのは少し骨が折れます。意図せずサポートされていないアクションで条件キーを使用してしまった時、ポリシーチェックにより警告なり提案をしてくれるようになったというのはありがたいことです。

やってみた

最後のタグベースのコントロールに対するチェックの具体例をご紹介します。

まずはチェックに引っかからないパターンです。

上で確認したリファレンスをおさらいすると、S3 の中ではリソースタイプstoragelensconfigurationのみ、条件キーaws:ResourceTag/${TagKey}に対応しています。

そこで、リソースタイプがstoragelensconfigurationであるアクションs3:GetStorageLensConfigurationを指定し、以下のようなポリシーを記載します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetStorageLensConfiguration",
            "Resource": "arn:aws:s3:*:012345678910:storage-lens/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Project": "Hoge"
                }
            }
        }
    ]
}

Conditon ブロックにより、「 Project キーの値が Hoge であるタグが付与されている場合のみ〇〇可能」という権限が与えられています。

このポリシーを記載する分には、ポリシーチェックに引っかかりません。

ここで、アクションをCreateBucketに変更します。このアクションはaws:ResourceTag/${TagKey}をサポートしていないため、提案として Allow with unsupported tag condition key for service が表示されます。

↑実際にこのポリシーを作成しても、何の効果ももたらしません。

Effect を Deny に変更すると、セキュリティ警告に切り替わります。

Deny を与えたつもりでも、上記のポリシーはそのようには機能しません。

条件キーのサポート範囲を誤って理解していたとしても、このチェックによって気づけるようになったのは嬉しいですね。

終わりに

IAM Access Analyzer のポリシーチェックの項目が増えたというアップデートでした。

理解が難しいタグベースのコントロールについて、自動的にチェックしてくれるようになったのは助かります。もともと 100 個以上のチェック項目が用意されていましたが、今回のアップデートのように追加されていくことで、より使いやすくなりますね。

「こんなチェックしてくれると助かるんだけどな〜！」という思いがある方はフィードバックを送ってみると取り込んでもらえるかも知れません。声をあげてみてはいかがでしょうか。

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