Services cloud sous ISO 27001 : critères de sélection et contrôles pour l'intégration dans le SMSI

Beaucoup d’entreprises se retrouvent aujourd’hui dans la même tension : les services cloud promettent rapidité et montée en charge, tandis que l’ISMS exige traçabilité, exploitation contrôlée et responsabilités clairement définies. C’est précisément là que le thème central Services cloud sous ISO 27001 devient pertinent sur le plan pratique. Non pas parce que la norme complique le « cloud » par principe, mais parce qu’elle exige de vous d’identifier systématiquement les risques, d’appliquer efficacement les contrôles et de documenter le tout de manière exploitable en audit. Ça ressemble à du papier — mais dans le cloud cela se transforme vite en questions opérationnelles concrètes : qui peut faire quoi ? Où sont les données ? Comment sont consignés les logs ? Comment réagissons‑nous aux incidents ? Et comment sort‑on, si nécessaire ?

Cet article fournit une logique de sélection et d’intégration robuste : critères de décision pour l’acquisition, contrôles concrets pour l’intégration dans l’ISMS, perspectives d’audit typiques et indications de mise en œuvre du point de vue opérationnel. L’accent est mis sur IaaS/PaaS/SaaS, c’est‑à‑dire les services d’infrastructure, de plateforme et d’application depuis le cloud — chacun ayant des conséquences pour la gouvernance, l’administration et la sécurité.

Services cloud sous ISO 27001 en pratique

Dans les audits et revues internes, des schémas récurrents apparaissent, qui ne tiennent pas aux configurations isolées mais à des interfaces floues entre le fournisseur et le client :

• Responsabilités floues : Le Shared Responsibility Model (responsabilité partagée entre fournisseur et client) n’est pas traduit au quotidien en tâches, rôles et preuves.
• Portée trop vague : « Nous utilisons le cloud » ne remplace pas une délimitation du périmètre. Sans cartographie des services, flux de données et dépendances, l’analyse des risques est aléatoire.
• Choix du fournisseur sans annexe sécurité : les achats et le métier priorisent les fonctionnalités, l’IT/la sécurité interviennent trop tard. Résultat : SLA sans indicateurs de sécurité, absence de droits d’audit, sous‑traitants non clarifiés.
• Conception du logging absente : des logs existent, mais pas centralisés, pas corrélés, pas de règles de conservation, pas de responsabilité définie. Lors d’un incident, « rien n’est prouvable ».
• Pas de plan de sortie : dans le cloud, le lock‑in n’est rarement « juste une question de prix ». Il s’agit de formats de données, de couplages IAM, de services propriétaires et de l’absence de trajectoires de migration.

ISO 27001 n’impose pas un contrôle maximal, mais un contrôle approprié et justifié. L’étape décisive est donc de considérer les services cloud comme une relation fournisseur plus une plateforme opérationnelle critique — avec des contrôles techniques vérifiables.

Positionnement : ISO 27001, Annexe A et ce que le « cloud » y change

ISO 27001 exige un système de gestion de la sécurité de l’information (ISMS) fondé sur une approche basée sur les risques, une efficacité mesurable et une amélioration continue. L’Annexe A (objectifs de contrôle/contrôles, restructurée dans ISO/IEC 27001:2022) est un outillage, pas un catalogue d’obligations « tout le temps ». Dans le cloud, la mise en œuvre évolue :

• Les contrôles deviennent davantage contractuels et procéduraux (par ex. gestion des fournisseurs, preuves d’audit, transparence des sous‑traitants).
• Les contrôles deviennent plus orientés configuration (par ex. IAM, chiffrement, segmentation réseau), car vous contrôlez moins de composants « physiques ».
• Les preuves s’appuient davantage sur les données (par ex. extraits de logs, exports de configuration, enregistrements de changements), car les checklists serveur classiques ne conviennent plus.

Pour la pratique, il est utile de classer selon le modèle de service : pour SaaS vous contrôlez principalement les identités, les autorisations, les données, les intégrations et la gestion des fournisseurs. Pour PaaS s’ajoutent les paramètres de la plateforme, les contrôles réseau et d’exécution. Pour IaaS vous assumez nettement plus de responsabilités pour les systèmes d’exploitation, le hardening, l’application des correctifs et l’architecture réseau.

Critères de sélection : comment évaluer les services cloud avant achat

Du point de vue ISMS, la phase de sélection est le moment le plus propice pour intégrer la sécurité et l’aptitude à l’audit. Plus tard, chaque lacune coûtera cher : avenants contractuels, contournements, shadow IT ou outils supplémentaires.

1) Scope-Fit et flux de données : que doit-on placer précisément dans le cloud ?

Ne commencez pas par les fonctionnalités, mais par les valeurs informationnelles : quelles catégories de données le service traite-t-il (données à caractère personnel, confidentielles, critiques pour l’exploitation) ? Quels systèmes sont connectés (ERP, IAM, e‑mail, tickets) ? Un service qui exporte et distribue des données nécessite des contrôles différents d’un outil isolé.

Preuve minimale pratique : fiche de service avec finalité, catégories de données, interfaces, groupes d’utilisateurs, dépendances critiques et fenêtres d’exploitation. C’est ensuite le lien avec l’évaluation des risques, le Statement of Applicability (SoA) et les audits internes.

2) Traduire le modèle de responsabilité partagée en tâches

De nombreux fournisseurs documentent la responsabilité partagée. Pour votre ISMS, cela ne suffit pas tant que ce n’est pas converti en tâches concrètes : qui configure le MFA ? Qui vérifie les logs ? Qui est responsable des clés ? Qui applique les correctifs (sur IaaS) ?

Une matrice RACI (Responsible, Accountable, Consulted, Informed) par domaine de contrôle s’est révélée efficace. L’important est «Accountable» : un rôle interne qui, le cas échéant, assume la responsabilité devant les auditeurs et la direction.

3) Capacité du fournisseur : preuves, droits d’audit, sous-traitants

ISO 27001 aborde explicitement le contrôle des fournisseurs. Pour le cloud, cela signifie : vous avez besoin d’informations fiables sur les mesures de sécurité, les sous‑processeurs/sous‑traitants, les questions de localisation/région et sur les notifications en cas d’incident de sécurité. Vérifiez notamment :

• Stratégie d’audit et de preuves : recevez-vous des rapports/preuves appropriés (p. ex. rapports d’audit indépendants), et sont-ils suffisants pour votre périmètre ?
• Transparence sur les sous‑traitants : les pRESTataires secondaires sont-ils nommés, les changements annoncés, et existe‑t‑il un droit d’opposition ?
• Voies et délais de notification : notification d’incident de sécurité, personnes de contact, contact 24/7, contenu minimal de la notification.
• Continuité de service : disponibilité, fenêtres de maintenance, processus d’urgence, sauvegarde/RESTauration (souvent le point critique pour les SaaS).

Si vous souhaitez approfondir les risques fournisseurs : prévoyez en interne un lien vers votre contribution sur la gestion des fournisseurs (clauses contractuelles, critères de vérification technique, processus d’intégration).

4) Capacité d’intégration technique : IAM, journalisation, réseau, clés

Un service cloud n’est pas « un outil », mais fait partie de votre architecture de sécurité. Vérifiez donc au préalable les points d’intégration :

• Intégration IAM : SSO (Single Sign-On), SCIM (provisionnement/déprovisionnement automatisé), modèle de rôles, prise en charge du MFA et du Conditional Access.
• Journalisation : export vers votre solution centrale de logging/SIEM, détails des logs (actions administrateur, authentification, accès aux données), conservation, cohérence des horodatages.
• Réseau et accès : endpoints privés, RESTrictions IP, séparation des locataires, accès API, limitations de débit.
• Chiffrement / gestion des clés : chiffrement au repos/en transit, clés client (BYOK/CMK), rotation, options HSM, accès aux clés par le fournisseur.

Ces points ne sont pas des « nice to have ». Ils déterminent si les contrôles sont opérationnellement soutenables et vérifiables, ou si vous devrez effectuer en permanence des travaux manuels.

5) Conséquences sur les coûts et l’exploitation : la sécurité est aussi un effort continu

Les coûts cloud sont souvent perçus comme des frais d’utilisation. Toutefois, les coûts additionnels pertinents pour ISO 27001 sont régulièrement liés à :

• Exploitation des identités (SSO, gestion des rôles, recertification des habilitations)
• Journalisation/monitoring (volume de données, licences SIEM, conservation)
• Gestion des clés et des certificats (HSM/Key Vault, rotation, processus)
• Charge d’audit et de justification (revues fournisseurs, évaluations annuelles, audits internes)
• Préparation à la sortie (export des données, tests de migration, exploitation parallèle)

Un dossier décisionnel clair nomme explicitement ces coûts récurrents, afin d’éviter que les mesures de sécurité ne démarrent « sous-financées ».

