Модель угроз: публичный API мультиарендного SaaS
Вопрос
Вы открываете публичный API для клиентов B2B SaaS: интеграции через API-ключи и OAuth-приложения партнёров, вебхуки к клиентам. Смоделируйте угрозы.
Коротко
Что должно быть в решении
- 1Схема: клиентские интеграции, партнёрские приложения, API-шлюз, сервисы, база с арендаторами, исходящие вебхуки; границы: интернет, арендаторы между собой
- 2Spoofing: утечка API-ключей, scopes и срок жизни, привязка к IP, ротация
- 3Elevation и Information disclosure: BOLA между арендаторами, scopes OAuth, минимальные права
- 4Tampering: mass assignment, валидация схем, идемпотентность
- 5DoS: квоты и лимиты по ключу и арендатору, стоимость запросов, пагинация
- 6Исходящие вебхуки: SSRF через URL клиента, подпись вебхуков
- 7Repudiation: аудит вызовов по ключу, доступный клиенту
- 8Inventory: версии API, устаревшие эндпоинты, документация
Что спросит интервьюер
- Как отозвать ключ, если клиент сообщил об утечке ночью?
- Как не дать одному клиенту положить API для всех?
Разбор
Эталонный разбор. Главная граница здесь между арендаторами: любая ошибка авторизации становится утечкой чужих данных, поэтому тенант определяется только из ключа или токена, а не из параметров, и проверяется в слое данных. API-ключи хранятся хешированными, имеют scopes, срок, префикс для сканеров секретов и самостоятельную ротацию клиентом. OAuth-приложения партнёров получают минимальные scopes с согласием администратора клиента. Лимиты и квоты по ключу и арендатору защищают от шумного соседа. Исходящие вебхуки на URL клиента это SSRF-риск: отправка через изолированный egress, запрет внутренних адресов, подпись HMAC. Аудит вызовов доступен клиенту. Версии API учтены, старые выводятся по плану.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.