Условный доступ: политики, зависящие от контекста

Условный доступ — подход, при котором решение о доступе принимается не только по учётным данным, но и с учётом обстоятельств входа: с какого устройства, откуда, в какое время, к какому ресурсу.

Классическая схема отвечает на вопрос «правильный ли пароль». Условный доступ добавляет вопрос «похоже ли это на нормальный вход этого пользователя».

Зачем это нужно

Украденные учётные данные — самый частый способ проникновения. Злоумышленнику не нужно взламывать систему, если он может просто войти.

Проблема в том, что для системы правильный пароль выглядит одинаково независимо от того, кто его ввёл. Условный доступ добавляет контекст: тот же пароль, но вход из другой страны в три часа ночи с неизвестного устройства — повод потребовать подтверждения.

Сигналы для принятия решения

Устройство. Знакомое или новое, управляемое компанией или личное, соответствует ли требованиям безопасности.

Местоположение. Страна и сеть, из которых выполняется вход. Особенно показательны географически невозможные перемещения: вход из одного города, а через десять минут — из другого на другом континенте.

Время. Соответствует ли попытка обычному графику работы пользователя.

Запрашиваемый ресурс. Чтение справочной информации и доступ к административной панели заслуживают разной строгости.

Поведение. Отклонения от привычной картины: необычный объём запросов, нетипичная последовательность действий.

Возможные реакции

Решение не сводится к «пустить или не пустить»:

• Пропустить — контекст обычный, дополнительных действий не требуется.
• Запросить подтверждение — потребовать второй фактор, даже если сессия уже активна.
• Ограничить — предоставить доступ только на чтение или закрыть отдельные разделы.
• Отказать — заблокировать попытку и зафиксировать событие.

Промежуточные варианты важнее крайних: жёсткая блокировка при малейшем отклонении быстро становится помехой в работе, а сплошное разрешение обесценивает саму идею.

Основные принципы

Проверять, а не предполагать. Нахождение в корпоративной сети само по себе не является доказательством благонадёжности.

Минимальные права. Контекст уточняет решение, но базовый объём прав всё равно должен быть ограничен ролью.

Исходить из того, что взлом возможен. Политики строятся так, чтобы скомпрометированная учётная запись давала как можно меньше.

Соизмерять строгость и риск. Требовать подтверждения на каждый чих — верный способ приучить пользователей подтверждать всё не глядя.

Типичные трудности

Баланс с удобством. Слишком строгие правила порождают обходные пути: люди начинают искать способы не сталкиваться с проверками.

Сложность правил. Десяток пересекающихся политик приводит к ситуациям, когда никто не может объяснить, почему конкретному пользователю отказано.

Унаследованные приложения. Системы, не понимающие современных протоколов, остаются вне действия политик.

Ложные срабатывания. Сотрудник в командировке выглядит подозрительно с точки зрения географии. Без продуманной реакции это превращается в поток обращений в поддержку.

Как это устроено в Keydee

Keydee поддерживает базовый уровень условности через политику компании:

• Требование второго фактора включается на уровне организации и распространяется на все её приложения.
• Фактор привязан к сессии: подтвердив личность, пользователь не проходит проверку повторно в рамках этой сессии, а завершение сессии возвращает требование подтверждения.
• Активные сессии видны и завершаются — при подозрении на компрометацию доступ прекращается немедленно.
• Журнал фиксирует реальный IP-адрес каждого входа, что позволяет обнаружить нетипичные обращения при разборе.

Полноценный механизм политик по геолокации, состоянию устройства и оценке риска — отдельный класс функциональности; на сегодня его в платформе нет. Практический подход: использовать обязательный второй фактор для всех административных сценариев, ограничивать срок жизни сессий и регулярно просматривать журнал на предмет необычных входов.

С чего начать

1. Определите, что вы защищаете: какие ресурсы критичны, а какие нет.
2. Начните с обязательного второго фактора для администраторов — это даёт наибольший эффект при минимальных усилиях.
3. Разберите журнал входов и посмотрите, как выглядит нормальная картина. Без этого невозможно отличить аномалию.
4. Вводите ограничения постепенно, наблюдая за числом ложных срабатываний.
5. Заранее продумайте, что делает пользователь, которому отказано, и как поступает поддержка.