Wer verschlüsselt Daten?

Tag zusammen,

ich stehe hier gerade vor dem Problem Kreditkartendaten zu speichern. In Anbetracht der aktuellen Fälle (Sony, Neckermann) frage ich mich wie ich diese Daten am besten sichere. Wenn ich hier so lese, dann ist das erste Problem die richtige Absicherung des SQL-Servers und Einstellung der Benutzerrechte. Die sensiblen Daten lägen aber immer noch im Klartex in der DB auf dem SQL-Server und könnten mit einer gestohlenen DB-Sicherung auch außer Haus wiederhergestellt und ausgelesen werden.

Timo hat ja in den NAV-Tools eine einfachere Verschlüsselung schon mal vorgestellt. Betrachtet Ihr das als ausreichend? Und ist der Aufwand gerechtfertigt dies z. B. für die Daten in DO Payment ... NAV-weit anzupassen? Gibt es eine einfachere Möglichkeit der Datenabsicherung (z. B. Verschlüsselung bestimmter Tabellen im SQL-Server mit Zertifikaten)? Wird es mit neuen NAV-Versionen hier eine Änderung geben?

Volker

Timo hat ja in den NAV-Tools eine einfachere Verschlüsselung schon mal vorgestellt. Betrachtet Ihr das als ausreichend?

Die von mir vorgestellten "Verschlüsselungen" sind in erster Linie dazu gedacht, bestimmte Daten vor den NAV-Anwendern zu "verschleiern".
Dies ist in der Regel völlig ausreichend, um ein "Supervisor-Passwort" o. ä. verschleiert in dem Feld abzulegen, so dass der NAV-Anwender über den Zoom nicht sofort das tatsächliche Passwort erkennen kann.
Von einer echten Verschlüsselung kann nicht gesprochen werden, da ein halbwegs versierter Kryptologe dies innerhalb kürzester Zeit entschlüsselt.
Einzige Ausnahme: Salted-MD5, jedoch lässt dies keine Wiederherstellung des ursprünglichen Ausgangswertes zu, da es einen verstärkten Hash-Wert darstellt.

Evtl. ist der Database Security Hardening Guide auf der NAV DVD das richtige für Dich.

Es macht sicherlich Sinn, den SQL Server nur für NAV zu nutzen und die Webservices (die benutzt Du ja auch) insoweit abzusichern, dass keine SQL Injection stattfinden kann.

Hi Jan,

Du meinst bestimmt den Security Hardening Guide. Da steht aber eigentlich nur allgemein gültiges drin (User-Rechte, Passwort-Richtlinie, Firewall,...). Zur eigenlichen Sicherheit steht da eigentlich nichts. Die Seite von Stryk (http://dynamicsuser.net/blogs/stryk/archive/2010/02/16/extended-database-hardening-nav-sql.aspx) bringt da erheblich tiefere Info. Aber die Daten bleiben da aber nach wie vor unverschlüsselt in der Datenbank. Im Prinzip reicht es ja aus eine fbk-Datei in die Hände zu bekommen (oder schlimmer aufgrund der User-Einstellung ggf. sogar selber zu ziehen) um sich dann bei der Rücksicherung selbst Superrechte zu geben; somit ist alles in der DB lesbar.

Übertreib ich vielleicht?

Volker

Hi Jan,

Du meinst bestimmt den Security Hardening Guide. Da steht aber eigentlich nur allgemein gültiges drin (User-Rechte, Passwort-Richtlinie, Firewall,...). Zur eigenlichen Sicherheit steht da eigentlich nichts. Die Seite von Stryk (http://dynamicsuser.net/blogs/stryk/archive/2010/02/16/extended-database-hardening-nav-sql.aspx) bringt da erheblich tiefere Info. Aber die Daten bleiben da aber nach wie vor unverschlüsselt in der Datenbank. Im Prinzip reicht es ja aus eine fbk-Datei in die Hände zu bekommen (oder schlimmer aufgrund der User-Einstellung ggf. sogar selber zu ziehen) um sich dann bei der Rücksicherung selbst Superrechte zu geben; somit ist alles in der DB lesbar.

Übertreib ich vielleicht?

Volker

Es gibt ja von SQL nativ eine "transparente" Verschlüsselung, aber ich weiß nicht, inwieweit die mit NAV kompatibel ist.
Problem an sich: Das nützt dir alles nichts, wenn jemand eine fbk ziehen kann. Damit hebelst du alle SQL-möglichen Schutzmechanismen aus.
Aber bzgl. Hack meinst Du eher einen direkten Serverangriff statt über ERP Software?
fbk's ziehen/einspielen darf sowieso kein einziger produktiv nutzer machen, sonst würde ja das ganze System lahmgelegt werden. Diese entsprechenden Rechte dürfen nur 2 versierte Nutzer haben. (Einer als Ersatz falls der andere dem "Truck-Faktor" zum Opfer fällt.)

Es gibt ja von SQL nativ eine "transparente" Verschlüsselung, aber ich weiß nicht, inwieweit die mit NAV kompatibel ist.

Das habe ich auch schon gelesen, aber noch nie etwas im Zusammenhang mit NAV.

Aber bzgl. Hack meinst Du eher einen direkten Serverangriff statt über ERP Software?

Ich lese immer wieder, dass der Großteil der Versuche von intern kommen. Ich glaube auch , dass in vielen Bereichen mal auf die schnelle Berechtigungen für ein Problemchen vergeben werden und nie mehr zurückgesetzt werden. Ich verweise mal nur auf die hier immer wieder auftauchende Situation, dass normale User db-owner-Rechte erhalten. Wenn ich dann noch sehen, dass wir hier immer mal wieder Excel-Tabellen erhalten, die komplette Kundenlisten enthalten oder Irrläufer mit kompletten Projekt-Kalkulationen ... da will ich an Kreditkarten-Daten gar nicht denken. Ich muss aber zugeben, dass der Ausgangpunkt meines Gedanken tatsächlich ürsprünglich von einer Absicherung nach außen ausging.

fbk's ziehen/einspielen darf sowieso kein einziger produktiv nutzer machen

Brauch man eine fbk-Sicherung im Rahmen von SQL eigentlich überhaupt noch?

Volker

Brauch man eine fbk-Sicherung im Rahmen von SQL eigentlich überhaupt noch?

Ja, z.B. wenn man nur Daten zurücksichern möchte oder nur einzelne Mandanten.

Hallo Volker,

Du kannst Kundendaten im Standard maximal über Zuständigkeitseinheiten filtern. Aber das könnte evtl. zu Dubletten führen, wenn jemand den Kunden nicht sieht, und den nochmal anlegt.
Deine Bedenken sind verständlich. Aber wenn ihr rein RTC anbietet, sind die Daten insofern sicher, da die Daten nie in Klartext angezeigt werden, wenn ich mich recht erinnere. Da kommt auch der RTC-Zoom nicht dahinter.

Gruß
Jan