Voici un point de données d'un éditeur 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 écartés, exécutent différents câbles réseau à code couleur.

Chaque employé dispose d'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». Cela a un accès administrateur complet, et l'utilisateur peut faire ce qu'il veut. Cependant, il est connecté uniquement 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éveloppeur, c'est une solution courante.

Pour répondre à votre question, oui, il est courant d'autoriser l'accès administrateur aux développeurs, mais cela ne signifie pas toujours un accès administrateur à une machine qui pourrait causer des problèmes de sécurité des informations.

D'après mon expérience, il est courant pour les développeurs d'avoir un accès administrateur sur leurs propres machines. Il est courant pour eux de ne pas avoir un accès administrateur sur leurs propres ordinateurs. Cependant, dans cette dernière situation, des aménagements sont généralement faits pour qu'ils puissent faire leur travail sans trop de friction.

L’accès à un hyperviseur sur le poste de travail (qu’il s’agisse d’une version de VMWare ou de l’Hyper-V fourni avec Windows), ainsi que des autorisations spécifiques nécessaires pour créer et détruire des VM au sein de cet hyperviseur si nécessaire ^{( Hyper-V / VMWare)} , y compris la création de VM sur lesquelles ils 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 question de préparer une machine virtuelle entière à partir de zéro juste pour faire ce qui devrait être un test rapide pour quelque chose qui nécessite un administrateur privilèges.

L'hyperviseur peut ou non être configuré pour autoriser l'accès à Internet pour ses VM; Je l'ai vu dans les deux sens, même si personnellement je suis fortement favorable à ce que l'accès à Internet devrait être autorisé ... du 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 minimum être configuré pour forcer les VM à entrer dans un vlan dédié, séparé du reste du réseau d'entreprise. Je ne suis pas sûr que cela soit possible d'appliquer directement via Hyper-V ou VMWare, mais vous pouvez utiliser 802.1x sur les ports de nombreux commutateurs réseau pour empêcher l'accès à certains vlans à partir de machines non autorisées, y compris les VM devloper. Ensuite, vous pouvez donner un petit tutoriel aux développeurs sur la façon de définir une balise vlan dans une VM et leur faire savoir quelles balises vlan seront autorisées sur leur port de commutateur. J'ai également vu cela imposé via la formation simplement comme un édit de 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 à la fois.

Je travaille pour une assez grande société de gestion d’investissements (~ 6000 employés) et les développeurs sont l’un des groupes que nous approuvons pour l’accès des administrateurs locaux. Nous leur disons de ne pas installer de logiciel, car cela est géré par la conformité du bureau / logiciel local.

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 un administrateur local.

D'après mon expérience, autoriser et interdire l'accès administrateur local est courant, tout aussi courant que les solutions de contournement sales pour ce dernier. - Vous devriez donc vous demander:

Quelle menace pour votre réseau est aggravée par les droits d'administrateur local?

À laquelle la réponse devrait ê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 dispose d'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 utilisateur ne peut pas accéder à quelque chose sur votre réseau, les droits d'administrateur local n'y changeront rien.

Vous devriez faire confiance à vos développeurs pour gérer leur propre machine de manière responsable - et avec une configuration de sécurité sensible dans les droits d'administrateur local de votre entreprise 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 devriez accordez à 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é en tout temps, mais vous devez leur faire confiance pour l'utiliser de manière raisonnable chaque fois qu'ils en ont besoin - sans demander l'autorisation à chaque fois.

Pourquoi les développeurs devrait avoir des droits d'administrateur local

Vos développeurs sont des personnes à qui vous confiez la conception des opérations de base 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.

Premièrement, il y a 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'aide 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 ne reçoivent pas d'administrateur local, ils devront demander au support technique ou à la sécurité pour chaque installation / configuration dont ils ont besoin. Et dans de nombreux cas, ces personnes du support technique en savent moins sur le logiciel que votre développeur principal principal. , mais ils doivent toujours mendier les 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 avons toujours eu des droits d'administrateur local. Soit nous avons de vraies machines de bureau qui sont maintenues par le service informatique, mais qui en ont les droits, soit nous avons été autorisés à avoir des machines virtuelles de toutes sortes que nous gérons complètement par nos propres moyens.

