Ist das Sperren eines Entwicklers mehr Aufwand als sein Wert? [geschlossen]

Nachdem ich als Entwickler und IT-Administrator / Support-Mitarbeiter für ein Entwicklungsteam gearbeitet habe, bin ich auf viele verschiedene Arten von Umgebungen gestoßen, von vollständig gesperrten bis zu nicht gesperrten Umgebungen. Aufgrund meiner begrenzten Supporterfahrung war es meiner Meinung nach weniger aufwendig, mit einem weniger gesperrten Computer zu arbeiten, und ich hatte das Gefühl, dass dies einfacher war, aber natürlich könnte dies eine Verzerrung sein. Ich würde gerne wissen, wie die Sichtweise des IT-Supports ist. Ist es wirklich schwieriger, Entwickler mit nicht gesperrten Computern zu unterstützen?

Das größte Problem, wenn ein Entwicklercomputer nicht gesperrt wird, besteht darin, dass jede von ihm entwickelte Software vollständige Administratorrechte benötigt, um ausgeführt werden zu können. Der Entwicklerzugriff sollte mit der Umgebung identisch sein, in der er ausgeführt werden muss. Wenn er "selbstunterstützend" oder "selbstinstallierend" sein muss, geben Sie ihm ein anderes Administratorkonto, z. B. Bruce.admin, das er für die Verwaltung verwenden muss Zeug, aber nicht verwendet von Tag zu Tag.

So wie kein anständiger UNIX-Administrator, der es wert ist, jemals ein Root-Konto für seine tägliche Nicht-Administrator-Arbeit verwenden wird.

Die meisten Entwickler sind technisch versiert und wissen, was sie tun. Sie müssen häufig viele spezialisierte Apps installieren, müssen dazu die Erlaubnis einholen und müssen dafür sorgen, dass die IT herunterfährt und sie hinzufügt. Dies kann für beide Seiten sehr frustrierend sein, insbesondere in größeren Unternehmen.

Ich habe festgestellt, dass es am besten funktioniert, wenn sie das tun, was sie wollen, um Software auf ihren Computern zu installieren. Wenn sie jedoch Probleme mit etwas bekommen, das wir nicht unterstützen, sind sie auf sich allein gestellt. Die meisten Entwickler sind damit zufrieden und möchten sich sowieso lieber um ihre eigene Maschine kümmern können.

Es ist in Ordnung, jemanden in der Buchhaltung zu sperren, um nur IE und Open Word zu verwenden. Wenn Sie jedoch ein Entwickler sind, der 4 verschiedene Browsertypen installieren und eine App schnell installieren muss, um ein Problem zu lösen, kann dies ärgerlich sein.

Ich habe die Erfahrung gemacht, dass Unternehmen, die viel technisches Wissen haben, also Entwicklungsbetriebe, IT-Zulieferer usw., die ihren Mitarbeitern vertrauen und entscheiden lassen, was sie installieren möchten, viel glücklicher sind und die IT weniger stören

In diesem Stackoverflow-Beitrag wird eine lebhafte Debatte über die Vorteile des Sperrens von Entwicklermaschinen geführt. (Haftungsausschluss: Ich habe die akzeptierte Antwort geschrieben).

Aus sysadministischer Sicht ist der Zugriff auf Produktionssysteme vertraulich, und Sie sollten diesen Zugriff auf Personen beschränken, die ihn für ihre Arbeit benötigen (dies kann Entwickler mit Tier-3-Support-Zuständigkeiten für die Anwendung einschließen). Lokale Administratorrechte über einen Entwicklungs-PC oder Entwicklungsserver beeinträchtigen die Sicherheit Ihrer Produktionssysteme nicht wesentlich.

Erstellen Sie ein Image, mit dem Sie die Computer bei Bedarf neu erstellen können. Das manuelle Installieren von SQL Server Dev Edition, Visual Studio, Cygwin und MikTex sowie einer Reihe anderer Apps ist recht zeitaufwändig. Ein Image mit diesen großen installierten Apps ist einigermaßen wertvoll, wenn Sie die Computer häufig neu imageen müssen.

