プロキシサーバーのホワイトリスト設定について

プロキシサーバーのホワイトリスト設定とは、許可した通信先・ユーザー・IPアドレス・ドメイン・サービスだけを通すためのアクセス制御です。

社内ネットワークや学校、官公庁、金融機関、医療機関、クラウド環境などで利用されることが多く、主な目的は以下のとおりです。

• 業務に不要なWebサイトへのアクセスを制限する
• マルウェア感染やフィッシングサイトへの接続を防ぐ
• 情報漏えいや不正アップロードを防止する
• 社内端末から利用できる外部サービスを管理する
• セキュリティポリシーに沿った通信だけを許可する

ホワイトリスト方式では、基本的に「許可したもの以外はすべて拒否する」という考え方を取ります。

そのため、セキュリティを高めやすい一方で、設定が不十分だと業務に必要なサイトやSaaSまで利用できなくなる可能性があります。

プロキシサーバーの基本的な仕組み

プロキシサーバーとは

プロキシサーバーとは、ユーザーのPCやスマートフォン、社内端末とインターネットの間に入る中継サーバーです。

通常の通信では、端末はWebサイトへ直接アクセスします。

端末 → Webサイト

一方、プロキシサーバーを利用する場合は、以下のように通信が中継されます。

端末 → プロキシサーバー → Webサイト

この中継地点で、アクセス先の確認、通信ログの記録、危険なサイトのブロック、特定サイトのみの許可などを行います。

プロキシサーバーでできる主な制御

プロキシサーバーでは、主に以下のような制御ができます。

- 特定のWebサイトだけ許可する
- 特定のWebサイトをブロックする
- ユーザーや部署ごとにアクセス権限を変える
- アクセスログを記録する
- 不審な通信を検知する
- ファイルアップロードやダウンロードを制限する
- HTTPS通信を検査する

企業では、単にWebサイトをブロックするだけでなく、誰が・いつ・どのサイトへ・どのような通信をしたかを把握するためにも使われます。

ホワイトリスト設定の意味

ホワイトリスト方式とは

ホワイトリスト方式とは、あらかじめ許可した対象だけを通す方式です。

たとえば、以下のようなルールを設定します。

許可する通信先：
- example.com
- company-service.jp
- api.example.jp
- 203.0.113.10

拒否する通信先：
- 上記以外すべて

この場合、ユーザーは許可リストに登録されたサイトやサービスにしかアクセスできません。

つまり、ホワイトリスト方式は「危険なものを止める」のではなく、安全または必要と判断したものだけを許可する考え方です。

ブラックリスト方式との違い

ホワイトリストとよく比較されるのが、ブラックリスト方式です。

ブラックリスト方式は、危険なサイトや禁止したいサイトだけを登録し、それ以外は許可する方法です。

項目	ホワイトリスト方式	ブラックリスト方式
基本方針	許可したものだけ通す	禁止したものだけ止める
セキュリティ強度	高い	中程度
利便性	制限が強い	比較的高い
運用負荷	高い	比較的低い
向いている環境	重要端末、金融、医療、教育、社内システム	一般的なWeb利用環境

ホワイトリスト方式はセキュリティ面では強力ですが、許可リストにない通信はすべて止まります。

そのため、業務に必要な通信先を正確に洗い出し、継続的にメンテナンスすることが重要です。

プロキシサーバーで設定できるホワイトリストの種類

ドメイン単位のホワイトリスト

ドメイン単位で許可する方法

もっとも一般的なのが、ドメイン単位で許可する方法です。

例として、以下のようなドメインを許可します。

example.com
company-service.jp
google.com
chat.openai.com

ドメイン単位で許可すると、指定したWebサイトやサービスへのアクセスを制御できます。

ただし、単にメインドメインを許可しただけでは、サービスが正常に動作しない場合があります。

たとえば、あるWebサービスが以下のような複数ドメインを利用しているケースがあります。

app.example.com
api.example.com
auth.example.com
cdn.example.com
static.examplecdn.net

この場合、app.example.com だけを許可しても、ログインできない、画像が表示されない、APIが動かないといった問題が起こることがあります。

サブドメインの扱いに注意する

ホワイトリスト設定では、サブドメインの扱いに注意が必要です。

たとえば、以下はすべて異なるFQDNです。

example.com
www.example.com
api.example.com
login.example.com

プロキシ製品によっては、example.com を許可しても api.example.com や login.example.com は自動的に許可されない場合があります。

サブドメインをまとめて許可したい場合は、以下のようなワイルドカード指定を使うことがあります。

*.example.com

