Was ist erforderlich, damit Entwickler ihren eigenen VM-Server in einer Unternehmensumgebung ausführen können? [Geschlossen]

Dieses Szenario wurde auch auf SO veröffentlicht , mit unterschiedlichen Fragen für unterschiedliche Zielgruppen - und ich bin sehr froh, dass ich dies getan habe, da ich einige sehr gute Antworten erhalten habe.

Wir versuchen, eine Entwicklungsumgebung mithilfe von Virtualisierung für ein kleines Team von 4 Entwicklern innerhalb einer Unternehmensorganisation zu implementieren. Dies würde es uns ermöglichen, separate Entwicklungs-, Test- und Staging-Umgebungen einzurichten und den Zugriff auf neue Betriebssysteme zu ermöglichen, die Anforderungen an Systeme oder Tools sind, die wir evaluieren.

Wir haben einen vorhandenen Computer der Workstation-Klasse neu konzipiert, 24 GB RAM und RAID-10 eingebaut und es ging uns gut, bis wir versuchten, den Computer zur Domäne hinzuzufügen.

Jetzt beginnen wir den Krieg, den alle Unternehmensentwickler seit jeher führen mussten - den Kampf um die lokale Kontrolle einer Entwicklungs- und Testumgebung. Die Netzwerk- und IT-Administratoren haben eine Reihe von Bedenken geäußert, die von "ESX Server ist der Unternehmensstandard" über "Server sind in Client-VLANs nicht zulässig" bis zu "[Fill-in-the-Blank] sind keine Fähigkeiten, die derzeit vorhanden sind die lokale oder Unternehmens-IT-Organisation ".

Wir könnten wahrscheinlich Hardware auf Produktionsebene und formellen IT-Support rechtfertigen (lesen Sie: Wir könnten die Notwendigkeit rechtfertigen, wenn wir müssten, aber es würde Zeit in Anspruch nehmen und eine Menge Kopfschmerzen verursachen) - aber es würde wahrscheinlich Monate dauern, um IT-Ressourcen formell zu erhalten zugewiesen, indem wir dies als Produktionssystem behandeln - und selbst wenn wir dies tun würden, würden wir wahrscheinlich die lokale Kontrolle verlieren, die wir wollen.

Ich stelle mir vor, dass viele von Ihnen ähnliche Probleme mit Entwicklern in Ihrem Unternehmen um die Entwicklersteuerung von Nicht-Produktionsumgebungen hatten. Meine Fragen lauten daher wie folgt:

1. Welche Argumente haben Ihre Entwickler vorgebracht, die Sie davon überzeugt haben, dass diese Arten von Silos in Unternehmen existieren können, in denen Standard-Netzwerk- und Sicherheitsrichtlinien vorhanden sind, die diese Art von nicht (zentral) verwalteter Infrastruktur im Allgemeinen (und verständlicherweise) ausschließen würden?
2. Geht es nur darum, dass die Entwickler eine technische oder geschäftliche Begründung abgeben und sicherstellen, dass Patch-Management und AV stattfinden - oder eher um einen politischen Kampf um Kontrolle und Eigenverantwortung?
3. Möchten Sie angesichts der Wahl lieber die Hardware / das Betriebssystem in Besitz nehmen und unterstützen, während Sie den Entwicklern lokale Administratorrechte gewähren, oder sie diese vollständig verwalten lassen, während Sie sicherstellen, dass sie Patch-Management / AV einrichten und sie mit Verantwortung beauftragen, falls sie Probleme verursachen?
4. Wenn Sie Entwickler erfolgreich daran gehindert haben, die lokale Kontrolle über "Rogue Server" in Ihrer Infrastruktur zu haben, haben die Entwickler dies dann nur fällig gemacht oder haben sie (oder Sie) die Entwicklungsumgebung in ein getrenntes VLAN / ein vollständig separates Netzwerk verschoben?

Einige Annahmen, um den Umfang dieser Frage einzuschränken:

1. Um es noch einmal zu wiederholen, ist dies für eine Entwicklungsumgebung vorgesehen - es sind keine Produktionslasten oder Unterstützbarkeit erforderlich. Nichts von außen zugänglich.
2. Dies ist kein heiliger Krieg zwischen Hyper-V und ESX (wir wären auch in Ordnung - aber Hyper-V wurde ausgewählt, da es mit MSDN für diese Zwecke "kostenlos" ist [ja, VMWare hat auch kostenlose Tools - aber das gute Management Tools sind im Allgemeinen nicht] und würden von den lokalen Entwicklern in einem "Microsoft Shop" einfacher zu verwalten sein. Argumente für oder gegen beide sind daher nicht Gegenstand dieser Frage.
3. Das Entwicklerteam hat bereits zugesichert, entweder Patch-Management und Antivirus zu verwalten oder in die vorhandenen Unternehmenssysteme zu integrieren, wenn die IT dies unterstützt - aber es liegt sicherlich im Rahmen, ob Sie bereit sind, dies zu akzeptieren oder nicht.

Zunächst sehe ich einige Gründe, warum Ihre Admins zu Recht zurückschieben:

• Die IT ist auch für die Berichterstattung über Patch-Management, Antivirensoftware, PCI-Konformität, jährliche (oder häufigere) Sicherheitsüberprüfungen usw. verantwortlich. Es geht nicht nur darum, dass Sie sich darum kümmern, sondern auch darum, dies zu tun Außenstehenden zu beweisen .

  Als Beispiel leite ich das Netzwerk an einem kleinen College, und wir haben ein Physiklabor mit einigen Datenerfassungsmaschinen für Schülerexperimente. Das einzige, was sie tun, ist, Daten von einem wissenschaftlichen Instrument zu sammeln und die Ergebnisse (auf einem direkt angeschlossenen Drucker) auszudrucken, damit der Schüler sie analysieren und dem Ausbilder übergeben kann. Sie sind nie im Internet - selbst AV- und Windows-Updates werden über das lokale Netzwerk angewendet. Der einzige Grund, warum sie mit dem Netzwerk verbunden sind und überhaupt AV-Software ausführen, ist der explizite Zweck, meiner Überwachungssoftware zu melden, dass sie noch vorhanden und aktuell sind. Es ist dumm, wie sie in Wirklichkeit wären mehr sicher die Netzwerkverbindung zu entfernen, aber sie wurden erst meine Berichtsanforderungen mit einer Ausbildungsbeihilfe und so die sind bezahlt.

• Ob es Ihnen gefällt oder nicht, Ihr Entwicklungsserver ist aus Sicht der Entwickler ein Produktionssystem. Nehmen Sie sich vielleicht einen Monat Zeit, und Entwickler werden Schwierigkeiten haben, ihre Arbeit zu erledigen, wenn sie aufgrund von Prozessen, die Sie einrichten und die davon ausgehen, dass der Server verfügbar ist, ausfällt. Das Vermeiden / Einschränken von Situationen, in denen Mitarbeiter aufgrund von Technologiefehlern untätig sind, ist ein wichtiger Grund, warum Unternehmen immer noch zentralisierte IT-Abteilungen verwenden.
• Wenn "ESX Server ist der Unternehmensstandard", müssen Sie dies befolgen. Derzeit gibt es erhebliche Unterschiede zwischen der Funktionsweise von Hyper-V, VMware, Xen und anderen, und es kann nicht einfach davon ausgegangen werden, dass eine für eine bestimmte Maschine auf der anderen Seite gut funktioniert. Wenn Sie dies tun möchten, muss die IT-Abteilung irgendwann bei der Verwaltung helfen, und sie möchte es nicht in VMware konvertieren müssen, nachdem sich auf dem Computer ein Haufen Cruft befindet, der möglicherweise ein Problem verursacht.
• Eines Tages wird diese Maschine alt und muss entweder regelmäßiger gewartet oder ein Standard-Austauschzyklus eingerichtet werden. Sogar neue Server haben manchmal Pennerteile. Diese Situation fast landet immer in Runde es ist nur nach etwas , das verhindert , dass Menschen aus ihrer Arbeit tun , gebrochen hat. Indem Sie frühzeitig die Verantwortung für den Server übernehmen, kann die IT viel besser arbeiten und sicherstellen, dass Sie ungeplante Ausfälle vermeiden.
• Dieser ist persönlich, aber ich kann Ihnen sagen , dass das sehr letzte , was ich um mein Netzwerk will , ist ein anderes Desktop - Masquerading als Server. Ich habe mich in den letzten paar Jahren mit genug davon befasst, um ein Leben lang zu leben.

Die IT muss diese Initiative jedoch unterstützen können. Es reicht ihnen nicht aus, nur "Nein" zu sagen. Fordern Sie sie auf, eine Alternative zu finden, die Ihren (sehr realen) Bedürfnissen entspricht. Die einzige politische Situation hier sollte sein, dass ihre Alternative wahrscheinlich einen höheren Aufkleberpreis hat (weil sie Kosten planen, die Sie noch nicht sehen können), und daher wird die Frage sein, wer dafür bezahlen muss. Die IT wird es nicht wollen, weil sie es nicht budgetiert haben, aber Sie werden zurückschrecken, weil es das Sechsfache dessen ist, was Sie für eine Lösung ausgegeben haben, mit der Sie (im Moment) zufrieden waren.

Es hört sich auch so an, als würden Sie versuchen zu rennen, bevor Sie laufen können. Sie möchten Ihren Entwicklungsprozess überarbeiten. Als ehemaliger Entwickler finde ich das großartig. Aber werfen Sie nicht einfach eine Reihe von VMs und "Umgebungen" weg (z. B. dev, stage, qa usw.). Planen Sie, wie die neuen Prozesse aussehen werden - wie Entwickler ihre Arbeit erledigen werden. Verwenden Sie eine kontinuierliche Integration? Automatisierte Builds? Mit welcher Software unterstützen sie? Dürfen Entwickler Code in die Produktion oder das Staging verschieben oder verfügt nur die Qualitätssicherung über diese Fähigkeit? Benötigen Sie eine separate Inszenierung? Was ist mit zwei Entwicklungszweigen (einer für vNext, einer für Fehler mit vCurrent)?

Möglicherweise benötigen Sie einen Server, damit der Entwicklungsleiter oder Manager das alles klären kann. Wenn dies jedoch der Fall ist, muss dies der erste Schritt sein, und die Einrichtung und das anfängliche Prozessdesign müssen durchgeführt werden, bevor die Entwickler ihn tatsächlich in die Hand bekommen verwenden.

1) Welche Argumente haben Ihre Entwickler vorgebracht, die Sie davon überzeugt haben, dass diese Arten von Silos in Unternehmen existieren, in denen Standard-Netzwerk- und Sicherheitsrichtlinien vorhanden sind, die diese Art von nicht (zentral) verwalteter Infrastruktur im Allgemeinen (und verständlicherweise) ausschließen würden ?

