Politique Services Cloud ISO 27001 : Word [A.5.23]

La politique des services cloud ISO 27001 formalise les exigences de sécurité applicables aux services cloud (SaaS, IaaS, PaaS, FaaS) dans le cadre du contrôle A.5.23 — Sécurité de l'information pour l'utilisation des services en nuage de l'Annexe A ISO/IEC 27001:2022. Ce contrôle, nouveau dans la version 2022, reconnaît explicitement le rôle prépondérant du cloud dans les infrastructures modernes et impose que les exigences de sécurité de l'information relatives à l'acquisition, à l'utilisation, à la gestion et à la sortie des services cloud soient définies selon l'approche de l'organisation en matière de gestion des risques. Le cloud a fondamentalement transformé le modèle de responsabilité en sécurité : dans un modèle de responsabilité partagée, le fournisseur cloud sécurise l'infrastructure sous-jacente, mais la sécurisation des données, des accès, des configurations et des applications reste la responsabilité du client. Des failles de configuration cloud — buckets S3 publics, permissions IAM trop larges, journalisation désactivée — sont à l'origine de la majorité des incidents de fuite de données liés au cloud. Ce template Word, développé par Ayi NEDJIMI, consultant cybersécurité Lead Implementer ISO 27001, couvre le processus de qualification des prestataires cloud (critères de sélection, certifications attendues comme SecNumCloud, ISO 27017, ISO 27018, SOC 2 Type II), les clauses contractuelles de sécurité à inclure dans les accords cloud (DPA RGPD, droits d'audit, notifications d'incidents, engagement de confidentialité, portabilité des données), les contrôles de sécurité à configurer dans chaque environnement cloud (IAM, logging, chiffrement, configuration baseline), et le processus de sortie sécurisée d'un prestataire cloud (migration des données, révocation des accès, destruction certifiée des données). Il s'adresse aux RSSI qui définissent la stratégie cloud sécurisée de l'organisation, aux équipes DevOps et infrastructure qui déploient et opèrent les services cloud, aux responsables achats qui négocient les contrats avec les fournisseurs cloud, et aux auditeurs internes qui vérifient la conformité des déploiements cloud. La politique cloud est indissociable de la politique de sécurité réseau (A.8.20) pour les connexions cloud, du registre des exigences légales (A.5.31) pour les obligations RGPD liées au cloud, et de la politique de logging (A.8.15) pour la collecte des logs cloud.

Contexte réglementaire et normatif

Le contrôle A.5.23 d'ISO/IEC 27001:2022 est entièrement nouveau — il n'existait pas dans la version 2013. Son introduction reflète la transformation numérique des organisations et le rôle central du cloud dans les architectures modernes. Il impose que des processus formels couvrent l'ensemble du cycle de vie des services cloud : sélection, contrat, mise en œuvre, exploitation, surveillance et exit.

• ISO/IEC 27017:2015 (Sécurité cloud) : guide de contrôles de sécurité spécifiques au cloud, complétant ISO 27001. Les fournisseurs cloud certifiés ISO 27017 démontrent des contrôles de sécurité adaptés à leur modèle de service.
• ISO/IEC 27018:2019 (Protection données personnelles dans le cloud) : code de bonne pratique pour la protection des données à caractère personnel dans le cloud public, aligné avec le RGPD.
• SecNumCloud (ANSSI) : qualification française pour les prestataires cloud offrant le plus haut niveau de sécurité et de confiance pour les données sensibles de l'État et des organisations critiques.
• RGPD (Chapitre V) : les transferts de données personnelles vers des prestataires cloud hors UE nécessitent des garanties appropriées (clauses contractuelles types, codes de conduite approuvés par la Commission européenne).
• DORA (Règlement UE 2022/2554) : pour les entités financières, impose des exigences spécifiques sur la gestion des risques liés aux prestataires ICT tiers, dont les fournisseurs cloud.

Structure détaillée du template

Section 1 — Politique générale d'utilisation du cloud

