Sécuriser les API à l’aide de certificats
Les certificats peuvent servir à fournir une authentification mutuelle TLS entre le client et la passerelle API. Vous pouvez configurer la passerelle Gestion des API pour autoriser uniquement les demandes assorties de certificats contenant une empreinte spécifique. L’autorisation au niveau de la passerelle est gérée par le biais de stratégies de trafic entrant.
Authentification du client TLS
Avec l’authentification client TLS, la passerelle Gestion des API peut inspecter le certificat contenu dans la demande client et vérifier des propriétés comme :
Propriété | Description |
---|---|
Autorité de certification | Autoriser uniquement les certificats signés par une autorité de certification particulière |
Empreinte | Autoriser les certificats contenant une empreinte spécifiée |
Objet | Autoriser uniquement les certificats avec un objet spécifié |
Date d’expiration | N’autorisez pas les certificats expirés |
Ces propriétés ne sont pas mutuellement exclusives et vous pouvez les combiner pour former vos propres exigences de stratégie. Par exemple, vous pouvez spécifier que le certificat passé dans la requête est signé et qu’il n’est pas expiré.
Les certificats clients sont signés pour garantir qu’ils ne sont pas falsifiés. Quand un partenaire vous envoie un certificat, vérifiez qu’il provient bien de lui et non d’un imposteur. Il existe deux moyens courants de vérifier un certificat :
- Vérifiez qui a émis le certificat. Si l’émetteur est une autorité de certification de confiance, vous pouvez utiliser le certificat. Vous pouvez configurer les autorités de certification approuvées dans le portail Azure pour automatiser ce processus.
- Si le certificat est émis par le partenaire, vérifiez qu’il vient bien de lui. Par exemple, s’il délivre le certificat en personne, vous êtes sûr de son authenticité. Ce type de certificat est appelé certificat auto-signé.
Acceptation des certificats clients dans le niveau Consommation
Le niveau Consommation dans Gestion des API est conçu pour être conforme aux principaux de conception serverless. Si vous générez vos API à partir de technologies serverless, comme Azure Functions, ce niveau est parfaitement adapté. Dans le niveau Consommation, vous devez activer explicitement l’utilisation des certificats clients, ce que vous pouvez faire dans la page Domaines personnalisés. Cette étape n’est pas nécessaire dans les autres niveaux.
Stratégies d’autorisation de certificat
Créez ces stratégies dans le fichier de stratégie de traitement du trafic entrant au sein de la passerelle Gestion des API :
Vérifier l’empreinte d’un certificat client
Chaque certificat client inclut une empreinte, à savoir un code de hachage, calculée à partir d’autres propriétés de certificat. L’empreinte permet de s’assurer que les valeurs incluses dans le certificat n’ont pas été modifiées depuis son émission par l’autorité de certification. Vous pouvez vérifier l’empreinte dans votre stratégie. L’exemple suivant vérifie l’empreinte du certificat passé dans la demande :
<choose>
<when condition="@(context.Request.Certificate == null || context.Request.Certificate.Thumbprint != "desired-thumbprint")" >
<return-response>
<set-status code="403" reason="Invalid client certificate" />
</return-response>
</when>
</choose>
Vérifier l’empreinte par rapport à des certificats chargés sur Gestion des API
Dans l’exemple précédent, une seule empreinte doit fonctionner et donc un seul certificat doit être validé. En règle générale, chaque client ou partenaire peut passer un certificat différent avec une empreinte différente. Pour prendre en charge ce scénario, obtenez les certificats auprès de vos partenaires et utilisez la page Certificats clients dans le portail Azure pour les charger sur la ressource Gestion des API. Ensuite, ajoutez ce code à votre stratégie :
<choose>
<when condition="@(context.Request.Certificate == null || !context.Request.Certificate.Verify() || !context.Deployment.Certificates.Any(c => c.Value.Thumbprint == context.Request.Certificate.Thumbprint))" >
<return-response>
<set-status code="403" reason="Invalid client certificate" />
</return-response>
</when>
</choose>
Vérifier l’émetteur et l’objet d’un certificat client
Cet exemple vérifie l’émetteur et l’objet du certificat passé dans la demande :
<choose>
<when condition="@(context.Request.Certificate == null || context.Request.Certificate.Issuer != "trusted-issuer" || context.Request.Certificate.SubjectName.Name != "expected-subject-name")" >
<return-response>
<set-status code="403" reason="Invalid client certificate" />
</return-response>
</when>
</choose>