# Безопасность (/ru/docs/b24/security)

Общее для всех CLI WireCat — связка ключей, права, MCP и то, что никогда не попадает в журнал, — описано на
[общей странице о безопасности](/llms.mdx/docs/ru/security/content.md). Здесь только то, что относится именно к `b24`.

`b24` хранит настройки в `config.json`, а состояние — в папках, которые показывает `b24 doctor`. Он обращается только
к порталу вебхука или локального приложения профиля и к `oauth.bitrix.info` за токенами приложения, по HTTPS, и
никогда не идет по перенаправлению.

Адрес вебхука несет его секрет в своем пути, поэтому весь адрес и есть пароль. `b24` хранит его в системной связке
ключей (служба `bitrix24-cli`, аккаунт `token:<profile>`) или, с `--credential-storage file`, в закрытом файле, и
никогда не пишет его в вывод, ошибку, журнал или запись запуска: запуск хранит метод и `/rest/:user/:token/<method>`,
но не адрес. Ошибка хранит код ошибки Битрикс24 и имена отклоненных полей, но не описание от Битрикс24, которое может
цитировать введенное.

Вход через локальное приложение хранится там же (аккаунт `oauth:bitrix24:<profile>`). Это код и ключ приложения,
токен доступа, который живет час, и токен обновления, который живет 180 дней и меняется при каждом обновлении. Ключ
уходит только в `oauth.bitrix.info`, как просит Битрикс24, и никогда на портал. Токен уходит на портал в теле каждого
вызова, никогда в адресе. Ни один из них не попадает в вывод, ошибку, журнал или запись запуска. Вход возвращается
через страницу `https://wirecat.dev/webhooks/apps/b24-callback`, которая в вашем браузере передает одноразовый код в
`b24` на этом компьютере. Код действует 30 секунд и только вместе с ключом. В Битрикс24 нет вызова, который отзывает
токен. `session end` забывает вход здесь, а удаление приложения на портале останавливает его.

Вебхук действует с правами сотрудника, который его создал. Вебхук, созданный администратором, позволяет агенту
читать и менять все в CRM. `session status --check` показывает, чьи права у вебхука; создавайте вебхук от
сотрудника, чьи права подходят для работы, и только с нужными scope. `sync` использует `crm`, `user_basic` для адресов
почты сотрудников и `department` для структуры компании. `user_basic` достаточно, потому что `sync` никогда не меняет
сотрудника, а полный scope `user` добавляет право приглашать и править сотрудников. Синхронизация хранит имя, адрес
почты, должность и руководителя отдела каждого сотрудника в локальном хранилище, где их читает любой инструмент
WireCat.

Если пользователь вебхука не администратор Битрикс24, синхронизация копирует только его собственных клиентов, то есть
контакты и компании, назначенные на него или указанные в его сделках и лидах. Списки показывают телефоны и почту
только у них. `people
show` и `organizations show` дают их и для чужих, не больше 100 в день на пользователя и его агентов вместе. Этот
счетчик хранится на этом компьютере, поэтому он остановит случайность или агента, но не того, кто хочет забрать базу.
Это делают права доступа самого Битрикс24.

