Comment lancer une instance EC2 de manière sécurisée dans un VPC personnalisé

Lancer une instance Amazon EC2 dans le VPC par défaut est rapide, mais cela offre souvent moins de contrôle qu'un environnement de production ou de préproduction. Un VPC personnalisé vous permet de choisir la plage d'adresses, de séparer les sous-réseaux publics et privés, et de décider exactement quels chemins atteignent Internet.

Ce guide présente une disposition sécurisée pratique : un sous-réseau public pour les équilibreurs de charge ou les bastions, un sous-réseau privé pour les instances d'application, des tables de routage correspondant à ces rôles, et des groupes de sécurité n'autorisant que le trafic nécessaire.

Comprendre les composants essentiels d'un VPC sécurisé

Un Cloud Privé Virtuel (VPC) est le fondement sur lequel repose tout réseau AWS sécurisé. Avant de lancer une instance, vous devez vous assurer que les composants suivants sont correctement configurés :

VPC : Le conteneur principal de votre réseau, définissant une plage d'adresses IP privées (bloc CIDR).
Sous-réseaux : Divisions au sein du VPC, catégorisées comme Publics (avec accès direct à Internet) ou Privés (isolés).
Passerelle Internet (IGW) : Nécessaire pour que les ressources des sous-réseaux publics communiquent avec Internet.
Tables de routage : Règles qui déterminent où le trafic réseau des sous-réseaux est dirigé.
Groupes de sécurité (SGs) : Pare-feu avec état qui contrôlent le trafic entrant et sortant au niveau de l'instance.

Étape 1 : Création du VPC personnalisé et des sous-réseaux

Nous commençons par créer l'enceinte réseau et la segmenter en zones fonctionnelles. Pour une configuration standard, nous recommandons au moins un sous-réseau public et un privé.

1.1 Création du VPC

Lors de la création de votre VPC, sélectionnez un bloc CIDR privé qui ne chevauche pas les réseaux sur site auxquels vous pourriez vous connecter ultérieurement (par exemple, via AWS VPN ou Direct Connect).

Exemple de CIDR VPC : 10.0.0.0/16

1.2 Création des sous-réseaux

Chaque sous-réseau se trouve dans une zone de disponibilité (AZ). Les VPC de production utilisent généralement des sous-réseaux publics et privés correspondants dans au moins deux AZ, mais cet exemple maintient une disposition réduite avec un sous-réseau public et un privé dans us-east-1a.

