Amazon WorkSpaces Secure Browser のインターネット通信を EC2 上の Squid プロキシ経由にしてみた

はじめに

以前、Amazon WorkSpaces Secure Browser と Microsoft Entra ID を SAML 連携し、Entra ID 認証でポータルへログインする構成を試しました。

https://dev.classmethod.jp/articles/amazon-workspaces-secure-browser-entra-id-saml/

前回の記事では、Secure Browser セッションから Regional NAT Gateway を経由してインターネットへ接続する構成にしていました。

WorkSpaces Secure Browser
↓
Regional NAT Gateway
↓
Internet

今回は、作成済みの環境に Amazon EC2 上の Squid プロキシを追加し、WorkSpaces Secure Browser のブラウザ通信をプロキシ経由に変更しました。

WorkSpaces Secure Browser
↓ TCP/3128
Proxy EC2（Squid）
↓
Regional NAT Gateway
↓
Internet

WorkSpaces Secure Browser では、Chrome の ProxySettings ポリシーを使って HTTP アウトバウンドプロキシを設定できます。

AWS 公式ドキュメントにも、WorkSpaces Secure Browser のポリシー設定に ProxySettings を追加する手順が記載されています。

https://docs.aws.amazon.com/workspaces-web/latest/adminguide/restricted-setup.html

本記事では、WorkSpaces Secure Browser に ProxySettings を設定し、Squid のアクセスログからプロキシを経由していることを確認するところまでを紹介します。

前提条件

今回は以下を前提とします。

• 検証リージョンは ap-northeast-1
• Microsoft Entra ID と SAML 連携した WorkSpaces Secure Browser ポータルを作成済み
• WorkSpaces Secure Browser 用の VPC とプライベートサブネットを作成済み
• プライベートサブネットのデフォルトルートを Regional NAT Gateway に設定済み
• WorkSpaces Secure Browser 用セキュリティグループを作成済み
• WorkSpaces Secure Browser から Regional NAT Gateway 経由でインターネットへ接続できることを確認済み
• Proxy EC2 は WorkSpaces Secure Browser と同じ VPC のプライベートサブネットに作成する
• Proxy EC2 の OS は Amazon Linux 2023

WorkSpaces Secure Browser ポータルと Microsoft Entra ID の設定については、前回の記事をご参照ください。

https://dev.classmethod.jp/articles/amazon-workspaces-secure-browser-entra-id-saml/

構成

今回の構成は以下です。

VPC
├─ Private Subnet 1
│  ├─ WorkSpaces Secure Browser 用 ENI
│  └─ Proxy EC2（Squid）
│
├─ Private Subnet 2
│  └─ WorkSpaces Secure Browser 用 ENI
│
└─ Regional NAT Gateway
   └─ Proxy EC2 からインターネットへの通信に使用

通信経路は以下です。

WorkSpaces Secure Browser
↓ Chrome の ProxySettings
Proxy EC2 のプライベート IPv4 アドレス:3128
↓ Squid
Regional NAT Gateway
↓
Internet

プライベートサブネットに関連付けたルートテーブルは、既存の設定をそのまま利用します。

WorkSpaces Secure Browser から Proxy EC2 への通信は、VPC の local ルートを使用します。

Proxy EC2 からインターネットへの通信は、0.0.0.0/0 のルートを使用して Regional NAT Gateway を経由します。

Proxy EC2 用セキュリティグループを作成する

Proxy EC2 用セキュリティグループには、WorkSpaces Secure Browser 用セキュリティグループからの TCP/3128 を許可します。

Squid の待ち受けポートには TCP/3128 を使用します。

今回の検証では、Proxy EC2 用セキュリティグループのアウトバウンドルールは、デフォルトの全許可としました。

Proxy EC2 への管理接続に必要なルールは、利用する接続方法に応じて別途設定します。Systems Manager Session Manager や EC2 Instance Connect Endpoint など、環境に応じた接続方法を利用してください。

