Datenschutzoptionen verhindern Sicherheit

[PawelPopolski]

Hallo zusammen,

ich bin total irritiert. Bisher habe ich meine FE Datenbank immer so abgesichert, dass ich Navigation etc. ausgeschaltet habe, dann als ACCDE gespeichert und als letzten Schritt in den Dateioptionen die Einstellung "Vollständige Menüs zulassen" abgewählt habe.

User sind beim Start sofort im login-Form gelandet und das ganze Access Drumherum war weg und das war auch gut so.

Heute musste ich schockiert feststellen, dass alle meine FE's plötzlich im Backstage den Eintrag Datenschutzoptionen aufweisen. Hiermit kann ich jetzt problemlos wieder alles einschalten, was ausgeschaltet war. An den Code kommt zwar niemand, aber bei eingeschaltetem Navigationsbereich kann jeder User, unabhängig von seiner Berechtigung in Tabellen und Abfragen klicken, Aktionsabfragen ausführen, jedes Formular öffnen etc.

Frage: Habe ich da eine Einstellung übersehen, mit der ich meinen gewollten "Datenbank ist dicht" Zustand wieder herstellen kann?
Bin ich blind oder ist MS jetzt dem trumpischen Schwachsinn anheim gefallen?

Grüße
PawelPopolski

[Debus]

Hallo Pawel,

dazu habe ich mal die KI bemüht und folgende Antwort erhalten:

Ja, du bist nicht blind – Microsoft hat da tatsächlich was geändert und viele Access-Entwickler sind 2023/2024 drüber gestolpert.

Das ist die "Modern Backstage" bzw. die neuen "Datenschutzoptionen". Seit einem Office-Update ca. Mitte 2023 wird in ACCDE/MDE-Dateien der Backstage-Bereich nicht mehr komplett unterdrückt, wenn du "Vollständige Menüs zulassen" deaktivierst. Der Punkt `Datei > Datenschutzoptionen > Aktuelle Datenbank` ist jetzt immer da.

**Kurz: Dein "Datenbank ist dicht"-Setup per Häkchen reicht seitdem nicht mehr.**

### Warum passiert das?

Microsoft hat aus Compliance-Gründen den Backstage-Bereich umgebaut. Die Idee: User sollen ihre Datenschutz-Einstellungen immer erreichen können. Blöder Nebeneffekt: Darüber kommt man auch wieder an `Optionen > Aktuelle Datenbank` und kann Navigationsbereich, Menübänder etc. reaktivieren. Deine ACCDE schützt nur noch den VBA-Code, nicht mehr die Oberfläche.

### So machst du die DB wieder dicht

Du musst jetzt aktiv per Code die Shift-Taste + spezielle Access-Properties sperren. Die Häkchen in den Optionen reichen nicht mehr.

**1. Die 3 kritischen DB-Properties auf False setzen**

Das ist der neue Pflicht-Teil. Einmalig in einer ACCDB ausführen, bevor du die ACCDE erstellst:

```vba
Sub DatenbankAbdichten()
    Dim db As DAO.Database
    Set db = CurrentDb
   
    ' Fehler ignorieren falls Property noch nicht existiert
    On Error Resume Next
   
    ' Shift-Taste beim Start deaktivieren
    db.Properties("AllowBypassKey") = False
    If Err.Number = 3270 Then ' Property existiert nicht
        db.Properties.Append db.CreateProperty("AllowBypassKey", dbBoolean, False)
        Err.Clear
    End If
   
    ' Vollständige Menüs deaktivieren
    db.Properties("AllowFullMenus") = False
    If Err.Number = 3270 Then
        db.Properties.Append db.CreateProperty("AllowFullMenus", dbBoolean, False)
        Err.Clear
    End If
   
    ' Spezielle Access-Tasten deaktivieren - sperrt Backstage-Optionen
    db.Properties("AllowSpecialKeys") = False
    If Err.Number = 3270 Then
        db.Properties.Append db.CreateProperty("AllowSpecialKeys", dbBoolean, False)
        Err.Clear
    End If
   
    On Error GoTo 0
    MsgBox "Datenbank ist jetzt abgedichtet. Als ACCDE speichern!"
End Sub
```

`AllowSpecialKeys = False` ist der wichtigste: Der sperrt F11 für den Navigationsbereich und auch die meisten Backstage-Optionen, inkl. dem Weg zurück zu `Aktuelle Datenbank`.

**2. Runtime-Version nutzen als Alternative**

Wenn du es ganz hart willst: Gib deinen Usern nur die Access Runtime. Da gibt es von Haus aus keinen Backstage, keine Entwurfsansicht, kein F11. Nachteil: Du musst die Runtime auf allen Clients installieren.

**3. Navi-Bereich per Code ausblenden + sperren**

Zusätzlich im AutoExec-Makro oder Startformular:

```vba
DoCmd.NavigateTo "acNavigationCategoryObjectType"
DoCmd.RunCommand acCmdWindowHide
Application.SetOption "Show Hidden Objects", False
```

**4. Notfall-Schlüssel für dich als Entwickler**

Wenn `AllowBypassKey = False` ist, kommst du selbst auch nicht mehr mit Shift rein. Bau dir vorher eine versteckte Hintertür, z.B. eine separate ACCDB die die Properties per Code wieder auf True setzt:

```vba
Sub DatenbankOeffnen()
    Dim db As DAO.Database
    Set db = DBEngine.OpenDatabase("C:\Pfad\DeineFE.accdb")
    db.Properties("AllowBypassKey") = True
    db.Properties("AllowSpecialKeys") = True
    db.Close
End Sub
```

### Zu deiner Trump-Frage 😄

Ne, das ist kein politischer Schwachsinn, sondern DSGVO/GDPR-Paranoia. MS will sicherstellen dass jeder User seine Telemetrie/Diagnosedaten-Einstellungen sehen kann. Dass dabei 20 Jahre Access-Security-Praxis über den Haufen geworfen wird, war denen wohl egal.

**Checkliste für dein neues Vorgehen:**

1. In ACCDB: Alle 3 Properties per VBA auf False
2. Navigation, Menüband etc. wie gehabt in den Optionen ausschalten
3. Dann erst ACCDE erstellen
4. ACCDE testen: F11 darf nicht gehen, Backstage > Optionen sollte gesperrt sein

Damit bist du wieder so "dicht" wie früher. Der reine Haken bei "Vollständige Menüs" ist seit dem Update leider nur noch Deko.



Ich hoffe, dass hilft Dir weiter
Holger

[PawelPopolski]

Hallo und Danke für deine Mühe.

Vorweg der Hinweis, dass in der DB keine Fort Knox Sicherheit verlangt wird. Dann wäre Access auch tatsächlich eine schlechte Wahl.

Das hatte ich alles schon bei den früheren Versionen umgesetzt, ABER die meisten Einstellungen habe ich einfach durch händisches abschalten in den Optionen umgesetzt.

Ich werde das jetzt an mein Login Form heften.
Wenn es jetzt jemanden in die Datenschutzoptionen verschlägt, kann es dort gerne alles zurückstellen. "Gefährliche" Änderungen am System kann er (Warum gehe ich hier direkt von einem ER aus? ) aber nicht vornehmen, weil die meisten Änderungen erst nach Neustart wirksam werden...und beim Login werden sie wieder zurückgesetzt.

Danke, dass du mich auf den richtigen Weg gebracht hast!

Grüße,
PawelPopolski

[Knobbi38]

... weil die meisten Änderungen erst nach Neustart wirksam werden...und beim Login werden sie wieder zurückgesetzt.

Dann gibt das beim Login Formular nicht so richtig Sinn. Besser, man schreibt die Optionen zurück, kurz bevor Access beendet wird. Wer zuletzt schreibt hat gewonnen. 
Alternativ könnte man vielleicht den Backstagebereich neu definiere und dabei den Eintrag weglassen (ungetestet):

Code [Auswählen] Erweitern

<customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui">
  <!-- StartFromScratch löscht das gesamte Datei-Menü inkl. Datenschutzoptionen -->
  <ribbon startFromScratch="true">
    <tabs>
      <!-- Hier blenden Sie die Standard-Registerkarten (z.B. Start) wieder ein -->
      <tab idMso="TabHomeAccess" visible="true" />
    </tabs>
  </ribbon>
 
  <backstage>
    <!-- Hier definieren Sie, welche wenigen Befehle im Datei-Menü übrig bleiben sollen -->
    <button idMso="FileCloseDatabase" visible="true"/>
    <button idMso="FileExit" visible="true"/>
  </backstage>
</customUI>

Hier gibt es auch noch ein paar Informationen:
https://www.access-programmers.co.uk/forums/threads/securing-your-databases-a-tutorial.304340/

Knobbi38

[Debus]

Vielleicht macht das ja auch noch spaß

Holger

[PawelPopolski]

Wer zuletzt schreibt hat gewonnen. 

Guter Hinweis, werde ich so machen.

Alternativ könnte man vielleicht den Backstagebereich neu definiere und dabei den Eintrag weglassen (ungetestet):

