Безопасность веб-API
Безопасность веб-API предполагает аутентификацию программ или пользователей, вызывающих веб-API .
Наряду с простотой интеграции API возникают трудности с обеспечением правильной аутентификации (AuthN) и авторизации (AuthZ). В мультитенантной среде меры безопасности, основанные на правильных AuthN и AuthZ, могут помочь гарантировать, что доступ к API будет ограничен теми, кто в нем нуждается (и имеет на это право). Соответствующие схемы AuthN позволяют производителям (API или службам) правильно идентифицировать потребителей (клиентов или вызывающие программы) и оценивать их уровень доступа (AuthZ). Другими словами, может ли потребитель вызвать определенный метод (бизнес-логику) на основе предоставленных учетных данных ?
«Ошибки проектирования интерфейсов широко распространены: от мира криптопроцессоров различных до встроенные системы, вплоть до антивирусного программного обеспечения и самой операционной системы». [1]
Метод аутентификации и авторизации
[ редактировать ]Наиболее распространенные методы аутентификации и авторизации включают в себя:
- Статические строки: они похожи на пароли, которые API предоставляются потребителям.
- Динамические токены: это токены, основанные на времени, полученные вызывающим абонентом от службы аутентификации.
- Токены, делегированные пользователем: это токены, такие как OAuth. [2] которые предоставляются на основе аутентификации пользователя.
- Управление доступом на основе политик и атрибутов : политики используют атрибуты для определения того, как можно вызывать API с использованием таких стандартов, как ALFA или XACML .
Вышеуказанные методы обеспечивают различный уровень безопасности и простоту интеграции. Часто самый простой метод интеграции также предлагает самую слабую модель безопасности.
Статические строки
[ редактировать ]
В методе статических строк вызывающий API или клиент встраивает строку в качестве токена в запрос. Этот метод часто называют базовой аутентификацией . «С точки зрения безопасности базовая аутентификация не очень удовлетворительна. Это означает отправку пароля пользователя по сети в виде открытого текста для каждой страницы, к которой осуществляется доступ (если только безопасный протокол более низкого уровня, такой как SSL для шифрования всех транзакций не используется ). ). Таким образом, пользователь очень уязвим для любых анализаторов пакетов в сети». [3]
Динамические токены
[ редактировать ]Когда API защищен динамическим токеном, одноразовый номер, в токен вставляется основанный на времени. У токена есть время жизни (TTL), по истечении которого клиент должен приобрести новый токен. Метод API имеет алгоритм проверки времени , и если срок действия токена истек, запрос запрещается. «Примером такого токена является JSON Web Token . Утверждение «exp» (время истечения срока действия) определяет время истечения срока действия, в течение которого или после которого JWT НЕ ДОЛЖЕН приниматься для обработки». [4]
Делегированный пользователем токен
[ редактировать ]Этот тип токена используется в трехногих системах, где приложению необходимо получить доступ к API от имени пользователя. Вместо того, чтобы раскрывать приложению идентификатор пользователя и пароль, пользователь предоставляет токен, который инкапсулирует разрешение пользователя приложению на вызов API.
Платформа авторизации OAuth 2.0 позволяет стороннему приложению получать ограниченный доступ к службе HTTP либо от имени владельца ресурса путем организации взаимодействия утверждения между владельцем ресурса и службой HTTP, либо путем разрешения стороннему приложению получить доступ от своего имени. [5]
Детализированная авторизация для API
[ редактировать ]Управление доступом на основе атрибутов
[ редактировать ]В этом подходе существует точка применения политики либо внутри самого API, либо в структуре API (в качестве перехватчика или обработчика сообщений), либо в качестве шлюза API (например, WSO2 , Kong или аналогичного ), который перехватывает вызов API. и/или ответ от API. Он преобразует его в запрос авторизации (обычно в формате XACML), который отправляет в точку принятия решения о политике (PDP). Точка принятия решения политики настроена с помощью политик, которые реализуют динамическое управление доступом, которое может использовать любое количество атрибутов пользователя, ресурса, действия и контекста для определения того, какой доступ разрешен, а какой запрещен. Политика может касаться:
- ресурс (например, банковский счет)
- пользователь (например, клиент)
- контекст (например, время суток)
- отношения (например, клиент, которому принадлежит учетная запись).
Политики выражаются в ALFA или XACML.
Ссылки
[ редактировать ]- ^ «Атаки API» (PDF) .
- ^ «OAuth 2.0 — OAuth» . oauth.net . Проверено 10 октября 2015 г.
- ^ «Руководство по альтернативам веб-аутентификации: Часть 2» . unixpapa.com . Проверено 10 октября 2015 г.
- ^ Джон, Брэдли; Нат, Сакимура; Майкл, Джонс. «Веб-токен JSON (JWT)» . www.tools.ietf.org . Проверено 10 октября 2015 г.
- ^ Хардт, Дик. «Структура авторизации OAuth 2.0» . www.tools.ietf.org . Проверено 11 октября 2015 г.
