ブラウザープロファイル自動化に最小権限を適用する方法

認可の範囲から始める

NISTの最小権限の定義は、利用者と、その代理で動くプロセスのアクセスを、割り当てられた業務に必要な最小限へ制限することです。したがって、automationのような一つのロールは、ブラウザープロファイル業務には広すぎます。呼び出し元が誰かは示しますが、どのプロファイルを開けるか、どのWebサイトへアクセスできるか、何を変更できるか、許可がいつまで続くかは示しません。

有用な認可範囲には、八つの側面があります。

側面	答えるべき質問	強い既定値
実行主体	どの人、ワークロード、エージェントがジョブを開始したか	人またはワークロードごとに、追跡可能な一つのID
テナント	どの組織またはクライアント境界が適用されるか	一つの組織のみ。テナントをまたがない
プロファイル群	どのプロファイルを利用できるか	明示的なID、または確認済みのフォルダー・タグ選択条件
操作	自動化は何を行えるか	ファイルシステムやプロセスの基本操作ではなく、名前の付いたドメイン操作
宛先	どのサイト、API、環境へ接続できるか	承認済みのオリジンと環境のみ
時間	権限はいつ始まり、いつ失効するか	短期間の認証情報と、上限のあるジョブ実行時間
処理量	どれだけの作業を行えるか	同時実行、リクエスト、費用の上限
副作用	何を変更、公開、削除し、いくら支出できるか	まず読取専用。影響が大きい操作は承認が必要

ポリシー判断はコマンドごとに評価します。プロファイルの起動に成功しても、Cookieのエクスポート、チーム管理、請求変更、ブラウザーから到達できる任意のサイトでの操作を暗黙に許可してはなりません。

三種類の権限を分ける

ブラウザー自動化では、三つの異なる認証情報が一つの業務に混ざりやすくなります。

1. 自動化の認証情報は、プロファイル管理ツールまたは自動化サービスへの呼び出しを認可します。
2. プロファイルのセッション状態は、Webサイトに対して人またはテストアカウントを認証する場合があります。
3. 対象サービスの委任は、そのアカウントがWebサイトで何を行えるかを決めます。

これらは相互に置き換えられません。自動化トークンにプロファイルのCookieを含めたり露出したりしてはいけません。認証済みプロファイルがあっても、呼び出し元がWebサイトで利用可能なすべての操作を行う権限があるとは限りません。WebサイトのパスワードやOAuthトークンを、プロファイル管理ツールの認証情報として再利用してはいけません。

認証済みブラウザー状態自体が機密情報であるため、この分離は重要です。Playwrightは、保存済み状態にテストアカウントを偽装できるCookieやヘッダーが含まれる場合があると警告しています。秘密情報を含む成果物として扱い、ソース管理、通常のログ、チャット履歴、課題管理、一般的な自動化出力から除外してください。

遠隔ブラウザー制御にも同じ注意が必要です。Chrome 136以降、Chromeは既定のデータディレクトリに対するリモートデバッグ用スイッチを受け付けなくなり、デバッグと実際のプロファイルを分離するため独自ユーザーデータディレクトリの利用を推奨しました。Googleは2025年3月17日のセキュリティ通知で、変更理由の一つとしてリモートデバッグを使ったCookie抽出を挙げています。近道として個人が日常利用するブラウザープロファイルへ自動化を接続しないでください。

権限を割り当てる前に操作を分類する

管理インターフェースは、一つの無制限なブラウザー接続を公開するのではなく、業務操作とそのリスクを表現する必要があります。

操作区分	例	既定の管理策
観察	許可されたプロファイルの一覧、健全性の読取、編集済み状態の表示	範囲の狭い読取スコープで許可
ライフサイクル	起動、停止、プロファイルリースの取得、テスト用スナップショットの作成	指定プロファイルだけに許可し、各遷移を記録
対話	承認済みオリジンへの移動、定義済みテストの実行、テスト成果物のダウンロード	宛先、入力、出力先、期間を制限
高影響	コンテンツ送信、テストデータの初期化、アクセス変更、費用発生、プロファイル削除	プレビュー、明示的承認、より強いポリシー
秘密情報を伴う操作	Cookie、認証情報、プロキシパスワード、復旧材料、生のプロファイル状態のエクスポート	通常の自動化インターフェースでは拒否

