Environnement d'exécution

La Figure 1–3 présente les composants de l'environnement d'exécution. Chaque composant fournit des services donnés qui, ensemble, constituent la plate-forme globale sur laquelle les domaines invités de production peuvent s'exécuter. Une configuration correcte des composants est primordiale pour garantir l'intégrité du système.

Tous les composants de l'environnement d'exécution sont des cibles potentielles pour une personne malveillante. Cette section décrit les menaces qui pèsent sur chaque composant dans l'environnement d'exécution. Certaines menaces et contre-mesures peuvent s'appliquer à plusieurs composants.

Menace : manipulation de l'environnement d'exécution

En manipulant l'environnement d'exécution, il est possible de prendre le contrôle de plusieurs façons. Par exemple, il est possible d'installer des microprogrammes manipulés dans ILOM pour intercepter toutes les entrées/sorties d'un domaine invité à partir d'un domaine d'E/S. Ce type d'attaque peut permettre d'accéder à la configuration du système et de la modifier. Une personne malveillante qui prend le contrôle du domaine de contrôle d'Oracle VM Server for SPARC peut reconfigurer le système comme elle l'entend, et une personne malveillante qui prend le contrôle d'un domaine d'E/S peut apporter des modifications aux dispositifs de stockage connectés, tels que des disques d'initialisation par exemple.

Evaluation : manipulation de l'environnement d'exécution

Une personne malveillante qui parvient à entrer dans ILOM ou dans n'importe quel domaine de l'environnement d'exécution peut lire et manipuler toutes les données mises à la disposition de ce domaine. Un accès de ce type peut s'effectuer par l'intermédiaire du réseau ou par le biais d'une erreur dans la pile de virtualisation. Ce type d'attaque est difficile à mettre en oeuvre car en général, ILOM et les domaines ne peuvent pas être attaqués directement.

La mise en oeuvre de contre-mesures pour éviter une manipulation de l'environnement d'exécution est une pratique de sécurité courante et doit être implémentée sur n'importe quel système. Les pratiques de sécurité courantes constituent une barrière protectrice supplémentaire pour l'environnement d'exécution et réduisent un peu plus les risques d'intrusion et de manipulation.

Contre-mesure : sécurisation des chemins d'accès interactifs

Assurez-vous de ne créer que les comptes absolument nécessaires pour les applications qui s'exécutent sur le système.

Assurez-vous que les comptes requis pour l'administration sont sécurisés en recourant à l'authentification basée sur une clé ou à des mots de passe forts. Ces clés ou mots de passe ne doivent pas être partagés par différents domaines. Envisagez également d'implémenter une authentification à deux facteurs ou une "règle des deux personnes" pour l'exécution de certaines actions.

N'utilisez pas des connexions anonymes pour les comptes tels que root, afin que toutes les commandes exécutées sur le système puissent être tracées et attribuées à un utilisateur donné. Utilisez plutôt des droits pour accorder à des administrateurs donnés l'accès aux seules fonctions qu'ils sont autorisés à effectuer. Assurez-vous que l'accès au réseau d'administration utilise toujours un protocole de chiffrement tel que SSH et que les stations de travail des administrateurs sont traitées comme des systèmes à haute sécurité.

Contre-mesure : réduction du SE Oracle Solaris

L'intégrité de n'importe quel logiciel installé sur un système étant susceptible d'être compromise, vous devez veiller à n'installer que les logiciels indispensables pour minimiser les failles de sécurité.

Contre-mesure : sécurisation du SE Oracle Solaris

En plus d'effectuer une installation minimale du SE Oracle Solaris, configurez les packages logiciels de manière à “sécuriser” le logiciel contre les attaques. Exécutez tout d'abord des services réseau limités afin de désactiver tous les services réseau à l'exception de SSH. Cette stratégie est le comportement par défaut sur les systèmes Oracle Solaris 11. Pour plus d'informations sur la sécurisation du SE Oracle Solaris, reportez-vous à la page de sécurité Solaris.

Contre-mesure : recours à la séparation des rôles et à l'isolement des applications

Les applications de production sont nécessairement connectées à d'autres systèmes et sont, par conséquent, plus exposées aux attaques extérieures. Ne déployez pas les applications de production sur un domaine qui fait partie de l'environnement d'exécution. Au contraire, déployez-les uniquement sur des domaines invités dépourvus de privilèges particuliers.

L'environnement d'exécution doit uniquement fournir l'infrastructure nécessaire pour ces domaines invités. En séparant l'environnement d'exécution des applications de production, vous pouvez introduire un certain niveau de précision dans les privilèges d'administration. Un administrateur de domaine invité de production n'a pas besoin d'accéder à l'environnement d'exécution et un administrateur d'environnement d'exécution n'a pas besoin d'accéder aux domaines invités de production. Si possible, affectez les différents rôles de l'environnement d'exécution, tels que le domaine de contrôle et le domaine d'E/S, à des domaines différents. Une configuration de ce type permet de limiter les dommages si l'un des domaines est compromis.

Vous pouvez également étendre la séparation des rôles à l'environnement réseau utilisé pour la connexion des différents serveurs.

Contre-mesure : configuration d'un réseau de gestion dédié

Connectez tous les serveurs équipés de processeurs de service à un réseau de gestion dédié. Cette configuration est également recommandée pour les domaines de l'environnement d'exécution. S'ils sont connectés en réseau, hébergez ces domaines sur leur propre réseau dédié. Ne connectez pas directement les domaines de l'environnement d'exécution aux réseaux qui sont affectés aux domaines de production. Bien que vous ayez la possibilité d'effectuer toutes les tâches d'administration en vous connectant à la console unique mise à disposition par le processeur de service d'ILOM, cette configuration rend l'administration suffisamment fastidieuse pour la rendre impraticable. En séparant les réseaux de production et d'administration, vous vous protégez contre les écoutes électroniques et les manipulations. Ce type de séparation élimine également le risque d'une attaque dirigée contre l'environnement d'exécution et menée depuis les domaines invités via le réseau partagé.

Figure 1-5  Réseau de gestion dédié