it-swarm-eu.dev

Risiken, Entwicklern Administratorrechte für ihre eigenen PCs zu erteilen

Ich muss meine interne IT-Abteilung davon überzeugen, meinem neuen Entwicklerteam Administratorrechte für unsere eigenen PCs zu erteilen. Sie scheinen zu glauben, dass dies ein gewisses Sicherheitsrisiko für das Netzwerk darstellt. Kann jemand erklären, warum das so ist? Was sind die Risiken? Was richten IT-Abteilungen normalerweise für Entwickler ein, die Software auf ihren PCs installieren müssen?.

Diese Frage war IT-Sicherheitsfrage der Woche.
Lesen Sie den 8. Juni 2012 Blogeintrag für weitere Details oder eigene einreichen Frage der Woche.

78
carolineggordon

An jedem Ort, an dem ich gearbeitet habe (als Vertragsentwickler), erhalten Entwickler lokale Administratorrechte auf ihren Desktops.

Die Gründe sind:

1) Entwickler-Toolsets werden häufig sehr regelmäßig aktualisiert. Grafikbibliotheken, Code-Helfer, Visual Studio-Updates; Am Ende erscheinen fast wöchentlich Updates, die installiert werden müssen. Der Desktop-Support wird es normalerweise sehr leid, jede Woche 20 Tickets für die Installation aktualisierter Software auf allen Entwicklungscomputern zu erhalten, sodass die Entwickler nur die Administratorrechte erhalten, dies selbst zu tun.

2) Debugging-/Test-Tools benötigen manchmal Administratorrechte, um funktionieren zu können. Kein Administratorzugriff bedeutet, dass Entwickler ihren Code nicht debuggen können. Manager mögen das nicht.

3) Entwickler sind in der Regel sicherheitsbewusster und führen/installieren daher seltener gefährliche Malware. Natürlich passiert es immer noch, aber insgesamt kann man Entwicklern normalerweise vertrauen, dass sie über einen höheren Zugriff verfügen, um ihre Arbeit erledigen zu können.

63
Alan Barber

Dies hängt teilweise von der Art der Software ab, die das Entwicklerteam entwickeln soll. Einige Softwaretypen lassen sich ohne Administratorrechte einfacher entwickeln als andere.

Zum Beispiel können Sie eine ganze Menge webbasierter Java -Entwicklung mit Eclipse mit Maven-Artefakten durchführen, die alle lokal installiert sind (und normalerweise auf Port 8080 getestet werden), ohne dass viele Administratorrechte erforderlich sind (Möglicherweise müssen Sie bestimmte Ports öffnen.) Die Entwicklung von Tools, die einen engeren Zugriff auf die Hardware benötigen, kann sich ohne Administratorrechte als unmöglich erweisen. Selbst für die Webentwicklung empfiehlt es sich, einen Testcomputer von Grund auf neu erstellen zu können ( normalerweise eine VM), für die möglicherweise Administratorrechte erforderlich sind.

Wenn es um Vertrauen geht (d. H. Einige Mitglieder Ihres Entwicklerteams könnten böswillige Absichten haben), sind Sie trotzdem in Schwierigkeiten. Es ist unwahrscheinlich, dass die Systemadministratoren, die bestimmte Rechte genehmigen/ablehnen würden, überprüfen können, was der von ihnen geschriebene Code im Detail bewirkt. Das bedeutet weder, dass Sie Ihrem Entwicklerteam uneingeschränkten Zugriff auf Ihre Produktionsservices gewähren sollten, noch, dass es Administratorzugriff auf mehr Maschinen haben sollte, als es benötigt. Es ist gut, über Mechanismen zu verfügen, um Risiken zu minimieren, aber Sie benötigen ein grundlegendes Maß an Vertrauen, damit Ihr Unternehmen funktioniert. Die Einrichtung des Entwicklerteams in einem separaten physischen Netzwerk ist ein erster Schritt, um Vertrauensprobleme und mögliche Fehler zu verringern.

Ein typisches Risiko für jemanden mit Administratorzugriff besteht darin, Pakete im Netzwerk erfassen zu können. Dies ist ein Risiko, das Sie je nach Art der Entwicklung möglicherweise akzeptieren müssen. Tools wie Wireshark können manchmal für die Entwicklung nützlich sein. Selbst innerhalb Ihres Unternehmens sollten IT- oder Nicht-IT-Mitarbeiter nach Möglichkeit Dienste mit aktiviertem SSL/TLS verwenden. Dies sollte Abhör- und MITM-Angriffen entgegenwirken.

