Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 20
Разве не любая учетная запись, у которой есть доступ к базе данных, где обрабатывается информация, может читать всё что угодно?
Да, если у человека есть прямой доступ к серверу или базе данных то он технически может читать данные.
В статье речь о другом: о штатной функции "Авторизоваться под пользователем" внутри самого коробочного Bitrix24. Она работает на уровне приложения и не требует доступа к БД.
Проблема в том, что в стандартной поставке нет подробного журналирования того, кто и когда заходил под пользователем и просматривал переписку.
Модуль добавляет именно прикладной контроль и аудит таких действий.
От root-доступа к серверу он, разумеется, не защищает - это уже инфраструктурный уровень.
root-доступ к серверу и не нужен - у админа в распоряжении и php-командная строка, и sql-командная строка, и просто просмотр всех таблиц - все это через админку битрикса. Модуль бессмысленный получился, чисто для галочки видимо 🤷
Доступ к PHP- и SQL-консолям в админке не является и не должен быть "по умолчанию доступным любому администратору".
Он регулируется правами, в частности операцией edit_php (Изменение PHP-кода), которая настраивается на уровне групп пользователей.
На практике такие права выдаются строго ограниченному кругу технических администраторов и не относятся к обычным бизнес-админам портала.
Модуль закрывает прикладные сценарии:
- контроль использования функции «Авторизоваться под пользователем»
- аудит действий
- ограничение просмотра таблиц IM-модуля через штатный интерфейс админки
Это контроль внутри модели платформы, а не вмешательство в ядро.
Ну подождите, все же придумано до нас. Защиту от администратора может обеспечить только сквозное шифрования. И то если разработчик не сделает закладку...
Сквозное шифрование решает другую задачу защиту от инфраструктуры и третьих лиц. Да и в Битриксе это невозможно. В коробке администратор по определению управляет системой.
Вопрос в другом: фиксируются ли его действия и есть ли контроль внутри самой платформы
Даже если они и фиксируются, администратор может их зачистить или модифицировать. Иначе нужен администратор администраторов
Тут задача немного другая - усложнить и сделать прозрачными злоупотребления штатными механизмами.
В решении используется двойное логирование:
запись события в журнал приложения + независимная фиксация через триггеры БД, а также оперативное уведомление службы ИБ (мессенджер, e-mail, webhook).
Дополнительно настройки самого модуля защищены мастер-паролем. Это отдельный уровень контроля - администратор портала не может просто отключить аудит без знания этого пароля. Тем самым вводится элемент разделения полномочий.
Опять же это не «защита от root» - инфраструктурный доступ по определению выше прикладного уровня.
Речь о снижении риска незаметного использования impersonation внутри самой платформы.
В корпоративной среде чаще стоит задача не абсолютной недоступности, а управляемого контроля и аудита действий администраторов.
Хватит генерить тупую бесполезно чушь через вайбкодинг, если вы не умеете в битрикс
А что не так? Рабочий аккаунт он не ваш, он вашей фирмы. Логично дать возможность нескольким людям ходить в один аккаунт.
А подключить двухфакторку со своего личного телефона для исключения возможности входа в твою учетку постороннего лица, даже админа, нельзя в битриксе?
Двухфакторная аутентификация защищает вход в конкретную учётную запись извне.
В случае impersonation администратор не «подбирает пароль» и не входит как внешний злоумышленник. Он использует штатную функцию внутри системы «Авторизоваться под пользователем», уже будучи аутентифицированным как администратор.
То есть 2FA от входа в аккаунт пользователя здесь не срабатывает, потому что сессия создаётся на уровне приложения от имени администратора.
В статье речь как раз про контроль использования этой функции, а не про защиту от внешнего взлома.
С точки зрения информационной безопасности правильным будет отключить эту функцию и вырезать её из исходного кода.
Если администратору нужен доступ под чужим аккаунтом, он может подать служебную заявку, согласовать её с заведующими отделов, подтвердить у профильного заместителя директора, собрать комиссию, выбрать секретаря для ведения протокола, пригласить сотрудника и подключиться вместе с ним.
Удалить функцию из исходного кода - самый радикальный вариант, но на практике это означает вмешательство в ядро и проблемы с обновлениями.
«Авторизоваться под пользователем» - штатный механизм, который вендор поддерживает много лет. Он используется для поддержки и диагностики, поэтому полностью вырезать его - не всегда реалистично.
Более практичный подход - не ломать систему, а контролировать использование функции: ограничить круг лиц, фиксировать действия, уведомлять и обеспечивать прозрачность.
Это не вмешательство в ядро, а всего лишь маленький патч из двух строк.
а где указано что это штатный механизм?
https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=35&LESSON_ID=2004&LESSON_PATH=3906.4503.2004
в официальной документации указано "Форма редактирование параметров пользователя вызывается с помощью двойного клика левой кнопкой мыши по записи пользователя, либо с помощью пункта Изменить в контекстном меню. С помощью команды Авторизоваться администратор может в один клик выйти из своего аккаунта и авторизоваться под выбранным аккаунтом" .
Спустя 20 лет существования битрикса, пользователи начали что-то подозревать...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Администратор может читать переписку сотрудников в Bitrix24. Это нормально?