Расширения браузера с ИИ: что проверить перед доступом к рабочей CRM

Помощник появился раньше согласованного доступа

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

Это сценарная ситуация, а не описание инцидента клиента НТА. Она показывает разрыв между полезной функцией и техническим полномочием. Пользователь оценивает качество ответа. Администратор видит установленное дополнение. Владелец CRM отвечает за доступ сотрудника. При этом ни один из трёх вопросов сам по себе не устанавливает, какие данные вправе получить поставщик помощника.

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

В статье рассматривается механизм расширений Chrome и средства управления Яндекс Браузера для организаций. Общие термины помогают поставить проверку, но одинаковый движок не доказывает одинаковое поведение конкретных сборок. Версию, операционную систему и способ управления нужно записать в карточку допуска. Здесь нет заключения о каком-либо коммерческом расширении: такого образца мы не испытывали.

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

Что расширение получает вместе со страницей

Браузер строит модель открытого документа — DOM. Это программное представление элементов страницы, с которым работает её код. Скрипт расширения, допущенный к странице, тоже может обращаться к этой модели. Поэтому предложение «расширение работает отдельно» требует уточнения: отдельно от чего?

Документация Chrome разделяет среду JavaScript и DOM. Переменные страницы и скрипта расширения в изолированных средах не становятся общими, однако сам документ остаётся доступен обеим сторонам. Изоляция кода нужна, но из неё не следует изоляция раскрытого содержимого. При этом установленное расширение без соответствующего доступа нельзя автоматически считать способным читать любую страницу.

Представим вымышленную карточку: описание проблемы, ответственный и внутренний комментарий. Для составления ответа нужен первый фрагмент. Если скрипту доступен весь документ, организационное правило «пользователь выделяет только обращение» ещё не доказывает технического запрета прочитать комментарий. Сначала проверяют фактический состав доступных данных, затем поведение расширения. Техническая возможность чтения и состоявшаяся отправка — разные утверждения, для которых нужны разные доказательства.

×

Схема НТА по документации Chrome: изоляция JavaScript не означает отдельную копию документа для расширения.

Возможность извлечения содержимого не является исключительно мысленным предположением. Исследователи Arcanum на USENIX Security 2024 отслеживали потоки содержимого страниц и обнаружили расширения, автоматически извлекавшие пользовательские данные. Исследование охватывало семь публичных сайтов. Это эмпирическое основание проверять такой путь, но не оценка доли опасных ИИ-расширений сегодня и не результат испытания российской CRM.

Для решения важна и граница серверной защиты. Если система контролирует раскрытие поля, это ограничивает момент появления значения у пользователя. Но когда значение уже передано в документ, вопрос о его чтении расширением относится к клиентскому контуру. Публичное описание коннектора DataSafe для BPMSoft не даёт основания обещать автоматическое пресечение такого чтения. Защиту хранения и доступ к раскрытой странице проверяют раздельно.

Сначала назначение, затем перечень разрешений

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

Начните с одного наблюдаемого результата. Например: «сотрудник получает черновик ответа по выбранному описанию обращения; расширение не меняет запись и не отправляет сообщение клиенту». Это проектное ограничение вымышленного сценария. Оно ещё не говорит, что выбранный продукт его соблюдает, зато задаёт предмет проверки. Если полезный результат невозможно сформулировать без доступа ко всей CRM, это уже другой объём решения.

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

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

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

Временный доступ и постоянное разрешение

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

В Chrome механизм activeTab предоставляет расширению временный доступ к активной вкладке при вызове. Его область не следует понимать как «один выделенный абзац». Документация также указывает, что переход на другой путь в пределах того же origin может сохранить доступ; уход на другой origin или закрытие вкладки его прекращает. Поэтому нажатие кнопки не тождественно одному мгновенному чтению.

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

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

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

Где заканчивается правило о страницах CRM

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

