Як передавати роботу в браузері без передавання паролів і cookies

Команда часто каже «треба поділитися логіном», хоча потреба вужча: переглянути чернетку, оновити дозволений магазин, відтворити регіональну помилку чи продовжити роботу підтримки. Якщо почати із завдання, а не пароля, з’являється більше варіантів.

Що вважати необробленими обліковими даними

Очевидні приклади — паролі, коди відновлення, початкові секрети одноразових паролів, приватні ключі та паролі проксі. У браузері є й менш помітні:

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

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

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

Відокремте завдання від повноважень

До вибору механізму сформулюйте доступ:

Визначений оператор A може виконувати дії B з ресурсом C на погодженому пристрої D до часу E за правилами погодження й аудиту F.

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

Архітектура нульової довіри NIST рекомендує доступ до окремих ресурсів на рівні сеансу з мінімальними правами для завдання. Принцип корисний без придбання продукту з відповідною назвою: це перевірка будь-якої схеми передавання роботи.

Вибирайте моделі в такому порядку

1. Персональний доступ у цільовому сервісі

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

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

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

2. Обмежене делегування сервісом

Якщо сервіс підтримує OAuth або інший протокол, надайте клієнту чи виконавцю лише потрібні ресурси, дії та строк. RFC 9700 рекомендує мінімальні привілеї токена й обмеження його цільовим сервером ресурсів.

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

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

3. Використання збереженого секрету через посередника

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

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

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

4. Захищене передавання сеансу браузера

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

Мінімальний набір контролю:

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

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

5. Передавання необроблених секретів

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

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

Порівнюйте повноваження, а не лише зручність

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

Тому «ніхто не бачить пароля» — недостатній критерій успіху. Важливо, які права отримує людина, на який строк і яка система може їх відкликати.

Ключі доступу покращують вхід, але не створюють командних ролей

WebAuthn створює облікові дані з відкритим ключем для конкретного сервісу. За WebAuthn Level 3, приватний ключ залишається в автентифікаторі, а скрипт сайту отримує підписаний результат. За правильної реалізації це забезпечує стійкість до фішингу.

Ключі доступу автоматично не створюють ролей. Сервіс може зареєструвати окремий засіб для кожного учасника, зберігаючи персональний доступ. Постачальник ключів також може дозволяти синхронізацію чи спільне використання. NIST SP 800-63B-4 визнає таку модель і називає ризики: недозволене використання, поширення на пристроях, компрометація синхронізації та складне відкликання.

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

Визначте правила передавання

До переміщення стану дайте відповіді:

1. Хто діє? Персональна ідентичність організації, не загальне ім’я оператора.
2. Хто дозволив? Власник або рішення політики без збереження секретів погодження.
3. Що передається? Профіль і завдання, не перелік необроблених cookies.
4. Що дозволено одержувачу? Окремі права запуску, редагування, експорту, автоматизації, поширення й адміністрування.
5. Де можна запускати? Лише зареєстровані довірені пристрої, придатні для цих даних.
6. На який строк? Дата завершення й закриття неактивних сеансів.
7. Чи можуть діяти два записувачі? Один активний, якщо іншу модель не спроєктовано й не перевірено.
8. Що записується? Виконавець, пристрій, посилання на профіль, дія, результат і час; за замовчуванням без секретів та вмісту сторінок.
9. Як відкликається? І доступ у менеджері, і сеанс цільового сервісу.
10. Як відновлюється? Остання справна версія без випадкового повернення скасованих прав.

Шифрування — частина цих правил: воно захищає зберігання й передавання. Перевірка прав визначає, хто отримує шлях розшифрування. Довіра до пристрою та локальна ізоляція захищають використання. Аудит підтримує відповідальність і розслідування. Жоден засіб не замінює інших.

Тримайте автоматизацію поза межею секретів

API, SDK, CLI та агентам часто потрібно запустити профіль або виконати дозволену дію життєвого циклу. Їм рідко потрібні значення cookies, паролі, ключі доступу, секрети проксі чи архів.

Вузький інтерфейс може прийняти непрозоре посилання й повернути:

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

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

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

Два рівні відкликання

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

При звичайному завершенні доступу:

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

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

Обмеження залишаються

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

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