Aus Sicht der Entwicklung kann ich die meisten Probleme mit dem Computer beheben und benötige in der Regel nur in seltenen Fällen Hilfe von Mitarbeitern des Netzwerk-Supports. Übermäßig restriktive Umgebungen neigen dazu, falschen Entwickler-Support-Datenverkehr zu generieren, um Arbeiten auszuführen, die die Entwickler perfekt selbst ausführen können.

Ein weiterer Ort, an dem Entwickler in der Regel viel Verwaltungsarbeit benötigen, sind Datenbankserver, auf denen sich Entwicklungsumgebungen befinden. Die meisten Entwickler sind in der Lage, routinemäßige DBA-Aufgaben mühelos zu erlernen, und sollten sowieso ein funktionierendes Wissen darüber erhalten (IMHO-Prinzip). Übermäßig restriktive Administratorzugriffsrichtlinien auf Entwicklungsservern können auf viele Arten unterlaufen werden.

Ein Scratch-Entwicklungsnetzwerk ist eine gute Idee, wenn es eingerichtet werden kann - Sie können dies bei Bedarf von Ihren Produktionsservern aus durch eine Firewall schützen.

• Wenn Entwickler die Struktur einer Produktionsumgebung auf einfache Weise replizieren können, wird eine Testkultur für die Bereitstellung gefördert, bei der ein Integrationstest synthetisiert werden kann, ohne durch die Rahmen springen zu müssen. Dies wird tendenziell die Qualität der Produktionsfreigabe und -bereitstellung verbessern.

• Die Fähigkeit, eine Produktionsumgebung zu emulieren, schärft auch das Bewusstsein für Probleme bei der Bereitstellung und beim Support der Produktion. Es ermutigt die Entwicklungsmitarbeiter, darüber nachzudenken, wie eine Anwendung in der Produktion unterstützt werden könnte, was wahrscheinlich Architekturen fördern wird, die in diesem Sinne erstellt wurden.

• Wenn dieses Netzwerk über einen Domänencontroller verfügt, können Sie eine Vertrauensstellung einrichten, sodass der Hauptdomänencontroller und seine Konten als vertrauenswürdig eingestuft werden. Diese Vertrauensbeziehung muss nicht wechselseitig sein, sodass die Sicherheit Ihrer Produktionsnetzwerkinfrastruktur nicht beeinträchtigt wird. Dies kann dazu führen, dass Sie ein nicht vertrauenswürdiges Entwicklungsnetzwerk haben, den Entwicklern jedoch weiterhin Zugriff auf domänenauthentifizierte Ressourcen wie Exchange-Konten oder Dateiserver gewähren.

• Sie möchten, dass Entwickler ausreichend Spielraum zum Experimentieren haben, ohne durch die Rahmen springen zu müssen. Das Aufstellen politischer Hindernisse auf dem Weg zu dieser Arbeit führt tendenziell dazu, dass Putzlösungen aufgeklebt werden, die zwar politisch sinnvoll sind, jedoch langfristige (und häufig nicht anerkannte) technische Schulden verursachen. Erraten Sie als Systemadministrator oder Support-Analyst, wer die Teile einsammeln darf ...

Ich möchte hinzufügen, dass dies in einer Unix- oder Linux-Umgebung weitaus weniger ein Problem darstellt. Benutzer können ihre eigene Umgebung ziemlich stark anpassen .profile. Sie können /home/bloggsj/binnach Herzenslust Dinge in Ihrem eigenen Verzeichnis kompilieren und installieren . 'Lokale Administratorrechte' sind meist ein Windows-Problem, obwohl es unter Unix noch einige Dinge gibt, die root-Zugriff benötigen.

Die vernünftigste Option, die ich je gesehen habe (war auf beiden Seiten - und ist es immer noch -), ist einfach freigeschaltetes und nicht unterstütztes Material . Geben Sie ihnen Freiheit, und wenn sie es vermasseln, können sie nur ein Bild mit einem Standard-Image wiederherstellen .... In dieser Situation halte ich es für einen guten Plan, sie in irgendein "nicht vertrauenswürdiges" Netzwerk zu stellen.

