Office: (Office 2010) allowbypasskey von extern nicht mehr veränderbar?

Das Blockieren der Shift-Taste per VBA gem. Don Karls 1.8 habe ich zu meiner vollen Zufriedenheit schon Dutzende von Malen eingesetzt.
Es gibt noch ein Restproblem(chen):
Die Anweisung ..
Code:

kann aber auch so laufen, dass sie aus einer externen Datenbank aufgerufen wird. Das Database-Objekt db wird dann einfach referenziert auf die Original-DB, bei welcher die Shift-Taste blockiert ist.

Eine solche externe Knack-DB habe ich mir selbst für Notfälle erstellt, es klappt!!
Mein Wunsch: Auch das soll eben nicht mehr gehen können!

Ich weiß, dass in der zu schützenden DB hierzu eine Systemvariable gesetzt werden kann, die es verhindert, dass aus der externen „Welt“ das Allowbypasskey verändert wird.
Einen entsprechenden Hinweis habe ich hier in diesem Forum vor ca. 1 Jahr gesehen, ihn wieder vergessen und auch per Suche / Googelns finde ich ihn nicht wieder.
(ich glaube, es war Sascha Trowitzsch, bin mir aber nicht sicher)
Wer hilft mir bitte noch mal auf die Sprünge?
Vielen Dank im Voraus.

:)

 

Hallo,
evtl. meinst du Code:

.
Aber es ist nicht der Bringer, man kann zwar zuverlässig ein CreateObject abfangen, aber man kann sich ja auch mit GetObject() bzw. DAO an die laufende DB hängen.

DAO selbst kann man mMn. mit einem Datenbankkennwort (+StartEXE/StartDB) zuverlässig sperren, aber es bleibt halt das GetObject().

 

Hallo Werner,

von einer solchen Lösung habe ich bisher noch nichts gelesen.

Ich bezweifle auch ein Stück weit, dass das geht. Selbst wenn Du in einer Systemtabelle einen Eintrag ändern könntest, der die Anpassung von AllowBypassKey verhindert, kann man doch auch diesen Eintrag in der Systemtabelle wieder ändern. Du würdest zwar eine zusätzliche Hürde einbauen, einen absoluten Schutz hättest Du aber nicht.

CU

 

Hallo,

Wenn man damit einen Zugriff von außen (komplett) verhindern könnte, wäre auch keine Änderung von außen mehr möglich.
Also wäre das schon sicher, wenn es denn so was gäbe.

 

Ich schliesse mich Thomas Meinung an.

Um von außen die Eigenschaften nicht ändern zu können, muss der Befehl Opendatabase in Einsatz kommen.
Wenn diese fehlschläge weil diese nicht öffnenbar ist, weil geschützt über system.mdw, dann hast du deine lösung.
Aber ich meine mich zu erinnern, du stehst nicht so auf diese technik *tongue.gif*

Grüße
JPA

 

Hallo
Frage:
wie währe es
damit das die MDB oder besser die MDE
nur als RUNTIME (Echt Runtim oder symuliert (option /Runtim)) gestartet werden kann bei nicht Runtim DB schliesen würde so was Dich weiter bringen ?
dann spielt die Shift-Taste keine grosse Rolle mehr *wink.gif*
schon getestet ?

 

Hallo zusammen,

@Werner
ich denke, wie Steffen, du bist mal über
Code:

gestolpert.

Mich würde wirklich mal interessieren, warum immer solche Verrenkungen vorgenommen werden,
statt mit 2 Mausklicks eine vor Eingriffen geschütze MDE/ACCDE zu erstellen.
Klärt mich doch mal bitte auf.

 

\@Marsu65:

"Mein" Thema ist die Sicherung der Daten (von außen).
Ich habe dabei ein "Konzept" für eine sichere DB, allein GetObject() macht mir einen Strich durch die Rechnung.
Leider kann dieser Code, wie geschrieben, dabei nicht helfen, da er nur auf CreateObject() anspringt.

