Exécution avec un compte de tiers (impersonation)

De SOS Paris
Aller à : navigation, rechercher

L’« impersonation » consiste à utiliser un compte autre que celui de l'ordonnanceur pour exécuter un traitement.

Cette fonctionnalité est généralement imposée par les logiciels en proposant des solutions plus ou moins adaptées, la pire étant l'utilisation d'un compte sur-privilégié,
comme administrateur ou root, pour exécuter des actions qui ne demandent pas forcément de droits particuliers.

Ce problème concerne la sécurité et est généralement à la charge de l'administrateur système qui peut imposer une solution.

Impersonation à travers Jobscheduler (solution préconisée)

La solution optimale est de profiter de l'architecture collaborative de JobScheduler en dédiant un jobscheduler à chaque compte.

Mise place

Le principe est d'installer le JobScheduler avec l'utilisateur qui exécutera la commande, si on a plusieurs utilisateurs sur une même machine, on installera autant de JobSchedulers avec des ports différents. On définit ensuite les process class qui permettront de soumettre le job avec le bon utilisateur.

  • Pour la partie unix, on installera le jobscheduler avec le compte utilisateur en précisant l'argument "unprivileged"
  • Pour la partie windows, on modifiera le compte de service localsystem par l'utilisateur de soumission

Avantages/Inconvénients

Cette solution a plusieurs avantages:

  • elle permet d'avoir une solution unifiée quelque soit la plateforme et la version des ces plateformes
  • elle restreint les droits en n'utilisant que le compte utilisateur et jamais le compte root ou localsystem
  • elle compartimente les applications en dédiant un moteur par équipe d'utilisateurs
  • elle offre une exécution des jobs aussi bien en local, qu'entre jobschedulers d'une même machine ou à travers le réseau
  • sur windows, elle charge la base de registres et permet ainsi de retrouver un contexte utilisateur complet

Les inconvénients peuvent être limités:

  • l'installation des multiples jobschedulers (mais le template permet d'installer rapidement plusieurs jobschedulers à partir d'un fichier modèle)
  • l'espace disque consommé (cet espace disque est principalement utilisé par Java qu'on peut mutualiser pour l'ensemble des jobschedulers)

Si cette solution ne vous convient pas, vous pourrez alors vous tourner vers des méthodes plus spécifique à l'OS ou à sa version.

Attente de fichiers

Les droits pour une attente de fichiers soulèvent des questions similaires car on doit intervenir sur des objets qui appartiennent à différents utilisateurs. On rencontre plusieurs cas de figures:

  • Les fichiers appartiennent à l'utilisateur applicatif, ce qui est souvent le cas d'une application en local sur un serveur ou un ensemble de machines dédiés à cette application. L'utilisateur dispose des droits nécessaires pour l'accès au fichier
  • Les fichiers appartiennent à différents utilisateurs, par exemple pour des échanges de fichiers. Les fichiers sont stockés en local ou à travers des partages du réseau, ce qui ne change absolument rien sur l'aspect sécurité puisque dans tous les cas, ces fichiers sont protégés à travers des définitions de groupes

Pour qu'un utilisateur accède à ces différents fichiers, on retrouve les mêmes solutions que pour une soumission de job:

  • l'utilisateur dispose de tous les droits système (root, système local, admin de domaine, etc...) et peut ainsi accéder à tous les fichiers. Cette solution est évidemment à bannir car ce type de compte ne doit jamais être utilisé quelque soit l'outil de production.
  • l'utilisateur n'a pas de droits particuliers mais dispose au moins de droits d'accès aux partages et de droits d'accès en lecture. La mise en place des droits se fait simplement en ajoutant l'utilisateur dans les groupes de lecture des répertoires concernés.

Pour résumer, la solution préconisée serait:

  • dédier un JobScheduler pour l'attente de fichier
  • utilisé un compte particulier pour ce moteur
  • inclure ce compte dans les groupes des répertoires

L'arrivée de fichier pourra ensuite déclencher les chaines à travers un ordre sur les autres moteurs.

Impersonnation sous Unix

Commande sudo

C'est la solution la plus couramment utilisée et qui tend à se généraliser.
Elle a un avantage majeur, c'est l'administrateur de la machine qui donne les droits aux équipes applicatives, ce qui permet de restreindre strictement aux besoins.
Exemple :

sudo -i user "commande à exécuter"

Exécution via SSH

Le ssh est installé sur toutes les machines unix, la connexion permet de spécifier un utilisateur. A noter que la commande peut aussi être exécutée sur la machine locale.
Il est fortement déconseillé de stocker le mot de passe dans les jobs, on privilégiera un échange de clés.
SOS Berlin indique qu'il existe un job java pour le ssh, cela est seulement pertinent si le serveur ne dispose pas d'un client ssh.
Dans le cas contraire le chargement de la jvm va consommer des ressources bien plus importantes qu'un ssh natif.
Exemple :

ssh user@machine "commande a exécuter"

Agent utilisateur

Sur le même principe que le ssh, on va exécuter la commande sur un agent.
Dans le cas du jobscheduler, on l'aura installé avec le compte d'exécution.
Cela peut être réalisé avec la commande setup -u (unprivileged) afin de limiter son installation au périmètre de l'utilisateur.

voir : Exécution sur une machine distante

Utilisateur Windows

Le nombre de solution pour lancer un traitement avec un utilisateur spécifique sous Windows n’est pas plus restreint :

Windows NT/2000/XP/2003

Pour l’exécution de traitement avec un utilisateur spécifique depuis un serveur distant nous recommandons l’utilisation de Winexe disponible sur SourceForge à l’adresse suivante :
http://sourceforge.net/projects/winexe/

Attention: Ces versions de windows en sont plus supportées, cette solution est donc un pis aller.

Versions supérieures

Pour les versions supérieures à celle déjà mentionnée l’utilisation de Winexe n’est pas possible.
Néanmoins toutes les versions de Windows supérieures à 2003 sont supportées pour l’agent OSJS v1.8.2
Cette solution est toutefois contraignante car elle nécessite l’installation d’un agent par utilisateur.

Autre solutions

voir : Exécution distante Windows