Le principe des communications passives

La conception du système AWS Nitro suit un principe dite de « communication passive ». Cela signifie que, en production, les composants du système n'initient jamais de communication sortante, y compris vers un plan de contrôle, un service de gestion ou un service cloud. Au lieu de cela, un seul service de confiance et spécifiquement durci écoute le réseau, écoute les commandes lancées sur le réseau ou le bus système, agit en fonction de ces commandes, puis renvoie des résultats, le tout via des API bien définies avec un accès restreint. Les deux extrémités de ces voies de communication effectuent également une validation des paramètres afin de garantir que seuls des paramètres valides sont envoyés et reçus.

Ce principe commence par l'Hyperviseur lui-même. Il attend les commandes du Contrôleur Nitro sur un canal privé via PCIe. Il n'initie jamais de communication sortante avec le reste du Système Nitro. Il ne peut pas établir de connexion réseau sortante car, comme indiqué précédemment, il ne possède aucune couche réseau. Si, à un quelconque moment, par le biais d'une série d'actions improbables, l'Hyperviseur Nitro tentait d'établir des communications avec d'autres composants du Système Nitro, cela indiquerait clairement un défaut du microprogramme ou une possible compromission du système, et le service EC2 est conçu pour réagir en conséquence de façon à éviter tout impact et à alerter pour qu’un opérateur intervienne.

Note

En mode « bare metal », aucun hyperviseur ne s'exécute sur le processeur du serveur pour attendre les instructions du Contrôleur Nitro afin de démarrer, arrêter ou réinitialiser le serveur hôte. Dans ce cas, le Contrôleur Nitro contrôle la carte mère via sa connexion BMC privée et la Puce de Sécurité Nitro.

Le modèle de communication passive s’applique également à la couche suivante du Système Nitro. Le Contrôleur Nitro écoute sur un canal réseau sécurisé en attente de commandes authentifiées et autorisées sous la forme d'API spécifiques invoquées par le plan de contrôle EC2. Le Contrôleur Nitro n'initie jamais de communications sortantes sur le réseau du plan de contrôle EC2. Même les fonctionnalités « push » logiques, telles que la publication de métriques CloudWatch pour les instances EC2 exécutées sur l'hôte ou l'envoi des journaux de l'API Nitro au plan de contrôle EC2, sont mises en œuvre sous la forme d'un processus « pull ». Le plan de contrôle interroge régulièrement le Contrôleur Nitro pour récupérer les métriques à l'aide d'API bien définies. Toute tentative de communication sortante depuis le Contrôleur Nitro indiquerait clairement un bogue du microprogramme ou une possible compromission du système. Le service EC2 est conçu pour réagir en conséquence de façon à éviter tout impact et à alerter l'opérateur pour qu’il intervienne.

Le résultat de ce modèle de communication passive est un degré élevé d'isolation et de sécurité. Comme le fonctionnement normal implique de n'écouter que des messages bien définis, dont les paramètres ont été validés et d'y répondre à l'aide de réponses bien définies et dont les paramètres ont été validés, le système est conçu pour repérer et signaler toute activité qui paraîtrait suspecte. Le système est conçu de telle sorte que, dans le cas peu probable d'un bogue du microprogramme sur la carte mère, il est très probable qu'un adversaire potentiel tentant de s'échapper de la carte mère vers les Cartes Nitro soit détecté, bloqué et signalé. De plus, même dans le cas extrêmement improbable où un adversaire potentiel parviendrait tout de même à s’échapper de la carte mère et à accéder d'une manière ou d'une autre aux Cartes Nitro, la conception du Système Nitro fait à nouveau en sorte que toute tentative de cet adversaire de s'échapper des cartes Nitro serait très probablement détectée, bloquée et signalée, précisément pour les mêmes raisons. Ces multiples couches de défense protègent non seulement le service EC2 lui-même, mais également tous les clients exécutant des environnements et des applications au sein du système EC2.