Autorisations Windows pour les développeurs?

Je travaille dans une entreprise du Fortune 500 en tant que développeur de logiciels Windows en R&D. L'informatique d'entreprise se prépare actuellement à un déploiement Win7 à l'échelle de l'entreprise et, dans le cadre de cette stratégie, elle cherche à verrouiller complètement les droits d'administrateur sur toutes les boîtes (y compris nos postes de travail de développement).

J'ai été chargé de travailler avec eux pour rendre la transition aussi fluide que possible. J'ai de la chance.

Je voudrais savoir s'il existe des ressources publiées ou d'autres ressources très respectées que je peux utiliser pour:

1. comprendre où tracer une ligne dans le sable
2. sauvegarder ma position.

Personnellement, je pense que nous sommes de la R&D et notre travail consiste à faire des choses qui sont «prêtes à l'emploi». Nous avons donc besoin de droits d'administrateur. Cependant, après avoir commencé ma carrière en tant qu'administrateur Windows, je connais leurs objectifs et ce qu'ils doivent atteindre. Ce que j'ai besoin de comprendre et de sauvegarder, c'est un moyen de créer l'environnement de manière à ce que l'informatique et la R&D puissent vivre avec et continuer à effectuer leurs tâches de manière productive.

Les machines virtuelles de développement avec des droits d'administrateur local aideront certainement beaucoup, mais pas dans tous les cas, car nous nous connectons avec de nombreux matériels personnalisés.

Le CIO qui pousse ces changements est définitivement un type de «pure informatique» avec une connaissance limitée du processus de développement, j'ai donc besoin de références qui seraient appropriées à partager avec quelqu'un comme ça.

Je ne cherche pas à rassembler beaucoup d'opinions personnelles (dont beaucoup ont déjà été partagées ici ), j'ai vraiment besoin de livres blancs, d'articles de magazines, d'ouvrages savants, etc. à utiliser pour plaider la cause de la haute direction.

Parce que vous allez spécifiquement vers Windows 7, vous devez vous efforcer d'être des administrateurs sur vos propres boîtes. Il y a deux très bonnes raisons pour empêcher les développeurs d'être des administrateurs:

• pour la même raison que vous empêchez tous les autres d'être des administrateurs, afin que les logiciels malveillants ne fassent pas de choses vraiment horribles s'ils se produisent
• afin qu'ils n'écrivent pas d'applications qui ne fonctionnent que si vous êtes administrateur

Avec l'UAC, aucune de ces choses ne se produira, car les applications que vous lancez ne s'exécuteront pas en tant qu'administrateur, sauf si vous le leur demandez délibérément. Ainsi, il y a peu de risques à vous laisser un compte administrateur.

Certains patrons ont une troisième raison - je ne veux pas que vous installiez des jeux ou des outils non autorisés. Sans discuter du bien-fondé de cette raison, je ferai observer qu'elle reste généralement non déclarée. Vous avez besoin d'un accès administrateur pour installer les éléments que vous écrivez, pour configurer IIS, pour reconfigurer votre machine pour différents types de tests (par exemple, modifier votre fichier hôte) et les deux "vraies" raisons pour éviter l'accès administrateur ne s'appliquent plus pour Windows 7 Par conséquent, vous devriez être des administrateurs.

Honnêtement, je pense que ce sera une affaire difficile à faire. Une fois que la haute direction se décide, il est assez difficile de les faire changer. S'ils accordaient plus de privilèges sur votre machine, quelqu'un d'autre pourrait être en mesure d'accéder et d'exécuter les actions que tout ce plan a été conçu pour empêcher.

Cela peut aider:

• http://www.slate.com/id/2226279/pagenum/all/
• /server/232416/should-dev-be-admin-on-their-computer
• http://avecto.com/blog/2010/09/the-pros-and-cons-of-windows-7-application-control-with-applocker/

PS: bonne chance!

Une option consiste à demander des postes de travail de test qui autorisent l'accès administratif.

Une autre option consiste à faire exactement ce qu'ils disent. Ensuite, lorsque le prochain projet arrivera, vous ne progresserez pas car vous devez vous adresser à l'informatique pour chaque petit changement. Expliquez cela au chef de projet, et il organisera rapidement les droits d'administrateur.

Une troisième option consiste à vérifier si votre service est représenté dans le projet de migration Win7. Si c'est le cas, contactez votre représentant et demandez-lui s'il peut ajouter des droits administratifs à la liste des exigences de votre service.

Une quatrième option consiste à échanger. Le projet de migration doit généralement être développé pour mettre à jour leur logiciel pour Win7. Il pourrait être possible de conditionner une attitude favorable aux droits d'administrateur dans le nouvel environnement.

Je ne peux pas imaginer essayer de développer sans être un administrateur local, mais je pense que les besoins varieront en fonction des tâches de développement et de la normalisation du processus de développement et de la chaîne d'outils sur votre lieu de travail.

