Как передавать браузерную работу без пересылки паролей и cookies

Команды часто говорят «нужно передать логин», хотя задача уже: проверить черновик, обновить разрешённую витрину, воспроизвести региональную ошибку или продолжить обращение поддержки. Если начать с задачи, а не с пароля, вариантов становится больше.

Что считается исходными учётными данными

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

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

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

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

Отделите задачу от полномочий

До выбора способа передачи сформулируйте доступ:

Исполнитель A вправе выполнять действия B над ресурсом C с разрешённого устройства D до момента E по правилам согласования и аудита F.

Формулировка выявляет лишние права. Для согласования одного черновика полный административный сеанс чрезмерен. Если сервис уже поддерживает роль проверяющего, передача состояния браузера добавляет риск без новой возможности.

Архитектура нулевого доверия NIST рекомендует доступ к отдельным ресурсам на уровне сеанса с минимальными правами для задачи. Принцип применим без покупки продукта с названием «zero trust» и полезен для любой передачи браузерной работы.

Предпочитайте модели в таком порядке

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

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

Обычно это самая сильная модель: права проверяются там, где понятен смысл действия. Менеджер браузера не может надёжно превратить общий административный сеанс сайта в роль проверяющего на этом сайте.

Общие и групповые аккаунты снижают прослеживаемость. NIST SP 800-53 Rev. 5 советует ограничивать их применение и заранее задавать явные условия допустимости.

2. Ограниченное делегирование целевого сервиса

Если сервис предлагает OAuth или другой протокол, выдавайте клиенту или исполнителю только нужные ресурсы, действия и срок. RFC 9700 рекомендует минимальные полномочия токена и ограничение получателя целевым сервером ресурсов.

Предпочитайте короткоживущие отзывные разрешения для конкретного получателя. Токены с привязкой к отправителю уменьшают риск повторного использования утечки, но не помогают, если атакующий получил и токен, и связанный ключ. Устройство и программа клиента остаются внутри модели угроз.

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

3. Использование сохранённого секрета через посредника

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

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

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

4. Защищённая передача браузерного сеанса

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

Минимальные меры:

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

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

5. Передача исходных учётных данных

Копирование пароля, cookie, кода восстановления, ключа доступа или архива профиля в сообщение, таблицу, заявку, скрипт или незащищённый экспорт создаёт долговечный секрет с неизвестными копиями и слабым отзывом. Избегайте этого.

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

Сравнивайте полномочия, а не только удобство

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

Поэтому критерия «никто не видит пароль» недостаточно. Важно, сколько полномочий получает человек, как долго и какая система может их отозвать.

Ключи доступа улучшают вход, но не решают передачу ролей

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 как неявно используемые полномочия: браузер может приложить их к запросу, даже если инициатор не знает значения. В этом главное ограничение передачи сеанса. Скрытие учётных данных уменьшает раскрытие, но не полномочия, которые может использовать браузер.