Инструкция: как агентству хранить свои пароли и доступы клиентов

У агентства на десять клиентов набирается больше сотни разных доступов.

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

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

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

Свои доступы агентства 

Давайте ещё раз посмотрим, какие доступы хранит агентство:

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

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

 У каждого сотрудника агентства будет какое-то количество доступов:

Ключ шифрования: создаётся один раз

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

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

Ключ у нас не хранится. Это то же свойство, из-за которого ваши пароли недоступны нам — и из-за которого мы не восстановим ключ, если вы потеряете файл. Зашифрованные данные останутся недоступны навсегда.

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

Как хранить файл .pem? Мы рекомендуем владельцу сохранить файл на своём устройстве или в хранилище на сервере. 

Двух администраторов назначают сразу

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

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

Роли и права: это важно

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

Персональные учётные данные для сотрудников агентства

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

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

Фрилансеры и подрядчики

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

1. Он приходит на один проект — значит, доступ должен получить к группе по проекту, а не к внутренним группам агентства.
2. Он работает со своего устройства удалённо. Значит, при завершении работ обязателен сброс устройств, а не только отключение.
3. Он может параллельно работать на другое агентство и выполнять работы для своих клиентов. Это значит, что доступ выдаётся точечно и на срок. 

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

Клиентские доступы: сначала модель, потом настройка 

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

Модель 1. Не брать пароль, если можно взять доступ 

Начинайте с этой проверки по каждой системе. Яндекс.Директ, Яндекс.Метрика, VK.Реклама, сервисы Google, большинство CMS и панелей хостинга умеют выдавать подрядчику права на его собственный логин.

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

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

Модель 2. Так делают почти все, и это не решение

Схема выглядит так:

• клиент прислал пароль в мессенджере, аккаунт-менеджер сохранил его себе, потом переслал разработчику;
• или клиент «расшарил» файл со списком паролей на аккаунты агентства (или аккаунт сотрудника).

При сотрудничестве про обмен данными в договорах нет никакой конкретики. Обычно, клиент не знает, где лежат его данные, и через два года после окончания работ пишет в агентство: «пришлите наш доступ к биллингу». У нас был такой опыт: в агентстве скопилось около 3 000 паролей 350 компаний, и запросы «найдите нам…», «у вас же был…» были регулярными. 

При инциденте у клиента проверят и агентство. Иск за разглашение конфиденциальной информации и штраф по 152-ФЗ приходят к тому, у кого данные фактически находились, а не к тому, кто их формально не запрашивал.

Модель 3. Хранить по договору, принимать по процедуре 

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

Условия перехода в эту модель ровно три:

1. Хранение и способ передачи прописаны в договоре или NDA. Кстати, если будете использовать наш менеджер паролей попросите у нас документ  — пришлём.
2. Клиент подключён к своей папке и видит те же данные, что и вы.
3. Зафиксирован срок хранения после окончания работ и обязанность подтвердить удаление.

Третий пункт превращает бессрочный риск в срочный. Именно он отличает модель 3 от модели 2, а не факт использования менеджера паролей.

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

Модель 4. Клиенту использует собственный менеджер паролей, агентству выдаёт временный доступ

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

Что получает агентство: клиентских паролей у вас нет, и после проекта отзывать нечего  — клиент закрывает доступ сам.

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

Этот вариант подходит не всем. Если клиент передаст вам 10–20 паролей, то выгоднее использовать модель 1 или 3. Если же у клиента есть своя команда, несколько подрядчиков или требования по безопасности, то модель 4 практичнее.

Структура: группа на каждого клиента

Базовое правило — отдельная группа под каждого клиента. Не одна общая папка «Клиенты», не «Реклама» и «Разработка», а именно проект клиента.

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

Что видит представитель клиента

Клиента подключают к команде на время проекта. Клиент должен видеть:

• данные своей организации;
• доступы, которые ему предоставило агентство (например, ссылки на документы).

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

Что агентство не берёт на хранение ни в одной модели

Не принимайте ЭЦП, доступы к государственным сервисам, банковские токены и приложения, коды подтверждения на личный телефон руководителя.

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

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

Настройка TeamDo: четыре действия

1. Зарегистрируйте команду в Пароли.TeamDo и создайте ключ шифрования. Тестовый период — 14 дней, IT-специалист не нужен, запуск занимает около получаса.
2. Заведите группы: по проекту на клиента плюс внутренние. 
3. Пригласите сотрудников, фрилансеров и представителей клиентов по персональным e-mail, раздайте права через группы, включите 2FA на команду.
4. Внесите данные: скачайте шаблон, заполните и импортируйте или добавьте вручную. 

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

Жизненный цикл клиентского доступа

Как подключить клиента к проекту?

До начала проекта

1. Выберите модель и зафиксируйте её в договоре.
2. Создайте отдельную группу под проект клиента. 
3. Перенесите в неё доступы, если вам уже что-то передали.
4. Пригласите представителей клиента по персональным e-mail.
5. Назначьте им права для самостоятельного добавления — так пароли перестанут приходить в переписке.
6. Проверьте, что клиент не видит данные других организаций.

Во время проекта

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

Если клиент всё-таки передал пароль в мессенджере или письмом:

1. Внесите его в Пароли.TeamDo.
2. Удалите сообщение или файл, если это допускается правилами вашего агентства. 
3. Попросите клиента сменить пароль и к самой системе и в менеджер паролей.
4. Держите актуальный пароль только в Пароли.TeamDo. 

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

После завершения проекта

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

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

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

Сотрудник уволился из агентства

В TeamDo пользователя можно отключить c сохранением профиля, либо удалить из команды полностью. Администратор в день прекращения работы сотрудника должен:

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

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

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

Если уволился администратор

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

Если клиент против хранения доступов у подрядчика 

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

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

Что закрепить в договоре

Три формулировки, которых достаточно в большинстве случаев:

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

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

Читайте также 

• Сколько бизнес тратит на корпоративные SaaS-подписки