ただし、設定形式は製品によって異なります。

たとえば、ある製品では *.example.com と書き、別の製品では .example.com と書く場合があります。正規表現やURLカテゴリで指定する製品もあります。

そのため、実際に設定する際は、利用しているプロキシ製品やSWG、ファイアウォールの仕様を確認する必要があります。

URL単位のホワイトリスト

URL単位で許可する方法

URL単位のホワイトリストでは、ドメイン全体ではなく、特定のURLだけを許可します。

例は以下の通りです。

https://example.com/login
https://example.com/admin
https://example.com/api/v1/

このようにURL単位で制御できると、より細かいアクセス管理が可能です。

たとえば、同じドメイン内でも、一般ページは許可し、管理画面は拒否するといった制御ができます。

HTTPS通信ではURLパスが見えない場合がある

URL単位の制御で特に注意すべきなのが、HTTPS通信です。

現在のWebサイトの多くはHTTPSを利用しています。

HTTPSでは通信内容が暗号化されるため、プロキシサーバーがそのまま確認できる情報は限られます。

SSL/TLSインスペクションを行わない場合、プロキシが主に確認できるのは以下のような情報です。

- 接続先ホスト名
- SNI
- 接続先IPアドレス
- ポート番号
- 証明書情報の一部

一方で、以下のようなURLパスは暗号化されているため、通常は見えません。

/login
/admin
/api/v1/

そのため、HTTPS通信でURLパス単位のホワイトリストを行うには、多くの場合、SSL/TLSインスペクションが必要です。

IPアドレス単位のホワイトリスト

IPアドレスで許可する方法

IPアドレス単位のホワイトリストでは、特定のIPアドレスやIPレンジだけを許可します。

例は以下の通りです。

203.0.113.10
203.0.113.20
198.51.100.0/24

固定IPを持つ取引先システム、自社サーバー、外部APIなどでは有効な方法です。

たとえば、以下のようなケースで使われます。

- 取引先の固定IPだけAPIアクセスを許可する
- 社内サーバーから特定の外部APIだけへ接続を許可する
- 管理画面へのアクセスを社内IPだけに限定する

SaaSやCDNではIP許可だけでは運用が難しい

IPアドレスによるホワイトリストは一見シンプルですが、SaaSやクラウドサービス、CDNでは注意が必要です。

理由は以下の通りです。

- IPアドレスが変更されることがある
- 同じIPアドレスを複数サービスで共有していることがある
- CDN経由では接続先IPが地域や時間で変わることがある
- クラウドサービスではIPレンジが広いことがある
- DNSの応答内容によって接続先が変わることがある

たとえば、AWS、Google Cloud、Microsoft Azure、Cloudflare、Akamai、CloudFrontなどを利用しているサービスでは、IPアドレスだけで厳密に管理するのが難しいケースがあります。

そのため、SaaSやクラウドサービスでは、IPベースだけでなく、ドメインベース、アプリケーション制御、公式ドキュメントに記載されたネットワーク要件などを組み合わせて管理するのが一般的です。

ポート番号単位のホワイトリスト

ポート番号で通信を制限する

ホワイトリスト設定では、通信先だけでなく、ポート番号を指定して許可することもあります。

代表的なポート番号は以下の通りです。

ポート番号	用途
80	HTTP
443	HTTPS
22	SSH
25	SMTP
53	DNS
587	メール送信
3306	MySQL
5432	PostgreSQL

たとえば、以下のように指定します。

example.com:443

この場合、example.com へのHTTPS通信だけを許可するイメージです。

プロキシとファイアウォールで役割が異なる

ポート制御は、プロキシサーバーだけで行うとは限りません。

実務では、以下のような機器やサービスと役割分担することが多いです。

- プロキシサーバー
- ファイアウォール
- ルーター
- クラウドのセキュリティグループ
- SWG
- WAF

たとえば、WebプロキシではHTTPSの CONNECT メソッドで接続できるポートを制限し、ファイアウォールではL3/L4レベルで宛先IPやポートを制限する、といった構成が考えられます。

同じ「ポートを許可する」という表現でも、どのレイヤーで制御しているかによって意味が変わるため注意が必要です。

ユーザー・グループ単位のホワイトリスト

部署や役割ごとに許可範囲を変える

プロキシサーバーでは、ユーザーや部署ごとにアクセスできるサイトを変えることもできます。

たとえば、以下のような設定です。

全社員：
- 社内ポータル
- メール
- 勤怠管理
- Web会議

営業部：
- CRM
- 取引先サイト
- オンライン商談ツール

