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.

tadata
IaaS (VMs) Containers (CaaS) PaaS / serverless SaaS Data and access policy You You You You Identity and IAM configuration You You You Shared Application code You You You Provider Runtime / container image You You Shared Provider Guest OS and patching You Shared Provider Provider Network configuration You Shared Shared Provider Hypervisor, hardware, facility Provider Provider Provider Provider You Shared Provider responsibility shifts Qui sécurise quoi, par modèle de service
IaaS (VMs) Containers (CaaS) PaaS / serverless SaaS Data and access policy You You You You Identity and IAM configuration You You You Shared Application code You You You Provider Runtime / container image You You Shared Provider Guest OS and patching You Shared Provider Provider Network configuration You Shared Shared Provider Hypervisor, hardware, facility Provider Provider Provider Provider You Shared Provider responsibility shifts Qui sécurise quoi, par modèle de service
Le trait épais de chaque colonne marque le changement de responsable ; le client possède toujours les données, les identités et la configuration des accès, même en SaaS

Extrait de la fiche « Cloud Reference Architectures » · Demander la fiche complète

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
tadata
Internet Gateway VPC (Flow Logs on) Public subnet (NACL) ALB + SG NAT GW Private subnet (NACL) EC2 + SG, IMDSv2 S3/DynamoDBendpoint { } PrivateLink: KMS,SSM, STS DB subnet RDS + SG 443 8080 5432 egress
Internet Gateway VPC (Flow Logs on) Public subnet (NACL) ALB + SG NAT GW Private subnet (NACL) EC2 + SG, IMDSv2 S3/DynamoDBendpoint { } PrivateLink: KMS,SSM, STS DB subnet RDS + SG 443 8080 5432 egress
VPC trois tiers avec endpoints. SG = stateful par ENI, NACL = stateless par subnet ; le 8080 n'est autorisé que depuis le SG de l'ALB et le 5432 que depuis le SG de l'application (références SG à SG, sans CIDR) ; l'application ne sort vers Internet qu'en egress via le NAT ; les VPC Flow Logs enregistrent les flux acceptés et rejetés

Extrait de la fiche « AWS Security Essentials » · Demander la fiche complète

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
tadata
GitHub OIDC provider Issuer token.actions.githubusercontent.com Signs a short-lived JWT per job Job token claims aud sts.amazonaws.com sub repo:acme/api:ref:refs/heads/main issues IAM role trust policy Federated the OIDC provider ARN StringEquals token.actions... sub = repo:acme/api:ref:refs/heads/main checked by STS AssumeRoleWithWebIdentity Returns ASIA... keys, 1 h default Logged in CloudTrail with the sub claim allows
GitHub OIDC provider Issuer token.actions.githubusercontent.com Signs a short-lived JWT per job Job token claims aud sts.amazonaws.com sub repo:acme/api:ref:refs/heads/main issues IAM role trust policy Federated the OIDC provider ARN StringEquals token.actions... sub = repo:acme/api:ref:refs/heads/main checked by STS AssumeRoleWithWebIdentity Returns ASIA... keys, 1 h default Logged in CloudTrail with the sub claim allows
CI sans clé avec GitHub Actions OIDC : chaque maillon vérifie le précédent, et la condition sub de la trust policy du rôle est le contrôle qui compte. Un sujet générique comme repo:acme/* permet à n'importe quel dépôt ou branche de l'organisation d'assumer le rôle de déploiement ; fixez aussi aud

Extrait de la fiche « AWS Security Essentials » · Demander la fiche complète

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.