PortiQ публикует веб-приложения компании в интернет. Каждый запрос проходит проверку личности через IdP организации — облачный или локальный — и политику доступа, подписанную самой компанией.
Relay стоит у российского провайдера и передаёт шлюзу зашифрованный поток, не расшифровывая его. Входящие порты и белый IP вам не нужны.
ADFS, Keycloak или другой OIDC-провайдер, с вашей MFA — в облаке или в локальной сети, без публикации в интернет. Пароль видит только IdP, шлюз получает токен.
Группы, MFA, путь, метод, срок действия. Разрешено — шлюз передаёт запрос приложению вместе с личностью пользователя. Нет — отказ и запись в журнал.
Чем PortiQ отличается от привычных способов открыть внутренние сервисы для работы из интернета.
| Что сравниваем | VPN | Проброс порта или reverse proxy | PortiQ |
|---|---|---|---|
| Что получает пользователь | Доступ в сегмент сети | Приложение, открытое всему интернету | Только разрешённые приложения, после входа через ваш IdP |
| Клиент на устройстве | Нужен | Не нужен | Не нужен — достаточно браузера |
| Белый IP и входящие порты в ЦОДе | Нужны для VPN-шлюза | Нужны | Не нужны: шлюз сам подключается к relay |
| Кто видит приложение из интернета | Никто | Все, включая сканеры | Только пользователи, прошедшие вход |
| Подрядчики | Получают доступ в сеть | Входят наравне со всеми | Видят только свои приложения |
| Журнал | Подключения к сети | Журнал веб-сервера | Решение по каждому запросу: кто, куда, по какому правилу |
Подрядчик входит через ваш IdP и видит только GitLab и Jira своего проекта. Доступа во внутреннюю сеть нет, каждый запрос — в журнале.
Grafana, веб-клиент 1С, внутренний портал — после входа через корпоративный IdP, без клиента VPN на ноутбуке.
Код не трогаем: аутентификацию делает шлюз, а приложению передаёт пользователя в заголовке и подписанном JWT.
Сканеры и эксплойты из интернета вообще не доходят до сервиса: без входа запрос останавливается на relay или шлюзе. Уязвимость или ошибку настройки нельзя проэксплуатировать снаружи — обновление ставите без спешки.
Пайплайн предъявляет токен вашего IdP и проходит те же политики и тот же журнал, что и люди. А саму консоль скрипты и интеграции вызывают по API-токенам — с ролью, сроком действия и отзывом в один шаг.
DNS указывает на relay, а шлюз на новой площадке сам подключается к нему. Белый IP не нужен ни в старом ЦОДе, ни в новом, правила на периметре не меняются.
Администраторы и подрядчики заходят на серверы через тот же relay и шлюз, после входа через ваш IdP. Кого и куда пускать, решает подписанная политика — как и для веб-приложений.
Сеанс открывается прямо в браузере, без клиента и ключей на ноутбуке. Привычный ssh-клиент тоже работает — после входа через ваш IdP.
Шлюз выдаёт пользователю короткоживущий сертификат, серверы доверяют УЦ шлюза. Ключи УЦ не покидают ваш периметр.
Сеансы записываются на шлюзе: записи подписаны и связаны в цепочку, срок хранения задаёте вы. Просмотр — только из периметра.
Например, подрядчикам нельзя rm -rf, shutdown и iptables. Запрет срабатывает и в интерактивной оболочке. Можно не запрещать, а разрешать с оповещением. До подписи проверка «что если» покажет, как правило сработает.
Оболочка, exec, передача файлов и проброс портов разрешаются по отдельности. Передача файлов — с журналом имён и размеров.
Пользователь просит доступ к серверу или приложению, ответственный одобряет на странице шлюза. Срок кончился или доступ отозван — сеанс закрывается.
Список открытых сеансов в консоли, обрыв в один клик. Журнал команд — в вашей SIEM.
Другие TCP-сервисы — пробросом порта через тот же SSH-вход, по тем же политикам и с тем же журналом.
Страница входа внутреннего IdP открывается через relay и шлюз — только нужные пути, админ-консоль Keycloak и WS-Trust ADFS закрыты. Доступ к ней ограничивают пять уровней защиты, их можно сочетать. Включение и ослабление защиты — только с подписью вашим ключом.
Страница входа открывается лишь по одноразовому билету, который шлюз выдаёт при переходе из опубликованного приложения. Прямой заход — 404.
Relay отсекает чужие страны, сети и AS ещё до шлюза.
Собственная задача proof-of-work в браузере, без сторонних сервисов.
Страница входа открыта только устройствам, которые пользователь подключил из офиса или по коду администратора.
Без сертификата вашего УЦ или ключа устройства соединение не устанавливается.
Есть служба каталогов — подключим её. Нет ни IdP, ни каталога — дадим свой.
Логин и пароль проверяются в вашем каталоге по LDAPS, группы берутся оттуда же. Второй фактор — TOTP или passkey. Заменять каталог не нужно.
Вход через привычный аккаунт, но только для адресов и доменов из белого списка. Поверх — passkey.
Компании не нужно покупать и внедрять отдельный IdP и службу каталогов ради безопасного доступа. PortiQ IdP закрывает обе задачи: учётные записи сотрудников и единый вход в приложения.
Облако только хранит и раздаёт то, что подписал ваш администратор. Решение о каждом запросе принимает шлюз в вашем периметре.
Relay отсекает лишнее на входе, консоль хранит настройки, а пускать или нет, решает шлюз в вашем периметре. Обойти его нельзя.
Принимает соединения из интернета и отбрасывает чужие имена хостов, флуд и сканеры до шлюза. Трафик не расшифровывает — видит только имя хоста. Поставьте у нескольких провайдеров, и отказ одного не остановит работу.
Проверяет вход через ваш IdP и подписанную политику на каждом запросе. TLS-ключи, сессии и журнал не покидают ваш периметр. Наружу — только исходящие соединения, ни одного открытого порта.
Приложения, политики, узлы и сессии в одном окне. Правила собираются в визуальном конструкторе, а открыть кому-то доступ можно только с подписью вашим ключом.
PortiQ встраивается в то, что у вас уже есть. Четыре типовых подключения — выберите своё.
Учётные записи сотрудников и подрядчиков ведутся в PortiQ IdP, вход — по passkey. Служба каталогов и отдельный IdP не нужны.
PortiQ IdP работает в вашем контуре и входит в базовый тариф. Для быстрого старта — вход через Яндекс ID, VK ID или Сбер ID с белым списком адресов.
Шлюз проверяет логин и пароль прямо в AD по LDAPS и берёт группы оттуда же. Второй фактор — TOTP или passkey, его хранит PortiQ.
Так же подключаются ALD Pro и FreeIPA. Если удобнее, можно поставить Keycloak с федерацией AD — PortiQ работает с ним из коробки.
IdP связан с AD и доступен только из внутренней сети. Шлюз обращается к нему изнутри, а страницу входа для сотрудников вне офиса публикует сам.
Публикуются только пути входа, админ-консоль Keycloak и WS-Trust ADFS закрыты. Доступ к странице входа ограничивают уровни защиты: билет через приложение, фильтр по источнику, проверка на бота, известные и корпоративные устройства.
Relay у двух-трёх провайдеров под их Anti-DDoS, шлюз в DMZ, за ним — ваш WAF и приложения. Вход — через корпоративный IdP, журнал решений — в ваш SIEM.
Ваш WAF стоит за шлюзом: туда приходят уже расшифрованные запросы и только от вошедших пользователей. Как опцию WAF можно включить и у Anti-DDoS-провайдера — тогда провайдер расшифровывает трафик до relay, а шлюзу нужен свой сертификат вместо автоматического. Отказ одного relay или провайдера не останавливает доступ.
Docker или systemd-служба рядом с приложениями. Подключается к консоли по одноразовому токену.
Контейнер на VPS у российского провайдера, можно у нескольких. Управляется через шлюз.
ADFS, Keycloak или другой OIDC-провайдер, облачный или локальный. Если IdP доступен только изнутри — включаете публикацию страницы входа.
Внешнее имя и внутренний адрес. В DNS — CNAME на пул relay.
Кто и к чему получает доступ. Подписываете своим ключом на экране шлюза — правило вступает в силу.
Да. Шлюз обращается к IdP изнутри периметра, а страницу входа для сотрудников вне офиса публикует сам — только нужные пути и с уровнями защиты. Выставлять ADFS или Keycloak в интернет не придётся.
Шлюз продолжает работать на последней валидной конфигурации, доступ к приложениям сохраняется. Изменения политик и обновления дождутся восстановления связи.
Поставьте relay у двух-трёх провайдеров. Имя приложения указывает на их пул, неработающий relay автоматически исключается из DNS. Соединения через него оборвутся, новые пойдут через остальные.
Нет. TLS расшифровывает только ваш шлюз, relay видит лишь имя хоста. Пользователь входит напрямую в ваш IdP. С опцией «IdP внутри периметра» пароль проходит через шлюз транзитом: шлюз его не хранит, не разбирает и не журналирует.
Код не трогаем. Шлюз передаёт приложению пользователя в заголовке и подписанном JWT, а если внутреннее имя отличается от внешнего — переписывает редиректы и cookie. Иногда в настройках приложения нужно указать внешний адрес.
Веб-приложения и API: HTTP/1.1, HTTP/2, WebSocket, git по HTTPS — для них пользователю нужен только браузер: Chrome, Яндекс Браузер и другие на базе Chromium, Firefox или Safari. Кроме того, через PortiQ публикуются TCP-сервисы и SSH.
Покажем PortiQ на ваших приложениях и вашем IdP: от первой встречи до работающего доступа без VPN и белых IP.