Implémenter la sécurité réseau de l’API et la protection contre les menaces

Terminée

Les stratégies d’authentification et d’autorisation contrôlent qui peut appeler vos API. Les contrôles de sécurité réseau traitent d’un risque différent : empêcher une consommation excessive, bloquer les demandes à partir d’emplacements non autorisés et réduire la surface d’attaque de la passerelle elle-même. Ces couches fonctionnent en même temps que les stratégies d’identité, pas au lieu d’elles.

Filtrer les demandes par adresse IP

La ip-filter stratégie autorise ou bloque les requêtes en fonction de l’adresse IP source de l’appelant ou de la plage CIDR (Classless Inter-Domain Routing). Elle évalue la requête pendant le traitement entrant, avant que toute redirection de routage ou de back end ne se produise.

Utilisez une liste d'autorisation lorsque les partenaires de Contoso Retail se connectent à partir de plages d’adresses IP fixes connues :

<inbound>
  <ip-filter action="allow">
    <address>203.0.113.0/24</address>
    <address>198.51.100.5</address>
  </ip-filter>
  <base />
</inbound>

Avec action="allow", Gestion des API accepte les requêtes uniquement à partir des adresses répertoriées et des plages CIDR et rejette tout le reste avec une 403 Forbidden réponse. Avec action="deny", les demandes des adresses répertoriées sont bloquées et toutes les autres adresses IP sources sont autorisées.

Pour le produit destiné aux partenaires de Contoso Retail, une liste d'autorisation des plages d'adresses IP de sortie partenaires limite qui peut atteindre le point de terminaison entrant de la passerelle. Même les appelants disposant d'une clé d'abonnement valide sont rejetés si leur adresse IP source ne figure pas sur la liste.

Note

La ip-filter stratégie évalue l’adresse IP telle que vue par la gestion des API. Si les appelants atteignent la passerelle via un proxy ou une passerelle NAT, gestion des API voit l’adresse IP du proxy, et non l’adresse IP du client d’origine. Comptez-y lors de la définition de votre liste verte : ajoutez la plage d’adresses IP de sortie du proxy plutôt que les adresses clientes internes individuelles.

Appliquer la limitation de débit et les contrôles de quota

La limitation du débit et les stratégies de quota contrôlent la quantité d’appelants pouvant consommer. Trois politiques complémentaires abordent différents horizons temporels et contrent des stratégies clés.

La rate-limit stratégie limite les appels par abonnement dans une fenêtre de temps courte :

<inbound>
  <rate-limit calls="100" renewal-period="60" />
  <base />
</inbound>

Cet exemple autorise 100 appels par fenêtre de 60 secondes par abonnement. Lorsqu’un appelant dépasse la limite, gestion des API retourne 429 Too Many Requests. Le compteur est réinitialisé automatiquement à la fin de chaque période de renouvellement. Appliquez cette stratégie à l’étendue du produit pour appliquer des limites cohérentes à tous les abonnés du produit.

La stratégie rate-limit-by-key applique une limitation de débit basée sur une clé de compteur personnalisée — toute expression évaluée comme une chaîne identifiant l’appelant :

<inbound>
  <rate-limit-by-key calls="30"
                     renewal-period="60"
                     counter-key="@(context.Request.IpAddress)" />
  <base />
</inbound>

Utilisez rate-limit-by-key quand les appelants n’utilisent pas de clés d’abonnement, ou lorsque vous souhaitez appliquer une limitation secondaire basée sur l’adresse IP, indépendamment de l’identité de l’abonnement. Vous pouvez dériver la clé du compteur à partir d’une revendication JSON Web Token (JWT), d’une valeur d’en-tête ou de tout autre attribut de requête accessible via le contexte d’expression de stratégie.

La quota stratégie applique le nombre total d’appels ou les limites de bande passante sur une période plus longue :

<inbound>
  <quota calls="10000" bandwidth="40960" renewal-period="2592000" />
  <base />
</inbound>

Cet exemple limite chaque abonnement à 10 000 appels ou 40 Mo de données transférées par période de 30 jours (2 592 000 secondes). Lorsque le quota est épuisé, les appelants reçoivent une 403 Forbidden réponse jusqu’au renouvellement de la période.

La distinction entre rate-limit et quota reflète deux risques de consommation différents :

