Sollten Entwickler Produktionsdatenbanken abfragen können?

Nein.

Entwickler sollten nicht haben aus folgenden Gründen Zugriff auf Produktionsdatenbanksysteme:

1. Verfügbarkeit und Leistung : Schreibgeschützte Rechte an einer Datenbank sind nicht harmlos. Eine schlecht geschriebene Anfrage kann:

   1. Sperren Sie Tabellen und blockieren Sie andere kritische Prozesse.
   2. Entsorgen Sie Ihren Datencache und zwingen Sie andere Prozesse, Daten erneut von der Festplatte zu lesen.
   3. Steuern Sie Ihre Speicherebene und wirken Sie sich auf andere Dienste aus, die diesen Speicher gemeinsam nutzen.

2. Sicherheit : Ihre Produktionsdatenbank enthält möglicherweise vertrauliche Informationen wie:

   • passwort-Hashes
   • abrechnungsdaten
   • andere personenbezogene Daten

   Nur diejenigen, die unbedingt Zugriff auf diese Informationen benötigen, sollten diese haben. In einem gut organisierten Unternehmen gehören Entwickler nicht zu diesen Leuten. Darüber hinaus wird Ihr Unternehmen die PCI- und SOX-Konformität nicht erfüllen, wenn seine Entwickler mit diesen Daten auf Produktionssysteme zugreifen können.

   Die Gründe dafür liegen auf der Hand. Die Entwicklungsarbeit eines Entwicklers durchläuft viele Hände, bevor sie live geht. Was kann einen böswilligen Entwickler mit direktem Produktionszugriff davon abhalten, Ihre Produktionsdaten zu stehlen oder Ihre Live-Datenbank in die Knie zu zwingen?

   "Aber das gilt auch für die DBAs! Das könnten sie!" Genau. Sie möchten so wenig Superuser wie möglich.

Ja.

Entwickler sollte haben Zugriff auf Produktionssysteme.

In meiner Firma haben wir vier Teams, die sich mit Produktionsdatenbanken befassen. Sie sind:

1. Entwickler , die das Schema und den Code für die Datenbanken entwerfen und schreiben. Sie haben keinen Zugriff auf die Datenbanken in der Produktion. Manchmal sitzen sie jedoch mit den Administratoren oder Support-Mitarbeitern zusammen und helfen ihnen dabei, sich etwas im Leben anzusehen.
2. Administratoren , die die Datenbanken in der Produktion bereitstellen, überwachen und verwalten.
3. Unterstützen Sie Mitarbeiter , die zeitkritische Produktionsprobleme untersuchen und den Entwicklern Feedback geben, damit sie Korrekturen entwickeln können.
4. Business Intelligence-Mitarbeiter , die Daten aus Produktionsdatenbanken extrahieren, indem sie entweder regelmäßig aktualisierte Kopien dieser Datenbanken oder sorgfältig geschriebene und QS-erarbeitete Auszüge (normalerweise von den Administratoren erstellt) verwenden ).

Es ist angebracht, Ihren Entwicklern Produktionszugriff zu gewähren, wenn Sie bestimmte Mängel in diesen anderen Gruppen haben.

Zum Beispiel:

• Sie haben kein Support-Team. Wer weiß, wo er suchen muss, um dieses zeitkritische Produktionsproblem zu beheben? Ihre Entwickler. Gewähren Sie ihnen " Glas zerbrechen " Zugang.
• Sie haben kein BI-Team. Ihre Administratoren haben oder wollen nichts mit Berichten oder Auszügen zu tun haben. Wer wird den Bericht beheben, den Ihre Führungskräfte jeden Morgen sehen? Ihre Entwickler. Gewähren Sie ihnen eingeschränkten Zugriff zum Debuggen dieser Berichte und Auszüge.
• Sie haben kein Admin-Team. Sie befinden sich in einem sehr kleinen oder Startup-Unternehmen. Begrüßen Sie also den "versehentlichen DBA". Ihre Entwickler fungieren gleichzeitig als Administratoren und benötigen daher vollen Zugriff auf die Produktion.

Leistung wäre ein großer Grund.

Nur weil sie die Daten nicht ändern können, heißt das nicht, dass sie den Server nicht beeinflussen können. Eine schlecht geschriebene Abfrage kann die Produktionsumgebung in die Knie zwingen und möglicherweise andere Probleme verursachen (z. B. Tempdb-Überläufe):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

Das ist ein Rezept für eine Katastrophe. Beachten Sie, dass dies ein kartesisches Produkt mit einer Bestellung von ist, was bedeutet, dass es in tempDB sortiert wird.

Das Prinzip lautet "geringstes Privileg" und "müssen wissen": Bestehen Entwickler diesen Test?
Besonders wenn Auditoren oder Sarbannes-Oxley klopfen.

Dann meine nächste Annahme: Entwickler sind dumm. Also, wenn sie für die Unterstützung der 3. Zeile etwas sagen müssen, wer dann braucht es? Web-Affen tun dies normalerweise nicht, aber Datenbanktypen ja, wenn erwartet wird, dass sie dies unterstützen.

Wird dann dauerhaft Zugriff benötigt? Sie können über ein SQL-Login oder ein alternatives Windows-Konto, für das eine Abmeldung erforderlich ist, auf "Glasbruch" zugreifen. In unserem Fall war es der Dateneigentümer (hoffentlich ein technisch versierter Geschäftsmann) und der IT-Manager, der dies genehmigte.

Ich habe Entwickler gesehen, die Abfragen in der Produktion getestet oder ausgeführt haben, und habe es heruntergenommen wegen Unwissenheit. Entwickler sollten die Verantwortung für ihre Aktionen übernehmen: Wenn sie einen Server herunterfahren, sollten sie entsprechend leiden. Ich habe jemanden nach einem Vorfall herabgestuft ...

Diese setzen natürlich einen einigermaßen großen Laden voraus. Je mehr Hüte die Leute tragen, desto weniger Aufgabentrennung kann man haben

Gibt es auch eine Umgebung, in der Entwickler Abfragen für aktuelle Daten ausführen können? In meinem letzten Shop wurde prod jeden Abend auf einem Testserver wiederhergestellt, um dies bereitzustellen.

Ich denke, die Antwort ist, wie bei vielen IT-Dingen, "es kommt darauf an".

Eine massive ERP -Datenbank mit vielen vertraulichen Unternehmens- und Kundeninformationen? Wahrscheinlich nicht (sowohl aus Sicherheits- als auch aus Leistungsgründen).

Eine abteilungsbezogene 5-MB-Datenbank mit einem Access-Frontend, das Beiträge zu den Donut- und Pizzafonds verfolgt? Zumindest für den schreibgeschützten Zugriff wird dies keinen großen Unterschied machen.

Zugegeben, das erste Beispiel ist viel häufiger als das zweite, aber dies sind Unterschiede, die Sie beachten sollten, wenn Sie für diese Art von Richtlinienentscheidungen verantwortlich sind. Aber auf der anderen Seite ist es erstaunlich, wie schnell sich eine 5-MB-Donut-and-Pizza-Fund-Datenbank auf 50-GB-Teilenummern/Kundenkreditkartennummern/wer-weiß-was- einschleichen kann. sonst Datenbank, wenn Sie es zulassen.

In einer normalen 24/7 OLTP -Umgebung sollte ein normaler Entwickler nicht in die Produktion zugelassen werden. Zeitraum! Wenn von Zeit zu Zeit ein bestimmter Grund auftritt, können auf Anfrage Berechtigungen erteilt werden. Aber normalerweise nein.

Ich habe viele Gründe dafür gesehen:

• SELECT * von einem großen Tisch führt zu:

  • leistungsprobleme (kartesische Produkte);
  • blockieren von Problemen, die die Site schließlich in die Knie zwangen;
  • blockierkette, die die Replikation zum Stillstand bringt;
  • bestellen eines großen Datensatzes, der das TempDB-Laufwerk füllte. Verursachte völligen Wahnsinn :-)!
  • hoher Blutdruck für den DBA, der für diese Nacht für die Produktion verantwortlich ist;

• lesen sensibler Daten (ein Entwickler sollte keinen Zugriff auf Kreditkarteninformationen oder persönliche Daten des Benutzers haben);

Ich bin sicher, es gibt noch mehr Gründe.

• Sicherheit: Möglicherweise sind vertrauliche Informationen bereinigt, wenn sie Entwicklern zur Verfügung gestellt werden.
• Paranoia: Einige denken vielleicht, Sie könnten mit nur ausgewähltem Zugriff immer noch Daten durcheinander bringen.
• Leistung: Für eine Abfrage sind einige Ressourcen erforderlich, und Sie können mir nicht sagen, dass Ihre Entwickler beim Schreiben von Code perfekt sind.

Einige zu berücksichtigende Punkte

• Sind die Daten sensibel?
• Sind die Programmierer Teil eines vertrauenswürdigen Kernteams oder eines Offshore-Teams?
• Wie groß sind die Daten, die abgefragt werden, um die Leistung zu beeinträchtigen?
• Wie groß ist das Projekt oder die damit verbundenen Dollars?
• Wie kritisch ist die Betriebszeit?

Kleinere Dollars benötigt weniger Prozess benötigt schnelleren Entwicklungsfluss.

Größere Dollars braucht mehr Prozess braucht strengere Standards für Entwicklungspraktiken.

Passen Sie Ihre Praktiken an das an, was Sie tun.

Ich arbeite als Entwickler für ein sehr großes Unternehmen. Alle unsere Entwickler, die jegliche Art von Support leisten (im Grunde alle), haben Zugriff auf relevante Produktionsdatenbanken. Ich kann nur für mein spezielles Team sprechen, aber ich werde Ihnen sagen, warum wir Zugriff haben.

1. Wir benötigen Echtzeitzugriff, um unsere tägliche Verarbeitung im Auge zu behalten. (Obwohl wir ein Dashboard haben, müssen wir in der Lage sein, die Dinge genau im Auge zu behalten. Es wäre zwar schön, diese Funktion in unserem Dashboard zu haben, aber wir haben festgestellt, dass dies unpraktisch ist.)
2. Wir benötigen Echtzeitzugriff, um Produktionsausfälle zu untersuchen, da Verzögerungen enorme Auswirkungen haben können. (Ich werde hier nicht über unsere Fehler sprechen. Sie kommen in allen möglichen Fällen vor.)
3. Wir müssen häufig benutzerdefinierte Berichte für Geschäftsbenutzer erstellen und diese Informationen müssen auf dem neuesten Stand sein. (dba hat keine Zeit dafür und wir haben keine Zeit darauf zu warten. Nicht ideal, aber sicher.)
4. Wir müssen die DDL/DML-Bereitstellungen/Patches für die Produktion überprüfen. (DBAs stellen sie bereit, aber nur wir wissen, wie sie strukturiert sein sollten. Wir wissen mehr über unsere Datenbankstruktur als über die DBAs. Wir mögen hier seltsam sein, aber unsere Datenbank ist sehr kompliziert, weil unser Geschäft sehr kompliziert ist.)

Leistung ist ein Anliegen. Wir haben Entwickler, die Verlangsamungen verursachen. Dies sind jedoch isolierte Instanzen, und unser SQL ist so leistungsorientiert, dass unsere Entwickler die Auswirkungen ihrer Abfragen selten nicht verstehen.

Damit diese Frage gestellt werden kann, muss davon ausgegangen werden, dass sie derzeit keinen Zugriff haben. Wenn die eigene Organisation Software entwickelt und dies zur Behebung eines Kundenproblems dient und der Kunde eine Kopie seiner Datenbank bereitstellt, klicken Sie auf "Ja". Andernfalls würde ich befürworten, Entwickler von der Produktion fernzuhalten und alternative Umgebungen für ihre Forschungsbedürfnisse zu erstellen. Sobald die Zahnpasta aus der Tube ist, ist es schwierig, sie wieder einzulegen.

Ich stimme zu, dass die Last der Rechtfertigung bei denjenigen liegen sollte, die Zugang benötigen. In Umgebungen, in denen ich mich beraten habe, hatte ich normalerweise Zugriff auf Produktionssysteme, in denen es sich um eine kleine Umgebung handelte, und ich war die Support-Person. Ich hatte Zugriff auf Backups usw., bei denen ich den Support unterstützte, und indirekten Zugriff (über einen dedizierten Support-Entwickler) auf Produktionsdaten.

Die große Sache ist: Sie benötigen diesen Zugang, wenn Sie am Haken sind, damit alles reibungslos läuft, und Sie müssen die Frage des Finanzmanns nach etwas beantworten, das nicht funktioniert. In diesem Fall können Sie nicht immer mit eintägigen Daten arbeiten. Auf der anderen Seite ist es umso schlechter, je mehr Zugang vorhanden ist. Normalerweise vermeide ich als Berater, diese Art von Zugriff zu erhalten, es sei denn, dies wird benötigt. Da ich an Finanzdatenbanken arbeite, möchte ich als letztes beschuldigt werden, meine eigenen Rechnungen eingegeben zu haben :-D.

Wenn Sie dagegen keinen Zugriff benötigen, sollten Sie ihn nicht haben. Ich kaufe das Argument für vertrauliche Daten nicht wirklich, da der Entwickler wahrscheinlich am Haken ist, um sicherzustellen, dass dies korrekt gehandhabt wird (und es sehr schwer zu überprüfen ist, ohne zu prüfen, was tatsächlich gespeichert wurde, wenn ein Fehlerbericht eingeht). Wenn Sie dem Entwickler nicht vertrauen können, dass er sich die Daten ansieht, die in der Entwickler-App gespeichert sind, sollten Sie den Entwickler nicht damit beauftragen, die App zu schreiben. Es gibt zu viele Möglichkeiten, wie der Entwickler die Daten verschleiern und per E-Mail versenden kann, und Sie können sich nie sicher sein. MAC-Steuerelemente helfen hier, sind aber immer noch recht komplex zu implementieren.

Das große Problem von meiner Seite hat mit dem Schreibzugriff zu tun. Wenn ein Entwickler erst recht keinen Zugriff hat, hat der Entwickler keinen Schreibzugriff. Wenn Sie die Integrität der Bücher überprüfen möchten, möchten Sie den Schreibzugriff auf so wenige Personen wie möglich beschränken. Audit-Trails sind viel einfacher zu validieren, wenn die Entwickler keinen Zugriff haben. Wenn der Entwickler über Lesezugriff verfügt, haben Sie immer eine Frage, ob ein Berechtigungs-Escallation-Anhang vorhanden ist, der Schreibzugriff ermöglicht (möglicherweise SQL-Injection mit gespeicherter Prozedur?). Ich hatte oft vollen Zugriff auf Kundenabrechnungsinformationen, wenn ich Zugriff auf Staging-Umgebungen hatte. Wenn es eine Staging-Umgebung gibt, die jedoch funktioniert, werde ich normalerweise aktiv darum bitten, nicht Zugriff auf die Produktion zu haben, es sei denn, dies ist erforderlich.

Das ist natürlich nicht perfekt. Ein Entwickler könnte immer noch Hintertüren in die Anwendung einbauen, die möglicherweise nicht leicht zu erkennen sind. Dieser Ansatz ist jedoch ein vernünftiger Ansatz, da Sicherungsdaten ab einem Tag zuvor verfügbar sind. Dies scheint mir das Problem zu sein, das sie haben.

Hoffe das hilft.

Bearbeiten: Wenn ich nur hinzufüge, dass ich in den größeren Umgebungen, in denen ich gearbeitet habe, Zugriff auf vollständige Sicherungsdaten hatte, die für das Finanzsystem häufig zwischen einigen Tagen und einigen Monaten alt waren. Dies war immer gut genug für meine Arbeit und das einzige Mal, dass es zusammenbrach, war, als die Finanzleute die Fähigkeit brauchten, mit neueren Daten zu testen, damit sie mit der Produktion mithalten konnten.

Kein Zugriff ist eine gute Sache und eine Möglichkeit, Entwickler und andere davor zu schützen, die Daten nicht versehentlich zu beschädigen oder anzuzeigen. Dies schützt Unternehmen auch vor Gesetzesverstößen (d. H. Hipaa-Verstößen und Datenschutzbedenken).

Ein Entwickler braucht nie wirklich Zugriff auf eine Produktionsumgebung. Aus Entwicklersicht ist es nur einfacher, wenn ein schwerer Fehler nicht reproduziert werden kann.

Ein Entwickler kann jedoch Mini-Dumps oder Protokolldateien einfügen und die PDB-Symboldateien verwenden, um den Fehler neu zu erstellen.

Wenn die Daten in eine Testumgebung gebracht werden müssen, ist es typisch für einen Prozess, die Daten zu bereinigen, was zusätzliche Arbeit verursachen kann.

Abhängig von der Datenbanksoftware, die in der von Ihnen als Produktion bezeichneten Produktion verwendet wird, ist möglicherweise eine neue Lizenz erforderlich, damit der Entwickler auf die Datenbank zugreifen kann. Dies ist ein großer Aufwand für den einfachen Lesezugriff.

Wenn Ihr Unternehmen Ihnen nicht die Tools zum Debuggen oder Erforschen von Produktionsproblemen zur Verfügung stellt, liegt dies nicht daran, dass Sie keinen Zugriff auf die Produktionsdaten haben.

Daten sind der wertvollste Teil der meisten Anwendungen!

Leistung könnte einer der Gründe sein.

Entwicklerabfragen können häufig ineffizient sein und zu übermäßiger Sperrung oder Ressourcennutzung führen, bis sie ordnungsgemäß optimiert wurden.

