Exploiter API Gateway pour la souveraineté des données et la conformité réglementaire

Ming Wen

Ming Wen

November 28, 2022

Technology

Contexte et défis

Avec la popularité croissante des smartphones, de l'IoT et des réseaux mobiles à haut débit, une grande quantité de données sensibles a été générée, telles que des photos, des transactions financières, des localisations géographiques, des séquences ADN, des dossiers médicaux et des essais cliniques. L'analyse statistique basée sur ces données sensibles peut décrire avec précision les identités des individus, des entreprises ou des groupes de personnes, menaçant la vie privée et la sécurité nationale.

De plus en plus de législateurs nationaux prennent conscience de la gravité et de l'urgence de ce problème. Ils ont introduit de nombreuses lois et réglementations pour encadrer la collecte et le transfert transfrontalier de données. Le Règlement général sur la protection des données (RGPD) en Europe et la Loi sur la portabilité et la responsabilité en matière d'assurance maladie (HIPAA) aux États-Unis sont des précurseurs de ces lois. De nombreux pays en développement suivent également le mouvement :

Ainsi, les données générées par les terminaux et les utilisateurs, stockées et conservées par les fabricants, sont supervisées par plusieurs agences d'application de la loi. Par conséquent, les entreprises, en particulier les grandes multinationales, sont confrontées à de nombreux nouveaux problèmes urgents :

- Quelles données peuvent être collectées ? Lesquelles ne le peuvent pas ?

- Comment et où les données sont-elles stockées ?

- Les données peuvent-elles être transférées à travers les frontières ?

Ce sera un projet colossal de trier et de formuler des solutions pour tous ces problèmes. Ici, nous nous concentrerons principalement sur une question :

Pour les données client transmises via l'API, comment déterminer la souveraineté des données au niveau de la passerelle API pour s'assurer que les données sont traitées et stockées légalement ?

Par exemple, un utilisateur américain en voyage d'affaires en Europe utilise son téléphone pour effectuer un virement bancaire. À ce moment-là, les données de la transaction doivent être traitées et stockées par un serveur plus éloigné aux États-Unis, et non par un serveur européen plus proche.

Dans la seconde partie de cet article, nous donnerons une solution technique spécifique pour cet exemple. Avant cela, examinons d'abord la souveraineté des données et la conformité.

Qu'est-ce que la souveraineté des données et la conformité des données ?

Souveraineté des données

Un pays a non seulement la souveraineté sur l'espace physique, comme le territoire, l'espace aérien et les eaux territoriales, mais aussi sur ses données et son cyberespace national.

Prenons l'exemple du Règlement général sur la protection des données (RGPD), qui est une réglementation de l'UE pour la confidentialité et la protection des données personnelles. L'une des exigences les plus fondamentales du RGPD est la suivante : "Toutes les actions de collecte de données des utilisateurs nécessitent le consentement de l'utilisateur, et celui-ci a le droit de supprimer ses données personnelles stockées à tout moment."

Par conséquent, si une entreprise souhaite transférer des données européennes vers d'autres régions, elle doit s'assurer que les exigences de souveraineté des données du pays tiers correspondent à celles de l'UE. Concernant la nécessité pour les données de se conformer aux lois locales, il existe en effet de nombreuses préoccupations dans les entreprises multinationales.

Une autre préoccupation est la Loi PATRIOT des États-Unis, qui exige que toutes les données stockées aux États-Unis, ou stockées par des entreprises américaines, soient sous la supervision des États-Unis. Le ministère de la Justice et la Central Intelligence Agency (CIA) ont le droit de demander aux entreprises de fournir des données. En 2013, le ministère de la Justice américain a demandé à Microsoft de divulguer certaines informations d'e-mail stockées sur ses serveurs en Irlande. Microsoft a rejeté la demande du ministère de la Justice américain car cela violerait les exigences réglementaires de l'Union européenne. Ensuite, le ministère de la Justice a poursuivi Microsoft en justice, mais Microsoft a gagné le procès. Plus tard, pour éviter de risquer la souveraineté des données, de nombreuses entreprises aux États-Unis ont placé leurs centres de données directement en Europe, pensant que cela serait sûr. Néanmoins, il y a eu récemment des cas où les juges ont statué que les États-Unis avaient le droit de demander des données aux entreprises américaines en Europe. C'est ce qu'on appelle la juridiction extraterritoriale des États-Unis.

La souveraineté des données a en effet posé des défis importants aux entreprises dans leurs activités mondiales, et la manière de gérer correctement la question de la souveraineté des données dans les entreprises est devenue particulièrement importante.

Conformité des données

Pour les entreprises multinationales, la synchronisation des données est relativement simple s'il n'y a pas d'exigence de souveraineté des données. Les données d'un utilisateur aux États-Unis peuvent facilement être synchronisées avec des serveurs en Asie et au Royaume-Uni, comme le montre le diagramme ci-dessous. De cette manière, lorsqu'un Américain voyage en Asie, il peut également accéder aux différentes données générées lorsqu'il était aux États-Unis.

Synchronisation des données entre les IDC

Avec les exigences de conformité de la souveraineté des données, beaucoup de données ne peuvent pas être synchronisées et accessibles entre les pays. Les entreprises doivent distinguer les utilisateurs et isoler leurs données associées. Une méthode standard consiste à diviser les utilisateurs en fonction des régions.

