# ブラウザ自動化の攻防戦略を設計する：検出モデルと階層型コントロールプレーン

本稿ほんこうは、ブラウザ自動化じどうかの攻防戦略こうぼうせんりゃく設計せっけいに焦点しょうてんを当あて、2つの部分ぶぶんに分わけて説明せつめいします。

1. 原則げんそく：リスクスコアリングシステムがどのように結論けつろんを導みちびくか
2. コントロールプレーン：階層設計かいそうせっけいがどのようにリスクと変動へんどうを低減ていげんするか

本稿ほんこうには、コマンドライン操作そうさや工学的こうがくてきな実装手順じっそうてじゅんは含ふくまれません。

Turnstile 関連かんれんの内容ないようについては、こちらを参照さんしょうしてください。 Cloudflare Turnstile 攻防策略设计：系统原则与控制平面

1. 原則げんそく

1.1 リスクスコアリングは単一たんいつポイントの命中めいちゅうではない

高度こうどなリスク管理かんりを行おこなうサイトでは、「チャレンジするか / 評価ひょうかを下さげるか」といった判断はんだんは、通常つうじょう、一ひとつのルールによる二値判断にちはんだんではなく、多次元たじげんのスコアリングから生しょうじます。

主おもな入力次元にゅうりょくじげん：

1. 一貫性いっかんせい：同一どういつの身元みもとが異ことなる表面ひょうめんの間あいだで矛盾むじゅんしていないか
2. 希少性きしょうせい：低頻度ていひんどの異常いじょうな組くみ合あわせが現あらわれていないか
3. 時間性じかんせい：行動こうどうの時系列じけいれつが機械的きかいてきな統計的特徴とうけいてきとくちょうを示しめしていないか
4. 実行完全性じっこうかんぜんせい：重要じゅうようなパス（チャレンジスクリプト、クロスオリジンリソース、worker）が破壊はかいされていないか

flowchart LR
  A["環境和行为"] --> B["一致性评分"]
  A --> C["稀有性评分"]
  A --> D["时间评分"]
  A --> E["执行完整性评分"]
  B --> F["总体风险"]
  C --> F
  D --> F
  E --> F
  F --> G{"放行 / 挑战 / 限速"}

1.2 一貫性いっかんせい：単一たんいつポイントの調整ちょうせいではなく、制約集合せいやくしゅうごう

一貫性いっかんせいの本質ほんしつは、「同一どういつの身元みもとについて、複数ふくすうの観測対象かんそくたいしょう表面ひょうめんにおける制約せいやくが同時どうじに成立せいりつしなければならない」ということです。

1.2.1 制約集合せいやくしゅうごうの模式図もしきず

身元みもとの一貫性いっかんせいは「制約せいやくグラフ」としてモデル化かできます。

flowchart TD
  UA["UA 字符串"] --> UACH["UA-CH / userAgentMetadata"]
  UA --> LangH["Accept-Language"]
  LangH --> LangJS["navigator.language(s)"]
  LangJS --> Intl["Intl locale/timeZone"]
  Plat["platform"] --> Rend["渲染能力 / WebGL"]
  Rend --> Win["窗口 / 屏幕参数"]
  UACH --> Plat

図ずの各かくエッジは、「2種類しゅるいの表面ひょうめんが互たがいに一貫いっかんしていなければならない」ことを表あらわします。そうでない場合ばあい、衝突しょうとつスコアが発生はっせいします。

1.2.2 典型的てんけいてきな衝突しょうとつタイプ

• UA が示しめすプラットフォーム/バージョンと UA-CH が一致いっちしない
• Accept-Language と navigator.languages が一致いっちしない
• Intl のタイムゾーンと、推定すいていされたオフセット/地域ちいきが一致いっちしない
• デバイスの申告しんこくとレンダリング能力のうりょくの間あいだに異常いじょうな組くみ合あわせがある

工学的こうがくてきな意味いみ：

• 1点てんを修正しゅうせいすると、別べつの1点てんを壊こわす可能性かのうせいがある
• 設計順序せっけいじゅんじょは「まず制約集合せいやくしゅうごうを定義ていぎし、その後あとで各かく表面ひょうめんがどのように制約せいやくを満みたすかを決きめる」べきである

1.3 希少性きしょうせい：単一値たんいつちリスクではなく、組くみ合あわせリスク

希少性きしょうせいは「低頻度ていひんどの組くみ合あわせ」から生しょうじ、危険きけんは個々ここの項目こうもくではなく、共起きょうきから生しょうじます。

希少性きしょうせいは「結合分布けつごうぶんぷ」からの逸脱いつだつとして理解りかいできます。

