SSLプロキシとはなんなのか

SSLプロキシとは、HTTPSなどのSSL/TLSで暗号化された通信を中継するプロキシのことです。

特に企業や学校などのネットワークでは、ユーザーの端末とWebサイトの間に入り、暗号化された通信を必要に応じて復号し、内容を検査したうえで、再び暗号化して送信する仕組みとして使われます。

現在のWeb通信の多くはHTTPSです。

HTTPSでは通信内容が暗号化されるため、通常のネットワーク機器からは、通信の中身を簡単には確認できません。

SSLプロキシは、この暗号化通信をセキュリティ目的で可視化・制御するために使われます。

ただし、厳密には現在使われているのは古いSSLではなくTLSです。

そのため、技術的には「TLSプロキシ」や「TLSインスペクション」と呼ぶ方が正確です。

しかし実務上は今でも「SSLプロキシ」「SSLインスペクション」「SSL復号」と呼ばれることが多くあります。

プロキシとは何か

プロキシは通信の代理をする仕組み

プロキシとは、ユーザーの端末とWebサイトの間に入り、ユーザーの代わりに通信を行うサーバーのことです。

通常、ユーザーがWebサイトにアクセスする場合、ユーザーのブラウザはWebサイトへ直接通信します。

一方、プロキシを使う場合は、ユーザーの通信がいったんプロキシサーバーを経由し、そのプロキシサーバーがWebサイトへアクセスします。

つまり、プロキシは「通信の代理人」のような役割を持ちます。

プロキシが使われる目的

プロキシは、企業や学校、公共機関、セキュリティ製品などでよく使われます。

主な目的は、Webアクセスの制御、ログの取得、危険サイトへのアクセス防止、マルウェア対策、社内ネットワークの保護、通信経路の管理などです。

たとえば、企業では社員が危険なWebサイトにアクセスしないように制限したり、業務に不要なサイトへのアクセスを管理したりするためにプロキシが使われます。

SSLプロキシの基本的な仕組み

HTTPS通信を中継する

SSLプロキシは、通常のプロキシの中でも、特にHTTPS通信を扱うものです。

HTTPSでは、ユーザーのブラウザとWebサイトの間で暗号化通信が行われます。

暗号化されているため、途中のネットワーク機器は通信内容をそのまま読むことができません。

SSLプロキシは、このHTTPS通信の途中に入り、通信を中継します。

通信を2本に分ける

SSLプロキシが復号検査を行う場合、HTTPS通信は実質的に2本に分かれます。

1本目は、ユーザーのブラウザとSSLプロキシの間の通信です。

2本目は、SSLプロキシとWebサイトの間の通信です。

ユーザーから見るとWebサイトに接続しているように見えますが、実際にはSSLプロキシが間に入り、それぞれ別の暗号化通信を確立しています。

この仕組みにより、SSLプロキシはユーザーから受け取った通信をいったん復号し、内容を確認したうえで、Webサイトへ再暗号化して送ることができます。

すべてのHTTPSプロキシが復号するわけではない

ここで注意したいのは、HTTPS通信を扱うプロキシがすべて通信内容を復号するわけではない、という点です。

HTTPSプロキシには、暗号化された通信をそのまま通すだけのものもあります。

この場合、プロキシは通信の中身を見ず、ブラウザとWebサイトの間の暗号化通信をトンネルのように中継します。

一方、SSLプロキシやSSLインスペクションと呼ばれるものは、通信をいったん復号して検査することがあります。

そのため、「HTTPSプロキシ」と「SSLプロキシ」は似ていますが、必ずしも同じ意味ではありません。

SSLプロキシが通信内容を確認できる理由

SSLプロキシが暗号化通信の終端になる

通常のHTTPS通信では、暗号化通信の相手はWebサイトです。

ユーザーのブラウザは、Webサイトの証明書を確認し、そのWebサイトと暗号化通信を行います。

しかし、SSLプロキシが復号検査を行う場合、ユーザーのブラウザから見た暗号化通信の相手は、実際にはSSLプロキシになります。

つまり、ユーザーの端末とSSLプロキシの間で一つのTLS通信が作られ、SSLプロキシとWebサイトの間でも別のTLS通信が作られます。

