Orientation sur les pratiques exemplaires en matière de sécurité des API

Sur cette page

• But
• Authentification et identité
• Autorisation
• Filtrage des données
• Chiffrement et signature
• Protection du contenu

But

Le présent document traite de divers concepts de sécurité des API et des pratiques exemplaires lors de l’élaboration d’une API. Il s’agit d’un document complémentaire à l’Orientation sur la sécurisation des interfaces de programmation d’applications (section 7 de l’Orientation sur l’élaboration d’applications sécurisées) et à l’Orientation sur les passerelles API.

Il comporte les éléments suivants :

1. Mécanismes d’authentification et contexte d’identité
2. Granularité des autorisations
3. Filtrage de données
4. Chiffrement de transport et chiffrement de charge utile
5. Garantie d’un contenu sûr

Authentification et identité

Les API font partie d’une interaction intersystémique plutôt que d’une interaction entre l’utilisateur et le système. Par conséquent, les concepts d’authentification et d’identité sont liés, mais doivent être considérés séparément.

Mécanismes d’authentification

Il y a un large éventail d’options pour déterminer les mécanismes d’authentification à prendre en charge avec votre API. Il faut prendre note que les mécanismes d’authentification RESTful sont optimisés pour les interactions API lancées par les utilisateurs Web, alors que les mécanismes SOAP ont des options intersystémiques plus solides.

Mécanismes appropriés pour l’interaction intersystémique (non lancée par l’utilisateur ou le navigateur) :

• Les clés API statiques constituent la méthode la plus simple d’authentification directe. Les clés statiques ne doivent être utilisées que lorsque l’utilisateur d’API est une partie hautement fiable (p. ex., même domaine de sécurité, réseau restreint) et que les données sont de faible sensibilité, ou qu’il existe des mécanismes supérieurs d’authentification et d’autorisation en aval. Les clés API doivent être passées au moyen de l’en-tête HTTP d’autorisation et non dans la chaîne de requête ou le corps de requête pour assurer la compatibilité avec des composants tels que les passerelles API.
• Les jetons Web JSON (JWT) constituent en fait une méthode normalisée de génération, de signature, d’échange et de vérification de clés API temporaires. Les JWT doivent être la norme par défaut pour toutes API RESTful exposant des données sensibles. Utilisez des bibliothèques de codes fiables ou des services d’informatique en nuage pour générer et vérifier les JWT au lieu de les développer sur mesure.
• Les jetons de nom d’utilisateur WSS pour les services Web SOAP sont similaires aux clés API statiques pour les API RESTful et ne doivent être utilisés que pour les consommateurs très fiables et les données à faible sensibilité. L’option Nonce doit être mise en œuvre dans la mesure du possible afin d’éviter les attaques par relecture.
• Les certificats X.509 pour les services Web SOAP créent une méthode d’authentification solide où le consommateur et le fournisseur d’API peuvent accéder à la même autorité de certification.
• Les jetons SAML pour les services Web SOAP sont utilisés pour l’authentification fédérée, par laquelle le fournisseur d’API s’appuie sur un fournisseur d’authentification distinct. Les interactions SAML doivent être configurées pour le canal arrière dans les appels intersystémiques, dans la mesure du possible.
• OAuth 2.0 est le protocole d’authentification et d’autorisation par défaut pour les API RESTful. Il utilise une approche d’authentification fédérée similaire à SAML pour SOAP. L’objectif principal d’OAuth est de permettre les interactions lancées par le navigateur permettant à l’utilisateur d’autoriser une demande à ses données sur une autre application fédérée. Le type d’octroi de justificatifs d’identité du client OAuth 2.0 doit être utilisé pour les interactions API entre machines lorsqu’un utilisateur n’est pas impliqué.
• OpenID Connect est une couche d’authentification d’identité simplifiée au-dessus d’OAuth 2.0. Dans le cas d’interaction entre machines, le consommateur d’API agit effectivement comme l’utilisateur et doit d’abord s’authentifier auprès du fournisseur d’authentification au moyen de certains justificatifs d’identité préétablis (p. ex., clé statique, nom d’utilisateur/mot de passe) pour recevoir un jeton transactionnel. Le jeton est généralement représenté comme un JWT.
• L’authentification mutuelle exige que le consommateur et le fournisseur d’API s’authentifient mutuellement pour établir une confiance forte et pour atténuer les attaques de l’intercepteur. L’authentification mutuelle SSL/TLS peut être mise en œuvre à la couche de protocole HTTP si le fournisseur et le consommateur d’API ont le contrôle de la connexion HTTPS. OAuth fournit également un mécanisme d’authentification mutuelle TLS.

