Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info
Безопасность «последней мили» защищает серверные службы, которые проксируются API-сервисами. Основная цель безопасности «последней мили» — предотвращение так называемых «атаок обхода», когда разработчик приложения обнаруживает URL-адрес серверной службы и обходит любые API-прокси, чтобы напрямую обратиться к этому URL-адресу.
Ниже представлены основные варианты организации безопасности на последнем этапе доставки:
- Клиентский TLS/SSL
- Исходящая аутентификация
- Модуль tls для Node.js
Клиентский TLS/SSL
Основным механизмом защиты «последней мили» является клиентский протокол TLS/SSL, также известный как «взаимная аутентификация».
См. раздел «Настройка TLS от периферии сети к бэкэнду (облако и частное облако)» .
Исходящая аутентификация
Безопасность на последнем этапе также может быть обеспечена путем требования от API-прокси передавать учетные данные бэкэнд-сервису.
Например, вам может потребоваться, чтобы API-прокси передавал ключ API вашему бэкэнд-сервису. Вы также можете использовать API-прокси для получения и передачи токена доступа к учетным данным клиента OAuth.
ключ API
Ключи API могут применяться к исходящим запросам от API-прокси к бэкэнд-сервисам. Это предполагает, что бэкэнд-сервис является API, способным выдавать и проверять ключи API.
Если вы настроили API-прокси для предоставления API-ключа в исходящих запросах, необходимо хранить API-ключ в месте, доступном для его получения во время выполнения. Одним из таких мест является карта ключ/значение. См. политику «Операции с картами ключ/значение» .
Вы можете использовать тип политики AssignMessage для добавления ключа API в качестве заголовка HTTP, параметра запроса или элемента полезной нагрузки к исходящему запросу. См. раздел «Политика AssignMessage» .
учетные данные клиента OAuth
Учетные данные клиента OAuth можно использовать для повышения возможности отзыва ключей API. Если ваши бэкэнд-сервисы поддерживают учетные данные клиента OAuth, вы можете настроить API-прокси для предоставления токена доступа с учетными данными клиента для каждого запроса.
API-прокси должен быть настроен на выполнение вызова для получения токена доступа от вашей конечной точки токенов. API-прокси также должен кэшировать токен доступа, чтобы предотвратить получение нового токена доступа для каждого вызова.
Для реализации исходящих клиентских учетных данных можно использовать несколько подходов.
Вы можете изменить этот пример, чтобы он вызывал вашу конечную точку для получения токена доступа. В этом примере используется JavaScript для прикрепления токена к исходящему запросу в качестве заголовка HTTP Authorization. Для этой цели вы также можете использовать политику назначения сообщений .
SAML
Тип политики GenerateSAMLAssertion можно использовать для добавления утверждения SAML к исходящему XML-запросу от API-прокси к бэкэнд-сервису. Это позволяет бэкэнд-сервису выполнять аутентификацию и авторизацию запросов, полученных от API-прокси.
См. политики утверждений SAML .
Node.js
Если целевым API-прокси является приложение Node.js, вы можете использовать модуль Node.js tls для создания безопасных соединений с бэкэнд-сервисами. Исходящие запросы с помощью модуля tls выполняются так же, как и в обычном режиме Node.js. В основном, вам нужно добавить ключи и сертификаты на стороне клиента (.pem-файлы) в каталог resources/node и загрузить их в свой скрипт. Для получения информации об использовании модуля tls и его методов см. документацию по модулю Node.js tls . Дополнительную информацию см. в разделе «Понимание поддержки Edge для модулей Node.js» .