Attestation C5 : préparer les preuves d’assurance du cloud

Un client cloud veut savoir quelles protections le fournisseur assure et lesquelles restent de sa propre responsabilité. L’Office fédéral allemand de la sécurité de l’information (BSI) publie le Cloud Computing Compliance Criteria Catalogue, ou C5, comme base structurée pour examiner cette assurance. Pour un directeur technique, se préparer consiste à rendre vérifiables la limite du service, la mise en œuvre des mesures et les enregistrements opérationnels, et pas seulement à rassembler des politiques.

C5 est un catalogue de critères utilisé pour une attestation indépendante, et non une certification de type ISO. La documentation du BSI sur C5 est la référence principale. Commencez par convenir avec l’auditeur indépendant de l’édition applicable, de l’objectif d’assurance et du périmètre de l’examen.

Définir précisément le service couvert par le rapport

Décrivez le service cloud, les sites d’exploitation, les limites organisationnelles et les dépendances. Un rapport couvrant un service ne couvre pas automatiquement tous les produits commercialisés sous la même marque. Identifiez les composants de production, les interfaces d’administration, les opérations de support et les services externes susceptibles d’affecter les affirmations d’assurance.

La description du système doit permettre à une personne extérieure de comprendre comment les données des clients entrent dans le service, y circulent et en sortent. Incluez les chemins d’administration, les processus de déploiement, la surveillance de la sécurité, les sauvegardes et la répartition des responsabilités entre équipes. Expliquez les caractéristiques pertinentes du service et ses conditions d’exploitation plutôt que de remplacer le récit par des schémas d’architecture.

Tranchez ces questions de périmètre avant de collecter des preuves :

• Quels produits, régions et environnements sont inclus ?
• Quelles équipes administrent la production ou peuvent accéder aux informations des clients ?
• Quels fournisseurs sous-jacents soutiennent le service, et comment leurs mesures sont-elles traitées ?
• Quelles configurations et tâches de sécurité restent à la charge des clients ?
• Quels changements significatifs sont intervenus, ou sont prévus, pendant la période d’examen ?

Justifiez explicitement les exclusions. Si un déploiement historique est exclu, veillez à ce que les déclarations destinées aux clients ne laissent pas entendre qu’il est couvert. Le livrable est une description du système versionnée, étayée par des enregistrements relatifs à l’architecture, aux dépendances et aux responsabilités.

Choisir le type de rapport avant de fixer le calendrier des preuves

L’assurance C5 s’exprime généralement par un rapport d’attestation de l’auditeur. Le type 1 porte sur la conception et la mise en œuvre des mesures à une date donnée. Le type 2 examine en outre l’efficacité opérationnelle sur une période déterminée.

Le type 1 peut constituer une étape utile lors de la mise en place d’un environnement de mesures, mais il ne répond pas à la même question que le type 2. Vérifiez ce que les clients exigent réellement avant de choisir un rapport intermédiaire.

Convenez de la période et des attentes en matière de preuves avec l’auditeur. Ne supposez pas une durée d’observation universelle. Une procédure rédigée vers la fin d’une période ne peut pas établir que la mesure fonctionnait auparavant. De même, un test actuel réussi n’efface pas une défaillance passée.

Construire les preuves autour de la responsabilité et de l’exécution

À titre de méthode de préparation pratique, constituez un registre des preuves reliant chaque critère applicable à la mesure mise en œuvre, au responsable, à la limite du service, à la source des preuves, à la fréquence de revue et aux écarts non résolus. Consignez les décisions d’applicabilité et leur justification ; évitez de déclarer un critère non pertinent au seul motif que sa mise en œuvre serait difficile.

Distinguez trois questions : ce qui doit se produire, ce qui est mis en œuvre et ce qui s’est réellement produit. Une politique répond à la première. Les enregistrements de configuration peuvent étayer la deuxième. Les tickets, journaux, validations et résultats de tests étayent la troisième.

Il s’agit d’exemples pratiques, et non d’une liste de contrôle C5 complète. Utilisez le catalogue et le périmètre convenus pour déterminer la couverture requise, y compris les mesures organisationnelles, liées au personnel, physiques et techniques.

