La sécurité des services cloud consiste à appliquer des contrôles adaptés aux données et applications hébergées chez des prestataires cloud (SaaS, PaaS, IaaS). L'ISO 27002 mesure 5.23 recommande cinq contrôles principaux :

• Classification et localisation des données : identifier quelles données peuvent aller dans le cloud, où elles sont stockées géographiquement, et qui y a accès
• Contrôles d'accès renforcés : authentification multi-facteurs obligatoire, gestion des identités fédérée, limitation des permissions selon le moindre privilège
• Chiffrement des données : chiffrement en transit (TLS) et au repos, avec gestion des clés de chiffrement maîtrisée
• Surveillance et audit : logs d'accès centralisés, détection d'anomalies, audit régulier des configurations et permissions
• Contractualisation claire : SLA définis, responsabilités partagées comprises, conformité réglementaire vérifiée (RGPD, souveraineté)

Ces contrôles visent à maintenir un niveau de sécurité équivalent au SI interne malgré l'externalisation.

SaaS (Software as a Service)

Applications clés en main accessibles via navigateur : messagerie : Microsoft 365, Google Workspace, collaboration** : Slack, Teams, Zoom, CRM : Salesforce, HubSpot, RH : Workday, BambooHR,  comptabilité : QuickBooks, Xero.

Responsabilité partagée : le fournisseur gère l'infrastructure, les serveurs, le réseau, l'application. L'organisation gère les accès utilisateurs, la configuration de sécurité de l'application, les données stockées.

Risques spécifiques : compromission de comptes utilisateurs (phishing), partages de documents mal configurés, applications connectées non contrôlées (OAuth), perte de données si fournisseur disparaît.

PaaS (Platform as a Service)

Plateformes de développement et déploiement d'applications : développement* : Heroku, Google App Engine, bases de données managées : Azure SQL Database, Amazon RDS, fonctions serverless : AWS Lambda, Azure Functions.

Responsabilité partagée : le fournisseur gère l'infrastructure, le système d'exploitation, la plateforme. L'organisation gère le code applicatif, les configurations, les données.

Risques spécifiques : vulnérabilités dans le code déployé, configurations insécurisées des bases de données, secrets API mal gérés, logs applicatifs insuffisants.

IaaS (Infrastructure as a Service)

Infrastructure virtualisée à la demande : serveurs virtuels : AWS EC2, Azure VMs, Google Compute Engine, stockage : AWS S3, Azure Blob Storage, réseaux virtuels : VPC, VNET.

Responsabilité partagée : le fournisseur gère l'infrastructure physique, la virtualisation, le réseau physique. L'organisation gère les systèmes d'exploitation, les applications, les données, les pare-feu, les sauvegardes.

Risques spécifiques : VMs non patchées, buckets de stockage publics par erreur, groupes de sécurité trop permissifs, snapshots non chiffrés.

Identifier ce qui va dans le cloud

Toutes les données ne sont pas adaptées au cloud public : OK pour le cloud public : données publiques ou internes non sensibles, collaboration externe nécessaire, applications non critiques, cloud privé ou hybride recommandé : données clients sensibles, propriété intellectuelle critique, données RH confidentielles, à éviter dans le cloud : données soumises à des contraintes réglementaires strictes (santé, défense), secrets industriels critiques.

Réaliser une classification préalable des données et définir une politique claire de ce qui peut migrer vers le cloud.

Souveraineté et localisation géographique

Vérifier où les données sont physiquement stockées : RGPD : les données personnelles de citoyens européens doivent rester dans l'UE ou dans des pays avec accord d'adéquation. Vérifier les datacenters utilisés par le fournisseur.

Cloud Act (US) : les fournisseurs américains (Microsoft, Google, AWS) peuvent être contraints de donner accès aux données aux autorités US, même si stockées en Europe. Évaluer le risque selon la sensibilité.

Souveraineté française : pour les données vraiment sensibles, privilégier des clouds souverains (OVHcloud, Scaleway, 3DS Outscale) ou des offres qualifiées SecNumCloud (ANSSI).

Inventaire des services cloud

Maintenir un inventaire complet de tous les services cloud utilisés : officiels : services approuvés et contractualisés par l'organisation, shadow IT : services utilisés par les équipes sans validation (Dropbox perso, WeTransfer, outils gratuits).

Le shadow IT représente un risque majeur : données professionnelles sur des services non maîtrisés, non audités, non sauvegardés.

Authentification multi-facteurs obligatoire

