Backend-Datenbank vor CLEVEREN(!) Anwendern schützen
Rudolf Hennemuth
ich arbeite an Dokumentationssystem für soziale Einrichtungen, wobei es
wesentlich darauf ankommt, sicherzustellen, dass Daten nicht manipuliert
werden können.
Ich benutze zur Entwicklung das Betriebssystem Windows XP und Office XP
Developer, die Anwendung soll aber als Runtime auf möglichst allen
Windows-Betriebssystemen einsetzbar sein.
Das Frontend ist ziemlich leicht durch eine MDE zu schützen. Dagegen
bereitet mir der Schutz der Backend-Datenbank Kopfschmerzen.
Ich muss verhindern, dass
a) irgendjemand die Backend-Datenbank öffnet und direkt in den Tabellen
Daten manipuliert,
b) irgendjemand die Tabellen der Backend-Datenbank in eine andere Datenbank
einbindet oder sonst die eröffnet (ODBC).
Ich denke dabei ausdrücklich nicht an die DAUs, sondern an clevere Anwender,
die sich mit Access auskennen.
Der klassische Weg wäre Vergabe der Rechte mittels einer MDW. Doch die
Rechte zum Lesen, Verändern und Löschen der Daten müssen für die User der
Frontend-Datenbank erhalten bleiben, während dieselben User in der
Backend-Datenbank nichts zu suchen haben.
Erschwerend kommt meines Erachtens hinzu, dass es gelegentlich notwendig
ist, die Backend-Datenbank zu pflegen, d. h. auch Felder in einzelnen
Tabellen hinzuzufügen oder zu ändern und manchmal auch neue Tabellen
einzufügen. Dies geschieht durch Funktionen, die in dem autoexec-Makro
aufgerufen werden. Hier braucht der User doch die Rechte, die ihm durch die
MDW entzogen wurden, oder?.
Bevor ich mich ernsthaft eine Lösung meines Problems daran machen, würde ich
gerne die Meinung von Newsgroup-Mitgliedern hören, die sich mit der Materie
auskennen.
Gruß,
Rudolf Hennemuth
Thomas Jennerwein
Evt. MSDE anstatt Access als Backend benutzen ? Du musst dann halt alle
Änderungen Scripten aber das machen wir am SQL-Server auch so. Meiner
Meinung nach ist nur ein SQl-Server gut zu sichern. Vergiss nicht die
SHIFT-Sperre am Frontend.
Ansonsten googlen da gibts allerhand Tips zu dem Thema.
Thomas
CMC-Solutions.com - Creating your Digital Business
CMC Mag. Karl Haag GmbH
Raiffeisenstrasse 9
A-6890 Lustenau
Tel.: +43 / +5577 / 82170
Fax.: +43 / +5577 / 8217014
mailto:t.jenn...@cmc-solutions.com
Peter Steimann[MVP Access]
"Rudolf Hennemuth" <Rudolf.H...@t-online.de> schrieb:
> Hallo Newsgroup,
> ich arbeite an Dokumentationssystem für soziale Einrichtungen, wobei es
> wesentlich darauf ankommt, sicherzustellen, dass Daten nicht manipuliert
> werden können.
> Ich benutze zur Entwicklung das Betriebssystem Windows XP und Office XP
> Developer, die Anwendung soll aber als Runtime auf möglichst allen
> Windows-Betriebssystemen einsetzbar sein.
> Das Frontend ist ziemlich leicht durch eine MDE zu schützen. Dagegen
> bereitet mir der Schutz der Backend-Datenbank Kopfschmerzen.
> Ich muss verhindern, dass
> a) irgendjemand die Backend-Datenbank öffnet und direkt in den Tabellen
> Daten manipuliert,
> b) irgendjemand die Tabellen der Backend-Datenbank in eine andere Datenbank
> einbindet oder sonst die eröffnet (ODBC).
> Ich denke dabei ausdrücklich nicht an die DAUs, sondern an clevere Anwender,
> die sich mit Access auskennen.
>
Dann hast Du keine Chance. Der Schutz ist für einen gewieften Access-ler
kein Problem. Du müsstest als BE ein richtiges Serversystem nehmen.
(SQL-Server, MSDE, MySQL,...)
> Der klassische Weg wäre Vergabe der Rechte mittels einer MDW. Doch die
> Rechte zum Lesen, Verändern und Löschen der Daten müssen für die User der
> Frontend-Datenbank erhalten bleiben, während dieselben User in der
> Backend-Datenbank nichts zu suchen haben.
Das dürfte dann aber problematisch werden. Der User müsste mit der
niederigsten Zugriffsstufen einsteigen, dann müsstest Du via Code den
User wechseln, damit Du höhere Berechtigungen kriegst. (Das Passwort
darf ja dem User nicht bekannt sein, damit's Ihn beim Backend beim
Direktzugriff wieder raushaut)
Sobald er aber in's Datanbankfenster kommt, kann er im BE rumwurschteln
wie er will (Ausser Strukturänderungen vornehmen)
Nochmals: Ein BE lässt sich imo wirlich nur für Dau's schützen, solange
Du eine Access-DB als BE hast.
Gruss
Peter
Rudolf Hennemuth
vielen Dank für die Bestätigung meiner schlechten Vorahnungen.
Nun kann ich meinen Kunden unmöglich den SQL-Server auferlegen. MSDE - mit
dem ich bisher kaum Erfahrung habe (wohl aber mit MS SQL Server) - wäre eine
Möglichkeit, weil es nichts kostet.
Gibt es eine Möglichkeit,
1. die Backend-Datenbank in MSDE umzusetzen (bisher kenne ich nur die
Möglichkeit, mit dem Upsizing-Assistenten eine MS SQL-Datenbank aus Acces
heraus zu erstellen) und
2. die MSDE-Datenbank dann an die Kunden mit dem Setup des Office XP
Develpers zu verteilen?
Außerdem gibt das eine "Schweine-"Arbeit, den gesamten Code auf den
SQL-Server umzustellen.
Gruß,
Rudolf Hennemuth
#######################################
"Peter Steimann[MVP Access]" <PSteiman...@Timesoft.ch> schrieb im
Newsbeitrag news:OFn1T3vWCHA.2476@tkmsftngp09...
Peter Steimann[MVP Access]
"Rudolf Hennemuth" <Rudolf.H...@t-online.de> schrieb:
> Hallo Peter,
> vielen Dank für die Bestätigung meiner schlechten Vorahnungen.
> Nun kann ich meinen Kunden unmöglich den SQL-Server auferlegen. MSDE - mit
> dem ich bisher kaum Erfahrung habe (wohl aber mit MS SQL Server) - wäre eine
> Möglichkeit, weil es nichts kostet.
> Gibt es eine Möglichkeit,
> 1. die Backend-Datenbank in MSDE umzusetzen (bisher kenne ich nur die
> Möglichkeit, mit dem Upsizing-Assistenten eine MS SQL-Datenbank aus Acces
> heraus zu erstellen) und
Der Assi hat nicht so einen guten ruf. Ohne Nacharbeit wird's nicht
gehen. Die MSDN taugt auch nur bis 5 gleichzeitige Nutzer, dann wird's
langsam
> 2. die MSDE-Datenbank dann an die Kunden mit dem Setup des Office XP
> Develpers zu verteilen?
Das ist beides möglich
> Außerdem gibt das eine "Schweine-"Arbeit, den gesamten Code auf den
> SQL-Server umzustellen.
Schau mal, ob Du nicht MySQL verwenden willst. Der Portierungsaufwand
ist imo wesentlich geringer. MySQL kostet nix, ist schneller und Du hast
keinen Flaschenhals wie bei der msde. Ansonsten lieber auf SQL-Server
gehen. Der Portierungsaufwand ist genau derselbe wie mei der msde. Er
kostet natürlich, (sooo viel nu auch wieder nicht)aber die Investition
lohnt sich für den Kunden bestimmt.
--
Gruss
Peter
-----------------------------------------------------------
Mitglied des APP-Profipools Http://www.Accessprofipool.de
Zeiterfassungs-Systeme unter Http://www.Timesoft.ch
Juergen Frieling
> Hallo Peter,
> vielen Dank für die Bestätigung meiner schlechten Vorahnungen.
> Nun kann ich meinen Kunden unmöglich den SQL-Server auferlegen. MSDE -
Hat noch keiner erwähnt, obs Dir reicht musst Du wissen:
Möglicherweise hilft Dir, Abfragen mit 'WITH OWNERACCESS OPTION' zu
erstellen (im Designer die Eigenschaft 'Ausführungsberechti-
gungen').
Man kann dann allen, ausser einem 'SuperUser', im BE die Rechte entziehen
und den Zugriff im FE nur über Abfragen durchführen, die diesem SuperUser
gehören.
Die normalen Benutzer bekommen dann nur Berechtigungen auf diese Abfragen
und über diese dann an die Daten.
(Hab' ich alles nur gelesen, ausprobieren musst Du es... ;-)
Gruss,
Juergen
Peter Steimann[MVP Access]
"Juergen Frieling" <jue...@beer.com> schrieb:
Funzen tut es schon. Nur: Wenn man so einfach die Kennwörter auslesen
kann, ist der BE dann offen wie ein Scheunentor!
Gruss
Peter
Erwin Kainbacher
> Hallo Jürgen
>
> "Juergen Frieling" <jue...@beer.com> schrieb:
> > Moin,
> >
> > > Hallo Peter,
> > > vielen Dank für die Bestätigung meiner schlechten Vorahnungen.
> > > Nun kann ich meinen Kunden unmöglich den SQL-Server auferlegen. MSDE -
> > Hat noch keiner erwähnt, obs Dir reicht musst Du wissen:
> > Möglicherweise hilft Dir, Abfragen mit 'WITH OWNERACCESS OPTION' zu
> > erstellen (im Designer die Eigenschaft 'Ausführungsberechti-
> > gungen').
> > Man kann dann allen, ausser einem 'SuperUser', im BE die Rechte entziehen
> > und den Zugriff im FE nur über Abfragen durchführen, die diesem SuperUser
> > gehören.
dieser Superuser braucht dann gar nicht in der mit der App. zur
Laufzeit
verwendeten MDW sein, sondern ist nur i.e. Entwickler MDW vorhanden !
> > Die normalen Benutzer bekommen dann nur Berechtigungen auf diese Abfragen
> > und über diese dann an die Daten.
Das klappt alles wunderbar, siehe
www.ms-office-forum.de/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=32&t=013373
(Link in einer Zeile)
wobei "owneraccess"-queries einen anderen Pferdefuss haben, auf
welchen
in o.a. Link eingegangen wird.
> Funzen tut es schon. Nur: Wenn man so einfach die Kennwörter auslesen
> kann, ist der BE dann offen wie ein Scheunentor!
@Peter
von welchen Passwörtern sprichst du jetzt ? Mit den neuesten Versionen
von Hackertools kann man aus direkt aus einer MDB die Obj.Owner+PID
auslesen, womit jegliches Verwenden einer MDW obsolet wird. Allerdings
kann man auch da
dem Hobbyhacker (der zwar weiss wo er sich die Tools beschafft, aber
sonst
selber kein Crack ist), ein Schnippchen schlagen, indem man
DBCS-User/PID
mit "ungewöhnlichem" ;=) Inhalt per Code erzeugt, dann ist die Ausgabe
div.
Hackertools bzgl. Obj.Owner/PID/Pwd. nicht wirklich hilfreich.
so long Erwin...
Peter Steimann[MVP Access]
"Erwin Kainbacher" <er...@kainbacher.de> schrieb:
> "Peter Steimann[MVP Access]" <PSteiman...@Timesoft.ch> wrote in
message news:<OT8oo2BXCHA.2896@tkmsftngp10>...
> Das klappt alles wunderbar, siehe
>
www.ms-office-forum.de/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=32&t=01337
3
> (Link in einer Zeile)
> wobei "owneraccess"-queries einen anderen Pferdefuss haben, auf
> welchen
> in o.a. Link eingegangen wird.
>
> > Funzen tut es schon. Nur: Wenn man so einfach die Kennwörter auslesen
> > kann, ist der BE dann offen wie ein Scheunentor!
> @Peter
> von welchen Passwörtern sprichst du jetzt ? Mit den neuesten Versionen
> von Hackertools kann man aus direkt aus einer MDB die Obj.Owner+PID
> auslesen, womit jegliches Verwenden einer MDW obsolet wird. Allerdings
> kann man auch da
> dem Hobbyhacker (der zwar weiss wo er sich die Tools beschafft, aber
> sonst
> selber kein Crack ist), ein Schnippchen schlagen, indem man
> DBCS-User/PID
> mit "ungewöhnlichem" ;=) Inhalt per Code erzeugt, dann ist die Ausgabe
> div.
> Hackertools bzgl. Obj.Owner/PID/Pwd. nicht wirklich hilfreich.
Iss ne Zeit her, wo ich mich intensiver damit beschäftigt habe. Soweit
ich mich erinnern kann, lag das Problem darin, dass wenn die DB gezielt
abgeschossen wird,der Benutzer Administrator dann wieder alle Rechte an
den Objekten erhielt. Es braucht dazu also keine Hackertools. Müsste ich
jetzt nochmals genau mit Deiner Beispiel-DB nachprüfen.
Gruss
Peter
>
> so long Erwin...
Erwin Kainbacher
<PSteiman...@Timesoft.ch> schrieb in im
Newsbeitrag: eCxsVrVXCHA.2656@tkmsftngp10...
Hallo Peter
> Hallo Erwin
> > @Peter
> > von welchen Passwörtern sprichst du jetzt ? Mit den neuesten Versionen
> > von Hackertools kann man aus direkt aus einer MDB die Obj.Owner+PID
> > auslesen, womit jegliches Verwenden einer MDW obsolet wird. Allerdings
> Iss ne Zeit her, wo ich mich intensiver damit beschäftigt habe. Soweit
> ich mich erinnern kann, lag das Problem darin, dass wenn die DB gezielt
> abgeschossen wird,der Benutzer Administrator dann wieder alle Rechte an
> den Objekten erhielt.
hast du da noch irgendwelche Dokus/Links/Demos obwohl
ich mich ganz gut im Thema Acc.Sec. auskenne, bin ich über
einen derartigen Hinweis bei meinen Recherchen noch
nicht gestolpert. Welche Acc.Version(en) meinst du eigentlich ?
so long Erwin
Peter Steimann[MVP Access]
"Erwin Kainbacher" <er...@kainbacher.de> schrieb:
>
Es gibt das Problem, dass bei einer DB, welche repariert werden muss,
sämtliche Zugriffsrechte flöten gehen und der Admin wieder vollen
Zugriff hat. Je nach Defekt der DB kann das, muss aber nicht passieren.
Es ist mir jedenfalls mehrfach gelungen, durch gezielte Verwendung eines
Texteditors einen solchen Zustand herzustellen. Wäre aber dekonstruktiv,
hier eine genaue Anleitung zu geben. Siehe mal unter Google, vielleicht
findest Du da was bezüglich Verlust der Berechtigungen. Passieren kann
dies, wie gesagt, bei jedem Defekt der DB, je nachdem, wo's geknallt
hat.
Demo-DB habe ich hierfür keine und müsste mich nochmals damit
auseinandesetzen. Mir reichte es damals aus zu wissen, dass der Fall
eintreten kann.
Bezieht sich auf A97. (vermutlich SR1) Ob's bei A2000 und AXP anders
ist, habe ich damals noch nicht testen können-;)
Gruss
Peter
>
> so long Erwin
>
>
Juergen Frieling
> Es ist mir jedenfalls mehrfach gelungen, durch gezielte Verwendung
> eines Texteditors einen solchen Zustand herzustellen. Wäre aber
> dekonstruktiv, hier eine genaue Anleitung zu geben. Siehe mal unter
müüste man bzgl. dieser Frage halt mal klären, ob ein CLEVERER Anwender
einer ist, der seine ganze Energie dahinein investiert, so eine MDB zu
knacken, oder ob man nur den vorwitzigen Knaben abhalten möchte, der weiss,
dass es ja auch eine BE-MDB gibt.
Gruss,
Juergen
Ralf Mueller
Erwin Kainbacher <er...@kainbacher.de> schrieb am 15.09.02
zum Thema: Re: Backend-Datenbank vor CLEVEREN(!) Anwendern schützen
>>> Man kann dann allen, ausser einem 'SuperUser', im BE die Rechte
>>> entziehen und den Zugriff im FE nur über Abfragen durchführen, die
>>> diesem SuperUser gehören.
> dieser Superuser braucht dann gar nicht in der mit der App. zur
> Laufzeit verwendeten MDW sein, sondern ist nur i.e. Entwickler MDW
> vorhanden !
Ebend!
> Mit den neuesten
> Versionen von Hackertools kann man aus direkt aus einer MDB die
> Obj.Owner+PID auslesen, womit jegliches Verwenden einer MDW obsolet
> wird.
Und wenn, wie Du selbst oben geschrieben hast, der Superuser in der
Entwickler MDW der Eigentümer aller Objekte ist? Dann können diese
Hackertools doch auch keinen Owner aus den Kunden-MDWsauslesen, oder wo
liege ich daneben?
> Allerdings kann man auch da dem Hobbyhacker (der zwar weiss wo er
> sich die Tools beschafft, aber sonst selber kein Crack ist), ein
> Schnippchen schlagen, indem man DBCS-User/PID mit "ungewöhnlichem" ;=)
> Inhalt per Code erzeugt, dann ist die Ausgabe div. Hackertools bzgl.
> Obj.Owner/PID/Pwd. nicht wirklich hilfreich.
Du meinst der Hobbyhacker würde dann den Ausgaben dieser Tools nicht
trauen, wenn die verwendeten Zeichenketten für PID/Passw nur 'verrückt'
genug gewählt würden ... ?
Gruß
Ralf
Rudolf Hennemuth
ich bin erfreut, dass die Diskussion so lebhaft weitergegangen ist. Ich
verfolge sie mit großem Interesse.
Zunächst zur Frage, was ich unter einem "CLEVEREN User" verstehe:
a) einen User, der sich mehr oder minder gut mit Access auskennt und gerne
etwas experimentieren will,
b) einen User, der auf die Idee kommt, sich die Datenbank mal eben mit nach
Hause zu nehmen, um etwas nachzugucken,
c) einen User, der a und b erfüllt und dann noch den Einfall hat, z.B.
nachträglich etwas zu Schönen, um einen Vorteil zu haben.
Unter einem "CLEVEREN User" verstehe ich nicht einen, der mit krimineller
Energie daran geht, die Daten zu klauen und zu fälschen und dafür alle
möglichen Mittel bis hin zu Hackertools einsetzt.
Meine eigenen Überlegungen haben sich mittlerweile etwas weiter entwickelt,
und ich erwäge folgende Möglichkeiten:
a) die BE-DB durch ein Startformular mit einem Passwort zu schützen (+ die
üblichen Starteinstellungen, die verhindern, dass einer an das
Datenbankfenster kommt) und die DB automatisch zu schließen, wenn das
Passwort falsch eingegeben oder das Startformular irgendwie unerlaubt
geschlossen wird,
b) die BE-DB durch die Vergabe von Rechten in einer MDW zu schützen und dem
normalen User nur Leserechte zu geben. Der Zugriff auf die Daten müsste im
Frontend dann jeweils über ADO mit Übergabe der UserID- und
Password-Argumente erfolgen.
Dabei könnte man eventuell darauf verzichten, die Tabellen ins Frontend
einzubinden, bzw. nur mit temporären Tabellen im Frontend zu arbeiten, die
jeweils bei Bedarf gefüllt werden.
Das sind bisher nur Überlegungen, die wahrscheinlich eine Menge von
Umprogrammierung mit sich bringen. Ich werde an einem kleinen Beispiel
versuchen, ob es klappt.
Ich hoffe, dass die Diskussion weiter geht,
Rudolf Hennemuth
Peter Steimann[MVP Access]
"Rudolf Hennemuth" <Rudolf.H...@t-online.de> schrieb:
[..]
> a) die BE-DB durch ein Startformular mit einem Passwort zu schützen (+ die
> üblichen Starteinstellungen, die verhindern, dass einer an das
> Datenbankfenster kommt) und die DB automatisch zu schließen, wenn das
> Passwort falsch eingegeben oder das Startformular irgendwie unerlaubt
> geschlossen wird,
Neue DB erstellen, Objekte importieren, und schon kommst Du wieder an
das DB-Fenster. Hängt halt von der Cleverness ab-;)
> b) die BE-DB durch die Vergabe von Rechten in einer MDW zu schützen und dem
> normalen User nur Leserechte zu geben. Der Zugriff auf die Daten müsste im
> Frontend dann jeweils über ADO mit Übergabe der UserID- und
> Password-Argumente erfolgen.
Warum ADO?
> Dabei könnte man eventuell darauf verzichten, die Tabellen ins Frontend
> einzubinden, bzw. nur mit temporären Tabellen im Frontend zu arbeiten, die
> jeweils bei Bedarf gefüllt werden.
>
> Das sind bisher nur Überlegungen, die wahrscheinlich eine Menge von
> Umprogrammierung mit sich bringen. Ich werde an einem kleinen Beispiel
> versuchen, ob es klappt.
>
> Ich hoffe, dass die Diskussion weiter geht,
Ohne Deinen Usern bezüglich Cleverness zu nahe treten zu wollen: Ich
würde mal Erwin's Vorschlag weiterverfolgen. So Clever werden Deine User
wohl nicht sein-;)
Gruss
Peter