Frage Wie kann ich verhindern, dass versehentlich eine Produktionsdatenbank aufgebockt wird?


Erst kürzlich hatte ich einen Entwickler versehentlich versuchen, eine Datenbank in Produktion wiederherzustellen, wenn er in eine Staging-Kopie hätte wiederherstellen sollen. Es ist einfach zu tun, da die Datenbanknamen ähnlich sind, d. H. CustomerName_Staging versus CustomerName_Production.

Idealerweise würde ich diese auf völlig separaten Boxen haben, aber das ist zu teuer, und streng genommen verhindert es nicht das Gleiche, wenn der Benutzer sich an die falsche Box anmeldet.

Dies ist an sich kein Sicherheitsproblem - es war der richtige Benutzer, der mit der Staging-Datenbank arbeitete, und wenn in der Produktionsdatenbank noch etwas zu tun ist, wäre es auch er. Ich hätte gerne einen Einsatzoffizier, um diese Bedenken zu trennen, aber das Team ist nicht groß genug dafür.

Ich würde gerne etwas Rat in Bezug auf Übung, Konfiguration und Kontrolle darüber hören, wie dies verhindert werden kann.


30
2018-01-07 20:43


Ursprung


Entwickler sollten keinen Schreibzugriff auf die Produktionsdatenbanken haben oder irgendein Zugriff. - Michael Hampton♦
@MichaelHampton - Ich und er. Ich bin auch ein Entwickler. Was schlagen Sie vor? - Chris B. Behrens
Trennen Sie Benutzerkonten für jede Rolle (dev vs ops / DBA). Und eine Menge Vorsicht. - Michael Hampton♦
Ich würde dringend empfehlen, dass Sie Ihre Produktionsumgebung auf einer separaten Box haben. Andernfalls müssen sich Staging und Produktion Ressourcen teilen - Festplatte, CPU usw. - und wenn die Bereitstellung eine Ressource monopolisiert, kann Ihre Produktionsumgebung darunter leiden. - Thorbjørn Ravn Andersen
Sie müssen nur separate Benutzer / Passwörter zu diesen Datenbanken haben. - neutrinus


Antworten:


Wenn Sie das häufig tun, automatisieren Sie es. Und da Sie beide Entwickler sind, sollte das Schreiben von Code in Ihrem Steuerhaus sein. :) Aber ernsthaft ... durch Automatisierung können Sie Dinge tun wie:

  • Stellen Sie sicher, dass Sie auf dem richtigen Server wiederherstellen (d. H. No dev -> prod wiederherstellt)
  • Stellen Sie sicher, dass es der richtige "Typ" der Datenbank ist (in Ihrem Fall "Staging" und "Produktion")
  • Finden Sie heraus, welche Backups automatisch wiederhergestellt werden, indem Sie sich die Backup-Tabellen in msdb anschauen

Und so weiter. Sie sind nur durch Ihre Vorstellungskraft begrenzt.


32
2018-01-07 22:27



Das ist eine interessante Idee ... wir haben bereits einen Code, der db-Wiederherstellungen verwaltet (für automatisiertes Testen). Wir könnten eine Abstraktionsschicht dazwischen legen, die nur auf die Inszenierung ausgerichtet war, so dass die Wiederherstellung der Produktion ein ganz anderer Prozess war ... - Chris B. Behrens
Jetzt denkst du mit Portalen. :) - Ben Thul
Bei automatisierten Jobs, die sich auf die Produktion auswirken, füge ich gerne einen manuellen Schritt hinzu, bei dem der Benutzer das Wort "Produktion" eingibt, um die Wahrscheinlichkeit zu reduzieren, dass er denkt, dass er z. das Staging-Äquivalent. - Joe Lee-Moyet
Ich habe abgelehnt, da niemand standardmäßig auf die Produktion zugreifen darf. Sie müssen einen speziellen Prozess haben, um ein Passwort abzurufen. Es ist unbequem, aber wirklich das Minimum. - OliverS
@BenThul Das Hinzufügen eines anderen Kontos für den Zugriff auf den Zugriff und das Unmögliche machen ist immer noch die richtige Lösung für mich. Der Geschäftsbedarf besteht nicht darin, das DEV 2 Minuten speichern zu lassen, sondern die Datenbank wiederherzustellen, die perfekt auf ein Produktkonto verschoben werden kann. - OliverS


