В этой статье я расскажу об автономном сервере – коротко или как получится. Расскажу о трех так называемых «темных сторонах» автономного сервера – о том, о чем обычно не думают. И немного поговорим о защите.
Что такое автономный сервер
Автономный сервер – это специальное серверное приложение, которое предназначено для обеспечения работы с информационной базой управляемого приложения любого клиентского приложения и Конфигуратора.
Это определение с сайта ИТС. Оно за время развития автономного сервера несколько раз менялось. Потому что впервые он появился в версии 8.3.14, сначала почти ничего не умел, но развивается вместе с платформой и сейчас умеет очень многое.
Изначально автономный сервер, как мне кажется, придумали для компаний, которым уже сложно работать с файловой базой, но до полноценной серверной они еще не доросли. И фирма 1С дала им возможность запускать управляемые приложения на так называемом автономном сервере.
Автономный сервер – это фактически две утилиты, два консольных приложения: ibsrv и ibcmd, где ibsrv – это сервер, а ibcmd – утилита управления автономным сервером. Дальше я их буду называть общим названием «автономный сервер». Просто имейте в виду, что для одних операций используется ibcmd, для других – ibsrv.
Консольная утилита – это первая особенность автономного сервера. Мы просто обращаемся к каталогу, куда установлен 1С. Если автономный сервер там тоже установлен – просто запускаем, и у нас волшебным образом появляется сервер.
Нам не нужно запускать службу, не нужно идти к администраторам, чтобы они регистрировали сервис, настраивали его – ничего этого не требуется. Автономный сервер прекрасно работает сам по себе.
Как конфигуратор, но лучше
Чем лично для меня хорош автономный сервер? Почему я его использую? Причем тут вообще конфигуратор? Все просто: я чаще использую автономный сервер в тех задачах, где раньше мне помогал конфигуратор – во всем, что связано с DevOps.
Во-первых, он быстрее*. Да, тут есть звездочка: официальных бенчмарков нет. Но по ощущениям он действительно работает быстрее.
Во-вторых, не требует графической оболочки. Все, кто сталкивался с DevOps в 1С, на это натыкались. Вы поднимаете CI/CD-контур, админы дают сервер, вы что-то на нем настраиваете – и у вас не работает конфигуратор.
Потому что конфигуратору нужна графическая оболочка. Несмотря на то, что это часть 1С – одной из самых мощных платформ для разработки бизнес-приложений – он работает только при наличии графики. Такая особенность, ее просто нужно учитывать.
Дальше – не требует лицензии. Тоже частая история: пытаются настроить выгрузку в исходный код, ничего не работает, потому что забыли пробросить лицензию.
Автономный сервер требует лицензию только для клиентских подключений – и то, если их больше трех. Все операции, о которых мы будем говорить, лицензии не требуют.
И, наверное, главная киллер-фича автономного сервера, которой лично мне удалось воспользоваться, напрямую не относится к теме статьи, но я не могу ее не упомянуть. Автономный сервер позволяет делать миграцию между различными базами на разных серверах баз данных без выгрузки в dt. То есть можно переносить данные напрямую, например, с MS SQL на PostgreSQL. И вам не нужно ждать, пока сначала выгрузится dt-файл на 100 ГБ, который еще может и не выгрузиться.
Это, на мой взгляд, самые сильные стороны автономного сервера. Конечно, не все, но самые важные.
Инструменты для работы: командная строка и OScript
Как работать с автономным сервером? Так как это консольные утилиты, с ними работают из командной строки. На сайте ИТС подробно описано, как с ним работать. Если внимательно прочитать, все будет понятно.
Также с автономным сервером можно работать с помощью OScript. OScript – это специальное приложение, на котором можно писать скрипты на 1С-подобном языке. Для OScript существуют библиотеки – заранее написанные модули и приложения, которые можно установить буквально одной командой.
Есть две библиотеки, с помощью которых можно работать с автономным сервером.
Первая – это Vanessa-Runner. Про нее наверняка многие слышали. Это такой супер-мега-гиперкомбайн для 1С-разработчика, с помощью которого можно делать практически все: выгружать конфигурации в исходный код, работать с dt, запускать тесты и так далее. Изначально он не умел работать с автономным сервером, но уже довольно давно – эту возможность добавили.
И есть еще одна библиотека для OScript – ibcmdrunner. С ее помощью можно создавать собственные скрипты, которые делают запуск команд автономного сервера более удобным. Дальше я покажу, как это выглядит.
Темная сторона: скрытые операции с базой
Теперь к основной теме статьи – к темной стороне.
Если автономный сервер такой хороший, зачем вообще говорить о темных сторонах? Затем, что об этом просто не думают.
Смотрите: автономный сервер – это отдельный сервер, который может работать с базой данных. И он ничего не знает о том, что к этой базе уже подключен настоящий сервер.
Ничего не мешает подключиться к рабочей базе – той самой, где прямо сейчас работают пользователи – через автономный сервер. Например, взять и сделать выгрузку базы в dt.
Все выполнится, все будет работать. Да, можно задуматься о консистентности данных, но на практике чаще всего все проходит нормально.
И представьте: мы можем снять dt с рабочей базы. С одной стороны, это даже удобно. Лично мне это нравится – можно быстро сделать копию базы, не обращаясь к администраторам, посмотреть данные и разобраться с проблемой. Но есть нюанс.
Так как это отдельный сервер, он ничего не знает о журнале регистрации основного сервера. И в журнале регистрации не будет ни одной записи о том, что кто-то выгрузил базу в dt – ни сейчас, ни вчера, ни вообще когда-либо.
И вот это уже выглядит не очень хорошо.
Как запустить выгрузку в dt?
ibcmd infobase dump
--dbms=mssqlserver
--database-server=dbServerName
--database-user=dbUser
--database-password=dbUserPassword
--database-name=docs-db
--data="d:_ss-data\dbName-data"
1cv8.dt
Перед вами командная строка: вызывается утилита ibcmd с ключами infobase dump. Дальше передаются параметры базы – тип сервера (MS SQL или PostgreSQL), адрес, логин, пароль, имя базы.
Здесь обычно возникает вопрос, где взять логин и пароль. К этому мы еще вернемся.
С помощью Vanessa-Runner все делается так же просто: вызывается консольное приложение runner, используется команда dump, передаются параметры или подключается конфигурационный файл – и все выполняется.
И мой любимый вариант – написать скрипт на OScript.
Сначала я пишу «Использовать ibcmdrunner» – это ключевой момент для подключения библиотеки. Дальше создается свой экземпляр класса «УправлениеИБ» – этот класс работает с автономным сервером, передает туда параметры. Далее выполняется команда «Выгрузить данные ИБ». Лично мне такой подход нравится больше всего.
Теперь вторая операция – загрузка конфигурации. Здесь темная сторона та же самая: мы можем с помощью автономного сервера загрузить конфигурацию или расширение в рабочую базу, минуя конфигуратор.
Если мы работаем через конфигуратор, то делаем две операции: сначала загружаем файл конфигурации, потом обновляем базу данных.
С автономным сервером – ровно то же самое. Первая команда – ibcmd infobase config load:
ibcmd infobase config load
--user=ibuser
--password=123
--dbms=mssqlserver
--database-server=dbServerName
--db-user=dbUser
--database-password=dbUserPassword
--database-name=docs-db
--data="D:\ss-data\cs-data"
--name=docsIB
1Cv8.cf
Вторая – ibcmd infobase config apply:
ibcmd infobase config apply
--user=ibuser
--password=123
--dbms=mssqlserver
--database-server=dbServerName
--db-user=dbUser
--database-password=dbUserPassword
--database-name=docs-db
--data="D:\ss-data\cs-data"
--name=docsIB
--force
С Vanessa-Runner тоже две команды, но там разделены сценарии для загрузки конфигурации и для загрузки расширений.
В случае скрипта на OScript все выглядит аналогично: создается класс «УправлениеИБ», затем выполняется загрузка конфигурации и ее обновление.
Я лично сталкивался с ситуацией, когда в рабочую базу загрузили расширение, и никто не понимал, как оно там появилось. В журнале регистрации не было ни одной записи. Удалось восстановить картину только благодаря системе мониторинга запросов – PerfExpert от компании Softpoint. Там мы увидели, что в определенный момент к серверу SQL было подключение с нехарактерного источника – не с сервера 1С.
Раскрытие паролей базы данных
Самое неприятное – это раскрытие паролей пользователей базы данных.
То, о чем я говорил раньше и о чем сейчас скажу – это не какая-то секретная информация. Все это есть на ИТС, в разделе про автономный сервер.
Разработчики сделали, по сути, хелпер – упрощение для тех, кто переходит с обычного сервера на автономный. Есть команда, в которую можно передать файл из каталога кластера 1С, где хранится описание кластера. И из этого файла можно получить пароли к базе данных.
Сам каталог выглядит обычным образом.
ibcmd server config import
--cluster-data="d:\1C srvinfo"
--name=basename
--out=d:\yml\basename.yml
Пароль там, конечно, хранится не в открытом виде – он зашифрован. Но дальше мы выполняем команду ibcmd server config import, передаем каталог с этим файлом, указываем, для какой базы нужны данные – и получаем результат либо в yml-файл, либо прямо в консоль.
Дальше начинается самое интересное.
Как 1С-разработчик, я могу зайти в рабочую базу, открыть универсальные инструменты – или любую обработку с файловым менеджером. Захожу на файловую систему сервера, нахожу каталог кластера, копирую нужный файл себе на компьютер. У меня локально развернут автономный сервер. Я выполняю эту команду – и получаю пароль без каких-либо сложностей.
На самом деле это не столько проблема инструмента, сколько неправильная настройка прод-контура. В 1С есть возможность разделить пользователей операционной системы: под одним запускается агент кластера, под другим – рабочие процессы сервера 1С.
Если бы такая настройка была (хотя я редко видел, чтобы ее использовали), то, так как весь код выполняется рабочим процессом, запустив файловый менеджер, я бы не смог получить эти настройки – потому что пользователю, под которым выполняется рабочий процесс, должен быть запрещен доступ к этому конфигурационному файлу. Скажу больше – так надо настраивать, но этого почему-то никто не делает.
Меры защиты
Что можно сделать для защиты от такого использования автономного сервера?
На самом деле, ключевая мера – одна. Не должно быть доступа в прод у посторонних людей. А программист – это, по сути, посторонний человек для прод-контура. Доступ в прод должен быть только у пользователей и, максимум, у одного администратора, который управляет системой. Если это правило соблюдается, то описанных ситуаций просто не возникает.
Вторая мера – защита на уровне сети. Доступ к SQL-серверу должен быть только с сервера 1С. Потому что автономный сервер, запущенный с любого компьютера, напрямую обращается к базе данных и выполняет все операции.
Вся эта информация находится в открытом доступе. Но, например, когда я впервые увидел историю с паролями, я в это не поверил, пока не убедился, что эти команды действительно работают.
По этим ссылкам можно найти документацию на ИТС, а также материалы по Vanessa-Runner, OScript и соответствующим библиотекам.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт
