Политики доступа
This section is available to the Founder, Owners and Administrators.
Политики — это сердце системы контроля доступа в приложениях. Каждый входящий запрос проходит через цепочку политик, и первая политика, чей шаблон пути совпал, определяет судьбу запроса: пропустить, потребовать MFA, запросить одобрение или отказать.
По умолчанию доступ запрещён — если ни одна политика не совпала, запрос будет отклонён.
Как устроена политика
Каждая политика задаётся тремя ключевыми параметрами:
| Параметр | Описание |
|---|---|
| Имя | Понятное название — «Admin panel», «Public API», «Monitoring» |
| Паттерн пути | Glob-шаблон URL-пути: * — все пути, /admin/* — всё внутри /admin/ |
| Действие | Что произойдёт, если путь совпал |
Действия
Разрешить — пользователь получит доступ, если пройдёт проверк у правил. Самое частое действие.
Требовать MFA — работает как «Разрешить», но дополнительно потребует подтверждение вторым фактором (TOTP-приложение или код на email). Используйте для чувствительных разделов — финансы, удаление данных, управление пользователями.
Запретить — безусловная блокировка. Правила даже не проверяются — запрос отклоняется сразу. Это полезно, когда нужно закрыть путь для всех, а затем создать allow-политику с более высоким приоритетом для избранных.
Пропустить — путь доступен вообще без аутентификации. Страница входа не показывается. Типичные кандидаты: health check, webhook-эндпоинты, публичные API.
Дополнительные параметры
- Длительность сессии — можно задать свой TTL сессии для конкретной политики, отличный от общего у приложения.
- Активна — выключенная политика сохраняется, но пропускается при оценке. Удобно для временного отключения без удаления.
- Требовать одобрение администратора — перед получением доступа пользователь заполнит форму с причиной запроса, а администратор вручную одобрит или отклонит. Подробнее — в разделе Запросы доступа.
Правила
Внутри каждой политики с действием «Разрешить» или «Требовать MFA» настраиваются правила — они определяют, кто именно получит доступ.
Режимы правил
Правила группируются по режимам, и режимы комбинируются между собой:
| Режим | Логика | Что значит |
|---|---|---|
| Любое (or) | OR | Достаточно совпадения хотя бы одного правила |
| Все (and) | AND | Должны совпасть все правила одновременно |
| Исключить | NOT | Если хоть одно правило совпало — доступ запрещён |
Доступ предоставляется, когда: совпало хотя бы одно Любое, совпали все Все, и ни одно Исключить не сработало.
Типы правил
| Тип | Описание | Пример значения |
|---|---|---|
| Команда | Все активные участники команды | — |
| Конкретный email-адрес | alice@company.com | |
| Email RegExp | Регулярное выражение по email | .*@company\.com$ |
| Service Token | Машинная аутентификация по сервисному токену | Client ID |
| IP / CIDR | IP-адрес или подсеть | 10.0.0.0/8 |
| Способ входа | Метод аутентификации | oidc, otp, mfa |
| Провайдер | Конкретный Identity Provider | google, * |
| Страна | ISO-код страны (определяется по GeoIP) | RU, US, DE |
Пример
Допустим, вы хотите, чтобы к /admin/* имели доступ только участники команды, и только из России. Создайте политику:
- Имя: admin
- Паттерн:
/admin/* - Действие: Разрешить
- Правила:
- Любое (or): Команда — все участники
- Все (and): Страна —
RU
Результат: чтобы попасть в админку, нужно быть участником команды и заходить из России.
Приоритет и порядок
Политики оцениваются сверху вниз по номеру — чем меньше номер, тем выше приоритет. Как только путь запроса совпал с шаблоном политики, она применяется и остальн ые не проверяются.
Порядок можно менять перетаскиванием в интерфейсе.
При создании приложения автоматически создаётся политика Default с паттерном * и наименьшим приоритетом. Она отвечает за все пути, не покрытые другими политиками. Удалять её не рекомендуется — без неё все непокрытые пути будут молча отклоняться.
Обзор
Блок Обзор на странице деталей визуализирует полную картину: кто входит, через какие политики проходит и куда попадает.
Тестирование политик
Прежде чем применять конфигурацию, её можно проверить. Инструмент Тест политик позволяет смоделировать запрос с любыми параметрами — email, страна, IP, метод входа, статус MFA — и увидеть, какое решение примет система.
Результат покажет, какая политика совпала, какие правила сработали и итоговое решение. Тестер не создаёт реальных сессий — это безопасный способ отладки.