フォワードプロキシ認証の課題 – LDAP / Basic 認証 / HTTPS プロキシ / SAML・OIDC の整理

フォワードプロキシに認証を入れると、一見すると「ユーザー単位で外部通信を制御できる」ように見えます。しかし、実際にはプロキシ認証、HTTP CONNECT、HTTPS、ブラウザ実装、LDAP、SAML/OIDC の責務が重なり、思ったほど単純ではありません。

前提となる構成

ここで考えるのは、特定のインターネット上のサイトへアクセスする際に、送信元 IP 制限を満たすため、クライアント通信を特定のフォワードプロキシへ誘導する構成です。PAC ファイルを配布し、対象 URL だけプロキシを経由させる形は一般的です。

プロキシ認証で実現したいこと

ネットワーク的には特定セグメントからのアクセスだけを許可していても、さらにユーザー単位で認証したい、という要件は自然です。LDAP に登録されているユーザーを使いたい、認証情報を平文で流したくない、という発想も妥当です。

• プロキシへの接続元ネットワークを限定する。
• 利用者を LDAP ユーザーで認証する。
• 認証情報を途中経路で読まれないようにする。
• URL 単位でプロキシ経由の有無を制御する。

LDAP 認証の限界

Apache や Squid で LDAP 認証を使うこと自体は可能です。ただし、多くの場合は Basic 認証として扱われます。Basic 認証の認証情報は Base64 エンコードであり、暗号化ではありません。つまり、通信路が保護されていなければ、認証情報を守れているとは言えません。

HTTP と HTTPS でプロキシの意味が変わる

HTTP の場合、プロキシは HTTP リクエストを解釈できます。代理アクセスとして URL、ヘッダー、認証、制御を扱いやすい構造です。

Client --- HTTP --- Proxy --- HTTP --- Web Server

HTTPS の場合、通常のフォワードプロキシは CONNECT でトンネルを作ります。プロキシは宛先ホストとポートを見て中継しますが、TLS の中身は読めません。

Client --- CONNECT --- Proxy --- TCP Tunnel --- Web Server
Client === TLS ================================== Web Server

ここで重要なのは、宛先 Web サーバーとの HTTPS と、クライアントがプロキシへ送るプロキシ認証は別の文脈だという点です。宛先が HTTPS だからといって、プロキシ認証そのものが自動的に安全になるわけではありません。

HTTPS プロキシはブラウザで扱いにくい

理屈上は、クライアントとプロキシ間を HTTPS 化した「HTTPS プロキシ」にすれば、プロキシ認証の通信路を保護できます。curl などでは挙動を確認できる場合があります。

Client === HTTPS === Proxy --- CONNECT --- Web Server
Client === TLS ================================ Web Server

しかし、ブラウザ利用では期待通りに動かないことがあります。ブラウザはプロキシとの TLS と、宛先サイトとの TLS を同一の通信文脈で扱う際、実装上の制約や安全性判断により接続を拒否する場合があります。ここはプロキシ製品、ブラウザ、OS の実装差にも強く依存します。

SAML/OIDC はどこに置けるのか

SAML や OIDC は、Web アプリケーションの認証・認可には強力です。Keycloak のような IdP と連携すれば、LDAP を背後に置きつつ、現代的な認証基盤を作れます。

ただし、フォワードプロキシの認証にそのまま自然に適用できるわけではありません。SAML/OIDC はブラウザリダイレクト、トークン、セッションを前提とするため、HTTP CONNECT を中継するプロキシ認証とは責務が異なります。

本質的な課題

フォワードプロキシ認証の難しさは、「誰を認証するか」と「どの通信を制御するか」が混ざりやすい点にあります。プロキシは通信経路上の中継点であり、Web アプリケーションそのものではありません。

• ユーザー認証をしたいのか。
• 端末を識別したいのか。
• 送信元 IP を固定したいのか。
• URL 単位で通信を振り分けたいのか。
• 外部サービス側の許可条件を満たしたいのか。
• 認証情報を暗号化したいのか。

これらをまとめて「プロキシ認証」で解決しようとすると、構成が不自然になります。特に HTTPS が標準となった現在では、プロキシが見える情報は制限され、ブラウザや TLS の安全性判断にも制約されます。

設計としての落としどころ

現実的には、プロキシ認証だけに過度な意味を持たせず、複数の層で役割を分ける方が自然です。

まとめ

フォワードプロキシにおける認証は、見た目ほど単純ではありません。LDAP 認証を付ければユーザー認証はできますが、Basic 認証であれば通信路保護が問題になります。HTTPS プロキシで暗号化しようとしても、ブラウザ実装や CONNECT の性質にぶつかることがあります。

SAML/OIDC は強力ですが、Web アプリケーション認証の仕組みであり、フォワードプロキシの認証にそのまま載せるものではありません。プロキシは通信経路、IdP は認証基盤、PAC は経路選択、ネットワーク制御は接続元制限として、責務を分けて設計する必要があります。

この問題の本質は、プロキシ認証を高度化することではなく、ユーザー、端末、通信経路、外部サービス側の制約をどの層で担保するかを分離することにあります。

Related posts:

LDAP より SAML/OIDC が高セキュリティという幻想 – 認証方式は適材適所で選ぶ NTP トラブル時に確認すること – chrony、ntpd、timesyncd の整理 Nextcloud SAML 認証で WebDAV が問題になる理由 CentOS 7 Apache TLS 設定 – 自己署名証明書で HTTPS 化する CentOS 7 Apache TLS 設定 – Let’s Encrypt で HTTPS 化する PEM 形式の証明書・秘密鍵を 1 行に整形する方法 – SAML や Kubernetes Secret で扱う時の注意点 Samba の SID と認証の整理 CentOS 7 LDAP クライアント設定 – authconfig と nslcd の LDAPS 接続 CentOS 8 389 Directory Server と Samba – LDAP スキーマ連携の基本 Ubuntu 22.04 389 Directory Server #1 – インスタンス作成と suffix 設計 Ubuntu 22.04 389 Directory Server #2 – TLS 有効化と LDAPS 設定 Ubuntu 22.04 OpenLDAP LDAP ユーティリティ – ldapsearch / ldapadd / ldapmodify の使い方