利用規定(AUP)

利用規定(AUP)

この記事は、プロキシ業界全体の利用規定を概説します。以下の制限は異なる事業者のものであり、ProxyCompassの条件は最後に別途記載します。

利用規定(AUP)は、利用者がプロキシサービスで行える活動を示します。事業者のサービス利用方針の一部で、独立して公開する場合も、利用規約に含める場合もあります。同じ作業向けと宣伝する2つのサービスで、許可する実行方法が違うとき、その実用上の意味が分かります。

例えば、ログイン後の情報収集を禁止する公開方針も、権限を得た非公開情報へのアクセスを認める方針もあります。利用者自身のサイトでも、負荷テストに書面の許可を求める場合もあります。この違いで、支払済みで技術的には動くプロキシが、作業に合うかが決まります。

スクレイピング:ログインが必要なページで変わること

会社が仕入先サイトの価格を収集するとします。誰でも見える価格と、顧客アカウントでログイン後に見える卸価格があります。会社にとっては同じ価格監視プロジェクトです。しかし公開データ限定のAUPでは、両者は許可範囲の内外に分かれます。自分の有効なログインを持っていても、事業者の制限はなくなりません。

権限を得た非公開データへのアクセスを認める方針なら、別の評価になります。重要なのは、利用者が収集自体の許可を持つかです。アカウントページの閲覧、内容の書き出し、得たデータの再配布は別々の権限です。従業員が資料を読める契約でも、プログラムで複製・再販売してよいとは限りません。

収集の方法に関する条項もあります。公開AUPには、対象のrobots.txtの指示、API上限、技術的な頻度制限に従うよう明示したものがあります。その条項では、多くのIPに分散するだけで禁止収集が許可されることにはなりません。購入時に利用者が同意した条件だからです。robots.txtのすべての指示が法律だと言っているわけではありません。

ページ内容も重要です。公開商品価格と、公開されている個人の連絡先は別のデータです。AUPは個人データ収集の適法な根拠を求め、医療情報、子どものデータ、識別可能な個人の追跡には厳しい条件を設ける場合があります。後の公開やAI学習も制限対象になり得ます。ダウンロードできたことだけでは、その後の用途は許可されません。

自動化は実際の動作で判断される

「スクレイパー」「ボット」「SNSツール」はソフトを示しますが、動作はほとんど説明しません。同じブラウザー自動化で、広告を検査することも、有料クリックを捏造することもできます。公開AUPでは以下を区別します。左の作業に対応していても、右の行為を許可する意味ではありません。

サービスが対応し得る作業 公開AUPで制限される活動
広告の掲載位置と表示の確認 偽の表示回数や有料クリックの生成です。他の広告主の予算を使い切らせるクリックも含みます。
検索結果と順位の監視 順位を操作したり、関心のある利用者からの通信に見せたりするためのクリック捏造です。
企業のSNSアカウント管理 偽のプロフィール、レビュー、フォロワー、反応の作成です。大量アカウント登録も禁止される場合があります。
チケットの価格と空き状況の監視 大量取得や転売のための自動購入です。チケット購入ボット自体を一括して禁止する方針もあります。

メールポートがブロックされていてもスパム禁止が適用される理由も、同じ区別で分かります。サイトのフォーム、コメント、私信機能でもメッセージを送れます。SMTPポートを閉じるのはメール送信の1経路を止めるだけで、望まれないメッセージの全形式を止めるわけではありません。

より直接的な悪用には、可能なパスワードを試す総当たり攻撃や、盗んだID・パスワードの組を試すクレデンシャルスタッフィングがあります。フィッシング、盗難カードの確認、マルウェア配布、DDoS攻撃、児童の搾取や著作権侵害を含む違法コンテンツも禁止されます。禁止は行為自体に関するため、ほぼ通信量を使わなくても、少数の試行でAUP違反になり得ます。

攻撃や詐欺以外の制限

AUPには業務上の除外もあります。実際の公開リストには、有料アンケート、ゲーム内アイテム取引、配信関連ドメイン、暗号資産取引、賭博、成人向けコンテンツなどがあります。異なるサービスの例であり、業界共通の禁止ではありません。事業者は、すべて犯罪だと主張せずとも、ある事業活動を対象外にできます。

