Les développeurs devraient-ils avoir des autorisations d'administrateur sur leur PC


135

Les développeurs devraient-ils avoir des autorisations d'administrateur sur leur PC ou leur donner un accès utilisateur avancé est-il suffisant?

Certains commentaires:

  • S'ils souhaitent essayer une nouvelle application qui aurait besoin d'être installée, ils peuvent l'essayer sur une machine virtuelle et demander plus tard à l'administrateur réseau de l'installer pour eux. Tu penses que ça pourrait marcher?
  • Y a-t-il quelque chose qu'un développeur doit faire sur son PC qui nécessiterait des autorisations d'administrateur?

Nous sommes une équipe de 5 développeurs et construisons des applications web


116
Si j'arrivais à un emploi et que je découvrais que je n'avais aucun droit d'administrateur sur ma machine, je ne reviendrais pas le lendemain. Rendez la vie de vos développeurs plus facile, pas plus difficile.
annakata le

29
Cette question va souffrir d'un biais de sélection - il y a des moments où les machines des développeurs devraient être verrouillées, mais ce type de réponse ne sera jamais voté à la hausse sur un site destiné aux développeurs.
romandas

5
Moins courant qu'on pourrait le penser. Dans la plupart des cas, le problème sous-jacent concerne les données sensibles - par exemple, les lois suisses sur la confidentialité bancaire ont tendance à empêcher les développeurs de voir les données réelles des clients (le rapprochement des comptes est laissé comme un exercice pour le lecteur). Dans ce cas, le problème n'est pas de verrouiller les machines, mais de fournir des ensembles de données nettoyés pour le travail de développement. La plupart des autres situations sont soit des exigences réglementaires (par exemple, travailler avec des données classifiées), soit une CYA intéressée.
ConcernedOfTunbridgeWells

12
Je me demande comment la même question se déroulerait sur ServerFault ... (@romandas)
Ben Mosher

4
@BenMosher: voici votre réponse: serverfault.com/questions/232416/…
kmote

Réponses:


228

La réponse est oui'. Les développeurs devront se débattre avec des configurations système pour tester les éléments, installer des logiciels (si rien d'autre, pour tester le processus d'installation de tout ce qu'ils développent), fouiller dans le registre et exécuter des logiciels qui ne fonctionneront pas correctement sans les privilèges d'administrateur (juste pour lister quelques articles). Il existe une foule d'autres tâches qui font partie intégrante du travail de développement et qui nécessitent des privilèges d'administration.

Sachant que le personnel de développement n'a pas nécessairement un accès root aux systèmes de production, les droits d'administrateur sur un PC local ne compromettent pas de manière significative la sécurité des systèmes de production. Il n'y a pratiquement aucune raison opérationnelle légitime de restreindre l'accès administrateur aux PC locaux pour le personnel qui en a besoin pour faire son travail.

Cependant, la raison la plus importante pour fournir un accès administratif est que la configuration d'un environnement de développement compromis ou de second ordre envoie un message à votre équipe de développement:

«Nous apprécions si peu votre travail que nous sommes prêts à compromettre considérablement votre capacité à faire votre travail sans raison valable. En fait, nous sommes très heureux de faire cela pour couvrir notre propre cul, nous plier aux caprices de la petite bureaucratie ou parce que nous ne pouvons tout simplement pas être dérangés. C'est juste le meilleur des cas. Le pire des cas est que nous sommes vraiment le genre de maniaques du contrôle qui le considèrent comme notre perogatif de vous dire comment faire votre travail et ce que vous faites ou n'avez pas besoin de le faire. Faites avec ce que vous avez reçu et soyez reconnaissant d'avoir un travail.

En règle générale, fournir un environnement de travail de second ordre (et encore moins fondamentalement défectueux) pour le personnel de développement est une recette pour les conséquences naturelles de faire chier votre personnel - incapacité à retenir des personnes compétentes, roulement élevé du personnel, moral médiocre et prestation de mauvaise qualité. Faire tout son possible pour le faire - en particulier s'il y a une connotation de soumission aux caprices bureaucratiques - est tout simplement irresponsable.

