Konzepte und Merkmale des Projekts server-daten

• » Home
• »Server-Daten
• » Konzepte

Server-daten ermöglicht Kunden die Nutzung einer eigenen Web-Datenbank auf der Basis einer monatlichen Miete. Bei der Registrierung ist ein noch freier Datenbank-Name zu wählen, zu diesem wird eine Subdomain (datenbank-name.server-daten.de) eingerichtet. Nach der Registrierung und Freischaltung kann die Datenbank zunächst maximal 30 Tage kostenfrei verwendet werden. Anschließend ist entweder die erste Mietzahlung für den folgenden Monat fällig oder die Datenbank wird gesperrt und später gelöscht.

Der Datenbankserver, ein Microsoft Sql-Server (Sql216-Standardlizenz), läuft im Hintergrund auf eigener Hardware und wird durch einen Webserver abgeschottet, welcher die Anwendungslogik bereitstellt. Die Prozessor-Lizenz gestattet den gleichzeitigen Zugriff von beliebig vielen Nutzern. Das interne Netz ist durch eine eigenständige Hardware-Firewall gegen Angriffe von außen abgeschirmt und läßt nur die Kommunikation über den Http-Port 80 sowie - von innen nach außen - für den Mail-Dienst zu. Die Verwaltung durch den Kunden erfolgt durch Standard-Browser. Zur Nutzung der internen Menüs muß JavaScript aktiviert sein.

Ein kleines Beispiel ist unter beispiel.server-daten.de zugänglich. Falls Sie sich dort mit Mailadresse und Nick anmelden, können Sie den Code der Ausgabeseiten direkt lesen.

Leitüberlegung

Dem Angebot liegt der folgende Gedanke zugrunde: Eine kleine / mittlere Firma verwendet lokal eine Datenbank, welche von mehreren Personen genutzt wird. Nun sollen Teile auf der Homepage eingebunden werden und ein Kontakt zu Kunden herstellbar sein. Es gibt drei Möglichkeiten:

1. Eine Datenbank wird lokal betrieben, Kunden senden über ein Kontaktformular oder über eine kleine Web-Datenbank (meist PHP + mySql) Mails, die manuell weiterverarbeitet, also doppelt eingegeben werden. Ebenso müssen lokale Daten manuell auf der Website oder in die Web-Datenbank nachgetragen, also ebenfalls doppelt verarbeitet werden.
2. Lokal werden sowohl eine Datenbank als auch Webserver + Standleitung betrieben. Dies erfordert Personal / Sachmittel und überfordert die meisten kleinen / mittleren Unternehmen.
3. Es wird nur eine einzige Web-Datenbank genutzt. Diese stellt die gewünschte Funktionalität bereit.

server-daten bietet für die dritte Variante keine Individualprogrammierung, da diese ebenfalls oberhalb üblicher Budgets liegen würde. Stattdessen wird eine modulare Lösung angeboten, die von vielen Kunden gemeinsam genutzt wird. Erst bei solchen hinreichend großen Datenbank-Systemen ist der Einsatz entsprechender Soft- und Hardware (MS-SqlServer Enterprise, Raid-V) sinnvoll, so daß anstelle der lokalen Standardcomputer nun eine hinreichend sichere Server-Lösung zur Verfügung steht.

Als Datenbank-Software wird keine Eigenentwicklung ohne Transaktionssicherheit, sondern ein ausgereiftes, transaktionssicheres Produkt (MS-SqlServer) verwendet. Wichtige Daten gehören nicht in ein von einer oder wenigen Personen entwickeltes Datenbank-Backend, auch wenn eine solche Web-Datenbank zu weitaus geringeren Kosten angeboten wird. Bei einem solchen, nicht transaktionssicheren Angebot muß im Fehlerfall auf die letzte Sicherung zurückgegriffen werden, so daß alle seither eingegebenen Daten verloren sind. Da diese bei Kundenanmeldungen nicht mehr zur Verfügung stehen, warten die Kunden vergeblich.

1. Grundlagen

Die Verwaltung und Nutzung der Datenbank erfolgt zunächst über die internen Menüs, welche über http://datenbank-name.server-daten.de/admin/ erreichbar sind. Hier können mehrere Tabellen, Verknüpfungen zwischen Tabellen, einige weitere Objekte, Nutzer und ihre Berechtigungen eingerichtet werden. Es stehen Upload- und Download-Möglichkeiten zur Verfügung.

2. Dateneingabe, die Trennung zwischen interner Speicherung und Ausgabeformat

