AWS OrganizationsでルートユーザーをIP制限する

はじめに

こんにちは。クラウド活用推進担当の安田です。

AWSアカウントのルートユーザーは、全ての権限を持つ特権アカウントです。そのため、認証情報が漏洩した場合、アカウント内の全てのリソースが危険にさらされます。

今回は、AWS Organizations環境でメンバーアカウントのルートユーザーだけにSCPで接続元IP制限をかけられるのかを検証しました。


この記事の位置づけ

AWS Organizationsでは、新規作成するメンバーアカウントはroot資格情報なしがデフォルトであり、AWSはcentralized root accessによるroot資格情報の削除を推奨しています。

ただし、緊急時の復旧手段や一部のルートユーザー専用操作のために、root資格情報を残して運用するケースもあります。

この記事では、そのような場合の追加対策として、SCPによる接続元IP制限を検証します。

目次

  1. この記事で分かること
  2. 検証の目的
  3. 検証環境
  4. 実装方法
  5. 検証結果
  6. 検証で分かったこと
  7. 重要な注意事項
  8. まとめ
  9. 参考資料

この記事で分かること

この記事では、以下の内容を紹介します。

・SCPでルートユーザーのみにIP制限をかける方法
・IP制限の動作特性
・許可IP外からのルートユーザー操作がどう拒否されるか
・IAMユーザーの日常業務に影響が出るか
・IP制限だけでは不十分な理由と追加対策

検証の目的

今回は、AWS Organizationsで複数のAWSアカウントを管理している環境を前提とします。

管理アカウント配下にあるメンバーアカウントのルートユーザーに対して、SCPで接続元IP制限を適用できるかを確認しました。


確認したいこと

  1. メンバーアカウントのルートユーザーに対して、SCPで接続元IP制限が可能か
  2. ルートユーザーだけを制限対象にできるか
  3. IAMユーザーや通常業務に影響が出ないか

検証のポイント

SCPはアカウント全体に影響するため、条件指定を誤るとIAMユーザーやIAMロールの通常業務まで止めてしまう可能性があります。

今回は、aws:PrincipalArn 条件を使って、対象をルートユーザーに限定できるかを確認します。

検証環境

項目 内容
AWS Organizations 有効化済み
対象アカウント メンバーアカウント1つ
検証方法 特定アカウントにSCPを直接アタッチ
影響範囲 検証対象アカウントのみ

実装方法

SCPポリシーの作成

以下のSCPポリシーを作成しました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUserOutsideApprovedIP",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": ["arn:*:iam::*:root"]
        },
        "NotIpAddress": {
          "aws:SourceIp": [
            "xxx.xxx.xxx.xxx/xx",
            "yyy.yyy.yyy.yyy/yy"
          ]
        }
      }
    }
  ]
}

ポリシーのポイント

設定 意味
aws:PrincipalArn ルートユーザー(arn:*:iam::*:root)のみを対象にする
NotIpAddress 許可IPリスト以外からの操作を拒否する
Action: "*" 全てのAWS操作を対象にする
Effect: Deny 条件に一致した操作を明示的に拒否する

アタッチ手順

  1. AWS Organizations コンソールを開く
  2. 上記のSCPポリシーを作成する
  3. 対象のメンバーアカウントにSCPをアタッチする
  4. 許可IPと許可IP外の両方から動作を確認する

検証結果

テスト1:許可IPからルートユーザーでアクセス

結果:成功

・許可IPからルートユーザーでログイン成功
・S3、EC2などの各AWSサービスに正常にアクセス可能
・操作に制限なし


テスト2:許可IP外からルートユーザーでアクセス

結果:期待通りに拒否

・コンソールへのログイン自体は成功
・各サービスにアクセスすると「アクセス拒否」エラーが表示される
・例:servicecatalog:ListApplications などの操作が拒否される
・ログイン後の操作が実質的にブロックされる

https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_4368186_751dbcce-b963-4baa-bb7f-227210c344b3.jpg

テスト3:IAMユーザーへの影響確認

結果:今回のSCP条件では影響なし

・IAMユーザーでログイン成功
・接続元IPアドレスに関係なく正常にアクセス可能
・検証環境では、IAMユーザーは各AWSサービスに制限なくアクセス可能


結果の整理

検証内容 結果 補足
許可IPからルートユーザーで操作 成功 通常通りAWSサービスを操作できる
許可IP外からルートユーザーで操作 拒否 ログイン後のAPI操作が拒否される
IAMユーザーで操作 影響なし aws:PrincipalArn 条件で対象外になる

検証で分かったこと

1. SCPはログイン拒否ではなくAPI操作拒否として機能する

今回の検証では、許可IP外からでもルートユーザーのコンソールログイン自体は成功しました。

ただし、ログイン後に各AWSサービスへアクセスすると、API操作が拒否されます。

セキュリティ上の重要な注意点

ログイン自体が成功するため、攻撃者は「認証情報が正しい」ことを確認できてしまいます。

そのため、SCPによるIP制限だけで安心するのは危険です。CloudTrailでルートユーザーログインを監視し、アラートを出す仕組みが必要です。


2. aws:PrincipalArn 条件でルートユーザーだけを対象にできる

今回のSCPでは、aws:PrincipalArn に arn:*:iam::*:root を指定しました。

この条件により、IAMユーザーは制限対象外となり、接続元IPに関係なく通常通り操作できました。

実用上の意味

・日常運用はIAMユーザーまたはIAMロールで実施する
・ルートユーザーは緊急時のみ許可IPから使用する
・ルートユーザーの認証情報が漏洩しても、許可IP外からの操作を抑止できる


3. IP制限は有効だが、単独では不十分

SCPによるIP制限は、ルートユーザーの操作を抑止する対策として有効でした。

ただし、ログイン自体は成功すること、またSCPの対象外となる操作が存在することを考えると、これだけで十分とは言えません。

重要な注意事項

この記事で検証したIP制限は有効ですが、ルートユーザー保護の対策としては一部にすぎません。

IP制限だけでは不十分な理由

1. ログイン自体は成功するため、認証情報の正当性が確認される
2. AWS公式にSCPの対象外として明記されている操作が存在する
3. 許可IPの管理を誤ると、緊急時にルートユーザーを使えなくなる可能性がある

必須の追加対策

・ルートユーザーにMFAを設定する
・CloudTrailでルートユーザーログインを監視する
・許可IPリストの管理手順を明確にする
・緊急時の復旧手順を文書化する
・状況に応じてroot資格情報の削除も検討する

まとめ

今回の検証では、SCPでメンバーアカウントのルートユーザーだけに接続元IP制限をかけられることを確認しました。

aws:PrincipalArn 条件でルートユーザーに対象を絞ることで、IAMユーザーの日常業務には影響を与えずに、ルートユーザーの操作だけを制限できます。

今回の結論

・SCPでルートユーザーのIP制限は可能
・IAMユーザーへの影響はなし
・ただし、ログイン自体は成功する
・IP制限に加えて、MFAとCloudTrail監視が必須

ルートユーザーを完全に使わない運用にできるなら、root資格情報の削除を検討するのが望ましいです。

一方で、組織の事情によりroot資格情報を残す必要がある場合は、MFA、監視、IP制限を組み合わせて多層的に保護することが重要です。

参考資料

AWS account root user

Root user best practices for your AWS account

Service Control Policies (SCPs)

AWS Global Condition Context Keys

IP制限の例

Service Control Policy Library - Root User Deny

AWS re:Post - IAMユーザーのIP制限実装ガイド

クラウド基盤ソリューション