Managed CNAPP : externalisez les opérations de sécurité cloud-native

Managed CNAPP confie l’exploitation de votre plateforme de protection des applications cloud-native à un prestataire. Découvrez les modèles de service, quand externaliser et comment en choisir un.

Qu’est-ce qu’un Managed CNAPP ?

Un Managed CNAPP est un modèle de service dans lequel un prestataire exploite votre plateforme de protection des applications cloud-native (CNAPP) et ses opérations de sécurité pour votre compte. La plateforme reste la vôtre. La responsabilité aussi. Ce qui change, c’est qui assure la surveillance.

Le niveau d’exigence de cette surveillance est désormais inscrit dans la politique fédérale. En décembre 2024, la Binding Operational Directive 25-01 de la CISA a ordonné aux agences civiles fédérales d’identifier et de corriger les mauvaises configurations cloud et d’exécuter une surveillance continue sur l’ensemble de leurs tenants cloud, après que des contrôles mal configurés ont offert aux attaquants une voie d’exfiltration de données. Le mot clé est continu. Maintenir ce niveau de couverture sur chaque compte que vous exploitez représente une charge que peu d’équipes réduites peuvent assurer 24 h/24 et 7 j/7, et c’est précisément cet écart que le modèle managé vise à combler.

Comment le Managed CNAPP s’inscrit dans la cybersécurité

La sécurité cloud-native couvre la configuration, l’identité, les workloads et Kubernetes, et chaque couche génère des résultats en continu. 

Un CNAPP regroupe ces couches dans une seule plateforme. Le modèle managé y ajoute une équipe dédiée, afin que la couverture soit maintenue la nuit et le week-end, lorsqu’un bucket de stockage exposé ou un rôle trop permissif est aussi accessible à un attaquant qu’en pleine journée. Le prestataire exécute les opérations et, dans le cadre du modèle de responsabilité partagée, votre organisation reste responsable de sa posture de sécurité cloud et de sa conformité réglementaire.

Composants clés d’un service Managed CNAPP

Un service Managed CNAPP comporte deux couches : la plateforme qui produit les résultats, et les personnes et processus qui agissent sur ceux-ci.

Ce que couvre le CNAPP sous-jacent

La plateforme consolide quatre capacités, chacune représentant une couche exploitée par le prestataire managé afin que votre équipe puisse lire le risque cloud en un seul endroit, de la phase de build jusqu’au runtime :

• Cloud security posture management (CSPM) identifie les mauvaises configurations et les violations de conformité dans l’infrastructure cloud, des buckets de stockage ouverts aux règles de pare-feu trop permissives.
• Cloud workload protection (CWP) sécurise les conteneurs, les machines virtuelles, les fonctions serverless et les serveurs au runtime dans les environnements publics, privés et hybrides.
• Cloud infrastructure entitlement management (CIEM) analyse les autorisations des identités humaines et non humaines, signale les privilèges excessifs et applique une politique de moindre privilège.
• Kubernetes security posture management (KSPM) exécute des contrôles de mauvaise configuration sur les clusters Kubernetes et valide l’alignement de conformité.

Ensemble, elles répondent à quatre questions concrètes sur votre cloud : quelles configurations et quels contrôles de conformité ont dérivé (CSPM), quels workloads en cours d’exécution sont attaqués (CWP), quelles identités humaines et non humaines disposent de plus d’accès que nécessaire (CIEM), et quels clusters Kubernetes sont mal configurés (KSPM).

La plateforme signale ces résultats en continu, mais elle ne les trie pas, ne les classe pas selon leur exploitabilité et ne les attribue pas à un responsable. C’est ce travail que prend en charge le service managé.

Ce qu’ajoute le service managé

En plus de la plateforme sous licence, le prestataire fournit une couche opérationnelle dotée en personnel qui l’exploite au quotidien :

Couche opérationnelle	Ce que fait le prestataire
Gestion continue de la posture	Suit les configurations et la conformité à mesure que l’infrastructure dérive sur les comptes connectés.
Correction des mauvaises configurations	Identifie et priorise les problèmes, les transmet à l’équipe responsable et en assure le suivi jusqu’à leur résolution.
Gestion des vulnérabilités et des droits	Analyse sans agent sur les systèmes d’exploitation et les workloads, avec analyse CIEM des identités sur-privilégiées.
Réponse aux menaces au runtime	Protection basée sur agent ou capteur qui surveille les workloads et stoppe les attaques actives pendant leur exécution.
Couverture analyste	Triage, filtrage des faux positifs, escalade des résultats confirmés et reporting selon une cadence définie.