Ich stimme der Annahme in der Frage nicht zu ist Sicherheit - aber ich stimme auch nicht zu, dass Automatisierung den Tag selbst retten wird. Ich fange mit dem Problem an:

Du solltest es nicht können versehentlich tun Alles zur Produktion!

Dazu gehört, dass man versehentlich automatisierte Dinge tut.

Sie verwechseln die Systemsicherheit mit Konzepten wie "wer darf was machen". Ihre Entwicklungskonten sollten nur in der Lage sein, auf ihre Kopien, den Versionskontrollserver und die Entwicklungsdatenbank zu schreiben. Wenn sie die Produktion lesen / schreiben können, können sie gehackt und ausgenutzt werden, um Kundendaten zu stehlen, oder (wie Sie gezeigt haben) können sie dazu verleitet werden, Kundendaten zu verlieren.

Sie müssen zunächst Ihren Arbeitsablauf sortieren.

  • Ihre Entwicklerkonten sollten in der Lage sein, in ihre eigenen Kopien, Versionskontrolle zu schreiben und vielleicht von der Versionskontrolle in eine Testumgebung zu gelangen.

  • Backup-Benutzer sollten nur in der Lage sein, aus der Produktion zu lesen und in Ihren Backup-Speicher zu schreiben (der angemessen geschützt sein sollte).

  • Alle anderen Lese- / Schreibvorgänge in der Produktion erfordern spezielle und ungünstig Authentifizierung. Sie sollten nicht in der Lage sein, hinein zu rutschen oder zu vergessen, dass Sie eingeloggt sind. Eine physische Zugangskontrolle ist hier nützlich. Smart-Cards, Flip-Switches, um den Account zu "bewaffnen", simultaner Dual-Key-Zugriff.

    Der Zugriff auf die Produktion sollte nicht alltäglich sein. Der Großteil der Arbeit sollte auf Ihrer Testplattform und außerhalb der Geschäftszeiten nach sorgfältiger Prüfung in der Produktion erfolgen. Eine kleine Unannehmlichkeit bringt dich nicht um.

Automatisierung ist Teil der Lösung.

Ich bin nicht blind gegenüber der Tatsache, dass der vollständige Turnaround (Hochladen auf VCS, Überprüfen der Abdeckung, Ziehen zum Testserver, Ausführen von automatisierten Tests, erneute Authentifizierung, Erstellen einer Sicherung, Ziehen von VCS) ein langer Prozess ist.

Das ist wo Automatisierung helfen kann, nach Bens Antwort. Es gibt viele verschiedene Skriptsprachen, die das Ausführen bestimmter Aufgaben sehr viel einfacher machen. Achte nur darauf, dass du es nicht zu leicht machst, dumme Sachen zu machen. Ihre Reauthentifizierungsschritte sollten immer noch ausgesprochen werden (und falls gefährlich) sollte unbequem und schwer zu tun sein, ohne nachzudenken.

Aber alleinAutomatisierung ist schlimmer als nutzlos. Es hilft dir einfach größere Fehler mit weniger Gedanken zu machen.

Geeignet für Teams aller Größen.

Ich habe bemerkt, dass Sie auf die Größe Ihres Teams hingewiesen haben. Ich bin ein Typ und ich stelle mich selbst durch, weil nur eine Person einen Unfall hat. Es gibt einen Overhead, aber es ist es wert. Sie erhalten eine viel sicherere und viel sicherere Entwicklungs- und Produktionsumgebung.


32
2018-01-08 09:32



