はじめに

今回は、2026年6月16日に発表されたAWS Sign-InのResource Control Policy（RCP）対応について説明します。

AWS Sign-Inは、AWS Management Console（マネジメントコンソール）からAWSアカウントへサインインする際に利用されるサービスです。今回のアップデートにより、AWS Sign-Inに対してリソースベースポリシーやRCPを設定し、サインイン時のアクセス制御を行えるようになりました。

リソースベースポリシーは単一アカウントに対する制御で利用できます。一方、RCPはAWS Organizationsのポリシーとして管理できるため、OUやアカウント単位で組織的にマネジメントコンソールへのアクセス制御を適用できます。

実案件に対応していると、マネジメントコンソールに対して接続元IPアドレス制限を行いたいという要件はよくありましたが、これまではIAMポリシーによるIPアドレス制限を行うことで実現していたケースが多いのではないでしょうか。マルチアカウント環境下で画一的なIPアドレス制限を実現しようとすると、さまざまな機能を組み合わせる必要があり、実現負荷が高かったのですが、今回のアップデートでシンプルに実現できることが期待されます。

ただし、後述のとおり、IAM Identity Centerポータル経由のコンソールアクセスは、本稿執筆時点ではネットワーク条件による制限に対応していません。では、アップデート内容を詳しく説明していきます。

AWS Sign-InのRCP対応とは

AWS Sign-Inに対するRCPでは、サインインに関する以下のアクションを制御できます。

  • signin:Authenticate
  • signin:AuthorizeOAuth2Access
  • signin:CreateOAuth2Token

signin:Authenticateは、マネジメントコンソールへのサインイン時に評価されます。一方、signin:AuthorizeOAuth2Accessとsignin:CreateOAuth2Tokenは、コンソールセッション中に必要な認可やトークン発行のタイミングで評価されます。

そのため、マネジメントコンソールへのアクセス元IPアドレスを制限する場合は、認証前のsignin:Authenticateだけでなく、認証後に利用されるアクションもあわせて制御する必要があります。

また、公式ドキュメントでは、SAMLやOIDCによるフェデレーションサインインにも適用されることが説明されています。筆者が検証を行った時点では、IAM Identity Centerによるサインインも適用対象として記載されていたため、今回はIAM Identity Center経由のサインインで動作を確認しました。ただし、後述のとおり、その後ドキュメントが更新され、執筆時点ではIAM Identity Centerポータル経由のコンソールアクセスは適用対象から除外されています。

検証環境

本稿では、以下のような構成で検証を行いました。

これまでの記事と同様に、管理アカウントとは別のアカウントを委任管理者アカウントとして設定しています。

管理アカウントの操作

それでは、ここから管理アカウントでの操作について説明していきます。第18回で紹介したように、RCPが有効化されていることを事前に確認しておきます。RCPは委任管理者に対応しているため、委任管理者の設定を行います。

(1)Organizationsのサイドメニューから「設定」をクリックし、AWS Organizationsの委任された管理者の「編集」ボタンをクリックします（筆者の検証環境ではRCP以外の組織ポリシーの委任を設定済みのため、既存の委任ポリシーを「編集」ボタンから修正する形でRCPの委任設定を追加しています）。

(2)公式ドキュメントのサンプルを参考に、下記のような委任ポリシーを作成し、「ポリシーを保存」ボタンをクリックします。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRcpPolicyOperation",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{委任管理者アカウントID}:root"
      },
      "Action": [
        "organizations:ListPoliciesForTarget",
        "organizations:ListTargetsForPolicy",
        "organizations:ListPolicies",
        "organizations:DescribeEffectivePolicy",
        "organizations:UpdatePolicy",
        "organizations:DeletePolicy",
        "organizations:DetachPolicy",
        "organizations:AttachPolicy",
        "organizations:CreatePolicy",
        "organizations:DescribePolicy",
        "organizations:DisablePolicyType",
        "organizations:EnablePolicyType"
      ],
      "Resource": "*",
      "Condition": {
        "StringLikeIfExists": {
          "organizations:PolicyType": [
            "RESOURCE_CONTROL_POLICY"
          ]
        }
      }
    },
    {
      "Sid": "AllowListForRcpPolicyOperation",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{委任管理者アカウントID}:root"
      },
      "Action": [
        "organizations:ListRoots",
        "organizations:ListTagsForResource",
        "organizations:DescribeAccount",
        "organizations:ListAWSServiceAccessForOrganization",
        "organizations:ListChildren",
        "organizations:ListAccountsForParent",
        "organizations:ListHandshakesForAccount",
        "organizations:ListHandshakesForOrganization",
        "organizations:ListAccounts",
        "organizations:DescribeOrganization",
        "organizations:DescribeOrganizationalUnit",
        "organizations:ListParents",
        "organizations:ListOrganizationalUnitsForParent"
      ],
      "Resource": "*"
    }
  ]
}