マーケティング部：
- 広告管理画面
- アクセス解析ツール
- SEOツール
- SNS管理ツール

開発部：
- GitHub
- npm
- Docker Hub
- APIドキュメント

経理部：
- 会計システム
- 銀行サイト
- 請求書管理サービス

全社員に同じホワイトリストを適用すると、不要なサービスまで許可してしまう可能性があります。

そのため、業務内容に応じてグループ単位で管理する方が安全です。

認証基盤との連携が重要

ユーザー・グループ単位で制御する場合、プロキシサーバー単体ではなく、認証基盤と連携することが多くあります。

代表的な連携先は以下の通りです。

- Active Directory
- LDAP
- Microsoft Entra ID
- Google Workspace
- SAML認証
- IdP
- MDM

認証基盤と連携することで、ユーザーの所属部署や権限に応じたアクセス制御が可能になります。

また、退職者や異動者の権限管理もしやすくなります。

アプリケーション単位のホワイトリスト

サービスやアプリ単位で制御する方法

最近のプロキシ製品やSWG、SASE製品では、単純なドメインやIPだけでなく、アプリケーション単位で制御できるものがあります。

たとえば、以下のような制御です。

- Slackは許可する
- Dropboxはブロックする
- Google Driveは閲覧のみ許可する
- 個人アカウントのクラウドストレージ利用を制限する
- YouTubeは研修用途のみ許可する
- ChatGPTは特定部署のみ許可する

このような制御は、SaaS利用が多い企業では特に重要です。

ドメイン許可だけでは制御しきれないケースがある

SaaSでは、同じドメイン配下に複数の機能が存在することがあります。

たとえば、Google Driveを例にすると、以下のような要件が考えられます。

- 会社アカウントのGoogle Driveは許可したい
- 個人アカウントのGoogle Driveはブロックしたい
- ファイル閲覧は許可したい
- ファイルアップロードは制限したい

このような制御は、単純なドメインホワイトリストだけでは難しい場合があります。

そのため、CASB、SWG、IdP、MDM、EDRなどと組み合わせて、ユーザー、端末状態、アカウント種別、操作内容まで含めた制御を検討する必要があります。

HTTPS通信とSSL/TLSインスペクション

HTTPS通信でプロキシが確認できる情報

HTTPS通信では、通信内容が暗号化されます。

そのため、SSL/TLSインスペクションを行わない場合、プロキシサーバーが確認できる情報は限定的です。

主に以下の情報をもとに制御します。

- 接続先IPアドレス
- ポート番号
- CONNECTリクエストの宛先ホスト名
- SNI
- サーバー証明書の情報

一方で、以下のような情報は基本的に暗号化されます。

- URLパス
- HTTPヘッダーの多く
- Cookie
- POSTデータ
- ページ内容
- アップロードファイルの中身

そのため、HTTPS通信で詳細なURL制御や内容検査を行いたい場合は、SSL/TLSインスペクションが必要になることがあります。

SNIベース制御の限界

SNIとは、TLS接続時にクライアントが接続したいホスト名を伝える仕組みです。

HTTPS通信を復号しなくても、SNIを使えば接続先のホスト名をある程度判断できます。

ただし、SNIベースの制御は万能ではありません。

注意点は以下の通りです。

- SNIを送信しない古いクライアントや特殊なアプリがある
- IPアドレス直打ちの通信ではホスト名が分からない
- SNIと実際のHTTP Hostヘッダーが一致するとは限らない
- 一部の新しい技術により可視性が変わる可能性がある
- アプリ独自通信では識別が難しい場合がある

そのため、SNIベースの制御は便利ですが、厳密なURL制御や内容検査を行う場合は、SSL/TLSインスペクションやエージェント型セキュリティ製品との組み合わせが必要になることがあります。

SSL/TLSインスペクションの注意点

SSL/TLSインスペクションとは、プロキシサーバーやセキュリティ製品がHTTPS通信を一度復号し、中身を確認したうえで再暗号化する仕組みです。

これにより、以下のような制御が可能になります。

- URLパス単位の制御
- ファイルアップロード・ダウンロードの検査
- マルウェア検査
- DLPによる情報漏えい対策
- 不審な通信内容の検知

一方で、SSL/TLSインスペクションには注意点もあります。

- 端末にルート証明書を配布する必要がある
- 証明書ピンニングを使うアプリで通信エラーが起こることがある
- 個人情報や機密情報がログに含まれる可能性がある
- 金融、医療、個人メールなどは復号対象から除外すべき場合がある
- 社内規程や同意、監査ルールを整備する必要がある
- 復号装置自体が高リスクな中継ポイントになる

