Comment utiliser CSA STAR et le questionnaire CAIQ

La Cloud Security Alliance (CSA) propose deux outils complémentaires pour l’assurance fournisseur : STAR (Security, Trust, Assurance and Risk) et CAIQ (Consensus Assessments Initiative Questionnaire). Ils permettent de normaliser l’évaluation d’un service cloud, mais ne remplacent ni une analyse de risque, ni des exigences contractuelles vérifiables.

→ Lire l’explication complète de la marmotte

STAR : déclaration, attestation et certification

STAR signifie Security, Trust, Assurance and Risk. Le programme distingue trois niveaux d’assurance, souvent confondus dans les appels d’offres alors qu’ils n’apportent pas la même preuve.

Le niveau 1, STAR Level 1, repose sur une auto-évaluation publiée par le fournisseur. Celle-ci s’appuie généralement sur la Cloud Controls Matrix (CCM), la matrice de contrôles de la CSA, et sur le CAIQ. Le fournisseur décrit ses pratiques, ses services couverts et ses réponses aux contrôles. C’est une déclaration, pas une preuve indépendante. Une réponse affirmative signifie que le fournisseur affirme disposer d’un mécanisme, pas que ce mécanisme fonctionne sur le périmètre acheté.

Le niveau 2 apporte une évaluation indépendante. STAR Attestation associe généralement la CCM à SOC 2 (System and Organization Controls 2), un rapport d’audit sur les contrôles d’une organisation de service. STAR Certification repose sur une certification ISO/IEC 27001 (International Organization for Standardization et International Electrotechnical Commission), enrichie d’exigences STAR. Les deux voies n’ont pas la même valeur probatoire selon le contexte contractuel : SOC 2 décrit des contrôles sur une période donnée, ISO/IEC 27001 certifie un système de management dans un périmètre défini.

Le niveau 3 vise l’assurance continue. Il reste moins fréquent et ne doit pas être présumé parce qu’un portail fournisseur affiche un joli logo STAR. Le logo est un indice de sélection, jamais une mesure compensatoire. Les slides commerciales ont une propriété remarquable : elles ne journauxisent rien.

La position à tenir est nette : exiger au minimum une auto-évaluation STAR récente pour présélectionner un fournisseur, puis demander des éléments de niveau 2 quand le service traite des données sensibles, des identités ou des charges critiques. Une déclaration STAR Level 1 suffit rarement pour justifier une externalisation à impact élevé. Son compromis central est brutal : la standardisation accélère la comparaison, mais elle réduit le contexte métier à une grille de réponses. Il faut accepter ce compromis pour filtrer, pas pour décider seul.

La page Cloud Security Alliance donne le positionnement général de l’organisme. Pour rattacher cette collecte à une décision d’architecture, consulter aussi les repères cloud et gouvernance.

CAIQ et Cloud Controls Matrix : ce que les réponses prouvent

Le CAIQ est un questionnaire structuré à partir de la CCM. Chaque question renvoie à un domaine de contrôle : gouvernance, gestion des actifs, cryptographie, journalisation, continuité, sécurité applicative, identité ou sécurité de l’infrastructure. Cette correspondance évite la collection habituelle de questionnaires maison, où trois équipes demandent la même chose avec des synonymes et finissent avec quatre réponses incompatibles.

Une réponse CAIQ exploitable doit comporter plus qu’un « oui ». Il faut obtenir :

le statut du contrôle : implémenté, partiel, non applicable ou prévu ;
le périmètre exact : produit, région, offre managée, environnement de production ou d’administration ;
une référence de preuve : politique, rapport d’audit, procédure, configuration ou engagement contractuel ;
le responsable du contrôle : fournisseur, client, ou responsabilité partagée ;
les limites et exceptions connues.

La notion de responsabilité partagée doit être traitée ligne par ligne. Un fournisseur peut chiffrer le stockage physique et laisser la gestion des clés applicatives au client. Il peut fournir des journaux d’audit sans les conserver assez longtemps pour une investigation. Il peut proposer l’authentification multifacteur sans l’imposer aux comptes à privilèges. Répondre « oui » à la question de contrôle ne résout aucune de ces frontières.

