Environnement opérationnel
L'environnement opérationnel comprend les systèmes physiques et leurs composants, les architectes de centre de données, les administrateurs et les membres du département informatique. Une violation de la sécurité peut se produire en n'importe quel point de l'environnement opérationnel.
La virtualisation place une couche logicielle entre le matériel proprement dit et les domaines invités qui exécutent les services de production, ce qui accroît la complexité. Par conséquent, planifiez et configurez avec soin le système virtuel et méfiez-vous des erreurs humaines. Méfiez-vous également des tentatives de personnes malveillantes d'accéder à l'environnement opérationnel par le biais de "l'ingénierie sociale".
Les sections suivantes décrivent les menaces caractéristiques que vous pouvez contrer au niveau de l'environnement opérationnel.
Menace : configuration incorrecte non intentionnelle
En matière de sécurité, la préoccupation principale pour un environnement virtualisé est d'assurer l'isolement du serveur en séparant les segments du réseau, en prévoyant un accès administratif séparé et en répartissant les serveurs dans des classes de sécurité, lesquelles correspondent à des groupes de domaines partageant les mêmes exigences et privilèges de sécurité.
Création de canaux de communication inutiles entre les domaines invités de production et l'environnement d'exécution
Création d'accès inutiles à des segments du réseau
Création de connexions non intentionnelles entre des classes de sécurité distinctes
Migration non intentionnelle d'un domaine invité dans la mauvaise classe de sécurité
Allocation insuffisante de matériel pouvant entraîner une surcharge inattendue des ressources
Affectation de disques ou de périphériques d'E/S au mauvais domaine
Configurez attentivement les ressources virtuelles afin d'éviter les erreurs suivantes :
Contre-mesure : création d'instructions opérationnelles
Gestion des patchs pour tous les composants de l'environnement
Mise en place d'une procédure d'implémentation des modifications sécurisée, traçable et bien définie
Vérification des fichiers journaux à intervalles réguliers
Surveillance de l'intégrité et de la disponibilité de l'environnement
Avant de commencer, définissez soigneusement les instructions opérationnelles applicables à votre environnement Oracle VM Server for SPARC. Ces instructions décrivent les tâches à effectuer et la manière de les effectuer. Il s'agit des tâches suivantes :
Effectuez régulièrement des contrôles pour vous assurer que ces instructions restent à jour et adaptées, et pour vérifier qu'elles sont suivies au jour le jour.
En plus de ces instructions, vous pouvez prendre plusieurs mesures plus techniques pour réduire le risque d'actions non intentionnelles. Reportez-vous à la section Logical Domains Manager.
Menace : erreurs dans l'architecture de l'environnement virtuel
Lorsque vous déplacez un système physique vers un environnement virtualisé, vous pouvez en général conserver la configuration du stockage existante en réutilisant les LUN d'origine. Toutefois, la configuration réseau doit être ajustée par rapport à l'environnement virtualisé et l'architecture résultante peut différer considérablement de l'architecture utilisée sur le système physique.
Vous devez vous poser la question de savoir comment préserver l'isolement des classes de sécurité distinctes et connaître leurs besoins. Vous devez également prendre en compte le matériel partagé de la plate-forme et les composants partagés tels que les commutateurs réseau et SAN.
Pour optimiser la sécurité de votre environnement, assurez-vous de préserver l'isolement des domaines invités et des classes de sécurité. Lors de la conception de l'architecture, anticipez les erreurs possibles et les attaques et mettez en oeuvre des moyens de défense. Une bonne conception permet de limiter les éventuels problèmes de sécurité tout en permettant la gestion de la complexité et des coûts.
Contre-mesure : affectation attentive de domaines invités aux plates-formes matérielles
Utilisez des classes de sécurité, c'est-à-dire des groupes de domaines partageant les mêmes exigences et privilèges de sécurité, pour isoler les domaines les uns des autres. En affectant à une plate-forme matérielle donnée des domaines invités appartenant à la même classe de sécurité, vous empêchez qu'une éventuelle violation de l'isolement ne se propage à une autre classe de sécurité.
Contre-mesure : planification d'une migration de domaine Oracle VM Server for SPARC
La fonction de migration de domaine en direct peut rompre l'isolement si un domaine invité est migré par inadvertance vers une plate-forme assignée à une autre classe de sécurité, comme illustré dans la figure suivante. Planifiez donc avec soin la migration des domaines invités afin de vous assurer qu'aucune migration entre classes de sécurité différentes n'est autorisée.
Figure 1-4 Migration de domaine d'une classe de sécurité à une autre
Pour réduire ou éliminer la vulnérabilité de sécurité présentée par l'opération de migration, vous devez échanger et installer manuellement les certificats d'hôte générés par ldmd hors bande entre la paire machine source/machine cible. Pour plus d'informations sur la configuration des certificats SSL, reportez-vous à Configuration des certificats SSL pour la migration du manuel Guide d’administration d’Oracle VM Server for SPARC 3.2 .
Contre-mesure : configuration correcte des connexions virtuelles
Si vous n'assurez pas le suivi de toutes les connexions réseau virtuelles, il est possible qu'un domaine puisse accéder de manière indue à un segment du réseau. Un tel accès peut par exemple contourner le pare-feu ou une classe de sécurité.
Pour réduire les risques d'erreurs d'implémentation, planifiez et documentez soigneusement toutes les connexions virtuelles et physiques de votre environnement. Optimisez le plan de connexion des domaines pour plus de simplicité et de facilité de gestion. Documentez précisément votre plan et vérifiez l'exactitude de votre implémentation par rapport à votre plan avant le passage en production. Même une fois votre environnement virtuel en production, vérifiez régulièrement l'implémentation par rapport au plan.
Contre-mesure : utilisation du balisage VLAN
Vous pouvez utiliser le balisage VLAN pour consolider plusieurs segments Ethernet sur un même réseau physique. Cette fonctionnalité est également disponible pour les commutateurs virtuels. Pour limiter les risques liés à des erreurs logicielles dans l'implémentation des commutateurs virtuels, configurez un commutateur virtuel par carte NIC physique et réseau VLAN. De plus, pour vous protéger contre des erreurs dans le pilote Ethernet, évitez d'utiliser des VLAN balisés. Toutefois, la probabilité que de telles erreurs se produisent est faible car la vulnérabilité des VLAN balisés est bien connue. Des tests d'intrusion sur la plate-forme Sun SPARC T-Series d'Oracle avec le logiciel Oracle VM Server for SPARC n'ont pas mis en évidence cette vulnérabilité.
Contre-mesure : utilisation des dispositifs de sécurité virtuels
Les dispositifs de sécurité tels que les filtres de paquets et les pare-feux sont des instruments d'isolement et protègent l'isolement des classes de sécurité. Ces dispositifs sont soumis aux mêmes menaces que tout autre domaine invité, c'est pourquoi leur utilisation ne garantit pas une protection complète contre une violation d'isolement. Par conséquent, évaluez avec soin tous les aspects des risques et de la sécurité avant de prendre la décision de virtualiser un tel service.
Menace : effets secondaires du partage des ressources
Le partage des ressources dans un environnement virtualisé peut conduire à des attaques par déni de service (DoS, denial-of-service), qui surchargent une ressource jusqu'à ce qu'un autre composant tel qu'un autre domaine soit affecté.
Emballement des zones de cache partagées par les strands et assignées à deux domaines invités
Surcharge de la bande passante de la mémoire
Dans un environnement Oracle VM Server for SPARC, seules certaines ressources sont susceptibles d'être affectées par une attaque par déni de service. Les ressources de CPU et de mémoire sont assignées de manière exclusive à chaque domaine invité, ce qui empêche la plupart des attaques par déni de service. Mais même l'assignation exclusive de ces ressources peut ralentir un domaine invité de l'une des manières suivantes :
Contrairement aux ressources de CPU et de mémoire, les services de disque et les services réseau sont généralement partagés par les domaines invités. Ces services sont fournis aux domaines invités par un ou plusieurs domaines de service. Etudiez avec soin comment assigner et répartir ces ressources entre les domaines invités. Notez que toute configuration permettant à la fois des performances maximales et une exploitation optimale des ressources réduit les risques d'effets secondaires.
Evaluation : effets secondaires liés aux ressources partagées
Qu'il soit assigné à un domaine de manière exclusive ou partagé par plusieurs domaines, un lien réseau peut être saturé ou un disque peut être surchargé. De telles attaques affectent la disponibilité d'un service pendant toute la durée de l'attaque. Leur cible n'est pas compromise et aucune donnée n'est perdue. Vous pouvez facilement réduire les effets de cette menace, mais vous devez la garder à l'esprit, même si elle se limite aux ressources réseau et de disque dans Oracle VM Server for SPARC.
Contre-mesure : affectation attentive des ressources matérielles
Assurez-vous que vous affectez uniquement les ressources matérielles requises aux domaines invités. Veillez à annuler l'affectation d'une ressource inutilisée lorsque celle-ci n'est plus nécessaire ; c'est le cas par exemple d'un port réseau ou d'une unité de DVD requis uniquement lors d'une installation. En appliquant cette pratique, vous réduisez le nombre de points d'entrée possibles pour une personne malveillante.
Contre-mesure : affectation attentive des ressources partagées
Les ressources matérielles partagées, telles que les ports réseau physiques, constituent une cible potentielle pour des attaques par déni de service. Pour limiter l'impact d'attaques par déni de service à un seul groupe de domaines invités, déterminez avec soin quels domaines invités partagent quelles ressources matérielles.
Par exemple, vous pouvez regrouper des domaines invités partageant des ressources matérielles en fonction de leur disponibilité ou de leurs exigences en matière de sécurité. Outre le regroupement, vous pouvez appliquer différents types de contrôles des ressources.
Vous devez vous poser la question de savoir comment partager les ressources de disque et les ressources réseau. Vous pouvez limiter les problèmes en séparant l'accès au disque au moyen de chemins d'accès physiques dédiés ou de services de disque virtuel dédiés.
Résumé : effets secondaires liés aux ressources partagées
Toutes les contre-mesures décrites dans cette section exigent que vous maîtrisiez les aspects techniques de votre déploiement et leurs implications en matière de sécurité. Veillez à planifier avec soin, à bien documenter et mettez en place l'architecture la plus simple possible. Assurez-vous de connaître les implications du matériel virtualisé afin de pouvoir vous préparer à déployer le logiciel Oracle VM Server for SPARC en toute sécurité.
Les domaines logiques font preuve de robustesse face aux effets du partage de CPU et de mémoire, car le partage qui se produit effectivement est très limité. Néanmoins, il est préférable d'appliquer des contrôles de ressources tels que la gestion des ressources Solaris dans les domaines invités. L'utilisation de ces contrôles vous protège contre les défauts de comportement des applications, que vous travailliez dans un environnement virtualisé ou non virtualisé.