Auteur : clarus.news Source : clarus.news

Mode rédactionnel : CLARUS_ANALYSIS Recommandation d'indexation : INDEX Langue/Rôle : FULL_ANALYSIS Date de vérification des faits : 2026-02-20

Résumé exécutif

La sécurité des charges de travail IA dans le cloud nécessite un changement de paradigme fondamental par rapport à la sécurité cloud traditionnelle. Tony de la Fuente, fondateur du projet open-source Prowler, avertit d'un élargissement du « fossé de responsabilité partagée » dans les services IA gérés tels qu'AWS Bedrock ou Google Vertex AI. Le problème central : alors que les fournisseurs de cloud définissent clairement leurs domaines de responsabilité pour les services classiques (comme S3 ou EC2), il reste flou de savoir quelles options de configuration et options de sécurité les clients doivent gérer eux-mêmes. La complexité croît exponentiellement lorsque les services IA agissent comme couche intermédiaire vers OpenAI, Claude ou d'autres modèles – ce qui crée des quatrième et cinquième niveaux de responsabilité.

Personnes

Sujets

  • Sécurité de l'IA vs. sécurité cloud
  • Modèle de responsabilité partagée
  • Outils de sécurité open-source
  • Sécurité de l'infrastructure en tant que code
  • Configuration des LLM et protection des données

Clarus Lead

Le passage de la sécurité cloud à la sécurité IA n'est pas simplement une évolution technique, mais un réalignement architectural. Alors que 90 % de tous les logiciels contiennent du code open-source et que les modèles IA sont de plus en plus déployés en environnement de production, un vide critique émerge : Les recommandations de sécurité documentées par les fournisseurs pour des services comme AWS Bedrock ont doublé en 18 mois, ce qui prouve que les responsabilités se déplacent progressivement du fournisseur vers les clients. Pour les décideurs, cela signifie que les modèles traditionnels de gouvernance cloud (réseau, IAM, journalisation) sont insuffisants pour les services IA – des couches de sécurité supplémentaires au niveau du modèle, lors de l'intégration d'outils (comme les MCPs) et dans l'accès aux données sont nécessaires.

Résumé détaillé

Le problème fondamental du fossé de responsabilité partagée

À l'ère du cloud classique, le partage des responsabilités était compréhensible : AWS gère l'infrastructure physique, l'hyperviseur, le réseau ; les clients configurent les groupes de sécurité, les rôles IAM, le chiffrement. Avec les services IA, cette frontière s'estompe dramatiquement. Un déploiement AWS Bedrock offre des centaines d'options de configuration – du contrôle d'accès au modèle à la journalisation en passant par les politiques de stockage des données – dont les implications de sécurité sont inconnues de nombreuses équipes. La situation s'aggrave lorsque Bedrock lui-même agit comme passerelle vers ChatGPT, Claude ou des modèles propriétaires. Soudainement, plusieurs limites de confiance existent : AWS (Infrastructure), configuration Bedrock (Gouvernance), LLM tiers (Sécurité du service). Les clients ne savent souvent pas qu'ils doivent gérer eux-mêmes cette complexité.

Architecture plutôt que simple configuration

De la Fuente souligne une distinction critique : la sécurité de l'IA est moins un problème de configuration qu'un problème de conception architecturale. Une erreur courante consiste à connecter directement les protocoles de contexte de modèle (MCPs) – les interfaces entre les modèles IA et les sources de données – aux accès aux bases de données. À la place, un contrôle d'accès strict basé sur les rôles (RBAC) devrait se situer sous la couche MCP. Cela signifie : l'IA ne reçoit pas de permissions directes sur les bases de données ; au lieu de cela, une couche API dédiée avec RBAC garantit que le modèle n'accède qu'aux données dont il a besoin. Cela nécessite des décisions de conception avant la phase de déploiement, non après.

Le rôle de l'open-source et du scanning continu

Prowler, en tant qu'outil open-source avec 300+ contributeurs, a étendu son focus de la pure sécurité cloud (seaux S3, politiques IAM) aux charges de travail IA. L'outil utilise maintenant des mappages OWASP-AI et l'intégration avec des cadres tels que « From » (un outil d'évaluation des LLM) pour vérifier à la fois la sécurité de l'infrastructure et celle du modèle. L'avantage de l'open-source : la transparence favorise la confiance, l'itération plus rapide, et – grâce aux extensions IA – la génération automatique de détections. Par exemple : Google Cloud Code aurait de grandes difficultés à effectuer une simple vérification de sécurité (« Y a-t-il des seaux S3 accessibles publiquement ? ») ; Prowler résout cela élégamment en combinant un moteur basé sur des règles avec des détections générées par l'IA.

L'IA fantôme et la conformité à la protection des données

