Frage Warum sollten Sie Entwickler nicht in die Nähe von Root-Passwörtern bringen? [Duplikat]


Diese Frage hat hier bereits eine Antwort:

Ich bin gerade hergekommen Im Serverraum brennt etwas; Wie kann ich schnell erkennen, was es ist?. In den Kommentaren fand ich folgendes Zitat:

you don't let a developer anywhere near your root passwords

Als Entwickler, aber auch jemand, der sich sehr für Sysadmin-Sachen interessiert, frage ich mich, ob es etwas mehr als nur den Standard für alle gibt - also keine Passwörter weitergeben? Der Kommentator erklärt dies so, als ob es in der Sysadmin-Community recht allgemein bekannt ist. Ist es?


24
2018-04-05 08:40


Ursprung


Ich denke, es ist eher eine Notwendigkeit, die Art der Sache zu wissen. Entwickler sind dafür bekannt, Systemänderungen vorzunehmen, um Dinge zum Laufen zu bringen, unabhängig davon, was ihre Aktionen sonst noch bewirken. Ich persönlich denke, es läuft auf individuelle Umstände hinaus. - David Houde
Hmm, das macht Sinn. Nicht eine vollständige Antwort, aber ich würde immer noch Ihren Kommentar auffrischen, wenn ich könnte (kein Vertreter oder Handy, nicht sicher welche). - strugee
zucken Wir lassen auch nicht zu, dass Systemadministratoren regelmäßig Root-Passwörter haben. Sie können erhalten Zugang, aber wenn sie es tun, wird es aufgezeichnet, und sie sollten das nicht regelmäßig tun müssen. - kojiro


Antworten:


Ich sage nicht, dass Systemadministratoren perfekt sind, aber es gibt eine große Anzahl von Beispiele für Entwickler das sollte nicht einmal Entwickler sein. Ganz zu schweigen davon, dass man Root-Zugriff auf Systeme mit unternehmenskritischen Daten haben darf.

Aber in jedem Fall geht es vor allem darum, Verantwortung für Veränderungen zu übernehmen. Für viele Systemadministratoren scheint es so zu sein, dass Entwickler Dinge auf Servern tun, und dann übernehmen sie keine Verantwortung für das, was sie getan haben. Entwickler konzentrieren sich oft nur auf das einzelne Programm / die Aufgabe, an dem sie arbeiten, und nehmen sich nicht die Zeit, um über das Gesamtbild oder den langfristigen Zustand des Systems nachzudenken, das sie berühren. Sie haben keine Gewohnheiten gelernt, wie man Veränderungen sicher macht.

Dies gilt nicht für alle Entwickler, es gibt sicherlich einige großartige Entwickler, die Systeme gut pflegen können. Es scheint oft so, als ob diese 95% der Zeit wahr sind.

Gewohnheiten wie:

  • Nehmen Sie keine Änderungen an einem System vor, ohne zuerst die Dev-Systeme zu testen
  • Mache keine Veränderungen, die du nicht verstehst (blind googeln und Dinge tun, die du nicht verstehst)
  • Nehmen Sie keine Änderungen vor, ohne sicherzustellen, dass Sie wissen, dass die Backup-Systeme funktionieren, und wie Sie alles zurücksetzen, was Sie tun.
  • Nehmen Sie keine Änderungen vor, die das System auf lange Sicht schwieriger warten lassen. (Fügen Sie keine technischen Schulden hinzu)
  • Beeinträchtigen Sie nicht die Sicherheit des Systems
  • Ändern Sie das System nicht so, dass das potenzielle regulatorische Risiko erhöht wird (siehe PCI-DSS, HIPPA, FERPA usw.).

16
2018-04-05 08:58



+1 für die nette Liste. - strugee


Da die Betriebsverantwortung eines Produktionssystems normalerweise für ein Sysadmin gilt, sollte nur ein Sysadmin vollen administrativen Zugriff auf das System haben - so einfach ist das.

Nun, könnten Sie sagen "Nun, manchmal machen wir Codeänderungen, die eine Neukonfiguration des Systems erfordern. Sollten wir nicht Zugang haben, die Systeme entsprechend neu zu konfigurieren?"

NEIN

Wenn Ihre Codeänderungen eine Neukonfiguration des Systems erfordern, sollten Sie in der Lage sein, einem Systemadministrator zu erklären, welche Anforderungen Sie haben. Auf diese Weise kann der Systemadministrator Ihre Änderungsanforderungen überprüfen und die Änderung stoppen, wenn dies betriebliche Auswirkungen hat, die Sie als Entwickler möglicherweise nicht voraussehen konnten.