Inhalte von Tabellenspalten sind durch Datentypen (Text, Ganzzahl, Dezimalzahl, Datum usw.) eingeschränkt. Zusätzlich können NotNull- sowie, für Textspalten, Einschränkungen mit Regular Expressions erfolgen. Wird ein eingegebener Datensatz aufgrund einer Einschränkung zurückgewiesen, so zeigt das hiesige System die Daten erneut an und ermöglicht eine Eingabe. Dies stellt einen Unterschied zu anderen Web-Datenbanken dar. Das System unterstützt Unicode, so daß Tabellen- und Spaltennamen und Texte in verschiedenen Sprachen bzw. die Verwendung von Unicode-Sonderzeichen möglich sind, ohne daß diese mit Entities codiert werden müssen. Die Sortierung ist standardmäßig binär. 'Artikel' und 'artikel' sind verschiedene Tabellen. Für Textspalten kann die Sortierung und Filterung durch zusätzliche Kriterien (Groß/Klein, Akzent u.ä.) geändert werden. Datums- und Zahlformate werden intern immer in ihren Originalformaten gespeichert, es erfolgt keine Reduktion auf eine Text- oder eine verkürzte Darstellung (nur Speicherung des Monats). Die Form der Darstellung (Monat/Tag/Jahr versus Tag.Monat.Jahr) hängt innerhalb der internen Masken von der Browsereinstellung des Lesers ab. Für individuell erstellte Ausgabeseiten (s.u.) kann die Darstellung jeweils einzeln festgelegt werden.

3. Verknüpfungen zwischen Tabellen

Eine Datenbank bei server-daten kann, im Gegensatz zu einigen anderen Webdatenbank-Systemen, mehrere Tabellen umfassen. Dies ermöglicht die Berücksichtigung der drei Normalformen, so daß die Daten auf eine geeignete Zahl von Tabellen aufgeteilt und redundanzfrei abgelegt werden können. Ein Problem bei dieser Aufteilung besteht darin, daß die Verknüpfungen zwischen den Tabellen nur durch Zahlcodierungen erzeugt werden, die Daten für den späteren Gebrauch jedoch wieder in ihrer Klartext-Darstellung benötigt werden. Deshalb gestattet server-daten das Erstellen von Verknüpfungen zwischen Grund- und Detailtabellen, wobei zu jeder Verknüpfung die gewünschte Darstellung aus Spalten der Grundtabelle zusätzlich angegeben werden muß und bis zu zwei Sortierungen optional sind. Hieraus werden im Hintergrund passende Pulldown-Listen erzeugt, welche den gewünschten Ausdruck anzeigen, intern jedoch nur die Zahlcodierung verwenden. Zusätzlich kann durch diese Listen mittels einfacher Links geblättert oder die Liste durch einen Ausdruck gefiltert werden. Damit sind auch Grundtabellen mit mehreren tausend Einträgen problemlos in Verknüpfungen nutzbar.

Beispiel: Eine Personen-Grundtabelle mit Nachname, Vorname und Eintrittsdatum, eine Detailtabelle mit Aktivitäten dieser Personen. Als Ausdruck wird

Nachname + ', ' + Vorname

definiert, als Sortierung das Eintrittsdatum absteigend genutzt. Alle in Sql-Abfragen (s.u.) zusätzlich nutzbaren MS-SqlServer-Funktionen können auch hier verwendet werden, so daß der obige Ausdruck auch bei fehlendem Vornamen korrekt dargestellt wird:

Nachname + CoalEsce(', ' + Vorname, '')

4. Zwei Sonderformen: Kurz-Relationen und BitSet-Tabellen

Werden für eine Relation nur wenige Klassifikationen benötigt (Anrede Firma/männlich/weiblich), so daß sich die Erstellung einer eigenen Grundtabelle nicht lohnt, kann stattdessen eine Kurzform genutzt werden. Der Detailspalte wird der Datentyp Integer zugewiesen, ein ergänzendes Feld wird mit der Zeichenfolge

1;Firma;2;männlich;3;weiblich

belegt. Das Ergebnis ist eine Pulldown-Liste der folgenden Gestalt:

Firmamännlichweiblich

Intern werden die angegebenen Zahlen als Wert für die Zellen verwendet.

Eine zweite Sonderform besteht darin, daß eine Spalte mehrere Ja/Nein-Werte zusammenfassen soll. Man betrachte die folgende Darstellung:

