Die Sicherheit des Gesamtsystems

Die Idee | Beispiele | Sicherheit & Features | Preise | News | Datenschutz | AGB

Server-Daten ist dadurch gekennzeichnet, daß es diverse strukturelle Sicherheitskonzepte gibt, die im Gesamtsystem eingebaut und allen Kunden jederzeit zur Verfügung stehen. Eine Deaktivierung dieser Sicherheitskonzepte ist nicht möglich. Technisch stehen alle Server in Deutschland im Rechenzentrum, Sitz des Geschäftsbetriebs ist Berlin. Es gilt europäisches bzw. deutsches Recht.

1. Sicherheit auf der Ebene der Hardware

  1. Server-Daten basiert auf einem Zwei-Server-System bestehend aus Webserver und Datenbankserver. Solche Zwei-Server-Systeme sind grundsätzlich sicherer als Ein-Server-Systeme. Selbst wenn es jemandem gelänge, den Webserver zu übernehmen, könnte er lediglich jene gespeicherten Prozeduren auf dem Datenbankserver ausführen, die Nutzer dort ohnehin ausführen können.
  2. Nutzung von RAID-X: Bei RAID werden diverse physikalische Platten zu mehreren logischen Platten zusammengeschaltet, die Daten werden auf diese redundant verteilt. Wirkung: Selbst wenn einzelne Platten ausfallen, bleiben die Daten erhalten. RAID-X lohnt damit aber nicht für kleine Datenmengen (mehrere GB). Erst recht nicht für Kunden, die lediglich 50 - 100 MB Datenbankplatz benötigen. Innerhalb von Server-Daten teilen sich viele Kunden dieselbe Hardware. Damit kann RAID-X genutzt werden.
  3. Vorgeschaltete Hardware-Firewall: Wenn Sie versuchen, den Webserver von Server-Daten von außen her anzusprechen, dann reagiert dieser nur auf die beiden http-Ports 80 / 443 und die beiden Mail-Ports 25 / 587. Verwaltungsports sind von außen her nicht zugänglich. Das ist ein wesentlicher Unterschied zu typischen "kleinen webbasierten Anwendungen". Bei diesen sind die Verwaltungsports ebenfalls von außen her zugänglich. Und damit empfindlich gegen weltweite Angriffe.
  4. Starke Verschlüsselung aller Zugriffe: Alle Zugriffe auf *.server-daten.de sind nur verschlüsselt möglich. Üblicherweise sollte der Browser eine 256-Bit-Verschlüsselung unterstützen. Der öffentliche RSA-Schlüssel hat eine Länge von 4096 Bit. Selbst bei Banken findet man oft noch Schlüssel von lediglich 2048 Bit.

    Schlüssel von 8192 Bit werden bislang noch nicht von Browsern unterstützt, so daß 4096 Bit aktuell das Maximum sind.

  5. Kunden können eigene Domains bzw. Subdomains (datenbank.kundendomain.de) per CNAME-Eintrag auf www.server-daten.de zeigen lassen. Damit können Kunden ihre Datenbank unter ihrer eigenen Domain/Subdomain nutzen. Seit Mai 2018 gibt es im Gesamtsystem einen Letsencrypt-Client, der solche Domains automatisch und inklusive mit Zertifikaten versorgt. Seither erfolgen Zugriffe auf Datenbanken ausschließlich verschlüsselt. http / Port 80 dient nur zur Weiterleitung auf https.
  6. Automatische nächtliche Sicherungen, die anschließend von den Servern wegtransportiert werden und noch eine Weile aufbewahrt werden. Praktisch spielt das so gut wie keine Rolle. Aber es ist gut, zu wissen, daß dies automatisch und regelmäßig erledigt wird.

    Das bedeutet auch: Die Sicherungen einer 100-MB-Datenbank liegen im Bereich von mehreren GB.

  7. Wenn Kunden dies wünschen, können sie sich nächtlich die Datenbank als Access-Datenbank (verschlüsselt mit einem eigenen 8192-RAS-Schlüssel) per Mail zusenden lassen. Falls die Datenbank für das Mailkonto zu groß ist, kann das auch in mehreren Portionen erfolgen.

    In Kundendatenbanken lassen sich vielfältige Excel-Exporte einrichten. So daß ein Kunde mit einer Exceltabelle auf Server-Daten umzieht, sich diese aber jederzeit in der alten Version wieder herunterladen und offline weiternutzen kann.

    Ferner können vorhandene Word-Dokumente, die bislang für Serienbriefe oder Einzelschreiben (Auftrag, Rechnung) genutzt wurden, so angepaßt werden (ab Office 2007), daß sie direkt mit dem Ergebnis einer Abfrage gematcht und als reines Word-Dokument ausgegeben werden.

    Server-Daten erstellt seine eigenen Rechnungen ebenfalls über eine Web-Datenbank als Word-Dokument. Mit einer Kopfzeile (Daten, die pro Rechnung einmal benötigt werden) und vielen Detailzeilen (Einzelposten bei Einrichtungstätigkeiten).

    Etwas ähnliches ist mit PDF-Dokumenten möglich, die beschreibbare Felder haben. Diese werden mit Inhalten der Datenbank befüllt und in ein reines PDF (ohne Eingabefelder) umgewandelt. Allerdings gibt es bei PDF-Dokumenten nicht die Möglichkeit, einen Block mehrfach zu kopieren und mit Detailzeilen zu befüllen. Bei Word geht dies.