Tous les comptes cloud, sans exception, doivent avoir l'authentification multi-facteurs (MFA/2FA) activée : Microsoft 365 : Conditional Access + Azure MFA, Google Workspace : 2-Step Verification, AWS : MFA sur tous les comptes IAM, Azure : Azure AD MFA.

L'authentification par mot de passe seul est insuffisante pour le cloud. Un mot de passe volé par phishing donne un accès complet.

Identités fédérées (SSO)

Utiliser l'authentification fédérée (Single Sign-On) avec Azure AD, Okta, ou Google Identity : avantages : un seul point de contrôle des identités, désactivation centralisée à la cessation d'emploi, logs d'authentification centralisés, politique MFA unique.

Éviter les comptes locaux créés directement dans chaque service cloud. Tout doit passer par l'annuaire centralisé.

Principe du moindre privilège

Attribuer uniquement les permissions strictement nécessaires : rôles prédéfinis : utiliser les rôles intégrés (Lecteur, Contributeur, Propriétaire sur Azure ; IAM Roles sur AWS), permissions personnalisées : créer des rôles sur mesure si les rôles standards donnent trop de droits, revue trimestrielle : auditer régulièrement qui a accès à quoi, supprimer les accès obsolètes.

Limiter drastiquement les comptes administrateurs globaux (Global Admin Microsoft 365, Root AWS).

Accès conditionnel

Configurer des règles d'accès selon le contexte : géolocalisation : bloquer les connexions depuis des pays non autorisés, appareils gérés uniquement : autoriser l'accès uniquement depuis des appareils avec MDM, réseaux de confiance : exiger MFA renforcé depuis l'extérieur, relaxer depuis le bureau.

Exemples : Microsoft Conditional Access, AWS IAM Conditions, Google Context-Aware Access.

Chiffrement en transit (TLS)

Toutes les communications entre utilisateurs et services cloud doivent être chiffrées : HTTPS obligatoire : vérifier que tous les services utilisent TLS 1.2 minimum (idéalement TLS 1.3), APIs : toutes les connexions API doivent utiliser HTTPS, clients lourds : applications desktop/mobile doivent chiffrer leurs communications.

Désactiver les protocoles obsolètes (SSLv3, TLS 1.0, TLS 1.1) dans les configurations.

Chiffrement au repos

Les données stockées dans le cloud doivent être chiffrées : par défaut chez la plupart des fournisseurs : AWS S3 (SSE-S3, SSE-KMS), Azure Storage (encryption at rest), Google Cloud Storage (encryption at rest).

Vérifier que le chiffrement est activé. Même s'il est par défaut, confirmer explicitement.

Gestion des clés de chiffrement

Deux approches possibles : clés gérées par le fournisseur : simplicité, le fournisseur gère tout, mais le fournisseur peut techniquement accéder aux données, clés gérées par le client (BYOK) : l'organisation conserve le contrôle des clés de chiffrement dans un HSM dédié (Azure Key Vault, AWS KMS avec Customer Managed Keys).

Pour les données très sensibles, privilégier BYOK : si le fournisseur est compromis ou contraint légalement, il ne peut pas déchiffrer sans les clés du client.

DLP cloud (Data Loss Prevention)

Déployer des solutions DLP pour surveiller et bloquer les fuites de données dans le cloud : Microsoft 365 DLP : bloquer le partage externe de documents contenant des données sensibles (numéros CB, données RH), Google Workspace DLP : empêcher l'envoi d'emails avec pièces jointes sensibles à l'extérieur, CASB (Cloud Access Security Broker) : solutions tierces (Netskope, Zscaler, McAfee MVISION) qui analysent tout le trafic cloud.

Logs d'accès centralisés

Activer et centraliser tous les logs cloud : Microsoft 365 : Unified Audit Log, Azure AD Sign-in Logs, AWS : CloudTrail (tous les appels API), CloudWatch Logs, Google Workspace : Admin Audit Logs, Drive Activity Logs, Azure : Activity Log, Resource Logs.

Conserver ces logs suffisamment longtemps (minimum 90 jours, recommandé 1 an) et les exporter vers un SIEM pour analyse.

Détection d'anomalies