Das teste ich vielleicht mal später. Bisher gab es überall die Info, dass man zwar das Ribbon, aber nicht den Backstage Bereich beeinflussen kann.

Vielleicht macht das ja auch noch spaß

Macht es   

Vielen Dank nochmal an euch
PawelPopolski

[werner budde]

Vielleicht macht das ja auch noch spaß

Holger

Mann Holger, das ist ja mal eine echte Rundum-Sorglos-Paket-Lösung.
Vielen Dank dafür.
Ich hatte mal vor Jahrhunderten von Don Karls FAQ 1.8 (https://www.donkarl.com/FAQ/FAQ1Grundlagen.htm#1.8 )
den Code übernommen zum Blockieren der Shft-Taste.
Aber Dein Tool ist ja deutlich umfassender.

Gruß
Werner

[Debus]

Hey, ich habe das ganze nochmal erweitert.

AllowBuiltInToolbars   Killt das alte Menüband komplett

AllowToolbarChanges    Man kann keine eigenen Symbolleisten anlegen

StartupShowDBWindow    Navibereich kommt beim Start nicht hoch

StartupShowStatusBar   Statusleiste unten ist weg

MeinDbKey              Eigener Schlüssel als Property


Der Key muss mindestens 12 Stellen haben haben und gewisse Kriterien erfüllen.
Es gibt eine Blacklist, die man selber Pflegen kann  hier:

Code [Auswählen] Erweitern

    arrBlacklist = Array("passwort", "password", "123456789012", "qwertzuiopü", "administrator")

Wichtig ist es muss der Verweis auf mscorlib.dll gesetzt sein.

Einfach mal ausprobieren und wenn noch was fehlt......


Holger

[werner budde]

Nochmals vielen Dank, Holger.
Aber einen kleinen Haken hat Deine Abschliessen-DB nun doch (das soll kein Gemeckere sein):

in Ereigniscoe des Buttons [Öffnen]:

Code [Auswählen] Erweitern

'If Not CheckEingabe(True) Then Exit Sub--> stillsetzen

' und ...

In deiner Proc SetDbProperty bei Übergabeparameter bAbschliessen = FAlse (= Öffnen):
   

Code [Auswählen] Erweitern

' Beim Öffnen: Hash prüfen
    ' If Not bAbschliessen Then
    '    sPruefHash = GetProp(db, "LockKeyHash", "")
    '    If sPruefHash <> GetSHA256(sEingegebenerKey) And sPruefHash <> "" Then
    '        db.Close
    '        UpdateStatus "Falscher Schlüssel!", vbRed
    '        MsgBox "Falscher Schlüssel!", vbCritical
    '        Me.txtKey.SetFocus
    '        Me.txtKey.SelStart = 0
    '        Me.txtKey.SelLength = Len(Me.txtKey)
    '        Exit Sub
    '    End If
    'End If
   
  
    Call SetProp(db, "AllowBypassKey", Not bAbschliessen)
    Call SetProp(db, "AllowSpecialKeys", Not bAbschliessen)
    Call SetProp(db, "AllowFullMenus", Not bAbschliessen)
    Call SetProp(db, "AllowShortcutMenus", Not bAbschliessen)
    Call SetProp(db, "AllowBuiltInToolbars", Not bAbschliessen)
    Call SetProp(db, "AllowToolbarChanges", Not bAbschliessen)
    Call SetProp(db, "StartupShowDBWindow", Not bAbschliessen)
    Call SetProp(db, "StartupShowStatusBar", Not bAbschliessen)
   
...
die oben mit Hochkommas eingeleitetetn Zeilen ebenfalls stillsetzen

Hier kann ein kriminell veranlagter Programmierer die Überprüfung der Fremd-DB-Eigenschaft LockKeyHash stillsetzen und trotzdem die Fremd-DB wieder öffnen.
Ich habe es getestet, es geht!!

Voraussetzung:
- dieser Bösewicht hat gute VBA-Kenntnisse
- er hat Deine Abschliessen-DB (z.B. hier downgeloadet), guckt sich den ganzen Code an..
- er versteht ihn und baut ihn wie oben gezeigt um
Aber das sind schon hohe Hürden.
Wenn Du möchtest, kann ich diesen Beitrag wieder in 1 oder 2 Stunden löschen, da ich Dir nicht in den Rücken fallen will!

Nochmals Danke.

[Debus]

Hallo Werner,

danke für den Hinweis, aber es ist ja auch nicht gedacht um kriminelle komplett auszugrenzen, denn das geht sowieso nicht wirklich :=)
Es sollte auch nur eine Hilfestellung für das Thema des Threads sein. Aber ich werde mir das ganze nochmal anschauen. Vielleicht geht ja noch was.

