チームが行うべきブラウザープロファイルのバックアップと復旧テスト

利用可能な復旧を定義する

バックアップが答えるのは「何かをコピーしたか」です。復旧演習が答えるのは「適切な人が承認済み業務を安全に再開できるか」です。

演習前に二つの目標を設定します。

• 復旧時点： 許容できる最新の状態。たとえば、前回の承認済みスナップショット以降の変更は失ってもよいが、一日分の承認済み業務は失えない、と定められます。
• 復旧時間： プロファイルが利用不能だと宣言してから、利用可能で安全な代替を確認するまでに許容できる最長時間。

これらの目標は、運用への影響とクライアントへの義務から決めます。別のチームの一般的な数値をそのまま使わないでください。

「利用可能」を観察できる確認項目で定義します。ブラウザーウィンドウが開くだけでは不十分です。Cookieが破損している、誤った拡張機能が読み込まれる、端末に結びつく認証情報がない、退職した担当者のアクセスが復活する、といった状態があり得ます。

NISTのGuide for Cybersecurity Event Recoveryは、現実的なテストシナリオ、定義済みロール、結果の記録、演習で誤りだと分かった点に基づく改善を推奨しています。この考え方はプロファイル復旧にも適しています。

復旧対象を棚卸しする

ブラウザー状態は複数の境界をまたぎます。復元、再構築、再認可、意図的な除外のどれを行うか決めてください。

状態区分	例	復旧時の質問
プロファイル内容	ブックマーク、履歴、Cookie、サイトストレージ、権限、セッション状態	どの項目が必要で、どの項目はコピーによって許容できない露出を生むか
ブラウザーコンテキスト	正確なブラウザービルド、プロファイル形式、ポリシー、承認済み拡張機能、ネイティブヘルパー	復元したプロファイルを、対応中の最新ビルドで実行できるか
OS依存要素	キーチェーン項目、証明書、パスワードプロバイダー、パスキー、端末登録	同じmacOSユーザー、移行済みユーザー、新規登録のどれが復旧に必要か
チーム管理状態	所有者、ロール、ロック、監査履歴、版、同期カーソル、失効済み端末	古い権限を復活させずにデータを復元できるか
外部サービス	IDプロバイダー、プロキシ、クライアントアプリケーション、承認システム	稼働中セッションをコピーせずに担当者が再認証できるか

Chromiumは、ユーザーデータディレクトリにプロファイルのサブディレクトリとインストール単位のローカル状態が含まれると説明しています。macOSでは、別のキャッシュパスも導出されます。目に見える一つのフォルダーを復旧対象の全体とみなさず、上流のディレクトリ構造を確認してください。

最も安全な範囲が最大の範囲とは限りません。稼働中のCookieまたはプロキシ認証情報を含むバックアップは、継続を速める一方で、より価値の高い攻撃対象を作る場合があります。各機密区分を含める理由、復元できる人、暗号化方法、失効時期を記録してください。

一貫した時点を取得する

アプリケーションが対応するバックアップまたはエクスポート操作を優先します。対応済み機構がない場合は、ファイル単位のスナップショット前にプロファイルを閉じるか静止させ、その限界を文書化します。稼働中のプロファイルディレクトリを繰り返しコピーして、一貫していると想定しないでください。

多くのブラウザーストアはSQLiteを使いますが、一つの一貫したデータベースが、一貫した複数ファイルのプロファイルを意味するわけではありません。SQLiteのOnline Backup APIは、同時アクセスを処理しながら一つの稼働中データベースのスナップショットを作れます。この保証は、別のデータベース、ファイル、キーチェーン項目、拡張機能状態、コントロールプレーン記録には自動的に及びません。ブラウザープロファイルのバックアップには、アプリケーションレベルの一貫性境界、またはテスト済みの停止状態手順が必要です。

各復旧ポイントとともに次を記録します。

• 秘密情報や不要なクライアント名を埋め込まないプロファイル識別子。
• 作成時刻と完了状態。
• ブラウザー、OS、スキーマ、アーカイブ、鍵のバージョン。
• 含めるデータ区分と除外するデータ区分。
• 完全性情報と認証付き暗号化の状態。
• 保持期間と削除日。
• 必要な復旧ロールと承認。
• 直前の正常な版。