再販売も具体的な制限です。借りたプロキシ認証情報へのアクセスを顧客に販売するには、別契約が必要か、通常契約で禁止される場合があります。サブユーザー機能があっても判断できません。個別の認証情報は、自社チーム向けかもしれません。プロキシで報告書を作る代理店と、プロキシアクセス自体を売る会社は、異なるサービスを提供しています。

プール自体を保護する条件もあります。取得したアドレスやノードの情報を、プロキシ検出、IP評判評価、通信ブロックのデータベースへ渡すことを禁じます。例えば、アクセスを借りて事業者の出口IPを一覧化し、検出データベースに提供することは、対象サイトを攻撃しなくても違反になり得ます。ネットワークの商業的価値を守る制限です。

このため、AUPを犯罪の一覧に単純化できません。適法な事業モデルが、そのサービスに合うかを決める場合があります。社内調査から再販売へ、公開価格収集から個人に関するデータセット作成へ変えると、同じプログラムや設定でも、契約上の評価が変わり得ます。

自社サイトのテストにも許可が必要な場合

会社が業者に自社サイトの脆弱性スキャンを依頼するとします。会社はテストを許可できますが、業者のプロキシネットワークは管理していません。公開規則には、脆弱性スキャン、ストレステスト、負荷テストの前に、事業者の書面同意を明示的に求めるものがあります。サイト所有者の許可だけで、必要な許可がすべて揃うとは限りません。

テストを運ぶネットワークも、発生する通信や苦情を受けます。スキャンが合意対象外のシステムに届いたり、負荷テストが共有ホスティングや保護サービスに影響したりします。認める事業者では、対象、方法、期間の合意が、引き受けた通信を特定します。「セキュリティー研究」だけでは範囲は定まりません。

プロキシ経由の活動が悪用通報になる流れ

利用者A17はIP 198.51.100.24と198.51.100.25を使え、それらでサイトのパスワードを推測します。サイトは事業者に苦情を送り、このIPと14:03–14:06 UTCを示します。事業者は14:04と14:05の接続記録を照合し、利用者A17を正確に特定します。利用者に停止と事情説明を求め、このサイトへのアクセスを停止します。その後で、サイトに実施した措置を報告します。下部では、攻撃によって事業者のサブネットがブロックリストに載る可能性を示します。サイトはそのリストで他の利用者のIPもブロックします。利用者は作業できず、事業者は顧客と収益を失います。
例:サイトがIPとパスワード推測の時刻を報告します。事業者は記録と照合して利用者A17を特定し、その利用者のサイトへのアクセスを止め、措置を報告します。

接続先にはプロキシのIPが見えます。運営者がパスワード攻撃やスキャンを見つけた時点で、証拠がまず示すのはそのアドレスです。通報はプロキシ事業者か、アドレスとサーバーを供給するホスティング会社へ届きます。後者では、販売者は自社の供給元から問題を伝えられます。

公開ホスティング文書には、証拠の内容が示されています。スキャン記録には、時刻、送信元IP、接続先IP、接続先ポートがあります。例えば、同じ送信元が複数サーバーの22番ポートへ繰り返し接続すると、SSHスキャンと報告されます。大量通信の通報なら、パケット頻度や接続先ごとの通信概要を含む場合があります。異なるインシデントの記録なので、必要な説明も異なります。

次に事業者は、外部のインシデントを利用者の活動と結び付けます。専用アドレスなら割り当てが役立ちますが、共有やローテーションIPではアドレスだけでは不足する場合があります。同じIPを別時刻や同時に使う人がいるためです。正確な時刻とタイムゾーン、利用可能で関連があれば送信元ポートが、区別に役立ちます。実際にネットワークが持つ記録次第です。

苦情が届いた時刻と、報告された活動の時刻も違います。サポートから連絡された時に待機中の作業でも、以前に対象通信を発生させたかもしれません。そのため、現在のプロセス一覧や今の動作確認だけでは、通報への回答になりません。

この流れに、すべてのHTTPSページの読み取りは不要です。通常のエンドツーエンドTLSをトンネルで通す場合、パス、送信パスワード、応答内容は暗号化されます。対象サイトは自身の側の証拠を出し、事業者やホストは取得可能なネットワーク情報を使います。実際にページを処理する管理ブラウザーやスクレイピングAPIは、役割と見える範囲が異なります。

1つの接続先だけ使えなくなる理由