Rendre les preuves reproductibles

Pour chaque export ou capture d’écran, conservez le système source, la date de collecte, la période concernée, les filtres et la personne qui a collecté. Indiquez s’il représente l’ensemble de la population ou un élément sélectionné. Les auditeurs doivent comprendre la population dans laquelle ils sélectionnent leurs échantillons ; un dossier ne contenant que des exemples réussis ne suffit pas.

Privilégiez les enregistrements qui conservent l’acteur, l’horodatage, l’action et le résultat. Protégez les preuves contre toute modification non autorisée et évitez d’exposer inutilement des données clients. Lorsqu’une occultation est nécessaire, conservez suffisamment de contexte pour que le réviseur comprenne ce que l’enregistrement prouve.

Séparer les mesures héritées des obligations conservées

L’assurance d’un fournisseur d’infrastructure peut étayer la sécurité physique ou les mesures de la plateforme sous-jacente. Elle n’établit pas que l’autorisation au niveau des locataires de votre application fonctionne. Documentez la dépendance, le périmètre du rapport concerné, la période, les exceptions et les responsabilités que votre équipe doit encore assumer.

Les mesures complémentaires à la charge des clients doivent elles aussi être formulées de manière concrète. « Le client est responsable de la sécurité » est trop large. Précisez des tâches telles que l’administration des utilisateurs du locataire, la configuration de la fédération d’identités ou la revue des politiques d’accès contrôlées par le client. Gardez ces responsabilités cohérentes entre la description du système, la documentation du service et les dispositions contractuelles.

Mener la préparation comme un programme d’ingénierie

Commencez par une analyse des écarts au regard des critères convenus. Distinguez la mise en œuvre manquante des preuves manquantes : elles appellent des remèdes différents. Une revue non documentée peut nécessiter de meilleurs enregistrements ; une revue des accès qui n’a jamais eu lieu nécessite une mesure opérationnelle.

Attribuez à chaque écart un responsable, une action de remédiation, des dépendances et une date cible. Donnez la priorité aux problèmes touchant la séparation des locataires, les accès à privilèges, les changements en production, la réponse aux incidents et la capacité de reprise en fonction des risques du service, et pas seulement aux tâches documentaires les plus faciles.

Avant la période de type 2, vérifiez que les mesures récurrentes disposent de calendriers réalistes et d’enregistrements durables. Confirmez qui les exécute en cas d’absence ou de rotation du personnel. Pour les mesures déclenchées par des événements, comme la suppression de comptes, assurez-vous que la population déclenchante peut être identifiée.

Réalisez une revue de préparation avec des preuves représentatives. Suivez un changement de la demande jusqu’au déploiement, un administrateur sortant jusqu’à la révocation de ses accès et un exercice de reprise jusqu’à l’action corrective. Cela met en évidence des passages de relais défaillants qu’une revue des politiques peut manquer.

Pendant l’examen, tenez un registre des demandes avec leurs responsables et l’état des réponses. Gardez les enregistrements originaux disponibles, expliquez ouvertement les écarts et suivez la remédiation séparément des preuves historiques. Ne réécrivez pas d’anciens enregistrements pour les faire paraître conformes. C’est l’auditeur qui détermine comment les constats influent sur les tests et sur l’opinion.

Exemple concret : une application gérée sur une infrastructure externe

Supposons, à titre illustratif, qu’un fournisseur exploite une application multilocataire dans une région, utilise un fournisseur d’infrastructure externe et vise une assurance de type 2. Son équipe maîtrise les mises en production de l’application, les droits des locataires, l’administration de la production et les procédures de reprise.

La description du périmètre identifie l’application, la base de données, le plan de gestion, les outils de support et la dépendance d’infrastructure. Elle explique quelles mesures sous-jacentes sont héritées et lesquelles restent à la charge du fournisseur de l’application.

