本ドキュメントは、最近のセキュリティ研究および報告においてBright Dataのネットワークに関して提起された特定の技術的主張を取り上げています。セキュリティ研究者、エンジニア、ジャーナリスト、および技術的な観点からこれらの主張を評価するすべての方を対象としています。主張が正確である場合はその旨を明記し、相関関係と因果関係を混同している場合や、なりすましと参加を混同している場合は、実際のメカニズムと結論が成立しない理由を説明します。
「分散型プロキシ」というフレーミングについて
批評家たちは、HolaのP2P設計を「従来のVPNとは異なるリスクプロファイルを持ち、分散型プロキシに近い」と表現し、ピア同士が互いに接続または経由していると示唆しています。
実際にはそうではありません。HolaはP2Pで動作していません。ピア—サーバー—ピア方式で動作しています。すべてのリクエストはBright Dataのサーバーを経由してルーティングされます。ピアが別のピアのデバイスに直接接続することはなく、他のユーザーのシステム、ファイル、トラフィック、または情報を参照することもありません。
この違いは意味論的なものではなく、アーキテクチャ上のものであり、この回答の残りの部分を成立させる根拠です。すべてのトラフィックは転送前に当社のインフラで終端されるため、真のP2Pシステムでは実現できないコントロールをそのチェックポイントで実施できます。
アクセス可能なのはホワイトリストに登録されたドメインのみです。バックエンドサーバーはドメインおよびIPブラックリストを管理しています。顧客がどのようなリクエストを行っても、事前承認されていないサイトにピアデバイスを使用してアクセスすることはできません。
許可されるのはHTTP/HTTPSトラフィックのみです。その他のすべてのポートはプロトコルレベルでブロックされています。これだけで、「分散型プロキシ」というフレーミングが示唆するほとんどの悪用手法が排除されます。任意のTCP、SSHトンネリング、生のソケットアクセスはいずれも不可能です。
ピアインフラがブルートフォースや認証情報スタッフィングのベクターとして使用されるのを防ぐため、レート制限が実施されています。
脅威モデリングの観点における分散型プロキシとは、攻撃者が選択した宛先への攻撃者制御のルーティングを意味します。ホワイトリスト制御により、当社のアーキテクチャでは攻撃者が宛先を選択することはできません。
「ラテラルムーブメント」という主張について
批評家たちはまた、デバイス上にHolaが存在することで「ラテラルムーブメントを含む悪意ある行為の足がかりとなる可能性がある」と示唆しています。
ラテラルムーブメントには、ローカルまたはプライベートネットワークアドレス、ルーター管理パネル、NASデバイス、プリンター、同一サブネット上の他のマシンへのアクセスが必要です。以下に、すべてのレイヤーでこの経路が閉じられている理由を説明します。
プレーンIPリクエストは完全に禁止されており、ローカルネットワークを直接標的にする最も単純なベクターが排除されています。
バックエンドサーバーは、すべてのプライベートおよびローカル範囲（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、およびそれに相当するもの）をカバーするIPv4およびIPv6ブラックリストを管理しており、DNS解決後に適用されます。つまり、公開ホスト名をプライベートアドレスに解決することでフィルターを回避することはできません。
SDKレイヤーが同じブラックリストを独立して適用します。これは単一障害点ではなく、チェックは2つの異なる場所で2回実行されるため、一方のレイヤーをバイパスしても他方はバイパスできません。
プラットフォームネイティブの制御がその上に重ねられています。たとえばAndroidでは、プラットフォームレベルのシステム関数がローカル/プライベートIPターゲティングを独立して禁止しており、制御が当社自身のコードの正常動作のみに依存しないことを意味します。オペレーティングシステム自体が制御の一部となっています。
これは、ネットワーク、SDK、OSレベルでの冗長かつ独立して実施される技術的フィルタリングです。また、これはSpur Intelligence Labsによって独立して検証された設計ポイントでもあります。同社のテストでは、Bright Dataのプロキシレイヤーが、テストされた他のプロバイダーに影響を与えたラテラルネットワークアクセスの脆弱性に対して免疫があることが判明しました。これは主に、ほとんどの競合他社がこの多層的な多重防御ブロッキングを実装していないためです。
悪意ある行為者がピアデバイスを使用してそのデバイスのホームネットワークにアクセスすることはできません。なぜなら、リクエストはそのために必要な解決またはルーティング段階に到達しないからです。DNSの前にブロックされ、DNS後にブロックされ、SDKでブロックされ、OSでブロックされます。端的に言えば、顧客はBright Dataのネットワークを使用して誰かのホームルーター、プリンター、またはローカルデバイスにアクセスすることはできません。ローカルおよびプライベートIPの範囲は、DNS解決前、DNS解決後、SDKレイヤー、OSレイヤーで独立かつ冗長にブロックされており、単一の障害がその扉を開くことはありません。
なりすましIDとユーザーエージェント文字列の限界について
この報告全体を通じて、別の、しかし関連した混乱が見られます。HolaまたはBright Dataとして識別されるトラフィックは、必ずHolaまたはBright Dataのソフトウェアから発信されたはずだという思い込みです。実際にはそうではありません。マルウェアは、ブラウザやオペレーティングシステムに偽装するのと同様に、HolaまたはBright Dataのトラフィックに偽装することができます。どのようなソフトウェアもユーザーエージェント文字列を偽装できます。これはHTTPの仕組みの特性であり、なりすまされた製品の設計や意図の証拠ではありません。攻撃者は、よく知られた信頼されたソフトウェアの識別マーカーを借用します。それはそれらのマーカーが認証されておらず、簡単に書き換え可能だからです。悪意あるトラフィックに見慣れたラベルが存在することは、攻撃者の手口について何かを語っていますが、なりすまされたソフトウェアについては何も語っていません。
責任あるネットワークと悪意あるネットワークの実際の境界線
技術そのものは中立であるため、同意を得た責任あるネットワークと、同意を得ていない悪意あるネットワークを区別するものを明確に述べる価値があります。違いは検証可能かつテスト可能であり、4つの次元にわたります。ソーシング、審査、ガバナンス、そして説明責任です。
責任あるネットワークにおける不正使用を実際に防止するのは、法的免責事項の一文ではなく、ここで説明したコントロールの組み合わせが連携して機能することです。ドメインホワイトリスト、HTTP/HTTPSへのプロトコル制限、レート制限、多層プライベートIPブロッキング、顧客のKYC確認審査、および独立したサードパーティ監査。これらはすべて独立して検証可能であり、同意を得ていない悪意あるネットワークにはそのいずれも存在しません。
責任あるネットワークのすべてのIPは、スタンドアロンの同意画面を確認し、何を求められているかを理解し、いつでも数ステップで退出できるピアから提供されます。悪意あるネットワークのデバイスは、同意ではなく侵害によって、所有者の知らないうちに組み込まれます。これはテスト可能です。実際のオプトインフローを確認してください。
責任あるネットワークは、アクセスを許可する前にすべての顧客を審査します。本人確認、ユースケースの審査、継続的なコンプライアンス監視を行い、文書化された基準を満たさない申請者を拒否します。悪意あるネットワークは、審査なしに匿名で誰にでもアクセスを販売します。これはテスト可能です。アクセス取得を試み、何が必要かを確認してください。
責任あるネットワークは、不正使用が発生した際に検出、ブロック、および帰属を行い、定められたタイムライン内で外部からの不正使用報告に対応します。悪意あるネットワークは、発見されることに関心がないため、不正使用報告チャンネルを持ちません。これはテスト可能です。不正使用報告を提出し、応答を測定してください。
責任あるネットワークは、独立した外部監査を受け入れ、その結果を公開します。PwC、ISO 27001/27017/27018、SOC 2 Type II、AppEsteem認証、Spurのような企業によるサードパーティセキュリティ研究などです。悪意あるネットワークは何も公開しません。調査されたいものが何もないからです。これはテスト可能です。監査は公開されています。
さらなる技術的詳細については、以下をご覧ください。
Bright Data トラストセンター
PwC 監査レポート
Bright SDK ユーザーFAQ
セキュリティ研究者の方々には、当社のSDKとネットワークをテストすることをお勧めします。セキュリティ上の問題を発見された場合は、Bright Data セキュリティ脆弱性報奨プログラムを通じてご報告ください。
