Comment désactiver les fichiers d'échange dans ESXi?


18

Nous exécutons quelques machines virtuelles Solaris / Linux sur ESXi qui contiennent des données chiffrées très sensibles qui finissent par être déchiffrées comme requis en mémoire.

Tout va bien, à l'exception des fichiers d'échange ESXi qui pourraient potentiellement stocker certaines des données décryptées, la cerise sur le gâteau étant que ces fichiers ne seront pas supprimés en cas de panne de l'hôte.

Existe-t-il un moyen de désactiver complètement ces fichiers?

Nous avons déjà essayé de réserver la totalité de la RAM allouée aux machines virtuelles par machine virtuelle, mais les fichiers sont toujours créés.

Que faudrait-il pour que la permutation ESXi soit complètement désactivée pour l'hôte entier ou seulement pour certaines machines virtuelles?


Êtes-vous uniquement préoccupé par une condition dans laquelle votre hôte ESXi plante?
ewwhite

1
Pourquoi? Qui a accès au serveur?
ewwhite

2
Je ne veux pas être impoli, mais je préfère attirer l'attention sur la question initiale.
Marius Burz

1
Mais @ewwhite est l'un de nos meilleurs experts VMware. Il demande certainement une très bonne raison. Après tout, comprendre la totalité de votre situation est essentiel pour vous donner une bonne réponse .
Michael Hampton

5
C'était un audit de sécurité qui a déclenché toute la situation, nous nous sentirions tellement plus à l'aise de n'avoir aucune mémoire contenant des données déchiffrées transférées / sérialisées vers le FS.
Marius Burz

Réponses:


13

C'est une question intéressante. Je n'ai jamais pensé à la sécurité des données au niveau de l'hyperviseur ... généralement, les politiques de sécurité et le renforcement tournent autour des tâches spécifiques au système d'exploitation (limitation des démons, des ports, désactivation des fichiers de base, options de montage du système de fichiers, etc.)

Mais après quelques recherches rapides (et en cours d'exécution stringssur des fichiers .vswp VMWare actifs), il est définitivement possible d'extraire des données de fichiers .vswp résidant dans une banque de données VMWare. Ce lien permet d'expliquer le cycle de vie de ces fichiers.

Dans votre cas, je pense que votre approche sera déterminée par la politique et les exigences de sécurité. D'après mon expérience en finance et en audit, je pense qu'une approche acceptée serait de limiter / sécuriser l'accès au serveur hôte. Rappelez-vous que par défaut, votre hôte ESXi n'a pas d'accès SSH ou console activé. L'activation de ces fonctionnalités génère un événement / une alerte dans vCenter qui doit être remplacé manuellement , donc l'hypothèse est que l'audit de l'accès est le meilleur moyen de contrôler l'accès à ces informations.

Si vous ne savez pas qui peut accéder au serveur, il n'y a peut-être pas de solution technique à un problème administratif. Je vais vérifier d'autres sources pour voir s'il existe un moyen de limiter l'utilisation des fichiers .vswp.

--Éditer--

Vous pouvez réserver toute la RAM invitée. Vous ne spécifiez pas la version de VMWare que vous utilisez, mais dans mon installation 5.1, il y a une option pour réserver toute la mémoire invité . L'activation de cette option crée un fichier .vswp de longueur nulle, plutôt qu'un fichier égal à la taille de la RAM allouée à la machine virtuelle. Ne faites pas attention au fichier vmx - *. Vswp. C'est nouveau pour ESXi 5.x , et ce n'est pas lié à la pression de la mémoire du système d'exploitation de l' invité (c'est pour le tas de processus VMX, les périphériques invités et les agents de gestion). De plus, les fichiers vmx - *. Vswp peuvent être désactivés en définissant sched.swap.vmxSwapEnabledsur FALSE.

Je pense que cela vous donnera ce que vous demandez.

entrez la description de l'image ici


Aucune réservation de mémoire (par défaut):

root@deore:/volumes/vol2/staging/Test_Bed# ls -al | grep vswp
-rw------- 1 nfs  nobody  3221225472 Dec 23 13:31 Test_Bed-ad493981.vswp
-rw------- 1 nfs  nobody   115343360 Dec 23 13:31 vmx-Test_Bed-2907257217-1.vswp

Avec réservation de mémoire verrouillée:

root@deore:/volumes/vol2/staging/Test_Bed# ls -al | grep vswp
-rw------- 1 nfs  nobody           0 Dec 23 13:38 Test_Bed-ad493981.vswp
-rw------- 1 nfs  nobody   115343360 Dec 23 13:38 vmx-Test_Bed-2907257217-1.vswp

1
Un scénario théorique impliquerait une chaîne d'événements (comme toujours), disons qu'un hôte se bloque, les disques durs sont remplacés, ces disques durs peuvent contenir des données déchiffrées dans de tels fichiers d'échange (à l'insu de la plupart), se retrouvent entre de mauvaises mains parce que la plupart pensent que les données sur eux n'est pas si sensible (les données sensibles se trouvent sur d'autres disques durs, cryptées).
Marius Burz

@MariusBurz Voir les modifications ci-dessus.
ewwhite

Nous ne pouvions pas nous débarrasser des fichiers vmx - *. Vswp, mais maintenant que vous dites qu'ils ne sont pas ce que nous pensions être, nous devons revoir le tout. Je peux confirmer sur ma machine de test 5.1 @ home que le fichier vswp standard est créé avec 0 ko.
Marius Burz

1
@MariusBurz Les fichiers vmx vswp sont contrôlés par le sched.swap.vmxSwapEnabledparamètre. Ils peuvent également être désactivés.
ewwhite

Merci beaucoup de m'avoir aidé @ewwhite. J'aurais aimé pouvoir mieux l'expliquer en ce qui concerne les fichiers encore créés, il aurait été beaucoup plus facile pour vous de reconnaître où se trouvait notre problème. Nous pensions que ce fichier était un fichier d'échange standard où il ne l'était pas.
Marius Burz

4

Il semble que vous tentiez de résoudre le problème de manière incorrecte. Essayer d'arrêter l'échange de machine n'est pas une garantie que les données sensibles ne seront pas enregistrées sur le disque. Qu'en est-il des vidages mémoire, etc.? Une fois que vous avez un périphérique inscriptible qui a été dans un système qui contient des données sensibles, il ne doit pas être considéré comme «propre» et doit être détruit lorsque son utilisation est terminée.

Si vos données sont sensibles, vous devez sécuriser physiquement le système. Tous ceux qui ont besoin d'accéder au système doivent être contrôlés de manière appropriée et spécifiquement autorisés à le faire. Leurs activités doivent être autorisées, enregistrées et supervisées, etc.

Le scénario que vous décrivez est facile à gérer. Vous devez disposer de procédures pour détruire les appareils contenant des données sensibles proportionnées à la sensibilité des données. Vous ne laissez tout simplement pas l'appareil hors de votre environnement sécurisé à moins qu'il ne soit signé par une autorité appropriée, auquel cas il cesse d'être votre problème.


Bien qu'il s'agisse d'une question technique intéressante, je suis entièrement d'accord avec cela.
Dan

2

Il doit être suffisant pour chiffrer les fichiers d'échange de machines virtuelles créés par ESXi. Essayez de placer les fichiers d'échange sur une banque de données chiffrée, comme un SAN de chiffrement ou un disque à chiffrement automatique.


C'est en effet une façon de résoudre ce problème, mais ce n'est encore qu'une solution de contournement. Je suppose que le plus sûr serait d'utiliser certains SED locaux, une idée si / comment ESXi les prend en charge?
Marius Burz
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.