Изоляция браузерных профилей: что действительно разделяется?

Выражение «отдельный профиль» кажется точным, пока от него не начинает зависеть рабочий процесс. В одном продукте оно означает другую папку. В другом к этому добавляются контроль процессов, сетевая политика для каждого профиля, шифрование, блокировки, резервное копирование и командные права. Само название не гарантирует определённого сочетания этих границ.

Поэтому практический вопрос звучит так: что отделено от чего, от какого сбоя или участника это защищает и чем это подтверждено?

Четыре границы, которые легко перепутать

Граница	Что она разделяет	Чего она не подтверждает
Origin веб-сайта	Доступное скриптам хранилище одного источника и другого	Разделение двух входов на один сайт внутри одного профиля
Браузерный профиль	Набор состояния браузера, относящийся к одному профилю	Защиту от другого человека с доступом к той же учётной записи ОС
Изоляция сайтов и песочница	Контент разных сайтов в ограниченных процессах рендеринга	Отдельную установку браузера или сетевой стек для каждого профиля
Учётная запись ОС, контейнер или виртуальная машина	Файлы, процессы, учётные данные, а иногда и сетевую политику на системной границе	Автоматическое разделение аккаунтов внутри браузера без настройки

Эти уровни решают разные задачи. Правило одного источника в вебе не позволяет обычному скрипту одного origin читать хранилище другого. Модель безопасности Site Isolation в Chromium добавляет между сайтами границы процессов рендеринга с песочницей. Браузерный профиль объединяет состояние браузера для человека или рабочего процесса. Учётная запись ОС или виртуальная машина решает более строгую задачу защиты от локального нарушителя либо изоляции на уровне системы.

Утверждение об одном уровне нельзя использовать как доказательство свойств другого.

Что обычно разделяет постоянный браузерный профиль

Согласно документации Chromium, каталог пользовательских данных содержит историю, закладки, cookies и другие данные, а каждый профиль занимает подкаталог внутри него. Справка Chrome о профилях также говорит о раздельном хранении закладок, истории, паролей и настроек.

Для постоянного рабочего профиля ожидаемая граница состояния обычно включает следующее:

Состояние	Практический результат разделения
Cookies и состояние входа	Вход в сервис через профиль A не должен выполнять вход в профиль B через общее хранилище cookies
Local storage и базы данных сайтов	Локально сохранённое состояние веб-приложения относится к профилю, который его создал
HTTP-кэш и Cache Storage	Повторно используемые ответы и офлайн-данные приложения обычно не переходят в другой профиль
История, закладки и состояние открытого сеанса	Посещения и сохранённые адреса остаются связанными с нужным рабочим процессом
Разрешения сайтов	Решения о камере, микрофоне, уведомлениях, геолокации и других возможностях могут различаться по профилям
Расширения и их состояние	Установленными расширениями, их настройками и правами можно управлять отдельно для каждого профиля
Пароли и автозаполнение	Локальные учётные данные и содержимое форм остаются в выбранном профиле с учётом включённой синхронизации аккаунта

Физическое размещение зависит от платформы. Документация Chromium указывает, что путь кэша может вычисляться из пути профиля, но находиться в системном каталоге кэша, а не рядом с остальными данными профиля. Она также отделяет данные профиля от другого локального состояния установки в каталоге пользовательских данных. Поэтому обоснованная архитектура изоляции учитывает все принадлежащие профилю пути и описывает общее состояние установки, а не считает одну видимую папку полной границей.

Одной папке всё равно нужны правила жизненного цикла

Уникальный путь предотвращает случайное повторное использование состояния только тогда, когда каждый запуск получает правильный путь. Chromium также отмечает, что два запущенных экземпляра Chrome не могут безопасно использовать один каталог пользовательских данных. Система управляемых профилей должна явно определять правила жизненного цикла:

• назначать каждому профилю уникальный корневой каталог данных;
• не допускать одновременной записи в одно постоянное состояние из двух процессов;
• определять процессы, относящиеся к конкретному запуску;
• останавливать или восстанавливать их как единый жизненный цикл;
• завершать запись до резервного копирования или миграции;
• обнаруживать незавершённое выключение до следующего запуска.

Без этих мер даже «отдельные папки» не исключают запуск не того профиля, зависшие блокировки, неполные копии и повреждение после прерывания.

Что браузерный профиль не разделяет автоматически

Локальный доступ

Chrome предупреждает: человек с доступом к устройству может переключиться в другой профиль Chrome и просмотреть, например, посещённые сайты. Рекомендация — давать устройство только тем, кому вы доверяете. Обычный выбор профиля упорядочивает работу доверенных пользователей. Он не ограничивает доступ другого пользователя той же учётной записи ОС.

Если в модель угроз входит любопытный или недобросовестный человек рядом с устройством, используйте отдельные учётные записи ОС, средства защиты устройства или более строгую границу выполнения. Шифрование профиля и правила разблокировки могут снизить риск для данных в покое, но всё равно требуют проверки архитектуры, хранения ключей, восстановления и поведения в разблокированном состоянии.

Бинарный файл браузера и обновления

В одном каталоге пользовательских данных Chromium могут находиться несколько профилей. Обычно они используют один установленный браузер и один механизм обновления. Отдельное состояние профилей не означает отдельных правил установки исправлений безопасности.

Общий компонент бывает удобен: один поддерживаемый браузер проще обновлять последовательно. Но устаревшая или скомпрометированная сборка затронет все профили, которые её используют. Актуальность браузера, проверка подписи и безопасный откат должны входить в оценку изоляции.

Сетевые признаки

Создание профиля само по себе не меняет публичный IP-адрес, путь DNS, локальную сеть или вышестоящий прокси. Профили на одном устройстве обычно используют один сетевой маршрут, если браузер, расширение, политика ОС или менеджер профилей не задаёт другое поведение.

Если процесс требует отдельного прокси для каждого профиля, проверяйте не только указанный адрес. Проверьте аутентификацию, обработку DNS, WebSocket и других протоколов, поведение при сбое и до готовности прокси. Переход к прямому соединению при ошибке может нарушить задуманную сетевую границу даже при правильной сохранённой настройке прокси.

Характеристики устройства и среды

У профиля могут быть другие cookies и настройки, но он всё равно может раскрывать характеристики того же браузера, ОС, оборудования, экрана, языка и сети. W3C описывает фингерпринтинг как повторное распознавание по наблюдаемым признакам; среди возможных входных данных в руководстве по фингерпринтингу перечислены заголовки запросов, IP-адрес, размер окна, шрифты, подключённые устройства, производительность, датчики и графический рендеринг.

Разделение профилей может предотвратить повторное использование состояния. Оно не делает устройство неузнаваемым, не гарантирует другой отпечаток и не гарантирует доступ к стороннему сервису.

Файлы вне профиля

Скачанные файлы часто покидают принадлежащее профилю хранилище и попадают в обычную пользовательскую папку. Справка Chrome наглядно показывает различие: очистка истории загрузок не удаляет скачанные файлы.

При загрузке файлов на сайт возникает обратный риск. Диалог выбора файла может показывать нескольким профилям одну файловую систему устройства. Буфер обмена, перетаскивание, печать, снимки экрана и уведомления ОС тоже могут пересекать границу профиля, если окружающий продукт или ОС их не ограничивает.

Выберите и опишите политику скачивания. Возможные варианты — отдельная папка для каждого профиля, временный рабочий каталог, явный экспорт или более строгая контейнерная граница. Выбор зависит от цели: предотвращать ошибки, защищать секреты или разделять взаимно недоверенные задачи.

Облачные аккаунты и синхронизация

Раздельные на диске данные всё равно могут копироваться через включённую синхронизацию. Пароль, закладка, настройка или запись истории может появиться в другом месте, если профиль связан с аккаунтом, синхронизирующим эту категорию. Например, Chrome позволяет вошедшему пользователю выбирать сведения профиля, сохраняемые в аккаунте Google.

Считайте синхронизацию отдельной границей доверия. Зафиксируйте, что загружается, как шифруется, кто разрешает доступ новому устройству, как распространяется удаление и может ли восстановление объединить данные не того профиля.

Site Isolation — другая мера безопасности

На поддерживаемых платформах Site Isolation в Chromium размещает страницы разных сайтов в разных процессах рендеринга с песочницей. Это снижает вероятность того, что скомпрометированный процесс одного сайта получит чувствительные данные другого.

Такая защита действует внутри сеанса браузера. Она не отвечает на вопросы о том, есть ли у двух рабочих профилей отдельные каталоги данных, управление жизненным циклом, разные прокси, независимые резервные копии или разные командные права. И наоборот: продукт может создавать отдельные каталоги, продолжая полагаться на обычную песочницу браузера для защиты от вредоносного веб-контента.

Обе меры важны. Их нужно описывать и проверять отдельно.

Постоянный профиль, инкогнито или одноразовый профиль?