Btw:
Ganz allgemein wird dem internen Schutz nmM zu viel Aufmerksamkeit geschenkt, wenn man bedenkt, dass man "normal" schon allein mit Excel und ein paar Mausklicks die Daten auf einem Tablett serviert bekommt.

 

Hallo Steffen!

Darunter verstehe ich jetzt die Sicherung des Daten-Backends.
Da dort nur Tabellen liegen, fällt mir kein Grund ein, hier die Shifttaste außer Kraft setzen zu wollen,
die die "Start"-Einstellungen (welche sich imho nur auf den Anwendungteil einer Acc-DB beziehen) außer Kraft setzt.

Bei der Verwendung von Acc2010/13 ist Imho der beste Schutz für ein Daten-Backend die Benutzung des Datenbankpasswortschutzes,
das bei der Verwendung eines sicheren Passwortes (bisher) nicht auszulesen ist.
Für alle vorherigen Versionen gibt es nur einbaubare Hürden und genausoviele Tools um diese zu umgehen/aufzuhebe(l)n und somit keinen echten Schutz.

Wer mit streng geheimen Daten witschaftet oder unter übersteigerte Paranoia leidet, sollte ein alternatives DBMS verwenden.

 

Hallo,
mein Problem ist das Frontend. Hier kann man sich von Außen jederzeit per Automatisierung ankoppeln. Wenn die BE-Tabellen fest eingebunden sind, dann sind alle Daten erreichbar.
Selbst wenn man sich die Mühe macht nur temporär per Code einzubinden hat man zumindest bei gebundenen Formularen vollen Zugriff.
Ja und auch ein DBMS mKn. ist da keine große Hilfe. Für den berechtigten Nutzer macht das keinen wesentlichen Unterschied.

 

Hallo an alle und Danke für die Antworten,

also:

mit 2 Mausklicks zur Accde :
In der Praxis sieht es bei mir so aus, dass ich in der Startphase des Projektes noch den einen oder anderen kleinen bug am Original-Kundensystem entdecke, dann möchte ich zügig sofort vor Ort im Programmcode / Formularentwürfen nachfeilen können. Das ginge ja dann nicht mit accde.
Natürlich könnte ich dann zweigleisig fahren und während der Umstrickerei temporär auch beim Kunden mit der accdb arbeiten, nach Abschluss des Vororteinsatzes dann aus dieser wieder die accde erzeugen.
Es gibt aber noch ein anderes Problemchen mit accde:
hier kann immer noch in den Tabellen- und Abfrageentwürfen geändert werden!!
Das ist mir dann zu heiß. Deshalb schon noch die Shift-Tasten-Blockade.

@ Jean Pierre:
Das gesamte Projekt ist bis jetzt erst noch gar nicht auf .mdw- Schutz umgebaut.
Ggf. kann ich das ja immer noch in einem späteren Schritt machen. Dann komme ich ggf. auf Dich zurück.
Es gibt im Übrigen den sehr speziellen Kundenwunsch, dass datenspezifische Zugriffsrechte eingerichtet werden sollen (stark vereinfacht: User A soll nur Datensatz 1 schreiben, User B DS 2 usw), das habe ich per VBA gelöst, die Baustelle läuft rund, aber dazu muss die entsprechende VBA Startprozedur auch zwingend einmal laufen, auch deshalb ist die Notwendigkeit der unterdrückten Shifttaste für mich wichtig.

@ Steffen / Marsu:
Application.UserControl probierte ich aus.
Ist Control eine Eigenschaft?
Kann man die auch setzen und nicht nur lesen, wenn ja, wie?
Der Versuch
Code:

im Direktfenster erzeugt die Fehlermeldung 2455:
Sie haben einen Ausdruck eingegeben, der einen ungültigen Verweis auf die USerControleigensdhaft enthält.

Um externen Zugriff zu unterbinden:
False oder True ?
Standard ist wohl True, für mein Ziel wäre doch dann False das richtige, oder?

 

Das sicherheitskonzept von access kann "nur" objektweise berechtigungen vergeben, also für die gesamte tabelle und nicht feldweise, und auch nicht datensatzweise. Daher ist deine Lösung die einzige die mir auch einfällt.

Naja, das hat nicht so viel mit den daten zutun, den die liegen im backend (vermute ich jetzt stark). Dafür ist das Berechtigungssystem gedacht.
Ziel der shift-taste ist es das Frontend zu "schützen". Also, damit nicht in ins navi-fenster zu gelangen, um dort aktions-abfragen anzustoßen oder formulare zu öffnen... oder nach zu schauen wo das backend liegt *wink.gif*

Gruß
JPA

 

Hallo,
unter #7 hat Marsu einen passenden Code gepostet, welcher in das AutoExec-Makro gehört.

Hilft aber nur gegen CreateObject().
DAO und GetObject() sind davon unbetroffen. Wie du DAO-Zugriff verhinderst hatte ich auch geschrieben.

Gegen GetObject sehe ich leider keine Chance *frown.gif* Ja und daran scheitern mMn alle Konzepte gegen berechtigte Nutzer.

 

Hallo Steffen,

IMHO gelten Deine Aussagen nur, wenn das BackEnd eine Access-Datenbank ist. Bei einem DBMS als Backend gibt es andere Möglichkeiten. Bei mir ist folgendes Vorgehen im Einsatz:

• Ich habe die Daten auf einen Datenbankserver ausgelagert. Bei mir ist es DB/2, das Vorgehen funktioniert aber grundsätzlich mit jedem per ODBC erreichenbaren Datenbankserver.
• Der Zugriff auf die Tabellen im BackEnd ist nur einem technische User gestattet. Dieser Account ist so eingestellt, dass man sich damit nicht anmelden darf. Der Account wird nur für die Komunikation mit der Datenbank verwendet.
• Die Tabellen vom Server habe ich in meiner Anwendung eingebunden. Dabei speichere ich die ODBC-Verbindungzeichenfolge. User-ID und Passwort werden allerdings nicht gespeichert.
• Die Anwendung wird als *.mde ausgeliefert. Wer die Anwendung mit gedrückter Shift-Taste öffnet, sieht zwar die eingebundenen Tabellen. Er kann aber nicht auf diese zugreifen. Dazu müsste er User-ID und PWD des technischen Users kennen.
• Im Startformular der Anwendung wird eine Prozedur ausgeführt, die mit der User-ID und dem PWD des technischen Users einen Zugriff auf den Datenbankserver macht. (Meistens rufe ich die Anzahl der DS in einer Tabelle ab.)
• Durch diesen initialen Zugriff wird per VBA eine Connection zum Datenbankserver erstellt. Access merkt sich diese Connection. Beim späteren Zugriff auf die Objekte mit der selben ODBC-Zeichenfolge wird diese Connection verwendet.

Für mich ist diese Verfahren ausreichend sicher. Wer die Anwendung startet, bekommt Zugriff auf die Daten, kann aber nicht mehr auf das Datenbankfenster zugreifen. Wer die Datenbank mit gedrückter Shift-Taste öffnet, sieht zwar die eingebundenen Tabellen, kann aber nicht auf diese zugreifen. Für mich, der User-ID und Passwort kennt, bietet das auch im Produktivbetrieb die Möglichkeit, direkt auf die Daten zuzugreifen.

CU

 

Hallo,

Nein, mMn. nicht.

Ein einfaches Beispiel:
Du hast ein Formular, welches alle relevanten Daten anzeigt.
Mit GetObject() gehe ich auf das FE und hole mir das Formular. Jetzt kann ich über das Recordset alle Daten auslesen und wenn die Berechtigung besteht auch alle Daten schreiben.

Ich vermute sogar, dass ich direkt auf die Tabellen gehen kann, nachdem die initiale Verbindung ja hergestellt wurde. Aber wie geschrieben, das wäre gar nicht notwendig.