Frage:
Verweigert den Zugriff, um Änderungen direkt an der Live-Site vorzunehmen
Arka Poddar
2016-11-20 20:50:01 UTC
view on stackexchange narkive permalink

Als Junior-Entwickler arbeite ich seit 4 Monaten an einem Projekt. Mein Projekt wurde über das Versionskontrollsystem TFS konfiguriert, während das Projekt meines Teamkollegen von SVN konfiguriert wird. Das Projekt wird gewartet, daher finden dort keine regelmäßigen Arbeiten statt. Wenn unser Client jedoch eine Änderungsanforderung sendet, ist es meistens meine Person, die die Änderung vornimmt, nachdem sie den Quellcode getestet und in TFS eingecheckt hat. Es liegt wieder in meiner Verantwortung, diese Änderungen an meinen Senior-Teamkollegen zu senden, der sie einer Peer-Review unterzieht und den Code für die Produktion bereitstellt.

Ich habe meinen Senior gebeten, den FTP-Zugriff für das zu übergeben Produktionsstandort für mich. Wenn also eine Änderung erforderlich ist, werde ich sie unter den folgenden Bedingungen an PROD weitergeben:

  1. Wenn er mit anderen Projekten beschäftigt ist
  2. Ist er es? nicht verfügbar (Busfaktor), bei dem ich eine Notfreigabe durchführen werde.
  3. ol>

    Er gibt mir nur ungern den FTP-Zugang. Einmal habe ich unseren Lead zu diesem Thema gefragt, aber unser Teamleiter hat auch geschwiegen.

    Meine Fragen:

    1. Was muss ich beachten? Bevor Sie den Zugriff auf die Produktseite anfordern?

    2. Wie kann ein Business Case erstellt werden, bei dem mir der Zugriff auf PROD als Backup gewährt wird, falls dies bei meinem Kollegen der Fall ist? plötzlich nicht mehr verfügbar im Interesse der Geschäftskontinuität?

    3. ol>
Ihrer Geschichte scheinen einige Details zu fehlen.Zum Beispiel sagten Sie, Sie hätten Ihren Lead um FTP-Zugang gebeten, aber "er hat geschwiegen".Was bedeutet das genau?Außerdem ist mir nicht klar, warum Sie einen FTP-Zugriff benötigen, wenn es in der Verantwortung Ihres Senioren liegt, die Änderung auf der Live-Site bereitzustellen.
Warum stimmen die Stimmen ab?Wenn Sie mit der Perspektive des OP nicht einverstanden sind, ist das eine Sache, aber es erfordert Mut, die Leute hier zu fragen!
Ich sehe die Argumentation hier nicht hinter den Abstimmungen.Die Frage hier scheint (zumindest für mich) ziemlich klar zu sein.
Fragen Sie Ihren Chef.Ihr Chef kann den "Senior" anweisen, den Zugang zu übergeben, wenn dies als wünschenswert erachtet wird.Ansonsten machen Sie einfach weiter, was Sie getan haben.
Fragen Sie "Was soll ich tun, wenn X nicht verfügbar ist, wenn Änderungen am Produktionsstandort vorgenommen werden müssen?".Gehen Sie nicht davon aus, dass die Antwort darin besteht, Ihnen direkten Zugriff zu gewähren.Es kann sein, dass sich eine ältere Person oder jemand in einer anderen Abteilung befindet oder dass sich die Passwortinformationen in einem Safe befinden ... bereit für diese Situation.
@Pete Ich war der erste enge Wähler, also lassen Sie mich erklären.Als ich abstimmte, war der Fragentitel "Ein Zustand der Verwirrung mit Zögern", der nicht mit der Beschreibung korrelierte, obwohl es sich wie ein großartiger Titel für ein Gedicht anhört.Außerdem: "Gibt es etwas, das ich nicht verstehen kann?"hat ein Fragezeichen, aber das macht es nicht zu einer klaren Frage.Es war nicht klar, was genau das OP brauchte, was übrigens in den Details des nahen Grundes erwähnt wird.
Es hört sich nicht so an, als ob Sie Zugriff benötigen.Du willst es einfach.
Gibt es eine Entwicklungsumgebung?Ein Ort, an dem Sie die Änderungen ablegen können, bevor Sie sie einer Live-Umgebung hinzufügen?
Lesen Sie diese Geschichte: http://thedailywtf.com/articles/the-helpful-manager darüber, was schief gehen kann, wenn Menschen Zugriff haben, den sie nicht benötigen.Ja, es ist extrem und endet damit, dass der Manager seinen Job verliert.
Ich möchte hinzufügen, dass der Zugriff auf ein kritisches System, das für Ihren Job nicht viral ist, eine große Verantwortung ist.Wenn auf dem FTP ein Fehler auftritt, stellen Sie sicher, dass Sie vor dem Senior misstrauisch sind.
Technisch gesehen sollte niemand physisch über diesen FTP-Zugang verfügen, außer über ein Bereitstellungssystem jeglicher Art.Dies würde nur wenigen Personen (die dieses System konfigurieren) diese Informationen zur Verfügung stellen, und die Bereitstellung wäre völlig transparent.Ich spreche nicht einmal über Lastausgleich ...
Acht antworten:
#1
+63
dfundako
2016-11-20 21:02:58 UTC
view on stackexchange narkive permalink

