# Кто может зайти в ваш внутренний сервис? 5 способов закрыться авторизацией

2 июля 2026 г. · 6 мин. чтения

Внутренние сервисы иногда нужно открывать — сотруднику, подрядчику или заказчику. Например, открыть staging, служебную панель, внутреннюю админку или API для интеграций. Или HTTP-сервис без собственной авторизации, вроде Prometheus или Alertmanager.

Возникает задача: не встраивать логин в каждый сервис отдельно, а поставить перед ним слой доступа и решить, кого пускать, каким способом и к каким путям.

Способов решить эту задачу несколько, и каждый хорош для своей ситуации. Разберём от самых простых к более гибким по контролю. В конце — сравнительная таблица.

[Перейти к разделу Приложения в документации](https://tuna.am/docs/apps.md)

![Главная страница приложений](/docs/img/apps/policies_list.png)

## Способ 1. VPN: не выставлять сервис наружу вообще

Классика: сервис живёт в приватной сети, доступ — только через VPN.

![VPN](/blog/img/2026-07-02-apps-access-methods/VPN.webp)

**Когда работает.** В компании уже есть поднятый и поддерживаемый VPN, все пользователи — штатные сотрудники с настроенными клиентами, и никого извне пускать не нужно.

**Ограничения:**

* Контроль на уровне сети, а не на уровне пользователя и пути. Настроить так, чтобы разработчики имели полный доступ, а дизайнеры — только к /dashboards, не получится.
* VPN кто-то должен поднимать и поддерживать.

Избыточен для небольших проектов. Разворачивать всё это ради одной Grafana и пяти человек — стрельба из пушки по воробьям.

## Способ 2. Basic auth: логин-пароль на прокси

Самый быстрый вариант: повесить HTTP basic auth на nginx или прямо на туннель — в Tuna это делается флагом при запуске:

```bash
tuna http 3000 --basic-auth="user:password"

```

![Basic auth](/blog/img/2026-07-02-apps-access-methods/basic_auth.png)

**Когда работает.** Нужно на день-два показать демо заказчику или прикрыть тестовый стенд от случайных глаз и ботов. Одна пара логин-пароль, ноль настройки.

**Ограничения.**

* Не видно, кто заходил. Пароль один на всех, его пересылают в чатах — персональной привязки нет, и вы не узнаете, кто именно был внутри.
* Доступ нельзя отозвать у одного человека — только сменить пароль сразу всем.
* Нет ролей, второго фактора и журнала. Basic auth просто спрашивает пароль, но не дает разграничить права или посмотреть историю входов.

По сути это замок для честных людей: подходит для демо на пару дней, но не для постоянного доступа к админке.

## Способ 3. IP-фильтры: пускать только со своих адресов

Дать доступ списку IP или подсетей на файрволе, в nginx или на туннеле.

![IP filters](/blog/img/2026-07-02-apps-access-methods/ip_filter.png)

**Когда работает.** Доступ нужен из офиса со статическим адресом или с конкретных серверов (мониторинг, CI). Для машинного трафика с известных адресов — нормальное решение.

**Ограничения:**

* Когда люди работают из дома, с мобильного интернета и из поездок, и их адреса меняются.
* Нет персональной привязки. Фильтр отвечает на вопрос, откуда пришли, но не кто пришёл.

## Способ 4. Собрать самому: nginx + oauth2-proxy

Полноценная авторизация перед сервисом без правок его кода: реверс-прокси, перед ним oauth2-proxy, OIDC-провайдер, сертификаты.

![Nginx + oauth2-proxy](/blog/img/2026-07-02-apps-access-methods/OAuth2_Proxy_horizontal.svg)

**Когда работает.** У вас есть DevOps-ресурс, нестандартные требования и желание полностью контролировать каждый слой. Так работают многие инфраструктурные команды.

**Ограничения:**

* Выше порог входа. До запуска нужно связать прокси с провайдером, разобраться с cookie-доменами и редиректами, настроить обновление сертификатов.
* Нужна поддержка. Связку нужно обслуживать и переделывать при каждой смене требований.
* Тонкие правила собираются вручную. Чтобы открыть путь только одной группе пользователей и только с MFA, нужно использовать несколько инструментов.

Для одного-двух внутренних сервисов такие трудозатраты редко окупаются.

## Способ 5. Zero Trust реверс-прокси: готовый слой авторизации

Идея та же, что в способе 4 — проверять каждый запрос до того, как он дойдёт до приложения, — но всю инфраструктуру авторизации берёт на себя готовая платформа. Этот подход называют [Zero Trust](https://en.wikipedia.org/wiki/Zero_trust_architecture). По нему работают корпоративные продукты вроде Cloudflare Access, а в **Tuna** это сервис [Приложения](https://tuna.am/docs/apps/).

![Zero Trust](/docs/img/apps/auth_page.png)

Как это выглядит на практике. Вы создаёте приложение в веб-интерфейсе и описываете правила доступа: какие пути кому открыты, где требовать второй фактор, кого не пускать вовсе. Проверка происходит на стороне Tuna — до вашего сервиса доходят только запросы, прошедшие все правила. В коде приложения ничего менять не нужно.

Несколько вещей, которые в самосборном варианте потребовали бы отдельных инструментов, здесь есть из коробки:

* **разные способы входа под разных людей** — корпоративный SSO для команды (Google, Yandex, GitHub, GitLab, VK или любой OIDC-провайдер) и одноразовый код на email для внешнего подрядчика, которому не нужно заводить аккаунт;
* **правила на уровне путей** — например, служебный `/api/health` оставить открытым для проверок, а всё остальное закрыть; правила комбинируются по email, команде, стране, IP и способу входа;
* **управление доступом** — режим запроса доступа с ручным одобрением (человек объясняет, зачем ему вход, а вы решаете, пускать ли), видимость активных сессий и отзыв доступа в любой момент: в разделе сессий видно, кто сейчас внутри, и любую сессию можно закрыть точечно или все разом;
* **сервисные токены** для CI/CD и мониторинга — машинный трафик ходит отдельно от человеческого и так же подчиняется правилам;
* **журнал и сессии** — в аудит-лог пишется, кто и откуда заходил, кто менял правила и выдавал доступ; видно историю входов и действий администраторов.

Если у сервиса нет публичного IP — он на ноутбуке, за NAT, в закрытом контуре — его можно опубликовать через туннель одной командой:

```bash
tuna app my-service --url=http://127.0.0.1:8080

```

Подробный разбор настройки — в [документации](https://tuna.am/docs/apps/), анонс с обзором возможностей — [в блоге](https://tuna.am/blog/apps/).

**Ограничения:**

* Это решение для веб-сервисов и HTTP API. Доступ к базе данных или SSH-доступ к серверам — отдельные задачи, для них есть [TCP-туннели с IP-фильтрами](https://tuna.am/docs/tunnels/tcp/) и [Бастион](https://tuna.am/docs/bastion/).
* Как любой SaaS, платформа — это внешняя зависимость: если политика компании требует держать контроль доступа строго внутри контура, ваш путь — способ 4.

## Сравнение

|                              | Известен пользователь     | Правила доступа        | MFA            | Отзыв доступа            | Сложность запуска | Поддержка            |
| ---------------------------- | ------------------------- | ---------------------- | -------------- | ------------------------ | ----------------- | -------------------- |
| VPN                          | частично (на уровне сети) | нет                    | зависит от VPN | вручную, профиль         | средняя–высокая   | постоянная           |
| Basic auth                   | нет                       | нет                    | нет            | нельзя точечно           | минуты            | нулевая              |
| IP-фильтры                   | нет (только откуда)       | нет                    | нет            | правкой списка           | минуты            | рутина со списками   |
| nginx + oauth2-proxy         | да                        | да, собирается вручную | да             | вручную                  | дни               | на вашей стороне     |
| Zero Trust proxy (Tuna Apps) | да                        | да, из интерфейса      | да             | в один шаг из интерфейса | минуты            | на стороне платформы |

## Итог: как выбрать

Показываете демо на пару дней → хватит basic auth на туннеле.

Пускаете только серверы и офис со статическим IP → достаточно IP-фильтров.

Вся команда штатная, VPN уже работает и есть кому его обслуживать → оставайтесь на VPN.

Нужен контроль на уровне пользователей и путей, видно, кто заходил, и доступ нужно забирать точечно — но нет ресурса собирать и поддерживать связку прокси с OIDC — берите Zero Trust proxy.

А если требования запрещают выносить авторизацию из своего контура → собирайте способ 4 и закладывайте время на поддержку.

## Попробуйте прямо сейчас

Перейдите в раздел [Приложения](https://my.tuna.am/team_apps), нажмите **+ Добавить приложение** — и закройте свой первый сервис авторизацией за пару минут.

Подробное описание всех возможностей — в [документации](https://tuna.am/docs/apps.md):

* [Политики доступа](https://tuna.am/docs/apps/policies.md)
* [Запросы доступа](https://tuna.am/docs/apps/access_requests.md)
* [Сервисные токены](https://tuna.am/docs/apps/service_tokens.md)
* [Сессии](https://tuna.am/docs/apps/sessions.md)
* [Настройки приложения](https://tuna.am/docs/apps/settings.md)

## Оставьте отзыв

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста [оставьте отзыв](https://my.tuna.am/?show_feedback=1).

![](/blog/img/2024-08-22/feedback.gif)

## Помощь

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

* [Электронная почта](mailto:info@tuna.am)
* [Telegram сообщество](https://telegram.me/+Kgbtt0_gJwI5ZmEy)

**Теги:**

* [apps](https://tuna.am/blog/tags/apps)
* [security](https://tuna.am/blog/tags/security)
* [vpn](https://tuna.am/blog/tags/vpn)
* [reverse-proxy](https://tuna.am/blog/tags/reverse-proxy)