Soweit das (Nicht-) Gefühl, Entwickler-Desktops zu sperren: Ich bin mir ziemlich sicher, dass alle Sperren ohnehin nur die Produktivität beeinträchtigen. Außerdem wird jeder einigermaßen erfahrene Entwickler die Lücken leicht finden ....

Die Antwort ist wirklich: Es gibt keine einfache Ja- oder Nein-Antwort. Aber Sicherheit ist für Ihre Entwicklerbenutzer mindestens genauso wichtig wie für alle anderen.

Einerseits neigen ja Entwickler dazu, technisch versierter zu sein. Auf der anderen Seite ist ihre Arbeit oft stressig und ihre Entwicklungsmeilensteine ​​haben wahrscheinlich Vorrang vor der zusätzlichen Sorgfalt, die erforderlich ist, um das eigene System als sichere Umgebung zu erhalten. Dies ist keine Kritik an Entwicklern. Es ist eine klare Betrachtung ihrer täglichen Pflichten.

Wenn Sie Entwicklern uneingeschränkten Zugriff auf ihre Systeme gewähren möchten, sollten Sie die folgenden zusätzlichen Maßnahmen in Betracht ziehen:

• Stellen Sie ein anderes System bereit, das für den normalen Gebrauch durch Nicht-Entwickler gesperrt ist, so wie normale Benutzersysteme gesperrt sind.
  • Die Entwicklercomputer mit vollem Zugriff werden in ein spezielles VLAN gestellt, das nur auf Entwicklerressourcen zugreifen kann.
• Fragen Sie, was ein infiziertes System daran hindern könnte, die Codebasis zu gefährden. Könnte eine Backdoor-Maschine in den Händen eines feindlichen Hackers bösartigen Code einchecken oder die Codebasis auslöschen? Ergreifen Sie geeignete Maßnahmen, um dieses Risiko zu verringern.
• Fragen Sie in ähnlicher Weise, ob die Geschäftsdaten in den Systemen, auf die die Entwickler Zugriff haben, durch irgendetwas geschützt werden.
• Führen Sie regelmäßig Softwareinventuren und Sicherheitsüberprüfungen von Entwicklungssystemen durch.
  • Machen Sie sich ein Bild davon, was sie ausführen, und verwenden Sie diese Informationen, um die Images für die Neuverteilung Ihres Entwicklungssystems zu erstellen.
  • Früher oder später haben Sie einen Entwickler, der nachlässig wird und Dinge installiert, die eindeutig gefährlich oder völlig arbeitsfrei sind. Wenn Sie in diesem Fall schnell Warnungen senden, werden Sie die Entwicklergemeinschaft darüber informieren, dass ja, jemand zuschaut, und dass er dafür verantwortlich ist, angemessene Standards einzuhalten.
• Führen Sie regelmäßige Malware-Scans durch? In einigen Fällen beklagen Entwickler zu Recht die Leistungssteuer, die von On-Access-AV-Systemen erhoben wird (jene AV-Systeme, die immer eingeschaltet sind und bei jedem Dateizugriff immer scannen). Möglicherweise empfiehlt es sich, nachts zu scannen und / oder beim Scannen bei Zugriff Datei- / Ordnerausschlüsse zu erstellen. Stellen Sie jedoch sicher, dass ausgeschlossene Dateien auf andere Weise gescannt werden.
  • Können Ihre admin-fähigen Entwickler alle AV-Scans deaktivieren? Wie würden Sie dies erkennen und beheben?

Wenn Sie Dev-Systeme sperren möchten, sollten Sie Folgendes berücksichtigen:

• Verfügen Sie über die Support-Kapazität, um Ihre Support-Anfragen schnell zu beantworten? Betrachten Sie die durchschnittliche Vergütung Ihrer Entwickler und fragen Sie, ob sie eine schnellere SLA-Antwortzeit verdienen. Es ist wahrscheinlich nicht sinnvoll, Ihren 120.000-Dollar-Entwickler (der der Schlüssel zu einem millionenschweren Projekt ist) warten zu lassen, während Sie Supportanfragen von 60.000-Dollar-Mitarbeitern pro Jahr bearbeiten.
• Haben Sie eine klare und eindeutige Richtlinie darüber, welche Support-Anfragen Sie für Ihre Entwickler bearbeiten und welche nicht? Wenn sie das Gefühl anfangen, dass die Unterstützung beliebig ist, Sie werden schließlich den Schmerz fühlen.

