Первый пользователь Bitrix часто становится общей учётной записью разработчика, подрядчика и владельца. Когда меняется команда, возникает желание удалить пользователя ID=1 или напрямую убрать его из группы администраторов. Такая операция затрагивает системную защиту и не решает автоматически проблему оставшихся сессий, ключей интеграций и доступа к серверу.
Разберём управляемую смену административного доступа: проверка действующих записей, создание персонального администратора, защита первоначальной записи и отзыв полномочий обычного пользователя. Материал относится к коробочной CMS «1С-Битрикс: Управление сайтом»; облачный Битрикс24 и внешняя авторизация требуют своей процедуры. Ниже нет SQL для обхода ограничений ядра.
1. Почему пользователь ID=1 отличается от группы ID=1
ID пользователя определяет запись человека или технического субъекта, ID группы — набор полномочий. Совпадение цифры 1 не делает эти сущности одинаковыми. Удаление строки связи между ними не тождественно удалению пользователя и не является полным отзывом доступа.
В проверенном текущем коробочном ядре CUser::Delete исключает пользователя с ID=1 из выборки для удаления. Следовательно, отказ API для этой записи нельзя считать обычной неисправностью базы. Реализацию своей установленной версии проверяют отдельно: статья не обещает одинаковое поведение всех релизов и кастомизаций.
Документация CUser описывает операции с пользователями, а руководство групп — разграничение полномочий. Прямой DELETE пропускает обработчики, очистку связанных данных и штатное управление состоянием. Наличие доступа к SQL не делает такой обход поддерживаемым способом администрирования.
2. Определите, какую проблему требуется решить
Сформулируйте цель: прекратить использование общего логина, отключить ушедшего подрядчика, передать аварийную запись владельцу или расследовать компрометацию. Каждая цель имеет свой набор действий. При компрометации нужно проверить не только CMS, но и SSH, панель хостинга, почту восстановления, OAuth и секреты интеграций.
Смена имени пользователя не закрывает существующую сессию. Блокировка одной записи не отзывает права другого администратора, созданного тем же подрядчиком. Удаление пользователя может повредить связи с объектами, которые были созданы от его имени.
Зафиксируйте ответственного, время изменения и разрешённый способ возврата. Для передачи обслуживания полезен отдельный перечень доступа: система, учётная запись, роль, владелец и статус отзыва. Пароли и токены в этот перечень не включают.
3. Подготовьте восстановление до изменения прав
Сохраните согласованную копию базы, файлов приложения и конфигурации, включая нужные настройки аутентификации. Проверьте восстановление на отдельном контуре. Архив, который ни разу не открывали, не является доказанным способом возврата.
Убедитесь, что организация контролирует сервер или панель хостинга, почту восстановления и второй административный вход. При AD/LDAP или другом внешнем источнике идентичности выясните, где отключают пользователя и как CMS обновляет его роли.
Старую рабочую сессию оставляйте открытой до проверки нового входа. Она полезна для возврата небольшого изменения, но не является заменой резервной копии. Если система подозревается во взломе, сохраняйте необходимые следы до очистки и согласуйте порядок расследования.
4. Как проверить запись и её группы через CLI
Пример только читает пользователя и его группы. Сохраните его вне web-root, задайте фактический путь сайта и запустите PHP CLI нужного окружения. Не размещайте диагностический файл по публичному URL.
<?php
if (PHP_SAPI !== 'cli') { exit(2); }
$siteRoot = '/srv/www/example-site';
if (!is_file($siteRoot . '/bitrix/modules/main/include/prolog_before.php')) {
throw new RuntimeException('Проверьте путь сайта');
}
$_SERVER['DOCUMENT_ROOT'] = $siteRoot;
define('NO_KEEP_STATISTIC', true);
define('NO_AGENT_CHECK', true);
require $siteRoot . '/bitrix/modules/main/include/prolog_before.php';
$id = 1;
$row = CUser::GetByID($id)->Fetch();
if (!$row) { throw new RuntimeException('Пользователь не найден'); }
echo json_encode([
'id' => (int)$row['ID'],
'active' => $row['ACTIVE'],
'groups' => CUser::GetUserGroup($id),
], JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT), PHP_EOL;Результат показывает свойства записи, но не доказывает отсутствие других путей авторизации. Для полного аудита изучите персональных администраторов, интервалы членства в группах, внешние источники и доступ интеграций. CLI может использовать другой PHP и другой набор расширений, чем web-процесс; зафиксируйте это различие.
5. Создайте персонального администратора и проверьте его отдельно
Откройте Настройки → Пользователи → Список пользователей, создайте персональную запись нового ответственного и назначьте согласованную административную группу. Порядок формы описан в пользовательском руководстве Bitrix. Полные права нужны только тому, кто действительно администрирует систему.
Задайте индивидуальный секрет через защищённую форму, актуальную почту восстановления и доступную в вашей редакции MFA. Не копируйте общую парольную строку старой записи и не отправляйте секрет через обычный комментарий заявки.
В отдельном профиле браузера выполните новый вход. Проверьте доступ к пользователям и требуемым административным разделам, затем выход и повторный вход. Разрешение одной страницы не доказывает достаточные полномочия для восстановления или обслуживания. Убедитесь, что MFA и восстановление принадлежат организации, а не прежнему подрядчику.
6. Как защитить первоначальную запись ID=1
Первоначальную запись разумно рассматривать как контролируемый аварийный доступ, а не повседневный общий логин. Передайте её секрет в управляемое хранилище организации, смените известный прежним участникам пароль и проверьте контакт восстановления. Доступ к хранилищу также должен иметь владельца и аудит.
При изменении логина сначала проверьте зависимости: автоматические задания и внешняя интеграция могли использовать его буквально. Такие интеграции лучше перевести на отдельные технические записи с узкими правами, а не сохранять общий административный пароль в скриптах.
Не обходите запрет интерфейса правкой таблиц и файлов ядра. Если политика требует полного исключения системной записи, сначала получите поддерживаемую процедуру для конкретного продукта и релиза. Скрытие формы входа, смена URL или снятие одной связи с группой не являются доказательством отзыва доступа.
7. Как отозвать доступ обычного администратора
В административной части откройте список пользователей через меню «Настройки → Пользователи → Список пользователей» либо поиск меню. Найдите точную запись по ID, откройте её карточку и сверяйте источник авторизации. Для создания персональной записи используйте «Добавить пользователя»: задайте контролируемую организацией почту, персональный логин, способ первоначального входа и необходимые группы. Во вкладке групп назначайте административную роль только согласованному ответственному, затем проверьте вход в отдельном браузере. Названия вкладок могут отличаться в вашей редакции.
После проверки нового администратора выберите точную запись уходящего пользователя по ID, а не только отображаемому имени. Проверьте источник авторизации и связанные обязанности. Для обычной локальной записи изменение выполняют через интерфейс или штатный API с контролем результата.
CUser::Update возвращает результат операции и LAST_ERROR при отказе. Поле GROUP_ID представляет список назначаемых групп: передача неполного массива способна удалить и полезные непривилегированные роли. Для групп с датами учитывайте сроки, а не восстанавливайте только номера.
В карточке обычного локального пользователя снимите флаг активности и сохраните изменение; при работе с группами отдельно удалите административное членство, сохранив согласованные остальные роли и даты. Это не инструкция для принудительного изменения защищённого ID=1. Для автоматизации обычной записи после подключения ядра в контролируемом CLI-файле применим следующий фрагмент:
// Ядро уже подключено по CLI-примеру выше.
// Замените ID после проверки карточки и сохранения состояния.
$targetId = 123;
if ($targetId <= 1) { throw new RuntimeException('Системная запись исключена'); }
$target = CUser::GetByID($targetId)->Fetch();
if (!$target) { throw new RuntimeException('Целевая запись не найдена'); }
$userApi = new CUser();
if (!$userApi->Update($targetId, ['ACTIVE' => 'N'])) {
throw new RuntimeException($userApi->LAST_ERROR);
}
$after = CUser::GetByID($targetId)->Fetch();
if (!$after || $after['ACTIVE'] !== 'N') {
throw new RuntimeException('Состояние после изменения не подтверждено');
}Перед этим изменением сохраните исходные ACTIVE и группы с датами, проверьте независимый вход и соответствие целевого ID. CLI действует с полномочиями серверного процесса; не отдавайте такой файл пользователям и не размещайте его в web-root. Фрагмент не завершает сессии и не отзывает внешние ключи: это отдельные проверки ниже.
Для целевого отзыва предпочтительно оставить карточку и историю, отключив необходимый способ входа по поддерживаемой процедуре. Это упрощает расследование и сохранение авторства. Проверьте обработчики проекта: они могут запрещать изменение или синхронизировать права обратно из внешнего каталога.
8. Почему нужно отдельно проверить активные сессии
Изменение флага активности, групп и пароля — разные события. Поведение уже открытой сессии зависит от механизма авторизации, версии и дополнительных модулей. Не делайте вывод «права отозваны» только по новой строке формы.
Примените штатное завершение сессий и отзыв сохранённых авторизаций, доступные вашему продукту. Затем проверьте старую сессию, новый вход по старым данным и повторный доступ к защищённому разделу. Если используется внешняя MFA или SSO, отзыв проверяют и в этом контуре.
Смените или отзовите отдельные ключи интеграций, которые получал пользователь, после оценки влияния на сервисы. Блокировка CMS не закрывает SSH и доступ к базе. Эти системы должны быть включены в перечень передачи обслуживания, а результат отзыва — подтверждён отдельно.
9. Как диагностировать отказ и выполнить возврат
Если интерфейс не принимает изменение, прочитайте сообщение, журналы безопасности и обработчики авторизации. Отказ может означать защиту последнего администратора, ограничение системного пользователя, внешнюю синхронизацию или ошибку кастомного обработчика. Прямой SQL уничтожает диагностическую границу между этими причинами.
Возврат небольшого изменения восстанавливает прежние согласованные поля и роли, включая даты членства, через штатный механизм. Полный возврат базы влияет на изменения всех пользователей после копии и требует отдельного решения. Не восстанавливайте старый скомпрометированный пароль как способ исправить доступ.
Если новый административный вход потерян, действуйте по процедуре восстановления продукта с контролируемым серверным доступом. Файл, который выдаёт администратору доступ при обращении по URL, нельзя оставлять в публичном каталоге «для будущего случая».
10. Когда передача административного доступа завершена
Персональный администратор входит повторно, MFA и восстановление контролируются организацией, прежний пользователь не проходит новый вход и не сохраняет привилегии через старую сессию. Аварийная запись защищена, автоматизация использует собственные роли, ключи и серверный доступ включены в проверку.
Сохраните ID изменённых записей, параметры до и после без секретов, результаты проверки и место резервной копии. Первоначальная системная запись должна иметь понятную роль и контролируемый жизненный цикл.
Удаление ID=1 само по себе не является улучшением безопасности. Проверенный отзыв конкретных полномочий, персональные записи и воспроизводимый порядок возврата дают администратору управляемый результат без вмешательства в защиту ядра.
Нужно безопасно администрировать Битрикс24?
Настройку учётных записей и прав стоит связать с регулярным сопровождением портала и контролем доступа.