ProxyCompass ナレッジベース

プロキシ認証：IP許可リストとユーザー名・パスワードのどちらを選ぶ？

プロキシ認証は、アプリケーションがプロキシサービスを利用してよいかを確認する仕組みです。通常、プロキシのアドレスとポートを知っているだけでは利用できません。サービスに接続できるシステムのうち、許可されたクライアントを区別する必要があるためです。これにより、購入したプロキシを、利用を認めたクライアントだけが使えるようにします。

一般的な2つの方式は、確認に使う情報が異なります。IP認証では、プロキシは接続元を確認します。ユーザー名とパスワードによる認証では、アプリケーションが認証情報を送信します。前者はアクセス権限をネットワークアドレスに結び付けます。後者は、アプリケーションが別のネットワークに移ってもアクセスを維持できる方式です。サービスによっては、両方の条件を同時に満たす必要があります。

この選択は、接続方法、利用できるアプリケーション、作業環境が変わった際の挙動に影響します。プロキシの構成を選ぶ際に、独立して検討する項目です。認証方式は、出口IPがデータセンターか住宅用か、固定かローテーションかを決めるものではありません。そのIPを提供するサービスを誰が利用できるかを決めます。

2つの認証方式の仕組み

IP認証：接続元に対して利用を許可する

IP認証では、クライアントのアドレスを事業者の許可リストに追加します。このリストはホワイトリストや許可リストと呼ばれます。接続を受けると、プロキシは送信元IPをリストと照合します。一致し、サービスのほかのアクセス条件も満たしていれば、アプリケーションはプロキシ用のユーザー名とパスワードを別途送信せずに利用できます。

インターネット上のプロキシで通常必要なのは、利用するネットワークのパブリックな送信元IPです。これは、アプリケーションからプロキシに接続する際のアドレスであり、プロキシがその後ウェブサイトに示す出口IPではありません。固定IPプロキシを購入しても、自宅の回線のIPが固定になるわけではありません。経路上の異なる部分に属するアドレスだからです。

したがって、許可した送信元が変わらない間は、手軽にアクセスできます。プログラムを再起動したり、同じネットワークから別の許可された端末を接続したりする際に、それぞれのプロキシパスワードは必要ありません。送信元IPが変わると、以前の許可が新しいアドレスに自動で適用されることはありません。正しい送信元アドレスの調べ方と許可リストの管理方法は、IP認証ガイドで説明しています。

ユーザー名とパスワード：アプリケーションが認証情報を提示する

ユーザー名とパスワードによる認証では、事業者がプロキシ利用のための認証情報を発行します。アプリケーションは、対応するプロキシプロトコルの手順でその情報を送信します。ブラウザーは利用者に入力を求める場合があります。スクリプトなら、ログイン画面を表示せず、設定から読み取って送信できます。

認証情報だけが認証要件である場合、アプリケーションはネットワークを移ってもアクセスを維持できます。動作していた同じ設定で、新しい送信元IPから接続を続けられます。プロキシ設定よりも、タスクの実行場所のほうが頻繁に変わる場合に便利です。

この認証情報は、プロキシへの接続に使うものです。事業者の管理画面にログインするパスワードとは限らず、接続先ウェブサイトへのログインにもなりません。ウェブサイトでは、独自のログイン規則やアクセス規則が適用されます。接続設定の項目、対応クライアント、認証情報の書式は、ユーザー名とパスワードによる認証ガイドで説明しています。

IP認証とユーザー名・パスワード認証の比較

以下では、2つの方式を別々に比較します。ここでいうパスワードによるアクセスは、追加のIP制限がない方式です。併用方式については後で説明します。

どちらの方式も、サービスの出口IP数を決めるものではありません。許可された1つのクライアントIPや1組の認証情報で、多数のプロキシにアクセスできる場合があります。また、どちらを選んでも接続数が無制限になるわけではなく、出口アドレスが1人の利用者専用になるわけでもありません。

アプリケーションとネットワークに合う選び方

まず、アプリケーションが提供される方式を使えるか確認する

