AWS PrivateLink で企業ネットワークから AWS Quick へのアクセスを保護する

本記事は 2026 年 10 月 21 日 に公開された「Securing Quick access from corporate networks with AWS PrivateLink」を翻訳したものです。

AWS Quick の AI エージェントやダッシュボードは、ほぼあらゆるデータソースに問い合わせできます。しかし、企業のデータが社内ファイアウォールの内側やプライベートなオンプレミスのデータセンターにある場合、AWS からそこへ直接つながるネットワーク経路はありません。管理者は、機密性の高い企業データをパブリックインターネットにさらさずに、AI による分析やアクションに利用できるようにする必要があります。

多くの企業にとって、パブリックインターネット経由でトラフィックを流すことは許容できないリスクです。HIPAA、FedRAMP、PCI-DSS などの規制の枠組みでは、機密データを管理されたネットワーク境界の中にとどめるよう求められることがよくあります。コンプライアンスが主な理由でない場合でも、社内のデータ経路を外部にさらすと攻撃対象領域が広がり、監査証跡が複雑になります。レイテンシーも不安定になり、ユーザー体験が悪くなるおそれがあります。

本記事では、トラフィックがパブリックインターネットを通らないように、オンプレミスのデータソースを Quick にプライベートに接続する手順を説明します。前提として、オンプレミス環境と Amazon Virtual Private Cloud (Amazon VPC) が AWS Direct Connect または AWS Site-to-Site VPN ですでにつながっているものとします。その上に AWS PrivateLink による VPC エンドポイントを構成し、Quick が AWS のバックボーンを通じてプライベートなリソースに到達できるようにします。さらに、多層防御としてセキュリティグループと VPC エンドポイントポリシーを重ねます。

最終的に、Quick とオンプレミスのデータソースの間のトラフィックがパブリックインターネットを通らないネットワークアーキテクチャができあがります。攻撃対象領域を減らし、低レイテンシーで安定した接続を実現し、コンプライアンスのための明確な監査証跡も得られます。

AWS Quick とプライベートネットワーク接続の確立

Quick は、検索、分析、調査、自動化を 1 つの対話型の体験にまとめた、AI を活用したワークスペースです。以降で説明するアーキテクチャは、どのコンポーネントがどのようにプライベートネットワークに到達するかによって決まります。

Quick のデータアクセスには 2 つの経路があります。ユーザー向けのトラフィックは、Quick コンソールを開く、ダッシュボードを操作する、API を呼び出す、Quick Desktop を利用するといった操作によるトラフィックです。こうしたトラフィックはすべて VPC エンドポイントを経由するため (「ユーザーアクセスと API アクセス用の VPC エンドポイント」を参照)、ユーザーのセッションはパブリックインターネットを通りません。

データ取得のトラフィックは、Quick 自身がネットワークに入ってデータを取得するときのトラフィックです。このトラフィックは VPC 接続が処理します (「データソースアクセス用の VPC 接続」を参照)。アーキテクチャ上の判断が必要になるのは、主にこの経路です。データ取得の接続を開始する機能と統合は次のとおりです。

• AWS Quick Sight は、VPC 内に配置した Elastic Network Interface (ENI) を通じて、オンプレミスのデータベース (PostgreSQL、MySQL、SQL Server、Oracle など) に直接クエリを実行します。VPC 接続を最も多く利用するのが Quick Sight です。
• Quick Flows と Quick Automate は、それぞれ別の自動化機能です。Flows は繰り返しのタスクを処理し、Automate は人の確認を挟む (human-in-the-loop)、複数のシステムにまたがる複雑なオーケストレーションを処理します。どちらもアクションコネクタを呼び出し、その中には VPC 内でプライベートにホストされている Model Context Protocol (MCP) サーバーも含まれます。社内 API を呼び出すワークフローは、すべてこの経路を通ります。
• Quick Agents はすべての対話的な操作の土台であり、アクションコネクタを直接呼び出せます。カスタムエージェントがプライベートにホストされた MCP サーバーや社内 API を呼び出すと、トラフィックは VPC 接続を通ります。
• Quick Index は、Confluence、SharePoint、Amazon Simple Storage Service (Amazon S3) などの接続済みソースをまたぐ統合された検索レイヤーを作ります。VPC 内やオンプレミスにあるデータについて、ナレッジベースの VPC 接続が現在サポートしているのは Amazon Redshift のみです。Confluence、SharePoint、Box、Google Drive、OneDrive、Amazon S3 などのソースは、現時点では Quick の VPC 接続を利用できません (「Supported VPC data sources」を参照)。なお、バケットポリシーで Amazon S3 バケットへのアクセスを VPC エンドポイントに制限することはできますが、これは VPC 接続とは別の仕組みです。
• Quick Research は、出典付きのレポートを作るために、パブリックインターネットのデータとあわせてファイアウォールの内側にある企業のソースにもアクセスします。プライベートなソースにアクセスするときは VPC 接続を利用します。
• Quick のアプリは、構造化データとアクションコネクタの上にインタラクティブな Web アプリケーションを作ります。Quick Sight や Flows と同じ VPC 接続を引き継ぎます。
• Quick のスペースは、ここまでの機能のコンテンツを整理するもので、独自にデータ接続を開始することはありません。

2 つのトラフィック経路には、それぞれ別のプライベート接続の仕組みが必要で、両者は連携して動きます。

• VPC エンドポイント (AWS PrivateLink): Quick の Web サイトへのアクセス、API 呼び出し、管理アクセスなど、ユーザー向けのトラフィックを処理します。ユーザーのトラフィックがパブリックインターネットを通らないようにします。
• VPC 接続: データソースのトラフィックを処理します。Quick は VPC (さらにその先のオンプレミスネットワーク) に入り、データベース、Amazon Redshift のナレッジベースのソース、社内 API からデータを取得します。VPC 接続は Quick コンソールで設定します。

プライベート接続を設定する

このセクションでは、4 つの構成要素を順に説明します。ユーザーアクセスと API アクセス用の VPC エンドポイント、データソースアクセス用の VPC 接続、AWS のデータサービス用の VPC エンドポイント、必要な外部ドメインへのアウトバウンドアクセスです。

前提条件

Quick のプライベート接続を設定する前に、次のものがそろっていることを確認してください。

• Quick Enterprise サブスクリプションがある有効な AWS アカウント (VPC 接続には Enterprise エディションが必要です)。
• Quick をデプロイした AWS リージョンにある既存の VPC。
• サポートされている AWS リージョン。Quick の Web サイト用 VPC エンドポイントは、AWS 中国リージョンと AWS GovCloud (US) リージョンでは利用できません。
• オンプレミスネットワークと VPC の間に確立した AWS Direct Connect 接続または Site-to-Site VPN。データセンターから AWS へトラフィックを運ぶプライベートな経路です。
• VPC エンドポイントとセキュリティグループの作成・管理、および Quick の管理に必要な AWS Identity and Access Management (IAM) 権限。VPC 接続を作成するには、管理者の IAM アイデンティティに quicksight:CreateVPCConnection、quicksight:DescribeVPCConnection、quicksight:ListVPCConnections、quicksight:UpdateVPCConnection、quicksight:DeleteVPCConnection、ec2:DescribeSubnets、ec2:DescribeVpcs、ec2:DescribeSecurityGroups、iam:ListRoles と、VPC 接続の実行ロールに範囲を絞った iam:PassRole も必要です。
• 組織の DNS 管理（Amazon Route 53 のプライベートホストゾーンまたはオンプレミスの DNS フォワーダー）へのアクセス。プライベート DNS の名前解決によって、トラフィックはパブリックアドレスではなく VPC エンドポイントを通るようになります。

ユーザーアクセスと API アクセス用の VPC エンドポイント (AWS PrivateLink)

PrivateLink による VPC エンドポイントは、Web サイト、API 呼び出し、埋め込みコンテンツなど、Quick へのユーザー向けトラフィックをすべて処理します。ユーザーはパブリックインターネットを通らずに Quick コンソールにアクセスできます。

図 1: VPC エンドポイントを通じた、企業のデータセンターから Quick へのプライベートアクセス

図 1 の流れは次のとおりです。(1) 社内ネットワークのクライアントが Quick にリクエストを送ります。(2) リクエストは AWS Direct Connect を通り、Direct Connect ゲートウェイを経由して VPC に入ります。(3) Quick の VPC エンドポイントがエンドポイントポリシーを評価し、リクエストを許可または拒否します。(4) 許可されたリクエストは AWS のネットワークを通って Quick に届きます。

VPC エンドポイントのアーキテクチャを計画する

エンドポイントのアーキテクチャを計画するときは、まず Quick アカウントをデプロイした AWS リージョンを確認します。VPC エンドポイントは同じリージョンに置く必要があるからです。エンドポイントの ENI を配置するサブネットは複数のアベイラビリティーゾーンから選び、そのサブネットから Direct Connect または VPN を通じてオンプレミスネットワークへのルートがあることを確認します。

エンドポイントの ENI のトラフィックを、必要なポートと送信元の範囲のみに制限するセキュリティグループを設計します。Quick が Amazon S3、Amazon Redshift、Amazon Athena に対して行う呼び出しも含め、すべてのトラフィックをプライベートに流したい場合は、それらのサービスの VPC エンドポイントも計画します (「データソース用の VPC エンドポイントを設定する」を参照)。

Quick の VPC エンドポイントを作成する

Quick へ完全にプライベートにアクセスするには、2 つのインターフェイス VPC エンドポイントが必要です。

• Web サイトアクセス用エンドポイント – サービス名は com.amazonaws.<region>.quicksight-website です。Quick コンソールへのユーザートラフィックの大部分を処理します。Quick の Web サイトのプライベート DNS 名はパブリック URL と異なるため、VPC エンドポイントを指す <region>.quicksight.aws.amazon.com の A レコードを作成する必要があります。
• API アクセス用エンドポイント – サービス名は com.amazonaws.<region>.quicksight です。プログラムからの API 呼び出しを処理します。プライベート DNS を有効にすると、quicksight.<region>.amazonaws.com への既存の API 呼び出しは、DNS の追加設定なしで自動的に VPC エンドポイントを通ります。FIPS に準拠する必要がある場合は、com.amazonaws.<region>.quicksight-fips を利用します。

注: 次の 13 個の Quick の API は、API 用 VPC エンドポイントの対象外です。アクションコネクタの API (CreateActionConnector、DeleteActionConnector、DescribeActionConnector、DescribeActionConnectorPermissions、ListActionConnectors、SearchActionConnectors、UpdateActionConnector、UpdateActionConnectorPermissions) と、フローの API (GetFlowMetadata、GetFlowPermissions、ListFlows、SearchFlows、UpdateFlowPermissions) です。アクションコネクタやフローをプログラムで管理する自動化には、パブリック API エンドポイントへの経路が必要です。「Quick and interface VPC endpoints」を参照してください。

管理者が VPC を通じて IAM ユーザーとして Quick にサインインする場合は、AWS マネジメントコンソール用のエンドポイントも作成します。

• com.amazonaws.<region>.console
• com.amazonaws.<region>.signin

Amazon Virtual Private Cloud (Amazon VPC) コンソールで Web サイト用エンドポイントを作成する手順は次のとおりです。

1. Amazon VPC コンソールを開きます。ナビゲーションペインの PrivateLink and Lattice で Endpoints を選択し、Create endpoint を選択します。
2. Name tag (例: my-quicksight-vpc-endpoint) を入力し、Type で AWS services を選択します。
3. Services で com.amazonaws.<region>.quicksight を検索し、com.amazonaws.<region>.quicksight-website を選択します (図 2)。

図 2: エンドポイントに名前を付け、Quick の Web サイト用エンドポイントサービスを選択する

4. Network settings で VPC を選択します。Additional settings で Enable private DNS name を選択したままにします。
5. 2 つ以上のアベイラビリティーゾーンのサブネットを選択し、エンドポイントの ENI 用のセキュリティグループを選択します (図 3)。

図 3: エンドポイントの VPC、プライベート DNS、サブネット、セキュリティグループを選択する

6. Policy を選択し (後述の「VPC エンドポイントポリシーを設定する」を参照)、タグを追加して、Create endpoint を選択します (図 4)。

図 4: エンドポイントポリシーを選択してエンドポイントを作成する

7. API 用エンドポイント com.amazonaws.<region>.quicksight についても、同じ手順を繰り返します。

DNS の名前解決を設定する

Web サイト用エンドポイントについては、<region>.quicksight.aws.amazon.com の A レコードを作成し、VPC エンドポイントの DNS 名を指すようにします。こうしておくと、社内ネットワークのユーザーが Quick の URL を名前解決したときに、トラフィックはパブリックインターネットではなくプライベートエンドポイントを通ります。API 用エンドポイントについては、VPC エンドポイントでプライベート DNS を有効にするだけで十分です。API 呼び出しは自動的にエンドポイントのプライベート IP アドレスに解決されます。

Route 53 プライベートホストゾーンが応答するのは、関連付けた VPC の内側からのクエリのみです。ユーザーは社内ネットワークから接続するため、オンプレミスの DNS サーバーで、<region>.quicksight.aws.amazon.com へのクエリを VPC 内の Route 53 Resolver インバウンドエンドポイントに転送するよう設定します (または、同じ内容のレコードをオンプレミスの DNS でホストします)。最後に、社内ネットワークから DNS の名前解決を確認し、リクエストがパブリックアドレスではなく VPC 内のプライベート IP に解決されることを確かめます。

Route 53 でレコードを作成する手順は次のとおりです。

1. Route 53 コンソールで Hosted zones を選択し、Create hosted zone を選択します。
2. Domain name に <region>.quicksight.aws.amazon.com (例: us-east-1.quicksight.aws.amazon.com) を入力します。ゾーンの範囲をリージョンに絞ることで、Quick の他のホスト名を上書きせずに済みます。Private hosted zone を選択し、VPC を関連付けて、Create hosted zone を選択します (図 5)。

