Office: (Office 2010) Sicherheitskonzept FE

Hallo,
ich soll eine accdb, aufgeteilt in FE und BE so absichern, dass eine Manipulation der Daten auf dem BE nur durch das entsprechende FE möglich ist. Die FE's laufen auf Arbeitsplatzrechnern, auf denen nur eine A 2010 Runtime-Umgebung installiert ist.
Der Einsatz eines SQL-Servers als BE oder die Aktivierung des Access eigenen Sicherheitsystems auf Benutzer- / Gruppenebene (ugam) kommt nicht in Betracht. Nach diversem rumggoogeln habe ich mit folgendes Konzept überlegt
- Das BE wird mit Kennwort verschlüsselt.
- Das FE wird als accde ausgeliefert. Da auf den Arbeitsplatzrechner nur die Runtime-Umgebung installiert ist, kann der Benutzer das in der Tabelle MSysObjects gespeicherte Kennwort nicht auslesen.
- Wird das FE in einer Vollumgebung geöffnet, wird es sofort wieder per Quellcode geschlossen. (Shift-Tast selbstverständlich deaktiviert)
Haltet ihr das Verfahren für einen gangbaren Weg? Gibt es Dinge, die ich übersehen habe?
Vielen Dank für Eure Antworten im Voraus.

:)

 

Hallo!

Wie ist der Schutz zu betrachten?
Sollen damit nur irrtümliche Änderungen der Daten verhindert werden oder soll auch verhindert werden, dass sich jemand die Dateien mit nach Hause nimmt und dann in aller Ruhe die Daten ansieht bzw. einen eigenen Client baut, mit dem er dann direkt auf die Tabellen zugreifen kann?

Tabelleninhalte sind auch ohne Access-Vollversion aus dem unverschlüsselten Frontend auslesbar.
Du darfst das Kennwort vom BE nicht speichern - vor allem auch nicht in den verknüpften Tabellen, wenn es nicht ausgelesen werden soll.
Problem dabei: wenn du die Tabellen aus dem verschlüsselten BE verknüpfst, kannst du das Speichern gar nicht verhindern. Du müsstest das Frontend zuerst mit dem unverschlüsselten BE verknüpfen und erst anschließend das Backend verschlüsseln. Beim Starten des FE kannst du dann per VBA-Code das Backend für den Zugriff öffnen. (Das Thema wurde hier im Forum schon so oft behandelt.)

Auch die kann man z. B. per VB-Script wieder aktivieren.

mfg
Josef

 

Hallo Josef, vielen Dank für Deine schnelle Reaktion.
In erster Linie soll unterbunden werden, dass jemand ausserhalb den FEs die Daten z.B. mit Excel oder mit einem eigenem Client nachträglich verändert und dadurch die im FE hinterlegten Regeln umgeht.