Utiliser les capacités de détection intégrées ou des solutions tierces : Microsoft Defender for Cloud Apps : détecte les connexions impossibles (deux localisations simultanées), accès inhabituels, téléchargements massifs, AWS GuardDuty : détection de menaces (compromissions d'instances, comportements anormaux), Google Workspace Alerts : alertes sur partages suspects, modifications de règles de sécurité.

Configurer des alertes pour événements critiques : création compte administrateur, désactivation MFA, modification permissions critiques, connexion depuis pays non autorisé.

Audits de configuration

Auditer régulièrement les configurations de sécurité : Microsoft Secure Score : score de sécurité avec recommandations d'amélioration, AWS Security Hub : agrège les findings de GuardDuty, Config, Inspector, Azure Security Center : recommandations de durcissement, Google Security Command Center : visibilité sur les risques.

Corriger les configurations faibles identifiées (buckets publics, groupes de sécurité trop ouverts, MFA non activé).

Contrôle des partages externes

Les fonctionnalités de partage sont pratiques mais risquées : SharePoint/OneDrive : limiter les partages externes aux domaines approuvés, expiration automatique des liens de partage, Google Drive : restreindre le partage externe, empêcher le téléchargement pour liens "Consulter uniquement", Dropbox Business : désactiver les liens publics, limiter aux collaborateurs invités nominativement.

Interdire les liens "Tout le monde avec le lien peut consulter" pour les documents sensibles.

Applications tierces connectées (OAuth)

Surveiller les applications tierces autorisées à accéder aux comptes : Microsoft 365 : auditer les consentements d'applications (Azure AD > Enterprise Apps), révoquer les apps suspectes ou non utilisées, Google Workspace : auditer les apps connectées, limiter les scopes autorisés, AWS/Azure : surveiller les service principals et leurs permissions.

Former les utilisateurs à ne pas cliquer sur "Autoriser" sans vérifier quelle app demande quels accès.

Classification des documents

Utiliser les étiquettes de sensibilité : Microsoft Information Protection : étiqueter automatiquement les documents sensibles (Confidentiel, Secret), appliquer des protections automatiques (chiffrement, watermark, interdiction de partage externe), Google Drive : classification manuelle avec Drive Labels (moins avancé).

Responsabilités partagées

Comprendre et documenter le modèle de responsabilité partagée : fournisseur cloud responsable de : infrastructure physique, réseau, virtualisation, disponibilité de la plateforme, organisation responsable de : identités et accès, données stockées, applications déployées, configurations de sécurité, conformité réglementaire.

Beaucoup d'incidents viennent d'une incompréhension : "je pensais que AWS sécurisait mes buckets" (non, c'est votre responsabilité).

SLA et disponibilité

Vérifier les engagements de disponibilité : SaaS : généralement 99.9% (8h46 d'indisponibilité/an), IaaS/PaaS : 99.95% à 99.99% selon services et régions, pénalités : crédits de service si SLA non respecté (rarement compensation financière).

Pour les services critiques, architecturer en multi-région pour garantir la disponibilité même si une région tombe.

Conformité et certifications

Exiger et vérifier les certifications du fournisseur : ISO 27001 : certification du SMSI du fournisseur, SOC 2 Type II : audit indépendant des contrôles de sécurité, RGPD : conformité aux exigences européennes, certifications nationales : SecNumCloud (France), C5 (Allemagne), FedRAMP (US gouvernemental).

Demander les rapports de certification récents (< 12 mois) et vérifier qu'ils couvrent les services utilisés.

• Pas de MFA : laisser des comptes cloud sans authentification multi-facteurs est l'erreur la plus dangereuse. Compromission par phishing = accès total. MFA obligatoire sans exception.
• Buckets/partages publics : de nombreuses fuites de données viennent de buckets S3 ou dossiers SharePoint accidentellement publics. Auditer régulièrement les permissions.
• Shadow IT non contrôlé : ignorer les services cloud utilisés sans autorisation crée des angles morts. Détecter et encadrer le shadow IT.
• Comptes admin trop nombreux : multiplier les comptes administrateurs globaux augmente la surface d'attaque. Limiter au strict minimum avec MFA renforcé.

La sécurité des services cloud repose sur une compréhension claire du modèle de responsabilité partagée (le fournisseur sécurise l'infrastructure, l'organisation sécurise les données et accès). L'authentification multi-facteurs obligatoire sur tous les comptes, combinée au Single Sign-On fédéré et à l'accès conditionnel selon contexte, protège contre les compromissions de comptes.

Le chiffrement en transit (TLS 1.2+) et au repos (activé par défaut, BYOK pour données sensibles) garantit la confidentialité. La surveillance continue via logs centralisés, détection d'anomalies (Defender for Cloud Apps, GuardDuty), et audits réguliers de configuration (Secure Score, Security Hub) permet d'identifier rapidement les incidents et dérives. Le contrôle strict des partages externes, la révocation des applications OAuth suspectes, et la classification des données sensibles limitent les fuites. La contractualisation claire avec vérification des certifications (ISO 27001, SOC 2, RGPD) et compréhension des SLA complète le dispositif.