リスクは文脈によって変わります。使い捨てのステージングアカウントへのフォーム送信は通常のテストでも、同じ操作を本番アカウントで行えば法的、金銭的、評判上の影響を生む場合があります。環境、アカウント、提案された正確な変更に判断を結びつけてください。

範囲が狭く短期間の認証情報を発行する

ワークロードごとに別のサービスIDを使います。人間の管理者セッションを、継続的インテグレーション（CI）、ローカルスクリプト、エージェントに貸さないでください。有用なトークンは、次の項目で制限されます。

• 組織、および必要に応じてクライアントまたはワークスペース。
• プロファイルID、フォルダー、タグ、その他の安定したリソース選択条件。
• 許可された操作。
• 対象のサービスまたはオーディエンス。
• 発行時刻、失効時刻、失効状態。
• プラットフォームが対応する場合は端末またはワークロードのID。
• 同時実行、処理量、費用の上限。

RFC 9700は、対象リソースサーバー、リソース、操作を含め、アクセストークンの権限を必要最小限に限定することを推奨しています。また、対象の制限によって漏えいしたトークンの影響を減らせる理由も説明しています。現行のModel Context Protocol（MCP）認可仕様も同様に、対象の検証を必須とし、クライアントに意図した操作に必要なスコープだけを要求するよう求めています。

段階的な認可を優先してください。ジョブは、検出とプレビューの権限から開始します。後の手順で強い権限が必要になれば、その手順向けの新しい短期間の許可を要求します。業務の一つの分岐でいつか必要になるかもしれないという理由で、恒久的な全権トークンを発行してはいけません。

MCPなどの仲介層では、上流の認証情報を分離します。MCP認可のセキュリティ考慮事項は、リソース固有のトークンを要求し、受信したMCPトークンを上流APIへそのまま渡すことを禁じています。より一般的な教訓は、どの自動化ゲートウェイにも当てはまります。各信頼境界が独自の認証情報を検証し、承認済み操作に必要な下流権限だけを発行または取得します。

承認を具体的かつ検証可能にする

承認は「何を承認するのか」に答えなければなりません。「このエージェントを許可する」のような一般的な確認では、確認者が理解した以上の権限を許可する可能性があります。

影響が大きいコマンドのプレビューには、次を含めます。

• 開始した人とワークロード。
• 組織、プロファイル、対象アカウント、宛先。
• 提案する変更の人が読める説明。
• 影響する正確なリソースと最大件数。
• 予想される費用または外部への影響。
• 変更される値。秘密情報は編集して隠す。
• ロールバックまたは復旧経路。
• 短い承認有効期限。
• より低い権限では実行できない理由。

承認を、正規化した要求のダイジェスト、ポリシーバージョン、プロファイルバージョンに結びつけます。不可逆または外部から見える操作では、一回限りにします。要求、宛先、リソース数、関連状態が変わった場合は承認を無効にし、新しいプレビューを示してください。

承認は認可の代わりではありません。確認者は組織が持たない権利を付与できず、確認画面によって禁止された業務を許可されたものへ変えることもできません。

安全に失敗するよう実行を設計する

最小権限は、エラー後の動作も制限します。実行契約には、プロファイルリース、事前条件、上限付き再試行、キャンセル、復旧動作を含めます。

障害	安全な応答
権限拒否	停止する。自動的に昇格せず、不足する権限を報告する
プロファイルが使用中	二人目の書き込み担当を開始しない。上限時間内で待つか、明確な競合を返す
実行中にリースを喪失	新しい操作を停止し、編集済みの根拠を保持し、プロファイルを復旧経路へ移す
読取前のネットワークタイムアウト	定義済みの回数と期限内でのみ再試行する
送信後に接続を喪失	結果を不明と記録する。対象が安全な冪等性機構を提供しない限り繰り返さない
承認期限切れまたは要求変更	操作をキャンセルし、新しいプレビューと承認を求める
監査先が利用不能	定義済みポリシーに従う。高影響操作は通常、安全側に失敗させる。低リスクイベントは保護された容量制限付きローカルバッファを使える場合がある
スナップショットまたは復元の検証失敗	影響した状態を隔離し、最終正常版を上書きしない

すべての変更コマンドについて、冪等であるか、どの事前条件を確認するか、中断後に最終結果をどう発見できるかを定義します。「どのエラーでも再試行」は、送信、購入、削除、招待、権限変更では安全ではありません。

