Les composants du Système Nitro
Comme indiqué précédemment, le Système Nitro est constitué de trois composants principaux :
-
Les Cartes Nitro
-
La Puce de Sécurité Nitro
-
L'Hyperviseur Nitro
Les Cartes Nitro
Un serveur EC2 moderne est composé d'une carte système principale et d'une ou de plusieurs Cartes Nitro. La carte principale, ou carte mère, contient les processeurs hôtes (processeurs
Intel
Les Cartes Nitro mettent en oeuvre toutes les interfaces de contrôle externes utilisées par le service EC2 pour provisionner et gérer la puissance de calcul, la mémoire et le stockage. Ils fournissent également toutes les interfaces d'E/S, telles que celles nécessaires pour fournir le réseau virtuel (SDN – Software Defined Network), le stockage Amazon EBS et le stockage dédié à l’instance (instance storage). Cela signifie que tous les composants qui interagissent avec le monde extérieur du service EC2, au-delà de la carte mère, qu'ils soient entrants ou sortants, s'exécutent sur des composants informatiques autonomes physiquement séparés de la carte mère sur laquelle s'exécutent les environnements des clients.
Le Système Nitro est conçu pour créer une forte isolation logique entre les composants de l’hôte et les Cartes Nitro ; ceci bénéficie de l’isolation physique décrite précédemment, qui fournit une délimitation claire et fiable entre ces composants. Tout en étant ainsi isolées logiquement et séparées physiquement, les Cartes Nitro se trouvent généralement dans le même boîtier physique que la carte mère du système hôte et partagent son alimentation ainsi que son interface
PCIe
Note
Dans le cas des instances EC2 mac1.metal et mac2.metal, un Contrôleur Nitro est colocalisé avec un Mac Mini, dans un boîtier physique commun, et les deux sont connectés via Thunderbolt. Reportez-vous à la section Amazon EC2 Mac
Instances
Les principaux composants des Cartes Nitro sont constitués d’un système embarqué sur un circuit intégré (System on a Chip - SoC) conçu par AWS, qui exécute un micrologiciel (firmware) spécialisé. AWS a soigneusement piloté le processus de conception et de fabrication du matériel et du microprogramme de ces cartes. Le matériel est entièrement conçu par Annapurna Labs, l'équipe responsable de la conception interne des composants électroniques d'AWS. Le micrologiciel de ces cartes est développé et maintenu par des équipes d'ingénierie d’AWS dédiées.
Note
Annapurna Labs a été rachetée par Amazon en 2015, suite à un partenariat réussi lors des phases initiales de développement des principales technologies du système AWS Nitro. Annapurna Labs est responsable non seulement de la fabrication du matériel du système AWS Nitro, mais également des processeurs Graviton spécialement conçus et réalisés pour AWS et basés sur la technologie ARM, des puces d'accélération matérielle AWS
Trainium
Le microprogramme de contrôle des Cartes Nitro peut être mis à jour en direct à l'aide de progiciels signés cryptographiquement. Les Cartes Nitro peuvent être mises à jour indépendamment des autres composants du Système Nitro, y compris les unes des autres et de tout composant susceptible d’être mis à jour sur la carte mère, de façon à déployer de nouvelles fonctionnalités et des mises à jour de sécurité. La mise à jour des Cartes Nitro a un impact quasi-imperceptible sur les applications des clients et ne nécessite aucun assouplissement des contrôles de sécurité du Système Nitro.
Les Cartes Nitro sont connectées physiquement à la carte mère du système et à ses processeurs via PCIe, mais elles sont isolées logiquement de la carte mère qui exécute les environnements des clients. Un Système Nitro peut contenir une ou plusieurs Cartes Nitro ; s'il en existe plusieurs, elles sont connectées via un réseau interne au sein d'un boîtier physique. Ce réseau fournit un canal de communication privé entre les Cartes Nitro, indépendant de la carte mère, ainsi qu'une connexion privée au contrôleur de gestion de la carte mère (Baseboard Management Controller, BMC), s'il en existe un dans le serveur.
Le Contrôleur Nitro
La carte Nitro principale est appelée Contrôleur Nitro. Le Contrôleur Nitro constitue la base de confiance (root of trust) matérielle de l'ensemble du système. Il a pour fonction de gérer tous les autres composants du système, y compris le microprogramme chargé sur les autres composants. Le microprogramme du système dans son ensemble est stocké sur une mémoire SSD chiffrée, directement connectée au Contrôleur Nitro. La clé de chiffrement de la mémoire SSD est protégée par la combinaison d'un module TPM (Trusted Platform Module) et des fonctionnalités de démarrage sécurisé du SoC. Cette section décrit comment est conçu le démarrage sécurisé du Contrôleur Nitro ainsi que le rôle de ce dernier comme interface sécurisée entre un serveur et le réseau.
Note
Dans le cas des déploiements d'AWS Outpost, une clé de sécurité Nitro est également utilisée avec un module TPM et les fonctionnalités de démarrage sécurisé du SoC pour protéger la clé de chiffrement de la mémoire SSD, qui est directement connectée au Contrôleur Nitro.
Le démarrage sécurisé du Contrôleur Nitro
Le processus de démarrage sécurisé du SoC du Contrôleur Nitro commence par sa ROM (mémoire morte) de démarrage, et se poursuit avec la chaîne de confiance en surveillant et en vérifiant les premiers stades du microprogramme stocké dans une mémoire flash connectée au Contrôleur Nitro. Au fur et à mesure que l'initialisation du système progresse, un
TPM (Trusted
Platform Module)
Si aucune modification n'est détectée, des clés de déchiffrement supplémentaires, elles-mêmes chiffrées par des clés verrouillées dans le module TPM, sont utilisées pour déchiffrer des données supplémentaires dans le système afin de permettre au processus de démarrage de se poursuivre. Si des modifications sont détectées, les données supplémentaires ne sont pas déchiffrées et le système est immédiatement mis hors service et n'hébergera ainsi pas les environnements des clients.
Les étapes précédentes détaillent le processus par lequel le Contrôleur Nitro vérifie l'intégrité et la validité du logiciel système au démarrage. Pour que la procédure de démarrage sécurisé soit réellement sécurisée, chaque étape du code de démarrage du SoC doit non seulement être valide et non modifiée, mais aussi fonctionnellement correcte telle qu'elle est implémentée. Cela est particulièrement le cas du code ROM statique qui fait partie de la fabrication physique du composant. À cette fin, AWS a, lors de la conception
intégré des méthodes de preuve formelles
Le Contrôleur Nitro comme interface entre les serveurs EC2 et le réseau
Le Contrôleur Nitro est la passerelle exclusive entre le serveur physique et les plans de contrôle pour EC2, Amazon EBS et Amazon Virtual Private Cloud
Note
Au sein d'AWS, un modèle de conception courant consiste à diviser un système en services chargés de traiter les commandes informatiques générées par les environnements des clients (le plan de données – « data plane ») et services chargés de gérer et de distribuer la configuration des ressources des clients, par exemple pour créer, supprimer ou en modifier des ressources (le plan de contrôle – « control plane »). Amazon EC2 est un exemple de service qui inclut un plan de données et un plan de contrôle. Le plan de données se compose de serveurs physiques EC2 sur lesquels s'exécutent les instances virtuelles EC2 des clients. Le plan de contrôle comprend un certain nombre de services chargés de communiquer avec le plan de données et d'exécuter des fonctions telles que le relais des commandes pour lancer ou terminer une instance ou l'ingestion des données de télémétrie.
Architecture de contrôle du Système Nitro
Le Contrôleur Nitro présente au réseau dédié au plan de contrôle EC2 un ensemble d'API réseau avec une authentification et un chiffrement robustes, permettant la gestion du système. Chaque action d'interface API est enregistrée et toutes les tentatives d'appel d'une API sont authentifiées et autorisées par chiffrement à l'aide d'un système fin de contrôle d'accès. Chaque composant du plan de contrôle est autorisé à réaliser uniquement les opérations nécessaires à la réalisation de sa mission. Nous avons utilisé des méthodes formelles pour démontrer que l'API analysant les messages de contrôle du Contrôleur Nitro est exempte de faille de sécurité mémoire, quelle que soit le fichier de configuration et quelle que soit l’entrée réseau.
Cartes Nitro pour les entrées/sorties (E/S)
Outre le Contrôleur Nitro, certains systèmes utilisent des Cartes Nitro spécialisées supplémentaires pour exécuter certaines fonctions spécifiques. Ces Cartes Nitro subordonnées partagent la même architecture de SoC et les mêmes microprogrammes de base que le Contrôleur Nitro. Elles sont conçues avec du matériel supplémentaire et des microprogrammes spécialisés pour leurs fonctions spécifiques. Il s'agit, par exemple, de la Carte Nitro pour VPC, de la Carte Nitro pour EBS et de la Carte Nitro pour le stockage
NVMe
Ces cartes mettent en œuvre le chiffrement des données pour la mise en réseau et le stockage à l'aide de moteurs matériels dotés d'un stockage sécurisé des clés intégré au SoC. Ces moteurs matériels permettent de chiffrer à la fois le stockage NVMe local et les volumes EBS distants sans impact mesurable sur leurs performances. Les trois dernières versions de la Carte Nitro pour VPC, y compris celles utilisées sur tous les types d'instances récemment mises en service, chiffrent de manière transparente et sans impact sur les performances tout le trafic VPC vers d'autres instances EC2 exécutées sur des hôtes également équipés de Cartes Nitro compatibles avec le chiffrement.
Note
AWS fournit une connectivité sécurisée et privée
Les clés de chiffrement utilisées pour EBS, le stockage d'instance local et les réseaux VPC ne sont présentes en clair que dans la mémoire volatile protégée des Cartes Nitro ; elles sont inaccessibles à la fois aux opérateurs AWS et à tout code client exécuté sur les processeurs du système hôte. Les cartes Nitro fournissent des interfaces de programmation (API) matérielles via la connexion PCIe au processeur du serveur physique : NVMe pour le stockage par blocs (EBS et stockage d'instances), Elastic Network Adapter (ENA) pour la mise en réseau, port série pour un accès « out-of-band » aux consoles du système d'exploitation pour la journalisation et le débogage, etc.
Note
EC2 permet aux clients d'accéder à la sortie de la console de l'instance à des fins de dépannage. Le Système Nitro permet également aux clients de se connecter à une session de la console série pour résoudre de manière interactive les problèmes de démarrage, de configuration réseau et autres. Dans ce contexte, le terme « out-of-band » désigne la capacité des clients à obtenir des informations ou à interagir avec leurs instances via un canal distinct de l'instance elle-même ou de sa connexion réseau.
Lorsqu'un système est configuré pour utiliser l'Hyperviseur Nitro, chaque fonction PCIe fournie par une Carte Nitro est subdivisée en fonctions virtuelles à l'aide de la technologie de virtualisation des entrées/sorties à racine unique (SR-IOV). Cela facilite l'attribution d'interfaces matérielles directement aux machines virtuelles. Les données des clients (le contenu que les clients nous transfèrent à des fins de traitement, de stockage ou d'hébergement) sont transférées directement entre les instances et ces périphériques d'E/S virtualisés fournis par les Cartes Nitro. Cela permet de réduire le nombre de composants logiciels et matériels utilisés dans les E/S, ce qui se traduit par une baisse des coûts, de meilleures performances et une sécurité accrue.
La Puce de Sécurité Nitro
Le Contrôleur Nitro et les autres Cartes Nitro fonctionnent ensemble comme un seul domaine dans un Système Nitro, tandis que la carte mère, dotée de processeurs Intel, AMD ou Graviton, sur laquelle s'exécutent les environnement des clients, constitue un second domaine distinct. Bien que le Contrôleur Nitro et son processus de démarrage sécurisé constituent les éléments matériels de base de la confiance d’un Système Nitro, un composant supplémentaire est utilisé pour étendre cette confiance à la carte mère du système. La Puce de Sécurité Nitro est le lien entre ces deux domaines et étend le contrôle du Contrôleur Nitro à la carte mère et en fait un composant subordonné du système couvert par la chaîne de confiance du Contrôleur Nitro. Les sections suivantes expliquent comment le Contrôleur Nitro et la Puce de Sécurité Nitro fonctionnent ensemble pour atteindre cet objectif.
La protection du matériel système par la Puce de Sécurité Nitro
La Puce de Sécurité Nitro est un composant intégré à la carte mère du serveur. Au moment de l'exécution, elle intercepte et modère toutes les opérations vers les composants de stockage non volatil locaux et les interfaces de bus de gestion système à faible vitesse (telles que l'interface périphérique série (SPI) et l'I2C
La Puce de Sécurité Nitro est située entre le BMC et le processeur principal, sur sa connexion PCI haut débit, ce qui constitue un pare-feu logique pour protéger cette interface sur les systèmes de production. La Puce de Sécurité Nitro est contrôlée par le Contrôleur Nitro. C’est par l’intermédiaire de son contrôle sur la Puce de Sécurité Nitro que le Contrôleur Nitro gère et valide les mises à jour des micrologiciels et la programmation d'autres composants non volatils sur la carte mère ou les Cartes Nitro.
Une pratique courante consiste à s'appuyer sur un hyperviseur pour protéger ces actifs matériels, mais en l'absence d'hyperviseur, par exemple lorsque EC2 est utilisé en mode « bare metal », un autre mécanisme est nécessaire pour s’assurer que les utilisateurs ne peuvent pas manipuler le microprogramme du système. La Puce de Sécurité Nitro assure la fonction de sécurité essentielle qui garantit que les processeurs principaux du système ne peuvent pas mettre à jour le micrologiciel en mode « bare metal ». De plus, lorsque le Système Nitro fonctionne avec l'Hyperviseur Nitro, la Puce de Sécurité Nitro fournit également une défense en profondeur qui s’ajoute à la protection des composants matériels du système assurée par l'hyperviseur.
La Puce de Sécurité Nitro au démarrage ou à la réinitialisation du système
La Puce de Sécurité Nitro remplit également une autre fonction de sécurité critique lors du démarrage ou de la réinitialisation du système. Elle contrôle les broches physiques de réinitialisation de la carte mère du système, y compris ses processeurs et le contrôleur de gestion de la carte mère (BMC), le cas échéant. Cela permet au Contrôleur Nitro d'accomplir son propre processus de démarrage sécurisé, puis de vérifier l'intégrité du système d'entrée/sortie de base (BIOS), du BMC et de tous les autres microprogrammes avant de commander à la Puce de Sécurité Nitro de libérer les processeurs principaux et le BMC. Ce n'est qu'ensuite que les processeurs et le BMC peuvent commencer leur processus de démarrage à l'aide du BIOS et du micrologiciel qui viennent d'être validés par le Contrôleur Nitro.
L'Hyperviseur Nitro
L'Hyperviseur Nitro est un composant conçu intentionnellement pour être réduit et strictement limité aux fonctionnalités nécessaires pour exécuter les fonctions qui lui sont assignées, et rien de plus. L'Hyperviseur Nitro est conçu pour recevoir les commandes de gestion des machines virtuelles (démarrage, arrêt, etc.) envoyées par le Contrôleur Nitro, pour partitionner la mémoire et les ressources du processeur en utilisant les fonctionnalités de virtualisation matérielle du processeur, et pour attribuer des fonctions virtuelles SR-IOV
Note
L’architecture Nitro est unique du fait qu’elle ne nécessite pas d’hyperviseur pour fournir des composants d’infrastructure définis par logiciel (« software defined »). Néanmoins, dans la plupart des scénarios clients, la virtualisation est utile car elle permet de subdiviser de très grands serveurs pour une utilisation simultanée en plusieurs instances (VM) et présente d'autres avantages tels qu'un provisionnement plus rapide. Les hyperviseurs sont nécessaires dans les configurations virtualisées pour fournir l'isolation, la planification et la gestion des invités et du système. L'Hyperviseur Nitro joue donc un rôle essentiel dans la sécurisation d'un serveur EC2 basé sur Nitro dans ces scénarios courants.
Certains types d'instances créés sur le Système Nitro incluent des accélérateurs matériels, conçus à la fois par AWS et par des tiers (tels que des processeurs graphiques ou GPU). L'Hyperviseur Nitro est également chargé d'attribuer ces périphériques matériels à la machine virtuelle, de traiter les cas d'erreur matérielle et d'exécuter d'autres fonctions qui ne peuvent pas être exécutées via une interface de gestion « out-of-band ».
L'Hyperviseur Nitro ne comporte, de par sa conception, aucune couche logicielle réseau, aucune implémentation de système de fichiers et aucune prise en charge de pilotes de périphériques. L'Hyperviseur Nitro a été conçu pour inclure uniquement les services et fonctionnalités strictement nécessaires à sa tâche : il ne comprend ni interface de ligne de commande (« shell ») ni aucun mode d'accès interactif. La petite taille et la relative simplicité de l'Hyperviseur Nitro constituent un avantage de sécurité significatif par rapport aux hyperviseurs classiques.
Le code de l'Hyperviseur Nitro est un composant géré et signé de manière cryptographique, semblable à un microprogramme (firmware), stocké sur le stockage local chiffré et rattaché au Contrôleur Nitro. Il est ainsi chaîné à la base de confiance matérielle (root-of-trust) du Contrôleur Nitro. Lorsqu'un système est configuré pour utiliser l'Hyperviseur Nitro, le Contrôleur Nitro charge directement sur la carte mère du système une copie du code de l'hyperviseur, dont l’authenticité a été vérifiée, comme cela se ferait pour un microprogramme.
Note
Le mécanisme « d'injection » de l'hyperviseur utilise un périphérique NVMe en lecture seule, fourni par le Contrôleur Nitro à la carte mère, en tant que lecteur de démarrage du système.
Le transfert du traitement des données et de la virtualisation des E/S à du matériel dédié, ainsi que la réduction des responsabilités confiées à l'hyperviseur exécuté sur le processeur hôte, sont au cœur de la conception du Système Nitro. Cette architecture ne fournit pas seulement des performances améliorées et une sécurité renforcée grâce à l'isolation, elle permet également de proposer des instances de type « bare metal » d'EC2, l'hyperviseur est ainsi un composant qui n'est pas nécessaire pour fournir la virtualisation des E/S, la gestion du système ou la surveillance.
Note
Le Système Nitro garantit des performances comparables à du « bare metal » en exécutant presque toutes les fonctionnalités du système de virtualisation sur les Cartes Nitro plutôt que sur les processeurs de la carte mère du système hôte. Reportez-vous à la page Performances du Bare Metal avec le système AWS Nitro
La suppression des fonctionnalités non essentielles de l'Hyperviseur Nitro élimine des catégories entières de bogues dont les autres hyperviseurs peuvent être affectés, tels que les attaques réseau à distance ou les augmentations de privilèges liées à des pilotes. Même dans le cas peu probable de la présence d'un bogue dans l'Hyperviseur Nitro qui permettrait d'accéder à du code privilégié, il constitue tout de même un environnement inhospitalier pour tout attaquant potentiel en raison de l'absence de fonctionnalités standard du système d'exploitation comme la ligne de commande, les systèmes de fichiers, les utilitaires courants ou l'accès à des ressources susceptibles de faciliter les accès latéraux au sein de l'infrastructure.
Par exemple, comme nous l’avons déjà souligné, l'Hyperviseur Nitro ne possède aucune couche logicielle réseau et aucun accès au réseau EC2. Au lieu de cela, le Contrôleur Nitro et les autres Cartes Nitro assurent tous les accès de quelque nature que ce soit au réseau extérieur, que le processeur du serveur principal exécute l'Hyperviseur Nitro ou qu'il fonctionne en mode « bare metal ». De plus, comme nous le verrons en détail par la suite, la conception passive des communications de Nitro signifie que toute tentative de « communication » par du code exécuté dans le contexte de l'hyperviseur vers les Cartes Nitro sera refusée et fera l’objet d’une alarme.
Processus de mise à jour de l'Hyperviseur Nitro
ALes mises à jour régulières constituent un aspect crucial du maintien de la sécurité du système. L'Hyperviseur Nitro permet une mise à jour complète du système en direct sans interruption. Lorsqu'une nouvelle version de l'Hyperviseur Nitro est disponible, le code complet de l'hyperviseur en cours d'exécution est remplacé sur-le-champ, tout en préservant les instances EC2 des clients, avec un impact quasi imperceptible sur les performances de ces instances. Ces processus de mise à jour sont conçus de telle sorte qu'à aucun moment les protocoles de sécurité ou les défenses du Système Nitro n’ont besoin d’être mis en pause ou assouplis. Cette fonctionnalité de mise à jour en direct est conçue pour ne pas interrompre les instances des clients, tout en garantissant que non seulement les nouvelles fonctionnalités, mais aussi les mises à jour de sécurité peuvent être appliquées régulièrement et rapidement.
Le découplage entre les temps d'arrêt des instances clients et les mises à jour des composants du Système Nitro évite au service EC2 d'avoir de devoir jongler entre l'expérience client et l'impact potentiel sur la sécurité lors des mises à jour du système, améliorant ainsi la sécurité.