Der Leser soll keine, eine oder mehrere Möglichkeiten anhaken können, es ist jedoch nicht gewünscht, hierfür vier Spalten vom Datentyp Bit/Ja-Nein zu erstellen. Stattdessen sollen die Werte komprimiert in einer Spalte abgelegt werden. Dieser Spalte wird der server-daten-Datentyp bitSet zugeordnet, intern als Integer implementiert. Ferner muß eine Tabelle mit der Markierung als Bittabelle mit einer einzigen Spalte erstellt werden, deren bis zu 30 Zeilen die Einträge deutsch/englisch usw. erhalten. Anschließend genügt es, eine übliche Relation von der bitSet-Spalte auf die bitSet-Tabelle zu erstellen. Die Hintergrundlogik erstellt die Einträge in der BitSet-Tabelle mit Primärschlüsseln, die Potenzen von 2 darstellen und faßt die angehakten Werte als Summe bzw. logisches Or in einem Ausdruck zusammen.

5. Kreuzsuche und Sortierung auf allen Eingabemasken

Eine Tabelle mit mehreren hundert Einträgen kann rasch unübersichtlich werden. Die beste Datenbank wird wertlos, falls Daten nicht mehr zu finden sind. Um diesem Problem entgegenzuwirken, ist auf fast allen Eingabemasken standardisiert eine Kreuzsuche mit der Möglichkeit einer Spaltensortierung implementiert. Werden in der Eingabemaske einzelne Felder belegt oder wird aus einer Pulldown-Liste ein Wert gewählt und anschließend gesucht, so werden die eingegeben Werte als AND-Filter genutzt: 'Suche nach allen Personen, deren Nachname mit "T" beginnt und vom Typ "Mitarbeiter" sind'. Die Ausgabe erfolgt als View, so daß zunächst eine Liste mit der ersten Tabellenspalte ausgegeben wird. Es können weitere eigene Views erstellt werden, hier variiert die Zahl der Ausgabespalten und ihre Reihenfolge. Ferner können die Listen durch Sortierpfeile nach jeder Spalte in beide Richtungen sortiert werden. Sucht man bsp. nach den zuletzt hinzugefügten Mitarbeitern mit 'M', so genügt es, diese Ausgabe nach der standardmäßig eingefügten Id-Spalte abwärts zu sortieren. Diese Sortierung über alle Spalten ermöglicht eine 'unscharfe Suche': Von einem Datensatz sind Bruchstücke bekannt: 'weiblich', 'Mitarbeiter', Vorname am Ende des Alphabets. Nun werden die beiden ersten Kriterien als Filter gesetzt, die Daten nach dem Vornamen absteigend sortiert und die verbleibende, sehr viel kleinere Liste durchgeblättert. Diese Technik steht sowohl bei benutzerdefinierten Tabellen als auch für die meisten Systemobjekte zur Verfügung, die Ausnahmen beziehen sich auf Unterobjekte (Tabellenspalten innerhalb von Tabellen sind immer nach der Spaltennummer sortiert) und Einschränkungen aus Sicherheitsgründen (Passwortfelder werden bei der Suche nicht berücksichtigt).

Bei benutzerdefinierten Tabellen kann zwischen den verschiedenen, für diese Tabelle erstellten Views gewechselt werden. Der Name des zuletzt verwendeten Views wird gecacht und steht beim nächsten Aufruf diesem Nutzer wieder zur Verfügung. Bei der Sortierung nach Spalten, die als Detailspalten von Relationen definiert sind, werden nicht die internen Nummern, sondern die gewünschten Ausdrücke aus der Primärspalte berücksichtigt.

6. Länderverzweigungen / Multilang-Spalten

Ein regelmäßiges Problem bei der Nutzung von Datenbanken besteht darin, daß die meisten Spalten einer Tabelle für alle Nutzer gültig sind, für wenige Spalten die Informationen jedoch in verschiedenen Sprachen bereitgestellt werden sollen. Man denke an eine Tabelle zu Vorträgen: Datum, Raum und Dozent sind einheitlich, Vortragstitel und -beschreibung sollen deutschen Lesern deutsch, englischen und anderen Lesern englisch ausgegeben werden. Theoretisch ist hier entweder die Erstellung zusätzlicher Spalten sowie die Filterung nach Spalten oder die Erstellung von zusätzlichen Tabellen mit automatisierter LeftJoin-Verknüpfung sowie der Ausgabe des möglichst spezifischen, nicht leeren Wertes notwendig. Tatsächlich kapselt server-daten die zweite Logik, so daß ein Kunde bsp. in der Grundtabelle zwei Spalten 'title' und 'description' hinzufügt, in diese die englischen Daten einträgt und zusätzlich zwei Multilang-Spalten 'title-de' und 'description-de' im Menü 2 erstellt. Werden über dieses Menü die Spalten mit Werten gefüllt, so erhalten Leser mit Browsereinstellung 'de', 'de-DE', 'de-AU', 'de-CH' usw. die deutschen Texte, allen anderen Lesern wird die englische Version ausgegeben. Dies wird auch berücksichtigt, falls die Spalten 'title'/'description' in Relationen verwendet werden oder falls nach diesen Spalten sortiert wird.