Keine - hauptsächlich, weil ich in meiner Organisation keine Führungsrolle spiele und mich diese "politischen Dinge" nicht wirklich einbeziehen. Das einzige Argument, das mich wirklich überzeugen würde, ist, etwas zuzulassen, das ausdrücklich gegen die Netzwerkrichtlinie verstößt und sowohl von der Kontrolle als auch von der Sichtbarkeit des Systembetriebsteams ausgenommen ist, ist ein Luftspalt und ein CYA-Brief des Chefs meines Chefs.

Es ist nicht so, dass ich wirklich "Nein" sagen möchte, es ist nur so, dass es aus Sicht des Operationsteams keinen guten Weg gibt, dies gut zu beenden.

1. Wir haben Server, die von Personen verwaltet werden, deren Hauptkompetenz nicht darin besteht, Server im Netzwerk zu verwalten, die nicht das gesamte Netzwerk und den damit verbundenen Problembereich sichtbar machen. Dies ist nicht nur ein politisches Anliegen des "Schutzes" von Rasen; Stellen Sie sich als einfaches Beispiel vor, was passiert, wenn ein Entwickler aus irgendeinem Grund DHCP aktiviert.
2. Am Ende verwalten wir die Server des Entwicklungsteams für sie. Dies ist aus dem entgegengesetzten Grund chaotisch. Die Entwickler sind ständig verärgert darüber, dass wir dies patchen (etwas brechen, von dem sie wissen, aber nicht) oder dass sie für uns kämpfen, um Funktionen zu aktivieren, die wir aus einer Vielzahl von guten Gründen nicht aktivieren möchten. Dies wird schnell zu einem Stillstand, in dem sich das Betriebsteam belastet und belästigt fühlt und das Entwicklungsteam sich frustriert und ignoriert fühlt.
3. Es gibt politische Konsequenzen - denn dann müssen Sie einer anderen Abteilung erklären, warum die Entwickler "besonders" sind und warum sie von der Netzwerkrichtlinie ausgenommen werden.

