Как организовать безопасный доступ к 1С через веб-сервис с двухфакторной аутентификацией и внешним сервером?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Организация безопасного доступа к внутренним ресурсам 1С из внешней сети — это комплексная задача, требующая баланса между удобством пользователя и жесткими требованиями безопасности. Рассмотрим ситуацию, когда необходимо вынести веб-сервисы 1С во «внешний мир», обеспечив при этом надежную авторизацию, включая двухфакторную проверку (2FA) через СМС или другие каналы, минуя необходимость предварительного входа на рабочее место по VPN или RDP.

В данной статье мы разберем несколько проверенных архитектурных решений: от тонкой настройки Nginx для управления сессиями до использования современных протоколов авторизации и программных методов внутри самой платформы 1С.

Решение 1: Использование Nginx в качестве реверс-прокси с подменой данных авторизации

Проанализируем метод, при котором внешний сервер на базе Linux (CentOS/Ubuntu) выступает в роли «защитного экрана». Основная идея заключается в том, что пользователь сначала проходит авторизацию на веб-странице внешнего сервера, а затем Nginx прозрачно для пользователя передает учетные данные в 1С.

Для реализации этого механизма можно использовать модуль rewrite и сопоставление пользователей через map. Это позволяет скрыть реальные пароли базы данных 1С и использовать единую точку входа. Разберем пример настройки конфигурационного файла Nginx:


# Определяем соответствие внешнего логина и закодированных данных (Base64) для 1С
map $remote_user $cred {
    'ivanov' 'aXZhbm92OnBhc3N3b3JkMTIz'; # base64 от 'логин:пароль'
    'petrov' 'cGV0cm92OnN1cGVyc2VjcmV0';
}

server {
    listen 443 ssl;
    server_name 1c-external.company.com;

    # Настройка авторизации на уровне веб-сервера
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        # Перехватываем запрос к форме логина и добавляем параметр cred
        rewrite ^(/.*/e1cib/login)(.*)$ $1?cred=$cred break;

        proxy_pass http://internal-1c-server.local;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # Важные параметры для стабильности веб-клиента 1С
        proxy_buffering off;
        keepalive_timeout 600;
    }
}

Рассмотрим подробнее, как это работает. Когда пользователь обращается к веб-клиенту, 1С пытается перенаправить его на страницу /e1cib/login. В этот момент Nginx перехватывает запрос и добавляет в URL параметр cred, содержащий строку авторизации. Платформа 1С умеет считывать этот параметр и автоматически авторизовать пользователя, не показывая стандартное окно ввода логина и пароля.

Важное замечание: Передача данных в URL-строке (даже в Base64) может логироваться сервером. Для повышения безопасности рекомендуется использовать передачу заголовка Authorization: Basic через директиву proxy_set_header, если авторизация на внешнем и внутреннем серверах совпадает.

Решение 2: Двухфакторная аутентификация на уровне платформы 1С

Выясним, как использовать встроенные возможности 1С для реализации 2FA. Начиная с версии платформы 8.3, разработчики добавили штатные механизмы двухфакторной аутентификации. Настроить их можно в свойствах пользователя в режиме Конфигуратор или через управление пользователями в интерфейсе программы.

Однако, если стандартный функционал (например, в старых версиях «Документооборота») не подходит, мы можем реализовать собственную логику в модуле управляемого приложения. Рассмотрим алгоритм действий:

  1. Используем событие ПередНачаломРаботыСистемы.
  2. В этом событии проверяем, включена ли для текущего пользователя двухфакторная проверка.
  3. Генерируем случайный код (например, 6 цифр) и отправляем его через внешний сервис (SMS-шлюз, Telegram-бот или электронную почту).
  4. Открываем модальное (или блокирующее весь интерфейс) окно для ввода полученного кода.
  5. Если код введен верно, продолжаем работу, иначе — завершаем сеанс командой Отказ = Истина;.

Пример программного кода для реализации такой проверки:


Процедура ПередНачаломРаботыСистемы(Отказ)
    
    // Проверяем, что это веб-клиент или тонкий клиент через интернет
    Если ИмяПрограммы() = "WebClient" Или Найти(СтрокаСоединенияИнформационнойБазы(), "ws=") > 0 Тогда
        
        КодПодтверждения = СгенерироватьСлучайныйКод();
        ОтправитьКодПользователю(ПользователиИнформационнойБазы.ТекущийПользователь(), КодПодтверждения);
        
        ПараметрыФормы = Новый Структура("ЭталонныйКод", КодПодтверждения);
        Результат = ОткрытьФормуМодально("ОбщаяФорма.ФормаВводаКода2FA", ПараметрыФормы);
        
        Если Результат <> Истина Тогда
            Отказ = Истина;
            Сообщить("Ошибка авторизации: код не подтвержден.");
        КонецЕсли;
        
    КонецЕсли;

КонецПроцедуры

Посмотрим на преимущества этого метода: он не требует сложной настройки системного окружения и работает непосредственно в логике 1С. Однако помните, что для веб-клиента использование модальных окон требует правильной настройки свойства конфигурации РежимИспользованияМодальности.

Решение 3: Современный подход через OpenID Connect и Keycloak

Проанализируем наиболее современный и безопасный способ, который часто требует служба безопасности в крупных компаниях. Вместо того чтобы «пробрасывать» пароли, мы можем использовать внешний сервис идентификации (Identity Provider), такой как Keycloak.

Алгоритм работы в этой схеме следующий:

  1. В DMZ (внешнем контуре) разворачивается сервер Keycloak.
  2. В нем настраиваются правила авторизации, включая обязательный OTP (One-Time Password) через мобильное приложение (Google Authenticator) или СМС.
  3. В 1С настраивается использование OpenID Connect.
  4. При попытке входа 1С сама перенаправляет пользователя на защищенную страницу Keycloak.
  5. После успешного ввода пароля и второго фактора Keycloak возвращает в 1С подтверждающий токен.

Этот метод исключает хранение и передачу паролей 1С через интернет. Платформа 1С (начиная с 8.3.18+) поддерживает этот протокол «из коробки» в настройках публикации на веб-сервере.

Решение 4: Защита на уровне веб-сервера и сертификатов (mTLS)

Если ваша задача — максимально ограничить круг лиц, имеющих доступ к веб-сервису, разберем метод двустороннего TLS (mTLS). Это решение часто называют «вариантом для параноиков», так как оно предотвращает любую попытку соединения, если у пользователя не установлен специальный сертификат.

Для этого в конфигурации Nginx на внешнем сервере необходимо включить проверку клиентских сертификатов:


server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # Включаем проверку клиентского сертификата
    ssl_client_certificate /etc/nginx/ssl/ca.crt;
    ssl_verify_client on;

    location / {
        if ($ssl_client_verify != SUCCESS) {
            return 403;
        }
        proxy_pass http://internal-1c-server.local;
    }
}

При такой настройке, даже если злоумышленник узнает логин и пароль от 1С, он не сможет даже увидеть форму входа, так как Nginx разорвет соединение на этапе SSL-handshake без наличия доверенного сертификата в браузере клиента.

Дополнительные рекомендации по безопасности и оптимизации

При выносе 1С во внешнюю среду крайне важно выполнить ряд технических настроек на веб-сервере, чтобы избежать утечек данных и проблем с производительностью:

Подводя итог, выбор конкретного метода зависит от ваших ресурсов и требований безопасности. Для быстрой реализации подойдет настройка Nginx с параметром cred или использование события ПередНачаломРаботыСистемы. Для построения долгосрочной и масштабируемой системы лучше смотреть в сторону OpenID Connect и Keycloak.

← На главную