あるプロキシプロトコルに対応するプログラムでも、そのすべての認証方式に対応しているとは限りません。アドレス欄とポート欄があるだけでは、ユーザー名とパスワードを送信できるとは判断できません。例えば、Chrome内蔵のSOCKS5機能は、SOCKS5のユーザー名・パスワード認証に対応していません。認証情報が正しくても、クライアントにない機能を補うことはできません。

必要なアプリケーションが提供されるプロトコルには対応していても、認証情報を送信できない場合、IP認証なら利用できることがあります。ただし、送信元アドレスが許可されている必要があります。そのアドレスが頻繁に変わる場合、IP認証への切り替えで認証情報の問題は解決しても、送信元アドレスの管理は残ります。必要な認証に対応するクライアントや、安定したネットワーク出口が必要になる場合もあります。

したがって、購入前には「このアプリケーションで、この認証方式を使って、このプロキシプロトコルに接続できるか」を具体的に確認します。別のブラウザーやコマンドラインツールで成功しても、この問いへの答えにはなりません。

次に、構成の中で普段何が変わるかを考える

IP認証は、ネットワーク出口が安定していて管理できるタスクに適しています。その出口を許可すれば、背後のプログラムを変更しても、新しいプロセスごとにプロキシ認証情報を配布する必要はありません。サービスのアクセス設定は、タスクが使うネットワークに結び付いたままです。

認証情報を使う方式は、実行場所が変わるタスクに適しています。別のサーバーへの移動や、異なるネットワークからの新しいワーカーの起動でも、サービスがIPをひも付けない認証情報を受け付けるなら、送信元ごとに許可リストを変更する必要はありません。プロキシ設定をアプリケーションと一緒に移せます。

重要なのは、機器をノートパソコン、VPS、クラウドサーバーのどれと呼ぶかではなく、外向きの送信元がどの程度変わるかです。ノートパソコンが固定のオフィス出口を使い続けることも、サーバーの構成変更でパブリックアドレスが切り替わることもあります。実際の接続経路と、通常の作業で予想される変化に合わせて選びます。

両方使えるなら、管理しやすい方式を選ぶ

誰が設定を管理するかを考えます。複数のアプリケーションが共有する固定出口を管理するネットワーク管理者なら、1つの送信元に対する許可でアクセスを管理できます。環境間でタスクを移すものの、それぞれのパブリックIPを管理できない開発者には、IPをひも付けない認証情報のほうが扱いやすい場合があります。

その選択に必要な追加リソースも考慮します。固定パブリックIP、許可リストの追加枠、管理されたゲートウェイには費用がかかる場合があります。パスワードによるアクセスなら、その費用を避けられる可能性がありますが、必要なネットワークから使えることが前提です。実際のサービスの選択肢を比較してください。パスワードがあるだけでプロキシが安くなるわけではありません。

併用認証：IPとパスワード

事業者は、IPによるアクセスとパスワードによるアクセスを選択式にする場合も、両方を必須にする場合もあります。この2つは異なる構成です。併用モードでは、許可されたアドレスまたはネットワークから接続した場合にだけ、有効な認証情報が受け付けられます。正しいパスワードだけでも、許可された送信元だけでも不十分です。

これは、接続元を制限しながら、ユーザー名とパスワードの入力欄を必須とするアプリケーションを使う場合に適しています。コピーされた認証情報が、許可されたネットワークの外で使われることも制限できます。ただし、IPをひも付けないパスワード方式のように、任意のネットワークへ自由に移れるわけではありません。

ProxyCompassの固定IPパッケージでは、ホワイトリストに追加したIPと同じ/24サブネットにあるクライアントのパブリックIPv4から、有効な認証情報を使うと併用モードで接続できます。これらのアドレスは、先頭の3つの数値が同じです。そのため、1件のホワイトリスト登録で、同じサブネット内の複数のクライアントアドレスから認証情報を使えます。この規則はサービスに接続するクライアントに関するもので、購入した出口IPの規則ではありません。接続例は、前述のユーザー名・パスワード認証ガイドにあります。

どちらの方式がアクセスを管理しやすい？

