Kurze Frage DSG §14

Re(16): Kurze Frage DSG §14

Codename 47 — Mon, 16 Apr 2007 17:23:34 GMT

gut. sehe nicht nur ich das so

Re(2): Kurze Frage DSG §14

bigboss007 — Mon, 16 Apr 2007 10:33:57 GMT

SUPPI...das nenn ich mal ne antwort!

VIELEN DANK!!

Re: Kurze Frage DSG §14

fleptin — Mon, 16 Apr 2007 09:59:47 GMT

UNBEFUGTEN NICHT ZUGÄNGLICH

bedeutet dass zB Rechnungsdaten, Stammdaten usw. nicht öffentlich einsehbar sind. D.h. Kunden-Login-Daten soll nur der Kunde erhalten. Das musst du nach dem "aktuellen technischen Stand" - so stehts im DSG - weitgehend sicherstellen. Verschlüsselte standardisierte Mails gibts nicht, aber einen Webshop kannst sehr wohl mit https nach dem Kundenlogin betreiben. Damit hättest du das soweit gewährleistet.

Weiters kennt das Datenschutzgesetz noch den Begriff Dienstleister, welchen Daten anvertraut werden aber diese nur im seinen beauftragten Umfang vewenden darf. Z.B. Weitergabe von Rechnungsdaten eines Nichtzahlers an ein Inkassobüro als Dienstleister. Oder ein Informatiker der mit der Betreuung der Shop-Datenbank beauftragt ist gilt auch als Dienstleister. Der darf für Wartungszwecke in die Datenbank eingreifen, sich aber nicht den Umsatz eines Kunden ausrechnen.

Re(15): Kurze Frage DSG §14

GrummelGrumpf — Sun, 15 Apr 2007 15:40:20 GMT

weiß gar ned ob geizhals alles annimmt

Na, das wäre aber eine Katastrophe, wenn unsere Nicks nicht durch Hochsicherheitspasswörter zu schützen wären!

Re(14): Kurze Frage DSG §14

Codename 47 — Sun, 15 Apr 2007 09:27:11 GMT

stimmt schon weiß gar ned ob geizhals alles annimmt... muss mal testen

Re(13): Kurze Frage DSG §14

GrummelGrumpf — Sun, 15 Apr 2007 05:44:50 GMT

setzt natürlich voraus das man sonderzeichen im passwort verwenden kann.

Wo man das nicht kann, wäre ein Passwort ohnehin unnötig. Ich weiß zwar, dass viele Programmierer schlampen, aber solche Blödheiten sollten doch vermieden werden können.

Re(12): Kurze Frage DSG §14

Codename 47 — Sat, 14 Apr 2007 21:11:18 GMT

verstehe worauf du hinaus willst, setzt natürlich voraus das man sonderzeichen im passwort verwenden kann.

wobei ich denke das auch das vorige unsichere passwort vor leuten schützt die einfach "ausprobieren" wenn du mit brute-force ansetzt ist halt immer die frage was dein system alles berücksichtigt.

Re(11): Kurze Frage DSG §14

GrummelGrumpf — Sat, 14 Apr 2007 20:46:43 GMT

und was wäre dagegen ein gutes pw??

Entschuldige, aber habe ich vorher vielleicht vergessen, zu schreiben, warum das erwähnte PW leicht zu knacken wäre? Nein? Also hast Du alle Anleitung, um ein besseres zu finden.

Z.B. bereits "Æ®hR³;€|6" wäre sicherer, obwohl weit kürzer.

Re(4): Kurze Frage DSG §14

\\ H // — Sat, 14 Apr 2007 20:16:47 GMT

Re(10): Kurze Frage DSG §14

Codename 47 — Sat, 14 Apr 2007 19:44:50 GMT

verstehe... und was wäre dagegen ein gutes pw??

Re(9): Kurze Frage DSG §14

GrummelGrumpf — Sat, 14 Apr 2007 19:43:33 GMT

