Nginx, Keycloak, Active Directory и отдельный IIS: выносим второй фактор во внешний контур и сохраняем интеграции

Веб-клиент 1С удобен тем, что для работы достаточно браузера. Но когда публикация становится доступной из внешних сетей, возникает вопрос: как добавить второй фактор, не меняя аутентификацию самой 1С и не нарушая работу существующих интеграций?

В статье рассказываем, как мы вынесли проверку MFA во внешний контур на Nginx и Keycloak, сохранили Active Directory как источник учётных записей и оставили интеграциям привычные точки входа.

Исходная задача: один IIS для пользователей и интеграций

До изменений сотрудники открывали 1С через веб-публикацию на IIS. Тот же IIS обслуживал внешние интеграции: автоматизированные обмены, HTTP-сервисы и обращения сторонних систем. 

Заказчику нужно было добавить MFA для сотрудников, работающих через браузер, и при этом выполнить несколько принципиальных требований:

• не использовать 1С OpenID Authentication;

• сохранить Active Directory как источник пользовательских учётных записей;

• не ломать действующие интеграции на существующем IIS;

• по возможности оставить сотрудникам привычный сценарий запуска веб-клиента.

Просто включить интерактивную MFA-проверку на общей точке входа было рискованно: автоматические запросы интеграций вместо ожидаемого ответа могли получить перенаправление на страницу авторизации.

Поэтому первым делом мы разделили два потока: сотрудники заходили через шлюз с MFA, а внешние системы продолжали обращаться к своим точкам входа с разрешённых IP-адресов.

Архитектура: новый IIS для пользователей, прежний — для интеграций

На тестовом стенде развернули три виртуальные машины. Существующий IIS не переносили и не демонтировали: он продолжил обслуживать интеграционные подключения. Для сотрудников подготовили отдельную веб-публикацию 1С на новом IIS.

Рисунок 1. Логическая схема пользовательского и интеграционного контуров.

Зачем здесь oauth2-proxy

В нашей схеме Nginx отвечает за HTTPS, маршрутизацию и проверку результата авторизации, а oauth2-proxy выполняет OIDC-обмен с Keycloak. Оба сервиса размещены на одной Linux-ВМ. Отдельная, четвёртая виртуальная машина не нужна.

Как происходит вход от браузера до веб-клиента 1С

1. Сотрудник открывает публичный HTTPS-адрес веб-публикации, например https://1c.example.ru.

2. Запрос приходит на Nginx. Через oauth2-proxy шлюз проверяет, есть ли действующая сессия внешней аутентификации.

3. Если сессии нет, oauth2-proxy запускает OIDC-сценарий и перенаправляет браузер в Keycloak.

4. Keycloak проверяет учётные данные пользователя через Active Directory и запускает настроенный второй фактор. Например, ввод одноразового TOTP-кода из приложения-аутентификатора.

5. После успешной проверки Keycloak возвращает браузер на callback oauth2-proxy. Тот создаёт сессию внешней аутентификации, после чего Nginx пропускает запрос на новый IIS.

6. Дальше веб-клиент работает с 1С через штатную публикацию. Авторизация внутри информационной базы остаётся отдельным уровнем.

MFA на шлюзе и вход в 1С — разные проверки

MFA на шлюзе подтверждает право доступа к веб-публикации, но не создаёт пользовательскую сессию внутри 1С. Поскольку 1С OpenID Authentication не внедряли, автоматического входа в информационную базу после MFA здесь нет, штатная авторизация 1С продолжает работать по правилам заказчика.

Keycloak и Active Directory: кому разрешён доступ через MFA

Чтобы не сопровождать отдельную базу пользователей только для внешней веб-публикации, мы связали Keycloak с корпоративным Active Directory. Для защищённого ресурса выделили отдельную группу, например 1C_Web_2FA. Это позволяет управлять допуском централизованно: добавление пользователя в группу открывает ему доступ через шлюз, а удаление закрывает доступ после синхронизации данных и истечения или отзыва действующей сессии.