このように、SSLプロキシが通信の終端になるため、通信内容を復号して確認できるのです。

正規の中間者型通信

SSLプロキシの仕組みは、技術的には中間者型の通信に近い構造です。

ただし、企業や学校などが管理端末に正規の証明書を配布し、セキュリティポリシーに基づいて運用している場合は、攻撃ではなく管理目的のTLSインスペクションとして扱われます。

一方で、利用者に説明がないまま証明書をインストールさせたり、信頼できないWi-Fiや不審なソフトウェアが同様の仕組みを使ったりする場合は、重大なセキュリティリスクになります。

SSLプロキシと証明書の関係

HTTPSでは証明書が重要になる

HTTPSでは、WebサイトがSSL/TLS証明書を使って、自分が正規のサイトであることを証明します。

ブラウザは、証明書の発行元が信頼できるか、ドメイン名が一致しているか、有効期限が切れていないか、証明書が改ざんされていないかなどを確認します。

この確認が正常に行われることで、ユーザーは安全にWebサイトへアクセスできます。

SSLプロキシは独自の証明書を提示する

SSLプロキシがHTTPS通信を復号する場合、ユーザーのブラウザには本来のWebサイトの証明書ではなく、SSLプロキシが生成した証明書が提示されることがあります。

たとえば、Googleにアクセスしているのに、証明書の発行者が会社名やセキュリティ製品名になっている場合があります。

これは、企業や組織のSSLプロキシが通信を中継している可能性を示しています。

端末側にルート証明書が必要になる

SSLプロキシを正しく動作させるには、ユーザー端末がSSLプロキシの証明書を信頼している必要があります。

企業PCでは、管理者が社内のルート証明書を端末に配布していることがあります。

これにより、ブラウザはSSLプロキシが発行した証明書を信頼し、証明書エラーを出さずに通信できます。

逆に、この証明書が端末に入っていない場合、ブラウザに「証明書が信頼できません」「この接続ではプライバシーが保護されません」といった警告が表示されることがあります。

SSLプロキシの主な目的

マルウェア対策

現在では、危険なWebサイトやマルウェア配布サイトもHTTPSを使うことが一般的です。

HTTPSだから安全というわけではありません。

攻撃者もHTTPSを利用できます。

SSLプロキシを使うと、暗号化された通信の中に含まれる不審なファイル、危険なスクリプト、マルウェア通信などを検査し、必要に応じてブロックできます。

企業ネットワークでは、端末をマルウェア感染から守るためにSSLプロキシが使われることがあります。

フィッシング対策

フィッシングサイトもHTTPS化されていることが多くあります。

見た目が本物そっくりで、URLにも鍵マークが表示されているため、利用者が安全なサイトだと誤解してしまう場合があります。

SSLプロキシは、アクセス先のURLやページ内容、証明書情報、送信先などを確認し、危険なサイトへのアクセスをブロックするために使われます。

情報漏えい対策

企業では、社員が意図せず、または意図的に社内情報を外部へ送信してしまうリスクがあります。

たとえば、顧客リスト、契約書、見積書、個人情報、ソースコード、社内資料などが外部のクラウドサービスへアップロードされる可能性があります。

通常のHTTPS通信では中身が暗号化されているため、ネットワーク機器からは内容を確認しにくいです。

SSLプロキシを使うと、通信内容を復号し、DLPと呼ばれる情報漏えい防止の仕組みと連携して、機密情報の送信を検出・制御できます。

Webアクセス制御

企業や学校では、特定カテゴリのWebサイトへのアクセスを制限することがあります。

たとえば、マルウェア配布サイト、違法ダウンロードサイト、ギャンブルサイト、アダルトサイト、匿名プロキシサイト、業務に関係のないストレージサービスなどです。

SSLプロキシを使うことで、HTTPSサイトであってもカテゴリやURL、通信内容に基づいてアクセスを許可・拒否しやすくなります。

ログ取得と監査

セキュリティ事故が発生した場合、いつ、誰が、どのサイトにアクセスしたのかを確認する必要があります。

SSLプロキシは、アクセス日時、ユーザー名、端末名、アクセス先、通信量、ブロック理由、脅威検知結果などのログを残すために使われることがあります。