2) Geht es nur darum, dass die Entwickler eine technische oder geschäftliche Begründung abgeben und sicherstellen, dass Patch-Management und AV stattfinden - oder eher um einen politischen Kampf um Kontrolle und Eigenverantwortung?

Ich denke nicht, dass die Entwickler einen Business Case erstellen müssen - es ist ziemlich klar, dass Entwickler entwickeln müssen, und um dies zu tun, benötigen sie eine Art Entwicklungsumgebung. Patch-Management und AV - das ist die Aufgabe des Betriebsteams, und wir werden sicherstellen, dass dies erledigt wird. Wir glauben nicht, dass Entwickler das nicht können. Wir vertrauen nur nicht darauf, dass Sie es richtig machen - Systemadministratoren bleiben Systemadministratoren, weil sie nichts vertrauen, um etwas richtig zu machen, also ist es nichts Persönliches. Natürlich gibt es ein offensichtliches politisches Problem mit dem Gefühl, dass jemand anderes "Ihren Job macht", aber das ist kein wirklich technisches Problem und liegt daher außerhalb des Anwendungsbereichs von SF.

3) Wenn Sie die Wahl haben, würden Sie es vorziehen, die Hardware / das Betriebssystem zu übernehmen und zu unterstützen, während Sie den Entwicklern lokale Administratorrechte gewähren, oder sie diese vollständig verwalten zu lassen, während Sie sicherstellen, dass sie Patch-Management / AV einrichten und sie mit Verantwortung beauftragen, falls sie dies verursachen Probleme?

Weder aus den oben genannten Gründen.

4) Wenn Sie Entwickler erfolgreich daran gehindert haben, die lokale Kontrolle über "Rogue Server" in Ihrer Infrastruktur zu haben, haben die Entwickler dies dann nur fällig gemacht oder haben sie (oder Sie) die Entwicklungsumgebung in ein getrenntes VLAN / ein vollständig separates Netzwerk verschoben?

Luftspalt. Der beste Weg, um mit dieser Situation umzugehen, besteht darin, den Entwicklern ihre Umgebung (und Kontrolle darüber) und dann einen Luftspalt zu geben oder eine andere robuste Methode zu verwenden, um sie vom Netzwerk zu trennen. Dies ist im Wesentlichen, wie wir mit öffentlichem WLAN umgehen. Sie möchten WLAN-Dienste? Sicher. Sie bezahlen für die Netzwerkverbindung, wir verwalten die WAPs, aber sie werden unser Netzwerk niemals berühren. Es tut uns leid. Ihre Bedürfnisse sind nur eine von Hunderten. Es gibt andere Bedenken, die wir berücksichtigen müssen.

Sie möchten nicht nein sagen, weil Entwickler (die besonders technisch klug sind) Wege finden, um das zu bekommen, was sie wollen. Stellen Sie ihnen also eine Umgebung zur Verfügung, die ihren Anforderungen entspricht, machen Sie sie glücklich und finden Sie dann einen Weg, um zu verhindern, dass alles , was sie in der Entwicklungsumgebung tun, den Rest Ihres Unternehmensnetzwerks berührt.

TL; DR: Ich würde Ihnen einen Server mit jeder gewünschten Virtualisierungsplattform in einem separaten physischen Netzwerk oder VLAN geben. Der Zugriff auf Ihre Entwicklungsumgebung erfolgt über einen einzelnen Bastion-Host, den das Betriebsteam steuern und überwachen würde. Was Sie damit in Ihrem Unternehmen machen - Es wird nicht unterstützt, aber wir beraten und helfen, wenn es die Zeit für die Serveradministration zulässt.

