Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация
Безопасность последней мили защищает серверные службы, которые проксируются службами API. Основная цель безопасности последней мили — предотвратить так называемые атаки «конечного запуска», когда разработчик приложения обнаруживает URL-адрес серверной службы и обходит любые прокси-серверы API, чтобы напрямую попасть на внутренний URL-адрес.
Ниже приведены основные варианты настройки безопасности последней мили:
- Клиент TLS/SSL
- Исходящая аутентификация
- Модуль Node.js tls
Клиент TLS/SSL
Основным механизмом защиты последней мили является клиентский TLS/SSL, который также известен как «взаимная аутентификация».
См. раздел Настройка TLS от Edge к серверной части (облако и частное облако) .
Исходящая аутентификация
Безопасность последней мили также можно обеспечить, потребовав от прокси-сервера API предоставления учетных данных внутренней службе.
Например, вы можете захотеть, чтобы прокси-сервер API предоставлял ключ API вашей внутренней службе. Вы также можете использовать прокси-сервер API для получения и предоставления токена доступа к учетным данным клиента OAuth.
API-ключ
Ключи API можно применять к исходящим запросам от прокси-серверов API к серверным службам. При этом предполагается, что серверная служба представляет собой API, способный выдавать и проверять ключи API.
Если вы настроили прокси-сервер API для предоставления ключа API в исходящих запросах, вы должны хранить ключ API в месте, где он может быть получен прокси-сервером API во время выполнения. Одним из мест, доступных для хранения ключей API, является карта «ключ/значение». См. политику операций с картами ключевых значений .
Вы можете использовать тип политики AssignMessage, чтобы добавить ключ API в качестве заголовка HTTP, параметра запроса или элемента полезных данных в исходящий запрос. См. политику назначения сообщений .
Учетные данные клиента OAuth
Учетные данные клиента OAuth можно использовать для добавления уровня возможности отзыва к ключам API. Если ваши серверные службы поддерживают учетные данные клиента OAuth, вы можете настроить прокси-сервер API для предоставления токена доступа к учетным данным клиента для каждого запроса.
Прокси-сервер API должен быть настроен для выполнения вызова для получения токена доступа из конечной точки вашего токена. Прокси-сервер API также необходим для кэширования токена доступа, чтобы предотвратить получение нового токена доступа для каждого вызова.
Для реализации учетных данных исходящего клиента можно использовать ряд подходов.
Вы можете изменить этот пример, чтобы вызвать конечную точку вашего токена для получения токена доступа. В этом примере используется JavaScript для прикрепления токена к исходящему запросу в виде заголовка авторизации HTTP. Для этой цели вы также можете использовать политику назначения сообщений .
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. Дополнительные сведения см. в разделе Общие сведения о поддержке Edge для модулей Node.js.