Notions de base de la sécurité

La sécurité et la conformité constituent une responsabilité partagée entre AWS et le client. En suivant ce modèle partagé, les clients peuvent réduire leur charge opérationnelle, AWS étant responsable de l'exploitation, de la gestion et du contrôle des composants « du cloud ». Ils peuvent ainsi se concentrer sur le développement de leurs applications et la mise en œuvre de leurs services, tout en assumant la responsabilité de sécuriser ces services « dans le cloud ». En savoir plus sur le modèle de responsabilité partagée.

Lorsque vous créez un compte AWS, vous commencez par ce que l'on appelle l'utilisateur root. Il s'agit du premier utilisateur AWS qui existe dans votre compte AWS. AWS vous recommande de ne pas utiliser ce compte pour les opérations quotidiennes, car il dispose d'un accès et d'un contrôle complets sur le compte, et de suivre les bonnes pratiques recommandées pour sécuriser l'utilisateur root. Cela implique de verrouiller vos clés d'accès d'utilisateur root, d'utiliser un mot de passe fort, d'activer l'authentification multifactorielle AWS et de créer un utilisateur IAM pour accéder à votre compte. Ce compte peut se voir attribuer des privilèges d'administrateur et doit être utilisé pour toutes les tâches administratives futures.

Ensuite, vous devez attribuer des contacts de sécurité alternatifs à votre compte. Ceux-ci recevront des notifications relatives à la sécurité, notamment de la part de l'équipe AWS Trust & Safety. Pour comprendre l'importance de définir ces informations de contact dès le début de la configuration de votre compte, consultez l'article de blog Update the alternate security contact across your AWS accounts for timely security notifications.

Une fois que vous avez confirmé vos contacts de sécurité, vous devez choisir les Régions AWS dans lesquelles vos charges de travail devront s'exécuter et celles dans lesquelles elles ne devront pas s'exécuter. Vous pouvez ensuite verrouiller les régions inutilisées pour vous assurer qu'aucune charge de travail ne s'exécutera à partir de ces régions. En plus d'optimiser les coûts, cela permet de renforcer la sécurité. Comment ? En verrouillant les régions dans lesquelles vous ne prévoyez pas d'exécuter de charges de travail, vous pouvez concentrer vos efforts de surveillance sur les régions que vous utilisez activement.

À ce stade, vous avez sécurisé l'utilisateur root, créé un ou plusieurs utilisateurs IAM, attribué des contacts de sécurité et verrouillé les régions dans lesquelles les charges de travail peuvent s'exécuter. Voyons maintenant comment les utilisateurs interagiront avec les ressources AWS. Il existe deux modes principaux d'interaction : l'interface de la ligne de commande AWS (AWS CLI) et la Console de gestion AWS. Il est recommandé de configurer l'authentification unique pour la CLI AWS et la console. Consultez l'article Configuring the AWS CLI to use AWS IAM Identity Center (successor to AWS Single Sign-On) pour en savoir plus sur la gestion centralisée des accès avec AWS IAM Identity Center.

L'étape suivante pour sécuriser votre compte consiste à configurer des Groupes d'utilisateurs IAM AWS afin de contrôler l'accès. Plutôt que de contrôler l'accès de chaque utilisateur en définissant des politiques directement sur l'utilisateur, il est préférable de créer un groupe, de lui attribuer les autorisations nécessaires, puis d'affecter des utilisateurs au groupe. Les utilisateurs hériteront des autorisations de ce groupe. Il s'agit d'un moyen plus évolutif de fournir un contrôle d'accès à de multiples utilisateurs. Il est important de comprendre comment fonctionnent IAM et les groupes IAM, car ils couvrent plusieurs services. IAM est un service qui interagit avec tous les services AWS à des degrés divers. Prenez donc le temps de vous familiariser avec lui.

Si vous suivez ces pratiques dès le départ, l'accès à vos ressources AWS sera plus sécurisé. Nous allons maintenant voir comment sécuriser l'infrastructure que vous compilez sur AWS.

L'infrastructure que vous compilez est souvent négligée, car elle fait partie de l'architecture sous-jacente et n'est pas en contact avec le client. Toutefois, si elle tombe en panne, les services offerts aux clients échouent. Pour cette raison, il est impératif qu'elle soit sécurisée dès le départ.

