Как навести порядок в доступах к сайту и хостингу за день

19% компаний держат пароли администраторов в Excel и Word, и файл «Доступы.xlsx» переживает всех, кто его открывал. План на день по часам: реестр из 11 точек входа без единого пароля, SSH-ключи вместо root, отдельный пользователь базы, порядок включения 2FA и чистка старых доступов.

Файл называется «Доступы.xlsx» и лежит на общем диске. В нем 30 строк: хостинг, регистратор домена, админка сайта, FTP, почта, Метрика. Половину паролей вписал программист, который уволился 2 года назад, вторую половину — подрядчик, с которым давно не работают. Файл открывали с 6 компьютеров, копия есть в чьей-то почте. Кто из этих людей может сегодня зайти на сервер, в компании не знает никто.

Картина типичная. По опросу более 50 российских компаний со штатом 50–500 человек, проведенному при поддержке ассоциации «Руссофт», пароли привилегированных учетных записей в файлах Excel и Word хранят 19% организаций, а с инцидентами из-за паролей сталкивались 20% (CNews, 5 октября 2026 года). При этом формальная парольная политика есть у 66,7% опрошенных. Документ написан, а пароли от сервера лежат в таблице.

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

Почему файл с паролями хуже, чем кажется

Сам по себе Excel не дырявый. Проблема в том, что файл с паролями ведет себя как обычный документ, а требования к нему как к сейфу.

• Копии. Файл скачивают, пересылают в мессенджере, прикладывают к письму. Через год его копий больше, чем людей в отделе, и удалить их все невозможно.
• Нет журнала. Неизвестно, кто и когда открывал файл. После инцидента это первый вопрос, и ответа на него не будет.
• Все или ничего. Менеджеру нужен пароль от Метрики, а получает он весь файл вместе с root-доступом к серверу.
• Пароль на файл не спасает. Его знают все, кому файл нужен, и он не меняется годами.
• Увольнение ничего не меняет. Человек ушел, копия осталась у него. Чтобы закрыть доступ, нужно сменить все пароли из файла, и этого обычно не делают.

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

Шаг 1. Реестр доступов: что есть у сайта

Первые 2 ч. уходят на инвентаризацию. Задача: выписать все места, куда можно войти и что-то изменить в сайте или вокруг него. У типового сайта компании таких мест 8–12, и про 2–3 из них обычно забывают.

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

system;url;owner_account;who_has_access;role;2fa;last_review
Регистратор домена;registrar.example;company@example.ru;директор;владелец;да;2026-10-05
Хостинг;panel.example;company@example.ru;техдир, подрядчик;админ, техдоступ;да;2026-10-05
SSH сервера;203.0.113.10;-;ivanov, petrov (ключи);sudo, deploy;ключи;2026-10-05
Админка сайта;example.ru/admin/;-;5 личных учеток;админ 2, контент 3;да;2026-10-05
Метрика;metrika.yandex.ru;company@example.ru;маркетолог, подрядчик;просмотр;да;2026-10-05

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

Шаг 2. Личные учетные записи вместо общих

Правило простое: один человек — одна учетная запись, и права у нее ровно под его задачи. На это уходит еще 2 ч., и это самая полезная часть дня.

Админка сайта

Откройте список пользователей с правами администратора. Обычно там находятся admin, test, учетная запись студии, которая делала сайт 4 года назад, и пара бывших сотрудников. Каждому действующему сотруднику заведите личную учетную запись, контент-менеджеру дайте права на контент, а не полный доступ. Общие и чужие записи деактивируйте. Удалять их сразу не нужно: на них могут быть завязаны авторство материалов и история изменений.

В «1С-Битрикс: Управление сайтом» права раздаются через группы пользователей, и проверить нужно в первую очередь состав группы «Администраторы». Чем она короче, тем лучше: 2 человека, один из которых технический специалист, достаточно почти всегда.

Сервер: ключи вместо пароля

На сервере общий пароль root — худший вариант из возможных. Каждому, кому нужен доступ, создается отдельный пользователь, вход идет по SSH-ключу, вход по паролю отключается.

# на компьютере сотрудника: создать ключ
ssh-keygen -t ed25519 -C "ivanov@example.ru"

# на сервере: отдельный пользователь и его публичный ключ
adduser ivanov
mkdir -p /home/ivanov/.ssh
nano /home/ivanov/.ssh/authorized_keys   # вставить содержимое id_ed25519.pub
chown -R ivanov:ivanov /home/ivanov/.ssh
chmod 700 /home/ivanov/.ssh && chmod 600 /home/ivanov/.ssh/authorized_keys

Когда все зашли по ключам и проверили, что вход работает, пароли отключаются в настройках SSH:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

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

Теперь увольнение или смена подрядчика сводится к одной операции: удалить строку из authorized_keys или заблокировать пользователя. Менять пароли всем остальным не нужно. FTP, если он еще используется, лучше закрыть совсем и перейти на SFTP: FTP передает пароль открытым текстом.