2. Sicherheit auf der Ebene der gemeinsam genutzten Hintergrund-Software

  1. Server-Daten nutzt für die Kommunikation zwischen Web- und Datenbankserver ausschließlich gespeicherte Prozeduren, die keinen dynamischen Code zusammenbauen. Damit sind per definitionem keine Sql-Injektionen möglich.

    Ferner werden alle Eingaben auf ihre korrekten Datentypen geprüft, so daß nicht über diesen Weg Lücken ausgenutzt werden können.

    • Test: Geben Sie in der Suche auf dem Blog https://blog.server-daten.de/de/

      don't

      ein. Dann werden Ihnen korrekt einige Ergebnisse angezeigt. Teils ist das Suchergebnis bereits im Titel, teils im Inhalt des Beitrags zu finden (englisches Zitat).

      Aber: Es kommt nicht zu einer Fehlermeldung, weil mit dem ' eine Sql-Injektion bzw. ein syntaktisch falscher Sql-Befehl produziert wurde.

      Dasselbe gilt für Stellen, wo nach Zahlen gesucht werden kann. Wenn ein System gegen Sql-Injektionen anfällig ist, kann man an diesen Stellen auch eigene Sql-Logik einfügen und das System damit kompromittieren.

  2. Alle Ausgabeseiten werden über eine Xsl-Transformation abgewickelt. Diese maskiert Spitzklammern (< und >) automatisch, so daß diese nicht als Spitzklammern, sondern als &lt; und &gt; zum Browser gesendet werden. Damit sind keine Cross-site Scripting (XSS) - Attacken möglich.

    • Test: Geben Sie in der Suche auf dem Blog https://blog.server-daten.de/de/

      <script>alert("Hallo");</script>

      ein. Dann wird Ihnen korrekt ausgegeben, daß nichts gefunden wurde.

      Wenn Sie in den Quellcode der Ergebnisseite sehen, sind die von Ihnen eingegebenen Spitzklammern maskiert.

      Der Blog ist dabei nur ein öffentlich zugängliches Beispiel. Der Schutz funktioniert auf allen Eingabeseiten analog, die Blogsuche wurde dafür nicht gesondert angepaßt.

  3. Schutz gegen Cross-Site-Request-Forgery (CSRF) - Attacken. Diese sind zwar "eigentlich" innerhalb von Server-Daten kaum denkbar, weil dafür alle Seiten bei Kunden sehr individuell aussehen. Aber sie werden gestoppt, indem Zufallswerte in versteckten Feldern mitgeschickt werden. Beim Speichern wird überprüft, ob der zurückgeschickte Zufallswert mit jenem Zufallswert in der Session des Nutzers übereinstimmt. Damit ist ein "Unterjubeln" von Aktionen per unsichtbarem iFrame auf eine Kundendatenbank o.ä. nicht mehr möglich.

    Diese Techniken erfordern einen gewissen Aufwand, der meist außerhalb typischer "kleiner Individualprogrammierungen" (quick and dirty) liegt.

  4. Jeder Nutzer kann sich zu einem Zeitpunkt nur mit einem Browser anmelden. Nutzt er dieselben Zugangsdaten mit einem anderen Browser (gleiches oder anderes Gerät), wird die Zufallszeichenfolge, die der ersten Sitzung zugeordnet ist, überschrieben und damit ungültig. Diese erste Sitzung kann keine Daten mehr abrufen oder speichern. Das ist eine Möglichkeit, zu merken, daß der eigene Account womöglich gehackt worden ist.
  5. Alle Schreibzugriffe werden protokolliert und allen eingeloggten Nutzern angezeigt. Das sorgt dafür, daß allen Nutzern klar ist, daß ihr Tun Spuren hinterläßt.
  6. Implementierung einer Content Security Policy (CSP): Diese sorgt dafür, daß selbst über die internen Formulare zur Verwaltung der Datenbank kein eigenes JavaScript eingeschleust werden kann. Sprich: Selbst bei einem gehackten Administratoraccount ist es nicht möglich, per JavaScript Ransomware / Verschlüsselungssoftware einzuschleusen und an alle Nutzer auszuliefern.

    Das ist ein wesentlicher Unterschied gegenüber üblichen Content Management Systemen. Diese lassen es üblicherweise immer zu, daß über die Administratoroberfläche zusätzlicher, "roher Html-Code" mitsamt JavaScript-Code in eine Seite ergänzt werden kann. Bei einem gehackten Administratoraccount kann der Hacker über diesen Weg JavaScript, damit Ransomware einschleusen und verteilen lassen.

  7. Keine systemweite Einbindung von Scripts, die auf anderen Websites gehostet sind. Diese können dort gehackt werden und können damit (falls keine Subresource Integrity definiert wurde) vorhandene Webanwendungen mißbrauchen.