7. Sql-Abfragen

Ein weiteres Problem bei hinreichend großen Datenmengen besteht darin, daß es nicht genügt, Daten nur zu filtern und zu sortieren, um sie bearbeiten zu können. Die Daten sollen auswertbar und aggregierbar sein, es soll möglich sein, sie zu wenigen Kennziffern zusammenzufassen. Hierfür hat sich die Erstellung von aggregierenden Abfragen mittels Sql als Standard entwickelt. Innerhalb von server-daten können solche weitergehenden Abfragen individuell erstellt und ausgeführt werden. Neben den Standard-Sql-Befehlen lassen sich über 70 der innerhalb des MS-SqlServers definierten Funktionen und Operatoren verwenden, so daß bsp. täglich angefallene Daten mittels der Year- und der Month-Funktion nach Monaten gruppiert werden können. Abfragen dürfen zusätzlich Parameter erhalten, die erst zur Ausführungszeit mit geeigneten Werten belegt werden. Deren Belegung kann sowohl innerhalb der internen Masken als auch innerhalb von Ausgabeseiten erfolgen, entweder in Form von unsichtbar vorbelegten Werten oder aufgrund einer Nutzereingabe.

8. Ausgabeseiten

Alle Funktionen können mit den internen Masken genutzt werden. Für die Verwaltung einer kleinen Firma, welche die Vorzüge eines MS-SqlServers auf einem Raid-System nutzen möchte und nur eigene Mitarbeiter als Nutzer zuläßt, genügt diese Logik. Zusätzlich können die Daten jedoch auf normalen Html-Seiten ausgegeben werden. Hierzu lassen sich Ausgabeseiten erstellen, welche unter

http://datenbank-name.server-daten.de/Ausgabeseite.html

aufrufbar sind und in üblicher Weise von anderen Seiten her verlinkt werden. Diese geben den Inhalt von Tabellen mittels Views oder Abfragen aus, stellen Masken zur Suche oder Datenbearbeitung bereit oder ermöglichen die Neuanmeldung weiterer Nutzer per Mail/Nickname, einige grundlegende Sicherheitsfunktionen (neues Passwort, Passwort ändern) oder ein Login. Diese Ausgabeseiten sind zunächst gewöhnliche Html-Seiten und enthalten zusätzlich mehrere der über 70 Ausgabeseiten / sd-Elemente . Bei der späteren Ausgabe werden die sd-Elemente durch Inhalte der Datenbank ersetzt oder fügen zusätzliche Logik in Abhängigkeit von der zuletzt ausgeführten Aktion ein. Da sd-Elemente selbst wiederum Html-Elemente enthalten können und diese Struktur beim Erzeugen der Seite rekursiv aufgelöst wird, lassen sich die Inhalte der Datenbank in praktisch jede beliebige Html-Darstellung einbetten. Dasselbe gilt für die Buttons und Verweise zum Blättern durch die Ergebnisse. Diese stehen, eingefaßt in Containerelementen, elementar zur Verfügung und erlauben die Verwendung von Texten, Unicode-Zeichen oder eigenen Grafiken. Wird eine solche Seite per iFrame-Element in eine bereits bestehende Firmenpräsenz eingebunden, so kann ihr Design der Umgebung angepaßt werden.

9. Upload/Download von Daten

Die Definition eines Datenuploads oder Downloads wird als Eintrag in einer Systemtabelle aufgezeichnet. Damit lassen sich Up/Downloads wiederholt verwenden und über die Sicherheit verwalten, ohne die Metadaten jedesmal neu einzugeben. Eine Ausnahme stellt der lokale Pfad zur Datei beim Upload dar: Browser verweigern die Vorbelegung aus Sicherheitsgründen, so daß hierfür keine Automatisierung möglich ist.

Beim Upload werden OleDB/ODBC und das interne Bulk Insert bzw. bcp kombiniert. ODBC erlaubt die Berücksichtigung vielfacher Formatangaben, so daß Legacy-Daten aus älteren Datenbank-Systemen übernommen werden können. Das Altsystem muß lediglich in der Lage sein, die eigenen Tabellen als Text mit Trennzeichen zu exportieren. Die Optionen orientieren sich an den kulturabhängigen Einträgen in der Systemsteuerung - Dezimaltrennzeichen (Komma oder Punkt), Währungszeichen vor / nach der Zahl, Festlegung des Währungszeichens (Euro versus DM). Allerdings unterstützt ODBC als altes Format nicht ausreichend Unicode, sondern erlaubt offiziell nur den Import von Ansi/OEM. Es können jedoch einzelne Spalten für den Unicode-Upload markiert werden. Diese werden intern vom ODBC-Import ignoriert und mittels einer Bulk-Insert-Anweisung sowie einer Formatdatei, welche das Überspringen der anderen Zeilen erzwingt, in eine Hilfstabelle eingelesen und mit den Restdaten gematcht.

