tadata
Retour à l'accueil

Architecture de Sécurité Cloud : Couches, Modèles et Pratiques

#cloud#security#architecture#compliance

La sécurité cloud n'est pas un produit que l'on achète -- c'est une architecture que l'on construit. Comprendre le modèle de responsabilité partagée, la défense en profondeur et la sécurité centrée sur l'identité est fondamental pour tout déploiement cloud.

Le modèle de responsabilité partagée

La frontière entre responsabilité du fournisseur et du client varie selon le type de service :

CoucheIaaSPaaSSaaS
Sécurité physiqueFournisseurFournisseurFournisseur
Infrastructure réseauFournisseurFournisseurFournisseur
Hyperviseur / OS hôteFournisseurFournisseurFournisseur
OS invitéClientFournisseurFournisseur
Runtime / middlewareClientFournisseurFournisseur
ApplicationClientClientFournisseur
DonnéesClientClientClient
Identité et accèsClientClientClient
Chiffrement côté clientClientClientClient

Point clé : les données et l'identité sont toujours votre responsabilité, quel que soit le modèle de service.

Sécurité réseau

Architecture VPC

  • Sous-réseaux publics -- uniquement pour les load balancers et bastions
  • Sous-réseaux privés -- serveurs applicatifs, bases de données, services internes
  • Sous-réseaux isolés -- aucun accès internet, pour le traitement de données sensibles
  • Endpoints VPC -- accéder aux services cloud sans traverser internet

Contrôles de sécurité

ContrôleObjectifExemples
Security GroupsPare-feu au niveau instance (stateful)AWS SG, GCP Firewall Rules
Network ACLsPare-feu au niveau sous-réseau (stateless)AWS NACL, Azure NSG
WAFProtection applicativeAWS WAF, Cloud Armor, Azure WAF
Protection DDoSMitigation des attaques volumétriquesAWS Shield, Cloud Armor
Private LinkConnectivité privée aux servicesAWS PrivateLink, GCP Private Service Connect

Gestion des identités et des accès

L'IAM est la couche de sécurité la plus critique dans le cloud. Un IAM mal configuré est la première cause de brèches cloud.

Principes fondamentaux :

  • Moindre privilège -- accorder uniquement les permissions nécessaires
  • Pas de credentials à longue durée -- utiliser des rôles IAM, pas des clés d'accès
  • MFA partout -- imposer l'authentification multi-facteur pour tous les utilisateurs humains
  • Fédération -- centraliser l'identité avec le SSO (Okta, Azure AD, Google Workspace)
  • Comptes de service -- identité séparée pour chaque service, pas de credentials partagés

Architecture d'identité

PatternDescriptionCas d'usage
SSO + SAML/OIDCFédérer l'identité corporate vers le cloudAccès humain
Workload IdentityIdentité cloud-native pour les servicesService-à-service
Rôles cross-accountAssumer des rôles entre comptes AWSArchitectures multi-comptes
Accès juste-à-tempsPermissions élevées temporairesScénarios de break-glass

Chiffrement

Au repos

  • Chiffrement par défaut -- tous les providers majeurs chiffrent le stockage par défaut
  • Clés gérées par le client (CMK) -- vous contrôlez la clé dans KMS
  • Chiffrement côté client -- chiffrer avant d'envoyer au cloud (contrôle maximal)

En transit

  • TLS partout -- imposer TLS 1.2+ pour toutes les connexions
  • TLS mutuel (mTLS) -- client et serveur s'authentifient mutuellement
  • Gestion des certificats -- utiliser ACM (AWS), Certificate Manager (GCP), ou Let's Encrypt

Gestion de la posture de sécurité

Catégorie d'outilExemplesFonction
CSPMPrisma Cloud, AWS Security Hub, WizDétecter les misconfigurations
CWPPAqua, Sysdig, FalcoProtection runtime des workloads
CIEMErmetic, CloudKnoxAnalyse des permissions d'identité
Scan IaCCheckov, tfsec, BridgecrewDétecter les problèmes avant déploiement
Scan de secretsGitGuardian, TrufflehogDétecter les credentials dans le code

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.