措置は、必ずしもアカウント無効化ではありません。公開された苦情処理手順には、通報されたサイトやホストだけを一時制限できるものがあります。他の通信は継続できます。その場合、主要作業が接続先に届かなくても、チェックツールは接続が動くと報告することがあります。

予防的な規則もあります。銀行ログインなどの慎重な扱いが必要な接続先への頻度を監視し、過剰なら追加制限するサービスもあります。通常は使えるカテゴリでも、無制限の自動リクエストが許されるとは限りません。これは接続先の制御であり、月間通信量枠とは限りません。

AUPと公平利用が重なる場合でも、介入理由は重要です。許可された価格収集でも共有リソースを過負荷にできます。パスワード攻撃は、はるかに少ない量でもAUP違反です。通信量追加は、関連容量が増える場合にだけ前者に役立ち、後者を許可するものではありません。

上流のホストは、さらに広い制限をかけられます。ホスティング規則には、攻撃やスキャン後に個別IP、複数アドレス、サーバー全体をロックするものがあります。そのインフラを使う販売者は、ホストと問題を解決してからでないと復旧できない場合があります。同じ活動を続けてIPだけ変えても、原因は残ります。

共通の警告順序もありません。利用者と解決を試みると説明しながら、初回違反後の停止権を留保する方針もあります。公開アカウントシステムも、悪用通報、検出済みAUP違反、決済不正を区別します。利用者には、説明された制限理由と範囲が必要です。「停止中」という一言では分かりません。

外注先や別の利用者が通信を送った場合

認証情報を複数アプリに設定したり、代理店へ渡したりする場合があります。条件により、アカウント所有者がそのアクセスによる活動の責任を負います。事業者の関係相手は購入者なので、外注先が実行したという説明だけではインシデントは解決しません。

実際には、通報時刻にどのアプリや人が認証情報を使ったかを特定し、活動を止めます。漏えいしたなら、認証情報を無効化または変更する必要があります。対応サービスでは、別々の認証情報や作業記録が助けになりますが、AUPの例外にはなりません。

禁止後の代替アカウント開設、条件に反する試用の繰り返し、本人確認回避など、自社規則を迂回する行為も制限対象です。新アカウントや新IPで、同じ禁止操作が許可済みになることはありません。

支払済みパッケージと残高の扱い

金銭面の結果はいくつかあり、区別が必要です。苦情処理作業の手数料、違反による契約終了での未使用サービス権利の喪失、利用者の行動が生じさせた特定の第三者請求・費用を負担する義務などです。パッケージの支払額が、すべての義務の上限になるとは限りません。

実際に契約で違いがあります。違反による終了では未使用クレジットを失効させる一方、事業者都合の終了では別の扱いにする公開条件もあります。コンプライアンス上の停止でも、契約やクレジットの有効期限を自動延長しないとする場合もあります。使わないアカウントでも、有料期間が一時停止しているとは限りません。

苦情処理手数料に業界共通の金額はありません。払うのは契約に定める料金であり、禁止行為の継続許可や復旧保証を買うのではありません。逆に、通報が届いただけですべての金銭的結果が決まるわけでもありません。強行法上の権利を前提に、制限・終了の根拠と支払い条項が契約上の結果を定めます。

サポートから連絡されたときに送る情報

必要なのは、通報された活動への回答です。「プロキシは動く」「支払済み」「スクレイピングだけ」では、何が接続を生んだか分かりません。有用な回答は、実際の作業とインシデントを結び付け、対応内容を説明します。

  1. 対象作業を停止し、設定と残るログを保存します。メッセージの受信時刻ではなく、タイムゾーンを含む活動の時刻を使います。
  2. 使ったアプリ、定時タスク、従業員、外注先を特定します。接続先とプロキシIPを記録と比べ、不足情報は正規のサポート窓口で求めます。
  3. 原因と変更点を説明します。例えば、作業停止、意図しない接続先の削除、漏えいしたアクセスの無効化です。合意済みテストなら、書面の許可と範囲を添えます。
  4. 残る制限と、許可された作業の再開前に求められる条件を確認します。原因未解決のまま、別IPで同じ操作を再開しないでください。

チケット、管理画面のフォーム、専用回答手順が使われます。苦情の本文や状態をAPIで提供するサービスもあります。どれも処理方法であり、共通の復旧時間を定めるものではありません。回答の審査期限と、再開を約束する期限も違います。

ナレッジベースに戻る