SSL/TLSインスペクションは強力ですが、すべての通信を無条件に復号すればよいわけではありません。

業務上必要な範囲、プライバシー、法務、セキュリティリスクを踏まえて設計する必要があります。

ホワイトリスト設定で重要な設計方針

必要最小限の許可にする

ホワイトリスト設定の基本は、必要最小限の通信だけを許可することです。

たとえば、業務に必要なサイトだけを許可し、それ以外は拒否します。

Allow：業務に必要な通信先
Deny：それ以外すべて

ただし、必要最小限を意識しすぎると、業務に必要な通信まで止まることがあります。

そのため、セキュリティと業務効率のバランスを取りながら設計することが重要です。

ワイルドカード許可を乱用しない

ホワイトリスト設定では、ワイルドカードを使うと広範囲のドメインをまとめて許可できます。

例は以下の通りです。

*.example.com
*.google.com
*.amazonaws.com
*.cloudfront.net

ワイルドカードは便利ですが、広く許可しすぎると想定外のサービスまで通ってしまう可能性があります。

特に、クラウドやCDN系のドメインは、多くのサービスで共有されることがあります。

そのため、ワイルドカードを使う場合は、以下のような対策を組み合わせると安全です。

- 対象ユーザーを限定する
- 対象端末を限定する
- 一時許可には期限を付ける
- アクセスログを監査する
- 公式ドキュメントを確認する
- 可能な範囲で許可範囲を絞る

公式ドキュメントを確認する

SaaSやクラウドサービスを許可する場合は、必ず公式ドキュメントを確認することが重要です。

多くのサービスでは、以下のような情報が公開されています。

- 必要なドメイン
- 必要なIPレンジ
- 使用するポート
- プロキシ利用時の注意点
- SSLインスペクション除外が必要な通信
- ファイアウォール許可設定

プロキシのブロックログだけを見て許可ドメインを追加していくと、不要な通信まで許可してしまう可能性があります。

ログは重要ですが、公式情報と照らし合わせながら判断することが大切です。

SaaS利用時に見落としやすい通信先

認証用ドメイン

SaaSでは、ログイン処理に外部の認証基盤を使うことがあります。

たとえば、以下のようなドメインです。

accounts.google.com
login.microsoftonline.com
okta.com
auth0.com

サービス本体のドメインだけを許可しても、認証用ドメインがブロックされているとログインできません。

API用ドメイン

Web画面は表示されても、データの保存や検索、更新ができない場合は、API通信がブロックされている可能性があります。

例は以下の通りです。

api.example.com
graphql.example.com
backend.example.com

最近のWebアプリケーションは、画面表示とAPI通信が別ドメインになっていることが多いため注意が必要です。

CDN・静的ファイル配信用ドメイン

CSS、JavaScript、画像、フォントなどは、CDNや静的ファイル配信用ドメインから読み込まれることがあります。

例は以下の通りです。

cdn.example.com
static.example.com
assets.examplecdn.net
fonts.googleapis.com

これらがブロックされると、画面が崩れたり、ボタンが動かなかったり、画像が表示されなかったりします。

アップロード・ストレージ用ドメイン

ファイルアップロードやダウンロード機能を使うサービスでは、ストレージ系のドメインが必要になる場合があります。

例は以下の通りです。

upload.example.com
storage.googleapis.com
s3.amazonaws.com
blob.core.windows.net

画面は正常に開けるのにファイル操作だけ失敗する場合は、ストレージ系通信が止まっている可能性があります。

アプリ更新・ライセンス認証用ドメイン

業務用アプリやセキュリティ製品では、更新やライセンス認証のための通信が必要です。

例は以下の通りです。

- Windows Update
- macOS Software Update
- Google Chrome Update
- Adobe製品の更新
- セキュリティソフトの定義ファイル更新
- EDR製品の管理サーバー通信
- MDM管理通信

これらを止めてしまうと、脆弱性修正やセキュリティ対策に影響が出るため注意が必要です。

実務でのホワイトリスト設定手順

対象範囲を決める

まず、ホワイトリスト設定の対象範囲を決めます。

たとえば、以下のように整理します。

- 全社員のWebアクセス
- 特定部署のWebアクセス
- 開発環境から外部への通信
- 本番サーバーから外部APIへの通信
- ゲストWi-Fi
- 管理端末
- 教育用端末

対象が変わると、必要な通信先も変わります。

全社向けのホワイトリストと、サーバー向けのホワイトリストを同じ設計にすると、過剰許可や業務影響が起こりやすくなります。