Nimm es nicht persönlich oder als Beleidigung. Es hat wahrscheinlich nichts mit Ihrer Kompetenz als Entwickler zu tun.

Es gibt bestimmte Verantwortlichkeiten, die Managern, Teamleitern und Senioren vorbehalten sind. Die Hauptverantwortung ist der Zugang zu Live- / Produktionssystemen. Einem Junior-Entwickler Zugang zu einem kritischen System zu gewähren, verstößt höchstwahrscheinlich gegen die Unternehmensrichtlinien und ist insgesamt keine gute Praxis. Es ist eine gute Idee, Ihren Code von einem älteren Entwickler durchlaufen zu lassen, um den Code zu überprüfen und sicherzustellen, dass nichts kaputt geht. Das Unternehmen verringert die Wahrscheinlichkeit, dass schlechter Code in die Produktion gelangt, indem es die Anzahl der Personen begrenzt, die ihn bereitstellen können.

Es ist nicht einmal eine Frage des Dienstalters.Es ist immer eine gute Idee, einen zweiten Blick auf Änderungen zu werfen, bevor diese in Produktion gehen, auch wenn der Rezensent wesentlich jünger ist als der ursprüngliche Autor.
Es ist auch erwähnenswert, dass es in Finanzunternehmen als kritisches operationelles Risiko angesehen wird, zu verwalten, dass jeder, der direkt weiß, wie die Ausgabe eines Finanz-IT-Systems zu manipulieren ist, unabhängig vom Dienstalter KEINEN Zugriff auf die Produktionsserver erhält.
@toadflakz: genau.Im Allgemeinen ist es Teil der Schwergewichtsprozesse, die in großen Läden leider unvermeidlich sind.Du magst es nicht?Arbeite für einen kleinen Laden.
Es hat nichts mit großen oder kleinen @gazz, zu tun, die reguliert oder nicht reguliert sind, ja.
Ich muss Folgendes sagen: Als "Lone Ranger" in meinem Unternehmen für die Entwicklung habe ich in Active Directory separate Identitäten für meine Rollen als Entwickler und als Release-Manager erstellt, um sicherzustellen, dass ich nicht versehentlich etwas tueohne es zweimal anzusehen.
#2
+19
PeteCon
2016-11-21 09:56:28 UTC
view on stackexchange narkive permalink

Sie gehen davon aus, dass der leitende Entwickler berechtigt ist, Ihnen Zugriff auf den Produktionsserver zu gewähren.

In vielen Entwicklungsumgebungen ist dies nicht der Fall. Ich arbeite mit Unternehmen zusammen, in denen keiner der Entwickler Zugriff auf das Back-End der Produktionsserver hat. Nur das Sicherheitsteam und das Systemadministrationsteam haben Zugriff auf die Server auf SSH-Ebene. Entwickler können ein automatisiertes Bereitstellungssystem verwenden, um Änderungen auf die Produktionsserver zu übertragen, jedoch erst, nachdem das Sicherheitsteam die vorgeschlagenen Codeänderungen überprüft und den entsprechenden Zweig mit dem Produktionszweig zusammengeführt hat.