Что настроили в Keycloak:

• отдельный realm, например 1c-web;

• федерацию пользователей с AD через LDAPS;

• OIDC-клиент для шлюза, например nginx-1c;

• точный redirect URI, например https://1c.example.ru/oauth2/callback;

• передачу членства в группах в OIDC-токен и ограничение доступа группой 1C_Web_2FA;

• обязательный второй фактор по выбранной политике;

• сроки действия сессий, политику повторного входа и процедуру восстановления MFA.

В качестве второго фактора подходит TOTP, одноразовый код из приложения-аутентификатора. Алгоритм, длину кода, период его действия и допустимое отклонение времени важно зафиксировать в политике организации, настроить в Keycloak и учесть в пользовательских инструкциях.

Одного создания группы в AD недостаточно. Нужно проверить, что Keycloak передаёт её в claim groups OIDC-токена, а oauth2-proxy действительно запрещает доступ тем, кто не входит в разрешённую группу. Если передаётся полный путь группы, это должно совпадать со значением allowed_groups. Названия настроек могут различаться между версиями Keycloak.

Техническая связка Nginx и Keycloak через oauth2-proxy

Ниже референсный пример интеграции. Он показывает механику, но не является готовым production-конфигом. Сертификаты, домены, версии компонентов, настройки cookie, тайм-ауты и маршруты нужно адаптировать и проверить на своём стенде. Предполагается, что oauth2-proxy слушает только loopback-интерфейс 127.0.0.1:4180, а новая публикация IIS доступна Nginx по внутреннему адресу 10.10.10.30.

Оauth2-proxy: OIDC-клиент и проверка доступа по группе

provider = "keycloak-oidc"oidc_issuer_url = "https://sso.example.ru/realms/1c-web"client_id = "nginx-1c"client_secret = "REPLACE_WITH_SECRET"redirect_url = "https://1c.example.ru/oauth2/callback" http_address = "127.0.0.1:4180"reverse_proxy = trueupstreams = ["static://202"] # Ограничение допуска: группа должна быть передана в OIDC-токене.email_domains = ["example.ru"]allowed_groups = ["/1C_Web_2FA"]scope = "openid profile email groups"set_xauthrequest = true cookie_secure = truecookie_httponly = truecookie_samesite = "lax"cookie_secret = "REPLACE_WITH_BASE64_SECRET"# Срок действия cookie задайте по принятой политике сессий.

Для такой конфигурации в Keycloak понадобится confidential OIDC-клиент с точно заданным callback. Чтобы работали allowed_groups и scope groups, нужно настроить передачу групп в токен и проверить, что claim groups содержит ожидаемое значение. Секреты нельзя хранить в открытом репозитории: файл конфигурации должен быть доступен только сервисной учётной записи и администраторам.

Nginx: проверяем сессию перед передачей запроса в IIS