In jedem Fall müssen Sie zugeben, dass Entwickler ein Sonderfall sind und zusätzliche Unterstützung benötigen. Wenn Sie dies nicht budgetieren, treten wahrscheinlich gerade Probleme auf ... oder werden es in Zukunft sein.

Nebenbei bemerkt, ich habe sehr ähnliche Auseinandersetzungen mit Sysadmins gesehen. Bei mindestens zwei verschiedenen Jobs haben sich Sysadmins ziemlich scharfsinnig gestritten, als ihnen vorgeschlagen wurde, Systeme selbst zu sperren, oder mindestens zwei Anmeldungen zu verwenden (eine mit root / admin-Rechten; eine ohne). Viele Sysadmins waren der Meinung, dass sie in keiner Weise gesperrt werden sollten und sprachen sich energisch gegen solche Maßnahmen aus. Früher oder später hatte ein Admin, der sich einer Sperre widersetzte, einen Sicherheitsvorfall und das Beispiel hatte einen erzieherischen Effekt auf uns alle.

Früher war ich einer dieser Sysadmins, die die ganze Zeit mit Administratorrechten gearbeitet haben. Als ich die Umstellung auf zwei Konten vorgenommen und nur bei Bedarf erhöht habe, muss ich zugeben, dass es in den ersten Monaten ziemlich frustrierend war. Aber der Silberstreifen in der Cloud war, dass ich viel mehr über die Sicherheit der von mir verwalteten Systeme erfahren habe, als mein normales Konto denselben Einschränkungen unterlag, die ich den Benutzern auferlegte. Es hat mich zu einem besseren Admin gemacht! Ich vermute, dass dies auch für Entwickler gilt. Zum Glück gibt es in der Windows-Welt jetzt eine Benutzerkontensteuerung, die es einfacher macht, als Benutzer mit eingeschränkten Rechten zu arbeiten und nur bei Bedarf zu erhöhen.

Persönlich denke ich nicht, dass jemand über irgendeiner Form von Sicherheitspraktiken stehen sollte. Jeder (Sysadmins, Entwickler, einschließlich des oberen Managements) sollte ausreichend Sicherheitsverfahren und -aufsicht unterliegen, um auf dem Laufenden zu bleiben. Anders zu sagen bedeutet, dass Unternehmenssysteme und -daten den Schutz nicht wert sind.

Sagen wir es anders. Wenn Mark Russinovich von einem Rootkit aufgenommen werden kann, kann das jeder!

Wenn Sie einige Entwickler haben, ist der Ansatz, ihnen Entwicklungsserver zu geben, eine Möglichkeit, aber wenn Sie eine ganze Etage von Entwicklern haben, bin ich sehr dagegen, ihnen Administratorrechte zu erteilen.

Das Problem ist, dass Sie am Ende eine ganze Reihe von Entwicklern haben, die jeweils das tun, was sie tun. Die meisten sind normalerweise nicht einmal sicherheitsbewusst und möchten nur, dass ihre App funktioniert. Dann erhalten Sie die Aufforderung: "Wir haben die Entwicklungsphase abgeschlossen. Bitte replizieren Sie unsere Entwicklungsumgebung auf test, pre-prod und prod."

Sie werden auch angewöhnt, zufälligen Müll (schlecht verpackte Software) zu installieren und Sie dann zu beauftragen, ihn auf etwa einem Dutzend Servern in den anderen Ebenen zu installieren.

Ich mache die Politik ganz einfach:

• Entwickler erhalten KEINEN Root-Zugriff für die Entwicklungsumgebung.
• Die Entwickler erhalten zwar Root-Zugriff auf VMware-Server vor der Entwicklung, aber KEINE Unterstützung.
• Entwickler müssen entweder RPM-Pakete bereitstellen, die zur Betriebssystemdistribution gehören, auf der ihre App ausgeführt wird, oder RPM-Pakete, die mit FHS und LSB kompatibel sind.
• Keine ihrer Anwendungen kann unter keinen Umständen als root ausgeführt werden
• Sie haben keinen Zugriff auf suoder sudoauf den Anwendungsbenutzer - der darauf beschränkt ist, KEINEN Shell-Zugriff zu haben. (Dies ist für die Buchhaltung / Prüfung).
• Alle Befehle, die sie mit privilegiertem Zugriff ausführen müssen, müssen explizit angefordert und genehmigt werden. Zu diesem Zeitpunkt wird sie der sudoersDatei hinzugefügt .
  • Keiner dieser Befehle / Skripte kann von ihnen geschrieben werden.
  • Kein Skript (direkt oder indirekt), auf das diese Befehle verweisen, kann von ihnen geschrieben werden.

Dies wird sie vor allem dazu bringen, darüber nachzudenken, was erlaubt ist und was nicht, wenn es Zeit ist, das Projekt auf die Testserver und höher zu verschieben.

Das Abschalten von Entwicklermaschinen ist aufwändiger als es sich lohnt. Dies beeinträchtigt die Produktivität erheblich, da Sie ohne Administratorrechte kaum etwas unternehmen können. Natürlich wird das System irgendwann durcheinander geraten, aber Ihre IT-Abteilung bietet sicherlich keine Unterstützung für alle Tools von Drittanbietern, die in der Entwicklung verwendet werden?

Wie Vincent De Baere angedeutet hat, besteht die beste Vorgehensweise darin, das System von einem Image wiederherzustellen. Natürlich muss die Umgebung danach wiederhergestellt werden, aber das sollte nicht das Problem der IT sein. Wenn es N-mal vorkommt, können Sie eine besagte Person auf eine Art "schwarze Liste" setzen und, ja, ihre Administratorrechte für eine Weile streichen.

In beiden Fällen sollte die Umgebung so eingerichtet werden, dass sichergestellt ist, dass ein infizierter (oder anderweitig fehlerhafter) Computer keine anderen Computer beeinträchtigt oder beispielsweise keinen Spam oder ähnliches sendet (in Ordnung, jetzt) Ich sage nur offensichtliche Dinge, sorry.

Nun, es kann teilweise davon abhängen, in welcher Umgebung Sie arbeiten (z. B. Linux oder Windows). Unter der Annahme einer Windows-Umgebung ist dies jedoch in der Regel schwieriger als sinnvoll, da für einige der dortigen Entwicklungssoftware erhöhte Berechtigungen für die Arbeit erforderlich sind. Es ist beispielsweise bekannt, dass Visual Studio Administratorrechte erfordert. Daher sehe ich keinen Vorteil darin, jemanden dazu zu bringen, für einen bestimmten Teil seines Auftrags durch die Rahmen zu springen.

Wenn das Unternehmen jedoch verlangt, dass die Dinge gesperrt werden, bietet Ihre beste Wahl wahrscheinlich allen Entwicklern virtuelle Maschinen auf ihren Systemen, in denen sie verrückt werden können. Einige mögen dies möglicherweise nicht so sehr, aber Sie erhalten wahrscheinlich das Beste von beiden Welten (zB restriktiver normaler Desktop und eine vollständig anpassbare Umgebung).

Update - Auf der Windows-Seite gibt es ein bisschen mehr zu erwähnen, anscheinend ist das Visual Studio, für das Administratorrechte erforderlich sind, etwas veraltet und es gibt jetzt explizite Möglichkeiten, die erforderlichen Berechtigungen festzulegen (PDF-Datei). Ich glaube jedoch nicht, dass dies meine Option insofern ändert, als die meisten mir bekannten Entwickler, auch ich, dazu neigen, zusätzliche Tools zu verwenden, die über Visual Studio hinausgehen, und zu wissen, was alle in Bezug auf Berechtigungen erforderlich sind, kann schwer vorherzusagen sein.

Ich stimme dem Gedanken zu, virtuelle Maschinen auf einem eingeschränkten Desktop zu verwenden.