meinst du zu kurz?

Nein, aber ausschließlich über die Tasatur leicht erreichbare und noch dazu nahe zueinander liegende Zeichen; deutliches Muster, das viel Zeit spart.

Re(13): Kurze Frage DSG §14

googleDork — Sat, 14 Apr 2007 10:36:37 GMT

Auch die DB selbst ist so stärker geschützt...

Denn du hast ja oft die Situation, daß zB aus dem Firmenlan die Metadaten gewartet werden (Produkte, Einkaufspreise) - und vom Webserver nur Aufträge eingebucht werden dürfen und eben vieles nicht gesehen werden darf.

Wenn der Webserver nur die Credentials kennt, die er braucht (und zB die Zugangsdaten für Admin-DB-Accounts dort nie hinterleg wurden) wird es für Angreifer wieder schwieriger.. Denn er könnte uU Buchungen tätigen, aber nicht mehr... Also zB nicht die DB löschen, ...

Problem ist hierbei, daß bei gehacktem Webserver man auch von wahrscheinlicher Privilege Escalation ausgehen muß - und daß der Webserver nun jemand Admin/root-Rechte erlaubt.

Daher muß der DB-Server so abgesichert sein, als ob er selbst direkt im INet wäre...

Beispiel Apache-SSL-Exploit - wie es ihn ja schon öfters gab - verheiratet mit dem ptrace-Bug aus den 2.4er-Kerneln.... (ok, altes Beispiel) |-)

Wenn die DB auf dem Server wäre, könnte der Angreifer alles mit der DB machen...

Wenn die DB aber in der DMZ liegt (und auf dem DB-Server hoffentlich kein Apache rennt) ist ein weiterer Angriff schwierig...

Re(12): Kurze Frage DSG §14

MG — Sat, 14 Apr 2007 10:26:40 GMT

Nicht ganz...
Natürlich gehst Du davon aus, daß der im Web erreichbare Server, dessen App,
... unsicher ist (sonst würdest Dir ja DMZ und ähnliches gar nicht erst
antun).

Deshalb beschränkst du ja die Möglichkeiten des Servers so stark es geht
Richtung DMZ:
- Zugang zu nur den Servern, auf die er hinmuß
- nur die Zugänge (Ports), die er unbedingt braucht
- nur die Credentials am Server, die er zwingend benötigt, ...
- innerhalb der Zugänge nur die Rechte, die er unbedingt haben muß (also nur
auf wenige Tabellen in nur wenigen DBs, die meisten Zugriffe ro, ...)
- zwischen Web- und DB-Server IDS/IPS

Genauso beschränkst du ja den DB-Server, daß er eben nach außen nur zum
Webserver übermitteln kann.

Das ändert aber nichts, dass in dem Moment wo die Anwendung am Webserver geknackt ist, der Zugriff auf die Datenbank funktioniert, wo immer sie auch liegt.

Durch geeignete Sicherheitsmaßnahmen bleiben die anderen Datenbanken auf dem DB Server davon unbeeindruckt. Das stimmt. Aber sehr oft hab ich für eine Anwendung sowieso einen eigenen DB Server. Da ist dann kein Sicherheitsunterschied zu einer ein Maschinenlösung gegeben.

Re(8): Kurze Frage DSG §14

Codename 47 — Sat, 14 Apr 2007 09:57:38 GMT

