プロキシのログ記録とプライバシー
サイトには自分のIPの代わりにプロキシIPが見えても、事業者は接続した利用者アカウントを把握している場合があります。同じリクエストの別々の見え方です。サイトに見えるアドレスを変えても、通信を運ぶ会社から活動が見えなくなるわけではありません。
プロキシのログ記録は、接続、接続先、通信量、エラー、製品によってはリクエストや応答など、サービスの使用記録を残すことです。この記事は業界全般の慣行を説明します。他の事業者の利用方針と同じく、詳細はサービス次第です。末尾でProxyCompassのデータ処理を説明します。
HTTPSサイトへの接続でプロキシに見えるもの
架空のオークションを考えます。アプリが€180で入札し、送信先はhttps://bid.example/lot/218/bidsです。通常のプロキシトンネルでは、HTTPSがTLSというセキュリティープロトコルでアプリとサイト間を保護します。事業者には、接続するクライアントのIP、接続先bid.example:443、接続時刻が見え、転送量も測れます。完全なURL、選んだ出品、操作、入札額、Cookie、応答はHTTPS内に残ります。証明書を正しく検証し、通信の傍受・復号がなければ、事業者は読めません。
暗号化通信が始まる前に、ドメインが分かる場合があります。通常のHTTP CONNECTは接続先ホストとポートを指定します。SOCKS5はドメイン名かIPを受け取ります。アプリがドメイン名での接続を求めれば、プロキシはその名前を知ります。複数サイトが共有できるため、接続先IPだけでは特定サイトを識別できるとは限りません。
平文HTTPは違います。ヘッダー、ページのパス、内容は、中継するプロキシが読めます。SOCKS5は元から平文のアプリ通信を暗号化しません。SOCKS5経由のHTTPSはHTTPSの保護を維持し、HTTPは読めるままです。
サイト自身は復号されたリクエストを受け取ります。送ったログイン情報、Cookie、フォームを読め、IP変更後も既存アカウントを認識できます。HTTPSは転送中のデータを保護し、本来の受取人から隠すものではありません。
証明書のインストールを求める事業者がある理由
HTTPS検査を行う特定サービスでは、事業者自身のルート証明書を信頼するよう求める場合があります。これは訪問先サイトではなく事業者の要件で、すべてのプロキシに必要なものではありません。ProxyCompassは当社ルート証明書のインストールを求めません。
通常のHTTPSトンネルでは、プロキシはリクエストや応答の内容を読めません。送信データの検査、規則の適用、応答分析を行うには、その内容にアクセスする必要があります。HTTPS検査では、通過する通信を復号してアクセスします。
ルート証明書は、アプリが他の証明書を信頼する根拠になるデジタル文書です。事業者の証明書を信頼対象に加えると、その事業者が発行したサイト証明書を受け入れられます。検査モードでは、本来のサイト証明書に代えてそれを提示します。対応する信頼設定がなければ、通常の証明書検証は失敗します。
プロキシは、アプリとの接続とサイトとの接続という、独立した暗号化接続を2本作ります。その間ではリクエストと応答を読めます。オークションの例では、完全なアドレスhttps://bid.example/lot/218/bids、出品番号、送った€180の入札、Cookie、入札受理の応答が分かります。事業者はクライアントの実際の操作を見られます。
要件は製品、モード、接続方法によります。サイトアクセスを自動化するサービスや、プロキシ管理ソフトで通信分析を有効にした場合などに現れます。「住宅用」「データセンター」という分類だけでは分かりません。1つのスクリプトにだけ証明書を渡せばよく、システム全体へのインストールが不要なこともあります。
証明書を入れるだけで、すべての通信が事業者を通るわけではありません。ここでのアクセスは、検査を有効にしたサービスをリクエストが通る場合に生じます。プロキシ自身のHTTPSアドレスを検証するためだけの証明書も、対象サイトへの通信内容を復号する意味ではありません。
読めることと、ログへ保存することは別です。証明書から内容へアクセスできる主体は分かりますが、保持期間や担当者の権限は分かりません。証明書検証を無効にしても、復号するサービスからデータを隠すことはできません。
スクレイピングAPIと遠隔ブラウザーは内容を受け取る
スクレイピングAPIには、このURLを開きページや抽出データを返すという作業を渡します。サービス自身がサイトに接続し、読める形で応答を受け取ります。ページを取得するクライアントがサービス自身なので、利用者に証明書を入れさせず実行できます。
事業者がホストするブラウザーは、その会社の機器で動きます。操作用の接続が暗号化されていても、ページ、Cookie、ブラウザーセッションはそこで処理されます。製品によって、作業に完全URL、独自ヘッダー、Cookie、フォームデータ、ページ操作の指示が含まれます。
これは作業に必要なアクセスであり、全ページが保存される、従業員が日常的に結果を読む、という証明ではありません。ただし、作業と結果の扱いの規則が重要です。通常のプロキシトンネル向けの約束が、APIやホスト型ブラウザーも含むとは限りません。
企業にとっては、監視する商品の一覧、検索の並び、調査対象の組が機密情報かもしれません。元のページがすべて公開でも、集めた内容や利用方法から事業上の計画が分かる場合があります。
プロキシログに含まれ得る情報
事業者は、複数種類の記録を持てます。同じ場所に保存する必要はありません。接続はアカウント番号を参照し、メール、注文、決済は別システムにある場合もあります。
| 記録の種類 | 含まれ得る内容 |
|---|---|
| 接続 | 開始時刻、継続時間、接続元IP、サイトに接続したプロキシIP、接続先アドレスやドメイン、ポート、接続エラーです。 |
| 利用量 | 転送バイト数、接続数、アカウントや課金期間ごとの合計です。 |
| アカウントとアクセス | 登録情報、ログイン、許可したクライアントIP、認証情報の変更、注文、決済参照情報です。 |
| サポートとインシデント | チケット、添付資料、サイトからの苦情、調査記録です。 |
| リクエストと結果 | 製品が読めて、設定で記録を認める場合の、完全URL、ヘッダー、本文、取得ページです。 |
可能な分類の例であり、全事業者が必ず集める一覧ではありません。接続を開くために値を処理しても保持しない場合があります。各接続先を永続記録せず、通信量の合計だけを保持することもできます。
ログのクライアントIPは、プロキシに直接接続する端末や中継者のアドレスです。直接接続なら通常は利用者のパブリックIPですが、前段に中継者がいれば、そのアドレスの場合があります。
ノーログの表現が対象とするもの
「通信内容を保存しない」と、接続先ドメイン、時刻、利用量の記録は両立します。「利用量の合計だけ保持する」は別の方式です。短いノーログの表示だけでは、どの約束か分かりません。
指定されたデータと製品に照らして読みます。ページ内容、個別接続記録、接続先履歴のどれを除外し、すべてを除外するのでしょうか。通常運用だけか、診断ログも含むのでしょうか。アカウント、決済、サポート、悪用対応に何が残るのでしょうか。
RAMのみという説明は保存方法です。メモリが消去される前に、別システムへ送るかは分かりません。同様に、暗号化保存は一部の不正アクセスから記録を守りますが、事業者が読めないという意味ではありません。
プライベート、専用、高匿名という表示では答えは分かりません。別の特性だからです。IP確認サイトは、自分のサイトへ届くリクエストを調べられますが、事業者内部のログ運用は検証できません。
障害、課金、悪用通報でのログの役割
接続記録は、認証失敗と接続先の応答なしを区別できます。利用量合計は、通信量枠の消尽を説明します。接続パターンの急変から、壊れたスクリプトや予期しないアカウント利用が分かる場合もあります。
プロキシ接続の成功とサイトへのリクエストの成功は、区別が重要です。CONNECTの成功応答は、トンネルが開いたことを確認します。内部でサイトがCAPTCHAやHTTP 403を返すことはあります。通常のトンネルは暗号化応答を読まないので、接続結果とアプリ側の結果は異なり得ます。
対象サイトには別の見え方があります。パスワード推測を受ければ、リクエスト、プロキシIP、時刻、接続情報を報告できます。対応記録が十分なら、事業者はその接続に使われた利用者アカウントと照合できます。苦情でパスを知ることは、元のHTTPSを復号したという意味ではありません。
共有IPでも照合は可能です。詳細記録は、認証済み利用者の接続とサイトへの接続を結び付けられます。記録されていればミリ秒も含む正確な時刻、ポート、接続先が、同時接続の区別に役立ちます。ローテーションIPも同じアカウントに結び付く場合があります。アドレスの変更や共有で記録は消えません。
記録の保持期間
接続ログ、請求書、サポートチケット、収集結果は、保持期間が違う場合があります。有用な方針は分類ごとの期間や、必要な長さを決める条件を説明します。
管理画面で見える履歴が、全保持期間とは限りません。最近の活動しか表示しなくても、それは閲覧可能な範囲です。内部記録、インシデント資料、バックアップの削除時点は分かりません。
閉鎖で関連記録がすべて消えるとは限りません。適法な保持理由があれば、請求やインシデントの記録は残ります。稼働システムからの削除と、バックアップの失効も別の予定で行われる場合があります。
会社がIDと利用者の対応を保持していれば、名前をアカウントIDへ変えても匿名記録にはなりません。残る情報をアカウントや人に結び付けられるかが重要です。
情報にアクセスできる主体
ログの存在と閲覧許可は別です。サポートは接続エラー、経理は決済記録、セキュリティーチームはインシデント情報を必要とします。プライバシー方針でアクセスと共有を説明し、安全対策で必要な人だけに制限するべきです。
再販売者とネットワーク運営会社は、記録の別部分を持つ場合があります。決済処理会社、ホスティング会社、サポート基盤も特定データを扱います。関係会社と受け取る情報を確認してください。
IPの国だけで、記録の保存場所や事業者への適用法は決まりません。契約会社、処理体制、法律も関係します。拘束力のある法的要請で、保持情報を当局に開示する必要もあります。適用条件は方針で確認してください。世界中の全プロキシに共通する単一規則はありません。
作業に合うプライバシー条件を選ぶ
ページ内容を自分のアプリ内に留める必要があるなら、通常トンネルと管理型取得サービスの違いは重要です。トンネルは内容を中継者に読ませず、接続メタデータは見せることができます。管理型APIは開発を減らせますが、作業と結果を受け取ります。
接続先メタデータも重要です。ドメイン一覧、訪問時刻、量から、調査中の企業や市場が分かるかもしれません。内容の暗号化だけで十分と考える前に、その情報が機密か判断してください。
自分からサポートに送る資料も考えてください。設定やネットワークキャプチャには、事業者の通信ログに出なかったパスワード、アクセストークン、Cookie、リクエスト本文が含まれます。診断資料の共有前に、無関係な秘密情報を取り除いてください。
開始前に、製品が読めるもの、保持するもの、削除時期、受領できる主体を確認します。これらの詳細が、実際の作業に役立つ方針になります。
