Vous consultez la documentation Apigee Edge.
Accéder à la documentation d'Apigee X en savoir plus
Le protocole TLS (Transport Layer Security), dont le prédécesseur est SSL (Secure Socket Layer), 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 chiffré HTTPS, au lieu du protocole non chiffré HTTP.
Edge est compatible avec les protocoles TLS unidirectionnels et bidirectionnels dans le cloud et les déploiements sur site (pour connaître les versions compatibles de TLS, consultez la section Logiciels et versions compatibles). Le protocole TLS unidirectionnel 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 vérifier l'identité des API Edge (serveur).
Apigee prend également en charge une forme d'authentification plus forte utilisant le protocole TLS bidirectionnel, ou client,. Le protocole TLS bidirectionnel est généralement mis en œuvre pour améliorer la sécurité de bout en bout et protéger vos données contre les attaques client telles que le spoofing de client ou les attaques man-in-the-middle. Avec le protocole TLS bidirectionnel, le client vérifie l'identité du serveur, puis le serveur vérifie l'identité du client.
Terminologie TLS
Vous devez connaître les termes et concepts importants suivants avant de configurer TLS:
|
Terme |
Définition |
|---|---|
|
Canada |
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 |
Souvent, vous n'avez pas de certificat signé par la clé privée racine de votre autorité de certification. À la place, vous disposez de votre certificat avec un ou 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. |
|
Conseiller clientèle |
Demande de signature de certificat. Une requête de signature de certificat est un fichier généré sur le serveur TLS à partir de la clé privée. La requête de signature de certificat 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 requête de signature de certificat pour créer un certificat TLS. En général, vous générez une requête de signature de certificat lorsque votre certificat a expiré et que vous souhaitez le renouveler. |
| DER |
Règles d'encodage distinctes. Le format DER est une forme binaire de certificat, et non le format PEM ASCII. Il a parfois l'extension .der, mais il a souvent l'extension .cer. Le seul moyen de distinguer un fichier DER .cer d'un fichier PEM .cer consiste à l'ouvrir dans un éditeur de texte, puis à 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 northbound, le routeur agit en tant que serveur et son certificat est stocké dans le keystore d'Apigee Edge. Sur la connexion limitée au sud, 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. |
| Pixel 7B |
Le format PKCS #7 ou P7B est généralement stocké au format ASCII en base64 et porte l'extension .p7b ou .p7c. Les certificats P7B contiennent des instructions |
|
PEM |
Le format PEM (Privacy Advanced Mail) est un format texte ASCII qui est un encodage Base64 au format DER (Distinguished Encoding Rules). Les certificats PEM peuvent être ouverts dans n'importe quel éditeur de texte, et leur contenu est délimité par les instructions Il est conforme au format X.509 pour le stockage d'un certificat, d'une chaîne de certificats ou d'une clé privée. Si votre certificat ou 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, tous les certificats intermédiaires et la clé privée dans un fichier chiffré. 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 des données. Seul le serveur TLS dispose de la clé privée. Elle n'est pas partagée avec les clients TLS. |
|
Clé publique |
Utilisé pour chiffrer les données envoyées depuis un client TLS vers un serveur TLS. La clé publique est incluse dans le certificat. Tous les clients TLS possèdent 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 au keystore ne nécessitent pas de mise à jour d'hôte virtuel tant que la même référence et le même alias de clé sont conservés. Vous pouvez ainsi exploiter ces modifications en libre-service 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 la diffusion de plusieurs cibles HTTPS à partir de la même adresse IP et du même port sans exiger que ces cibles utilisent 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 des certificats de confiance sur 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. Sur la connexion northbound, 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 limitée au sud, les certificats du serveur backend sont stockés dans le magasin de confiance d'Apigee Edge. Cela est nécessaire si vous souhaitez vérifier le certificat du backend dans Apigee Edge dans le cadre d'une communication TLS unidirectionnelle ou bidirectionnelle entre Apigee Edge et le serveur backend. Apigee Edge ne possède pas d'objet truststore distinct. Par conséquent, les Truststores sont créés en tant qu'objets keystore, mais référencés en tant que Truststores partout où ils sont utilisés (par exemple, dans les hôtes virtuels, 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 un traitement distinct de chaque nom) sur un seul serveur (ou un seul 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 utilisent le même nom d'hôte. Un hôte virtuel peut diffuser du trafic HTTP ou HTTPS (compatible avec SSL). Un hôte virtuel SSL peut être configuré en mode TLS unidirectionnel ou bidirectionnel. Il est configuré comme suit:
|
TLS/SSL à sens unique
La figure suivante illustre le handshake TLS/SSL pour l'authentification unidirectionnelle entre un client TLS et un serveur TLS:
Dans une configuration TLS unidirectionnelle, le handshake se produit comme suit:
- Le client envoie une demande 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 vérifier que la chaîne de certificats est signée par une autorité de certification 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 illustre un handshake TLS/SSL utilisant un Truststore facultatif sur le client:
Si le serveur TLS utilise un certificat autosigné ou un certificat non signé par une autorité de certification approuvée, vous créez 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, celui-ci est ensuite validé par rapport aux certificats de son magasin de confiance.
Dans le protocole TLS unidirectionnel, Edge peut être soit le serveur, soit le client, comme suit:
-
Edge en tant que serveur TLS
Edge est le serveur hébergeant 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. Le serveur backend dispose donc d'un keystore qui contient 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 protocole TLS bidirectionnel, le handshake se présente comme suit:
- Le client et le serveur possèdent tous deux leurs propres keystores. Le keystore du client contient son certificat et sa clé privée, tandis que 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 illustre le handshake TLS à l'aide d'un Truststore facultatif:
Dans ce scénario, le handshake se présente comme suit:
- Si le serveur TLS utilise un certificat autosigné ou un certificat non signé par une autorité de certification approuvée, vous créez un magasin de confiance 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 magasin de confiance au certificat envoyé par le serveur afin de vérifier l'identité du serveur.
- Si le client TLS utilise un certificat autosigné ou un certificat non signé par une autorité de certification de confiance, vous devez créer un Truststore sur le serveur.Le serveur possède une copie du certificat du client dans son Truststore. Lors du handshake TLS, le serveur compare le certificat de son magasin de confiance 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 soit le serveur, soit le client, comme suit:
-
Edge en tant que serveur
Edge est le serveur hébergeant le point de terminaison TLS, où celui-ci 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 magasin de clés de confiance contenant le certificat du client et la chaîne d'autorité de certification.
-
Edge en tant que client
Edge agit comme un 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 qui contient son certificat et sa clé privée.
Edge doit également définir un keystore contenant le certificat nécessaire pour s'authentifier auprès du service de backend et éventuellement un magasin de confiance contenant le certificat du serveur backend si celui-ci utilise un certificat autosigné ou un certificat non signé par une autorité de certification de confiance.
Il est important de se rappeler qu'Edge est suffisamment flexible pour prendre en charge le protocole TLS bidirectionnel, quelle que soit la façon dont vous décidez de le configurer.
Compatibilité SNI
Edge prend en charge l'utilisation de l'indication du nom du serveur (SNI, Server Name Indication) des proxys d'API vers Edge, où Edge agit en tant que serveur TLS, et d'Edge vers des points de terminaison cibles, où Edge agit en tant que client TLS, à la fois dans les installations de cloud et de cloud privé.
Avec SNI, 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 exiger que ces cibles utilisent le même certificat.
Pour plus d'informations sur l'activation de la SNI pour une installation sur site, consultez la section Utiliser SNI avec Edge.
Nord et sud
Dans Apigee, "northbound" fait référence au point de terminaison d'API utilisé par les applications clientes pour appeler le proxy d'API. Généralement, le routeur est le point d'entrée d'Apigee Edge et gère les requêtes entrantes adressées à 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é Nord.
Dans Apigee, "Direction Sud" fait référence au point de terminaison cible utilisé par Apigee 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 backend est appelé limité au sud. Le processeur de messages est un composant d'Apigee Edge qui sert de proxy pour les requêtes API aux serveurs cibles backend.
La figure suivante illustre les connexions nord et sud pour Apigee Edge:
