Notions de base de la sécurité

GUIDE DE MISE EN ROUTE

Introduction

La sécurisation de votre compte et de vos ressources cloud peut s'avérer être une tâche ardue. Les pratiques de sécurité doivent être constamment réévaluées et ajustées à mesure que les acteurs malveillants continuent de perfectionner leurs techniques. Ce guide décrit les tâches essentielles que vous pouvez effectuer dès le premier jour de votre transition vers le cloud. Les pratiques suivantes sont considérées comme essentielles à la posture de sécurité d'une organisation, mais ne sont en aucun cas définitives ni ne constituent une garantie de protection. Appliquez ces pratiques dans le cadre de votre vérification continue en matière de sécurité du cloud. Pour chacun des domaines abordés, nous fournissons des liens supplémentaires permettant d'approfondir chaque sujet.

  • Qu'est-ce que la sécurité dans le cloud ? Tout comme la sécurité traditionnelle que l'on retrouve dans les réseaux sur site, la sécurité dans le cloud implique la compilation d'une infrastructure sécurisée, performante, résiliente et efficace pour vos applications. Elle implique également la mise en œuvre de contrôles conçus pour empêcher tout accès non autorisé, ainsi que de contrôles pour détecter les problèmes, agir et les corriger au besoin. Enfin, la sécurité dans le cloud peut impliquer à la fois la sécurité du réseau et de l'infrastructure, la sécurité des hôtes et des points de terminaison, la protection et le chiffrement des données, la gestion des identités, la sécurité des applications, ainsi que la journalisation, la surveillance et la détection des menaces. Il ne s'agit pas d'un concept isolé, mais plutôt d'une pratique qui consiste à utiliser des outils et des techniques pour protéger les données, les ressources et les processus d'une organisation.

  • 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, plusieurs étapes sont recommandées pour sécuriser sa gestion et son accès.

    Utilisateur root

    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.

    Contacts de sécurité

    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.

    Contrôle régional

    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.

    Accès à la console et à la CLI AWS

    À 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.

    Groupes IAM

    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.

    Sécurité Amazon VPC

    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.

    Groupes de sécurité

    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.

    AWS Network Firewall et protection contre les DDoS

    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.

  • Lorsque vous créez des ressources dans le Cloud AWS, vous devez réfléchir aux moyens de les sécuriser en vous basant sur les bonnes pratiques actuelles. C'est particulièrement le cas si vous déployez une instance EC2, une base de données ou des ressources sans serveur. Dans cette section, nous allons voir les étapes essentielles pour sécuriser les ressources que vous créez.

    Sécurité Amazon EC2

    Lorsque vous créez des ressources dans AWS, veillez à suivre les bonnes pratiques de sécurité recommandées pour le type de ressource que vous utilisez. Pour sécuriser les instances EC2, vous devez commencer par vous pencher sur le contrôle de l'accès réseau à vos instances, par exemple en configurant votre VPC et vos groupes de sécurité. (Pour plus d'informations, consultez la section « Sécurité Amazon VPC » dans la section « Sécuriser l'infrastructure que vous compilez ».)

    Un autre aspect de la sécurité des instances est la gestion des informations d'identification utilisées pour la connexion à vos instances. Celle-ci concerne les autorisations utilisateur IAM que vous attribuez, mais s'étend au groupe attribué. Elle fournit un niveau de sécurité à l'utilisateur qui utilise l'instance EC2, mais pas à l'instance elle-même. Vous devez également configurer les rôles IAM attachés à l'instance et les autorisations associées à ces rôles. Pour accéder à une instance EC2, au lieu d'ouvrir le port SSH ou de configurer un bastion/hôte jump, vous devez utiliser EC2 Instance Connect.

    Assurez-vous que le système d'exploitation client et les logiciels déployés sur l'instance sont à jour, de même que les correctifs de sécurité. Pour plus de détails, consultez la section Sécurité dans Amazon EC2.

    Sécurité des bases de données

    La sécurisation de votre base de données est un aspect important de votre approche de sécurité. Comme indiqué dans la section sur la sécurité d'Amazon VPC, il est recommandé de déployer les bases de données sur un sous-réseau privé afin d'empêcher tout accès par des tiers via Internet. AWS propose 15 bases de données sur mesure. Chacune est sécurisée différemment, mais elles ont toutes les points communs suivants.

    Authentification

    Pour accéder à une base de données, une certaine forme d'authentification est requise. Il peut s'agir d'un nom d'utilisateur et d'un mot de passe, qui doivent être renouvelés régulièrement. Vous pouvez également utiliser le Proxy Amazon RDS pour gérer l'accès à la base de données pour vous à l'aide des rôles IAM. Certains services de base de données, comme Amazon DynamoDB, utilisent des rôles IAM pour fournir un accès. Vous n'avez donc pas besoin de gérer vous-même les informations d'identification.

    Accès SSH basé sur la console

    SSH est l'une des méthodes les plus courantes de gestion des instances EC2. Amazon EC2 Instance Connect vous permet d'utiliser SSH pour vous connecter à vos instances EC2 à l'aide de clés SSH uniques directement dans la console. Cet article explique comment activer Amazon EC2 Instance Connect et présente un cas d'utilisation type. Vous pouvez également générer des clés SSH lorsque vous créez votre instance EC2, les télécharger localement et les utiliser pour vous connecter à votre instance. Toutefois, cela signifie que vous devez protéger ces clés, vous assurer qu'elles sont stockées à un endroit auquel vous ne perdrez pas l'accès et que vous ne pouvez vous connecter à votre instance qu'à partir d'une machine sur laquelle ces clés ont été téléchargées. EC2 Instance Connect fournit le même accès SSH simple et sécurisé sur toutes les machines depuis la console.

    Autorisations minimales

    Restreindre l'accès à votre base de données uniquement aux services et à l'infrastructure qui nécessitent un accès est une bonne pratique recommandée. Vous pouvez le faire en configurant des groupes de sécurité pour vos instances RDS, vos bases de données Amazon Neptune ou vos clusters Amazon Redshift.

    Sauvegarder et tester les restaurations

    Sauvegarder vos données et effectuer des restaurations fréquentes pour vérifier que les sauvegardes fonctionnent correctement devrait être une priorité. Avec AWS Backup, vous pouvez facilement configurer et gérer les sauvegardes pour des services AWS spécifiques, notamment Amazon RDS, DynamoDB, Neptune et d'autres.

    Sécurité sans serveur

    En ce qui concerne la sécurité sans serveur, familiarisez-vous avec AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon SQS et IAM. Avec la sécurité sans serveur, AWS assume une plus grande responsabilité qu'avec le Modèle de responsabilité partagée, mais il faut savoir que le client a encore une certaine responsabilité. Dans un environnement sans serveur, AWS gère l'infrastructure, le calcul, l'environnement d'exécution et le langage d'exécution. Le client est responsable de son code et de ses bibliothèques de fonction, de la configuration des ressources et de la gestion des identités et des accès, comme illustré dans l'image suivante.
    Dans les sections suivantes, nous allons détailler les pratiques de sécurité qui relèvent de la responsabilité du client. Pour en savoir plus, consultez la section Security in AWS Lambda.
    Code et bibliothèques de fonction du client
    AWS Lambda fournit des exécutions de votre code de fonction dans un environnement basé sur Amazon Linux. Toutefois, si vous utilisez des bibliothèques supplémentaires avec votre fonction, vous êtes responsable de leur mise à jour. La mise à jour de vos bibliothèques peut vous aider à maintenir votre posture de sécurité.
    Configurer les ressources
    AWS Lambda s'intègre avec plusieurs ressources AWS telles qu'Amazon DynamoDB, Amazon EventBridge et Amazon Simple Notification Service (Amazon SNS). Suivre les pratiques de sécurité recommandées pour chaque service que vous utilisez dans le cadre de votre fonction permettra de renforcer votre posture de sécurité. La documentation de chaque service fournit des conseils supplémentaires.
    Gestion des identités et des accès
    L'exécution des fonctions Lambda peut nécessiter des autorisations et des rôles IAM spécifiques. Vous trouverez plus de détails dans la section Autorisations du Guide du développeur AWS Lambda.
    Inventaire et configuration
    Votre politique de sécurité doit également inclure la surveillance, la journalisation et la gestion de la configuration. Par exemple, de nombreuses entreprises effectuent la comptabilisation de leurs appareils à l'aide du protocole TACACS+, de RADIUS ou de journaux Active Directory. Cela leur permet de garantir la création d'une piste d'audit pour toutes les activités administratives. Dans le Cloud AWS, vous pouvez le faire avec AWS CloudTrail. Il s'agit d'un service qui permet l'audit, la surveillance de la sécurité et le dépannage opérationnel en suivant l'activité des utilisateurs et l'utilisation des API. AWS Serverless Application Repository, qui permet aux développeurs et aux entreprises de rechercher, de déployer et de publier rapidement des applications sans serveur dans le Cloud AWS, est intégré à AWS CloudTrail. Pour en savoir plus, consultez le Guide du développeur AWS Serverless Application Repository.
     
    Dans tous les cas, vous devrez fournir une protection contre les DDoS et une protection d'infrastructure à vos environnements sans serveur. Pour cela, vous pouvez utiliser AWS Shield et AWS Shield Advanced. La surveillance et la détection des menaces sont abordées plus en détail dans la section « Surveiller votre environnement ».
  • 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.

    Sécurité dans Amazon S3

    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.

    Chiffrer les données au repos

    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.

    Réseaux privés virtuels (VPN)

    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.

  • Chacun des éléments ci-dessus étant sécurisé, il est essentiel que vous surveilliez ce qui se passe dans votre environnement. Ainsi, vous pourrez identifier les menaces et les atténuer de manière proactive.

    Visibilité sur les flux de trafic

    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.

    Visibilité sur l'activité du compte

    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.

    Détecter les menaces

    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.

Cette page vous a-t-elle été utile ?