Пользователю отозвали роль, но кэш разрешений ещё действителен. Как спроектировать кэширование решений авторизации, чтобы не сохранить доступ после отзыва?
Кэш решений авторизации должен иметь ограниченный срок жизни и механизм немедленного или почти немедленного отзыва. Надёжная схема сочетает короткий TTL, версию политики или счётчик ревизии субъекта и обработку событий об изменении ролей; при невозможности проверить актуальность решение следует отклонять, а не разрешать.
Ключ кэша должен учитывать субъекта, ресурс, действие, арендатора и значимые условия политики. Нельзя кэшировать разрешение только по идентификатору пользователя: это может перенести право между ресурсами или контекстами.
Кэширование авторизации появилось как ответ на стоимость частых обращений к централизованному хранилищу политик и идентификационных данных. В распределённых системах проверка каждого действия через удалённый сервис увеличивает задержку и создаёт дополнительную точку отказа.
Однако кэш вводит временную рассинхронизацию. После изменения роли или политики уже выданное разрешение может оставаться действительным, поэтому безопасность требует явно определить допустимое окно устаревания.
Предположим, пользователь получил доступ к конфиденциальному ресурсу, а затем его роль отозвали. Если положительный результат проверки хранится в кэше, запросы могут продолжать проходить без новой проверки.
Последствия зависят от операции: для просмотра данных это может означать утечку, для изменения состояния — несанкционированную модификацию, а для административных действий — компрометацию всей области управления. Простое увеличение TTL улучшает производительность, но одновременно увеличивает окно действия отозванного права.
Используйте несколько защитных механизмов:
Кэш следует разделять по области действия и не смешивать решения для разных арендаторов. Контекстные атрибуты, например состояние устройства, географическая зона или время, также должны входить в ключ либо полностью исключать кэширование такого решения.
Для особо критичных операций кэширование положительных решений можно запретить или требовать свежую проверку непосредственно перед действием. Отрицательные решения тоже нельзя хранить бездумно: слишком долгий TTL будет блокировать недавно выданные права, поэтому для них обычно выбирают отдельную, более короткую политику.
В многотенантной системе администратор организации отзывает у сотрудника право выгружать финансовые отчёты. Рассматривались три варианта: полностью отказаться от кэша, использовать только TTL или применять события инвалидирования.
Отсутствие кэша даёт наиболее простую модель свежести, но увеличивает задержку и нагрузку на сервис авторизации. Один TTL проще всего внедрить, однако окно доступа сохраняется даже при штатном отзыве роли. Одни события быстрее, но при потере сообщения кэш может остаться действительным дольше ожидаемого.
Выбран вариант с ревизией прав сотрудника, событиями инвалидирования и коротким TTL как резервом. Каждый запрос проверяет, что ревизия в кэшированной записи совпадает с текущей ревизией субъекта; при недоступности источника ревизии критичная операция отклоняется. В результате успешная доставка события отзывает доступ почти сразу, а при сбое максимальное окно ограничено TTL.
Нет. Событие может потеряться, задержаться или быть обработано только частью узлов. Поэтому инвалидирование должно дополняться TTL, а для критичных решений — проверкой версии политики или свежим обращением к источнику авторизации.
Разрешение часто зависит от ресурса, арендатора и атрибутов запроса. Кэш по неполному ключу способен выдать право, рассчитанное для одного ресурса или организации, в другом контексте. Полный ключ должен отражать все входы политики, влияющие на результат.
С точки зрения конфиденциальности и целостности — обычно да, потому что сбой не превращается в разрешение. Но это компромисс с доступностью: временная ошибка зависимости может заблокировать легитимные действия. Поэтому границу проводят по критичности операции: для административных и финансовых действий применяют строгий fail-closed, а для низкорисковых операций допустим заранее ограниченный режим с явно установленным TTL.