Mécanismes appropriés pour les appels API lancés par l’utilisateur ou le navigateur :

• Des méthodes d’authentification fédérées comme les jetons SAML ou OAuth doivent être utilisées. Les utilisateurs doivent s’authentifier auprès d’un fournisseur d’authentification qui retourne le jeton approprié que l’application Web doit utiliser pour authentifier les API de service principal. Dans le cas d’OAuth, le type d’octroi implicite doit être évité, car il n’est pas considéré comme très sûr.

Mécanismes les moins préférables :

• Les méthodes d’authentification fondées sur les sessions et les témoins ne correspondent pas aux interactions API sans état.
• Les mécanismes propres à la technologie comme NTLM ne sont pas des normes ouvertes et créent des restrictions de compatibilité pour les consommateurs d’API.
• L’authentification HTTP de base offre peu ou pas de sécurité ou d’assurance et est facilement compromise.
• Les clés API temporaires exigeant une API d’authentification distincte créent une complexité importante à gérer pour le consommateur d’API et rendent l’interaction avec état.

Contexte d’identité

La sensibilité des données et les exigences de confidentialité doivent dicter le contexte d’identité requis par l’API (c’est-à-dire, si l’API doit authentifier l’utilisateur final ou simplement le système du consommateur).

Contexte d’utilisateur – Si les données sont de nature personnelles, très sensibles ou si des exigences précises d’audit ou de journalisation de l’accès aux données sont requises au niveau individuel, l’authentification doit être établie à l’aide des justificatifs d’identité de l’utilisateur final jusqu’à l’API de service principal. Dans la mesure du possible, des mécanismes d’authentification fédérés comme SAML et OpenID Connect doivent être utilisés afin que le jeton d’authentification puisse être retracé vers l’utilisateur initiateur. Lorsque des mécanismes d’authentification fédérés ne sont pas disponibles, un identifiant d’utilisateur (p. ex., ID d’utilisateur) doit être transmis au moyen de la charge utile de la demande d’API afin que l’API de service principal puisse corréler la demande et une personne.

Contexte du système – Si les données sont moins sensibles ou qu’elles n’ont pas besoin d’être autorisées au niveau individuel (p. ex., rapports, finances, références) et qu’une relation de confiance entre les systèmes est adéquate, il n’est pas nécessaire de propager le contexte d’utilisateur. Les méthodes d’authentification intersystémique directe sont généralement plus faciles à mettre en œuvre et réduisent la latence, car elles n’exigent pas les interactions supplémentaires avec un fournisseur d’authentification ou les étapes supplémentaires d’extraction et de transmission du contexte d’utilisateur dans un message.

Autorisation

Alors que les mécanismes d’authentification valident l’identité du consommateur d’API, les méthodes d’autorisation valident l’autorisation de ce consommateur d’accéder à une API ou à des composants de cette API.

Niveau de l’API ou des ressources

La méthode d’autorisation la plus simple est d’accorder l’accès à l’intégralité de l’API tant que le consommateur est autorisé. Cela est facilité lorsque les API sont suffisamment petites ou que les données sont peu sensibles, de sorte que le profil d’autorisation multiple n’est pas nécessaire.

