Доступ сотрудников к маркетплейсам: как разделить права безопасно

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

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

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

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

У общего пароля есть ещё четыре недостатка:

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

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

Какие задачи и данные нужно распределить до настройки ролей

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

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

• Продажи и ассортимент. Создание карточек, редактирование описаний, изменение цены, участие в продвижении и контроль публикации.
• Заказы. Просмотр статусов, поиск заказа, проверка выдачи и разбор исключений.
• Поддержка. Ответы покупателям, обработка отзывов и сбор данных по спорной ситуации.
• Цифровой склад. Загрузка ключей или файлов, просмотр остатков, остановка товара при нехватке кодов.
• Финансы. Просмотр начислений, актов, комиссий, реквизитов и выплат.
• Администрирование. Добавление пользователей, выдача ролей, создание интеграций и изменение настроек безопасности.

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

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

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

Доступ сотрудников к маркетплейсам: принцип минимальных прав

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

Проверять разрешение удобно тремя вопросами:

1. Какую конкретную рабочую задачу человек выполняет с этим правом?
2. Можно ли решить задачу без просмотра чувствительных данных или изменения настроек?
3. Что произойдёт, если сотрудник ошибётся либо его учётную запись взломают?

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

Как определить права менеджеров маркетплейса

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

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

Что разрешить поддержке

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

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

Какие права оставить администратору

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

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

Матрица ролей для небольшой команды цифровых товаров

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

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

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

Если площадки не дают достаточно гибких ролей, часть процессов можно вынести из их кабинетов. В КОВАЛС.iO есть команда с отдельными правами для сотрудников, единая страница заказов и защищённое хранение ключей и файлов. Это позволяет настроить командный доступ и автовыдачу, не передавая каждому сотруднику полный доступ к магазинам на Яндекс Маркете, Wildberries, Ozon и Etsy.

Как создать учётные записи и включить двухфакторную защиту

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

1. Создайте персональный рабочий адрес. Используйте корпоративную почту или управляемый адрес, который можно отключить при увольнении. Личный почтовый ящик сотрудника усложняет восстановление контроля.
2. Добавьте пользователя штатным способом. Используйте раздел команды, сотрудников или ролей в кабинете площадки. Не создавайте копии основного аккаунта и не отправляйте пароль в мессенджере.
3. Назначьте минимальную роль. Сверьте каждый переключатель с матрицей. Если значение разрешения непонятно, сначала изучите актуальную справку площадки.
4. Включите двухфакторную аутентификацию. Предпочтительны доступные на площадке приложения-аутентификаторы, аппаратные ключи или другие защищённые способы. СМС можно использовать, если иных вариантов нет и площадка поддерживает только такой сценарий.
5. Сохраните резервные коды. Они должны находиться в контролируемом защищённом хранилище, а не в той же почте или переписке, где лежат логин и инструкция.
6. Проверьте доступ на практике. Попросите сотрудника выполнить типовые действия и убедитесь, что финансовые данные, реквизиты, пользователи и секреты ему недоступны.

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

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

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

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

Как организовать выдачу доступа, временные права и отзыв

Безопасность аккаунта селлера зависит не только от настроек, но и от процесса. Даже правильно созданная роль становится риском, если её не отключили после увольнения или временного проекта.

Заявка на новый доступ

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

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

Временное повышение прав

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

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

Отзыв доступа

При увольнении, смене подрядчика или переводе сотрудника действуйте по чек-листу в день изменения статуса. Простого удаления из рабочего чата недостаточно.

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

Если заявки покупателей обрабатываются вручную на разных площадках, сотрудники вынуждены чаще входить в кабинеты и получают больше разрешений. КОВАЛС.iO автоматически забирает оплаченные заказы по API, выдаёт ключ, код, файл или текст и собирает заказы на одной странице. Такой процесс помогает сократить число повседневных входов с расширенными правами и перенести выдачу в единый кабинет.

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

Что записывать в журнал проверок доступа

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

В журнал стоит включить следующие поля:

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

Сам журнал не должен содержать пароли, резервные коды и токены API. Его задача состоит в учёте прав, а секреты хранятся отдельно в предназначенной для этого системе.

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

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

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

Практический чек-лист безопасной работы команды

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

1. Составлены перечень операций и список чувствительных данных.
2. Для владельца, администратора, менеджера и поддержки определены отдельные роли.
3. Каждый сотрудник использует персональную учётную запись и рабочую почту.
4. Права соответствуют реальным задачам, а не должности «вообще».
5. У всех доступных аккаунтов включена двухфакторная защита.
6. Резервные коды и пароли хранятся отдельно от рабочих переписок.
7. Для каждой интеграции создан отдельный подписанный API-ключ.
8. Поддержка не видит финансовые реквизиты и полный запас цифровых товаров.
9. Менеджер не может добавлять администраторов без рабочей необходимости.
10. Временные права имеют основание, ответственного и дату отзыва.
11. Есть чек-лист отключения сотрудника в день увольнения или смены роли.
12. Ведётся журнал доступов и выполняется регулярная ревизия.

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

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