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.

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.

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.

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.

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.

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?

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.

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.

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.