Si nous n'avions pas d'accès administrateur local , nous essayerions toutes sortes de mauvaises «solutions» qui, comme dans votre cas, conduisent à moins de sécurité. C'est l'un de ces cas, où les restrictions conduisent en fait à l'opposé de leur intention.

Dans un département plutôt petit d'une grande organisation (~ 100 dans le département, ~ 3500 dans l'organisation complète), nous avons choisi une solution au milieu :

• 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 utilisateurs expérimentés ) ont reçu un compte local avec des privilèges d’administrateur de la machine locale. Il était censé être rarement utilisé lorsqu'une administration locale était nécessaire.

Refuser les droits d'administrateur aux 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 d'opération de l'administrateur:

• Si plus de plusieurs fois par jour, je conseillerais 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 limite des petites et des grandes , donc ...

Il semble qu'il soit temps pour votre organisation de développer des pratiques de développement plus matures.

Pour être honnête, ce genre de changement n'est pas quelque chose des groupes opérationnels devrait 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 ce conflit 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’activité principal.

Vous ne faites pas de développement sur vos ressources 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é.

Il est préférable d'avoir une configuration d'environnement de développement complète qui réplique parties clés des fonctionnalités et des ensembles de données (sans exposer quelque chose comme des informations privées sur de vrais individus 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 de mettre en œuvre un environnement de développement distinct:

• Matériel complètement séparé (postes de travail, serveurs, périphériques réseau, etc.), connectés ou non à Internet
• Environnements virtualisés (y compris les réseaux virtuels); hébergé sur votre matériel ou chez 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.

Environnements de développement doit être protégé comme la plupart des réseaux. Ne vous contentez pas de mettre en ligne tout votre code et vos ressources de développement sans réfléchir 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 en un puis créez / déployez le tout dans un autre environnement complètement séparé pour les tests d'intégration.

Tout d'abord, vous devez savoir que ce qui est "commun" ou "typique" n'a pas d'importance car: en général, de telles situations sont gérées horriblement . Vous faites le meilleur des cas pour cette déclaration.

Si l'accès de l'administrateur local est nécessaire pour une personne (que ce soit un entrepreneur ou un employé), alors c'est l'obligation de la sécurité équipe / personne - quel que soit le responsable de ce domaine particulier - pour trouver une solution. Il existe de nombreuses solutions: créer un VLAN isolé, des machines virtuelles et 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 soit exactement la même que la vôtre. La seule chose qui compte, c'est que l'équipe / la personne de sécurité planifie une solution sécurisée qui est ensuite mise en œuvre par le service informatique de cette organisation particulière.

Si la solution qui a été implémentée ne fonctionne pas correctement et vous empêche donc toujours de travailler, faites-en part à nouveau à l'équipe / la personne de sécurité. Si cela ne fonctionne pas, parlez-en à votre patron ou à votre contracté.

Ce que vous faites en ce moment, c'est de 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.

J'ai vu deux approches qui fonctionnent.

1. Donnez aux développeurs un accès administrateur à leurs machines. C'est l'approche la plus simple et la plus courante. C'est généralement le meilleur choix
2. Créer une équipe dans l'organisation dont l'ensemble du travail est de s'assurer 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, donc un budget pour l'achat de nouveau matériel pour tous les développeurs. Lorsque 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 votre entreprise fait 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'installer le leur OS sur celui-ci.

Dans certaines organisations, tout développement doit être effectué dans un environnement à air comprimé, dans lequel aucun appareil électronique ne peut être intégré 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.

Le problème que vous rencontrez en fait, c'est qu'un service informatique compétent essaie de faire appliquer une règle à tête blanche. Vous n'avez vraiment qu'un seul choix, donner aux développeurs un accès administrateur efficace.

Je ne cesse de voir le même conseil se répéter encore et encore, qui se résume à une deuxième machine que le développeur a admin mais pas d'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 typique 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 de choisir l'administrateur à partir de là. Le pirate a la capacité de modifier le code pour insérer des portes dérobées. Gagner l'administrateur sur la boîte du développeur n'est pas tellement plus intéressant.

Contre quoi défendez-vous lorsque vous voulez refuser l'administration? Quelqu'un accède à la base de code? Non. Quelqu'un l'utilise comme point de départ? Si votre réseau local de production n'est pas protégé contre vos boîtiers 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 le code produit par le compilateur. Cela pourrait aussi bien être la définition de l'exécution de logiciels non approuvés.

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 détournant les yeux pendant que les développeurs se renversaient la politique de sécurité. J'ai entendu beaucoup plus de TI sans même le savoir. J'ai entendu certains responsables du développement dire aux développeurs de contourner les contrôles de sécurité.

Tôt ou tard, les organisations apprennent à donner simplement aux développeurs l'administrateur. La plupart de ceux qui ne finissent probablement pas par l'avoir fait sans le savoir.

Il est beaucoup plus sage de donner aux développeurs un administrateur local 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, retirer un administrateur comme celui-ci entraîne presque toujours la perte de les développeurs les plus importants. Vous ne voulez pas de ç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 devriez faire de même.

J'ai travaillé pendant un certain temps pour une entreprise qui croit vraiment en 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érie ... 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 à à remplir
• Recherchez et téléchargez le document intitulé "Release Sheet"
• Imprimez-le
• Remplissez-le avec votre demande et signez-le
• Le remettre au secrétaire
• Le secrétaire transmettra toutes ces demandes au directeur le matin du lendemain
• Tôt ou tard le directeur le signera
• La secrétaire vous le rapportera
• À ce stade, vous pouvez le scanner
• Ouvrir le site utilisé par le service 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 définir l'urgence, d'une heure à deux semaines.
• Finalement, le service informatique le fera (espérons-le)

En moyenne, il 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 vous avez oublié de mentionner le sous-dossier? HA! Vous avez gagné un autre tour! Et devine quoi? Comme ils suivaient un processus de contrôle qualité, ils organisaient les documents dans beaucoup de dossiers différents. Lorsqu'un nouveau collègue arrivait, il pouvait facilement passer semaines à essayer d'obtenir toutes les autorisations dont il avait besoin.

Maintenant.

• Pensez-vous que les responsables ont pris la peine de vérifier ce qu'ils signaient? Certainement pas. Ils ont reconnu la feuille de sortie, et c'est tout.
• Pensez-vous que les secrétaires vérifiaient beaucoup plus? Peut-être ont-ils essayé, mais peuvent-ils vraiment comprendre les implications de me donner l'autorisation de lecture / écriture sur un certain dossier sur une certaine machine? Certainement pas.
• Pensez-vous que l'informatique se fichait de l'urgence? Certainement pas.

Alors, à quoi a conduit cette approche? Que si vous vouliez voler tout ce que l'entreprise a jamais fait, il vous suffisait d'apporter une clé USB et de la connecter à votre PC. Pas d'accès à ce dossier "Confidential_Documents"? Demandez-le simplement, ils le signeront. Et si c'est urgent? "Bonjour, j'ai besoin de ce document mais je ne peux pas y accéder, pouvez-vous me donner votre mot de passe?"

Ce "modèle de sécurité" était donc incroyablement lent, maladroit et frustrant, et il n'ont pas du tout protégé leurs propriétés, mais au moins personne ne pouvait facilement jouer avec les participants à l'événement de bowling ( xkcd obligatoire).

Merci de ne pas le faire. t être cette entreprise. Comme d'autres l'ont dit: ne demandez pas si c'est courant (c'est le cas), 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 distinct qui leur permet d'é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 un accès administrateur aux ordinateurs de développement standard 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 strictes, une interdiction de périphérique amovible, des proxys de passerelle, des politiques DLP, des règles antivirus 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 la ou les applications qui ont besoin de l'UAC (trouver les dossiers, les clés de registre, etc. dont elle a besoin) et atténuer l'invite UAC, mais cela prend du temps et de la recherche et toutes les entreprises n'ont pas les ressources pour le faire. Nous les rencontrons donc à mi-chemin et nous attendons une confiance réciproque. Nous utilisons également plusieurs produits d'entreprise pour faire appliquer une multitude de règles, donc il y a un certain soulagement à cela.