Gardez à l'esprit que votre rotation de personnel n'entraîne pas seulement des coûts de remplacement du personnel. Le coût le plus grave du roulement du personnel est que la plupart de ceux qui restent seront le bois mort qui ne peut pas obtenir un meilleur emploi. Au fil du temps, cela dégrade les capacités des services concernés. Si votre industrie est suffisamment proche, vous pouvez également vous faire une réputation.

Un point à noter est que les privilèges administratifs sont beaucoup moins problématiques pour le développement sur des systèmes unix-oid ou mainframe que sur Windows. Sur ces plates-formes, un utilisateur peut faire beaucoup plus dans son propre domaine sans avoir besoin d'autorisations à l'échelle du système. Vous voudrez probablement toujours un accès root ou sudo pour les développeurs, mais ne pas avoir cela sera beaucoup moins fréquent. Cette flexibilité est une raison significative mais moins connue de la popularité continue des systèmes d'exploitation dérivés d'Unix dans les écoles d'informatique.


3
Il y a une différence entre avoir des droits d'administrateur et tout exécuter avec des droits d'administrateur :) De nombreux développeurs auront bien sûr besoin de droits d'administrateur. Mais tout exécuter de manière interactive avec des droits d'administrateur sur un système local n'est pas le moindre privilège. Il ouvre la porte aux attaques contre les systèmes de production auxquels le développeur a accès et un PC local compromis donne à tout attaquant le même accès. C'est plus facile que vous ne le pensez. La sécurité est un problème de couche sur couche, le moindre privilège par processus et un problème de formation des utilisateurs. Le respect de la sécurité de chaque appareil est le seul moyen: vimeo.com/155683357
Oskar Duveborn

Je suis partisan d'accorder des droits d'administrateur local aux développeurs, mais dire que "les droits d'administrateur sur un PC local ne compromettent pas de manière significative la sécurité des systèmes de production" dépendra de votre environnement. Ce qui préoccupe la plupart des informaticiens, c'est que vous installerez un logiciel contenant des logiciels malveillants / virus pouvant se propager dans toute l'entreprise ou si quelqu'un compromet votre ordinateur local et que vous avez des fichiers de données sensibles stockés localement ou sur une base de données locale. Dans un monde parfait, aucun développeur n'a accès aux fichiers de données HIPAA / PCI et toutes les bases de données de développement sont nettoyées, mais nous savons que ce n'est pas le cas.
L_7337

87

Les développeurs doivent avoir un contrôle complet et total de la machine qu'ils utilisent. La plupart des outils de débogage nécessitent des autorisations d'administrateur pour se connecter au runtime de l'application qu'ils construisent.

De plus, les développeurs téléchargent et essaient fréquemment de nouvelles choses. L'ajout d'étapes supplémentaires, telles que la nécessité pour un administrateur réseau de venir et d'installer quelque chose pour eux, frustre simplement le développeur et rendra rapidement la vie d'enfer pour la personne chargée des opérations réseau.

Cela dit, ils devraient être un administrateur sur LEUR box, pas sur le réseau.


5
Le plus gros problème que j'ai rencontré avec les développeurs avec des autorisations d'administrateur est que vous prenez pour acquis les droits que vous avez sur vos ressources informatiques locales. Tant de résultats logiciels de merde - écrit dans C: \ Program Files, écrit sur HKLM, etc.
SqlRyan

4
@rwmnau: Cela ne s'applique pas au développement Web. En outre, le problème devient apparent assez rapidement lors du contrôle qualité avec des autorisations normales.
NotMe

2
Rendre les machines virtuelles disponibles et les connexions de test de développement sans privilèges d'administrateur est un bon moyen de faciliter le test que le logiciel s'exécutera avec des autorisations utilisateur normales.
ConcernedOfTunbridgeWells

Les logiciels publiés avec de telles autorisations réservées aux administrateurs ont subi un processus d'assurance qualité extrêmement médiocre (ou aucun). Le logiciel doit être testé dans des environnements réels, par conséquent, le contrôle qualité devrait le détecter tôt et le problème autrement négligé par les développeurs serait résolu. Droite?

2
@rwmnau - Tout développeur digne de ce nom en est parfaitement conscient, mais la réponse n'est pas de verrouiller sa machine de développement. Il s'agit de leur fournir un environnement de test dans lequel ils peuvent déployer leur projet à leur convenance pour résoudre ces problèmes.
Spencer Ruport

48

Oui et non.

Oui, cela fait gagner beaucoup de temps au support système.