Lors de la compilation de votre infrastructure cloud, vous allez commencer par créer un Amazon Virtual Private Cloud (Amazon VPC). Il s'agit d'un réseau virtuel que vous définissez (un réseau par défaut est créé dans chaque région lorsque vous créez votre compte) et qui vous permet de lancer des ressources. Un VPC ressemble à un réseau traditionnel, car une plage d'adresses IP CIDR lui est attribuée et il est subdivisé en créant des sous-réseaux. Vos sous-réseaux peuvent être utilisés pour isoler différents ensembles de ressources. Les sous-réseaux peuvent être publics ou privés. Les sous-réseaux publics disposent d'une route vers une passerelle Internet, ont accès à Internet via cette passerelle et sont accessibles depuis Internet si les contrôles d'accès appropriés le permettent. Les sous-réseaux privés disposent également d'une table de routage, mais n'ont pas de route vers une passerelle Internet. Par défaut, ils ne peuvent donc pas accéder à Internet et ne sont pas accessibles depuis Internet. Pour permettre aux ressources d'un sous-réseau privé d'accéder à Internet, une passerelle NAT est nécessaire. Au niveau du sous-réseau, une liste de contrôle d'accès (ACL) réseau autorise ou refuse un trafic entrant ou sortant spécifique. Vous pouvez utiliser la liste ACL réseau par défaut ou créer une liste ACL réseau personnalisée pour votre VPC. Les listes ACL réseau sont des listes numérotées, traitées de haut en bas, et sont statiques. Cela signifie que vous aurez besoin d'une règle de liste ACL réseau entrant et sortant pour autoriser le trafic bidirectionnel.

Lorsque vous déployez des ressources EC2 dans votre VPC, vous leur associez un groupe de sécurité. Celui-ci contrôle le trafic entrant et sortant pouvant atteindre les ressources EC2. Les groupes de sécurité sont semblables à un pare-feu, mais au lieu d'utiliser simplement une liste ou une plage d'adresses IP, ils peuvent pointer vers ce que l'on appelle une référence de ressource. Une référence de ressource est un groupe nommé qui tient à jour la liste des adresses IP attribuées à chaque ressource du groupe. Par exemple, si vous créez un groupe de scalabilité automatique pour mettre en service des instances Amazon EC2, une nouvelle adresse IP est attribuée à chaque instance lors du démarrage. En ajoutant un groupe de sécurité à ces instances, vous pouvez autoriser l'accès au groupe de sécurité de votre serveur de base de données via l'ID du groupe de sécurité des instances EC2, et toute nouvelle instance EC2 lancée aura accès à la base de données sans que son adresse IP n'ait besoin d'être ajoutée à la liste autorisée.

Les règles des groupes de sécurité sont semblables aux listes ACL réseau, car lorsque vous les créez, vous faites correspondre le port, le protocole et les adresses, mais elles sont dynamiques. Elles sont semblables aux pare-feu dynamiques. Lorsque vous créez une entrée pour autoriser un type de trafic spécifique, vous n'avez pas besoin de créer de règle correspondant au trafic de retour ; celui-ci étant dynamique, il sera autorisé. Consultez cette comparaison pour mieux comprendre comment les groupes de sécurité et les listes ACL interagissent.

Pour ajouter une couche de sécurité à l'infrastructure, vous pouvez déployer AWS Network Firewall. Il s'agit d'un service géré qui déploie la protection de votre Amazon VPC. Celui-ci fournit une protection plus précise que les groupes de sécurité, car il peut intégrer le contexte des flux de trafic, comme le suivi des connexions et l'identification des protocoles, pour appliquer des politiques telles que l'interdiction pour vos VPC d'accéder à des domaines en utilisant un protocole non autorisé. Pour cela, des règles Suricata personnalisées sont configurées. Par exemple, vous pouvez configurer le pare-feu réseau pour qu'il vous protège contre les attaques de logiciels malveillants. Pour aller encore plus loin, vous pouvez déployer un autre service géré, AWS Shield Advanced, pour vous protéger contre les menaces DDoS.

Les clients stockent de nombreuses données dans le Cloud AWS. Celles-ci contiennent des informations essentielles au fonctionnement d'une organisation, dont les données clients, la propriété intellectuelle, les commandes directement liées au chiffre d'affaires, etc. Dans cette section, nous allons voir comment configurer les données stockées sur AWS ainsi que les données transférées sur le réseau vers et depuis AWS.