Als Reaktion auf @NathanLong weiß ich, dass dies in kleineren Unternehmen manchmal der Fall ist. In diesen Situationen, in denen Administratoren und Entwickler die gleichen Benutzer sind, besteht eine Alternative darin, die Systemeigentümerschaft auf mehrere Personen zu verteilen und sicherzustellen, dass niemand - und ich meine NIEMALS - ihre eigenen Konfigurationsänderungen überträgt. Lassen Sie einen anderen Entwickler Ihre Änderungen überprüfen, lassen Sie einen Dritten die Neukonfiguration durchführen.

Wenn Zweifel auftreten, beginnen Sie mit der Änderungsplanung und -überprüfung - alles andere würde konstituieren schreckliches Change Management


29
2018-04-05 11:38



+1; Wir haben einen Kunden, der speziell darum gebeten hat, dass die Entwickler Administratorrechte auf dem Entwicklungssystem hatten, das ihre Git-Repositories hostet. Trotz Einwänden wollten sie immer noch, dass wir weitermachen. Während der Kunde uns bezahlt, um zu tun, was er verlangt, haben die Entwickler Admin-Rechte. Einige Zeit später (und zum Glück, bevor es zu spät war) bemerkten wir, dass die Entwickler einige Änderungen vorgenommen hatten, die den Backup-Prozess auf dem Server komplett unterbrachen. Das hätte leicht mehrere Entwicklungsjahre wert sein können, die verloren gegangen wären, wenn es länger unbemerkt geblieben wäre. - Bryan
Als Entwickler schätze ich die Zusammenarbeit, die Sie mit sich bringen. Leider sind der Entwickler und der Systemadministrator häufig die gleiche Person, so dass die Idee, "abgeschnitten" zu sein, einige Entwickler irritieren könnte. Ich würde sagen, wenn du dedizierte Systemadministratoren hast, ist es ein netter Deal, den root-Zugang aufzugeben, wenn du beide Dinge nicht tun musst. - Nathan Long


Ich werde versuchen, mit einer Metapher zu erklären (Ich bin ein Entwickler, gelegentlich Sysadmin Sachen tu tun.)

Maler und Innendekorateur

Nehmen wir an, der Entwickler ist Maler und schafft viele fantastische Gemälde. Ok, vielleicht sind sie nicht fantastisch, aber er hat gemacht, was sein Arbeitgeber von ihm verlangt hat. Er ist gut darin, so dass alle Bilder gut ausgehen.

Jetzt müssen die Bilder in den jeweiligen Gebäuden platziert werden. Der Maler weiß alles über Farbe, hat aber keine Ahnung, wie man etwas an einer Wand befestigen kann. Wenn der Maler sich entscheidet, es dennoch zu versuchen (weil er es kann), könnte der Innenarchitekt (Sysadmin) in ein paar Wochen später kommen und so antworten: "Was zum Teufel ist hier passiert?" "Alles ist schief, das .. das musste an die Decke gehen! Wie zum Teufel ist das mit dem wa verbunden ... IST DAS KLEBSTOFF !?"

Unnötig zu erwähnen, dass der Innenarchitekt eine bessere Arbeit geleistet hätte. Er wusste, wo er was hinstellen und wie er es montieren sollte. Er verwendete konsequent die gleichen Schrauben und gelegentliche Drähte. Er hatte es schon tausend Mal getan und konnte es mit geschlossenen Augen tun.

Um es kurz zu machen: Der Systemadministrator weiß, wie er mit seinem Rig besser umgeht als der Entwickler (zumindest sollte er es tun). Er wird sein System sauber und organisiert halten und wissen, wie das Ganze funktioniert. Außerdem sind viele Entwickler daran gewöhnt, Sysadmin-Sachen zu machen (zu Hause zum Beispiel), und Sie werden versuchen, es selbst zu tun, wenn sie können, weil es ihnen Zeit spart.

Natürlich gibt es Situationen, in denen eine Person beides tut, aber sie werden höchstwahrscheinlich in relativ einfachen Umgebungen oder an Orten sein, wo der Manager nicht gesehen hat, dass er tatsächlich zwei Leute braucht.


12
2018-04-05 12:37





Ich rate, es herumzudrehen und sich selbst in die Position als die andere Partei zu versetzen.