利用サービスを洗い出す

次に、業務で必要なサービスを洗い出します。

以下のような項目で整理すると管理しやすくなります。

- サービス名
- 利用部署
- 利用目的
- 利用者
- 必要な機能
- 取り扱う情報
- 代替手段
- 利用期間

単にサービス名だけを並べるのではなく、どの部署が何の目的で使うのかを明確にすることが重要です。

必要なドメイン・IP・ポートを確認する

利用サービスが決まったら、それぞれの通信要件を確認します。

確認方法は以下の通りです。

- 公式ドキュメントを確認する
- ベンダーに問い合わせる
- プロキシログを確認する
- ファイアウォールログを確認する
- ブラウザの開発者ツールで通信を見る
- ネットワークキャプチャを行う

ただし、ログに出てきた通信先をすべて許可するのは危険です。

業務に必要な通信かどうかを確認したうえで、必要最小限に絞り込むことが大切です。

テストグループで検証する

ホワイトリスト設定は、いきなり全社展開しない方が安全です。

まずは、以下のような小さな範囲で検証します。

- 情シス部門
- セキュリティ担当者
- テスト用端末
- 協力してくれる一部ユーザー
- 影響の小さい部署

テスト中は、利用できないサービスやブロックされた通信を確認し、必要な通信だけを追加していきます。

ブロックログを確認して調整する

ホワイトリスト方式では、最初から完璧な許可リストを作るのは難しいです。

そのため、ブロックログを確認しながら調整します。

確認すべき項目は以下の通りです。

- どのユーザーの通信か
- どの端末からの通信か
- どの宛先がブロックされたか
- どのポートが使われたか
- どのルールで拒否されたか
- 業務上必要な通信か
- 一時的な通信か継続的な通信か

ブロックされた通信をすぐに許可するのではなく、必要性を確認したうえで追加することが重要です。

段階的に展開する

テストが完了したら、段階的に適用範囲を広げます。

例は以下の通りです。

1. 情シス部門で検証
2. 一部部署で検証
3. 問題点を修正
4. 全社展開
5. 展開後もログを監視

ホワイトリスト設定は業務影響が大きいため、ロールバック手順や問い合わせ窓口も準備しておくと安心です。

ホワイトリスト設定の管理台帳

管理台帳に記録すべき項目

ホワイトリスト設定は、時間が経つと「なぜ許可したのか分からない通信先」が増えがちです。

そのため、管理台帳を作成しておくことが重要です。

記録すべき項目は以下の通りです。

項目	内容
サービス名	Google Analytics、Salesforceなど
用途	アクセス解析、CRM、広告管理など
許可対象	ドメイン、URL、IP、ポート
対象部署	全社、営業部、開発部など
対象ユーザー	ユーザー名、グループ名
通信方向	社内から外部、外部から社内
プロトコル	HTTPS、HTTP、SSHなど
ポート	443、80など
申請者	依頼した人や部署
承認者	情シス、セキュリティ責任者など
許可理由	業務上必要な理由
期限	永続、一時、プロジェクト期間
備考	公式ドキュメントURL、注意事項など

管理台帳の記入例

たとえば、以下のように記録します。

サービス名：Google Analytics
用途：アクセス解析
許可対象：
- analytics.google.com
- www.google-analytics.com
対象部署：マーケティング部
プロトコル：HTTPS
ポート：443
許可理由：アクセス解析およびレポート確認のため
期限：永続
備考：必要ドメインは公式情報を定期確認

別の例です。

サービス名：取引先API
用途：受注データ連携
許可対象：
- api.partner-example.jp
対象ユーザー：基幹システムサーバー
プロトコル：HTTPS
ポート：443
許可理由：受注データの自動連携のため
期限：契約期間中
備考：本番環境のみ許可

このように記録しておくことで、後から見直しや監査がしやすくなります。

よくあるトラブルと原因

サイトのトップページは開くがログインできない

ログイン用の認証ドメインが許可されていない可能性があります。

例は以下の通りです。

accounts.google.com
login.microsoftonline.com
auth.example.com
okta.com

サービス本体のドメインだけでなく、認証に使う外部ドメインも確認しましょう。

ログインできるが画面が崩れる

CSS、JavaScript、画像、フォントなどの静的ファイル配信元がブロックされている可能性があります。

例は以下の通りです。

cdn.example.com
static.example.com
assets.examplecdn.net
fonts.googleapis.com

この場合、ブラウザの開発者ツールやプロキシログを確認すると原因を特定しやすくなります。

画面は表示されるが保存できない