ただし、実際にどこまでログを残すかは、製品や設定、組織のポリシーによって異なります。

クラウドサービス利用の可視化

企業では、社員がさまざまなクラウドサービスを利用します。

Google Drive、OneDrive、Dropbox、Box、Slack、Notion、GitHub、ChatGPTなど、業務に使われるサービスは多岐にわたります。

SSLプロキシやCASBと呼ばれる仕組みを組み合わせることで、どのクラウドサービスが利用されているか、どのようなデータが送信されているかを把握しやすくなります。

SSLプロキシの種類

フォワードプロキシ型

フォワードプロキシ型は、ユーザー側の通信を中継するタイプです。

企業や学校のネットワークでよく使われるのはこのタイプです。

社内ユーザーがインターネットへアクセスする際、SSLプロキシを経由して通信します。

一般的に「SSLプロキシ」と言う場合、このフォワードプロキシ型のSSL/TLSインスペクションを指すことが多いです。

リバースプロキシ型

リバースプロキシ型は、WebサイトやWebアプリケーションの前段に置かれるタイプです。

外部ユーザーからのアクセスをリバースプロキシが受け取り、その後ろにあるWebサーバーへ通信を転送します。

この仕組みは、ロードバランサー、WAF、CDN、Nginx、Apache、F5、Cloudflare、AWS CloudFrontなどで使われます。

広い意味では、リバースプロキシもTLS通信を終端するSSL/TLSプロキシ的な役割を持ちます。

ただし、実務上は「SSLプロキシ」と言うと、ユーザー側に置くフォワードプロキシを指すことが多いです。

透過型プロキシ

透過型プロキシは、ユーザーが明示的にプロキシ設定をしなくても、ネットワーク側で自動的に通信をプロキシへ流す方式です。

利用者は通常どおりWebサイトにアクセスしているつもりでも、ネットワーク機器が通信をプロキシへ転送します。

企業や学校の管理されたネットワークで使われることがあります。

ただし、HTTPS通信を復号する場合は、端末側でプロキシの証明書を信頼している必要があります。

明示型プロキシ

明示型プロキシは、ブラウザやOSにプロキシサーバーの設定を明示的に入れる方式です。

企業では、管理者が端末管理ツールやグループポリシー、MDMなどを使ってプロキシ設定を配布することがあります。

PACファイルと呼ばれる自動構成ファイルを使い、アクセス先に応じてどのプロキシを使うかを制御することもあります。

SSLプロキシとVPNの違い

SSLプロキシはWeb通信の制御が主目的

SSLプロキシは、主にWeb通信、特にHTTPS通信を中継・検査・制御するための仕組みです。

目的は、マルウェア対策、情報漏えい対策、アクセス制御、ログ取得などです。

企業や学校のネットワークで、利用者のWebアクセスを安全に管理するために使われます。

VPNは安全な通信経路を作る仕組み

VPNは、ユーザー端末とVPNサーバーの間に暗号化された通信経路を作る仕組みです。

リモートワークで社内ネットワークへ接続したり、拠点間を安全につないだりするために使われます。

VPNは通信経路を暗号化するための仕組みであり、必ずしも通信内容を検査するためのものではありません。

役割が異なる

SSLプロキシは「Web通信を中継して管理・検査する仕組み」です。

VPNは「安全な通信トンネルを作る仕組み」です。

どちらも通信の中間に関わる技術ですが、目的と役割は異なります。

SSLプロキシとSSLオフロードの違い

SSLオフロードとは

SSLオフロードとは、Webサーバーの代わりにロードバランサーやリバースプロキシがTLS処理を担当することです。

Webサーバー自身がTLSの暗号化・復号処理を行わず、前段の機器がその処理を引き受けます。

これにより、Webサーバーの負荷を軽減したり、証明書管理を一元化したりできます。

SSLプロキシとの違い

SSLプロキシは広い意味では、SSL/TLS通信を中継するプロキシ全般を指します。

一方、SSLオフロードは、Webサーバー側でTLS処理を肩代わりする構成を指すことが多いです。

企業ネットワークで使われるSSLプロキシは、主にユーザー側の通信を検査するフォワードプロキシです。