IP認証は、ネットワーク出口を基準にアクセス可否を判断します。プロキシアドレスだけを入手した人は、別の許可されていない送信元からは利用できません。ただし、同じ許可済みIPを共有しているだけでは、プロキシは個々の人を識別できません。複数の利用者が同じパブリックアドレスを通る場合、IPの確認では全員が同じ送信元に見えます。オフィスの共有出口や、インターネット回線の契約者間で共有されるパブリックアドレスでは、この点が重要です。

ユーザー名とパスワードによる認証は、場所とは別にアプリケーションが提示できる認証情報にアクセス権限を持たせます。関連のないネットワークをまたぐ場合に便利です。一方、有効な認証情報を含む設定がコピーされると、ほかの場所でも利用できる可能性があります。事業者が利用者別やタスク別の認証情報を提供する場合は、アクセスを細かく管理できます。全員で1つのパスワードを共有しても、そのような区別は生まれません。

したがって、許可済みネットワーク出口の背後にあるシステム群と、アプリケーションへ渡す認証情報のどちらを確実に管理できるかで選びます。併用方式では両方が必要なため、認証情報が有効でも、利用できる接続元が制限されます。

アクセス制御と暗号化は別の問題です。IP認証は通信を暗号化せず、パスワードも自動的に暗号化接続を作るものではありません。転送中の認証情報を守るには、クライアントとプロキシ間の接続自体を保護する必要があります。プロキシ経由でHTTPSサイトを開くだけでは、それ以前にプロキシと行った暗号化されていないログイン情報の交換は保護されません。

IP認証ならプロキシは速くなる？

IPによるアクセスでは認証情報の交換を省けますが、接続確立の手順はHTTPとSOCKSで異なります。SOCKS5のユーザー名・パスワード認証では、接続確立時にリクエストと応答が1回ずつ追加されます。HTTPでは、認証要求を待ってリクエストを再送する場合も、最初から適切な認証情報を送信する場合もあります。したがって、パスワード方式で必ずネットワークの往復が増えるわけではありません。

この違いが最も影響するのは、少量の処理のために新しい接続を繰り返し作るタスクです。確立済みの接続を再利用する場合は、影響が小さくなります。例えば、既存のHTTPSトンネルで同じサイトの追加ページを要求しても、そのトンネルを作った際のプロキシログインは繰り返しません。これは接続確立のコストであり、プロキシのデータ転送速度が一定量低下するという意味ではありません。

両方の方式が構成に合うなら、同じプロトコル、同程度のプロキシリソース、実際の接続パターンで比較します。リクエストごとに新しい接続を作るテストと、接続を再利用するテストでは、確認することが異なります。その比較がなければ、一方の認証方式が常に速いという主張は、サービス選びにあまり役立ちません。

認証の応答から、プロキシのアドレスだと分かることはある？

あります。パスワードで不正利用を防いでいても、外部システムがサービスを識別できる場合があります。例えば、検査ツールは有効な認証情報がなくても、HTTPプロキシのアドレスとポートに接続できます。407 Proxy Authentication Requiredという応答とProxy-Authenticateレスポンスヘッダーは、プロキシ認証が必要だと明示します。その証拠を得るためにパスワードを知る必要はありません。

IP制限のあるサービスが、識別可能なプロキシ応答を返す前に未許可の送信元を遮断すれば、外部に伝わる情報を減らせます。ただし、許可リストがあるだけでその挙動が保証されるわけではありません。特徴的な拒否応答を返すサーバーもあります。パスワードで保護されたエンドポイントに、ネットワークフィルターを設けることもできます。重要なのは、外部からどこまで接続でき、どのような応答を受け取るかです。

調べるアドレスも重要です。プロキシの入口アドレスと出口IPが同じなら、識別可能な応答によって、ウェブサイトが見るアドレスを特定できることがあります。異なる出口IPを使うゲートウェイでは、ゲートウェイを識別しただけで、プール内のすべての出口が分かるわけではありません。

通常の閲覧中に、接続先ウェブサイトへプロキシの認証要求が自動で届くことはありません。そのやり取りはクライアントとプロキシの間で行われます。サイトやその検知サービスには、アドレスの独立した検査など、別の証拠が必要です。そのため、認証方式の変更だけで、IPがプロキシと識別されなくなったり、すでに知られている情報が消えたりすると約束することはできません。