Also, in diesem Sinne:

Warum sollten Systemadministratoren nicht uneingeschränkt Zugriff auf den Quellcode haben?

Lang und knapp ist für mich, dass Entwickler keinen Root-Zugriff haben sollten, weil sie nicht unbedingt wissen, was sie tun, aus der Perspektive der Systemadministration und nicht (oder nicht) brauchen sollten Daher erhöht die Gewährung der Wurzel das Risiko, Probleme zu verursachen, ohne Nutzen. Die Verwaltung der Systeme ist die Aufgabe eines anderen.

Genauso wie Systemadministratoren aus denselben Gründen keine Codeänderungen vornehmen sollten.


8
2018-04-05 21:14





Dieser Rat fühlt sich etwas veraltet an; Es stammt aus einer Zeit, in der ungezogene Entwickler, die ein Root-Passwort hatten, in das Live-System einsteigen und Änderungen vornehmen würden.

Heutzutage Niemand sollte Änderungen an einem Live-System vornehmen, weder Entwickler noch Noch Systemadministrator Änderungen an einem Server vorzunehmen ist die Aufgabe eines Systems wie Chef oder Puppet. Unsere Industrie ist über das Konzept von. Hinausgegangen der singuläre Server das kann vor Jahren handkonfiguriert werden. Jetzt brauchen wir entweder die Fähigkeit zu haben viele identisch konfigurierte Server sofort bereitgestellt werden, oder zumindest die Fähigkeit, jeden einzelnen Server zu jedem Zeitpunkt zuverlässig wiederherzustellen. Dies schließt Änderungen aus, die von jemandem mit einem root-Passwort an einem Server vorgenommen werden, unabhängig davon, auf welchem ​​Server sie sich befinden.

Also zurück zur Frage: Sollten Entwickler das Root-Passwort haben? Ja! Sollten Systemadministratoren das Root-Passwort haben? Ja! Warum? weil Komplexe Systeme können ohne intelligente Generalisten, die sie von Grund auf verstehen, nicht effektiv diagnostiziert werden - oder zumindest ein Team aus Entwicklern und Systemadministratoren. Und ein Teil der Diagnose kann nicht durchgeführt werden, ohne sich beim Server anzumelden und die Rechte zu haben, zu prüfen, was passiert (zum Beispiel könnte ein Entwickler strace oder dtrace ausführen müssen, um zu verstehen, was der Webserver tatsächlich die ganze Zeit macht). Denk nur daran - schau, nicht anfassen!


4
2018-04-05 13:43





Ich habe mit einer großen Anzahl von Entwicklern zusammengearbeitet, die (zu Recht) kein Interesse daran haben, Systemadministratoren zu sein - sie wollen einfach ihre Software zum Laufen bringen. Sie werden den schnellsten Weg zu diesem Zweck nehmen, was oft z. Behebung von Zugriffsfehlern mit chmod 777 -R .

Dies ist natürlich eine schlechte Sache.


3
2018-04-05 09:09





Ich kann nicht für die Sysadmin-Gemeinschaft sprechen, aber ich kann aus Erfahrungen.

Während sie scheinen ihre Sachen zu wissen, scheinen sie nicht die Aufmerksamkeit auf Details benötigt und zufällige Dinge installiert / geändert haben, zum Beispiel den anderen Monat fand ich heraus, dass einer unserer Produktion Web-Server KVM / QEMU installiert hatte!
Die andere Sache, die mich nervt, ist, dass sie dazu neigen, Serverrollen zu mischen, so dass ein Hypervisor-Host plötzlich auch ein Überwachungsserver und ein Webserver werden würde. Es scheint auch einen Mangel an Konsistenz zu geben, zum Beispiel 3 Server, die die gleiche Rolle haben, die auf die gleiche Weise eingerichtet werden sollte, würde auf 3 völlig verschiedene Arten eingerichtet werden.

Natürlich hätte der Kommentator nur gemeint, dass sie SSH-Schlüssel anstelle von Passwörtern verwenden sollten :)


1
2018-04-05 09:07



Dies alles läuft im Wesentlichen auf die zwei getrennten Rollen von Dev und Ops hinaus. Hauptziel der Entwickler ist es, etwas zu schaffen, das funktioniert. Hauptziel des Betreibers ist es, die Dinge am Laufen zu halten. Manche Menschen schaffen es, diese auszugleichen, aber nicht die meisten. - Chris S