Und wenn man Ahnung von vba hat, dann kann man das ganze eh umgehen und wer kriminelle Handlungen vorhat, da gibt es ganz andere Programme.

Aber ich denke sowas ist hier nicht gefordert. Aber wenn Du das ganze abschliest und dann eine accde verteilst, sollte es doch einigermaßen dicht sein, oder? Und wenn Du dann alleine die Master accdb behälst ist doch alles wieder grün.

Sag mal wie Du das so siehst.

Ich glaube ich werde da noch einfach ein echtes DB Kennwort einbauen. Dann kann man auch mit dem Code nix anfangen ausser man kennt auch noch das Kennwort aber dann.....

Wäre das ein Ansatz?  Schau später mal rein werde ich noch umbauen. Ich werde den Key dann für die Verschlüsselung nehmen.

Holger

[werner budde]

Hallo Holger,

• Ja, ich bin da ganz bei Dir. An Hunderten anderen Stellen in diesem und andren Foren wird immer wieder gesagt, dass ein 100%-iger Schutz bei .accdb-Datenbanken wohl in der Tat so gut wie nicht möglich ist
• und das Konvertieren auf .accde, wie von Dir vorgeschlagen, hatte ich gar nicht mehr auf dem Schirm;
  
• wie Du schon schreibst, muss natürlich die Master.accdb vom DB-Ersteller gut verwahrt werden.

Schönes Wochenende Dir und allen anderen fleißigen Fragern und Helfern hier

[Debus]

Ich habe kann das mit der AES verschlüsselung einbauen, hat dann aber den Nachteil, dass man immer das KW eingeben muss um in der DB was zu tun. Daher werde ich es mal machen aber das mit der accde wird glaube ich reichen.

Holger

[werner budde]

Hallo Holger,

• Ja, ich bin da ganz bei Dir. An Hunderten anderen Stellen in diesem und andren Foren wird immer wieder gesagt, dass ein 100%-iger Schutz bei .accdb-Datenbanken wohl in der Tat so gut wie nicht möglich ist
• und das Konvertieren auf .accde, wie von Dir vorgeschlagen, hatte ich gar nicht mehr auf dem Schirm;
  
• wie Du schon schreibst, muss natürlich die Master.accdb vom DB-Ersteller gut verwahrt werden.
• Deine Idee mit dem DB-Kennwort hatte ich auch schon, aber:
  wenn die Fremd-DB bereits eines hat, kommt Du ohne die Kenntnis dieses aus der Abschliesen-DB nicht dran
• Der Ersteller der Fremd-DB müsst es mittels Deiner Abschliessen-DB erstmalig einrichten UND es in der Abschliessen-DB dauerhaft in einer TAb speichern
• ... dann wiederum kommen die nächsten Probleme, wenn die Kennwort-.gesicherte Fremd-DB im nachherein umbenannt / und in anderen Pfad verschoben wird etc.
• ... das wird ein Fass ohne Boden

Sorry, dieser Beitrag ist eine Wiederholung und Ergänzung des Beitrages #10.
Schönes Wochenende Dir und allen anderen fleißigen Fragern und Helfern hier

[Debus]

Hallo Werner und der Rest :=)


ich habe nun noch eine AES Verschlüsselung eingebaut. Aber ich denke die erste Version und dann als accde würde reichen, da es ansonsten immer umständlich ist mit KW eine DB zu öffnen.

Holger

[werner budde]

Guten Abend Holger,

Super, klappt alles.
Man könnte (Betonung auf könnte) Deinen letzten Stand ja als Ersteller noch selbst so erweitern,
dass die einzelnen properties in

Code [Auswählen] Erweitern

SetProp(db, "<propertyName>", False)im frmmain oder einem dem Button [Abschliessen] nachgeschalteten Formular mittels einzelner Kontrollkästchen der Ersteller der Fremd-DB selst auf True oder auf False setzen.
Aber das kann ja jeder, der hier mitliest und Deine Abschließen-DB aus #13 gesaugt hat,
dann selbst nach eigenem Gusto umsetzen, Du hast Dir erstmal ein Erholungswochenende verdient.
Nochmals Danke.

Ich bin heute 73, für mich kommt das alles leider 10 Jahre zu spät, damals hätte ich Dein Tool sehr gern schon gekannt und für diverse Acc-Projekte an Kunden gut einsetzen können.
Shit happens.

Schönes Wochenende Dir und allen anderen