Prenons l'exemple du Kindle d'Amazon, les livres électroniques achetés par les utilisateurs aux États-Unis ne peuvent pas être téléchargés sur leur Kindle avec un compte chinois. Cela s'explique par le fait que les données entre différents pays (régions) sont entièrement isolées. L'architecture du système est la suivante :

Accédez uniquement à votre propre IDC

Alors, que faut-il faire techniquement si un utilisateur au Royaume-Uni souhaite accéder à Amazon UK avec un compte américain ? Examinons le diagramme d'architecture ci-dessous. La plupart des produits de passerelle API existants proposent des solutions similaires.

Solution existante au niveau de la passerelle API

Solution de passerelle API pour la conformité des données

Nous pouvons résumer le cœur de cette solution en une phrase :

La passerelle API au Royaume-Uni identifie l'utilisateur. Si l'API découvre que l'utilisateur est enregistré aux États-Unis, elle sera redirigée vers les serveurs américains pour traitement.

Cependant, il existe également des défis techniques cachés derrière cela, ainsi que des risques de non-conformité :

  1. La passerelle API a besoin de capacités de planification de routage fine, obtient des données à partir de l'en-tête HTTP, des arguments de requête et du corps de la requête, et coopère avec des requêtes de base de données externes pour déterminer quel serveur doit traiter l'utilisateur.

  2. Le réseau entre les régions doit être connecté pour transférer la requête. Le centre de données au Royaume-Uni et celui aux États-Unis doivent être connectés.

  3. La passerelle API dans le centre de données au Royaume-Uni pourrait avoir déjà déchargé le certificat SSL, lu le contenu de l'API, et enregistré les données sur le disque local ou d'autres services via des journaux d'accès, des journaux d'audit, des systèmes d'observabilité, etc.

Existe-t-il un moyen de résoudre ces problèmes ?

Réseau multicouche : La solution d'Apache APISIX pour garantir la conformité de la transmission des données API

Nous introduisons ici le concept de "réseau multicouche" dans APISIX pour garantir la conformité et la sécurité des données transmises par l'API au niveau de la passerelle API. Un réseau multicouche, comme son nom l'indique, divise la passerelle API en deux couches, la couche 1 et la couche 2, comme le montre la figure suivante :

Passerelle API avec réseau multicouche pour la conformité des données

  • Passerelle API de couche 1 : responsable du déchargement du certificat SSL, de la planification fine du routage et de la décision de quelle passerelle API de couche 2 doit traiter les requêtes API.
  • Passerelle API de couche 2 : Il s'agit de la passerelle API d'origine, qui n'a pas besoin de se soucier de la conformité des données.

Revenons à la question posée au début de l'article : comment un utilisateur enregistré aux États-Unis peut-il garantir la conformité des données API, quel que soit l'endroit où il effectue sa transaction ?

Tout d'abord, la requête API sera envoyée à la passerelle API de couche 1, qui est essentiellement Apache APISIX mais ajoute l'objet réseau multicouche, sur lequel des plugins personnalisés peuvent être liés :

  1. La passerelle API de couche 1 définit l'adresse, le poids et d'autres informations des clusters de passerelles API de couche 2. Ici, nous configurons le cluster américain et le cluster britannique :
http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/clusters/cluster-US
{
  "desc": "description",
  "http_port": 80,
  "https_port": 443,
  "gateways": [
    {"host": "IP1", "weight": 1},
    {"host": "IP2", "weight": 2}
  ]
}

http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/clusters/cluster-UK
{
  "desc": "description",
  "http_port": 80,
  "https_port": 443,
  "gateways": [
    {"host": "IP1", "weight": 1},
    {"host": "IP2", "weight": 2}
  ]
}
  1. Définir les règles de routage sur le réseau multicouche, et les lier avec le plugin bar :
http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/routes/bank-foo
{
  "desc": "bank API",
  "hosts": ["foo.com"],
  "uris": ["/*"],
  "plugin_id": "bar"
}
  1. Définir des plugins personnalisés :
http://***/apisix/admin/multilayer_network/plugins/bar
{
  "desc": "plugin",
  "plugins": {
    "jwt-auth": {
      ... ...
    },
    "foo-upstream-selector": {
      "scheme": "HTTPS"
      ... ...
    },
    ... ...
  }
}

Ici, nous avons lié deux plugins. Le plugin jwt-auth est utilisé pour compléter l'authentification de la requête. Le foo-upstream-selector est utilisé pour lire des informations telles que l'ID de l'utilisateur, le pays/région et le cluster auquel l'utilisateur appartient à partir de la base de données et spécifie vers quel cluster de passerelle API de couche 2 il doit être routé.

Cette architecture multicouche garantit la conformité des données entre différents pays.

Conclusion

En résumé, la planification fine du routage rendue possible par l'architecture multicouche de la passerelle API peut aider les entreprises à traiter rapidement et en toute sécurité les données API tout en respectant les exigences de conformité des données. Nous fournissons cette fonctionnalité prête à l'emploi dans API7 Cloud et API7 Enterprise. N'hésitez pas à remplir le formulaire pour nous contacter.

Tags:
API Gateway Concept
Data Management