Le personnel du prestataire et les heures de couverture définies sont ce que le service ajoute à une plateforme que vous pourriez autrement exploiter seul. La question suivante est de savoir si l’exploiter seul est le bon choix.

Fonctionnement d’un Managed CNAPP

Le service Managed CNAPP fonctionne comme une boucle continue en six phases. Le prestataire prend en charge les étapes opérationnelles. Votre équipe entre dans la boucle lorsqu’un résultat devient un travail sur lequel vous devez agir, afin que vous sachiez exactement où la responsabilité vous revient.

1. Intégration et onboarding. Le prestataire se connecte à vos comptes cloud sur AWS, Azure, GCP et tout autre fournisseur que vous utilisez. Un déploiement complet sur tous les comptes, y compris les comptes développeur, établit la base de référence avant le début du réglage fin.
2. Analyse sans agent et couverture runtime. Le prestataire active deux couches de visibilité. L’analyse sans agent interroge les API des fournisseurs cloud pour évaluer les configurations, les droits et les vulnérabilités sans installer de logiciel sur les workloads. Une couverture basée sur agent ou capteur ajoute une protection runtime en temps réel pour les clusters Kubernetes et les workloads dans des conteneurs ou des machines virtuelles (VM).
3. Surveillance continue. L’analyse s’exécute en continu afin que les nouveaux comptes, workloads et changements de configuration soient couverts dès leur apparition. La vision de la posture et des vulnérabilités reste à jour entre les points de contrôle.
4. Triage et priorisation des alertes. Le prestataire filtre les faux positifs et classe les résultats confirmés selon leur exploitabilité et leur exposition, avec l’impact métier reflété dans le classement.
5. Correction et transfert à la réponse à incident. Le prestataire transmet les résultats priorisés à l’équipe responsable avec le contexte nécessaire pour agir. Le prestataire prend en charge l’identification, le triage et l’acheminement. Votre équipe prend en charge l’exécution de la correction.
6. Reporting. Le prestataire fournit des rapports selon une cadence définie, avec des métriques de sécurité liées aux résultats métier.

La boucle ne s’arrête jamais. La seule question est de savoir qui doit l’exploiter : votre propre équipe ou un prestataire. 

Quand externaliser les opérations de sécurité cloud-native

Le choix entre exploiter les opérations CNAPP en interne et les confier à un prestataire dépend des effectifs de votre équipe, de son expertise, de vos exigences de couverture et de vos besoins de contrôle.

Condition	Favorise l’externalisation	Favorise l’interne
Effectifs en sécurité cloud	Équipe réduite avec peu de personnel dédié à la sécurité cloud	SOC mature avec des ingénieurs sécurité cloud dédiés
Heures de couverture	Couverture continue nécessaire, l’équipe actuelle ne couvre que les heures ouvrées	Modèle existant de suivi continu mondial ou par rotation déjà doté en personnel
Délai de mise en valeur	Besoin rapide de couverture opérationnelle	Temps disponible pour construire et ajuster en interne
Complexité multi-cloud	Multiples fournisseurs cloud, prolifération des comptes entre unités métier	Environnement mono-cloud ou dual-cloud étroitement contrôlé
Expertise cloud-native	Équipe solide on-premises, profondeur limitée sur Kubernetes, les conteneurs ou IAM	Expertise existante approfondie sur les opérations CSPM, CWPP et CIEM
Exigences de contrôle	Disposition à définir une frontière de responsabilité partagée avec un prestataire	Exigences strictes de résidence des données, contraintes réglementaires sur l’accès des tiers ou politique interdisant l’externalisation des opérations de sécurité
Maturité des outils	CNAPP récemment acquis ou pas encore opérationnalisé	CNAPP entièrement déployé et ajusté, équipe l’exploitant efficacement

Trois modèles de service se situent sur le spectre de l’externalisation :