Non, vos utilisateurs ne l'ont pas, alors ne comptez pas dessus.

Nous développons avec des autorisations d'administrateur et testons sans. Ce qui fonctionne bien.


11
Ma femme a dû plaider pour un compte non administrateur sur son ordinateur, afin qu'elle puisse s'assurer que les utilisateurs pouvaient faire ce qu'elle pouvait. Votre politique est exactement la bonne (et donc votée pour).
David Thornley

1
Exactement, dev devrait avoir admin, test et QA devrait avoir user.
Dr Watson

Je ne peux pas être plus d'accord avec toi! L'accès administrateur est idéal pour le développement, mais la plupart des utilisateurs ne l'auront pas (si vous développez un logiciel d'entreprise ... le service informatique verrouille assez bien les choses en général).
Pulsehead

18

Administrateur local oui, pour toutes les raisons indiquées ci-dessus. Administrateur réseau non, car ils seront inévitablement entraînés dans les tâches d'administration réseau parce que "ils le peuvent". Les développeurs devraient se développer. L'administration du réseau est un travail entièrement différent.


15

Les développeurs doivent normalement faire des choses que la personne moyenne ne ferait pas, et devraient donc normalement avoir des comptes d'administrateur. Les faire sauter à travers des cerceaux maladroits leur fait perdre leur temps et les démoralise. Il peut y avoir des exceptions dans les situations de haute sécurité, mais si vous ne pouvez pas faire confiance à quelqu'un avec un compte administrateur, vous ne pouvez certainement pas faire confiance à son code.

Ils doivent également avoir un compte disponible avec la même autorisation que leurs utilisateurs (plus d'un compte si le pool d'utilisateurs a des statuts d'autorisation différents). Sinon, ils peuvent simplement développer quelque chose de cool, le déployer, puis constater que cela ne fonctionnera pas pour les utilisateurs.

Il y a aussi trop de façons de bousiller les ordinateurs avec des comptes d'administrateur (oui, je l'ai fait). Le service informatique a besoin d'une politique selon laquelle il ré-image l'ordinateur d'un développeur s'il ne peut pas le réparer rapidement. À un endroit où j'ai contracté, j'ai dû signer une copie de cette politique pour obtenir mon compte administrateur.

C'est une réponse assez spécifique à Windows. Sous Linux et autres systèmes Unix-y, les développeurs peuvent plus souvent se débrouiller avec des comptes utilisateurs uniquement, souvent n'ont pas besoin d'un autre compte pour le test (s'ils ont un compte avec lequel ils peuvent sudo, ils savent quand ils utilisent sudo, mais ils peuvent en avoir besoin avec les mêmes autorisations de groupe), et peuvent très facilement causer des dommages incroyables au système d'exploitation, de sorte que la même politique informatique est nécessaire.


4
"Il peut y avoir des exceptions dans les situations de haute sécurité, mais si vous ne pouvez pas faire confiance à quelqu'un avec un compte administrateur, vous ne pouvez certainement pas faire confiance à son code." - c'est une bonne idée, merci!
Utilisateur le

Vous ne pouvez pas faire confiance au code de toute façon: vous devriez faire du code révisé par des pairs pour tout. Et je pense que cela a également du sens pour les installations: demander à quelqu'un de «revoir» le logiciel qu'il est sur le point d'installer.
Tim

10

Oui, Half-Life 1 (et tous les mods associés: contre-grève, jour de défaite, etc.) ont besoin de droits d'administrateur (au moins pour la 1ère exécution, je pense) pour fonctionner correctement sous Windows NT, 2000, XP, etc. .

Et quel genre de développeur ne joue pas à Counter Strike à l'heure du déjeuner? (une merde à coup sûr)


10

Ayant enduré la douleur d'avoir à développer sans droits d'administrateur sur la machine ma réponse ne peut être que oui, c'est essentiel.


8

Absolument! Sinon, comment installer le gestionnaire de téléchargement pour télécharger des films la nuit?

Parfois, les développeurs ont vraiment besoin d'installer des choses ou de modifier quelque chose dans le système pour tester une idée. Ce sera impossible si vous devez appeler l'administrateur chaque fois que vous devez modifier quelque chose.