以下のコマンドをCloudShell等で実行し、コンソール認可設定（console authorization configuration）を有効化します。--target-idには、Organizationsのダッシュボード等で確認できる組織ID（o-から始まるID）を指定します。このコマンドは管理アカウントでのみ実行可能です。委任管理者アカウントで実行するとエラーが表示されます。


~ $ aws signin put-console-authorization-configuration \
>   --target-id o-xxxxxxxxxx \
>   --region us-east-1
{
 "targetId": "o-xxxxxxxxxx",
 "scope": "ORGANIZATION",
 "consoleAuthorizationEnabled": true
}

ここで注意が必要なのは、AWS Sign-Inのコンソール認可設定APIの書き込み操作は、IAM Identity Centerのリージョンにかかわらず、常にus-east-1で実行する必要がある点です。

今回の検証環境では、IAM Identity Centerのリージョンは東京リージョン（ap-northeast-1）でしたが、これに合わせてap-northeast-1で書き込み操作を実行すると、以下のエラーが返されました。


Write operations only supported in us-east-1

これは、AWS Sign-Inのポリシー変更を扱うコントロールプレーンの書き込み操作がus-east-1でのみ受け付けられるためです。us-east-1で作成された設定は、グローバルに複製されます。IAM Identity Centerのリージョンがどこであっても、AWS Sign-Inの設定APIの書き込み操作はus-east-1で実行する点に注意してください。

これで管理アカウントの操作は完了です。次に委任管理者アカウントでの操作に移ります。

委任管理者アカウントの操作

(1)Organizationsのサイドメニューから「ポリシー」をクリックし、「リソースコントロールポリシー」リンクをクリックします。

(2)「ポリシーを作成」ボタンをクリックします。

(3)以下のRCPを作成します。このポリシーでは、/32以外の送信元IPアドレスからAWS Sign-Inへアクセスした場合に拒否します。

また、復旧用の経路を残すため、メンバーアカウントのルートユーザーは除外しています。検証目的であっても、マネジメントコンソールへの入口を制御する場合は、ロックアウト時の復旧方法を念のため用意しておいたほうが良いでしょう。 認証前のsignin:Authenticateと、認証後のsignin:AuthorizeOAuth2Access・signin:CreateOAuth2Tokenとでは、除外ユーザーの指定方法が異なります。そのため、別々のステートメントとして記述する必要がある点に注意してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyConsolePreAuthOutsideExpectedIpExceptRoot",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "signin:Authenticate",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "<ALLOWED_GLOBAL_IP>/32"
          ]
        },
        "ArnNotEquals": {
          "signin:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    },
    {
      "Sid": "DenyConsolePostAuthOutsideExpectedIpExceptRoot",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "signin:AuthorizeOAuth2Access",
        "signin:CreateOAuth2Token"
      ],
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "<ALLOWED_GLOBAL_IP>/32"
          ]
        },
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

(1)作成したRCPを選択し、「アクション」→「ポリシーのアタッチ」をクリックします。

(2)対象OUを選択し、「ポリシーのアタッチ」ボタンをクリックします。

IAM Identity Center経由のサインインの確認

それでは設定後、IAM Identity CenterのAWSアクセスポータルから、対象アカウントのAdministratorAccessロールでサインインを試みます。

検証を行った時点の公式ドキュメントでは、IAM Identity Center経由のサインインにもAWS Sign-Inに対するRCPが適用されると説明されていました。ところが、筆者の環境では、RCPで許可したIPアドレスからアクセスしたにもかかわらず、以下のようにアカウントログインエラーとなり、サインインがブロックされてしまいました。

切り分けのため、RCPからNotIpAddressの条件を削除した場合と、許可するIPアドレスを0.0.0.0/0へ変更した場合を試したところ、いずれも問題なくサインインできました。この結果から、RCP自体は評価されているものの、IPアドレスの条件が意図どおりに機能していないと考えられます。