Sur AWS, les données sont stockées dans Amazon S3, qui dispose de plusieurs contrôles pour protéger les données. L'article Top 10 security best practices for securing data in Amazon S3 présente les bonnes pratiques fondamentales. Celles-ci incluent notamment le blocage des compartiments S3 publics au niveau de l'organisation, l'utilisation de politiques relatives aux compartiments pour vérifier que tous les accès accordés sont restreints et spécifiques, ainsi que le chiffrement et la protection des données.

Pour le chiffrement, AWS Key Management Service (AWS KMS) vous permet de créer et de contrôler les clés utilisées pour chiffrer ou signer numériquement vos données. Si vous souhaitez chiffrer vos données sur AWS, plusieurs options s'offrent à vous. La première consiste à utiliser le chiffrement côté serveur avec des clés de chiffrement gérées par Amazon S3 (SSE-S3). Avec cette méthode, le chiffrement est effectué après l'envoi des données à AWS à l'aide de clés gérées par AWS.

La deuxième option consiste à chiffrer les données une fois qu'elles sont dans AWS, mais au lieu d'utiliser des clés créées et gérées par AWS, vous pouvez effectuer un chiffrement côté serveur à l'aide de clés principales client (CMK) stockées dans AWS KMS (SSE-KMS).

La troisième option pour stocker des données chiffrées sur AWS consiste à utiliser le chiffrement côté client. Avec cette approche, les données sont chiffrées avant d'être transférées vers AWS.

L'image suivante montre les avantages du chiffrement côté client et du chiffrement côté serveur pour les clients.

Les VPN peuvent englober plusieurs technologies. L'idée d'un VPN est que vos données en transit conservent leur intégrité et peuvent être échangées en toute sécurité entre deux parties. AWS propose plusieurs technologies qui garantissent la sécurité de vos données en transit. L'une d'entre elles est AWS PrivateLink, qui fournit une connectivité privée et chiffrée entre les VPC, les services AWS et vos réseaux sur site. Votre trafic n'est pas exposé à l'Internet public. Ce service peut être considéré comme un réseau privé virtuel.

Cependant, dans la plupart des cas, le VPN s'articule autour de l'utilisation du chiffrage des données. Selon le contexte, vous devez fournir un chiffrement entre un client et vos ressources Cloud AWS. Cette situation nécessite un AWS client VPN. D'un autre côté, il se peut que vous transmettiez des données entre votre centre de données ou votre filiale et vos ressources AWS. Pour ce faire, vous pouvez utiliser des tunnels IPsec entre vos ressources sur site et vos VPC Amazon ou AWS Transit Gateway. Cette connectivité sécurisée est connue sous le nom de Site-to-Site VPN.

Enfin, vous pouvez également chiffrer les données en transit en gérant vos ressources cloud à l'aide de la console de gestion AWS. Bien que la connectivité avec la console ne fasse pas penser à un VPN en premier lieu, votre session utilise le chiffrement TLS (Transport Layer Security). Vos configurations restent confidentielles lorsque vous compilez votre architecture sécurisée. Le protocole TLS est également utilisé avec l'API AWS.

AWS propose plusieurs services gérés qui vous aident à surveiller votre environnement, ainsi que des options en libre-service. Par exemple, vous pouvez utiliser les journaux de flux VPC pour enregistrer et afficher les flux de trafic réseau ou bien Amazon CloudWatch pour analyser les journaux AWS WAF, voire pour créer des alarmes pour les instances EC2. Pour en savoir plus sur Amazon CloudWatch, suivez cet atelier.

Par ailleurs, AWS CloudTrail contrôle et enregistre l'activité du compte sur l'ensemble de votre infrastructure AWS afin de vous donner le contrôle sur le stockage, l'analyse et les actions correctives. Cela est essentiel pour créer une piste d'audit des activités administratives, identifier les incidents de sécurité et résoudre les problèmes opérationnels.

Enfin, Amazon GuardDuty vous permet de détecter les menaces, et même d'aller plus loin en configurant les résultats publiés pour qu'ils déclenchent des actions de correction automatique au sein de votre environnement AWS.

En vous attaquant à chacun de ces domaines opérationnels, vous serez sur la bonne voie pour mettre en place les fonctionnalités de sécurité essentielles à votre environnement cloud.