• 単一特徴たんいつとくちょうの逸脱いつだつ：許容きょようされる可能性かのうせいがある
• 複数特徴ふくすうとくちょうの共起逸脱きょうきいつだつ：リスクが急速きゅうそくに蓄積ちくせきする

工学的こうがくてきな意味いみ：

• 目標もくひょうは、同一どういつセッション内ないで低頻度ていひんどの組くみ合あわせの重かさなりを減へらすこと
• 目標もくひょうは、固定こていされたペルソナに適合てきごうさせることではない

1.4 時間性じかんせい：行動意味こうどういみではなく、統計的特徴とうけいてきとくちょう

行動検出こうどうけんしゅつは、通常つうじょう、統計分布とうけいぶんぷの特徴とくちょうに注目ちゅうもくします。

• 低分散ていぶんさん：動作どうさの間隔かんかくが安定あんていしすぎている
• 強つよい周期性しゅうきせい：間隔かんかくが固定こていされたリズムに従したがう
• 強つよい同期性どうきせい：異ことなる動作どうさタイプの間隔かんかくが同おなじである

工学的こうがくてきな意味いみ：

• 行動制御こうどうせいぎょの目標もくひょうは「分布整形ぶんぷせいけい」（分散ぶんさん/ジッター/バックオフ）である
• 行動制御こうどうせいぎょは「さらに多おおくの動作どうさを追加ついかする」ことではない

1.5 実行完全性じっこうかんぜんせい：上流条件じょうりゅうじょうけん

実行完全性じっこうかんぜんせいは、「システムが正ただしく動作どうさできるか」の前提ぜんていです。

• チャレンジスクリプト、クロスオリジン iframe、またはクロスオリジン worker の意味論いみろんが破壊はかいされると、失敗率しっぱいりつは大幅おおはばに上昇じょうしょうする
• この種しゅの失敗しっぱいは、「識別しきべつされたかどうか」とは別べつカテゴリの問題もんだいである可能性かのうせいがある

工学原則こうがくげんそく：

シグナルを調整ちょうせいするよりも、実行じっこうチェーンを保護ほごすることを優先ゆうせんする。

1.6 反はんデバッグ実行表面じっこうひょうめん：フィンガープリントスコアリング表面ひょうめんと並行へいこう

多おおくのサイトはフィンガープリントスコアリングだけに依存いぞんせず、「能動的対処型のうどうてきたいしょがたの反はんデバッグ」スクリプトも導入どうにゅうします。

典型的てんけいてきなパス：

flowchart LR
  A["页面启动"] --> B["反调试探测"]
  B --> C{"命中？"}
  C -->|是| D["关闭 / 后退 / 重定向"]
  C -->|否| E["继续业务逻辑"]

それとフィンガープリントスコアリング表面ひょうめんとの関係かんけい：

1. フィンガープリントスコアリングは「チャレンジ / 通過つうか / 降格こうかく」を決定けっていする
2. 反はんデバッグ対処たいしょは「ページがまだ使用しようできるか」を決定けっていする

したがって、「ページが自動的じどうてきに閉とじる」ことから、直接ちょくせつ「フィンガープリントが識別しきべつされた」と推論すいろんすることはできません。より一般的いっぱんてきなのは、反はんデバッグチェーンが発火はっかしたケースです。

2. コントロールプレーン（階層設計かいそうせっけい）

2.1 コントロールプレーンの概観がいかん

攻防戦略こうぼうせんりゃくは、4つのコントロールプレーンに分解ぶんかいできます。

1. 起動制御きどうせいぎょ：起動初期きどうしょきに明示的めいじてきリスクを制御せいぎょする
2. プロトコル制御せいぎょ：プロトコル層そうで身元みもとの一貫性いっかんせいを制御せいぎょする
3. ランタイム制御せいぎょ：ページスクリプトから観測可能かんそくかのうな表面ひょうめんを制御せいぎょする
4. 行動こうどうとセッション制御せいぎょ：時間分布じかんぶんぷとコンテキストのドリフトを制御せいぎょする

flowchart LR
  A["启动控制"] --> B["协议控制"]
  B --> C["运行时控制"]
  C --> D["行为与会话控制"]
  D --> E["一致性与稳定性"]

2.2 起動制御きどうせいぎょ

目標もくひょう：セッション初期しょきに明示的めいじてきリスクを下さげる。

設計制約せっけいせいやく：

• 高たかい確信度かくしんどを持もつ自動化識別子じどうかしきべつしだけを処理しょりする
• プロトコル層そう/ランタイム層そうと不一致ふいっちになる変更へんこうを持もち込こまない

2.3 プロトコル制御せいぎょ

目標もくひょう：プロトコル層そうの出力しゅつりょくで、身元みもとの制約集合せいやくしゅうごうを実現じつげんする。

