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:
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.
Lokal werden sowohl eine Datenbank als auch Webserver + Standleitung betrieben. Dies erfordert Personal / Sachmittel
und überfordert die meisten kleinen / mittleren Unternehmen.
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:
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:
Fremdsprachen:
deutsch
englisch
französisch
spanisch
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
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:
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
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.
Link zur hiesigen Seite als QR-Code
Kontaktformular:
Schreiben Sie mir und wir bauen gemeinsam Ihre neue Web-Datenbank!
Mit dem Klick auf den Button stimmen Sie zu, daß Cookies in Ihrem Browser gespeichert werden. Informationen zu den gespeicherten Cookies finden Sie unter Datenschutz#Cookies.Bei Fragen zur Technik wenden Sie sich bitte an Server-Daten - Web-Datenbank-Lösungen