J'ai aussi mon observation personnelle que certains administrateurs ont tendance à visser tout ce qui est possible afin de faire dépendre même de petites choses d'eux au quotidien donc ... quoi, sécuriser leur travail? énervant les autres utilisateurs? Je n'ai pas de réponse. Mais le bon sens n'est pas vu ici.

La dernière fois qu'il y a eu un problème avec mon PC, j'ai participé activement à la restauration du système, en faisant des suggestions en travaillant en équipe avec l'administrateur, ou alors j'ai pensé ... L'administrateur s'est avéré très en colère et m'a accusé d'essayer d'enseigner lui ou redéfinir les règles. Je suppose que c'était juste son ego car il n'a pas été vu aussi cool dans notre chambre parmi d'autres collègues.


Je ne peux pas être plus d'accord. Après avoir été ingénieur système pendant 6 ans, il est douloureux de devoir appeler le helpdesk pour réparer quelque chose.
Matthew Whited

8

La réponse est que les développeurs devraient avoir 2 machines !!

  • Un programme de développement doté de droits d'administrateur et d'une puissance, d'une mémoire, d'une taille d'écran et d'une portabilité suffisantes, ainsi que de privilèges ADMIN, avec un logiciel antivirus d'entreprise chargé mais configurable par le développeur lorsque cela est nécessaire avec la politique de réinitialisation automatique.

  • Une entreprise qui a une charge d'entreprise, des politiques, des privilèges d'utilisateur non administrateur, etc. Les développeurs peuvent utiliser celle-ci pour les applications en mode version de test unitaire, car certains développeurs ont la mauvaise habitude de faire tous les tests unitaires avec des privilèges d'administrateur.


9
Excellente idée ... mais la plupart des entreprises ne vous donneront même pas une «bonne» machine, mais deux.
Matthew Whited

1
Vous pouvez faire la deuxième machine dans une VM avec la version «standard». Ceci est particulièrement utile si le réseau de développement est séparé sur son propre domaine. Une machine virtuelle de production distincte sur le domaine principal permet aux développeurs d'accéder aux ressources réseau.
ConcernedOfTunbridgeWells

5

Si vous inversez la question, je pense qu'il devient plus facile de répondre; devrions-nous supprimer les autorisations d'administrateur des développeurs? Quel est le gain?

Mais en fait, je pense que la réponse dépend de votre contexte, de votre environnement. La petite startup aura une réponse différente de celle d'une agence gouvernementale certifiée ISO.


5

Oui, mais ils doivent être conscients des limitations auxquelles leurs utilisateurs seront confrontés lorsqu'ils exécutent des logiciels dans un environnement plus limité. Les développeurs doivent avoir un accès facile aux environnements «typiques» avec des ressources et des autorisations limitées. Dans le passé, j'ai intégré le déploiement de builds sur l'un de ces systèmes "typiques" (souvent une machine virtuelle sur mon propre poste de travail) dans le cadre du processus de construction, afin que je puisse toujours avoir une idée rapide de la façon dont le logiciel fonctionnait à une extrémité. la machine de l'utilisateur.

Les programmeurs ont également la responsabilité de connaître les règles strictes de l'écriture de logiciels pour les utilisateurs non administrateurs. Ils doivent savoir exactement à quelles ressources système ils sont toujours autorisés (ou interdits) d'accéder. Ils doivent connaître les API utilisées pour acquérir ces ressources.

"Ça marche sur ma machine" n'est jamais une excuse!


5

En tant qu'administrateur système, je suis tout pour les développeurs ayant des droits d'administrateur local sur leurs postes de travail. Lorsque cela est possible, ce n'est pas une mauvaise idée de faire la plupart des choses avec un compte de niveau `` utilisateur '' standard, puis d'utiliser un autre compte `` administrateur '' pour apporter des modifications, installer des applications, etc. Souvent, vous pouvez sudo ou runas pour accomplir ce que vous voulez sans même vous connecter en dehors. Il est également utile de nous rappeler ce que la sécurité empêche les utilisateurs finaux de franchir lors de la mise en production.

Par ailleurs, il est également conseillé d'avoir un système [propre] ou une ou plusieurs VM afin de pouvoir tester les choses correctement et ne pas entrer dans le scénario «ça a l'air / fonctionne bien sur mon système» en raison de modifications du système.


3

Aucun utilisateur expérimenté

