«Пароль от хостинга? Сейчас найду в переписке с Сергеем». Знакомая фраза — и в этот момент компания зависит от того, не удалил ли Сергей историю чатов и помнит ли он, каким паролем менял тот самый доступ два года назад.
Пароли — не про безопасность «вообще», а про управляемость. Пока они живут в переписке, вы не можете ни быстро отозвать доступ, ни понять, кто и чем пользовался, ни нормально ввести сотрудника в работу. Ниже — как выглядит типичная картина, чем именно она опасна и что сделать за десять дней.
Что обычно думают про пароли и доступы
| Ожидание | Реальность |
|---|---|
| «Пароли у директора в файле, значит, всё под контролем» | Файл синхронизирован в облако и открыт трём сотрудникам «на всякий случай» |
| «Мы работаем в одном ящике info@, так проще» | Не видно, кто из сотрудников что отправил, а смена пароля ломает работу всем сразу |
| «У нас не тот масштаб, чтобы нас взламывали» | Атакуют не «масштаб», а доступ: почту, хостинг, CRM — по одному и тому же паролю |
| «Когда сотрудник уходит, мы меняем пароль» | Меняют один, а у него остаются ещё девять: CRM, хостинг, соцсети, сервисы аналитики |
Ключевая проблема не в том, что пароли записаны, а в том, что они записаны так, что их невозможно отозвать по одному. Это и есть причина большинства инцидентов в малом бизнесе: не хакерская атака, а «доступ, о котором забыли».
Пять мест, где живут пароли в МСБ
- Переписка (мессенджер, почта). Пароль в истории чата остаётся навсегда, включая резервные копии чатов на устройствах. Уволившийся сотрудник уносит его с собой.
- Excel или Word на рабочем столе. Часто с названием «пароли.docx» и без пароля на сам файл. Иногда синхронизируется в облако «для надёжности».
- Стикер на мониторе и записка в ящике стола. Работает до первого гостя или уборки.
- Заметки в телефоне. Удобно и почти безопасно до момента, когда телефон потерян или экран разблокирован чужими руками.
- Голова администратора. Самое частое «хранилище» и самое уязвимое: человек уходит в отпуск или увольняется — и доступы исчезают вместе с ним.
Отдельная категория — общие аккаунты. Один пароль хостинга на трёх сотрудников, один ящик на отдел продаж, одна учётка CRM «для всех». Такая схема удобна ровно до первого инцидента: непонятно, кто что изменил, невозможно отозвать доступ у одного, а смена пароля останавливает работу всех.
Чем это заканчивается: три типовых сценария
Сценарий 1. Ушёл сотрудник. Менеджер вёл переписку с клиентами, имел доступ к ящику info@, к CRM и к хостингу (потому что «он же разбирается»). При увольнении меняют пароль от почты. Через месяц выясняется, что он заходит в CRM под своей старой учёткой и видит базу клиентов, а через неё — новые заявки.
Сценарий 2. Угнали почту. Пароль от директорского ящика лежал в переписке и участвовал в утечке другого сервиса. Почта — это универсальный ключ: через неё сбрасываются пароли почти везде. Дальше мошенник восстанавливает доступ к домену, к сайту, к CRM и к банковским уведомлениям.
Сценарий 3. Фишинговая ссылка. Сотрудник вводит пароль на странице, которая выглядит как вход в Битрикс24. Пароль попадает в руки злоумышленника, и с этого момента все действия в системе сделаны «его» руками — по журналу виноват ваш сотрудник.
Пароль в переписке — это не пароль, а служебная записка «доступ у всех, кто её видел».
Что делать: четыре уровня вместо поиска «правильного пароля»
Порядок важен: сначала исчезают общие учётки, потом появляется хранилище. Если сделать наоборот, менеджер паролей просто станет ещё одним местом для старых общих паролей.
Уровень 1. Раздельные аккаунты
У каждого сотрудника своя учётка в CRM, почте, на хостинге. Общие ящики (info@, sales@) остаются как адреса, но получают алиасы и правила пересылки — читать их можно из личных аккаунтов. Права выдаются по роли: менеджер не видит настройки, стажёр не видит выгрузку базы.
Уровень 2. Менеджер паролей
Одно рабочее хранилище на компанию: у сотрудника личный вход, а пароли к рабочим сервисам лежат в общих папках по ролям. Это даёт три эффекта: пароли не дублируются в переписке, доступ выдаётся и отзывается одним движением, а уволенный сотрудник теряет весь набор сразу.
Смысл не в конкретном продукте, а в модели: хранилище рабочее, а не личное; папки по ролям; у собственника и ответственного есть доступ ко всем папкам; при увольнении блокируется аккаунт в хранилище, а пароли меняются только там, где был именно этот сотрудник.
Уровень 3. Двухфакторная аутентификация
Сначала там, где сосредоточены деньги и данные: хостинг, домен, почта, CRM, банк, соцсети. Два фактора убивают почти весь смысл кражи пароля: его недостаточно, нужен ещё код.
Уровень 4. Регламент отзыва
Правило «в день увольнения»: аккаунт блокируется в CRM, в почте, в хранилище, в сервисах аналитики; выдаются новые пароли туда, где использовался общий. Хорошая практика — чек-лист на одной странице, который заполняет руководитель, а не «как получится». Подробный порядок — в статье Увольнение сотрудника: чек-лист по доступам и данным.
План на 10 дней
| День | Что делаем | Результат |
|---|---|---|
| 1 | Составляем список сервисов: хостинг, домен, почта, CRM, соцсети, аналитика, банк, 1С | Таблица на 15–30 строк |
| 2 | Отмечаем, где используются общие учётки | Понятно, что переделывать |
| 3–4 | Заводим хранилище и личные аккаунты сотрудникам | У каждого свой вход |
| 5–6 | Переносим пароли в общие папки по ролям, меняем слабые и повторяющиеся | Пароли уникальны |
| 7 | Включаем 2FA на почте, хостинге, домене, CRM | Кража пароля уже не даёт доступа |
| 8 | Настраиваем права по ролям в CRM и на хостинге | Меньше лишних доступов |
| 9 | Пишем регламент: выдача, отзыв, смена паролей | Одна страница с правилами |
| 10 | Чистим переписку от паролей и старых файлов, включаем журнал действий | Старые копии перестают быть дырой |
Десять дней — это календарь для компании до 30 человек, где решения принимаются быстро. Основное время уходит не на технику, а на инвентаризацию: вспомнить все сервисы, к которым есть доступы, обычно сложнее, чем всё перенастроить.
Диагностика за 30 минут: насколько всё плохо
| Где смотреть | Что искать | Норма |
|---|---|---|
| Корпоративная почта и мессенджер | Сообщения с паролями за последние 6 месяцев | Находится 0–2 старых, новых нет |
| Общие ящики | Сколько людей знают пароль от info@ | Пароль знают не более двух, вход возможен из личных аккаунтов |
| CRM | Сколько учёток с правами администратора | 1–2, остальные по роли |
| Хостинг | Одна учётка на всех или у каждого своя | У каждого своя, у подрядчика — отдельная |
| Двухфакторная аутентификация | Включена ли на почте, домене, хостинге | Включена везде, где есть деньги и данные |
| Журнал действий | Есть ли история: кто удалял, выгружал, менял права | Пишется и хранится не меньше месяца |
Если по трём пунктам из шести ответ «не знаю» — это и есть текущий уровень управляемости доступами. Хорошая новость в том, что порядок наводится за неделю и без покупки дорогих систем.
Во что обходится один угнанный доступ
- Почта. Через неё сбрасываются пароли остальных сервисов. Восстановление: смена паролей везде, проверка правил пересылки (мошенники ставят скрытую копию), письма клиентам о взломе.
- Хостинг. Сайт, почтовые ящики, SSL, иногда домен. Восстановление из копий — от часов до суток, плюс репутация.
- CRM. База клиентов и история сделок. Иногда её просто выгружают и уводят — деньги теряются не на восстановлении, а на ушедших клиентах.
- Соцсети. Угнанный доступ к сообществу — это рассылка от вашего имени и потеря аудитории; возврат занимает дни.
Стоимость наведения порядка: хранилище паролей для команды — от нескольких сотен рублей в месяц, 2FA бесплатно, день-два работы. Сравнение не в пользу «пока не случилось».
Когда проблема не в паролях
Иногда доступы разложены аккуратно, а данные всё равно утекают или теряются. Три типовые причины, которые к паролям отношения не имеют:
- Нет резервных копий. Права настроены, но после ошибочного удаления нечего восстанавливать — резервное копирование: три истории потерь.
- Сотрудников не учат фишингу. Правильные пароли не спасают, если их вводят на поддельной странице — фишинг в малом бизнесе.
- Доступы остаются у подрядчиков. Бывший разработчик с доступом к хостингу — та же история, что уволившийся сотрудник.
Навести порядок в доступах и поддерживать его мы берём в рамках администрирования и обслуживания Битрикс24 (от 15 000 ₽/мес: права, 2FA, журнал действий, отзыв доступов) и обслуживания сайтов (доступы к хостингу, домену, панели).
Что зафиксировать в договоре с подрядчиком
- Отдельные учётки: подрядчик работает под своими, а не под вашими — тогда при расторжении вы просто отключаете его доступ.
- Список доступов: приложение к договору с перечнем сервисов и уровнем прав.
- Передача при расторжении: пароли, ключи, 2FA-секреты и резервные копии переходят вам в течение N дней.
- Ответственность: что происходит, если доступ утёк по вине исполнителя.
- NDA: особенно если в доступах есть персональные данные клиентов.
Формулировки про сроки и ответственность разобраны отдельно: SLA в договоре: семь формулировок.
Частые вопросы
Можно ли обойтись браузерным менеджером паролей?
Для личного пользования — да, для компании — нет. Браузерное хранилище привязано к устройству и профилю: нет общих папок по ролям, нет централизованного отзыва доступа, нет истории. Как временный вариант годится, как рабочая схема — нет.
Что делать с общим ящиком info@?
Оставить адрес, но дать сотрудникам личные ящики и доступ к общему через пересылку или общий ящик с ролями. Пароль от info@ при этом знают два человека: руководитель и ответственный за почту.
Обязательно ли менять пароли каждый месяц?
Нет, при условии что пароли уникальны и есть 2FA. Частая смена без нужды приводит к тому, что люди начинают выбирать предсказуемые вариации и записывать их на стикерах. Меняйте при увольнении, утечке и подозрении на компрометацию.
Можно ли передавать пароли клиентам?
Лучше не передавать, а заводить отдельный доступ с ограниченными правами и сроком. Пароль, отправленный в мессенджере клиенту, живёт в его истории бесконечно.
Как быть, если сотрудник против 2FA?
Объяснить, что это защита от поддельных страниц входа, а не контроль. И включить 2FA не «по желанию», а как обязательное условие доступа к рабочим сервисам — иначе система остаётся дырявой у одного человека.
Нужен ли пароль на архив с резервными копиями?
Если архив уходит в облако — да, шифрование полезно: в базе персональные данные клиентов. Ключ храните отдельно от архива, иначе шифрование защищает только от вас.
Что сделать на этой неделе
- Найдите в почте и мессенджере пять последних сообщений с паролями и удалите их из рабочих чатов.
- Посчитайте, сколько людей знают пароль от основного ящика компании.
- Проверьте, у кого в CRM права администратора.
- Включите 2FA на почте, домене и хостинге — это 15 минут.
- Заведите рабочее хранилище паролей и перенесите туда доступы к трём главным сервисам.
