| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| checkopenedconsole [2020/07/15 15:50] – [Le script] inc002 | checkopenedconsole [2020/07/16 09:24] (Version actuelle) – [Solution] inc002 |
|---|
| ====Introduction==== | ====Introduction==== |
| |
| Avec l'arrivée de nouveaux clients qui sont amenés à se connecter sur vSphere et qui potentiellement peuvent voir accès à des serveurs autres que ceux qu'ils doivent gérer, ou en cas de vol d'identifiant, nous avons besoin d'une solution permettant de connaître quel sont les consoles des VM qui sont ouvertes et quels sont les utilisateurs ainsi que leur niveau de privilège sur Windows. | Avec l'arrivée de nouveaux clients amenés à se connecter à vSphere pour gérer des VM et qui potentiellement peuvent voir accès à des serveurs autres que ceux qu'ils doivent gérer, ou en cas de vol d'identifiant, nous avons besoin d'une solution permettant de connaître quel sont les consoles des VM qui sont ouvertes et quels sont les utilisateurs ainsi que leur niveau de privilège sur Windows. |
| |
| ==== Problématique ==== | ==== Problématique ==== |
| |
| Même si la gestion des droits est extrêmement fine sur vSphere, il est possible que des droits puissent être modifiés par une tierce personne sans forcément penser aux conséquences sur l'héritage ou sur la pertinence des accès. De plus, les accès pour le support 1er niveau ont généralement les droits stop/start/reset sur les machines mais également le droit de console, le plus souvent pour monter un ISO sur la VM. Dans tous ses cas, si une session utilisateur est ouverte sur le serveur, la personne qui s'y connecte obtient les privilèges de l'utilisateur connecté. | Même si la gestion des droits est extrêmement fine sur vSphere, il est possible que des droits puissent être modifiés par une tierce personne sans forcément penser aux conséquences sur l'héritage ou sur la pertinence des accès. De plus, les accès pour le support 1er niveau ont généralement les droits stop/start/reset sur les machines mais également le droit de console, le plus souvent pour monter un ISO sur la VM. Dans tous ses cas, si une session utilisateur est ouverte sur le serveur, la personne qui ouvre la console obtient les privilèges de l'utilisateur connecté. |
| |
| ==== Solution ==== | ==== Solution ==== |
| Plusieurs solutions peuvent être mises en place afin de minimiser le risque d'accès au serveur via la console: | Plusieurs solutions peuvent être mises en place afin de minimiser le risque d'intrusion dans le réseau via la console: |
| |
| * Gérer finement les droits des utilisateurs afin de ne leur donner accès qu'a leurs ressources | * Gérer finement les droits des utilisateurs afin de ne leur donner accès qu'a leurs ressources |
| * Limiter à une seule console à la fois par VM | * Limiter à une seule console à la fois par VM |
| * Verrouiller automatiquement la session utilisateur dans Windows au bout d'un certain temps | * Verrouiller automatiquement la session utilisateur dans Windows au bout d'un certain temps |
| * | |
| Afin de permettre aux administrateurs des vCenter d'être au courant régulièrement des consoles ouvertes, le script ci-dessous permet, via les vmware tools installés dans les VM d'interroger directement Windows et de lui demander quels sont les utilisateurs qui possèdent des sessions actives et quels privilèges ils possèdent. | Afin de permettre aux administrateurs des vCenter d'être au courant régulièrement des consoles ouvertes, le script ci-dessous permet, via les vmware tools installés dans les VM, d'interroger directement Windows et de lui demander quels sont les utilisateurs qui possèdent des sessions actives et avec quel privilège. |
| |
| ==== Le script ==== | ==== Le script ==== |