Autorisation implicite – Il s’agit de la méthode d’autorisation la plus facile pour les API utilisant des mécanismes d’authentification directe (c’est-à-dire, non fédérés). L’hypothèse est que si l’API a validé l’utilisateur, l’utilisateur doit avoir accès à l’API. Il faut prendre note que l’authentification doit être effectuée avec soin dans les répertoires de justificatifs d’identité qui sont partagés avec d’autres systèmes ou domaines de sécurité (p. ex., LDAP organisationnel). Cette méthode ne doit être utilisée que sur les données de faible sensibilité ou lorsque l’authentification API est autonome et ne partage pas les données d’authentification avec un autre système.

Liste de contrôle d’accès – Une liste autorisée de justificatifs d’identité autorisés (p. ex., clés API, ID utilisateur) doit être mise en œuvre sur les API avec un petit ensemble de consommateurs essentiellement statique. La gestion des listes de contrôle d’accès au niveau des justificatifs d’identité individuels peut devenir extrêmement fastidieuse à mesure que le nombre de consommateurs et d’API augmente, et ne devrait donc être utilisée que dans de petits environnements d’API.

Contrôle d’accès basé sur les rôles – RBAC est la norme par défaut pour l’autorisation d’API à l’échelle. Sur le plan conceptuel, les justificatifs d’identité du consommateur doivent être attribués à des rôles dans le répertoire des justificatifs d’identité ou dans les systèmes du fournisseur d’authentification. Les rôles sont ensuite transmis à l’API et l’autorisation est déterminée en fonction du rôle plutôt que des justificatifs d’identité individuels.

Autorisation externe – Il existe plusieurs mécanismes communs pour externaliser les décisions d’autorisation de l’API afin de garder le code API petit et portable entre les environnements :

• OAuth est la méthode la plus populaire pour transmettre des renseignements d’autorisation entre l’API et le fournisseur d’autorisation pour les API RESTful. Les flux OAuth placent généralement l’utilisateur au milieu du processus d’autorisation dans les interactions lancées par le navigateur. La capacité à définir des règles d’autorisation statique dépend généralement des solutions de passerelle ou de gestion d’accès particulières mettant en œuvre OAuth.
• SAML a également des dispositions concernant les renseignements d’autorisation (assertions) pour les services Web SOAP. Comme OAuth, la capacité de gérer les autorisations dépend des solutions de passerelle ou de gestion d’accès.
• On peut utiliser des passerelles pour gérer l’accès aux points d’extrémité en fournissant la façade avec laquelle les consommateurs d’API peuvent interagir. Les mises en œuvre de passerelle impliquent généralement que les fournisseurs d’API doivent implicitement faire confiance au service de passerelle. La transmission du contexte d’utilisateur au moyen des passerelles exige généralement des efforts supplémentaires de conception et de personnalisation. De nombreuses passerelles prennent en charge OAuth ou SAML pour transmettre des assertions ou des demandes d’autorisation.
• On peut utiliser d’autres solutions de gestion d’accès, comme celles conçues pour des applications Web (p. ex., Oracle Access Manager, Open AM) pour gérer l’accès aux API et aux opérations ou méthodes d’API. Le niveau de granularité et les exigences de compatibilité pour l’API varient considérablement selon la solution du fournisseur. Il n’est pas recommandé de mettre en œuvre une solution de gestion de l’accès Web pour externaliser les autorisations d’API à moins que l’organisation n’en ait déjà une en place, car sa configuration et sa maintenance peuvent être assez coûteuses et fastidieuses.

Niveau de l’opération ou de la méthode

Les API peuvent être sécurisées au niveau de l’opération (SOAP) ou de la méthode (RESTful) si un contrôle plus granulaire est nécessaire (p. ex., lecture seule ou mise à jour). Cela nécessite généralement que le fournisseur API mette en œuvre le code pour appliquer l’autorisation. Certaines solutions de gestion d’accès externalisées peuvent également fournir une protection au niveau de l’opération ou de la méthode. Il est généralement recommandé d’éviter de gérer l’accès à ce niveau, car il peut être fastidieux sur le plan opérationnel. Il est généralement plus facile de diviser l’API en API plus petites, chacune ayant un profil de sécurité ou d’accès différent.