図 5: Amazon Route 53 でプライベートホストゾーンを作成する

3. 作成したホストゾーンで Create record を選択します (図 6)。

図 6: 作成したプライベートホストゾーンでレコードを作成する

4. Record name は空欄のままにし、レコードタイプに A を選択します。Alias をオンにして Alias to VPC endpoint を選択し、リージョンと Web サイト用エンドポイントの DNS 名を選択して、Create records を選択します (図 7)。

図 7: Quick の Web サイト用 VPC エンドポイントを指すエイリアス A レコードを作成する

VPC エンドポイントポリシーを設定する

VPC エンドポイントポリシーでは、エンドポイントを利用できるアカウントや組織を制限します。Quick の場合、ポリシーの範囲は AWS アカウント ID または組織 ID で絞り込めます。ポリシーを変更するには、Amazon VPC コンソールでエンドポイントを開き、Policy タブを選択して Edit Policy を選択します (図 8)。

重要な制限: Quick の Web サイト用エンドポイントでは、Principal、Action、Resource のフィールドをすべて * に設定する必要があります。条件は aws:PrincipalAccount 属性または aws:OrgId 属性に対してのみ指定できます。アクション単位で絞り込む、より厳しいポリシーは API 用エンドポイントでのみサポートされています。

Web サイト用エンドポイントのポリシーの例:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalAccount": ["012345678901"]
                }
            }
        }
    ]
}

図 8: VPC エンドポイントの詳細ページからエンドポイントポリシーを開く

API 用エンドポイントのポリシーの例 (特定のアクションに制限):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "quicksight:DescribeUser",
                "quicksight:ListUsers"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalAccount": ["012345678901"]
                }
            }
        }
    ]
}

図 9: カスタムの VPC エンドポイントポリシーを編集する

データソースアクセス用の VPC 接続

VPC エンドポイントがユーザー向けのトラフィックを処理するのに対し、VPC 接続はサーバー側の経路を処理します。つまり、Quick が VPC に入り、データベース、Amazon Redshift のナレッジベースのソース、社内 API にアクセスする経路です。

VPC 接続の仕組み

Quick Enterprise エディションは Amazon VPC と完全に統合されています。Quick で VPC 接続を作成すると、VPC のサブネットに ENI が追加されます。Quick はこの ENI を通じて VPC 内のリソースとネットワークトラフィックを送受信します。さらに、Direct Connect や VPN でつながったオンプレミスのシステムなど、その VPC から到達できる宛先すべてと通信できます。

このトラフィックには、VPC の標準的なセキュリティ制御がすべて適用されます。ルートテーブル、ネットワーク ACL、サブネット、セキュリティグループは、VPC 内の他のインスタンス間のトラフィックと同じように、Quick との間のトラフィックも制御します。そのため、Quick から次のものに接続できます。

• パブリックインターネットに公開していないプライベートなデータベース
• Direct Connect または VPN で到達できるオンプレミスのデータソース
• ネットワーク内で IP アドレスによってアクセスできる社内 API

VPC 接続の ENI 用に専用のセキュリティグループ (例: QuickSight-VPC) を作成します。各データソースのセキュリティグループでは、そのセキュリティグループ ID からのデータベースポートへのインバウンドトラフィックを許可します。

2023 年 4 月 27 日より前に作成した VPC 接続についての注意: Quick のネットワークインターフェイスに付けたセキュリティグループはステートフルではありません。戻りのパケットはランダムに割り当てられた宛先ポートを使用するため、データソースのセキュリティグループからの戻りトラフィックを全ポート (0–65535) で明示的に許可するインバウンドルールを追加する必要があります。この日以降に作成した接続は、標準的なステートフルの動作になります。「Security groups: inbound and outbound rules」を参照してください。

実行ロールを作成する

Quick は VPC 接続の実行ロールを自動では作成しません。接続を追加する前に、専用の IAM ロールを作成する (推奨) か、Quick をすでに信頼している既存のロールを更新します。既存のロールの例が、本記事のスクリーンショットで使用している aws-quicksight-service-role-v0 です。ロールには次のものが必要です。

• Quick が ENI を管理するために使用する Amazon Elastic Compute Cloud (Amazon EC2) のアクションを許可するアクセス許可ポリシー (図 10)。
• quicksight.amazonaws.com がロールを引き受けることを許可する信頼ポリシー。Quick コンソールの Execution role の一覧に表示されるのは、この信頼ポリシーを持つロールのみです。

アクセス許可ポリシー:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateNetworkInterface",
                "ec2:DeleteNetworkInterface",
                "ec2:ModifyNetworkInterfaceAttribute",
                "ec2:DescribeSubnets",
                "ec2:DescribeSecurityGroups"
            ],
            "Resource": "*"
        }
    ]
}

