Выбор авторизатора API Gateway

Использование AWS Security для разработчиков

Rahul Singh

Technical Product Manager

Проверка перед выполнением кода

Клиент проходит через авторизатор API Gateway, прежде чем запрос достигнет вашего кода, а отклонённый клиент получает ошибку 401.

Успешно: запрос достигает вашего кода

Отказ: 401 unauthorized, ваш код не выполняется

Кто выполняет проверку

Три типа авторизаторов на выбор

IAM auth (AWS_IAM): AWS проверяет подпись

Вертикальный список на оси от проверки со стороны AWS до проверки вами самостоятельно. Заполнена только первая карточка: IAM auth, где AWS проверяет подпись.

Кто выполняет проверку

Три типа авторизаторов на выбор

IAM auth (AWS_IAM): AWS проверяет подпись
Cognito authorizer (COGNITO_USER_POOLS): AWS проверяет токен
- Подпись, iss, aud, exp

Тот же вертикальный список с двумя заполненными карточками: IAM auth, где AWS проверяет подпись, и Cognito authorizer, где AWS проверяет токен.

Кто выполняет проверку

Три типа авторизаторов на выбор

IAM auth (AWS_IAM): AWS проверяет подпись
Cognito authorizer (COGNITO_USER_POOLS): AWS проверяет токен
- Подпись, iss, aud, exp
Lambda authorizer: ваша функция возвращает allow или deny
- Для токенов, не относящихся к Cognito

Три авторизатора по шкале от проверки со стороны AWS до проверки вами: IAM auth, где AWS проверяет подпись, Cognito authorizer, где AWS проверяет токен, и Lambda authorizer, где проверку пишете вы.

Подберите дверь под клиента

Решение за клиентом

Внутренний сервис: уже имеет учётные данные AWS

Первая из трёх строк соответствия клиента и авторизатора: внутренний сервис сопоставлен с IAM auth.

Подберите дверь под клиента

Решение за клиентом

Внутренний сервис: уже имеет учётные данные AWS
Пользователь приложения: имеет токен Cognito

Две из трёх строк соответствия клиента и авторизатора: внутренний сервис сопоставлен с IAM auth, а пользователь приложения — с Cognito authorizer.

Подберите дверь под клиента

Решение за клиентом

Внутренний сервис: уже имеет учётные данные AWS
Пользователь приложения: имеет токен Cognito
Приложение партнёра: использует собственную логику авторизации

Три клиента сопоставлены с нужным им авторизатором: внутренний сервис — с IAM auth, пользователь приложения — с Cognito authorizer, а приложение партнёра — с Lambda authorizer.

Важен тип API

REST API

Все три авторизатора, а также политики ресурсов
API-ключи, троттлинг по клиентам, валидация запросов, WAF

Карточка сравнения для REST API с отмеченными IAM auth, Cognito user pool authorizer, Lambda authorizer и resource policy. Карточка HTTP API рядом ещё не заполнена.

Важен тип API

REST API

Все три авторизатора, а также политики ресурсов
API-ключи, троттлинг по клиентам, валидация запросов, WAF

HTTP API

JWT authorizer, любой OIDC issuer
Без политик ресурсов — дешевле и быстрее

Две карточки сравнения поддерживаемых авторизаторов для каждого типа API: REST API добавляет политики ресурсов, а HTTP API заменяет Cognito authorizer на JWT authorizer и не имеет политик ресурсов.

Авторизатор запоминает

Кэш экономит время

Первый вызов: авторизатор выполняется
Последующие вызовы: читается ответ из кэша

Первый вызов запускает авторизатор и записывает allow в кэш с заданным временем жизни, а последующий вызов читает этот allow из кэша, не запуская авторизатор повторно.

Авторизатор запоминает

Кэш экономит время

Первый вызов: авторизатор выполняется
Последующие вызовы: читается ответ из кэша

TTL кэша

authorizerResultTtlInSeconds: по умолчанию 300 с, максимум 3600 с
Ноль отключает кэширование

Кэшированное разрешение переживает отзыв прав

Временная шкала с двумя дорожками. Дорожка прав меняется с «действительно» на «отозвано» в момент отзыва, а дорожка кэшированного allow ниже по-прежнему показывает allow после этой точки; период после отзыва выделен.

В момент отзыва прав

Права: отозваны немедленно
Кэшированный allow: по-прежнему разрешает доступ

Кэшированное разрешение переживает отзыв прав

Та же шкала с двумя дорожками: период между моментом отзыва и истечением TTL выделен и помечен как «всё ещё разрешено» — права отозваны, но кэшированный allow продолжает предоставлять доступ.

Промежуточный период

Прав уже нет, но кэш об этом не знает
Доступ сохраняется до истечения TTL

Кэшированное разрешение переживает отзыв прав

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

Контролируйте этот период

Короткий TTL, если отзыв должен быть быстрым
TTL 0 для самых критичных маршрутов

Один клиент обходит главный вход

Сторонний сервис внутри вашего аккаунта

Принимает роль, которую вы создали
Вы передаёте ARN роли

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

Один клиент обходит главный вход

Сторонний сервис внутри вашего аккаунта

Принимает роль, которую вы создали
Вы передаёте ARN роли

ARN роли — не секрет

Проблема confused deputy

Второй блок клиента теперь активен и выделен красным: он передаёт ARN вашей роли, как будто это его собственный. Две стрелки теперь идут от поставщика мониторинга к вашей роли — по одному вызову на клиента, и различить их невозможно.

Один клиент обходит главный вход

Сторонний сервис внутри вашего аккаунта

Принимает роль, которую вы создали
Вы передаёте ARN роли

ARN роли — не секрет

Проблема confused deputy

Решение: sts:ExternalId

Поставщик создаёт отдельный ID для каждого клиента
Ваша политика доверия требует совпадения

Теперь у вашей роли есть требование, что external ID должен равняться 12345. Вызов с 12345 достигает роли, а вызов с 99999 останавливается красным крестом, не доходя до неё.

Давайте потренируемся!

Использование AWS Security для разработчиков