Eine goldene Sicherheitsregel, Wie Peter sagt, kann man niemals beschuldigt werden, wenn man keinen Zugang hat.

Auch wenn Sie von einer älteren Person einer Peer-Review unterzogen werden und etwas schief geht.Es ist nicht deine Schuld allein.Die Person Peer-Reviewing ist gleichermaßen verantwortlich.
#3
+13
Xavier J
2016-11-23 21:47:21 UTC
view on stackexchange narkive permalink

Nur weil sie (praktisch) Ihnen diese Art von Zugriff ermöglichen können, heißt das nicht, dass sie sollten. Alle BS beiseite: Es gibt einen Grund, warum Unternehmen zwischen "Junior" und "Senior" unterscheiden. Als Junior-Entwickler wird von Ihnen erwartet, dass Sie viele Fehler und Versehen machen. Keine, von der älteren Person, die Sie beschreiben, Ihrem Lead und ihren Vorgesetzten sowie den Vorgesetzten ihrer Vorgesetzten wird das Risiko eingehen, ihre Hypotheken bezahlen zu können, wenn Sie sich in Ihrer Position dort sicherer fühlen.

Bei allem Respekt kann jeder Dummkopf mit FTP-Zugriff Dateien auf einem Server ablegen. Es braucht nicht einmal einen technischen Benutzer - nur jemanden mit einer Kopie von Filezilla, einem Hostnamen, einem Benutzernamen und einem Passwort. Viele Unternehmen haben Ausfälle erlebt, weil junge Entwickler sich unbedingt beweisen wollten. Sie geben Ihnen also Zugriff auf eine Bereitstellung "in Akten", aber was hindert Sie daran, Fehler in den Akten zu beheben - Dinge, die Sie möglicherweise nicht rückgängig machen können - und die Dinge immer schlimmer zu machen ? Warum sollten sie dir vertrauen? Es sind nur vier Monate vergangen, und es dauert viel länger, bis man den Arbeitsstil eines Mitarbeiters herausfindet. Niemand hat wirklich Zeit , Ihnen dies zu erklären, weshalb Sie keine Antwort erhalten haben.

Nehmen Sie zu diesem Zeitpunkt eine Pille. Geben Sie bei den Ihnen zugewiesenen Aufgaben das Beste, was Sie können. Leuchten Sie mit dem, was Sie bereits haben. In ungefähr einem Jahr werden weitere Nachwuchsentwickler hinter Ihnen durch die Tür kommen. und wenn Sie in den Fällen, in denen sh-- den Fan trifft und die Leute versuchen, negative Aufmerksamkeit von ihnen fernzuhalten, bei der Arbeit gut aufgepasst haben, werden Sie dieses Paradigma viel, viel besser verstehen.

#4
+7
Anthony
2016-11-24 07:00:56 UTC
view on stackexchange narkive permalink

Als jemand, der im IT-Sicherheitsberuf arbeitet, gibt es sehr gute Gründe, die das Verhalten Ihres Senioren erklären. Die 2 wichtigsten Konzepte sind

Aufgabentrennung

Das Prinzip von SOD besagt, dass inkompatible Pflichten von 2 oder mehr Personen ausgeführt werden sollten, um Absprachen zu minimieren und Sicherheitslücken. Codeentwicklung (was Sie derzeit tun) und Codefreigabe (was Sie tun möchten) sind in den meisten Fällen inkompatible Aufgaben. Ein Entwickler, der Zugriff auf die Produktion hatte, konnte Code entwickeln, schädlichen Code wie Hintertüren oder Logikbomben in legitimen Code einbetten und den Code dann für die Produktion freigeben, während er unentdeckt blieb. Solche Aktivitäten sind für das Unternehmen äußerst riskant, und der Verlust kritischer IT-Ressourcen kann von den meisten Unternehmen schlecht bezahlt werden. Wenn die Daten, an denen gearbeitet wird, äußerst sensibel sind, kann das Überleben des Unternehmens in Frage gestellt werden.

Mindestberechtigung