Contrôles pour l’intégration dans l’ISMS: familles de contrôles pragmatiques

Plutôt que d’apprendre par cœur des numéros d’Annexe A, il est plus utile, pour la mise en œuvre, de structurer les contrôles cloud en familles de contrôles. Chaque famille doit fournir trois éléments : (1) règle/politique, (2) mise en œuvre technique, (3) preuve vérifiable.

Gouvernance Cloud : politiques, rôles, voies de décision

Sans gouvernance, la sécurité cloud devient affaire de décisions ponctuelles. Vous devriez au minimum définir :

• Processus d’onboarding des services cloud (qui approuve, quelles étapes de vérification, quelles exigences minimales)
• Modèle de rôles (Service Owner, Information Owner, responsables ISMS, équipe exploitation/plateforme, protection des données)
• Gestion des changements (modifications de configuration, habilitations, intégrations ; validations et documentation)
• Gestion des dérogations (acceptation du risque avec échéance, mesures compensatoires, date de revue)

Perspective d’audit : les auditeurs cherchent moins « la politique parfaite » que des preuves que les décisions sont prises de manière cohérente, fondée sur les risques et reproductible.

Gestion des actifs et des données : classification, résidence des données, cycle de vie

Dans le cloud, la classification des données est l’ancre : elle détermine quels contrôles sont obligatoires (p. ex. chiffrement, RESTrictions d’accès, DLP). Définissez :

• Classes de données (p. ex. public, interne, confidentiel, strictement confidentiel) et exemples clairs.
• Utilisation cloud autorisée par classe (quelles catégories de services sont permises, quelles régions/emplacements).

Important pour la pratique : pour le SaaS, la « suppression » est souvent un processus (suppression logique, conservation, sauvegardes). Votre ISMS doit représenter et évaluer cette réalité, pas l’idéaliser.

Gestion des identités et des accès (IAM) : la constatation d’audit cloud la plus fréquente

IAM est, dans les projets cloud, le domaine avec le plus de constats, car il croît rapidement et est proche des métiers. Contrôles minimaux :

• SSO et MFA pour tous les comptes privilégiés, idéalement pour tous les utilisateurs.
• Principe du moindre privilège (droits strictement nécessaires) et rôles plutôt que droits individuels particuliers.
• Joiner/Mover/Leaver : provisionnement/déprovisionnement automatisé, idéalement avec SCIM.
• Recertification régulière des autorisations (qui vérifie, comment documenter, quelle fréquence selon le risque).
• Comptes Break-Glass : accès d’urgence fortement protégés, surveillance séparée et utilisation documentée.

Éléments de preuve acceptés par les auditeurs : export des rôles, statut MFA, journaux de recertifications, tickets/changes pour les modifications de rôles, journalisation des actions d’administration.

Chiffrement et gestion des clés : du simple „cocher“ à une pratique contrôlée

« Chiffrement activé » n’est pas un contrôle tant que les accès aux clés, la rotation et les responsabilités sont flous. Pour les services cloud, vous devriez définir :

• Chiffrement en transit : normes TLS, gestion des certificats, aucun protocole non sécurisé.
• Chiffrement au repos : chiffrement standard, éventuellement clés gérées par le client (Customer Managed Keys).
• Cycle de vie des clés : rotation, accès (qui peut gérer les clés), séparation des fonctions.
• Sauvegardes et exportations : chiffrement également hors de la plateforme, en particulier pour les exportations de données.

Conséquence pratique : si vous optez pour BYOK/CMK, vous devez être capable d’en assurer l’exploitation (processus, supervision, accès d’urgence). Sans cette capacité, la possession de ses propres clés n’est souvent qu’une illusion de contrôle.

Logging, Monitoring et Détection : auditable plutôt que « nous pourrions »

ISO 27001 n’exige pas une solution SIEM spécifique, mais la capacité à détecter, investiguer et démontrer des événements. Dans le cloud, vous devez donc préciser :

• Quels événements sont journalisés ? Authentification, actions d’administration, modifications de politiques, exportations de données, appels d’API, erreurs/anomalies.
• Où sont stockés les logs ? Centralisé, protégé contre la manipulation (stockage Write Once/stockage immuable, dans la mesure du possible), avec une durée de rétention définie.
• Qui réagit ? Responsabilités, voies d’alerte, astreinte/remplacement, Runbooks.

Une erreur fréquente en pratique est « trop de journalisation sans plan ». Il est préférable d’adopter un profil de journalisation basé sur le risque par classe de service, complété par un jeu minimal toujours actif (en particulier les événements d’administration et IAM).

Beispiel: Minimaler Audit-Nachweis-Ordner je Cloud-Service (Strukturvorschlag)
01_Service-Steckbrief.pdf
02_Risikoanalyse_und_Risikobehandlung.pdf
03_SoA_Zuordnung_Controls.pdf
04_Vertrag_und_Sicherheitsanhang.pdf
05_RACI_und_Betriebsmodell.pdf
06_IAM_Rollenexport_MFA_Nachweise/
07_Logging_Forwarding_Nachweise/
08_Change_Records_und_Ausnahmen/
09_Incident_Runbooks_und_Tests/
10_Exit_Plan_und_Exporttests/

Gestion des vulnérabilités et des correctifs : différente selon le modèle de service

Ici, SaaS se distingue nettement d’IaaS :

• SaaS : le fournisseur applique les correctifs de plateforme et d’application. Vos contrôles portent sur la configuration, l’IAM, les intégrations, les endpoints et l’évaluation des informations de release/changes communiquées par le fournisseur.
• PaaS : le fournisseur applique les correctifs des services de base, vous appliquez éventuellement les correctifs des runtimes/dépendances de votre application. Important : des politiques sur les versions supportées et les déploiements.
• IaaS : vous appliquez les correctifs des systèmes d’exploitation et des applications. C’est un programme classique de patching et de hardening, simplement avec des outils cloud.

Perspective d’audit : il sera vérifié que les responsabilités sont claires, qu’une évaluation des vulnérabilités a lieu et qu’un processus existe pour appliquer ou compenser rapidement les mises à jour critiques.

Sauvegarde, RESTauration et continuité d’activité : RTO/RPO et rétablissement réel

Dans les projets cloud, la disponibilité est souvent confondue avec « le fournisseur est hautement disponible ». Pour votre ISMS, ce qui compte ce sont vos exigences métier. Définissez :

• RTO/RPO (Recovery Time Objective/Recovery Point Objective) : À quelle vitesse et avec quelle perte de données pouvons-nous rétablir le service ?
• Étendue des sauvegardes : configurations (IAM, politiques), données, matériel de clés (lorsque permis), configurations d’intégration.
• Tests de RESTauration : fréquence, critères de réussite, enregistrements. Sans tests, la sauvegarde se révèle insuffisante pour l’audit.

Pour les SaaS, le point critique est souvent : quelles possibilités d’export existe-t-il ? À quelle rapidité obtenez-vous les données en cas d’urgence ? Quelles dépendances aux services d’identité ou à la messagerie empêchent l’accès ?

Gestion des incidents et forensique : ce qui change dans le cloud

La réponse aux incidents dans le cloud est avant tout une question d‘accès aux données probantes et de coordination. Définissez pour chaque service :

• Voies de contact avec le fournisseur (hotline sécurité, priorité des tickets, escalade).
• Conservation des preuves : Quels logs, snapshots ou exports sont possibles ? Quelle rétention est active ?
• Rôles : Qui conduit, qui décide d’une coupure/isolement, qui communique en interne/externe ?

Une preuve vérifiable est un runbook testé (un exercice tabletop suffit comme point de départ), incluant les leçons apprises et le suivi des mesures.

Gestion des changements et des configurations : conforme au cloud, pas centrée sur les serveurs

ISO 27001 attend des changements contrôlés. Dans le cloud, cela signifie : les modifications apparaissent souvent dans les configurations, les politiques et les rôles. De bons contrôles sont :

• Configurations de référence par classe de service (p. ex. MFA activé, logging activé, rôles administrateurs RESTreints).
• Enregistrements de changement pour les modifications affectant la sécurité (droits, réseau, clés, logging).
• Relectures régulières des configurations et traitement des écarts.

Si vous utilisez Infrastructure as Code (IaC) : cela facilite la traçabilité, mais ce n’est pas automatique. Le facteur déterminant est le processus : revue, approbation, rollback, et détection des modifications manuelles.

Stratégie de sortie et portabilité : contrôle contre le lock-in et le risque opérationnel

Un plan de sortie est, dans le cadre d’ISO 27001, un argument très solide dans le traitement des risques, car il réduit les dépendances et augmente la capacité d’action en cas de crise. Un plan de sortie pragmatique comprend :

• Export des données : formats, complétude, fréquence, chiffrement, intégrité (somme de contrôle / checksums), responsables.
• Export des configurations : rôles, politiques, intégrations, automatisations.
• Voie de migration : options de plateforme cible, dépendances critiques, test minimal (p. ex. test annuel d’export/RESTauration).
• Clauses contractuelles : délais, assistance, suppression, RESTitution, coûts.