Wenn Sie mit einem Computer der Workstation-Klasse zu mir kommen würden, der mit RAM für Endverbraucher, Festplatten für Endverbraucher, Netzteil für Endverbraucher und RAID für Endverbraucher ausgestattet ist, würde ich es ablehnen, ihn auch in das Servernetzwerk aufzunehmen.

Es gibt eine Menge zu verstehen, wenn Sie so etwas in das Server-VLAN einfügen.

1. Das Server-VLAN kann sehr gut eine DMZ sein. In eine DMZ legen Sie nichts ein , was nicht gehärtet und gesichert ist. Dies ist nur eine Maschine, die Sie ihnen gegeben haben. Sie haben keine Ahnung, was Sie damit gemacht haben. Dies bedeutet auch regelmäßige Patches und Updates, dh eine zentrale Verwaltung. Ich bin mir sicher, dass ich mich nicht bei jedem nicht verwalteten Server anmelden und Patches von Hand anwenden werde.

2. Die Komponenten in dieser Maschine werden ausfallen. Ich verspreche. Innerhalb von 6 oder 12, 24 Monaten wird es Bauch hoch gehen. Wo sind dann die Backups? Oh, du hast sie nicht eingerichtet? Aber ich dachte, es wäre ein Server? Oh, es ist ein Server, den jemand anderes bereitgestellt hat? ... und das Schuldspiel beginnt von vorne

3. Wer wird die Verantwortung übernehmen, wenn es abstürzt und Scheiße den Fan trifft? In den meisten Organisationen wird "Ich habe es den Entwicklern gegeben, um mich zu kümmern" nicht fliegen.

4. Wo werden sie es hinstellen? Heutzutage sind alle Server in einem Rack montiert, und das Aufstellen eines Turms in einem Rack verschwendet Platz, und ihre Racks sind möglicherweise nicht dafür ausgelegt.

Die IT-Abteilung ist daher zu Recht berechtigt, diesen zufälligen Computer nicht in ihr Servernetzwerk aufzunehmen.

Allerdings ist es die IT - Abteilungen Aufgabe, sicherzustellen , dass Sie richtig Ihre Aufgabe tun können. Sie müssen sicherstellen, dass Sie das haben, was Sie brauchen, wenn Sie es brauchen. Wenn Sie ein Stück Software haben , dass die Geschäftsbedürfnisse Laufen zu halten, sie haben eine Plattform für sie auf laufen. Das ist ihre Stellenbeschreibung. Sie müssen jedoch sicherstellen, dass sie über die Informationen verfügen, die sie für ihre Arbeit benötigen.

Wenn Sie in meiner Organisation zu mir gekommen wären und mir gesagt hätten, dass Sie ein neues Projekt starten, hätte ich Ihnen drei VMs gegeben: Dev, Live und Staging. Sie hätten die vollen Administratorrechte für Dev und wir würden besprechen, was Sie für Ihre Arbeit für die beiden anderen benötigen. Wenn Sie vollständige Administratorrechte für diese benötigen und diese rechtfertigen könnten, würden Sie sie erhalten. Wir haben unsere VM-Bereitstellung heruntergefahren. VMWare macht dies unglaublich einfach - es dauert nur etwa 5 Minuten pro VM, um es bereitzustellen.

Es hört sich so an, als ob Ihre IT-Abteilung unter dem leidet, woran so ziemlich jede IT-Abteilung in einem großen Unternehmen leidet. Baue kleine Burgen und verteidige sie mit deinem Leben, lasse andere nicht herein, sei herrisch usw. Als jemand, der jeden Tag mit den IT-Abteilungen anderer Leute zu tun hat, sehe ich das die ganze Zeit. Und es ist frustrierend.

