プライベートアクセスでデータ境界を AWS マネジメントコンソールまで拡張

本ブログは 2026 年 8 月 28 日に公開された AWS Blog “Extend your data perimeter to the AWS Management Console with Private Access” を翻訳したものです。

金融サービス、政府、防衛、ヘルスケアなどの規制対象業界の組織は、機密性の高いワークロードを、パブリックインターネットにアクセスできない分離されたネットワーク環境に限定しています。これまでも、AWS マネジメントコンソールへのアクセスを承認済みの AWS アカウントと企業ネットワークに制限することはできましたが、コンソール自体にはインターネット接続が必要でした。そのため、運用上の利便性とネットワークセキュリティ統制が相反する状況が生じていました。

このたび、AWS マネジメントコンソールプライベートアクセスが、インターネット接続のない仮想プライベートクラウド (VPC) に対応し、一般提供を開始したことをお知らせします。ワークロードを分離されたネットワーク環境に限定している規制対象業界の組織は、サポート対象のサービスコンソールのすべてのトラフィックを AWS PrivateLink の VPC エンドポイント経由でルーティングできるようになりました。対象となるトラフィックには、認証フロー、静的アセット (JavaScript、CSS、画像)、コンソール専用 API、AWS サービスの API コールが含まれます。これにより、インターネットゲートウェイ、NAT ゲートウェイ、パブリックインターネットへのルートが一切不要になります。この機能は、すべての AWS 商用リージョンにおいて、一部のサポート対象のサービスコンソールで利用できます。

AWS は 2023 年に AWS マネジメントコンソールプライベートアクセスをリリースしました。この機能では、コンソール、サインイン、サービスの API コールを VPC エンドポイント経由でルーティングして、コンソールに接続できます。ただし、コンソールにアクセスする際、静的アセットとコンソール専用 API にはインターネット接続が必要でした。その結果、セキュリティチームは、コンソールを使用するためにインターネット接続を許可するか、ネットワークが分離された環境で作業するオペレーターのコンソールアクセスを拒否するかの選択を迫られていました。

今回のリリースにより、AWS マネジメントコンソールプライベートアクセスは、次の 2 つの一般的なシナリオに対応します。

インターネットアクセスが制限されたネットワークでのコンソールトラフィック: サポート対象のサービスコンソールのトラフィックが、すべて VPC エンドポイント経由で流れるようになりました。プロキシの許可リストを維持する必要も、TLS インターセプトプロキシを運用する必要もありません。妥協策として CLI のみのワークフローを受け入れる必要もありません。同じ経路は、Amazon WorkSpaces、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、および AWS Direct Connect または AWS Site-to-Site VPN で接続されたオンプレミスネットワークからもシームレスに利用できます。サインイン用のリソースコントロールポリシー (RCP) とサインインリソースポリシーを組み合わせると、想定されたネットワークからのみコンソール認証が成功するように設定できます。有効な認証情報が別の場所で提示されても、そのセッションは拒否されます。これまで制限付きのエグレスルールや手動のドメイン許可リストに頼っていたチームも、既に信頼している同じネットワーク統制のもとで、コンソールに全面的にアクセスできるようになります。
データ流出の防止: プライベートアクセスを使用すると、VPC 内から AWS マネジメントコンソールを使用できる AWS アカウントと組織のアイデンティティを制限できます。これにより、個人アカウントや組織外のアカウントからのアクセスを防止できます。aws:ResourceOrgID 条件を含む VPC エンドポイントポリシーをアタッチすると、コンソールで実行するアクションの対象が自動的に組織内のリソースに限定されます。さらにサインイン RCP によって、境界内のネットワークからの認証のみが成功するようになり、2 つ目の防御層が加わります。これらの統制を組み合わせることで、複雑なネットワークレイヤーの回避策を講じなくても、サポート対象のサービスコンソールを使用して個人アカウントなど組織外のアカウントのリソースにアクセスすることを防止できます。

この記事では、インターネット接続のない環境で AWS マネジメントコンソールプライベートアクセスがどのように機能するかを説明します。また、VPC エンドポイントポリシーとサインイン RCP を使用してアクセス統制を多層化し、データ境界を強化する方法も紹介します。

ソリューションの概要