秘密情報を記録せず判断を記録する

監査イベントは、別の認証情報保管庫にならずに操作を再構成できる必要があります。OWASPのログ記録ガイダンスは、認可失敗と高リスク操作を記録し、「いつ、どこで、誰が、何を」を捉え、ログデータへのアクセスを保護することを推奨しています。また、ログがパスワードなどの技術的秘密情報を露出し得ると注意しています。

各自動化判断について、次を記録します。

• 人、サービス、委任された実行主体のID。
• 組織と編集済みのプロファイル参照。
• コマンド名、要求ID、該当する場合は冪等性キー。
• ポリシーバージョン、判断、理由コード。
• 承認済み操作の場合は、承認参照と承認者。
• 編集済みの宛先とリソース数。
• 開始時刻、完了時刻、結果。
• ブラウザー、クライアント、自動化アダプターのバージョン。
• 復旧、キャンセル、手動確認の状態。

Cookieの値、パスワード、アクセス・リフレッシュトークン、Authorizationヘッダー、プロキシ認証情報、暗号鍵、ページ内容全体、フォーム値、生のプロファイルアーカイブは記録しません。パスやクエリ文字列に個人情報や秘密情報が含まれる場合があるため、URLも最小化します。監査アクセスを保護し、保存期間を定め、ログ記録が遅い、満杯、利用不能な場合の動作をテストしてください。

具体的なポリシー例

次の疑似コードは設計例であり、Isolineの設定ではありません。CIワークロードに、ステージング用プロファイルで地域別スモークテストを実行する権限だけを与えます。

principal: "workload:regional-smoke-tests"
tenant: "org:example-studio"
profiles:
  selector: "tag == qa-staging"
operations:
  allow:
    - "profile.read"
    - "profile.launch"
    - "test.run-approved-suite"
    - "profile.stop"
  deny:
    - "profile.export-session-state"
    - "profile.delete"
    - "team.manage"
destinations:
  allow:
    - "https://staging.example.test"
conditions:
  expiresAt: "2026-08-26T18:00:00Z"
  maxConcurrentProfiles: 2
  maxRuns: 20
  requireCleanStop: true
approvals:
  "staging-data.reset": "single-use-human-approval"
onUnknownSideEffect: "stop-and-review"

このポリシーは、一般的なブラウジング、本番アクセス、秘密情報のエクスポート、チーム管理、スコープ追加の無期限な権限を与えません。スモークテストに新しいオリジンまたは操作が必要な場合、その変更は実行時に推測せず、ポリシー確認を通します。

確認チェックリスト

ブラウザープロファイル自動化を有効にする前に、次を確認します。

• システム所有者と、該当する場合はクライアントが、許可された目的を文書化している。
• 各人とワークロードに追跡可能なIDがある。
• トークンがテナント、プロファイル、操作、対象、時間、処理量で制限されている。
• 対象アカウントが業務に必要なロールだけを持つ。
• 日常利用する個人プロファイルが除外されている。
• セッション状態などの秘密情報が通常の読取やログに現れない。
• 高影響操作に具体的なプレビューと期限付き承認がある。
• プロファイルロックが同時書き込みを防ぐ。
• 変更コマンドに事前条件、冪等性、不明結果の処理が定義されている。
• キャンセル、失効、中断、復元の経路がテストされている。
• 監査記録が機密内容を露出せずに判断を再構成できる。
• 認可が撤回された場合、または対象サービスが操作を拒否した場合に業務が停止する。

限界

最小権限はミスや認証情報漏えいの影響を減らしますが、認可されていない業務を許容可能にしたり、第三者サービスが操作を認めることを保証したりはしません。Playwrightのブラウザーコンテキスト文書にあるように、ブラウザーコンテキストの分離はテスト分離を改善しますが、一台の機器を独立して信頼される複数の端末へ変えるものではありません。侵害されたエンドポイント、悪意ある拡張機能、過剰権限の対象アカウント、安全でない下流サービスは、意図した境界を破る可能性があります。

業務が変わるたびに権限を見直してください。未使用スコープを削除し、非アクティブな認証情報を失効させ、拒否経路を再テストし、生のセッション材料を求める要求は通常の自動化機能ではなく、別の高リスクセキュリティ確認として扱います。