Як оцінити браузер для команди: практичний список перевірок

Визначте рішення до перегляду тарифів

Корисне оцінювання починається з роботи, а не списку постачальників. Запишіть:

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

Розрізняйте види ресурсів. План із 500 збереженими профілями, 100 хмарними профілями, п’ятьма місцями й десятьма одночасними сеансами не дає 500 паралельних командних сеансів. Переведіть кожен ліміт в одиниці вашої роботи.

Визначте обов’язкові умови. Наприклад:

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

Не усереднюйте провалену обов’язкову умову в загальний бал. Гарний інтерфейс не компенсує неперевіреного оновлення чи втрати стану при відновленні.

Проста шкала доказів

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

Результат

• Пройдено: вимогу продемонстровано у визначеному середовищі.
• Зауваження: поведінка суперечить вимозі або створює значущий компроміс.
• Не перевірено: доказів немає, вони недоступні, застарілі або неоднозначні.
• Не застосовується: вимога не стосується роботи; причину записано.

Доказ

1. Опублікована заява: маркетинговий або комерційний текст.
2. Технічна документація: версійні документи продукту, безпеки, API чи підтримки.
3. Спостережувана демонстрація: постачальник наживо виконує ваш сценарій.
4. Контрольоване випробування: команда відтворює поведінку на одноразових даних і записує версії та результати.
5. Незалежний або договірний доказ: оцінка з визначеним обсягом, підписане зобов’язання чи умови підтримки, що охоплюють вимогу.

Вищий рівень не завжди кращий. Незалежний звіт може виключати настільний браузер, тоді як власний тест перевіряє саме його. Для кожного матеріалу фіксуйте обсяг, дату, версію та обмеження.

1. Стан продукту та межі заяв

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

Збережіть інсталятор, екран версії, примітки випуску та документи на дату оцінювання. Відповідь відділу продажів без сталого посилання — заява, а не перевірена поведінка.

2. Ізоляція й цілісність профілів

Спочатку визначте, що продукт називає профілем: постійний каталог браузера, тимчасовий контекст, синхронізований архів, віддалений сеанс чи набір налаштувань. Це різні речі.

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

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

Потрібні перехресні тести: поставте нешкідливу ознаку в A, перевірте її відсутність у B, перезапустіть обидва й повторіть після оновлення. Використовуйте одноразові акаунти та синтетичні дані.

3. Актуальність браузера, пісочниця та оновлення

Браузер — важливий для безпеки компонент, який потребує постійного супроводу. Починаючи з Chrome 153, випущеного 8 вересня 2026 року, нові версії Chrome Stable виходять кожні два тижні. Цей графік випусків не визначає точних зобов’язань кожного постачальника, але показує, чому слів «на базі Chromium» недостатньо без відомостей про версії та оновлення.

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

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

Для цілісності оновлень корисний The Update Framework, який прямо розглядає компрометацію репозиторію та ключів. SLSA provenance визначає перевірювані дані про місце, час і спосіб створення файла. Постачальник не зобов’язаний використовувати саме ці проєкти, але має пояснити ідентичність файлів, компрометацію ключів, повернення старих версій, затримування оновлень та походження збірок.

4. Ідентичності, пристрої та мінімальні права

NIST SP 800-53, редакція 5 групує засоби доступу, аудиту, автентифікації, аварійного планування, реагування й ризиків постачання. Використовуйте групи для запитань, а не вважайте заявлену відповідність доказом реалізації.

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

Терміни й рівні довіри дивіться в NIST SP 800-63B-4, остаточну версію якого опубліковано 31 липня 2025 року. Уточніть охоплення заяв: вхід на сайт, розблокування застосунку, локальний API, хмарний API, відновлення та підтримка можуть мати різні механізми.

5. Чутливі дані та межі довіри

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

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

«Зашифровано» — неповна відповідь. Запишіть категорію, місце, межу шифрування, власника ключа, відновлення та випадки існування відкритого тексту.

6. Співпраця й аудит