Nous avons résolu ce problème en utilisant une machine virtuelle .

Chaque développeur a un compte utilisateur normal sans aucun droit d'administrateur. À l'intérieur de ce compte d'utilisateur, il y a une machine virtuelle sans aucun 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 société est récemment passée des postes de travail avec accès administrateur aux machines virtuelles sans. Cela affectait tellement notre flux de travail que je me suis parfois retrouvé à ne rien faire d'autre que lire des articles pour que le service informatique gère quelque chose en tant qu'administrateur pour moi.

La direction a proposé un deux machines virtuelles .

L'une de nos machines virtuelles était une machine professionnelle de base avec Email, Web Access et Microsoft Suite. Cela répondait au besoin de communiquer.

L'autre machine virtuelle disposait de droits d'administrateur local , mais était entièrement déconnectée d'Internet . De cette façon, nous ne pourrions 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.) Nous avons toujours accès aux sites internes et avons ajouté à la liste blanche quelques éléments utilisés par Visual Studio (Nuget, Symboles, etc.)

Cette approche a laissé le service informatique satisfait en termes de sécurité, tout en nous redonnant un 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 son propre moniteur, mais nous n'utilisions généralement qu'un écran pour le code et l'autre pour la navigation Web de toute façon.

Réponse courte : Oui, il est courant d'avoir un accès administrateur local à certains groupes, tels que les développeurs ou les 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 des 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 en fonction des faits, des circonstances, de l'appétit pour le risque et de la situation de menace de l'entreprise est demandé. Mettre en évidence les «meilleures pratiques» et faire un geste unique et masqué est une échappatoire généralement causée par la ou les personnes responsables de la sécurité des informations qui manquent de temps et / ou de connaissances 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 ont tort . Une analyse complète pourrait très bien conduire à la même conclusion.

