Безопасность веб-API

Безопасность веб-API влечет за собой аутентификацию программ или пользователей, которые вызывают веб-API.

Наряду с простотой интеграции API возникают трудности с обеспечением надлежащей аутентификации (AuthN) и авторизации (AuthZ). В многопользовательской среде средства управления безопасностью, основанные на правильных AuthN и AuthZ, могут помочь гарантировать, что доступ к API будет ограничен теми, кто в нем нуждается (и имеет на это право). Соответствующие схемы AuthN позволяют производителям (API или сервисам) правильно идентифицировать потребителей (клиентов или вызывающие программы) и оценивать их уровень доступа (AuthZ). Другими словами, может ли потребитель вызвать конкретный метод (бизнес-логику) на основе представленных учетных данных ?

«Недостатки дизайна интерфейсов широко распространены, от мира крипто процессоров до различных встроенных систем вплоть до антивирусного программного обеспечения и сама операционная система. "

• 1 Метод аутентификации и авторизации
  • 1.1 Статические строки
  • 1.2 Динамические токены
  • 1.3 Токен, делегированный пользователем
• 2 Детальная авторизация для API
  • 2.1 Управление доступом на основе атрибутов
• 3 Ссылки

Наиболее распространенные методы аутентификации и авторизации включают.

1. Статические строки: они похожи на пароли, предоставляемые API потребителям.
2. Динамические токены: это токены на основе времени, полученные вызывающим абонентом из службы аутентификации.
3. Делегированные пользователем токены : Это токены, такие как OAuth, которые предоставляются на основе аутентификации пользователя.
4. Политика и управление доступом на основе атрибутов : политики используют атрибуты для определения того, как могут быть вызывается с использованием таких стандартов, как ALFA или XACML.

. Вышеупомянутые методы обеспечивают разный уровень безопасности и простоту интеграции. Часто самый простой метод интеграции предлагает и самую слабую модель безопасности.

Статические строки

В методе статических строк вызывающий API или клиент вставляет строку в качестве токена в запрос. Этот метод часто называют базовой аутентификацией. «С точки зрения безопасности, базовая аутентификация не очень удовлетворительна. Это означает отправку пароля пользователя по сети в виде открытого текста для каждой страницы, к которой осуществляется доступ (кроме безопасного протокола нижнего уровня, такого как SSL, используется для шифрования всех транзакций). Таким образом, пользователь очень уязвим для любых анализаторов пакетов в сети ».

.

Динамические токены

Когда API защищенный динамическим токеном, в токен вставлен временный одноразовый номер. У токена есть время жизни (TTL), по истечении которого клиент должен получить новый токен. Метод API имеет алгоритм проверки времени , и если срок действия токена истек, запрос запрещен. «Примером такого токена является JSON Web Token. Утверждение« exp »(время истечения срока) определяет время истечения срока действия или после которого JWT НЕ ДОЛЖЕН приниматься в обработку».

Токен, делегированный пользователем

Этот тип токена используется в трехсторонних системах, где приложению требуется доступ к API от имени пользователя. Вместо того, чтобы раскрывать приложению идентификатор пользователя и пароль, пользователь предоставляет токен, который инкапсулирует разрешение пользователя для приложения на вызов API.

Платформа авторизации OAuth 2.0 позволяет стороннему приложению получать ограниченный доступ к службе HTTP либо от имени владельца ресурса, организуя согласование взаимодействия между владельцем ресурса и HTTP-сервис или разрешив стороннему приложению получить доступ от своего имени.

.

Атрибутный контроль доступа

В этом подходе является точкой применения политики либо в самом API, либо в структуре API (в качестве перехватчика или обработчика сообщений), либо в качестве шлюза API (например, WSO2, Kong или аналогичный ) который перехватывает вызов API и / или ответ API. Он преобразует его в запрос авторизации (обычно в XACML), который он отправляет в точку принятия решения о политике (PDP), например. AuthZForce или Axiomatics. Точка принятия решения о политике настроена с помощью политик, реализующих динамический контроль доступа, который может использовать любое количество атрибутов пользователя, ресурса, действия и контекста, чтобы определить, какой доступ разрешен или запрещен. Политики могут касаться:

1. ресурса (например, банковского счета)
2. пользователя (например, покупателя)
3. контекста (например, времени дня)
4. a отношения (например, клиент, которому принадлежит учетная запись).

Политики выражаются в ALFA или XACML.