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

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

Когда новому сотруднику, агентству или фрилансеру нужен доступ к сервисам интернет-магазина, начинать стоит не с вопроса «как передать пароль?», а с вопроса «что именно этот человек должен иметь возможность делать?».

Рабочая схема выглядит так:

задача человека → необходимые сервисы → отдельный пользователь, если сервис это позволяет → минимально необходимые права → подходящий 2FA → срок доступа → общий доступ только там, где без него нельзя → заранее понятный способ отключения.

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

Главное правило: доступ, для которого заранее неизвестно, как его отключить, выдан неправильно.

Перед выдачей доступа ответьте на восемь вопросов

Неважно, подключаете вы штатного сотрудника на несколько лет или фрилансера на три дня. Логика одна.

1. Какую конкретную задачу будет выполнять человек?
2. Какие сервисы действительно нужны для этой задачи?
3. Можно ли создать в них отдельного пользователя?
4. Какие минимальные права этому пользователю необходимы?
5. Как будет устроена двухфакторная аутентификация?
6. Доступ нужен постоянно или только на срок проекта?
7. Есть ли общие аккаунты, API-ключи или другие доступы, без которых не обойтись?
8. Кто и каким способом отключит этот доступ после окончания работы?

Эти вопросы важнее должности.

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

Передать пароль и предоставить доступ — разные вещи

Во многих рабочих сервисах пароль владельца вообще не нужно кому-либо передавать.

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

Например, в Wildberries владелец кабинета может добавлять других пользователей и отдельно настраивать им доступ к разделам портала, включая финансовую информацию. В Ozon Seller предусмотрено управление сотрудниками и назначение ролей. В Яндекс Директе можно добавить представителя и выбрать для него уровень доступа; удалить такого представителя затем можно отдельно, не передавая пароль от основного аккаунта.

Поэтому правильный порядок такой:

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

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

Как это выглядит для разных участников интернет-магазина

Таблица ниже — не универсальная матрица прав, а примеры логики.

Рекламное агентство

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

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

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

Разработчик или интегратор

Для исправления модуля в CMS может потребоваться доступ к конкретному проекту. Для настройки интеграции — API. Для работы с сервером — отдельная техническая учетная запись.

Но формулировка «он разработчик» сама по себе не означает, что человеку нужны одновременно CMS, DNS, домен, серверы, платежные системы, корпоративная почта и учетная запись владельца маркетплейса.

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

Контент-менеджер

Сотруднику, который меняет карточки товаров и контент сайта, обычно нужен доступ к соответствующим разделам CMS и маркетплейсов.

Ему не следует автоматически выдавать финансовые разделы, управление другими пользователями или критичную инфраструктуру.

На Wildberries владелец кабинета, например, может отдельно ограничивать доступ пользователя к различным разделам портала. Это позволяет строить права от рабочей задачи, а не от принципа «раз уж сотрудник работает с маркетплейсом — откроем весь кабинет».

Минимальный доступ — это не только права, но и время

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

Но у него есть второе измерение — срок.

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

Поэтому при выдаче доступа полезно сразу фиксировать две границы:

что человек может делать;

до какого момента ему это нужно.

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

Персональный рабочий аккаунт предпочтительнее общего

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

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

Но «персональный» не должен означать «принадлежащий сотруднику».

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

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

Когда общий пароль все-таки необходим

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

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

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

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

Поэтому для общего аккаунта нужно заранее принять правило:

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

Удаление пользователя из менеджера паролей и смена самого пароля — это два разных действия.

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

Что делать с 2FA

Совет «включите двухфакторную аутентификацию» недостаточен. Для команды есть как минимум три разных сценария.

Персональная учетная запись

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

Тогда отключение одного человека не требует менять схему входа всей команды.

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

Общая учетная запись

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

Хранить TOTP-секрет рядом с логином в командном хранилище удобно: Кейра например, умеет генерировать TOTP непосредственно из сохраненного ключа аутентификации.

Но это компромисс.

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

Восстановление

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

Микро-пример: вся команда знает пароль от сервиса, но TOTP находится только в телефоне владельца. Формально 2FA включена, однако рабочий процесс теперь зависит от того, может ли один конкретный человек прямо сейчас прислать код.

Разработчику не всегда нужен основной аккаунт: проверьте API

Доступ — это не только логины и пароли.

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

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

Ozon Seller API также связывает доступные методы API-ключа с выбранной для него ролью.

Здесь работает тот же принцип:

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

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

Если подрядчиков несколько, не объединяйте их в одну условную роль

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

У них нет общей бизнес-задачи только потому, что все они являются внешними исполнителями.

Рекламному агентству могут требоваться рекламные кабинеты. SEO-подрядчику — аналитика и инструменты для сайта. Разработчику — технические системы. Интегратору — конкретные API доступы.

Поэтому схема «внешние подрядчики → доступ ко всему внешнему набору» быстро становится слишком широкой.

Лучше каждый раз двигаться от задачи:

конкретный подрядчик → конкретный проект → конкретные системы → конкретные права → конкретный срок.

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

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

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

При выдаче доступа должно быть понятно:

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

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

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

Где в этой схеме нужен командный менеджер паролей

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

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

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

Особенно он полезен в двух случаях:

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

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

Для этой части системы интернет-магазин может использовать Кейра

Как Кейра помогает управлять рабочими доступами

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

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

Не рассылать пароли по чатам

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

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

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

Сделать рабочие учётные данные ресурсом компании

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

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

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

Это особенно важно для аккаунтов, от которых зависит работа магазина: рекламы, CMS, интеграций и других операционных систем.

Упростить работу с неизбежными общими аккаунтами

Лучший вариант — отдельный пользователь в самом рабочем сервисе. Кейра не отменяет этого правила.

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

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

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

Быстрее подключать новых сотрудников и подрядчиков

Без централизованного хранилища подключение нового специалиста часто превращается в серию сообщений:

«пароль от этого кабинета спроси у маркетолога»;

«доступ к CMS когда-то отправляли разработчику»;

«код приходит владельцу»;

«актуальный пароль вроде бы в таблице».

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

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

Сохранять контроль при смене команды

Централизованное хранение особенно заметно упрощает смену сотрудников и подрядчиков.

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

Но здесь важно разделять два действия.

Закрыть человеку доступ к Кейра — значит прекратить его дальнейшую работу с корпоративным хранилищем.

Сделать ранее известный ему общий пароль недействительным — значит изменить этот пароль в самом рабочем сервисе.

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

Что в итоге получает интернет-магазин

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

Его задача — навести порядок там, где компании приходится работать непосредственно с доступами.

Вместо схемы:

пароли в чатах → копии у разных сотрудников → непонятно, где актуальная версия → проблемы при смене команды

появляется схема:

рабочие доступы компании → централизованное хранение → доступ только по рабочей необходимости → понятный процесс подключения и отключения людей.

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

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