weswegen ist !§df§S4578GHZF$§&( ziemlich leicht zu knacken? meinst du zu kurz?

Re(13): Kurze Frage DSG §14

googleDork — Sat, 14 Apr 2007 09:43:33 GMT

Das ist aber etwas anderes als wenn du sagst, daß DB-Server grundsätzlich im INet sind, auch wenn sie in einer DMZ stehen....

Abgesehen davon bezweifel ich auch die These...

IT-Sicherheit hört natürlich beim Faktor Mensch auf... Ein Spion, der Sysadmin ist, ist nun mal eine potenzielle Gefahr. Trotz allem gibt es auch hier Schutzmechanismen (zB ausschließlich 4-Augenprinzip bei "heiklen" Tätigkeiten) sowie Prävenionsmechanismen (zB laufende Überwachung eigener, exponierter Mitarbeiter). Das bedeutet nichts anderes, als daß IT-Sicherheit wo enden muß - aber die Systemsicherheit ja nicht bei der IT-Sicherheit endet...

Beispiel im US-Militär:
Grundsatz "Need to know":
Kommandanten brauchen natürlich Zugriff auf Daten, mit denen sich ihre Mitarbeiter(Spezialisten) befassen. Einem Kommandanten wird aber keinesfalls (nicht einmal ein lesender) Zugriff auf diese Daten ermöglicht - er kann sie aber von seinen Untergebenen anfordern. Diese Untergebenen wiederum haben die Pflicht, diverse Auskünfte zu verweigern, wenn sie dem Kommandanten nicht zustehen...

Andernfalls wäre der Kommandant ja ein vordringliches Ziel - hätte man ihn umgedreht, hätte er ja Vollzugriff auf Aufklärung, Waffensysteme, was-auch-immer.

Sieh es ähnlich wie den Tresorraum einer Bank.
Der Tresorraum ist natürlich mal technisch geschützt... Natürlich gibt es legitime Zugriffe drauf - und natürlich müssen Banken organisatorisch die Aufgabe lösen zu verhindern, daß ein Fillialleiter mit ein paar Mille abhaut .

Meines Wissens nach ist diese Forderung ausreichend gut erfüllt - man hört seltenst von solchen Vorfällen

Re(11): Kurze Frage DSG §14

googleDork — Sat, 14 Apr 2007 09:33:53 GMT

Wenn die Applikation die am Internet hängt Lücken hat -und >90 von 100 Applikationen haben diese- ist alles weitere Makulatur.

Nicht ganz...
Natürlich gehst Du davon aus, daß der im Web erreichbare Server, dessen App, ... unsicher ist (sonst würdest Dir ja DMZ und ähnliches gar nicht erst antun).

Deshalb beschränkst du ja die Möglichkeiten des Servers so stark es geht Richtung DMZ:
- Zugang zu nur den Servern, auf die er hinmuß
- nur die Zugänge (Ports), die er unbedingt braucht
- nur die Credentials am Server, die er zwingend benötigt, ...
- innerhalb der Zugänge nur die Rechte, die er unbedingt haben muß (also nur auf wenige Tabellen in nur wenigen DBs, die meisten Zugriffe ro, ...)
- zwischen Web- und DB-Server IDS/IPS

Genauso beschränkst du ja den DB-Server, daß er eben nach außen nur zum Webserver übermitteln kann.

Der Webserver ist (IMHO!!!) ja nur deshalb beliebtestes Angriffsziel (wie du richtig sagst), weil man eben i.d.R. nicht von außen auf den Datenbankserver kommt. Angenommen, du willst die DB des Servers http://www.ziel.com angreifen - dann wird eben der Angriff zuerst dorthin stattfinden müssen. Wenn du allerdings wüßtest, daß db.ziel.com sein Datenbankserver wäre - und der von außen erreichbar ist - würdest Du Dich wohl sofort auf den stürzen. Meine (unbeweisbare) Vermutung wäre eben, daß du Recht hast, daß die Web-App primäres Ziel ist - allerdings nur deshalb, weil eben die Gefahr eines DB-Servers im INet eh jedem bekannt ist und drum keiner seinen DB-Server direkt verbindet.

Re(10): Kurze Frage DSG §14

MG — Sat, 14 Apr 2007 09:17:41 GMT

Das ist richtig, aber trotzdem weitgehend akademisch.
Weil die Angriffsvektoren dioe eine Rolle spielen, werden in aller Regel nicht über die Firewall oder den TCP Stack des Servers führen, sondern über die Datenbankapplikation/Webapplikation.

Und in dem Moment wo diese aufgemacht werden, spielt es eine eher untergeornete Rolle, ob die DB am lokalen Server, oder in einer DMZ hinter einer weiteren FW steht.

Wenn die Applikation die am Internet hängt Lücken hat -und >90 von 100 Applikationen haben diese- ist alles weitere Makulatur.

Re(6): Kurze Frage DSG §14

bigboss007 — Sat, 14 Apr 2007 08:55:17 GMT

endlich mal einer der sachlich argumentieren kann...DANKE dir!

Re(5): Kurze Frage DSG §14

MG — Sat, 14 Apr 2007 08:46:01 GMT

Käme so was vor Gericht, würde sich der Richter einen Sachverständigen holen, der diese Frage zu beurteilen ht. und was der zu einem 1234 Passwort sagen würde, ist wohl klar.

Interessanter wäre was er zu Bugs in der Anwendung sagen würde, die SQL-Injection zulassen, oder ähnliches. Das sind die eher interessanten Szenarien.

Re(3): Kurze Frage DSG §14

MG — Sat, 14 Apr 2007 08:40:10 GMT

Dann wird nach spätestens 24h das Datenschutzgesetz dein geringstes Problem sein... .

Re(7): Kurze Frage DSG §14

GrummelGrumpf — Fri, 13 Apr 2007 20:42:30 GMT

also ist 1234 schon ein Schutz...

Scherz? Warum kommen immer solch konstruierte Argumente? Ist doch ein ernstes Thema.

weil 1234 ist genau so zu bruten wie !§df§S4578GHZF$§&(

Nein. 1234 ist der spätestens fünfte RATEversuch, !§df§S4578GHZF$§&( ist (noch dazu ziemlich leicht) zu knacken. Den Unterschied möchte ich klavierspielen können.

Re(12): Kurze Frage DSG §14

Desolationrob — Fri, 13 Apr 2007 14:03:51 GMT

das ist genau das was ich ausdrücken will, 100% sicher gibt es nicht.Gibts einene Weg für erlaubten Datenverkehr, dann genauso einen für unerwünschten

Re(11): Kurze Frage DSG §14

edi666.com — Fri, 13 Apr 2007 13:53:51 GMT

Ich glaube, ihr denk in eien komplett falsche Richtung, ich denke hier an
sensible Daten die Mitarbeitern von aussen aber irgendwie zur verfügung
gestellt werden müssen. Bevor man sich dei Mühe macht und solche abgesicherten
Systeme knackt...krallt man sich doch lieber einen solchen Mitarbeiter und
nutzt seinen Zugang

das is aber wieder ein ganz anderes problem. der authentifizierungsprozess muss natürlich auch dementsprechend sicher sein. mit smartcards, verschlüsselung, etc. is man da schon auf der sicheren seite. wenn die benutzer ihre passwörter allerdings auf post its aufschreiben kompromitiert das die beste security policy.

Und so etwas ließe sich nur verhindern wenn der DB Server oder was auch immer
überhaupt nicht von aussen erreichbar wäre.

und wie kommst dann von aussen an die daten? über eine abhörsichere telefonleitung der nsa? über brieftauben?

Re(6): Kurze Frage DSG §14

bigboss007 — Fri, 13 Apr 2007 13:31:50 GMT

es steht ja drinnen ,,unbefungten nicht zugänglich"..

also ist 1234 schon ein Schutz...
weil 1234 ist genau so zu bruten wie !§df§S4578GHZF$§&(

verstehst du um was es mir geht?

Re(5): Kurze Frage DSG §14

GrummelGrumpf — Fri, 13 Apr 2007 10:34:20 GMT

es geht nur ums prinzip weil mir das juristendeutsch nicht ganz klar ist!

Das Juristendeutsch ist in dem Fall völlig egal. Du solltest nämlich nicht jeden Richter für vollkommen dämlich halten.

Du solltest Dir lieber die Frage stellen, mit welch treuherzigem Augenaufschlag Du eine solche "Sicherung" einem >14-jährigen Richter als "ausreichend" verkaufen könntest - und schwupps - hast Du Deine Frage auch schon selbst beantwortet.

Re(4): Kurze Frage DSG §14

bigboss007 — Fri, 13 Apr 2007 10:27:53 GMT

es geht nur ums prinzip weil mir das juristendeutsch nicht ganz klar ist!

Re(3): Kurze Frage DSG §14

GrummelGrumpf — Fri, 13 Apr 2007 10:25:09 GMT

also wenn ich den server sagen wir am internet hängen hab und ich hab den RDP
offen und ein fettes passwort ,,1234" fällt das dan unter ausreichend
gesichert??

Wer imstande ist, solche Fragen zu stellen, hat sich einen Arbeitsplatz weitab von jedem Server redlich verdient.

Re(10): Kurze Frage DSG §14

Desolationrob — Fri, 13 Apr 2007 09:37:26 GMT

aber irgendwie erfolgt ein zugriff drauf und dadurch ist der Server einfach nicht mehr vor Unbefugten geschützt.

Ich glaube, ihr denk in eien komplett falsche Richtung, ich denke hier an sensible Daten die Mitarbeitern von aussen aber irgendwie zur verfügung gestellt werden müssen. Bevor man sich dei Mühe macht und solche abgesicherten Systeme knackt...krallt man sich doch lieber einen solchen Mitarbeiter und nutzt seinen Zugang

Und so etwas ließe sich nur verhindern wenn der DB Server oder was auch immer überhaupt nicht von aussen erreichbar wäre.

Re(9): Kurze Frage DSG §14

rbr — Fri, 13 Apr 2007 09:10:52 GMT

Wenn es korrekt gemacht wird, dann muss der Datenbankserver keine Verbindung zum Internet haben (nur lokale IP, kein Gateway) und kann daher nicht direkt von außen angegriffen werden.

Re(8): Kurze Frage DSG §14

Desolationrob — Fri, 13 Apr 2007 06:56:24 GMT

natürlich ist es sicherer, er hängt dennoch am netz und ist somit potentiell gefährdet.

ich weiß wirklich nciht was daran so schwer zu kapieren ist

Re(7): Kurze Frage DSG §14

rbr — Thu, 12 Apr 2007 10:34:35 GMT

Doch. Informiere Dich einmal über DMZ, damit Du siehst welcher Sicherheitsvorteil dadurch entsteht.

http://de.wikipedia.org/wiki/Demilitarized_Zone

Re(7): Kurze Frage DSG §14

googleDork — Thu, 12 Apr 2007 08:28:48 GMT

Ahem... Doch.

Re(6): Kurze Frage DSG §14

Desolationrob — Thu, 12 Apr 2007 06:12:48 GMT

das spielt nicht geringste Rolle.

Re(5): Kurze Frage DSG §14

googleDork — Wed, 11 Apr 2007 18:31:32 GMT

Der DB-Server hängt dann eben nicht im Internet...
Sondern hat nur eine Verbindung "von draußen" - nämlich die vom Webserver.

Selbst wenn der Webserver also gehackt wird (und das ist ja der einzig von draußen erreichbare) - ist das Schadpotenzial geringer, weil dem ja nur ein Low-Provileged-DB-Account gestattet wird...

Re(4): Kurze Frage DSG §14

Desolationrob — Wed, 11 Apr 2007 07:17:37 GMT

öhm,beide lösungen laufen ja darauf hinaus das der DB Server am internet hängt, geht garnicht anders. Die verbindungen sind einfach nur abgesichert.

*klug*PIEP**
das beste wäre so und so ein MPLS VPN, da haben dann wirklich nur mehr die Leute zugriff die ihn brauchen.
Allerdings,100%ige Sicherheit gibt es nicht und kann es nie geben. Da müsste man den Server schon einmauern ohne eine einzige Verbindung nach draussen...wo er dann nicht grade viel Sinn macht.
*klug*PIEP*de*

Re(4): Kurze Frage DSG §14

bigboss007 — Tue, 10 Apr 2007 14:14:08 GMT

dann frag mal schnell deine oma

Re(3): Kurze Frage DSG §14

edi666.com — Tue, 10 Apr 2007 14:07:40 GMT

darauf kennt sogar meine oma eine antwort

Re(2): Kurze Frage DSG §14

bigboss007 — Tue, 10 Apr 2007 13:38:53 GMT

du musst nur sicherstellen, dass unbefugte keinen zugriff haben.

also wenn ich den server sagen wir am internet hängen hab und ich hab den RDP offen und ein fettes passwort ,,1234" fällt das dan unter ausreichend gesichert??

Re(3): Kurze Frage DSG §14

googleDork — Tue, 10 Apr 2007 13:36:05 GMT

Im einfachsten Falle wie im Lehrbuch:


                 INET
                   |
---------------FIREWALL-----------
                   | Web-Server
---------------FIREWALL-----------
DMZ:               | Datenbankserver
---------------FIREWALL-----------
Firmenlan:         | PCs, ....

Der Außendienstler kommuniziert via https mit dem Webserver... Wahlweise Webzugriff oder XML-Operationen aus einer Applikation.

Der Webserver kommuniziert Problemlos mit dem Datenbankserver mit nur dem einen User, den er kennen muß... Ein User, der auf fast alles einen ro-Zugriff hat...

Eine andere Lösung wäre natürlich, daß der Außendienstler via VPN-Client ins Firmenlan kommt - freilich mit einer Firewall dazwischen, um infizierte Außendienst-Lappies auszuschließen...

Re(3): Kurze Frage DSG §14

coke — Tue, 10 Apr 2007 13:33:48 GMT

über einen Portalserver der eine Verbindung zum DB-Server hat ?

Re(2): Kurze Frage DSG §14

Desolationrob — Tue, 10 Apr 2007 13:30:20 GMT

aha, und wie sollen dann zB Aussendienstler Kundendaten abfragen bzw. neue eintragen ? nur so als gaaaaanz einfaches beispiel

Re: Kurze Frage DSG §14

googleDork — Tue, 10 Apr 2007 12:43:19 GMT

Edi666 und Nagelfar haben komplett Recht...

Ich möchte aber hinzufügen, daß es in der Masse der Fälle sowieso eine schlechte Idee ist, eine Datenbank auf einem Internetserver zu betreiben (noch schlechter kann eigentlich nur sein, diese Datenbank auf einem shared-Server/vhost zu betreiben ).

Re: Kurze Frage DSG §14

edi666.com — Tue, 10 Apr 2007 12:20:02 GMT

du musst nur sicherstellen, dass unbefugte keinen zugriff haben. wo der server steht is wurst. wenn ein server ned am internet hängt kannst trotzdem nicht sicher sein, dass keiner daten ausspioniert.

Kurze Frage DSG §14

bigboss007 — Tue, 10 Apr 2007 12:12:34 GMT

So, da ich gerade übers Datenschutzgesetz gestolpert bin hab ich da ne schnelle Frage:
in § 14 steht:
daß ihre Verwendung ordnungsgemäß erfolgt und daß die Daten Unbefugten nicht zugänglich sind.
...
die Zugriffsberechtigung auf Daten und Programme und der Schutz der Datenträger vor der Einsicht und Verwendung durch Unbefugte zu regeln,

wie ist das eigentlich mit Benutzerdaten in verbindung mit einem webshop zu verstehen.

wenn es heisst UNBEFUGTEN NICHT ZUGÄNGLICH zu machen dann wäre das ja z.b. das internet.
also würde es bedeuten dass die datenbank mit den kundendaten NICHT am internet hängen dürfte oder??