При работе в терминальной среде (RDS) на Windows Server 2012 R2 часто возникает ситуация, когда пользователи, обладая минимальными техническими знаниями, пытаются самостоятельно подключать базы данных или создавать новые. Если на этом же сервере развернут PostgreSQL, возникает риск несанкционированного доступа к данным в обход установленных прав 1С. В данной статье мы разберем комплексный подход к решению этой проблемы: от модификации интерфейса окна запуска до глубокой настройки безопасности СУБД и кластера 1С.
Самый простой и эффективный способ запретить пользователям добавлять базы — это лишить их соответствующих кнопок в окне запуска 1С. Проанализируем, как это реализовать. По умолчанию 1С считывает список баз из профиля пользователя, позволяя его редактировать. Однако использование параметра /runshortcut позволяет принудительно запустить 1С с конкретным файлом описания баз, при этом кнопки «Добавить», «Изменить» и «Удалить» станут неактивными.
Рассмотрим пошагово процесс настройки такого ярлыка:
ibases.v8i, в котором прописаны только разрешенные информационные базы.%USERPROFILE%\AppData\Roaming\1C\1CEStart\).
"C:\Program Files (x86)\1cv8\common\1cestart.exe" /runshortcut "C:\Path\To\Your\File\ibases.v8i"
Проанализируем ситуацию: когда пользователь запускает 1С через такой ярлык, платформа переходит в режим работы с фиксированным списком. Это исключает возможность ввода произвольного имени базы PostgreSQL в диалоговом окне создания ИБ, так как само окно создания станет недоступным.
Выясним причину, по которой пользователь вообще может создать базу. Если администратор кластера 1С не установил пароль на сам кластер, то любой процесс, имеющий доступ к портам сервера (по умолчанию 1540, 1541), может подать команду на создание новой базы. Чтобы этого избежать, необходимо выполнить следующие действия:
После этого, даже если пользователь попытается программно или через интерфейс добавить базу, система потребует аутентификацию администратора кластера. Без этих данных прописать путь к серверу СУБД и создать базу будет невозможно.
Одной из критических ошибок при настройке PostgreSQL является использование метода авторизации trust для локальных подключений. Разберем, чем это опасно. Если в файле конфигурации указан метод trust, СУБД пускает любого пользователя без пароля, если подключение идет с того же сервера (localhost). Пользователь, зная имя базы, может легко подключиться к ней.
Для исправления ситуации нам необходимо отредактировать файл pg_hba.conf. Найдем строки, отвечающие за локальные подключения, и заменим метод доступа на md5 или scram-sha-256. Рассмотрим пример правильной настройки:
# IPv4 local connections:
# Было: host all all 127.0.0.1/32 trust
# Стало:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
После внесения изменений необходимо перезагрузить службу PostgreSQL. Теперь при попытке подключения (даже через консоль 1С) система обязательно запросит пароль пользователя postgres или другого владельца БД. Пользователь, не знающий пароля системного аккаунта СУБД, не сможет добавить базу.
Для системных администраторов RDS-серверов удобным инструментом является файл 1cestart.cfg. Он позволяет жестко задать параметры поведения окна запуска для всех пользователей сервера. Посмотрим на пример конфигурации, которая перенаправляет список баз на защищенный сетевой ресурс или локальную папку с правами «только для чтения»:
CommonInfoBases=C:\ProgramData\1C\Common\SharedBases.v8i
InventoryLocation=C:\Program Files\1cv8\common\1cestart.exe
AdminInstall=0
Параметр CommonInfoBases указывает путь к общему списку. Если на уровне файловой системы (NTFS) запретить пользователям редактировать файл SharedBases.v8i, они смогут только запускать перечисленные в нем базы, но не смогут вносить изменения или добавлять свои. Важно: убедитесь, что у пользователей также ограничены права на запись в папку %AppData%\1C\1CEStart, чтобы они не могли подменить локальный список баз.
Если мы хотим максимально обезопасить систему, стоит рассмотреть отказ от публикации полного рабочего стола RDS. Вместо этого используем RemoteApp. Проанализируем преимущества этого подхода:
Для реализации этого метода создайте в диспетчере серверов коллекцию RemoteApp и добавьте в нее 1cestart.exe. В параметрах запуска приложения укажите путь к конкретной информационной базе. В этом случае пользователь при клике на иконку будет сразу попадать в окно авторизации 1С (ввод логина/пароля пользователя 1С), полностью минуя этап настройки списка баз.
Если пользователям не требуется вносить изменения в структуру базы, мы можем ограничить их в правах на запуск конфигуратора. Большинство манипуляций с подключением к СУБД и просмотром строк соединения происходит именно в режиме конфигуратора. Проанализируем возможность настройки прав NTFS на папку bin платформы 1С. Можно создать группу безопасности «1C_Users_OnlyEnterprise» и запретить ей доступ на чтение/выполнение к файлу 1cv8.exe (в случае толстого клиента), оставив доступ только к компонентам, необходимым для работы тонкого клиента, если архитектура это позволяет.
Подводя итог, можно сказать, что наиболее надежным решением является комбинация методов: установка пароля на кластер 1С, перевод PostgreSQL на метод авторизации md5 и использование RemoteApp с предустановленными параметрами запуска. Это создает многоуровневую защиту, которую практически невозможно обойти обычному пользователю RDS-сервера.