Orientation sur les passerelles d’interface de programmation d’applications (API)

Sur cette page

1. Gérer l’achalandage
2. Contrôler la connectivité
3. Contrôler l’accès
4. Inspecter le contenu
5. Surveiller les demandes

Les interfaces de programmation d’applications (API) fournissent des interfaces puissantes pour accéder à distance aux données et aux fonctionnalités système. L’accès intersystémique direct activé au moyen des API augmente le risque et l’incidence d’une brèche de sécurité. La sécurité de l’API doit être au premier plan de la mise en œuvre de toutes API. La passerelle API est un concept de solution qui permet de gérer les divers risques de sécurité associés à l’exposition des API à l’intérieur et à l’extérieur d’une organisation, comme la limitation et le proxy.

• Pourquoi avons-nous besoin de passerelles API? Différentes mesures de sécurité et de stratégie sont essentielles pour gérer l’accès à vos API internes et externes à votre organisation. Les passerelles API vous permettent de vous adapter au profil de risque nettement plus élevé de vos API accessibles à l’externe. Les passerelles API permettent également d’externaliser les mesures pour éviter de définir ces stratégies dans chacune des API elles-mêmes.
• Comment mettre en œuvre des passerelles API? Même s’il y a un certain nombre de produits qui s’appellent des passerelles API, il y a une grande variation dans la fonctionnalité et l’objectif de ces technologies (p. ex., sécurité ou gestion de l’achalandage). Le présent document d’orientation fournit une liste de référence des mesures et des scénarios où ils doivent être appliqués pour vous aider à décider des produits de passerelle API à déployer et des mesures supplémentaires qui doivent être mis en œuvre.
• Dois-je placer les passerelles API devant toutes mes API? Pas forcément. Différents scénarios d’utilisation pour les API exigent différents mesures de stratégie. Les Normes du gouvernement du Canada sur les API stipulent que toutes les API orientées vers Internet doivent utiliser des passerelles et des proxys plutôt que des listes blanches. Lorsque vous traitez d’API internes ou pangouvernementales, il vous appartient de déterminer si un composant de passerelle API est nécessaire ou non pour gérer l’accès à votre API, à condition que vous puissiez traiter les mesures nécessaires.
• Dois-je passer par une passerelle API pour accéder aux API externes ou tierces? Non. Les passerelles API contrôlent l’accès à vos API (c’est-à-dire, entrées). Les demandes sortantes vers les API d’une autre personne doivent respecter les politiques et les pratiques exemplaires en matière de sécurité du réseau et de la connectivité, comme passer par un proxy de transfert.
• Dois-je encore mettre en œuvre la sécurité au niveau des API si je mets en œuvre des passerelles API? Oui. Il faut mettre en œuvre une approche de défense approfondie lors de la mise en œuvre des API. Les API peuvent être attaquées de plusieurs façons, comme les applications Web, car elles sont toutes deux basées sur HTTP. Par conséquent, les mesures OWASP doivent toujours être appliqués de façon holistique à l’API.

L’orientation est destinée à servir de jeu de données de base pour les praticiens techniques (p. ex., les développeurs d’API, les architectes) lors de la mise en œuvre de solutions axées sur l’API. Il ne s’agit en aucun cas d’une liste exhaustive de toutes les fonctionnalités de passerelle API possibles. Le marché des technologies de passerelle API évolue rapidement, notamment en raison de l’augmentation des architectures de microservice, et les limites entre les passerelles API, la gestion des API, les bus de service d’entreprise et les maillages de service se brouillent rapidement. Il n’existe pas d’approche unique pour les passerelles API et il est peu probable qu’un seul produit réponde à tous vos besoins.

1. Gérer l’achalandage

Diverses méthodes doivent être déployées pour contrôler la quantité de l’achalandage qui atteint une API afin de réduire le risque de voir le retrait d’en raison de charges de requêtes élevées inattendues, qu’elles soient malveillantes ou non. La plupart de ces méthodes sont disponibles même dans les technologies de proxy inverse HTTP de source libre les plus basiques (p. ex., NGINX).