Tout d'abord, Power User est fondamentalement un administrateur - donc " limiter " un utilisateur à Power User n'apporte aucune augmentation de la sécurité du système - vous pourriez aussi bien être administrateur.

Connectez-vous de manière interactive en tant qu'utilisateur normal

Deuxièmement, bien sûr, un développeur a besoin d'un accès administratif à sa machine de développement (et aux serveurs et aux seconds boîtiers, etc.), mais bien sûr, personne ne doit se connecter de manière interactive en tant qu'administrateur pendant le développement ou les tests normaux. Utilisez un compte d'utilisateur normal pour cela et la plupart des applications.

Vous ne voulez sérieusement pas exécuter [insérer un navigateur, un plugin, une messagerie instantanée, un client de messagerie, etc.] en tant qu'administrateur.

Vous ne vous connectez normalement pas non plus à votre machine Linux en tant que root, même si vous avez probablement un accès root lorsque vous en avez besoin.

Utiliser un compte administrateur personnel distinct

Fournissez au développeur un compte d'administrateur personnel distinct sur sa machine (compte de domaine de préférence) qui est également un administrateur valide sur d'autres serveurs et boîtiers de développement / test auxquels la personne a besoin d'un accès administratif.

Utilisez «exécuter en tant que» et dans Vista + UAC pour demander ou demander une invite et entrez les informations d'identification administratives pour les tâches et les processus uniquement lorsque cela est nécessaire. L'infrastructure PKI avec des cartes à puce ou similaires peut réduire considérablement la contrainte de saisie fréquente des informations d'identification.

Tout le monde est heureux (ou?;)

Vérifiez ensuite l'accès. De cette façon, il y a une traçabilité et un moyen facile de savoir qui utilise les sessions des services Terminal Server sur un serveur de développement / test particulier auquel vous devez accéder maintenant ...

Certes, il y a certainement un travail de développement qui ne nécessitera jamais de privilèges d'administrateur local - comme la plupart des développements Web où le déploiement est testé sur un serveur ou une machine virtuelle séparé et où cassini ou tout ce qui est utilisé pour le débogage local fonctionne réellement bien comme un utilisateur normal.


2
Vous dites: ne leur permettez pas de se connecter en tant qu'administrateur, mais donnez-leur les clés juste au cas où ils auraient besoin de faire quelque chose qui l'exige. J'ai lu cette même merde sur le site de MS concernant l'UAC, et cela montre un manque total de considération réelle concernant les cent choses qu'un développeur fait en un jour.
NotMe

2
UAC a été mis en place pour empêcher les gens normaux de se tirer une balle dans le pied. Si un développeur fait cela, honte à lui. S'il le fait continuellement, il doit trouver une autre ligne de travail.
NotMe

Si vous leur donnez les clés, vous leur "autorisez" réellement, nous, à se connecter en tant qu'administrateurs. C'est juste que ce n'est jamais une bonne idée de faire cela pour les tâches quotidiennes. Pourquoi les gens pensent encore que c'est normal ou nécessaire simplement parce qu'ils sont des geeks, des codeurs ou des administrateurs me dépasse.
Oskar Duveborn le

Si vous avez déjà vu ce qu'un administrateur système moderne fait en une journée, vous vous rendrez compte que le besoin d'un accès administratif et de la saisie d'informations d'identification alternatives est bien plus élevé que tout codeur de niveau système hardcore ne le verra jamais. Ils ne se connectent toujours pas en tant qu'administrateurs pour les tâches quotidiennes et se débrouillent bien.
Oskar Duveborn le

Vous ne vous connectez normalement pas en tant que root à un système Unix même lorsque vous l'administrez, alors pourquoi feriez-vous cela sur un système Windows, même si vous êtes un développeur? Ça n'a aucun sens. Exécuter toutes les applications aléatoires comme Skype ou autre avec des privilèges système élevés est pour le moins ignorant - vous n'élevez que les applications qui en ont besoin.
Oskar Duveborn

3

Je travaille principalement dans le monde * nix et le modèle standard existe pour que les développeurs travaillent dans un compte d'utilisateur normal et non privilégié avec la possibilité (via sudoou su) de passer aux privilèges d'administrateur si nécessaire.

