Elle couvre réseaux virtuels, routage, résolution de noms, passerelles, répartiteurs de charge, liaisons privées, périphéries Internet et politique réseau. Son périmètre est la couche de communication cloud, pas l'ensemble de la sécurité cloud.
Les API du fournisseur et l'automatisation créent et modifient les réseaux cloud. Les workloads peuvent être de courte durée, tandis que le trafic peut rester à l'intérieur de l'infrastructure du fournisseur et contourner les périmètres traditionnels. Une conception saine cartographie les flux requis vers des chemins contrôlés et protège les interfaces de transfert et de gestion.
Points clés
Architecture et politiqueSéparer environnements et zones de confiance, minimiser l'exposition publique, contraindre les communications entrantes, sortantes et est-ouest, et préserver la politique lorsque les ressources montent en charge ou se déplacent.
Plan de contrôle et responsabilitéDocumenter quelles couches réseau le fournisseur exploite et quels contrôles le client configure. Appliquer le moindre privilège à l'administration et à l'automatisation réseau, protéger les identifiants, revoir les changements et détecter la dérive dans les routes, passerelles, règles de sécurité, services de noms et connectivité privée.
Visibilité et résilienceCollecter les événements de flux, DNS, pare-feu, répartiteur de charge et plan de contrôle appropriés ; tester chemins asymétriques, limites de service, défaillance de dépendance, protections contre le déni de service et récupération sans conserver de contenu inutile.
Limite importanteUne adresse privée, un réseau virtuel ou un backbone de fournisseur n'authentifie pas un workload ni ne rend son trafic sûr. Les contrôles cloud-native peuvent avoir des lacunes de service, de région, de protocole et de journalisation, tandis qu'une route dangereuse, une permission d'identité ou un changement d'automatisation peut contourner plusieurs frontières prévues à la fois.