05. Sécurité réseau cloud

05. Sécurité réseau cloud

Amazon Virtual

PRIVATE CLOUD

Virtual private cloud, c’est quoi ?

Un Nuage Privé Virtuel, ou Cloud Virtuel Privé, ou Virtual Private Cloud (VPC) est un groupe de ressources informatiques configurables à la demande dans un environnement de cloud public, qui fournit un certain niveau d’isolement entre les différentes organisations qui utilisent ces ressources.

Fonctionnement

Les groupes de sécurité &

NACLs

Les groupes de sécurité

• Un groupe de sécurité est un pare-feu virtuel stateful appliqué au niveau d’une ressource cloud (instance, machine virtuelle, base de données, load balancer, etc.).

• Il contrôle les flux entrants et sortants en autorisant explicitement le trafic selon des règles de sécurité.

• Fonctionne avec une approche deny all par défaut : seul le trafic explicitement autorisé est accepté.

• Règles entrantes (Inbound) : contrôle des connexions vers la ressource.

• Règles sortantes (Outbound) : contrôle des connexions initiées par la ressource.

• Filtrage réseau : adresses IP, protocoles (TCP, UDP, ICMP), ports et références à d’autres groupes de sécurité.

• Stateful : le trafic de retour est automatiquement autorisé sans règle supplémentaire.

• Gestion des accès : contrôle fin des communications entre applications, serveurs, bases de données et services.

• Segmentation réseau : limitation des flux au strict nécessaire selon le principe du moindre privilège.

• Cas d’usage : protection des instances EC2, bases RDS, clusters Kubernetes, load balancers, services applicatifs et communications inter-services.

• Les groupes de sécurité permettent :

  • L’accès aux ports.
  • Les plages d’adresses IP autorisées : IPv4 et IPv6.
  • Le contrôle du réseau entrant.
  • Le contrôle du réseau sortant.

Groupes de sécurité : compléments

• Peut être attaché à plusieurs instances.
• Verrouillé sur une combinaison région/VPC.
• Il est bon de maintenir un groupe de sécurité distinct pour l’accès SSH.
• Si votre application n’est pas accessible (expiration du délai) → problème de groupe de sécurité.
• Si votre application donne une erreur « connexion refusée » → application en erreur ou pas lancée.
• Tout le trafic entrant est bloqué par défaut.
• Tout le trafic sortant est autorisé par défaut.

Listes de contrôle d’accès réseau (NACLs)

Groupe de sécurité vs NACLs

Critère	Groupe de sécurité	NACL
Niveau	Ressource	Sous-réseau
Type	Stateful	Stateless
Trafic retour	Automatique	Règle requise
Règles d’autorisation	Oui	Oui
Règles de refus	Non	Oui
Ordre des règles	Non	Oui
Granularité	Fine	Large
Usage principal	Protection des ressources	Filtrage réseau

Private Endpoints : accès privé aux services managés

Un Private Endpoint est un point d’accès réseau privé permettant de connecter un VPC/VNet à un service managé sans exposer le trafic à Internet public. Le service est accessible via une adresse IP privée dans le réseau du client, avec un contrôle par routage, DNS privé et règles réseau.

Élément	Description
Principe	Le service reçoit une adresse privée dans le VPC/VNet
Cible	Bases de données, stockage, APIs cloud, services SaaS
Contrôle	Accès limité au réseau privé, aux DNS privés et aux règles réseau
Usage principal	Réduire l’exposition publique des services critiques

Cas d’usage :

• Accès privé à une base managée
• Stockage cloud sans endpoint public
• Connexion sécurisée entre VPC/VNet et SaaS
• Réduction des flux Internet sortants
• Segmentation réseau des services sensibles

Web application firewall

• Service de pare-feu applicatif web qui protège les applications web et API contre les requêtes malveillantes.
• Fonctionne au niveau HTTP / HTTPS.
• Peut être associé à :
  • Amazon CloudFront
  • Application Load Balancer
  • Amazon API Gateway
  • AWS AppSync
• Permet de créer des règles pour autoriser, bloquer ou surveiller le trafic.
• Propose des règles managées contre des risques courants : injections SQL, XSS, bots, abus de requêtes
• Peut limiter le trafic avec du rate limiting.
• S’intègre avec AWS Firewall Manager pour une gestion centralisée.

AWS Web Application Firewall

Hôte bastion