Au point où vous êtes, d'après ce que vous écrivez, c'est une inconnue. Vous pourriez demander qu'une analyse des risques appropriée soit effectuée, en ajoutant vos connaissances spécialisées au coût de l'atténuation du côté de l'équation, en mettant en chiffres la perte de productivité et les autres effets de la mesure actuelle. Cela doit être mis en balance avec le risque que les personnes chargées de la sécurité des informations identifient.

Il existe également d'autres mesures liées. Une solution typique que je recommande parfois (je suis un architecte de la sécurité de l'information de profession, donc on me pose régulièrement ces questions) est de séparer le réseau de développeurs du réseau de bureau ordinaire pour contenir la zone à haut risque. Renforcez suffisamment les machines de développement et insistez sur des pare-feu locaux et une protection antivirus à jour et vous êtes très 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 soient pas la proie aussi facilement d'attaques ciblées.

J'ai personnellement supervisé des environnements de développement des deux types, et avec un peu d'effort, les deux peuvent fonctionner correctement. Le simple fait de tirer la fiche d'un mode de travail établi le manipulait mal et le contrecoup dont vous faisiez partie était prévisible. Mais ce qui est fait est fait et il est probablement judicieux de ne pas se concentrer sur cela et de regarder vers l'avenir.

Séparez vos réseaux

Vous devriez 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 avoir des droits administratifs au cas où ils voudraient tester des extraits de code ou exécuter quelque chose sans l'empaqueter pour le déploiement à tester / produire.

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 au développement sont raisonnables.

Test

