После отзыва административной роли пользователь всё ещё получает доступ к закрытому разделу. Как установить, что причиной является устаревший кэш авторизации?
Нужно сравнить результат проверки доступа при тёплом кэше с результатом после принудительного истечения или очистки записи кэша. Если доступ исчезает только после очистки кэша, система использует устаревшее решение авторизации и допускает временное сохранение отозванных прав.
Кэширование решений авторизации появилось как способ снизить нагрузку на хранилище пользователей, службы ролей и централизованные системы управления доступом. Оно особенно важно в распределённых приложениях, где каждый запрос иначе может требовать обращения к удалённому сервису.
Цена оптимизации — задержка распространения изменений. Поэтому отзыв роли, блокировка учётной записи или удаление разрешения могут не подействовать немедленно, если приложение не умеет корректно инвалидировать связанные кэшированные решения.
Тестировщик должен создать пользователя с административным правом, получить успешный доступ к защищённому разделу, затем отозвать это право через штатный механизм управления ролями. После отзыва следует повторить запрос с той же сессией, с новой сессией, через разные экземпляры приложения и после истечения предполагаемого времени жизни кэша.
Критический результат — момент, когда доступ прекращается. Если старое право действует дольше объявленного допустимого периода или сохраняется на одном узле, но исчезает на другом, возникает окно несанкционированного доступа. Его последствия зависят от операции: пользователь может продолжать просматривать данные, изменять настройки или выполнять административные действия.
Сначала нужно зафиксировать исходное состояние: идентификатор пользователя, роль, ресурс, успешный ответ авторизации и конкретный экземпляр приложения, если он известен. Затем роль отзывается, после чего выполняются одинаковые запросы с контролем времени, маршрута, сессии и результата.
Для подтверждения гипотезы сравнивают несколько состояний: запрос до отзыва, первый запрос после отзыва, запрос после очистки кэша или истечения TTL, запрос к каждому узлу без балансировщика и запрос после повторной аутентификации. Одного отказа после перелогина недостаточно: он может быть вызван обновлением сессии, а не корректной инвалидизацией авторизационного кэша.
Безопасное поведение — немедленный отказ после отзыва либо явно документированная короткая задержка, одинаковая для всех узлов. Для критичных административных действий обычно предпочтительна проверка актуального состояния или надёжная событийная инвалидизация, а не длительный TTL.
Кэш должен учитывать все значимые параметры решения: пользователя, ресурс, действие, область полномочий и версию прав. Нельзя использовать только идентификатор пользователя, если решения различаются по ресурсам или операциям. При ошибке хранилища авторизации безопаснее отказать в доступе, чем продолжить работу по старому разрешающему результату.
У короткого TTL есть компромисс: он уменьшает окно устаревших прав, но повышает нагрузку. Инвалидация по событию быстрее, однако требует надёжной доставки событий, обработки повторов и контроля ситуации, когда один узел пропустил уведомление. Для особо чувствительных операций можно сочетать кэширование обычных проверок с обязательной свежей проверкой перед выполнением действия.
В распределённой административной панели роль оператора отзывалась в центральном сервисе, но API-шлюз кэшировал разрешающие решения на десять минут. После отзыва пользователь продолжал выгружать отчёты через один узел, тогда как другой узел уже возвращал отказ. Проверка только через интерфейс дала бы неполную картину из-за случайного выбора маршрута балансировщиком.
Рассматривались три варианта. Полностью отключить кэш было просто и надёжно с точки зрения актуальности, но это увеличивало задержку и нагрузку. Уменьшить TTL было дешевле, однако сохраняло окно доступа и не устраняло различия между узлами. Внедрить адресную инвалидизацию по событиям отзыва роли было сложнее, зато позволяло быстро удалить решения на всех экземплярах.
Выбрали событийную инвалидизацию с безопасным отказом при недоступности источника актуальных прав, а для критичных операций добавили повторную проверку непосредственно перед выполнением. Повторный тест проверил тёплый кэш, каждый узел, новую сессию, потерю события и временную недоступность хранилища. В результате отзыв роли прекращал доступ на всех узлах, а сбой доставки события не приводил к продолжению административной операции.
1. Достаточно ли проверить отзыв роли только в текущей сессии?
Нет. Проблема может находиться не в сессии, а в кэше решения, общем для нескольких сессий или узлов. Нужно проверить прежнюю сессию, новую сессию, разные экземпляры приложения и состояние после истечения TTL; иначе можно ошибочно принять обновление сессии за корректную инвалидизацию прав.
2. Почему проверка только чтения не всегда выявляет риск?
Чтение может проходить через один слой кэширования, а изменение данных — через другой путь с более строгой проверкой. Поэтому нужно отдельно проверять чувствительное действие, которое реально меняет состояние, особенно если административное право позволяет удаление, экспорт или изменение настроек. Разрешение на чтение после отзыва не доказывает безопасность операции изменения.
3. Как отличить устаревший кэш авторизации от кэша самого HTTP-ответа?
Нужно менять признаки запроса, не меняющие право доступа, например добавлять уникальный параметр против кэширования ответа, отправлять запрос с заголовками запрета кэширования и сравнивать фактическое выполнение операции. Если устаревший ответ исчезает, но сервер всё ещё принимает защищённое действие, проблема находится в авторизационном кэше. Если же меняется только содержимое ответа, следует дополнительно исследовать промежуточный HTTP-кэш.