Das habe ich nicht so ganz verstanden. Aber eher die generelle Frage an Dich: Gibt es aus deiner Sicht ein halbwegs sicheres (und praktikables) Verfahren, FE und BE per Verschlüsselung mit Kennwort zu schützen? Wenn ja, kann wo kann ich dazu Infos finden? (Den von A. Minhorst geschilderten konzeptionellen Ansatz http://www.access-im-unternehmen.de/...&BeitragID=920ist m. Einschätzung nicht praktikabel, da ich eine bestehende Anwendung aufrüsten soll.

Leider funktioniert die Google-Suche im Forum bei mir nicht, es würde mit daher helfen, wenn Du bitte Links auf die entsprechendes Threads hier einstellen würdest.
Vielen Dank von
Thomas

 

Was ist für dich "sicher"?
Ich selbst verwende kein Access-Backend sondern nur aktive DBMS, bei denen ich die "Zugriffssicherheit" auf Tabellen besser regeln kann.
Bei einem File-Backend musst du immer bedenken, dass die ganze Datei kopiert werden kann und man dann zu Hause genug Zeit fürs "Aufmachen" hat.

Ein Angebot: Du sicherst ein Test-FE für den "geregelten" BE-Zugriff und ein dazu passendes BE mit Testdaten ab und stellst es als Download bereit. Wenn ich dir aus diesen Dateien die Tabellendaten schicken kann, ist dein Konzept nicht sicher. *wink.gif*

Oder reicht es aus, wenn der "Normal"-User (der ohne Programmiererfahrung) nicht an die Daten kann?

Warum sind die Regeln im Frontend und nicht im Backend als "Tabellen-Regeln" umgesetzt?
Du verwendest doch schon Access 2010 - damit stehen dir sogar Trigger (Datenmakros) zur Verfügung.

mfg
Josef

 

Hallo Josef,

M.E. ist es zunächst ausreichend, wenn der von Dir beschriebene "Normal"-User (der weiss, das man auch mit Excel Access-Datenbanken öffnen kann, der aber keine Programmierkenntnisse hat) nur mit dem FE an die Daten des BE rankommt. Eine weitere mögliche Sicherheitsstufe wäre es dann, den VBA-Profi auszubremsen.

Vielen Dank für das Angebot des Praxistests, ich komme später drauf zurück. Meiner Einschätzung nach funktioniert ein Schutz des BE nur im Zusammenspiel mit Windows-Benutzerechten. Ich habe inzwischen dazu eine etwas ältere Diskussion gefunden: http://www.ms-office-forum.net/forum...=265869&page=3. Frage: Hast Du mal (prototypisch) ausprobiert, wie man das FE mit einem anderen Windows-User als dem tatsächlich angemeldeten starten kann? Hat sich das Konzept ggf. bewährt?

Die Anwendung habe ich vor 17 Jahren zusammen geklöppelt, da war noch nix mit Datentrigger. Daher liegt ein großer Teil der Fachlogik in den Formularen ...
Viele Grüße & Dank im Voraus von
Thomas

 

Dazu gibts eine Anleitung hier im Forum. Schaus dir mal an.

Ist ein interessanter Ansatz. Habs selbst aber noch nie umgesetzt.
Ich gehe mal davon aus, dass man via getObject (mit Pfadangabe) nicht mehr auf das geöffnete Frontend zugreifen kann. Ohne Pfadangabe wird es aber dennoch gehen, da das COM Objekt selbst kein Sicherheitssystem hat.
Prüf es und gib uns doch Bescheid.

99% solltest du mit dieser Methode draußen halten.
Allerdings ist die Hürde nicht besornder groß, soweit man sich auskennt.
LG Markus

Edit:
Ich habe mich mit dem Thema ausgiebig auseinandergesetzt.
Ich glaube, dass auch 100% möglich sind, was den Zugriff über das Objektmodell angeht.
Das erfordert aber eine Neuprogrammierung und ein aktives DBMS ist Grundvoraussetzung dies ist aber Profis hier im Forum nicht erstrebenswert, da man auf die Möglichkeiten der simplen Programmierung von Access verzichten muss.

All das gilt nur wenn man versucht über das Objektmodell zuzugreifen. Bei anderen Wegen gibt es keinen Schutz - das gilt dann aber für jede Art von Software.

 

Hallo markusxy, vielen Dank für den Link zur Anleitung und den Hinweis auf das COM-Objekt, beides ist sehr hilfreich für meine Überlegungen. Die Absichering des BE durch den Einsatz eines technischen Useres mit den entsprechenden Datei- und Verteichnisrechten ist m.E. ein praktikable und angemessene Lösung. Bei der Absicherung des FE bin ich da etwas pessimistischer: Da sich der Zugriff per getObject() auf das geöffnete FE vermutlich nicht nicht verhindern lässt, hätte ich nur noch die Idee, das Frontend virtualisiert und dadurch in einer gekapselten Umgebung laufen zu lassen (folgt der alten Terminalserveridee von JosefP): Die einfache Variante wäre, nur das FE und ggf. die Runtimeumgebung zu virtualisieren, z.B. Application Virtualization | Windows Apps in the Browser. Wenn das nicht ausreicht / funktioniert, bielbe dann m.E. noch die Möglichkeit, auf den Arbeitsplatzrechner eine restriktiv administrierte virtuelle Maschine, in der dann die Runtime und das FE läuft, zu installieren. Da stellt sich dann aber auch irgendwann die Frage der wirtschaftlichen Sinnhaftigkeit ...
How ever, dieser Faden hat mir bei meinen Überlegungen sehr weitergeholfen. Ich werde nun ersteinmal klären, wie wir weiter vorgehen wollen. Wenn es neue Erkenntnisse von der COM-Front gibt, melde ich mich natürlich.
Viele Grüße von
Thomas

 

Hallo Thomas!

Vom Prinzip her muss sichergestellt werden, dass man auf das Access Objekt nicht zugreifen kann.

Wenn eine ACCDE als Runtime Version in einer TS Sitzung läuft, die auf die Anwendung beschränkt ist - dann sollte mEn auch kein Zugriff möglich sein,
da es nicht möglich ist einen anderen Code in der Sitzung auszuführen. Sobald das gelingt, ist der Schutz dahin.

Welche Einschränkungen das mit sich bringt wäre natürlich zu prüfen.

LG Markus

Edit:
Die Absicherung des Backend durch den "technischen User" ist natürlich nur relativ.
Wenn ich auf das Frontend zugreifen kann hab ich direkten Zugriff auf das Backend.
Man kann das Backend zwar nicht direkt kopieren, aber den Inhalt eben - das gilt auch wenn ein aktives DBMS hinten dran ist. Alles was ich lesen darf kann ich mitnehmen oder auch editieren/löschen usw.

 

Hallo Markus

was verstehst Du unter Run-Time Version ?
eine AccdR oder Starten mit Option /Runtime ?

 

\@Ruedi,
das ist etwas unpräzise ausgedrückt.
Es geht um eine ACCDE und einer Runtime Umgebung. Also eine Version ohne die Möglichkeit den Code zu verändern als Basis der ACCDR.
Wobei es in dem speziellen Fall egal ist. Es geht nur darum, dass man den Direktbereich der Entwicklungsumgebung nicht erreichen kann.

LG Markus

 

Hallo verehrte Community,
ich war noch ein Testergebnis bzgl. des Angriffs per COM-Objekt Set objAccess = GetObject( , "Access.Application") auf eine Access-Instanz, die unter Zuhilfnahme von 'run as' mit einem anderen User gestartet, schuldig. Das Ergebis ist erfreulich: In einem solchen Szenario kann durch den zuerst angemeldeten User keine Access-Instanz erkannt werden, die von ihm mit 'run as' und mit einem anderen User gestartet wurde.
Fallen Euch noch weitere Angriffsmöglichkeiten auf eine Datenbank, die so gestartet wurde, ein?
Viele Grüße von
Thomas

Dank an Benutzer WeinGeist, der die Idee mit 'run as' in diesem Thread beschrieben hatte.

 

Danke für den Test.
Das Positive ist jetzt mal sicher, dass man über das Objekt Modell von Access/VBA nicht einfach zugreifen kann.
Testen müsste man ob man über das "running object table" darauf zugreifen kann. GetObject verwendet vermutlich auch die Tabelle.
Da hab ich aber noch keine Erfahrung. Das müsste man sich etwas ansehen.

LG Markus

 

Hallo Markus, Dank für den weiteren Hinweis. Wenn ich Erkenntnisse zum Thema 'ROT' gewonnen habe, werde ich diese hier an dieser Stelle wieder kommunizieren. Das kann aber etwas dauern ...
Viele Grüße von
Thomas

 

Macht nichts. Jedenfalls wäre es ein wertvoller Beitrag für das Forum. Unabhängig vom Ergebnis würde ich die Möglichkeit als sehr sicher betrachten, da die wenigsten über diese vertieften Kenntnisse verfügen - auch wenn es im Web genug Anleitungen dazu gibt.

LG Markus