3. Ausdifferenzierte Zugriffsrechte

  1. Beliebig feine Zugriffskonzepte: Eine Datenbank kann viele Tabellen und viele Ausgabeseiten haben. Nutzer werden Gruppen zugeordnet. Jeder Gruppe können Lese-, Schreib- und Ausführungsrechte (für Abfragen und Seiten) zugeordnet werden. Wurde die Berechtigung nicht erteilt, wird bereits der Zugriff auf die Tabelle oder Ausgabeseite verweigert.

    Nutzer können über ihre Gruppenmitgliedschaft auf alle Zeilen einer Tabelle, nur auf die selbst erstellten Zeilen oder nur auf die Zeilen zugreifen, die von einer Gruppe erstellt wurde. Letzteres wird bsp. so verwendet, daß der Admin eines Unternehmens Müller-GmbH (Kunde eines Server-Daten-Kunden) den Account Müller-GmbH:admin erhält. Er kann weitere Nutzer (seine Mitarbeiter Schmidt und Maier) zulassen. Diese erhalten die Nutzernamen Müller-GmbH:Schmidt bzw. Müller-GmbH:Maier. Alle drei Nutzer können alle Datensätze sehen und bearbeiten, die von diesen drei Nutzern erzeugt wurden.

  2. Ferner gibt es die Möglichkeit, Nutzern zwar theoretisch den Zugriff auf eine gesamte Tabelle zu erlauben. Praktisch kann der Nutzer aber nur jene Datensätze sehen / editieren, die Sonderbedingungen erfüllen. Das deckt jene Fälle ab, bei denen die globalen Berechtigungen nicht ausreichen.

    Nutzer können auch nur Lesezugriffe haben. Wobei sich die Daten aus Abfragen ergeben, also beliebig aus vorhandenen Tabellen kombiniert werden können.

  3. Wenn eine Web-Datenbank sowohl von internen Mitarbeitern als auch Kunden dieses Server-Daten-Kunden genutzt werden, sind in den Seiten für die externen Nutzer (alle mit eigenem Login) in der Regel diverse Spalten unsichtbar. Diese externen Nutzer sehen diese Daten nicht. Auch nicht beim Blick in den Quellcode. Die Daten werden nicht in den Seiten mitgeliefert. Selbst wenn sie die Feldnamen wüßten (interner Mitarbeiter scheidet aus und wird Mitarbeiter eines externen Nutzers), würde ein Mitsenden dieses Inhalts nicht dazu führen, daß auf diesem Weg Daten geändert werden könnten.

  4. Zwar nicht direkt ein Sicherheitskonzept, aber wesentlich bei der Verwaltung der Daten: Aktionen mit den Daten (Statusänderung) können Mails (bsp. an eigene Kunden) auslösen. "Der Vertrag wurde bearbeitet". Ferner kann der Status von Daten abgefragt und nächtlich eine Mail für bestimmte Fälle verschickt werden: "In drei Wochen endet die Bescheinigung ..., bitte erneuern". Damit können Termine automatisiert überwacht werden.
