En début de carrière, un ingénieur DevOps doit maîtriser de nombreux concepts. Certains sont propres à un fournisseur cloud ou de services donné ; d’autres, comme l’objet de cet article, s’appliquent à l’ensemble du secteur.

Dans cet article, nous nous intéresserons aux clouds privés virtuels (VPC), à leur mode de fonctionnement et à leur caractère incontournable dans les infrastructures cloud actuelles.

Présentation des VPC

Qu’est-ce qu’un VPC ? Imaginez la scène d’un film se déroulant dans la chambre forte d’une banque, cette grande pièce sécurisée dont les murs accueillent de nombreux coffres.

Un VPC est un compartiment indépendant au sein du cloud public d’un fournisseur donné, à l’image d’un coffre dans la chambre forte de la banque. La chambre forte est ouverte au public. De nombreux clients de la banque y ont régulièrement accès. Ils peuvent même détenir un coffre dans la même chambre forte que vous. En revanche, personne d’autre que vous ne peut accéder à votre coffre. Vous seul disposez de la clé pour l’ouvrir. Personne ne peut y avoir accès sans votre accord.

Dans le cas d’un VPC, le fournisseur — AWS, Google Cloud ou Azure — charge une horde d’ingénieurs de la gestion des coffres, ces derniers étant séparés par des fonctionnalités logiques.

Sur AWS et GCP, le VPC conserve son appellation ; en revanche, sur Azure, on parlera de VNet (Azure Virtual Network, réseau virtuel Azure). Leurs fonctionnalités et mesures de sécurité sont similaires.

Fonctionnalités et isolation

Un VPC vous permet de déployer des services et des offres du cloud public en contrôlant étroitement les accès. Il peut couvrir plusieurs régions et leurs zones de disponibilité, ce qui vous permet de déployer l’infrastructure au plus près de vos clients ou d’offrir une protection contre une défaillance au niveau d’un seul emplacement.

L’isolation est la fonctionnalité la plus importante. Vos données sont séparées de celles des autres clients. Tout ce que vous décidez d’isoler est inaccessible de l’extérieur. L’accès aux ressources déployées peut être facilement réservé aux personnes que vous aurez désignées.

Les mécanismes d’isolation les plus utilisés sont les sous-réseaux publics/privés, les groupes de sécurité et les listes de contrôle des accès, dont nous parlerons plus loin.

Avantages

Pourquoi choisir un  VPC plutôt que le cloud public ? Le fait de disposer d’une entité indépendante régie par vos propres règles tout en faisant partie d’une entité plus large protégée par le fournisseur cloud de votre choix présente de nombreux avantages.

Comme toujours, la sécurité est la priorité. Vous avez accès à autant de solutions qu’avec un cloud public traditionnel, mais vous bénéficiez d’une plus grande flexibilité. Les outils d’observabilité, le contrôle granulaire des accès et la multitude de protections et mécanismes intégrés au concept lui-même contribuent largement à la sécurité et à la confidentialité de votre infrastructure et de vos données.

Les VPC sont également beaucoup moins chers qu’un cloud privé traditionnel et vous offrent de nombreuses fonctionnalités autrement payantes.

Les ressources pouvant être déployées à l’intérieur d’un VPC sont celles généralement proposées par un cloud public. Comme avec les clouds publics, vous pouvez monter en charge facilement et de façon économique.

Configuration – Listes de contrôle des accès réseau, groupes de sécurité et sous-réseaux

Il vous revient de configurer l’accès à votre VPC et de préserver l’isolation des données. Il est important d’exécuter avec soin ces opérations critiques. Les mécanismes ci-après peuvent vous y aider.

Sous-réseaux

Les sous-réseaux constituent le moyen le plus classique de séparer des objets réseau. Si vous avez déjà configuré un routeur à votre domicile, ou travaillé avec des réseaux, vous savez en quoi ils consistent. Concrètement, il s’agit d’un bloc d’adresses IP que vous pouvez affecter à vos ressources et qui proviennent du principal pool réseau de votre VPC.

Les sous-réseaux peuvent être privés ou publics. Un sous-réseau privé n’a pas accès à Internet, sauf si vous provisionnez un terminal NAT pour faire office de « traducteur ».