Die grundlegende Tatsache ist jedoch, dass die Änderung innerhalb der IT-Abteilung erfolgen muss und von oben initiiert werden muss. Und wenn Sie der IT klar machen können, dass sie keine Kraft für sich selbst sind (da die meisten von ihnen kein Einkommen für ihr Unternehmen erwirtschaften, kann dies ein ziemlicher Schlag ins Gesicht sein) und dass sie da sind, um die vorhandenen Mitarbeiter zu unterstützen und das Geschäft verbessern , dann werden Sie feststellen, dass Ihre Fragen irrelevant werden, weil jeder glückliche Familien spielen wird.

Warum soll es der Domain hinzugefügt werden? Anders ausgedrückt, was die Frage besser beantwortet: Sie können ein Labor einrichten, in dem Sie alles tun können, was Sie wollen, solange es nicht mit dem Unternehmens-LAN verbunden ist. (Wenn Sie einen Internetzugang benötigen, können Sie möglicherweise ein DMZ-ed-VLAN erwerben. Dies sollte kein Problem sein, insbesondere wenn Sie es nur zum Ausgehen verwenden , z. B. zum Herunterladen.)

Das ist eine von vielen, vielen, unterschiedlichen Antworten auf die Frage.

Sie werden hier eine Menge Antworten erhalten, für und gegen Entwickler, die Administratorzugriff auf einen beliebigen Teil der Umgebung haben (wahrscheinlich meistens dagegen), aber hier ist das Fazit:

Die Sysadmin-Gruppe hat die Aufgabe, Produktionssysteme am Laufen zu halten, stabil und sicher zu halten, und ist dafür verantwortlich, dass diese Systeme die Dienste bereitstellen, für die das Unternehmen bezahlt (weil sie dafür bezahlen), und zwar auf dem von ihnen erwarteten Niveau.

Ebenso wurde das Entwicklerteam beauftragt, Dienstleistungen für das Unternehmen (Web, Apps usw.) bereitzustellen, wenn auch in einem anderen Bereich. Der Kampf um die Kontrolle über die Entwicklungsumgebung ist kontraproduktiv und hat für beide Seiten keinen nützlichen Zweck.

Ich arbeite bei einem kleinen ISV / ASP. Wir haben einen Entwickler und einen Systemadministrator (mich). Wir haben eine Beziehung, die auf gegenseitigem Respekt und Vertrauen beruht. Wir müssen als Team arbeiten, um die übergeordneten Ziele des Unternehmens zu erreichen. Ich gebe dem Entwickler vollständigen, uneingeschränkten Zugriff auf seine Entwicklungsumgebung, die Workstations und Server enthält. Ich verwalte die Entwicklungssysteme für Sicherheit, Updates, AV und Hardware und der Entwickler erledigt den Rest. Wenn sein Code für die Produktion bereit ist, gibt er ihn mir, unterstützt mich bei der erforderlichen Konfiguration und tritt zurück. Wir unterstützen uns gegenseitig.

Entwickler sollten die Meister der Entwicklungsumgebung sein, und Sysadmins sollten die Meister der Produktionsumgebung sein, innerhalb angemessener Grenzen und mit angemessenen Kontrollen, Abwägungen und Kontrollen. Wenn eine Seite "überqueren" muss, sollte dies in Zusammenarbeit und Abstimmung mit der "regierenden" Partei unter ihrer Kontrolle und Anleitung erfolgen.

Zunächst einmal bin ich ausschließlich in einer kleineren Organisation tätig, aber dieses Problem tritt bei Unternehmen jeder Größe auf, also ...

1.  What arguments have your developers made that won you over to
allow these types of silos to exist within enterprises which have
standard network and security policies in

Aus meiner Sicht ist das einzige Argument, das die Entwickler vorbringen müssen, "wir brauchen das". Wenn sie zuerst zu mir kämen, würde ich versuchen, ihre Bedürfnisse zu verstehen und zu sehen, was wir herausfinden könnten. Aber wenn sie letztendlich sagen "wir brauchen das", würde ich ihnen den Vorteil des Zweifels geben und darauf vertrauen, dass sie wissen, was sie tun.

Aber das ist erst der Anfang - das ist die "Pro" -Seite der Gleichung. Die "Con" ist, wo wir in die Auseinandersetzung geraten ...

2. Is this just a matter of the developers making a technical or
business justification