server {listen 443 ssl;server_name 1c.example.ru; ssl_certificate /etc/nginx/tls/fullchain.pem;ssl_certificate_key /etc/nginx/tls/privkey.pem; # OAuth2 Proxy: начало входа и callback от Keycloaklocation /oauth2/ {    proxy_pass http://127.0.0.1:4180;    proxy_set_header Host          $host;    proxy_set_header X-Real-IP     $remote_addr;    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;    proxy_set_header X-Forwarded-Proto $scheme;    proxy_set_header X-Auth-Request-Redirect $request_uri;} # Внутренняя проверка действующей сессииlocation = /oauth2/auth {    proxy_pass http://127.0.0.1:4180/oauth2/auth;    proxy_set_header Host          $host;    proxy_set_header X-Real-IP     $remote_addr;    proxy_set_header X-Scheme      $scheme;    proxy_set_header X-Auth-Request-Redirect $request_uri;    proxy_pass_request_body off;    proxy_set_header Content-Length "";} # Защищённая пользовательская веб-публикация 1Сlocation / {    auth_request /oauth2/auth;    error_page 401 = @oauth2_signin;     proxy_pass http://10.10.10.30;    proxy_http_version 1.1;    proxy_set_header Host          $host;    proxy_set_header X-Real-IP     $remote_addr;    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;    proxy_set_header X-Forwarded-Proto https;     # Настройте под размер файлов и длительность операций 1С.    client_max_body_size 128m;    proxy_read_timeout 600s;    proxy_send_timeout 600s;} location @oauth2_signin {    return 302 /oauth2/start?rd=scheme://host$request_uri;}}

Директива auth_request пропускает запрос, если проверяющий сервис вернул 2xx. Ответы 401 и 403 означают отказ, причём в приведённой конфигурации при 401 браузер перенаправляется на процедуру входа. Для этой схемы в сборке Nginx необходим модуль ngx_http_auth_request_module, наличие которого лучше проверить заранее.

Новый IIS доступен по внутреннему адресу, который нельзя публиковать напрямую в интернет. Межсетевой экран должен разрешать обращения к пользовательской публикации только от Nginx, иначе MFA можно обойти прямым запросом. В примере соединение Nginx с IIS идёт по HTTP: в рабочей среде нужно отдельно оценить требования к защите трафика между узлами и при необходимости использовать TLS.

Почему заголовок с логином не заменяет авторизацию в 1С

При работе с обратным прокси возникает соблазн передать имя пользователя из OIDC-токена в заголовке X-Forwarded-User или сформировать HTTP Basic Authorization и считать, что вход в 1С уже выполнен. Но это не работает автоматически: веб-сервер и платформа должны поддерживать и явно использовать такой механизм доверия и сопоставления учётных записей.

Поэтому наш пример решает конкретную задачу — ставит MFA перед доступом к веб-публикации. Он не передаёт пароль 1С и не подменяет штатную авторизацию в информационной базе. Если нужен единый вход без повторной проверки пользователя внутри 1С, это отдельная интеграционная задача. Её следует решать поддерживаемыми механизмами, а не произвольными HTTP-заголовками.

Массовое подключение: AD-группа, пароли и инструкции для пользователей

Для подключения подготовили список сотрудников заказчика и выделили отдельную группу AD для тех, кому требовался доступ через MFA. Кроме того, автоматизировали подготовку учётных данных с генерацией случайных паролей и рассылку данных и инструкций для первого входа и настройки второго фактора.

При массовом подключении главное — не превратить автоматизацию в дополнительный канал утечки:

• временные пароли должны быть случайными, достаточно длинными и иметь ограниченный срок действия либо требовать смены при первом входе;

• пароль и секрет TOTP не следует передавать одним сообщением или по одному и тому же каналу;

• QR-код для TOTP безопаснее формировать в пользовательском сценарии регистрации, а не хранить в обычной рассылке;

• выгрузки и служебные файлы с учётными данными должны храниться в каталоге с минимальными правами доступа и удаляться после завершения процедуры;

• для потерянного телефона, замены устройства и увольнения сотрудника нужны понятные процедуры сброса MFA и отзыва доступа.

Отдельная группа AD упрощает централизованное управление доступом, но не заменяет отзыв активных сессий. После блокировки учётной записи или удаления пользователя из группы нужно проверить, когда изменение становится известно Keycloak и oauth2-proxy, и при необходимости отозвать уже выданные сессии.

Как сохранили интеграции без интерактивной MFA

Существующий IIS мы сохранили как точку входа для интеграций. Вместо того чтобы отправлять автоматические запросы на интерактивную MFA-проверку, ограничили подключения списком разрешённых IP-адресов. Пользовательская публикация при этом работает на другом IIS и доступна через Nginx.

Ниже пример ограничения доступа по IP в IIS. Адреса тестовые, но в рабочей конфигурации нужны адреса реальных интеграционных систем. Правило следует применять только к соответствующему сайту или приложению IIS и проверять вместе с существующими настройками доступа.

<configuration>  <system.webServer><security>  <ipSecurity allowUnlisted="false">    <clear />    <add ipAddress="10.10.20.50" allowed="true" />    <add ipAddress="10.10.20.51" allowed="true" />  </ipSecurity></security>  </system.webServer></configuration>

Список разрешённых IP-адресов — не замена аутентификации. Интеграциям по-прежнему нужны сервисные учётные записи или другой подходящий способ проверки клиента, минимальные права, защищённые соединения и контроль доступных HTTP-сервисов. Если сетевой маршрут меняется, проверяйте, какой IP фактически видит IIS: это может быть адрес NAT или промежуточного прокси.

Как сохранили запуск веб-клиента с рабочего стола

Оставался вопрос удобства. Сотрудники привыкли запускать 1С с рабочего стола и не хотели каждый раз искать нужную вкладку. Веб-публикацию можно установить как отдельное браузерное приложение. Например, средствами Chrome или Яндекс Браузера. В таком случае это будет выглядеть так:

• на рабочем столе появляется ярлык;

• веб-клиент открывается в отдельном окне без привычной панели вкладок;

• пользователь продолжает работать именно с веб-клиентом, а не со стандартным тонким клиентом;

• правила внешней аутентификации и повторного входа через MFA продолжают действовать.

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

Границы решения и проверки перед запуском

У решения есть чёткая граница: в описанной конфигурации MFA защищает именно браузерный вход в веб-клиент. На обычный тонкий клиент этот сценарий автоматически не распространяется. При этом тонкий клиент 1С тоже может подключаться к информационной базе через веб-сервер по HTTP(S), просто он не проходит тот же браузерный OIDC-сценарий, поэтому его защиту нужно проектировать и тестировать отдельно.

Перед промышленным запуском мы бы проверили как минимум следующее:

• к новой публикации на IIS нельзя обратиться из внешней или пользовательской сети в обход Nginx;

• Nginx и oauth2-proxy корректно обрабатывают callback, cookie, редиректы и завершение сессии;

• пользователь вне разрешённой группы AD не получает доступ;

• секреты OIDC-клиента и cookie защищены правами файлов и не попадают в репозиторий/логи;

• административная консоль Keycloak и служебные порты недоступны из интернета без необходимости;

• входы, отказы, блокировки и ошибки шлюза журналируются и попадают в мониторинг;

• есть процедура восстановления второго фактора и аварийного отзыва пользовательских сессий;

• для Nginx, oauth2-proxy и Keycloak предусмотрены обновления, резервное копирование и восстановление;

• проверены долгие операции, загрузка/выгрузка файлов и тайм-ауты веб-клиента 1С.

Главный риск — прямой доступ к IIS в обход MFA

Если новую веб-публикацию можно открыть напрямую на IIS, проверка MFA на Nginx перестаёт быть обязательной. Сетевые ограничения, отсутствие прямой публикации IIS и контроль доверенных заголовков — необходимая часть архитектуры, а не дополнительная оптимизация.

Добавили MFA и разделили зоны ответственности

Главный технический результат заключается в том, что второй фактор появился перед веб-публикацией 1С без изменения её штатного механизма аутентификации и без вмешательства в интеграционный контур. Но MFA защищает именно доступ через внешний шлюз, который не заменяет авторизацию и разграничение прав в 1С, не распространяется автоматически на тонкий клиент и требует закрыть прямой доступ к новому IIS.

Для бизнеса у такого разделения тоже есть практическая польза: не пришлось перестраивать работу 1С и её интеграций, а задачи получилось распределить между командами. 

Теперь провайдер и специалисты ИБ отвечают за внешний шлюз и MFA, команда 1С – за учётные записи и права внутри информационной базы. Новым сотрудникам проще выдавать доступ через AD, а при увольнении или смене роли можно оперативно закрыть вход через шлюз. При этом активные внешние сессии нужно отзывать отдельно, а блокировку доступа в самой 1С контролировать по внутренним правилам.