Für den Download können mehrere Tabellen unter einem Namen zusammengefaßt und gemeinsam als ZIP-Archiv downgeloadet werden. Eine Wahl zwischen Textdateien analog zum Upload, einer Access-Datenbank oder einem Standard-NET-DataSet ist möglich. Damit lassen sich bsp. offline Word-Serienbriefe basierend auf Adressdaten erstellen, indem nur wenige Tabellen unmittelbar vor der Nutzung downgeloadet werden und als Access-Datenquelle zur Verfügung stehen.

Bei der Ausführung eines Up/Downloads wird geprüft, ob der Besitzer dieses Objektes Lese- bzw. Schreibzugriff auf die gewünschten Tabellen besitzt, ansonsten wird die Aktion abgebrochen. Damit kann ein Administrator bsp. einen Download einrichten und einem Nutzer die Ausführungsberechtigung für diesen erteilen, ohne daß der Nutzer selbst Downloads erstellen darf.

10. Mailbenachrichtung bei Datenänderungen und zur Wiedervorlage

Zu benutzerdefinierten Tabellen und zu Änderungen an den Systemobjekten können Aktionen definiert werden. Diese versenden eine Mail an den Besitzer (= Ersteller) der Aktion, falls in der Tabelle Daten geändert oder ein Systemobjekt erstellt wurde. Dies gilt auch für das Erstellen von Tabellen und sämtlichen weiteren Objekten sowie bei der Neuanmeldung von Nutzern. Aktionen können nicht an andere Nutzer weitergereicht werden, indem diesen die Execute-Berechtigung für die Aktion erteilt wird. Dies verhindert, daß ein Nutzer in böswilliger Absicht eine Aktion für eine Tabelle mit häufigen Änderungen erstellt, einem anderen Nutzer die Ausführungsberechtigung hieran erteilt und der andere Nutzer ständig Mails erhält, ohne die Execute-Berechtigung entfernen oder die Aktion löschen zu können.

Eine zweite Variante ermöglicht das Erstellen von Wiedervorlagen als Benachrichtungen. Hier kann eine Datumsspalte mit DateAdd-Funktionen verknüpft werden, deren Wert auch 0 sein kann. Fällt das in dieser Spalte definierte Datum plus die gewünschte Zeitdifferenz auf den heutigen Tag, so wird eine Mail verschickt. Ein Datensatz mit Datum 01.06.2006 kann bsp. eine Mail für denselben Tag, für den 05.09.2006 (drei Monate plus fünf Tage) oder für den 20.04.2006 erzeugen (zwei Monate zurück und 20 Tage weiter).

11. Nutzertypen

Das System kennt vier verschiedene Nutzertypen: Zunächst gibt es den einzigen vordefinierten Systemnutzer admin, der Mitglied der admin-group ist und sämtliche Aktionen ausführen kann. Dieser kann weitere authorized user (mit Mail und Nicknamen) erstellen, sie in Gruppen ordnen und Gruppen Berechtigungssätze zuweisen. Ferner gibt es zwei weitere Nutzertypen: anonymous User with Nick benötigen für eine Erstanmeldung eine Mailadresse und einen Nicknamen, anonymous User benötigen nur eine Mailadresse. Falls externe Nutzer lediglich die Befugnis haben sollen, Daten einzutragen und nicht untereinander kommunizieren, genügt die Anmeldung und Identifikation mit Mail. Ist es erwünscht, daß Nutzer auf Ausgabeseiten sich auf andere Nutzer beziehen, so soll im Regelfall die Mailadresse nicht sichtbar sein. Hier kann die Version mit Nick genutzt werden. Diese beiden Nutzertypen können sich nur selbst an einer Datenbank anmelden. Es stehen vordefinierte Ausgabeseiten zur Verfügung, welche die benötigten sd-Elemente automatisch erzeugen, um beiden Nutzertypen eine Erstanmeldung und ein Login zu gestatten.

12. Mail- und Passwortverwaltung

