Раз в квартал ко мне приходит клиент с одинаковой историей: разработчик, который делал сайт, пропал, а доступы к хостингу и админке остались только у него - сайт лежит с истёкшим SSL и без возможности что-то поправить. Как хранить доступы к сайту - вопрос, который стоит закрыть на берегу, а не в момент, когда что-то уже сломалось. Ниже - рабочий чек-лист, который я применяю в проектах на WordPress, Tilda и в сервисах на n8n: от инвентаризации доступов до регламента их отзыва.
Какие доступы к сайту нужно инвентаризировать
Первый шаг - не менеджер паролей, а таблица (потом перенесённая в нормальный инструмент) со списком того, что вообще есть у проекта. На практике набор почти всегда такой:
- панель хостинга (ISPmanager, cPanel, VDS-провайдер) и доступ по SSH
- регистратор домена и управление DNS-записями
- админка CMS - WordPress, Tilda, Bitrix
- база данных и FTP/SFTP
- платёжные интеграции - например, ключи T‑Bank для эквайринга в WooCommerce
- API служб доставки - СДЭК, Boxberry, Почта России
- токены ботов - скажем, bot token aiogram-бота, подключённого к сайту
- аналитика - Яндекс.Метрика, GA4, Search Console
- репозиторий кода (GitHub/GitLab) и деплой-ключи
- учётки в n8n или Zapier с credentials для автоматизаций между сайтом, CRM и мессенджерами
За восемь лет работы с сайтами на Tilda и WordPress я ни разу не видел взлома через подбор пароля, а вот доступ, потерянный из-за уволившегося сотрудника или пропавшего фрилансера, - регулярная история. Инвентаризация занимает час-два, но именно она показывает, сколько живых точек входа реально есть у сайта.
Почему таблица в чате и общий пароль - плохая идея
Классика: пароль от админки лежит в закреплённом сообщении Telegram-группы, а доступ к хостингу передают голосом на созвоне. Проблемы у такой схемы конкретные:
- нет аудита - непонятно, кто и когда заходил под общей учёткой
- нельзя отозвать доступ у одного человека, не сменив пароль для всех
- чат читают люди, которые давно не работают над проектом, а поиск по истории находит пароль за секунду
- без принудительного 2FA один слитый пароль - это полный доступ к сайту, платёжным ключам и базе клиентов
Особенно критично это для интеграций с оплатой и доставкой: если ключи T‑Bank или API СДЭК утекут вместе с общим паролем от Google-документа, отследить источник утечки почти невозможно.
Менеджеры паролей для команды: сравнение
Для хранения доступов внутри команды нужен именно менеджер паролей с ролями и логами, а не заметки. Вот что я обычно предлагаю клиентам в зависимости от размера команды и требований к локализации данных.
| Сервис | Формат | Шаринг для команды | 2FA / аудит | Когда подходит |
|---|---|---|---|---|
| Bitwarden (облако) | SaaS | Есть, по группам | Есть, платно - лог событий | Команда до 10-15 человек, без жёстких требований к серверу в РФ |
| Vaultwarden | Self-hosted (Docker) | Есть, полный контроль | Есть | Когда нужен сервер в РФ и контроль над данными |
| 1Password Business | SaaS | Есть, гибкие политики | Есть, продвинутый аудит | Крупная команда, бюджет на подписку |
| KeePass | Локальный файл | Практически нет | Нет | Один человек или архив старых паролей, не для команды |
Для большинства своих клиентов на WordPress и Tilda я рекомендую Vaultwarden на своём же VDS - это тот же интерфейс Bitwarden, но база с паролями физически лежит на сервере в России, а не в чужом облаке.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Разграничение доступов по ролям
Одна учётка с правами администратора на всех - источник половины проблем. В WordPress есть встроенные роли (администратор, редактор, автор), в Tilda - уровни доступа для команды проекта, и их стоит использовать по назначению, а не выдавать всем максимум.
| Роль | Что нужно | Что не нужно |
|---|---|---|
| Контент-менеджер | Редактор в CMS, доступ к медиабиблиотеке | SSH, база данных, платёжные ключи |
| Маркетолог/таргетолog | Аналитика, пиксели, доступ к формам | Админка хостинга, репозиторий кода |
| Штатный разработчик | SSH, база, репозиторий, staging | Личный кабинет хостинг-провайдера с оплатой |
| Подрядчик на проект | Временный доступ под задачу, ограниченный сроком | Постоянный доступ после сдачи работ |
Отдельно слежу за тем, чтобы у платёжных интеграций и API служб доставки был свой набор ключей на проект, а не общий аккаунт компании - тогда компрометацию одного сайта не нужно чинить перекрёстно во всех остальных.
Как передавать доступы подрядчику и закрывать их после проекта
Когда беру проект на доработку - кастомный скрипт для Tilda, интеграцию с СДЭК или бота на aiogram - прошу заводить отдельную временную учётку, а не делиться личным паролем клиента. После сдачи работ доступ у меня забирают, и это нормальная практика, а не недоверие.
Чек-лист передачи доступов подрядчику:
- создать отдельного пользователя в CMS и на хостинге, не делиться главным логином
- выдавать deploy-ключ в Git с ограниченными правами, а не полный доступ к репозиторию
- ставить срок действия доступа в календаре - не полагаться на память
- после сдачи проекта менять пароли от хостинга и API-ключи, к которым был доступ у подрядчика, а не только удалять его учётку
- отзывать SSH-ключи и деплой-токены отдельно - удаление аккаунта не всегда убирает выпущенные ранее ключи
Если в компании больше пяти-семи активных доступов и часто меняются подрядчики, есть смысл один раз составить письменный регламент доступов - кто, что и на какой срок получает, и как это закрывается.
Секреты в коде и автоматизациях - не хардкодить
Отдельная зона риска - не пароли людей, а секреты внутри кода: токен телеграм-бота, ключ платёжного API, доступ к базе. Их нельзя коммитить в репозиторий открытым текстом. Стандартная схема - переменные окружения в .env-файле, который добавлен в .gitignore:
BOT_TOKEN=123456:AAxxx-yyyyyyyyyyyyyyy
TBANK_API_KEY=sk_live_xxxxxxxx
SDEK_ACCOUNT=xxxx
SDEK_SECURE_PASSWORD=xxxx
DB_PASSWORD=xxxxВ GitHub такие значения хранятся в Secrets для Actions, а не в коде пайплайна. В n8n для этого есть встроенное шифрованное хранилище credentials - не нужно вставлять токен бота или ключ СДЭК прямо в HTTP-ноду, credential создаётся один раз и переиспользуется в сценариях. Это же правило касается ботов на aiogram: токен читается из переменной окружения на сервере, а не хранится в файле, который может попасть в публичный репозиторий.
Регламент хранения доступов: что зафиксировать письменно
Доступы держатся в порядке, только если есть простой документ, а не устная договорённость. Минимальный набор пунктов, которые я фиксирую для клиентов:
- реестр доступов - кто, к какой системе, с какого числа и с какой ролью
- ответственный за выдачу и отзыв доступов - обычно это не разработчик, а владелец бизнеса или технический директор
- обязательный 2FA для админки CMS, хостинга и менеджера паролей
- ротация паролей для критичных систем - на практике делаю раз в 90 дней для хостинга и платёжных интеграций
- порядок действий в день увольнения сотрудника: смена паролей от общих систем, отзыв SSH-ключей, удаление из группы в менеджере паролей
- журнал доступа - кто заходил на сервер и когда, хотя бы через встроенные логи хостинга
Этот регламент не требует отдельного софта - достаточно закреплённого документа и менеджера паролей с логами, который уже описан выше.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Как передать доступы подрядчику без риска для сайта?
Заводите отдельную временную учётку с ограниченной ролью вместо того, чтобы делиться личным паролем администратора. После сдачи проекта меняйте пароли и ключи API, к которым был доступ у подрядчика, а не только удаляйте его аккаунт.
Сколько человек должно иметь права администратора на сайте?
На практике держу число полных администраторов минимальным - обычно один-два человека со стороны владельца бизнеса плюс разработчик на период активных работ. Остальным ролям хватает прав редактора или доступа к конкретным разделам.
Что делать с доступами после увольнения сотрудника?
В тот же день меняются пароли от общих систем (хостинг, CMS, менеджер паролей), отзываются SSH-ключи и деплой-токены, сотрудник удаляется из групп доступа. Если у него были отдельные API-ключи платёжных систем или служб доставки - их тоже нужно перевыпустить.
Нужно ли менять пароли, если утечки не было?
Да, для критичных систем - хостинга, платёжных интеграций, базы данных - плановая ротация раз в 60-90 дней снижает риск от паролей, которые могли осесть в старых чатах, письмах или на компьютере уволившегося сотрудника, даже если явного инцидента не произошло.