Вопрос безопасности при публикации информационных баз 1С:Предприятие в глобальной сети является одним из самых критичных для системных администраторов и разработчиков. Прямой проброс портов (Port Forwarding) с внешнего IP-адреса на внутренний сервер — это распространенное, но потенциально уязвимое решение. В этой статье мы подробно разберем, как минимизировать риски, какие встроенные механизмы платформы использовать и как выстроить эшелонированную систему защиты.
Когда мы открываем доступ к базе через веб-сервер (Apache или IIS) простым пробросом 80-го или 443-го порта, сервер становится виден всем сканерам интернета. Основные угрозы в этом случае включают:
HTTP данные передаются в открытом виде.Рассмотрим рекомендации по усилению авторизации непосредственно в конфигурации. Первым делом необходимо обеспечить сложность учетных данных. Разберем основные правила:
Выясним, как реализовать механизм защиты от подбора паролей. В самой платформе "из коробки" жесткого бана по IP нет, но есть несколько способов решения задачи:
1. Использование Библиотеки стандартных подсистем (БСП)
Проанализируем возможности БСП. В современных конфигурациях (таких как 1С:Бухгалтерия 3.0 или 1С:УТ 11) уже реализован функционал защиты. В подсистеме "Пользователи" можно настроить:
2. Реализация собственного механизма блокировки
Если ваша конфигурация не использует БСП, мы можем самостоятельно дописать функционал. Для этого создадим РегистрСведений, в который будем записывать количество попыток и время последнего входа. Рассмотрим концептуальный пример кода для проверки при входе:
Процедура ПриНачалеРаботыСистемы()
ИмяПользователя = ПользователиИнформационнойБазы.ТекущийПользователь().Имя;
Если ПревышенЛимитПопытокВхода(ИмяПользователя) Тогда
Предупреждение("Доступ временно заблокирован из-за большого количества ошибок авторизации.");
ЗавершитьРаботуСистемы(Ложь);
КонецЕсли;
КонецПроцедуры
Важно помнить, что этот код срабатывает после того, как платформа проверила пароль. Для полноценной защиты от роботов на уровне веб-сервера лучше использовать внешние инструменты, такие как Fail2ban.
Использование протокола HTTPS является обязательным стандартом. Без SSL/TLS-сертификата любые меры по сложности паролей бесполезны, так как логин и пароль могут быть перехвачены в момент передачи. Проанализируем шаги для настройки:
Let's Encrypt).Nginx, Apache или IIS).default.vrd убедитесь, что обращения идут по защищенному протоколу.Вместо того чтобы пробрасывать порты напрямую к серверу с 1С, мы рекомендуем установить Nginx в качестве обратного прокси. Это дает нам ряд преимуществ:
Apache или 1С:Предприятия вы используете, что затрудняет поиск специфических эксплойтов.Nginx может отсекать подозрительную активность еще до того, как запрос дойдет до платформы 1С.Для глубокой защиты сервера разберем механизм Профилей безопасности платформы 1С. Профили позволяют ограничить возможности встроенного языка на стороне сервера:
Также крайне важно запускать службу веб-сервера от имени пользователя с минимальными правами в операционной системе. Если злоумышленник сможет взломать веб-сервер, он не должен получить права администратора на всем компьютере.
Если требования к безопасности максимально жесткие, стоит рассмотреть отказ от прямой публикации в пользу VPN (Virtual Private Network). В этом случае порты 1С вообще не смотрят в интернет. Посмотрим, как это работает:
WireGuard или OpenVPN).Этот метод считается наиболее надежным, так как атаковать сервер 1С извне становится физически невозможно без доступа к VPN-ключу.
Подводя итог, можно сказать, что публикация 1С в вебе — это рабочее и удобное решение, но только при соблюдении следующих условий:
Во-первых, обязательное использование HTTPS.
Во-вторых, строгая парольная политика и использование механизмов БСП для контроля попыток входа.
В-третьих, настройка дополнительных барьеров в виде Reverse Proxy или VPN.
Помните, что безопасность — это не результат, а процесс. Регулярно просматривайте Журнал регистрации 1С и логи веб-сервера на предмет попыток несанкционированного доступа.