図 10: VPC 接続の実行ロールに必要な Amazon EC2 の権限を追加する

信頼ポリシー:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": { "Service": "quicksight.amazonaws.com" },
            "Action": "sts:AssumeRole"
        }
    ]
}

VPC 接続を設定する

Quick コンソールで VPC 接続を作成する手順は次のとおりです。

1. 管理者として Quick にサインインします。右上のプロフィールアイコンを選択し、Manage account を選択します (図 11)。この項目が表示されない場合は、Quick の管理者権限がありません。

図 11: Quick のプロフィールメニューから Manage account を開く

2. ナビゲーションペインの Security で Manage VPC connections を選択し (図 12)、Add VPC connection を選択します。

図 12: Manage account ページの Security にある Manage VPC connections

3. 次の項目を入力します (図 13)。
   1. 内容が分かる VPC connection name
   2. 接続先 VPC の VPC ID (後から変更できません)
   3. 前の手順で作成した Execution role
   4. 異なるアベイラビリティーゾーンにある 2 つ以上のサブネット
   5. 1 つ以上のセキュリティグループ ID
   6. (オプション) データベースのホスト名をプライベート DNS で解決する必要がある場合は、DNS resolver endpoints に Route 53 Resolver インバウンドエンドポイントの IP アドレスを入力します。
4. ADD を選択します。

図 13: Quick コンソールで VPC 接続を追加する

接続のステータスは、Quick が ENI のプロビジョニングを終えるまで UNAVAILABLE と表示され、終わると AVAILABLE に変わります。PARTIALLY AVAILABLE は ENI の 1 つが利用できない状態を表しますが、接続は引き続き利用できます。

データソース用の VPC エンドポイントを設定する

VPC エンドポイント (PrivateLink。ここでは AWS のサービス API に使用します) と VPC 接続 (VPC 内に配置する Quick の ENI。「データソースアクセス用の VPC 接続」を参照) は別の仕組みです。Quick は、ダッシュボードや分析のデータを取得するときに、他の AWS のサービス (Amazon S3、Amazon Redshift、Amazon Athena、AWS Secrets Manager) にアクセスします。Quick がこうした AWS のサービスに対して行う呼び出しも含め、すべてのトラフィックをプライベートにとどめたい場合は、サービスごとにインターフェイス VPC エンドポイントまたはゲートウェイ VPC エンドポイントを作成します。

* Athena は VPC 接続のデータソースとしてはサポートされていません。Athena のエンドポイントは、Athena の API トラフィックを AWS PrivateLink 上にとどめるだけです。

データソース用のエンドポイントは、Quick の ENI を配置したのと同じ VPC に作成します。ルートテーブルとセキュリティグループで、Quick のサブネットとエンドポイントのサブネットの間のトラフィックが許可されていることを確認してください。

必要な外部ドメインへのアクセスを許可する

Quick とオンプレミスのソースの間のデータトラフィックはプライベートネットワーク上にとどまりますが、ユーザーのブラウザは、サインイン、静的アセット、クライアント側のメトリクス、統合のために、いくつかのドメインに到達する必要があります。VPC エンドポイントを設定していても、VPC エンドポイントに対応していないドメインにはアウトバウンド接続が必要です。通常は社内のプロキシやファイアウォールを経由します。アカウントで AWS IAM Identity Center を利用している場合、ブラウザでのサインインには、パブリックな AWS サインインエンドポイントと IAM Identity Center エンドポイントも必要です (「ユーザーアクセスとID フェデレーションのセキュリティ」を参照)。

必要な外部ドメイン

出典: Domains accessed by Quick

設定のポイント:

• VPC エンドポイントに対応しているドメイン (Quick の Web サイトと API、signin.aws.amazon.com、Amazon S3) については、対応する VPC エンドポイントと DNS レコードを作成します。
• VPC エンドポイントに対応していないドメインについては、社内のインターネットへの出口 (アウトバウンドプロキシまたはファイアウォール) で許可します。ユーザーのトラフィックが VPC から外に出る構成の場合は、パブリックサブネットの NAT ゲートウェイを利用します。
• セキュリティポリシー上 URL 単位のフィルタリングが必要な場合は、アウトバウンドプロキシか AWS Network Firewall のドメインフィルタリングルールを利用し、前述のドメインのみを許可します。
• 社内の端末 (または同じ出口経路にあるインスタンス) からテストします。各ドメインに対して nslookup と curl を実行し、DNS の名前解決とルーティングを確認します。

VPC エンドポイントによるアクセス制限を適用する

エンドポイントを設定してテストしたら、Quick アカウントへのアクセスをすべて VPC エンドポイント経由に限定し、インターネットからのアクセスを完全にブロックできます。その結果、ユーザーが Quick にアクセスできるのは、社内ネットワークから構築したプライベートな経路を通る場合に限られます。

