Verrouiller une machine de développeur demande-t-il plus d'efforts que cela ne vaut? [fermé]

Ayant travaillé en tant que développeur et administrateur / support informatique pour une équipe de développement, je suis tombé sur de nombreux types d'environnement, du complètement verrouillé au complètement non. Dans mon expérience de support limitée, je pense que cela a été moins d'effort pour prendre en charge avec une machine moins verrouillée et j'ai certainement pensé que c'était plus facile, mais bien sûr, cela pourrait être un parti pris. J'aimerais savoir quel est le point de vue du support informatique, est-il vraiment plus difficile de soutenir les développeurs qui ont des machines non verrouillées?

Le plus gros problème de ne pas verrouiller une machine de développeur est que tout logiciel qu'ils développent nécessitera des privilèges d'administrateur complets pour s'exécuter. L'accès des développeurs doit être le même que l'environnement dans lequel ils devront s'exécuter. S'ils doivent être "auto-supportables" ou "auto-installables", donnez-leur un autre compte administrateur, par exemple Bruce.admin, qu'ils doivent utiliser lors de l'administration mais pas utilisé au jour le jour.

Tout comme aucun administrateur UNIX décent digne de ce nom n'utilisera un compte root pour son travail quotidien non administrateur.

La plupart des développeurs sont techniquement avertis et savent ce qu'ils font. Ils ont souvent besoin d'installer de nombreuses applications spécialisées, d'avoir à obtenir la permission de le faire et de faire en sorte que le service informatique tombe en panne et l'ajoute peut être très frustrant, en particulier dans les grandes entreprises, pour les deux parties.

J'ai trouvé que ce qui fonctionne le mieux est de leur permettre de faire ce qu'ils veulent en ce qui concerne l'installation de logiciels sur leurs machines, mais s'ils rencontrent des problèmes avec quelque chose que nous ne prenons pas en charge, alors ils sont seuls. La plupart des développeurs en sont satisfaits et préfèrent de toute façon pouvoir s'occuper de leur propre machine.

Verrouiller quelqu'un dans la comptabilité pour utiliser uniquement IE et Word ouvert est bien, mais si vous êtes un développeur qui a besoin d'installer 4 types de navigateur différents et qui doit installer rapidement une application pour résoudre un problème, cela peut être ennuyeux.

D'après mon expérience, les entreprises qui ont beaucoup de connaissances techniques, donc les ateliers de développement, les fournisseurs informatiques, etc., qui font confiance à leurs employés et les laissent décider ce qu'ils veulent installer sont beaucoup plus heureuses et dérangent moins l'informatique

