Wie kann ich ein versehentliches Aufbocken mit einer Produktionsdatenbank verhindern?

Erst kürzlich hatte ein Entwickler versehentlich versucht, eine Datenbank für die Produktion wiederherzustellen, obwohl er eine Staging-Kopie hätte wiederherstellen sollen. Dies ist einfach, da die Datenbanknamen ähnlich sind, dh CustomerName_Staging im Vergleich zu CustomerName_Production.

Idealerweise würde ich diese auf völlig getrennten Boxen haben, aber das ist unerschwinglich und genau genommen verhindert es nicht, dass das Gleiche passiert, wenn der Benutzer eine Verbindung zur falschen Box herstellt.

Dies ist per se kein Sicherheitsproblem - es war der richtige Benutzer, der mit der Staging-Datenbank arbeitete, und wenn in der Produktionsdatenbank noch etwas zu tun ist, ist er es auch. Ich hätte gerne einen Einsatzleiter, der diese Bedenken ausräumt, aber das Team ist dafür nicht groß genug.

Ich würde gerne Ratschläge in Bezug auf Übung, Konfiguration und Kontrolle darüber erhalten, wie dies verhindert werden kann.

Wenn Sie dies häufig tun, automatisieren Sie es. Und da Sie beide Entwickler sind, sollte sich das Schreiben von Code in Ihrem Steuerhaus befinden. :) Im Ernst ... durch die Automatisierung können Sie Dinge tun wie:

• Stellen Sie sicher, dass Sie auf dem richtigen Server wiederherstellen (dh keine dev -> prod-Wiederherstellung)
• Stellen Sie sicher, dass es sich um den richtigen Datenbanktyp handelt (in Ihrem Fall "Staging" und "Produktion").
• Finden Sie anhand der Sicherungstabellen in msdb heraus, welche Sicherungen automatisch wiederhergestellt werden sollen

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

Ich bin mit der Annahme in der Frage nicht einverstanden - das ist Sicherheit -, aber ich bin auch nicht einverstanden, dass Automatisierung den Tag für sich retten wird. Ich werde mit dem Problem beginnen:

Sie sollten nicht versehentlich irgendetwas mit der Produktion anfangen können!

Dazu gehört, dass Dinge versehentlich automatisiert werden.

Sie verwechseln die Systemsicherheit mit Konzepten wie "Wer darf was?". Ihre Entwicklungskonten sollten nur in der Lage sein, auf ihre Kopien, den Versionskontrollserver und die Entwicklerdatenbank 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 falsch behandelt werden, um Kundendaten zu verlieren.

Sie müssen zunächst Ihren Workflow sortieren.

• Ihre Entwicklerkonten sollten in der Lage sein, auf ihre eigenen Kopien zu schreiben, die Versionskontrolle durchzuführen und möglicherweise von der Versionskontrolle in eine Testumgebung zu ziehen.

• Sicherungsbenutzer sollten nur in der Lage sein, aus der Produktion zu lesen und in Ihren Sicherungsspeicher zu schreiben (der entsprechend geschützt sein sollte).

• Für andere Lese- / Schreibvorgänge in der Produktion ist eine spezielle und unpraktische Authentifizierung erforderlich . Sie sollten nicht hineingelangen können oder vergessen, dass Sie angemeldet sind. Die physische Zugriffskontrolle ist hier hilfreich. Smartcards, Kippschalter zum Aktivieren des Kontos und gleichzeitiger Dual-Key-Zugriff.

  Der Zugriff auf die Produktion sollte nicht etwas sein, das Sie jeden Tag tun müssen. Der Großteil der Arbeit sollte auf Ihrer Testplattform und in Bereitstellungen außerhalb der Geschäftszeiten erfolgen, die nach sorgfältiger Prüfung in der Produktion durchgeführt wurden. Eine kleine Unannehmlichkeit wird dich nicht töten.

Automatisierung ist Teil der Lösung.

Ich bin nicht blind für die Tatsache, dass der vollständige Turnaround (Hochladen auf VCS, Überprüfen der Abdeckung, Abrufen auf den Testserver, Ausführen automatisierter Tests, erneute Authentifizierung, Erstellen eines Backups, Abrufen von VCS) ein langer Prozess ist.

Hier kann die Automatisierung helfen, so Bens Antwort. Es gibt viele verschiedene Skriptsprachen, die das Ausführen bestimmter Aufgaben erheblich vereinfachen. Stellen Sie nur sicher, dass Sie es nicht zu einfach machen, dumme Dinge zu tun. Ihre Schritte zur erneuten Authentifizierung sollten immer noch ausgesprochen (und falls gefährlich) sein. Sie sollten unpraktisch und schwer zu bewerkstelligen sein , ohne nachzudenken.