Sous-réseau public : 10.0.1.0/24 (Utilisé pour les bastions ou les équilibreurs de charge)
Sous-réseau privé : 10.0.2.0/24 (Utilisé pour les serveurs d'application et les bases de données)

Étape 2 : Configuration de la connectivité Internet et du routage

Les ressources dans les sous-réseaux privés ne doivent pas avoir d'accès direct à Internet. Les ressources dans le sous-réseau public doivent être correctement routées pour atteindre Internet via une passerelle Internet (IGW).

2.1 Attachement d'une passerelle Internet (IGW)

Créez une ressource IGW dans la console AWS.
Attachez cette IGW à votre VPC nouvellement créé.

2.2 Configuration des tables de routage

Les tables de routage définissent les chemins de trafic. Vous avez besoin d'au moins deux tables : une pour le sous-réseau public et une pour le sous-réseau privé.

Table de routage publique

Cette table dirige tout le trafic non local (0.0.0.0/0) vers la passerelle Internet attachée.

Destination	Cible
`10.0.0.0/16` (CIDR VPC)	`local`
`0.0.0.0/0`	`igw-xxxxxxxx` (Votre ID IGW)

Associez cette table de routage à votre sous-réseau public (10.0.1.0/24).

Table de routage privée

Cette table autorise uniquement la communication interne. Crucialement, elle ne doit avoir aucune route pointant vers l'IGW.

Destination	Cible
`10.0.0.0/16` (CIDR VPC)	`local`

Associez cette table de routage à votre sous-réseau privé (10.0.2.0/24).

Meilleure pratique : Si les ressources du sous-réseau privé doivent télécharger des correctifs ou des mises à jour, vous devez utiliser une passerelle NAT placée dans le sous-réseau public. La table de routage privée dirigerait alors le trafic 0.0.0.0/0 vers la passerelle NAT au lieu de l'IGW.

Étape 3 : Définition de règles strictes de groupe de sécurité

Les groupes de sécurité (SGs) agissent comme des pare-feu virtuels pour vos instances EC2. Ils fonctionnent au niveau de l'instance et sont avec état (le trafic de retour est automatiquement autorisé).

Pour une configuration sécurisée, vous devez adhérer au principe du moindre privilège, en n'autorisant explicitement que le trafic entrant nécessaire.

Exemple de groupe de sécurité pour un serveur Web (sous-réseau privé)

Si cette instance EC2 est un serveur d'application accessible uniquement depuis un équilibreur de charge d'application (ALB) résidant dans le sous-réseau public, les règles doivent être très restrictives :

Règles entrantes

Type	Protocole	Plage de ports	Source
HTTP	TCP	80	ID SG de l'ALB
HTTPS	TCP	443	ID SG de l'ALB
SSH	TCP	22	Plage IP de votre réseau d'entreprise ou ID SG du bastion

Règles sortantes

Par défaut, le trafic sortant est généralement autorisé vers toutes les destinations (0.0.0.0/0). Vous pouvez restreindre davantage si nécessaire (par exemple, n'autoriser que les connexions vers un SG d'instance RDS).

Conseil de sécurité : N'attribuez jamais 0.0.0.0/0 au port 22 (SSH) ou au port 3389 (RDP) sur un groupe de sécurité exposé publiquement. Limitez toujours l'accès de gestion à des plages IP internes connues.

Étape 4 : Lancement sécurisé de l'instance EC2

Lors du lancement de votre instance, assurez-vous de la mapper aux composants réseau corrects établis ci-dessus.

Choisir AMI et type d'instance : Sélectionnez votre Amazon Machine Image (AMI) et les spécifications matérielles souhaitées.
Paramètres réseau : Dans l'étape 'Configurer les détails de l'instance' :
- Réseau : Sélectionnez votre VPC personnalisé.
- Sous-réseau : Sélectionnez le sous-réseau privé (10.0.2.0/24) si vous lancez un serveur d'application qui ne doit pas être directement exposé à Internet.
- Attribuer automatiquement une IP publique : Assurez-vous que cette option est désactivée si vous lancez dans un sous-réseau privé. (Si vous sélectionnez un sous-réseau public, vous pouvez l'activer pour une instance nécessitant un accès public direct, comme un bastion).
- Groupes de sécurité : Sélectionnez le groupe de sécurité configuré à l'étape 3.
Stockage et paire de clés : Configurez le stockage et associez une paire de clés pour un accès SSH sécurisé.

Accès aux instances dans un sous-réseau privé

Étant donné que l'instance résidant dans le sous-réseau privé n'a pas d'adresse IP publique, vous ne pouvez pas vous connecter directement en SSH depuis Internet public. Vous devez utiliser l'une des deux méthodes sécurisées :

Bastion (Jump Box) : Lancez une petite instance EC2 durcie dans le sous-réseau public. Vous vous connectez d'abord en SSH au bastion, puis ensuite depuis le bastion, vous vous connectez en SSH à l'instance privée en utilisant son adresse IP privée.
AWS Systems Manager (SSM) Session Manager : C'est la méthode moderne préférée. Si l'instance a l'agent SSM installé et un rôle IAM approprié attaché autorisant la connectivité SSM, vous pouvez initier une session shell sécurisée directement depuis la console AWS sans avoir besoin de règles SSH entrantes ni de bastions.

Résumé et prochaines étapes

Sécuriser une instance EC2 dans un VPC personnalisé implique de superposer la sécurité réseau du niveau macro (VPC, sous-réseaux, tables de routage) au niveau micro (groupes de sécurité). En contrôlant soigneusement l'adressage IP et le flux de trafic :

Vous garantissez que les serveurs d'application résident dans des sous-réseaux privés isolés.
Vous utilisez l'IGW ou la passerelle NAT uniquement là où c'est nécessaire.
Vous appliquez le principe du moindre privilège via les règles d'entrée des groupes de sécurité.

Une fois votre instance lancée, n'oubliez pas de surveiller son activité à l'aide d'AWS CloudTrail et des VPC Flow Logs pour maintenir une visibilité continue sur votre trafic réseau privé.