Ein Produktionssystem ist kein geeigneter Ort für Entwickler zum Experimentieren.

Es hängt vom DBA ab und wie er oder sie dem Entwickler vertraut. Normalerweise erhalten Entwickler AbfrageLese-) Berechtigungen für die Produktionsdatenbanken. Als Faustregel gilt, dass Entwickler --- (sollten nur mit Test-/Entwicklungsdatenbanken arbeiten.

Die Herausforderung besteht darin, dass die meisten Softwareanwendungen datengesteuert sind. Wenn Sie also versuchen, ein Problem in der Anwendung zu beheben, müssen Sie wirklich die Daten sehen, die es steuern. Die Entwickler brauchen also wirklich irgendeine Form von Zugang.

Es ist großartig, SQL-Anmeldungen zu verwenden, um ihnen nur Lesezugriff auf Tabellen zu gewähren. ABER, was hindert sie daran, eine Abfrage mit 20 Verknüpfungen zu erstellen oder SELECT * aus einer Tabelle mit Millionen von Datensätzen auszuführen? Diese Abfragen können versehentlich die Leistung Ihrer Datenbank und Ihres Speichers beeinträchtigen.

Meine Firma Stackify hat einen cleveren Weg gefunden, um dieses Problem zu lösen. Entwickler können die Abfrage über unsere Software ausführen. Wir verwenden den Abfrageplan, um sicherzustellen, dass es sich nur um eine SELECT-Anweisung handelt und dass die geschätzten Kosten der Abfrage niedrig sind und nur wenige Datensätze zurückgegeben werden. Auf diese Weise können sie nicht viel Schaden anrichten. Wir prüfen auch alle von ihnen ausgeführten Abfragen.

Dies ist nur eines der Dinge, die wir anbieten. Besuchen Sie uns unter http://www.Stackify.com , um mehr über unsere DevOps-Unterstützung Lösungen zu erfahren.

Ja. In einigen Fällen ist es sinnvoll, einigen Benutzern, einschließlich Entwicklern, einen gewissen Zugriff auf Abfrageproduktionsdaten zu gewähren. Die richtigen Einschränkungen müssen jedoch aus zwei Gründen bestehen. Als DBA müssen Sie zunächst Ihr Bestes geben, um das von allen Benutzern benötigte Serviceniveau sicherzustellen. Außerdem möchten Sie unbeabsichtigte fehlerhafte Abfragen wie Massenlöschungen oder Verleumdungen von Geschäftsregeln verhindern. Es sollte selbstverständlich sein, dass angemessene Sicherheitskontrollen vorhanden sein müssen.

Unabhängig von den Gründen, aus denen Sie möglicherweise Ad-hoc-Abfragen nicht direkt in Datenbanktabellen zulassen, kann es vorkommen, dass Abfragen Ansichten und gespeicherten Prozeduren gestattet werden. Mithilfe von Datenbankberechtigungen können Sie verhindern, dass SELECT-Abfragen für Tabellen direkt durchgeführt werden, und sogar einschränken, auf welche Ansichten und gespeicherten Prozeduren ein bestimmter Benutzer Zugriff hat. Diese Methode bietet nicht nur Flexibilität für Ihre Benutzerbasis, sondern schützt auch Ihre Datenintegrität und -realisierbarkeit bei korrekter Implementierung.

In unserem Unternehmen unterhalten wir schreibgeschützte Slaves von Produktionsdatenbanken, auf die sich Produktionsdienstleistungen nicht verlassen. Wir gewähren Entwicklern Zugriff auf diese für den Zugriff auf Produktionsdaten. Wenn vertrauliche Daten (Kundeninformationen, Zahlungsinformationen usw.) vorhanden sind, beschränken wir die Replikation dieser Tabellen und verwalten eine Beispieldatentabelle auf dem Slave-Server.

Nein niemals!!

Aus diesem Grund haben wir Entwicklungs-/Test-/UAT-Server. Die Daten aus der Produktion können in die Testumgebung kopiert werden, und die Entwickler können ihre Tests fortsetzen. Ausgewählte Abfragen können auch in einer Produktionsumgebung sehr schädlich sein. Es erhöht die Last und kann in Spitzenzeiten die gesamte Leistung beeinträchtigen.

Alle benötigten Informationen sollten über den DBA gesendet werden, der ausführen kann, was er möchte (Auswählen), und ihm die Ergebnisse senden. So machen wir es in unserer Umwelt.