Quick には、アカウントへのアクセスを事前に定義した IP 範囲、VPC ID、VPC エンドポイント ID の一覧に限定する、IP と VPC エンドポイントの制限機能があります。たとえば、Direct Connect で利用する VPC エンドポイントからのアクセスのみを許可するルールを作成すると、パブリックインターネットから Quick にアクセスしようとする人はすべて拒否されます。

Quick コンソールで設定する手順は次のとおりです (制限のページにアクセスできるのは、IAM 認証情報でサインインした管理者のみです)。

1. プロフィールアイコンを選択し、Manage account を選択します。Security で Manage IP/VPC restrictions を選択します。
2. Restriction フィールドに VPC エンドポイント ID (例: vpce-001122def) を入力し、Description を入力して Add を選択します (図 14)。
3. Save changes を選択してルールを適用します。
4. Enforce restrictions をオンにします。

図 14: IP と VPC エンドポイントの制限のページで VPC エンドポイントのルールを追加する

AWS Command Line Interface (AWS CLI) で設定することもできます。

aws quicksight update-ip-restriction \
--aws-account-id ACCOUNT_ID \
--region REGION \
--enabled \
--vpc-endpoint-id-restriction-rule-map \
vpce-001122def=CorporateVpcEndpoint

注: UpdateIpRestriction はルールのマップ全体を置き換えます。aws quicksight describe-ip-restriction で現在のルールを取得し、既存のルールも含めて更新してください。

主な考慮事項:

• IP と VPC エンドポイントのルールは、Quick の Web、埋め込み、モバイルからのアクセスに適用されます。パブリック API へのアクセスは制限しません。特定の送信元からの API 呼び出しを制限するには、aws:SourceIp または aws:SourceVpce の条件を付けた IAM ポリシーを利用します。
• 制限を有効にする前に、自分の IP または VPC エンドポイントがルールに含まれていることを確認してください。含まれていないと、自分自身が締め出されます。
• ルールが完全に反映されるまで、最大 10 分かかることがあります。
• IP のルールと VPC エンドポイントのルールは組み合わせられます。その場合、どちらかのルールを満たせばトラフィックは許可されます。IP と VPC エンドポイントのルールは合わせて最大 100 個まで追加できます。
• IP と VPC エンドポイントのルールはアカウントのすべての AWS リージョンに適用されますが、追加や管理ができるのは Quick アカウントを作成した AWS リージョンからのみです。
• パブリックに埋め込んだダッシュボードがある場合、制限を有効にすると、そのダッシュボードには VPC エンドポイント経由でしかアクセスできなくなります。

制限を適用すると、Quick アカウントに到達できるのは、指定した VPC エンドポイント (または許可した IP 範囲) を経由したトラフィックに限られます。それ以外のアクセスはすべて拒否されます。

ユーザーアクセスとID フェデレーションのセキュリティ

プライベートネットワーク接続でトラフィックはパブリックインターネットを通らなくなりますが、Quick の中で誰が何にアクセスできるかは、ID とアクセス権の設定で別に制御する必要があります。このセクションでは、社内の ID プロバイダーとの統合、ユーザーのプロビジョニングの制御、Quick のコンポーネント全体での細かいアクセスの分離について説明します。

AWS IAM Identity Center と統合する

重要: IAM Identity Center と統合した Quick アカウントでは、ブラウザでの認証にパブリックな AWS サインインエンドポイントと IAM Identity Center エンドポイントへのアクセスが必要です。VPC エンドポイントは、このブラウザでのサインインの経路を提供しません。パブリック IP アドレスは不要です。NAT ゲートウェイかプロキシでアウトバウンド接続を用意してください。IAM Identity Center ユーザーガイドの「Considerations for private access」を参照してください。

Quick は、従業員のアイデンティティ管理の中心として AWS IAM Identity Center を利用します。IAM Identity Center は、既存の社内 ID プロバイダー (IdP) に接続し、認証には SAML 2.0 を、ユーザーとグループの自動プロビジョニングには SCIM 2.0 を利用します。IAM Identity Center と統合すると、次のことができます。

• IdP と同期したユーザーの自動プロビジョニングと自動プロビジョニング解除
• グループメンバーシップの同期 – ユーザーをグループに追加したりグループから外したりすると、その変更が Quick に反映されます
• 既存の社内の認証情報を利用したシングルサインオン (SSO)
• IAM ロールを引き受けることによる一時的な認証情報 – Quick 専用の長期間有効なパスワードは不要です

ID プロバイダーと IAM Identity Center を設定する詳しい手順は、「Getting started with IAM Identity Center」を参照してください。

Quick のロールベースのアクセス

Quick には、ユーザーができることを決める 3 つの基本ロールがあります。

