Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info
Transport Layer Security (TLS), dont le prédécesseur est Secure Sockets Layer (SSL), est la technologie de sécurité standard permettant d'établir un lien chiffré entre un serveur Web et un client Web, tel qu'un navigateur ou une application. Un lien chiffré garantit que toutes les données transmises entre le serveur et le client restent privées. Pour utiliser TLS, un client envoie une requête sécurisée au serveur à l'aide du protocole HTTPS chiffré au lieu du protocole HTTP non chiffré.
Edge est compatible avec le protocole TLS unidirectionnel et bidirectionnel, que ce soit dans un déploiement cloud ou sur site (pour connaître les versions de TLS compatibles, consultez la section Logiciels et versions compatibles). Le TLS à sens unique permet au client TLS de vérifier l'identité du serveur TLS. Par exemple, une application exécutée sur un téléphone Android (client) peut valider l'identité des API Edge (serveur).
Apigee est également compatible avec une forme d'authentification plus sécurisée à l'aide du protocole TLS bidirectionnel ou client. Vous implémentez généralement le TLS bidirectionnel pour améliorer la sécurité de bout en bout et protéger vos données contre les attaques client telles que l'usurpation d'identité ou les attaques de l'homme du milieu. Dans le TLS à deux voies, le client vérifie l'identité du serveur, puis le serveur vérifie l'identité du client.
Terminologie TLS
Avant de configurer TLS, vous devez connaître les termes et concepts importants suivants:
|
Terme |
Définition |
|---|---|
|
CA |
Autorité de certification. Entité de confiance, telle que Symantec ou VeriSign, utilisée pour émettre des certificats et valider leur authenticité. Un type de certificat, appelé certificat autosigné, ne nécessite pas d'autorité de certification. |
|
Chaîne de certificats |
Vous ne disposez souvent pas d'un certificat signé par la clé privée racine de votre autorité de certification. À la place, vous disposez de votre certificat ainsi que d'un ou de plusieurs certificats intermédiaires qui forment une chaîne. Le dernier certificat intermédiaire de la chaîne est généralement signé par la clé privée racine de l'autorité de certification. |
|
CSR |
Demande de signature de certificat. Une requête de signature de certificat est un fichier généré sur le serveur TLS en fonction de la clé privée. La CSR contient la clé publique et d'autres informations telles que le nom, l'emplacement et le nom de domaine de l'organisation. L'autorité de certification signe la CSR pour créer un certificat TLS. Vous générez généralement une requête de signature de certificat lorsque vous disposez d'un certificat expiré et que vous souhaitez le renouveler. |
| DER |
Distinguished Encoding Rules (DER) Le format DER est une forme binaire d'un certificat au lieu du format PEM ASCII. Il peut parfois avoir l'extension .der, mais il a souvent l'extension .cer. Le seul moyen de faire la différence entre un fichier .cer DER et un fichier .cer PEM est d'ouvrir le fichier dans un éditeur de texte et de rechercher les instructions |
| Alias de clé |
Un alias de clé identifie de manière unique une entrée de keystore (certificat TLS et clé privée correspondante) dans le keystore.
Dans Apigee Edge, |
|
Keystore |
Un keystore est un dépôt qui contient un ou plusieurs certificats TLS et une clé privée correspondante qui permet d'identifier l'entité lors d'un handshake TLS entre un client et un serveur. Sur la connexion nord-sud, le routeur agit en tant que serveur et son certificat est stocké dans le keystore d'Apigee Edge. Sur la connexion southbound, le processeur de messages agit en tant que client et le serveur backend en tant que serveur. Le certificat client et sa clé privée sont stockés dans le keystore d'Apigee Edge. |
| 7 milliards de dollars |
Le format PKCS #7 ou P7B est généralement stocké au format ASCII Base64 et porte l'extension de fichier .p7b ou .p7c. Les certificats P7B contiennent des instructions |
|
PEM |
Le format PEM (Privacy Enhanced Mail) est un format ASCII basé sur du texte qui est un codage base64 du format DER (Distinguished Encoding Rules) binaire. Les certificats PEM peuvent être ouverts dans n'importe quel éditeur de texte. Le contenu du certificat est délimité entre les instructions Il est conforme au format X.509 pour stocker un certificat, une chaîne de certificats ou une clé privée. Si votre certificat ou votre clé privée n'est pas défini par un fichier PEM, vous pouvez le convertir en fichier PEM à l'aide d'utilitaires tels qu'OpenSSL. |
| PKCS #12/PFX | Le format PKCS #12 ou PFX est un format binaire permettant de stocker le certificat du serveur, les éventuels certificats intermédiaires et la clé privée dans un seul fichier chiffrable. Les fichiers PFX ont généralement des extensions telles que .pfx et .p12. Les fichiers PFX sont généralement utilisés sur les machines Windows pour importer et exporter des certificats et des clés privées. |
|
Clé privée |
Utilisé sur le serveur TLS pour déchiffrer les données. Seul le serveur TLS dispose de la clé privée. Elle n'est pas partagée avec les clients TLS. |
|
Clé publique |
Permet de chiffrer les données envoyées d'un client TLS à un serveur TLS. La clé publique est incluse dans le certificat. Tous les clients TLS disposent d'une copie de la clé publique du serveur. |
| References | Les références fournissent un niveau d'indirection pour les keystores. Par conséquent, les modifications apportées aux keystores ne nécessitent pas de mise à jour de l'hôte virtuel tant que la même référence et le même alias de clé sont conservés. Vous pouvez ainsi effectuer ces modifications vous-même et réduire les dépendances avec l'équipe d'assistance Apigee. |
|
Certificat autosigné |
Certificat non signé par une autorité de certification approuvée. L'émetteur et le sujet sont identiques. Ils sont signés avec la clé privée correspondant à la clé publique qu'ils contiennent. |
|
SNI |
Indication du nom du serveur. Permet de diffuser plusieurs cibles HTTPS à partir de la même adresse IP et du même port sans que ces cibles aient besoin d'utiliser le même certificat. |
|
Certificat TLS |
Fichier numérique qui identifie une entité dans une transaction TLS. Un certificat, ou cert, peut être utilisé pour identifier le serveur TLS et le client TLS, en fonction de la configuration TLS. |
|
Truststore |
Contient les certificats de confiance d'un client TLS utilisé pour valider le certificat d'un serveur TLS présenté au client. Ces certificats sont généralement des certificats autosignés ou des certificats qui ne sont pas signés par une autorité de certification de confiance. Dans la connexion nord-sud, les certificats de l'application cliente sont stockés dans le truststore d'Apigee Edge. Cette opération n'est requise que si vous avez configuré un protocole TLS bidirectionnel entre le client et Apigee. Sur la connexion southbound, les certificats du serveur backend sont stockés dans le truststore d'Apigee Edge. Cela est nécessaire si vous souhaitez vérifier le certificat du backend dans Apigee Edge dans une communication TLS unidirectionnelle ou bidirectionnelle entre Apigee Edge et le serveur de backend. Apigee Edge ne dispose pas d'un objet truststore distinct. Par conséquent, les truststores sont créés en tant qu'objet keystore, mais référencés en tant que truststore partout où ils sont utilisés (par exemple, dans l'hôte virtuel, les points de terminaison cibles, les serveurs cibles, etc.). |
| Hôte virtuel |
L'hôte virtuel représente le point de terminaison de l'API Apigee pour les applications clientes. Il s'agit d'une entité qui permet d'héberger plusieurs noms de domaine (avec une gestion distincte de chaque nom) sur un seul serveur (ou pool de serveurs). Cela permet à un serveur de partager ses ressources, telles que la mémoire et les cycles de processeur, sans que tous les services fournis aient besoin d'utiliser le même nom d'hôte. Un hôte virtuel peut diffuser du trafic HTTP ou HTTPS (compatible SSL). Un hôte virtuel compatible avec SSL peut être configuré en mode TLS unidirectionnel ou bidirectionnel. Il est configuré avec les éléments suivants:
|
TLS/SSL à sens unique
La figure suivante illustre le handshake TLS/SSL pour l'authentification à sens unique entre un client TLS et un serveur TLS:
Dans une configuration TLS unidirectionnelle, le handshake se déroule comme suit:
- Le client envoie une requête de session au serveur.
- Le serveur répond avec un certificat, qui contient sa clé publique. Ce certificat provient du keystore du serveur, qui contient également la clé privée du serveur. La clé privée n'est jamais envoyée au client.
- Pour un certificat signé, le client utilise un truststore contenant des certificats de serveur et des clés publiques pour valider que la chaîne de certificats est signée par une autorité de certification (CA) de confiance.
- Le client et le serveur échangent plusieurs autres messages pour valider les clés.
- Le client commence le transfert de données TLS avec le serveur.
La figure suivante montre un handshake TLS/SSL à l'aide d'un truststore facultatif sur le client:
Si le serveur TLS utilise un certificat autosigné ou un certificat qui n'est pas signé par une autorité de certification approuvée, vous devez créer un truststore sur le client. Le client remplit son truststore avec les certificats de serveur et les clés publiques qu'il approuve. Lorsque le client reçoit un certificat, le certificat entrant est ensuite validé par rapport aux certificats de son truststore.
Dans le protocole TLS unidirectionnel, Edge peut être le serveur ou le client, comme suit:
-
Edge en tant que serveur TLS
Edge est le serveur qui héberge le point de terminaison TLS, où le point de terminaison TLS correspond à un proxy d'API déployé sur un hôte virtuel. Le client est une application qui tente d'accéder au proxy d'API. Dans ce scénario, Edge dispose du keystore contenant le certificat et la clé privée.
-
Edge en tant que client TLS
Edge agit en tant que client qui accède à un service de backend. Dans ce cas, le service de backend correspond au serveur hébergeant un point de terminaison TLS. Par conséquent, le serveur backend dispose d'un keystore contenant son certificat et sa clé privée.
TLS bidirectionnel
La figure suivante illustre le handshake TLS/SSL pour l'authentification TLS bidirectionnelle entre un client et un serveur:
Dans le TLS bidirectionnel, le handshake se déroule comme suit:
- Le client et le serveur disposent chacun de leur propre keystore. Le keystore du client contient son certificat et sa clé privée, et le keystore du serveur contient son certificat et sa clé privée.
- Le serveur TLS présente son certificat au client TLS pour s'authentifier. Le client vérifie ensuite l'identité du serveur avant d'envoyer son certificat au serveur.
- Le client TLS présente son certificat au serveur TLS pour s'authentifier auprès du serveur.
La figure suivante montre le handshake TLS à l'aide d'un truststore facultatif:
Dans ce scénario, l'établissement de la liaison est le suivant:
- Si le serveur TLS utilise un certificat autosigné ou un certificat qui n'est pas signé par une autorité de certification approuvée, vous devez créer un truststore sur le client. Le client dispose d'une copie du certificat du serveur dans son truststore. Lors du handshake TLS, le client compare le certificat de son truststore au certificat envoyé par le serveur pour vérifier l'identité du serveur.
- Si le client TLS utilise un certificat autosigné ou un certificat qui n'est pas signé par une autorité de certification approuvée, vous devez créer un magasin de confiance sur le serveur.Le serveur dispose d'une copie du certificat du client dans son magasin de confiance. Lors de l'établissement d'une session TLS, le serveur compare le certificat de son truststore au certificat envoyé par le client pour vérifier l'identité du client.
Le client ou le serveur, ou les deux, peuvent utiliser un truststore.
Dans le protocole TLS bidirectionnel, Edge peut être le serveur ou le client, comme suit:
-
Edge en tant que serveur
Edge est le serveur qui héberge le point de terminaison TLS, où le point de terminaison TLS correspond à un proxy d'API. Le client est une application qui tente d'accéder au proxy d'API. Dans ce scénario, Edge dispose d'un keystore contenant le certificat et la clé privée, et nécessite un truststore contenant le certificat et la chaîne de certification du client.
-
Edge en tant que client
Edge agit en tant que client qui accède à un service de backend. Dans ce cas, le service de backend correspond au serveur hébergeant le point de terminaison TLS. Le serveur backend dispose donc d'un keystore contenant son certificat et sa clé privée.
Edge doit également définir un keystore contenant le certificat nécessaire pour se valider auprès du service backend, et éventuellement un truststore contenant le certificat du serveur backend si le serveur utilise un certificat autosigné ou un certificat qui n'est pas signé par une autorité de certification approuvée.
N'oubliez pas qu'Edge est suffisamment flexible pour prendre en charge le TLS à deux voies, quelle que soit la manière dont vous décidez de le configurer.
Compatibilité SNI
Edge prend en charge l'utilisation de l'indication du nom du serveur (SNI) des proxys d'API vers Edge, où Edge agit en tant que serveur TLS, et d'Edge vers les points de terminaison cibles, où Edge agit en tant que client TLS, à la fois dans les installations Cloud et dans les installations de cloud privé.
Avec le SNI, qui est une extension de TLS/SSL, plusieurs cibles HTTPS peuvent être diffusées à partir de la même adresse IP et du même port sans que ces cibles aient besoin d'utiliser le même certificat.
Pour savoir comment activer le SNI pour une installation sur site, consultez la section Utiliser le SNI avec Edge.
Dans les deux sens
Dans Apigee, le terme "nord-sud" fait référence au point de terminaison de l'API utilisé par les applications clientes pour appeler le proxy d'API. En règle générale, le routeur est le point d'entrée dans Apigee Edge et il gère les requêtes entrantes vers Apigee Edge. Par conséquent, dans Apigee, le point de terminaison utilisé pour la communication entre l'application cliente et Apigee Edge (routeur) est appelé Northbound.
Dans Apigee, le trafic Southbound fait référence au point de terminaison cible qu'Apigee utilise pour communiquer avec le serveur backend. Par conséquent, dans Apigee, le point de terminaison utilisé pour la communication entre Apigee Edge (processeur de messages) et le serveur de backend est appelé Southbound. Le processeur de messages est un composant d'Apigee Edge qui transfère les requêtes API vers les serveurs cibles backend.
La figure suivante illustre les connexions Northbound et Southbound pour Apigee Edge:
