Eine Datenbank liegt auf einer verschlüsselten Festplatte. Das klingt sicher. Dann meldet sich jemand mit gültigen Zugangsdaten an und führt SELECT aus. Die Daten erscheinen lesbar. Genau an diesem Punkt endet der Schutz von Encryption at Rest.
(mehr …)
In Teil 1 dieser Reihe ging es um strukturelle Fehler: fehlende Fremdschlüssel, falsche oder fehlende Indizes, zu spät gesetzte Filter und Soft Deletes, die Daten nicht wirklich löschen.
Teil 2 hat gezeigt, warum mehrere zusammengehörige Schreibvorgänge in eine Transaktion gehören. Ohne BEGIN, COMMIT und ROLLBACK kann eine Anwendung Daten in einem Zustand hinterlassen, der nie hätte entstehen dürfen.
In Teil 3 ging es um Datenbanksicherheit: Root-Zugänge, Encryption at Rest, sensible Spalten und Backups. Dieser Teil führt den Gedanken konsequent weiter.
Denn selbst ein starkes Passwort und ein geschlossener Port lösen ein grundlegendes Problem nicht: Wenn die Anwendung mit einem Benutzer verbunden ist, der alles darf, wird aus jeder Schwachstelle in der Anwendung potenziell ein vollständiger Datenbankzugriff.
(mehr …)
In Teil 1 dieser Reihe ging es um strukturelle Fehler: fehlende Fremdschlüssel, falsche Indizes, Abfragen die unter Last zusammenbrechen. In Teil 2 um Transaktionen und warum ein fehlendes BEGIN die Datenbank in Zustände bringt aus denen es keinen sauberen Ausweg gibt.
Teil 3 ist unangenehmer. Nicht weil das Thema komplexer ist, sondern weil die Fehler die hier beschrieben werden selten aus bösem Willen entstehen. Manchmal ist es Zeitdruck. Manchmal Bequemlichkeit. Oft schlicht, dass in diese Richtung noch gar nicht gedacht wurde. ‚Die Datenbank läuft, der Zugriff ist geregelt, das reicht‘ — und damit endet die Sicherheitsbetrachtung, bevor sie die entscheidenden Punkte erreicht hat.
(mehr …)
In Teil 1 dieser Reihe ging es um strukturelle Fehler: fehlende Fremdschlüssel, falsche Indizes, Soft Deletes die keine sind. Am Ende stand ein Versprechen: Transaktionen. Ein Thema das in der Theorie einfach klingt und in der Praxis erschreckend oft falsch eingesetzt wird — oder gar nicht.
(mehr …)
Die Datenbank ist das Fundament jeder Anwendung. Das Frontend lässt sich neu bauen, Business-Logik refactoren, ein Framework austauschen — aber eine schlecht strukturierte oder langsame Datenbankschicht zieht die gesamte Anwendung nach unten. Und das meist schleichend: Nicht mit einem Knall, sondern mit Abfragen die nach und nach langsamer werden, mit Daten die irgendwann nicht mehr stimmen, mit einem System das unter Last in die Knie geht.
Trotzdem bekommt die Datenbank in vielen Projekten die wenigste Aufmerksamkeit. Sie läuft, also ist sie gut. Bis sie es nicht mehr ist.
In der Praxis sehe ich immer wieder dieselben Muster: Egal ob Neuprojekt oder gewachsenes System. Hier sind die fünf die mir am häufigsten begegnen.
(mehr …)Die Datenbank ist das Fundament jeder Anwendung. Das Frontend lässt sich neu bauen, Business-Logik refactoren, ein Framework austauschen — aber eine schlecht strukturierte oder langsame Datenbankschicht zieht die gesamte Anwendung nach unten. Und das meist schleichend: Nicht mit einem Knall, sondern mit Abfragen die nach und nach langsamer werden, mit Daten die irgendwann nicht mehr stimmen, mit einem System das unter Last in die Knie geht.
Trotzdem bekommt die Datenbank in vielen Projekten die wenigste Aufmerksamkeit. Sie läuft, also ist sie gut. Bis sie es nicht mehr ist.
In der Praxis sehe ich immer wieder dieselben Muster: Egal ob Neuprojekt oder gewachsenes System. Hier sind die fünf die mir am häufigsten begegnen.
(mehr …)
Es fing mit einer simplen Aufgabe an: Eine AJAX-Abfrage sollte idempotent werden. Konkret bedeutete das — egal wie oft der Request gefeuert wird, das Ergebnis bleibt stabil und vorhersehbar. Kein Flackern, keine Race Conditions, keine doppelten Einträge die sich gegenseitig überholen.
Die klassische Lösung: ORDER BY id. Fertig. Nächstes Problem.
Nur dass es diesmal kein nächstes Problem gab. Zumindest nicht sofort.
(mehr …)