Ajout de la prise en charge de mTLS aux déploiements d'API
Découvrez comment utiliser une politique de demande pour ajouter la prise en charge de mTLS aux déploiements d'API avec la passerelle d'API.
Les passerelles d'API que vous créez avec le service de passerelle d'API sont sécurisées au moyen du chiffrement et de la vérification TLS. Une passerelle d'API présente un certificat de serveur à un client d'API lors d'une liaison TLS, ce qui permet au client d'API de valider l'authenticité de la passerelle d'API. Le processus d'authentification du client d'API de la passerelle d'API est appelé TLS unidirectionnel.
Dans de nombreux cas, vous ne voulez autoriser que les clients d'API authentifiés à accéder à une API. Dans ces situations, vous voulez que la passerelle d'API valide l'authenticité d'un client d'API, en vérifiant le certificat TLS présenté par le client d'API. Le processus d'authentification du client d'API par la passerelle d'API est appelé TLS mutuel (mTLS).
Avec mTLS, la passerelle d'API et le client d'API échangent et vérifient les certificats lors de l'établissement d'une liaison TLS. La passerelle d'API vérifie le certificat TLS présenté par le client d'API à l'aide de certificats racines d'autorité de certification personnalisée et d'ensembles AC personnalisés de certificats racines et intermédiaires. Les autorités de certification et les ensembles AC personnalisés sont stockés dans le magasin de certificats SSL de la passerelle d'API, ainsi qu'un ensemble AC par défaut qui contient des certificats d'autorités de certification publiques connues. Notez que dans une liaison mTLS, la passerelle d'API utilise uniquement des autorités de certification personnalisées et des ensembles AC personnalisés pour vérifier les certificats de client d'API. La passerelle d'API n'utilise pas l'ensemble AC par défaut pour vérifier les certificats de client d'API. Ainsi, si vous voulez qu'une passerelle d'API prenne en charge mTLS, vous devez ajouter des autorités de certification et des ensembles AC personnalisés au magasin de certificats SSL de la passerelle d'API (voir Personnalisation des magasins de certificats SSL pour la vérification des certificats TLS).
Pour un contrôle supplémentaire, vous pouvez également spécifier que les certificats présentés par les clients d'API à une passerelle d'API doivent contenir des valeurs particulières dans les champs Adresse de courriel, URL ou Nom de domaine du certificat. Si vous spécifiez des valeurs pour ces champs lors de la configuration de mTLS pour une passerelle d'API, la passerelle d'API rejettera les demandes des clients d'API présentant des certificats qui ne les contiennent pas. Si vous ne spécifiez pas de valeurs pour ces champs lors de la configuration de mTLS, la passerelle d'API acceptera toutes les demandes des clients d'API fournissant que le certificat est valide. Vous pouvez spécifier jusqu'à 10 valeurs par défaut pour chaque déploiement d'API (vous pouvez modifier cette limite interne).
Après l'établissement d'une liaison mTLS entre la passerelle d'API et un client d'API, une version encodée en Base64 du certificat présenté par le client d'API est enregistrée dans la table de contexte request.cert
en tant que variable de contexte nommée request.cert[client_base64]
. Lors de la définition d'un déploiement d'API, vous pouvez référencer le certificat au format ${request.cert[client_base64]}
(voir Ajout de variables de contexte aux politiques et aux définitions d'élément dorsal HTTP). Notez que si un client d'API présente un certificat TLS dont la taille est supérieure à 8 Ko (après avoir été encodé en Base64), le certificat n'est pas enregistré en tant que variable de contexte.
Vous utilisez une politique de demande dans la spécification de déploiement d'API pour ajouter la prise en charge mTLS à une API (voir Ajout de politiques de demande et de réponse aux spécifications de déploiement d'API). La politique de demande mTLS s'applique globalement à toutes les routes d'une spécification de déploiement d'API.
- Si un client d'API présente un certificat TLS à une passerelle d'API et que le déploiement d'API n'est pas activé pour mTLS, la passerelle d'API ignore simplement le certificat TLS qui a été présenté. La variable de contexte
request.cert[client_base64]
n'est pas définie dans cette situation. - Si une passerelle d'API ne parvient pas à valider le certificat TLS présenté par un client d'API, la passerelle d'API rejette la demande avec un code de réponse de statut d'erreur HTTP 401.
- Si une passerelle d'API utilise un ensemble AC personnalisé pour valider le certificat TLS présenté par un client d'API, au plus trois certificats AC peuvent être parcourus à tout moment dans la chaîne de certificats lors de la validation. En d'autres termes, pour être valide, un certificat d'autorité de certification dans la chaîne doit être signé directement par une autorité de certification personnalisée présente dans le magasin de certificats de la passerelle d'API, ou ne pas être à plus de deux certificats intermédiaires d'un certificat qui a été signé par une telle autorité de certification personnalisée. Communiquez avec nous si vous voulez autoriser d'autres certificats intermédiaires.
Vous pouvez ajouter une politique de demande mTLS à une spécification de déploiement d'API comme suit :
- En utilisant la console.
- En modifiant un fichier JSON.
Utilisation de la console pour ajouter des politiques de demande mTLS
Pour ajouter une politique de demande mTLS à une spécification de déploiement d'API à l'aide de la console :
-
Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option À partir de zéro et entrez les détails dans la page Informations de base.
Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.
-
Dans la section Politiques de demande d'API de la page Informations de base, sous Mutual-TLS, sélectionnez l'option Activer mTLs et spécifiez éventuellement :
- Nom de remplacement du sujet (SAN) / Nom commun : Valeurs qui doivent apparaître dans un ou plusieurs des champs suivants du certificat présenté par le client d'API pour que la passerelle d'API accepte les demandes du client :
- Adresse courriel
- URL
- Nom de domaine
Par exemple
example.com
. Vous pouvez spécifier jusqu'à 10 valeurs par défaut (vous pouvez modifier cette limite interne). La validation n'est pas sensible à la casse.Vous pouvez inclure un caractère générique astérisque (*) au début et/ou à la fin de chaque valeur, pour représenter zéro, un ou plusieurs caractères. Vous ne pouvez pas inclure un caractère générique d'astérisque au milieu de la valeur. Par exemple :
*.example.com
correspond àserver.example.com
server.example.*
correspond àserver.example.com
*.example.*
correspond àserver.example.com
server.*.com
ne correspond pas àserver.example.com
, car le caractère générique ne peut pas se trouver au milieu de la valeur
Si vous spécifiez des valeurs lors de la configuration de mTLS pour un déploiement d'API, la passerelle d'API rejettera les demandes des clients d'API présentant des certificats qui ne les contiennent pas. Si vous ne spécifiez pas de valeurs lors de la configuration de mTLS, la passerelle d'API acceptera toutes les demandes des clients d'API fournissant le certificat valide.
- Nom de remplacement du sujet (SAN) / Nom commun : Valeurs qui doivent apparaître dans un ou plusieurs des champs suivants du certificat présenté par le client d'API pour que la passerelle d'API accepte les demandes du client :
- Sélectionnez Vérifier pour vérifier les détails que vous avez entrés pour le déploiement d'API.
- Sélectionnez Créer ou enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
- (Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).
Modification d'un fichier JSON pour ajouter des politiques de demande mTLS
Pour ajouter une politique de demande mTLS à une spécification de déploiement d'API dans un fichier JSON :
-
Dans votre éditeur JSON préféré, modifiez la spécification de déploiement d'API existante à laquelle vous souhaitez ajouter la prise en charge de mTLS ou créez une spécification de déploiement d'API (voir Création d'une spécification de déploiement d'API).
Par exemple, la spécification de déploiement d'API de base suivante définit une simple fonction sans serveur Hello World du service des fonctions pour OCI en tant qu'élément dorsal unique :
{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
-
Pour spécifier une politique de demande mTLS qui s'applique globalement à toutes les routes d'un déploiement d'API :
-
Insérez une section
requestPolicies
avant la sectionroutes
, si elle n'existe pas déjà. Par exemple :{ "requestPolicies": {}, "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
-
Ajoutez la politique
mutualTLS
suivante à la nouvelle sectionrequestPolicies
pour l'appliquer globalement à toutes les routes d'un déploiement d'API :{ "requestPolicies": { "mutualTls":{ "isVerifiedCertificateRequired": true|false, "allowedSans": [<list-of-values>] } }, "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
où :
"isVerifiedCertificateRequired": true|false
esttrue
oufalse
, indiquant si mTLS est activé pour le déploiement d'API. Si vous ne spécifiez pas de valeur, la valeur par défaut estfalse
."allowedSans": [<list-of-values>]
est une liste facultative séparée par des virgules de valeurs qui doit apparaître dans un ou plusieurs des champs suivants du certificat présenté par le client d'API pour que la passerelle d'API accepte les demandes du client :- Adresse courriel
- URL
- Nom de domaine
Par exemple
example.com
. Vous pouvez spécifier jusqu'à 10 valeurs par défaut (vous pouvez modifier cette limite interne). La validation n'est pas sensible à la casse.Vous pouvez inclure un caractère générique astérisque (*) au début et/ou à la fin de chaque valeur, pour représenter zéro, un ou plusieurs caractères. Vous ne pouvez pas inclure un caractère générique d'astérisque au milieu de la valeur. Par exemple :
*.example.com
correspond àserver.example.com
server.example.*
correspond àserver.example.com
*.example.*
correspond àserver.example.com
server.*.com
ne correspond pas àserver.example.com
, car le caractère générique ne peut pas se trouver au milieu de la valeur
Si vous spécifiez des valeurs lors de la configuration de mTLS pour un déploiement d'API, la passerelle d'API rejettera les demandes des clients d'API présentant des certificats qui ne les contiennent pas. Si vous ne spécifiez pas de valeurs lors de la configuration de mTLS, la passerelle d'API acceptera toutes les demandes des clients d'API fournissant le certificat valide.
Par exemple :
{ "requestPolicies": { "mutualTls":{ "isVerifiedCertificateRequired": true, "allowedSans": [ "example.com", "example.co.uk" ] } }, "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
-
- Enregistrez le fichier JSON contenant la spécification de déploiement d'API.
-
Utilisez comme suit la spécification de déploiement d'API lorsque vous créez ou mettez à jour un déploiement d'API :
- En spécifiant le fichier JSON dans la console lorsque vous sélectionnez l'option Charger une API existante.
- En spécifiant le fichier JSON dans une demande à l'API REST du service Passerelle d'API.
Pour plus d'informations, voir Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et Mise à jour d'une passerelle d'API.
- (Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).