[2/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”

Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:

While secure flows are essential, they should be complemented by a keen focus on access tokens.

Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.

Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.

Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.

Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.

Такая token termination в видении авторов состоит из двух задач:
🔵валидация входящих временных учетных данных
🔵трансляция их в JWT access token для конечных сервисов.
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.

Говорится:

We have seen that your overall API security is distributed between the API gateway APIs, and possibly additional components such as service meshes.

В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).

На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
🔵Здесь получаете не отдельный токен доступа в виде JWT, а обернутый в JWT тот же ответ от introspection endpoint
🔵Таким образом два представления токена доступа полноценно не “развязать”: полученный JWT не ограничить отдельно по времени жизни или области действия
🔵Сами авторы RFC пишут, что возвращаемый здесь JWT “is not an alternative representation of the introspected access token and is not intended to be used as an access token”

В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).

Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.

Интересна и часть, где авторы описывают преимущества использования выделенной entitlement management system (EMS):
🔵Flexibility (API работают только с предоставленным результатом, саму логику контроля доступа можно изменять, не ломая их)
🔵Auditability (имеем события аудита как для применения политик, так и их для изменения)
🔵Security agility (отделение ЖЦ политик доступа от ЖЦ конечных сервисов)
🔵Quality assurance via policy as code (если политики прописываются отдельно, сами сервисы могут не тестировать их внутреннюю логику, а покрывать только возможные исходы)

В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.

#book #iam_general #oauth.