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

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

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.

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.

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.

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.

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.

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)

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.

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.

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.

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.

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!

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.

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.

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.

[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. ;)

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.

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

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é.

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 :)

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.

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é.

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.