Ich kann mir ein paar Nachteile vorstellen, wenn ich Entwicklern keinen Administratorzugriff erteile (es sei denn, sie brauchen ihn wirklich nicht):

  • Dies kann zu einer Kultur zwischen Entwicklern und Systemadministratoren in Ihrer Organisation führen. Dies gibt es bereits an vielen Orten, aber es ist im Allgemeinen keine gute Sache. Jedes Team wird das andere wahrscheinlich als Schmerz betrachten. Sicherheit ist kein rein technisches Problem, sondern auch ein menschliches Interaktionsproblem. Ich denke, eine gute menschliche Kommunikation sollte die allgemeinen Ziele Ihrer Organisation im Allgemeinen unterstützen, nicht nur unter Sicherheitsgesichtspunkten. (Ich habe immer festgestellt, dass ich nach im persönlichen Gespräch mit den Systemadministratoren, mit denen ich Probleme lösen musste, bessere Lösungen finden konnte, anstatt auf ein gesichtsloses Ticket zu antworten.)

  • Die menschliche Natur ist so, dass Menschen kreativ werden, wenn sie begrenzt sind, aber nicht unbedingt auf die richtige Weise. Möglicherweise stellen Sie fest, dass die Entwickler sich ziemlich viel Mühe geben (und es oft gelingen), die ihnen innerhalb der Organisation auferlegten Einschränkungen zu umgehen. Sie sollten ihre Kreativität stattdessen für das einsetzen, was sie tun sollen.

  • IT-Systeme sind komplex und das Debuggen ist eine dunkle Kunst. Wenn Sie Ihr Produkt gegen die Bibliotheks-XYZ-Versionen a.b.c_13 und a.b.c_24 debuggen müssen, müssen die Entwickler möglicherweise in der Lage sein, jede Version zu installieren und zu deinstallieren, was wiederum Administratorzugriff erfordern kann. Das Verfolgen von Fehlern, die von den Versionsnummern abhängen, ist bereits ärgerlich. Wenn Sie ein Ticket erheben und warten müssen (vielleicht Stunden oder Tage), bis jemand anderes die richtige Version installiert/deinstalliert, wird dies zu einem Albtraum: Dies erhöht das kulturelle Problem "Sie gegen uns" und, was noch wichtiger ist, die Kosten mehr zur Organisation. Sie können sich dies aus Sicht der Risiko-/Kostenbewertung vorstellen.

28
Bruno

Das Risiko ist eine zunehmende Funktion des Zugangs

Es gibt eine einfache Regel für die Risikoberechnung, die die Angst Ihrer Kollegen im IT-Team erklärt. Je mehr Zugriff Sie auf ein Betriebssystem haben, desto höher sind die Auswirkungen von Fehlern oder Angriffen.
Wenn beispielsweise einer Ihrer Kollegen, beispielsweise Bob, durch einen Standard-Phishing-Angriff angegriffen wird, steht das Bob-Konto Cyberkriminellen zur Verfügung und wird innerhalb von Minuten im Internet verkauft. Wenn das Bob-Konto über Administratorrechte verfügt, wird dieses Konto verwendet, um SPAM in großem Umfang im Internet zu senden, andere Konten mit Phishing-Angriffen in großem Umfang zu stehlen und sehr schnell (innerhalb von Minuten) eine Hintertür zu Ihrem Konto zu öffnen Netzwerk (dies ist möglich, da es sich bei dem Bob-Konto um ein Administratorkonto handelt), das eine vollständige Fernsteuerung von Bobs PC ermöglicht (über Tools wie ssh, VNC, VPN...) . Dieser Angriff, der von einem internen PC aus von einem privilegierten Konto aus ausgelöst wird, kann jede Firewall beschädigen und jeglichen Viren- und Spamschutz verhindern.

Das Böse ist drinnen.

Selbst Ihre besten Netzwerkadministratoren, Systemadministratoren oder Sicherheitsadministratoren können diesen beschädigten PC monatelang unberührt lassen (vgl. Stuxnet).

Falsche Risikominderung

Wenn Ihre Entwicklerkollegen das Betriebssystem, auf dem sie arbeiten, gut verwalten können und physischen Zugriff auf den Computer haben, ist dieser Risikodifferenz null.

Jeder Ingenieur unter jedem Betriebssystem
kann sich selbst Administratorzugriff gewähren
wenn er physischen Zugriff auf den Computer hat.

Das Blockieren des Administratorzugriffs auf einem beliebigen Betriebssystem ist ein gültiger Ansatz zur Risikominderung für Benutzer, die keinen Unterschied zwischen Administratorrechten und normalen Benutzerrechten machen können. Hier ist die Schlüsselfrage, die ich Ihren Entwicklerteamkollegen stellen und auf deren Risikobewusstsein reagieren möchte:

"Worauf werden Sie achten, wenn Sie gewährt werden?
Administratorrechte auf Ihrem Betriebssystem? "