Un CAIQ ne garantit pas la sécurité effective d’une instance louée. Il ne prouve pas qu’une configuration client ne rendra pas un compartiment de stockage public, qu’un jeton d’accès ne sera pas exposé dans une chaîne d’intégration continue, ou qu’une fédération d’identité est correctement conçue. La sécurité du plan de contrôle n’est pas celle de la charge hébergée. Confondre les deux produit des architectures très conformes sur papier et très ouvertes sur Internet. Une espèce assez répandue, hélas.

La CCM est utile pour construire une matrice de correspondance avec ISO/IEC 27001, le NIST (National Institute of Standards and Technology) Cybersecurity Framework ou les exigences internes. Elle ne dispense pas d’exiger les contrôles spécifiques au risque : localisation des données, séparation des locataires, clés détenues par le client, réversibilité, délai de notification d’incident et droit d’audit. Les référentiels NIST et ISO aident à maintenir cette correspondance sans inventer une taxonomie de plus.

Exploiter le CAIQ avant contractualisation

L’erreur fréquente consiste à envoyer le questionnaire, recevoir un tableur, puis cocher « fournisseur évalué ». Une réponse CAIQ doit devenir une décision, une exigence ou un risque accepté. Sans cette transformation, le fichier est un objet décoratif, légèrement moins lourd qu’un classeur de conformité de 200 onglets.

Commencer par fixer le périmètre du service évalué. Une réponse globale du groupe fournisseur ne vaut pas pour chaque produit. Le contrat doit nommer le service, les régions, les sous-traitants concernés, les options activées et la date de version du questionnaire. Les contrôles d’un service de calcul ne décrivent pas nécessairement ceux d’un outil d’analyse, même sous la même marque.

Classer ensuite les réponses dans quatre catégories :

Accepté : contrôle attesté, périmètre conforme, preuve indépendante disponible.
À contractualiser : contrôle déclaré mais sans obligation opposable, par exemple notification d’incident ou délai de suppression.
À compenser : lacune fournisseur couverte par une mesure côté client, par exemple chiffrement applicatif avec clés propres.
Bloquant : absence de contrôle incompatible avec la classification des données ou le scénario de reprise.

Les mesures compensatoires doivent avoir un propriétaire et une preuve d’exploitation. Chiffrer côté client ne compense pas une incapacité à exporter les journaux. Une sauvegarde externe ne compense pas l’absence de contrôle d’accès fort sur les consoles d’administration. Chaque risque a son mécanisme ; la magie des cases vertes s’arrête assez vite.

Les réponses du CAIQ doivent aussi alimenter le contrat. Exiger la mise à jour annuelle du questionnaire, la notification des changements matériels de contrôle, l’accès aux rapports d’audit sous accord de confidentialité, et le maintien des engagements pendant la durée de réversibilité. Une clause qui garantit seulement l’accès au portail de conformité garantit surtout l’existence d’un portail.

Exemple : transformer des réponses CAIQ en écarts actionnables

Un export CAIQ peut être enrichi localement avec une colonne de criticité et une décision. L’exemple suivant filtre les réponses non confirmées pour des contrôles critiques. Il suppose un fichier CSV (Comma-Separated Values) nommé caiq.csv, avec les colonnes control_id, question, answer, evidence_url et criticality.

#!/usr/bin/env python3
# Analyse locale d'un export CAIQ CSV.
# Requiert Python 3.10 ou supérieur, sans dépendance externe.

import csv
import sys

with open("caiq.csv", newline="", encoding="utf-8") as source:
    rows = csv.DictReader(source)
    gaps = [
        row for row in rows
        if row["criticality"].strip().lower() == "high"
        and (
            row["answer"].strip().lower() not in {"yes", "implemented"}
            or not row["evidence_url"].strip()
        )
    ]

for gap in gaps:
    print(
        f'{gap["control_id"]}: {gap["question"]}\n'
        f'  réponse={gap["answer"] or "absente"}\n'
        f'  preuve={gap["evidence_url"] or "absente"}'
    )

sys.exit(1 if gaps else 0)

Le code doit échouer dans la chaîne d’intégration continue si un contrôle critique perd sa preuve ou passe à un statut incomplet. Ce contrôle de dérive ne remplace pas la revue humaine : une URL de rapport peut exister tout en pointant vers un document expiré, hors périmètre ou généreusement caviardé.

Conserver l’export source, la date de collecte, les pièces justificatives et la décision associée dans un dépôt à accès restreint. Les questionnaires contiennent parfois des informations d’architecture, de sécurité physique ou de réponse à incident. Les déposer dans un espace de partage général revient à documenter la surface d’attaque pour la commodité administrative. Conceptuellement audacieux, opérationnellement médiocre.

