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