.svg)
Où la sécurité des API fait défaut dans l'e-commerce moderne
Connecter davantage de systèmes est ce qui fait fonctionner une opération e-commerce moderne. C'est aussi ce qui crée plus de risques. Chaque nouvel outil que vous ajoutez est une API supplémentaire partageant des données avec le reste de la pile. Le risque augmente avec le nombre de connexions, et non avec la nouveauté de votre plateforme.
Le problème est rarement une faille majeure. Ce sont de petites lacunes qui s'accumulent. Une connexion utilise une méthode de connexion moderne, une autre fonctionne toujours avec une ancienne clé que quelqu'un a tapée dans le code il y a des années. L'une chiffre son trafic, l'autre a été configurée rapidement et n'a jamais été vérifiée depuis. Aucune connexion n'est sécurisée de la même manière, et personne n'a un enregistrement complet des données qui transitent par quel lien. C'est le problème plus large que la sécurité des données e-commerce traite, mais la couche API est l'endroit où il se manifeste réellement.
Une bonne sécurité des API n'est pas quelque chose que l'on achète une seule fois. C'est un ensemble d'habitudes que vous appliquez à chaque connexion, à chaque fois. Les sections ci-dessous couvrent celles qui comptent le plus. Ensuite, nous examinons la partie avec laquelle la plupart des équipes ont du mal, à savoir faire tout cela de manière cohérente à mesure que la pile technologique se développe.
Authentifier et autoriser chaque appel d'API
Commencez par l'identité. Chaque requête vers vos systèmes doit indiquer qui la fait et ce qu'elle est autorisée à faire. Aucune connexion ne doit fonctionner avec une clé partagée ou permanente.
Utilisez des méthodes de connexion où l'accès expire, comme OAuth 2.0, au lieu de clés API fixes qui restent indéfiniment dans un script. Donnez à chaque connexion uniquement l'accès dont elle a besoin. De cette façon, une clé volée pour votre outil d'expédition ne peut pas accéder aux enregistrements de paiement des clients. Là où un système le permet, gérez l'accès à partir d'un emplacement central via le SSO, afin de pouvoir l'accorder ou le révoquer rapidement.
Conseil : Commencez par lister chaque identifiant utilisé par vos intégrations. Vous ne pouvez pas protéger ce qui n'a pas été documenté.
Quelles données devraient réellement transiter par chaque connexion ?
Uniquement les champs dont le système récepteur a besoin, et rien de plus. Un outil d'expédition a besoin d'une adresse et d'une ligne de commande. Il n'a pas besoin de l'historique complet des paiements d'un client, il ne devrait donc jamais l'obtenir.
Chiffrez tout ce qui transite, à chaque appel, y compris le trafic entre les systèmes internes. Ensuite, limitez chaque connexion aux données qu'elle transporte réellement, et masquez ou supprimez les champs que l'autre système n'a aucune raison de conserver. L'envoi de moins de données réduit votre exposition en cas de violation d'une connexion. Cela réduit également vos obligations concernant l'endroit où les données réglementées sont autorisées à résider, ce qui est au cœur de la plupart des transferts de données transfrontaliers.
Enregistrer et surveiller chaque flux de données
Vous ne pouvez pas protéger ce que vous ne voyez pas. Chaque appel API et chaque erreur doivent être enregistrés : ce qui a été déplacé, quand et entre quels systèmes.
L'enregistrement n'est que la moitié du travail. L'autre moitié consiste à surveiller ces enregistrements pour détecter tout élément inhabituel, comme une augmentation des échecs de connexion, une connexion qui extrait soudainement beaucoup plus d'enregistrements que la normale, ou une activité à une heure où ce flux ne s'exécute jamais. Les alertes sur ces signes permettent de détecter un problème en quelques minutes au lieu d'attendre le prochain audit. Un historique complet et consultable vous permet également de prouver, après un incident, ce qui a été exposé et ce qui ne l'a pas été.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