Abgesehen davon, dass "nur" eine unglaubliche Untertreibung ist, ja, wenn die Entwickler eine technische und geschäftliche Begründung abgeben können, gibt es kein Problem. Andere hier und auf Programmierern. SE (wo Ihre SO-Frage migriert wurde) haben auf eine Menge Fallstricke bei Ihrem Setup hingewiesen, daher werde ich sie nicht wiederholen. Wenn Sie einen Plan entwickeln, um all diese und alle anderen Probleme, an die Ihre IT-Abteilung denkt, zu lösen und ALLE Kosten zu rechtfertigen , ist es sinnvoll, fortzufahren.

3.  Given the choice, would you prefer to take ownership and support
of the hardware/OS while giving devs local admin rights,

Dies ist ein Nichtstarter. Sie können nicht zwei Gruppen mit unterschiedlichen Zielen und Verantwortlichkeiten haben, die versuchen, dieselben Systeme zu verwalten. Es wird nicht nur schlecht enden, es wird schlecht beginnen und in Blutvergießen enden.

(more of 3.) ... or let them manage it entirely, while ensuring that
they institute patch management/AV and charging them with
responsibility should they cause problems?

Ich denke, dies wird durch meine Antwort auf 2 abgedeckt: Dies sind technische Details, für die sie Lösungen finden müssten.

4.  If you successfully blocked developers from having local control
of "rogue servers" on your infrastructure, did the developers just
make due or did they (or you) move the development environment to a
disconnected VLAN/entirely separate network?

Ich stimme kce zu: "Luftspalt"

Wenn sie den zusätzlichen Aufwand rechtfertigen können, den sie auf sich nehmen (indem sie Administratoren ihrer Umgebung werden), können Entwickler ein eigenes Mini-Netzwerk haben, in dem sie freie Hand haben, ABER es ist vollständig unter Quarantäne gestellt: Nichts berührt den Rest des Netzwerks. Sie müssen sich also mehr technische und geschäftliche Begründungen einfallen lassen, z. B. für "Wie werden wir kritische Daten sichern?"

Auch hier muss ich kce zustimmen: "Systemadministratoren bleiben Systemadministratoren, weil sie nichts vertrauen, um etwas richtig zu machen." Es ist unsere Aufgabe, aus unzuverlässigen Komponenten die zuverlässigsten Systeme zu erstellen, die wir können Dutzend Dinge, von denen ein erfahrener Systemadministrator weiß, dass sie unglaublich schuppig sind, werden eine starke negative Reaktion hervorrufen.

Aus den Antworten und Kommentaren hier und auf programmers.se geht hervor, dass es Aspekte gibt, die Sie nicht berücksichtigt haben. Obwohl es länger dauern wird, denke ich, dass Sie wirklich mit Ihren IT-Mitarbeitern sprechen und die Dinge anders präsentieren müssen: "Hier ist, was wir tun müssen, gibt es eine Möglichkeit, dies in die vorhandene Infrastruktur und den Betrieb zu integrieren?"

Das allgemeine Problem in Ihren und Millionen ähnlicher Fälle ist:

1) Fuzzy-Verantwortung - Es gibt keinen direkten Zusammenhang zwischen den Handlungen eines Unternehmensarbeiters und seinen Gewinnen. Er wird monatlich bezahlt und nicht nach Effekten, die umso schwieriger zu messen sind, je größer die Organisation ist. Dies gilt für Sicherheit, Manager usw. Wenn sie Ihre Arbeit lähmen, ist ihnen das egal.

2) Politik und Sicherheit haben normalerweise wenig oder gar keine Programmierkenntnisse. Sie konnten nicht verstehen, dass sie Ihre Arbeit lähmen, selbst wenn sie sich darum kümmern würden (was normalerweise nicht zutrifft).

3) Bevorzugtes psychologisches Profil für die Arbeit in der Sicherheit ist paranoide Persönlichkeit oder Zwangsstörung. Diese Leute sehen die Verschwörung überall. Wenn Entwickler etwas möchten, beispielsweise einen neuen Server, möchten sie es sicherlich verwenden, um Unternehmensdaten zu stehlen und in WikiLeaks zu veröffentlichen oder an Nordkorea zu verkaufen.