Wenn sie gut genug sind, um risikobewusst zu sein, sind sie gut genug, um den gewünschten Zugang zu erhalten. Dann gibt es keine Risikominderung, wenn ihnen dieser Administratorzugriff verweigert wird. Achtung: Es besteht ein Kollateralrisiko für Ihr Unternehmen als Ganzes, wenn Sie ihnen einen Zugang verweigern, den sie leicht erhalten können: Sie tun es auf schmutzige Weise, sie verhalten sich wie Gesetzlose, sie können keine Hilfe anfordern, sie Ich muss jedes Missgeschick abdecken.

10
dan

Sie geben ihnen lokale Administratorrechte für ihre Workstation und alles andere, was sie wollen. Die Entwicklungsumgebung ist immer vom Hauptnetzwerk isoliert. Es ist Aufgabe der IT, sicherzustellen, dass Sie ihnen das Setup zur Verfügung stellen, das sie benötigen, und gleichzeitig sicherstellen, dass nichts in der Entwicklungsumgebung das Hauptnetzwerk schädigen kann. Planen Sie im Voraus und arbeiten Sie mit dem Management zusammen, um die Ausrüstung/Software zu kaufen, die Sie dazu benötigen.

8
wrb

Einige Dinge, die in früheren Antworten und Kommentaren nicht erwähnt wurden, wären ein Argument für Entwickler, die unter den geringsten Privilegien arbeiten:

  1. Abhängig von der Branche, in der Sie arbeiten, kann es rechtliche oder behördliche Gründe geben, die Mitarbeiter daran hindern, erhöhte Berechtigungen auf ihren Arbeitsstationen zu haben. Durch das Zulassen des Administratorzugriffs für Entwickler kann das Unternehmen gefährdet werden, die Richtlinien nicht einzuhalten.

  2. Wenn Komponenten mit erhöhten Berechtigungen entwickelt werden, besteht das Risiko eines Ausfalls während der Bereitstellung in anderen Umgebungen, die nicht über diese Berechtigungen verfügen. Entwickler haben möglicherweise versehentlich Bibliotheken auf ihren lokalen Computern aktualisiert oder hinzugefügt, die in anderen Umgebungen nicht vorhanden sind, und die Komponenten sind möglicherweise von bestimmten Versionen dieser Bibliotheken abhängig. Außerdem haben Benutzerkonten, unter denen die Komponenten in anderen Umgebungen ausgeführt werden, möglicherweise nicht die erforderliche Datenbank oder einen anderen Zugriff, der vom Entwickler mit erhöhten Berechtigungen angenommen wurde. Ich habe dies in der Vergangenheit schon oft gesehen. Manchmal ist es offensichtlich, warum die Bereitstellung fehlgeschlagen ist, manchmal nicht, und Sie müssen alles zurücksetzen, bis Sie es herausfinden können.

  3. Wenn Entwickler Open-Source-Tools oder -Bibliotheken installieren und diese für die Entwicklung verwenden, kann es zu unbeabsichtigten Lizenzbeschränkungen bei der Verteilung der von ihnen produzierten Software kommen, insbesondere wenn "Copyleft" -Begriffe Teil der Lizenz sind. Es ist nichts Falsches an der Verwendung von Open Source-Tools oder -Bibliotheken, es sollte nur beabsichtigt sein. Sie möchten bei der Lieferung nicht herausfinden, dass Sie jetzt Ihren gesamten Quellcode wieder in der Community veröffentlichen müssen, da Ihre Entwickler eine Open-Source-Komponente verwendet haben, deren Lizenz strenge Copyleft-Bedingungen enthält, die sie zuvor nicht wirklich gelesen haben installiert es.

Ich habe gesehen, dass die Entwickler unter den geringsten Berechtigungen arbeiten, ihnen jedoch erlauben, für einen bestimmten Zeitraum erhöhte Berechtigungen anzufordern. Anschließend wird diese "Feuerruf" -Anforderung für erhöhte Berechtigungen aufgezeichnet und überwacht und am Ende der angeforderten Zeit automatisch zurückgesetzt.

8
Todd Dill

Sie haben ein paar Fragen zu beantworten.

  1. Welche Anwendungen, die diese Entwickler täglich verwenden müssen, erfordern Administratorrechte. Gibt es eine Möglichkeit, diese Anwendungen so einzurichten, dass dies nicht der Fall ist?
  2. Aus welchen Gründen benötigen diese Entwickler Administratorrechte, um triviale tägliche Aufgaben zu erledigen, und gibt es eine Möglichkeit, dies zu vermeiden?
  3. Sind diese Entwicklermaschinen mit dem Internet verbunden?