Jeder Nutzer benötigt für seine Anmeldung eine gültige Mailadresse. Entweder meldet sich der Nutzer selbst als anonymer Nutzer bzw. als anonymer Nutzer mit Nick an oder er teilt die Mailadresse dem Administrator mit, welcher daraufhin einen neuen Nutzer erstellt. An diese Mailadresse wird das Initialpasswort versandt. Für den Administrator gibt es keine Möglichkeit, für einen anderen Nutzer ein Passwort einzutragen oder zu ändern. Diese Einstellung ist nicht optional, sondern verbindlich für alle Kunden und Systemnutzer. Sie schützt den Administrator innerhalb gewisser Grenzen vor Situationen des Social Engineering. Dies sind Versuche, ihn zu einer kurzfristigen Änderung eines Passworts sowie der telefonischen Weitergabe dieses Passworts an eine andere Person zu bewegen mit der Begründung, es müssten dringend Wartungsarbeiten oder ähnliches durchgeführt werden. Jeder Nutzer kann sein eigenes Passwort und seine Mailadresse später ändern, dies allerdings niemals gleichzeitig, sondern immer nur entweder Passwort oder Mail. An jede neue Mailadresse wird zunächst ein Schlüssel versandt, der innerhalb von 24 Stunden zu bestätigen ist. Erst nach dieser Bestätigung wird die neue Mailadresse verwendet.

Passwörter müssen mindestens 10 Zeichen umfassen, mindestens zwei Zeichen aus der Menge

!§$&/= +*#-_.:,;|

enthalten und sich hinreichend stark vom Nutzernamen unterscheiden. Der Unterschied zwischen Nutzername und Passwort wird mittels der SoundEx-Funktion geprüft. Das zufällig generierte Passwort enthält unter Umständen nicht zwei der bei der interaktiven Prüfung geforderten Sonderzeichen.

Aus der obigen Logik ergibt sich, daß ein Administrator zwar in böswilliger Absicht einem Nutzer eine andere Mailadresse aus dem Besitz dieses Administrators zuordnen, sich ein neues Passwort erzeugen und an die neue Mailadresse senden, um sich anschließend als dieser Nutzer anmelden und böswillige Aktionen durchführen kann. Er kann anschließend jedoch die Mailzuordnung nicht wieder auf den ursprünglichen Besitzer ohne dessen Einwilligung zurücktransferieren, ebenso kann er nicht mehr das Passwort auf den alten Stand zurücksetzen.

Ein Nutzer kann seinen eigenen Account jederzeit bis zu einem bestimmten Datum sperren. Er erhält daraufhin zwei Schlüssel per Mail zugesandt. Der erste Schlüssel aktiviert die Sperre endgültig und stellt implizit eine Überprüfung der Mail dar. Die Sperre gilt entweder während des gesamten festgelegten Zeitraums oder kann mit dem zweiten Schlüssel aufgehoben werden. Jeder Nutzer kann nur für sich selbst eine solche Urlaubssperre festlegen, ein Administrator kann weder eine solche Sperre für einen anderen Nutzer erzeugen noch aufheben. Der Administrator kann jedoch - unabhängig von diesem Mechanismus - Accounts direkt sperren, so daß deren Login scheitert.

13. Konsequenzen angesichts der Phishing-Problematik:

Unter Phishing werden Formen des Trickbetrugs verstanden, das gutgläubige Opfer dazu zu verleiten, eigene sensible Daten wie Passwörter an die Täter weiterzugeben, um diesen Aktivitäten anstelle ihrer Opfer zu erlauben. Dieser Betrug nutzt meistens Mails mit eingebetteten Links, die bsp. wie folgt aussehen können:

http://www.server-daten.de/check-your-account/?
	id=E94F0822-0FDC-4BBD-A725-0C25661E7683

Der Link führt jedoch in Wirklichkeit nicht auf einen Server von server-daten.de bzw. von sql-und-xml.de, sondern auf eine andere Domain.

Zur Vorbeugung gegen Phishing-Manipulationen nutzt das hiesige System folgende Prinzipien:

• Es werden drei Typen von Mails versandt:
  • Mails mit Initialisierungspasswörtern, welche innerhalb von 24 Stunden durch eine Anmeldung bestätigt werden müssen oder verfallen. Die Anmeldung kann für Nutzer mit der Berechtigung, auf die internen Masken zuzugreifen, unter

    http://datenbank-name.server-daten.de/admin/

    erfolgen. Für Nutzer ohne diese Berechtigung kann eine passende Ausgabeseite erstellt und auf der zur Anmeldung dienenden Seite verlinkt werden.
  • Mails mit zufällig generierten Einmalschlüsseln zur Bestätigung einer neuen Mail oder zur Administration einer Urlaubssperre. Als Einmalschlüssel werden jene aus der Windows-Welt bekannten Ausdrücke verwendet, welche durch Aufruf der GUID.NewGUID() erzeugt werden.
  • Mails als das Ergebnis von Aktionen mit Daten. Diese Mails dienen nur zur Information und erfordern keine Reaktion.