Каждая запись проверяется по правам и сохраняется в журнале отправок. `B24_READ_ONLY=1` отклоняет любую запись.
Назначение записи другому сотруднику отклоняется, пока вы его не разрешите. Смена стадии все равно может запустить
собственных роботов портала, которые могут написать вашим клиентам. Если на вашем портале есть такие роботы,
задайте `permissions.deals.move` и `permissions.leads.move` как `readonly` или `deny` до того, как агент получит
профиль через MCP, где `ask` ничего не спрашивает
([разрешения](/llms.mdx/docs/ru/b24/permissions/content.md#stage-changes-start-the-portals-robots)). Каждая запись, которая задает
стадию, проверяет их; стадия успеха или провала и `close` проверяют еще и `deals.close` или `leads.close`, а
`api call` со `stageId` проверяет оба. `--field` сделки или лида, который называет стадию, воронку или
ответственного, отклоняется. Удаление сделки или лида сначала спрашивает. `api.crm.deal.update: deny` останавливает
и `deals update`, `move` и `close`, а при `ask` они тоже спрашивают.

`search all` читает то, что разрешают ключи списков: при `deals.list: deny` он не берет сделки, при `leads.list: deny`
лиды, и называет каждый пропущенный вид в `missing` и в stderr. Если запрещены все виды, о которых его спросили, он
отклоняется.

`api call` работает по списку разрешенного. Он разрешает чтение CRM, каталога, пользователей и отделов, которое делает
сам `b24`, и запись сделок, лидов, контактов и компаний. Чтение контактов и компаний доступно только администратору,
что бы ни говорили разрешения. И чтение, и запись проверяют ключ команды, которая читает или
пишет те же записи: `api call crm.deal.list` проверяет `deals.list`, а `crm.item.update` с `entityTypeId` 2 проверяет
`deals.update`. `department.get` проверяет `users.list`, а `crm.mycompany.*` проверяет `organizations.list`. Тело, которое называет одно поле дважды в любом написании (`assignedById` и `ASSIGNED_BY_ID`, `fields`
и `FIELDS`), `entityTypeId`, который не является простым числом, и метод с любым суффиксом, кроме одного `.json`,
отклоняются до отправки. Удаление спрашивает. Любой другой метод тоже спрашивает и без терминала отклоняется, если вы
не передали `--yes`. Методы, которые пишут людям, публикуют или отправляют данные наружу, отклоняются, пока вы их не
разрешите: `im`, `imopenlines`, `imbot`, `imconnector`, `log.blogpost`, SMS, почта, телефония, бизнес-процессы, дела
CRM, задачи, `user.add`, публичные ссылки на файлы, `event.bind` и `batch`. Их чтение тоже отклоняется, потому что в
них лежат сообщения, письма и задачи. `api show <method>` называет уровень метода. `api call`
не предлагается через MCP.

`schedule command` ставит таймер (systemd, launchd или Планировщик заданий), который запускает `b24` сам, без
терминала. Таймер запускает `b24 schedule exec <file>`, а файл расписания в папке состояния хранит слова команды,
профиль, ваш `PATH` и папки, которые использует `b24` (`B24_CONFIG_DIR`, `B24_STATE_DIR`, `MESSAGING_STORE`), но
никогда не адрес вебхука. Каждый запуск заново проверяет разрешения. `B24_READ_ONLY` отклоняет
`schedule command`, `remove`, `run` и `exec`, и ни один инструмент MCP не предлагает `schedule`.

Запись, на которую не пришел ответ, не отправляется снова: она становится `outcome_unknown` со своим
`operation_id`. Проверьте портал и повторите ее, только если ее там нет: Битрикс24 выполнит повтор второй раз.

`b24 work mcp serve --http` слушает только на `127.0.0.1`, для браузерных приложений, которые подключаются к нему
через ваш собственный туннель. Каждое приложение входит по одноразовому коду, а сервер хранит хеш каждого выданного
входа в папке состояния, доступной для чтения только вам. `b24 work mcp revoke` забывает их все.

Запись запуска хранит командную строку в том виде, как вы ее ввели, поэтому `b24 runs show` показывает, что было
запущено. Секрет при этом сохраняется как `[redacted]`: параметр с именем вроде token или password, пароль в ссылке,
длинная непрозрачная строка. Номер телефона заменяется на `[redacted]` внутри введенного слова, включая текст
сообщения: номер, записанный с «+» и кодом страны, или от 11 до 15 цифр подряд, так что длинный id такой длины тоже
скрывается. Чтобы не хранить ни одного введенного слова, выполните `b24 work config set record_input false`.

Секрет распознается и по внешнему виду — в записи запуска и в сохраненном сообщении об ошибке: токен известного
формата (GitHub, OpenAI, Slack, AWS, Stripe, npm и подобные), учетные данные `Bearer`, случайная на вид строка из 20 и
более символов и случайная на вид последовательность из 20 и более шестнадцатеричных символов в нижнем регистре,
например шестнадцатеричный ключ или полный хеш коммита. Значение после имени секрета тоже скрывается, будь то после
`=`, `:` или пробела: `password=`, `API_TOKEN=`, `password hunter2`, `pin 1234`. Некоторые секреты похожи на обычные
слова и остаются: значение из одних букв после имени секрета и пробела (`pin this message` остается),
шестнадцатеричный ключ в верхнем регистре, короткий хеш коммита или UUID, короткий пароль, введенный без имени
секрета перед ним, и секрет внутри ссылки или пути к файлу, если он не известного формата и не стоит после имени
секрета.

`config.json` сохраняется доступным для чтения только вам (`0600`), а его папка создается только для вас (`0700`).
Файл или папка, созданные старой версией, могут быть открыты другим пользователям компьютера: `b24 doctor` выводит
каждый такой путь в `files.problems` и печатает `chmod`, который это исправляет. В Windows это не проверяется. Об
уязвимости сообщайте так, как описано в [SECURITY.md](https://github.com/WireCatLabs/bitrix24-cli/blob/main/SECURITY.md).