Important : la sortie n’est pas un « projet final », mais une compétence. De petits tests réguliers coûtent moins cher qu’une grande migration sous pression temporelle.

Perspective d’audit : quelles preuves comptent réellement dans les environnements cloud

Beaucoup d’équipes documentent trop au mauvais endroit (textes longs) et trop peu au bon endroit (artefacts vérifiables). Dans les audits cloud, comptent typiquement :

• Périmètre et inventaire : quels services cloud sont dans le périmètre ISMS, avec propriétaires et finalité.
• Évaluation des risques : risques traçables par service ou par classe de service, incluant le traitement des risques.
• SoA : choix motivé des contrôles, incl. mise en œuvre/statut.
• Dossier fournisseur : contrat, annexe sécurité, preuves/rapports, informations sur les sous-traitants, revues.
• Preuves opérationnelles : exports IAM, protocoles de recertification, transfert des logs, exercices d’incident, tests de RESTauration.

Si vous souhaitez vous structurer pour être « Audit-Ready », prévoyez en interne un lien vers une check-list « Audit-Ready ». Cela améliore à la fois la préparation et la qualité du dépôt quotidien des documents.

Checklist pratique : intégrer un service cloud conforme à l’ISMS en 10 étapes

1. Établir une fiche service (finalité, données, interfaces, utilisateurs, propriétaires).
2. Définir la classification des données et les régions/résidence autorisées.
3. Documenter la responsabilité partagée sous forme de RACI par famille de contrôles.
4. Contrôle du fournisseur incluant sous-traitants, procédure de notification d’incident, preuves.
5. Réaliser l’évaluation des risques, planifier le traitement des risques (incl. mesures compensatoires).
6. Finaliser le contrat/annexe sécurité (SLA, logging, support, exit, informations d’audit).
7. Intégrer l’IAM (SSO, MFA, rôles, SCIM, Break-Glass).

Cet ordre a été choisi volontairement pour que la gouvernance et les preuves ne soient pas « rattrapées » après coup, mais que l’approvisionnement et l’exploitation soient viables dès le départ.

Responsabilités et gouvernance au quotidien : qui doit décider de quoi ?

L’intégration du cloud dans l’ISMS échoue souvent à cause d’hypothèses implicites : « la sécurité s’en occupe » ou « le fournisseur est responsable ». Des décisions solides requièrent des rôles clairs :

• Responsable de service : responsabilité fonctionnelle, budget, accepte les risques résiduels dans le cadre de la gouvernance.
• Responsable de l’information : prend en charge le besoin de protection/la classification des données (souvent le service métier, assisté par l’IT/la conformité).
• Plateforme cloud/Exploitation : lignes de base techniques, journalisation, comptes, automatisation, exploitation.
• ISMS/Conformité : méthode, évaluation des risques, SoA, tenue des preuves, communication d’audit.
• Sécurité : contrôles, monitoring, gestion des incidents, évaluations des exceptions.
• Protection des données (le cas échéant) : bases juridiques, traitement pour le compte (sous-traitance), transferts internationaux.

La direction générale n’est pas « responsable des détails », mais elle doit soutenir la gouvernance : par des mandats clairs, des ressources pour les contrôles et une tolérance au risque définie.

Conclusion : utiliser des services cloud conformes à ISO 27001 implique des décisions contrôlées

Les services cloud sous ISO 27001 ne sont pas contradictoires — ils ne sont maîtrisables que si le choix, le contrat, la configuration et l’exploitation sont considérés comme un système de contrôle cohérent. Le levier central n’est pas un outil isolé, mais votre capacité à attribuer clairement les responsabilités, à documenter les flux de données et les risques, et à mettre en œuvre des contrôles techniques de manière à ce qu’ils tiennent au quotidien et en audit.

Si vous souhaitez démarrer de façon pragmatique : établissez une fiche de service, un paquet standard d’exigences minimales IAM et de journalisation, une annexe de sécurité fournisseur et un test minimal de sortie. Cela réduit sensiblement les risques cloud typiques (incertitude, absence de preuves, verrouillage) — sans alourdir votre ISMS avec une documentation inutile.

Pour ce sujet, l’intégration ISMS Cloud et la gouvernance cloud sont également importantes. L’article remet ces aspects en perspective de manière compréhensible et montre ce qui compte au quotidien.