Un risque souvent négligé est l'« IA fantôme » : les employés téléchargent des contrats contenant des données personnelles ou des informations commerciales dans ChatGPT, Claude ou DeepSeek – sans savoir que ces services utilisent par défaut les entrées pour l'entraînement des modèles. Seuls les désengagements explicites (par exemple, ChatGPT Enterprise, mode API sans apprentissage) empêchent cela. Ce n'est pas un problème technique, mais un problème de gouvernance et de sensibilisation – il nécessite des politiques, des outils pour contrôler qui peut utiliser quels services IA, et la surveillance de l'accès IA aux données sensibles.

Messages clés

  • Le fossé de responsabilité partagée s'aggrave : Les services IA gérés transfèrent plus de responsabilité de sécurité aux clients que les services cloud classiques ; ce transfert n'est pas documenté de manière transparente.
  • Architecture avant configuration : La sécurité des charges de travail IA est un problème de conception (RBAC sous les MCPs, API gating), pas seulement un problème de configuration.
  • L'open-source permet une adaptation plus rapide : Les outils comme Prowler peuvent, avec l'intégration IA (évaluations LLM, génération automatique de détections), répondre plus rapidement aux nouvelles questions de sécurité que les solutions propriétaires.
  • L'évaluation continue est nécessaire : De nouveaux modèles et services IA émergent chaque mois ; les vérifications de sécurité statiques ne suffisent pas – un scanning continu sur l'infrastructure, le code et l'exécution est requis.
  • L'IA fantôme est un problème de gouvernance : Les mécanismes de contrôle pour l'utilisation de l'IA et la conformité à la protection des données doivent être adressés au niveau organisationnel, pas seulement au niveau technique.

Questions critiques

  1. [Preuve/Qualité des données] Quelles sources prouvent le doublement des recommandations de sécurité pour Bedrock entre son lancement et début 2026 ? Y a-t-il des rapports d'audit internes AWS ou des retours de clients disponibles pour documenter ce changement ?

  2. [Qualité/Validité des données] L'affirmation « 90 % de tous les logiciels sont open-source » – est-elle basée sur une étude spécifique (par exemple, Black Duck, GitHub) ? Dans quels contextes (Entreprise, Startups) ce taux est-il fiable ?

  3. [Conflits d'intérêts] De la Fuente est fondateur de Prowler, un outil de scanning de sécurité. Son focus sur les lacunes de configuration et les déficits architecturaux pourrait-il inconsciemment surestimer la taille du marché pour son produit ?

  4. [Causalité/Alternatives] Le fossé de responsabilité partagée est-il vraiment dû à la conception du service Bedrock, ou reflète-t-il simplement la complexité accrue des systèmes d'IA générative – un problème qu'un modèle de responsabilité partagée simplifiée ne pourrait pas résoudre ?

  5. [Contre-hypothèse] La proposition de placer les MCPs « sous » le RBAC réduit la flexibilité de l'IA et pourrait augmenter la latence. Y a-t-il une documentation sur les compromis de performance et les cas d'utilisation où de telles architectures ne peuvent pas évoluer ?

  6. [Faisabilité] Comment les organisations de taille moyenne sans équipes de sécurité dédiées peuvent-elles mettre en pratique les modèles architecturaux proposés (couche RBAC, isolation MCP, scanning continu) si ces conceptions nécessitent des compétences substantielles en cloud et en IA ?

  7. [Effets secondaires] Les outils open-source comme Prowler permettent la transparence, mais augmentent aussi la surface d'attaque pour les acteurs menaçants qui comprennent et contournent la logique de l'outil. Comment ce risque est-il adressé ?

  8. [Risques de mise en œuvre] Les contrôles de l'IA fantôme (politiques, surveillance, désengagements) nécessitent d'être acceptés culturellement au niveau organisationnel. Quelles organisations ont mis en œuvre avec succès de tels programmes, et lesquelles ont échoué ?

Autres dépêches

  • Incident DeepSeek : Un incident de sécurité non nommé avec DeepSeek est mentionné ; les détails restent flous, mais pourraient indiquer des déficits de protection des données ou de sécurité chez les nouveaux modèles IA.
  • Extensions Prowler élargies : Au-delà d'AWS, Google Cloud et Azure, des fournisseurs cloud de niche et des solutions SaaS (Microsoft 365, MongoDB Atlas) sont désormais pris en charge.

Répertoire des sources

Source primaire : Episode du Cloud Security Podcast avec Tony de la Fuente – https://anchor.fm/s/10fb9928/podcast/play/115712786/

Sources complémentaires :

  • Référentiel Prowler Open-Source (GitHub)
  • Documentation AWS Bedrock
  • Cadre de sécurité OWASP AI
  • Documentation From (outil d'évaluation LLM)

Statut de vérification : ✓ 2026-02-20

Ce texte a été créé avec l'assistance d'un modèle IA. Responsabilité éditoriale : clarus.news | Vérification des faits : 2026-02-20