SSLオフロードは、主にWebサイト側の負荷分散やTLS終端の文脈で使われます。

SSLプロキシのメリット

暗号化通信内の脅威を検出できる

現在のWeb通信はほとんどがHTTPSです。

そのため、HTTPS通信をまったく検査できない場合、セキュリティ機器は通信の多くを十分に確認できません。

SSLプロキシを使うことで、暗号化通信内に隠れたマルウェア、フィッシング、危険なファイル、不審な通信などを検出しやすくなります。

セキュリティポリシーを適用しやすい

企業では、部署やユーザーごとに異なるアクセスルールを設定したい場合があります。

たとえば、一般社員には個人用ストレージへのアップロードを禁止し、開発部門にはGitHubの利用を許可し、経理部門には特定の金融サイトへのアクセスを許可するといった運用です。

SSLプロキシを使うと、ユーザー、グループ、端末、アクセス先カテゴリなどに応じてポリシーを適用しやすくなります。

インシデント調査に役立つ

セキュリティ事故が起きたとき、ログがないと原因調査が難しくなります。

SSLプロキシのログがあれば、どの端末が危険サイトへアクセスしたのか、どのファイルをダウンロードしたのか、どの外部サービスへデータを送信したのかを確認しやすくなります。

これにより、被害範囲の特定や再発防止策の検討に役立ちます。

クラウド利用を把握しやすい

企業では、管理部門が把握していないクラウドサービスが使われることがあります。

このような利用はシャドーITと呼ばれます。

SSLプロキシを使うことで、どのクラウドサービスが利用されているか、どの程度通信が発生しているかを可視化しやすくなります。

SSLプロキシのデメリットと注意点

プライバシーへの影響がある

SSLプロキシは、設定によってはHTTPS通信の内容を復号できます。

そのため、個人情報、ログイン情報、フォーム入力内容、Cookie、ファイル内容など、機微な情報が見える可能性があります。

企業や学校で導入する場合は、何を検査するのか、何を検査しないのか、ログに何を残すのか、誰がログを見られるのかを明確にする必要があります。

特に、金融、医療、行政、個人メール、決済、パスワード管理サービスなどは、復号対象から除外する設計が検討されることがあります。

証明書エラーが発生することがある

SSLプロキシを使うには、端末がプロキシの証明書を信頼している必要があります。

証明書が正しく配布されていない場合、ブラウザに証明書エラーが表示されることがあります。

企業PCでは管理者が証明書を配布しますが、個人端末や持ち込み端末ではエラーが発生しやすい場合があります。

一部のアプリが動作しないことがある

一部のアプリは、特定の証明書や公開鍵だけを信頼する証明書ピンニングという仕組みを使っています。

この場合、SSLプロキシが別の証明書を提示すると、アプリが通信を拒否することがあります。

銀行アプリ、決済アプリ、セキュリティアプリ、一部のモバイルアプリ、開発者向けツール、APIクライアントなどで問題が出ることがあります。

なお、ブラウザ向けのHPKPという仕組みは現在ほぼ廃止されていますが、アプリ独自の証明書ピンニングは今でも使われることがあります。

パフォーマンスに影響する

SSLプロキシは、通信を復号し、内容を検査し、再び暗号化します。

そのため、処理負荷が高くなりやすく、利用者数や通信量が多い環境ではパフォーマンスに影響することがあります。

特に動画、大容量ファイル、クラウドストレージ、オンライン会議などの通信が多い環境では、プロキシ側の処理能力や設計が重要になります。

SSLプロキシ自体が重要な信頼点になる

SSLプロキシは、暗号化通信を復号できる強い権限を持ちます。

そのため、SSLプロキシ自体が侵害されたり、秘密鍵が漏えいしたり、ログ管理が不適切だったりすると、大きなリスクになります。

管理者権限の制限、証明書秘密鍵の保護、ログ閲覧権限の管理、監査ログの取得、定期的な設定レビューなどが重要です。

SSLプロキシで見える可能性がある情報

復号対象の通信では詳細情報が見える場合がある

SSLプロキシが復号対象にしている通信では、設定次第でさまざまな情報を確認できます。