原因を調査するため、メンバーアカウントのCloudTrailを確認したところ、IAM Identity Center経由でマネジメントコンソールへサインインする際には、GetSigninTokenイベントとConsoleLoginイベントの2つが記録されていました。ConsoleLoginイベントのソースIPアドレスは筆者の接続元のIPアドレスでしたが、GetSigninTokenイベントのソースIPアドレスはAWS側のIPアドレスとなっており、サインインフローの一部が筆者の接続元とは異なるネットワークから実行されているように見えます。このため、aws:SourceIpの条件に一致せず、拒否されているのではないかと推測しています。

その後、公式ドキュメントが更新され、本稿執筆時点では以下の注記が追加されています。

Console access through the IAM Identity Center portal is not currently compatible with AWS Sign-In policies that restrict access based on network condition keys. Enabling network-based restrictions will block console access for user in IAM Identity Center users.

IAM Identity Centerポータル経由のコンソールアクセスは、現時点では、ネットワーク条件キー（aws:SourceIp等）に基づいて制限を行うAWS Sign-Inのポリシーと互換性がなく、ネットワークベースの制限を有効化すると、IAM Identity Centerユーザーのコンソールアクセスがブロックされる、という内容です。あわせて、適用対象の認証方式の一覧からも、IAM Identity Centerによるサインインの記載が削除されています。筆者が確認した事象は、まさにこの注記のとおりの動作でした。

そのため、IAM Identity Centerポータル経由のコンソールアクセスが必要な環境では、現時点ではネットワーク条件を含むRCPをsigninアクションに対して適用できません。すでに対象OUへアタッチしてしまっている場合は、ポリシーのデタッチ、またはネットワーク条件の見直しが必要です。なお、注記が「not currently compatible」という表現になっていることから、将来的なサポートが期待されます。本連載でも、アップデートがあれば改めて紹介したいと思います。

課題となりやすいポイント

最後に課題となりやすいポイントを紹介します。

(1)本稿でも述べたとおり、マネジメントコンソールの接続元IPアドレス制限の除外対象となるユーザーの設計は慎重に行う必要があります。誤った設計を行うと、管理者がコンソールにアクセスできなくなる可能性があります。復旧用の経路を残すことは必須です。今回は検証のため、ルートユーザーを除外する方法を紹介しましたが、実運用では、CCoE用のユーザーを除外するなどの運用になるかと思います。

(2)今回のアップデートによるRCPの評価は、あくまでAWS Sign-Inに対して行われます。アクセスキー等を用いたSigV4署名によるCLIやSDKの操作は制限対象外です（なお、aws loginコマンドによるサインインはAWS Sign-Inを経由するため制限対象です）。CLIやSDKでの操作も制限したい場合は、IAMポリシーを組み合わせて設計する必要があります。

(3)本稿の検証で確認したとおり、IAM Identity Centerポータル経由のコンソールアクセスは、本稿執筆時点ではネットワーク条件キーによる制限に対応していません。IAM Identity Centerを利用している環境でネットワークベースの制限を有効化すると、許可したいユーザーのアクセスまでブロックされてしまいます。この点は今後のアップデートで変わる可能性があるため、適用を検討する際は、必ず公式ドキュメントで最新のサポート状況を確認してください。

おわりに

本稿では、AWS Sign-InのRCP対応を利用して、マネジメントコンソールへのサインインをIPアドレスで制限する方法と、IAM Identity Centerポータル経由のコンソールアクセスが本稿執筆時点ではネットワーク条件による制限に対応していないという注意点を紹介しました。

マネジメントコンソールへのアクセス制御は、従来はネットワークやIAMポリシー、SCPを組み合わせて設計することが多い領域でした。AWS Sign-InのRCP対応により、Organizationsを利用したマルチアカウント環境では、コンソールサインインの入口に対してより直接的なガードレールを適用できるようになることが期待されます。本稿が、マルチアカウント環境におけるコンソールアクセス制御の設計の一助になれば幸いです。

奥村康晃

奥村康晃

おくむらやすあき

NTTデータ入社以来、クラウドサービスのAPIを連携させることで効率的な管理を可能とするクラウド管理プラットフォームの開発に従事。現在では、クラウド導入の技術コンサルや組織での技術戦略立案にも携わる。 2025年度Top AWS Ambassador受賞

この著者の記事一覧はこちら