生の認証情報を共有せずにブラウザー業務を引き継ぐ方法

チームが「ログイン情報を共有する必要がある」と言うとき、実際の必要性はもっと限定的なことがよくあります。草稿を確認する、承認済みのストアを更新する、地域固有の不具合を再現する、サポート業務を引き継ぐ、といったものです。パスワードではなく業務から考え始めると、選択肢が増えます。

生の認証情報に含まれるもの

分かりやすい例は、パスワード、復旧コード、ワンタイムパスワードのシード、秘密鍵、プロキシパスワードです。ブラウザー業務には、目に見えにくい認証情報もあります。

• 認証Cookieとセッション識別子。
• OAuthのアクセスおよびリフレッシュトークン。
• パスワード管理ツールの記録とAutoFillデータ。
• パスキーの秘密鍵材料、またはそれを保持する認証器へのアクセス。
• 信頼済み端末と復旧の状態。
• 上記のいずれかを含むプロファイルアーカイブ。

NISTのセッションガイダンスは、ブラウザーセッションを、セッション秘密情報を所持していることに基づく継続性として説明しています。OWASP Session Management Cheat Sheetが示す運用上の意味は明確です。有効な間、セッショントークンは、そのセッションを作った最も強い認証と同等の権限になり得ます。

暗号化されたプロファイルバンドルは、その値をストレージ提供者や偶然見た人へ露出しません。しかし、認可された受信者の端末が復号してプロファイルを起動した後は、ブラウザーがそのセッションの権限を行使できます。受信者がCookieを読むことがなくても、引き継ぎによって権限は移っています。

業務と権限を分ける

共有方法を選ぶ前に、短いアクセス文を書きます。

個人を特定できる担当者Aは、承認済み端末Dから、時刻Eまで、承認・監査規則Fに従い、リソースCに対して操作Bを実行できる。

この文は不要な権限を見つける助けになります。業務が「この草稿を承認する」なら、完全な管理者セッションは過剰です。対象サービスがすでにレビュアーロールを提供しているなら、ブラウザー状態の共有は機能を増やさずリスクだけを増やします。

NISTのZero Trust Architectureは、業務に必要な最小権限で、個々のリソースへのアクセスをセッション単位に判断することを推奨しています。「ゼロトラスト」と名付けられた製品を採用しなくても、この原則は適用できます。どのブラウザー引き継ぎにも有用な設計上の確認基準です。

次の順序でモデルを優先する

1. 対象サービス上の個人別アクセス

Webサイトまたはアプリケーションの所有者が用意するチーム、組織、ロール、委任、承認の機能があれば、それを使います。各人が個別のアカウントと認証器で認証します。これにより対象サービスは、権限の適用、操作担当者の記録、リスク管理、一人だけの失効を、その操作を理解できる場所で実施できます。

認可が操作の意味を理解する場所にあるため、通常はこれが最も強いモデルです。ブラウザー管理ツールは、あるサイトの共有管理者セッションを、そのサイトのレビュアーロールへ確実に変換することはできません。

共有アカウントやグループアカウントは説明責任を弱めます。NIST SP 800-53 Rev. 5は、その利用を制限し、認める前に明示的な条件を定めるよう組織に助言しています。

2. 対象サービスからの範囲を限定した委任

サービスがOAuthなどの委任プロトコルを提供している場合、クライアントまたは実行主体に、必要なリソース、操作、期間だけを許可します。RFC 9700は、アクセストークンの権限を必要最小限に制限し、対象を意図したリソースサーバーに限定することを推奨しています。

短期間で失効可能、かつ対象を限定した許可を優先します。送信者制約付きトークンは、トークンが漏えいした場合の再利用を抑えられますが、攻撃者がトークンと紐づく鍵材料の両方を取得した場合には役立ちません。クライアント端末とソフトウェアは引き続き脅威境界の内側にあります。

委任は特に自動化に適しています。スクリプトは、個人のパスワードや一般的なブラウザーセッションを受け取らず、定義済み操作の権限を得られます。監査イベントには、開始した人、委任された実行主体、リソース、スコープ、結果を記録します。

3. 保存済み秘密情報の仲介利用

一部の旧式サービスは共有認証情報しか提供しません。管理された認証情報ブローカーまたはパスワード管理ツールを使えば、承認済みブラウザーフローから秘密情報を利用しつつ、その値をチャット、チケット、文書、通常のアプリケーション出力へ見せずに済みます。

これは保管、ローテーション、アクセス確認を改善しますが、対象サービスのアカウントモデルを修復するものではありません。サインイン後は、すべての担当者が同じサイト上のIDとして行動する可能性があります。作成されたセッションにも、独自のタイムアウト、失効、端末管理が必要です。

