Question:
Risques de donner aux développeurs des droits d'administrateur sur leurs propres PC
carolineggordon
2012-05-15 16:33:00 UTC
view on stackexchange narkive permalink

Je dois convaincre mon service informatique interne de donner à ma nouvelle équipe de développeurs les droits d'administrateur sur nos propres PC. Ils semblent penser que cela créera un risque pour la sécurité du réseau. Quelqu'un peut-il expliquer pourquoi cela serait? Quels sont les risques? Qu'est-ce que les services informatiques mettent généralement en place pour les développeurs qui ont besoin de pouvoir installer des logiciels sur leurs PC?

Cette question était la Question de la semaine sur la sécurité informatique .
Lisez le article de blog du 8 juin 2012 pour plus de détails ou envoyez le vôtre Question de la semaine.

Quelque chose semble manquer à cette question: quel type de logiciel est-il censé développer? Application Web? Pilotes graphiques? (Connaître la langue / la plate-forme peut aider.)
Également utile: Ont-ils un laboratoire / poste de travail séparé sur lequel ils devraient faire le développement d'applications? Cette question concerne-t-elle ces systèmes ou systèmes destinés aux systèmes de «bureautique» (c'est-à-dire: édition de documents, courrier électronique, navigation Web)?
Le plus grand risque est que les développeurs puissent réellement faire du travail.
Expliquez-leur que le plus gros risque pour la sécurité de leur réseau est un _ développeur en colère_ ... ou laissez-les simplement l'apprendre à la dure.
Ne soyez pas un développeur en colère. Les informaticiens sont vos collègues qui ont probablement beaucoup en commun avec vous, comme des intérêts pour les systèmes et les réseaux. Connaissez vos informaticiens par leurs prénoms et allez parfois déjeuner avec eux. S'il y a un problème de processus, la première étape consiste à demander à votre responsable d'en discuter avec son responsable.
«Je dois convaincre mon service de développement logiciel interne de donner à mes administrateurs système les droits d'écrire et de déployer leurs propres scripts. Ils semblent penser que cela créera du code spaghetti non maintenable.
Dites-le ainsi: soit donnez aux développeurs des droits d'administrateur, soit les développeurs obtiendront des droits d'administrateur par leurs propres moyens.
Comment allez-vous développer un programme d'installation, ou un service Windows, ou un composant ActiveX, ou une couche de communication interprocessus, ou utiliser un serveur Web intégré sans accès administrateur local?
//, Un service informatique devrait être en mesure de protéger les réseaux de production de leurs environnements de développement, en évitant quelque peu des questions comme celles-ci.
Huit réponses:
#1
+63
Alan Barber
2012-05-15 19:56:20 UTC
view on stackexchange narkive permalink

Partout où j'ai travaillé (en tant que développeur sous contrat), les développeurs ont des droits d'administrateur local sur leurs bureaux.

Les raisons sont:

1) Les outils des développeurs sont souvent mis à jour très régulièrement. Bibliothèques graphiques, assistants de code, mises à jour de Visual Studio; ils finissent par avoir des mises à jour presque hebdomadaires qui doivent être installées. Le support bureautique est généralement très fatigué d'obtenir 20 tickets par semaine pour installer des logiciels mis à jour sur toutes les machines de développement afin qu'ils donnent simplement aux administrateurs des droits de le faire eux-mêmes.

2) Les outils de débogage / test ont parfois besoin droits d'administrateur pour pouvoir fonctionner. Aucun accès administrateur signifie que les développeurs ne peuvent pas faire leur travail de débogage du code. Les gestionnaires n'aiment pas ça.

3) Les développeurs ont tendance à être plus soucieux de la sécurité et sont donc moins susceptibles d'exécuter / d'installer des logiciels malveillants dangereux. Évidemment, cela arrive encore, mais dans l'ensemble, on peut généralement faire confiance aux développeurs pour avoir un accès de plus haut niveau pour pouvoir faire leur travail.

Les droits d'administrateur local n'affectent / ne devraient pas non plus affecter leurs droits réseau. Vous venez de leur donner accès à leur point de terminaison réseau, auquel ils ont de toute façon un accès physique.
Il est à noter que l'accès au matériel de la machine équivaut à l'octroi de droits d'administrateur en termes de sécurité. Un agent malveillant intelligent peut facilement transformer l'un en l'autre.
Dans le passé, sur des systèmes hautement renforcés, j'ai eu un compte "utilisateur de débogage" qui avait les autorisations supplémentaires nécessaires pour exécuter le débogueur de Visual Studio 2003; mais qui n'autorisait aucun autre droit de type administrateur (écritures de registre, installations de logiciels, écriture dans des fichiers programme, etc.).
@DanNeely: Si vous pouvez attacher un débogueur à un processus qui ne vous appartient pas, vous pouvez faire en sorte que ce processus fasse tout ce que vous voulez. Donc droits de débogage = admin.
J'ai besoin d'en savoir plus sur la façon dont les droits d'administrateur local peuvent être accordés sans donner de droits sur le réseau, nos administrateurs informatiques me disent que cela ne peut pas être fait. Tout pointeur vers où je peux lire à ce sujet est apprécié.
@carolineggordon, s'ils sont préoccupés par le reniflement du réseau, il y a peut-être un problème plus large ici. Essentiellement, cela impliquerait que des données sensibles peuvent être transférées sur le réseau, là où les postes de travail normaux sont branchés et où certains employés ne peuvent pas faire confiance. C'est peut-être le problème qui devrait être résolu à la place: obliger les utilisateurs à utiliser des services protégés SSL / TLS pour les données sensibles à la place. Sinon, il y aura toujours un risque (peut-être faible) que quelqu'un branche son propre appareil de capture.
@carolineggordon Dans Windows, c'est très facile à faire. Un administrateur se connecte à l'ordinateur des développeurs et exécute la ligne de commande suivante "domaine \ nom d'utilisateur / add des administrateurs de groupe local réseau"
@JayBazuzi le groupe d'utilisateurs Débogueur (créé par Visual Studio lors de l'installation) permet uniquement à l'utilisateur de déboguer les processus exécutés sous son compte. Ce n'est pas la même chose que SeDebugPrivilege qui vous permet de connecter un débogueur à n'importe quel processus sur la machine. Si je comprends bien l'implémentation, cela fonctionne en exécutant le débogueur sous un autre compte d'utilisateur en l'exposant via un proxy qui effectue un filtrage de propriété avant d'autoriser l'utilisateur à se connecter.
Ce n'est pas non plus le cas où il n'y a pas de différence entre l'octroi de SeDebugUser et des droits d'administrateur local. Du point de vue de la protection, il y a peu de différence car cela donne à l'utilisateur tout ce dont il a besoin pour exploiter son chemin vers un contrôle administratif complet; sa valeur est d'un point de vue général d'administration / maintenance ou d'audit de sécurité dans la mesure où l'utilisateur ne peut pas * accidentellement * faire des actions destructives / abusives qui nécessitent des droits d'administrateur. http://blogs.msdn.com/b/oldnewthing/archive/2008/03/14/8080140.aspx
Donc, le problème est que les administrateurs ne viendront pas me donner cet accès en exécutant cette commande parce qu'ils ne croient pas que quiconque devrait installer le logiciel. Mmm, revenons à ma question initiale. Merci pour toutes les réponses ... c'est un excellent forum!
@carolineggordon, cela ressemble à un cas des administrateurs classiques sur-protecteurs. Donnez-lui un dernier essai pour raisonner avec eux que le fait d'avoir des droits d'installation locaux vous permettra de mieux faire votre travail. S'ils refusent toujours, vous devez commencer à remonter la chaîne de commandement et jouer au jeu tellement amusant de la politique d'entreprise.
#2
+28
Bruno
2012-05-15 21:50:39 UTC
view on stackexchange narkive permalink

Cela dépend en partie du type de logiciel que l'équipe de développement devrait développer. Certains types de logiciels sont plus faciles à développer sans droits d'administration que d'autres.

Par exemple, vous pouvez faire une bonne quantité de développement Java basé sur le Web en utilisant des artefacts comme Eclipse avec Maven, tous installés localement (et généralement testé sur le port 8080), sans avoir besoin de beaucoup de droits d'administrateur (vous devrez peut-être ouvrir certains ports). Le développement d'outils nécessitant un accès plus étroit au matériel peut s'avérer impossible sans droits d'administrateur.Cela étant dit, même pour le développement Web, il est bon de pouvoir reconstruire une machine de test à partir de zéro (généralement une VM), ce qui peut nécessiter des droits d'administrateur. .

S'il s'agit de confiance (c'est-à-dire que certains membres de votre équipe de développement pourraient avoir des intentions malveillantes), vous avez quand même des problèmes. Il est peu probable que les administrateurs système qui approuveraient / désapprouveraient certains droits puissent vérifier en détail ce que fait le code qu'ils ont écrit.Cela ne signifie pas non plus que vous devez donner à votre équipe de développement un accès illimité à vos services de production, ni que ils devraient avoir un accès administrateur sur plus de machines que nécessaire, bien sûr. Il est bon d'avoir des mécanismes en place pour atténuer les risques, mais vous aurez besoin d'un niveau de confiance de base pour que votre organisation fonctionne. Mettre l'équipe de développement sur un réseau physique distinct est une première étape pour atténuer les problèmes de confiance et les erreurs possibles.

Un risque typique d'avoir quelqu'un avec un accès administrateur est de pouvoir capturer des paquets sur le réseau. C'est un risque que vous devrez peut-être accepter selon la nature de ce qui est développé. Des outils comme Wireshark peuvent parfois être utiles pour le développement. Même au sein de votre organisation, les informaticiens ou les non-informaticiens devraient utiliser des services avec SSL / TLS activé si possible, cela devrait aider contre les écoutes clandestines et les attaques MITM.

Je peux penser à quelques inconvénients lorsque je ne donne pas l'administrateur aux développeurs accès (à moins qu'ils n'en aient vraiment besoin):

  • Cela peut créer une culture «eux contre nous» entre les développeurs et les administrateurs système de votre organisation. Cela existe déjà dans de nombreux endroits, mais ce n'est généralement pas une bonne chose. Chaque équipe est susceptible de considérer l'autre comme une douleur. La sécurité n'est pas un problème purement technique, mais aussi un problème d'interaction humaine. Je pense qu'une bonne communication humaine devrait aider les objectifs généraux de votre organisation en général, pas seulement d'un point de vue de sécurité en fait. (J'ai toujours trouvé que je pouvais trouver de meilleures solutions après avoir parlé en personne aux administrateurs système avec lesquels je devais résoudre des problèmes plutôt que de répondre à un ticket sans visage.)

  • La nature humaine est telle que les gens deviennent créatifs lorsqu'ils sont limités, mais pas nécessairement de la bonne manière. Vous constaterez peut-être que les développeurs finissent par mettre beaucoup d'efforts (et réussissent souvent) à contourner les limitations qui leur sont imposées au sein de l'organisation. Ils devraient utiliser leur créativité sur ce qu'ils sont censés faire à la place.

  • Les systèmes informatiques sont complexes et le débogage est un art sombre. Si vous devez déboguer votre produit par rapport aux versions a.b.c_13 et a.b.c_24 de la bibliothèque XYZ, les développeurs peuvent avoir besoin de pouvoir installer et désinstaller chaque version, ce qui peut à son tour nécessiter un accès administrateur. Chasser les bogues qui dépendent des numéros de version est déjà ennuyeux. Si vous devez lever un ticket et attendre (peut-être des heures ou des jours) que quelqu'un d'autre installe / désinstalle la bonne version en fera un cauchemar: cela augmentera le problème culturel «eux contre nous» et, plus important encore, cela vous coûtera plus à l'organisation. Vous pouvez penser à cela du point de vue de l'évaluation des risques / coûts.

La raison la plus importante de NE PAS donner à un programmeur les droits d'administrateur est le fait qu'il fera la même erreur que les gens ont faite depuis des années, et ne testera pas son code en tant qu'utilisateur limité, car dans la version actuelle de Windows, il y a des dossiers protégés.
@Ramhound, ce n'est pas tant un problème de sécurité mais une mauvaise pratique de développement. Avoir des droits d'administrateur ne signifie pas que vous devez tout exécuter avec tous les privilèges à tout moment, même en tant que développeur.
@Ramhound - C'est pourquoi vous avez une équipe d'assurance qualité distincte avec un plan de test écrit. Ce n'est pas une excuse pour monopoliser vos développeurs pour le bien de la construction d'un empire informatique.
#3
+10
dan
2012-05-17 02:18:04 UTC
view on stackexchange narkive permalink

Le risque est une fonction d'accès croissante

Il existe une règle simple de calcul des risques qui explique la peur de vos collègues de l'équipe informatique. Plus vous avez d'accès sur n'importe quel système d'exploitation, plus les impacts de toute erreur ou attaque sont élevés.
Par exemple, si l'un de vos collègues, disons Bob, est attaqué par une attaque de phishing standard, alors le compte Bob est disponible pour cyber -criminel et vendu sur Internet en quelques minutes. Si le compte Bob a des privilèges d'administrateur, ce compte sera utilisé pour envoyer du SPAM à grande échelle sur Internet, puis pour voler d'autres comptes avec des attaques de phishing à grande échelle, et très rapidement (en quelques minutes) ouvrira une porte dérobée à votre réseau (cela est possible car le compte Bob est un compte administrateur) permettant un contrôle total à distance du PC de Bob (via des outils comme ssh , VNC , VPN ...). Cette attaque initiée depuis un PC interne, depuis un compte privilégié est capable de briser n'importe quel pare-feu, d'arrêter toute protection anti-virus, anti-spam.

Le mal est à l'intérieur .

Même vos meilleurs administrateurs réseau, administrateurs système ou administrateurs de sécurité peuvent laisser ce PC corrompu inaperçu pendant des mois (cf. Stuxnet ).

Réduction des faux risques

Si vos collègues développeurs maîtrisent bien le système d'exploitation sur lequel ils fonctionnent et ont un accès physique à l'ordinateur, alors cette différence en risque est nulle.

Tout ingénieur sur n'importe quel système d'exploitation
peut s'octroyer un accès administrateur
s'il dispose d'un accès physique à l'ordinateur.

Blocage l'accès administrateur sur n'importe quel système d'exploitation est une approche valable de réduction des risques pour les utilisateurs qui ne peuvent pas faire la différence entre les privilèges d'administrateur et les privilèges d'utilisateur normaux. Voici la question clé que je poserais à vos collègues de l'équipe de développement et agirais en fonction de leur conscience du risque:

"De quoi vous occuperez-vous si on vous accorde
privilège d'administrateur sur votre système d'exploitation? "

S'ils sont assez bons pour être conscients des risques, alors ils sont assez bons pour obtenir l'accès qu'ils veulent. Il n'y a alors aucune réduction des risques dans en leur refusant cet accès administrateur.Méfiez-vous: il y a un risque collatéral pour votre entreprise dans son ensemble si vous leur refusez un accès qu'ils peuvent facilement obtenir: ils le feront à la manière sale, ils se comporteront comme des hors-la-loi, ils ne pourront pas demandez de l'aide, ils devront couvrir tout incident.

#4
+8
Todd Dill
2012-05-16 08:52:09 UTC
view on stackexchange narkive permalink

Quelques éléments qui n'ont pas été mentionnés dans les réponses et commentaires précédents qui seraient un argument pour les développeurs travaillant sous le moindre privilège:

  1. En fonction du secteur dans lequel vous travaillez , il peut y avoir des raisons légales ou réglementaires qui empêchent les employés d'avoir des privilèges élevés sur leurs postes de travail. Autoriser l'accès administratif aux développeurs peut exposer l'organisation au risque de ne pas être conforme.

  2. Lorsque les composants sont développés avec des privilèges élevés, il peut y avoir un risque d'échec lors du déploiement sur d'autres les environnements qui ne disposent pas de ces privilèges. Les développeurs peuvent avoir mis à niveau ou ajouté par inadvertance des bibliothèques à leurs machines locales qui n'existent pas dans d'autres environnements, et les composants peuvent avoir des dépendances sur des versions spécifiques de ces bibliothèques. De même, les comptes d'utilisateurs sous lesquels les composants seront exécutés dans d'autres environnements peuvent ne pas avoir la base de données requise ou un autre accès qui a été supposé par le développeur travaillant avec des privilèges élevés. J'ai vu cela se produire à plusieurs reprises dans le passé. Parfois, il est évident pourquoi le déploiement a échoué, parfois ce n'est pas le cas, et vous devez tout annuler jusqu'à ce que vous puissiez le comprendre.

  3. Si les développeurs installent des outils ou des bibliothèques open source et utilisent ceux pour le développement, il pourrait y avoir des restrictions de licence involontaires sur la façon dont le logiciel qu'ils produisent est finalement distribué, en particulier lorsque les termes «copyleft» font partie de la licence. Il n'y a rien de mal à utiliser des outils ou des bibliothèques open source, cela devrait simplement être intentionnel. Vous ne voulez pas savoir lors de la livraison que vous devez maintenant publier tout votre code source dans la communauté, car vos développeurs ont utilisé un composant open source qui avait des termes de copyleft stricts dans la licence qu'ils n'avaient pas vraiment lus avant de installé.

Quelque chose que j'ai vu faire est de faire travailler les développeurs avec le moindre privilège, mais de leur permettre de demander des privilèges élevés pendant une période de temps spécifiée. Ensuite, cette demande "d'appel d'incendie" pour les privilèges élevés qu'elle a enregistrés et surveillés, et est réinitialisée automatiquement à la fin de l'heure demandée.

Le point 1 est délicat. J'ai vu des organisations essayer de restreindre l'utilisation à des logiciels approuvés, mais il est bien sûr pratiquement impossible d'auditer un logiciel pendant son développement. Le point 2 est juste une bonne pratique de développement / test, il n'a pas grand-chose à voir avec la sécurité du poste de travail de développement lui-même. Le point 3 est juste une pratique de développement normale aussi, cela n'a rien à voir avec l'open / close source: tout logiciel ou bibliothèque utilisé aura une licence qui doit être respectée, les développeurs doivent toujours vérifier s'ils ont ou non des droits d'administrateur. (Notez que très peu d'outils OSS * * impliquent que ce pour quoi ils sont utilisés doit être OSS.)
2. Doit être géré par un serveur d'intégration continue
#5
+8
wrb
2012-05-27 14:18:45 UTC
view on stackexchange narkive permalink

Vous leur donnez les droits d'administrateur local sur leur poste de travail et tout ce qu'ils veulent. L'environnement de développement est toujours isolé du réseau principal. C'est le travail du service informatique de s'assurer que vous leur fournissez la configuration dont ils ont besoin tout en vous assurant que rien dans l'environnement de développement ne peut nuire au réseau principal. Planifiez à l'avance et travaillez avec la direction pour acheter l'équipement / logiciel dont vous avez besoin pour y parvenir.

#6
+4
Ramhound
2012-05-15 17:12:58 UTC
view on stackexchange narkive permalink

Vous avez quelques questions à répondre.

  1. Quelles applications ces développeurs doivent-ils utiliser quotidiennement nécessitent des privilèges d'administrateur et existe-t-il un moyen de configurer ces applications pour que ce ne soit pas le cas?
  2. Pour quelles raisons ces développeurs ont-ils besoin de privilèges d'administrateur pour effectuer des tâches quotidiennes triviales et y a-t-il un moyen d'éviter cela?
  3. Ces machines de développement sont-elles connectées à Internet?
  4. La question ne devrait pas être de savoir quels sont les risques, la question devrait être (à laquelle vous ne pouvez que répondre) quelles sont les raisons pour lesquelles les développeurs ont même besoin d'avoir un compte administrateur. Vous pouvez les créer avec un compte "utilisateur expérimenté" et leur donner la possibilité de faire exactement ce dont ils ont besoin, mais aussi de limiter leur capacité à nuire à votre réseau.

    Si ces machines sont connectées à Internet. ... alors vous introduirez une grande quantité de risques en raison de leur capacité à exécuter n'importe quoi et à installer n'importe quoi sur ces machines. Ces développeurs sont de bons développeurs, ce ne sont pas des experts en sécurité, il ne s'agit que de savoir QUAND ils feront une erreur qui expose le réseau à des logiciels malveillants.

    Jetez un œil à Google par exemple. Un employé de Google clique sur un lien contenu dans une fenêtre de MSN Messenger, télécharge un malware qui a profité d'un exploit déjà corrigé par Microsoft et infecte l'ensemble du réseau.

    Je devrais ajouter l'employé de Google en cliquant sur le lien n'avait rien à voir avec cette question, c'était pour le souligner, les gens vont faire une erreur alors limitez votre exposant.

L'infection du réseau de Google ne serait-elle pas la faute du service informatique pour ne pas avoir installé le correctif existant à partir de MS?
@Andy - C'est mon point.Un employé les a encore exposés à la menace.
Mais rien ne se serait produit si le service informatique avait appliqué le correctif en temps opportun.S'attendre à ce que les humains ne commettent jamais d'erreurs semble être une façon assez idiote de gérer la sécurité.
Je tiens à souligner que tous les employés de Google ne sont pas des développeurs, c'est peut-être la dame qui commande les fournitures de bureau.
La question portait spécifiquement sur l'octroi de droits d'administrateur aux développeurs.L'employé de Google dans ce cas peut vraisemblablement être un développeur.C'était aussi juste un exemple.
#7
+4
DKNUCKLES
2012-05-15 18:09:22 UTC
view on stackexchange narkive permalink

Les risques de sécurité associés à la possibilité pour les développeurs d'installer leurs ordinateurs sont nombreux. Voici pourquoi je m'opposerais (parlant en tant qu'administrateur système)

1) Violation potentielle des meilleures pratiques de sécurité - L'une des 8 règles de sécurité est la règle du moindre privilège - uniquement donner aux employés l'accès à ce dont ils ont besoin pour accomplir leur tâche. Si quelqu'un me disait que son développeur avait besoin d'un accès administrateur pour installer le logiciel pour faire son travail, je répondrais par "Pourquoi un membre de mon équipe ne peut-il pas l'installer pour lui?". Disposer d'un point centralisé pour l'installation des logiciels garantit qu'un service informatique sait exactement quel logiciel se trouve sur quelle machine.

2) Raisons juridiques - Peut-être que l'un de vos développeurs a une éthique moins qu'admirable et décide d'installer un logiciel piraté. Non seulement ce logiciel est probablement criblé de logiciels malveillants, mais vous ouvrez ensuite une boîte de vers pour les litiges si vous êtes pris avec un logiciel piraté sur votre ordinateur. Un service informatique est considéré comme responsable de ces ordinateurs et, à ce titre, il est chargé de les auditer et de s'assurer que la licence est conforme aux conditions d'utilisation de chaque logiciel. Bien que cela soit pratique pour les développeurs dans la mesure où ils peuvent installer leur propre logiciel sans déranger le service informatique, vous créez beaucoup plus de travail pour le service informatique.

3) Installation involontaire de logiciels malveillants - mentionné auparavant, mais cela pourrait être assez innocent. Élever les privilèges des utilisateurs afin qu'ils puissent installer des logiciels malveillants les rend vulnérables aux logiciels malveillants en ouvrant un PDF infecté qu'ils ont obtenu via un e-mail ou un lecteur par téléchargement. Limiter l'accès des utilisateurs afin qu'ils ne puissent pas installer de logiciel contribuera à atténuer la menace des logiciels malveillants.

4) Activité malveillante - Similaire au point 2, mais comment dire que l'un de vos développeurs ne va pas installer une porte dérobée ou ouvrir délibérément une autre menace de sécurité sur votre réseau? Vous seriez surpris de voir combien de professionnels de l'informatique font cela pour se venger s'ils devaient être licenciés ou si leur patron les faisait chier.

Dans l'ensemble, je devrais le déconseiller. Bien que les gens puissent affirmer que cela leur permettrait de gagner du temps en les empêchant de toujours bogue informatique pour installer des logiciels, je dirais que "cela prend moins de temps pour faire cela que pour corriger les failles de sécurité créées en permettant aux utilisateurs d'installer leur propre logiciel" . Si cela est jugé nécessaire, ils devraient vraiment être placés sur un réseau qui n'a pas d'accès direct au monde extérieur.

Presque tout cela peut être fait sans privilèges d'administrateur. De nombreux logiciels ne nécessitent pas l'installation de privilèges d'administrateur. La seule façon d'éviter la plupart d'entre eux est d'avoir une liste blanche de logiciels, mais c'est évidemment impossible pour les développeurs.
D'accord, mais du point de vue de "vous couvrir le cul", cela semble assez mauvais si votre réseau est compromis et que vous avez eu des politiques peu rigoureuses en ce qui concerne l'installation de logiciels. En tant qu'administrateur système, vous serez celui avec un œuf sur le visage et celui qui travaillera pour résoudre le problème.
"8 règles de sécurité"? Il n'y en a que 8?
1, 2 et 3 sont tous vrais, cependant l'attachement d'un débogueur à un processus exécuté en tant qu'un autre utilisateur nécessite un administrateur local. Visual Studio 2005 recommande de toujours l'exécuter en tant qu'administrateur. L'installation des services Windows nécessite un administrateur. Ce sont toutes des choses que je dois faire en tant que développeur, certaines plus souvent que d'autres, ce qui signifie que l'administrateur local est une autorisation dont j'ai besoin pour faire mon travail. Pour le point 4, je dirais que le développeur a un accès physique au poste de travail, donc s'ils étaient malveillants, ils pourraient obtenir des droits d'administrateur, à moins que le PC ne soit verrouillé.
Vous faites un point valable pipTheGeek - peut-être ai-je sauté le pistolet. Tous les développements qui ont eu lieu dans les bureaux dans lesquels j'ai travaillé ont pu faire leur travail sans administrateur local. Merci pour la perspicacité.
Je voterais contre cette réponse si je le pouvais. Je ne vois pas comment ces problèmes ne peuvent être résolus avec une bonne communication avec les développeurs. Si vous ne faites pas confiance à un développeur pour répondre aux exigences que vous avez mentionnées, il serait préférable de ne pas l'embaucher en premier lieu. Je pense que restreindre les privilèges d'administrateur aux utilisateurs avancés (non approuvés?) Qui ont un accès complet à leur matériel est naïf, c'est le moins qu'on puisse dire.
Je rétorquerais en "faisant confiance à l'utilisateur" d'être naïf, c'est le moins qu'on puisse dire. La question (et la réponse) n'était pas SI possible, mais plutôt des considérations de sécurité potentielles. À aucun moment je ne dis que ce qui est listé ci-dessus est à toute épreuve, mais plutôt ce qu'un directeur informatique ou un administrateur système peut identifier comme des risques de sécurité. Bien que je puisse respecter les critiques, elles seraient plus valables si j'avais commencé «voici comment durcir efficacement votre réseau».
En tant que développeur professionnel, je dirais que j'ai besoin de votre approbation pour installer un logiciel, vous feriez mieux de ne pas écrire de scripts sans le mien.
+1 Même si je ne suis pas d'accord avec les raisons, la question initiale était précisément de savoir quels arguments les administrateurs système pourraient donner, afin qu'ils puissent être discutés / négociés. c'est la seule réponse qui explique cela.
+1 Cette réponse serait pratiquement complète si elle incluait le spectre de la régulation comme indiqué dans une autre réponse.
Le personnel de support informatique qui corrige les tickets triviaux a-t-il un accès administrateur aux machines locales (comme j'ai besoin d'installer / mettre à niveau un nouveau programme / bibliothèque; redémarrer le serveur Web; etc.)? Un développeur professionnel est généralement plus soucieux de la sécurité que les résolveurs de tickets de bas niveau. Une bonne politique est la défense contre les logiciels piratés / les utilisateurs malveillants (annoncer une infraction pouvant être activée pour le piratage; avoir un protocole de résiliation pour supprimer les comptes, sauvegarder hors ligne et re-flasher leur PC). La sécurité de votre réseau doit détecter et empêcher une machine d'utilisateur final compromise d'affecter d'autres machines (vous avez donné un accès physique).
Outre les points soulevés par PipTheGeek, presque tous les développeurs ont leur ensemble privé d'outils d'aide qu'ils utilisent afin d'être plus productifs au travail (raccourcis clavier, luanchers, snippet-orgenizers, générateurs de code, grep, Notepad ++, etc ...) En outre, ils utilisent des outils sysinternals comme l'explorateur de processus pour tuer les processus suspendus. Ils doivent également accéder aux journaux d'événements et à d'autres composants logiciels enfichables MMC, et utiliser des outils tels que regsvr32.exe pour enregistrer leur contenu COM ... la liste s'allonge encore et encore ... Je ne peux pas imaginer faire mon travail sans être au moins administrateur local . Au lieu de cela, lancez-moi le domaine, ne fournissant qu'un accès Internet.
Bien que cela semble raisonnable du point de vue de la sécurité, c'est complètement irréaliste en réalité et irréalisable pour un développeur. De plus, en tant que développeur, me restreindre l'accès pour faire mon travail ne fait que me * supplier * de contourner votre sécurité. S'il y a une personne dans l'entreprise, vous ne voulez * pas * faire cela ...
#8
+2
Louis Somers
2012-05-27 03:57:13 UTC
view on stackexchange narkive permalink

Une solution de contournement consiste à installer une machine virtuelle, non connectée au domaine. Ce sera assez compliqué mais c'est mieux que d'être totalement paralysé par les politiques.

Pour les futurs lecteurs: cela ne fonctionnera pas pour les développeurs d'applications mobiles qui nécessitent l'utilisation d'un émulateur de périphérique.Les émulateurs de périphérique sont également des machines virtuelles et vous ne pouvez pas exécuter une machine virtuelle dans une machine virtuelle.Notez également que si vous utilisez un IDE moderne (Visual Studio, Intellij IDEA, Eclipse), les mauvaises performances de ces outils dans une VM vous rendront la vie misérable.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...