Какие есть способы сделать API более безопасными?

Вопрос. Как организации могут обеспечить устойчивость своих API к компрометации перед лицом возросшего количества атак на основе API?

Рори Бланделл, основатель и генеральный директор Gravitee: Компании всех размеров и во всех отраслях обычно полагаются на внутренние API-интерфейсы для объединения своих бизнес-приложений и на внешние API-интерфейсы для обмена данными или услугами с поставщиками, клиентами или партнерами. Поскольку один API может иметь доступ к нескольким приложениям или службам, компрометация API — это простой способ компрометации широкого набора бизнес-активов с минимальными усилиями.

API-интерфейсы стали популярным вектором атак, и частота атак API увеличилась на поразительный 681%, согласно недавнему исследования Salt Labs. Первым шагом в обеспечении безопасности ваших API является следование передовым методам, таким как те, которые OWASP рекомендует защищаться от распространенных рисков безопасности API.

Однако базовых методов обеспечения безопасности API недостаточно для обеспечения безопасности ИТ-ресурсов. Компании должны предпринять следующие дополнительные шаги для защиты своих API.

1. Используйте аутентификацию на основе рисков

Предприятиям следует применять политики аутентификации на основе рисков, которые позволяют применять меры безопасности в случаях повышенного риска. Например, клиенту API с большим опытом выдачи законных запросов, следующих по предсказуемой схеме, может не потребоваться проходить тот же уровень проверки подлинности для каждого запроса, что и новому клиенту, который никогда раньше не подключался. Но если схема доступа давнего клиента API изменится — если, например, клиент внезапно начнет выдавать запросы с другого IP-адреса — более строгая проверка подлинности будет разумным способом гарантировать, что запросы не исходят от скомпрометированного клиента.

2. Добавьте биометрическую аутентификацию

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

3. Внешняя аутентификация

Чем сложнее становятся ваши схемы аутентификации API, тем сложнее обеспечить соблюдение требований безопасности в самом приложении. По этой причине разработчики должны стремиться отделить правила безопасности API от логики приложения и вместо этого использовать внешние инструменты, такие как шлюзы API, для обеспечения соблюдения требований безопасности. Такой подход делает политики безопасности API более масштабируемыми и гибкими, поскольку их можно легко внедрять и обновлять в шлюзах API, а не через исходный код приложения. И самое главное, он позволяет применять разные правила к разным пользователям или запросам на основе разных профилей риска.

4. Сбалансируйте безопасность API с удобством использования

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

Атаки, нацеленные на API, не показывают признаков замедления. При проектировании и защите API разработчики должны выходить за рамки рекомендаций OWASP, чтобы затруднить использование API.