Proxy EC2 を作成する

Proxy EC2 は以下の設定で作成しました。

Proxy EC2 は、WorkSpaces Secure Browser からプライベート IPv4 アドレスで到達できるよう、同じ VPC 内に作成しました。

インスタンス作成後、環境に応じた方法で Proxy EC2 へ接続します。

Squid をインストールする

Proxy EC2 に接続し、Squid をインストールします。

sudo dnf install -y squid

インストールされたバージョンを確認します。

squid --version

今回の環境では、以下のバージョンがインストールされました。

Squid Cache: Version 6.13
Service Name: squid

Squid のバージョンは、利用する Amazon Linux 2023 のリポジトリや実行時期によって異なる可能性があります。

Squid を設定する

最初に、既存の設定ファイルをバックアップします。

sudo cp /etc/squid/squid.conf \
  /etc/squid/squid.conf.original

続いて、/etc/squid/squid.conf を以下の内容に変更します。

sudo tee /etc/squid/squid.conf > /dev/null <<'EOF'
http_port 3128

acl SSL_ports port 443

acl Safe_ports port 80
acl Safe_ports port 443

acl CONNECT method CONNECT

acl wsb_clients src 10.0.0.0/16

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access allow wsb_clients
http_access deny all

access_log stdio:/var/log/squid/access.log
cache_log /var/log/squid/cache.log

visible_hostname wsb-poc-proxy
EOF

10.0.0.0/16 は今回使用した VPC の CIDR です。実際に試す場合は、自身の VPC CIDR に置き換えてください。

主な設定内容は以下です。

Squid の設定では VPC CIDR を許可していますが、Proxy EC2 用セキュリティグループでは WorkSpaces Secure Browser 用セキュリティグループからの TCP/3128 だけを許可しています。

そのため、Proxy EC2 の TCP/3128 への通信元は、セキュリティグループでも制限されています。

Squid を起動する

設定ファイルの構文を確認します。

sudo squid -k parse

今回の環境では、以下のように設定ファイルの各行が処理され、エラーで終了しないことを確認しました。

2026/07/21 07:32:11| Processing Configuration File: /etc/squid/squid.conf (depth 0)
2026/07/21 07:32:11| Processing: http_port 3128
2026/07/21 07:32:11| Processing: acl SSL_ports port 443
2026/07/21 07:32:11| Processing: acl Safe_ports port 80
2026/07/21 07:32:11| Processing: acl Safe_ports port 443
2026/07/21 07:32:11| Processing: acl CONNECT method CONNECT
2026/07/21 07:32:11| Processing: acl wsb_clients src 10.0.0.0/16
2026/07/21 07:32:11| Processing: http_access deny !Safe_ports
2026/07/21 07:32:11| Processing: http_access deny CONNECT !SSL_ports
2026/07/21 07:32:11| Processing: http_access allow wsb_clients
2026/07/21 07:32:11| Processing: http_access deny all
2026/07/21 07:32:11| Processing: access_log stdio:/var/log/squid/access.log
2026/07/21 07:32:11| Processing: cache_log /var/log/squid/cache.log
2026/07/21 07:32:11| Processing: visible_hostname wsb-poc-proxy

続いて、Squid を起動し、EC2 インスタンスの再起動後も自動起動するように設定します。

sudo systemctl enable --now squid

Squid の状態を確認します。

sudo systemctl status squid --no-pager

今回の環境では、以下のように active (running) になりました。