API通信がブロックされている可能性があります。

例は以下の通りです。

api.example.com
graphql.example.com
backend.example.com

最近のWebアプリは、画面表示とデータ更新の通信先が分かれていることが多いため注意が必要です。

ファイルアップロードだけ失敗する

アップロード用ドメインやストレージ系ドメインが許可されていない可能性があります。

例は以下の通りです。

upload.example.com
storage.googleapis.com
s3.amazonaws.com
blob.core.windows.net

画面表示だけでなく、ファイル操作に関係する通信先も確認しましょう。

アプリ版だけ動かない

ブラウザ版では動くのに、デスクトップアプリやモバイルアプリでは動かない場合があります。

この場合、アプリ版がブラウザ版とは異なる通信先を使っている可能性があります。

たとえば、以下のような通信です。

- アプリ更新用サーバー
- 通知用サーバー
- 同期用API
- ライセンス認証サーバー
- モバイル向けAPI

アプリ利用を許可する場合は、ブラウザ版だけでなくアプリ版のネットワーク要件も確認しましょう。

証明書エラーが出る

SSL/TLSインスペクションを行っている環境で証明書エラーが出る場合、端末にプロキシ用のルート証明書が正しく配布されていない可能性があります。

よくあるエラーは以下の通りです。

- この接続ではプライバシーが保護されません
- 証明書が信頼されていません
- SSL certificate error
- certificate verify failed

特に、Windows、macOS、iOS、Android、Linux、Javaアプリ、Node.js、Pythonなどでは、証明書ストアの扱いが異なる場合があります。

フォワードプロキシとリバースプロキシの違い

フォワードプロキシのホワイトリスト

フォワードプロキシは、社内ユーザーが外部サイトへアクセスするときに使われます。

通信の流れは以下の通りです。

社内端末 → フォワードプロキシ → インターネット

この場合のホワイトリスト対象は、主に以下です。

- 外部Webサイト
- SaaS
- 外部API
- CDN
- 認証サービス
- 更新サーバー

社内から外部へのアクセスを制御したい場合に使います。

リバースプロキシのホワイトリスト

リバースプロキシは、外部ユーザーから自社Webサービスや社内システムへアクセスするときの入口に置かれます。

通信の流れは以下の通りです。

外部ユーザー → リバースプロキシ → 自社Webサーバー

この場合のホワイトリスト対象は、主に以下です。

- 接続元IPアドレス
- 取引先の固定IP
- 管理者のIP
- WAFやロードバランサーのIP
- VPN経由の通信

たとえば、管理画面へのアクセスを社内IPだけに限定する場合に使います。

フォワードプロキシとリバースプロキシの比較

種類	主な用途	ホワイトリスト対象
フォワードプロキシ	社内から外部へのアクセス制御	外部サイト、SaaS、API
リバースプロキシ	外部から自社サービスへのアクセス制御	接続元IP、取引先、管理者
APIゲートウェイ	APIの入口制御	クライアントIP、APIキー、認証情報
SWG	Webアクセス全般の制御	URLカテゴリ、SaaS、ユーザー、端末状態

同じ「プロキシのホワイトリスト」でも、通信の向きによって設計が大きく変わります。

Squidでのホワイトリスト設定例

最小構成の例

Squidでは、ACLを使って許可対象を定義し、http_access で許可・拒否を制御します。

たとえば、以下はシンプルな例です。

acl allowed_sites dstdomain .example.com .example.jp .company-service.jp

http_access allow allowed_sites
http_access deny all

この設定では、allowed_sites に該当する宛先だけを許可し、それ以外を拒否します。

ただし、この例はホワイトリストの考え方を示す最小構成です。

実運用では、送信元ネットワークやユーザー認証なども組み合わせる必要があります。

実務向けの設定例

実務では、以下のように送信元ネットワークやSSLポート制御を加える方が安全です。

# 社内ネットワーク
acl localnet src 192.168.1.0/24

# 許可する宛先ドメイン
acl allowed_sites dstdomain .example.com .example.jp .company-service.jp

# SSL CONNECTで許可するポート
acl SSL_ports port 443
acl CONNECT method CONNECT

# 不正なSSLポートへのCONNECTを拒否
http_access deny CONNECT !SSL_ports

# 社内ネットワークから許可ドメインへのアクセスのみ許可
http_access allow localnet allowed_sites

# それ以外は拒否
http_access deny all

この設定では、以下の条件を満たす通信のみ許可します。

- 送信元が社内ネットワークである
- 宛先が許可ドメインである
- HTTPS CONNECTは443番ポートのみ許可する