• Limitation – Les API doivent idéalement être déployées dans des infrastructures à hyperscale comme le nuage et être mises à l’échelle automatiquement. En fait, la capacité de la grande majorité de l’infrastructure du GC est de nature fixe. La capacité de fixer des limites des taux de requête (p. ex., 1 000 demandes par minute) pour des API précises devrait être obligatoire pour toute personne exposée à d’autres ministères ou à des parties externes. Il est beaucoup plus judicieux d’avoir un code d’erreur de retour de limitation pour les consommateurs d’API lorsque les limites sont atteintes que de faire retirer l’API en raison d’une charge excessive.
• Mise en cache – Les API en lecture seule, en particulier celles qui s’opposent aux données de référence qui changent lentement (p. ex., les codes de pays, l’emplacement des bureaux, les renseignements sur les organigrammes), doivent être mises en cache à la couche de passerelle API si la fréquence des requêtes est élevée ou peut atteindre des pics extrêmes. La mise en cache de ce type de données stockées en mémoire dans la couche de passerelle limite la charge de traitement sur l’API chaque fois. Les API transactionnelles ou celles où il est peu probable que des requêtes répétées sur un même enregistrement (p. ex., données fiscales individuelles) soient mises en cache.
• Qualité du service (QoS) – Certains consommateurs d’API peuvent bénéficier d’un traitement préférentiel pour offrir un taux de transaction supérieur (p. ex., les API à frais pour service, les partenaires de confiance et les systèmes de sécurité publique). Dans ces cas, une technologie de passerelle avec fonction QoS doit être sélectionnée. La QoS n’est généralement disponible que sur les passerelles intégrées dans les plateformes de gestion des API ou celles qui ont une capacité de contrôle d’accès plus solide, car la QoS dépend fortement de la capacité à gérer les justificatifs d’identité des consommateurs d’API (p. ex., clés, certificats) à l’intérieur de la passerelle.
• Détection des intrusions – Les attaques par déni de service (DoS, DDoS) sont une préoccupation majeure pour les API Internet. Toute API accessible à partir d’Internet doit être protégée par des services appropriés de protection des limites et de sécurité comme la protection contre DoS et le système de détection d’intrusion (SDI) ou le système de protection contre les intrusions (SPI). Les initiatives du gouvernement du Canada en matière de périmètre de sécurité (p. ex., point d’interconnexion fiable ou de point d’accès au nuage) pourraient aborder cette question à l’avenir.
• Équilibrage de charge – L’équilibrage de charge sur un groupement de nœuds API au niveau de la passerelle API ne doit être mis en œuvre que si un équilibrage de charge Web existant (c’est‑à-dire HTTPS) n’existe pas déjà pour la solution.

2. Contrôler la connectivité

Les passerelles API fournissent un point de consolidation de la connectivité pour simplifier et contrôler les flux réseau entre les API et les consommateurs d’API. Cela est particulièrement important pour les API exposées à d’autres ministères ou à des parties externes, car les IP internes doivent être retirées des systèmes externes. Cela garantit également que toute modification interne de la topologie de déploiement ou de l’infrastructure n’a pas d’incidence sur les consommateurs d’API. Ces fonctionnalités sont généralement disponibles dans toutes les technologies de proxy inverse HTTP et sont universellement disponibles dans la plupart des produits de passerelle API.

• Routage et proxy – La couche de passerelle API doit présenter une URL de base unique aux consommateurs externes qui se dirigeraient ensuite vers un certain nombre d’adresses URL hôtes pour les API du système principal. Les API ne devraient voir que l’achalandage provenant de la couche de passerelle API au lieu des consommateurs d’API externes.
• Liste blanche d’adresses IP – Les API exposées à des partenaires de confiance sur Internet devraient mettre en œuvre la liste blanche d’IP dans la couche de passerelle API afin de réduire le risque d’attaques et d’accès non autorisé. Même si la liste blanche d’adresses IP pour les API sur place peut être mise en œuvre à la couche réseau, le fait que les mesures soient gérées par les équipes des opérations d’API accélère le processus pour les partenaires intégrés ou non. Il faut prendre soin de scénarios où les systèmes consommateurs peuvent ne pas avoir d’IP statiques (p. ex., hébergés dans le nuage) et, par conséquent, des plages d’adresses IP doivent être utilisées.

3. Contrôler l’accès

Des solutions de passerelle API plus solides offrent une authentification et une autorisation sur les demandes d’API. Même si le déchargement de la lourde charge dans la logique d’authentification et d’autorisation est logique dans certains cas, cela ne signifie pas que l’authentification ou l’autorisation n’est pas nécessaire aussi au niveau de l’API. Les API non authentifiées ne sont appropriées que pour les données ouvertes et les API publiques non classifiées, tandis que le contrôle d’accès à la passerelle est une couche de sécurité supplémentaire pour les données plus sensibles.

• Authentification – La couche de passerelle API doit au minimum être configurée pour effectuer un certain niveau d’authentification pour le compte de l’API principale. Cette authentification garantit que les tentatives de connexion non valides sont traitées avant que la demande n’accède à l’API, ce qui réduit les risques et le traitement inutile. Toutefois, la conception de l’authentification doit tenir compte de la nécessité pour l’API principale de connaître l’identité du consommateur de l’API. Dans de nombreux cas, d’autres fonctionnalités de passerelle API plus avancées comme la QoS et le suivi de l’utilisation exigent que l’authentification se produise à la passerelle API afin que l’achalandage puisse être associé à des consommateurs d’API précis.
• Translation des justificatifs d’identité – Les API centrales n’ont pas toujours besoin d’authentifier chaque consommateur d’API de façon unique. Par exemple, une API de vérification d’adresse qui vérifie qu’une adresse donnée est valide peut ne pas nécessiter de renseignements au niveau utilisateur. Dans ces cas, il suffit que la passerelle API s’authentifie au moyen d’une clé API de système générique unique. Dans d’autres cas, le justificatif d’identité du consommateur ou l’identificateur du système est nécessaire, mais uniquement à des fins d’audit. Pour ce faire, vous pouvez translater les justificatifs d’identité du consommateur d’API en une chaîne d’attributs qui est ajoutée au contenu de demande envoyé à l’API principale.

  La translation des justificatifs d’identité n’est généralement pas considérée comme une fonctionnalité explicite sur la plupart des produits de passerelle API, mais plutôt comme un modèle de mise en œuvre exécuté au moyen d’une combinaison de sélection des mécanismes d’authentification appropriés et de mise à profit des capacités de translation des demandes.

• Autorisation grossière – La gestion de l’autorisation au niveau de la passerelle API doit être limitée au niveau de la ressource ou des opérations au plus. Toute autorisation granuleuse, comme le filtrage des données, doit être laissée à l’API principale elle-même.

4. Inspecter le contenu

Les solutions de passerelle API axées sur la sécurité permettent d’effectuer une grande partie des mesures de sécurité des données de charge utile en plus de les mettre en œuvre dans l’API elle-même. L’objectif est de déplacer le point initial d’application de la sécurité plus loin dans le périmètre et loin des données sans compromettre la position de sécurité de l’API elle-même.