Die Frage sollte nicht sein, was die Risiken sind, die Frage sollte sein (was Sie nur beantworten können), warum die Entwickler überhaupt ein Administratorkonto benötigen. Sie können sie mit einem "Power User" -Konto einrichten und ihnen die Möglichkeit geben, genau das zu tun, was sie benötigen, aber auch ihre Fähigkeit einschränken, Ihrem Netzwerk Schaden zuzufügen.

Wenn diese Maschinen mit dem Internet verbunden sind, besteht ein großes Risiko, da sie alles ausführen und auf diesen Maschinen installieren können. Diese Entwickler sind gute Entwickler, sie sind keine Sicherheitsexperten, es ist nur eine Frage, WANN sie einen Fehler machen, der das Netzwerk Malware aussetzt.

Schauen Sie sich zum Beispiel Google an. Ein Google-Mitarbeiter klickt auf einen Link in einem MSN Messenger-Fenster, lädt Malware herunter, die einen bereits von Microsoft behobenen Exploit ausnutzt, und infiziert das gesamte Netzwerk.

Ich sollte hinzufügen, dass der Google-Mitarbeiter, der auf den Link klickt, nichts mit dieser Frage zu tun hat. Es sollte darauf hingewiesen werden, dass die Leute einen Fehler machen werden, also beschränken Sie Ihren Exposer.

4
Ramhound

Die Sicherheitsrisiken, die mit der Möglichkeit für Entwickler verbunden sind, ihre Computer zu installieren, sind zahlreich. Hier ist, warum ich Einwände erheben würde (als Systemadministrator sprechen)

1) Möglicher Verstoß gegen die besten Sicherheitspraktiken - Eine der 8 Sicherheitsregeln ist die Regel der geringsten Berechtigungen. Geben Sie den Mitarbeitern nur Zugriff auf das, was sie zur Erfüllung ihrer Aufgabe benötigen. Wenn mir jemand sagte, dass der Entwickler Administratorzugriff benötigt, um Software für seine Arbeit zu installieren, würde ich mit "Warum kann einer meiner Mitarbeiter sie nicht für ihn installieren?" Antworten. Durch einen zentralen Punkt für die Installation von Software wird sichergestellt, dass eine IT-Abteilung genau weiß, welche Software sich auf welchem ​​Computer befindet.

2) rechtliche Gründe - Vielleicht hat einer Ihrer Entwickler eine weniger als bewundernswerte Ethik und beschließt, Raubkopien zu installieren. Diese Software ist wahrscheinlich nicht nur mit Malware durchsetzt, sondern Sie öffnen auch eine Dose Würmer für Rechtsstreitigkeiten, falls Sie mit Raubkopien auf Ihrem Computer erwischt werden. Eine IT-Abteilung ist für diese Computer verantwortlich und als solche dafür verantwortlich, sie zu prüfen und sicherzustellen, dass die Lizenzierung den Nutzungsbedingungen jeder Software entspricht. Während es für die Entwickler praktisch ist, dass sie ihre eigene Software installieren können und die IT-Abteilung nicht stören, schaffen Sie viel mehr Arbeit für die IT-Abteilung.

3) nbeabsichtigte Installation von Malware - bereits erwähnt, dies könnte jedoch unschuldig genug sein. Wenn Sie die Benutzerrechte erhöhen, damit sie Malware installieren können, sind sie anfällig für Malware, indem Sie ein infiziertes PDF öffnen, das sie per E-Mail oder über ein Laufwerk per Download erhalten haben. Durch die Einschränkung des Benutzerzugriffs, damit keine Software installiert werden kann, wird die Bedrohung durch Malware verringert.

4) böswillige Aktivität - Ähnlich wie Punkt 2, aber was soll ich sagen, dass einer Ihrer Entwickler keine Hintertür installieren oder absichtlich eine andere Sicherheitsbedrohung in Ihrem Netzwerk öffnen wird? Sie wären überrascht, wie viele IT-Experten dies tun, um sich zu rächen, wenn sie gekündigt werden oder ihr Chef sie verärgert.

Alles in allem müsste ich davon abraten. Während die Leute vielleicht argumentieren, es würde Zeit sparen, um zu verhindern, dass sie die IT bei der Installation von Software immer nerven, würde ich dem entgegenwirken: "Es dauert weniger Zeit, dies zu tun, als Sicherheitslücken zu schließen, die dadurch entstehen, dass Benutzer ihre eigene Software installieren können." . Wenn dies als IS notwendig erachtet wird, sollten sie wirklich in ein Netzwerk eingebunden werden, das keinen direkten Zugang zur Außenwelt hat.

4
DKNUCKLES

Eine Problemumgehung besteht darin, eine virtuelle Maschine zu installieren, die nicht mit der Domäne verbunden ist. Es wird ein ziemlicher Aufwand sein, aber es ist besser, als von der Politik total verkrüppelt zu werden.

2
Louis Somers