Applique la responsabilité cloud et protège les secrets

01Distingue les modèles

IaaS
→ machines, réseau et stockage configurables
→ client responsable du système invité et de nombreuses configurations

PaaS
→ runtime ou plateforme gérée
→ client responsable de l'application, des données et des paramètres exposés

SaaS
→ application fournie
→ client responsable des comptes, usages, données, partage et configuration du tenant

Plus le service est géré, plus la frontière change ; la responsabilité du client ne disparaît pas.

02Attribue chaque contrôle

03Vérifie le contrat réel

- localisation et sous-traitants
- réversibilité et export
- sauvegarde et restauration
- chiffrement et gestion des clés
- logs accessibles
- notification d'incident
- suppression des données
- disponibilité et support
- responsabilités explicites

Une fonction présente dans une brochure n’est pas forcément activée dans ton abonnement.

04Observe la matrice cloud

lab=/tmp/soria-cyber-data-network-cloud-$USER
bash module4-cyber-data-network-cloud.sh setup "$lab"
bash module4-cyber-data-network-cloud.sh run "$lab"
column -s, -t "$lab/output/cloud-responsibility.csv"

Le lab attend une attribution cohérente pour huit contrôles, par exemple :

CLOUD-102 guest_os_patching → customer
CLOUD-104 user_access_reviews → customer
CLOUD-108 tenant_backup_scope → shared

05Traite le fournisseur comme une dépendance

Service critique
→ fournisseur identifié
→ niveau de service
→ dépendances techniques
→ données hébergées
→ procédure de sortie
→ contacts incident
→ tests et preuves

ANSSI recommande une décision adaptée à la sensibilité du SI et met en avant des offres qualifiées pour certains usages sensibles.

06Protège les secrets

Secret manager ou key vault
→ contrôle d'accès
→ audit
→ versioning ou rotation
→ portée réduite
→ injection au runtime

À éviter :

secret dans le code
secret dans une image
secret partagé dans un wiki
secret global pour plusieurs environnements
secret sans propriétaire ni expiration

07Observe les six secrets

column -s, -t "$lab/output/secret-review.csv"

Résultats clés :

SECRET-103 → BLOCK_EXPOSED_SECRET
SECRET-105 → BLOCK_SHARED_SECRET
SECRET-102 → IMPROVE_SECRET_STORAGE

Un fichier .env non suivi peut être acceptable dans certains contextes locaux, mais il reste à gouverner, sauvegarder ou reconstruire et protéger par permissions.

08Réagis après exposition

1. Révoquer ou désactiver le secret
2. Générer un nouveau secret
3. Identifier les systèmes et logs concernés
4. Rechercher l'usage non autorisé
5. Corriger le stockage ou le pipeline
6. Retirer le secret de l'historique selon procédure
7. Documenter l'incident et les preuves

Supprimer uniquement la ligne du dernier commit ne retire pas le secret de l’historique ni des clones existants.

09Évite les identifiants permanents

Identité de workload
→ jeton court
→ périmètre limité
→ rotation automatique

Clé API permanente
→ longue exposition
→ copie facile
→ révocation souvent tardive

Lorsque la plateforme le permet, préfère les identités fédérées ou temporaires aux secrets statiques.

10Conserve la preuve côté client

Configuration exportée
Revue des identités
Journal d'administration
Inventaire des secrets
Rapport de patch
Test de sauvegarde
Contrat et attestation fournisseur
Exercice de réversibilité