AWS マネジメントコンソールプライベートアクセスとサインイン RCP は、API トラフィックに既に使用しているサービスコントロールポリシー (SCP)、RCP、VPC エンドポイントポリシーを自然に拡張したもので、これらの統制をコンソールセッション自体にも適用します。プログラムによるアクセスを保護しているアイデンティティ、リソース、ネットワークのデータ境界の統制によって、インタラクティブなブラウザセッションも同じように保護されます。

境界	統制の目的	ポリシーの構成要素	実装手順
アイデンティティ	信頼できるアイデンティティのみが自組織のリソースにアクセスできる	サインイン RCP とリソースベースのポリシー (RBP)	コンソールにサインインできるプリンシパルを制限します。認証前は、`signin:PrincipalArn` を除外の指定にのみ使用できます。認証後は、RCP で組織、アカウント、またはプリンシパルのレベルで制限し (`aws:PrincipalOrgID`、`aws:PrincipalAccount`、`aws:PrincipalArn`)、RBP でアカウントまたはプリンシパルのレベルで制限します。
アイデンティティ	自組織のネットワークからは信頼できるアイデンティティのみを許可する	コンソールの VPC エンドポイントポリシーとサインインの VPC エンドポイントポリシー	コンソールエンドポイント: サインイン済みのアイデンティティに対して `aws:PrincipalOrgID` または `aws:PrincipalAccount` を使用します。サインインエンドポイント: 認証前は `aws:ResourceOrgID` または `aws:ResourceAccount` を、認証後はプリンシパルキーとリソースキーを使用します。これにより、自組織のネットワークから個人アカウントなど組織外のアカウントへのサインインをブロックします。
リソース	自組織のアイデンティティは信頼できるリソースにのみアクセスできる	SCP	`aws:ResourceOrgID` を使用したリソース境界 SCP は、すべてのコンソールセッションでプリンシパルに適用されます。コンソールがプリンシパルに代わって行う各サービス API コールは、対象リソースが組織外にある場合に拒否されます。
リソース	自組織のネットワークからは信頼できるリソースにのみアクセスできる	コンソールの VPC エンドポイントポリシーとサービスの VPC エンドポイントポリシー	コンソールエンドポイントポリシーで `aws:ResourceOrgID` と `aws:ResourceAccount` を使用して、ネットワーク経由でコンソールがアクセスできる範囲を限定します。
ネットワーク	自組織のアイデンティティは想定されたネットワークからのみリソースにアクセスできる	SCP	aws:SourceVpc を使用するネットワーク境界 SCP は、想定されたネットワークの外部から行われるプリンシパルのサービス呼び出しを拒否します。プライベートアクセスでは、コンソールがサポート対象のサービスにプロキシするリクエストの `aws:SourceVpc` には、プライベートアクセスエンドポイントをホストしている VPC が設定されます。ブラウザからの直接リクエストに VPC コンテキストが含まれるのは、そのサービスに独自の VPC エンドポイントがある場合に限られます。そのため、使用するすべてのサービスにエンドポイントを設定してください。AWS が条件に使用することを推奨しているのは `aws:SourceVpc` であり、特定の `aws:SourceVpce` の値ではありません。
ネットワーク	自組織のリソースには想定されたネットワークからのみアクセスできる	サインイン RBP と RCP、およびネットワーク境界 RCP	サインインポリシーは、認証前と認証後の両方のステートメントで `aws:SourceIp`、`aws:SourceVpc`、`aws:SourceVpce`、`aws:VpcSourceIp` を使用して、想定外のネットワークからのコンソール認証を拒否します。ネットワーク境界 RCP は、アクセス経路にかかわらず、データリソースに同じネットワーク条件を適用します。

今回のリリースにより、コンソールプライベートアクセスは、サポート対象のサービスコンソールのブラウザトラフィックを VPC エンドポイント経由でルーティングします。対象となるトラフィックは次のとおりです。

認証フロー – サインイン、認証情報の交換、セッショントークンのリクエスト
静的アセット – コンソール UI をレンダリングする JavaScript、CSS、画像
サービスコンソールの API コール – ユーザーがサービスコンソールを操作するときに発生するバックエンドリクエスト

プライベート VPC 内のワークロードからのトラフィックは、パブリックインターネットへの経路を一切使用せずに、3 つのプライベートアクセスエンドポイントを経由します。その流れは次のとおりです (図 1 を参照)。

オペレーターのブラウザが <region>.console.aws.amazon.com をリクエストします。
企業の DNS フォワーダーが、VPC 内に設定された Amazon Route 53 Resolver インバウンドエンドポイントにクエリを転送し、このエンドポイントがトラフィックをコンソールの VPC エンドポイントに転送します。
ブラウザトラフィックは、オンプレミスから Direct Connect (または AWS Site-to-Site VPN) を経由して VPC に到達し、VPC エンドポイントが AWS プライベートネットワーク経由でトラフィックをコンソールサービスにルーティングします。
コンソールサービスは、ブラウザセッションを確立するために、サインインエンドポイント <region>.signin.aws.amazon.com にリダイレクトします。
DNS によって、サインインのドメインがサインインの VPC エンドポイントのプライベート IP アドレスに解決され、ブラウザトラフィックは AWS プライベートネットワーク経由でサインインサービスに送信されます。
認証情報が入力されると、サインインサービスは RBP と RCP に加えて VPC エンドポイントポリシーを評価し、コンソールに戻るようリダイレクトします。
コンソールは VPC エンドポイントポリシーを評価し、コンソール API の VPC エンドポイントから静的コンテンツを読み込みます。また、AWS サービス API を呼び出す際に、アイデンティティとリソースの制限を適用します。
これで、ユーザーはプライベートアクセス経由で AWS マネジメントコンソールにアクセスできるようになります。

Figure 1: Network isolation architecture

図 1: ネットワーク分離アーキテクチャ

AWS マネジメントコンソールプライベートアクセスをパイロット導入する

ここでは、1 つの組織単位 (OU) 内の単一の AWS リージョンを対象に、AWS マネジメントコンソールプライベートアクセスをセットアップする手順の概要を説明します。段階的に展開することをお勧めします。追加のリージョンや OU に拡大する前に、各ステップを検証してください。

完全なソリューションを構築する前に、プライベートアクセスのデプロイの仕組みを検証したい場合は、「テスト環境での開始方法」ガイドを参照してください。このガイドでは、単一の VPC に 3 つのプライベートアクセスエンドポイントと制限の緩いポリシーを設定する最小限の構成を、順を追って説明しています。この記事で後述するデプロイとは別に、実際に動作する環境で試すことができます。ユーザーがコンソールにアクセスする際に、サインインポリシーでユーザーのネットワークロケーションを検証する方法については、「リソースベースのポリシーとリソースコントロールポリシーによるコンソールアクセスの制御」を参照してください。

前提条件

次の前提条件を満たしている必要があります。

AWS Organizations の組織に所属している AWS アカウント。ステップ 6 の RCP の例では、管理アカウントへのアクセスが必要です。
選択した AWS リージョンにある VPC。企業ネットワークからの接続は任意です。VPC へのアクセス手段としては、AWS Direct Connect 接続、AWS Site-to-Site VPN、または VPC 内で直接実行される Amazon WorkSpaces や Amazon EC2 のブラウジング用インスタンスなどのワークロードを使用できます。
AWS CloudTrail が同じリージョンで有効になっており、記録された ConsoleLogin イベントを確認できること。
AWS PrivateLink のインターフェイスエンドポイントと AWS Identity and Access Management (IAM) のポリシー評価に関する知識。

ステップ 1: 現在のコンソールアクセスのベースラインを把握する

変更を加える前に、CloudTrail を使用して、ユーザーが現在どのようにコンソールにアクセスしているかを把握します。代表的な期間 (30 日を推奨します) を対象に eventName = ConsoleLogin を検索し、sourceIPAddress、vpcEndpointId、awsRegion の各フィールドを確認します。ルートユーザー、IAM ユーザー、SAML フェデレーション、AWS IAM Identity Center のうち、どのアイデンティティの種類が使用されているかを特定し、パイロットを実施する OU またはアカウントを決定します。

注: サインインポリシーの設定を誤ると、ユーザーがコンソールからロックアウトされる可能性があります。本番アカウントや共有アカウントでのパイロットは避け、専用のテストアカウントを使用してください。また、アクセス制御の適用を有効にする前に、ブレークグラス (緊急アクセス用) プリンシパルを設定してください (ステップ 6 で説明します)。

ステップ 2: プライベートアクセスの VPC エンドポイントを作成する

選択したリージョンで、エンドポイントをホストする VPC を作成するか、既存の VPC を選択します。次に、その VPC に 3 つのインターフェイス VPC エンドポイントを作成します。

com.amazonaws.<region>.console はコンソール用です。
com.amazonaws.<region>.signin は AWS サインイン用です。
com.amazonaws.<region>.console-static はコンソール専用 API 用です。このエンドポイントは、VPC にインターネットへの経路がない場合にのみ必要です。