Je ne suis pas sûr de la configuration Windows équivalente, mais c'est, d'après mon expérience, la configuration idéale:

  • D'une part, avoir des droits d'administrateur disponibles à la demande donne au développeur toute la puissance sur son poste de travail en cas de besoin.

  • D'autre part, les logiciels Windows ont une longue, longue histoire de supposer que tous les utilisateurs ont des droits d'administrateur, au point que de nombreux programmes ne fonctionneront pas pour un utilisateur non administrateur. De nombreux problèmes de sécurité de Windows découlent directement de cette exigence implicite selon laquelle, pour pouvoir utiliser l'ordinateur de manière fiable, tous les utilisateurs doivent être administrateurs. Cela doit changer et le moyen le plus efficace de garantir que votre logiciel fonctionnera pour des utilisateurs non administrateurs est que vos développeurs l'exécutent eux-mêmes en tant qu'utilisateurs non administrateurs.


Je ne pense pas avoir rencontré une application métier qui ne puisse pas fonctionner en tant qu'utilisateur normal au cours des 5 à 10 dernières années. Une fois que j'étais un BOFH et tous les utilisateurs de cet endroit ont été obligés de tout exécuter en tant qu'utilisateurs normaux depuis ~ 2001 en fait - aucun administrateur privé n'est délégué et cela a bien fonctionné et a contrecarré de nombreux logiciels malveillants de l'époque. Il existe également des shims automatiques appliqués dans les versions plus récentes de Windows si une telle application héritée est exécutée (tromper dans un bac à sable) et dans mon travail de développement quotidien, c'est à peu près seul Visual Studio qui est jamais élevé lorsque je dois attacher à d'autres processus pour le débogage.
Oskar Duveborn

3

[Désolé, l'anglais n'est pas ma langue maternelle, je fais de mon mieux :)] Eh bien,

Expérience personnelle (je suis un développeur c ++ / SQL):

J'étais administrateur de ma machine Windows dans mon travail précédent. J'avais également des droits dbo (et non dba) sur les bases de données, y compris les bases de données d'environnement de production. En 2 ans et demi avec 8 personnes ayant ces hauts droits fous ... nous n'avons jamais eu de soucis. En fait, nous avons résolu de nombreux problèmes en mettant à jour db manuellement. Nous pourrions faire beaucoup de choses très rapidement pour les correctifs et les développeurs.

Maintenant, j'ai changé de travail. J'ai réussi (en pleurant beaucoup) à être administrateur de ma machine Windows. Mais le serveur dev est un serveur Red Hat auquel nous nous connectons en utilisant ssh. Essayer d'installer Qt était une torture, des limites de quota, des limites d'espace, des droits d'exécution et d'écriture. Nous avons finalement abandonné et avons demandé à l'administrateur de le faire pour nous. 2 semaines plus tard encore rien n'est installé. Je deviens très rapide à la lecture de journaux et à la frappe alt + tab.

J'ai demandé des droits d'administrateur, car seuls les développeurs de mon logiciel utilisent cette machine.

-> Réponse: "S'il y a des processus, c'est à vous de ne pas faire ce que vous voulez. Il doit bien fonctionner une fois en production".

-> Essayer d'expliquer à un responsable non technique: "Je n'aurai aucun droit d'administrateur dans les environnements de production ou UAT. Mais ma machine de développement est différente. Si je devais construire des chaises au lieu de logiciels, me diriez-vous que je peux ne pas mettre les outils que je veux dans mon atelier parce que mon atelier doit ressembler à l'endroit où la chaise sera utilisée? Je donne un package exécutable à uat. Les bibliothèques et les outils que j'ai utilisés pour les construire sont invisibles pour l'utilisateur final ou pour le mec qui installe le paquet. "

J'attends toujours aujourd'hui. J'ai trouvé une solution, ouvrez un environnement de développement, allez voir votre juge en ligne préféré, mettez-vous au défi. quand quelqu'un regardera votre écran, il vous verra en train de programmer. ;)


2

Vous pouvez répondre de deux manières. Oui et non, ou cela dépend. - Puis-je être plus vague ...

Cela dépend de la nécessité pour eux de faire leur travail. Si c'est le cas, accordez-leur des pouvoirs administratifs sur leur ordinateur. Sinon, ne le faites pas. Tous les développements logiciels ne nécessitent pas qu'un ingénieur ait les droits d'administrateur.

