С помощью API-шлюза вы можете реализовать меры безопасности на периферии, работая над созданием системы с нулевым уровнем доверия (zero trust), пишет на портале The New Stack Дэвид Судиа, старший специалист по работе с разработчиками компании Ambassador Labs.

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

Я привык защищать активный веб-сайт, но не случайный IP-адрес. Такова реальность сегодняшней среды веб-разработки. Если у вас есть API, работающий через сеть, вы должны защитить его, потому что кто-то гарантированно атакует его.

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

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

То же самое справедливо и для авторизации, и обработка авторизации в API-шлюзе — это все равно что вспомогательный сервис для более крупной системы. Существует две основные области безопасности, которые API-шлюз должен обеспечивать сам или иметь интеграцию: аутентификация (Authn) и авторизация (Authz).

Ниже мы остановимся на этих темах применительно к API-шлюзам.

Аутентификация и авторизация

Вкратце, система использует процессы аутентификации и авторизации, чтобы ответить на два вопроса по конкретному запросу:

  • кто сделал этот запрос? (аутентификация);
  • разрешено ли ему делать то, что он пытается сделать? (авторизация).

Это справедливо независимо от того, приходит ли запрос извне или изнутри системы, например, запрос от другой службы или из системы управления идентификацией и доступом (IAM). Некоторые инструменты дублируют обе функции. Например, JSON Web Token (JWT) может использоваться для идентификации пользователя и содержать список авторизованных разрешений в своей полезной нагрузке.

Аутентификация для API

Суть аутентификации заключается в проверке полномочий пользователя по известному объекту и отправке обратно учетных данных, которые пользователь должен отправить при последующих запросах, будь то JWT, сессионный cookie и т. д. Что вам нужно в API-шлюзе, так это встроенная совместимость с максимально возможным количеством стандартных методов аутентификации и расширяемость, чтобы вы могли использовать другие методы, не встроенные в шлюз.

Некоторые распространенные методы аутентификации, которые следует искать в API-шлюзе, следующие:

  • базовая аутентификация — также известная как «имя пользователя и пароль»;
  • OpenID Connect (OIDC) — этот инструмент используется для единого входа (SSO) большинством крупных провайдеров, таких как Azure Active Directory, Google, Github, Okta и т. д.;
  • JWT — чтобы получить JWT, пользователь должен пройти аутентификацию другим способом, но JWT будет отправляться для будущих запросов до тех пор, пока токен действителен. Быстрая проверка JWT в точке входа очень удобна.

Расширяемость

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

Авторизация для API

Авторизация — более сложная тема, поскольку она часто зависит от специфики бизнеса и предметной области. Даже если существуют общие типы систем авторизации, такие как управление доступом на основе ролей (RBAC), роли и то, что каждая роль может делать, будут специфичны для вашей системы. Тем не менее, есть несколько возможностей, которые следует искать в API-шлюзе, которые можно считать авторизацией, и вам может понадобиться возможность интегрировать ее с вашими системами, как и в случае с аутентификацией.

Возможности авторизации API-шлюзов

Если авторизация — это попытка ответить на вопрос «Что вам разрешено делать?», то на периферии вашей сети есть некоторые разрешения, которые ваш шлюз должен уметь подтверждать:

  • Разрешено ли вам вообще делать этот запрос? Ваш API-шлюз должен быть способен немедленно вернуть ответ 403 или аналогичный ответ «Не авторизован», если пользователь пытается сделать запрос, который он не должен делать.
  • Как часто вам разрешено делать запросы? Ограничение частоты — это форма разрешения, и оно находится в рамках компетенции API-шлюза. В идеале вы должны иметь возможность настроить шлюз на ограничение частоты глобально, по IP-адресу и идентификатору пользователя.
  • Куда вам следует разрешить делать запросы? Системы, которые должны обрабатывать ваши запросы, могут быть частью системы авторизации. Например, в мультирегиональной архитектуре вы можете потребовать, чтобы клиенты из одного региона могли делать запросы только к серверам этого региона. Ваш API-шлюз должен уметь осуществлять динамическую маршрутизацию для поддержки этого.
  • Работа с OAuth2, которая часто встречается там, где вы используете OIDC. Там, где OIDC проверяет вашу личность, протокол OAuth2 обеспечивает авторизацию доступа к тем же системам.

Интеграция

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

Начните на периферии

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

Точно так же, как вы можете начать с внедрения TLS на периферии вашей сети с помощью API-шлюза, а затем добавить mutual TLS между внутренними службами с помощью сервисной сетки, вы можете внедрить меры безопасности на периферии, работая над созданием полной системы с нулевым доверием.