Das Prinzip der Mindestberechtigung besagt, dass ein Benutzer nur über die Mindestberechtigungen verfügen sollte, die zur Erfüllung seiner Aufgaben erforderlich sind, und nicht mehr . Dieses Konzept ist auch eng mit der CIA-Triade der Sicherheit verbunden. Das Befolgen dieser Vorgehensweise minimiert das Risiko, dass ein Benutzer IT-Ressourcen missbraucht oder nicht autorisierte Administrator- / Superuser-Befugnisse über ein System erlangt, in dem er im Grunde alles tun kann, was er oder sie möchte, z. B.:

  1. Daten zerstören - Verletzung der Integrität und potenzielle Verfügbarkeit

  2. Den Zugriff legitimer Benutzer verweigern - Verletzung der Verfügbarkeit

  3. Weitergabe von Daten an Unbefugte - Verletzung der Vertraulichkeit

  4. ol>

    Ihre Aufgabe als Junior-Entwickler ist es, Quellcode zu schreiben. Es scheint nicht, dass es die Freigabe für PROD beinhaltet. Daher befolgt Ihr Senior die bewährten Sicherheitsmethoden, indem er Ihnen den Zugriff verweigert.

    So erstellen Sie Business Case als Backup für Notfalländerungen an PROD

    Nach alledem sollte es eine Backup-Person geben, die Live-Releases durchführen kann, falls Ihr Senior nicht verfügbar ist. Die Geschäftskontinuität wird beeinträchtigt, wenn nur eine Person eine bestimmte Aufgabe ausführen kann, ein Risiko, das für ein vernünftiges Management wichtig ist. Bevor Sie jedoch Ihren Fall präsentieren, sollten Sie die Protokollierungssysteme überprüfen, die zum Überwachen von Änderungen an der Produktionsumgebung verwendet werden . Wenn Sie dies nicht haben oder wenn Sie dies tun, es aber nicht überwacht oder überwacht wird, aber ohne einen Vorfallreaktionsplan, um auf die Erkennung nicht autorisierter Änderungen in der Produktion zu reagieren, gibt es größere Probleme in Ihrem Unternehmen. Wenn Sie dem Management versichern können, dass von Entwicklern gestellte Notfalländerungsanforderungen sicher protokolliert werden, damit Änderungen überprüft und nicht autorisierte Änderungen auf die verantwortliche Person zurückgeführt werden können, steigt Ihr Fall, dass Ihnen Zugriff auf PROD gewährt wird, erheblich. Damit ein Überwachungsprotokoll als sicher definiert werden kann, müssen die folgenden Merkmale erfüllt sein:

    1. Der Zugriff auf das Protokoll wird auf die Mindestanzahl von Benutzern beschränkt, die dies wissen müssen seinen Inhalt. - Vertraulichkeit

    2. Protokolleinträge werden beim Festschreiben gesperrt, sodass nachfolgende Änderungen zuvor geschriebene Protokolleinträge nicht ändern können. - Integrität

    3. Jedem Benutzer, der eine Änderung vornimmt, wird eine eindeutige Benutzer-ID zugeordnet, die zusammen mit einem Zeitstempel angibt, wann die Änderung vorgenommen wurde. - Nonrepudiation

    4. ol>

      Um weitere Einblicke in das zu erhalten, was passieren kann, wenn Zugriffsrechte schlampig sind, werfen Sie einen Blick darauf, was mit dem OP in diesen beiden Fragen geschehen ist:

    5. Ich habe bei einem Live-Projekt bei der Arbeit einen möglichen Fehler gemacht. Wie gehe ich mit diesem Durcheinander um?

    6. Schriftliche Warnung des Arbeitgebers wegen Befolgung der Anweisungen des Managers, Bugfix direkt in der Produktion bereitzustellen

    7. ol>

      Da Sie noch ein Junior-Entwickler sind, Ihr Senior hatte möglicherweise nicht genug Vertrauen in Sie, da das Risiko von Fehlern in der Live-Produktionsumgebung besteht. Dies sollte nicht persönlich genommen werden, da Ihre Erfahrung mit der Zeit in Ihrem Unternehmen wächst. Es sollte für Sie auch etwas beruhigend sein zu wissen, dass Sie ohne Zugriff nicht verdächtig wären, wenn etwas schief gehen würde, da Sie niemals auf die Produktion hätten zugreifen können, selbst wenn Sie dies wollten.