Filtrage des données

La limitation de la quantité de données retournées au moyen d’une API, que ce soit pour la confidentialité ou pour la stabilité de l’exécution, est un élément essentiel de la conception d’une API sécurisée.

Données propres à l’utilisateur

Le code de l’API doit garantir que seules les données que l’utilisateur ou le système requérant est autorisé à voir seront retournées. Il faut utiliser et propager des identifiants couramment compris (p. ex., ID utilisateur, ID employé, nom système, numéro de compte).

Segmentation de données

La capacité de renvoyer de grandes quantités de données rend les API de requête des cibles pour les attaques par déni de service (DDoS). Les API doivent être conçues pour empêcher les recherches de caractères génériques ou les longues requêtes. Les limites doivent être fixées sur la quantité de données qui peuvent être retournées par demande pour limiter les délais HTTP et les types d’attaques de dépassement de capacité. Dans les cas où une grande quantité de données doit être échangée, cherchez à mettre en œuvre un gestionnaire de rappels qui permet de segmenter les données retournées en petites charges utiles (p. ex., pagination) et de les envoyer progressivement au point d’extrémité de rappel.

Chiffrement et signature

Les API peuvent être chiffrées au niveau du transport et du message en fonction de la sensibilité des données transmises.

Chiffrement de transport

Comme toutes les API ont lieu sur HTTP, TLS (c’est-à-dire, HTTPS) est la forme de chiffrement la plus simple. Ceci doit être le minimum par défaut pour toutes les mises en œuvre d’API. Le chiffrement de transport empêche l’interaction d’être observée par des parties non autorisées ailleurs dans le réseau, mais n’empêche pas les violations par lesquelles le mécanisme d’authentification est compromis ou les fuites de données en aval.

Les certificats TLS doivent être délivrés par une autorité de certification publique ou privée agréée par le gouvernement du Canada. Les certificats autosignés ne doivent être utilisés à aucune fin autre que les essais.

Chiffrement des messages

Les API traitant de données hautement sensibles doivent être chiffrées à la couche de message. Le chiffrement du message API garantit que seuls les consommateurs possédant la clé de déchiffrement appropriée peuvent visualiser la charge utile. Il offre un niveau supplémentaire de protection contre les accès non autorisés.

WS-Security fournit des mécanismes (p. ex., des échanges de clés, des en-têtes, des schémas) pour chiffrer les charges utiles SOAP.

Javascript Object Signing and Encryption (JOSE) est le meilleur cadre disponible pour chiffrer et signer les messages JSON, mais il y a quelques préoccupations et considérations :

• Absence de mises en œuvre normalisées – JOSE est un ensemble de normes distinctes (JWT pour le jeton, JWS pour la signature et JWE pour le chiffrement) sans aucune orientation normalisée sur la façon de les mettre en œuvre collectivement pour chaque cas d’utilisation (p. ex., chiffrer le message ou à chiffrer toute la charge utile entière).
• Faiblesses de la crypto – La crypto sous-jacente pour JWE a un vecteur d’attaque connu pour potentiellement exposer des clés privées. Le risque de défaut peut être atténué en s’assurant que l’accès à l’API est limité aux parties fiables (p. ex., l’inscription des adresses IP autorisées). Cela signifie que JOSE n’est pas recommandé pour les API ouvertement accessibles à partir d’Internet.

Signature des messages

Comme pour le chiffrement des messages, les signatures numériques pour les services Web SOAP sont prises en charge par la norme WS-Security. Dans le cas de SOAP, un message doit d’abord être chiffré pour qu’il soit signé. Pour les API RESTful, on peut utiliser JOSE en utilisant l’en-tête JOSE pour transmettre les paramètres cryptographiques, et toute la charge utile est chiffrée et signée. JWS Cleartext doit être évité, car le message peut être lu même si le consommateur de l’API ne valide pas la signature.

