Risques de donner aux développeurs des droits d'administrateur sur leurs propres PC
Je dois convaincre mon service informatique interne de donner à ma nouvelle équipe de développeurs les droits d'administrateur sur nos propres PC. Ils semblent penser que cela créera un risque pour la sécurité du réseau. Quelqu'un peut-il expliquer pourquoi ce serait? Quels sont les risques? Qu'est-ce que les services informatiques mettent généralement en place pour les développeurs qui ont besoin de pouvoir installer des logiciels sur leurs PC.
Cette question était Question de sécurité de la semaine de la TI.
Lisez le 8 juin 2012 entrée de blog pour plus de détails ou soumettez le vôtre Question de la semaine.
À chaque endroit où j'ai travaillé (en tant que développeur de contrat), les développeurs reçoivent des droits d'administrateur local sur leurs bureaux.
Les raisons sont les suivantes:
1) Les jeux d'outils des développeurs sont souvent mis à jour très régulièrement. Bibliothèques graphiques, aides de code, mises à jour de Visual Studio; ils finissent par avoir des mises à jour presque hebdomadaires qui doivent être installées. Le support de bureau est généralement très fatigué d'obtenir 20 billets chaque semaine pour installer un logiciel mis à jour sur toutes les machines de développement, de sorte qu'ils donnent simplement aux administrateurs les droits d'administrateur pour le faire eux-mêmes.
2) Les outils de débogage/test ont parfois besoin de droits d'administrateur pour pouvoir fonctionner. Aucun accès administrateur signifie que les développeurs ne peuvent pas faire leur travail de débogage de code. Les gestionnaires n'aiment pas ça.
3) Les développeurs ont tendance à être plus soucieux de la sécurité et sont donc moins susceptibles d'exécuter/d'installer des logiciels malveillants dangereux. Évidemment, cela se produit toujours, mais dans l'ensemble, les développeurs peuvent généralement avoir confiance pour avoir un accès de plus haut niveau pour pouvoir faire leur travail.
Cela dépend en partie du type de logiciel que l'équipe de développement devrait développer. Certains types de logiciels sont plus faciles à développer sans droits administratifs que d'autres.
Par exemple, vous pouvez effectuer une bonne quantité de développement Web Java en utilisant des éléments comme Eclipse avec des artefacts Maven, tous installés localement (et généralement testés sur le port 8080), sans avoir besoin de beaucoup de droits d'administrateur (vous devrez peut-être ouvrir certains ports.) Développer des outils qui nécessitent un accès plus étroit au matériel peut s'avérer impossible sans droits d'administrateur. Cela étant dit, même pour le développement Web, il est recommandé de pouvoir reconstruire une machine de test à partir de zéro ( généralement une machine virtuelle), qui peut nécessiter des droits d'administrateur.
S'il s'agit de confiance (c'est-à-dire que certains membres de votre équipe de développement pourraient avoir des intentions malveillantes), vous avez quand même des ennuis. Il est peu probable que les administrateurs système qui approuveraient/désapprouveraient certains droits puissent vérifier en détail ce que fait le code qu'ils ont écrit. Cela ne signifie pas non plus que vous devez donner à votre équipe de développement un accès illimité à vos services de production, ni qu'ils doivent avoir un accès administrateur sur plus de machines que nécessaire, bien sûr. Il est bon d'avoir des mécanismes en place pour atténuer les risques, mais vous aurez besoin d'un certain niveau de confiance de base pour que votre organisation fonctionne. Mettre l'équipe de développement sur un réseau physique distinct est une première étape pour atténuer les problèmes de confiance et les erreurs possibles.
Un risque typique en ayant quelqu'un avec un accès administrateur est de pouvoir capturer des paquets sur le réseau. C'est un risque que vous devrez peut-être accepter selon la nature de ce qui est développé. Des outils comme Wireshark peuvent parfois être utiles pour le développement. Même au sein de votre organisation, les informaticiens ou les non-informaticiens devraient utiliser des services avec SSL/TLS activé si possible, cela devrait aider contre l'écoute clandestine et les attaques MITM.
Je peux penser à quelques inconvénients en n'accordant pas d'accès administrateur aux développeurs (à moins qu'ils n'en aient vraiment pas besoin):
Cela peut créer une culture "eux contre nous" entre les développeurs et les administrateurs système de votre organisation. Cela existe déjà dans de nombreux endroits, mais ce n'est généralement pas une bonne chose. Chaque équipe est susceptible de considérer l'autre comme une douleur. La sécurité n'est pas un problème purement technique, mais aussi une interaction humaine. Je pense qu'une bonne communication humaine devrait aider les objectifs globaux de votre organisation en général, pas seulement d'un point de vue de la sécurité en fait. (J'ai toujours trouvé que je pouvais trouver de meilleures solutions après parler en personne aux administrateurs système avec lesquels j'avais besoin de résoudre des problèmes plutôt que de répondre à un ticket sans visage.)
La nature humaine est telle que les gens deviennent créatifs lorsqu'ils sont limités, mais pas nécessairement de la bonne manière. Vous constaterez peut-être que les développeurs finissent par consacrer beaucoup d'efforts (et réussissent souvent) à contourner les limitations qui leur sont imposées au sein de l'organisation. Ils devraient utiliser leur créativité sur ce qu'ils sont censés faire à la place.
Les systèmes informatiques sont complexes et le débogage est un art sombre. Si vous devez déboguer votre produit par rapport à la version X.Z de la bibliothèque a.b.c_13 et a.b.c_24, les développeurs peuvent avoir besoin d'installer et de désinstaller chaque version, qui peut à son tour nécessiter un accès administrateur. La chasse aux bogues qui dépendent des numéros de version est déjà ennuyeuse. Si vous devez lever un ticket et attendre (peut-être des heures ou des jours) que quelqu'un d'autre installe/désinstalle la bonne version en fera un cauchemar: cela augmentera le problème culturel "eux contre nous" et, plus important encore, cela coûtera plus à l'organisation. Vous pouvez penser à cela du point de vue de l'évaluation des risques/coûts.
Le risque est une fonction croissante de l'accès
Il existe une règle simple de calcul des risques qui explique la peur de vos collègues de l'équipe informatique. Plus vous avez d'accès sur n'importe quel système d'exploitation, plus les impacts de toute erreur ou attaque sont importants.
Par exemple, si l'un de vos collègues, disons Bob, est attaqué par une attaque de phishing standard, alors le compte Bob est accessible aux cybercriminels et vendu sur Internet en quelques minutes. Si le compte Bob a des privilèges d'administrateur, ce compte sera utilisé pour envoyer du SPAM à grande échelle sur Internet, puis pour voler d'autres comptes avec des attaques de phishing à grande échelle, et très rapidement (en quelques minutes) ouvrira une porte dérobée à votre réseau (ceci est possible car le compte Bob est un compte administrateur) permettant un contrôle total à distance du PC de Bob (via des outils comme ssh, VNC, VPN...) . Cette attaque lancée depuis un PC interne, depuis un compte privilégié est capable de casser n'importe quel pare-feu, d'arrêter toute protection anti-virus, anti-spam.
Le mal est à l'intérieur.
Même vos meilleurs administrateurs réseau, administrateurs système ou administrateurs de sécurité peuvent laisser ce PC corrompu non détecté pendant des mois (cf. Stuxnet).
Fausse réduction des risques
Si vos collègues développeurs sont capables de gérer le système d'exploitation sur lequel ils fonctionnent et ont un accès physique à l'ordinateur, cette différence de risque est nulle.
N'importe quel ingénieur sur n'importe quel OS
peut s'accorder l'accès administrateur
s'il a un accès physique à l'ordinateur.
Le blocage de l'accès administrateur sur n'importe quel système d'exploitation est une approche de réduction des risques valide pour les utilisateurs qui ne sont pas en mesure de faire la différence entre les privilèges administrateur et les privilèges utilisateur normaux. Voici la question clé que je voudrais poser à vos collègues de l'équipe de développement et agir en fonction de leur conscience du risque:
"De quoi allez-vous vous occuper si on vous accorde
privilège administrateur sur votre système d'exploitation? "
S'ils sont assez bons pour être conscients des risques, alors ils sont assez bons pour obtenir l'accès qu'ils veulent. Il n'y a alors aucune réduction des risques en leur refusant cet accès administrateur. Attention: il y a un risque collatéral pour votre entreprise dans son ensemble si vous leur refusez un accès qu'ils peuvent facilement obtenir: ils le feront de façon sale, ils se comporteront comme hors la loi, ils ne pourront pas demander d'aide, ils devra couvrir tout incident.
Vous leur donnez des droits d'administrateur local sur leur poste de travail et tout ce qu'ils veulent. L'environnement de développement est toujours isolé du réseau principal. C'est le travail des TI de s'assurer que vous leur fournissez la configuration dont ils ont besoin tout en s'assurant que rien dans l'environnement de développement ne puisse endommager le réseau principal. Planifiez à l'avance et travaillez avec la direction pour acheter l'équipement/le logiciel dont vous avez besoin pour y parvenir.
Quelques éléments qui n'ont pas été mentionnés dans les réponses et commentaires précédents qui seraient un argument pour les développeurs travaillant sous le moindre privilège:
Selon l'industrie dans laquelle vous travaillez, il peut y avoir des raisons légales ou réglementaires qui empêchent les employés d'avoir des privilèges élevés sur leurs postes de travail. L'autorisation d'accès administratif aux développeurs pourrait exposer l'organisation au risque de non-conformité.
Lorsque des composants sont développés avec des privilèges élevés, il peut y avoir un risque d'échec lors du déploiement dans d'autres environnements qui ne disposent pas de ces privilèges. Les développeurs peuvent avoir mis à niveau ou ajouté par inadvertance des bibliothèques à leurs machines locales qui n'existent pas dans d'autres environnements, et les composants peuvent avoir des dépendances sur des versions spécifiques de ces bibliothèques. De plus, les comptes d'utilisateurs sous lesquels les composants s'exécuteront dans d'autres environnements peuvent ne pas disposer de la base de données requise ou d'un autre accès supposé par le développeur travaillant avec des droits élevés. J'ai vu cela se produire plusieurs fois dans le passé. Parfois, il est évident que le déploiement a échoué, parfois ce n'est pas le cas, et vous devez tout restaurer jusqu'à ce que vous puissiez le comprendre.
Si les développeurs installent des outils ou des bibliothèques open source et les utilisent pour le développement, il pourrait y avoir des restrictions de licence involontaires sur la façon dont le logiciel qu'ils produisent est éventuellement distribué, en particulier lorsque les termes de "copyleft" font partie de la licence. Il n'y a rien de mal à utiliser des outils ou des bibliothèques open source, cela devrait être intentionnel. Vous ne voulez pas savoir à la livraison que vous devez maintenant publier tout votre code source dans la communauté parce que vos développeurs ont utilisé un composant open source qui avait des termes de copyleft stricts dans la licence qu'ils n'avaient pas vraiment lus avant l'a installé.
Quelque chose que j'ai vu faire, c'est que les développeurs travaillent sous le moindre privilège, mais leur permettent de demander des privilèges élevés pour une période de temps spécifiée. Ensuite, cette "demande d'incendie" demande des privilèges élevés qu'elle enregistre et surveille, et est réinitialisée automatiquement à la fin du temps demandé.
Vous avez quelques questions auxquelles répondre.
- Quelles applications ces développeurs doivent utiliser quotidiennement nécessitent des privilèges d'administrateur et existe-t-il un moyen de configurer ces applications afin que ce ne soit pas le cas?
- Quelles raisons ces développeurs ont-ils besoin de privilèges d'administrateur pour effectuer des tâches quotidiennes triviales et existe-t-il un moyen d'éviter cela?
- Ces machines de développement sont-elles connectées à Internet?
La question ne devrait pas être quels sont les risques, la question devrait être (à laquelle vous ne pouvez répondre) quelles sont les raisons pour lesquelles les développeurs ont même besoin d'avoir un compte administrateur. Vous pouvez les créer avec un compte "utilisateur avancé" et leur donner la possibilité de faire exactement ce dont ils ont besoin, mais aussi de limiter leur capacité à nuire à votre réseau.
Si ces machines sont connectées à Internet ... alors vous introduirez un grand risque en raison de leur capacité à exécuter n'importe quoi et à installer quoi que ce soit sur ces machines. Ces développeurs sont de bons développeurs, ils ne sont pas des experts en sécurité, il s'agit seulement de QUAND ils commettront une erreur qui exposera le réseau aux logiciels malveillants.
Jetez un œil à Google par exemple. Un employé de Google clique sur un lien contenu dans une fenêtre MSN Messenger, télécharge un malware qui a profité d'un exploit déjà corrigé par Microsoft et infecte l'ensemble du réseau.
Je devrais ajouter que l'employé de Google en cliquant sur le lien n'avait rien à voir avec cette question, c'était pour souligner que les gens feraient une erreur alors limitez votre exposant.
Les risques de sécurité associés à la possibilité pour les développeurs d'installer leurs ordinateurs sont nombreux. Voici pourquoi je m'opposerais (en parlant en tant qu'administrateur système)
1) Violation potentielle des meilleures pratiques de sécurité - L'une des 8 règles de sécurité est la règle du moindre privilège - ne donne aux employés que l'accès à ce dont ils ont besoin pour accomplir leur tâche. Si quelqu'un me disait que son administrateur avait besoin d'un accès administrateur pour installer le logiciel pour faire son travail, je répondrais par "Pourquoi un membre de mon personnel ne peut-il pas l'installer pour lui?". Le fait d'avoir un point centralisé pour l'installation des logiciels garantit qu'un service informatique sait exactement quel logiciel se trouve sur quelle machine.
2) Raisons légales - Peut-être que l'un de vos développeurs a une éthique moins qu'admirable et décide d'installer un logiciel piraté. Non seulement ce logiciel est probablement criblé de logiciels malveillants, mais vous ouvrez ensuite une boîte de vers pour litige si vous êtes pris avec un logiciel piraté sur votre ordinateur. Un service informatique est considéré comme responsable de ces ordinateurs et, en tant que tels, ils sont chargés de les auditer et de s'assurer que la licence est conforme aux CGU de chaque logiciel. Bien qu'il soit pratique pour les développeurs de pouvoir installer leur propre logiciel sans déranger le service informatique, vous créez beaucoup plus de travail pour le service informatique.
3) Installation involontaire de logiciels malveillants - mentionné précédemment, mais cela pourrait être assez innocent. L'élévation des privilèges des utilisateurs afin qu'ils puissent installer des logiciels malveillants les rend vulnérables aux logiciels malveillants en ouvrant un PDF qu'ils ont obtenu via un e-mail ou un lecteur par téléchargement. Limiter l'accès des utilisateurs afin qu'ils ne puissent pas installer un logiciel aidera à atténuer la menace des logiciels malveillants.
4) Activité malveillante - Similaire au point 2, mais que dire d'un de vos développeurs ne va pas installer une porte dérobée ou ouvrir intentionnellement une autre menace de sécurité sur votre réseau. Vous seriez surpris de voir combien de professionnels de l'informatique font cela pour se venger s'ils devaient être licenciés ou si leur patron les faisait chier.
Dans l'ensemble, je devrais déconseiller cela. Bien que les gens puissent affirmer que cela gagnerait du temps en les empêchant de toujours mettre sur écoute l'informatique pour installer le logiciel, je dirais que "cela prend moins de temps pour le faire que pour corriger les failles de sécurité créées en permettant aux utilisateurs d'installer leur propre logiciel" . S'il est jugé que cela IS nécessaire, ils devraient vraiment être mis sur un réseau qui n'a pas d'accès direct au monde extérieur.
Une solution de contournement consiste à installer une machine virtuelle, non connectée au domaine. Ce sera assez compliqué, mais c'est mieux que d'être totalement paralysé par les politiques.