Сотрудник или подрядчик ушёл: как отозвать доступы ко всем сервисам интернет-магазина

Как организовать доступы к сервисам интернет-магазина: пароли, сотрудники, подрядчики и 2FA

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

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

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

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

Почему проблема начинается не с паролей

Даже у небольшого интернет-магазина быстро накапливаются CMS, CRM, рекламные кабинеты, аналитика, Ozon, Wildberries и Яндекс Маркет, платежные сервисы, домен, хостинг, корпоративная почта, службы доставки и другие системы.

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

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

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

Начните с реестра сервисов и аккаунтов

Для каждого рабочего аккаунта полезно зафиксировать:

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

Если в одном сервисе несколько кабинетов или организаций, учитывайте их отдельно. Например, вместо строки "Яндекс Директ" лучше перечислить конкретные рекламные кабинеты, а вместо "хостинг" — конкретную учетную запись.

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

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

Для таких аккаунтов дополнительно проверьте:

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

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

Практическая матрица доступов для интернет-магазина

Базовую модель можно построить так:

Смысл матрицы — перестать решать задачу в формате "дать сотруднику пароль".

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

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

Персональные аккаунты лучше общих

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

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

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

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

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

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

Когда без общего аккаунта не обойтись

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

Тогда действует важное правило:

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

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

Сам общий аккаунт стоит оформить как актив компании:

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

Микро-пример: разработчику на месяц дали общий административный пароль от старой CMS. Работы закончились, его удалили из рабочего чата, но пароль не поменяли. Формально подрядчика в команде уже нет, фактически его старый доступ продолжает работать.

Как организовать двухфакторную аутентификацию

Базовый принцип можно сформулировать так:

персональный аккаунт → персональный второй фактор;

общий аккаунт → совместный TOTP только там, где общего доступа нельзя избежать.

При этом нужно различать три ситуации.

1. Двухфакторная аутентификация менеджера паролей

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

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

Также важно предусмотреть независимый способ восстановления. Единственный способ пройти 2FA самого менеджера не должен быть доступен только после входа в этот же менеджер.

2. Двухфакторная аутентификация рабочих сервисов

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

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

3. Общий аккаунт с TOTP

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

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

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

Доступ нужно не только выдать, но и уметь отозвать

Качество системы доступов проще всего проверить увольнением сотрудника.

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

При подключении права лучше выдавать по роли:

• контент-менеджеру — CMS и необходимые разделы маркетплейсов;
• рекламному агентству — рекламные кабинеты и нужную аналитику;
• разработчику — технические ресурсы на срок работ;
• бухгалтеру — необходимые финансовые разделы.

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

При отключении человека нужно:

1. удалить его персональные учетные записи или роли в сторонних сервисах;
2. убрать его из командного менеджера паролей;
3. сменить общие пароли и TOTP-секреты, которые он мог видеть;
4. проверить выданные API-ключи и интеграционные токены;
5. убедиться, что почта, телефоны и резервные способы восстановления критичных аккаунтов остаются под контролем компании.

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

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

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

Зачем нужен командный менеджер паролей

Таблица хорошо подходит для реестра сервисов и доступов, но не для хранения самих паролей.

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

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

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

Одним из вариантов такого инструмента может быть Кейра.

Как эту модель можно реализовать в Кейра

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

Разделить общие учетные данные по задачам

Вместо одного общего списка учетные записи можно распределить по коллекциям — например, "Реклама", "Маркетплейсы", "CMS", "Инфраструктура" и "Финансы" — и открывать доступ только нужным сотрудникам.

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

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

Централизованно работать с общими аккаунтами и TOTP

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

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

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

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

Использовать хранилище как часть процесса подключения и отключения

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

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

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

Кейра не заменяет права внутри других сервисов

Это ключевое ограничение всей схемы.

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

Разделение ответственности выглядит так:

права внутри CMS, CRM, маркетплейса или другого сервиса → настраиваются средствами самого сервиса;

персональные рабочие пароли → централизованно хранятся в менеджере паролей;

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

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

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

1. Составьте реестр сервисов и аккаунтов. Зафиксируйте владельцев, пользователей, критичность, 2FA и восстановление — без самих паролей в таблице.
2. Разделите персональные и общие аккаунты. Где есть пользователи и роли, используйте их.
3. Определите минимальные доступы по ролям. Отдельно для владельца, маркетинга, поддержки, разработки, финансов и подрядчиков.
4. Проверьте критичные аккаунты. Компания должна контролировать почту, телефоны, второй фактор и способы восстановления.
5. Опишите процедуру отключения. Заранее определите, что происходит при увольнении или завершении договора.
6. Перенесите неизбежные общие учетные данные в командный менеджер паролей.
7. После этого выбирайте конкретный инструмент. Он должен соответствовать уже определенной модели доступа, а не определять ее вместо вас.

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

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