Office: (Office 2010) Navigationsbereich ausblenden > SICHER ???

Eine etwas gegensätzliche Meinung:
Wenn das Backend die Integrität der Daten sicherstellt, ist das Frontend für die Sicherheit irrelevant.
Anders gesagt: Solange die Daten am Ende konsistent und fachlich korrekt sind, ist es völlig wurscht, ob der Benutzer sie mit einem Access-Frontend oder mit selbstgetippten SQL Statements in die DB geschrieben hat.

 

Man kann sich ja vieles Schönreden wenn man will. *wink.gif*

Sollte man mit Access Verknüpfungen verwenden, kann der User die Daten jedenfalls einfach absaugen.
Sollten bei den verknüpften Daten irgend welche Schreibrechte vorhanden sein, kann er sie auch unkontrolliert ändern.
Auch wenn die Daten konsistent bleiben, heißt das noch lange nicht, dass man sie nicht unkontrolliert manipuliert wurden.

Abgesehen davon, dass viel Business Logik in die DB verlegen müsste.

In der Praxis will ich aber nicht, dass ein User mit entsprechendem kriminellen Potential auf simple weise unkontrolliert an die Daten kommen kann.

Man kann das natürlich alles irgendwie erreichen.
Mit einem Bruchteil des Aufwandes geht das mit einer ordentlichen Entwicklungsumgebung. *wink.gif*

 

Nein, nicht viel Business Logik. - Alle!

 

Jetzt hast du meine Aufmerksamkeit. *Smilie

Und ihr macht das so?

Was ist mit den Verknüpfungen, bzw. DbEngine.Databases Auflistung?
Das Absaugen der Daten ist da doch so einfach.
Wird das als nicht änderbar hingenommen oder gibts da irgend welche Maßnahmen bei euch?

 

Ja, in einigen Projekten.

"Absaugen von Daten" - Die Formulierung, auch in der Folge, finde ich etwas seltsam. Mit was für Benutzern hast du bei deinen Kunden zu tun? Wäre es nicht besser denen zu kündigen, wenn man schon so fest damit rechnet, dass sie kriminelle Handlungen begehen?

Um dennoch auf die Frage einzugehen:
Das wurde noch nie von Kunden als Problem thematisiert. - Und ich weise durchaus auf diese Möglichkeit hin. - Bei den meisten Anwendungen wäre es übrigens überflüssig dafür irgendwelche Hintertüren zu verwenden, es gibt meist eine Export-Funktion in der Benutzeroberfläche über die ein Benutzer Daten exportieren kann, für die er Lese-Berechtigungen hat. An andere Daten kommt er auch nicht, wenn der die Anwendungsoberfläche umgeht.

Dass Benutzer Daten lesen, die sie für ihre Arbeit brauchen, kannst du natürlich nicht unterbinden.
Wenn es um besonders schützenswerte Daten geht, kann man Daten nur Datensatzweise anhand eines Aktenzeichens, KundenNr, BestellNr etc. abrufbar machen. Zusätzlich sollte man Audit-Funktionen implementieren, die genau dokumentieren welche Daten ein Benutzer wann abgerufen hat. Das kann man dann auch mit einem Warnsystem kombinieren, das anschlägt wenn ein Benutzer mehr/häufiger Daten abruft, als für sein normale Arbeit üblich ist. - Der Mehraufwand für ein solches System ist erheblich.

Dem widerspreche ich. - Eine Client-Anwendung auf einem Rechner der mehr oder weniger unter der Kontrolle des Benutzers steht ist kein Mechanismus für hohe Sicherheit wenn man eben diesen Benutzer als den Angreifer betrachtet.

 

Das ist ja nicht der Fall.
Der User hat keine Admin Rechte und kann auch nichts installieren.
Access öffnen, Excel anwerfen, verbinden, absaugen fertig.
Das geht in Null komma Nix, ohne irgendwelche speziellen Mittel, ohne PW zur DB.

Ich spreche davon, dass ein Mitarbeiter Daten klaut - aus welcher Motivation auch immer.
Dieses Szenario habe ich doch nur bei Access.

Wenn eine Anwendung eine verschlüsselte Verbindung zum Server hat, dann hat der User ohne Admin Rechte eine echte Hürde.

Und ja, ich weiß schon (zumindest einiges) was man alles dagegen machen kann.
Nur der Aufwand ist viel zu groß.

PS: Meine Kunden sind 26000 Mitarbeiter.

 

Die Hürde ist niedriger als du denkst. Für uns als Access/VBA-Entwickler sind die uns bekannten Schwachstellen einer Access/VBA-Anwendung die offensichtlichen Einfallstore. Ein Angreifer, der die Client-Anwendung mehr als Blackbox betrachtet und generische Angriffsvektoren verwendet sieht vermutlich gleichermaßen Schwachstellen in anderen Anwendungen.

Der Prozess deiner Anwendung wurde vom Benutzer gestartet und hält recht zwingend die Zugangsdaten für die Backend-DB im Klartext in seinem Adressraum im Arbeitsspeicher. - Es ist unmöglich den Zugriff darauf für den Benutzer komplett zu unterbinden.

Mit diesen Zugangsdaten erhält der Benutzer die maximalen Berechtigungen deiner Applikation in der DB. - Es mag etwas schwieriger sein die Zugangsdaten zu bekommen, dafür sind die Auswirkungen, wenn das gelingt, potenziell schwerwiegender.

 

Aber der Unterschied ist dir schon klar.
In einem Fall bin ich darauf angewiesen, dass das Passwort unverschlüsselt für mich zugänglich im Ram liegt.
Muss 100 MB oder mehr durchkämmen um etwas zu finden, dass möglicherweise ein Passwort ist.
Dann brauch ich eine Spezialsoftware - die der Mitarbeiter aber nicht installieren kann.

Beim Ram kann ich verschlüsseln - Memory Protection - nicht mein Gebiet, man könnte es überschreiben, wenn man auf Sicherheit wert legt.
Ich weiß nicht wie leicht man es da Hackern macht.

Bei Access brauch in gar nichts.
Wissen in recht kurzer Zeit herausfinden kann falls man sich nicht auskennt.

Ich hab grad nicht das Gefühl, dass diese Diskussion ehrlich geführt wird.

Aber sei's drum.
Ich arbeite ja auch beruflich damit und hab mir halt ein paar Gedanken gemacht.

Edit:
Das Windows insgesamt nur weniger Sicherheit anbietet ist mir klar.
Das Problem beginnt beim Betriebssystem.
Wie gut man das machen könnte weiß ich nicht.

 

I.d.R. tut es das.

Habe es 2-3 mal versucht, hat nie länger als 5 Minuten gedauert.

Nein

Guter Einstiegspunkt: Stichwort SecureString
RAM komplett verschlüsseln gegen den Benutzer, der den Prozess gestartet hat? - I don't think so!

OK. EOD.