ステップ 3: AWS マネジメントコンソールプライベートアクセス用にプライベート DNS を設定する

AWS マネジメントコンソールプライベートアクセスを使用するには、プライベート DNS を設定して、コンソールドメイン (.console.aws.amazon.com、.signin.aws.amazon.com、および関連する静的コンテンツドメイン) が VPC 内にあるインターフェイスエンドポイントのネットワークインターフェイスに解決されるようにする必要があります。

VPC 内のワークロードの場合: VPC 内のワークロードがデフォルトの Amazon Route 53 Resolver を使用している場合、追加の DNS 設定は必要ありません。各インターフェイスエンドポイントの作成時に、プライベート DNS 名のオプションを有効にします (PrivateDnsEnabled = true に設定)。これにより、パブリックのコンソールドメインが、VPC 内にあるエンドポイントのネットワークインターフェイスに自動的に解決されます。カスタム DNS リゾルバーまたはプライベートホストゾーンを使用する場合は、コンソールドメインをエンドポイントアドレスにマッピングするよう明示的に設定する必要があります。詳細については、「プライベートホストゾーンの使用」を参照してください。ドメインの完全なリストと DNS 設定の詳細な手順については、AWS マネジメントコンソールプライベートアクセスに必要なエンドポイントに関するドキュメントを参照してください。
VPC 外のワークロードの場合: AWS Direct Connect や AWS Site-to-Site VPN で接続する企業オフィスなど、VPC の外部からエンドポイントにアクセスするワークロードでは、企業の DNS リゾルバーがこれらのドメインに対してエンドポイントアドレスを返すように設定してください。詳細については、「Route 53 Resolver でマルチアカウント環境の DNS 管理を簡素化する」を参照してください。

ステップ 4: プライベート接続を検証する

VPC 内のワークロードからコンソールにサインインします。コンソールが通常どおり読み込まれるはずです。トラフィックが VPC エンドポイント経由でルーティングされていることを確認するには、コンソールのナビゲーションバーに鍵アイコンが表示されているかを確認します (図 2 を参照)。

図 2: コンソールプライベートアクセス

CloudTrail で、最近の ConsoleLogin イベントの vpcEndpointId フィールドに、いずれかのエンドポイント ID が入力されていることも確認できます。次に示すのは、CloudTrail の ConsoleLogin イベントのスニペットの例で、vpcEndpointId フィールドが含まれています。

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROA3XFRBF23EXAMPLE:john.doe",
    "arn": "arn:aws:sts::123456789012:assumed-role/Admin/john.doe",
    "accountId": "123456789012"
  },
  "eventTime": "2026-07-08T19:15:32Z",
  "eventSource": "signin.amazonaws.com",
  "eventName": "ConsoleLogin",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "10.0.1.47",
  "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...",
  "requestParameters": null,
  "responseElements": {
    "ConsoleLogin": "Success"
  },
  "additionalEventData": {
    "LoginTo": "https://console.aws.amazon.com/console/home",
    "MobileVersion": "No",
    "MFAUsed": "Yes",
    "vpcEndpointId": "vpce-0abc123def456789a"
  },
  "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
  "eventType": "AwsConsoleSignIn",
  "recipientAccountId": "123456789012"
}

AWS マネジメントコンソールが読み込まれない場合は、次の項目を確認してください。

各インターフェイスエンドポイントでプライベート DNS が有効になっている (またはカスタムリゾルバーがエンドポイントアドレスを返す)

プライベート DNS を有効にすると、AWS は、サービスドメイン (例: console.aws.amazon.com) を VPC エンドポイントのプライベート IP アドレスに解決する DNS エントリを自動的に作成します。この設定が無効の場合、ブラウザは引き続きパブリックの AWS エンドポイントにルーティングされ、プライベートアクセスの設定が完全にバイパスされます。

各エンドポイントで PrivateDnsEnabled が有効になっていることを確認します。

aws ec2 describe-vpc-endpoints \
--filters "Name=vpc-endpoint-type,Values=Interface" \
--query "VpcEndpoints[].{Id:VpcEndpointId,Service:ServiceName,PrivateDns:PrivateDnsEnabled}" \
--output table

次に、VPC 内から、ドメインがプライベートアドレスに解決されることを確認します。

nslookup console.aws.amazon.com
nslookup signin.aws.amazon.com

