Bases du réseau cloud

Faire voyager une requête depuis internet jusqu'à une base de données privée, en sécurité

2 leçons plus tôt, une base de données e-commerce vivait bien au chaud dans une base relationnelle, stockant des commandes qui devaient rester cohérentes avec des clients réels et un inventaire réel. Cette base ne sert à rien si le navigateur d'un acheteur ne peut pas l'atteindre, et devient dangereuse si n'importe qui sur internet peut l'atteindre directement. Le réseau cloud est la couche qui résout cette tension : elle fait voyager une requête depuis le navigateur d'un utilisateur jusqu'au bon serveur applicatif et à la bonne base de données, tout en gardant la base elle-même totalement injoignable depuis l'extérieur. Cette leçon construit ce chemin morceau par morceau.

Le VPC : votre propre réseau privé, virtualisé

Un réseau privé virtuel (VPC) est un réseau virtuel logiquement isolé, dédié à votre compte. Vous choisissez une plage d'adresses IP pour lui, puis vous ajoutez sous-réseaux, passerelles et contrôles de sécurité, les mêmes briques que vous configureriez dans un réseau de centre de données physique, sauf qu'il n'y a ni câblage ni matériel à installer en baie. Chaque ressource que vous lancez, une machine virtuelle, une instance de base de données, vit à l'intérieur d'un VPC, ce qui donne son sens à la brique suivante : les sous-réseaux.

Sous-réseaux : public contre privé

Un sous-réseau est une plage d'adresses IP à l'intérieur d'un VPC, et, chez AWS, un sous-réseau vit entièrement dans 1 seule zone de disponibilité, le même concept de zone vu plus tôt dans ce sujet, maintenant appliqué au réseau. Ce qui rend un sous-réseau public ou privé, ce n'est pas son nom mais sa table de routage : un sous-réseau public a une route vers une passerelle internet, ses ressources peuvent donc être jointes depuis internet et l'atteindre ; un sous-réseau privé n'a aucune route de ce type, rien à l'extérieur du VPC ne peut donc le joindre directement.

C'est exactement la forme de l'architecture de référence RDS : les serveurs applicatifs vivent dans des sous-réseaux publics répartis sur 2 zones de disponibilité, joignables par les utilisateurs, et les instances de base de données vivent dans des sous-réseaux privés dans ces mêmes 2 zones, joignables seulement par les serveurs applicatifs à l'intérieur du VPC, jamais directement depuis internet. Une ressource dans un sous-réseau privé n'est pas coupée du monde pour autant : elle peut toujours joindre internet en sortie, pour télécharger une mise à jour logicielle par exemple, via une passerelle NAT séparée, mais rien à l'extérieur ne peut initier une connexion entrante.

Security groups et network ACL : 2 serrures différentes sur 2 portes différentes

Bien placer les choses n'est que la moitié du travail. L'autre moitié consiste à décider exactement quel trafic chaque élément a le droit de voir, et AWS vous donne 2 outils différents pour cela, à 2 portées différentes.

Un security group est un pare-feu virtuel attaché à une instance précise, comme un videur posté devant une porte unique qui se souvient de tous ceux qu'il a laissés entrer : une fois qu'il autorise une requête sortante, il laisse automatiquement passer la réponse correspondante sans revérifier sa liste. Cette mémoire, c'est ce que "stateful" veut dire. Un security group ne prend en charge que des règles d'autorisation, et il vérifie toutes ses règles avant de décider, puisqu'il n'y a rien à refuser, seulement une permission à accorder ou non.

Un network ACL travaille plutôt au niveau du sous-réseau, davantage comme l'accueil d'un bâtiment qui vérifie chaque personne franchissant le seuil, dans les 2 sens, contre une liste écrite, sans mémoire de qui il a laissé passer 5 minutes plus tôt. C'est ce que "stateless" veut dire : un network ACL prend en charge à la fois l'autorisation et le refus, et il s'arrête à la première règle qui correspond, vérifiée dans l'ordre, plutôt que de passer en revue toutes les règles comme le fait un security group.

Les recommandations d'AWS conseillent d'utiliser les security groups comme contrôle d'accès principal et d'ajouter les network ACL comme couche secondaire, plus grossière, par-dessus. La raison est simple : un network ACL protège tout le sous-réseau, elle continue donc de servir de filet de sécurité même dans le cas rare où une instance serait lancée sans le bon security group attaché. 2 couches qui peuvent échouer de façons différentes vous protègent mieux qu'1 seule couche qui devrait être parfaite en permanence.

Le répartiteur de charge : distribuer le trafic entre cibles en bonne santé

Rappelez-vous la mise à l'échelle horizontale de la leçon sur le calcul : ajouter davantage d'instances de la même taille plutôt que de redimensionner l'existante. Répartir la charge entre 4 serveurs applicatifs identiques ne fonctionne que si quelque chose décide lequel des 4 traite chaque requête entrante, et ce quelque chose, c'est un répartiteur de charge. Un répartiteur de charge se place devant un groupe de cibles, vérifie l'état de santé de chacune, et ne route le trafic que vers celles qui passent actuellement ces vérifications, en contournant automatiquement une instance qui a cessé de répondre.

Le chemin complet, assemblé

Assemblez chaque brique de cette leçon et le chemin qu'une requête emprunte réellement ressemble à ceci : la requête d'un utilisateur entre dans le VPC par une passerelle internet, atteint un répartiteur de charge, qui la route vers l'un de plusieurs serveurs applicatifs en bonne santé situés dans un sous-réseau public, protégé par le security group de cette instance. Le serveur applicatif se tourne ensuite vers un sous-réseau privé pour lire ou écrire la base de données, une connexion autorisée uniquement parce que les 2 côtés vivent à l'intérieur du même VPC, jamais parce que la base est joignable depuis internet. Un network ACL surveille chaque frontière de sous-réseau tout au long du chemin, comme le filet de sécurité grossier derrière chaque security group.

Où cela vous mène

Le réseau n'est pas un simple réglage, c'est un empilement de décisions : le sous-réseau où vit une ressource décide si internet peut l'atteindre, les security groups décident exactement quel trafic atteint une instance précise, les network ACL renforcent cela au niveau du sous-réseau, et un répartiteur de charge décide laquelle de plusieurs instances en bonne santé répond réellement à une requête donnée. Chaque service couvert dans ce sujet, calcul, stockage, bases de données, vit quelque part à l'intérieur de ce réseau, et rien de tout cela n'est joignable, ni protégé, sans lui. Le prochain sujet de ce domaine, Architectures cloud modernes, s'appuie sur chacune de ces briques pour couvrir les modèles que les équipes déploient réellement aujourd'hui : calcul serverless, conteneurs et microservices, et infrastructure as code.