たとえば、アクセスしたURL、Webページの内容、HTTPヘッダー、Cookie、フォーム送信内容、ダウンロードファイル、アップロードファイル、API通信内容などです。

ただし、実際にどの情報を検査し、どの情報をログに保存するかは、製品や設定、組織のポリシーによって異なります。

復号していない通信でも一部情報は見える

SSLプロキシが通信内容を復号していない場合でも、ネットワーク機器から接続先IPアドレス、通信時刻、通信量、接続先ドメインの一部などが見える場合があります。

ただし、最近はTLSやDNSまわりのプライバシー保護技術も進んでおり、見える情報は環境やプロトコルによって変わります。

すべての通信内容が必ず見えるわけではない

SSLプロキシがあるからといって、すべてのHTTPS通信が必ず見られるわけではありません。

復号対象から除外されている通信、証明書ピンニングで拒否される通信、プロキシを経由しないアプリ通信、QUICやHTTP/3への対応状況によって、見える範囲は変わります。

QUIC・HTTP/3との関係

QUICは従来のプロキシと相性が悪い場合がある

最近のブラウザやWebサービスでは、HTTP/3という新しい通信方式が使われることがあります。

HTTP/3はQUICというUDPベースのプロトコルを使います。

従来のHTTPS通信は主にTCP上のTLSを使っていましたが、QUICは仕組みが異なるため、従来型のプロキシやSSLインスペクションと相性が悪い場合があります。

企業環境ではQUICを制御することがある

企業ネットワークでは、SSLインスペクションやWebフィルタリングを正しく行うために、QUICをブロックし、通常のTCPベースのHTTPSへフォールバックさせる設定が使われることがあります。

そのため、SSLプロキシを設計する場合は、HTTP/3やQUICへの対応も考慮する必要があります。

SSLプロキシが使われる場面

企業ネットワーク

SSLプロキシが最もよく使われるのは企業ネットワークです。

社員のPCからインターネットへ出るHTTPS通信を検査し、マルウェア対策、情報漏えい対策、フィッシング対策、アクセス制御、ログ監査などに活用します。

特に、クラウドサービスの利用が増えている企業では、SSLプロキシやSASE、CASBといった仕組みが組み合わされることがあります。

学校や大学

学校や大学では、学生や教職員の端末から危険サイトや不適切サイトへのアクセスを制限するために使われることがあります。

また、教育用端末を安全に管理するために、SSLプロキシやWebフィルタリングが導入される場合があります。

セキュリティ製品

次世代ファイアウォール、UTM、Webセキュリティゲートウェイ、SASE、CASB、EDR、アンチウイルスソフトなどには、SSLインスペクション機能が含まれている場合があります。

代表的なベンダーとして、Zscaler、Palo Alto Networks、Fortinet、Cisco、Check Point、Netskope、Broadcom/Symantecなどがあります。

Webサービスの前段

Webサイト側では、CDN、WAF、ロードバランサー、リバースプロキシなどがTLS終端を行うことがあります。

この場合、ユーザーの通信はWebサーバーへ直接届くのではなく、まずリバースプロキシやCDNに届き、その後オリジンサーバーへ転送されます。

これは企業内のSSLインスペクションとは目的が異なりますが、TLS通信を中継・終端するという意味では関連する仕組みです。

公共Wi-Fiでの注意点

通常の公共Wi-FiはHTTPSの中身を勝手に復号できない

カフェ、ホテル、空港などの一般的な公共Wi-Fiは、通常、HTTPS通信の中身を勝手に復号することはできません。

HTTPS通信はブラウザとWebサイトの間で暗号化されているため、Wi-Fiの運営者がそのまま中身を読むことは困難です。

ルート証明書のインストールを求められたら注意

公共Wi-Fiや不審なサービスが、ルート証明書のインストールを求めてきた場合は注意が必要です。

その証明書を信頼してしまうと、その証明書を使ってHTTPS通信を中継・復号される可能性があります。

信頼できない相手のルート証明書をインストールすることは、非常に大きなリスクになります。

企業や学校の管理端末で、正規の管理ポリシーに基づいて証明書が配布される場合と、公共の場で不明な証明書を入れさせられる場合は、まったく意味が異なります。

