Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info
La sécurité du dernier kilomètre protège les services de backend mis en proxy par les services d'API. Le principal objectif de la sécurité du dernier kilomètre est d'empêcher les attaques dites "end-run", où le développeur d'une application découvre l'URL d'un service de backend et contourne tout proxy d'API pour accéder directement à l'URL du backend.
Voici les principales options de configuration de la sécurité du dernier kilomètre :
- TLS/SSL client
- Authentification sortante
- Module tls Node.js
TLS/SSL client
Le mécanisme principal de sécurisation du dernier kilomètre est le protocole TLS/SSL client, également appelé "authentification mutuelle".
Consultez la page Configurer TLS de la périphérie au backend (cloud et cloud privé).
Authentification sortante
La sécurité du dernier kilomètre peut également être appliquée en obligeant le proxy d'API à présenter un identifiant au service de backend.
Par exemple, vous pouvez souhaiter qu'un proxy d'API présente une clé API à votre service de backend. Vous pouvez également souhaiter qu'un proxy d'API obtienne et présente un jeton d'accès d'identifiants client OAuth.
Clé API
Les clés API peuvent être appliquées aux requêtes sortantes des proxys d'API vers les services de backend. Cela suppose que le service de backend est une API capable d'émettre et de valider des clés API.
Si vous configurez un proxy d'API pour présenter une clé API lors de requêtes sortantes, vous devez stocker cette clé à un emplacement où elle peut être récupérée par le proxy d'API au moment de l'exécution. Un emplacement disponible pour stocker des clés API est un mappage clé-valeur. Consultez la section Règle des opérations de mappage clé-valeur.
Vous pouvez utiliser le type de règle AssignMessage pour ajouter la clé API en tant qu'en-tête HTTP, paramètre de requête ou élément de charge utile à la requête sortante. Consultez la section sur la règle AssignMessage.
Identifiants clients OAuth
Les identifiants clients OAuth peuvent être utilisés pour ajouter une couche de révocabilité aux clés API. Si vos services de backend sont compatibles avec les identifiants clients OAuth, vous pouvez configurer un proxy d'API pour afficher un jeton d'accès aux identifiants clients pour chaque requête.
Le proxy d'API doit être configuré pour exécuter un appel afin d'obtenir le jeton d'accès à partir du point de terminaison de votre jeton. Le proxy d'API est également tenu de mettre en cache le jeton d'accès, pour l'empêcher d'obtenir un nouveau jeton d'accès pour chaque appel.
Il existe un certain nombre d'approches permettant de mettre en œuvre des identifiants clients sortants.
Vous pouvez modifier cet exemple pour appeler votre point de terminaison de jeton afin d'obtenir un jeton d'accès. Cet exemple utilise JavaScript pour associer le jeton à la requête sortante en tant qu'en-tête d'autorisation HTTP. Vous pouvez également utiliser la règle d'attribution de message à cette fin.
SAML
Le type de règle GenerateSAMLAssertion peut être utilisé pour associer une assertion SAML à un message de requête XML sortant, du proxy d'API à un service de backend. Cela permet au service de backend de procéder à l'authentification et l'autorisation sur les requêtes reçues des proxys d'API.
Consultez la page règles SAMLAssertion.
Node.js
Si la cible de votre proxy d'API est une application Node.js, vous pouvez utiliser le module tls de Node.js pour créer des connexions sécurisées aux services backend. Vous effectuez des requêtes sortantes avec le module tls de la même manière que vous le feriez normalement dans Node.js. En gros, vous devez ajouter des clés et des certificats côté client (fichiers .pem) au répertoire resources/node, puis les charger dans votre script. Pour en savoir plus sur l'utilisation du module tls et de ses méthodes, consultez la documentation du module TLS Node.js. Pour en savoir plus, consultez la section Comprendre la prise en charge des modules Node.js par Edge.