База данных

У сайта должен быть свой пользователь БД с правами только на свою базу. Если сайт ходит в MySQL под root, любая уязвимость в коде открывает все базы на сервере.

-- кто вообще есть и откуда может подключаться
SELECT user, host FROM mysql.user;

-- отдельный пользователь для сайта, только локально и только к своей базе
CREATE USER 'site_user'@'localhost' IDENTIFIED BY 'длинный_случайный_пароль';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP
  ON site_db.* TO 'site_user'@'localhost';

Строка с host = '%' в первом запросе означает, что этот пользователь может подключаться с любого адреса. Для сайта, у которого база лежит на том же сервере, таких строк быть не должно.

Сервисы Яндекса и реклама

Счетчик Метрики и рекламный кабинет должны принадлежать аккаунту компании. Сотрудникам и подрядчикам выдается гостевой доступ на их собственные логины: в Метрике это делается в разделе «Настройки» → «Доступ», уровень выбирается под задачу («Только просмотр» или «Редактирование»). С представителями аккуратнее: по справке Метрики представитель получает полные права на все счетчики аккаунта, включая удаление. Передавать логин и пароль от аккаунта компании подрядчику не нужно вообще, для этого и существуют гостевые доступы.

Шаг 3. Менеджер паролей и смена паролей

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

Менеджер паролей — программа, которая хранит учетные данные в зашифрованной базе и выдает их по правам. В том же опросе 23,8% компаний держат привилегированные пароли в KeePass, 19% — в российских менеджерах паролей, 9,5% используют PAM-системы, то есть специальные решения для контроля привилегированного доступа. Для компании на 10–50 человек с одним сайтом PAM избыточна, а менеджер паролей с общими папками закрывает задачу.

На что смотреть при выборе:

• Разделение по папкам и ролям. Маркетолог видит рекламные кабинеты, но не видит хостинг.
• Журнал обращений. Видно, кто и когда открывал запись.
• Отзыв доступа одним действием. Сотрудника отключили, и он больше ничего не видит.
• Где лежат данные. На своем сервере или в облаке поставщика. Для некоторых компаний это вопрос требований службы безопасности.
• Двухфакторная аутентификация на входе в сам менеджер.

Локальная база KeePass на общем диске лучше таблицы, потому что зашифрована. Но журнала обращений и разделения прав в ней нет, а мастер-пароль опять общий. Я бы считал ее промежуточным вариантом на 1–2 мес., пока выбирается командное решение.

Новые пароли не придумываются, а генерируются: 20 символов и больше, для каждого сервиса свой. Запоминать их не нужно, для этого есть менеджер. Запомнить придется один: от самого менеджера.

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

Шаг 4. Двухфакторная аутентификация

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

1. Почта, на которую завязано восстановление остальных сервисов.
2. Регистратор домена.
3. Панель хостинга или облака.
4. Аккаунт, которому принадлежат Метрика, Вебмастер и реклама.
5. Админка сайта и CRM.
6. Менеджер паролей.

Почта стоит первой не случайно. Тот, кто получил доступ к почтовому ящику администратора, через «Забыли пароль?» за 10 минут заберет регистратора, хостинг и рекламный кабинет. Сильные пароли на остальных сервисах при этом не помогут.

Код из приложения-аутентификатора надежнее кода из SMS: номер телефона можно перевыпустить, а приложение привязано к устройству. И сразу сохраните резервные коды в менеджер паролей. Потерянный телефон единственного администратора без резервных кодов превращается в неделю переписки с поддержкой хостинга.

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

Шаг 5. Отозвать лишнее и назначить ответственного

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

Чаще всего в списках остаются:

• студия или фрилансер, которые делали сайт или давно закончили проект;
• уволенные сотрудники, особенно из маркетинга: гостевые доступы в Метрике и рекламе живут годами;
• тестовые учетные записи с простым паролем, созданные «на минуту»;
• вебхуки и токены API для интеграций, которыми уже не пользуются;
• SSH-ключи без подписи, про которые никто не помнит, чьи они.

С ключами без подписи поступают жестко: если владельца не нашли за день, ключ удаляется. Кому он был нужен, тот придет сам.

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

И назначьте ответственного. Одного человека, по имени, у которого в календаре раз в квартал стоит задача «сверить реестр доступов». Без этого через год файл «Доступы.xlsx» появится снова, просто под другим названием.

План на один день

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

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

Что останется после этого дня

Останется документ на одну страницу, который в компании раньше не существовал: кто владеет доменом и хостингом, у кого какие права и когда это проверяли в последний раз. Пароли от сайта и хостинга перестанут быть общим знанием, а уход сотрудника или смена подрядчика превратятся в 10 минут работы по списку.

Мы в Design Lab проводим ревизию доступов, когда берем сайт на поддержку: без реестра невозможно отвечать за то, что на сервере происходит только согласованное. Но сделать это можно и своими силами. Достаточно выделить день и начать с таблицы, в которой нет ни одного пароля.