• Self-managed CNAPP signifie que vous licenciez la plateforme et l’exploitez en interne. Vos analystes assurent la surveillance, ajustent les résultats, trient les alertes et pilotent la correction.
• Co-managed CNAPP signifie que le prestataire fournit la plateforme et l’expertise opérationnelle, en prenant en charge l’onboarding, le réglage fin, la priorisation des alertes et le support d’escalade. Vous conservez la responsabilité principale des décisions d’investigation et de correction.
• Fully managed CNAPP signifie que le prestataire assume la responsabilité opérationnelle de la surveillance, du triage, de l’investigation et de la coordination de la correction. Vous conservez l’autorité de gouvernance et l’exécution de la correction sur les résultats transmis.

Votre position sur ce spectre détermine ce que vous payez et ce que vous conservez. La question suivante est de savoir si un prestataire donné peut le fournir sur l’ensemble de votre environnement cloud.

Ce qu’il faut évaluer chez un prestataire Managed CNAPP

Un prestataire CNAPP managé est évalué selon deux catégories : les engagements de niveau de service qui régissent la relation, et l’intégration technique qui détermine s’il peut couvrir votre environnement cloud.

Considérations relatives aux SLA

Un accord de niveau de service (SLA) mesurable définit des engagements spécifiques et limités dans le temps. Un SLA vague promet une « réponse rapide » sans préciser ce que signifie rapide. L’analyse des SLA cloud de MITRE a constaté une variation importante dans la manière dont les niveaux de performance sont définis et dont le risque est partagé entre prestataire et client. Lisez les définitions, pas les adjectifs.

Lorsque vous évaluez les SLA, concentrez-vous sur les engagements qui correspondent au risque opérationnel :

• Temps de réponse pour les résultats confirmés et modèle d’escalade d’astreinte
• Heures de couverture et délai de triage des alertes
• Taux de traitement des faux positifs et vitesse d’acheminement de la correction
• Cadence de reporting

Exigez des SLA contractuellement contraignants. Vérifiez si le prestataire rend compte de manière transparente de ses performances SLA et ce qui se passe lorsque les SLA ne sont pas respectés.

Exigences d’intégration multi-cloud

Votre prestataire doit se connecter à chaque environnement cloud que vous exploitez. Évaluez l’onboarding sans agent : à quelle vitesse le prestataire peut se connecter à vos comptes AWS, Azure et GCP et commencer l’analyse. Vérifiez si la couverture s’étend à tout fournisseur cloud supplémentaire que vous utilisez. Singularity™ Cloud de SentinelOne, par exemple, couvre AWS, Azure, GCP, Oracle Cloud Infrastructure (OCI) et Alibaba Cloud depuis une console unique.

Évaluez la couverture des conteneurs et de Kubernetes : le CNAPP sous-jacent du prestataire couvre-t-il vos clusters Kubernetes, registres de conteneurs et fonctions serverless ? Vérifiez quelles données quittent votre environnement, où elles sont stockées et si l’architecture du prestataire répond à vos exigences réglementaires.

CIEM doit couvrir l’évaluation et la correction des mauvaises configurations dans les politiques de gestion des identités et des accès (IAM).

Défis et limites du Managed CNAPP

L’externalisation des opérations de sécurité cloud-native introduit des contraintes structurelles qui persistent même lorsque la relation est bien gérée.

1. Réduction de la visibilité directe. Un prestataire qui exploite votre CNAPP s’interpose entre votre équipe et les résultats bruts. Le Software Engineering Institute (SEI) de Carnegie Mellon documente ce risque dans l’externalisation cloud : les organisations perdent en visibilité et en contrôle sur les actifs et opérations qu’elles délèguent, et les récupérer nécessite une surveillance et une analyse que la journalisation réseau on-premises fournissait auparavant.
2. Ambiguïté de la frontière de responsabilité. Le modèle de responsabilité partagée s’applique ici : le prestataire managé opère dans votre couche de responsabilité, et votre organisation reste responsable vis-à-vis du fournisseur cloud et des régulateurs.
3. Dépendance au prestataire et verrouillage. Les formats de données non standard, les API propriétaires et la dépendance à des outils spécifiques au prestataire rendent le coût et l’effort d’un changement de prestataire plus élevés que prévu initialement.
4. Le prestataire comme risque de chaîne d’approvisionnement. Accorder à un tiers un accès opérationnel à votre environnement cloud constitue en soi un risque à gérer. Le NCSC du Royaume-Uni note qu’un accès tiers non contrôlé et non observé est un anti-pattern : externalisez l’administration ou des fonctions opérationnelles et vous dépendez d’une autre organisation pour maintenir la sécurité de votre système. Limitez cet accès. Définissez les frontières de périmètre, surveillez l’activité du prestataire et examinez en continu son personnel, ses processus et sa technologie.
5. Latence dans le transfert entre alerte et action. Chaque résultat nécessitant une action de votre équipe passe par le processus de triage et d’acheminement du prestataire. Ce transfert peut retarder la correction.
6. Retard de couverture dans les environnements à évolution rapide. De nouveaux comptes, workloads ou services apparaissent entre les cycles d’onboarding, et la couverture du prestataire reflète l’environnement tel qu’il était configuré au dernier point de contrôle d’intégration.