Aber alleine ist Automatisierung schlimmer als nutzlos. Es hilft dir nur, größere Fehler mit weniger Gedanken zu machen.

Geeignet für Teams aller Größen.

Mir ist aufgefallen, dass Sie auf die Größe Ihres Teams hingewiesen haben. Ich bin ein Mann und habe es selbst durchgemacht, weil nur eine Person einen Unfall hat. Es ist ein Aufwand, aber es lohnt sich. Sie erhalten eine viel sicherere und sicherere Entwicklungs- und Produktionsumgebung.

Einer meiner Mitarbeiter hat einen interessanten Ansatz. Sein Endfarbenschema für die Produktion ist flüchtig . Grau und Rosa und schwer zu lesen, was theoretisch sicherstellen soll, dass er wirklich schreiben wollte, was auch immer er schreibt.

Ihre Laufleistung kann variieren ... und ich muss wahrscheinlich nicht sagen, dass sie für sich genommen kaum kugelsicher ist. :)

Entwickler sollten das Kennwort für die Produktionsdatenbank nicht kennen. Das Passwort sollte zufällig und nicht einprägsam sein - so etwas wie das Ergebnis von Tastatur-Mashing ( Z^kC83N*(#$Hx). Ihr Entwicklerpasswort kann $YourDog'sNameoder correct horse battery stapleoder was auch immer sein.

Sicher, Sie können herausfinden, wie das Kennwort lautet, insbesondere wenn Sie ein kleines Team sind, indem Sie die Konfigurationsdatei der Clientanwendung lesen. Dies ist der einzige Ort, an dem das Produktpasswort existieren sollte. Dies stellt sicher, dass Sie sich absichtlich anstrengen müssen, um das Kennwort für das Produkt zu erhalten.

(Wie immer sollten Sie Punkt-zu-Zeitpunkt-Sicherungen für Ihre Produktionsdatenbank durchführen. Archivieren Sie beispielsweise mit MySQL die Binärprotokolle als inkrementelle Sicherungen. Archivieren Sie für PostgreSQL die Write-Ahead-Protokolle. Dies ist Ihr letzter Schutz für jede Art von Katastrophe, selbstverschuldet oder auf andere Weise.)

Die kurze Antwort lautet RBAC - rollenbasierte Zugriffskontrolle.

Ihre Berechtigungen für alle Umgebungen müssen unterschiedlich sein - und so ärgerlich Dinge wie die Benutzerkontensteuerung auch sind, Sie benötigen sie: insbesondere für PROD-Umgebungen.

Es gibt NIEMALS einen Grund für Entwickler, direkten Zugang zu Prod zu haben - unabhängig davon, wie klein die Organisation / das Team ist. Ihr "Dev" trägt möglicherweise auch die Hüte "Stage" und "Prod", muss jedoch über unterschiedliche Berechtigungen und Prozesse verfügen, um unterschiedliche Umgebungen zu treffen.

Nervt es Absolut. Aber verhindert es, dass Ihre Umgebung kaputt geht? Absolut.

Eine schnelle und einfache Lösung: Verwenden Sie zwei verschiedene Benutzerkonten, eines für Ihre normale Entwicklungsarbeit, die nur Zugriff auf die Entwicklungsdatenbank hat, und eines für die eigentliche Bearbeitung der Produktionsdatenbank mit vollem Zugriff darauf. Auf diese Weise müssen Sie das von Ihnen verwendete Konto aktiv ändern, bevor Sie Änderungen in der Produktion vornehmen können. Dies sollte ausreichen, um versehentliche Fehler zu vermeiden.

Der gleiche Ansatz kann angewendet werden, wenn Sie über zwei Websites oder zwei Server oder zwei vollständige Umgebungen verfügen: ein Benutzerkonto für die Entwicklung ohne Zugriff (oder zumindest ohne Schreibzugriff ) auf die Produktion, ein anderes Benutzerkonto für die Arbeit am Produktionssystem ( s).

Dies ist der gleiche Ansatz wie ein Systemadministrator, der über ein Standardkonto ohne Administratorrechte für Routinearbeiten (Lesen von E-Mails, Surfen im Internet, Verfolgen von Tickets, Ablegen von Arbeitszeittabellen, Verfassen von Dokumentationen usw.) und ein separates Konto mit Administratorrechten verfügt, das für den tatsächlichen Betrieb verwendet wird auf Servern und / oder Active Directory.