書き込みが中断しても、直前の復旧ポイントまたは新しい復旧ポイントのどちらかが利用可能でなければなりません。公開途中のアーカイブが、唯一の正常コピーを置き換えることがあってはなりません。

クリーンルームで復旧演習を行う

新しいmacOSアカウント、クリーンな管理対象テスト端末、または対応環境に合う分離されたテスト用仮想マシンを使います。アーカイブの形式、完全性、マルウェア、ポリシー検査が終わるまでネットワークアクセスを制限してください。インポートするプロファイル、拡張機能、アーカイブはすべて信頼できない入力として扱います。

合成の根拠を準備する

確認しやすい無害な目印を持つプロファイルを作ります。

• 既知のタイトルを持つ小さなブックマーク階層。
• 本番アクセスを持たない合成WebサイトアカウントとCookie。
• テスト用オリジンのローカルストレージ値。
• 既知の設定を持つ、承認済みテスト拡張機能一つ。
• ダイジェストを記録した機密性のないダウンロードファイル。
• 明示的なサイト権限。
• サインアウト状態のままでなければならないアカウント。

演習を現実的に見せるために、本物のパスワードやセッショントークンをエクスポートしないでください。現実性が必要なのは復旧手順であって、データではありません。

復元を実行する

1. 文書化された経路で復旧ポイントを作成する。
2. メタデータを記録し、より古い正常ポイントがまだ存在することを確認する。
3. テスト環境から元プロファイルを削除するか、元端末を利用不能と宣言する。
4. 復旧担当者には、手順書に記載した材料と権限だけを渡す。
5. 本番サービスを開かず、クリーンな対象へ復元する。
6. 対応するブラウザーバージョンで起動し、すべての目印を確認する。
7. 承認済みのID手順を通じて合成サービスへ再認証する。
8. 達成した復旧時点と復旧時間を測定する。
9. 失敗、想定外のアクセス、確認画面、手作業、不足文書を記録する。
10. テスト計画に従い、復元済み合成プロファイルと一時復旧材料を破棄する。

演習担当者は、バックアップを作成した人だけが持つ文書化されていない知識に依存してはいけません。隠れた知識は復旧の依存要素です。

端末紛失以外もテストする

一度の復元成功だけでは、主な障害モードを網羅しません。

シナリオ	求める根拠
プロファイルの誤削除	影響を受けない新しいプロファイルを上書きせず、選択した過去版を復元
バックアップの中断	不完全なポイントを拒否し、直前の正常ポイントを引き続き利用可能にする
プロファイル書き込み中のクラッシュ	異なる時点のトランザクションを密かに混ぜず、文書化された一貫した状態へ復旧
Macの紛失または交換	クリーンな対応端末で目標内に復元できる、または手順書が再構築と再認証の必要性を明示
キーチェーンまたは復旧秘密情報の紛失	機密データは安全側に失敗し、代替復旧経路がログやサポート出力に鍵を露出せず動作
ブラウザーのアップグレード	古い対応済み復旧ポイントを一度だけ移行し、未変更の元コピーを保持し、意味の確認に合格
ブラウザーのダウングレード	ツールが安全でない復元を拒否するか、明確な互換性警告付きの分離コピーを使用
破損または悪意あるアーカイブ	完全性、パス、サイズ、スキーマ、拡張子の検査で、対象外への書き込みやコード実行前に拒否
ランサムウェアまたは侵害ホスト	侵害端末から保護された復旧ポイントへ到達できず、クリーン環境で復元可能
退職メンバーまたは失効端末	内容の復旧によって、失効済みメンバー、古い端末の信頼、不正なエクスポート権限が復活しない
クラウドまたはネットワーク停止	文書化されたローカル経路と復旧経路が設計どおり動作し、キュー済み変更と競合の規則が明確

Chromiumのユーザーデータストレージ方針は、新しいリリースで古いデータを読めることを求める一方、古いブラウザーが新しい版で書かれたファイルを扱うと機能が低下すると説明しています。唯一のバックアップを不変に保ち、コピーで移行をテストしてください。復元問題を解決するために、恒久的に古いブラウザーを動かしてはいけません。