# パブリック IP ではなく、プライベート IP (例: 10.x.x.x) が返されるはずです

いずれのクエリでも、VPC の CIDR 範囲内のプライベート IP アドレスが返されるはずです。Amazon 提供の DNS ではなくカスタム DNS リゾルバーを使用している場合は、転送ルールで AWS ドメインのクエリを VPC 内の Route 53 Resolver インバウンドエンドポイントに転送するよう設定してください。

エンドポイントのセキュリティグループで、ワークロードのサブネットからの HTTPS (TCP 443) が許可されている

各 VPC エンドポイントはサブネット内に Elastic Network Interface (ENI) を作成し、これらの ENI はセキュリティグループによって制御されます。セキュリティグループでワークロードからのインバウンド HTTPS トラフィックが許可されていない場合、接続はエラーが表示されないまま失敗します。

エンドポイントにアタッチされているセキュリティグループを特定します。

aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-0abc123def456789a \
  --query "VpcEndpoints[].Groups[].GroupId" --output text

次に、各セキュリティグループでワークロードのサブネットからのインバウンド TCP 443 が許可されていることを確認します。
```
aws ec2 describe-security-groups --group-ids sg-xxxxxxxx \
  --query "SecurityGroups[].IpPermissions[?ToPort==\`443\`]" \
  --output json
```

VPC の外部からのトラフィック (Direct Connect または Site-to-Site VPN) の場合、企業の DNS がエンドポイントの IP を返し、ルートが正しく伝播されている

AWS Direct Connect または AWS Site-to-Site VPN で接続されたオンプレミスのワークステーションからコンソールにアクセスする場合は、さらに 2 つの条件を満たす必要があります。

1 つ目に、企業の DNS が AWS ドメインを VPC エンドポイントのプライベート IP に解決する必要があります。オンプレミスのマシンから次のコマンドを実行します。
nslookup console.aws.amazon.com

パブリックの AWS IP が返される場合、企業の DNS は Route 53 Resolver 経由でクエリを転送していません。aws.amazon.com と amazonaws.com のドメインについて、Resolver インバウンドエンドポイントの IP への条件付き転送を設定してください。
2 つ目に、ネットワークルートが正しく伝播されている必要があります。戻りのトラフィックがオンプレミスネットワークに到達できるように、エンドポイントのサブネットに関連付けられたルートテーブルに、仮想プライベートゲートウェイ (VGW) またはトランジットゲートウェイからのルートが伝播されていることを確認してください。次のコマンドで確認できます。
```
aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-xxxxx" \
  --query "RouteTables[].PropagatingVgws"
```

簡単なエンドツーエンドの検証: ワークステーションから traceroute console.aws.amazon.com を実行し、経路にプライベートホップのみが含まれ、パブリックインターネットを経由するトラフィックがないことを確認します。

コンソールは読み込まれるが鍵アイコンが表示されない場合

コンソールは読み込まれるものの接続がプライベートになっていない場合 (例えば、鍵アイコンが表示されない場合)、ブラウザは VPC エンドポイントではなく、パブリックインターネット経由でコンソールにアクセスしています。

VPC 内のワークロードから nslookup console.aws.amazon.com を実行します。VPC の CIDR 範囲内のプライベート IP が返されれば正常です。パブリック IP が返される場合は、DNS がエンドポイントをバイパスしています。通常は、インターフェイスエンドポイントでプライベート DNS が有効になっていないことが原因です。この場合は、PrivateDnsEnabled = true に設定してください。
VPC 外のワークロードの場合は、企業の DNS がコンソールドメインのクエリを VPC 内に転送するように設定してください。例えば、Amazon Route 53 Resolver インバウンドエンドポイントを経由して転送できます。

ステップ 5: VPC エンドポイントポリシーを適用する

コンソールと AWS サインインのエンドポイントに、アクセスを組織内のアイデンティティに制限するエンドポイントポリシーをアタッチします。なお、静的コンテンツのエンドポイントはエンドポイントポリシーをサポートしていません。

まず、制限の緩い Allow * ポリシーを使用して、トラフィックがエンドポイント経由でルーティングされていることを確認します (CloudTrail のコンソールイベントで vpcEndpointId フィールドに値が入力されていれば確認できます)。ルーティングを確認できたら、VPC エンドポイントポリシーに制限を追加し、トラフィックを監視します。

