Проблема ограниченного доступа в стандартной консоли администрирования
В стандартной консоли администрирования можно назначить только одного администратора с полными правами. При этом нет возможности предоставить доступ лишь к отдельным функциям этого инструмента – права всегда будут максимальными. В рамках этой статьи я расскажу, как сделать так, чтобы доступ был до конкретной функциональности этого инструмента.
Меня зовут Евгений Крапивин, я являюсь экспертом по технологическим вопросам и занимаю должность технического архитектора в компании Factory 5.
Как говорится, театр начинается с вешалки, а доступ к базе 1С начинается с заведения пользователя в базу. Этот процесс имеет свои нюансы, но главное – сделать это правильно и, что особенно важно, безопасно.
Безопасная настройка пользователей и аутентификации
Слева на рисунке – небезопасный вариант настройки, на правом – безопасный. Что не так с вариантом слева?
Прежде всего, в левой версии одновременно включены два способа аутентификации: по логину и паролю, а также по доменной учетной записи. При этом пароль в системе 1С не задан. Такая ситуация типична: при создании пользователя указывают только доменную аутентификацию, нажимают «ОК» и считают, что все настроено корректно. Однако в результате у пользователя остается пустой пароль.
Если при этом установлена галочка «Показывать в списках выбора», возникает серьезная уязвимость: при запуске 1С можно просто выбрать этого пользователя из списка и войти в базу без ввода пароля. Доступ получен – и никакой защиты.
Чтобы этого избежать, необходимо проверять, чтобы у всех пользователей была отключена аутентификация по логину и паролю. В этом случае такие пользователи не будут отображаться в списках выбора, и обходной вход станет невозможен.
Если же используется аутентификация по логину и паролю, то крайне важно отключить отображение пользователя в списках выбора – это обязательное условие безопасности.
Для централизованного управления этими настройками можно обратиться напрямую к таблице [v8users] на сервере СУБД. В колонках [Show] и [EAuth] содержатся эти галочки – булево-значения, которые мы можем централизованно выключать для обеспечения безопасности.
Также в БСП есть опция «Потребовать установку пароля при входе пользователя», когда мы создаем нового пользователя. Давайте разберемся, чем она плоха.
Представим ситуацию: пользователь имеет доступ к нескольким информационным базам. Он заходит в первую – меняет пароль. Заходит во вторую – тоже меняет. А про третью забыл и не заходит в нее долгое время. Мы заходим в базу, точно так же открываем список выбора, видим пользователя, заходим без пароля (система позволяет это сделать) создаем новый пароль и таким образом получаем доступ в информационную базу.
Для контроля таких случаев в БСП предусмотрен регистр сведений «СведенияОПользователях», в котором фиксируется информация о необходимости смены пароля.
Кроме того, для защиты от подбора пароля (брутфорса) необходимо настроить параметры информационной базы, такие как количество неправильных вводов пароля и тайм-аут между неудачными попытками.
И политики паролей должны быть настроены так, чтобы пароли в базе были сложными.
Безопасный запуск компонентов сервера и управление учетными записями
Спускаемся на следующий уровень – безопасность компонентов сервера.
Каждый компонент сервера 1С должен быть настроен на запуск отдельного доменного пользователя. Это базовый принцип безопасности. Минимально необходимая настройка – использовать отдельных пользователей для агента сервера и для рабочих процессов (RP-хостов). Особенно важно, чтобы пользователь, от имени которого запускается rphost.exe, имел максимально ограниченные права в операционной системе.
Для управления учетными данными запуска процессов в 1С используется файл swpuser.ini. В нем можно декларативно указать, под каким логином и паролем должен запускаться тот или иной процесс. Доступ к этому файлу должен быть только у агента сервера. Все остальные пользователи и процессы должны быть лишены права чтения этого файла. Иначе прочитав этот файл из кода 1С мы можем получить логин и пароль.
Для всех пользователей, созданных для работы компонентов сервера, необходимо отключить возможность интерактивного входа на сервер.
Теперь спускаемся еще ниже – к настройке доступа к самому кластеру серверов. У нас есть два ключевых понятия: администратор сервера и администратор кластера. Когда мы создаем администратора кластера, по умолчанию включается галочка «Аутентификация паролем». Мы также проставляем аутентификацию по доменной учетной записи, вбиваем туда доменную учетную запись и нажимаем «ОК».
В результате можно открыть консоль кластера, ввести имя пользователя admin, нажать «ОК» – и успешно войти без пароля.
Как обнаружить такую ситуацию? В реестре кластера можно увидеть такую строчку – {"Админ","","","2jmj7l5rSw0yVb/vlWAYkK/YBwk=","\\domain\user",3}. Имя админа, хэш пустого пароля, его доменная идентификация и в конце указан режим, по которому заходят. Режим определяется числом:
-
1 – аутентификация по логину и паролю,
-
2 – только по доменной аутентификации,
-
3 – комбинированный режим (оба способа).
Если в настройках указан режим 3, а хэш пароля соответствует пустой строке – это дыра в безопасности.
Еще раз подчеркну: крайне важно использовать сложные пароли для администраторов. Хэш пустого или простого пароля легко подобрать с помощью специальных инструментов в интернете. Поэтому пароли администраторов должны быть сложными.
Интерактивные доступы и создание централизованного приложения управления
Рассмотрим стандартные инструменты, которые предоставляют доступ к администрированию кластера 1С.
Первый и самый известный – это консоль администрирования, о которой я уже упоминал. Она взаимодействует с агентом сервера и предоставляет доступ ко всем функциям кластера.
Второй инструмент – универсальная обработка, входящая в состав стандартных обработок платформы. В отличие от утилиты администрирования, она кроссплатформенная и работает как на Windows, так и на Linux. Она также предоставляет полный доступ к кластеру – что с точки зрения безопасности тоже плохо. Но хорошо то, что мы можем подключить ее к любой конфигурации, сохранить и посмотреть, как она написана, чтобы организовать на ее базе свой доступ со своими особенностями.
Что мы можем построить на этой основе?
У нас есть кластер, который, как мы уже выяснили и настроили до этого, находится в безопасности, есть сервер администрирования, с которым общается непосредственно клиент, который запрашивает у кластера информацию. Также у нас есть приложение управления, через которое пользователи взаимодействуют с кластерами.
Я рекомендую разрабатывать такое приложение на 1С. Мы все пишем на 1С, поэтому это просто и удобно. Там можно задавать свои роли и распределять по ним функциональность.
Выделенное на рисунке выше синей рамкой – это опциональные вещи, о которых я расскажу чуть позже. Это API и шлюз для взаимодействия с конкретной информационной базой, если это потребуется.
Что такое шлюз? Что в него можно зашить?
Это может быть дополнительная IDM-система – автоматизация создания пользователей и распределения прав. Внешние обработки или расширения устанавливаются в конкретную информационную базу. Центральная база управления взаимодействует с этими расширениями и выполняет административные действия.
Сбор дополнительной справочной информации. Можно выгружать, например, журнал регистрации, номер релиза, какая организация заведена в этой информационной базе и так далее. Агрегировать ее, аккумулировать в центральном приложении управления и это будет удобно для пользователей.
Также можно использовать БСП-метод установки блокировки. При установке блокировки через этот метод пользователь получает уведомление: «Через 5 минут работа в приложении будет завершена. Пожалуйста, сохраните свои документы». Это гораздо удобнее, чем резкое прерывание сессии с ошибкой.
Права пользователей в информационной базе можно настраивать через IDM-систему.
Особенно интересна функция имперсонализации. Допустим, аналитику нужно войти в базу под конкретным пользователем, чтобы воспроизвести какую-то ошибку. Мы можем не давать пароль от этого пользователя аналитику, а можем воспользоваться имперсонализацией.
Резервирование сервера администрирования и совместимость версий
Теперь хочу поговорить о сервере администрирования – о так называемом RAS (Remote Administration Server), о том, что его можно резервировать и зачем это нужно.
Один сервер администрирования общается только с одним кластером, но один кластер может общаться с несколькими серверами администрирования. Таким образом, мы получаем систему, при которой наши запросы идут через один сервер администрирования, и если он по какой-то причине не отвечает на наш запрос, мы идем по другому серверу администрирования и пытаемся выяснить, что там произошло: может быть, кластер перегружен и так далее.
Важное замечание: сервер администрирования и кластер обязательно должны быть на одной и той же версии платформы 1С. Однако приложение, которое управляется этим сервером администрирования и посылает в него команды, может быть написано на любой версии платформы. Ему неважно, сколько у вас версий платформы, он подключится к любому.
Из встроенного языка 1С это можно сделать с помощью объектной модели 1С, она очень простая и надежная.
Функциональность централизованного приложения управления и использование объектной модели 1С
Возможности центрального приложения управления
Какую функциональность может иметь центральное приложение? По сути, это расширение стандартных функций кластера 1С.
Прежде всего, приложение позволяет реализовать гибкую ролевую модель доступа. Например, пользователям с ролью «Программист» можно разрешить устанавливать блокировку информационной базы, останавливать регламентные задания и завершать сеансы. В то же время «Консультант» или «Аналитик» могут иметь право только на завершение сеансов – им недоступны изменения настроек базы или кластера.
При завершении сеанса через консоль администрирования соответствующие логи попадают только в технологические журналы, которые не всегда доступны и понятны обычным пользователям. Через центральное приложение мы можем собирать эти логи и предоставлять их.
Через центральное приложение можно организовать автоматизированный сбор всех информационных баз, которые доступны, наполнять его дополнительной справочной информацией, которая может быть полезна консультантам, аналитикам и так далее.
Приложение позволяет удобно управлять сеансами, устанавливать блокировки и, при необходимости, изменять отдельные настройки кластера.
Работа с объектной моделью 1С
Что касается объектной модели языка 1С, которая предоставляет возможность взаимодействовать с сервером администрирования, то здесь нужно понимать некоторые моменты.
ПолучитьСеансы() и ПолучитьСоединения() – у них внутри нет никаких параметров, они по умолчанию получают все сеансы. Единственное, как мы можем распределить этот массив получаемых сеансов и определить маленькая или большая будет выборка, это задать либо для кластера, либо для информационной базы. Если мы понимаем, что кластер маленький, там немного сеансов, мы можем получить сеансы для всех информационных баз прямо из кластера. Но если мы понимаем, что база может быть большая, то необходимо обращаться именно через информационную базу получения сеансов и соединений.
При подключении к серверу администрирования необходимо выполнить аутентификацию. Здесь по умолчанию нужно задавать логин и пароль. Если логин и пароль не установлены, то он пытается аутентифицироваться без них.
Для агента необходимо выполнять аутентификацию только если вы планируете создать новый кластер или изменить существующий.
Для кластера аутентификация обязательна для работы, чтобы получать соединения, сеансы и так далее. Это основной вариант аутентификации для работы, он используется больше всего.
С помощью аутентификации в информационной базе мы можем получать настройки информационной базы. Здесь важен момент, недокументированная особенность: если в предыдущих вариантах аутентификации не работает доменная аутентификация, то в информационной базе она работает.
Что это может нам дать? Так как объектная модель существует и на клиенте, и на сервере, мы можем спокойно запустить локальный экземпляр в сервер администрирования от имени пользователя, от имени доменной учетной записи пользователя, и от имени доменной учетной записи пользователя выполнить аутентификацию в информационной базе.
Если в информационной базе этот пользователь по доменной аутентификации заведен как админ, мы поймем, что он имеет полные права на эту информационную базу. И он действительно может завершать сеансы, делать административные действия в этой базе и т.д. и т.п. Это очень удобно.
Особенности завершения сеансов и прерывания серверных вызовов
Удаление сеансов: сложности и особенности
Следующая тема довольно холиварная – удаление сеансов. Многие сталкивались с ситуацией, когда сеанс не удаляется из кластера.Чтобы разобраться, нужно понимать, как происходит удаление сеанса из кластера.
Начнем непосредственно с команды «Удаление сеанса», когда вы либо в консоли администрирования нажимаете «УдалитьСеанс.» или через объектную модель задаете команду «ЗавершитьСеанс». Если в этот момент сеанс не производил никакого серверного вызова, то для пользователя ничего не произойдет. Только когда он попробует у себя в клиенте обратиться к серверу, выберет какой-нибудь список или начнет выполнять какие-нибудь модификации, у него появится сообщение о том, что его сеанс уже отсутствует или удален.
Если происходит серверный вызов, тогда мы поднимаемся на строчку выше, между сеансом и рабочим процессом образуется соединение, и первое, что происходит, это попытка разрыва этого соединения.
Когда строчка кода выполняет очень длительный запрос, и мы нажимаем «УдалитьСеанс», то этот запрос удалится, но только для Microsoft, ADB2 и Oracle. Для Postgres он не удалится (здесь нужно сделать ремарку: для Postgres 16 действует инструкция kill и запрос будет удален).
Второй вариант – когда мы в серверном вызове запустили консоль с TIMEOUT 100 секунд, он просто висит в фоне и ничего не делает. Контекст не покидает одну строку кода. А на ИТС написано, что завершение сеанса и разрыв соединения происходит только в моменте, когда строка переходит на следующую в рантайме. В таком случае процесс завершится, когда закончится серверный вызов. Если здесь задать не «TIMEOUT 100» секунд, а ping с ключом -t, который бесконечно пингует, то он никогда не завершится.
Третий вариант – это 1С-пауза, которая появилась в 25-й платформе. Платформа в этом случае очень корректно отрабатывает это соединение.
Дальше хотел бы рассказать про такую функцию, как прерывание текущего вызова. Она доступна для тонкого клиента, мобильного клиента и веб-клиента. Когда клиент выполняет серверный вызов, мы можем не полностью завершить этот сеанс, чтобы он умер, пользователь получил большую ошибку и ему пришлось перезаходить в информационную базу, а завершить только его текущий вызов. Пользователь в этом случае все равно получит ошибку, но останется жить в базе, ему не придется в нее перезаходить.
В этом случае мы можем предварительно собирать данные по технологическому журналу ADMIN и EXCP. В случае, когда мы удаляем из консоли серверный вызов, у нас будет писаться в ТЖ событие ADMIN, по которому после него будут собираться события EXCP, в которых будет содержаться контекст.
Таким образом мы можем получать контекст конкретного серверного вызова. Это может быть полезно, когда мы пытаемся расследовать, почему конкретный большой серверный вызов израсходовал столько памяти. Скорее всего, он выполняет что-то очень тяжелое, но что – непонятно. А таким образом мы сможем это понять. Да, мы прервем текущий серверный вызов, пользователь получит ошибку, но мы при этом получим точное место в указании кода, где происходила ошибка. Даже если происходил запрос, мы получим текст запроса и на языке SQL, и на языке 1С, и на DDL.
На этом у меня все. Занимайтесь безопасностью вашего кластера, пока ее отсутствием не воспользовался кто-то другой.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт
