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