• Vérification de la signature numérique – Pour les API ayant des exigences d’intégrité élevée, la validation de la signature numérique doit être effectuée à la couche de passerelle API afin de veiller à ce que les messages falsifiés soient rejetés au périmètre. Les solutions de passerelle d’API optimisées pour la sécurité ont également tendance à traiter les validations cryptographiques plus rapidement, ce qui réduit les frais de traitement de l’API elle-même et améliore le débit et le temps de réponse.
• Analyse de contenu malveillant – Comme toutes les autres charges utiles Web, les contenus malveillants comme les scripts ou les logiciels malveillants peuvent être intégrés dans une demande d’API. Toutes les demandes d’API provenant de sources externes doivent être analysées pour détecter les contenus malveillants dans le périmètre et les menaces rejetées avant d’atteindre l’API. Même si l’analyse du contenu des demandes d’API provenant de systèmes internes ou de partenaires de confiance n’est généralement pas nécessaire, dans le cas des demandes d’API fédérées ou transférées, il convient de prendre soin de comprendre d’où provient la demande d’origine.
• Validation du schéma de demande – Certaines API bénéficient des validations de schéma effectuées au niveau de la passerelle API. La passerelle peut valider le message de demande par rapport au schéma attendu et rejeter toute demande non valide. Dans les cas où le débit devrait être élevé ou si l’API est publique, le risque de messages mal formés est plus grand et, par conséquent, le déchargement des frais de traitement est bénéfique. Cette mise en œuvre exige un déploiement et des tests plus complexes pour maintenir la passerelle API synchronisée avec les modifications de schéma de demande, mais la compromission opérationnelle peut être utile pour éviter la charge de traiter un grand nombre de messages mal formés au niveau de l’API.
• Mappage de schéma de demande – Les translations de schéma de demande ont traditionnellement été une fonction de bus de service d’entreprise (ESB). Les solutions de passerelle API ont de plus en plus offert cette fonctionnalité pour les scénarios où la complexité est insuffisante pour justifier un ESB, mais il faut tenir compte de différents schémas de demande (p. ex., consommateur interne ou externe d’une même API). Le mappage d’un schéma de demande du consommateur au schéma de l’API principale n’est approprié dans la solution de passerelle API que si le mappage est direct (c’est-à-dire les noms d’attributs uniquement) et n’implique pas de manipulation de données (p. ex., concaténation) ou de logique (p. ex., translations conditionnelles, calculs). La logique opérationnelle réelle doit être évitée et traitée par l’API.

5. Surveiller les demandes

Tout l’achalandage, au moyen de la solution de passerelle API, doit être surveillé, consigné et signalé. Ces données sont l’un des principaux avantages de l’utilisation d’une passerelle et devraient être utilisées pour fournir à la fois une vue opérationnelle et une vue organisationnelle sur la façon dont l’API est exploitée et son rendement.

• Rapports d’utilisation – Toutes les statistiques de demande (p. ex., demande de consommateur d’API, heure d’accès, temps de réponse, opérations demandées) doivent être consignées et déclarées sur la couche de la passerelle API, y compris les demandes réussies et les demandes ayant échoué. La passerelle API doit être en mesure de fournir des tableaux de bord par défaut pour les mesures d’utilisation ou fournir une méthode d’exportation des données vers une solution tierce de production de rapports.
• Audit et journalisation des demandes – Toutes les demandes API doivent être consignées par la passerelle API et les renseignements suivants doivent être consignés au minimum :
  • Nom de l’API et adresse URL de destination
  • Opération de l’API
  • Clé et ID de l’API du consommateur
  • Heure de la demande
  • Code HTTP de réponse ou code d’erreur
  • Code d’erreur interne (le cas échéant)

  La passerelle API devrait avoir l’option de consigner plus de détails sur l’API pour les interactions API avec des exigences d’audit précises comme la charge utile et la réponse.

• Signalement d’activités suspectes – La solution de passerelle API doit être en mesure de trouver et de signaler les modèles d’utilisation douteux comme les suivants :
  • Plusieurs clés API non valides
  • Même clé API demandée à plusieurs adresses IP ou emplacements
  • Plusieurs tentatives d’accès aux opérations ou données non autorisées
  • Plusieurs échecs sur la vérification de signature numérique
  • Toute brèche de sécurité liée au contenu