OWASP Secrets Management Cheat Sheetは、きめ細かなアクセス、秘密情報の値に人が触れる機会の最小化、ライフサイクル管理、誰が秘密情報を要求・利用したかの監査を推奨しています。ブラウザー製品は、可能であれば不透明な参照を通じて連携し、別の汎用秘密情報保管庫にならないようにします。

4. 保護されたブラウザーセッションの引き継ぎ

対象サービスに十分な委任機能がなく、承認済み業務にセッションの継続が本当に必要な場合にのみ、共有された認証済みプロファイルを使います。受信者が稼働中アカウントの権限を得るため、通常の引き継ぎ方法の中で最も高リスクです。

最低限必要な管理策は次のとおりです。

• 明示的な所有者と承認済みの受信者。
• 指定された業務、リソース、有効期限。
• 一人のアクティブな書き込み担当、またはテスト済みの競合モデル。
• クラウドへアップロードする前のクライアント側暗号化。
• 受信端末の認可とローカル保護。
• 曖昧な同時作業を防ぐロック。
• 許可、ダウンロード、開始、機密性の高い操作、終了、失効、復旧の監査イベント。
• Cookieやトークンではなく、編集済みの状態を返す通常インターフェース。
• 対象サービスでセッションを失効させる計画。

このモデルは、認証情報の値が容易にコピーされたりクラウドストレージへ露出したりするのを防げます。しかし、同じ認証済みアカウントを使う二人を対象サービスに識別させることはできません。また、マルウェア、悪意ある拡張機能、付与された権限を不正利用する認可済み受信者からセッションを守ることもできません。

5. 生の認証情報の転送

パスワード、Cookie、復旧コード、パスキー、プロファイルアーカイブをメッセージ、スプレッドシート、チケット、スクリプト、保護されていないエクスポートへコピーすると、複製場所が不明で失効しにくい、長期間残る秘密情報が生まれます。避けてください。

例外的な旧式手順で転送が必要な場合は、組織が承認した認証情報手順に従い、受信者と有効期間を最小化し、その後に認証情報をローテーションまたは失効させます。メッセージの暗号化を、個人別の説明責任や全コピーの記録の代わりにしてはいけません。

利便性だけでなく権限を比較する

モデル	対象サービスが担当者を識別	業務に合う範囲設定	失効の境界	主な残存リスク
対象サービスの個人別メンバー	通常は可能	通常は最も強い	一人のメンバーまたはロールを削除	対象サービス上の過剰な権限
範囲を限定した委任トークン	実行主体とクライアントを表現可能	スコープと対象が狭ければ強い	許可またはトークンを失効	トークン、クライアント、鍵の侵害
仲介された共有サインイン	サインイン後は多くの場合不可能	共有アカウントの範囲に限定	秘密情報をローテーションしセッションを終了	共有されたサイト上のIDと稼働中セッション
暗号化されたブラウザーセッション	対象サービスでは通常不可能	プロファイル単位で、多くの場合広い	共有許可と対象セッションを失効	受信端末がセッションの全権限を行使可能
生の認証情報のコピー	信頼できる個人識別なし	通常は広い	コピーを探し、ローテーションし、セッションを終了	不明なコピーと弱い説明責任

この表は、「誰にもパスワードが見えない」だけでは成功基準として不十分な理由を示します。重要なのは、受信者がどれだけの権限を、どれくらいの期間行使でき、どのシステムで失効させられるかです。

パスキーは認証を改善するが、共有には注意が必要

WebAuthnは、Relying Partyごとに範囲が限定された公開鍵認証情報を作ります。WebAuthn Level 3仕様では、認証器が秘密鍵を保持し、Webサイトのスクリプトは秘密の認証情報そのものではなく署名済みの結果を受け取ります。正しく導入すれば、フィッシング耐性のある認証になります。

ただし、パスキーだけでチームロールが生まれるわけではありません。対象サービスは、個人別アクセスを維持するため、各メンバーに別々の認証情報を登録できます。一方、パスキー提供者が認証鍵の同期または共有に対応する場合もあります。NIST SP 800-63B-4はそのモデルを認める一方、不正な鍵利用、多数の端末への拡散、同期基盤の侵害、失効の難しさなどのリスクも示しています。

承認済みのチームでは、一人につき一つの個人別サービスアカウントと認証器を優先してください。共有パスキーしか利用できない場合は、共有認証器として扱い、誰がどの管理対象端末で受け取れるかを記録し、提供者が共有鍵をどう表示、失効、復旧するか確認します。対象サービスでは、すべての操作が一つのアカウントに記録される場合があります。

ブラウザー引き継ぎを契約として定義する

管理された引き継ぎでは、プロファイル状態を移す前に次の質問へ答えます。