ただし、実際の設定はSquidのバージョン、認証方式、明示プロキシか透過プロキシか、SSL Bumpを使うかどうかによって変わります。

本番環境へ適用する場合は、必ず検証環境で確認しましょう。

Nginxリバースプロキシでのホワイトリスト設定例

管理画面を特定IPだけに許可する例

Nginxでは、allow と deny を使って接続元IPを制限できます。

たとえば、管理画面 /admin/ へのアクセスを特定IPだけに許可する場合は、以下のように設定します。

location /admin/ {
    allow 203.0.113.10;
    allow 198.51.100.0/24;
    deny all;
}

この設定では、以下の接続元だけが /admin/ にアクセスできます。

- 203.0.113.10
- 198.51.100.0/24

それ以外のIPアドレスからのアクセスは拒否されます。

CDNやロードバランサー配下では注意が必要

NginxをCDNやロードバランサーの後ろに置いている場合、Nginxから見る接続元IPが実際のユーザーIPではなく、CDNやロードバランサーのIPになることがあります。

この場合、単純な allow / deny だけでは意図した制御にならないことがあります。

必要に応じて、以下を検討します。

- real_ip_header の設定
- set_real_ip_from の設定
- X-Forwarded-For の扱い
- CDN側でのIP制限
- WAFでの制御
- VPNや認証との併用

また、IPv6を利用している環境では、IPv6アドレスの許可・拒否も忘れないようにしましょう。

DNS・IPv6・QUICへの対応

DNS制御も考慮する

ドメインベースのホワイトリストを行う場合、DNSの扱いも重要です。

以下の点を確認する必要があります。

- 社内DNSで正しく名前解決できるか
- DNSログを取得しているか
- 外部DNSの利用を制限するか
- DNS over HTTPSを許可するか
- プロキシログとDNSログを突合できるか

特にDNS over HTTPSを許可している場合、端末が外部DNSを使い、社内DNSポリシーを迂回する可能性があります。

プロキシ制御とDNS制御は、あわせて設計することが重要です。

IPv6の抜け道に注意する

IPv4では制限できていても、IPv6側で制御が漏れているケースがあります。

たとえば、以下のような問題です。

- IPv4ではブロックされるがIPv6では通る
- IPv6のファイアウォールルールが未設定
- AAAAレコード経由で意図しない通信が発生する
- IPv6のログ監視ができていない

社内ネットワークやクラウド環境でIPv6が有効な場合は、IPv4と同じようにIPv6のホワイトリストやログ監視も設計しましょう。

QUIC・HTTP/3への対応を検討する

近年のWeb通信では、HTTP/3やQUICが使われることがあります。

QUICはUDP/443を利用するため、従来のTCP/443を前提としたプロキシ制御では扱いに注意が必要です。

企業ネットワークでは、以下のような対応が検討されます。

- UDP/443をブロックしてTCP/443へフォールバックさせる
- QUICに対応したSWGを利用する
- HTTP/3を許可する対象を限定する
- ログ取得や可視化の方法を確認する

Webアクセス制御を厳格に行う場合は、TCP/443だけでなくUDP/443の扱いも確認しておくと安全です。

ホワイトリスト設定の運用ルール

追加申請フローを用意する

ホワイトリスト運用では、現場から「このサイトを使いたい」という申請が発生します。

その場で安易に許可すると、不要な通信先が増えてしまいます。

そのため、追加申請フローを用意しておくことが重要です。

申請項目の例は以下の通りです。

- 利用したいサービス名
- URL
- 利用目的
- 利用部署
- 利用者
- 利用期間
- 取り扱う情報
- 代替手段の有無
- 公式ドキュメント
- 承認者

一時許可には期限を付ける

一時的に許可した通信先が放置されると、セキュリティリスクになります。

そのため、一時許可には必ず期限を設定します。

例は以下の通りです。

- プロジェクト期間中のみ許可
- 検証期間の1週間だけ許可
- 取引先との契約期間中のみ許可
- 期限到来時に自動削除または再承認

期限付きの運用にすることで、不要な許可ルールが残りにくくなります。

定期的に棚卸しする

ホワイトリストは、一度作って終わりではありません。

定期的な棚卸しが必要です。

見直すべきポイントは以下のとおりです。

- 利用されていない許可ルールはないか
- 期限切れの一時許可が残っていないか
- 退職者や異動者の権限が残っていないか
- ワイルドカード許可が増えすぎていないか
- 公式ドキュメント上の必要ドメインが変わっていないか
- SaaSの利用状況と許可リストが一致しているか