Sofern nicht anders erforderlich, ist meines Erachtens das beste Setup ein eingeschränkter Linux-Desktop mit einem kostenlosen VM an der Spitze. Linux senkt den Overhead für mich. Ein VM kann nicht nur das zur Hölle gewollte Betriebssystem sein, sondern auch in Snapshots oder Backups wiederhergestellt werden. Im Allgemeinen sieht die Welt ein bisschen heller aus, wenn nicht so viele verschiedene Setups erforderlich sind Unterstützung.

Ich (als Entwickler selbst) bevorzuge es, die volle Kontrolle über meine Maschinerie zu haben. läuft als admin wenn nötig.

Sie können Entwicklern spezielle Schulungen anbieten, bevor ihnen der uneingeschränkte Zugriff auf ihre Computer gewährt wird. Legen Sie einige Regeln für sie fest, und möglicherweise können Sie gelegentlich eine Prüfung durchführen, um festzustellen, ob sie den Best Practices entsprechen.

In den meisten Fällen müssen sie mehr über die IT-Infrastruktur aus Sicht der IT-Administratoren / des IT-Supports, über sicherheitsrelevante Dinge und darüber wissen, warum sie nicht mit erhöhten Rechten entwickeln sollten. (und wie man sicher geht, dass man es nicht tut ...)

"Vertraue uns nicht blindlings, wenn wir dir sagen, dass wir alles wissen, was wir über Computer wissen müssen" ;-)

Sie müssen sie weiterhin mit Netzwerken, Domain- und Account-Inhalten, Softwareinstallationen von Nicht-Entwickler-Tools usw. unterstützen.

Meine Erfahrung ist mit einer Benutzerpopulation, die ungefähr gleichmäßig zwischen Leuten aufgeteilt war, die nur eine gesperrte Maschine benötigten, und anderen (Entwicklern, Wissenschaftlern), die Administratorzugriff benötigten. Die High-End-Leute verwendeten eine Menge unterschiedlicher Software, einige im eigenen Haus, andere nicht, aber viele benötigten Administratorrechte, und für ihre Arbeit mussten sie viele Pakete verwenden, so dass es am sinnvollsten war, dies den Leuten zu überlassen es selbst.

Wir endeten mit den folgenden Prozessen:

• Unser Standard-Image enthielt die grundlegenden Tools: Windows, Office, Anti-Virus, Acrobat und einige Dienstprogramme.
• Wir haben viel Netzwerkspeicher bereitgestellt: genug, damit alles im Netzwerk gespeichert werden kann. Die einzige Ausnahme waren in Bearbeitung befindliche Videodateien, die lokal bleiben mussten.
• Die Mitarbeiter (in Absprache mit ihren Vorgesetzten) hatten zwei Möglichkeiten: Entweder wartete die IT ihren PC, führte alle Installationen und Konfigurationen durch, oder sie konnten über Administratorrechte verfügen, um dies selbst zu tun. In beiden Fällen wurden alle Daten im Netzwerk gesichert.
• Wenn die IT das System gewartet hat und es abgestorben ist, haben wir es auf den aktuellen Stand zurückgesetzt, einschließlich der Hinzufügung zusätzlicher Software, die wir installiert hatten.
• Wenn sie über Administratorzugriff verfügten und das System nicht mehr funktionierte, würden wir es überprüfen und versuchen, es zu beheben. Wir wollten sie jedoch wieder auf das Standard-Image zurückführen, und sie müssten es von dort aus übernehmen. Wenn sie lokale Daten hätten, würden wir versuchen, diese zuerst zu entfernen, aber unser SLA bestand nur darin, ihnen so schnell wie möglich einen funktionierenden Standard-PC zu verschaffen.
• Jeder Benutzer mit Administratorzugriff musste wissen, wie sichergestellt werden kann, dass Windows-Updates funktionieren, damit Viren- und Malware-Schutz auf dem neuesten Stand sind.

Wir hätten gerne alle Leute mit Administratorzugriff auf ein "nicht vertrauenswürdiges" VLAN gesetzt, aber wir sind nie dazu gekommen.