All diese Features existieren "per Design". So daß beim Einrichten von Kundendatenbanken das Risiko von Fehlern minimiert wird.

4. Konfigurieren statt programmieren

  1. Das Gesamtsystem Server-Daten bietet nur bestimmte Stellen, wo etwas in einer Datenbank eingerichtet werden kann:
    • Es können Tabellen deklariert und diese miteinander verknüpft werden
    • Es lassen sich Sql-Abfragen erstellen
    • Es können Ausgabeseiten mit zusätzlichen sd-Elementen erstellt werden
    • Es können Gruppen erstellt und diesen Berechtigungen zugewiesen werden
  2. Jede Aktion auf dieser Ebene sorgt dafür, daß im Hintergrundsystem zusätzlicher Code ausgeführt wird, so daß bsp. die Tabelle, Verknüpfung und Abfrage tatsächlich erstellt wird. Oder daß beim Aufruf der mit sd-Elementen definierten Seite die Seite aufgerufen und die sd-Elemente gemäß ihrer Definition verarbeitet und durch Inhalte der aktuellen Sitzung oder Inhalte der Datenbank ersetzt werden.

    Dieser Hintergrundcode des Gesamtsystems wurde zwischen 2003 - 2005 entwickelt und wird seither immer wieder ergänzt. Damit gilt:

    • Die Bereitstellung kann sehr schnell erfolgen.
    • Kunden nutzen Code, der bereits seit Jahren bei anderen Kunden fehlerfrei läuft.
    • Bei einem solchen Konfigurieren sind diverse Fehler nicht mehr möglich (bsp. nicht endende Schleifen), die bei einer typischen Individualprogrammierung auftreten können.
  3. Damit ist es möglich, mit speziellen Sql-Abfragen die vorhandenen Daten praktisch beliebig zu aggregieren und auszuwerten. Das Ergebnis kann in Tabellenform oder als Grafik ausgegeben werden.

    Gleichzeitig erfordert die Nutzung solcher Werkzeuge Kenntnisse, die oberhalb einer typischen Baukastenlösung liegen, innerhalb derer sich Kunden Datenbanken autonom einrichten. Deshalb meist die Einrichtung der Datenbank durch Server-Daten.

    Ähnliches gilt für Ausgabeseiten: Da die Ausgabeseiten aus Html + sd-Elementen bestehen, ist alles, was per Html geht, auch in einer Ausgabeseite möglich. Gleichzeitig bedeutet das, daß eine zu einer Tabelle neu hinzugefügte Spalte

    • in der Ausgabeseite unsichtbar durchgeschleift wird,
    • in der Ausgabeseite schreibgeschützt angezeigt wird,
    • in der Ausgabeseite einmalig eingegeben, dann schreibgeschützt angezeigt wird,
    • in der Ausgabeseite editierbar angezeigt wird,
    • oben als Teil eines Eingabeformulars oder unten in einer Excel-artigen Liste editiert werden kann,
    • falls sichtbar, an beliebigen Stellen postiert werden kann.
    Wird dieselbe Tabelle in mehreren Ausgabeseiten genutzt (Geschäftsleitung, Mitarbeiter, externe Geschäftsleitung, externe Mitarbeiter, Ansicht für nicht registrierte Nutzer), kann das in jeder Seite anders sein. Aufgrund der zu vielen Möglichkeiten ist das nicht mehr automatisch möglich, sondern erfordert eine manuelle Gestaltung der Ausgabeseiten.
  4. Deshalb können Datenbanken auch für sehr unterschiedliche Zwecke gleichzeitig genutzt werden: Eine interne Auftragsverwaltung, ein Blog, eine Website. Eigene Kunden können als Nutzer zu einer Datenbank zugelassen werden oder registrieren sich selbst und geben Aufträge intern auf.

    Die gemeinsame Basis sind immer mehrere, miteinander verknüpfte Tabellen, Ermittlung zusätzlicher Informationen durch Abfragen und sehr flexible Ausgabeseiten, die auf gecachte Werte zu diesem Nutzer oder auf das Ergebnis von Abfragen reagieren.



Kontaktformular:

Schreiben Sie mir und wir bauen gemeinsam Ihre neue Web-Datenbank!

Die Erläuterungen zum Datenschutz habe ich gelesen und stimme diesen zu.

© 2003-2018 Jürgen Auer, Berlin.