少なくとも四半期ごと、または半年ごとに見直すと管理しやすくなります。

ログ監査を行う

ホワイトリストに登録されている通信先でも、必ず安全とは限りません。

許可済みの通信であっても、以下のような異常がないか確認する必要があります。

- 深夜や休日の大量アクセス
- 通常利用しない部署からのアクセス
- 大量ダウンロード
- 大量アップロード
- 短時間に多数の接続
- 不審なAPI通信
- 個人クラウドストレージへのアクセス

ホワイトリストに入っているから安全、ではなく、許可後の監視も重要です。

ホワイトリスト設定で避けたい失敗

とりあえず広く許可してしまう

トラブル対応で、以下のように広く許可しすぎるケースがあります。

*.google.com
*.amazonaws.com
*.cloudfront.net
*.azure.com

一時対応として必要な場合もありますが、そのまま放置するとリスクになります。

広く許可した場合は、後から必ず範囲を見直しましょう。

許可理由を記録していない

半年後に設定を見たとき、なぜそのドメインを許可しているのか分からない状態は危険です。

以下の情報は必ず記録しましょう。

- 誰が申請したか
- 誰が承認したか
- 何の業務で使うのか
- どの部署が使うのか
- いつまで必要なのか

許可理由が不明なルールは、棚卸し時に判断できなくなります。

ログに出た通信をすべて許可する

ブロックログに表示されたドメインをすべて追加すると、不要な通信まで許可してしまいます。

特にWebページには、広告、解析、外部フォント、SNS埋め込み、トラッキングタグなど、多数の外部通信が含まれることがあります。

そのため、ログは参考にしつつ、業務上必要な通信かどうかを確認してから許可することが重要です。

テストせずに全社展開する

ホワイトリスト設定は業務影響が大きい設定です。

テストなしで全社展開すると、以下のような問題が起こる可能性があります。

- 業務システムにログインできない
- メールや会議ツールが使えない
- OSやセキュリティソフトが更新できない
- 広告や解析ツールが使えない
- 取引先API連携が止まる

必ず小規模にテストし、ログを確認してから展開しましょう。

導入前のチェックリスト

技術面のチェック項目

□ フォワードプロキシかリバースプロキシか整理したか
□ 制御対象の通信方向を明確にしたか
□ ドメイン、IP、URL、ポートのどれで制御するか決めたか
□ HTTPS通信の扱いを決めたか
□ SSL/TLSインスペクションの対象範囲を決めたか
□ SNIベース制御の限界を理解しているか
□ DNS制御も考慮しているか
□ IPv6の制御漏れがないか
□ QUIC・HTTP/3の扱いを決めたか
□ CDNやクラウドサービスのIP変動を考慮しているか

運用面のチェック項目

□ 業務に必要なサービスを洗い出したか
□ 公式ドキュメントで必要通信先を確認したか
□ 部署別・ユーザー別のルールを設計したか
□ 申請・承認フローを用意したか
□ 一時許可に期限を設定する運用にしたか
□ 許可理由を管理台帳に記録するか
□ ブロックログを確認する体制があるか
□ ユーザーからの問い合わせ窓口を用意したか
□ 定期棚卸しの頻度を決めたか
□ ロールバック手順を用意したか

まとめ

プロキシサーバーのホワイトリスト設定は慎重な設計が必要

プロキシサーバーのホワイトリスト設定は、許可した通信だけを通すことでセキュリティを高める仕組みです。

ブラックリスト方式よりも厳格な制御ができるため、重要な端末や社内システム、教育機関、金融・医療など高いセキュリティが求められる環境で有効です。

一方で、設定が不十分だと、業務に必要なSaaS、API、認証、CDN、更新通信まで止めてしまう可能性があります。

運用まで含めて設計することが重要

ホワイトリスト設定で特に重要なのは、以下の点です。

- 業務に必要な通信先だけを許可する
- SaaSの認証、API、CDN、ストレージ通信も確認する
- HTTPS通信ではURLパス制御に限界があることを理解する
- SSL/TLSインスペクションは慎重に設計する
- ワイルドカード許可を乱用しない
- IPアドレス許可はSaaSやCDNでは注意する
- DNS、IPv6、QUICも考慮する
- 申請、承認、期限管理、棚卸しの運用を整える

ホワイトリスト設定は、単なる技術設定ではありません。

技術設定、業務要件、セキュリティポリシー、運用ルールをセットで設計することが、安定したプロキシ運用のポイントです。

以上、プロキシサーバーのホワイトリスト設定についてでした。

最後までお読みいただき、ありがとうございました。