Außerdem möchte ich zwei benannte Konten pro Benutzer verwenden. Eines ist für die normale Benutzeranmeldung, den Betrieb, die tägliche Arbeit usw., während das zweite Konto (normalerweise mit einer Art Suffix wie einem + oder einem Unterstrich) volle Rechte für prod und dev hat, die der Benutzer benötigt. Auf diese Weise muss der Benutzer eine aktive Entscheidung treffen, um zu Prod statt Dev zu pushen. Dies entspricht der oben beschriebenen Aufzählung 3, erfordert jedoch keine signifikante zusätzliche Infrastruktur oder zusätzliche Kosten, um den Wert nachzuweisen. - user24313
Es ist auch wichtig zu vermeiden, dass Sie sich die Angewohnheit machen, etwas anderes zu tun, als die Wartung in Ihrem Produkt-Account zu betreiben. Stellen Sie zu diesem Zweck sicher, dass prod den Quellcode nicht sehen kann, eine IDE nicht starten kann usw. - Eric Lloyd
Wo bekomme ich eine dieser Dual-Key-Simultan-Turn-Geräte und kommt es mit USB? - Lilienthal
Etwas anderes, das helfen könnte, ist die vollständige Automatisierung (ein oder zwei Klicks) in staging und dev, aber nicht Automatisierung von Produktionsbereitstellungen Wenn Sie manuell in die Box schalten, um etwas für die Produktion zu tun, aber nicht für andere Umgebungen, ist dies ein erheblicher Komfortunterschied, wie Sie vorschlagen. (Sie können immer noch alle erforderlichen Schritte ausführen und dieses Skript in allen Umgebungen verwenden. Ich meine, dass Sie die Ausführung der Skripts für die Produktion manuell auslösen müssen.) Dies kann natürlich zusätzlich zum Typ der Authentifizierung erfolgen Verfahren, die Sie empfehlen. - jpmc26
@Lilienthal Es war eine Metapher für Hochsicherheitstheater, aber du könntest dem billigen Angreifen von USB-Sticks an jeden Entwickler nacheifern und dann deine Automation bei der Ausführung von gefährlichen Dingen auf mindestens zwei ihrer Seriennummern prüfen lassen. In größeren Teams könnten Sie dann loggen, um zu sehen, wer die Produktion stört und die richtigen Leute für den Fall verantwortlich machen, dass alles schief geht. - Oli


Einer meiner Kollegen hat eine interessante Herangehensweise. Sein Terminal Farbschema für die Produktion ist fugig. Grau und pink und schwer zu lesen, was theoretisch dafür sorgen soll, dass, was auch immer er schreibt, er eigentlich schreiben wollte.

Ihre Laufleistung kann variieren ... und ich muss wahrscheinlich nicht sagen, dass sie selbst kaum kugelsicher ist. :)


12
2018-01-08 09:02



Ich verwende auch eine große rote Hintergrundfarbe auf Terminals / db-Verbindungen zu Produktionsservern, sowie knallrote Hintergrundbilder für Admin-Accounts auf PCs ... - Falco
Ja, ich habe das gedacht. Machen Sie die Produktion Feuerwehr rot ... - Chris B. Behrens
Farbcodierung hilft. Genau wie in einer IDE. - Thorbjørn Ravn Andersen


