Zugriff verweigert, um Änderungen direkt an der Live-Site vorzunehmen

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 liegt im Zugriff auf Live-/Produktionssysteme. 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 erfahreneren Entwickler durchlaufen zu lassen, um den Code noch einmal zu überprüfen und sicherzustellen, dass nichts kaputt geht. Das Unternehmen verringert die Wahrscheinlichkeit, dass fehlerhafter Code in die Produktion gelangt, indem es die Anzahl der Personen begrenzt, die ihn bereitstellen können.

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

In vielen Entwicklungsumgebungen stimmt das nicht. Ich arbeite mit Unternehmen zusammen, in denen keiner der Entwickler Zugriff auf das Backend 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, aber 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, lautet: Wenn Sie keinen Zugriff haben, können Sie niemals beschuldigt werden.

Nur weil sie Ihnen (in der Praxis) diese Art von Zugriff gewähren können , bedeutet das nicht, dass sie es tun sollten . Bei allem Blödsinn: Es gibt einen Grund, warum Unternehmen zwischen „Junior“ und „Senior“ unterscheiden. Als Junior-Entwickler wird von Ihnen erwartet, dass Sie viele Fehler machen und versäumen. Keiner, von der leitenden Person, die Sie beschreiben, Ihr Lead und ihre Chefs und die Chefs ihrer Chefs werden riskieren, ihre Hypotheken bezahlen zu können, wenn Sie sich in Ihrer Position dort sicherer fühlen.

Bei allem Respekt, jeder Dummkopf mit FTP-Zugang kann Dateien auf einem Server ablegen. Es braucht nicht einmal einen technischen Benutzer – nur jemanden mit einer Kopie von Filezilla, einem Hostnamen, Benutzernamen und Passwort. Viele Unternehmen haben Ausfälle erlebt, weil Nachwuchsentwickler sich beweisen wollten. Sie geben Ihnen also Zugriff, um eine Bereitstellung „on record“ durchzuführen, aber was hindert Sie daran, „inoffizielle“ Fehlerkorrekturen durchzuführen – Dinge, von denen Sie möglicherweise nicht wissen, wie Sie sie rückgängig machen können – und die Dinge immer schlimmer machen ? Warum sollten sie dir vertrauen? Es sind nur vier Monate vergangen, und es dauert viel länger, um die Arbeitsweise eines Mitarbeiters zu erspüren. Niemand hat wirklich Zeit , Ihnen das zu erklären, weshalb Sie keine Antwort erhalten haben.

Nehmen Sie zu diesem Zeitpunkt eine Chill-Pille ein. Erledigen Sie die Ihnen übertragenen Aufgaben so gut Sie können. Glänzen Sie mit dem, was Sie bereits haben. In etwa einem Jahr werden Sie mehr Nachwuchsentwickler hinter sich durch die Tür kommen sehen; und wenn Sie bei der Arbeit in den Fällen gut aufgepasst haben, in denen sh-- den Ventilator trifft und die Leute versuchen, negative Aufmerksamkeit von ihnen fernzuhalten, werden Sie dieses Paradigma viel, viel besser verstehen.

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

• Aufgabentrennung (SOD)
• Geringstes Privileg

Aufgabentrennung

Das Prinzip von SOD besagt, dass inkompatible Aufgaben von zwei oder mehr Personen ausgeführt werden sollten , um geheime Absprachen und Sicherheitslücken zu minimieren. Die Codeentwicklung (was Sie derzeit tun) und die Codefreigabe (was Sie tun möchten) sind in den meisten Fällen unvereinbare 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, ohne entdeckt zu werden. Solche Aktivitäten sind für das Unternehmen äußerst riskant, und der Verlust kritischer IT-Ressourcen kann sich die Mehrheit der Unternehmen kaum leisten. Wenn die Daten, an denen gearbeitet wird, äußerst sensibel sind, könnte das Überleben des Unternehmens in Frage gestellt werden.

Geringstes Privileg

Das Prinzip der geringsten Rechte besagt, dass ein Benutzer nur die minimalen Rechte haben sollte, die zur Erfüllung seiner Aufgaben erforderlich sind, und nicht mehr . Dieses Konzept ist auch eng mit der Sicherheitstriade der CIA verbunden . Die Befolgung einer solchen Praxis minimiert das Risiko, dass ein Benutzer IT-Ressourcen missbraucht oder unautorisierte Administrator-/Superuser-Befugnisse über ein System erlangt, in dem er oder sie im Grunde alles tun kann, was er oder sie will, wie z.