• Un hôte bastion est un serveur sécurisé servant de point d’entrée unique pour accéder aux ressources situées dans un réseau privé.
• Il permet d’administrer des serveurs, bases de données ou équipements réseau sans exposer directement ces ressources à Internet.
• Point d’accès centralisé : toutes les connexions d’administration transitent par le bastion.
• Accès sécurisé : authentification forte, MFA, contrôle des accès et journalisation des connexions.
• Isolation réseau : les ressources administrées restent dans des sous-réseaux privés.
• Traçabilité : enregistrement des connexions, commandes et activités d’administration.
• Réduction de la surface d’attaque : une seule ressource est exposée au lieu de multiples serveurs.
• Protocoles supportés : SSH, RDP, WinRM, bases de données et outils d’administration.
• Cas d’usage : administration d’instances EC2, serveurs Linux et Windows, accès aux environnements de production, gestion des infrastructures cloud privées.
• Solutions : AWS Bastion Host, Azure Bastion, Google Cloud Bastion Host, Teleport, Apache Guacamole, JumpServer.

Zero trust network access (ZTNA)

• Le ZTNA est un modèle de contrôle d’accès qui applique le principe « Ne jamais faire confiance, toujours vérifier ».
• Il permet d’accéder aux applications et ressources sans exposer le réseau interne ni accorder un accès global comme avec un VPN traditionnel.
• Vérification continue de l’identité : authentification forte, MFA et contrôle des appareils.
• Accès par application : l’utilisateur accède uniquement aux ressources autorisées.
• Contrôle contextuel : prise en compte de l’identité, du terminal, de la localisation et du niveau de risque.
• Moindre privilège : accès limité au strict nécessaire.
• Micro-segmentation : isolation des applications et ressources.
• Accès sans exposition réseau : les ressources restent invisibles depuis Internet.
• Journalisation et traçabilité : suivi des accès, activités et décisions de sécurité.
• Solutions : Cloudflare Access, Zscaler Private Access, Microsoft Entra Private Access, Google BeyondCorp Enterprise, Netskope Private Access, Palo Alto Prisma Access.

Réseau privé virtuel (VPN)

Zero trust network access (ZTNA) vs VPN

VPN	ZTNA
J’accède au réseau	J’accède à une application
Une authentification au départ	Vérification continue
Confiance implicite après connexion	Aucune confiance implicite
Vision réseau	Vision identité

AWS Systems Manager Session Manager

• Session Manager permet d’accéder à des instances EC2 sans ouvrir de ports SSH (22) ou RDP (3389) et sans déployer de bastion.
• Les connexions transitent par le service AWS Systems Manager via HTTPS.
• Accès sans bastion : suppression des serveurs bastion dédiés.
• Aucun port entrant : pas d’ouverture SSH ou RDP sur Internet.
• Contrôle des accès IAM : autorisations basées sur les rôles et politiques AWS.
• Journalisation : enregistrement des sessions dans CloudWatch Logs ou S3.
• Authentification forte : intégration IAM, MFA et AWS Identity Center.
• Réduction de la surface d’attaque : aucune exposition réseau directe des instances.
• Cas d’usage : administration Linux, Windows, dépannage, accès aux environnements de production, automatisation opérationnelle.
• Services associés : Systems Manager, IAM, CloudTrail, CloudWatch Logs, AWS Identity Center.

En résumé

Concept	Résumé
Bastion Host	Point d’entrée d’administration sécurisé
VPN	Tunnel chiffré vers un réseau privé
ZTNA	Accès aux applications basé sur l’identité
Session Manager	Accès aux ressources privées sans bastion

API gateway

Amazon API Gateway

Service mesh

• Service Mesh = couche réseau intelligente entre microservices (sécurité, observabilité, trafic management sans modifier le code applicatif).

Service mesh (istio/linkerd) : Zero trust entre microservices

Dimension	Istio	Linkerd	En synthèse
Positionnement	Service mesh complet et très configurable	Service mesh léger et simple à exploiter	Istio = richesse fonctionnelle / Linkerd = simplicité
Architecture	Envoy sidecar ou mode ambient	Micro-proxy sidecar léger	Istio offre plus d’options d’architecture
Sécurité	mTLS, authentification, autorisation, politiques fines	mTLS automatique et politiques d’accès simples	Les deux sécurisent les échanges inter-services
Gestion du trafic	Routage avancé, canary, retries, timeouts, circuit breaking	Traffic split, retries et timeouts plus simples	Istio est plus adapté aux scénarios complexes
Observabilité	Métriques, traces et logs via Envoy	Métriques et dashboards intégrés	Linkerd est plus rapide à prendre en main
Complexité	Plus puissant mais plus complexe à maintenir	Plus simple, plus lisible, plus léger	Le choix dépend de la maturité de l’équipe
Cas d’usage	Grandes plateformes, multi-cluster, Zero Trust avancé	Adoption progressive, mTLS rapide	Istio pour les besoins avancés, Linkerd pour démarrer