Le réseau de test est l'endroit où le code compilé et prêt à être expédié est testé. Les développeurs peuvent avoir des droits d'administrateur, mais les administrateurs système réguliers 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 au débogage, et ceux-ci sont les seules raisons pour lesquelles ils devraient avoir des droits d'administrateur. Ils ne doivent pas être impliqués dans l'installation, la configuration et les tests à moins que cela ne soit absolument nécessaire.

Production

Le réseau de production est l'endroit où vous fournissez des services aux clients et partenaires. Puisqu'il doit exister un processus de déploiement formel, il n'y a aucune raison pour qu'il se connecte à vos réseaux de développement / test.

Pour minimiser les risques de logiciels malveillants sur Internet et de modifications accidentelles, les comptes du développeur / test / entreprise les réseaux 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 des 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.

Entreprise

Il s'agit du principal réseau de communication de l'entreprise.

La messagerie électronique, la navigation Web et la connectivité des partenaires apportent tous un une multitude de risques. Vos réseaux de développement, de test et de production doivent être isolés de ces risques dans 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 balancer complètement le pendule que de gérer la myriade de 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:

1. Il existe des comptes distincts et non privilégiés pour l'accès à Internet
2. Des comptes uniques sont utilisés dans chaque environnement
3. Des règles de pare-feu / ACL restrictives existent entre environnements
4. 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 sans privilège pour accéder aux ressources sur Internet (s'ils ne veulent pas aller et venir du réseau d'entreprise, ce qui est onéreux)
• Compte de développement privilégié pour configurer le poste de travail et tester le code
• Compte de test privilégié pour déboguer les applications
• Compte professionnel non privilégié pour les e-mails, le Web, l'intranet

Si vous avez des développeurs qui effectuent des travaux de validation ou d'assurance qualité, ils m Vous avez également besoin de comptes non privilégiés dans l'environnement de test.

Les développeurs ne doivent pas avoir 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 des changements 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 encore tendance à ignorer l'idée de séparation des privilèges. Ce type de contrôle d'accès est mal 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 honnêteté , même sur les systèmes Unix / Linux, je vois que beaucoup de développeurs n'utilisent pas la séparation des privilèges de manière appropriée à la fois pour les utilisateurs réels et pour les services. Mais sur n'importe quelle plate-forme, placer des barrières dans la manière dont les implémenteurs séparent les privilèges est encore plus contre-productif pour la sécurité que de leur donner des privilèges d'administrateur (local) complets .

D'un autre côté , bien que je connaisse peu 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 les services ou les reconfigurer, je n'ai pas beaucoup de sympathie pour vous - il est possible de fournir cette fonctionnalité aux utilisateurs désignés sans leur donner local admin. L'un des grands changements dans IIS7 a été la fonctionnalité administrateur délégué. Et il a toujours été facile de déléguer la reconfig d'Apache, MySQL et PHP.

il y a eu peu de temps avant la suppression de l'accès administrateur local

Cela semble comme le problème est l'équipe de sécurité aspirant à un niveau de compétence qu'elle est incapable de fournir (cela, selon mon expérience, est très courant). Ils n'auraient pas dû imposer un changement de politique sans faire une évaluation d'impact appropriée et envisager des mesures d'atténuation pour tout dommage à 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 pour protéger l'intégrité de ces systèmes et brosse un tableau 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 savez pas comment atteindre leurs objectifs. Et il semble qu'aucune des deux parties ne soit disposée à négocier. Aucun outil standard ne résoudra ce problème.

Il est normal que l'accès administrateur local soit refusé aux développeurs dans des entreprises où soit les développeurs sont si inutiles / malveillants qu'ils abusent de ces privilèges, soit où le département "IT et sécurité" est dirigé par des idiots impuissants qui voient tout le monde ne faisant pas partie de leur entourage comme une menace de sécurité évidente pour leur donner une mauvaise apparence.

Étant donné que votre département "IT et sécurité" impose également deux programmes antivirus lorsque Windows est livré avec un tout à fait bon gratuit, Je suis presque sûr que vous pouvez déterminer où se situe le problème dans votre organisation et travailler à partir de là.