1. 誰が操作するか。 一般的な担当者ラベルではなく、個人を特定できる組織IDを使う。
2. 誰が許可したか。 承認の秘密情報を保存せず、所有者またはポリシー判断を記録する。
3. 何を共有するか。 プロファイルと業務を指定し、Cookieや認証情報の生の一覧は避ける。
4. 受信者は何を行えるか。 起動、編集、エクスポート、自動化、共有、管理権限を分ける。
5. どこで実行できるか。 データに適した登録済みの信頼できる端末に限定する。
6. どのくらい続くか。 有効期限を設定し、アイドルセッションを閉じる。
7. 二人が書き込めるか。 競合動作を意図的に設計しテストしていない限り、一人のアクティブな書き込み担当にする。
8. 何を記録するか。 実行者、端末、プロファイル参照、操作、結果、時刻を記録する。秘密情報の値とページ内容は標準で除外する。
9. どう失効させるか。 ブラウザー共有の許可と対象サービスのセッションの両方を対象にする。
10. どう復旧するか。 失効済みの権限を誤って復元せず、最終正常版を保持する。

暗号化はこの契約の内側にあります。保存中または転送中のデータを保護します。認可は誰が復号経路を得られるかを決めます。端末の信頼性とローカル分離は利用時を保護します。監査は説明責任と調査を支えます。どの管理策も、他の管理策を置き換えません。

自動化を秘密情報の境界外に保つ

API、SDK、コマンドラインツール、エージェントは、プロファイルの起動や承認済みライフサイクル操作の実行を必要とすることがあります。Cookieの値、パスワード、パスキー、プロキシ認証情報、生のプロファイルアーカイブを必要とすることはほとんどありません。

範囲の狭いインターフェースは、不透明なプロファイル参照または秘密情報参照を受け取り、次の内容を返せます。

• 操作が認可されたか。
• 準備完了、ロック中、期限切れ、失効済みなど、編集済みの状態。
• 存続期間が限定されたプロセスまたはセッションの参照。
• 構造化されたエラーと復旧手順。
• 監査イベントの参照。

呼び出し元がプロファイルを起動できるという理由だけで、認証情報を返してはいけません。エクスポート、一括共有、その他の秘密情報を伴う操作には、別のポリシーと、必要に応じて明示的な承認が必要です。

Webサイトのコンテンツと自動化への入力も信頼できません。ページ上の指示によって、エージェントがログ、ツール出力、スクリーンショット、サポート窓口へセッション材料を漏らすことがあってはなりません。

失効には二つの層がある

ブラウザーワークスペースから共同作業者を削除すると、そのワークスペースを通じた今後の認可済みアクセスは止まります。しかし、対象サービスのセッションが無効になったことは証明できません。端末がすでに復号済み状態を持ち、コピー済みまたは実行中のセッションが継続する場合があります。

通常の終了時には、次の手順を行います。

1. チームの許可を失効し、プロファイルのリースを閉じる。
2. 保存方針に従って暗号化済みローカル材料を削除する。
3. 対応している場合、対象サービスで該当セッションを終了する。
4. 対象サービスでその人のメンバー資格または委任許可を削除する。
5. 承認済み期間だけ編集済みの監査証拠を保持する。

侵害が疑われる場合は、影響を受けたプロファイル版の隔離、稼働中セッションとトークンの失効、不正な認証器の削除、露出した共有秘密情報のローテーション、監査イベントの確認も行います。古いプロファイルスナップショットを復元すると古いセッション秘密情報も戻る可能性があるため、復旧では失効状態を尊重しなければなりません。

慎重に引き継いだ後にも残る限界

• クライアント側暗号化は保存中・転送中のデータを保護しますが、認可済みエンドポイントはブラウザーが必要とする内容を復号します。
• ブラウザーロックは製品レベルの同時実行を管理しますが、対象サービス上のすべての操作を管理するものではありません。
• 共有セッションでは、ブラウザー製品の監査記録が詳しくても、通常は対象サービスに一つのアカウントIDしか見えません。
• 侵害された端末または拡張機能は、読取可能なパスワードを抽出しなくても、有効なセッションを通じて操作できます。
• ワークスペースの許可失効と、Webサイトのセッション失効は別の操作です。
• 業務を委任できるかどうかは、対象サービスの規約、クライアント契約、適用法によって引き続き決まります。
• 個人別アクセスの安全な代替を提供しないサービスもあります。その場合は、対象範囲を縮小するか、引き継ぎを断ることが責任ある判断になり得ます。

RFC 6265は、Cookieを、リクエストに自動的に付随する権限（ambient authority）と説明しています。リクエストを発生させた人がCookieの値を知らなくても、ブラウザーはそれをリクエストへ添付できます。これがセッション共有の中心的な限界です。認証情報を隠すことは露出を減らしますが、ブラウザーが行使できる権限を減らすものではありません。