閉域網からQuickSightへ接続！SquidプロキシとVPCエンドポイントでの構成を徹底解説

はじめに
課題：なぜVPCエンドポイントだけでは不十分なのか
解決構成：Squid Proxyを活用したハイブリッド構成
Squidプロキシの設定とホワイトリスト定義
- Squid基本設定（squid.conf）
- ホワイトリスト定義（allowed_sites.txt）
DNS（Route 53）の名前解決設計と検証
- Route 53ホストゾーンによる名前解決の仕組み
- 【検証】名前解決が正しく行われているかの確認
導入結果：アクセスログによる通信経路の検証
- CloudWatch メトリクスによる着信確認
まとめ
- 参照資料

はじめに

こんにちは！ゼネットシステム事業部の方です。

近年、BI（Business Intelligence）基盤として Amazon QuickSight を採用するケースが増えています。一方で、エンタープライズ企業では以下のような厳しい要件が求められることが多々あります。

社内ネットワークがインターネット非接続（いわゆる 閉域ネットワーク）
セキュリティ要件により、通信経路や接続先をドメインレベルで厳しく制御したい

QuickSightへの接続設計は一筋縄ではいきません。本記事では、これらを解決するために EC2上にSquid Proxyを構築し、VPCエンドポイント（AWS PrivateLink）と組み合わせたハイブリッドな接続構成 を実務目線で解説します。

課題：なぜVPCエンドポイントだけでは不十分なのか

今回の要件と、直面した課題は以下の通りです。

■ 前提条件

ユーザーはDirect Connect（DX）やVPN経由の閉域ネットワークからのみアクセス
クライアント端末から直接インターネットへの疎通は禁止
通信経路・名前解決（DNS）を明示的に制御したい

■ 直面する問題：画面が真っ白になる罠

Amazon QuickSightはマネージドサービスであり、その通信は大きく2つに分かれます。

QuickSightサービス本体: 認証やデータ操作（API/Webサイト）
静的リソース（CDN）: 画像、JS、CSSなどの読み込み（CloudFront経由）

2024年にサポートされた「QuickSight VPCエンドポイント」は、

1（サービス本体）の通信をカバーします。しかし、2（静的リソース）は依然としてパブリックなCloudFront経由のアクセスが必要です。そのため、単純にVPCエンドポイントを作るだけでは「認証は通るが画面が正しく表示されない」といった問題が発生します。

解決構成：Squid Proxyを活用したハイブリッド構成

この課題を解決するため、通信の集約ポイントとして Squid Proxy を配置します。

■ 構成のポイント

Squid Proxy: 閉域網からのリクエストを一括で受け取り、宛先ドメインに応じて経路を振り分けます。
QuickSight VPCエンドポイント: サービス本体への通信をPrivateLink経由でAWS内部へ流します。
NAT Gateway: .cloudfront.net など、インターネット上の静的コンテンツへのアクセスのみを限定的に許可します。
Route 53 Private Hosted Zone: 内部DNSでQuickSightドメインをVPCエンドポイントのプライベートIPへ解決させます。

Squidプロキシの設定とホワイトリスト定義

Squid（Ver 6系想定）を用い、ドメインベースのホワイトリスト制御とSSL Bump（SNI解析）を組み合わせます。

Squid基本設定（squid.conf）

# SSL Bumpを利用した明示プロキシ設定
# ------------------------
# Minimal Squid 6 config with domain whitelist
# ドメインホワイトリスト方式の最小構成 Squid 6 設定
# ------------------------

# Listen on all interfaces (Explicit Proxy + SSL Bump)
# 全インターフェースで待ち受け（明示プロキシ + SSL Bump）
http_port 0.0.0.0:3128 ssl-bump \
  generate-host-certificates=on \
  dynamic_cert_mem_cache_size=4MB \
  cert=/etc/squid/ssl_cert/myCA.pem \
  key=/etc/squid/ssl_cert/myCA.key

# ------------------------
# Basic ACLs
# 基本的なアクセス制御リスト
# ------------------------
acl localnet src 10.0.0.0/8        # Private network (10.x.x.x)
acl localnet src 172.16.0.0/12     # Private network (172.16–31.x.x)
acl localnet src 192.168.0.0/16    # Private network (192.168.x.x)
acl localhost src 127.0.0.1/32     # Localhost

# ------------------------
# Safe ports
# 許可するポート番号
# ------------------------
acl Safe_ports port 80             # HTTP
acl Safe_ports port 443            # HTTPS
acl SSL_ports port 443             # SSL/TLS

# Deny access to unsafe ports
# 安全でないポートへの通信を拒否
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

# Allow localhost to manage cache
# localhost からの管理操作のみ許可
http_access allow localhost manager
http_access deny manager

# ------------------------
# Domain whitelist
# ドメインホワイトリスト定義
# ------------------------
acl allowed_sites dstdomain "/etc/squid/allowed_sites.txt"

# ------------------------
# SSL Bump settings
# SSL Bump 設定（SNI ベース制御）
# ------------------------
acl step1 at_step SslBump1          # TLS handshake step

# Peek SNI (do not decrypt payload)
# SNI のみ確認（通信内容は復号しない）
ssl_bump peek step1