SSLプロキシを使っているか確認する方法

証明書の発行者を確認する

ブラウザでHTTPSサイトを開き、証明書情報を確認すると、SSLプロキシが使われているかどうかを推測できる場合があります。

たとえば、GoogleやMicrosoftなどのサイトにアクセスしているのに、証明書の発行者が会社名やセキュリティ製品名になっている場合、SSLプロキシが通信を中継している可能性があります。

会社PCと個人PCで比較する

同じWebサイトを会社PCと個人PCで開き、証明書の発行者を比較する方法もあります。

会社PCだけ証明書の発行者が異なる場合、会社のSSLプロキシやセキュリティ製品が通信を検査している可能性があります。

OSやブラウザの証明書ストアを確認する

Windows、macOS、ブラウザには、信頼されたルート証明書を管理する場所があります。

そこに会社名、セキュリティ製品名、プロキシ製品名などの証明書が登録されていれば、SSLインスペクション用の証明書である可能性があります。

プロキシ設定を確認する

OSやブラウザのネットワーク設定を見ると、プロキシサーバーやPACファイルが設定されている場合があります。

企業PCでは、管理者が自動的に設定していることも多いため、ユーザーが手動で設定した覚えがなくてもプロキシが使われている場合があります。

SSLプロキシは危険なのか

適切に運用されていれば有効なセキュリティ対策になる

SSLプロキシは、適切に運用されていれば、企業や学校のセキュリティを高めるために有効な仕組みです。

暗号化通信に隠れたマルウェアやフィッシング、情報漏えいを検出しやすくなり、セキュリティ事故の予防や調査にも役立ちます。

不適切な運用は大きなリスクになる

一方で、SSLプロキシは暗号化通信を復号できる強い権限を持つため、不適切に運用されるとプライバシーやセキュリティの問題につながります。

利用者への説明がない、復号対象が広すぎる、ログの閲覧権限が緩い、証明書管理が不適切、個人情報性の高い通信まで無差別に復号する、といった運用は避けるべきです。

信頼できない証明書は入れない

特に重要なのは、信頼できない相手のルート証明書を端末にインストールしないことです。

ルート証明書を信頼するということは、その証明書を使って多くのHTTPS通信を信頼できるものとして扱う、という意味を持ちます。

不審なWi-Fi、不明なアプリ、怪しいWebサイトから証明書のインストールを求められた場合は、安易に許可しない方が安全です。

SSLプロキシ導入時の設計ポイント

復号対象を明確にする

SSLプロキシを導入する際は、どの通信を復号するのかを明確にする必要があります。

すべてのHTTPS通信を無差別に復号するのではなく、リスクの高いカテゴリや業務上必要な範囲に絞ることが重要です。

金融、医療、行政、決済、個人メール、パスワード管理サービスなどは、復号除外を検討することがあります。

利用者へ説明する

SSLプロキシはプライバシーに関わる仕組みです。

そのため、導入目的、検査対象、ログの保存内容、ログ閲覧者、除外対象、問い合わせ窓口などを利用者へ説明することが望ましいです。

透明性のある運用は、利用者とのトラブルを防ぐうえでも重要です。

証明書を安全に配布する

SSLプロキシ用のルート証明書は、MDM、グループポリシー、端末管理ツールなどを使って安全に配布するのが一般的です。

ユーザーに手動で証明書を入れさせる運用は、誤操作や不正証明書の混入リスクがあるため注意が必要です。

除外設定を丁寧に作る

SSLプロキシでは、除外設定が非常に重要です。

OSアップデート、セキュリティソフトの通信、金融系サイト、医療系サイト、決済系サイト、証明書ピンニングがあるアプリ、開発者向けツールなどは、復号すると不具合が出る場合があります。

業務影響を避けるためにも、除外ルールを丁寧に設計する必要があります。

ログ管理を厳格にする

SSLプロキシのログには、機微な情報が含まれる可能性があります。

誰がログを閲覧できるのか、どのくらい保存するのか、どの情報をマスキングするのか、監査ログを残すのかを明確にする必要があります。

ログはセキュリティ調査に役立つ一方で、管理を誤るとプライバシーリスクになります。

