Роли и права сотрудников в админке сайта

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

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

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

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

Чем плох один общий доступ

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

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

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

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

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

Подрядчики получают лишнее. Дизайнеру, правящему баннер, не нужен доступ к базе заказов.

Как это устроено в системах управления сайтом

В ХостСМС, как и в большинстве серьёзных систем управления, доступ строится по трёхуровневой схеме.

Пользователь. Конкретный человек со своим логином, паролем и почтой. Один человек — один пользователь, никаких общих учётных записей.

Группа. Набор пользователей с одинаковым набором прав. Например, «контент-менеджеры», «менеджеры заказов», «разработчики».

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

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

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

Какие роли имеет смысл завести

Универсального списка нет, но есть типовой набор, который подходит большинству компаний.

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

Контент-менеджер. Добавляет и редактирует страницы, новости, статьи, товары. Не имеет доступа к настройкам, к пользователям, к платёжным модулям.

Редактор блога. Ещё уже: только раздел блога или новостей. Удобно для внештатного автора.

Менеджер заказов. Работает с заявками и заказами: смотрит, меняет статусы, добавляет комментарии. Не редактирует содержимое сайта и не трогает настройки.

Менеджер каталога. Товары, цены, остатки, категории. Не трогает всё остальное.

Наблюдатель. Только просмотр, без права что-либо менять. Полезно для руководителя, которому нужно видеть заявки, но не нужно ничего править, и для стажёра.

Разработчик. Доступ к шаблонам, коду, настройкам. Обычно временный, на период работ.

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

Принцип минимально необходимого доступа

Основное правило: человеку выдаётся ровно то, что нужно для его задач, и ничего сверх.

Звучит очевидно, но на практике нарушается двумя способами.

«Дадим на всякий случай побольше, вдруг понадобится». Именно так один доступ превращается в полный.

«Потом ограничим». Не ограничивают никогда.

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

Отдельный вопрос — право удаления. Его стоит выдавать особенно осторожно. Большинству сотрудников достаточно возможности скрыть или деактивировать элемент, а не удалять его физически. Скрытое можно вернуть, удалённое — только из резервной копии.

Журнал действий: зачем он нужен

Хорошая система управления ведёт журнал: кто, когда и что изменил.

Польза от него становится очевидной ровно в тот момент, когда что-то сломалось. Вопрос «когда пропал этот раздел и кто его трогал» из неразрешимого превращается в вопрос двух минут.

Что стоит сделать:

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

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

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

Простой порядок, который стоит записать один раз и дальше просто выполнять.

1. Отключить учётную запись сотрудника в админке. Именно отключить, а не удалять — история его действий должна сохраниться.
2. Проверить, не был ли на него оформлен доступ к чему-то ещё: почте, хостингу, домену, аналитике, рекламному кабинету, карточкам организации на картах.
3. Проверить, не указан ли его личный телефон или почта в настройках уведомлений о заявках.
4. Если он знал общие пароли — сменить их.
5. Убедиться, что уведомления о заявках продолжают приходить кому-то живому.

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

Как это связано с продвижением 3 в 1

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

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

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

2ГИС. Ровно та же проблема: карточка должна быть привязана к корпоративной, а не личной учётной записи, и доступ к ней должен быть у нескольких человек.

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

Двухфакторная защита и другие меры

Разграничение прав — только часть картины. Несколько дополнительных мер, которые стоит применять.

Двухфакторный вход. Если система поддерживает — включите хотя бы для администраторов. Это резко снижает риск при утечке пароля.

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

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

Смена адреса входа в админку. Простая мера, отсекающая автоматический перебор.

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

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

Типовые ситуации, из-за которых это делают

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

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

Изменились цены по всему сайту. Сотрудник воспользовался массовым редактированием, не разобравшись в фильтре, и применил наценку не к той группе товаров. Заметили через сутки, когда пошли заказы по неверным ценам.

Сайт закрылся от индексации. Кто-то зашёл в общие настройки посмотреть и случайно переключил параметр. Обращения из поиска падали три недели, пока не разобрались. Причина простая: доступ к общим настройкам был у всех.

Утёк список клиентов. Уволившийся сотрудник перед уходом выгрузил базу заявок с телефонами и почтой. Формально он имел на это доступ, потому что права были у всех одинаковые.

Заявки перестали приходить. Уведомления о новых заявках были настроены на личную почту менеджера. Менеджер уволился, ящик отключили, заявки продолжали сохраняться в базе сайта, но никто их не смотрел. Обнаружили через месяц по жалобе клиента.

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

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

Частые ошибки

Один логин на всех. Корень большинства проблем.

Полные права всем «чтобы не мешать работать». Экономия минуты сейчас — авария потом.

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

Личная почта сотрудника в настройках уведомлений. Заявки уходят человеку, который уже не работает.

Карточки на картах на личной учётной записи. Уходит сотрудник — уходит контроль над карточкой.

Отключённый журнал действий. Разбираться в инциденте становится невозможно.

Пароли в переписке. Мессенджеры и почта — не хранилище паролей.

Отсутствие резервных копий. Разграничение прав снижает риск, но не отменяет необходимости бэкапов.

Короткий план

1. Открыть список пользователей админки и посмотреть, кто там есть.
2. Отключить всех, кто больше не работает или не должен иметь доступ.
3. Завести персональные учётные записи всем, кто реально пользуется админкой.
4. Создать три-четыре группы с понятными наборами прав.
5. Раздать права по принципу минимально необходимого, особенно осторожно — право удаления.
6. Убрать общий логин, если он был.
7. Проверить журнал действий: включён ли, хранит ли историю.
8. Проверить, на чью почту и телефон приходят уведомления о заявках.
9. Проверить, на чьих учётных записях висят карточки в Яндекс Бизнесе и 2ГИС, домен, хостинг и аналитика.
10. Поставить в календарь ревизию доступов раз в полгода.

Итог

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

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

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