Chapitre 1211 minIntermédiaire
Le modèle de responsabilité partagée
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- répartir les responsabilités entre client et fournisseur selon le modèle ;
- citer ce qui reste toujours à la charge du client ;
- reconnaître les incidents de sécurité cloud les plus fréquents et leurs parades.
3 exercices corrigés1 schéma
Le modèle de responsabilité partagée répartit la sécurité d'un service cloud entre le fournisseur et le client : le fournisseur protège l'infrastructure qui porte le service (centres de données, serveurs, réseau physique, hyperviseur), le client protège ce qu'il y met et ce qu'il configure (données, identités, droits, applications). La frontière se déplace selon le modèle de service : en IaaS, le client garde presque tout ; en SaaS, il garde au moins ses données, ses comptes et ses réglages. Ce chapitre présente la matrice de Microsoft, ce qui reste toujours au client, les incidents cloud les plus fréquents et les outils pour les éviter.
La matrice de responsabilité
Microsoft publie la répartition suivante pour Azure ; AWS et Google Cloud décrivent la même idée, avec leurs propres mots.
| Domaine | Sur site | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Données du client | Client | Client | Client | Client |
| Configurations et paramètres | Client | Client | Client | Client |
| Identités et utilisateurs | Client | Client | Client | Client |
| Terminaux des utilisateurs | Client | Client | Client | Partagé |
| Applications | Client | Client | Partagé | Partagé |
| Contrôles réseau | Client | Client | Partagé | Fournisseur |
| Système d'exploitation | Client | Client | Fournisseur | Fournisseur |
| Hôtes physiques | Client | Fournisseur | Fournisseur | Fournisseur |
| Réseau physique | Client | Fournisseur | Fournisseur | Fournisseur |
| Centre de données | Client | Fournisseur | Fournisseur | Fournisseur |
Lire les cases « partagé ». En PaaS, Microsoft maintient l'environnement d'exécution, mais la sécurité du code, sa configuration et ses accès restent au client ; Microsoft fournit une protection réseau de base, mais le client choisit qui peut joindre son application (restrictions d'accès, intégration à un réseau virtuel). En SaaS, Microsoft fournit des outils de gestion des appareils, mais la protection des postes reste au client.
Ce qui reste toujours au client
Quel que soit le modèle, Microsoft rappelle que le client garde quatre responsabilités :
- les données : leur classification, leur protection, les choix de chiffrement, le respect des règles de conservation ;
- les terminaux qui accèdent au service : postes, téléphones, tablettes ;
- les comptes : leur création, leur suivi, leur suppression au départ d'un salarié ;
- la gestion des accès : rôles RBAC, MFA, accès conditionnel.
C'est le principe à retenir pour l'écrit : le fournisseur sécurise le cloud, le client sécurise ce qu'il fait dans le cloud. Un abonnement mal configuré reste une faute du client, même chez le fournisseur le mieux protégé. La même logique s'applique en droit : Sorbier reste responsable de traitement de ses données, Microsoft n'est que son sous-traitant (chapitre 4).
Les incidents cloud les plus fréquents
La plupart des incidents de sécurité dans le cloud ne viennent pas d'une faille du fournisseur, mais d'une erreur de configuration ou d'un compte compromis chez le client.
| Incident | Comment il arrive | Comment on le détecte | La parade |
|---|---|---|---|
| Stockage exposé | Un conteneur de blobs ou un compartiment S3 laissé en accès public | Recommandations de Defender for Cloud, audit des comptes de stockage | Accès public désactivé, imposé par une stratégie Azure Policy |
| Secret divulgué | Une clé d'accès ou un mot de passe versionné dans un dépôt Git | Analyse des secrets du dépôt, alerte d'usage anormal | Identités managées, Key Vault, rotation des clés (chapitre 11) |
| Port d'administration exposé | SSH ou RDP ouvert à tout Internet, mot de passe faible | Journaux de connexion de la VM, recommandations de Defender for Cloud | Règles NSG limitées à une source, bastion, VPN (chapitre 7) |
| Compte d'administration compromis | Hameçonnage d'un administrateur sans MFA résistante | Journaux de connexion Entra ID, connexions depuis un pays inhabituel | MFA résistante à l'hameçonnage, accès conditionnel, comptes d'administration dédiés |
| Droits excessifs | Tout le monde Owner « pour aller plus vite » | Revue des attributions de rôles | Moindre privilège, PIM, revues d'accès régulières |
| Système non mis à jour (IaaS) | Une VM oubliée, jamais patchée | Évaluation des mises à jour, scanner de vulnérabilités | Mises à jour automatiques, Azure Update Manager |
| Ressources détournées | Un compte volé sert à créer des VM puissantes pour miner de la cryptomonnaie | Alerte de budget ou d'anomalie de coût, ressources inconnues dans une région inhabituelle | MFA, stratégie de régions autorisées, budgets et alertes, quotas |
Les outils de sécurité d'Azure
| Outil | Rôle |
|---|---|
| Microsoft Defender for Cloud | Évalue la configuration (score de sécurité et recommandations, gratuits) et, avec des plans payants, protège les charges de travail (VM, bases, stockage) en détectant les menaces |
| Azure Policy | Impose des règles à la création des ressources : régions autorisées, accès public interdit, étiquettes obligatoires, chiffrement |
| Journal d'activité (Activity Log) | Qui a créé, modifié ou supprimé quoi, et quand, dans l'abonnement |
| Journaux de connexion d'Entra ID | Qui s'est connecté, d'où, avec quelle méthode d'authentification |
| Azure Monitor | Métriques, journaux et alertes de toutes les ressources |
| Microsoft Sentinel | Le SIEM cloud de Microsoft ; chez Sorbier, c'est Wazuh qui centralise, et il sait collecter les journaux d'Azure et d'Entra ID |
À l'écrit : comment traiter une question de responsabilité
- Identifie le modèle de service (IaaS, PaaS, SaaS) de chaque élément cité dans l'énoncé.
- Répartis les tâches de sécurité avec la matrice : ce que fait le fournisseur, ce que fait l'organisation.
- Cite le contrat : l'engagement de niveau de service (SLA) pour la disponibilité (cours Droit et RGPD), le contrat de sous-traitance (article 28 du RGPD) pour les données personnelles.
- Propose des mesures concrètes pour la part du client : MFA, droits minimaux, sauvegardes, chiffrement, journalisation.
La méthode de rédaction complète est dans les cours Épreuve E7 SISR et Épreuve E7 SLAM.
Exercices
Exercice 1 sur 3 Qui est responsable ? Réussi À revoir
On suppose que Sorbier a adopté Microsoft 365 pour sa messagerie, comme elle l'envisage. Pour chaque tâche, dis qui en est responsable : Sorbier, le fournisseur, ou les deux.
- Remplacer un disque défaillant dans un serveur du centre de données de Paris.
- Appliquer les mises à jour du noyau Linux d'une VM Azure.
- Appliquer les mises à jour de l'environnement Node.js d'une application App Service.
- Corriger une faille d'injection SQL dans le code de l'API déployée sur App Service.
- Désactiver le compte Microsoft 365 d'un salarié qui quitte l'entreprise.
- Garantir la disponibilité de la messagerie Microsoft 365.
- Sauvegarder les courriels de la direction contre une suppression par erreur.
- Limiter les adresses autorisées à joindre l'application App Service.
Voir la réponseMasquer la réponse de l'exercice 1
- Le fournisseur : le matériel du centre de données.
- Sorbier : en IaaS, le système d'exploitation est au client.
- Le fournisseur : en PaaS, l'environnement d'exécution est géré par Microsoft.
- Sorbier : le code de l'application est toujours au client.
- Sorbier : les comptes et identités restent au client, même en SaaS.
- Le fournisseur, dans la limite de son engagement de niveau de service (SLA).
- Sorbier : les données restent au client ; Microsoft 365 garde des éléments supprimés pendant une durée limitée, mais une vraie sauvegarde, hors du fournisseur, est à la charge de Sorbier (cours Sauvegarde et PRA).
- Les deux (contrôles réseau partagés en PaaS) : Microsoft fournit la protection de base et l'outil de restriction d'accès, Sorbier choisit et configure les règles.
Tu avais trouvé ?
Exercice 2 sur 3 Les bons de livraison dans un moteur de recherche Réussi À revoir
Un client de Sorbier signale qu'en tapant son nom dans un moteur de recherche, il tombe sur son bon de livraison signé, hébergé à une adresse en blob.core.windows.net. Qui est responsable ? Quelle est la cause probable ? Que faut-il faire, dans l'ordre ?
Voir la réponseMasquer la réponse de l'exercice 2
Responsable : Sorbier. Le stockage est un service PaaS, mais la configuration des accès appartient toujours au client.
Cause probable : le conteneur bons-livraison est en accès public anonyme, et un lien vers un blob a circulé (dans un courriel, une page web) puis été indexé.
Dans l'ordre :
- Contenir : désactiver l'accès public du compte de stockage, tout de suite.
- Évaluer : lire les journaux d'accès du stockage pour savoir quels blobs ont été lus anonymement et depuis quand ; demander la suppression des résultats au moteur de recherche.
- Notifier : c'est une violation de données personnelles (noms, adresses, signatures). Sorbier la notifie à la CNIL dans les 72 heures si elle présente un risque pour les personnes, et informe les personnes concernées si le risque est élevé (cours Droit et RGPD).
- Corriger durablement : une stratégie Azure Policy qui interdit l'accès public à tous les comptes de stockage, des liens de partage temporaires (SAS) pour transmettre un document à un client.
Tu avais trouvé ?
Exercice 3 sur 3 La facture qui explose Réussi À revoir
Le 3 du mois, l'alerte de budget de Sorbier (500 € par mois) se déclenche à 100 %. On découvre douze VM à processeurs graphiques créées pendant la nuit dans une région d'Amérique du Sud, par le compte d'un administrateur. Ce compte n'avait pas de MFA résistante à l'hameçonnage, et l'administrateur avait saisi son mot de passe sur une fausse page de connexion la veille.
- Qui est responsable de l'incident ?
- Quelles sont les premières actions ?
- Quelles mesures auraient empêché ou limité l'incident ?
Voir la réponseMasquer la réponse de l'exercice 3
- Sorbier : le compte et ses droits relèvent du client. Le fournisseur n'a commis aucune faute ; la facture est due, même si les fournisseurs acceptent parfois un geste commercial après un incident documenté.
- Bloquer le compte et révoquer ses sessions, supprimer les VM créées, vérifier le journal d'activité pour lister tout ce que le compte a créé ou modifié (autres ressources, nouvelles attributions de rôles, nouveaux comptes), réinitialiser ses moyens d'authentification, déclarer l'incident en interne (cours Réponse à incident).
- Une MFA résistante à l'hameçonnage (clé FIDO2, clé d'accès) pour les administrateurs ; un compte d'administration distinct du compte de messagerie ; des droits élevés activés seulement au besoin (PIM) ; une stratégie de régions autorisées (France Central, et sa région de secours) qui aurait refusé la création ; des alertes de budget à 50 % et 80 % et une alerte d'anomalie de coût, qui auraient prévenu plus tôt ; des quotas bas sur les tailles de VM coûteuses.
Tu avais trouvé ?