• Admin – データソースの設定、VPC 接続、セキュリティ設定、ユーザー管理、SPICE 容量の購入など、すべての管理操作ができます。
• Author – ダッシュボードの作成と公開、エージェントの作成、スペースの設定、データソースの管理、フローの作成、アプリの作成ができます。
• Reader – 公開されたダッシュボードの閲覧、エージェントとの対話、アクセスを許可されたスペースの利用、Quick Research のレポートの閲覧ができます。

3 つのロールは、フェデレーションユーザーがサインイン時に引き受ける IAM ロールに対応付けられています。IdP でロールの割り当てを管理することで、誰がどのレベルのアクセス権を持つかを 1 か所で管理できます。

さらに Quick では、アカウント、ロール、ユーザーの各レベルでデフォルトのロールの権限を上書きする、カスタムの権限プロファイルを利用できます。ユーザーレベルの権限はロールレベルの権限より優先され、ロールレベルの権限はアカウントレベルの権限より優先されます。管理者は 3 つの基本ロールよりも細かく権限を制御できます。

スペースによるユーザーの分離

スペースを利用すると、ロールとは別に、スペースの単位でもアクセスを分離できます。スペースごとに特定のユーザーとグループの権限を設定できるため、たとえば次のようにできます。

• 機密性の高い収益のダッシュボードや財務のナレッジベースを含む財務チームのスペースには、財務グループのみがアクセスできる。
• CRM に接続したエージェントやパイプラインのダッシュボードがある営業チームのスペースは、営業のユーザーに限定する。
• 部門横断のスペースは、適切な権限を付けて複数のグループで共有する。

スペースへのアクセスは ID プロバイダーから同期したグループで制御します。そのため、新しいメンバーを適切なグループに追加すると、関連するスペースへのアクセス権が自動的に付与されます。

AWS Quick Sight の行レベルセキュリティ

構造化データに基づくダッシュボードでは、Quick Sight の行レベルセキュリティ (RLS) を利用して、ユーザーやグループごとに見られるデータの行を制限できます。RLS はデータセットのルールで設定します。ルールは、ユーザーやグループと、アクセスできるフィールドの値を対応付ける権限用のデータセットです。

たとえば、地域別の営業ダッシュボードを次のように設定できます。

• EMEA の営業グループには、region = 'EMEA' の行のみが表示される。
• NA の営業グループには、region = 'NA' の行のみが表示される。
• 営業担当バイスプレジデントには、すべての行が表示される。

RLS のルールは、IAM Identity Center が決めたユーザーのアイデンティティに基づいて評価されます。つまり、サインインを制御するのと同じID フェデレーションが、データレベルのアクセスも制御します。RLS は従来のダッシュボードの表示にも、AI による自然言語のクエリにも同じように適用されます。AI が回答を生成するときに参照できるデータも、同じセキュリティポリシーで制限されます。

列レベルセキュリティ

Quick Sight は、行レベルの制限に加えて、特定のユーザーやグループから機密性の高い列を隠す列レベルセキュリティ (CLS) もサポートしています。たとえば、従業員の情報を含むデータセットで、給与と SSN (社会保障番号) の列は HR グループのみに見せ、他のグループには同じデータセットの機密でない列のみを見せる、といった制限ができます。

アイデンティティとプライベート接続の関係

アイデンティティのレイヤーとネットワークのレイヤーは、次のように連携します。

1. 社内ネットワークのユーザーが、IdP → IAM Identity Center → Quick の順に認証を受けます。
2. ユーザーのリクエストは、VPC エンドポイント (プライベートネットワークの経路。「ユーザーアクセスと API アクセス用の VPC エンドポイント」を参照) を通って Quick に届きます。
3. Quick はユーザーのアイデンティティを評価し、ロール、スペースへのアクセス、RLS/CLS のポリシーを決めます。
4. Quick がオンプレミスのソースからデータを取得するときは、VPC 接続 (VPC 内の ENI。「データソースアクセス用の VPC 接続」を参照) を利用し、Direct Connect を通じてデータベースに到達します。
5. レスポンスは、同じプライベートな経路を通ってユーザーに返されます。

「必要な外部ドメインへのアクセスを許可する」で説明したサインインと静的アセットのトラフィックを除き、パブリックインターネットを通るトラフィックはありません。どの時点でも、ユーザーが何を見て何をできるかはユーザーのアイデンティティで決まります。

検証とテスト

本番環境で制限を適用する前に、アクセスのパターンごとにエンドツーエンドの接続を検証します。

モニタリング

継続的に可視化するには、すべてのエンドポイントと VPC 接続の ENI で VPC フローログを有効にし、トラフィックのメタデータを記録します。VPC エンドポイントの Amazon CloudWatch メトリクス (ActiveConnections、BytesProcessed、PacketsDropped) を監視し、接続の失敗や想定外の送信元からのトラフィックにアラームを設定します。フローログは、コンプライアンスの文書で参照する監査証跡にもなります。

