Zero Trust en environnement cloud : architecture et mise en œuvre pratique

Pourquoi le modèle périmétrique ne fonctionne plus

Le modèle de sécurité traditionnel — un périmètre réseau défendu (VPN, firewall) et une confiance implicite à l'intérieur — a été conçu pour des architectures on-premise des années 2000. Il est inadapté au cloud pour plusieurs raisons : les ressources sont distribuées sur plusieurs régions et fournisseurs, les employés travaillent depuis n'importe où, les micro-services communiquent entre eux de manière complexe, et les identités (humaines et machines) sont le nouveau périmètre.

Le framework Zero Trust (NIST SP 800-207) repose sur un principe simple : ne jamais faire confiance, toujours vérifier. Chaque accès — qu'il vienne de l'intérieur ou de l'extérieur du réseau — doit être authentifié, autorisé et audité.

Les 5 piliers du Zero Trust

1. Identité forte : MFA obligatoire, SSO centralisé, gestion des identités machines (service accounts, workload identity)
2. Endpoints vérifiés : conformité des appareils vérifiée avant accès (MDM, EDR)
3. Réseau micro-segmenté : accès réseau au minimum nécessaire, pas de confiance implicite entre VPCs ou services
4. Applications et APIs sécurisées : authentification à chaque appel, autorisation basée sur des attributs (ABAC)
5. Données classifiées et protégées : chiffrement au repos et en transit, DLP, accès aux données audités

Implémentation sur AWS

Identité et accès

• AWS IAM Identity Center (SSO) : point d'entrée unique pour tous les comptes AWS et applications SaaS
• MFA enforced : SCP (Service Control Policy) bloquant toute action sans MFA sur les comptes de production
• Least privilege automatisé : IAM Access Analyzer génère des politiques minimales basées sur l'activité CloudTrail
• Rotation automatique des credentials : AWS Secrets Manager avec rotation Lambda pour les credentials applicatifs

Réseau

• VPC sans accès Internet par défaut : tout le trafic sortant via NAT Gateway ou VPC Endpoints
• Security Groups restrictifs : autorisation explicite par port et source, aucune règle wildcard
• AWS Network Firewall : inspection du trafic est-ouest entre VPCs et nord-sud vers Internet
• PrivateLink : accès aux services AWS et partenaires sans traverser Internet

Monitoring continu

# AWS Config Rule - Détecter les Security Groups permissifs
resource "aws_config_config_rule" "no_unrestricted_ssh" {
  name = "restricted-ssh"
  source {
    owner             = "AWS"
    source_identifier = "INCOMING_SSH_DISABLED"
  }
}

# GuardDuty + EventBridge pour réponse automatique
resource "aws_cloudwatch_event_rule" "guardduty_alert" {
  event_pattern = jsonencode({
    source      = ["aws.guardduty"]
    detail-type = ["GuardDuty Finding"]
    detail = {
      severity = [{ numeric = [">=", 7] }]
    }
  })
}

Implémentation sur Azure

• Azure AD Conditional Access : accès conditionnel basé sur l'identité, le device, la localisation et le risque
• Microsoft Entra ID Protection : détection des connexions à risque en temps réel, MFA adaptatif
• Azure Policy : conformité continue des ressources avec remédiation automatique
• Microsoft Defender for Cloud : score de sécurité et recommandations Zero Trust sur l'ensemble du tenant
• Private Endpoints : équivalent Azure de PrivateLink pour tous les services PaaS

Matrice de maturité Zero Trust

Pilier	Niveau 1 (Traditionnel)	Niveau 2 (Avancé)	Niveau 3 (Optimal)
Identité	MFA sur certains comptes	MFA universel + SSO	Passwordless + risk-based
Réseau	VPN + firewall périmétrique	Micro-segmentation	Software-Defined Perimeter
Données	Chiffrement au repos	Chiffrement + DLP	DSPM + accès just-in-time
Applications	Auth basique	OIDC/OAuth + RBAC	ABAC + continuous verification
Monitoring	Logs centralisés	SIEM + alertes	XDR + réponse automatique

Accès Just-in-Time (JIT)

L'accès privilégié permanent est l'une des plus grandes surfaces d'attaque. Le principe JIT (Just-in-Time) consiste à n'accorder les droits élevés que sur demande, pour une durée limitée, avec approbation. Implémentations :

• AWS : IAM Identity Center avec accès temporaire via approbation, ou AWS Systems Manager Session Manager (accès SSH sans ouvrir le port 22)
• Azure : Privileged Identity Management (PIM) — activation des rôles Azure AD sur demande avec durée limitée
• Multi-cloud : HashiCorp Vault avec dynamic secrets (credentials éphémères générés à la demande)

Conclusion

Le Zero Trust n'est pas un produit à acheter mais une architecture à construire progressivement. Commencez par les gains les plus impactants : MFA universel, privilege minimum et micro-segmentation réseau. Puis avancez vers l'accès JIT, la vérification continue et la réponse automatique aux incidents. Move2Cloud accompagne ses clients dans l'évaluation de leur maturité Zero Trust et la définition d'une feuille de route pragmatique.