• Es wird niemals eine Mail mit einem Benutzernamen oder einem Link versandt. Jede Mail mit Link stammt nicht von server-daten. Alle Informationen sind unter https://www.sql-und-xml.de/server-daten/ zu finden.
• Das Formular zur Bestätigung von Einmalschlüsseln ist für alle Kunden ausschließlich unter

  		http://www.server-daten.de/confirm/
  		

  zu finden. Dieses Formular akzeptiert keine GET-Daten, ein Aufruf der Form

  http://www.server-daten.de/confirm/?
  	id=E94F0822-0FDC-4BBD-A725-0C25661E7683

  führt immer zum Verwerfen der übergebenen ID.

  Statt 'www' kann auch der Name einer Kundendatenbank genutzt werden. Das Formular bzw. der dahinter liegende Code ist in jedem Fall derselbe.

14. Ausdifferenzierte Rechte mittels Berechtigungssätzen, die Unterscheidung Admin/StvAdmin

Manche Datenbanksysteme kennen nur geringfügig ausdifferenzierte Rechte, bsp. Lesen/Schreiben/Administrieren in bezug auf Tabellen sowie globale Administratorrechte für alle sonstigen Aufgaben. Innerhalb des hiesigen Systems können Rechte durch das Erstellen von Berechtigungssätzen im Menü 16 global, bezogen auf einen Objekttyp (Tabellen, Multilang-Spalten, Abfragen usw.) oder bezogen auf ein Objekt (konkrete Tabelle, Abfrage usw.) an Gruppen vergeben werden. Als Rechtestufen stehen neben Lesen / Hinzufügen / Ändern / Löschen / StvAdmin / Admin für Tabellenzeilen und Objekte auch das Recht zur Administration eigener Objekte zur Verfügung. Dies ermöglicht es, einzelnen Nutzern keine globalen Rechte für einen Objekttyp erteilen zu müssen, sondern ihnen lediglich das Recht zur Erstellung eigener Objekte sowie deren Verwaltung einzuräumen.

Ferner kennt das hiesige System eine Besonderheit, den Unterschied zwischen Admin und seinem Stellvertreter. Üblicherweise haben Mitglieder der obersten Rechteebene im Verhältnis zueinander dieselben Rechte. Dieses Prinzip führt zu Problemen, falls bsp. im Rahmen einer Urlaubsvertretung jemand zum Administrator hochgestuft wird, um während der Urlaubszeit des Administrators Rechte verwalten zu können. Unterläuft ihm ein Fehler oder verhält er sich böswillig, so kann er den anderen Administrator herabstufen, obwohl ihm dieser das hierfür notwendige Recht erst verliehen hat. Der ursprüngliche Administrator kann diese Situation vermeiden, indem er den Mitarbeiter lediglich als stellvertretenden Admin (StvAdmin) einsetzt. Ein StvAdmin kann alle administrativen Tätigkeiten durchführen - mit einer Ausnahme: Er kann nicht die Berechtigung eines Admins ändern oder sich selbst zum Administrator hochstufen, er kann also beim Bearbeiten eines Berechtigungssatzes das Admin-Flag nicht ändern.

15. Protokollierung aller Schreibzugriffe

Datenbanksysteme, welche in geschlossenen Firmennetzwerken verwendet werden, sind zwar meist gut abgeschirmt gegen mögliche Angriffe von außen. Werden die Daten für Präsentationen im Web benötigt, so nutzen manche Systeme eine Push-Technik, welche die Daten regelmäßig auf den Webserver exportiert. Solche Techniken schützen zwar hinreichend sicher gegen Angriffe von außen. Sie lassen dabei jedoch außer acht, daß die meisten Angriffe gegen Datenbanksysteme von internen Nutzern erfolgen, Schätzungen vermuten, daß dies für 60% - 80% der Angriffe gilt. Das hiesige System erreicht einerseits mit dem Zwei-Server-System in Kombination mit der Firewall sowie dem Schutz gegen Sql-Injektionen ein hinreichendes Sicherheitsniveau gegen Angriffe von außen. Intern wird ein gewisser Schutz gegen Manipulationen dadurch erreicht, daß alle Schreibzugriffe automatisiert protokolliert und dieses Protokoll für jeden Nutzer der internen Masken sichtbar ist. Das Protokoll besteht aus der Id der aktuell bearbeiteten Tabelle, der Id des Datensatzes, einem eventuellen Verweis auf eine Multilang-Spalte, der Nutzer-Id sowie Datum und Uhrzeit des Schreibzugriffs. Diese Funktionalität ist nicht optional, sondern für alle Kunden dieses Systems verbindlich. Sie kann weder vom Administrator einer Datenbank (dem Kunden gegenüber server-daten) noch von server-daten mittels 'verborgener Parameter' (backdoors, Hintertüren) deaktiviert werden. Die einzigste Möglichkeit der Deaktivierung bestünde in der direkten Änderung des Quellcodes und dem Neuerstellen sämtlicher gespeicherter Prozeduren, über welche der Zugriff vom Webserver auf die Daten erfolgt. Eine solche Deaktivierung wird nicht durchgeführt.