1. Daten vernichten - Verletzung der Integrität und potenziellen Verfügbarkeit

2. Verweigern Sie legitimen Benutzern den Zugriff – Verletzung der Verfügbarkeit

3. Daten an Unbefugte weitergeben - Verletzung der Vertraulichkeit

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

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

Abgesehen davon sollte es eine Ersatzperson geben, die Live-Veröffentlichungen durchführen kann, falls Ihr Vorgesetzter nicht verfügbar ist. Die Geschäftskontinuität wird beeinträchtigt, wenn nur eine Person eine bestimmte Aufgabe erledigen kann, ein Risiko, das für ein vernünftiges Management wichtig ist. Bevor Sie Ihren Fall darlegen, sollten Sie jedoch die Protokollierungssysteme überprüfen, die zum Überwachen von Änderungen an der Produktionsumgebung verwendet werden. Wenn Sie dies nicht haben oder wenn Sie dies tun, aber nicht überwacht werden, oder überwacht, aber ohne einen Plan zur Reaktion auf Vorfälle, um auf die Erkennung nicht autorisierter Änderungen an der Produktion zu reagieren, dann gibt es größere Probleme in Ihrem Unternehmen. Wenn Sie dem Management versichern können, dass von Entwicklern gestellte Notänderungsanforderungen sicher protokolliert werden, damit Änderungen überprüft und nicht autorisierte Änderungen auf die verantwortliche Person zurückgeführt werden können, dann erhöht sich Ihr Fall, dass Ihnen Zugriff auf PROD gewährt wird, noch viel mehr. Damit ein Audit-Log als sicher definiert werden kann, sollten folgende Merkmale erfüllt sein:

1. Der Zugriff auf das Protokoll wird auf die minimale Anzahl von Benutzern beschränkt, die dessen Inhalt kennen müssen. - Vertraulichkeit

2. Protokolleinträge werden nach dem Festschreiben gesperrt, sodass spätere Änderungen zuvor geschriebene Protokolleinträge nicht ändern können. - Integrität

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

Um einen weiteren Einblick in das zu bekommen, was passieren kann, wenn die Zugriffsrechte schlampig sind, werfen Sie einen Blick darauf, was mit dem OP in diesen beiden Fragen passiert ist:

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

2. Schriftliche Verwarnung des Arbeitgebers für die Befolgung der Anweisung des Managers, Bugfix direkt in der Produktion bereitzustellen

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

Das können Vorschriften sein.

In meiner Tätigkeit als Entwickler ist mir der Zugriff auf Produktionsumgebungen ausdrücklich untersagt. Dies ist eine Sicherheitsmaßnahme. Diejenigen, die die Software herstellen, sollten nicht die Personen sein, die sie produzieren, denn dann besteht die Möglichkeit eines Interessenkonflikts.

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

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

Jetzt kann er versuchen, Ihnen Zugang zu verschaffen, aber das würde die Schuld nicht von ihm abwenden. Stattdessen würde er dir erlauben, zu tun, was du willst, und wenn du es vermasselst, ist es immer noch seine Schuld.

Das sollte erklären, warum er dir keinen Zugang gewähren will.

Was muss ich beachten, bevor ich den Zugriff auf die Prod-Site beantrage?

Das Wichtigste, was Sie berücksichtigen müssen, ist das Risiko, dass je mehr Sie auf den Zugriff drängen, desto größer die Sorge ist, dass Sie zu sehr darauf aus sind, ihn zu bekommen, und ihn auf irgendeine Weise überbeanspruchen oder missbrauchen würden. Könnte man sich wirklich darauf verlassen, dass Sie den direkten Zugang nur in Notfällen nutzen, oder könnten Sie anfangen, die normalen Kontrollen unnötig zu umgehen?

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

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

Ihnen direkten Zugriff zu gewähren, ist nur eine der möglichen Antworten und keine besonders wahrscheinliche. Beispielsweise kann es einen oder mehrere Stellvertreter geben, die nicht am normalen Ablauf beteiligt sind, aber bei Bedarf eine Aktualisierung vornehmen könnten. 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, kann dies der Lösung des eigentlichen Problems im Wege stehen, nicht zu wissen, was in dieser Situation zu tun ist.

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

Worst-Case-Szenario, Client erwartet/braucht dringend die Lösung. Sollen 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 im Unternehmen sollte die Konsequenzen tragen, und ich denke nicht, dass Sie es sein sollten, aber Sie werden der Überbringer schlechter Nachrichten sein.