Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

La sécurité à la périphérie

Dans le AWS Cloud, la sécurité est la priorité absolue. À mesure que les entreprises adoptent l'évolutivité et la flexibilité du cloud, AWS cela les aide à faire de la sécurité, de l'identité et de la conformité des facteurs commerciaux clés. AWS intègre la sécurité dans son infrastructure de base et propose des services pour vous aider à répondre à vos exigences uniques en matière de sécurité dans le cloud. Lorsque vous étendez la portée de votre architecture dans le AWS Cloud, vous bénéficiez de l'intégration d'infrastructures telles que les Zones Locales et les Outposts dans. Régions AWS Cette intégration permet d' AWS étendre un groupe sélectionné de services de sécurité de base jusqu'à la périphérie.

La sécurité est une responsabilité partagée entre vous AWS et vous. Le modèle de responsabilitéAWS partagée fait la différence entre la sécurité du cloud et la sécurité dans le cloud :

Protection des données

Le modèle de responsabilité AWS partagée s'applique à la protection des données dans AWS Outposts et Zones locales AWS. Comme décrit dans ce modèle, AWS est responsable de la protection de l'infrastructure globale qui gère AWS Cloud (sécurité du cloud). Vous êtes responsable du contrôle de votre contenu hébergé sur cette infrastructure (sécurité dans le cloud). Ce contenu inclut la configuration de la sécurité et les tâches de gestion pour le Services AWS produit que vous utilisez.

À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS Identity and Access Management (IAM) ou AWS IAM Identity Center. Cela donne à chaque utilisateur uniquement les autorisations nécessaires pour accomplir ses tâches.

Chiffrement au repos

Chiffrement dans les volumes EBS

Avec AWS Outposts, toutes les données sont cryptées au repos. Le matériau clé est enveloppé d'une clé externe, la clé de sécurité Nitro (NSK), qui est stockée dans un appareil amovible. Le NSK est nécessaire pour déchiffrer les données de votre rack Outpost. Vous pouvez utiliser le chiffrement Amazon EBS pour vos volumes et instantanés EBS. Le chiffrement Amazon EBS utilise AWS Key Management Service (AWS KMS) et des clés KMS.

Dans le cas des zones locales, tous les volumes EBS sont chiffrés par défaut dans toutes les zones locales, à l'exception de la liste décrite dans la Zones locales AWS FAQ (voir la question : Quel est le comportement de chiffrement par défaut des volumes EBS dans les zones locales ? ), sauf si le chiffrement est activé pour le compte.

Chiffrement dans Amazon S3 sur Outposts

Par défaut, toutes les données stockées dans Amazon S3 sur Outposts sont chiffrées à l’aide du chiffrement côté serveur avec les clés de chiffrement gérées Amazon S3 (SSE-S3). Vous pouvez éventuellement utiliser le chiffrement côté serveur avec les clés de chiffrement fournies par le client (SSE-C). Pour utiliser SSE-C, spécifiez une clé de chiffrement dans le cadre de vos demandes d’API sur les objets. Un chiffrement côté serveur chiffre uniquement les données d’objet, pas les métadonnées d’objet.

Chiffrement en transit