#5
+4
Pieter B
2016-11-21 15:29:12 UTC
view on stackexchange narkive permalink

Möglicherweise handelt es sich um Vorschriften.

In meiner Arbeit als Entwickler ist es mir ausdrücklich untersagt, auf Produktionsumgebungen zuzugreifen. Dies ist eine Sicherheitsmaßnahme. Diejenigen, die die Software herstellen, sollten nicht die Leute sein, die sie in Produktion bringen, da dann die Möglichkeit eines Interessenkonflikts besteht.

#6
+3
Peter
2016-11-21 02:55:21 UTC
view on stackexchange narkive permalink

Normalerweise ist derjenige mit Zugriff verantwortlich, wenn etwas schief geht.

Da der Senior die Änderungen genehmigt und bereitstellt, wird er im Idealfall beschuldigt, wenn es Probleme gibt.

Jetzt kann er versuchen, Ihnen Zugriff zu gewähren, aber das würde sich nicht ändern die Schuld von ihm weg. Stattdessen würde er Ihnen erlauben, zu tun, was Sie wollen, und wenn Sie es vermasseln, ist es immer noch seine Schuld.

Das sollte erklären, warum er Ihnen keinen Zugang gewähren möchte.

#7
+2
Patricia Shanahan
2016-11-24 01:53:23 UTC
view on stackexchange narkive permalink

Was muss ich beachten, bevor ich den Zugriff auf die Produktseite anfordere?

Die Hauptsache, die Sie berücksichtigen müssen, ist das Risiko, dass je mehr Sie auf den Zugriff drängen, desto größer ist das Risiko Größer die Sorge, dass Sie zu scharf darauf sind, es zu bekommen und es auf irgendeine Weise überbeanspruchen oder missbrauchen würden. Könnte Ihnen wirklich vertraut werden, dass Sie den direkten Zugriff nur in Notfällen verwenden, oder könnten Sie anfangen, die normalen Überprüfungen unnötig zu umgehen?

Wie kann ein Business Case erstellt werden, bei dem mir der Zugriff auf PROD als Backup gewährt wird? Falls mein Kollege im Interesse der Geschäftskontinuität plötzlich nicht mehr verfügbar ist?

Sie müssen wissen, was zu tun ist, wenn Ihr Kollege plötzlich nicht mehr verfügbar ist und Änderungen am Server erforderlich sind. Wenn Sie es nicht wissen, sollten Sie jetzt danach fragen und nicht warten, bis die Situation eintritt.

Der direkte Zugriff ist nur eine der möglichen und keine besonders wahrscheinliche Antwort. Beispielsweise kann es eine oder mehrere Alternativen geben, die nicht am normalen Ablauf beteiligt sind, aber bei Bedarf ein Update durchführen können. Oder vielleicht können die Änderungen auf Ihren Kollegen oder einen Ersatz warten.

Wenn Sie versuchen, daraus einen Business Case für den direkten Zugriff zu machen, der die Lösung des eigentlichen Problems, nicht zu wissen, was zu tun ist, möglicherweise behindert in dieser Situation tun.

#8
-1
user8365
2016-11-23 22:28:55 UTC
view on stackexchange narkive permalink

Ich denke, Sie müssen tiefer in Ihre Überlegungen eintauchen und herausfinden, wie dies dem Kunden zugute kommt. Lassen Sie Ihren Chef klarstellen, dass es in Ordnung ist, die Anwendung von Updates zu verzögern. Vielleicht verstehen die Kunden dies oder die Art ihres Geschäfts ist nicht ganz so zeitkritisch. Stellen Sie sicher, dass Ihr Chef die Risiken versteht.

Im schlimmsten Fall erwartet der Kunde die Lösung / benötigt sie dringend. Wollen Sie ihnen sagen, dass es nicht passieren wird, weil Ihr Chef nicht verfügbar ist? Wenn nicht, welche Lüge schlägt er vor?

Jemand in der Firma sollte die Konsequenzen tragen, und ich denke nicht, dass Sie es sein sollten, aber Sie werden der Überbringer von schlechten Nachrichten sein.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...