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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принцип: храним клиентские данные хаотично

Процесс в агентстве выглядит так:

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

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

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

Принцип: принимаем пароли, храним и удаляем по процедуре

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

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

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

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

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

Принцип: клиент хранит пароли в менеджере паролей, у агентства есть доступ

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

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

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

Раскладываем учётки в Пароли.TeamDo 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

До начала проекта нужно выбрать модель обмена паролями и зафиксировать её в договоре.  Рассмотрим порядок работы с клиентскими паролями на трёх стадиях.

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

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

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

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

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

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

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

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

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

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

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

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

1. Отключить или удалить учетную запись сотрудника в Пароли.TeamDo.
2. При отключении сбросить все его устройства.  
3. Сменить все критичные пароли, если сотрудник знал их или имел расширенные права.  
4. Удалить сотрудника из внешних сервисов, куда он был добавлен напрямую. 

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

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

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

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

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

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

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

Договор помогает разделить зоны ответственности за важные данные.

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

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