初期ポリシーでは 2 つの条件キーを使用します。aws:PrincipalOrgID でアイデンティティを組織内に制限し、aws:ResourceOrgID でコンソールがアクセスできるリソースを組織のリソースに制限します。追加の条件キーやリソース制限のパターンを含む完全なリファレンスについては、AWS マネジメントコンソールプライベートアクセスのユーザーガイドを参照してください。

パイロット以降のポリシーについては、「AWS のデータ境界」を参照してください。また、データ境界ポリシーの例を収録した GitHub リポジトリでは、環境にデータ境界を実装する際のサービス固有の考慮事項を紹介しています。

ステップ 6: サインインポリシーを適用する

サインインポリシーは、ネットワークまたはプリンシパルの条件に一致しないコンソール認証リクエストを拒否します。このポリシーは、signin:Authenticate を対象とする認証前のステートメントと、signin:AuthorizeOAuth2Access および signin:CreateOAuth2Token を対象とする認証後のステートメントで構成されます。必ず両方のステートメントを含めてください。

パイロットでは、AWS Organizations の管理アカウントから、ポリシーを RCP としてデプロイします。RCP を有効にすると組織内のすべてのアカウントに適用されるため、本格的に展開する前に、専用のテスト組織でパイロットを実施することをお勧めします。適用を有効にするには、us-east-1 リージョンで組織を対象に signin:PutConsoleAuthorizationConfiguration API を呼び出します (AWS サインインは、このリージョンからポリシーをグローバルにレプリケートします)。コンソール認可を有効にするまで、リソースのアクセス許可ステートメントは効力を持ちません。

重要: RCP を有効にする前に、ブレークグラス用の経路として、除外プリンシパルを少なくとも 1 つ設定してください。除外プリンシパルには、専用の IAM ロールを使用することをお勧めします。

ネットワーク条件を定義するアクセス許可ステートメントを記述します。
例 – アクセス元を企業 VPC に制限する

aws signin put-resource-permission-statement \
  --source-vpc vpc-0abc123def456789 \
  --requested-region us-west-2 \
  --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \
  --region us-east-1

例 – アクセス元を特定の IP 範囲に制限する

aws signin put-resource-permission-statement \
  --source-ip "IP_ADDRESS" \
  --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \
  --region us-east-1

組織のコンソール認可を有効にして、ポリシーの適用を開始します。

aws signin put-console-authorization-configuration \
  --target-id <your-target-id> \
  --region us-east-1

現在有効になっている統合ポリシーを確認します。
```
aws signin get-resource-policy --region us-east-1
```

ポリシーの例、AWS コマンドラインインターフェイス (AWS CLI) のリファレンス、ロックアウトからの復旧手順については、「AWS マネジメントコンソールへのアクセスを想定するネットワークに制限」のブログ記事と「リソースベースのポリシーによるコンソールアクセスの制御」のドキュメントを参照してください。このドキュメントでは、組織全体の RCP の代わりに、単一のアカウントにアタッチした RBP を使用する、アカウント単位の代替方法についても説明しています。

ステップ 7: サービスの VPC エンドポイントを追加する

ここまでで、コンソールシェルが読み込まれ、鍵アイコンが表示され、サインインポリシーによって承認されたアイデンティティのみがサインインできるようになりました。しかし、AWS Key Management Service (AWS KMS) コンソールなどのサービスコンソールを開くと、リソースの読み込みに失敗したり、ページが応答しなくなったりする場合があります。プライベートアクセスエンドポイントが伝送するのはコンソールシェルのトラフィックであり、コンソールがユーザーに代わって行うサービス API コールは含まれないためです。インターネットゲートウェイのない VPC では、これらの呼び出しがサービスに到達する経路がありません。

そこで、サービス自体の VPC エンドポイントを追加します。パイロットでは、AWS KMS インターフェイスエンドポイント (com.amazonaws.<region>.kms) を同じ VPC に作成し、プライベート DNS を有効にします。VPC 内から AWS KMS コンソールを開き、キーのリストが読み込まれることを確認します。ユーザーが初日から必要とするサービスごとに、この手順を繰り返します。なお、1 つのサービスコンソールが複数の AWS サービス API を呼び出すことはよくあります。コンソールは読み込まれるものの、ページの一部にエラーが表示されたり、空のままになったりする場合、主な原因は、そのコンソールが依存するいずれかのサービスのエンドポイントが不足していることです。