Chacun de ces points est un mode de défaillance connu. Les modes de défaillance connus peuvent être conçus en amont. Les pratiques ci-dessous les éliminent avant qu’ils ne vous coûtent quoi que ce soit.

Bonnes pratiques Managed CNAPP

Les relations qui tiennent dans la durée partagent quelques habitudes opérationnelles. Chacune d’elles corrige un mode de défaillance qui, autrement, bloque le travail de sécurité externalisé.

Définissez par écrit la frontière de responsabilité partagée avant que le prestataire n’achemine le moindre résultat. Lorsque la responsabilité de clôture n’est pas attribuée par catégorie de résultat, les éléments restent non résolus pendant que chaque partie suppose que l’autre s’en charge. Cette même clarté protège votre propre responsabilité : le prestataire exécute les opérations, et votre organisation reste propriétaire de sa posture de sécurité cloud, de sa conformité réglementaire et de l’exécution de la correction.

Intégrez le prestataire dans les workflows que vous utilisez déjà. Associez chaque type d’escalade à un responsable interne dans vos runbooks IR existants afin que les résultats du prestataire arrivent sous forme de travail de réponse structuré qui s’intègre à votre processus. 

Conservez également votre propre accès à la console CNAPP et aux rapports du prestataire, afin de pouvoir valider indépendamment les performances du prestataire par rapport à ses propres chiffres. Gouvernez le reste de la relation à partir de chiffres que vous vérifiez selon une cadence définie :

• Suivez les SLA que vous avez contractualisés et examinez-les selon un calendrier défini. Un SLA que personne ne mesure n’a aucun poids opérationnel.
• Liez le reporting aux résultats métier afin que chaque revue relie les métriques de sécurité au travail qu’elles protègent.
• Exécutez des audits de couverture sur votre environnement actif, y compris les comptes développeur, les environnements de staging et les nouveaux comptes cloud provisionnés.

Sélectionner sur le prix avant la couverture est un raccourci coûteux : un prestataire moins cher qui ne surveille qu’une partie de votre environnement laisse le reste sans surveillance.

Améliorez votre Managed CNAPP avec SentinelOne

Singularity Cloud Security est le CNAPP de SentinelOne. Il fonctionne du build au runtime avec une gestion de posture sans agent et une protection des workloads en temps réel sur les comptes cloud, les conteneurs, Kubernetes, les services d’IA et le serverless. Une seule console couvre AWS, Azure, GCP, OCI et Alibaba Cloud depuis une seule console. 

La couche sans agent, Singularity Cloud Native Security, confirme quels résultats sont réellement exploitables grâce à Verified Exploit Paths, afin qu’un prestataire transmette les résultats à forte valeur au bon responsable et passe moins de temps sur le bruit. Au runtime, les actions de réponse automatiques, notamment l’arrêt de processus, l’isolation réseau, la mise en quarantaine de fichiers et la déconnexion de pod, contiennent les incidents avant l’intervention d’un analyste. La Singularity Platform unifie la télémétrie endpoint, cloud et identité dans un seul agent, une seule console et un seul data lake. Elle a enregistré 88 % d’alertes en moins dans les 2024 MITRE ATT&CK® Evaluations avec 100 % d’identification.

Avec Purple AI™, la chasse aux menaces en langage naturel et l’investigation agentique réduisent le temps que les analystes consacrent à la collecte de preuves. Le snapshot d’avril 2025 d’IDC lui attribue une identification des menaces 63 % plus rapide et une correction 55 % plus rapide. Un prestataire peut exécuter tout cela pour votre compte. Une équipe interne réduite peut l’exploiter directement.