Voir cette publication Stackoverflow pour un débat animé sur les avantages de verrouiller les machines de développement. (Avertissement: j'ai écrit la réponse acceptée).

Du point de vue d'un administrateur système, l'accès aux systèmes de production est sensible et vous devez restreindre cet accès aux personnes qui en ont besoin pour faire leur travail (cela peut inclure les développeurs qui ont des responsabilités de support de niveau 3 pour l'application). Les droits d'administrateur local sur un PC de développement ou un serveur de développement ne compromettent pas de manière significative la sécurité de vos systèmes de production.

Créez une image que vous pouvez utiliser pour reconstruire les machines avec si nécessaire. L'installation manuelle de SQL Server dev edition, Visual Studio, Cygwin et MikTex ainsi que de nombreuses autres applications prend beaucoup de temps. Une image avec ces grandes applications installées sera raisonnablement précieuse si vous devez beaucoup recréer l'image des machines.

Du point de vue du développement, je trouve que je peux résoudre la plupart des problèmes avec la machine et que je n'ai généralement besoin que de l'aide du personnel de support réseau en de rares occasions. Les environnements trop restrictifs ont tendance à générer un trafic de support de développement parasite pour effectuer des travaux que les développeurs sont parfaitement capables de faire eux-mêmes.

Un autre endroit où les développeurs ont généralement besoin de beaucoup de travail administratif est sur les serveurs de bases de données hébergeant des environnements de développement. La plupart des développeurs sont capables d'apprendre facilement les tâches DBA de routine et devraient de toute façon en avoir une connaissance pratique (IMHO en principe). Les stratégies d'accès administrateur trop restrictives sur les serveurs de développement peuvent être sous-jacentes de plusieurs manières.

Un réseau de développement à zéro est une bonne idée s'il peut être organisé - vous pouvez le pare-feu à partir de vos serveurs de production si nécessaire.

• Lorsque les développeurs peuvent facilement répliquer la structure d'un environnement de production, cela favorise une culture de tests de déploiement où un test d'intégration peut être synthétisé sans passer par des cercles. Cela aura tendance à améliorer la qualité des versions de production et du déploiement.

• La possibilité d'émuler un environnement de production permet également de prendre conscience des problèmes de déploiement et de support de la production. Il encourage le personnel de développement à réfléchir à la façon dont une application peut être prise en charge en production, ce qui encouragera probablement les architectures conçues dans cet esprit.

• Si ce réseau possède un contrôleur de domaine, vous pouvez établir une relation d'approbation afin qu'il approuve votre contrôleur de domaine principal et ses comptes. Cette relation de confiance ne doit pas être réciproque, elle ne compromet donc pas la sécurité de votre infrastructure de réseau de production. Cela peut vous permettre d'avoir un réseau de développement non fiable, mais permet toujours aux développeurs d'accéder aux ressources authentifiées par domaine telles que les comptes Exchange ou les serveurs de fichiers.

• Vous voulez que les développeurs aient une marge de manœuvre raisonnable pour l'expérimentation sans avoir à sauter à travers des cercles. Placer des obstacles politiques sur le chemin de ces travaux a tendance à encourager le collage de solutions de plâtre qui sont politiquement opportunes mais génèrent une dette technique à long terme (et souvent non reconnue). En tant qu'administrateur système ou analyste de support, devinez qui peut récupérer les pièces ...

J'ajouterai que c'est beaucoup moins un problème sur un environnement unix ou linux; les utilisateurs peuvent assez fortement personnaliser leur propre environnement à partir de leur .profile. Vous pouvez compiler et installer des choses sous votre propre /home/bloggsj/binrépertoire pour le plus grand plaisir de votre cœur. Les «droits d'administrateur local» sont principalement un problème Windows, bien qu'il y ait encore quelques choses qui nécessitent un accès root sous Unix.

L'option la plus sensée que j'ai jamais vue (qui a été des deux côtés - et qui l'est toujours) - est simplement déverrouillée et non prise en charge . Donnez-leur la liberté, et s'ils bousillent, tout ce qu'ils peuvent obtenir est un restage avec une image standard .... Dans cette situation, je trouve que c'est un bon plan de les mettre sur une certaine forme de réseau "non fiable".

En ce qui concerne le (non) sens du verrouillage des bureaux des développeurs: je suis sûr que tout le verrouillage ne fait que nuire à la productivité de toute façon, de plus, tout développeur raisonnablement qualifié trouvera facilement les trous ....

La réponse est vraiment: il n'y a pas de réponse simple oui ou non. Mais la sécurité est au moins aussi importante pour vos utilisateurs de développement que pour n'importe qui d'autre.

D'une part, oui, les développeurs ont tendance à être techniquement plus avertis. D'un autre côté, leur travail est souvent stressant et leurs étapes de développement sont susceptibles de prendre le pas sur les soins supplémentaires nécessaires pour maintenir leur propre système en tant qu'environnement sécurisé. Ce n'est pas une critique des développeurs; c'est une considération directe de leurs tâches quotidiennes.

Si vous allez donner aux développeurs un accès complet et sans entrave à leurs systèmes, vous devriez vraiment envisager les mesures supplémentaires suivantes:

• Fournissez un autre système, verrouillé autant que les systèmes utilisateur normaux, pour une utilisation normale sans dev.
  • Ils mettent leurs machines de développement à accès complet dans un VLAN spécial, avec accès uniquement aux ressources de développement.
• Demandez si quelque chose empêcherait un système infecté de mettre en danger la base de code. Une machine détournée pourrait-elle archiver du code malveillant ou effacer la base de code entre les mains d'un pirate hostile? Prenez les mesures appropriées pour atténuer ce risque.
• De même, demandez si quelque chose protège les données commerciales détenues dans les systèmes auxquels les développeurs ont accès.
• Effectuez régulièrement un inventaire des logiciels et un audit de sécurité des systèmes de développement.
  • Faites-vous une idée de ce qu'ils exécutent et utilisez ces informations pour créer vos images de redéploiement de système de développement.
  • Tôt ou tard, vous aurez un développeur qui devient négligent et installe des choses clairement dangereuses ou complètement sans rapport avec le travail. En envoyant rapidement des avertissements lorsque cela se produit, vous informerez la communauté des développeurs que oui, quelqu'un regarde et qu'ils ont la responsabilité de respecter des normes raisonnables.
• Faites-vous régulièrement des analyses de logiciels malveillants? Dans certains cas, les développeurs se plaindront à juste titre de la taxe sur les performances perçue par les systèmes audiovisuels à l'accès (ces systèmes audiovisuels qui sont toujours activés, scannant toujours à chaque accès aux fichiers). Il peut être préférable de passer à une stratégie d'analyse nocturne et / ou de créer des exclusions de fichiers / dossiers à votre analyse sur accès. Assurez-vous cependant que les fichiers exclus sont analysés d'une autre manière.
  • Vos développeurs avec admin peuvent-ils désactiver toutes les analyses AV? Comment pourriez-vous détecter et corriger cela?

Si vous envisagez de verrouiller des systèmes de développement, vous devez prendre en compte les éléments suivants:

• Avez-vous la capacité d'assistance pour répondre rapidement à leurs demandes d'assistance? Tenez compte du taux de rémunération moyen de vos développeurs et demandez-leur s'ils méritent ou non un SLA à temps de réponse plus rapide. Il n'est probablement pas logique de laisser votre développeur de 120 000 $ (qui est la clé d'un projet de plusieurs millions de dollars) attendre pendant que vous gérez les demandes d'assistance de 60 000 $ par an.
• Avez-vous une politique claire et sans ambiguïté sur les demandes de support que vous répondrez ou non à vos développeurs? S'ils commencent à ressentir que le soutien est arbitraire, vous finirez par ressentir la douleur.

Quoi qu'il en soit, vous devez admettre que les développeurs sont un cas spécial et qu'ils ont besoin d'un support supplémentaire quelconque. Si vous ne prévoyez pas de budget pour cela, les problèmes s'atténuent probablement en ce moment ... ou le seront à l'avenir.

En remarque, j'ai vu des arguments très similaires se produire avec les administrateurs système. Sur au moins deux tâches différentes, j'ai vu des administrateurs système se disputer assez acrimoniquement lorsqu'il a été suggéré qu'ils devraient eux-mêmes avoir verrouillé les systèmes, ou au moins utiliser deux connexions (une avec des privilèges root / admin; une sans). De nombreux administrateurs système ont estimé qu'ils ne devaient en aucun cas être verrouillés et ont vigoureusement plaidé contre de telles mesures. Tôt ou tard, un administrateur opposé au verrouillage aurait un incident de sécurité et l'exemple aurait un effet éducatif sur nous tous.

J'étais l'un de ces administrateurs système qui fonctionnaient avec des privilèges d'administrateur tout le temps. Lorsque j'ai changé de compte double et que je n'ai augmenté que si nécessaire, j'avoue que c'était assez frustrant au cours des premiers mois. Mais la médaille d'argent dans le cloud était que j'en apprenais beaucoup plus sur la sécurité des systèmes que j'administrais, lorsque mon compte normal vivait sous les mêmes restrictions que celles que j'imposais aux utilisateurs. Cela m'a fait un meilleur administrateur! Je soupçonne que c'est la même chose pour les développeurs. Et heureusement, dans le monde Windows, nous avons maintenant l'UAC, ce qui facilite l'exécution en tant qu'utilisateur limité et n'élève que lorsque cela est nécessaire.

Personnellement, je ne pense pas que quiconque devrait être au-dessus d'une certaine forme de pratiques de sécurité. Tout le monde (administrateurs système, développeurs, cadres supérieurs inclus) devrait être soumis à suffisamment de procédures de sécurité et de surveillance pour les garder sur leurs gardes. Dire le contraire, c'est dire que les systèmes et les données de l'entreprise ne valent pas la peine d'être protégés.

Mettons les choses autrement. Si Mark Russinovich peut être capturé par un rootkit , tout le monde le peut!

Lorsque vous avez quelques développeurs, l'approche pour leur donner des serveurs de développement est une possibilité, mais si vous avez un étage complet de développeurs, je suis tout à fait contre leur donner des droits d'administrateur.

Le problème est que vous vous retrouverez avec un étage entier de développeurs, chacun faisant ce qu'il fait, généralement la plupart ne sont même pas soucieux de la sécurité et veulent simplement que leur application fonctionne. Ensuite, vous serez frappé par une demande de - "Nous avons terminé la phase de développement, veuillez répliquer notre environnement de développement sur test, pré-prod et prod".

Ils prennent également l'habitude d'installer des fichiers indésirables (logiciels mal emballés), puis vous délèguent de les installer sur la douzaine de serveurs des autres niveaux.

Je fais la politique assez simple:

• Les développeurs n'obtiennent PAS d'accès root - jamais - pour l'environnement de développement.
• Les développeurs obtiennent un accès root aux serveurs VMware antérieurs au développement, mais AUCUN support.
• Les développeurs doivent fournir des packages RPM qui appartiennent à la distribution du système d'exploitation sur laquelle leur application s'exécutera, OU, des packages RPM conformes aux normes FHS et LSB.
• Aucune de leurs applications ne peut en aucun cas s'exécuter en tant que root
• Le n'aura pas accès à suou sudoà l'utilisateur de l'application - qui sera verrouillé pour n'avoir AUCUN accès au shell. (C'est pour la comptabilité / audit).
• Toutes les commandes dont ils ont besoin pour s'exécuter avec un accès privilégié devront être explicitement demandées et approuvées - date à laquelle elles seront ajoutées au sudoersfichier.
  • Aucune de ces commandes / scripts ne sera inscriptible par eux.
  • Aucune référence de script (directement ou indirectement) par ces commandes ne sera accessible en écriture par elles.

Ce qui précède leur permettra avant tout de réfléchir à ce qui sera et ne sera pas autorisé au moment de déplacer le projet sur les serveurs de test et ci-dessus.

Le verrouillage des machines des développeurs demande plus d'efforts qu'il n'en vaut la peine. Cela nuit gravement à la productivité, car vous ne pouvez pratiquement rien faire sans droits administratifs. Bien sûr, le système finira par être gâché, mais votre responsable informatique ne fournit certainement pas de support pour tous ces outils tiers utilisés dans le développement?

Ainsi, comme l'a suggéré Vincent De Baere, la meilleure solution serait de simplement restaurer le système à partir d'une image, bien sûr, l'environnement doit être restauré après cela, mais cela ne devrait pas être le problème informatique. Si cela se produit N fois, vous pouvez mettre une telle personne sur une sorte de "liste noire" et, oui, abandonner ses droits administratifs pendant un certain temps.

Quoi qu'il en soit, l'environnement doit être configuré de manière à garantir qu'une machine infectée (ou autrement gâchée) n'affecte aucune autre machine ou, par exemple, n'envoie pas de spam ou quelque chose (ok, maintenant Je dis juste des choses évidentes, désolé).

Eh bien, cela peut dépendre en partie de l'environnement dans lequel vous exécutez (par exemple Linux contre Windows); Cependant, en supposant un environnement Windows, cela pose généralement plus de problèmes que cela ne vaut simplement parce que certains logiciels de développement nécessitent que vous ayez des autorisations élevées pour travailler. Par exemple, Visual Studio est connu pour nécessiter des autorisations d'administrateur , en tant que tel, je ne vois pas l'avantage de faire passer quelqu'un à travers des cerceaux pour une partie requise de son travail.

Cependant, si l'entreprise exige que les choses soient verrouillées, votre meilleur pari est susceptible de donner à tous les développeurs des machines virtuelles sur leurs systèmes dans lesquelles ils peuvent devenir fous. Bien que certains puissent ne pas aimer cela, cela vous donnera probablement le meilleur des deux. mondes (par exemple, un bureau normal restrictif et un environnement entièrement personnalisable).

Mise à jour - Du côté de Windows, il y a un peu plus à noter, apparemment, Visual Studio nécessitant des droits d'administrateur est un peu daté et il existe maintenant des moyens explicites de définir les autorisations nécessaires (fichier PDF). Cependant, je ne pense pas que cela change mon option autant dans la mesure où la plupart des développeurs que je connais, moi-même inclus, ont tendance à utiliser des outils supplémentaires au-delà de Visual Studio et savoir ce dont tous ont besoin en termes d'autorisations peut être difficile à prévoir.

Je suis d'accord avec l'idée d'utiliser des machines virtuelles sur un bureau restreint-

Sauf indication contraire, je pense que la meilleure configuration est un bureau Linux restreint avec un vm gratuit pour tous. Linux réduit les frais généraux pour moi, un vm peut non seulement être le système d'exploitation qu'ils veulent, mais également être restauré en instantanés ou en sauvegardes, et généralement le monde semble un peu plus lumineux lorsqu'il n'y a pas toute une série de configurations différentes nécessitant soutien.

Je (en tant que développeur moi-même) préfère avoir le plein contrôle de mes machines, ce qui signifie; en cours d'exécution en tant qu'administrateur en cas de besoin.

Vous pouvez fournir une formation spéciale aux développeurs avant qu'ils ne soient autorisés à accéder à leurs ordinateurs. Définissez-leur des règles, et vous pourriez peut-être faire un audit de temps en temps pour voir si elles suivent les meilleures pratiques.

La plupart du temps, ils devront en savoir plus sur l'infrastructure informatique du point de vue de l'administration informatique / du support informatique, des éléments liés à la sécurité, ainsi que pourquoi ne pas développer avec des droits élevés. (et comment vous en assurer, vous ne le faites pas ...)

"Ne nous faites pas aveuglément confiance lorsque nous vous disons que nous savons tout ce que nous devons savoir sur les ordinateurs" ;-)

Vous devrez toujours les soutenir avec la mise en réseau, les domaines et les comptes, les installations de logiciels d'outils non-dev, etc.

Mon expérience concerne une population d'utilisateurs qui était à peu près également répartie entre les personnes qui n'avaient besoin que d'une machine verrouillée et d'autres (développeurs, scientifiques) qui avaient besoin d'un accès administrateur. Ils ont utilisé beaucoup de logiciels différents, certains en interne, d'autres non, mais beaucoup d'entre eux avaient besoin d'un administrateur pour fonctionner, et leurs tâches les obligeaient à utiliser beaucoup de packages, donc il était plus logique de laisser les gens faire eux-mêmes.

Nous nous sommes retrouvés avec les processus suivants:

• Notre image standard avait les outils de base: Windows, Office, Anti-virus, Acrobat, quelques utilitaires.
• Nous avons fourni beaucoup d'espace disque réseau: suffisamment pour que tout puisse être stocké sur le réseau. La seule exception concernait les fichiers vidéo en cours de traitement qui devaient rester locaux.
• Le personnel (en consultation avec leurs superviseurs) avait deux choix: soit le service informatique maintenait son PC, effectuait toutes les installations et la configuration OU il pouvait avoir un accès administrateur pour le faire lui-même. Dans les deux cas, toutes les données ont été sauvegardées sur le réseau.
• Si le service informatique maintenait le système et qu'il mourait, nous le remettions dans l'état dans lequel il se trouvait, y compris en ajoutant les logiciels supplémentaires dont ils avaient besoin et que nous avions installés.
• S'ils avaient un accès administrateur et que le système mourait, nous chercherions à le réparer, mais notre engagement était de les ramener à l'image standard et ils devraient la reprendre à partir de là. S'ils avaient des données locales, nous essaierions de les retirer d'abord, mais notre contrat SLA était simplement de leur fournir un PC standard fonctionnel dès que possible.
• Toute personne disposant d'un accès administrateur devait savoir comment s'assurer que les mises à jour Windows fonctionnaient, afin de maintenir l'anti-virus et l'anti-malware à jour.

Nous aurions aimé mettre toutes les personnes avec un accès administrateur sur un vlan "non fiable", mais nous n'y sommes jamais arrivés.