Ізоляція профілів браузера: що саме відокремлюється?

«Окремий профіль» звучить однозначно, доки від цього не залежить реальна робота. Один продукт має на увазі іншу папку. Інший додає нагляд за процесами, окрему мережеву політику, шифрування, блокування, резервні копії та права команди. Сама назва не гарантує жодного конкретного поєднання цих меж.

Тому практичне запитання таке: від чого саме відокремлено профіль, від якого збою чи учасника це захищає та чим це підтверджено?

Чотири межі, які легко сплутати

Межа	Що вона розділяє	Чого вона не гарантує
Вебджерело, або origin	Сховища різних джерел, доступні скриптам сайтів	Розділення двох входів на той самий сайт в одному профілі
Профіль браузера	Набір стану браузера, пов’язаний із профілем	Захист від людини з доступом до того самого облікового запису ОС
Site Isolation і пісочниця	Вміст різних сайтів у процесах рендерингу з обмеженими правами	Окрему інсталяцію браузера чи мережевий стек для кожного профілю
Обліковий запис ОС, контейнер або віртуальна машина	Файли, процеси, облікові дані, а іноді й мережеву політику на системному рівні	Автоматичне розділення акаунтів у браузері без відповідних налаштувань

Ці рівні розв’язують різні завдання. Правила одного джерела забороняють звичайному скрипту одного сайту читати сховище іншого джерела. Модель безпеки Site Isolation у Chromium додає між сайтами межі ізольованих процесів рендерингу. Профіль об’єднує стан браузера для людини або робочого процесу. Обліковий запис ОС чи віртуальна машина забезпечують сильнішу межу проти локального зловмисника або між середовищами виконання.

Твердження про один рівень не можна вважати доказом захисту на іншому.

Що зазвичай розділяє постійний профіль браузера

Документація Chromium зазначає, що каталог даних користувача містить історію, закладки, cookies та інші дані, а кожен профіль є підкаталогом у цьому каталозі. Довідка Chrome про профілі також описує окреме зберігання закладок, історії, паролів і налаштувань.

Для постійного робочого профілю очікувана межа зазвичай охоплює такі дані:

Дані	Практичний результат розділення
Cookies і стан автентифікації	Вхід у сервіс у профілі A не повинен автоматично авторизувати профіль B через спільне сховище cookies
Локальне сховище й бази даних сайтів	Локальний стан вебзастосунку належить профілю, у якому його створено
HTTP-кеш і Cache Storage	Повторно використовувані відповіді та офлайн-дані застосунків зазвичай не переходять до іншого профілю
Історія, закладки та стан відкритого сеансу	Записи переходів і збережені адреси залишаються у відповідному робочому контексті
Дозволи сайтів	Доступ до камери, мікрофона, сповіщень, геолокації та інші дозволи можуть відрізнятися
Розширення та їхній стан	Набір розширень, налаштування та наданий доступ можна керувати окремо
Паролі й автозаповнення	Локальні облікові дані та дані форм залишаються у вибраному профілі з урахуванням увімкненої синхронізації акаунта

Фізичне розташування залежить від платформи. За документацією Chromium, шлях до кешу може визначатися шляхом профілю, але вести до системного каталогу кешу, а не до папки з рештою даних. Документація також відрізняє дані профілю від іншого локального стану інсталяції в каталозі даних користувача. Надійна схема ізоляції має враховувати всі належні профілю шляхи та описувати спільний стан інсталяції. Одна видима папка — не обов’язково вся межа.

Межа каталогу потребує керування життєвим циклом

Унікальний шлях запобігає випадковому використанню чужого стану лише тоді, коли кожен запуск отримує правильний шлях. Chromium також попереджає, що два одночасно запущені екземпляри Chrome не можуть безпечно використовувати один каталог даних. Керована система профілів має явно визначати правила:

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

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

Що профіль браузера не розділяє автоматично

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

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

Якщо загроза включає цікаву або недоброзичливу людину поруч, потрібні окремі облікові записи ОС, контроль пристрою чи сильніша межа виконання. Шифрування профілю та правила розблокування можуть зменшити ризик для даних на диску. Однак потрібно оцінити їхню реалізацію, зберігання ключів, відновлення та поведінку після розблокування.

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

Кілька профілів можуть міститися в одному каталозі даних Chromium. Зазвичай вони використовують спільну інсталяцію браузера та механізм оновлення. Окремий стан профілів не створює окремої політики виправлень безпеки.

Це може бути зручно: один підтримуваний браузер простіше послідовно оновлювати. Водночас застаріла або скомпрометована збірка впливає на всі профілі, що нею користуються. Актуальність браузера, перевірка підписів і безпечне повернення до попередньої версії належать до оцінки ізоляції.

Мережева ідентичність

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

Якщо потрібен окремий проксі для профілю, перевіряйте не лише адресу в налаштуваннях. Протестуйте автентифікацію, DNS, WebSocket та інші протоколи, поведінку після збою і до готовності проксі. Пряме з’єднання при відмові проксі може зруйнувати очікувану мережеву межу навіть за правильно збережених налаштувань.

Характеристики пристрою та середовища

Профілі можуть мати різні cookies і налаштування, але показувати характеристики того самого браузера, ОС, обладнання, екрана, мови та мережі. W3C описує цифрове відбиткування як повторне впізнавання за доступними характеристиками. У рекомендаціях 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. Відкрити те саме вебджерело у профілі B та переконатися, що в ньому немає авторизації й локального стану A.
3. Налаштувати потрібний мережевий маршрут для B і до введення облікових даних перевірити звичайні запити та поведінку при збоях.
4. Завантажити нешкідливий контрольний файл з кожного профілю та перевірити його розташування й доступність.
5. Перервати один запуск, відкрити профіль знову та перевірити, що жодні дані не перейшли до іншого профілю.
6. Створити резервну копію A, відновити її під новим тестовим ідентифікатором і підтвердити, що B не змінився.

Це перевіряє спостережувану поведінку. Знімок двох вікон різного кольору — ні.

Запитання перед тим, як покладатися на ізоляцію

• Які саме категорії даних належать профілю?
• Чи є стан або кеш за межами основного каталогу?
• Чи можуть два запуски записувати дані в один профіль і що цьому запобігає?
• Які процеси або служби браузера спільні?
• Чи застосовується мережева політика до першого запиту та чи блокує трафік при відмові?
• Де завантаження, передавання файлів, буфер обміну та сповіщення перетинають межу?
• Хто може розблокувати, експортувати, скопіювати, відновити чи видалити профіль?
• Як зберігаються та відновлюються ключі шифрування?
• Чи може синхронізація об’єднати стан різних профілів або пристроїв?
• Які є докази поведінки при збоях, оновленні, резервному копіюванні та поверненні до попередньої версії?

Як вибрати потрібну межу

Звичайний профіль підходить, якщо головна мета — впорядкувати роботу й розділити акаунти на пристрої довірених людей. Керована система ізольованих профілів потрібна, коли запуск не того профілю, одночасний запис, мережеві помилки, невдале відновлення або передавання роботи створюють істотний ризик. Обліковий запис ОС, контейнер чи віртуальна машина потрібні, коли загроза включає іншого локального користувача, недовірений нативний код або потребу в сильнішій системній межі.

Слово «ізольований» — лише початок. Реальна цінність полягає в описаній межі, її поведінці при відмові та доказах того, що вона витримує щоденну роботу.

Обмеження

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