Définition de la stratégie cloud de l'organisation : cloud public autorisé uniquement pour les données non sensibles ou avec mesures de protection renforcées, cloud privé ou hybride pour les données sensibles, liste des prestataires cloud approuvés (whitelist), processus de demande d'autorisation pour un nouveau service cloud (shadow IT interdit), classification des données autorisées dans le cloud par niveau de sensibilité. Principe fondamental : aucun service cloud ne peut être déployé en production sans validation préalable par le RSSI.

Section 2 — Critères de qualification des prestataires cloud

Grille d'évaluation des prestataires cloud : certifications de sécurité requises (ISO 27001 obligatoire, ISO 27017/27018 fortement recommandé, SOC 2 Type II ou SecNumCloud selon le niveau de sensibilité des données), localisation des centres de données (UE obligatoire pour les données personnelles, France pour les données souveraines), mécanismes de chiffrement au repos et en transit, capacités de journalisation et d'audit, procédure de notification d'incidents (délai, canal, granularité), politiques de sauvegarde et de disponibilité (SLA), conditions de portabilité des données (export, formats ouverts), procédure de destruction sécurisée des données à la fin du contrat.

Section 3 — Contrôles de sécurité par type de service cloud

Exigences spécifiques pour chaque modèle de service : SaaS — gestion des identités (SSO, MFA obligatoire), configuration des droits d'accès, vérification des paramètres de confidentialité, activation de la journalisation, revue périodique des utilisateurs actifs ; IaaS/PaaS — hardening des instances (CIS Benchmarks), gestion des clés de chiffrement (KMS client), configuration du réseau virtuel (VPC, security groups), scan de vulnérabilités, audit des configurations IAM, CloudTrail/CloudWatch activés ; Cloud hybride — gestion des identités fédérée (Azure AD Connect, etc.), chiffrement des données en transit entre on-premises et cloud.

Section 4 — Gestion des accès cloud

Exigences IAM (Identity and Access Management) pour le cloud : comptes IAM individuels (pas de partage), MFA obligatoire pour tous les accès cloud (particulièrement les comptes root/admin), principe du moindre privilège appliqué aux rôles IAM, rotation régulière des clés d'accès (access keys), audit trimestriel des permissions IAM, suppression immédiate des accès lors des offboarding, service accounts avec permissions minimales et sans rotation longue durée. Interdiction absolue de stocker les credentials cloud dans le code source (utiliser des gestionnaires de secrets).

Section 5 — Surveillance et conformité cloud continue

Outils et processus de surveillance continue des environnements cloud : CSPM (Cloud Security Posture Management) pour détecter les mauvaises configurations, audit régulier des permissions et ressources exposées, contrôle des coûts cloud comme indicateur d'activité anormale (cryptomining), revue mensuelle des alertes de sécurité cloud natifs (AWS Security Hub, Azure Security Center, GCP Security Command Center), intégration des logs cloud dans le SIEM.

Guide d'utilisation étape par étape

Étape 1 — Inventaire du shadow IT cloud

Avant de déployer la politique, réalisez un inventaire des services cloud déjà utilisés dans l'organisation, y compris le shadow IT (services cloud non validés par l'IT). Des outils comme un CASB (Cloud Access Security Broker) ou l'analyse des logs proxy/DNS peuvent révéler l'usage de dizaines de services cloud non référencés. Cet inventaire est souvent une découverte surprenante pour les organisations qui pensaient avoir une utilisation cloud limitée.

Étape 2 — Classifier les services existants

Pour chaque service cloud identifié : évaluez les données qu'il traite et leur niveau de sensibilité, vérifiez les certifications de sécurité du prestataire, évaluez le niveau de configuration de sécurité actuel, décidez d'autoriser formellement, de renforcer la sécurité, ou d'interdire et migrer. Cette classification produit une liste de services cloud approuvés (whitelist) et une liste de services à éliminer.

Étape 3 — Négocier les contrats cloud

Pour tout nouveau service cloud ou renouvellement de contrat, négociez les clauses de sécurité requises : DPA RGPD pour tous les services traitant des données personnelles, clauses de notification d'incident (délai de 24 à 72 heures), droits d'audit (inspection ou certification tierce annuelle), engagement de localisation des données (UE), conditions de portabilité et de destruction certifiée à la fin du contrat. Beaucoup de fournisseurs SaaS grand public ont des DPA standard que vous pouvez accepter si vos données ne sont pas très sensibles.