CISAのStopRansomware Guideは、オフラインの暗号化バックアップと、可用性・完全性の定期テストを推奨しています。「オフライン」は脅威に対して定義される性質です。侵害されたプロファイルホストが削除または書き換えられる復旧ポイントでは、意図した分離を提供できません。

認証をプロファイルファイルとは別にテストする

Webサイトへのアクセスは、ブラウザープロファイルのアーカイブ外にあるパスワード管理ツール、OSのキーチェーン、パスキー提供者、ハードウェアキー、端末証明書、IDプロバイダー登録に依存する場合があります。

現行のWebAuthn Level 3 Recommendationは、単一端末の認証情報と複数端末の認証情報を区別し、バックアップ可能性とバックアップ状態を定義しています。秘密鍵をバックアップする一つの一般的プロトコルは提供していません。Web Authentication Level 3 Recommendationは、Relying Partyに登録された唯一の認証情報を一つの認証器が持つ場合、その認証器を失うと利用者がロックアウトされる可能性を警告しています。プロファイルアーカイブとは別に、Relying Partyが文書化する登録および復旧方法をテストしてください。

重要な合成アカウントごとに、承認済みの代替認証器またはアカウント復旧経路を少なくとも一つテストします。失効も機能しなければなりません。データ復元が成功しても、古い端末や元チームメンバーを再び有効にしてはいけません。

macOSのバックアップツールが証明する範囲を理解する

Time Machineはファイルを自動的にバックアップし、同じMacまたは別のMacへ復元できます。AppleはTime Machineバックアップの暗号化にも対応し、後の復元にはパスワードが必要です。対象のmacOSバージョンについて、現行のTime Machineの設定と復元ガイダンスを確認してください。

これらの機能だけでは、ブラウザープロファイルが意味のある形で利用可能だとは証明できません。Appleのバックアップ検証手順は、ネットワークバックアップの状態を確認します。それでもチームは、クリーン環境で復元済みプロファイルを開き、内容、認証情報、バージョン、分離、認可を確認する必要があります。

端末全体の交換では、移行アシスタントを使って、MacまたはTime Machineバックアップから文書、アプリ、ユーザーアカウント、設定を転送できます。Appleは、メールなど一部のサービスには引き続き設定が必要な場合があると説明しています。移行をテストすべき一つの復旧経路として扱い、すべてのブラウザーまたはキーチェーン依存要素が動く証明とはしないでください。

根拠一式を記録する

確認可能な演習記録には、次を含めます。

• シナリオ、日付、担当者、立会人、承認。
• 元と復元先のブラウザーおよびmacOSのバージョン。
• 復旧時点の目標と達成した経過時間。
• 復旧時間の目標と達成時間。
• 鍵材料を含まない、アーカイブのバージョン、サイズ、完全性結果、鍵バージョン。
• 期待するデータ区分と意図的に除外したデータ区分それぞれの合否。
• ログ、スクリーンショット、診断、自動化出力に秘密情報が現れなかった証拠。
• 他のプロファイルとクライアントが変化していない証拠。
• 再認証、ロール、端末、ロック、失効の結果。
• 文書化されていなかった手作業または外部依存要素。
• 各是正措置の担当者と期限。

復元環境が宣言済みの受入基準を満たし、チームが残る各リスクへ対応または受容した時点で演習は完了です。バックアップ画面が緑色であるだけでは、復旧の根拠になりません。

変更に応じたテスト頻度を選ぶ

影響と変更頻度に基づいてテスト頻度を定めます。ブラウザープロファイル形式、macOS対応範囲、暗号化または鍵復旧、IDプロバイダー、パスワード管理ツール、同期プロトコル、拡張機能ポリシー、バックアップ提供者、チーム認可モデルに重要な変更があった後は演習を行います。移行前と重大な復旧事象の後にもテストしてください。

定期演習では、シナリオと担当者を入れ替えます。最も簡単なファイル復元だけを繰り返すと、チームが備えられる障害は一種類だけになります。