WAF vs API Gateway vs Service Mesh : Quand utiliser quoi ?

Ces 3 outils se complètent mais ne se remplacent pas. Choisir le mauvais = protection incomplète ou coût inutile.

Contexte	Décision recommandée	Pourquoi
API publique avec authentification	Passerelle API	Centralise l’authentification, le routage, la limitation de débit et les quotas
Protection contre les attaques web courantes	WAF	Filtre les attaques applicatives : injection SQL, XSS, inclusion de fichiers, règles managées et règles spécifiques
Site e-commerce / application grand public	WAF + Passerelle API	Combine protection applicative, contrôle d’accès, quotas et limitation du trafic
Robots, aspiration de contenu, DDoS applicatif	WAF + protection DDoS	Ajoute filtrage, règles anti-robots, limitation de débit et absorption du trafic malveillant
Microservices internes sans exposition publique	Maillage de services	Sécurise les échanges service à service avec mTLS, identité de workload et politiques d’accès fines
Architecture Zero Trust complète	WAF + Passerelle API + Maillage de services	Combine toutes les couches de sécurité : périmètre, accès et communication interne

Protection DDoS : AWS Shield, Azure DDoS Protection, Cloud

Armor

• DDoS : Distributed Denial of Service.
• Définition : Attaque visant à rendre un service indisponible en le submergeant de trafic parasite provenant de milliers de sources simultanées.
• Objectif : saturer la bande passante, les ressources CPU ou les connexions applicatives.
• AWS Shield Standard (gratuit) : protection L3/L4 (réseau/transport) automatique sur tous les services AWS : SYN flood, UDP reflection
• AWS Shield Advanced (3000$/mois) : protection L7 (applicatif) + SRT (Security Response Team) AWS 24/7 + protection des surcoûts liés à l’attaque.
• Azure DDoS Protection Standard : analyse du trafic baseline + mitigation automatique + rapport post-attaque + garantie SLA.
• GCP Cloud Armor : WAF + DDoS avec Adaptive Protection ML : apprend le trafic normal et détecte les anomalies. Bonnes pratiques : Définir une architecture distribuée (multi-AZ, CDN) · Rate limiting WAF · Plan de réponse DDoS documenté

Fonctionnement protection DDoS

VPC Flow Logs : Analyse et détection du trafic réseau

• VPC Flow Logs : Journal du trafic réseau cloud
• Objectif : Capture des métadonnées du trafic IP entrant et sortant de chaque interface réseau (ENI) de votre VPC. Indispensable pour l’audit, la détection d’anomalies et les investigations forensiques.
• Format des logs : version, account, interface, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action
• Détection : scans de ports (SYN sans ACK) · exfiltration (volume sortant anormal) · tentatives de connexion refusées
• Destination : CloudWatch Logs · S3 (coût réduit) · Kinesis Data Firehose (SIEM temps réel)
• Analyse : Athena (SQL sur S3) · CloudWatch Insights · Splunk · Microsoft Sentinel · OpenSearch Exemple de requête Athena : détecter tous les scans de port 22 refusés depuis Internet sur les 24 dernières heures

Prêt pour lundi

#	Action	Commande	Durée / Coût	Impact
1	Auditer tous les Security Groups avec des règles 0.0.0.0/0	aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==0.0.0.0/0]]]'	2 min / Gratuit	Chaque SG avec 0.0.0.0/0 sur port sensible = porte ouverte sur internet
2	Activer VPC Flow Logs sur tous vos VPCs	aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-xxx --traffic-type ALL --log-destination-type s3 --log-destination arn:aws:s3:::my-flowlogs	15 min / ~10€	mois / Sans Flow Logs, vous êtes aveugle sur le trafic réseau de votre VPC
3	Vérifier qu’aucune RDS/ElasticSearch n’est en subnet public	aws rds describe-db-instances --query 'DBInstances[?PubliclyAccessible==true].[DBInstanceIdentifier,Endpoint.Address]'	1 min / Gratuit	Une base de données publique = credential stuffing automatisé garanti