• □ Чи зрозумілий власник під час призначення й передавання профілю?
• □ Чи одночасні зміни блокуються або явно узгоджуються?
• □ Чи записуються запрошення, ролі, запуски, зупинки, доступ, експорт, видалення, автоматизація й відновлення?
• □ Чи подія визначає людину, делеговане завдання, ресурс, час, рішення й результат?
• □ Чи значущі зміни мають попередні й нові значення без секретів?
• □ Чи однозначні час, пояс, порядок подій і ID запитів?
• □ Чи описано доступ до аудиту, формат експорту, зберігання й видалення?
• □ Чи може адміністратор змінити або стерти записи власної перевірки?
• □ Чи можна експортувати журнали до вашої системи моніторингу або розслідування?
• □ Що відбувається при недоступності приймача журналів: продовження, безпечна черга чи блокування?

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

7. Відновлення, переривання й вихід

Заява про резервування неповна без тесту відновлення. NIST CSF 2.0 охоплює створення, захист, підтримку й тестування копій та перевірку засобів і результатів відновлення.

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

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

8. Автоматизація й засоби розробника

• □ Чи продукт надає версійні предметні операції замість необмеженого доступу до файлів або процесів?
• □ Чи окремо описано API, CLI, SDK, Playwright, CDP, WebDriver, вебхуки та агентів?
• □ Чи є точна матриця сумісності браузера й клієнта?
• □ Чи можна обмежити секрет клієнтом, профілем, операцією, цільовим сервісом, строком, частотою та витратами?
• □ Чи руйнівні, масові, зовні видимі, секретні або платні дії потребують сильнішої політики чи погодження?
• □ Чи попередній перегляд прив’язаний до точного виконуваного запиту?
• □ Чи команди зміни стану ідемпотентні або явно позначають невідомий результат?
• □ Чи можна скасувати й безпечно продовжити довгу операцію?
• □ Чи відкликання діє під час активного завдання?
• □ Чи автоматизація має той самий простежуваний аудит, що й люди?
• □ Чи вивід корисний без необробленого стану сеансу?
• □ Чи помилки допомагають відновитися без розкриття секретів?

Перевіряйте відмови. Токен лише для читання не має запускати профіль. Токен конкретного профілю не має відкривати іншу папку. Прострочений секрет не повинен непомітно оновлюватися до ширших прав. Агент не має перетворювати відхилений запит на погодження адміністратора зміною формулювання.

9. Зручність і доступність

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

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

10. Комерційна й операційна відповідність

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

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

План контрольованого випробування

Використовуйте тестові акаунти, синтетичні секрети та спеціально створені профілі. Не імпортуйте виробничі cookies заради реалістичності.

1. Зафіксуйте середовище. Версії застосунку й браузера, ОС, обладнання, мережу, тип проксі, розширення, план і дату.
2. Створіть дві ролі й кілька профілів. Адміністратор, обмежений оператор, різні папки та щонайменше один заборонений оператору профіль.
3. Виконайте звичайну роботу. Запуск, використання, зупинка, передавання й повторний запуск; очікуваний і фактичний стан.
4. Перевірте відмови. Недозволений профіль, експорт, зміну ролі та команду автоматизації від обмеженої ідентичності.
5. Перевірте переривання. На одноразових даних безпечним або підтримуваним способом перервіть зупинення чи синхронізацію й перевірте відновлення.
6. Відновіть і порівняйте. Створіть нову копію з відомого знімка, перевірте цілісність і збережіть поточну до приймання.
7. Відкличте доступ. Користувач, пристрій, сеанс і службовий секрет; перевірте відмову UI та API й події аудиту.
8. Перевірте переносність. Експортуйте дозволені дані, перевірте формат, за підтримки імпортуйте в одноразову ціль і назвіть пропущене.
9. Перевірте доступність. Виконайте основні дії клавіатурою й потрібними допоміжними технологіями на кожній платформі.
10. Зіставте витрати й заяви. Порівняйте фактичні ресурси та відповіді підтримки з пропозицією й договором.

Шаблон рішення

Вимога	Пріоритет	Результат	Доказ і дата	Обмеження або ризик	Відповідальний і наступна дія
Приклад: оператор не експортує стан сеансу	Обов’язкова	Пройдено	Контрольований тест, версія X, РРРР-ММ-ДД	Лише API; CLI не перевірено	Відповідальний за безпеку перевіряє CLI

Завершіть оцінювання чотирма явними списками:

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

Типові тривожні ознаки

Призупиніть рішення, якщо:

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

«Не перевірено» — не звинувачення, а точний опис браку доказів. Зберігайте цей статус, доки постачальник не надасть підтвердження, команда не виконає тест або відповідальний не прийме ризик.