BLT SDC Tech BlogPublicationへの投稿
⚠️

意外とやりがちなIAM権限設定の「落とし穴」

けいっち
に公開
AWS
インフラ
権限
tech

!!!!!!!あと18日!!!!!!!

前談

AWSでIAM権限を設定するとき、こんな風に考えたことありませんか？

  • 「AdminロールとWriteロールで分けてるから安全でしょ」
  • 「PowerUserAccessなら、Administratorより安全だよね」
  • 「IAM操作できないようにしてるから大丈夫」

でも実際、「なんでこんなに権限あるの？」って設定になってませんか？
「一応セキュリティ考えてるつもりだけど...」って感じで。

今回は、実際のAWS環境でよく見かける「実はかなり危険」なIAM設定について、わかりやすく解説していきます！

PowerUserAccessという名前の罠

PowerUserAccessって何？

まず、よく使われるPowerUserAccessというマネージドポリシーについて見てみましょう。

AWSの公式説明はこちら📕

Provides full access to AWS services and resources, but does not allow management of Users and groups.

わかりやすく説明すると「IAMユーザー管理以外は全部できる権限」です。

会社の部長で例えると

PowerUserAccessの危険性を身近な例で考えてみましょう。

つまり、「人事権がない部長」みたいなもの。でも会社のリソースは使い放題。
これって本当に安全ですか？

PowerUserAccessでも同じ

実際の環境では、PowerUserAccessをそのまま使っていることも多いです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "account:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "account:GetAccountInformation",
                "account:GetPrimaryEmail",
                "account:ListRegions",
                "iam:CreateServiceLinkedRole",
                "iam:DeleteServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeEffectivePolicy",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

NotActionで「これ以外は全部OK」という書き方になっています。

IAM操作を除外しているので、一見安全そうに見えますよね。

でも、結局のところ本番環境のリソースは触り放題なんです。

さらに危険：IAMFullAccessという爆弾💣

ここからが本当にヤバい話です。

スーパーサイヤ人になれるボタン

実際の環境で、writeRoleにこんな権限がついていることがあります⚠️⚠️

IAMFullAccess = 自分の権限を自由に変更できる権限

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:*",
                "organizations:DescribeAccount",
                "organizations:DescribeOrganization",
                "organizations:DescribeOrganizationalUnit",
                "organizations:DescribePolicy",
                "organizations:ListChildren",
                "organizations:ListParents",
                "organizations:ListPoliciesForTarget",
                "organizations:ListRoots",
                "organizations:ListPolicies",
                "organizations:ListTargetsForPolicy"
            ],
            "Resource": "*"
        }
    ]
}

ゲームのチートコードみたいなもの

つまり、こんなことができちゃいます。

# 自分のロールにAdministratorAccessを付与
aws iam attach-role-policy \
  --role-name writeRole \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# これで実質Admin権限獲得

「writeRole」という控えめな名前なのに、実質的にはAdmin権限を持っているのと同じなんです。

他の制限も意味がない

例えば、こんな感じで特定のS3バケットのみアクセス可能に制限していたとします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecificS3BucketOnly",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::dev-bucket",
                "arn:aws:s3:::dev-bucket/*"
            ]
        }
    ]
}

「開発用バケットしかアクセスできないようにした！安全！」

でも、IAMFullAccessがあったら、、、

# 制限を自分で外せちゃう
aws iam put-role-policy \
  --role-name writeRole \
  --policy-name AllowAllS3Access \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }]
  }'

せっかく設定した制限が、全部無意味になります。

こんな事故が起こります

「ちょっと確認だけ...」事故

よくある場面
開発者-「本番のEC2、ちょっと状況確認するだけ...」
👉 間違えてEC2を削除
👉 PowerUserAccessがあるので、本当に削除されちゃう

内部犯行のリスク

もし悪意を持った人がいたら

  • 自分にAdmin権限を付与
  • データを全部ダウンロードして持ち出し

IAMFullAccessがあると、全部できちゃいます。

ハッキング被害の拡大

もしwriteRoleの認証情報が漏れたら
攻撃者：「おっ、IAMFullAccessついてるじゃん」
👉 即座に自分にAdmin権限を付与
👉 完全にアカウント乗っ取り完了

被害が一気に拡大します。

どう改善すべきか

その1,Permissions Boundaryを設定する

Permissions Boundary（権限の境界）を使うと、ロールが持てる権限の上限を設定できます。

カスタムPermissions Boundaryポリシーを作成

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*",
                "s3:List*",
                "rds:Describe*",
                "cloudwatch:*",
                "logs:*"
            ],
            "Resource": "*"
        }
    ]
}

注意: AWSには特定サービス用の管理Permissions Boundary（AmazonBedrockStudioPermissionsBoundary等）がありますが、これは汎用的な権限制限には使えないと思ってください。独自のポリシーを作成することをお勧めします！

その２,IAM操作は別ロールに限定

writeRoleからIAMFullAccessを外して、IAM操作は本当のadminロールだけに限定します。

adminRole: IAM操作も含めて全部できる（少数の管理者のみ）
writeRole: リソース操作はできるが、IAM操作はできない
readRole: 参照のみ

その3,環境ごとにロールを分ける

本番環境と開発環境で、ロールを完全に分けるのも有効です。

prod-writeRole: 本番環境のみ操作可能
dev-writeRole: 開発環境のみ操作可能

その4,段階的に移行する

いきなり権限を厳しくすると、開発が止まってしまいます。

  1. 本当に必要な権限だけをリストアップ
  2. テスト環境で試してから本番に適用
  3. 定期的に見直す

まとめ

  • PowerUserAccessは「ほぼAdmin」と思った方がいい

    • IAM操作以外は何でもできる
    • 本番環境のリソースも触り放題

  • IAMFullAccessがあると、実質Admin権限

    • 自分の権限を自由に昇格できる
    • 他の制限も自分で外せる

  • ロール名に騙されない

    • 「writeRole」という名前でも、実質Adminということはある
    • 実際にどんな権限がついているか確認する

  • Permissions Boundaryで上限を設定

    • たとえIAMFullAccessがあっても、境界は超えられない
    • 段階的に権限を見直していく

IAM権限の設定は、一度設定したら終わりではありません。

定期的に見直して、本当に必要な権限だけを付与するようにしましょう。

BLT SDC Tech Blog
BLT SDC Tech BlogPublication

バレットグループ システムデベロップメントカンパニーでは、多種多様なニーズにあわせシステムの企画・立案からプログラムの開発、必要なハードウェア・ソフトウェアの選定・導入までを一気通貫して提供しています。

Discussion