Документация корпоративных настроек Chrome указывает: в шаблонах разрешённых и запрещённых для взаимодействия сайтов нельзя задавать путь. Для сетевых host permissions Chrome также поясняет, что часть пути после имени узла игнорируется. Это разные механизмы, но оба предупреждают против обещания ограничить всё расширение одним адресом раздела через доменную запись.

Рассмотрим сценарий: обращения и контакты находятся на одном корпоративном домене. Пользователь получает доступ к помощнику, находясь в обращении, а затем переходит в контакт без смены origin. Принятое условие «помощник только для обращений» не становится техническим фактом просто потому, что его записали в согласовании. Нужно проверить переход, фактическую политику, скрипты и все используемые способы чтения. Если продукт сам добровольно пропускает раздел, отдельно оценивают, достаточно ли организации такой границы доверия.

Возможная архитектурная альтернатива — специально выделенное представление с допустимыми полями и отдельной проверяемой областью доступа. Но это не универсальная рекомендация немедленно перенести CRM на другой домен. Такое изменение затрагивает вход, роли, ссылки и сопровождение; его стоимость и ограничения нужно оценить как проект. Для одного необязательного помощника отказ от доступа может оказаться проще.

Ещё одна частая ошибка — принимать невидимость за отсутствие данных. Поле может отсутствовать в показанном фрагменте экрана, но вопрос исследования состоит в том, что доступно скрипту документа. И обратное: нельзя объявлять доступными все сведения CRM только потому, что сотрудник вошёл в систему. Требуется конкретная карта страницы, роли и состояния, а не вывод по внешнему виду окна.

Передача данных требует отдельного решения

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

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

Отдельно стоит проверить обещание «всё локально». Manifest V3 ограничивает удалённо размещённый исполняемый код, однако само по себе это не запрещает обмен данными с ИИ-сервисом. Утверждение о месте обработки должно опираться на документацию выбранного продукта, его состав и наблюдаемый режим работы. Версия формата манифеста не отвечает на этот вопрос за поставщика.

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

×

Методика НТА: подтверждение установки не заменяет проверку чтения и сетевой передачи.

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

Кто управляет установкой и изменениями

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

В Яндекс Браузере для организаций политика ExtensionSettings управляет установкой, разрешениями и взаимодействием с сайтами. Документация различает блокировку новой установки и режим удаления ранее установленного расширения. У политики есть условия применения по ОС и способу управления. Поэтому в карточке фиксируют не только желаемую настройку, но и подтверждение её действия в нужной среде.

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

Допуск привязывают к идентификатору расширения, версии, источнику установки и способу обновления. Названия недостаточно: сотрудник должен иметь возможность однозначно отличить одобренный объект. При пересмотре важны изменения прав, получателей, состава отправки и назначения, а не только новый номер. По правилам Chrome добавление права с предупреждением может потребовать принятия. Из этого нельзя заключать, что любое существенное изменение обязательно покажет новое предупреждение.

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

Как провести ограниченную проверку

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

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

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

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

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

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

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

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

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

Отрицательный результат тоже должен быть понятным

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

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

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

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

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

Что останется за пределами проверки

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

Наблюдение запросов подтверждает только видимый участок пути. Даже если содержимое и адрес совпали с ожиданием, оно не доказывает исполнение обещаний о серверном хранении и удалении. И наоборот, наличие соединения ещё не доказывает передачу клиентского текста: нужно исследовать состав и назначение. Смешение этих утверждений порождает как необоснованные обвинения, так и необоснованные разрешения.

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

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

Если помощник начинает вызывать корпоративные инструменты, изменять записи или отправлять сообщения, появляется дополнительная задача. Её НТА разбирает в материале о полномочиях ИИ-ассистента. Карточка браузерного допуска не разрешает эти действия автоматически: она отвечает за свою границу — доступ к странице и передачу её содержимого.

Карточка допуска для одного расширения

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

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

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

Тест понедельником

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

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

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

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

Важное уведомление

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