Entwickler sollten das Kennwort für die Produktionsdatenbank nicht kennen. Das Prod-Passwort sollte zufällig und nicht einprägsam sein - etwas wie das Ergebnis des Keyboard-Mashing (Z^kC83N*(#$Hx). Dein Entwickler-Passwort kann sein $YourDog'sName oder correct horse battery staple oder Wasauchimmer.

Sicher, Sie könnten herausfinden, was das Passwort ist, besonders wenn Sie ein kleines Team sind, indem Sie sich die Konfigurationsdatei der Client-Anwendung anschauen. Das ist der einzige Ort, an dem das Passwort für die Übertragung vorhanden sein sollte. Dies stellt sicher, dass Sie sich bewusst bemühen müssen, das Passwort zu erhalten.

(Wie immer sollten Sie zeitpunktgenaue Backups für Ihre Produktionsdatenbank erstellen. Archivieren Sie die Binärprotokolle beispielsweise mit MySQL als inkrementelle Backups. Archivieren Sie für PostgreSQL die Write-Ahead-Protokolle. Dies ist Ihr Schutz als letzter Ausweg für jede Art von Katastrophe, selbstverschuldet oder anderweitig.)


1
2018-01-08 09:52



Ich kann dem nicht völlig zustimmen, denn in jedem realistischen großen Umfeld gibt es ziemlich regelmäßig Fälle, in denen Entwickler / Admins auf die Produktionsdatenbank zugreifen müssen. Sicher in einer perfekten Welt mit einem fehlerfreien System sollte dies nie passieren, aber in den meisten Systemen weiß ich, dass Sie einige produktionskritische Daten per Hand reparieren müssen ... Also ich bin mit Oli, Produktions-Login sollte unbequem, aber machbar sein - Falco
@Falco Das ist genau das, was ich vorschlage. Unbequem, aber machbar. - 200_success
Das Problem mit Ihrem Ansatz ist nur, wenn es einen Notfall gibt und die Produktion ausfällt, zählt die Zeit. Ihre Entwickler sollten also wissen, wo sie das Passwort finden und es schnell bekommen können. Wenn sie herumfragen müssen, die Repository- und Konfigurationsdateien durchsuchen und herumprobieren, verlieren Sie wertvolle Zeit = Geld. Also würde ich das Passwort lieber an einem Ort haben, an dem jeder weiß, wo er suchen soll, aber es ist immer noch unbequem, aber schnell, wenn es sein muss - Falco
@Falco Da Produkt-Umgebungen eng mit Entwicklungsumgebungen übereinstimmen sollten, würde sich die Konfigurationsdatei an der entsprechenden Stelle auf dem Produkt-Server befinden wie auf den Entwicklungsmaschinen. Jeder kompetente Entwickler sollte wissen, wo er suchen soll, und wenn er nicht weiß, wo er suchen soll, dann Sie wollen diese Verzögerung - gerade zur Vermeidung von Schäden der in der Frage angegebenen Art. - 200_success
Das Nichtwissen von Passwörtern behindert keine Unfälle. Ganz im Gegenteil, es schafft Motivation, das Passwort nur einmal zu suchen, und danach kann der Entwickler den Bash-Verlauf verwenden oder sogar einen Alias ​​erstellen, um sich mit der Datenbank zu verbinden. Und dann passieren eher Unfälle. - k0pernikus


Die kurze Antwort ist RBAC - rollenbasierte Zugriffskontrolle.

Ihre Berechtigungen für alle Umgebungen müssen unterschiedlich sein - und so nervig wie Dinge wie UAC sind, Sie brauchen sie: besonders für PROD-Umgebungen.

Es gibt NOCH NIE Ein Grund für Entwickler, direkten Zugang zu Prod zu haben - unabhängig davon, wie klein die Organisation / das Team ist. Ihr "Entwickler" kann auch die "Bühne" und "Prod" Hüte tragen, aber er muss verschiedene Anmeldeinformationen und Prozesse haben, um verschiedene Umgebungen zu treffen.

Ist es nervig? Absolut. Aber verhindert es [helfen], Ihre Umgebung zu stören? Absolut.


0
2018-01-12 20:20





Eine schnelle und einfache Lösung: Verwenden Sie zwei verschiedene Benutzerkonten, eines für Ihre normale Entwicklungsarbeit, das nur Zugriff auf die Entwicklungsdatenbank hat, und ein anderes für den tatsächlichen Betrieb in der Produktionsdatenbank mit vollem Zugriff darauf. Auf diese Weise müssen Sie Ändern Sie das Konto, das Sie verwenden, aktiv bevor Sie Änderungen in der Produktion vornehmen können, die ausreichen sollten, um versehentliche Fehler zu vermeiden.

Der gleiche Ansatz kann verwendet werden, wenn Sie zwei Websites oder zwei Server oder zwei ganze Umgebungen haben: ein Benutzerkonto für die Entwicklung ohne Zugriff (oder zumindest keine schreiben Zugriff) auf die Produktion, ein weiteres Benutzerkonto für die Arbeit am Produktionssystem.


Dies ist der gleiche Ansatz wie ein Systemadministrator mit einem Standardkonto ohne Administratorrechte für Routinearbeiten (Lesen von E-Mails, Surfen im Internet, Verfolgen von Tickets, Einreichen von Arbeitszeittabellen, Schreiben von Dokumentationen usw.) und ein separates Volladministratorkonto für den tatsächlichen Betrieb auf Servern und / oder Active Directory.


0
2018-06-02 21:33