Étape 4 — Configurer les contrôles de sécurité cloud

Pour chaque service cloud approuvé, configurez les contrôles de sécurité requis : activation du MFA, configuration du SSO si disponible, activation de la journalisation des actions (audit logs), chiffrement des données au repos et en transit, configuration des accès selon le principe du moindre privilège, désactivation des fonctionnalités non utilisées. Documentez la baseline de configuration sécurisée pour chaque service cloud.

Étape 5 — Déployer la surveillance CSPM

Déployez un outil de surveillance de la posture de sécurité cloud (CSPM) pour détecter les mauvaises configurations en continu. Les solutions disponibles incluent les outils natifs (AWS Config, Azure Policy, GCP Security Command Center), des solutions open-source (Prowler, ScoutSuite) et des solutions commerciales (Wiz, Prisma Cloud). Configurez des alertes sur les dérives de configuration critiques (bucket S3 public, security group 0.0.0.0/0 ouvert, journalisation désactivée).

Étape 6 — Intégrer les logs cloud dans le SIEM

Configurez l'export des logs cloud vers votre SIEM : AWS CloudTrail, Azure Activity Log, GCP Audit Log. Définissez des use cases de détection spécifiques au cloud : connexion depuis une IP non habituelle, accès root account (AWS), création d'un compte admin inattendu, modification des politiques IAM, accès massif à des données (exfiltration potentielle).

Étape 7 — Planifier la gestion de sortie

Anticipez la fin de la relation avec chaque prestataire cloud (exit strategy) : procédure d'export des données dans un format portable, délai de migration, suppression et destruction certifiée des données chez le prestataire, révocation de tous les accès. L'absence d'exit strategy peut créer une dépendance (vendor lock-in) qui est elle-même un risque ISO 27001 à documenter dans le registre des risques.

Étape 8 — Audit annuel des services cloud

Réalisez un audit annuel de tous les services cloud : état des certifications des prestataires (vérifiez que les certifications sont toujours valides), revue des configurations de sécurité (drift depuis la baseline), revue des droits d'accès utilisateurs (User Access Review), revue des DPA et clauses contractuelles (toujours conformes RGPD ?), mise à jour de la whitelist des services approuvés.

Tableau des contrôles / checklist complète

Points de vigilance pour l'audit de certification

Piège 1 — Shadow IT cloud non cartographié

La plupart des organisations utilisent bien plus de services cloud qu'elles ne le pensent — les études estiment entre 50 et 200 services cloud non référencés par les DSI dans les grandes entreprises. Un auditeur qui découvre des services cloud non documentés dans votre politique remet en cause la maîtrise de votre périmètre. Remédiation : analysez les logs du proxy Web ou déployez un CASB pour identifier tous les services cloud utilisés avant l'audit.

Piège 2 — Absence de DPA avec les prestataires SaaS

Tout prestataire SaaS qui traite des données personnelles pour votre compte est un sous-traitant au sens du RGPD, et un DPA doit être signé. L'absence de DPA pour des services comme Microsoft 365, Salesforce, ou tout autre SaaS traitant des emails ou des données clients est une non-conformité RGPD pouvant être signalée à la CNIL. Remédiation : vérifiez le statut DPA de tous vos prestataires SaaS et signez les DPA disponibles sur leurs portails de conformité.

Piège 3 — Comptes root/admin cloud sans MFA

Les comptes administrateurs cloud (compte root AWS, Global Admin Azure) sans MFA sont l'une des vulnérabilités cloud les plus critiques. Un compte admin cloud compromis donne accès à l'intégralité de vos ressources cloud. Remédiation : activez le MFA sur tous les comptes admin cloud sans exception, et idéalement stockez les credentials root dans un coffre-fort et ne les utilisez qu'exceptionnellement.

Piège 4 — Bucket S3 / Azure Blob / GCS publiquement accessible

Les erreurs de configuration de buckets publics sont à l'origine de nombreuses fuites de données majeures. Un CSPM détecte ce type de configuration en quelques minutes. Remédiation : configurez des alertes sur toute création de storage public, bloquez la création de resources publiques par policy au niveau de l'organisation cloud, et scannez régulièrement les configurations existantes.

Intégration dans le SMSI

• Registre des exigences légales (A.5.31) : les obligations RGPD liées au cloud (DPA, localisation) s'intègrent dans le registre légal.
• Politique réseau (A.8.20) : les connexions cloud sont documentées dans la politique réseau (flux autorisés).
• Politique Logging (A.8.15) : les logs cloud s'intègrent dans le SIEM central.
• Procédure JML : l'offboarding cloud (révocation accès SaaS) fait partie de la checklist de départ.

Bonnes pratiques terrain

Adoptez une approche "Cloud-First Security" : intégrez les exigences de sécurité cloud dès la phase de sélection d'un nouveau service, pas après déploiement. Créez un questionnaire de qualification sécurité cloud que vos équipes métier complètent avant toute décision d'achat d'un nouveau SaaS.

Utilisez les outils de sécurité natifs des hyperscalers : AWS Security Hub, Azure Security Center et GCP Security Command Center offrent des fonctionnalités de surveillance de la posture cloud très puissantes, souvent incluses dans vos abonnements cloud ou à faible coût supplémentaire. Ne les ignorez pas au profit de solutions tierces plus coûteuses.

FAQ

Comment gérer la sécurité des services Microsoft 365 dans le cadre d'ISO 27001 ?

Microsoft 365 (Exchange Online, SharePoint, Teams, OneDrive) est probablement le service cloud le plus utilisé dans les organisations françaises, et sa sécurisation est un point d'attention majeur en audit ISO 27001. Les actions prioritaires : activer le MFA sur tous les comptes Microsoft 365 (Microsoft Authenticator recommandé), configurer les politiques d'accès conditionnel (accès depuis des appareils conformes uniquement, blocage des pays non utilisés), activer Microsoft Defender for Office 365 pour la protection messagerie (anti-phishing, sandbox pièces jointes), activer l'audit unifié (Unified Audit Log) sur votre tenant et collecter les logs dans votre SIEM, configurer les politiques de prévention des fuites de données (DLP) dans le Centre de conformité Microsoft 365, signer le DPA Microsoft (disponible dans le Centre d'administration Microsoft 365), vérifier la localisation des données (demandez à Microsoft la confirmation de localisation de vos données dans l'UE). Microsoft 365 est certifié ISO 27001, 27017, 27018 et SOC 2 Type II — téléchargez les rapports d'audit depuis le Service Trust Portal Microsoft pour les présenter en audit ISO 27001.

La politique de services cloud ISO 27001 Annexe A.5.23 répond à une réalité incontournable des SI modernes : la majorité des organisations utilisent désormais de multiples services cloud (SaaS, IaaS, PaaS) de différents fournisseurs, créant une complexité de gouvernance qui nécessite un cadre politique structuré. Cette politique doit définir le processus d'évaluation et d'approbation de nouveaux services cloud, les critères de classification des données pouvant être hébergées dans le cloud et les exigences minimales de sécurité que doivent respecter les fournisseurs cloud retenus.

L'évaluation des fournisseurs cloud dans le cadre ISO 27001 doit couvrir plusieurs dimensions : la localisation des données et leur conformité au RGPD (transferts hors UE), les certifications de sécurité du fournisseur (ISO 27001, SOC 2 Type II, CSA STAR), les conditions contractuelles de traitement des données (DPA), les mécanismes de chiffrement des données au repos et en transit, et les engagements de continuité de service (SLA) avec des procédures de sortie (exit strategy) documentées pour éviter tout effet de lock-in.

La gestion des configurations cloud sécurisées (Cloud Security Posture Management - CSPM) constitue un complément opérationnel essentiel à la politique A.5.23 : des outils comme Microsoft Defender for Cloud, AWS Security Hub ou Wiz permettent d'auditer en continu la conformité des configurations cloud aux benchmarks CIS et aux politiques internes, d'identifier les ressources non conformes et de générer des rapports de conformité exploitables pour les auditeurs ISO 27001. Cette surveillance continue transforme la politique cloud d'un document statique en un dispositif de contrôle dynamique et mesurable.