Доступ фулфилмента к кабинету селлера: правила безопасности
Один фулфилмент-оператор может ежедневно собирать десятки заказов, печатать этикетки, сверять остатки, готовить поставки на FBO и передавать статусы по FBS.
Если все эти операции идут через сообщения в мессенджере, селлер тратит часы на пересылку заданий, выгрузок и скриншотов. Логичный следующий шаг — дать подрядчику доступ к личному кабинету маркетплейса.
Именно на этом шаге часто появляется критическая уязвимость: владелец отправляет пароль, одноразовый код из SMS или просит фулфилмент войти под его Ozon ID. Формально это ускоряет старт. Фактически — превращает кабинет с финансовыми отчётами, карточками, рекламой и логистикой в общий аккаунт без журнала ответственности.
Доступ фулфилмента к личному кабинету маркетплейса должен работать иначе: через отдельного пользователя с минимально необходимыми правами или через API-ключ, выпущенный под конкретную интеграцию. Это не бюрократия ради бюрократии. Это способ отделить складскую операцию от управления бизнесом — и затем безболезненно отключить её, когда подрядчик меняется.
Почему пароль от кабинета — не «быстрый старт», а технический долг
Пароль владельца кабинета — это не доступ к заказам. Это доступ ко всему контуру управления магазином: финансовым данным, реквизитам, товарам, поставкам, ценам, акциям, рекламным инструментам и настройкам сотрудников. В зависимости от маркетплейса такой вход может давать возможность менять критичные параметры или видеть данные, которые складу не нужны в принципе.
Передача SMS-кодов и основного номера телефона усугубляет проблему. Одноразовый код — часть второго фактора аутентификации, а не временный пропуск для подрядчика. Как только этот канал оказывается вне контроля владельца, двухфакторная защита перестаёт выполнять свою задачу.
На Wildberries риск выше ещё и потому, что кабинет жёстко связан с ИНН и первоначальным номером телефона. При смене номера телефона владельца включается режим карантина. Это не тот процесс, который стоит запускать из-за желания быстро подключить склад.
У общего логина есть четыре практических дефекта:
- Нельзя разделить ответственность. Если изменились данные карточки, исчезла поставка из рабочего процесса или были выгружены финансовые документы, в общем аккаунте сложно установить исполнителя действия.
- Невозможно применить принцип минимальных привилегий. Сотруднику нужен доступ к заданиям на сборку, но он получает одновременно отчёты, цены и потенциально инструменты продвижения.
- Отключение становится болезненным. После расторжения договора придётся менять пароль, проверять активные сессии, восстанавливать контроль над номером и убеждаться, что доступ не сохранился в браузере, менеджере паролей или внутренней системе оператора.
- Интеграция зависит от человека, а не от архитектуры. Когда API-ключ и учётная запись не отделены от владельца, перенос процессов к новому фулфилменту превращается в ручную миграцию с багами и пропущенными заказами.
Хороший доступ — тот, который можно отозвать за несколько минут и без смены главного пароля кабинета.
Для фулфилмента обычно не требуется полноценное администрирование магазина. Ему нужны операционные данные: новые отправления, состав заказа, сроки сборки, штрихкоды, статусы отгрузки, иногда остатки и задания на перемещение. Всё остальное — финансовые отчёты, рекламные кампании, реквизиты, ценообразование — должно оставаться в контуре селлера или его доверенной команды.
Wildberries: отдельный пользователь вместо делегирования главного входа
Вопрос «как дать доступ фулфилменту на ВБ» часто формулируют неверно. Передавать доступ к кабинету владельца не нужно. На Wildberries для этого предусмотрено добавление пользователей через ссылку-приглашение.
Владелец кабинета формирует приглашение в разделе управления пользователями, передаёт ссылку конкретному сотруднику или ответственному менеджеру оператора, а затем настраивает его права. После авторизации приглашённого пользователя ссылка становится недействительной. Это снижает риск повторного использования приглашения или его случайной пересылки в общий чат.
Здесь есть нюанс, который легко пропустить при первом подключении. Пользователь на Wildberries — не готовая роль с полностью предопределённым набором разрешений. Владелец вручную задаёт, что именно доступно приглашённому сотруднику. Например, можно ограничить просмотр финансовых отчётов либо закрыть управление отдельными инструментами, включая подписку «Джем» или «Витрину магазина».
Как настроить доступ без лишних привилегий
Рабочий порядок выглядит так:
1. Определить операционный сценарий до приглашения пользователя.
Фулфилмент работает только с FBS-заказами? Тогда ему не нужен доступ к аналитике, финансам и карточкам. Оператор также готовит поставки на склад Wildberries? Значит, набор разрешений будет шире, но всё равно не обязан включать коммерческие и финансовые разделы.
2. Создать отдельного пользователя для конкретного человека или функциональной группы.
Не стоит выдавать одну учётную запись на весь склад. При смене менеджера или увольнении сотрудника селлер теряет понимание, кто фактически работал в кабинете. Персонализированные доступы лучше ложатся в аудит и последующее отключение.
3. Открыть только нужные разделы.
Складскому исполнителю могут понадобиться задания и логистические операции. Доступ к отчётам реализации, взаиморасчётам, управлению магазином, подпискам и витринам следует включать только при понятной бизнес-причине.
4. Проверить доступ со стороны приглашённого пользователя.
В тестовом проходе полезно убедиться, что фулфилмент видит нужные заказы и документы, но не видит финансовые данные. Такая проверка занимает несколько минут и устраняет типичный баг настройки: права выданы слишком широко либо, наоборот, сотрудник не может завершить операцию без ручной помощи селлера.
5. Зафиксировать владельца доступа.
Внутри команды селлера стоит записать: кому выдан доступ, для какой задачи, на каком основании и кто отвечает за его отключение. Не обязательно строить тяжёлую IAM-систему; для небольшого бизнеса достаточно таблицы или карточки в таск-трекере.
| Задача фулфилмента | Нужен доступ в кабинет WB | Риск при избыточном доступе |
|---|---|---|
| Сборка и отгрузка FBS-заказов | Да, к операционным разделам | Просмотр коммерческих данных, не связанных со сборкой |
| Подготовка поставки на склад | Да, если оператор оформляет поставку | Ошибочные изменения в логистическом процессе |
| Печать этикеток и работа со штрихкодами | Обычно да | Доступ к несвязанным инструментам кабинета |
| Анализ прибыли и сверка выплат | Нет, если это не бухгалтер или финансовый менеджер | Раскрытие маржинальности, выручки, удержаний |
| Управление рекламой, витриной, подписками | Как правило, нет | Нецелевые расходы и изменения в коммерческой части магазина |
Важно не путать маркировку пользователя и права доступа. Само добавление сотрудника не заменяет ручную настройку разрешений. Если селлер видит в системе понятную подпись к пользователю, это ещё не означает, что у него автоматически ограничены финансы или управление инструментами.
Ozon: роли для логистики и доступы для интеграций
В Ozon модель разделения доступа более выражена на уровне ролей. Для складских и доставочных операций предусмотрены специализированные варианты, включая «Курьера» и «Сборщика-курьера». В таких ролях скрываются цены товаров и финансовые показатели, зато остаются логистические данные, необходимые для исполнения заказов.
Это полезное разделение: исполнитель видит не экономику SKU, а маршрут своей работы. Для фулфилмента, который собирает заказы, передаёт их в доставку или работает с последней милей, это ближе к правильной модели, чем универсальный доступ ко всему кабинету.
Однако роль не решает все задачи. Она подходит для людей, работающих в интерфейсе Ozon Seller. Если у оператора есть собственная WMS, ERP или панель управления несколькими складами, ему чаще нужен не вход в веб-интерфейс, а интеграция через API.
Ozon позволяет создавать API-ключи с разной областью действия. Среди доступных типов разрешений — Admin, Product, Review, Question, Report и Actions. С технической точки зрения это означает, что интеграцию можно собрать модульно: складская система получает только те методы API, которые требуются её процессу, а не полный доступ к кабинету.
Пользователь, API-ключ или оба механизма
Выбор зависит не от размера фулфилмента, а от того, где выполняется работа.
| Сценарий | Подход | Что получает оператор | Что остаётся у селлера |
|---|---|---|---|
| Сотрудник вручную собирает заказы в интерфейсе | Отдельный пользователь с логистической ролью | Операционные задания и статусы | Финансы, цены, отчёты, управление магазином |
| Фулфилмент ведёт сборку в собственной WMS | API-ключ с ограниченными разрешениями | Данные и методы, нужные интеграции | Веб-доступ владельца и лишние API-методы |
| Оператор готовит поставки, а селлер контролирует экономику | Пользователь + отдельная API-интеграция | Интерфейс для операций и машинный обмен данными | Финансовый контур и административные настройки |
| Подрядчик делает всё «под ключ» и просит пароль | Ни один из вариантов не оправдывает передачу пароля | — | Контроль, аудит и возможность быстро отозвать доступ |
На практике полезно разделить два контура:
- человеческий доступ — для сотрудника, который видит заказы, печатает документы и подтверждает операции;
- машинный доступ — для WMS, сервиса печати, дашборда остатков или другого ПО, которое обменивается данными без участия человека.
Это избавляет от распространённой схемы, когда API-ключ лежит в общем чате вместе с логином владельца «на всякий случай». У каждого токена должна быть понятная задача, владелец и дата пересмотра.
API-ключ — не пароль в другом формате. Это отдельный пропуск для конкретного программного процесса.
API-ключи Ozon: минимальные права и ротация раз в 180 дней
С 13 февраля 2026 года Ozon Seller перевёл новые API-ключи на систему ротации. Срок действия таких ключей ограничен 180 днями, после чего они автоматически отзываются. Для селлера это меняет не сам принцип интеграции, а операционную дисциплину вокруг неё.
Если ключ создан для фулфилмента, его истечение не должно обнаруживаться в момент, когда заказы перестали попадать в WMS. Ротацию следует включить в регулярный процесс: создать новый ключ заранее, обновить его в системе оператора, протестировать обмен и только потом отключить прежний ключ, если он ещё действует.
Для ключей, выпущенных до 12 февраля 2026 года включительно, нельзя исходить из предположения о бессрочной работе. Точные сроки их принудительного отзыва не стоит подменять догадками. Надёжнее провести инвентаризацию уже сейчас: понять, где они используются, какие права имеют и кто отвечает за замену.
Практика выпуска ключа для фулфилмента
При настройке прав доступа для фулфилмента Ozon полезно пройти короткий, но содержательный процесс.
- Сначала описать методы, а не выбирать максимальную роль.
Формулировка «нужен API для работы» не годится для настройки. Нужна конкретика: получать отправления, обновлять статусы, забирать сведения для печати этикеток, передавать данные по сборке. После этого проще сопоставить задачу с нужной областью доступа.
- Не выдавать Admin по умолчанию.
Полный административный ключ удобен на этапе теста, но опасен как постоянный production-доступ. Если интеграции достаточно ограниченного токена, избыточные разрешения создают ненужную поверхность риска.
- Разделять ключи по системам.
Один ключ — один сервис или один контур. Если WMS, сервис аналитики и внешний фулфилмент используют общий токен, нельзя быстро отключить одного участника, не сломав остальных. Отдельные ключи дают предсказуемое управление инцидентами.
- Не передавать ключи в незащищённых каналах.
Скриншот, файл в переписке или сообщение в групповом чате оставляют слишком много копий секрета. В нормальном процессе ключ передают через защищённый канал, а получатель подтверждает, что сохранил его в переменных окружения, vault или другом защищённом хранилище.
- Настроить мониторинг бизнес-симптомов, а не ждать технической ошибки.
Полезный дашборд контролирует не только ответ API, но и последствия: сколько новых заказов пришло в WMS, сколько заданий ушло на сборку, как давно обновлялся статус отгрузки, нет ли расхождения между остатками в учётной системе и кабинете.
- Планировать замену до дедлайна.
Для 180-дневного ключа разумно завести напоминание заранее. Уведомление за несколько недель оставляет время на согласование с подрядчиком, тестовый ключ и откат, если обновлённая интеграция ведёт себя нестабильно.
В этой части безопасность прямо влияет на логистическую SLA. Просроченный ключ — это не абстрактная проблема ИБ, а риск пропустить заказ, сорвать отгрузку и получить рост отмен. Поэтому владельцем процесса ротации должен быть не только разработчик фулфилмента, но и сотрудник селлера, отвечающий за операционный контур.
Что включить в договорённость с фулфилментом
Интерфейс маркетплейса не заменяет рабочие правила между селлером и оператором. Даже при корректно созданных пользователях и API-ключах стоит заранее договориться, как именно подрядчик обращается с доступом.
Минимальная техническая часть такой договорённости обычно включает:
- фулфилмент не запрашивает и не использует пароль владельца, SMS-коды, Ozon ID владельца и основной номер телефона;
- каждый доступ закреплён за конкретным сотрудником либо за документированным сервисным аккаунтом;
- API-ключ применяется только в обозначенной системе и для согласованной функции;
- оператор сообщает о смене ответственного сотрудника до передачи ему доступа;
- при инциденте — например, подозрении на компрометацию учётной записи или токена — стороны знают, кто и в какой последовательности отключает доступ;
- при прекращении сотрудничества оператор подтверждает удаление ключей и учётных данных со своей стороны, а селлер проводит отзыв в кабинете самостоятельно.
Последний пункт принципиален. Нельзя ограничиваться фразой «мы удалили вас из рабочего чата». Доступы живут в другом слое: в списке пользователей маркетплейса, в API-настройках, в WMS, интеграционных коннекторах, браузерных сессиях и иногда в локальных выгрузках.
Как завершить работу с фулфилментом без остаточного доступа
Самая частая ошибка — отключать подрядчика после того, как началась передача остатков, документов и заказов новому оператору. В этот момент команда занята физической логистикой, а цифровые доступы остаются на потом. Именно поэтому процедуру лучше включать в план расторжения с фиксированной датой.
Последовательность действий выглядит так:
1. Определить точку переключения операций.
До удаления доступа нужно убедиться, что все заказы, находящиеся у прежнего фулфилмента, обработаны или переданы в согласованный контур. Иначе отзыв прав может создать ручной разрыв в статусах FBS.
2. Удалить пользователей оператора из раздела управления пользователями.
На Wildberries и Ozon нельзя оставлять «временно неактивных» сотрудников бывшего подрядчика. Если сотрудник больше не участвует в процессе, его учётная запись должна быть удалена.
3. Отозвать все API-ключи, связанные с оператором.
Это относится не только к ключу основной WMS. Стоит проверить тестовые токены, ключи для печати, сервисы обмена остатками, коннекторы отчётности и временные интеграции, которые могли появиться в период запуска.
4. Проверить активные автоматизации.
Если внешний сервис продолжает забирать данные или отправлять статусы после завершения договора, значит, в архитектуре остался неучтённый ключ либо доступ. Здесь помогают логи интеграции и контроль последних успешных запросов.
5. Обновить реестр доступов.
В реестре нужно отметить дату отключения, причину и ответственного. Это кажется формальностью ровно до следующей смены фулфилмента, когда нужно быстро понять, какие права уже выдавались и почему.
6. Провести контрольный тест собственного контура.
После отзыва доступов селлер проверяет создание и обработку заказов, печать маркировки, передачу статусов, движение поставок и обновление остатков. Цель — не просто закрыть доступ, а убедиться, что отключение не задело действующую интеграцию.
Отдельно стоит проверить, не использовался ли один API-ключ в нескольких системах. Если им одновременно пользовались старый фулфилмент и внутренний дашборд селлера, его отзыв может остановить оба процесса. Это аргумент в пользу раздельных ключей с первого дня, а не в пользу того, чтобы сохранить старый токен «до лучших времён».
Вердикт: доступ — это настраиваемая часть логистики
Фулфилменту действительно нужен доступ к данным маркетплейса, иначе он не сможет стабильно собирать заказы, печатать этикетки и передавать статусы. Но доступ к заказам не равен доступу к кабинету владельца.
На Wildberries базовая модель — отдельный пользователь по ссылке-приглашению с вручную ограниченными правами. На Ozon для сотрудников логистики есть специализированные роли, а для программной интеграции — API-ключи с разной областью действия. После 13 февраля 2026 года новые ключи Ozon требуют ещё и плановой ротации раз в 180 дней.
Технически зрелый процесс здесь выглядит просто: отдельная учётная запись для человека, отдельный ключ для системы, минимальные разрешения для задачи, 2FA у владельца и понятный сценарий отзыва. Такая схема требует чуть больше настройки на старте, зато не заставляет менять главный пароль и пересобирать логистический контур при каждой смене подрядчика.