Режим инкогнито Chrome временно хранит cookies и данные сайтов, пока приватный сеанс открыт, а после его завершения не сохраняет эти данные и сведения о посещённых сайтах. Google также указывает, что инкогнито не меняет способы сбора данных посещаемыми сайтами и их сервисами.

Это полезно для короткого сеанса на доверенном устройстве. Но режим плохо заменяет постоянный рабочий профиль, если нужны повторяемый набор расширений, восстанавливаемое состояние, назначенный владелец или управляемая передача работы.

Одноразовый управляемый профиль может сочетать временное хранение с явными правилами запуска, сети и очистки. Удаление тоже нужно подтверждать. Менеджер должен проверять удаление принадлежащих профилю путей и учётных данных и отдельно указывать файлы или записи, сохраняемые вне профиля для аудита или по правовым основаниям.

Восстановление — часть изоляции

Изоляцию можно нарушить восстановлением так же, как запуском. Копирование работающего профиля может смешать старое и новое состояние базы данных. Восстановление под неверным идентификатором может объединить два процесса. Открытие данных нового браузера старой сборкой может вызвать проблемы совместимости; Chromium описывает правила совместимости и понижения версии пользовательских данных.

Архитектура восстановления должна подтверждать, что:

1. резервная копия относится к одной неизменяемой идентичности профиля;
2. снимок сделан в согласованной точке жизненного цикла;
3. секреты защищены в архиве и при восстановлении;
4. версия браузера совместима с восстановленным состоянием;
5. восстановление не объединяет данные с существующим профилем неявно;
6. после прерывания можно вернуться к последнему заведомо исправному состоянию.

Кэш обычно можно создать заново. Закладки, локальные пользовательские данные, учётные данные, состояние расширений и метаданные аудита — не всегда. Политика восстановления должна учитывать различие.

Практическая проверка изоляции

Представим QA-команду, которой разрешено тестировать двух клиентов одного веб-приложения. Клиентские среды A и B должны оставаться независимыми.

Для каждого профиля команда может пройти небольшой набор проверок:

1. Войти, задать настройку, выдать разрешение сайту и создать офлайн-состояние приложения в профиле A.
2. Открыть тот же origin в профиле B и убедиться, что состояние входа и локальные данные A отсутствуют.
3. Настроить нужный сетевой маршрут для B, затем до ввода учётных данных проверить обычные запросы и поведение при сбое.
4. Скачать из каждого профиля безобидный файл-маркер и проверить расположение файлов и круг тех, кто может их читать.
5. Прервать один запуск, открыть профиль заново и убедиться, что состояние не перешло в другой профиль.
6. Сделать резервную копию A, восстановить её под новым тестовым идентификатором и подтвердить, что B не изменился.

Это проверка наблюдаемого поведения. Снимок двух окон разного цвета таким доказательством не является.

Вопросы перед тем, как полагаться на изоляцию

• Какие именно категории данных принадлежат профилю?
• Есть ли пути состояния или кэша за пределами главного каталога профиля?
• Могут ли два запуска одновременно писать в профиль и что этому препятствует?
• Какие процессы или службы браузера общие?
• Применяется ли сетевая политика до первого запроса и блокирует ли соединение при сбое?
• Где скачивание, загрузка на сайт, буфер обмена и уведомления пересекают границу?
• Кто может разблокировать, экспортировать, копировать, восстанавливать или удалять профиль?
• Как хранятся и восстанавливаются ключи шифрования?
• Может ли синхронизация объединить состояние разных профилей или устройств?
• Какие есть подтверждения поведения при сбое, обновлении, резервном копировании и откате?

Как выбрать нужный уровень

Обычный профиль подходит, когда главная цель — порядок и разделение аккаунтов на устройстве под контролем доверенных людей. Управляемая система изолированных профилей нужна, когда существенный риск создают запуск не того профиля, одновременная запись, сетевые ошибки, сбои восстановления или передача работы. Учётная запись ОС, контейнер или виртуальная машина нужны, когда в модель угроз входят другой локальный пользователь, недоверенный нативный код или требуется более строгая системная граница.

Слово «изолированный» — лишь отправная точка. Суть продукта — документированная граница, её поведение при сбоях и доказательства того, что она сохраняется в повседневной работе.

Ограничения

Поведение браузера и ОС меняется со временем и зависит от платформы, политик, расширений и реализации продукта. Перечисленные категории — основа для оценки, а не утверждение, что все менеджеры профилей разделяют одинаковые данные. Проверяйте именно ту версию браузера, устройство, сеть, расширения, провайдера идентификации и процесс восстановления, которые собираетесь использовать.