Est-il courant d'autoriser l'accès et les droits d'administrateur local sur le bureau et / ou Active Directory aux développeurs des organisations?
Je travaille dans une entreprise avec un personnel d'environ 1000+. Nous avons actuellement du personnel de développement de programmation qui travaille sur des projets Web (environ 50 personnes).
Récemment, en raison de problèmes de sécurité, notre service informatique et sécurité a mis en place une restriction ne permettant plus à l'administrateur local d'accéder aux machines. Toute l'entreprise utilise Windows OS pour les postes de travail et les serveurs. Je suis entièrement d'accord avec la décision de supprimer l'administrateur, honnêtement, je pensais qu'il était attendu depuis longtemps (car la société traite les données des patients et exige la conformité HIPAA). Malheureusement, je pense qu'ils ont pris la décision trop loin. J'ai supposé qu'un sous-groupe ou un groupe AD serait créé pour les utilisateurs qui avaient légitimement besoin d'un accès administrateur pour faire leur travail (EX mon équipe de programmation) quelque chose comme un groupe Tech qui conserverait l'accès administrateur. Cependant, ce n'était pas le cas, le seul groupe a créé un groupe d'administration spécifique pour le personnel du réseau et du service d'assistance.
Le problème principal est que, en tant que développeurs Web, nous exécutons des programmes qui nécessitent un accès administrateur local et, malheureusement, ne peuvent pas faire notre travail sans qu'ils fonctionnent en tant qu'administrateur. Les exemples de programmes incluent le développement Web Visual Studio pour ASP.NET, MAMP pour le développement local, le compositeur, etc. Je pense que la principale raison pour laquelle ces programmes ont besoin d'un accès administrateur est qu'ils doivent exécuter et modifier IIS local, ligne de commande, etc.
Fondamentalement, il y avait un court préavis de quand l'accès administrateur local a été supprimé. Après environ 2 jours où l'équipe de développement est morte dans l'eau pour pouvoir travailler et moi et d'autres chefs d'équipe avons essentiellement crié et crié au personnel informatique pour trouver une solution qu'ils ont finalement concédé et trouvé un programme tiers qui fonctionne comme un passage permettant aux administrateurs de créer la capacité de certains programmes à s'exécuter en tant qu'administrateur même si nous n'avons pas d'accès administrateur local.
Malheureusement, ce programme que nous utilisons pour l'accès administrateur local est incroyablement bogué et peu fiable et ne provient pas d'une source fiable et il ne semble pas y avoir beaucoup d'alternatives. (Je préférerais ne pas divulguer le programme que nous utilisons.)
Ma question est la suivante: est-ce typique de ne pas autoriser l'accès administrateur local aux programmeurs/développeurs dans une entreprise ou une société? Et s'il est courant de le faire, comment les développeurs exécutent-ils les programmes dont ils ont besoin en tant qu'administrateur local?
Un peu plus d'informations sur notre environnement réseau (pas que cela se rapporte vraiment à la question que je pensais juste ajouter ceci):
- Nous utilisons AppBlocker pour bloquer les programmes ne figurant pas sur une liste approuvée
- Nous utilisons un bloqueur de sécurité de messagerie qui fait des choses comme scanner et convertir des pièces jointes en PDF, etc.
- Nous avons au moins 2 programmes antivirus majeurs sur tous les postes de travail.
- Le réseau et ses serveurs sont très séparés, les utilisateurs n'ont accès qu'à certains serveurs, dossiers et bases de données auxquels ils ont légitimement besoin d'accéder.
Voici un point de données d'une société de logiciels qui s'intéresse à la sécurité. Je sais que cela est courant dans des organisations similaires.
Il existe un certain nombre de réseaux. Ils sont physiquement séparés et à entrefer, acheminent différents câbles réseau à code couleur.
Chaque employé a une machine "d'administration", qui peut se connecter à Internet (via un proxy) pour envoyer des e-mails, etc. Tous les utilisateurs sont strictement verrouillés, et il y a un contrôle strict des appareils et des accès.
En plus de cela, chaque développeur dispose d'une machine "d'ingénierie". Celui-ci dispose d'un accès administrateur complet et l'utilisateur peut faire ce qu'il veut. Cependant, il n'est connecté qu'au réseau d'ingénierie (pas de route vers Internet).
Dans la plupart des contextes de développement logiciel, cela peut être considéré comme extrême, mais dans les organisations qui ont des exigences contradictoires de haute sécurité et de liberté de développement, c'est une solution courante.
Pour répondre à votre question, oui, il est courant de permettre aux administrateurs un accès administrateur, mais cela ne signifie pas toujours un accès administrateur à une machine qui pourrait entraîner des problèmes de sécurité des informations.
D'après mon expérience, il est courant que les développeurs aient un accès administrateur sur leurs propres machines. Il est également courant pour eux pas d'avoir un accès administrateur sur leurs propres machines. Cependant, dans ce dernier cas, certains aménagements sont généralement faits pour qu'ils puissent faire leur travail sans trop de friction.
Un hébergement très courant est l'accès à un hyperviseur sur la station de travail (qu'il s'agisse d'une version de VMWare ou de l'Hyper-V fourni avec Windows), ainsi que du autorisations spécifiques nécessaires pour créer et détruire des machines virtuelles au sein de cet hyperviseur selon les besoins ( Hyper-V / VMWare ), y compris la création de machines virtuelles où elles ont des droits d'administrateur sur le système d'exploitation invité. En règle générale, certaines de ces machines virtuelles auront une longue durée de vie, même si elles ne s'exécutent pas tout le temps, où il est rarement nécessaire de préparer un VM à partir de zéro uniquement pour faire ce qui devrait être un test rapide pour quelque chose qui nécessite des privilèges d'administrateur.
L'hyperviseur peut être configuré ou non pour autoriser l'accès à Internet pour ses machines virtuelles; Je l'ai vu dans les deux sens, mais personnellement, je suis fortement favorable à ce que l'accès Internet devrait soit autorisé ... au moins pour les types de développement avec lesquels j'ai le plus d'expérience. Mais l'accès à Internet, lorsqu'il est accordé, peut et doit au moins être configuré pour forcer les machines virtuelles dans un vlan dédié, distinct du reste du réseau d'entreprise. Je ne suis pas sûr que cela puisse être appliqué directement via Hyper-V ou VMWare, mais vous pouvez utiliser 802.1x sur les ports pour de nombreux commutateurs réseau pour empêcher l'accès à certains vlans à partir de machines non autorisées, y compris les machines virtuelles devloper. Ensuite, vous pouvez donner un petit tutoriel aux développeurs sur la façon de définir une balise vlan dans un VM et leur faire savoir quelles balises vlan seront autorisées sur leur port de commutateur. J'ai également vu cela appliqué via la formation simplement comme un édit politique, plutôt que via des mesures techniques, avec peut-être un audit amical occasionnel pour encourager la conformité et s'assurer que les développeurs savent que c'est important.
Et, bien sûr, cela coïncide avec la fourniture aux développeurs de machines suffisamment puissantes pour exécuter plusieurs machines virtuelles en même temps.
Je travaille pour une assez grande entreprise de gestion d'investissement (~ 6000 employés) et les développeurs sont l'un des groupes que nous approuvons pour l'accès administrateur local. Nous leur disons de ne pas installer de logiciel, car cela est géré par la conformité locale du bureau/logiciel.
Nous avons également un groupe de développeurs AD qui permet aux membres de modifier la politique d'exécution sur leurs machines sans nécessiter d'administrateur local.
D'après mon expérience, autoriser et interdire l'accès administrateur local est courant, tout aussi courant que des solutions de contournement sales pour ce dernier. - Vous devez donc vous demander:
Quelle menace pour votre réseau est aggravée par les droits d'administrateur local?
À laquelle la réponse doit être: AUCUNE - L'accès aux ressources de votre réseau doit être restreint par utilisateur, sans aucun rapport avec le fait que cet utilisateur a un accès local root, admin ou masterOfTheUniverse sur sa machine. Si l'utilisateur a le droit de faire exploser votre réseau, un virus local n'a même pas besoin d'un accès administrateur, il peut simplement utiliser le compte utilisateur pour faire exploser votre réseau. - Et si le compte d'utilisateur ne peut pas accéder à quelque chose sur votre réseau, les droits d'administrateur local n'y changeront rien.
Vous devez faire confiance à vos développeurs pour gérer leur propre machine de manière responsable - et avec une configuration de sécurité judicieuse dans votre entreprise, les droits d'administrateur local ne devraient être dangereux que pour une chose: la machine locale. Donc, le seul risque que vous acceptez en donnant un administrateur local est qu'un développeur casse sa propre machine (ce qu'il peut déjà faire avec une tasse de café).
Addendum: Vous devez accorder à vos développeurs la possibilité d'utiliser les droits d'administrateur local chaque fois qu'ils en ont besoin. Cela ne signifie pas qu'ils doivent être connectés avec un compte administrateur non sécurisé à tout moment, mais vous devez leur faire confiance pour l'utiliser judicieusement chaque fois qu'ils en ont besoin - sans demander la permission à chaque fois.
Pourquoi les développeurs devraient avoir des droits d'administrateur local
Vos développeurs sont des personnes à qui vous confiez la conception des opérations principales de votre entreprise. La plupart des entreprises sont aujourd'hui très dépendantes de leurs logiciels, les développeurs sont donc une ressource vitale pour façonner une partie très importante de votre entreprise.
Il y a d'abord l'avantage d'une productivité plus élevée, car le développeur peut simplement configurer, installer et tester tout ce dont il a besoin sur sa machine locale. Il peut avoir besoin de certains logiciels, outils d'assistance ou configurations inhabituelles pour expérimenter certains aspects de son logiciel (par exemple, exécuter son logiciel sur une ancienne version d'un système d'exploitation ou avec des pilotes/SDK plus anciens).
Deuxièmement, il y a l'avantage (à mon avis encore plus grand) de montrer à vos développeurs comment vous les appréciez. Vous leur montrez que vous leur faites confiance avec leur propre machine - vous traitez vos développeurs comme des personnes informatisées responsables qui peuvent administrer leur propre machine sans baby-sitter. (Dans de nombreuses entreprises où les développeurs n'ont pas d'administrateur local, ils devront demander le support technique ou la sécurité pour chaque installation/configuration dont ils ont besoin. Et dans de nombreux cas, ces personnes du support technique connaissent moins le logiciel que votre développeur principal. , mais ils doivent encore mendier des choses dont ils ont simplement besoin pour faire leur travail, ce qui peut être très frustrant.)
Dans ma carrière, avec des entreprises plutôt petites (moins de 100 personnes), nous avions toujours des droits d'administrateur local. Soit nous avons de vraies machines de bureau gérées par l'informatique, mais nous avons obtenu les droits, soit nous avons été autorisés à avoir des machines virtuelles de toutes sortes que nous gérons entièrement par nous-mêmes.
Si nous n'avions pas d'accès administrateur local, nous essaierions toutes sortes de mauvaises "solutions" qui, comme dans votre cas, conduisent à moins de sécurité. C'est l'un de ces cas, qui les restrictions conduisent en fait à l'opposé de leur intention.
Dans un département plutôt petit d'une organisation plus grande (~ 100 dans le département, ~ 3500 dans l'organisation complète), nous avons choisi une solution au milie:
- sysadmins avait 2 comptes, un (non administrateur même pour la machine locale) qui était utilisé pour des tâches non administratives (courrier, édition de documents, etc.) et un avec des privilèges d'administrateur AD qui était censé être utilisé uniquement pour l'administration AD
- tous les autres utilisateurs n'avaient qu'un seul compte non administrateur
- les développeurs (et certains tilisateurs expérimentés) ont reçu un compte local avec des privilèges d'administrateur de machine locale. Il était censé être rarement utilisé lorsqu'une administration locale était requise.
Refuser les droits d'administrateur sur les développeurs sera une cause de perte de productivité, et cela a un coût immédiat pour toute organisation. Le choix d'accorder des privilèges d'administrateur sur la machine locale au compte principal ou à un compte secondaire doit dépendre de la fréquence des opérations de l'administrateur:
- Si plus de plusieurs fois par jour, je vous conseille d'utiliser le compte principal.
- Si moins d'une fois par semaine, j'utiliserais un compte secondaire.
Choisissez le vôtre si vous êtes entre les deux ...
D'après mon expérience de travail pour de plus grandes organisations, il n'est absolument pas courant que les développeurs aient tous les droits sur autre chose que des ressources spécifiques au développement.
Il semble que votre organisation soit à la frontière des petits et des grands, alors ...
Il semble qu'il soit temps pour votre organisation de développer des pratiques de développement plus matures.
Pour être juste, ce type de changement n'est pas quelque chose dont les groupes d'opérations devraient surprendre les équipes de développement, comme cela semble avoir été fait dans votre cas.
La sécurité et la productivité des développeurs n'ont pas besoin de s'opposer pour votre entreprise. Vous pouvez éviter complètement cet affrontement en effectuant vos activités de développement sur un réseau qui n'a pas accès aux ressources de votre réseau d'entreprise principal.
Vous ne faites pas de développement contre vos actifs de production de toute façon, non?
Si vous l'êtes, vous ne devriez pas l'être - cela présente un risque important pour vos actifs, en particulier pour leur disponibilité.
Une bien meilleure pratique consiste à avoir une configuration d'environnement de développement complète qui reproduit des parties clés des fonctionnalités et des ensembles de données (sans exposer quelque chose comme des informations privées sur de vraies personnes dans votre entreprise). Cet environnement répliqué rend la séparation assez simple. Vos développeurs ont besoin d'un contrôle total des machines dans cet environnement de développement. Ils n'ont pas besoin d'un contrôle total des actifs en dehors de l'environnement de développement.
Il existe plusieurs façons d'implémenter un environnement de développement distinct:
- Matériel complètement séparé (postes de travail, serveurs, périphériques réseau, etc.), connecté ou non à Internet
- Environnements virtualisés (y compris les réseaux virtuels); hébergé sur votre matériel ou avec un fournisseur de services cloud et avec ou sans accès Internet
- Une combinaison des deux approches ci-dessus
Vous pouvez également implémenter une sorte de pont (si vous n'utilisez pas déjà un service quelconque) pour tout partage que vous devez faire dans et hors de l'environnement de développement.
Les environnements de développement doivent être protégés comme la plupart des réseaux. Ne jetez pas simplement tous vos codes et ressources de développement en ligne sans penser au contrôle d'accès ou aux mesures de sécurité de base.
J'ai également vu certains endroits aller plus loin et écrire tout leur code dans un environnement, puis le construire/déployer le tout dans un autre environnement complètement séparé pour les tests d'intégration.
Tout d'abord, vous devez apprendre que peu importe ce qui est "commun" ou "typique" car: généralement, de telles situations sont traitées horriblement. Vous faites le meilleur cas pour cette déclaration.
Si l'accès administrateur local est nécessaire pour une personne (que ce soit un entrepreneur ou un employé), il est de la responsabilité de l'équipe/personne de sécurité - qui est en charge de cette zone particulière - de trouver une solution . Il existe de nombreuses solutions: créer un VLAN isolé, des machines virtuelles et d'autres ont été nommées ici.
Cela n'a aucun sens de se renseigner sur la configuration d'autres organisations juste pour entendre "nous avons également des droits d'administrateur sur nos machines". Vous ne trouverez pas une infrastructure qui est exactement identique à la vôtre. La seule chose qui compte est que l'équipe de sécurité/personne planifie une solution sécurisée qui est ensuite implémentée par le service informatique dans cette organisation particulière .
Si la solution qui a été mise en œuvre ne fonctionne pas correctement et vous empêche donc toujours de travailler, faites-la remonter avec l'équipe/la personne de sécurité. Si cela ne fonctionne pas, signalez-le à votre patron ou à votre contractant.
Ce que vous faites actuellement, c'est brûler de l'argent et rien d'autre. Si les autres participants à ce jeu ne l'ont pas encore compris, c'est mauvais. Mais c'est bien si vous le faites.
Le problème que vous rencontrez est que les services informatiques compétents tentent d'appliquer une règle à tête d'os. Vous n'avez vraiment qu'un seul choix, donner aux développeurs un accès administrateur efficace.
Je continue de voir le même conseil se répéter encore et encore, cela revient à une deuxième machine que le développeur a admin mais pas Internet. Si vous voulez avoir la sécurité du fromage suisse, c'est la voie à suivre. Les listes de logiciels installés sur l'ordinateur d'un développeur type sont généralement plus longues qu'un écran. Beaucoup d'entre eux n'ont qu'une seule option pour vérifier les mises à jour - Internet. Vous ne pouvez pas les patcher via WSU car WSU ne sait pas qu'ils existent.
Voici ce que les arguments ne comprennent pas: violer les comptes personnels du développeur n'est pas un point de départ; c'est le jackpot. Il n'y a aucune raison d'aller à l'administrateur à partir de là. Le pirate a la capacité de modifier le codebade pour insérer des portes dérobées. Obtenir l'administrateur sur la boîte du développeur n'est pas beaucoup plus intéressant.
Contre quoi vous défendez-vous lorsque vous souhaitez refuser l'administrateur? Quelqu'un accède à la base de code? Non. Quelqu'un l'utilise comme point de lancement? Si votre LAN de production n'est pas protégé contre vos boîtes de développement, vous faites quelque chose de mal. Les développeurs installent des trucs qu'ils ne devraient pas? Non. Le développeur a un compilateur et exécute la sortie de code par le compilateur. Cela pourrait tout aussi bien être une définition de l'exécution d'un logiciel non approuvé.
J'ai entendu beaucoup d'histoires sur la politique selon laquelle les développeurs ne sont pas administrés, mais la pratique de l'informatique dans l'autre sens tandis que les développeurs renversaient la politique de sécurité. J'ai entendu beaucoup plus d'informations informatiques jamais découvert. J'ai entendu certains des responsables du développeur dire aux développeurs de contourner les contrôles de sécurité.
Tôt ou tard, les organisations apprennent simplement à donner aux développeurs l’administration. La plupart de ceux qui ne le font probablement pas sans le savoir.
Il est beaucoup plus sage de simplement administrer les développeurs locaux sur une seule boîte connectée à Internet et au domaine local et d'être prêt à faire face à toutes les conséquences. Protégez plutôt la production. Il y a moins de personnes qui devraient accéder à la production avec un niveau de privilège élevé, donc le verrouillage est plus facile et les organisations compétentes apprennent à le faire.
Mais soudainement, supprimer l'administrateur comme celui-ci entraîne presque toujours la perte des développeurs les plus importants. Tu ne veux pas ça.
Puisque vous voulez parler des sites Windows, il y a une anecdote qui l'emporte sur les données de la plupart des gens. Microsoft donne à ses développeurs un administrateur local. Le fabricant de Windows a conclu qu'il n'y avait pas suffisamment d'avantages à ne pas donner d'administrateur aux développeurs pour que cela en vaille la peine. Par conséquent, vous devez faire de même.
J'ai vu deux approches qui fonctionnent.
- Donnez aux développeurs un accès administrateur à leurs machines. Il s'agit de l'approche la plus simple et la plus courante. C'est généralement le meilleur choix
- Créez une équipe dans l'organisation dont le travail consiste à garantir que les développeurs peuvent travailler sans accès administrateur. Cette équipe sera généralement composée de 3 à 4 personnes. Vous constaterez que les exigences matérielles des développeurs augmentent considérablement à mesure que vous utiliserez des conteneurs et/ou des machines virtuelles, alors prévoyez un budget pour l'achat de nouveau matériel pour tous les développeurs. Lorsque vous vous déployez, commencez par une équipe d'adopteurs précoces, puis déplacez progressivement tous vos développeurs vers une machine sans accès administrateur. Ce processus prendra au moins six mois.
Si vous faites ce que fait votre entreprise maintenant, vos développeurs le supporteront pendant environ un mois, puis commenceront à chercher de nouveaux emplois.
Cela dépend fondamentalement du contexte, et en particulier de votre modèle de menace.
Dans certaines organisations, il est courant de donner aux développeurs un contrôle total sur leur poste de travail de développement, au point de leur permettre d'y installer leur propre système d'exploitation.
Dans certaines organisations, tout le développement doit se faire dans un environnement à espace restreint, dans lequel aucun appareil électronique ne peut être introduit ou retiré.
La plupart des organisations se situent quelque part entre ces deux extrêmes. Plus l'environnement de développement est verrouillé, moins vos développeurs seront productifs et plus vous risquez de perdre vos meilleurs talents. Votre organisation doit évaluer la probabilité et l'impact d'un poste de travail de développeur compromis, et dans quelle mesure elle est prête à réduire la productivité des développeurs pour atténuer ce risque.
J'ai travaillé pendant un certain temps pour une entreprise qui croit vraiment à la sécurité (du moins c'est ce qu'ils pensent).
De temps en temps, ils organisaient un événement social, comme jouer au bowling. L'adhésion était gratuite, mais vous deviez ajouter votre nom à une liste dans un fichier Excel, placé dans un dossier partagé. Ce dossier était dédié aux événements sociaux, rien d'autre.
Alors, tu veux jouer au bowling? Vous souhaitez ajouter votre nom à cette liste? Ohhhhhhhhhh, chéri ... Ce n'est pas comme s'ils pouvaient laisser tout le monde éditer ce fichier, n'est-ce pas? Vous devez demander les autorisations appropriées.
Voici la procédure:
- Ouvrez le site de l'entreprise
- Trouvez la section avec quelques modules prêts à être remplis
- Recherchez et téléchargez le document intitulé "Fiche de sortie"
- Imprime le
- Remplissez-le avec votre demande et signez-le
- Remettez-le au secrétaire
- Le secrétaire présentera toutes ces demandes au responsable dans la matinée du lendemain
- Tôt ou tard, le manager le signera
- Le secrétaire vous le ramènera
- À ce stade, vous pouvez le numériser
- Ouvrir le site utilisé par l'informatique pour gérer les tickets
- Créez un ticket décrivant (à nouveau) ce dont vous avez besoin et joignez la feuille de version numérisée. N'oubliez pas de régler l'urgence, d'une heure à deux semaines.
- Finalement, l'informatique le fera (avec un peu de chance)
En moyenne, cela prendrait 3-4 jours pour le faire. Dans certains cas, des semaines. Vraiment efficace, hein? Hé, vous avez demandé l'accès à un certain dossier mais avez oublié de mentionner le sous-dossier? HA! Vous avez gagné un autre tour! Et devine quoi? Puisqu'ils suivaient un processus d'AQ, ils organisaient les documents dans beaucoup de différents dossiers. Lorsqu'un nouveau collègue venait, il pouvait facilement passer semaines à essayer d'obtenir toutes les autorisations dont il avait besoin.
Maintenant.
- Pensez-vous que les managers ont pris la peine de vérifier ce qu'ils signaient? Certainement pas. Ils ont reconnu la feuille de sortie, et c'était tout.
- Pensez-vous que les secrétaires vérifiaient beaucoup plus? Peut-être qu'ils ont essayé, mais peuvent-ils vraiment comprendre les implications de me donner une autorisation de lecture/écriture sur un certain dossier sur une certaine machine? Certainement pas.
- Pensez-vous que l'IT se soit foutu de l'urgence? Certainement pas.
Alors, à quoi cette approche a-t-elle conduit? Que si vous vouliez voler tout ce que l'entreprise avait fait, il vous suffisait d'apporter une clé USB et de la connecter à votre PC. Pas d'accès à ce dossier "Confidential_Documents"? Il suffit de le demander, ils le signeront. Et si c'est urgent? "Salut, j'ai besoin de ce document mais je ne peux pas y accéder, pouvez-vous me donner votre mot de passe?"
Donc, ce "modèle de sécurité" était incroyablement lent, maladroit et frustrant, et il ne protégeait pas du tout leurs propriétés, mais au moins personne ne pouvait facilement jouer avec les participants à l'événement de bowling ( xkcd obligatoire ).
Veuillez ne pas être cette entreprise. Comme d'autres l'ont dit: ne demandez pas si c'est courant (ça l'est), demandez simplement si cela a du sens. Et la réponse est: non, ce n'est pas le cas, sauf si votre entreprise aime brûler de l'argent.
Oui et non - nos développeurs seniors ont un compte administrateur séparé qui leur permet de s'élever en cas de besoin et d'installer des applications/mises à jour. Cependant, ils ne sont pas autorisés à se connecter à l'ordinateur avec le compte. Leur compte administrateur leur permet également d'accéder en tant qu'administrateur à des ordinateurs de développement réguliers pour fournir une assistance plus rapide que de passer par l'équipe informatique.
Tout cela est combiné avec une liste blanche/noire d'application, des politiques de mot de passe solides, une interdiction de périphérique amovible, des proxys de passerelle, des politiques DLP, des règles AV strictes et plus encore. Leurs machines sont régulièrement auditées et la visibilité de l'équipe informatique est élevée.
Personnellement, je préférerais que les développeurs n'aient pas d'accès administrateur local. Nous pourrions enquêter sur les applications qui ont besoin d'UAC (trouver les dossiers, les clés d'enregistrement, etc. dont il a besoin) et atténuer l'invite UAC, mais cela prend du temps et des recherches et toutes les entreprises n'ont pas les ressources pour le faire. Donc, nous les rencontrons à mi-chemin et nous attendons une confiance à double sens. Nous utilisons également plusieurs produits d'entreprise pour appliquer une multitude de règles, ce qui soulage cela.
Réponse courte: Oui, il est courant d'avoir un accès administrateur local à des groupes sélectionnés, tels que des développeurs ou des administrateurs informatiques. Fondamentalement, les personnes dont le travail de jour est beaucoup plus facile avec un accès administrateur alors que l'employé de bureau habituel en aurait besoin au plus une fois par mois et généralement beaucoup moins que cela.
Réponse longue: Cela dépend ...
Pour la population générale d'utilisateurs, vous n'avez pas besoin d'effectuer une analyse complète des risques pour comprendre que l'accès administrateur a beaucoup de potentiel pour que les choses tournent mal et peu d'avantages pour compenser ce risque.
Cependant, pour les développeurs (et quelques autres groupes), une analyse des risques est définitivement justifiée, et une décision appropriée sur la question basée sur les faits, les circonstances, l'appétit pour le risque et la situation de menace de l'entreprise est demandée. Le fait de pointer vers les "meilleures pratiques" et de faire un déménagement à taille unique est une dérogation généralement causée par la ou les personnes responsables de la sécurité des informations qui n'ont pas le temps et/ou les connaissances nécessaires pour exécuter les chiffres et trouver une décision de traitement des risques basée sur des faits.
Cela ne signifie pas nécessairement qu'ils se trompent. Une analyse complète pourrait très bien conduire à la même conclusion.
Au point où vous en êtes, d'après ce que vous écrivez, c'est un inconnu. Vous pouvez demander qu'une analyse des risques appropriée soit effectuée, en ajoutant vos connaissances d'experts au coût de l'atténuation de l'équation, en mettant en chiffres la perte de productivité et d'autres effets de la mesure actuelle. Cela doit être mis en balance avec le risque identifié par les personnes chargées de la sécurité de l'information.
Il existe également d'autres mesures qui sont liées. Une solution typique que je recommande parfois (je suis architecte de sécurité de l'information de profession, donc on me pose régulièrement ces questions) consiste à séparer le réseau de développeurs du réseau de bureau ordinaire pour contenir la zone à risque plus élevé. Renforcez suffisamment les machines de développement et insistez sur les pare-feu locaux et une protection antivirus à jour et vous êtes bien contre les scénarios d'attaque typiques. Si votre entreprise est exposée à l'extérieur, vous pouvez également ajouter une formation de sensibilisation supplémentaire pour les développeurs afin qu'ils ne deviennent pas la proie si facilement des attaques ciblées.
J'ai personnellement supervisé les environnements de développement des deux types et, avec un peu d'effort, les deux peuvent fonctionner correctement. Le simple fait de débrancher la prise sur une méthode de travail établie le gênait mal et le jeu dont vous faisiez partie était à prévoir. Mais ce qui est fait est fait et il est probablement intelligent de ne pas se concentrer sur cela et de regarder vers l'avenir.
Nous avons résolu ce problème en utilisant Machine virtuelle.
Chaque développeur possède un compte utilisateur normal sans aucun droit d'administrateur. À l'intérieur de ce compte d'utilisateur, il y a une machine virtuelle sans accès à Internet. À l'intérieur de la machine virtuelle, le développeur peut exécuter son application avec des droits d'administrateur.
De cette façon, nous pouvons séparer l'accès à Internet et les données importantes de l'utilisation des droits d'administrateur tout en obtenant un moyen d'exécuter les programmes nécessaires dans un environnement clos.
Je suis dans le même bateau que vos développeurs de logiciels. Notre entreprise est récemment passée de postes de travail avec accès administrateur à des machines virtuelles sans. Cela a tellement affecté notre flux de travail que je me suis retrouvé à ne rien faire d'autre que lire des articles pour que le service informatique exécute quelque chose en tant qu'administrateur pour moi.
Ce que la direction a proposé est une approche deux machines virtuelles.
L'une de nos machines virtuelles était une machine métier de base avec messagerie électronique, accès Web et Microsoft Suite. Cela répondait au besoin de communiquer.
L'autre machine virtuelle avait droits d'administrateur local, mais entièrement déconnectée d'Internet. De cette façon, nous ne pouvions rien télécharger sur cette machine. (Bien que nous puissions toujours le télécharger de l'autre et copier le téléchargement sur ..) Nous avons toujours eu accès à des sites internes et avons ajouté à la liste blanche un certain nombre de choses que Visual Studio utilise (Nuget, Symbols, etc.)
Cette approche a laissé le service informatique satisfait en termes de sécurité, tout en nous redonnant l'accès administrateur.
Le seul point négatif est que nous ne pouvons pas utiliser nos deux moniteurs pour une seule machine car nous avions besoin que chaque machine soit sur leur propre moniteur, mais nous utilisons généralement un écran pour le code et l'autre pour la navigation Web de toute façon.
Séparez vos réseaux
Vous devez avoir des environnements relativement isolés pour le développement, les tests, la production et les affaires. Cela permet à vos développeurs d'avoir des privilèges là où ils en ont besoin.
Une ségrégation appropriée empêche les modifications non autorisées, limite la propagation des logiciels malveillants et empêche l'exfiltration des données.
Que se passe-t-il où?
Développement
Le réseau de développement est l'endroit où le codage a lieu. Les développeurs doivent disposer de droits d'administration s'ils souhaitent tester des extraits de code ou exécuter quelque chose sans l'empaqueter pour le déploiement vers test/prod.
Les ordinateurs exécutent des IDE, des référentiels sources et des applications/frameworks prérequis pour vos applications. Un outil de collaboration dédié ou d'autres applications spécifiques aux développeurs sont raisonnables.
Essai
Le réseau de test est l'endroit où le code compilé prêt à être expédié est testé. Les développeurs peuvent avoir des droits d'administrateur, mais les administrateurs système habituels doivent déployer des applications.
Les déploiements doivent refléter ce que les administrateurs maintiendront en production pour les applications internes. Il doit s'agir de packages prêts à l'emploi pour les applications externes (y compris l'assistant d'installation et les signatures numériques, mais en utilisant une signature distincte à des fins de test pour éviter les versions accidentelles).
Les développeurs ont souvent besoin de journaux système et d'un accès de débogage, et ce sont les seules raisons pour lesquelles ils doivent disposer de droits d'administrateur. Ils ne doivent pas être impliqués dans l'installation, la configuration et les tests, sauf si cela est absolument nécessaire.
Production
Le réseau de production est l'endroit où vous fournissez des services aux clients et partenaires. Puisqu'un processus de déploiement formel devrait exister, il n'y a aucune raison pour qu'il se connecte à vos réseaux de développement/test.
Pour minimiser les risques de malware sur Internet et de modifications accidentelles, les comptes des réseaux de développement/test/entreprise ne devraient pas avoir accès à la production si possible, ce qui se traduit par des autorisations limitées avec des arguments occasionnels dans la pratique.
Idéalement, ce réseau serait complètement isolé, mais en pratique, cela est impossible dans un monde où les serveurs de production doivent s'interfacer avec les systèmes de vente, de facturation, de planification, de netops et de gestion de projet. Rapprochez-vous le plus possible de l'idéal; c'est vraiment tout ce que nous pouvons faire.
Affaires
Il s'agit du principal réseau de communication pour l'entreprise.
La messagerie électronique, la navigation sur le Web et la connectivité des partenaires présentent tous une multitude de risques. Vos réseaux de développement, de test et de production doivent être isolés de ces risques dans toute la mesure du possible.
Détails, détails, détails
Il est possible que votre organisation soit allée trop loin. Il est plus facile de faire pivoter le pendule à fond que de traiter les innombrables détails essentiels à une architecture réseau flexible et sécurisée.
Les développeurs peuvent avoir un accès administrateur à leurs machines, avec un risque minimal pour l'entreprise, si:
- Il existe des comptes distincts et non privilégiés pour l'accès à Internet
- Des comptes uniques sont utilisés dans chaque environnement
- Des règles/ACL pare-feu restrictives existent entre les environnements
- Des mesures de sécurité standard telles que pare-feu, proxy Web, IDS/IPS, etc. sont en place
Vos développeurs auront besoin de quatre comptes:
- Compte de développement non privilégié pour accéder aux ressources sur Internet (s'ils ne veulent pas faire des allers-retours depuis le réseau d'entreprise, ce qui est onéreux)
- Compte de développement privilégié pour configurer la station de travail et tester le code
- Compte de test privilégié pour déboguer des applications
- Compte professionnel non privilégié pour e-mail, web, intranet
Si vos développeurs effectuent un travail de validation ou d'assurance qualité, ils peuvent également avoir besoin de comptes non privilégiés dans l'environnement de test.
Les développeurs ne doivent avoir aucun accès au réseau de production et aucun privilège administratif sur le réseau d'entreprise. Si cela est impossible pour le moment, alors ces rôles doivent être séparés ou bien un processus rigoureux de contrôle du changement doit être mis en place.
Bien que MS-Windows NT ait été un système système multi-utilisateurs depuis sa création, il n'est pas vraiment facile de le faire fonctionner de cette manière, et les développeurs (y compris ceux de Micosoft) ont toujours tendance à ignorer l'idée de séparation des privilèges. Ce type de contrôle d'accès est peu documenté, a tendance à ne pas figurer dans la formation, souvent difficile d'accès via l'interface utilisateur, difficile à auditer, manque de modèles/outils pour appliquer la séparation ...
En toute justice, même sur les systèmes Unix/Linux, je vois beaucoup de développeurs ne pas utiliser correctement la séparation des privilèges à la fois pour les vrais utilisateurs et pour les services. Mais sur n'importe quelle plate-forme, placer des barrières empêchant les implémenteurs de séparer les privilèges est encore plus contre-productif pour la sécurité que de leur donner des privilèges d'administrateur complets (locaux) .
D'un autre côté, bien que je sache peu de choses sur le développement sur MS-Windows, je trouve surprenant que le privilège d'administrateur local soit requis pour exécuter Visual Studio. Et si la seule raison pour laquelle vous avez besoin d'un accès administrateur est pour arrêter/démarrer des services ou les reconfigurer, je n'ai pas beaucoup de sympathie pour vous - possible de fournir cette fonctionnalité aux utilisateurs désignés sans leur donner local admin. L'un des grands changements dans IIS7 était la capacité admin déléguée . Et il a toujours été facile de déléguer la reconfiguration d'Apache, MySQL et PHP.
il y a eu un court préavis du moment où l'accès administrateur local a été supprimé
Il semble que le problème soit que l'équipe de sécurité aspire à un niveau de compétence qu'elle n'est pas en mesure de fournir (ce qui, selon mon expérience, est très commun). Ils n'auraient pas dû imposer un changement de politique sans avoir effectué une évaluation d'impact appropriée et envisagé des mesures d'atténuation pour tout préjudice à la productivité/sécurité.
Nous avons au moins 2 programmes antivirus majeurs sur tous les postes de travail
C'est une approche très naïve de la protection de l'intégrité de ces systèmes et dépeint une image de ce à quoi vous devez faire face.
il ne semble pas y avoir beaucoup d'alternatives là-bas
Entrer dans une discussion à ce sujet ne sera probablement pas très productif à ce stade.
Dans l'ensemble, il semble que vous soyez en concurrence avec votre équipe de sécurité locale. Ils ne comprennent pas ce dont vous avez besoin pour faire votre travail, vous ne comprenez pas comment atteindre leurs objectifs. Et il semble qu'aucune des parties ne veuille négocier. Aucun outil standard ne pourra résoudre ce problème.
Il est typique que l'accès administrateur local soit refusé aux développeurs dans les entreprises où les développeurs sont si inutiles/malveillants qu'ils abusent de ces privilèges, ou lorsque le département "Informatique et sécurité" est dirigé par des idiots maladroits qui ne voient pas tout le monde dans leur entourage comme une menace de sécurité évidente pour les faire mal paraître.
Étant donné que votre service "informatique et sécurité" exige également deux programmes antivirus lorsque Windows est livré avec un logiciel gratuit parfaitement bon, je suis presque sûr que vous pouvez déterminer où se situe le problème dans votre organisation et travailler à partir de là.