• rate-limit empêche les abus liés aux pics de trafic — lorsqu’un appelant inonde l’API en très peu de temps.
• quota applique des limites d’utilisation contractuelles : s’assurer qu’un abonné ne dépasse pas son engagement mensuel en volume.

Pour Contoso Retail, appliquez rate-limit à l’étendue du produit pour protéger les systèmes principaux contre les pics de trafic, et quota dans la même étendue pour appliquer les allocations mensuelles par abonnement qui s’alignent sur les niveaux de contrat partenaire.

Intégrer Gestion des API à Réseau virtuel Azure

Le filtrage IP et la limitation de débit fonctionnent au niveau de la couche application sur un point de terminaison de passerelle accessible publiquement. L’intégration de réseau virtuel (réseau virtuel) prend une approche plus fondamentale : la suppression ou la restriction du point de terminaison public lui-même afin que seuls les appelants sur des réseaux privés puissent atteindre la passerelle.

Gestion des API prend en charge deux modes d’intégration de réseau virtuel :

Le mode externe déploie gestion des API dans un sous-réseau de réseau virtuel tout en conservant une adresse IP publique. La passerelle accepte les demandes d’Internet et peut également communiquer avec des ressources internes au réseau virtuel, telles que les API principales s’exécutant sur des machines virtuelles, des environnements App Service ou des clusters Azure Kubernetes Service. Utilisez le mode externe lorsque les partenaires doivent atteindre l’API via Internet, mais que vos services back-end doivent rester privés de réseau virtuel, inaccessibles directement à partir de l’extérieur du réseau virtuel.

Le mode interne déploie la gestion des API entièrement à l’intérieur du réseau virtuel sans point de terminaison public. La passerelle et le plan de gestion sont accessibles uniquement à partir du réseau virtuel ou des réseaux locaux connectés via VPN ou Azure ExpressRoute. Aucune adresse IP publique n’est exposée. Utilisez le mode interne lorsque les appelants et les services back-end se trouvent sur des réseaux privés et que l’accès à Internet public à la passerelle n’est jamais nécessaire. Le mode interne offre l’isolation réseau la plus forte des deux options.

Important

Les fonctionnalités de réseau virtuel varient selon le niveau. L’injection de réseau virtuel (isolation complète , aucune adresse IP publique sur la passerelle) n’est disponible que dans les niveaux Développeur, Premium (classique) et Premium v2 . Standard v2 prend uniquement en charge l’intégration de réseau virtuel (connectivité sortante aux back-ends privés uniquement ; le point de terminaison de passerelle reste accessible publiquement à partir d’Internet). Les points de terminaison privés (isolation entrante sans injection complète de réseau virtuel) sont disponibles dans Developer, Basic, Standard, Standard v2, Premium et Premium v2. Sélectionnez un niveau qui correspond à vos exigences d’isolation avant le déploiement : la modification des niveaux après le déploiement initial n’est pas une opération simple.

Les points de terminaison privés fournissent un autre chemin d’accès entrant pour les instances de niveau Premium. Un point de terminaison privé attribue à la passerelle Gestion des API une adresse IP privée au sein d’un réseau virtuel sans injecter l’instance entière dans le réseau virtuel. Les clients sur le réseau virtuel (ou les réseaux connectés) atteignent la passerelle via le backbone Azure à l’aide de cette adresse IP privée, tandis que la configuration de gestion des API reste inchangée. Cela est utile lorsque vous avez besoin d’un accès entrant privé à une instance existante sans migrer vers un déploiement de réseau virtuel complet.

Pour Contoso Retail, le bon modèle dépend des personnes qui consomment l’API :

• API orientées partenaires auxquelles les partenaires externes doivent accéder via Internet : le mode externe avec filtrage IP et limitation de débit fournit une isolation principale tout en conservant la passerelle accessible publiquement.
• API de charges de travail IA internes consommées uniquement par les propres services de Contoso : le mode interne ou un point de terminaison privé élimine totalement l’exposition publique, de sorte que seules les applications du réseau privé de Contoso peuvent atteindre la passerelle.

Les contrôles réseau réduisent la surface d’attaque disponible pour un attaquant potentiel avant même l’application de stratégies d’identité. Combinés avec l’authentification et l’autorisation, ils créent une défense en couches où les appelants doivent arriver à partir du bon emplacement, porter l’identité appropriée et rester dans les limites de consommation avant que toute demande atteigne votre back-end.