PrivateLink をサポートするサービスの最新のリストは、AWS PrivateLink のドキュメントに記載されています。PrivateLink をサポートしていないサービスのコンソールは、インターネットに接続されていない VPC では機能しないため、別途対処する必要があります。

ステップ 8: 設定していないリージョンとサービスを非表示にする (オプション)

エンドポイントを用意していないサービスやリージョンへのコンソールリンクは、VPC 内では機能しません。ユーザーが機能しないページに移動しないようにするには、User Experience Customization (UXC) を使用して、プライベートアクセスのデプロイに含まれていないリージョンとサービスを非表示にします。UXC はアカウントレベルで設定し、ナビゲーション、検索結果、サービス選択のドロップダウンに適用されます。

ステップ 9: 検証してから拡大する

1 つのパイロットアカウントにエンドポイントポリシーとサインイン RCP を適用したら、次の手順を実行します。

企業ネットワーク内からサインインします。セッションが正常に確立されることを確認します。
企業ネットワーク外からサインインします。コンソールに到達する前に、サインインのステップでセッションが拒否されることを確認します。
CloudTrail で、ネットワーク内からのトラフィックの ConsoleLogin イベントに vpcEndpointId が入力されていることを確認します。
想定外の拒否が発生した場合は、CloudTrail で ConsoleLogin イベントのうち、エラーメッセージに Authorization denied because of a resource-based policy (リソースベースのポリシーにより認可が拒否されました) または Authorization denied because of a resource control policy (リソースコントロールポリシーにより認可が拒否されました) が含まれるものを探し、原因となったステートメントを特定します。

考慮事項

この設計を採用する前に、次の点に注意してください。

AWS IAM Identity Center: IAM Identity Center のサインインは、現時点では VPC エンドポイント経由ではサポートされていません。最初のシングルサインオン (SSO) 認証は、引き続きインターネット経由で行う必要があります。
プログラムによるアクセス: サインイン RBP と RCP が制御するのは、インタラクティブなコンソールサインインです。SigV4 で署名された AWS SDK と AWS CLI のリクエストは影響を受けません。これは復旧経路としても利用できます。コンソール認可の設定を誤った場合でも、signin:DeleteConsoleAuthorizationConfiguration アクセス許可を持つプリンシパルであれば、プログラムによって適用を無効にできます。
AWS サインインと統合されたアプリ: Amazon Connect、Amazon WorkSpaces、Amazon QuickSight、AWS Health Dashboard、Amazon AppStream 2.0、Amazon Lightsail が認証に AWS サインインを使用する場合、サインインポリシーはこれらのアプリケーションにも適用されます。
AWS マネジメントコンソールプライベートアクセスはすべての AWS 商用リージョンで利用できますが、サポートしているのは AWS サービスコンソールの一部のみです。詳細については、「プライベートアクセスでサポートされている AWS リージョン、サービスコンソール、機能」のドキュメントを参照してください。
サポートされていないサービスがあっても、他のコンソールには引き続き移動できます。ただし、サポートされていないサービスコンソールとコンソール専用 API には、インターネット接続が必要です。
コスト: デプロイするエンドポイントとリージョンごとに、通常の AWS PrivateLink エンドポイント料金とデータ処理料金が発生します。対象となる料金項目は、3 つのプライベートアクセスエンドポイント (console、signin、console-static) と、既に使用しているサービスエンドポイントです。

まとめ

この記事では、AWS のデータ境界フレームワークを AWS マネジメントコンソールに拡張する方法を説明しました。AWS マネジメントコンソールプライベートアクセスを使用して、VPC エンドポイント経由でコンソールトラフィックをルーティングし、サインイン RBP と RCP を使用して、ネットワークと組織に基づいてコンソールサインインを制限しました。さらに、インターネットゲートウェイのない VPC でコンソールが動作するように設定しました。これにより、API トラフィックに既に適用している 4 つの統制目的が、コンソールにも適用されるようになります。

使用を開始するには、AWS マネジメントコンソールプライベートアクセスのドキュメントを参照してください。デプロイパターンとリージョンごとの考慮事項については、AWS マネジメントコンソールプライベートアクセスのリファレンスアーキテクチャを参照してください。データ境界の全体像については、「AWS でのデータ境界の確立」を参照してください。

この記事に関するご質問は、AWS re:Post の IAM フォーラムで新しいスレッドを作成するか、AWS サポートにお問い合わせください。

本ブログは Security Solutions Architect の中島章博が翻訳しました。

Amazon Web Services ブログ