Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

DAU Schutz

Begonnen von Tanzmaus4, November 24, 2010, 10:29:21

⏪ vorheriges - nächstes ⏩

Tanzmaus4

Hallo Leute,
ich habe seit kurzer Zeit Access 2007 auf meinem Rechner und will jetzt anfangen meine Datenbank aufzubauen.
Nun möchte ich mir vorher Gedanken zum Schutz der Daten machen, bevor ich hinterher alles wieder umschmeissen muss.
Es geht nicht darum die Daten oder Programme vor Hackern zu schützen sondern vor DAUs.

Folgende Ideen habe ich bereits zusammen:

1. Benutzersystem aus Access2003 reaktivieren
  Ich klammere mich nur ungern an alte Systeme, da die Verwendung in folgenden Versionen sicherlich schwieriger wird.

2. eigenes Benutzersystem programmieren
  Mit einer Tabelle, die lesegeschützt alle Benutzer, Gruppen und Passwörter enthält und entsprechende selbst programmierte Sicherungen im FE

3. unterschiedliche FEs, die den Zugriff auf die Daten entsprechend gestalten
  hört sich für mich nach sehr viel Pflegeaufwand an, wenn später mal etwas geändert werden soll

4. ein "Schreib"-FE für die versierteren User und ein "Lese"-FE mit Datensammlung über Mail-Formulare für die DAUs
  hab in der Access-Hilfe gestöbert und ein neues Spielzeug entdeckt (Datensammlung per E-Mail) ;-)


Was haltet Ihr von meinen Ideen und welche hättet Ihr noch?
MfG, Ute

Hondo

#1
Hallo,
imo das Wichtigste ist den Usern den Zugriff auf Tabellen zu verhindern.
Dazu sind verschiedene Techniken notwendig wie z.B. Shift-Taste Abschalten, F11 Taste abschalten, Datenbankfenster verstecken, Menüleisten und Symbolleisten ausblenden.
Zu den ersten 3 findest du die Lösung auf www.donkarl.com, letzteres unter Extra/Start.

Danach Zugriff auf VBA-Code verhindern. Codemodul schützen ist zu unsicher, besser ist MDE erstellen.

Dritter Schritt ist die Frontends (FE/BE Aufteilung ist klar?) so gestalten dass die User nur die Frontends bekommen wo nur die Funktionalität vorhanden ist die sie benötigen. Also z.B. nur die Formulare die der User benötigt.

Andreas

Ich vergaß:
Benutzersystem ist nicht schlecht, auch wenn es nicht viel Sicherheit bringt.
Was noch sinnvoll wäre ist eine Protokollierung von Datenänderungen.

database

Hallo,

 zu 1
      Wenn du eine *.accdb erstellt hast, kann das 2003er  System nicht aktiviert werden, du müsstest die Möglichkeiten verwenden, die Acc2007 hierzu bietet.
      Siehe dazu hier im Forum unter dem Suchbegriff 'mdw', 'Sicherheitssystem' und oder Kombinationen aus dem mit '2007'

 zu 2
      Es gibt einige Möglichkeiten, die in dem Zusammenhang hervorragende Dienste leistn können. Einen absoluten Schutz gibt es natürlich nicht aber es besteht durchaus
      die Möglichkeiteit des Zugriffs durch 'unbefugte' Benutzer geregelt zu halten und die Applikation so zu sichern.
      Alles was in dem Zusammenhang zu programmieren ist macht natürlich entsprechend Aufwand. Solltest du damit was machen wollen,
      kann ich dir bei Bedarf sicher ein paar Tipps und Beispiele zeigen / überlassen

 zu 3
      FE und BE zu verwenden sollte/müsste eigentlich bei Mehrbenutzer - Lösungen Standard sein.
      Sicherheitsrelvante Infos in Tabellen abzulegen halte ich persönlich für keine gute Idee.
      Access ist zwar nicht ausgesprochen unsicher aber die Möglichkeiten des Zugriffsschutzes auf Tabellenebene
      wie sie z.B. beim SQL-Server Standard sind existieren hier nicht.

 zu 4
      Auch hier gilt, dass in der Richtung einiges programmierbar ist. Beim Öffnen von Formularen, beim Anzeigen und nach verschiedenen Aktionen KANN durch Berechtigungsprüfung das
      Schreiben und/oder Lesen von Daten erlaubt oder untersagt werden.
      Die Geschichten mit den E-Mailformularen kenn ich nicht wirklich gut, daher will ich mich darüber nicht besonders äussern, möchte aber einwerfen, dass jede 'fremdeinmischung'
      und E-Mail stellt m.E. eine solche dar zu Problemen und Mehraufwand fürhren kann.

Grüße
Peter

Tanzmaus4

@Andreas:
meine DAUs werden nicht absichtlich nach VBA Code oder Tabelleninhalten suchen. Wenn, dann stolpern sie da zufällig rein und rufen dann direkt um Hilfe (also nach mir  ::))
Ich werde die angesprochenen Punkte aber wahrscheinlich trotzdem machen, damit die Optik des Programmes einfacher wird und meine Jungs nicht mehr verwirrt als unbedingt nötig.  ;)

Ja, FE/BE Aufteilung ist klar (BE=Backend=Tabellen/Daten zentral auf dem Server, FE=Frontend=Formulare, Abfragen, Berichte, VBA-Code lokal auf jedem PC)