よくある問題のトラブルシューティング

セキュリティのベストプラクティス

ネットワークの分離もアイデンティティの制御も、それだけでは十分ではありません。このアーキテクチャでは両方を組み合わせます。ネットワークの制御は許可されていないアクセス経路を防ぎ、アイデンティティの制御は許可されたセッションの中での許可されていないデータアクセスを防ぎます。次のプラクティスで、両方のレイヤーを維持します。

• 最小権限のエンドポイントポリシー: Web サイト用エンドポイントは aws:PrincipalAccount または aws:OrgId で制限します。API 用エンドポイントでは、quicksight:* のすべてのアクションを許可するのではなく、自動化に必要な特定のアクションのみにポリシーの範囲を絞ります。
• 多層のセキュリティグループ: VPC エンドポイントの ENI (ユーザーのトラフィック) と VPC 接続の ENI (データのトラフィック) の両方にセキュリティグループを適用します。エンドポイントの ENI では、インバウンド HTTPS を社内の CIDR 範囲に制限します。VPC 接続の ENI では、専用のセキュリティグループを利用し、アウトバウンドを Quick が必要とするデータベースのポートと宛先のみに制限して、各データソースのインバウンドルールでそのセキュリティグループを参照します。
• すべてのエンドポイントの ENI で VPC フローログを有効にする: フローログは、セキュリティの監視、異常の検出、コンプライアンスの監査のためにトラフィックのメタデータを記録します。管理されたネットワーク境界について規制の枠組みが求める監査証跡にもなります。
• エンドポイントポリシーを定期的に監査する: エンドポイントポリシーを四半期ごとに見直します。AWS Config ルールを利用して、ベースラインの構成からのずれを検出します。
• 機密度に応じて VPC 接続を分ける: 複数のデータ環境 (開発、ステージング、本番) がある場合は、セキュリティグループを分けた別々の VPC 接続を作成し、環境をまたいだアクセスを防ぎます。
• CloudWatch で監視する: PacketsDropped と ActiveConnections のメトリクスにアラームを設定します。通常と異なるパターンは、設定ミスや不正アクセスの試みを示している可能性があります。

要件と AWS の構成の例

次の例は、本記事の構成で一般的なネットワークセキュリティの要件にどう対応できるかを示したものです。自社の要件に照らした評価は、セキュリティチームと一緒に行ってください。

コストの考慮事項

訳注: 料金はリージョンによって異なります。最新の料金は AWS PrivateLink の料金 と Amazon VPC の料金 を参照してください。

コスト最適化のヒント:

• S3 には、できるだけインターフェイスエンドポイントではなくゲートウェイエンドポイント (追加料金なし) を利用します。
• エンドポイントの ENI をまとめます。各エンドポイントに必要な ENI は、Quick の VPC 接続のサブネットがある AZ の分だけです。
• VPC フローログは、VPC 全体ではなくエンドポイントの ENI に絞って有効にします。
• すべての外部ドメインに NAT ゲートウェイ経由のアクセスが必要か、それともトラフィックのパターンによっては対象を絞ったプロキシのほうが費用対効果が高いかを検討します。

まとめ

このアーキテクチャでは、互いに補い合う 4 つの制御を構築します。VPC エンドポイントでユーザーのトラフィックをプライベートに保ち、VPC 接続で Quick からデータソースへのプライベートな経路を用意し、ID フェデレーションで誰が何にアクセスできるかを決め、VPC エンドポイントによるアクセス制限でプライベートな経路の利用を必須にします。各レイヤーは個別に監査でき、特定のコンプライアンス要件に対応付けられます (「要件と AWS の構成の例」を参照)。

この構成により、Quick Agents はオンプレミスのデータベースに問い合わせ、Quick Research はファイアウォールの内側にある企業のソースを調べ、Quick Sight のダッシュボードは機密データを可視化し、Quick Flows は社内システムをオーケストレーションできます。しかも、データはパブリックインターネットを通りません。AI の機能はそのままに、外部へさらされるリスクのみを取り除けます。

実装するときは、まずユーザーアクセスと API アクセス用の VPC エンドポイントから開始し、ユーザーのアクセスを検証してから、データソースアクセス用の VPC 接続に進みます。VPC エンドポイントによるアクセス制限は、すべてのアクセスのパターンがプライベートな経路で動くことを確認してから有効にしてください。ID フェデレーションの設定や、RLS/CLS の高度な設定については、IAM Identity Center のドキュメントを参照してください。

著者について

翻訳は Solutions Architect の 守田 凜々佳 が担当しました。