Hallo, kann man die BAK’s der Onlinesicherung auch direkt mit Passwort/Aes256 verschlüsseln lassen?
Hallo boomboom,
diese Funktion ist nicht vorgesehen.
Mit freundlichen Grüßen aus Nürnberg
Christian Tölle
Service Systemplattform/Basisdienste Ausgabe
DATEV eG
Hallo Herr Tölle,
danke für die Antwort.
Ist denn da was geplant?
Letztlich lassen diese BAK's am leichtesten aus dem System ziehen, sofern irgendjemand darauf Zugriff erlangen sollte.
P.S.: ist das die Verschlüsselung, nur nicht nutzbar?
@Gelöschter Nutzer schrieb:
Letztlich lassen diese BAK's am leichtesten aus dem System ziehen, sofern irgendjemand darauf Zugriff erlangen sollte.
Aber es kann doch nur der Administrator auf die Backup Dateien zugreifen, der Schutz sollte ja ausreichend sein
1080091: Nur Administratoren und das lokale Systemkonto können den Inhalt des Sicherungsverzeichnisses kopieren. Wenn Ihre Datensicherung einen anderen Benutzer verwendet, gehen Sie wie folgt vor:
sollte... ein 50-stelliges Passwort und AES256 fänd ich besser.. komprimiert wird es ohnehin. Da kann man auch direkt ein Schloss dranhängen.
Hallo boomboom,
wir verwenden keine Verschlüsselung bei den bak-Dateien.
Unser Sicherheitskonzept hat siro dankenswerterweise gepostet.
Mit freundlichen Grüßen aus Nürnberg
Christian Tölle
Service Systemplattform/Basisdienste Ausgabe
DATEV eG
@siro schrieb:
Aber es kann doch nur der Administrator auf die Backup Dateien zugreifen, der Schutz sollte ja ausreichend sein
Und dank etwaiger und in der Vergangenheit bekannter Lücken, kann man auch normale Konten durch gezielte Angriffe mit den passenden Rechten versehen/hochstufen (Rechteausweitung).
Und wenn es sogar eine Option dazu gibt aber diese deaktiviert ist? Hm. DATEV steht doch immer für Hochsicherheit und Sicherheit über alles, dass die Usability sogar drunter leidet und hier lässt man Möglichkeiten aus? Hm.
Wenn ein Angreifer sich an dieser Stelle Rechte verschafft hat, dann interessieren ihn die SQL Backups sicherlich am wenigsten, da er sich dann seine Backups auch selber ziehen kann, bzw. steht dem Angreifer dann eh Tür und Tor offen.
Für die Verschlüsselung wird der Angreifer dann früher oder später sicherlich auch noch sorgen, ohne diesen Haken im SQL Manager. 😉
das dürfte aber eher auffallen… ich würde zusätzlich alles verschlüssen, was geht…
Und wenn man die Backups am anderen Ort speichern will, muss man sich beim gesamten Ort an sich um eine adäquate Verschlüsselung kümmern?
@Gelöschter Nutzer : Bei den heutigen (Ransomware) Angriffen, wäre ich mir nicht sicher, ob das tatsächlich mal eben so (und schnell) auffällt.
Hier wäre etwas, was die DATEV implementiert hat und stetig weiterentwickelt, damit sowas (schnellstmöglich) auffällt bzw. von vorneherein unterbunden wird: https://events.splunk.com/DATEV_MITRE_ATTCK
100% sicher kann man sich eh nie sein.. dennoch sollte man einfach soviel verschlüsseln, wie eben geht.. und das wäre in dem Fall nicht so schwer.
@Gelöschter Nutzer
sollte... ein 50-stelliges Passwort und AES256 fänd ich besser.. komprimiert wird es ohnehin. Da kann man auch direkt ein Schloss dranhängen.
"Vorne" die Haustür abschließen ist immer besser als "hinten" die Schubladen
Und dank etwaiger und in der Vergangenheit bekannter Lücken, kann man auch normale Konten durch gezielte Angriffe mit den passenden Rechten versehen/hochstufen (Rechteausweitung).
Es gibt zum Glück vielfältige Möglichkeiten den Administrator abzusichern, SmartCard, 2FA, Delegierung etc. das Netz ist voll davon
Und wenn man die Backups am anderen Ort speichern will, muss man sich beim gesamten Ort an sich um eine adäquate Verschlüsselung kümmern?
Wenn die Partition auf welcher die SQL DBs liegen nicht eh schon ver-Bitlockert ist, kann man ja die BAK auf eine Bitlocker geschützte Partition legen.
Und auch populäre NAS können Partitionen verschlüsseln
sollte... ein 50-stelliges Passwort und AES256 fänd ich besser.. komprimiert wird es ohnehin. Da kann man auch direkt ein Schloss dranhängen.
"Vorne" die Haustür abschließen ist immer besser als "hinten" die Schubladen
schon richtig, aber wenn die Tür geknackt wird und direkt dahinter das Gold offen rumliegt..
es wäre kein großer Aufwand diese BAK's direkt zu verschlüsseln und das verschafft ein kleines bisschen mehr Sicherheit..
@Gelöschter Nutzer ,
das Verhindern der Verschlüsselung durch Ransomware ist mir eindeutig wichtiger als die eigene Verschlüsselung der SQL-Online-Sicherung
Ransomware könnte auch verschlüsselte *.bak-Dateien bestimmt ohne Probleme zusätzlich neu verschlüsseln
... die Ganoven von der Ransomware-Front sind sicher nicht an den Inhalten der *.bak-Dateien interessiert, sondern nur am Lösegeld
@Gelöschter Nutzer schrieb:schon richtig, aber wenn die Tür geknackt wird und direkt dahinter das Gold offen rumliegt..
es wäre kein großer Aufwand diese BAK's direkt zu verschlüsseln und das verschafft ein kleines bisschen mehr Sicherheit..
Warum soll der Angreifer in den Keller gehen und den Tresor mit dem "verschlüsselten Gold" mitnehmen anstatt die unverschlüsselten live Daten abzuziehen?
Verschlüsseln der Backups ist ne tolle Sache und macht Sinn bzw. ist Pflicht, wenn diese außer Haus - bspw. in die Cloud oder auf entsprechende portable Medien - gehen.
Bei einer Kompromittierung der IT Infrastruktur helfen verschlüsselte Backups nicht.
@Gelöschter Nutzer schrieb:
schon richtig, aber wenn die Tür geknackt wird und direkt dahinter das Gold offen rumliegt..
es wäre kein großer Aufwand diese BAK's direkt zu verschlüsseln und das verschafft ein kleines bisschen mehr Sicherheit..
Das kann man jetzt endlos weiterspielen 😁
Aber der Grundgedanke ist: Die erste Hürde muss die Größte und möglichst sicher sein! Wie @janm schon geschrieben hat, wenn erstmal jemand als Administrator drin ist hat er ganz andere Möglichkeiten. Er könnte z.B. die Verschlüsselung der BAK auf einen anderen Wert ändern, ZACK 😎
Außerdem wäre dieser Eindringling ja gar nicht auf die BAK angewiesen, weil er hat ja direkten Zugriff auf die Originale!
Edit : Hergebrannt
wenn er denn weiss, wie…….
die neuste generation verschlüsselt gar nicht mehr, sondern zieht nur noch daten ab und erpresst mit veröffentlichung.. so meine letzte info.
@Gelöschter Nutzer schrieb:wenn er denn weiss, wie…….
Es "soll" da schon Fälle gegeben haben, wo in der Erpressungsmail Screenshots aus dem DATEV Arbeitsplatz samt Stammdaten Export im CSV beigefügt waren.
Aber gut, "die" wissen vermutlich nicht "wie"... 😉
sind ja mehr als einer…. 😉