Protection du contenu

Les API doivent être conçues pour protéger contre les contenus malveillants et afin de veiller à ce que les réponses ne puissent pas être interceptées et redirigées pour injecter du contenu malveillant au consommateur de l’API.

Validation de la demande

Les API sont similaires en fonction des formulaires Web en ce qu’elles prennent les données au moyen du protocole HTTP et les transmettent aux couches de données et de logique opérationnelle. À l’instar des formulaires Web, les méthodes de validation de demande suivantes doivent être mises en œuvre :

Validation de schéma – Avoir un schéma de requête bien défini et effectuer une validation par rapport à ce schéma devraient être la première ligne de défense contre les messages malveillants. On peut mettre en œuvre la validation de schéma en plus dans une passerelle ou un service proxy pour réduire la charge de traitement sur l’API et pour éloigner le périmètre de sécurité des données. Veuillez prendre note que la mise en œuvre de passerelle ou de proxy ne dispense pas l’API elle-même des responsabilités de validation de schéma. Elle ne vise qu’à déplacer la validation primaire vers le périmètre et ne devrait en aucun cas affaiblir la position de sécurité du code API lui-même.

Regex – La mise en œuvre de la validation regex en plus de la validation de schéma protège davantage contre les messages mal formés et le type d’attaques par dépassement de capacité qui exploite une forme quelconque de scénario limite de requête de données. Notez que regex ne s’applique qu’aux types de champs simples dont le contenu attendu est assez uniforme.

Types forts – Plus la structure des données est précise, plus il est facile d’identifier les messages non valides. Définissez les attributs comme des types forts (p. ex., quantité, longueur, nom) au lieu de tout comme une chaîne pour limiter davantage les attaques de messages mal formés. Il s’agit également d’une bonne pratique d’élaboration et permet de tester plus facilement les API.

Caractères spéciaux ou mots-clés – La restriction des caractères spéciaux et des mots-clés permet d’atténuer les attaques classiques par script ou par injection.

Sécurité des réponses

Les méthodes suivantes devraient être mises en œuvre afin de veiller à ce que le message de réponse au consommateur de l’API soit le plus sûr possible.

Types de réponse – Le consommateur d’API peut demander que la réponse soit dans un type de contenu particulier (p. ex., JSON, XML, JavaScript) dans l’en-tête Accept. Le fournisseur d’API doit d’abord confirmer si le type de contenu demandé est sûr et pris en charge et veiller à ce que l’en-tête de type Content soit approprié et non pas seulement une copie de l’en-tête Accept. Par exemple, le consommateur peut demander que JavaScript soit retourné, mais le fournisseur d’API doit renvoyer JSON à la place.

Données de l’erreur – Il faut déployer des efforts afin de veiller à ce que les renseignements inutiles sur le système principal (p. ex., les noms de système, IP, ID, vidages de pile) ne soient pas présentés au consommateur de l’API. Les données de l’erreur constituent un espace commun où cela est négligé, car il est plus facile de simplement transférer l’exception de système dans le cadre de la réponse. Les erreurs de système doivent être traitées en interne à l’API et les réponses d’erreur doivent contenir uniquement des renseignements pertinents pour le consommateur d’API.

Protection antivirus

Les API acceptant des pièces jointes, des grands objets binaires ou des charges utiles binaires (p. ex., téléchargement d’images, documents) risquent d’être attaquées par des virus. La plupart des produits de passerelle d’API offrent des fonctionnalités d’analyse antivirus, mais il faut prendre note que si la charge utile d’API est chiffrée, la passerelle doit être en mesure de déchiffrer la charge utile pour l’analyser. Il n’est pas recommandé de traiter la protection antivirus dans le code API, car l’analyse antivirus devrait se faire aussi près que possible du périmètre.