Un sous-réseau public peut accéder au Web, en général avec l’aide d’une passerelle Internet faisant office de porte d’entrée/de sortie. La passerelle fournit une adresse IP accessible de l’extérieur, à laquelle vous pouvez vous connecter.

Sous-réseau public accessible depuis le Web et sous-réseau privé inaccessible de l’extérieur

Listes de contrôle des accès réseau

Une liste de contrôle des accès réseau constitue une partie supplémentaire de la logique d’un sous-réseau. Il s’agit d’une sorte de registre de règles ordonnées indiquant le type de trafic pouvant entrer et sortir, les ports utilisables et même la provenance et la destination. En voici un exemple :

Scénario typique de listes de contrôle des accès réseau en pratique. La requête de gauche aboutira. La requête de droite expirera.

L’ordre de ces règles doit être soigneusement surveillé. Les règles sont traitées par ordre croissant de numéro. Si une correspondance est trouvée, elle est appliquée quelles que soient les dispositions de la règle ayant un numéro plus élevé. Cette opération peut être facilement négligée. Or, la moindre erreur peut entraîner une fuite de données.

Groupes de sécurité

Les groupes de sécurité utilisent une approche différente. Au lieu de contrôler certains sous-réseaux, ils agissent sur les ressources, telles que les instances. Contrairement aux listes de contrôle des accès réseau, vous ne pouvez pas explicitement créer de règle de « refus ». Les groupes de sécurité considèrent par défaut que tout ce qui n’est pas défini comme autorisé est interdit. Vous n’avez pas non plus besoin d’autoriser explicitement le trafic sortant : s’il existe un flux entrant, la sortie de la réponse est autorisée.

L’ordre des règles spécifié pour un groupe de sécurité n’a pas non plus d’importance ; l’ensemble des règles sont évaluées à l’arrivée du trafic. Vous pouvez relier plusieurs groupes de sécurité à une ressource et (du moins avec AWS) si vous ne le faites pas, la ressource par défaut sera automatiquement rattachée.

Exemple de règles de groupes de sécurité contrôlant l’accès à un ensemble de ressources

Heureusement, la question du choix de la méthode de contrôle des accès ne se pose pas. Vous devez toutes les utiliser. En général, la bonne pratique consiste à placer autant de couches que possible entre vous et l’espace sombre et froid du Web.

Les VPC en pratique : 4 points clés

Voici quatre conseils pour tirer le meilleur parti de votre VPC sans vous compliquer la vie.

1. AWS propose un VPC par défaut au terme de la configuration de votre compte. Bien qu’il soit techniquement prêt à l’emploi, passez en revue les paramètres de sécurité mentionnés précédemment et vérifiez qu’ils sont adaptés à vos besoins afin d’éviter toute mauvaise surprise. Avertissement pour les opérateurs Terraform : la ressource VPC par défaut est fondamentalement différente d’une ressource courante !
2. Le provisionnement d’un VPC est une opération très simple. En revanche, la gestion des groupes de sécurité et des listes de contrôle des accès réseau gagne en complexité à mesure de l’augmentation du nombre de règles. Attention à ne pas vous laisser submerger par un nombre incalculable de règles illisibles et à ne pas oublier de combler une faille qui pourrait être à l’origine d’une attaque furtive.
3. Si vous utilisez des groupes de sécurité et des listes de contrôle des accès réseau pour contrôler l’accès à vos environnements pour vos collègues, veillez à ce que les adresses mises en liste blanche soient statiques ou mises à jour très fréquemment. Sinon, une adresse autorisée finira par tomber entre les mains d’un cybercriminel qui ne se fera pas prier pour mettre son nez partout. Pour éviter cette situation, plusieurs moyens sont à votre disposition : vous pouvez utiliser un VPN privé contrôlé par l’entreprise (un VPN public classique présente les mêmes risques de réaffectation d’adresse IP !) ou des outils comme HashiCorp Boundary.
4. Le nombre de VPC que vous pouvez provisionner sur presque tous les clouds publics est limité. Si vous souhaitez fournir à vos clients leurs propres espaces tenant, d’autres solutions (identités IAM, comptes utilisateur supplémentaires, etc.) constituent une meilleure alternative, sauf si c’est à très petite échelle.