Réservez une démo SentinelOne pour voir ce que Singularity Cloud retire de la charge de votre équipe.

Points clés à retenir

Le Managed CNAPP transfère la charge opérationnelle liée à l’exploitation d’une plateforme de protection des applications cloud-native à un prestataire qui assure pour votre compte la surveillance, le triage et l’acheminement de la correction. La décision d’externaliser dépend des effectifs de votre équipe, de vos besoins de couverture et de la complexité de votre environnement cloud. 

Les relations réussies reposent sur une frontière de responsabilité clairement définie, des SLA mesurables, une intégration dans vos workflows de réponse à incident et une validation continue de la couverture. Si vous maîtrisez ces quatre éléments, l’externalisation cesse d’être une perte de contrôle. Vous définissez la frontière, vous conservez la gouvernance et vous n’êtes plus celui qui trie les alertes à 3 heures du matin.

FAQ

Qu’est-ce que Managed CNAPP ?

Le CNAPP managé est un modèle de service dans lequel un fournisseur exploite une plateforme de protection des applications cloud-native pour votre compte. Le fournisseur prend en charge la gestion continue de la posture, la remédiation des erreurs de configuration, le triage des alertes et la réponse aux menaces à l’exécution dans l’ensemble de vos environnements cloud. 

Vous conservez l’autorité de gouvernance sur les décisions d’escalade ainsi que la responsabilité de l’exécution de la remédiation. Ce modèle transfère la charge opérationnelle liée à l’exploitation du CNAPP, y compris le personnel d’analystes et le travail continu d’ajustement des résultats, à des spécialistes externes de la sécurité cloud.

Comment Managed CNAPP est-il tarifé ?

La tarification suit généralement la taille de l’environnement couvert : le nombre de comptes cloud connectés, de charges de travail protégées ou d’actifs analysés, souvent selon un abonnement par paliers. 

Les heures de couverture et la profondeur du service font également varier le montant, car une couverture continue et une investigation complète coûtent plus cher qu’un triage pendant les heures ouvrées. Demandez à un prestataire d’associer le prix aux comptes et charges de travail spécifiques qu’il surveillera, afin que le devis reflète votre périmètre réel.

Combien de temps prend l’intégration de Managed CNAPP ?

La connexion sans agent aux comptes cloud via les API des fournisseurs met en place la visibilité sur la posture et les droits en quelques heures, puisqu’aucun logiciel n’est installé sur les charges de travail. La couverture d’exécution pour Kubernetes et les charges de travail de conteneurs ou de VM ajoute un déploiement d’agent ou de capteur. 

Le travail le plus long consiste à ajuster la configuration : filtrer les faux positifs et associer les escalades à vos responsables, ce qui se stabilise au cours des premières semaines. La couverture complète dépend de la connexion de chaque compte, y compris les environnements de développement et de préproduction.

Comment les services Managed CNAPP gèrent-ils les environnements multi-cloud ?

Les prestataires Managed CNAPP se connectent à chaque environnement cloud via les API des fournisseurs cloud. Le prestataire Managed CNAPP maintient une vue unifiée de la posture, des droits et de la protection des charges de travail sur l’ensemble des comptes connectés. 

L’analyse CIEM couvre les modèles d’identité entre les fournisseurs, en signalant les limites de confiance incohérentes et les autorisations excessives. Des audits de couverture doivent être exécutés régulièrement pour confirmer que le périmètre de surveillance du prestataire suit le rythme des nouveaux comptes et charges de travail dans toutes les régions.

Managed CNAPP remplace-t-il votre équipe de sécurité interne ?

Non. Un fournisseur de CNAPP managé assure l’exploitation quotidienne de votre plateforme de protection des applications cloud-native, y compris la surveillance, le triage et l’acheminement des détections, tandis que votre organisation conserve l’autorité de gouvernance et reste responsable de l’exécution de la remédiation. Vous restez responsable de votre sécurité du cloud et de votre conformité réglementaire. 

Ce modèle ajoute de la capacité opérationnelle et une expertise cloud-native à une équipe réduite, tout en maintenant la responsabilité des résultats de sécurité au sein de votre organisation.