設計要点せっけいようてん：

• UA と UA-CH を、同おなじ制約集合せいやくしゅうごうの異ことなる投影とうえいとして扱あつかう
• 適用範囲てきようはんいは目標もくひょうと一致いっちしていなければならない（ページ/worker/子こターゲット）

2.4 ランタイム制御せいぎょ

目標もくひょう：高頻度こうひんどの探知表面たんちひょうめんをカバーしつつ、実行意味論じっこういみろんが破壊はかいされないようにする。

設計要点せっけいようてん：

• 高頻度こうひんどで、説明可能せつめいかのうな探知経路たんちけいろを優先的ゆうせんてきに制御せいぎょする
• クロスオリジンのチャレンジチェーン対象たいしょうには厳格げんかくな注入境界ちゅうにゅうきょうかいを設定せっていする

2.4.1 反はんデバッグスクリプト制御せいぎょ（disable-devtool 系けいライブラリを例れいに）

反はんデバッグスクリプトは、通常つうじょう、固定こていされた起動きどうエントリによって発火はっかします（例たとえば disable-devtool-auto マーカー）。

実行可能じっこうかのうな制御戦略せいぎょせんりゃく：

1. 自動起動じどうきどうエントリだけを抑制よくせいし、能動的のうどうてきな対処たいしょの発火はっかを避さける
2. 汎用はんようのクエリ/スクリプト読よみ込こみ意味論いみろんを書かき換かえず、業務ぎょうむページへの影響えいきょうを避さける
3. 制御範囲せいぎょはんいを高確信度こうかくしんどの発火点はっかてんに限定げんていし、副作用表面ふくさようひょうめんを制御せいぎょする

これらの戦略せんりゃくの本質ほんしつは「実行表面じっこうひょうめんの隔離かくり」であり、「さらに多おおくのフィンガープリントを偽造ぎぞうする」ことではありません。

2.5 行動こうどうとセッション制御せいぎょ

目標もくひょう：時間分布じかんぶんぷを整ととのえ、コンテキストドリフトを減へらす。

設計要点せっけいようてん：

• 行動制御こうどうせいぎょは統計分布とうけいぶんぷ（分散ぶんさん/ジッター/バックオフ）を対象たいしょうとする
• セッション制御せいぎょはコンテキストの一貫性いっかんせい（身元みもとドリフトの回避かいひ）を対象たいしょうとする

2.6 チャレンジ場面ばめん（Turnstile）のコントロールプレーン要約ようやく

Turnstile の場面ばめんでは、重要じゅうようなコントロールプレーンを次つぎのように抽象化ちゅうしょうかできます。

1. 能力のうりょくトークンの意味論いみろん：サーバー側がわ検証けんしょう、限定げんていされた有効期間ゆうこうきかん、一回限いっかいかぎりの消費しょうひ
2. 範囲縮小はんいしゅくしょう：hostname/action/cdata によって悪用空間あくようくうかんを縮小しゅくしょうする
3. 実行じっこうチェーン保護ほご：クロスオリジンスクリプト/iframe/worker の意味論いみろんを保護ほごする
4. 摩擦まさつとセキュリティの分離ぶんり：clearance は体験層たいけんそうに属ぞくし、セキュリティ判断層はんだんそうを代替だいたいできない

この要約ようやくは、Turnstile を統一的とういつてきなコントロールプレーンの枠組わくぐみに組くみ込こむためのものです。詳細しょうさいは専用記事せんようきじを参照さんしょうしてください。

3. 方案設計ほうあんせっけいの優先順位ゆうせんじゅんい

コントロールプレーン設計せっけいは、通常つうじょう、次つぎの優先順位ゆうせんじゅんいで進すすめます。

1. 実行完全性じっこうかんぜんせい（反はんデバッグ発火表面はっかひょうめんの制御せいぎょを含ふくめ、チェーンが動作どうさできることを保証ほしょうする）
2. 一貫性制約集合いっかんせいせいやくしゅうごう（表面間ひょうめんかんの矛盾むじゅんを解消かいしょうする）
3. 希少性制御きしょうせいせいぎょ（低頻度ていひんどの組くみ合あわせの重かさなりを避さける）
4. 時間分布整形じかんぶんぷせいけい（機械的きかいてきな統計的特徴とうけいてきとくちょうを減へらす）
5. 体験最適化たいけんさいてきか（反復はんぷくチャレンジによる摩擦まさつを減へらす）

この順序じゅんじょの意味いみは、まず「システムの正確性せいかくせい」を確保かくほし、その後あとで「安定性あんていせいと摩擦まさつ」を最適化さいてきかすることにあります。