Zu beachten ist hierbei folgendes: Erstellt ein Kunde eine Tabelle und trägt er in diese Daten seiner Geschäftsbeziehungen (Namen, Adressen, Telefonnummern) ein, so verarbeitet er personengebundene Daten seiner eigenen Kunden im Sinne des Bundesdatenschutzgesetzes (BDSG). Werden nur Artikel und Preise eingetragen, so sind dies keine 'personengebundenen Daten'. Das BDSG fordert, für personengebundene Daten 'zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, ob und von wem personenbezogenen Daten in Datenverarbeitungssysteme eingegeben, verändert oder entfernt worden sind' (Zitat Bundesdatenschutzgesetz in der Fassung vom 14.01.2003, Anlage zu § 9 Satz 1, BDSG). Das BDSG fordert also die Erstellung von Protokolldaten bei der Bearbeitung personengebundener Daten durch das verwendete Datenmanagementsystem. Für die Integrität und Konsistenz des hiesigen Systems ist es jedoch unerheblich, ob von Nutzern mit Schreibzugriff personengebundene oder nicht personengebundene Daten (Artikeldaten) manipuliert wurden. Der einzigste Schutz vor solchen Manipulationen durch zugelassene Nutzer besteht deshalb darin, kanonisch bei allen Datenänderungen Protokolleinträge zu erzeugen und diese nicht zu verbergen, sondern sie im Sinne einer maximalen Transparenz jedem internen Nutzer anzuzeigen. Jeder interne Nutzer, der Inkonsistenzen bei einem Datensatz beobachtet, kann feststellen, wer diesen Datensatz zuletzt bearbeitet hat. Bei diesen Protokolldaten handelt es sich um neue personengebundene Daten der Nutzer, welche im Rahmen der Systemnutzung kanonisch aufgezeichnet werden. Jeder interne Nutzer kann über das Menü 14 (Eigene Daten - Protokolldaten) sämtliche durch sein Tun erzeugten Protokolldaten einsehen und hierdurch bsp. rasch die zuletzt bearbeiteten Datensätze wiederfinden. Ferner können, in Abhängigkeit von den Anforderungen des Kunden, Berechtigungen zum Lesen der Protokolldaten quer über alle Tabellen und Datensätze durch einen anderen Nutzer erteilt werden. Falls ein Nutzer Daten gezielt manipuliert hat, sind die von ihm zuletzt bearbeiteten Datensätze damit einigermaßen rasch identifizierbar.

16. Die Architektur der Hardware

Das System läuft grundsätzlich auf zwei Servern. Der nach außen hin sichtbare und per Firewall abgeschottete Web-Server stellt Html-Ausgaben bereit und kommuniziert mit dem Datenbank-Server über eine schwache Verbindung, die keine administrativen Berechtigungen in der Datenbank besitzt. Sämtliche objektmanipulierenden Aktionen (Erstellen / Ändern von Tabellen usw.), für die administrative Rechte in der Datenbank notwendig sind, können vom Webserver her nur angestoßen, nicht jedoch Schritt für Schritt ausgeführt werden. Alle direkten Aktionen (Erstellen / Ändern von Daten) sind über gespeicherte Prozeduren implementiert, der Webserver darf lediglich Namen gespeicherter Prozeduren senden und erhält Statusmeldungen zurück. Er ist nicht berechtigt, Sql-Befehle direkt auszuführen. Als Hardware für die Datenbankserver werden RAID-5-Systeme eingesetzt. Dies schützt die Daten wesentlich besser gegen Hardware-Schäden der Festplatten im Vergleich zu gewöhnlichen PC-Festplatten. Das Grundsystem wird nicht selbst betrieben, sondern ist bei einem größeren Provider (www.hosteurope.de) angemietet. Die Server stehen in einem klimatisierten Rechenzentrum, welches gegen Zutritt Unbefugter, Brand und Stromausfall geschützt ist. Die Datenbanken werden nächtlich innerhalb des eigenen Systems gesichert und anschließend vom Backup des Providers auf einem anderen System für zwei Wochen gespeichert.