Contexte et enjeux
Les agents d’intelligence artificielle, déployés comme micro‑services sur Kubernetes, manipulent des informations sensibles en temps réel. Chez Mastercard, chaque transaction implique des données client soumises à des exigences réglementaires strictes. La protection traditionnelle se limite au repos (data at rest) et au transit (data in motion), mais les agents exposent également les données pendant leur traitement (data in use). Cette exposition crée un vecteur d’attaque que le chiffrement seul ne peut neutraliser.
Le problème s’accentue avec l’élasticité de Kubernetes : le dimensionnement horizontal et vertical multiplie les points d’exécution, augmentant la surface d’attaque. Mastercard doit donc garantir la confidentialité tout au long du cycle de vie de l’agent, depuis le développement jusqu’à la production, dans un environnement soumis à des législations multiples.
Architecture de protection avec OpenShift
Mastercard s’appuie sur Red Hat OpenShift, plateforme Kubernetes certifiée, enrichie de confidential containers. Ces conteneurs s’exécutent sur du matériel nu (bare‑metal) et utilisent des enclaves matérielles (ex. : Intel SGX ou AMD SEV) pour isoler la mémoire et le processeur de toute inspection externe. L’isolation crée un « environnement confidentiel » où le code de l’agent et ses données restent chiffrés même pendant l’exécution.
Le flux de données suit trois étapes : ingestion, traitement et sortie. À l’ingestion, les données sont chiffrées et déchiffrées uniquement à l’intérieur de l’enclave. Le traitement s’effectue dans le conteneur confidentiel, qui empêche les hyperviseurs ou les processus voisins d’accéder à la mémoire. À la sortie, les résultats sont re‑chiffrés avant d’être transmis aux services en aval. Cette chaîne assure la continuité de la confidentialité sans interrompre les capacités d’autoscaling de Kubernetes.
Mise en œuvre et garde‑fous opérationnels
Le déploiement repose sur des « guardrails » intégrés à chaque phase. En développement, les équipes utilisent des images signées et des politiques de conformité OpenShift pour interdire les conteneurs non‑confidentiels. En CI/CD, les pipelines vérifient la présence des annotations de confidentialité et déclenchent des scans de vulnérabilité avant la promotion en production.
En production, OpenShift applique des contrôles d’accès basés sur les rôles (RBAC) et des politiques de réseau (NetworkPolicy) afin de restreindre les communications inter‑pods. Les services de confiance (trust services) ajoutés par Mastercard offrent une attestation d’intégrité : chaque enclave génère un rapport cryptographique vérifiable par les services de gestion des clés (KMS). Cette attestation permet aux auditeurs de prouver que les données ont été traitées dans un environnement certifié.
Limites et perspectives
Malgré la robustesse des enclaves, la solution reste dépendante du support matériel. Les performances peuvent être impactées par le chiffrement en temps réel et par la surcharge de gestion des enclaves, surtout lors de pics de charge. De plus, la visibilité des logs est réduite, ce qui complique le diagnostic d’incidents sans compromettre la confidentialité.
À l’avenir, l’intégration de standards ouverts comme le Confidential Computing Consortium pourrait harmoniser les API d’attestation, facilitant la portabilité entre fournisseurs cloud. Mastercard continue d’étendre les garde‑fous pour couvrir les agents de nouvelle génération, tout en surveillant les évolutions des exigences légales internationales.