Webマーケティング視点での影響

アクセス元IPが実ユーザーと異なる場合がある

企業ネットワークからのアクセスは、個々のユーザー端末ではなく、企業のプロキシやゲートウェイのIPアドレスから来ているように見える場合があります。

そのため、アクセス解析では同一IPから大量アクセスが発生しているように見えることがあります。

地域判定がずれることがある

プロキシサーバーの設置場所によって、実際のユーザー所在地とアクセス解析上の地域がずれることがあります。

たとえば、大阪のユーザーがアクセスしていても、東京のデータセンター経由に見える場合があります。

地域別分析や広告配信の評価では、このような影響を考慮する必要があります。

計測タグがブロックされる場合がある

企業のセキュリティ製品やSSLプロキシが、広告タグ、トラッキングスクリプト、サードパーティCookie、計測ピクセル、外部CDN、チャットウィジェット、ヒートマップツールなどを制限する場合があります。

そのため、BtoBサイトでは、企業ユーザーの行動データが一部取得できないことがあります。

A/Bテストやパーソナライズに影響することがある

SSLプロキシやセキュリティ製品がスクリプトやCookieを制御している場合、A/Bテストツールやパーソナライズツールが正常に動作しないことがあります。

特に、金融、医療、製造業、官公庁、大企業向けのBtoBサイトでは、企業ネットワーク経由のアクセスが多いため、計測値に影響が出る可能性があります。

似た用語との違い

SSLプロキシ

SSL/TLSで暗号化された通信を中継するプロキシです。

企業ネットワークでは、HTTPS通信を復号・検査・再暗号化するフォワードプロキシ型の仕組みを指すことが多いです。

SSLインスペクション

SSL/TLS通信の中身を検査する機能です。

SSLプロキシの主な用途の一つです。

現在の技術的な表現としては、TLSインスペクションの方が正確です。

HTTPSプロキシ

HTTPS通信を扱うプロキシです。

ただし、必ずしも通信内容を復号するとは限りません。

暗号化された通信をそのままトンネルするだけのHTTPSプロキシもあります。

TLS終端

TLS通信を、Webサーバーではなくプロキシ、ロードバランサー、CDN、WAFなどで終端することです。

Webサイト側の構成でよく使われます。

SSLオフロード

Webサーバーの代わりに、ロードバランサーやリバースプロキシがTLS処理を担当することです。

Webサーバーの負荷軽減や証明書管理の一元化が目的です。

WAF

WAFはWeb Application Firewallの略で、Webアプリケーションを攻撃から守る仕組みです。

リバースプロキシ型で動作することが多く、SQLインジェクションやクロスサイトスクリプティングなどの攻撃を検出・防御します。

CASB

CASBはCloud Access Security Brokerの略で、クラウドサービスの利用を可視化・制御する仕組みです。

SSLプロキシやAPI連携と組み合わせて使われることがあります。

SASE

SASEは、ネットワークとセキュリティ機能をクラウドで統合する考え方やサービス群です。

Webセキュリティ、ゼロトラスト、CASB、DLP、SSLインスペクションなどを含む場合があります。

まとめ

SSLプロキシとは、HTTPSなどのSSL/TLS暗号化通信を中継するプロキシです。

企業ネットワークでは、ユーザー端末とWebサイトの間に入り、通信を復号・検査・再暗号化することで、マルウェア対策、フィッシング対策、情報漏えい対策、アクセス制御、ログ監査などに使われます。

ただし、SSLプロキシがあるからといって、すべてのHTTPS通信が必ず復号されるわけではありません。

復号対象、証明書設定、製品仕様、除外ルール、アプリの仕様、QUICやHTTP/3への対応状況によって、見える範囲は変わります。

また、SSLプロキシは強力なセキュリティ対策である一方、プライバシーや証明書管理、ログ管理、アプリ互換性に関する注意点もあります。

一言でまとめると、SSLプロキシは「暗号化されたWeb通信を、セキュリティ管理のために中継・検査する仕組み」です。

正しく設計・運用されれば有効な防御策になりますが、不適切に使われるとプライバシーやセキュリティのリスクにもなります。

以上、SSLプロキシとはなんなのかについてでした。

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