Условный доступ нельзя управлять простым списком разрешений
Современное решение о доступе больше не сводится только к вопросу «верно ли имя пользователя?». Правильное решение должно учитывать вместе идентичность пользователя, состояние доверия устройства, локацию, время, чувствительность запрашиваемого сервиса, требуемый уровень MFA и изменения риска внутри сессии.
Статические правила и плоские списки разрешений не способны нести эту сложность. Со временем каждое исключение становится новым правилом, каждое приложение — новым особым случаем, каждый сигнал риска — отдельной контрольной точкой. Результат — нагромождение политик, которое никто не может прочитать от начала до конца и которое нельзя ясно объяснить при аудите, почему оно разрешает или почему отклоняет.
Некоторые решения переносят это решение в отдельное облако политик. Это делает самый критический момент аутентификации зависимым от внешнего API. Когда идентичность, MFA, маршрутизация сервисов и аудит распределены по разным системам, путь доступа становится невидимым; организация видит только результат, а не то, как сформировалось решение.
А ведь условный доступ должен быть единым движком решений, работающим рядом с вашими идентичностями и сервисами. Каждый шаг должен быть видимым, каждое условие — объяснимым, каждое решение — поддающимся аудиту.
Потому что безопасность доступа связана не только с тем, кто вошёл; но и с тем, в каком контексте, с какой силой проверки и на каком основании был предоставлен доступ.
Наш подход
Движок потоков, владеющий аутентификацией, MFA, решениями и маршрутизацией в едином определении на основе сервисов.
Каждый сервис запускает собственный поток доступа
Поток доступа сцепляет login, MFA, точки принятия решений, switch'и, управление lockout и терминалы access-granted/denied. Каждый сервис объявляет собственный поток; низкорисковое intranet-приложение остаётся простым, привилегированный административный путь остаётся строгим — без принуждения обоих к одной форме.
Ветвление на основе паттернов по любой переменной
Узлы switch маршрутизируют по любой переменной, видимой потоку — свойства сессии, заголовки запроса, оценённые шаблоны, upstream-сигналы с вашего edge — с пятью режимами сопоставления (exact, prefix, suffix, contains, regex) и опциональным case-insensitive вариантом. Решения выражаются как сопоставление паттернов, а не как скрипт.
Сигналы с edge включаются в поток
Географическая локация, репутация IP, оценка риска, сетевая зона — всё, что может вычислить ваш edge, может быть внедрено как заголовок запроса и прочитано узлом switch или точкой принятия решений. Поток остаётся единым источником; сигналы извне шлюза питают поток, не вставляя внешний сервис в путь аутентификации.
Каждый переход в логе аудита
Каждая оценка действия — какой шаг сработал, каким был вход, какая ветвь выбрана, какой терминал достигнут — попадает в структурированный поток аудита. Операторы пошагово воспроизводят сессии; команды безопасности соотносят решения о доступе с остальной телеметрией через SIEM streaming.
Возможности
Движок потоков в деталях, строительные блоки, образующие правила политики, и запланированные дополнения для их расширения.
Движок потоков — единая цепочка для auth, MFA, решений и маршрутизации
Один движок оркестрирует login, многофакторный challenge, управление lockout, точки принятия решений, маршрутизацию switch и терминалы access-granted / access-denied. Каждый шаг — это действие с явными переходами; путь от анонимного запроса к аутентифицированной сессии — это составной граф, а не разрозненная конфигурация.
Определение потока на основе сервисов
Каждый сервис регистрирует собственное определение потока. SaaS proxy может требовать только SSO; внутреннее приложение может добавить TOTP; продакшн-система может сцепить TOTP плюс свежий OTP плюс явную точку принятия решений. Изменение политики одного сервиса не влияет на другие.
Switch — многопутевая маршрутизация по сопоставлению паттернов
Действие switch оценивает настраиваемую переменную (заголовок, свойство сессии, шаблон AAM) и, сопоставляя поток с упорядоченным списком паттернов, маршрутизирует к целевому действию. Пять режимов сопоставления — exact, prefix, suffix, contains, regex — вместе с опциональным case-insensitive; покрывает всё, от проверки роли до regex-сопоставления по пути запроса.
Точки принятия решений для ветвления да/нет
Действия DecisionPoint делят поток на два пути в зависимости от наличия или отсутствия структурированного сигнала. Сегодня сигнал — это заголовок запроса, устанавливаемый вашим edge (CDN, upstream-модуль политик или сетевой шлюз); поверхность действия держит структуру потока стабильной, а нижележащее условие развивается для оценки более богатых выражений.
Шаблонные переменные AAM в условиях
Переменные, встроенные в конфигурацию потока — идентичность пользователя, членство в группах, id сервиса, окружение, пользовательские свойства сессии — разрешаются в момент оценки через движок шаблонов AAM. Тот же синтаксис шаблонов, используемый в брендинге, маршрутизации и сообщениях об ошибках, движет и решениями политики; операторы изучают единый язык подстановки и используют его везде.
Step-up и цепочка MFA, управляемые потоком
Поскольку MFA — это действие внутри того же потока, условный доступ может требовать второй фактор только в определённых ветвях — например, switch может запросить TOTP при обнаружении роли admin, или сцепить TOTP плюс свежий OTP, когда маршрут достигает высокочувствительного терминала. Повышение живёт в политике, а не в восприятии пользователя.
Операционная глубина
Механика, обеспечивающая безопасное развёртывание и лёгкий аудит изменений политики.
Пошаговый аудит с входом и результатом
Каждая оценка действия в потоке записывает структурированную запись аудита — id действия, тип действия, входные переменные, выбранная ветвь, достигнутый терминал, задержка. Сессии воспроизводятся пошагово в едином представлении временной шкалы, вместо реконструкции из разрозненных логов.
Координированное stateless-исполнение потоков через Redis
Состояние потока живёт в Redis; так любой экземпляр шлюза может подхватить любую сессию на любом шаге. Горизонтальное масштабирование и rolling upgrade без простоя не теряют текущее состояние аутентификации; операторы могут запускать несколько pod'ов шлюза за балансировщиком нагрузки без накладных расходов на координацию.
Координированная блокировка по всему потоку
Неуспешные попытки фактора, отклонённые MFA-challenge'и и терминалы access-denied питают те же счётчики блокировки, что использует слой login-attack-protection платформы. Пользователь не может проводить brute-force неуспешного фактора, повторяя его, пока ветвь switch ждёт параллельную попытку на другом шаге.
Версионированная конфигурация потоков
Определения потоков живут в JSON-конфигурации, доставляемой шлюзу; изменения конфигурации могут поэтапно развёртываться, проверяться и распространяться на каждое окружение. Сочетание версионированной конфигурации и пошагового аудита делает вопрос «почему этот пользователь вошёл вчера?» отвечаемым из единого источника.
В каких сценариях используется
Навязывание MFA на основе сервисов
Тот же движок потоков, что аутентифицирует пользователя, решает, требует ли определённый сервис MFA, какой фактор будет применён и действителен ли ярлык доверенного устройства. Политика MFA — это не отдельный продукт, а узел в потоке доступа этого сервиса.
Доступ с учётом geo и репутации IP
Edge-компоненты (CDN, feed'ы репутации IP, сетевой шлюз) внедряют географические и репутационные заголовки; узлы switch и точки принятия решений потока ветвятся по этим сигналам — например, отклоняют входы из известных вредоносных сетей или направляют высокорисковые регионы в более строгие цепочки MFA.
Ветвление на основе роли и группы
Узлы switch, маршрутизирующие по роли пользователя или членству в группах, формируют слои доступа в едином потоке — администраторы проходят по одному пути с более строгой MFA, обычные пользователи проходят по пути без трения, подрядчики проходят по третьему пути, привязанному к времени и списку ресурсов. Поток остаётся поддающимся аудиту как единый артефакт.
Пути доступа в сфере соответствия
Сервисы в области охвата PCI-DSS, HIPAA, GDPR, ISO 27001 запускают собственные более строгие потоки — обязательная MFA, обязательная регистрация в начале сессии, без ярлыка доверенного устройства. Аудитор изучает единое определение потока и единый поток аудита вместо нагромождения накладывающихся правил.
Часто задаваемые вопросы
Как сегодня определяется политика условного доступа?
Как оцениваются такие условия, как географическая локация, время и состояние устройства?
Поддерживает ли switch (маршрутизация по сопоставлению паттернов) regex?
Как проводится аудит каждого решения о доступе?
Можно ли протестировать изменение политики до выхода в продакшн?
Верните вашу политику доступа на единый движок
Один движок потоков, один источник, один поток аудита — для каждого сервиса, каждого шага, каждого решения. Проведём вас по живой установке на ваших собственных приложениях.