Pour l’isolation des locataires, l’équipe consigne sa conception des autorisations, ses tests négatifs automatisés, les constats des tests de sécurité et les approbations de mise en production. Elle conserve aussi les enregistrements de changements montrant quand la logique d’autorisation a été modifiée. Le rapport de l’infrastructure est une preuve de dépendance à l’appui, et non une preuve de l’isolation de l’application.

Pour les accès à privilèges, l’équipe conserve la population des administrateurs, les approbations d’attribution, les décisions de revue et les enregistrements de retrait. Supposons qu’une revue découvre un compte de support inutilisé. L’équipe consigne la découverte, la révocation, l’évaluation de l’exposition et l’action préventive. C’est plus crédible que de soumettre uniquement la liste de comptes nettoyée.

Pour la reprise, elle conserve un résultat de test de restauration montrant ce qui a été restauré, la durée écoulée, les contrôles d’intégrité des données et les limites non résolues. Une tâche de sauvegarde configurée ne démontre pas à elle seule la capacité de reprise. Chaque ensemble de preuves a un responsable et une période définie, de sorte que l’auditeur peut relier les enregistrements à la mesure examinée.

Réutiliser le travail d’assurance sans revendiquer d’équivalence

L’ISO/IEC 27001 porte sur un système de management de la sécurité de l’information au périmètre défini. SOC 2 est un rapport d’attestation qui utilise ses propres critères et son propre contexte de reporting. C5 se concentre sur l’assurance des services cloud selon le catalogue du BSI.

Les appréciations des risques, mesures de contrôle d’accès, procédures de gestion des incidents et enregistrements opérationnels existants peuvent soutenir plusieurs programmes. Réutilisez-les au moyen de correspondances propres à chaque version et à chaque périmètre, puis vérifiez les différences d’exigences ou de reporting. Une mesure commune ne crée pas une équivalence automatique entre référentiels.

Choisissez le portefeuille d’assurance en fonction des exigences réelles des clients et des risques du service. C5 n’est pas obligatoire pour tous les fournisseurs cloud ; les exigences d’appels d’offres, contractuelles ou sectorielles applicables doivent être examinées séparément. Ni un rapport C5 ni un autre document d’assurance n’établit à lui seul la conformité au RGPD ou à NIS2.

Préparer le rapport pour les décisions des clients

Les clients ont besoin de la description du système, de la date ou de la période, de l’opinion effective, des exceptions et des limites de responsabilité, et pas seulement de l’intitulé du rapport. Lorsque vous partagez des rapports, respectez la confidentialité contractuelle et fournissez le contexte nécessaire à l’évaluation du client.

Expliquez l’état de la remédiation sans laisser entendre que des corrections ultérieures modifient l’opinion historique. Si la période du rapport est antérieure à un changement d’architecture majeur, signalez cette limite. Convenez d’examens récurrents en fonction des attentes des clients et des évolutions de l’exploitation plutôt que de traiter l’attestation comme un titre intemporel.

Secani aide les équipes à relier la mise en œuvre des mesures et les preuves à des exigences revues. Modélisez le service et ses dépendances, attribuez des responsables et des réviseurs, rattachez les enregistrements à l’appui et transformez les lacunes de preuves en tâches. Gardez une validation humaine explicite pour les correspondances et les conclusions. Le modèle de préparation aux audits aide à préserver le périmètre et la responsabilité qui sous-tendent chaque affirmation.

Questions à trancher avant le premier examen

Le BSI délivre-t-il le rapport ?

Le BSI publie le catalogue. Un auditeur indépendant réalise l’examen et délivre le rapport d’attestation ; confirmez avec cet auditeur le cadre d’assurance applicable et les conditions de la mission.

Que faire si aucun incident réel ne s’est produit ?

N’inventez pas d’enregistrement d’incident. Conservez la preuve que le processus a été mis en œuvre et, le cas échéant, exercé. Convenez avec l’auditeur de l’incidence de l’absence d’événements sur les tests.

Que doit faire l’équipe ensuite ?

Prenez un service de production représentatif et préparez sa description de périmètre, sa matrice des responsabilités et son registre des preuves. Examinez ces trois livrables avec l’auditeur pressenti avant de constituer un volumineux dossier de preuves.