Общие пароли в Excel: риск для команды и переход на профили

Редакция GetAntik · 26 октября 2026 г. · 11 минут чтения

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

Почти в каждой агентстве или отделе, который ведёт клиентские аккаунты, есть этот файл. Он называется «Доступы», «Пароли клиентов» или просто «Base». Живёт в Google-таблице, Notion или общей папке на диске. Туда годами копируются логины, пароли, иногда коды 2FA текстом, иногда ссылки на почту для восстановления. Доступ к файлу есть у половины команды, потому что «так удобнее, не дёргать каждый раз админа».

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

Почему таблица с паролями — это не экономия, а отложенный риск

Проблема не в том, что таблица — это «несерьёзно». Проблема в том, что она решает одну задачу (быстро передать доступ) и создаёт пять новых, которые проявляются не сразу.

Нет границы ответственности. Любой человек с доступом к файлу видит все пароли сразу — не только те, что нужны ему для работы. Если в команде 15 специалистов и 60 клиентских аккаунтов, каждый технически может зайти в любой из них. Когда что-то идёт не так — пропал бюджет, аккаунт заблокирован, странная активность в кабинете — узнать, кто именно заходил и когда, невозможно. Таблица не ведёт журнал входов.

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

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

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

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

Сценарий, который рано или поздно случается

Типичная история: SMM-агентство ведёт 40 аккаунтов в Instagram и Facebook для 12 клиентов. Пароли и коды восстановления — в общей таблице, доступ у всей команды из 8 человек. Один специалист увольняется в пятницу. В понедельник выясняется, что он забрал с собой экспорт cookies трёх аккаунтов (просто потому что входил в них с рабочего ноутбука через расширение-менеджер паролей) и теоретически может зайти в них снова, пока клиент не сменит пароль сам. Паники нет, но есть разговор с клиентом, который звучит неловко: «мы не уверены, кто ещё имеет доступ к вашему аккаунту».

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

Что меняется при переходе на профили

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

Для команды это выглядит как набор ролей и ограничений, а не общий список логинов:

• Владелец и админ видят весь пул профилей, управляют ролями и лимитами.
• Участник получает доступ только к тем профилям, которые ему назначили — остальные он физически не видит в своём списке.
• Finance-роль может отвечать за биллинг и прокси, не имея доступа к самим аккаунтам.
• Для каждого участника можно задать лимит на число профилей, которые он вправе открывать.

Это снимает первую проблему таблицы: нет ситуации «каждый видит всё». Специалист по клиенту А физически не может открыть кабинет клиента Б, даже случайно.

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

Третья часть — журнал действий. Вместо вопроса «кто вообще заходил в этот аккаунт на прошлой неделе» у вас есть лог: кто открывал профиль, когда, с какого устройства. Это не инструмент слежки в духе кликера активности, а обычная управленческая гигиена — то же самое, что история версий в документе. Если у вас уже есть интерес к этой теме, стоит отдельно посмотреть на подход к аудиту как к инструменту, а не слежке — там разобрано, как выстроить логирование так, чтобы оно помогало команде, а не пугало её.

Четвёртая часть — шифрование. Данные профиля шифруются на устройстве паролем аккаунта, и сервер физически не может их прочитать. Это закрывает страх «а что если облако сломают или кто-то получит доступ к базе провайдера» — расшифровать профиль без пароля владельца невозможно даже на стороне сервиса.

Как выглядит сама миграция

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

1. Инвентаризация. Выгрузите список всех аккаунтов из таблицы: клиент, платформа, кто ответственный, включена ли 2FA, есть ли привязанная почта для восстановления. На этом этапе обычно обнаруживается 10–15% «мёртвых» записей — аккаунты клиентов, с которыми давно не работаете, или дубли.

2. Приоритизация по риску. Сначала переносите аккаунты с действующей 2FA и высокой ценностью (рекламные кабинеты с активным бюджетом, аккаунты с большой аудиторией) — именно там цена ошибки выше всего. Аккаунты с низкой активностью можно перенести позже, без спешки.

3. Создание профилей и привязка fingerprint. Для каждого аккаунта создаётся отдельный профиль с собственным набором параметров — ОС, версия браузера, экран, часовой пояс и язык, согласованные с прокси, который будет привязан к профилю. Если аккаунтов много и они однотипны (например, десятки Facebook-кабинетов), процесс ускоряют шаблоны профилей — но об этом подробно уже написано отдельно, здесь не будем повторяться.

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

5. Назначение прав. Распределите профили между сотрудниками по ролям: кто видит, кто может редактировать настройки, кто только работает внутри. На этом же шаге стоит сразу решить, кому можно передавать профиль временно, а кому — нет.

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

Таблица: что меняется на практике

Типичные ошибки при переходе

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

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

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

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

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

Когда миграция оправдана, а когда можно подождать

Если в команде 2–3 человека и 5 аккаунтов одного клиента — проблема с таблицей скорее гипотетическая, и городить ролевую структуру ради неё избыточно. Переход однозначно оправдан, когда:

• количество аккаунтов превышает число, которое один человек помнит наизусть (обычно это граница в 15–20 записей);
• доступ есть больше чем у 3–4 людей;
• хотя бы часть аккаунтов защищена двухфакторной аутентификацией;
• текучка в команде регулярная — фрилансеры, стажёры, подрядчики со стороны.

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

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

FAQ

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

Что делать, если пароль клиента вообще не нужен — только доступ к уже залогиненному кабинету? Это обычная ситуация для агентств: клиент один раз даёт войти под своим логином, дальше работа идёт в рамках сессии. В этом случае достаточно перенести сессию в профиль через cookies и дальше не трогать пароль вообще — он может оставаться только у клиента.

Как быть с сервисами, которые жёстко привязывают сессию к одному устройству и просят повторный логин при смене отпечатка? Именно поэтому важно создавать профиль один раз и дальше не менять его параметры — ОС, экран, часовой пояс должны оставаться стабильными между сессиями, а не пересобираться заново. При правильно настроенном профиле повторной верификации обычно не требуется чаще, чем при обычной смене IP у рядового пользователя.

Что произойдёт с доступом, если я забуду пароль от своего аккаунта GetAntik? Поскольку данные профилей шифруются локально паролем аккаунта, а сервер эту информацию расшифровать не может, восстановление пароля без доступа к зашифрованным данным невозможно — это та же логика, что у любого end-to-end зашифрованного хранилища. Поэтому пароль аккаунта стоит хранить так же бережно, как раньше хранили ключ от общей таблицы, только теперь это один пароль вместо полусотни.

Можно ли совмещать переходный период — часть аккаунтов в таблице, часть в профилях? Да, и это нормальная практика на 2–4 недели миграции. Важно только явно отметить в таблице, какие записи уже неактуальны и перенесены, чтобы два источника правды не расходились между собой.

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