Une intégration entre une boutique en ligne, un CRM, un ERP ou un outil de support reçoit souvent une autorisation décrite de manière trop large : « accès aux commandes » ou « accès au CRM ». Cette simplification rend difficile l’identification des besoins réels du connecteur et peut laisser disponibles des fonctions ou des données qui ne relèvent pas de son travail.
La matrice d’autorisations pour API transforme cet accès générique en décisions concrètes et révisables. Son utilité ne se limite pas à l’équipe technique : les opérations peuvent valider le processus, les équipes métier peuvent approuver les actions sensibles et les prestataires peuvent connaître les limites de leur intervention. L’objectif est que chaque acteur, humain ou automatisé, accède uniquement aux opérations, enregistrements et champs nécessaires.
Le problème consistant à autoriser un outil entier
Être authentifié identifie une personne, un processus ou un compte technique, mais ne détermine pas à lui seul ce qu’il peut faire. L’autorisation doit répondre, au minimum, à la question de savoir si cet acteur peut exécuter une action précise et sur quelle ressource. Par exemple, un connecteur qui crée des contacts à partir d’un formulaire n’a pas nécessairement besoin d’exporter tous les contacts, de modifier les propriétaires, de supprimer des enregistrements ou de consulter des informations internes. [2]
Il est également nécessaire de distinguer l’autorisation sur une fonction de l’autorisation sur un objet précis. Le fait qu’un portail permette de consulter des commandes ne signifie pas que n’importe quel client peut consulter n’importe quelle commande : le système doit vérifier que l’enregistrement demandé appartient à son entreprise ou à son compte. OWASP identifie l’absence de cette vérification au niveau de l’objet comme un risque pouvant entraîner l’exposition, la modification ou la suppression non autorisée de données. [1]
Ce qu’une matrice d’autorisations par opération doit inclure
Une matrice est un inventaire structuré des décisions d’accès. Chaque ligne représente un besoin opérationnel, et non un rôle générique tel qu’« administrateur » ou « accès complet ». Elle peut commencer par une intégration critique, comme web–CRM, e-commerce–ERP ou portail clients–support, puis être étendue au reste de l’écosystème. Sa valeur réside dans le fait de rendre visibles les exceptions avant de les transformer en identifiants ou en règles techniques.
Comme modèle minimal, incluez le système ou l’intégration ; l’acteur ; la ressource ; l’opération ; le périmètre ; les champs autorisés et exclus ; la méthode d’authentification et l’identifiant associé ; les conditions supplémentaires ; la personne responsable ; la date de révision, ainsi que l’événement à enregistrer. Parmi les opérations, il est utile de distinguer lire, créer, mettre à jour, annuler, approuver, exporter et supprimer, car leur impact n’est pas équivalent.
- Acteur : employé, client, prestataire, processus automatisé ou compte de service.
- Périmètre : ses propres données, une entreprise déterminée, une unité opérationnelle ou des données internes.
- Condition : par exemple, uniquement les commandes attribuées, uniquement les documents dans un état précis ou une approbation préalable pour
Exemple hypothétique d’une intégration web–CRM
Exemple hypothétique : une entreprise relie le formulaire de demande commerciale de son site web au CRM. Le compte technique du formulaire peut créer un contact et un prospect, mais uniquement avec le nom, l’e-mail, l’entreprise, le téléphone et le message. Il ne peut pas lire les contacts existants, télécharger des listes, modifier le propriétaire commercial, consulter des notes internes ni supprimer des enregistrements. Le responsable métier valide que ces champs sont suffisants pour traiter la demande.
La même matrice doit décrire le périmètre des données. Si le CRM organise les clients par filiales, le processus automatisé devrait créer des enregistrements uniquement dans l’unité qui lui est attribuée, et non dans toutes les unités. S’il doit détecter des doublons, il peut nécessiter une vérification limitée et journalisée, plutôt qu’un accès global en lecture. Cette précision évite qu’un besoin légitime se traduise par un identifiant doté de capacités inutiles.
Cinq règles pour transformer la matrice en contrôles réels
Premièrement, appliquez le refus par défaut : toute opération qui n’est pas expressément autorisée doit être rejetée. Deuxièmement, vérifiez côté serveur et à chaque requête à la fois l’action et l’objet demandé ; il ne suffit pas de masquer un bouton dans l’interface ni de valider l’autorisation uniquement lors de l’émission d’un jeton. Troisièmement, séparez les comptes de personnes des comptes techniques afin de pouvoir limiter, examiner et retirer leurs capacités de manière indépendante. [2]
Quatrièmement, limitez chaque compte d’intégration aux ressources, opérations et champs requis par le processus. Cinquièmement, établissez des révisions périodiques et des révisions déclenchées par des changements importants, tels qu’un départ de prestataire, une modification de fonctions, un nouvel endpoint ou une automatisation remplacée. La gestion du cycle de vie des comptes comprend l’enregistrement des créations, modifications, activations et suppressions, ainsi que la désactivation des comptes qui ne correspondent plus à une personne ou à un besoin actuel. [4]
- Évitez les clés partagées entre différents prestataires ou automatisations.
- Attribuez un responsable métier aux autorisations sensibles, même si la technologie met en œuvre le contrôle.
- Journalisez les modifications d’autorisations et les actions pertinentes des comptes techniques afin de faciliter leur examen.
Comment valider et maintenir la matrice
Avant de publier des changements, transformez la matrice en cas de test. Avec une autorisation explicite, un périmètre défini et, de préférence, des comptes ou données de test, confirmez que chaque action autorisée fonctionne et que chaque action non accordée est rejetée. Vérifiez à la fois les opérations de consultation et de modification, et testez les rôles ou comptes disposant du moindre privilège. La révision doit être défensive, planifiée et limitée à l’environnement et aux systèmes autorisés. [3]
Une révision utile ne cherche pas à démontrer que le système « est sécurisé » en termes absolus. Elle vise à détecter les écarts entre le processus approuvé, la matrice documentée et le comportement réel de l’API, du panneau d’administration et du site web. Si une règle diffère selon les canaux, si un compte technique possède des autorisations d’administrateur par précaution ou si un connecteur peut exporter des données qu’il n’utilise pas, il convient de corriger la conception et de valider à nouveau le changement. [1] [3]
Questions fréquentes
Quelle est la différence entre l’authentification et l’autorisation dans une API ?
L’authentification vérifie l’identité de la personne ou du compte qui effectue une requête, comme un utilisateur ou un compte d’intégration. L’autorisation décide quelle opération cette identité peut exécuter, sur quelle ressource, dans quel périmètre et sous quelles conditions. Les deux sont nécessaires.
Chaque intégration a-t-elle besoin de son propre compte ?
En général, séparer les comptes techniques par intégration facilite la limitation des autorisations, la journalisation des activités et le retrait des accès lorsqu’un processus change ou cesse d’être utilisé. Un compte partagé peut compliquer l’attribution des actions et l’application de limites précises.
Par quelle intégration est-il conseillé de commencer la matrice ?
Commencez par une intégration critique ou qui traite des données importantes, comme la connexion entre le web et le CRM, la boutique et l’ERP, ou le portail clients et le support. Documentez les opérations réelles, validez les limites avec les équipes métier et techniques, puis utilisez le résultat comme modèle pour les autres intégrations.