Wird eine Protokollierung von Datenänderungen die DB nicht schnell aufblähen? Die DB wird eh schon recht groß werden. (eine eierlegende Wollmilchsau halt)

@Peter:
Ich tendiere ganz stark zur eigenen Programmierung also Punkt 2, da ich den absoluten Schutz ja gar nicht brauche und dann genau weiß, was auch in folgenden Versionen geschützt ist.


Macht man eigentlich für jede Benutzergruppe eine eigene FE-Datei mit den benötigten Formularen, Berichten, etc. oder eine allgemeine FE-Datei mit allen Formularen, ... und der Programmierung welche Formulare etc. für wen benötigt werden? (Letzteres passt vom Gefühl her besser zu meiner selbst zu programmierenden Benutzerverwaltung)
MfG, Ute

database

#4
Hallo Ute,

Zitat...da ich den absoluten Schutz ja gar nicht brauche...
Mal abgesehen davon, dass es den bei Access nicht gibt - Schlupflöcher bleiben immer irgendwie - würde es auch keinen Sinn machen, eine Applikation derart zu sichern,
dass es den Sicherheitseinrichtungen von Fort Knox gleichkommt.

Ich kenne zwar das Thema deiner Anwendung nicht aber ich wage einmal zu mutmaßen, dass du mit einem ausgeklügelten Startformular das Auslangen finden wirst.
Hier lassen sich Funktionalitäten unterbrinden wie das Verbergen des Datenbankfensters, die Sicherung vor nicht gewolltem Schließen der Applikation durch
Klicken auf die Schließen-Schaltfläche, ein Dialog zum Einloggen, ev. das Auslesen des angemeldeten Windows-Benutzers an Hand dessen dann ev. verschiedene
Funktionen vorhanden oder nicht vorhanden sein werden.... Andreas hat in seiner Antwort da schon entsprechende Hinweise in dieser Richtung gegeben - der Phantasie
sind hier fast keine Grenzen gesetzt, man muss nur Acht geben, dass man den Aufwand nicht zu hoch treibt und mit diversen Dingen den User bei seiner Arbeit
ungebührlich behindert, bzw sich selbst mehr Arbeit macht als eigentlich nötig wäre.

Die Geschichte mit den FEs lässt sich nicht pauschal beantworten, da erstens die Möglichkeiten recht umfangreich sind und zweitens das auch
bestimmt abhängig davon ist, welche Funktion die DB im Kern haben soll.
Andererseits musst auch hier abwägen was eben wichtig ist, wie hoch der Aufwand bei der einzelnen Variante ist, sie zu realisieren
und wie notwendig es wirklich ist die eine oder die andere Variante zu wählen.
So würde es m.E. recht wenig Sinn machen einzelne FEs für Benutzergruppen zu erstellen, wenn es dann letztendlich 5 oder 6 verschiedene
Gruppen gibt, die jede ein anderes FE haben sollen - da wird der Wartungsaufwand derart hoch sein, dass du sicher keinen Spass mehr an der
Sache haben wist. In dem Fall würde ich dann eher die programmierte Variante bevorzugen - ist höchstwahrscheinlich
vom Programmieraufwand eher hoch der aber fällt halt auch nur einmalig an.

ZitatWird eine Protokollierung von Datenänderungen die DB nicht schnell aufblähen?
Auch hier gilt, dass es verschiedene Varianten der Protokollierung gibt. Das reicht vom Speichern des Benutzernamens zusammen mit
Datum und Uhrzeit der letzten Datensatzänderung bis hin zum Festhalten der geänderten Werte in den Datensätzen.
Es handelt sich um Tabellenwerte, die bei geeigneteten Feldgrößen und Datentypen zwar die DB vergrößern aber dennoch nicht gleich sprengen werden.
Zudem kann hier ein gut durchdachtes Archivierungssystem das Datenaufkommen in vernünftigem Maß halten oder die Protokollierung überhaupt in externen Dateien (z.B. txt) erfolgen.

So wird es in dem Zusammenhang auch eine Überlegung wert sein, sich zu entscheiden, ob man gebundene oder ungebundene Formulare verwendet.
Die gebunden Variante ist zwar die einfacher zu erstellende, bietet durch die direkte Bindung an die Datenquelle viele Vorteile, andererseits aber birgt sie auch
die Gefahr in sich, ungewollte Änderungen an den Quelldaten zuzulassen. Also bleibt auch hier gut zu überlegen was du wie lösen willst.

So ... Ende des Romans ...   ;D

Grüße
Peter

EDIT: p.s. Sieh mal hier rein unter DatenbankenSichern ...   http://www.team-moeller.de/?Downloads   ;)

Tanzmaus4

Vielen Dank an beide!!!

Ich werde die DB wohl grundsätzlich mit allen vorgeschlagenen Möglichkeiten schützen, ein Identifikations-Dialog im Startformular einbauen und bei meinem Usernamen alle Schutzeinstellungen wieder rückgängig machen, damit ich an alles dran komme.

So, jetzt habt Ihr erst Mal wieder ein paar Wochen Ruhe vor mir, da ich das alles schön durcharbeiten und ausprobieren werde.  ;)
MfG, Ute