# Allow only whitelisted domains
# ホワイトリストに一致するドメインのみ許可
ssl_bump splice allowed_sites

# Terminate all other HTTPS connections
# それ以外の HTTPS 通信は遮断
ssl_bump terminate all

# ------------------------
# Access control
# アクセス制御
# ------------------------
http_access allow allowed_sites     # Allow whitelisted domains
http_access deny all                # Deny everything else

# ------------------------
# Logging & cache
# ログおよびキャッシュ設定
# ------------------------
coredump_dir /var/spool/squid

# Cache refresh patterns
# キャッシュ更新ポリシー
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern .               0       20%     4320

ホワイトリスト定義（allowed_sites.txt）

# QuickSight API & Console
# QuickSight API（VPC エンドポイント経由）
quicksight.ap-northeast-1.amazonaws.com

# QuickSight console
# QuickSight 管理画面・閲覧画面
.quicksight.aws.amazon.com

# CloudFront used by QuickSight console
# QuickSight コンソール配信用 CloudFront
.cloudfront.net

# STS (QuickSight authentication)
# 認証・認可に使用される AWS STS
sts.ap-northeast-1.amazonaws.com
sts.amazonaws.com

# S3 (if QuickSight reads data from S3)
# QuickSight が S3 データを参照する場合
s3.ap-northeast-1.amazonaws.com

[Tips] QuickSightが依存するドメインは更新される可能性があるため、公式の Supported domains を定期的に確認することをお勧めします。

DNS（Route 53）の名前解決設計と検証

QuickSightをVPCエンドポイント経由で利用する場合、DNSの設定が極めて重要です。ここでは、エンドユーザーのブラウザ挙動を踏まえた設定方法と、その検証結果を解説します。

Route 53ホストゾーンによる名前解決の仕組み

エンドユーザーのブラウザが QuickSight のドメイン（quicksight.aws.amazon.com）にアクセスする際、そのリクエストをパブリックインターネットではなく、作成した VPC エンドポイント へ正しくルーティングさせる必要があります。

エンドユーザーのブラウザは、このドメインを解決した先のIPに対してリクエストを送信します。Route 53 を DNS として利用している場合、Private Hosted Zone を作成し、以下のように A レコードを設定することで、ブラウザからのリクエストを VPC エンドポイント経由で送信するように構成できます。

Route 53 Private Hosted Zone での A レコード設定例

この設定により、ブラウザはパブリックな経路を一切通らず、VPCエンドポイントのプライベートIP（例：172.31.26.112）へ直接リクエストを送るようになります。

【検証】名前解決が正しく行われているかの確認

設定が意図した通りに反映されているか、Squidサーバーからdigコマンドで検証を行いました。ここがプライベート接続の「動かぬ証拠」となります。

[ec2-user@ip-172-31-21-20 ~]$ dig quicksight.aws.amazon.com

;; QUESTION SECTION:
;quicksight.aws.amazon.com. IN A

;; ANSWER SECTION:
quicksight.aws.amazon.com. 60   IN      A       172.31.26.112

;; Query time: 0 msec
;; SERVER: 172.31.0.2#53(172.31.0.2) (UDP)

■ 結果の解説：なぜこれで「成功」と言えるのか？

ANSWER SECTION が VPC 内部 IP であること: 返ってきた IP 172.31.26.112 は、今回作成した VPC エンドポイントのプライベート IP です。
SERVER が AmazonRoute53Resolver であること: 172.31.0.2（VPC DNS）が Private Hosted Zone を正しく参照し、インターセプトしていることが分かります。
クエリタイム 0 msec: AWS 内部ネットワーク内で名前解決が完結しているため、極めて高速に応答が返っています。

導入結果：アクセスログによる通信経路の検証

構築後、/var/log/squid/access.log を確認し、意図した通りの挙動となっているか検証しました。

# 許可されない通信（AWSコンソールや外部SaaS）のブロック例
1766037135.120     55 127.0.0.1 TCP_DENIED/200 0 CONNECT outlook.office365.com:443 - HIER_NONE/- -
1766037135.389 156 127.0.0.1 TCP_DENIED/200 0 CONNECT telemetry.cell-0.us-east-1.prod.tangerinebox.console.aws.a2z.com:443 - HIER_NONE/- -

# 許可された通信（QuickSight本体とCloudFront）
1766037137.173 17020 127.0.0.1 TCP_TUNNEL/200 76510 CONNECT quicksight.aws.amazon.com:443 - HIER_DIRECT/172.31.26.112 -
1766037137.173 15750 127.0.0.1 TCP_TUNNEL/200 6263 CONNECT dw6mvobol0fbc.cloudfront.net:443 - HIER_DIRECT/3.166.208.143 -

■ 検証結果の考察

TCP_DENIED: QuickSightに関係のないOffice365やTelemetryドメインが設計通りブロックされています。
TCP_TUNNEL（QuickSight本体）: 接続先IP 172.31.26.112 はVPCエンドポイントのプライベートIPであり、PrivateLink経由の通信が確認できました。
TCP_TUNNEL（CloudFront）: パブリックIPへ向かっており、NAT Gateway経由で正常にアセットを読み込めています。