D'après mon expérience, il y a généralement du personnel de développement senior qui devra installer divers outils de développement (parfois à des heures impaires) pour prototyper rapidement ou résoudre un problème critique. Ils ont presque certainement besoin d'un accès administrateur local pour installer, déboguer, travailler avec les services, etc.

Le reste du personnel peut se débrouiller sans, si votre ensemble d'outils est assez constant et en fonction de ce qu'il développe / débogue / déploie. Ma suggestion serait de rassembler un petit nombre de vos cadres supérieurs de développement les plus équilibrés, d'expliquer le problème et leurs options, de leur demander quelques jours pour l'examiner, puis de tenir une réunion de planification pour déterminer quel type d'accès le personnel aurait dû.

Du point de vue purement informatique et du point de vue du développement, de nombreuses entreprises résolvent le problème de cette manière:

Mettez toutes les boîtes de développement sur un réseau distinct. Le réseau de développement peut être complètement isolé (pas d'Internet ni d'intranet). Dans ce cas, les développeurs ont une boîte d'entreprise distincte qui est utilisée pour le courrier électronique et les communications officielles - c'est-à-dire l'accès à la fois à Internet et à l'intranet. Cette solution a ses propres défis car certains IDE (comme Eclipse) et d'autres outils de développement supposent que vous avez une connexion en direct à Internet pour obtenir des mises à jour et des plugins. Pourtant, la grande majorité des outils de développement savent qu'il existe des réseaux isolés.

Une autre variante de cette approche consiste à avoir le réseau de développement sur un sous-réseau. Vous avez un accès indirect à Internet et à l'intranet via un pare-feu DMZ strict, mais les développeurs ont toujours un accès administrateur local.

Pensez à donner aux développeurs deux comptes.

Le premier est un compte utilisateur normal non privilégié, qui est celui à utiliser pour tous les travaux quotidiens (y compris le développement de logiciels). L'autre est un compte d'administrateur local, qui ne dispose que de privilèges d'administrateur sur des machines spécifiques. Il ne devrait être nécessaire que lors de l'installation réelle ou de la modification des paramètres de la machine.

Assurez-vous que les services quotidiens tels que le serveur proxy Internet, la messagerie électronique, etc. ne reconnaissent que le compte normal, afin que les développeurs ne puissent pas simplement utiliser l'administrateur local tout le temps. Chaque fois que des privilèges d'administrateur sont requis, UAC apparaîtra et offrira au développeur la possibilité d'entrer ses informations de connexion d'administrateur local pour continuer.

Le développement logiciel est une bête fondamentalement différente de toute autre utilisation d'un ordinateur, et il doit être traité comme tel.

La possibilité d'écrire votre propre code et, plus important encore, de suivre l'exécution de votre code lors du débogage, vous oblige à disposer d'autorisations sur votre ordinateur qui, dans tout autre contexte, représenteraient un risque énorme pour la sécurité locale. Reformulé sous forme de morsure sonore:

Les autorisations requises pour le développement de logiciels ne conviennent pas aux utilisateurs types.

Afin de faire votre travail, vous devez être administrateur local. Mais en étant administrateur local et en contournant la politique de sécurité, vous posez théoriquement un risque pour le reste du réseau. Il faut donc également répondre à cette préoccupation. La façon dont les entreprises critiques en matière de sécurité résolvent ce problème consiste à imposer deux règles simples:

1. Les programmeurs ont un accès administrateur local sur leur machine de développement.
2. Les machines de développement ne sont pas connectées au réseau de l'entreprise.

La manière dont la deuxième règle se déroule dépend du service informatique. Parfois, la machine de développement est isolée par elle-même sans réseau entrant ou sortant (vu chez plusieurs sous-traitants de la Défense), et parfois la machine est connectée à un réseau "Invité" ou "DMZ" pour permettre l'accès à Internet (téléchargement de correctifs, accès à la documentation , etc.) sans mettre le réseau de l'entreprise en danger indu.

Maintenant, trouverez-vous une source officielle à ce sujet? Je suppose que cela dépend de qui vous voyez comme officiel . L'avis sur cette question est essentiellement unanime. Mais c'est tellement bien compris que c'est rarement énoncé. C'est un peu comme demander: " Est-ce que ma voiture devrait avoir un frein de stationnement? " Vous n'allez pas trouver des sources faisant autorité qui parlent du sujet parce qu'elles ont de meilleures choses à faire et tout le monde connaît déjà cette réponse.

Pouvez-vous utiliser un environnement virtuel?

Si vous ne faites pas de trucs graphiques lourds, l'exécution de MSVC dans vmware ou virtualbox est très bien (si vous avez beaucoup de RAM), vous pouvez avoir l'administrateur dans l'environnement virtuel et «leur» installation est verrouillée