En AWS Outposts effet, le lien de service est une connexion nécessaire entre votre serveur Outposts et la région de votre choix Région AWS (ou de votre région d'origine) et permet la gestion de l'Outpost et l'échange de trafic vers et depuis le. Région AWS Le lien de service utilise un VPN AWS géré pour communiquer avec la région d'origine. Chaque hôte interne AWS Outposts crée un ensemble de tunnels VPN pour diviser le trafic du plan de contrôle et le trafic VPC. En fonction de la connectivité du lien de service (Internet ou AWS Direct Connect) AWS Outposts, ces tunnels nécessitent l'ouverture de ports de pare-feu pour que le lien de service puisse créer une superposition au-dessus de celui-ci. Pour obtenir des informations techniques détaillées sur la sécurité AWS Outposts et le lien de service, voir Connectivité via le lien de service et Sécurité de l'infrastructure AWS Outposts dans la AWS Outposts documentation.

Le lien AWS Outposts de service crée des tunnels chiffrés qui établissent la connectivité du plan de contrôle et du plan de données avec le parent Région AWS, comme illustré dans le schéma suivant.

Chaque AWS Outposts hôte (calcul et stockage) a besoin de ces tunnels chiffrés via des ports TCP et UDP connus pour communiquer avec sa région mère. Le tableau suivant indique les ports et adresses source et de destination pour les protocoles UDP et TCP.

Les zones Locales sont également connectées à la région mère via le backbone privé mondial redondant et à très haut débit d'Amazon. Cette connexion permet aux applications qui s'exécutent dans les Zones Locales d'accéder rapidement, de manière sécurisée et fluide aux autres Services AWS. Tant que les Zones Locales font partie de l'infrastructure AWS mondiale, toutes les données circulant sur le réseau AWS mondial sont automatiquement cryptées au niveau de la couche physique avant de quitter les installations AWS sécurisées. Si vous avez des exigences spécifiques pour chiffrer les données en transit entre vos sites locaux et AWS Direct Connect PoPs pour accéder à une zone locale, vous pouvez activer la sécurité MAC (MACsec) entre votre routeur ou commutateur local et le point de terminaison. AWS Direct Connect Pour plus d'informations, consultez le billet de AWS blog Ajouter MACsec de la sécurité aux AWS Direct Connect connexions.

Suppression de données

Lorsque vous arrêtez ou mettez fin à une EC2 instance AWS Outposts, la mémoire qui lui est allouée est nettoyée (mise à zéro) par l'hyperviseur avant d'être allouée à une nouvelle instance, et chaque bloc de stockage est réinitialisé. La suppression de données du matériel Outpost implique l'utilisation de matériel spécialisé. Le NSK est un petit appareil, illustré sur la photo suivante, qui se fixe à l'avant de chaque ordinateur ou unité de stockage d'un avant-poste. Il est conçu pour fournir un mécanisme permettant d'empêcher l'exposition de vos données depuis votre centre de données ou votre site de colocation. Les données de l'appareil Outpost sont protégées en enveloppant le matériel de saisie utilisé pour chiffrer l'appareil et en stockant le matériel emballé sur le NSK. Lorsque vous renvoyez un hôte d'Outpost, vous détruisez le NSK en tournant une petite vis sur le jeton qui écrase le NSK et détruit physiquement le jeton. La destruction du NSK détruit les données de votre avant-poste de manière cryptographique.

Identity and Access Management

AWS Identity and Access Management (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Les administrateurs IAM contrôlent qui peut être authentifié (connecté) et autorisé (autorisé) à utiliser AWS Outposts les ressources. Si vous en avez un Compte AWS, vous pouvez utiliser IAM sans frais supplémentaires.

Le tableau suivant répertorie les fonctionnalités IAM que vous pouvez utiliser avec AWS Outposts.

* Outre les politiques basées sur l'identité IAM, Amazon S3 on Outposts prend en charge les politiques relatives aux compartiments et aux points d'accès. Il s'agit de politiques basées sur les ressources associées à la ressource Amazon S3 on Outposts.

Pour plus d'informations sur la prise en charge de ces fonctionnalités AWS Outposts, consultez le guide de AWS Outposts l'utilisateur.

Sécurité de l'infrastructure

La protection de l’infrastructure est un aspect essentiel du programme de sécurité des informations. Il garantit que les systèmes et services de charge de travail sont protégés contre les accès involontaires et non autorisés, ainsi que contre les vulnérabilités potentielles. Par exemple, vous définissez les limites de confiance (par exemple, les limites du réseau et des comptes), la configuration et la maintenance de la sécurité du système (par exemple, renforcement, minimisation et application de correctifs), l'authentification et les autorisations du système d'exploitation (par exemple, les utilisateurs, les clés et les niveaux d'accès) et les autres points d'application des politiques appropriés (par exemple, les pare-feux d'applications Web ou les passerelles d'API).

AWS propose un certain nombre d'approches en matière de protection de l'infrastructure, comme indiqué dans les sections suivantes.

Protection des réseaux

Vos utilisateurs peuvent faire partie de votre personnel ou de vos clients, et peuvent être situés n'importe où. Pour cette raison, vous ne pouvez pas faire confiance à tous ceux qui ont accès à votre réseau. Lorsque vous appliquez le principe de sécurité à tous les niveaux, vous adoptez une approche zéro confiance. Dans le modèle de sécurité Zero Trust, les composants d'application ou les microservices sont considérés comme discrets, et aucun composant ou microservice ne fait confiance à aucun autre composant ou microservice. Pour atteindre une sécurité zéro confiance, suivez les recommandations suivantes :

Protection des ressources informatiques

Les ressources informatiques incluent les EC2 instances, les conteneurs, AWS Lambda les fonctions, les services de base de données, les appareils IoT, etc. Chaque type de ressource de calcul nécessite une approche différente en matière de sécurité. Cependant, ces ressources partagent des stratégies communes que vous devez prendre en compte : défense en profondeur, gestion des vulnérabilités, réduction de la surface d'attaque, automatisation de la configuration et du fonctionnement, et réalisation d'actions à distance.

Voici des conseils généraux pour protéger vos ressources informatiques pour les services clés :

En outre, pour chacune des Service AWS applications que vous utilisez, consultez les recommandations de sécurité spécifiques dans la documentation du service.

Accès Internet

Les deux, AWS Outposts ainsi que les Zones Locales, fournissent des modèles architecturaux qui permettent à vos charges de travail d'accéder à Internet et à partir de celui-ci. Lorsque vous utilisez ces modèles, considérez la consommation Internet depuis la région comme une option viable uniquement si vous l'utilisez pour appliquer des correctifs, mettre à jour, accéder à des référentiels Git externes à Git AWS, etc. Pour ce modèle architectural, les concepts d'inspection entrante centralisée et de sortie Internet centralisée s'appliquent. Ces modèles d'accès utilisent des passerelles NAT AWS Transit Gateway, des pare-feux réseau et d'autres composants résidant dans des zones locales Régions AWS, mais y étant AWS Outposts connectés, via le chemin de données entre la région et la périphérie.

Local Zones adopte une structure de réseau appelée groupe de frontières de réseau, qui est utilisée dans Régions AWS. AWS annonce les adresses IP publiques de ces groupes uniques. Un groupe frontalier du réseau est composé de zones de disponibilité, de zones locales ou de zones de longueur d'onde. Vous pouvez attribuer explicitement un pool d'adresses IP publiques à utiliser dans un groupe frontalier du réseau. Vous pouvez utiliser un groupe de bordure réseau pour étendre la passerelle Internet aux Zones Locales en autorisant le service d'adresses IP Elastic à partir du groupe. Cette option nécessite le déploiement d'autres composants pour compléter les services de base disponibles dans les Zones Locales. Ces composants peuvent provenir de votre zone locale ISVs et vous aider à créer des couches d'inspection, comme décrit dans le billet de AWS blog Architectures d'inspection hybrides avec Zones locales AWS.

Dans AWS Outposts, si vous souhaitez utiliser la passerelle locale (LGW) pour accéder à Internet depuis votre réseau, vous devez modifier la table de routage personnalisée associée au AWS Outposts sous-réseau. La table de routage doit avoir une entrée de route par défaut (0.0.0.0/0) qui utilise le LGW comme prochain saut. Vous êtes responsable de la mise en œuvre des contrôles de sécurité restants dans votre réseau local, y compris les défenses périmétriques telles que les pare-feux et les systèmes de prévention des intrusions ou les systèmes de détection des intrusions (IPS/IDS). Cela correspond au modèle de responsabilité partagée, qui répartit les tâches de sécurité entre vous et le fournisseur de cloud.

Accès à Internet par l'intermédiaire du parent Région AWS

Dans cette option, les charges de travail de l'Outpost accèdent à Internet via le lien de service et la passerelle Internet du parent. Région AWS Le trafic sortant vers Internet peut être acheminé via la passerelle NAT instanciée dans votre VPC. Pour renforcer la sécurité de votre trafic entrant et sortant, vous pouvez utiliser des services AWS de sécurité tels que AWS WAF, AWS Shield, et Amazon CloudFront dans le. Région AWS

Le schéma suivant montre le trafic entre la charge de travail de l' AWS Outposts instance et Internet passant par le parent Région AWS.

Accès à Internet via le réseau de votre centre de données local

Dans cette option, les charges de travail de l'Outpost accèdent à Internet via votre centre de données local. Le trafic de charge de travail qui accède à Internet passe par votre point de présence Internet local et sort localement. Dans ce cas, l'infrastructure de sécurité réseau de votre centre de données local est chargée de sécuriser le trafic de AWS Outposts charge de travail.

L'image suivante montre le trafic entre une charge de travail du AWS Outposts sous-réseau et Internet passant par un centre de données.

Gouvernance de l'infrastructure

Que vos charges de travail soient déployées dans une zone locale ou un Région AWS avant-poste, vous pouvez les utiliser AWS Control Tower pour la gouvernance de l'infrastructure. AWS Control Tower propose un moyen simple de configurer et de gérer un environnement AWS multi-comptes, en suivant les meilleures pratiques prescriptives. AWS Control Tower orchestre les capacités de plusieurs autres Services AWS, notamment AWS Organizations AWS Service Catalog, et IAM Identity Center (voir tous les services intégrés) pour créer une zone d'atterrissage en moins d'une heure. Les ressources sont configurées et gérées en votre nom.

AWS Control Tower fournit une gouvernance unifiée dans tous les AWS environnements, y compris les régions, les zones locales (extensions à faible latence) et les Outposts (infrastructure sur site). Cela permet de garantir une sécurité et une conformité cohérentes sur l'ensemble de votre architecture de cloud hybride. Pour plus d’informations, consultez la documentation AWS Control Tower.

Vous pouvez configurer AWS Control Tower des fonctionnalités telles que des garde-corps pour vous conformer aux exigences en matière de résidence des données dans les gouvernements et les secteurs réglementés tels que les institutions de services financiers ()FSIs. Pour comprendre comment déployer des barrières de sécurité pour la résidence des données à la périphérie, consultez ce qui suit :

Partage des ressources des Outposts

Comme un avant-poste est une infrastructure limitée installée dans votre centre de données ou dans un espace de colocation, pour une gouvernance centralisée AWS Outposts, vous devez contrôler de manière centralisée les comptes avec lesquels les AWS Outposts ressources sont partagées.

Grâce au partage d'Outpost, les propriétaires d'Outposts peuvent partager leurs Outposts et leurs ressources, y compris leurs sites et sous-réseaux, avec d'autres Comptes AWS utilisateurs de la même organisation dans. AWS Organizations En tant que propriétaire d'Outpost, vous pouvez créer et gérer les ressources d'Outpost à partir d'un emplacement central, et partager les ressources entre plusieurs personnes Comptes AWS au sein de votre AWS organisation. Cela permet aux autres consommateurs d'utiliser les sites Outpost, de configurer VPCs, de lancer et d'exécuter des instances sur l'Outpost partagé.

Les ressources partageables AWS Outposts sont les suivantes :

Pour suivre les meilleures pratiques en matière de partage des ressources d'Outposts dans un environnement multi-comptes, consultez les articles de blog suivants : AWS