Bonjour à tous (tes), -oui bon, l'écriture inclusive est un autre débat -
 
Je cherche un point d'équilibre entre les "systémeux" et les développeurs, l'un veut restreindre tous les droits et l'autre veut avoir tous les droits...
 
Mon contexte:
- une partie des serveurs est orientée système et applications standard (WSUS,DC,compta,ged,sql...), ceux là ne me posent pas de soucis
- une autre partie des serveurs est orientée "métier" et doit être accessible aux développeurs en tant qu'admin car ils installent/désinstallent et mettent à jour pas mal de trucs...
 
Mon problème se situe sur les serveurs "metier", actuellement les dev utilisent des comptes AD nominatifs et sont à la fois admin de leur PC et de ces serveurs (avec le même compte donc); oui ça pose un problème de sécurité et j'aimerais avoir vos avis pour corriger le tir.
 
-> Je pense qu'on va retirer les droits admin sur ces serveurs à partir de leurs comptes nominatifs de tous les jours, mais du coup quel est la meilleure option:
 
- 1 compte AD nominatif de tous les jours admin de leur PC + 1 autre compte AD nominatif avec comme préfixe admin.nom.prénom par exemple qui sera admin des serveurs métiers (inconvénient si le compte admin.nom.prénom est compromis, tous les serveurs métier le sont)
- 1 compte AD nominatif de tous les jours admin de leur PC + 1 compte admin différent sur chaque serveur (admin.srv1@domaine admin.srv2@domaine etc...), l'inconvénient est que tous les dev utilisent le même compte, mais est-ce un problème si on met en place un log des connexions de ces comptes en relevant les IP pour savoir qui a fait quoi au cas où?, autre inconvénient si 2 dev ont envie de travailler sur le même serveur, ce ne sera pas possible, il vont se 'voler' les sessions
- une autre solution à proposer?
 
Merci pour vos futures réponses!
 
 

Option1 sans hésiter
T'imagines devoir avoir 36 comptes differents pour te logger sur 36 serveurs?
En plus si un dev part, il a toujours le mot de passe des comptes puisque ce ne sont pas des comptes nominatifs, tu ne peux pas les revoquer simplement

la solution c'est qu'ils n'aient pas de droits d'admin du tout. Ils sont pas développeurs, pas administrateur.
S'ils ont besoin de droits admin c'est qu'ils font pas bien leur boulot

 
Merci, c'est ce que l'anssi conseille il me semble d'ailleurs.
 

 
En fait j'ai dit dev, mais ils ne font pas que du code, ils installent leurs produits que ce soit de l'apache ou du tomcat ou wamp, cygwin..., et font des montées de version, c'est pour ça qu'ils ont besoin des droits d'admin sur ces serveurs, idem pour leur PC, ils installent leur environnement de test sur leur PC directement.
Mais sur le fond je te rejoins parfaitement.
 
 

C'est une problématique courante et qui revient régulièrement sur le topic des aigris.
 
Il y a plusieurs approches/solutions possibles, qui varient selon les contraintes techniques/politiques/financières.
 
Mais en gros :
 
- Définir l'environnement "courant" : besoins basiques (messagerie, Office, filer...) sans droits d'admin.
- Définir l'environnement de test : machines dédiées à ce besoin, sans accès à l'environnement courant ni aux serveurs d'infra ou métier. Une sorte de sandbox. Ils auront des comptes admin (nominatifs) sur ces machines par contre.
- Définir l'environnement métier : les serveurs sur lesquels ils vont intervenir, et pour lesquels ils auront des comptes administrateurs limités. Comptes admin unqiuement de ces serveurs, et avec lesquels il est impossible d'ouvrir une session ailleurs (typiquement, sur les postes de travail de l'environnement courant).

Passer par google pour savoir de quoi tu parlais par ce topic des aigris...ça c'est fait!
 

Et vice versa, le compte courant n'a pas le droit d'ouvrir de session sur ces serveurs (sans être admin) dans ton idée? Il faut que je me renseigne davantage sur leur manière de travailler je crois aussi.
 

Oui bien sûr, hors de question que les comptes standard puissent ouvrir des sessions sur les serveurs (ce qui est le cas par défaut). C'est pour cela qu'il te faudra un modèle de délégation éventuellement.
 
Mais la base c'est d'échanger avec eux pour connaître leurs besoin oui. Sans ça tu n'iras pas très loin.
 
Edit : et hors de question que les comptes admin puissent ouvrir des sessions sur les postes de travail. Un compte = ouverture de session sur une cible précise

Oui, j'ai déjà "corrigé" l'ouverture de session pour les utilisateurs par défaut sur les serveurs via GPO; par contre tu parles d'un modèle de délégation, peux tu préciser stp? (la seule délégation que je connaisse est sur les objets de l'AD...)
 

j'ai eu la même problémeatique il y a peu.
et j'ai posé la question ici même
 
tous le personnel de la dsi (dev, infra, poste) ont tous 2 comptes ( utilisateur et utilisateur admin)
j'ai créé un groupe DEV_ADM et j'ai mis les comptes admin des dev dedans.
J'ai identifié les serveurs auquel ils avaient droits et j'ai mis le groupe DEV_ADM dans le groupe local "administrateurs" (via gpo voir groupes restreint" )
 

J'ai fait une recherche dans les posts avant de faire le mien, mais j'ai pas dû chercher assez, ni comme il fallait, désolé pour le doublon
Et merci de prendre le temps de répondre à un boulet comme moi! ^^
 

pas grave. on a tous appris un jour et on continue d'apprendre.