● squid.service - Squid caching proxy
     Loaded: loaded (/usr/lib/systemd/system/squid.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-07-21 07:32:26 UTC
       Docs: man:squid(8)
   Main PID: 26529 (squid)
      Tasks: 2
     Memory: 14.0M
        CPU: 57ms
     CGroup: /system.slice/squid.service
             ├─26529 /usr/sbin/squid --foreground -f /etc/squid/squid.conf
             └─26531 "(squid-1)" --kid squid-1 --foreground -f /etc/squid/squid.conf

TCP/3128 で待ち受けていることも確認します。

sudo ss -lntp | grep 3128

ここまでで、Proxy EC2 上の Squid が WorkSpaces Secure Browser からの接続を受け付けられる状態になりました。

WorkSpaces Secure Browser にプロキシを設定する

WorkSpaces Secure Browser の対象ポータルを開き、[ポータル設定] タブにある [ポリシーの詳細] の [編集] をクリックします。

WorkSpaces Secure Browser の [ポータル設定] タブから [ポリシーの詳細] を編集する画面

[JSON エディタ] を選択し、以下のブラウザポリシーを設定します。

WorkSpaces Secure Browser のブラウザポリシーに ProxySettings を設定した画面

{
  "chromePolicies": {
    "ProxySettings": {
      "value": {
        "ProxyMode": "fixed_servers",
        "ProxyServer": "10.0.136.199:3128"
      }
    }
  }
}

10.0.136.199 は、今回作成した Proxy EC2 のプライベート IPv4 アドレスです。

実際に試す場合は、自身の Proxy EC2 のプライベート IPv4 アドレスとポート番号に置き換えてください。

各設定値の意味は以下です。

ポリシーを保存した後、既存の Secure Browser セッションを終了し、新しいセッションを開始します。

今回は動作確認のため、ProxyServer に Proxy EC2 のプライベート IPv4 アドレスを直接指定しています。

ProxyServer には、WorkSpaces Secure Browser から名前解決および接続できる DNS 名を指定することもできます。継続的に利用する場合は、Proxy EC2 の再作成によるプライベート IPv4 アドレスの変更を考慮し、Route 53 プライベートホストゾーンなどで管理する DNS 名を指定する方法もあります。

DNS 名を利用する場合は、以下のようにホスト名とポート番号を指定します。

"ProxyServer": "proxy.example.internal:3128"

http:// や https:// などのスキームは付けず、DNS 名:ポート番号 の形式で指定します。

EC2のプライベートDNS名を直接使用する場合の例も加えるなら、以下です。

"ProxyServer": "ip-10-0-136-199.ap-northeast-1.compute.internal:3128"

ただし、EC2を終了して再作成するとプライベートDNS名も変わる可能性があるため、継続利用では独自に管理するDNS名のほうが扱いやすいです。

動作確認

ProxySettings の反映を確認する

新しい Secure Browser セッションを開始し、アドレスバーに以下を入力します。

chrome://policy

ProxySettings が表示され、設定したプロキシのプライベート IPv4 アドレスとポート番号が反映されていることを確認します。

ProxyMode：fixed_servers
ProxyServer：10.0.136.199:3128

AWS 公式ドキュメントでも、chrome://policy を開いて ProxySettings が適用されていることを確認する手順が案内されています。

https://docs.aws.amazon.com/workspaces-web/latest/adminguide/restricted-setup.html

Web サイトへアクセスする

続いて、Secure Browser から Web サイトへアクセスします。

今回の検証では、ProxySettings の設定後も Web サイトを表示できました。

プロキシ設定後に WorkSpaces Secure Browser から Web サイトへアクセスした画面

Squid のアクセスログを確認する

Proxy EC2 では、以下のコマンドで Squid のアクセスログを確認します。

sudo tail -f /var/log/squid/access.log

この状態で Secure Browser から Web サイトへアクセスします。

今回の検証では、Secure Browser から Web サイトへアクセスした際に、Squid のアクセスログへ通信が出力されることを確認しました。

以上から、今回の環境では WorkSpaces Secure Browser のブラウザ通信が Proxy EC2 上の Squid を経由していることを確認できました。

まとめ

Amazon WorkSpaces Secure Browser の ProxySettings に Proxy EC2 のプライベート IPv4 アドレスと TCP/3128 を指定し、Squid 経由で Web サイトへアクセスできました。

WorkSpaces Secure Browser のブラウザ通信を既存のプロキシへ集約したい場合の参考になれば幸いです。