Oui et non dépend de votre point de vue. Certains ingénieurs considèrent leur ordinateur comme leur domaine et ce sont les règles de leur domaine. D'autres ne veulent pas de responsabilité.

J'ai travaillé dans une entreprise où je n'avais pas de droits d'administrateur et chaque fois que je devais faire quelque chose qui nécessitait des droits d'administrateur, je devais appeler le service d'assistance et ils m'accordaient des droits d'administrateur temporaire jusqu'à ce que je redémarre. C'était parfois pénible, mais c'était comme ça que je vivais avec. J'ai également travaillé dans des endroits où j'ai tous les droits d'administrateur sur mon ordinateur. C'était génial, sauf le temps où j'ai installé un logiciel qui a arrosé le système d'exploitation et j'ai dû emmener mon ordinateur au service d'assistance et leur demander de réimaginer le disque dur ....

Personnellement, je pense qu'un ingénieur devrait avoir des droits d'administrateur sur son ordinateur, mais étant entendu que s'il le gâche, une nouvelle image de base peut être rechargée et il perdra tout ce qui a été fait depuis la ligne de base d'origine. Cependant, je ne pense pas que tout le monde dans une entreprise devrait avoir des droits d'administrateur sur son ordinateur. La comptabilité, les assistants administratifs et les autres départements n'ont pas vraiment besoin de ces droits, ils ne devraient donc pas être accordés.


J'étais un entrepreneur pour une entreprise où, pour obtenir les droits d'administrateur, je devais signer un accusé de réception que le personnel informatique ne passerait pas plus de dix ou quinze minutes à essayer de réparer mon ordinateur, puis ferait un nettoyage complet et re -image. Cela me semblait juste.
David Thornley

D'accord. Un grand pouvoir implique de grandes responsabilités.
CraigTP

2

ht tp: //msdn.microsoft.com/en-us/library/aa302367.aspx

D'après mon expérience, un compromis entre nous (les codeurs) et eux (la sécurité) est toujours nécessaire. J'admets (bien que je déteste), il y a du mérite dans l'article de Microsoft ci-dessus. Comme je suis programmeur depuis des années, j'ai éprouvé la douleur où je devais simplement installer un débogueur différent, juste pour être ennuyé, je ne peux pas. Cela m'a obligé à réfléchir de manière créative à la façon de faire mon travail. Après des années de lutte contre notre équipe de sécurité (et plusieurs discussions), je comprends leur travail de devoir sécuriser toutes les zones, y compris mon bureau. Ils m'ont montré les vulnérabilités quotidiennes qui apparaissent, même sur l'application Quicktime la plus simple. Je peux voir leur frutration à chaque fois que je veux installer un utilitaire rapide ou modifier mon IIS local que je peux causer un sérieux problème de sécurité. Je n'ai pas bien compris cela jusqu'à ce que je vois un autre développeur se faire mettre en conserve. Il essayait de déboguer et a fini par arrêter Symantec uniquement pour obtenir (puis DONNER) un virus à des centaines de personnes. C'était le bordel. En parlant à l'un des "secheads" (les gars de la sécurité) de ce qui s'est passé, j'ai pu voir qu'il voulait juste dire, "vous l'a dit ...".

J'ai appris que nos secheads (enfin, du moins les miens) veulent juste protéger notre entreprise. La bonne nouvelle est que nous avons trouvé un compromis, et je peux faire mon travail et les secheads sont cool avec notre réseau sécurisé!

Credo


1

Oui, si vous voulez que les pentesters ou certains utilisateurs malveillants qualifiés prennent pied pour compromettre votre domaine.

ie Compromettre le compte de bas niveau> Trouver où admin -> Mimikatz -> Élever les autorisations -> Administrateur de domaine.

Donc non, les utilisateurs normaux ne devraient pas être des administrateurs.

Microsoft a également déclaré que l'UAC n'était pas une limite de sécurité, alors ne l'utilisez pas comme tel. Il existe différents contournements du monde réel de l'UAC disponibles.

S'ils ont besoin d'un administrateur dans le cadre de leur rôle professionnel, attribuez des comptes d'utilisateur d'administrateur local de domaine distincts utilisés pour l'installation de logiciels uniquement (avec des autorisations d'administrateur sur leur propre ordinateur uniquement), jamais pour un usage général ou un accès Internet. Cela devrait avoir une politique de mot de passe plus stricte (par exemple, une longueur minimale de 15 caractères). La fonctionnalité Runas doit être utilisée pour cela.

Tout environnement dans lequel les comptes d'utilisateurs normaux sont admin est une recette pour un désastre de sécurité.


0

Wow, cette question va certainement ouvrir à des réponses intéressantes. En réponse, je cite le souvent utilisé - 'Cela dépend' :)

Dans les petites entreprises, cela peut être simplement une question de pragmatisme. Les développeurs sont également susceptibles d'être les plus experts techniquement, il est donc logique pour eux d'administrer leurs propres machines.

Personnellement, je suis fan du "compte administrateur" qui peut être utilisé si nécessaire - c'est-à-dire "Exécuter en tant que .." (j'ai remarqué que cette approche était en principe très similaire à UAC plus tard).

Si vous développez un logiciel de bureau, ce n'est pas une mauvaise idée pour les développeurs de travailler dans les limites que leur utilisateur final connaîtra - c'est-à-dire des droits limités ou restreints. Si vous créez le logiciel avec des droits limités, il y a de fortes chances que vous rencontriez les mêmes problèmes que vos utilisateurs cibles avec le même ensemble d'autorisations.

Cela dit, si vous avez un bon laboratoire de test et / ou une équipe d'assurance qualité décente, cela pourrait être un point discutable - surtout si vous avez une pratique ALM à moitié décente.

Donc finalement - je me développe sans UAC, principalement parce que j'ai confiance en moi et en mes compétences. Dans un environnement d'équipe, je le mettrais aux voix. Dans les grandes organisations, vous n'avez peut-être pas cette liberté. Les administrateurs d'entreprise ont souvent le dernier mot :)


0

Dans mon entreprise, les développeurs, les ingénieurs et mon patron (propriétaire de l'entreprise) ont le privilège d'administrateur local. Mon patron a également le privilège d'administrateur réseau, juste au cas où je serais touché par ce bus capricieux (ou quitte). Tout le monde est enfermé.

En tant qu'administrateur système, cette configuration m'a causé un peu de chagrin de temps en temps, en particulier lorsque des logiciels non approuvés sont installés. Cependant, venant d'une expérience de développeur, je comprends la nécessité pour les utilisateurs expérimentés d'avoir plus de contrôle sur leur environnement et, en tant que tel, je suis prêt à supporter les bizarreries ou les problèmes occasionnels qui peuvent surgir. J'effectue des sauvegardes de routine de leurs postes de travail - juste au cas où.

Au fait, j'ai eu plus de problèmes avec le patron qui bricolait avec les choses qu'avec n'importe qui d'autre. Un peu comme la vieille question: "Où est assis un éléphant? Où il veut!" Mais dans une petite entreprise où il est essentiellement l'administrateur système "de sauvegarde", il n'y a pas beaucoup de choix.


-1

Cela dépend des compétences du développeur et du fait qu'il / elle est consultant ou non.

Je pense qu'il est raisonnable qu'un développeur chevronné et digne de confiance ait le droit de faire tout ce qu'il veut avec son PC tant que cela ne nuit pas à sa productivité.


6
Pourquoi lieriez-vous les mains d'un consultant et non d'un employé régulier? Ne font-ils pas tous les deux le même travail? Attendez-vous moins du consultant même si vous payez probablement plus pour lui? Cela semble vraiment stupide. De plus, si un développeur ne peut pas faire fonctionner sa propre machine, il a besoin d'un nouveau travail
NotMe

-1

Personne sur Windows XP ne doit utiliser un compte administrateur pour une utilisation quotidienne, et dans Vista, si vous devez être administrateur, au moins avoir UAC activé. Surtout les développeurs Web et autres développeurs qui naviguent sur le Web avec Internet Explorer.

Ce que vous pouvez faire, c'est demander aux développeurs d'utiliser leur compte d'utilisateur régulier, mais leur donner un deuxième compte qui est un administrateur sur leur PC afin qu'ils puissent l'utiliser au besoin (Exécuter en tant que). Je sais qu'ils ont parlé de développement Web, mais pour le développement Windows, votre logiciel doit être testé en utilisant un compte utilisateur normal, et non en tant qu'administrateur.

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.