AWS マネジメントコンソールへのサインインを、企業のオフィス IP や社内 VPC からのリクエストだけに限定したいという要望は根強くあります。2026年6月に AWS から、AWS Sign-In がコンソール向けのリソースベースポリシーと RCP（resource control policies）をサポートすることが発表され、この制限をアカウント単位や組織全体で宣言的に強制できるようになりました。
本記事では、セキュリティエンジニアやインフラ担当者に向けて、仕組みと評価フェーズ、有効化手順、CloudTrail 監査、データ境界との統合、注意点を整理します。
AWS Sign-In のリソースベースポリシーと RCP で実現できること
AWS Sign-In のリソースベースポリシー（以下 RBP）と RCP を使うと、AWS マネジメントコンソールへのサインインを、想定ネットワーク、オンプレミス、Amazon VPC からのリクエストだけに制限できます。RBP は個々の AWS アカウント単位、RCP は AWS Organizations 経由で組織全体に適用します。追加コストはかからず、すべての AWS 商用リージョンで利用できます。適用対象の認証方式は次のとおりです。
- AWS マネジメントコンソールへの直接サインイン
- AWS IAM Identity Center 経由のコンソールサインイン
- SAML / OIDC によるフェデレーテッド ID でのサインイン
- Amazon Connect や Amazon QuickSight、Amazon Lightsail などの AWS Sign-In 統合アプリ
一方、アクセスキーを用いたプログラマティックアクセス（AWS SDK や SigV4 署名 API 呼び出し）には適用されません。この性質は後述するロックアウトからの復旧で重要になります。
リソースベースポリシーと RCP の仕組みと評価フェーズ
コンソールサインインはデフォルトで有効で、初期状態では無制限のアクセスが許可されます。制限には console authorization configuration の有効化が必要で、作成したリソース許可ステートメントはこの認可を有効にするまで効果を持ちません。
評価は2つのフェーズに分かれます。事前認証（pre-authentication）フェーズはサインインリクエスト受信時で、root ユーザーでは想定外ネットワークからのアクセスがパスワード入力前にブロックされます。事後認証（post-authentication）フェーズは認証成功後の OAuth トークン交換時で、プリンシパルの IAM ポリシーも併せて評価されます。サインインを Deny する IAM ポリシーがあればセッションは付与されず、IAM ポリシーとは併存します。
評価対象となる3つのアクション
コンソールサインインは OAuth 2.0 を使い、次の3つのアクションを順次経由します。事前認証と事後認証の両方のステートメントをカバーする必要があり、片方を省くとそのフェーズは保護されません。
アクション | フェーズ | 説明 |
|---|---|---|
signin:Authenticate | 事前認証 | サインインリクエスト受信時に評価される評価専用アクションです |
signin:AuthorizeOAuth2Access | 事後認証 | OAuth 認可コード生成時に評価されます |
signin:CreateOAuth2Token | 事後認証 | 認可コードをトークンへ交換する際に評価されます |
ネットワークとアイデンティティの condition キー
condition キーはフェーズによって利用可否が異なります。
- ネットワーク系（全アクション）― aws:SourceIp、aws:SourceVpc、aws:SourceVpce、aws:VpcSourceIp、aws:RequestedRegion
- アイデンティティ系（事後認証のみ）― aws:PrincipalArn、aws:PrincipalAccount
- サービス固有（事前認証 signin:Authenticate のみ）― signin:PrincipalArn。aws:PrincipalArn に相当します
1つのリクエストには aws:SourceIp（パブリック網）または aws:SourceVpc（VPC 経由）の一方しか含まれないため、両経路をカバーするには NotIpAddressIfExists のような IfExists 演算子を使います。また aws:SourceVpc は VPC ID がリージョン内でのみ一意なため aws:RequestedRegion と併用し、aws:VpcSourceIp は aws:SourceVpc か aws:SourceVpce と併用します。
コンソール認可を有効化する手順
設定は AWS CLI で行います。前提は、管理権限を含む AWS マネージドポリシー AWSSignInResourcePolicyManagement、ネットワーク境界の特定、緊急用の除外プリンシパルの用意です。AWS が us-east-1 からポリシーをグローバル複製するため、書き込み操作は --region us-east-1 が必須です（読み取りは任意のリージョン可）。まずリソース許可ステートメントを作成します。以下のとおりです。
aws signin put-resource-permission-statement \
--source-vpc vpc-0abc123def456789 \
--requested-region us-west-2 \
--excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \
--client-token unique-request-id-12345 \
--region us-east-1IP で制限する場合は --source-ip を使い、--excluded-principal には制限をバイパスできる緊急アクセス用プリンシパルを指定します。次に console authorization を有効化します。
# スタンドアロンアカウント
aws signin put-console-authorization-configuration --target-id <aws-account-id> --region us-east-1
# AWS Organizations 全体
aws signin put-console-authorization-configuration --target-id <aws-organization-id> --region us-east-1最後に検証します。get-resource-policy は全ステートメントを統合したポリシーを返します。
aws signin list-resource-permission-statements --max-results 50 --region us-east-1
aws signin get-resource-policy --region us-east-1console authorization の有効化は、ネットワーク設定の誤りや、signin:Authenticate / signin:AuthorizeOAuth2Access / signin:CreateOAuth2Token を Deny する既存の SCP・RCP があるとプリンシパルをロックアウトしかねません。事前にステートメントと既存ポリシーを必ず確認してください。
CloudTrail でアクセスを検証し監査する
AWS CloudTrail は、すべての AWS Sign-In ポリシー評価と設定変更を自動的に記録します。Event history では最大90日保持され、長期保持は S3 へのトレイル配信で行います。サインインイベントは eventSource が signin.amazonaws.com、eventName が ConsoleLogin です。許可時は responseElements に "ConsoleLogin": "Success" が、拒否時は "ConsoleLogin": "Failure"、"errorCode": "AccessDenied" とともに errorMessage が記録され、拒否要因が RBP か RCP かを切り分けられます。
- RBP による拒否 ―
Authorization denied because of a resource-based policy - RCP による拒否 ―
Authorization denied because of a resource control policy
アラートには EventBridge ルールや SIEM 転送を使います。
Console Private Access とデータ境界フレームワークとの統合
AWS Management Console Private Access は、VPC 内からのトラフィックに対し、コンソール利用を既知の AWS アカウント集合に限定できる機能です。AWS PrivateLink 経由でコンソールトラフィックを VPC エンドポイントにルーティングし、パブリックインターネットを経由させずに済みます。実装は、コンソール、コンソール専用 API、AWS Sign-In、サービス API への VPC エンドポイントを作成して行い、Direct Connect や VPN 経由のオンプレミスにも対応します。
Sign-In の RBP・RCP が「どのネットワークからサインインできるか」を、Console Private Access が「どのアカウントにアクセスできるか」を制御し、両者で多層防御が形成されます。これはデータ境界（data perimeter）の考え方に直結し、Sign-In 制御は次の境界に寄与します。
- ネットワーク境界 ― Sign-In ポリシーで想定 IP / VPC に制限
- アイデンティティ境界 ― 信頼された ID のみを認証
- リソース境界 ― VPC エンドポイントポリシーで到達可能なアカウントを制限
規制コンプライアンスのユースケースと導入時の注意点
多くのコンプライアンスフレームワークが、ネットワークベースのアクセス制御を要求します。承認済みネットワークからのみアクセスを許可する RCP を組織全体に適用し CloudTrail ログを証跡とする用途、多数アカウントの統一管理、委託先への一時アクセス制御に適します。
ロックアウトを防ぐための注意点
root を含むすべてのプリンシパルがポリシーの対象になるため、本番で強制する前に緊急復旧用の除外プリンシパル（break-glass）を最低1つ構成し、事前認証の signin:PrincipalArn と事後認証の aws:PrincipalArn の両方に除外 ARN を含めてください。万一ロックアウトしても、プログラマティックアクセスは対象外なので、SigV4 の CLI で delete-console-authorization-configuration を実行して復旧できます。
RCP の explicit deny は他ポリシーの allow を上書きするため、組織 root に直接アタッチせず、まず OU へ1アカウントずつ移動してテストする段階的な適用が安全です。最終的には Sign-In ポリシー、IAM、SCP、VPC エンドポイントポリシーによる多層防御を目指します。
