Les développeurs doivent-ils avoir des autorisations d'administrateur sur leur PC
Les développeurs devraient-ils avoir des autorisations d'administrateur sur leur PC ou leur donne-t-il un accès utilisateur avancé suffisant?
Certains commentaires:
- S'ils veulent essayer une nouvelle application qui aurait besoin d'être installée, ils pourraient l'essayer sur une machine virtuelle et ensuite demander à l'administrateur réseau de l'installer pour eux. Pensez-vous que cela pourrait fonctionner?
- 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 manipuler les configurations du système pour tester les éléments, installer le logiciel (si rien d'autre, pour tester le processus d'installation de tout ce qu'ils développent), fouiller le registre et exécuter un logiciel qui ne fonctionnera pas correctement sans privilèges d'administrateur (juste pour lister quelques éléments). Il existe une multitude d'autres tâches faisant partie intégrante du travail de développement 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 presque 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 le faire pour couvrir notre propre cul, flatter les caprices de 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 monstres de contrôle qui le considèrent comme notre prérogative pour vous dire comment faire votre travail et ce que vous faites ou pas besoin de le faire. Faites avec ce qui vous est donné et soyez reconnaissant que vous ayez du travail du tout. '
Généralement, fournir un environnement de travail de second ordre (et encore moins fondamentalement imparfait) au personnel de développement est une recette pour les conséquences naturelles de l'énervement de votre personnel - incapacité à conserver des personnes compétentes, roulement élevé du personnel, mauvais moral et prestation de mauvaise qualité. Sortir de votre façon de le faire - en particulier s'il y a une connotation de complaisance à un caprice bureaucratique - est tout simplement irresponsable.
Gardez à l'esprit que le roulement de votre personnel ne se limite pas aux coûts de remplacement du personnel. Le coût le plus sérieux du roulement du personnel est que la plupart de ceux qui resteront seront le bois mort qui ne peut pas obtenir un meilleur travail. Au fil du temps, cela dégrade les capacités des départements 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 les systèmes Unix-oid ou mainframe que sur Windows. Sur ces plateformes, un utilisateur peut faire bien plus dans son propre domaine sans avoir besoin d'autorisations à l'échelle du système. Vous souhaiterez probablement toujours un accès root ou Sudo pour les développeurs, mais ne pas l'avoir sera beaucoup moins souvent sous les pieds. Cette flexibilité est une raison importante 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 total et total sur 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é de passer par un administrateur réseau et d'installer quelque chose pour eux frustrent simplement le développeur et feront rapidement de la vie un enfer pour la personne chargée des opérations réseau.
Cela dit, ils devraient être un administrateur sur LEUR boîtier, pas le réseau.
Oui et non.
Oui, cela fait gagner beaucoup de temps à la prise en charge du 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 impliqués dans les tâches d'administration réseau car "ils le peuvent". Les développeurs devraient se développer. L'administration du réseau est un tout autre travail.
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 gaspille leur temps et les démoralise. Il peut y avoir des exceptions dans des 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 disposer d'un compte disponible de la même autorisation que leurs utilisateurs (plusieurs comptes 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 existe également 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 lui permettant de recréer l'image d'un ordinateur de développeur s'il ne peut pas le réparer rapidement. À un endroit où j'ai passé un contrat, j'ai dû signer une copie de cette politique pour obtenir mon compte administrateur.
Ceci est une réponse assez spécifique à Windows. Sous Linux et d'autres systèmes Unix-y, les développeurs peuvent plus souvent se débrouiller avec des comptes d'utilisateurs uniquement, n'ont souvent pas besoin d'un autre compte pour le test (s'ils ont un compte avec lequel ils peuvent utiliser Sudo, ils savent quand ils utilisent Sudo, mais ils peuvent en avoir besoin avec les mêmes autorisations de groupe), et peuvent causer des dommages incroyables au système d'exploitation très facilement, donc la même politique informatique est nécessaire.
Oui, Half-Life 1 (et tous les mods associés: contre-attaque, jour de la défaite, etc.) ont besoin de droits d'administrateur (au moins pour la première exécution, je pense) pour fonctionner correctement sous Windows NT, 2000, XP, etc. .
Et quel type de développeur ne joue pas à Counter Strike à l'heure du déjeuner? (un merdique à coup sûr)
Ayant enduré la douleur de devoir 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 changer 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 changer quelque chose.
J'ai également 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 quotidiennement donc ... quoi, sécuriser leur emploi? énerver les autres utilisateurs? Je n'ai pas de réponse. Mais le bon sens ne se voit pas 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 quelques suggestions en travaillant en équipe avec l'administrateur, du moins je pensais ... L'administrateur s'est montré 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'était pas vu aussi cool dans notre chambre parmi d'autres collègues.
La réponse est que les développeurs devraient avoir 2 machines !!
Un développement qui a des droits d'administrateur et une puissance, une mémoire, une taille d'écran et une portabilité suffisantes, ainsi que des privilèges ADMIN, avec un logiciel antivirus d'entreprise chargé mais configurable par le développeur lorsque cela est requis avec une politique de réinitialisation automatique.
Une entreprise qui a une charge d'entreprise, des politiques, des privilèges d'utilisateur non administrateur, etc. Le développeur peut utiliser celui-ci pour tester les applications en mode de version 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. Une petite startup aura une réponse différente à une agence gouvernementale certifiée ISO.
Oui, mais ils doivent être conscients des limites auxquelles leurs utilisateurs seront confrontés lorsqu'ils exécuteront des logiciels dans un environnement plus limité. Les développeurs devraient 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 à l'un de ces systèmes "typiques" (souvent un VM sur mon propre poste de travail) dans le cadre du processus de build, afin que je puisse toujours avoir une idée rapide pour savoir comment le logiciel fonctionnait sur la machine d'un utilisateur final.
Les programmeurs ont également la responsabilité de connaître les règles strictes et rapides d’écriture de logiciels pour les utilisateurs non administrateurs. Ils doivent savoir exactement à quelles ressources système ils sont toujours autorisés (ou interdits) à 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 à fait favorable aux développeurs disposant de 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 les problèmes de sécurité que les utilisateurs finaux devront franchir lors de la mise en production.
Sur une note secondaire, il est également conseillé d'avoir un système [propre] ou des machines virtuelles afin que vous puissiez tester les choses correctement et ne pas entrer dans le scénario "il semble/fonctionne bien sur mon système" en raison d'un ajustement du système.
[je m'excuse, l'anglais n'est pas ma langue maternelle, je fais de mon mieux :)]
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 (pas 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 droits élevés fous ... nous n'avons jamais eu aucun problème. En fait, nous avons résolu de nombreux problèmes en mettant à jour manuellement db. Nous pourrions faire beaucoup de choses très rapidement pour les correctifs et les correctifs.
Maintenant, j'ai changé d'emploi. J'ai réussi (en pleurant beaucoup) à être administrateur de ma machine Windows. Mais le serveur de développement est un serveur Red Hat auquel nous nous connectons à l'aide de 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 demandé à l'administrateur de le faire pour nous. 2 semaines plus tard, rien n'est installé. Je deviens vraiment rapide à lire les journaux et à frapper alt + tab.
J'ai demandé des droits d'administrateur, car seul le développeur de mon logiciel utilise cette machine.
-> Réponse: "S'il y a des processus c'est pour vous de ne pas faire ce que vous voulez. Il doit bien fonctionner une fois en prod".
-> Essayer d'expliquer à un responsable non technique: "Je n'aurai aucun droit d'administration que ce soit dans les environnements de production ou d'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 installant le paquet. "
J'attends toujours aujourd'hui. J'ai trouvé une solution, ouvrir un environnement de développement, aller voir votre juge en ligne préféré, vous mettre au défi. quand quelqu'un regarde votre écran, il va vous voir programmer. ;)
Aucun utilisateur expérimenté
Tout d'abord, Power User est essentiellement un administrateur - donc "limitation" un utilisateur de Power User n'apporte aucune augmentation de sécurité au 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 deuxièmes boîtiers, etc.) mais bien sûr, personne ne devrait 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 cette application et la plupart des applications.
Vous ne voulez vraiment pas exécuter [insérer un navigateur, un plug-in, une messagerie instantanée, un client de messagerie, etc.] en tant qu'administrateur.
Normalement, vous ne vous connectez pas à votre box 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 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îtes de développement/test auxquels cette 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'ICP avec les cartes à puce ou similaires peut réduire considérablement la pression de saisir souvent les informations d'identification.
Tout le monde est content (ou?;)
Auditez ensuite l'accès. De cette façon, il y a une traçabilité et un moyen facile de savoir qui utilise les sessions de services terminaux sur un serveur de développement/test particulier auquel vous devez accéder en ce moment ...
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 quoi que ce soit utilisé pour le débogage local fonctionne réellement bien en tant qu'utilisateur normal.
Je travaille principalement dans le monde * nix et le modèle standard permet aux développeurs de travailler dans un compte utilisateur normal et non privilégié avec la possibilité (via Sudo ou su) de passer à l'admin privilèges selon les besoins.
Je ne suis pas sûr de ce que serait l'arrangement Windows équivalent, mais c'est, selon mon expérience, la configuration idéale:
D'une part, le fait d'avoir des droits d'administrateur disponibles à la demande donne au développeur le plein pouvoir sur son poste de travail en cas de besoin.
De l'autre, le logiciel Windows a 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 des administrateurs. Cela doit changer et le moyen le plus efficace de garantir que votre logiciel fonctionnera pour les utilisateurs non administrateurs est que vos développeurs l'exécutent eux-mêmes en tant qu'utilisateurs non administrateurs.
ht tp: //msdn.Microsoft.com/en-us/library/aa302367.aspx
D'après mon expérience, un compromis entre nous (codeurs) et eux (sécurité) est toujours nécessaire. J'admets (bien que je déteste), il y a du mérite dans l'article Microsoft ci-dessus. Comme je suis programmeur depuis des années, j'ai connu la douleur où j'avais besoin d'installer simplement un débogueur différent, juste pour m'énerver, 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 tous les domaines, 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 Tweak mon local IIS que je peux causer un grave problème de sécurité. Je n'ai pas bien compris cela jusqu'à ce qu'un autre développeur soit mis en boîte . Il essayait de déboguer et a fini par arrêter Symantec uniquement pour obtenir (puis DONNER) du virus à des centaines de personnes. C'était un gâchis. En parlant à l'un des "secheads" (gars de la sécurité) de ce qui s'est passé, Je pouvais voir qu'il voulait juste dire "vous l'a dit ...".
J'ai appris que nos chefs (enfin, du moins les miens) veulent juste protéger notre entreprise. La bonne nouvelle, c'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
Vous pouvez répondre à cela de deux manières. Oui et non, ou cela dépend. - Puis-je être plus vague ....
Cela dépend s'il est nécessaire 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 des 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 exigeait des droits d'administrateur, je devais appeler le service d'assistance et ils m'ont accordé des droits d'administrateur temporaire jusqu'à ce que je redémarre. C'était parfois douloureux, mais c'était comme ça, alors j'ai vécu avec. J'ai également travaillé dans des endroits où j'ai tous les droits d'administrateur sur mon ordinateur. C'était génial, sauf pour le temps où j'ai installé un logiciel qui arrosait le système d'exploitation et que je devais emmener mon ordinateur au service d'assistance et les faire 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. Les comptables, les adjoints administratifs et les autres services n'ont pas vraiment besoin d'avoir ces droits, ils ne devraient donc pas être accordés.
Wow, cette question va certainement ouvrir des réponses intéressantes. En réponse, je cite le souvent utilisé - "Ça dépend" :)
Dans les petites entreprises, cela pourrait être simplement une question de pragmatisme. Les développeurs sont également susceptibles d'être les plus compétents sur le plan technique, il est donc logique pour eux d'administrer leurs propres machines.
Personnellement, je suis un 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 très similaire en principe à l'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 connaîtra leur utilisateur final - 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 auxquels vos utilisateurs cibles seraient confrontés étant donné 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 d'ALM à moitié décente.
Donc finalement - je me développe sans UAC, principalement parce que je me fais confiance et que je maîtrise mes compétences. Dans un environnement d'équipe, je le mettrais aux voix. Dans les grandes organisations, vous pourriez ne pas avoir 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 des privilèges d'administrateur local. Mon patron a également le privilège d'administrateur réseau, juste au cas où je serais frappé par ce bus capricieux (ou que je quitterais). Tout le monde est enfermé.
En tant qu'administrateur système, cette configuration m'a occasionné un peu de peine de temps en temps, en particulier lorsque des logiciels non approuvés sont installés. Cependant, venant du milieu des développeurs, 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 à accepter la bizarrerie ou le problème occasionnel qui peut apparaître. 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 bricole les choses qu'avec n'importe qui d'autre. Un peu comme la vieille question, "Où est assis un éléphant? N'importe 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.