Exploitation, révision et limites de STAR

STAR et CAIQ évaluent un fournisseur à un instant donné. La posture change avec les acquisitions, les nouvelles régions, les sous-traitants, les incidents et les modifications de service. Définir un cycle de révision annuel, mais déclencher aussi une réévaluation lors d’un changement de service critique, d’un incident significatif ou d’une évolution réglementaire.

Les éléments suivants doivent être suivis séparément du questionnaire :

rotation et révocation des clés de chiffrement, notamment lorsque le fournisseur opère un KMS (Key Management Service) ;
durée de conservation, intégrité et exportabilité des journaux ;
sauvegardes, tests de restauration et suppression vérifiable des données ;
comptes d’administration, fédération d’identité et authentification multifacteur ;
procédures de réponse à incident, canaux d’escalade et délais contractuels ;
plan de sortie, formats d’export, dépendances propriétaires et effacement final.

Aucune certification STAR ne garantit la disponibilité d’une application, la confidentialité d’un secret mal stocké ou la récupération d’une donnée supprimée par erreur. Le reste vient de l’architecture cliente : segmentation réseau, gestion des identités, chiffrement applicatif, sauvegardes indépendantes et supervision. Les mécanismes liés aux clés et aux modules cryptographiques sont détaillés dans cryptographie et module cryptographique matériel PKCS#11.

🐝 Ce qui arrive si on s’en passe

Sans questionnaire CAIQ ni niveau STAR exigé, aucune référence datée ne fixe ce que le fournisseur déclarait appliquer au moment de la signature. Lors d’un incident, il devient alors impossible d’établir si la défaillance relève d’un contrôle promis par le fournisseur ou d’une tâche restée à la charge du client : la recherche de responsabilité repose sur des échanges commerciaux non opposables, et les recours contractuels s’affaiblissent d’autant. Les contrôles de responsabilité partagée que personne n’a attribués restent sans exploitant, sans que rien ne signale leur absence. Enfin, l’organisation cliente ne peut pas démontrer à un auditeur ou à une autorité de contrôle la diligence exercée sur ses prestataires cloud, alors que plusieurs cadres de gestion du risque tiers exigent précisément cette trace documentée.

🦫 Explication de la marmotte 🍫

La Cloud Security Alliance publie des questions pour vérifier comment un fournisseur de services en ligne protège ses systèmes et les données confiées. Le questionnaire demande, par exemple, qui peut administrer les machines, comment les accès sont enregistrés, comment les données sont effacées et comment le fournisseur réagit à un incident.

Le fournisseur remplit les réponses et peut joindre des documents. Certaines réponses sont seulement déclarées par le fournisseur. D’autres sont vérifiées par un organisme extérieur qui examine les règles appliquées et les preuves disponibles. Le programme appelé STAR classe ces niveaux de vérification : une déclaration est moins convaincante qu’un examen indépendant.

Avant de signer un contrat, il faut vérifier que les réponses concernent bien le service acheté, pas un autre produit du même fournisseur. Chaque réponse doit aussi indiquer ce que le fournisseur fait réellement et ce qui reste à faire par le client. Si le fournisseur conserve les journaux des connexions pendant peu de temps, le client doit prévoir une autre conservation. Si le fournisseur chiffre les disques, cela ne protège pas forcément les fichiers contre un compte administrateur mal protégé.

Quand une réponse manque, est trop vague ou ne couvre pas un besoin critique, il faut soit demander un engagement dans le contrat, soit ajouter une protection côté client, soit renoncer au service. Les réponses doivent être revues régulièrement, car le service et ses règles changent.

Pages voisines

La citent

Évaluer la sécurité d'un fournisseur d'IA générative

Comment utiliser CSA STAR et le questionnaire CAIQ

Elle cite

: les deux pages se citent l’une l’autre.

Comment utiliser CSA STAR et le questionnaire CAIQ

Comment utiliser CSA STAR et le questionnaire CAIQ

STAR : déclaration, attestation et certification

CAIQ et Cloud Controls Matrix : ce que les réponses prouvent

Exploiter le CAIQ avant contractualisation

Exemple : transformer des réponses CAIQ en écarts actionnables

Exploitation, révision et limites de STAR

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines