Самые опасные вещи на проекте — те, которые работают и вроде никого не трогают.
Права доступа — как раз из этой серии.
Сайт на 1С-Битрикс живёт, заказы идут, сотрудники логинятся, что-то правят…
А где-то в тени лежат:
- один общий логин «admin» на всю компанию,
- бывший подрядчик с полным доступом,
- редактор, который случайно может снести половину каталога,
- открытая админка, в которую ломятся боты и не только.
И пока всё «пронóсит» — никто не шевелится.
А потом одна неудачная ночь, и вы утром смотрите на пустой каталог, сломанные шаблоны или утёкшие данные.
Я покажу 5 ошибок с правами в Битрикс, которые я вижу постоянно. Если сейчас узнаешь свой проект — это повод уже не просто «подумать», а пойти и проверить.
Ошибка №1. Один логин «admin» на всех, пароль «Qwerty123!»
Это прям классика жанра.
Сценарий:
- У вас есть главный логин «admin».
- Все разработчики, контентщики, маркетологи, подрядчики логинятся под ним.
- Пароль знают: бывшая студия, фрилансер, сисадмин, бывший маркетолог, сосед программиста и ещё пол-компании.
Что не так:
- вы не знаете, кто что сделал — в логах везде один и тот же пользователь;
- если пароль утечёт — любой желающий получит полный доступ к сайту и данным;
- уволенный сотрудник физически не перестаёт иметь доступ, если вы не сменили пароль в тот же день (а часто не сменили).
Как делаю я:
- создаю отдельные учётки для людей и подрядчиков;
- убираю общий «admin» из повседневной жизни (максимум — храню как резервный под супер-контроль);
- включаю длинный адекватный пароль + по возможности двухфакторку (через панель, VPN, IP-ограничения и т.д.).
Если у вас до сих пор один «священный» логин, который передаётся устно по легендам — это не удобство, это бомба замедленного действия.
Ошибка №2. Роль «Администратор» всем, кому не лень
Вместо того чтобы настроить нормальные роли типа:
- «редактор контента»,
- «менеджер по заказам»,
- «маркетолог»,
происходит следующее:
«Дайте ему админа, чтобы не отвлекать разработчика по мелочам».
И у вас:
- контентщик спокойно лезет в настройки модулей;
- маркетолог может удалить инфоблок или поменять права другим;
- сторонний SEO-шник имеет доступ к почтовым шаблонам, CRM и пользовательской базе.
Чем это кончается:
- случайно удалёнными разделами («я думал, это черновое…»);
- сломанными настройками корзины/оформления заказа;
- утечкой клиентских данных через обычный человеческий косяк.
Как делаю я:
- создаю отдельные группы пользователей: «Контент», «Заказы», «SEO», «Партнёры», и т.д.;
- каждой группе выдаю минимально необходимые права:
- контент — только инфоблоки контента;
- менеджеры — только заказы и CRM;
- маркетинг — формы, рассылки, метки;
- доступ уровня «Администратор» — только тем, кто реально отвечает за весь проект, а не просто «чтобы не просили лишний раз».
Принцип простой: минимум прав, максимум контроля.
Ошибка №3. Подрядчики и бывшие сотрудники всё ещё «внутри»
Очень люблю заходить в список пользователей и видеть:
- логин старого подрядчика с полными правами;
- учётки людей, которые уволились год назад;
- доступы «test_dev», «seo_freelance», «vasya_temp» — все активные.
Причём многие из этих людей:
- до сих пор имеют доступ в админку;
- часть — к файлам через FTP/SSH;
- часть — к базе/панели хостинга.
Почему это опасно, думаю, объяснять не надо.
У вас тупо нет контроля над тем, кто может зайти и что-то сделать.
Мой стандартный порядок наведения чистоты:
- Составляю список всех учёток с повышенными правами.
- Для каждой спрашиваю: «Этот человек/подрядчик сейчас с вами работает?»
- Всё лишнее — блокирую, а не удаляю: чтобы осталась история, но без входа.
- Отдельно ревизую доступы вне Битрикс: хостинг, SSH, Git, почта.
Самая жесть — когда заказчик даже не знает, сколько людей снаружи сейчас имеют доступ к его проекту.
Вот это прям надо выжигать сразу.
Ошибка №4. Открытая админка и отсутствие ограничений по входу
Ещё один весёлый сетап:
- /bitrix/ и /bitrix/admin/ доступны всему миру;
- нет ограничения по IP, по гео, по VPN;
- нет защиты от перебора паролей;
- логин/пароль передаются по HTTP без шифрования (да, такое ещё встречается).
И вы при этом удивляетесь, почему в логах постоянные попытки взлома.
Что я делаю:
- закрываю доступ к админке по IP/VPN, где это возможно;
- включаю HTTPS везде, в том числе на странице логина;
- настраиваю ограничения по попыткам входа, уведомления о множественных неудачных логинах;
- скрываю/меняю стандартные пути туда, где это оправдано.
Нет, это не даёт 100% защиты от всего на свете.
Но это отсекает тонну автоматической грязи и случайных атак по принципу «нашли открытую админку — пошли ломиться».
Ошибка №5. Права на файлы и разделы: можно удалить полсайта одним неловким движением
Битрикс — это не только админка.
У вас ещё есть:
- файловая структура;
- разделы, где через визуальный редактор можно убить верстку;
- доступ к системным файлам через «Редактировать страницу» и т.п.
И если вы даёте людям права «редактировать всё подряд», то:
- контентщик может залить картинку в 10 МБ прямо в шаблон;
- маркетолог через визуальный редактор снести половину верстки главной;
- SEO-шник «чуть-чуть подправит код» и положит шаблон компонента.
Как я это ограничиваю:
- запрещаю неквалифицированным людям лезть в структуру сайта и шаблоны;
- настраиваю безопасные точки правки через инфоблоки, отдельные поля и компоненты;
- для статичных страниц делаю инфоблок «Страницы» вместо правки сырых файлов.
И параллельно настроенные права на файловой системе:
чтобы не было истории «через FTP кто-то зашёл, удалил папку /bitrix/ и мы теперь живём на бэкапах».
Что я делаю, когда вижу бардак с правами на проекте
У меня уже на автомате:
1. Аудит пользователей и групп
- кто есть;
- кто чем пользуется;
- какие права у кого.
2. Чистка и раздача ролей
- убираю лишних, блокирую старых;
- создаю понятные группы под процессы бизнеса;
- раздаю минимально достаточные права.
3. Защита входа
- HTTPS везде;
- ограничения по IP/VPN, где это уместно;
- логирование подозрительных активностей.
4. Безопасные места для правок
- выношу всё, что должны править контентщики/маркетологи, в удобные и безопасные формы;
- убираю у них возможность одним кликом снести сайт.
После такой зачистки проект перестаёт жить в режиме «на честном слове и одном админском логине», а вы перестаёте зависеть от того, насколько аккуратным (или добросовестным) окажется каждый человек, который хоть раз заходил в вашу админку.