AWS管理者になって苦労した、IAMポリシー権限設定のあれこれ

はじめに

こんにちは、D2Cデータアナリストの稲垣です。

AWSの管理について右も左もわからない状態から勉強を始めました。
プロジェクトメンバーから様々な問題や依頼が発生している中で、
管理者である私が壁にぶつかった【IAMのポリシー権限】について誰でもわかる情報を共有できればと思います。
そのため、この記事ではなるべく誰でもわかる用語で説明していきます。

ポリシー・ユーザーグループ・ロールについて

ポリシーとは

AWSサービスに対して行う操作の権限を決めます。
このポリシーをユーザーやユーザーグループにアタッチ(付与)させることで初めて、s3やRedshiftなどの操作が行えるようになります。
jsonもしくはAWSコンソールのUIで設定ができます。

ポリシー作成時に使用される代表的なパラメータ

• Version：IAMポリシーのバージョンを表す。2023年9月時点では2012-10-17もしくは2008-10-17しか存在しない。
• Sid：ポリシーの説明を設定することが一般的、設定しなくても問題はない。
• Action：AWSのサービス(s3やEC2など)とアクションを設定できます。
• Effect：Actionで設定した内容に対してAllow(許可)かDeny(拒否)が設定できます。
• Resource：Actionで設定した内容に対して範囲(任意のユーザーなど)を設定できます。

ユーザーグループとは

名前の通り、各ユーザーをまとめたグループ。
グループごとに複数のポリシーを適用できる為、社員区分やプロジェクト別で作成されることがあります。
また、複数のグループにまたがって所属させることができる為直接ユーザーにアタッチさせるよりユーザーグループで管理していく方が良いです。

ロールとは

EC2経由でS3を操作したい場合などに設定するものです。
ロールはユーザーにも設定することができ、スイッチロールという機能を使用することで別のAWSアカウントを操作したりすることもできます。

今回の記事では使用しません。

実際に発生した問題をもとにポリシーを修正してみた

今回はMFA認証設定(2段階認証)ができない問題が発生したため、それを解決してみました。
セキュリティ認証情報からMFAを割り当てるで設定しようとしたところ以下のようなエラーが発生。

デバイス名を入力し次へのボタンを押すと

エラー原因の調査

該当ユーザーが所属しているグループユーザーから設定されている許可ポリシーを確認。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "account:*",
                "aws-portal:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:DeleteServiceLinkedRole",
                "iam:List*",
                "iam:Get*",
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIndividualUserToListOnlyTheirOwnMFA",
            "Effect": "Allow",
            "Action": [
                "iam:ListMFADevices"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/*",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "AllowIndividualUserToManageTheirOwnMFA",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "AllowIndividualUserToDeactivateOnlyTheirOwnMFAOnlyWhenUsingMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ],
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        }
    ]
}

上からMFA認証設定が関係していそうなアクションをAWSのドキュメンテーションで順番に確認していきます。

• NotAction：IAM（とその他もろもろ）以外のアクションをすべて許可する
• ListVirtualMFADevices：ユーザーに対して有効になっている仮想 MFA デバイスに関する詳細を表示
• ListMFADevices：MFA デバイスを一覧表示する
• CreateVirtualMFADevice：MFAデバイスの登録の許可を制御
• DeleteServiceLinkedRole：MFAデバイスの削除の許可を制御
• EnableMFADevice：MFAデバイスをとIAMユーザーを紐づける許可を制御
• ResyncMFADevice：MFAデバイスをとIAMユーザー・ロールに同期させる許可を制御
• DeactivateMFADevice：既に登録されているMFAデバイスとIAMユーザーの紐づけの削除を制御

エラー原因

結論から言うと、デバイス名を入力する際に自身のユーザー名で登録していればエラーにはなりませんでした。
今回はデバイス名については制御しないように修正していきます。
CreateVirtualMFADeviceに対してResourceで設定した範囲を修正。

        {
            "Sid": "AllowIndividualUserToManageTheirOwnMFA",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice"
            ],
            "Resource": [
+                "arn:aws:iam::*:mfa/*",
-                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },

修正し再度MFA登録をしたところ、次の画面に進むことができました。

前の管理者がポリシーを作成したタイミングでは、MFA登録時にデバイス名を入力する必要が無く、
デフォルトでユーザー名が入っていたことが今回の原因でした。

おわりに

本記事ではIAMのポリシーについて簡単な説明と対応内容について紹介いたしました。
今回は比較的シンプルな調査になりましたが、所属しているグループが多い場合や直接アタッチされているポリシーなどが複雑にある場合は地道に確認していく根気が必要となってきます。

そうしないためにも、グループごとで管理していく、もしくはポリシーの条件に一貫性を持たせる(DenyとAllowをいくつも織り交ぜない)などの必要があるかと思います。

参照

https://zenn.dev/khale/articles/aws-mfa-modify