46
Http vs. https im Intranet
Hallo zusammen,
ich wollte eine Konstallation zur Diskussion stellen, zu der mich eure Meinung interessiert.
In einem Unternehmen, mit ca 4000 Beschäftigten, gibt es ein Intranet.
Von der Startseite aus kommt man in weitere verschiedene Portale.
Unter anderem auch in eine zentrale Einkaufsplattfrom, welche die Eingabe von Benutzername und Passwort erfordert.
Die Startseite und verschiedene verlinkte Seiten/Portale sind nur über http erreichbar.
Ein Mitarbeiter des Unternehmen bemängelt dieses und schreibt der zuständigen IT ein Ticket.
Dieses wird mit dem Hinweis geschlossen, dass es "nur" das Intranet ist.
Bei mir rollen sich die Zehnägel auf, wenn ich das höre.
Ist das nicht schon ein Verstoß, bei dem der Datenschutzbeauftragte der Unternehmens informiert werden muss?
Für konstruktive Kommentare bin ich dankbar.
Grüße
Epi
ich wollte eine Konstallation zur Diskussion stellen, zu der mich eure Meinung interessiert.
In einem Unternehmen, mit ca 4000 Beschäftigten, gibt es ein Intranet.
Von der Startseite aus kommt man in weitere verschiedene Portale.
Unter anderem auch in eine zentrale Einkaufsplattfrom, welche die Eingabe von Benutzername und Passwort erfordert.
Die Startseite und verschiedene verlinkte Seiten/Portale sind nur über http erreichbar.
Ein Mitarbeiter des Unternehmen bemängelt dieses und schreibt der zuständigen IT ein Ticket.
Dieses wird mit dem Hinweis geschlossen, dass es "nur" das Intranet ist.
Bei mir rollen sich die Zehnägel auf, wenn ich das höre.
Ist das nicht schon ein Verstoß, bei dem der Datenschutzbeauftragte der Unternehmens informiert werden muss?
Für konstruktive Kommentare bin ich dankbar.
Grüße
Epi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1018762273
Url: https://administrator.de/contentid/1018762273
Ausgedruckt am: 05.11.2024 um 00:11 Uhr
46 Kommentare
Neuester Kommentar
Ehrlich gesagt würde ich da einfach mal fragen ob ihr sonst keine Langeweile habt. Klar wäre https auch da natürlich schöner - aber im "internen" Netz ist die Angriffswahrscheinlichkeit da ja eher überschaubar weil es nur über eure Infrastruktur läuft. Und diejenigen die darauf Zugriff haben sollten auch die Fähigkeit haben anders an die Daten zu kommen (im Zweifel nen Keylogger aufm PC installieren). Klar könnte man beim WLAN z.B. auch versuchen da mitzuschneiden - aber auch das ist vom Risiko her ja überschaubar weil es auch da leichtere Wege gibt an die Passwörter zu kommen (z.B. indem man sich einfach neben dem Kollegen stellt und beim Anmelden kurz auf die Tastatur guckt bzw. nach Feierabend den Schreibtisch kurz "inspiziert").
Ich kenne natürlich auch die Ansätze "alles muss https sein", "muss nen gültiges Zertifikat haben",... - die meistens dann spätestens daran scheitern wenns irgendwo doch die billige Plastikbox aus China trifft wo es seid Jahren keine Firmware mehr gibt aber die eben irgendwas spezielles macht...
WENN man das schon wirklich absichern will - dann würde ich eher in die Richtung 2FA gehen statt auf http / https zu gucken. Denn ganz ehrlich - lass doch jemanden das Passwort hacken, wenns nich über den 2ten Faktor bestätigt wird kann der sich damit auch den Ar... abwischen. Da kannst du dann sogar das Passwort 1234 zulassen - und es ist trotzdem kein grösseres Problem. Und wenn der zweite Faktor nicht grad auf dem PC ist sondern z.B. Smartphone,... dann hilft auch die Schreibtisch-Inspektion nicht wirklich weiter.
Wenns schön sein soll dann kannst ja https mit nem Self-Signed machen, das für 20 Jahre gültig ist und auf den PCs per GPO als "vertrauenswürdig" eingebaut wird. Das geht halt nur bei den Rechnern die sich auch um ne GPO kümmern... (z.B. keine MACs, keine Linux, keine Smartphones,...). Und das ganze ist natürlich nur dann gültig wenn sichergestellt ist das ihr nur intern bzw. per VPN auf die Server kommt - wenns natürlich erreichbare Server via Internet sind sieht das ganze anders aus...
Ich kenne natürlich auch die Ansätze "alles muss https sein", "muss nen gültiges Zertifikat haben",... - die meistens dann spätestens daran scheitern wenns irgendwo doch die billige Plastikbox aus China trifft wo es seid Jahren keine Firmware mehr gibt aber die eben irgendwas spezielles macht...
WENN man das schon wirklich absichern will - dann würde ich eher in die Richtung 2FA gehen statt auf http / https zu gucken. Denn ganz ehrlich - lass doch jemanden das Passwort hacken, wenns nich über den 2ten Faktor bestätigt wird kann der sich damit auch den Ar... abwischen. Da kannst du dann sogar das Passwort 1234 zulassen - und es ist trotzdem kein grösseres Problem. Und wenn der zweite Faktor nicht grad auf dem PC ist sondern z.B. Smartphone,... dann hilft auch die Schreibtisch-Inspektion nicht wirklich weiter.
Wenns schön sein soll dann kannst ja https mit nem Self-Signed machen, das für 20 Jahre gültig ist und auf den PCs per GPO als "vertrauenswürdig" eingebaut wird. Das geht halt nur bei den Rechnern die sich auch um ne GPO kümmern... (z.B. keine MACs, keine Linux, keine Smartphones,...). Und das ganze ist natürlich nur dann gültig wenn sichergestellt ist das ihr nur intern bzw. per VPN auf die Server kommt - wenns natürlich erreichbare Server via Internet sind sieht das ganze anders aus...
Hallo maretz,
danke für deinen Beitrag.
Wie siehst du die Problematik, wenn Hacker im Netz sind, dass sie dann weitere Passwörter abgreifen und das bei so einer Struktur halt leicht.
Wir machen zur Demostration, gerne ftp und zeichnen mit Wireshark auf und da hast du halt User und PW im Klartext, sehr einfach.
Grüße
danke für deinen Beitrag.
Ehrlich gesagt würde ich da einfach mal fragen ob ihr sonst keine Langeweile habt.
Wie siehst du die Problematik, wenn Hacker im Netz sind, dass sie dann weitere Passwörter abgreifen und das bei so einer Struktur halt leicht.
Wenns schön sein soll dann kannst.......
Es geht bei https nicht darum, dass ein Zertifikat angezeigt wird, sondern dass der Datenstrom verschlüsselt ist.https mit nem Self-Signed machen, das für 20 Jahre gültig ist
So sehe ich das auch, dann ist die Übertragung verschlüsselt.Wir machen zur Demostration, gerne ftp und zeichnen mit Wireshark auf und da hast du halt User und PW im Klartext, sehr einfach.
Grüße
Zitat von @maretz:
Ehrlich gesagt würde ich da einfach mal fragen ob ihr sonst keine Langeweile habt. Klar wäre https auch da natürlich schöner - aber im "internen" Netz ist die Angriffswahrscheinlichkeit da ja eher überschaubar weil es nur über eure Infrastruktur läuft.
Ehrlich gesagt würde ich da einfach mal fragen ob ihr sonst keine Langeweile habt. Klar wäre https auch da natürlich schöner - aber im "internen" Netz ist die Angriffswahrscheinlichkeit da ja eher überschaubar weil es nur über eure Infrastruktur läuft.
Damit wäre alles gesagt, was schief läuft in deutschen Unternehmensnetzwerken. Wenn alles so zusammengepfuscht ist braucht man sich über erfolgreiche Attacken auf niedrigstem Level nicht wundern.
Am besten du gehst zurück in 1990, da hattest du mit der Einstellung kein Problem. Sorry, nur ein Ausdruck des zynischen Eindrucks, den du hier von dir machst.
Bei mir rollen sich die Zehnägel auf, wenn ich das höre.
gut so!
Ist das nicht schon ein Verstoß, bei dem der Datenschutzbeauftragte der Unternehmens informiert werden muss?
Probieren solltest du es, obwohl die DSGVO da oftmals ein wahnsinnig zahnloser Tiger ist. Ggf. externe Stellen oder auch einfach mal prüfen, ob das Unternehmen sich gewisser Normen verschrieben hat.
Go for it!
PS: Es gibt mittlerweile einige Regeln für die Cybersicherheit, diese umfassen per „technische und organisatorische“ Maßnahmen geschützt werden.", dazu gehört im wesentlichen, in mehreren Kontexten genannt, die Verschlüsselung.
1
Hallo,
ich hab's jetzt noch nicht ganz verstanden. Ist nur die Startseite unverschlüsselt oder die Anmeldung und der Datentransfer nach der Anmeldung.
Wenn's denn nur die Startseite ist werden ja keine Personenbezogenen Daten übertragen und somit kein Problem, zumindest aus meiner Sicht. Die Erläuterung dann vom Support, ist ja nur Intranet ist aber dumm. Und lädt gerade dazu ein das sich Leute beschweren.
ich hab's jetzt noch nicht ganz verstanden. Ist nur die Startseite unverschlüsselt oder die Anmeldung und der Datentransfer nach der Anmeldung.
Wenn's denn nur die Startseite ist werden ja keine Personenbezogenen Daten übertragen und somit kein Problem, zumindest aus meiner Sicht. Die Erläuterung dann vom Support, ist ja nur Intranet ist aber dumm. Und lädt gerade dazu ein das sich Leute beschweren.
Hallo Mystery-at-min,
Einfacher wie hier, mit einem Packetsniffer an Passwörter zu kommen, kann es nicht sein.
Ich denke sogar, dass die Nutzer der Plattform einen Anspruch haben, dass ihre Passwörter verschlüsselt übertragen werden.
Aber da bin ich mir nicht sicher, wie das auch rechtlich (DSGVO) aussieht.
Grüße
Damit wäre alles gesagt, was schief läuft in deutschen Unternehmensnetzwerken. Wenn alles so zusammengepfuscht ist braucht man sich über erfolgreiche Attacken auf niedrigstem Level nicht wundern.
Denke ich auch.Einfacher wie hier, mit einem Packetsniffer an Passwörter zu kommen, kann es nicht sein.
Ich denke sogar, dass die Nutzer der Plattform einen Anspruch haben, dass ihre Passwörter verschlüsselt übertragen werden.
Aber da bin ich mir nicht sicher, wie das auch rechtlich (DSGVO) aussieht.
Grüße
Zitat von @wiesi200:
Hallo,
ich hab's jetzt noch nicht ganz verstanden. Ist nur die Startseite unverschlüsselt oder die Anmeldung und der Datentransfer nach der Anmeldung.
Hallo,
ich hab's jetzt noch nicht ganz verstanden. Ist nur die Startseite unverschlüsselt oder die Anmeldung und der Datentransfer nach der Anmeldung.
Die Startseite und verschiedene verlinkte Seiten/Portale sind nur über http erreichbar.
hört sich nach generischem an.
Zitat von @Epigenese:
Hallo Mystery-at-min,
Einfach wie hier, mit einem Packetsniffer an Passwörter zu kommen, kann es nicht sein.
Ich denke sogar, dass die Nutzer der Plattform einen Anspruch haben, dass ihre Passwörter verschlüsselt übertragen werden.
Aber da bin ich mir nicht sicher, wie das auch rechtlich (DSGVO) aussieht.
Grüße
Hallo Mystery-at-min,
Damit wäre alles gesagt, was schief läuft in deutschen Unternehmensnetzwerken. Wenn alles so zusammengepfuscht ist braucht man sich über erfolgreiche Attacken auf niedrigstem Level nicht wundern.
Denke ich auch.Einfach wie hier, mit einem Packetsniffer an Passwörter zu kommen, kann es nicht sein.
Ich denke sogar, dass die Nutzer der Plattform einen Anspruch haben, dass ihre Passwörter verschlüsselt übertragen werden.
Aber da bin ich mir nicht sicher, wie das auch rechtlich (DSGVO) aussieht.
Grüße
https://www.datenschutz-wiki.de/Technische_und_organisatorische_Ma%C3%9F ...
Bau darauf auf.
Hallo wiesi200,
Die Startseite ist http und z.B. ein auf der Startseite verlinktes internes Einkaufsportal mit Eingabe von User und PW, ist auch http.
Das finde ich halt grenzwertig, bzw. fahrlässig.
Habe ich so auch auf die Schilderung zurückgemeldet.
Grüße
ich hab's jetzt noch nicht ganz verstanden.
Ist nur die Startseite unverschlüsselt oder die Anmeldung und der Datentransfer nach der Anmeldung.
Ist nur die Startseite unverschlüsselt oder die Anmeldung und der Datentransfer nach der Anmeldung.
Die Startseite ist http und z.B. ein auf der Startseite verlinktes internes Einkaufsportal mit Eingabe von User und PW, ist auch http.
Das finde ich halt grenzwertig, bzw. fahrlässig.
Habe ich so auch auf die Schilderung zurückgemeldet.
Grüße
Zitat von @Mystery-at-min:
https://www.datenschutz-wiki.de/Technische_und_organisatorische_Ma%C3%9F ...
Bau darauf auf.
Zitat von @Epigenese:
Hallo Mystery-at-min,
Einfach wie hier, mit einem Packetsniffer an Passwörter zu kommen, kann es nicht sein.
Ich denke sogar, dass die Nutzer der Plattform einen Anspruch haben, dass ihre Passwörter verschlüsselt übertragen werden.
Aber da bin ich mir nicht sicher, wie das auch rechtlich (DSGVO) aussieht.
Grüße
Hallo Mystery-at-min,
Damit wäre alles gesagt, was schief läuft in deutschen Unternehmensnetzwerken. Wenn alles so zusammengepfuscht ist braucht man sich über erfolgreiche Attacken auf niedrigstem Level nicht wundern.
Denke ich auch.Einfach wie hier, mit einem Packetsniffer an Passwörter zu kommen, kann es nicht sein.
Ich denke sogar, dass die Nutzer der Plattform einen Anspruch haben, dass ihre Passwörter verschlüsselt übertragen werden.
Aber da bin ich mir nicht sicher, wie das auch rechtlich (DSGVO) aussieht.
Grüße
https://www.datenschutz-wiki.de/Technische_und_organisatorische_Ma%C3%9F ...
Bau darauf auf.
Danke dir, das gebe ich bei Gelegenheit mal weiter.
Würde mal sagen dass das relativ eindeutig ist.
Grüße
Moin,
Die Frage könnte dir der Datenschutzbeauftragte des Unternehmens ganz leicht beantworten. Wenn er gemein ist, zeigt er dir nur die Risikoanalyse. Wenn er nett ist, bespricht er sie mit dir.
Gruß
C.C.
Die Frage könnte dir der Datenschutzbeauftragte des Unternehmens ganz leicht beantworten. Wenn er gemein ist, zeigt er dir nur die Risikoanalyse. Wenn er nett ist, bespricht er sie mit dir.
Gruß
C.C.
Zitat von @Epigenese:
Hallo zusammen,
ich wollte eine Konstallation zur Diskussion stellen, zu der mich eure Meinung interessiert.
In einem Unternehmen, mit ca 4000 Beschäftigten, gibt es ein Intranet.
Von der Startseite aus kommt man in weitere verschiedene Portale.
Unter anderem auch in eine zentrale Einkaufsplattfrom, welche die Eingabe von Benutzername und Passwort erfordert.
Die Startseite und verschiedene verlinkte Seiten/Portale sind nur über http erreichbar.
Ein Mitarbeiter des Unternehmen bemängelt dieses und schreibt der zuständigen IT ein Ticket.
Dieses wird mit dem Hinweis geschlossen, dass es "nur" das Intranet ist.
Bei mir rollen sich die Zehnägel auf, wenn ich das höre.
Ist das nicht schon ein Verstoß, bei dem der Datenschutzbeauftragte der Unternehmens informiert werden muss?
Für konstruktive Kommentare bin ich dankbar.
Hallo zusammen,
ich wollte eine Konstallation zur Diskussion stellen, zu der mich eure Meinung interessiert.
In einem Unternehmen, mit ca 4000 Beschäftigten, gibt es ein Intranet.
Von der Startseite aus kommt man in weitere verschiedene Portale.
Unter anderem auch in eine zentrale Einkaufsplattfrom, welche die Eingabe von Benutzername und Passwort erfordert.
Die Startseite und verschiedene verlinkte Seiten/Portale sind nur über http erreichbar.
Ein Mitarbeiter des Unternehmen bemängelt dieses und schreibt der zuständigen IT ein Ticket.
Dieses wird mit dem Hinweis geschlossen, dass es "nur" das Intranet ist.
Bei mir rollen sich die Zehnägel auf, wenn ich das höre.
Ist das nicht schon ein Verstoß, bei dem der Datenschutzbeauftragte der Unternehmens informiert werden muss?
Für konstruktive Kommentare bin ich dankbar.
Nun - das kommt eben auf eure restliche Infrastruktur an. WENN ein Angriff erfolgreich war dann würde ich mal davon ausgehen das bei der Fülle an Daten eine interne Webplattform euer kleinstes Problem ist. Worauf würde "ich" gehen? Auf Mails z.B. (da stehen ja oft genug die Passwörter bereits drin weil die ja per Mail zugesandt werden - und natürlich löscht jeder diese Mails ...). Oder man schaut mal an den beliebten Orten nach Dateien mit der Endung "txt" - und schon wird man eben auf dem Desktop gerne fündig weil dort die Text-File völlig unverschlüsselt mit allen Passwörtern liegt die der Anwender so braucht - weil der idR. keine Lust hat sich das zu merken und es bequem auf den Desktop legt.
Und ja - natürlich kann man Passwörter sniffen... Was aber einen Zugang zur Infrastruktur erfordert da der Switch eine exklusive Verbindung schaltet. Somit sollte das eigentlich nur der Admin können - der aber eben auch wieder direkten Zugang zu den Mails, ggf. sogar zu den Passwörtern usw. haben wird oder eben nen Key-Logger auf den PC pustet (elegant im Hintergrund...).
Weiterhin sind grad "intern" die meisten Angriffe eben gar nicht so technisch komplex - da wird der Kollege im Urlaub angerufen "du, Kunde Meyer hat eben angerufen, der brauch dringend noch mal ne Mail die er versehentlich gelöscht hat... gibst mir mal dein Passwort das ich dem die neu schicken kann" - und schon hat man das oft genug... wenns nich eh einfach direkt unter der Tastatur steht.
Und selbst wenn man jetzt eine "offene" Infrastruktur aussieht (-> zum Thema "Passwörter verschlüsselt übertragen"): Hier sollte das interne Netzwerk ja eh nicht über ein komplett offenes WLAN erreichbar sein sondern min. mittels aktueller WLAN-Stds verschlüsselt sein, oder? Klar - wenn ich das WLAN wie CB-Funk betreibe und keinerlei WPA2/3 o.ä. verwende siehts auch anders aus - aber auch dann ist die http-Seite idR. das kleinste Problem.
Dazu kommt das es idR. bei solchen Dingen wie z.B. einer Einkaufs-Seite für gewöhnlich nen Prozess dahinter gibt. Wenn ich z.B. bei meiner letzten Firma mich da angemeldet habe hätte ich natürlich locker 20 Laptops, Kiloweise Software usw. zusammenklicken können. Dummerweise gab es auch da schon ne 2FA - genannt "Personal-Chef" der das auch freigeben musste. Damit wäre der Einkauf schon wieder storniert worden bevor der erste auch nur nen Kugelschreiber liefert...
Und ja - ich sehe das ganze recht realistisch weil ich ein Passwort generell für keinen Schutz halte. Dabei ist es nahezu egal ob du nun als Passwort "1234" oder "jfalösdfjsal$"!" nimmst, DAS ist nur bei Brute-Force relevant. Mit etwas social engineering kommt man da schon recht weit - und wo das nicht reicht guckt man sich halt die Rechner an. Und je komplexer die Passwörter umso besser - weils vermutlich im Browser gespeichert wird oder eben irgendwo im Plain-Text rumliegt... Das hat auch nix mit "1990" zu tun sondern damit das die meisten Anwender eben nur den Rechner nutzen wollen... Dann lieber eine saubere 2FA - und dann brauchst du schon sehr zielgerichtete Angriffe um da was zu werden. Und hier können die lustigen "Super-Security-Admins" sich ausdenken was die wollen -> EINES hat sich nämlich auch seid 1990 nicht verändert: Die Person VORM PC ist das beste Mittel um ins Netzwerk zu kommen...
2
@maretz,
ich lese da nur Nebelkerzen.
Es muss dabei nicht nur um Passwörter gehen, was ist mit Personenbezogenen Daten? Eine WLAN Verschlüsselung ist also gut, eine HTTPS Verschlüsselung nur Aufwand? Was willst du damit schönreden? - Geht es um dein Unternehmen oder sind die Webservices dort, wo du arbeitest genau so stümperhaft aufgesetzt? Sorry, deine Argumente kannst allesamt in die Tonne treten. Sie sind nicht alle schlecht, aber komplett irrelevant. (2fa über http? - Schlechter Witz - noch nie gesehen.)
ich lese da nur Nebelkerzen.
Es muss dabei nicht nur um Passwörter gehen, was ist mit Personenbezogenen Daten? Eine WLAN Verschlüsselung ist also gut, eine HTTPS Verschlüsselung nur Aufwand? Was willst du damit schönreden? - Geht es um dein Unternehmen oder sind die Webservices dort, wo du arbeitest genau so stümperhaft aufgesetzt? Sorry, deine Argumente kannst allesamt in die Tonne treten. Sie sind nicht alle schlecht, aber komplett irrelevant. (2fa über http? - Schlechter Witz - noch nie gesehen.)
Zitat von @Mystery-at-min:
@maretz,
ich lese da nur Nebelkerzen.
Es muss dabei nicht nur um Passwörter gehen, was ist mit Personenbezogenen Daten? Eine WLAN Verschlüsselung ist also gut, eine HTTPS Verschlüsselung nur Aufwand? Was willst du damit schönreden? - Geht es um dein Unternehmen oder sind die Webservices dort, wo du arbeitest genau so stümperhaft aufgesetzt? Sorry, deine Argumente kannst allesamt in die Tonne treten. Sie sind nicht alle schlecht, aber komplett irrelevant. (2fa über http? - Schlechter Witz - noch nie gesehen.)
@maretz,
ich lese da nur Nebelkerzen.
Es muss dabei nicht nur um Passwörter gehen, was ist mit Personenbezogenen Daten? Eine WLAN Verschlüsselung ist also gut, eine HTTPS Verschlüsselung nur Aufwand? Was willst du damit schönreden? - Geht es um dein Unternehmen oder sind die Webservices dort, wo du arbeitest genau so stümperhaft aufgesetzt? Sorry, deine Argumente kannst allesamt in die Tonne treten. Sie sind nicht alle schlecht, aber komplett irrelevant. (2fa über http? - Schlechter Witz - noch nie gesehen.)
Ok - ich weiss zwar nicht warum du meinst gleich so aggressiv reagieren zu müssen - scheint so das eine Diskussion nur dann erlaubt ist wenn sie deine Meinung wiederspiegelt...
Wenn du nämlich genau liest dann wirst du merken das die Aussage ist das es eher auf den Rest ankommt und das http(s) noch das geringste Problem ist. Was bringt dir denn genau das https gegen einen Hacker im Netzwerk wenn die Passwörter eh im Google Chrome gespeichert sind (und ggf. sogar noch die Sync mit dem persönlichen Konto an ist so das der Rechner zuhause dieselbe Passwort-Liste hat - welcher ja viel leichter angegriffen werden kann)? Ausser das der besagte Hacker eben dann über eine gesicherte Verbindung die Daten ausliest?
https soll doch die STRECKE zwischen Server und Client absichern - damit du eben sicher sein kannst das du z.B. mit dem korrekten Server kommunizierst. Dies ist in einem internen Netzwerk aber nicht zwingend nötig wenn die unterliegende Infrastruktur das bereits sichert.
Die DATEN soll dagegen eigentlich die Applikation schützen. Wenn du z.B. hier die Webservices ins Spiel bringst - nun, meine Webservices übertragen die Daten generell nur verschlüsselt dabei wird die Verschlüsselung von der Applikation geregelt UND die Applikation selbst muss sich auch erst bei jeder Anfrage authentifizieren bevor die überhaupt Daten austauschen kann. Selbst wenn du also den Traffic mitschneidest - viel Spass, du hast trotzdem nur Datenmüll... Der Grund warum das ganze eben per https läuft ist hier weils eben über ein öffentliches Netzwerk geht wo ich die Infrastruktur _nicht_ selbst kontrollieren kann.
Bei Personenbezogenen Daten verhält es sich nicht soviel anders. Wenn du dich da nur auf https verlässt - nun, viel spass. Der Hacker auf deinem Rechner wird sich freuen. Der zieht halt im dummsten Fall einfach die Daten noch kurz per WGET (wenns z.B. nen JSON is was ausgetauscht wird). Super, du hast mit https die Welt gerettet, so kann sich der Hacker wenigstens sicher sein die korrekten Daten zu haben. Auch hier ist es die Aufgabe der Applikation zu gewährleisten das die Anfrage überhaupt legitim ist. Ich möchte es also mal in derselben Tonlage zurückgeben: Sind eure Applikationen also so stümperhaft zusammenkopiert das die sich nur auf https verlassen? Ich hoffe allerdings das nicht...
Und selbst bei einer normalen Webseite: https schützt nicht wirklich viel vor einem Hacker - das ist deine besagte Nebelkerze. Du fühlst dich dann vielleicht wohler, aber am Ende hast du nur die Strecke zwischen deinem Rechner und dem Server geschützt - welche im LAN eh exklusiv geschaltet wird (und den Mirror-Port vom Admin nehme ich mal raus - weil der kann dir auch einfach nen falsches Zert unterschieben und den Traffic schön mitlesen). Wenn ich aber Kontrolle über deinen Rechner habe - dann hast du hier eh verloren. Ich kann dich auf jeder Ebene "auseinander nehmen". Ich habe genug Zugriff das ich irgendwo meinen eigenen Server habe? Hey, ich schiebe deinem Browser einfach ein Zertifikat als "Gültig" unter indem ich deinen Win-Cert-Speicher modifiziere und kann wieder wunderbar per MidM weitermachen. Ich haut dir nen Keylogger/Screenrecorder drauf - schon seh ich alle Daten als elegantes Video bzw. habe die Daten und kann mich einfach von jeder anderen Stelle anmelden.
Wogegen willst du dich also in einem internen Netzwerk mit https wirklich schützen? Gegen einen Hacker auf deinem Rechner bringt es wenig. Ein Hacker auf dem Server hat vermutlich bereits mehr als genug Zugriff. Du möchtest dich also mittels https vor einem Angriff auf die Infrastruktur (Netzwerk) schützen. Das ist auch generell nicht verkehrt aber in einem internem Netzwerk eben ein überschaubares Risiko sofern der Admin vertrauenswürdig ist. Wenn nicht - nun, dann hat auch der genug Möglichkeiten da was zu machen...
Die DATEN soll dagegen eigentlich die Applikation schützen. Wenn du z.B. hier die Webservices ins Spiel bringst - nun, meine Webservices übertragen die Daten generell nur verschlüsselt dabei wird die Verschlüsselung von der Applikation geregelt UND die Applikation selbst muss sich auch erst bei jeder Anfrage authentifizieren bevor die überhaupt Daten austauschen kann. Selbst wenn du also den Traffic mitschneidest - viel Spass, du hast trotzdem nur Datenmüll... Der Grund warum das ganze eben per https läuft ist hier weils eben über ein öffentliches Netzwerk geht wo ich die Infrastruktur _nicht_ selbst kontrollieren kann.
Echt? Deine Applikationen verschlüsseln die Daten selbst? Sag mir welche Applikationen das sind. Ich möchte diese auch in den Einsatz bringen.
Bei reinem http Verkehr uber Webserver sind die Daten plain. Sorry, ist einfach so, wie soll ein Standard Formularfeld auch die Daten verschlüsseln?
Authentifizierung, egal wie sicher, hilft da nichts, wenn dazwischen etwas mitliest und darum geht es. Sitzt etwas auf einem PC ist das schlecht, betrifft aber nur diesen. Sitzt etwas auf allen PCs hast du ein anderes Problem. Aber sitzt etwas im Netz kannst du dich per HTTPS leichter dagegen wappnen.
Dies schliesst weitere Sicherheitsmaßnahmen selbstredend nicht aus.
Ich denke du hast keine bis sehr wenig Ahnung von dem, was du hier erzählst.
Übrigens interessant, dass sich dann Trotzdem Konzerne darum kümmern, die internen Systeme per https abzusichern, wofür eigentlich? ;)
Das Argument böser Admin zählt nicht, denn Gott ist natürlich keine Referenz, das Argument schlechter eher. Du darfst dich angegriffen fühlen, wie zig Firmen, die nach Schema " wir haben 2fa buzzword" mittlerweile sehr lädiert da stehen.
Administrator sein heisst Verantwortung zu tragen.
Moin,
4000 Beschäftigte ist schon mal eine Hausnummer. Aus Erfahrung weiß ich, daß bei so vielen Mitarbeiter immer mal wieder ein faules Ei dabei ist, Einfach aus statistischen Gründen.
Intern einfach nur http statt https zu verwenden, ist so, als ob man hinter der Firmenpforte keien abgeschlossenen Türen mehr hat. Das kann man in einer 5-Mannbude machen, wo jeder jeden kennt und eh alle Zugang zu allem haben. Aber wenn da 400 Leute sind, unter denen rein statistisch gesehen das ein oder andere faule Ei dabei ist, will man doch ein paar Türen abschließen.
Sofern da nur informative Inhalte abgeliefert werden, ist es unerheblich ob man da http oder https nimmt, aber sobald man sich explizit anmelden muß um bestimmte Informationen zu bekommen oder einzugeben, sollte https Standard sein.
Von daher halte ich die Aussage der IT nur einen Vorwand, um sich Arbeit zu sparen.
lks
4000 Beschäftigte ist schon mal eine Hausnummer. Aus Erfahrung weiß ich, daß bei so vielen Mitarbeiter immer mal wieder ein faules Ei dabei ist, Einfach aus statistischen Gründen.
Intern einfach nur http statt https zu verwenden, ist so, als ob man hinter der Firmenpforte keien abgeschlossenen Türen mehr hat. Das kann man in einer 5-Mannbude machen, wo jeder jeden kennt und eh alle Zugang zu allem haben. Aber wenn da 400 Leute sind, unter denen rein statistisch gesehen das ein oder andere faule Ei dabei ist, will man doch ein paar Türen abschließen.
Sofern da nur informative Inhalte abgeliefert werden, ist es unerheblich ob man da http oder https nimmt, aber sobald man sich explizit anmelden muß um bestimmte Informationen zu bekommen oder einzugeben, sollte https Standard sein.
Von daher halte ich die Aussage der IT nur einen Vorwand, um sich Arbeit zu sparen.
lks
1Zitat von @Epigenese:
Hallo zusammen,
ich wollte eine Konstallation zur Diskussion stellen, zu der mich eure Meinung interessiert.
In einem Unternehmen, mit ca 4000 Beschäftigten, gibt es ein Intranet.
Von der Startseite aus kommt man in weitere verschiedene Portale.
Unter anderem auch in eine zentrale Einkaufsplattfrom, welche die Eingabe von Benutzername und Passwort erfordert.
Die Startseite und verschiedene verlinkte Seiten/Portale sind nur über http erreichbar.
Ein Mitarbeiter des Unternehmen bemängelt dieses und schreibt der zuständigen IT ein Ticket.
Dieses wird mit dem Hinweis geschlossen, dass es "nur" das Intranet ist.
Bei mir rollen sich die Zehnägel auf, wenn ich das höre.
Ist das nicht schon ein Verstoß, bei dem der Datenschutzbeauftragte der Unternehmens informiert werden muss?
Für konstruktive Kommentare bin ich dankbar.
Grüße
Epi
Hallo zusammen,
ich wollte eine Konstallation zur Diskussion stellen, zu der mich eure Meinung interessiert.
In einem Unternehmen, mit ca 4000 Beschäftigten, gibt es ein Intranet.
Von der Startseite aus kommt man in weitere verschiedene Portale.
Unter anderem auch in eine zentrale Einkaufsplattfrom, welche die Eingabe von Benutzername und Passwort erfordert.
Die Startseite und verschiedene verlinkte Seiten/Portale sind nur über http erreichbar.
Ein Mitarbeiter des Unternehmen bemängelt dieses und schreibt der zuständigen IT ein Ticket.
Dieses wird mit dem Hinweis geschlossen, dass es "nur" das Intranet ist.
Bei mir rollen sich die Zehnägel auf, wenn ich das höre.
Ist das nicht schon ein Verstoß, bei dem der Datenschutzbeauftragte der Unternehmens informiert werden muss?
Für konstruktive Kommentare bin ich dankbar.
Grüße
Epi
Zitat von @Mystery-at-min:
Echt? Deine Applikationen verschlüsseln die Daten selbst? Sag mir welche Applikationen das sind. Ich möchte diese auch in den Einsatz bringen.
Bei reinem http Verkehr uber Webserver sind die Daten plain. Sorry, ist einfach so, wie soll ein Standard Formularfeld auch die Daten verschlüsseln?
Authentifizierung, egal wie sicher, hilft da nichts, wenn dazwischen etwas mitliest und darum geht es. Sitzt etwas auf einem PC ist das schlecht, betrifft aber nur diesen. Sitzt etwas auf allen PCs hast du ein anderes Problem. Aber sitzt etwas im Netz kannst du dich per HTTPS leichter dagegen wappnen.
Dies schliesst weitere Sicherheitsmaßnahmen selbstredend nicht aus.
Ich denke du hast keine bis sehr wenig Ahnung von dem, was du hier erzählst.
Übrigens interessant, dass sich dann Trotzdem Konzerne darum kümmern, die internen Systeme per https abzusichern, wofür eigentlich? ;)
Das Argument böser Admin zählt nicht, denn Gott ist natürlich keine Referenz, das Argument schlechter eher. Du darfst dich angegriffen fühlen, wie zig Firmen, die nach Schema " wir haben 2fa buzzword" mittlerweile sehr lädiert da stehen.
Administrator sein heisst Verantwortung zu tragen.
Die DATEN soll dagegen eigentlich die Applikation schützen. Wenn du z.B. hier die Webservices ins Spiel bringst - nun, meine Webservices übertragen die Daten generell nur verschlüsselt dabei wird die Verschlüsselung von der Applikation geregelt UND die Applikation selbst muss sich auch erst bei jeder Anfrage authentifizieren bevor die überhaupt Daten austauschen kann. Selbst wenn du also den Traffic mitschneidest - viel Spass, du hast trotzdem nur Datenmüll... Der Grund warum das ganze eben per https läuft ist hier weils eben über ein öffentliches Netzwerk geht wo ich die Infrastruktur _nicht_ selbst kontrollieren kann.
Echt? Deine Applikationen verschlüsseln die Daten selbst? Sag mir welche Applikationen das sind. Ich möchte diese auch in den Einsatz bringen.
Bei reinem http Verkehr uber Webserver sind die Daten plain. Sorry, ist einfach so, wie soll ein Standard Formularfeld auch die Daten verschlüsseln?
Authentifizierung, egal wie sicher, hilft da nichts, wenn dazwischen etwas mitliest und darum geht es. Sitzt etwas auf einem PC ist das schlecht, betrifft aber nur diesen. Sitzt etwas auf allen PCs hast du ein anderes Problem. Aber sitzt etwas im Netz kannst du dich per HTTPS leichter dagegen wappnen.
Dies schliesst weitere Sicherheitsmaßnahmen selbstredend nicht aus.
Ich denke du hast keine bis sehr wenig Ahnung von dem, was du hier erzählst.
Übrigens interessant, dass sich dann Trotzdem Konzerne darum kümmern, die internen Systeme per https abzusichern, wofür eigentlich? ;)
Das Argument böser Admin zählt nicht, denn Gott ist natürlich keine Referenz, das Argument schlechter eher. Du darfst dich angegriffen fühlen, wie zig Firmen, die nach Schema " wir haben 2fa buzzword" mittlerweile sehr lädiert da stehen.
Administrator sein heisst Verantwortung zu tragen.
Nun - ich denke du kommst nich ohne persönliche Angriffe aus oder ohne Unterstellungen, oder?
Erstmal wechselst du nach belieben zwischen mal über "Webservices" reden, dann wieder "plain http anmeldung". Du möchtest wissen welche Anwendung bei Webservices z.B. Verschlüsselung von Daten einsetzt? Meine z.B., aber auch beliebig viele die ggf. auch Bezahldienste verwenden. Da man bei einem Webservice halt generell nicht dem Aufrufer vertrauen kann. Und da hilft dir dann das Mitlesen eben nicht weil die End-Point-Applikation die Entschlüsselung übernimmt.
So - jetzt gehen wir halt doch wieder zurück auf die Plain-Text-Anmeldung. Auch hier habe ich bereits mehrfach erwähnt das es eben in einem INTERNEN Netzwerk was anderes ist als in einem unbekannten Netzwerk. Also - wie möchtest du denn z.B. bei einem Netzwerk mittels Switches was "dazwischen" setzen ohne Admin-Rechte auf der Infrastruktur zu haben? Nenne hier bitte mal ein Beispiel. Oder willst du etwa dann doch wieder dahin gehen das jemand z.B. nen Hub installiert - d.h. doch wieder physischen Zugriff auf die Infra hat (und der Admin auch pennt weil keinerlei Port-Security da ist)?
Und glaubst du wirklich das du den Sicherheitsgewinn hast nur weil du - nochmal, extra für dich - in einem internen Netz auf HTTPS gehst? Was meinst du - wo finden denn die Angriffe statt? Oh, meistens ja auf den End-Points (Server bzw. Client) - und da bringt es dir wenig weil eben mit Zugriff auf diese Stellen auch das https leicht umgangen werden kann (auch nochmal für dich: Keylogger, Screen-Reader,...). Und wenn man hier sogar mal annimmt das in einem Netz der Grösse vermutlich Clients + Server nich im selben Netz stehen dann steht da ja sogar noch ne Firewall vermutlich zwischen - welche sogar noch zusätzlich dafür sorgt das der Traffic nicht einfach umgeleitet wird (sofern nich einfach alles freigegeben wurde).
So - und nun spare dir doch mal deine Vermutungen über meine Kenntnisse und sage mal ein Beispiel wo du einen relevanten Vorteil hast OHNE das jemand eben eh schon Kontrolle über die Arbeitsstation/Server hat und ohne das jemand bereits dein gesamtes Netz unter Kontrolle hat (dann wäre eh ne MidM einfach). Denn wir gehen ja davon aus das der Admin selbst Vertrauenswürdig ist und das wir eben nicht in einem offenen WLAN irgendwo bei der Fast-Food-Bude sitzen...
Die einen nennen es pennen, die anderen es sich einfach machen. Aber nein, man muss kein Administrator des unternehmens sein um ggf. Kritische Schnittstellen zu verwanzen. Am Ende genügt ein schlecht gewarteter Switch mit einer Sicherheitslücke - oder eine bridge zwischen den Switches. Du nennst es bereits.
Der Mehraufwand hält sich in so fern auch in Grenzen. Und bei 4.000 Mitarbeiter, oh man.
Ich würde gerne mal jemanden mit entsprechendem "goodwill" durch dein Netz gehen lassen. Übernimmst du die Verantwortung oder lenkst du nur ab?
Welche Applikation verschlüsselt in sich selbst vor Versand per Netzwerk? Nenn sie bitte. (M)ein Beispiel ist oben genannt.
Der Mehraufwand hält sich in so fern auch in Grenzen. Und bei 4.000 Mitarbeiter, oh man.
Ich würde gerne mal jemanden mit entsprechendem "goodwill" durch dein Netz gehen lassen. Übernimmst du die Verantwortung oder lenkst du nur ab?
Welche Applikation verschlüsselt in sich selbst vor Versand per Netzwerk? Nenn sie bitte. (M)ein Beispiel ist oben genannt.
Die einen nennen es pennen, die anderen es sich einfach machen. Aber nein, man muss kein Administrator des unternehmens sein um ggf. Kritische Schnittstellen zu verwanzen. Am Ende genügt ein schlecht gewarteter Switch mit einer Sicherheitslücke - oder eine bridge zwischen den Switches. Du nennst es bereits.
Der Mehraufwand hält sich in so fern auch in Grenzen. Und bei 4.000 Mitarbeiter, oh man.
Ich würde gerne mal jemanden mit entsprechendem "goodwill" durch dein Netz gehen lassen. Übernimmst du die Verantwortung oder lenkst du nur ab?
Man bringt es oben auf den Punkt
Welche Applikation verschlüsselt in sich selbst vor Versand per Netzwerk? Nenn sie bitte. (M)ein Beispiel ist oben genannt.
Der Mehraufwand hält sich in so fern auch in Grenzen. Und bei 4.000 Mitarbeiter, oh man.
Ich würde gerne mal jemanden mit entsprechendem "goodwill" durch dein Netz gehen lassen. Übernimmst du die Verantwortung oder lenkst du nur ab?
Man bringt es oben auf den Punkt
Intern einfach nur http statt https zu verwenden, ist so, als ob man hinter der Firmenpforte keien abgeschlossenen Türen mehr hat.
Welche Applikation verschlüsselt in sich selbst vor Versand per Netzwerk? Nenn sie bitte. (M)ein Beispiel ist oben genannt.
Beispiele welche Applikationen das machen:
- Bei Mail z.B. PGP usw. -> die Mail wird verschlüsselt unabhängig davon ob du TLS nutzt oder nicht.
- Online-Banking-SW z.B. (z.B. Star-Money), Kreditkarten-Daten,... haben idR. geschützte Schnittstellen grade damit eben ein lokaler Benutzer nicht einfach die Kommunikation fälschen kann
- Jedes gute Forum welches Daten u.a. in der DB hoffentlich nicht im Klartext abspeichert (hier z.B. per md5-Sum) - dabei interessiert es die z.B. PHP-Seite ja nicht ob du ne gesicherte Verbindung zur DB hast oder nicht, die Daten werden einfach vorher "verschlüsselt" und nur der "verschlüsselte" Wert steht dann in der DB
- Smart-TVs und Streaming-Webseiten wie Netflix (nennt sich da DRM idR) - da man wohl keine MP4-File als Provider dem Endkunden fröhlich zur Verfügung stellen will die der einfach am Rechner speichern könnte. Bei Smart-TVs musst du idR. sogar nen NDR unterzeichnen damit du an die Verschlüsselung (z.B. ProCentric) kommst
- In Hardware sogar bei HDMI drin - hier sagt das Copyright-Flag z.B. bei Encodern das die Filme von einem DVD-Player z.B. nich streamen während sich ein TV als legitimes Endgerät ausweist und den Film anzeigt...
Reichen die? Alle diese würden sich sicher nicht auf https verlassen sondern die Endpunkte regeln das untereinander weil auch die Hersteller erkannt haben das die grössten Schwachstellen selbst im Internet die "Endpunkte" sind und grad im Bereich DRM eben dafür sorgen wollen das man es nicht so einfach kopieren kann. Und das sind Beispiele die du selbst probieren kannst - bei Webservices siehts noch anders aus. Da gibt dir eben häufiger ne API lediglich ein codiertes Ergebnis - und wenn du die Lizenz nicht gekauft hast (und somit über keinen gültigen Key verfügst) kannst du es halt auch nicht enschlüsseln. So funktionieren da div. Abo-Modelle weil es ja schon blöd wäre wenn du dann für 2 Wochen nen Zugang kaufst aber der dann permanent weiter läuft weil die Schnittstelle alles im Plaintext raushaut...
Wenn du aber jetzt auf "schlecht gewartete Infrastruktur" gehst - nun, wo ist denn da der Schutz bei HTTPS? Ich packe dir einfach nen Proxy rein, leite die Pakete entsprechend um (nehmen wir an ich habe Zugriff auf den Router/die FW) und mache nen schönes Man-in-the-middle daraus. Wobei selbst das ja schon einiges an Dingen vorraussetzen würde: Du hast irgendwie aus einem erreichbaren Netz Zugriff auf die Mgmt-Funktionen vom Switch enthalten (was vermutlich in jedem halbwegs guten Netz nur aus dem Admin-Netz gehen sollte). Du hast ne Schwachstelle im Switch gefunden, du hast dir irgendwie noch nen Netzwerk-Port als Mirror gelegt (was heisst du bist entweder im selben Stack oder bereits auf Distri-Level). Nun - jetzt lass mich kurz überlegen: Wenn ich soweit bin - würde ich da versuchen mich am http-Traffic aufzuhalten oder würde ich nicht eher schauen - z.B. bei Cisco - die Admin-Daten auszulesen in der Hoffnung das diese auf allen Switches gleich sind? Würde ich dann nicht eher versuchen an die Server-Systeme direkt zu gehen?
Zum Beispiel was du hier anbringst: Wenn dein HTTPS das einzige is was die Firmenpforte darstellen soll - nun, dann stellt sich die Frage ob ich viel Aufwand in das Schloss der Firmenpforte stecke oder ob ich gucke ob der Zaun daneben überhaupt existiert und stabil ist... Bzw. ob ich zwar alle Türen abgeschlossen habe - aber blöd wenn die Fenster daneben dann permanent offen sind. Und die Sicherheit kommt eben nicht vom Protokoll - das is eben nur nen kleiner Teil, die Sicherheit kommt von der Applikation dahinter und vom Anwender...
- Bei Mail z.B. PGP usw. -> die Mail wird verschlüsselt unabhängig davon ob du TLS nutzt oder nicht.
- Online-Banking-SW z.B. (z.B. Star-Money), Kreditkarten-Daten,... haben idR. geschützte Schnittstellen grade damit eben ein lokaler Benutzer nicht einfach die Kommunikation fälschen kann
- Jedes gute Forum welches Daten u.a. in der DB hoffentlich nicht im Klartext abspeichert (hier z.B. per md5-Sum) - dabei interessiert es die z.B. PHP-Seite ja nicht ob du ne gesicherte Verbindung zur DB hast oder nicht, die Daten werden einfach vorher "verschlüsselt" und nur der "verschlüsselte" Wert steht dann in der DB
- Smart-TVs und Streaming-Webseiten wie Netflix (nennt sich da DRM idR) - da man wohl keine MP4-File als Provider dem Endkunden fröhlich zur Verfügung stellen will die der einfach am Rechner speichern könnte. Bei Smart-TVs musst du idR. sogar nen NDR unterzeichnen damit du an die Verschlüsselung (z.B. ProCentric) kommst
- In Hardware sogar bei HDMI drin - hier sagt das Copyright-Flag z.B. bei Encodern das die Filme von einem DVD-Player z.B. nich streamen während sich ein TV als legitimes Endgerät ausweist und den Film anzeigt...
Reichen die? Alle diese würden sich sicher nicht auf https verlassen sondern die Endpunkte regeln das untereinander weil auch die Hersteller erkannt haben das die grössten Schwachstellen selbst im Internet die "Endpunkte" sind und grad im Bereich DRM eben dafür sorgen wollen das man es nicht so einfach kopieren kann. Und das sind Beispiele die du selbst probieren kannst - bei Webservices siehts noch anders aus. Da gibt dir eben häufiger ne API lediglich ein codiertes Ergebnis - und wenn du die Lizenz nicht gekauft hast (und somit über keinen gültigen Key verfügst) kannst du es halt auch nicht enschlüsseln. So funktionieren da div. Abo-Modelle weil es ja schon blöd wäre wenn du dann für 2 Wochen nen Zugang kaufst aber der dann permanent weiter läuft weil die Schnittstelle alles im Plaintext raushaut...
Wenn du aber jetzt auf "schlecht gewartete Infrastruktur" gehst - nun, wo ist denn da der Schutz bei HTTPS? Ich packe dir einfach nen Proxy rein, leite die Pakete entsprechend um (nehmen wir an ich habe Zugriff auf den Router/die FW) und mache nen schönes Man-in-the-middle daraus. Wobei selbst das ja schon einiges an Dingen vorraussetzen würde: Du hast irgendwie aus einem erreichbaren Netz Zugriff auf die Mgmt-Funktionen vom Switch enthalten (was vermutlich in jedem halbwegs guten Netz nur aus dem Admin-Netz gehen sollte). Du hast ne Schwachstelle im Switch gefunden, du hast dir irgendwie noch nen Netzwerk-Port als Mirror gelegt (was heisst du bist entweder im selben Stack oder bereits auf Distri-Level). Nun - jetzt lass mich kurz überlegen: Wenn ich soweit bin - würde ich da versuchen mich am http-Traffic aufzuhalten oder würde ich nicht eher schauen - z.B. bei Cisco - die Admin-Daten auszulesen in der Hoffnung das diese auf allen Switches gleich sind? Würde ich dann nicht eher versuchen an die Server-Systeme direkt zu gehen?
Zum Beispiel was du hier anbringst: Wenn dein HTTPS das einzige is was die Firmenpforte darstellen soll - nun, dann stellt sich die Frage ob ich viel Aufwand in das Schloss der Firmenpforte stecke oder ob ich gucke ob der Zaun daneben überhaupt existiert und stabil ist... Bzw. ob ich zwar alle Türen abgeschlossen habe - aber blöd wenn die Fenster daneben dann permanent offen sind. Und die Sicherheit kommt eben nicht vom Protokoll - das is eben nur nen kleiner Teil, die Sicherheit kommt von der Applikation dahinter und vom Anwender...
So - jetzt gehen wir halt doch wieder zurück auf die Plain-Text-Anmeldung. Auch hier habe ich bereits mehrfach erwähnt das es eben in einem INTERNEN Netzwerk was anderes ist als in einem unbekannten Netzwerk. Also - wie möchtest du denn z.B. bei einem Netzwerk mittels Switches was "dazwischen" setzen ohne Admin-Rechte auf der Infrastruktur zu haben? Nenne hier bitte mal ein Beispiel. Oder willst du etwa dann doch wieder dahin gehen das jemand z.B. nen Hub installiert - d.h. doch wieder physischen Zugriff auf die Infra hat (und der Admin auch pennt weil keinerlei Port-Security da ist)?
Sorry, ich habe die Texte nur überflogen. Meiner Meinung sollte aber auch intern nicht auf HTTPS verzichtet werden. HTTP höchstens für statische, rein informative Daten.
Aber um mal was rauszupicken...jemand internes braucht natürlich keine adminrechte auf die Infrastruktur um Datenverkehr abzufangen.
Arp poisining, dhcp Server spielen, falsche DNS Server ausliefern etc.
Für MITM Angriffe gibt es genügend Möglichkeiten. Auch dafür gibt es Abwehrmechanismen. Aber wer es nichtmal schafft auf Https zu switchen, der nutzt auch keine Enterprise Funktionen der Switche.
Zitat von @LordXearo:
Sorry, ich habe die Texte nur überflogen. Meiner Meinung sollte aber auch intern nicht auf HTTPS verzichtet werden. HTTP höchstens für statische, rein informative Daten.
Sorry, ich habe die Texte nur überflogen. Meiner Meinung sollte aber auch intern nicht auf HTTPS verzichtet werden. HTTP höchstens für statische, rein informative Daten.
So sehe ich das auch aber wie geschrieben, ich wollte zu diesem Konstrukt mal Meinungen hören.
Zumal von der http Seite aus Logins, weiter mit http erfolgen, mit Username + PW.
ich finde auch den Einwand richtig von @Mystery-at-min dass wenn es ein Unternehmen mit ca 4000 Beschäftigten ist, das schon eine Hausnummer ist.
Ich hätte als Admin schon den Anspruch, dass ich hier auf verschlüsselte Datenübertragung setze und somit http vs. https für mich keine Frage ist.
1- Bei Mail z.B. PGP usw. -> die Mail wird verschlüsselt unabhängig davon ob du TLS nutzt oder nicht.
Du hast eins gefunden. Gratuliere, und warum nutzt man PGP nicht durchgängig? Weil man es per TLS verschlüsseln kann und das wesentlich einfacher.
- Online-Banking-SW z.B. (z.B. Star-Money), Kreditkarten-Daten,... haben idR. geschützte Schnittstellen grade damit eben ein lokaler Benutzer nicht einfach die Kommunikation fälschen kann
NichtFälschen ist etwas anderes als im Programm verschlüsseln. Bitte hier nochmals forschen. Eine geschützte Schnittstelle wird durch die Transportverschlüsselung daraus.
- Jedes gute Forum welches Daten u.a. in der DB hoffentlich nicht im Klartext abspeichert (hier z.B. per md5-Sum) - dabei
Werden hier die Beiträge verschlüsselt abgelegt? Vermutlich nicht. Werden in einer CRM Datenbank die Kunden verschlüsselt abgelegt? Nein. Nenne mir konkrete Beispiele.
interessiert es die z.B. PHP-Seite ja nicht ob du ne gesicherte Verbindung zur DB hast oder nicht, die Daten werden einfach vorher
wann?
"verschlüsselt" und nur der "verschlüsselte" Wert steht dann in der DB
siehe oben, eher nein.
- Smart-TVs und Streaming-Webseiten wie Netflix (nennt sich da DRM idR) - da man wohl keine MP4-File als Provider dem Endkunden fröhlich zur Verfügung stellen will die der einfach am Rechner speichern könnte.
Die Verschlüsseln aber nichts, die Entschlüsseln maximal und das per DRM Chip o.ä. Hier geht es um den anderen Weg.
Bei Smart-TVs musst du idR. sogar nen NDR unterzeichnen damit du an die Verschlüsselung (z.B. ProCentric) kommst
So wie beim Haustürschlüssel, aber es wird eben - ver und entschlüsselt. Du verfängst dich und driftest ab, merkst du das?
Nochmals, bitte. Ansonsten, lass es einfach sein.
Moin,
nachdem ich mir das ganze hier jetzt auch mal durchgelesen habe, muss ich einfach meinen Senf dazu geben:
Ja genau, und in NRW war es auch "nur" Regen.
Gruß
Doskias
nachdem ich mir das ganze hier jetzt auch mal durchgelesen habe, muss ich einfach meinen Senf dazu geben:
Ja genau, und in NRW war es auch "nur" Regen.
Bei mir rollen sich die Zehnägel auf, wenn ich das höre.
Bei mir wenn ich antworten lese wie:Zitat von @maretz
Ehrlich gesagt würde ich da einfach mal fragen ob ihr sonst keine Langeweile habt. Klar wäre https auch da natürlich schöner - aber im "internen" Netz ist die Angriffswahrscheinlichkeit da ja eher überschaubar weil es nur über eure Infrastruktur läuft.
Maertz scheint auch Langeweile zu haben, wenn er hier so viel schreibt. Aber mal Scherz beiseite. Wie schon einige geschrieben haben ist genau das Hauptproblem. Es geht hier nicht um das was schöner ist, sondern um das was sicher ist. Die Angriffswahrscheinlichkeit ist nicht geringer, nur weil es intern ist. Wenn sich der Angreifer auf einem Rechner befindet, dann hilft dir interne HTTPS dennoch massiv weiter.Ehrlich gesagt würde ich da einfach mal fragen ob ihr sonst keine Langeweile habt. Klar wäre https auch da natürlich schöner - aber im "internen" Netz ist die Angriffswahrscheinlichkeit da ja eher überschaubar weil es nur über eure Infrastruktur läuft.
Ist das nicht schon ein Verstoß, bei dem der Datenschutzbeauftragte der Unternehmens informiert werden muss?
Melden macht frei. lass es doch den DS-Beauftragten entscheiden. Dafür ist er da.Für konstruktive Kommentare bin ich dankbar.
Ich würde es richtig (mit HTTPS) machen oder gar nicht.Gruß
Doskias
Zitat von @148656:
Moin,
Die Frage könnte dir der Datenschutzbeauftragte des Unternehmens ganz leicht beantworten. Wenn er gemein ist, zeigt er dir nur die Risikoanalyse. Wenn er nett ist, bespricht er sie mit dir.
Gruß
C.C.
Moin,
Die Frage könnte dir der Datenschutzbeauftragte des Unternehmens ganz leicht beantworten. Wenn er gemein ist, zeigt er dir nur die Risikoanalyse. Wenn er nett ist, bespricht er sie mit dir.
Gruß
C.C.
Danke C.Caveman, der Tipp mit dem Datenschutzbeauftragten ist gut.
Da wir nur intern sprechen:
HTTPS wo immer möglich, HTTP muss die Ausnahme sein.
Das Zertifikat muss für die Verschlüsselung ja nicht mal gültig sein, falls das ein Argument sein sollte (weil das ja sooo teuer und sooo viel Aufwand wäre).
Klassisches Beispiel: Webinterface der USV. Durchaus kritisch, damit kann ich relativ viel Schaden anrichten.
Zertifikat ist standardmäßig natürlich selbst signiert und damit ungültig im Standardbrowser.
Für die verschlüsselte Kommunikation ist das aber erstmal nicht relevant, nur dein Browser wird dich anmeckern. So what.
HTTPS wo immer möglich, HTTP muss die Ausnahme sein.
Das Zertifikat muss für die Verschlüsselung ja nicht mal gültig sein, falls das ein Argument sein sollte (weil das ja sooo teuer und sooo viel Aufwand wäre).
Klassisches Beispiel: Webinterface der USV. Durchaus kritisch, damit kann ich relativ viel Schaden anrichten.
Zertifikat ist standardmäßig natürlich selbst signiert und damit ungültig im Standardbrowser.
Für die verschlüsselte Kommunikation ist das aber erstmal nicht relevant, nur dein Browser wird dich anmeckern. So what.
Zitat von @Drohnald:
Da wir nur intern sprechen:
HTTPS wo immer möglich, HTTP muss die Ausnahme sein.
Das Zertifikat muss für die Verschlüsselung ja nicht mal gültig sein, falls das ein Argument sein sollte (weil das ja sooo teuer und sooo viel Aufwand wäre).
Klassisches Beispiel: Webinterface der USV. Durchaus kritisch, damit kann ich relativ viel Schaden anrichten.
Zertifikat ist standardmäßig natürlich selbst signiert und damit ungültig im Standardbrowser.
Für die verschlüsselte Kommunikation ist das aber erstmal nicht relevant, nur dein Browser wird dich anmeckern. So what.
Da wir nur intern sprechen:
HTTPS wo immer möglich, HTTP muss die Ausnahme sein.
Das Zertifikat muss für die Verschlüsselung ja nicht mal gültig sein, falls das ein Argument sein sollte (weil das ja sooo teuer und sooo viel Aufwand wäre).
Klassisches Beispiel: Webinterface der USV. Durchaus kritisch, damit kann ich relativ viel Schaden anrichten.
Zertifikat ist standardmäßig natürlich selbst signiert und damit ungültig im Standardbrowser.
Für die verschlüsselte Kommunikation ist das aber erstmal nicht relevant, nur dein Browser wird dich anmeckern. So what.
Und genau da liegt nämlich das Problem: Wenns nicht die USV ist sondern mal wieder die Webseite bei der man nich die volle Kontrolle hat und ungültige Zertifikate auftauchen. Klar kann man den Benutzer erklären "klick halt auf "Accept" (bzw. bei Google tipp halt "thisisunsafe") und fertig. Und damit macht man es nämlich dann erst den Angreifern wirklich einfach -> wenns dann nämlich nen gefälschtes Zertifikat ist (oder der halt mal wieder in ner Mail aufn Link klickt) - was solls, man klickt ja eh immer weg, dann is es das eine mal mehr auch nicht ungewöhnlich.
Aber gut - ich denke ich bin raus hier ... scheinbar ist es für die meisten wichtiger den Transport zu sichern als das drumrum... solang ihr euch dann Sicher fühlt is ja alles gut. Eine wirkliche Diskussion entsteht hier nunmal nicht - und wer halt Applikations- und Transportverschlüsselung nicht auseinander halten kann oder will dem kann ich auch nich wirklich weiterhelfen.
Und genau da liegt nämlich das Problem: Wenns nicht die USV ist sondern mal wieder die Webseite bei der man nich die volle Kontrolle hat und ungültige Zertifikate auftauchen. Klar kann man den Benutzer erklären "klick halt auf "Accept" (bzw. bei Google tipp halt "thisisunsafe") und fertig. Und damit macht man es nämlich dann erst den Angreifern wirklich einfach -> wenns dann nämlich nen gefälschtes Zertifikat ist (oder der halt mal wieder in ner Mail aufn Link klickt) - was solls, man klickt ja eh immer weg, dann is es das eine mal mehr auch nicht ungewöhnlich.
SSL Wildcard Zertifikat 5 Jahre ab ca 10.000€ und das ist kein Problem mehr, die USV sollten die Benutzer gar nicht erreichen können. Also alles fein.
scheinbar ist es für die meisten wichtiger den Transport zu sichern als das drumrum... solang ihr euch dann Sicher fühlt is ja alles gut. Eine wirkliche Diskussion entsteht hier nunmal nicht - und wer halt Applikations- und Transportverschlüsselung nicht auseinander halten kann oder will dem kann ich auch nich wirklich weiterhelfen.
Das ist Blödsinn, wie des öfteren gesagt wurde. Die Verschlüsselung ist ein (1!) Teil des Sicherheitskonzepts bzw der TOMs
https://www.datenschutz-wiki.de/Technische_und_organisatorische_Ma%C3%9F ...
Aber gut - ich denke ich bin raus hier ...
gut.
Nein, nicht "wichtiger als". Das Eine sollte das Andere nicht ersetzen, zumal HTTPS heutzutage absoluter Standard ist.
Nach deiner Argumentation würde ich sagen: Wer in seiner Anwendung Transportverschlüsselung mit HTTS nicht umsetzen kann, der wird auch keine vernünftige Applikationsverschlüsselung hinbekommen.
Ich präzisiere nochmal:
Die Ausnahme für ungültige Zertifikate sollte den Admins vorbehalten sein.
Was ich sagen wollte: HTTPS ist IMMER besser als HTTP, selbst wenn das Zertifikat ungültig ist, weil trotzdem verschlüsselt übertragen wird.
@Epigenese:
Ich stimme dir zu, so eine Antwort bringt Fußkäse in den Schlappen, nur Mut!
Sprich es (schriftlich) an und erkläre den Verantwortlichen, warum das zu großen und teuren Problemen führen kann.
Es muss dafür auf jeden Fall eine Risikoanalyse geben genau aufgeführt wird, warum man HTTP an dieser Stelle für vertretbar hält. Sobald hier Personenbezogene Daten verarbeitet werden (Login eines Mitarbeiters mit Name etc.) müsste es schon sehr gut begründet werden.
Nach deiner Argumentation würde ich sagen: Wer in seiner Anwendung Transportverschlüsselung mit HTTS nicht umsetzen kann, der wird auch keine vernünftige Applikationsverschlüsselung hinbekommen.
Ich präzisiere nochmal:
Die Ausnahme für ungültige Zertifikate sollte den Admins vorbehalten sein.
Was ich sagen wollte: HTTPS ist IMMER besser als HTTP, selbst wenn das Zertifikat ungültig ist, weil trotzdem verschlüsselt übertragen wird.
@Epigenese:
Ich stimme dir zu, so eine Antwort bringt Fußkäse in den Schlappen, nur Mut!
Sprich es (schriftlich) an und erkläre den Verantwortlichen, warum das zu großen und teuren Problemen führen kann.
Es muss dafür auf jeden Fall eine Risikoanalyse geben genau aufgeführt wird, warum man HTTP an dieser Stelle für vertretbar hält. Sobald hier Personenbezogene Daten verarbeitet werden (Login eines Mitarbeiters mit Name etc.) müsste es schon sehr gut begründet werden.
Hallo Doskias,
danke für deinen Beitrag.
So sehe ich das auch. Ich denke auch dass es doch kein Aufwand ist auf https umzustellen.
Schliesslich werden auch Daten erfasst, verarbeitet und gespeichert.
Dachte mir schon, dass dieses Meinungsbild, nicht die Meinung der Administratoren und IT Verantwortlichen wiederspiegelt, die hier unterwegs sind.
Grüße
danke für deinen Beitrag.
So sehe ich das auch. Ich denke auch dass es doch kein Aufwand ist auf https umzustellen.
Schliesslich werden auch Daten erfasst, verarbeitet und gespeichert.
Bei mir rollen sich die Zehnägel auf, wenn ich das höre.
Bei mir wenn ich antworten lese wie:Zitat von @maretz
Ehrlich gesagt würde ich da einfach mal fragen ob ihr sonst keine Langeweile habt. Klar wäre https auch da natürlich schöner - aber im "internen" Netz ist die Angriffswahrscheinlichkeit da ja eher überschaubar weil es nur über eure Infrastruktur läuft.
Maertz scheint auch Langeweile zu haben, wenn er hier so viel schreibt. Aber mal Scherz beiseite. Wie schon einige geschrieben haben ist genau das Hauptproblem. Es geht hier nicht um das was schöner ist, sondern um das was sicher ist. Die Angriffswahrscheinlichkeit ist nicht geringer, nur weil es intern ist. Wenn sich der Angreifer auf einem Rechner befindet, dann hilft dir interne HTTPS dennoch massiv weiter.Ehrlich gesagt würde ich da einfach mal fragen ob ihr sonst keine Langeweile habt. Klar wäre https auch da natürlich schöner - aber im "internen" Netz ist die Angriffswahrscheinlichkeit da ja eher überschaubar weil es nur über eure Infrastruktur läuft.
Dachte mir schon, dass dieses Meinungsbild, nicht die Meinung der Administratoren und IT Verantwortlichen wiederspiegelt, die hier unterwegs sind.
Grüße
Hallo Drohnald
Denke auch, dass das doch Standard sein sollte.
Grüße
Denke auch, dass das doch Standard sein sollte.
Grüße
Servus @Epigenese,
Ich denke mal, dass die IT aus dem von dir beschriebenem Unternehmen nicht die Skills hat, HTTPS auszurollen.
Das sollte eigentlich kein großes Problem sein. Bei einem Unternehmen mit 4000 Mitarbeiters ist ziemlich sicher ein Zertifikatsserver vorhanden und wahrscheinlich läuft eh alles auf Windows Domäne. Warum man dann den Webservern kein Zertifikat ausstellt und die Clients per GPO konfiguriert, dass die Unternehmens-eigenen Zertifikate vertrauenswürdig sind, ist mir schleierhaft. Das ist innerhalb von 1-2 Tagen gemacht und muss dann erst mal nicht mehr angefasst werden, bis die Zertifikate wieder auslaufen.
Vorallem mit Passwsorteingaben über HTTP haben viele Browser bereits eine Warnung, bald ist das möghlicherweise garnicht mehr möglich. Warum die IT dort kein Interesse daran hat ist mir schleierhaft.
Schönen Gruß,
@Snowman25
Ich denke mal, dass die IT aus dem von dir beschriebenem Unternehmen nicht die Skills hat, HTTPS auszurollen.
Das sollte eigentlich kein großes Problem sein. Bei einem Unternehmen mit 4000 Mitarbeiters ist ziemlich sicher ein Zertifikatsserver vorhanden und wahrscheinlich läuft eh alles auf Windows Domäne. Warum man dann den Webservern kein Zertifikat ausstellt und die Clients per GPO konfiguriert, dass die Unternehmens-eigenen Zertifikate vertrauenswürdig sind, ist mir schleierhaft. Das ist innerhalb von 1-2 Tagen gemacht und muss dann erst mal nicht mehr angefasst werden, bis die Zertifikate wieder auslaufen.
Vorallem mit Passwsorteingaben über HTTP haben viele Browser bereits eine Warnung, bald ist das möghlicherweise garnicht mehr möglich. Warum die IT dort kein Interesse daran hat ist mir schleierhaft.
Schönen Gruß,
@Snowman25
Hi Snowman25,
danke dir für deine Einschätzung.
ich teile deine Einschätzung voll und ganz.
Grüße
Epi
danke dir für deine Einschätzung.
Zitat von @Snowman25:
Servus @Epigenese,
Ich denke mal, dass die IT aus dem von dir beschriebenem Unternehmen nicht die Skills hat, HTTPS auszurollen.
Servus @Epigenese,
Ich denke mal, dass die IT aus dem von dir beschriebenem Unternehmen nicht die Skills hat, HTTPS auszurollen.
ich teile deine Einschätzung voll und ganz.Grüße
Epi
Hallo,
das halte ich auch für nicht vertretbar. Es kommt nicht darauf an, ob es irgendwo in ganz anderem Zusammenhang noch Geräte gibt, die kein HTTPS ermöglichen. Auf einem eigenen Webserver ist es nunmal mit einfachsten Mitteln umsetzbar und sollte daher auch genutzt werden.
Die Gründe sind weitaus vielfältiger als MITM-Angriffe. Ein Unternehmen mit 4.000 Mitarbeitern wird eine IT-Abteilung haben, die dem Umfang nach eine effektive Funktionstrennung ermöglicht und erfordert. Unterschiedliche Administratoren haben auf Switche, Firewalls oder Web-Server Zugriff oder eben nicht. Eine Funktionstrennung ist aber technisch nur dann gewährleistet, wenn intern die verfügbaren Sicherheitsvorkehrungen genauso selbstverständlich genutzt werden wie extern.
Grüße
Richard
das halte ich auch für nicht vertretbar. Es kommt nicht darauf an, ob es irgendwo in ganz anderem Zusammenhang noch Geräte gibt, die kein HTTPS ermöglichen. Auf einem eigenen Webserver ist es nunmal mit einfachsten Mitteln umsetzbar und sollte daher auch genutzt werden.
Die Gründe sind weitaus vielfältiger als MITM-Angriffe. Ein Unternehmen mit 4.000 Mitarbeitern wird eine IT-Abteilung haben, die dem Umfang nach eine effektive Funktionstrennung ermöglicht und erfordert. Unterschiedliche Administratoren haben auf Switche, Firewalls oder Web-Server Zugriff oder eben nicht. Eine Funktionstrennung ist aber technisch nur dann gewährleistet, wenn intern die verfügbaren Sicherheitsvorkehrungen genauso selbstverständlich genutzt werden wie extern.
Grüße
Richard
Hallo C.R.S.
danke dir für deinen Beitrag.
Ich meine zu Erkennen, dass die Profis hier, die Situation mit http nicht für angemessen halten, um es mal vorsichitg auszudrücken.
So sehe ich es auch, wie ich ja schon geschrieben habe.
Ich danke mal für die Beiträge und setze auf gelöst.
Grüße
Epi
danke dir für deinen Beitrag.
Zitat von @c.r.s.:
Hallo,
das halte ich auch für nicht vertretbar. Es kommt nicht darauf an, ob es irgendwo in ganz anderem Zusammenhang noch Geräte gibt, die kein HTTPS ermöglichen. Auf einem eigenen Webserver ist es nunmal mit einfachsten Mitteln umsetzbar und sollte daher auch genutzt werden.
Die Gründe sind weitaus vielfältiger als MITM-Angriffe. Ein Unternehmen mit 4.000 Mitarbeitern wird eine IT-Abteilung haben, die dem Umfang nach eine effektive Funktionstrennung ermöglicht und erfordert. Unterschiedliche Administratoren haben auf Switche, Firewalls oder Web-Server Zugriff oder eben nicht. Eine Funktionstrennung ist aber technisch nur dann gewährleistet, wenn intern die verfügbaren Sicherheitsvorkehrungen genauso selbstverständlich genutzt werden wie extern.
Grüße
Richard
Hallo,
das halte ich auch für nicht vertretbar. Es kommt nicht darauf an, ob es irgendwo in ganz anderem Zusammenhang noch Geräte gibt, die kein HTTPS ermöglichen. Auf einem eigenen Webserver ist es nunmal mit einfachsten Mitteln umsetzbar und sollte daher auch genutzt werden.
Die Gründe sind weitaus vielfältiger als MITM-Angriffe. Ein Unternehmen mit 4.000 Mitarbeitern wird eine IT-Abteilung haben, die dem Umfang nach eine effektive Funktionstrennung ermöglicht und erfordert. Unterschiedliche Administratoren haben auf Switche, Firewalls oder Web-Server Zugriff oder eben nicht. Eine Funktionstrennung ist aber technisch nur dann gewährleistet, wenn intern die verfügbaren Sicherheitsvorkehrungen genauso selbstverständlich genutzt werden wie extern.
Grüße
Richard
Ich meine zu Erkennen, dass die Profis hier, die Situation mit http nicht für angemessen halten, um es mal vorsichitg auszudrücken.
So sehe ich es auch, wie ich ja schon geschrieben habe.
Ich danke mal für die Beiträge und setze auf gelöst.
Grüße
Epi
1
Zitat von @Mystery-at-min:
SSL Wildcard Zertifikat 5 Jahre ab ca 10.000€ und das ist kein Problem mehr, die USV sollten die Benutzer gar nicht erreichen können. Also alles fein.
Das ist Blödsinn, wie des öfteren gesagt wurde. Die Verschlüsselung ist ein (1!) Teil des Sicherheitskonzepts bzw der TOMs
https://www.datenschutz-wiki.de/Technische_und_organisatorische_Ma%C3%9F ...
gut.
Und genau da liegt nämlich das Problem: Wenns nicht die USV ist sondern mal wieder die Webseite bei der man nich die volle Kontrolle hat und ungültige Zertifikate auftauchen. Klar kann man den Benutzer erklären "klick halt auf "Accept" (bzw. bei Google tipp halt "thisisunsafe") und fertig. Und damit macht man es nämlich dann erst den Angreifern wirklich einfach -> wenns dann nämlich nen gefälschtes Zertifikat ist (oder der halt mal wieder in ner Mail aufn Link klickt) - was solls, man klickt ja eh immer weg, dann is es das eine mal mehr auch nicht ungewöhnlich.
SSL Wildcard Zertifikat 5 Jahre ab ca 10.000€ und das ist kein Problem mehr, die USV sollten die Benutzer gar nicht erreichen können. Also alles fein.
scheinbar ist es für die meisten wichtiger den Transport zu sichern als das drumrum... solang ihr euch dann Sicher fühlt is ja alles gut. Eine wirkliche Diskussion entsteht hier nunmal nicht - und wer halt Applikations- und Transportverschlüsselung nicht auseinander halten kann oder will dem kann ich auch nich wirklich weiterhelfen.
Das ist Blödsinn, wie des öfteren gesagt wurde. Die Verschlüsselung ist ein (1!) Teil des Sicherheitskonzepts bzw der TOMs
https://www.datenschutz-wiki.de/Technische_und_organisatorische_Ma%C3%9F ...
Aber gut - ich denke ich bin raus hier ...
gut.
Hi,
10k für ein WC??
Nobel Nobel...
RapidSSL 5 Jahre Wildcard glaub bissl mehr als 500
Gruß
Habe nicht nach dem günstigsten geschaut, sonst hätte ich let's encrypt gesagt.
Aber selbst bei 10.000€/4000nutzer/5jahre investiert das Unternehmen wohl für jeden Benutzer am Tag mehr Geld in Kaffee. Durch deine Rechnung, definitiv.
Aber selbst bei 10.000€/4000nutzer/5jahre investiert das Unternehmen wohl für jeden Benutzer am Tag mehr Geld in Kaffee. Durch deine Rechnung, definitiv.
War nur ein Spaß
Hab es nicht so bierernst wie maretz aufgefasst ;)
Sehr interessanter Thread, danke dafür! 👍
Zitat von @Mystery-at-min:
SSL Wildcard Zertifikat 5 Jahre ab ca 10.000€ und das ist kein Problem mehr, die USV sollten die Benutzer gar nicht erreichen können. Also alles fein.
SSL Wildcard Zertifikat 5 Jahre ab ca 10.000€ und das ist kein Problem mehr, die USV sollten die Benutzer gar nicht erreichen können. Also alles fein.
Kaufst du die in der Apotheke? Da kannst du locker zwei Nullen streichen, wenn man möchte gehts auch kostenlos.
/Thomas
Zitat von @Th0mKa:
Kaufst du die in der Apotheke? Da kannst du locker zwei Nullen streichen, wenn man möchte gehts auch kostenlos.
/Thomas
Zitat von @Mystery-at-min:
SSL Wildcard Zertifikat 5 Jahre ab ca 10.000€ und das ist kein Problem mehr, die USV sollten die Benutzer gar nicht erreichen können. Also alles fein.
SSL Wildcard Zertifikat 5 Jahre ab ca 10.000€ und das ist kein Problem mehr, die USV sollten die Benutzer gar nicht erreichen können. Also alles fein.
Kaufst du die in der Apotheke? Da kannst du locker zwei Nullen streichen, wenn man möchte gehts auch kostenlos.
/Thomas
Minderwertigkeitskomplexe oder warum musst du nach Schema "hallo, hallo, ich muss auch noch sinnloses wiederholend beitragen" dich einbringen?
Siehe hier und folgende, da muss man sich schon fragen, was das für ein Zweck haben soll?
Das Thema ist geklärt, dein Senf braucht's nicht, dass es auch kostengünstigere Varianten gibt ist allen klar und das sollte keine Einkaufsempfehlung sein. Um das aber nicht ganz so sinnlos wie deinen Beitrag abzuschließen: Kostenlos ist nicht mal der Tod, denn der kostet nicht nur das Leben sondern richtig Asche. (LE Einrichtung und Wartung und Updates sind z.T teurer als Kaufzertifikate.)
Zur Berechnung Verweise ich hierauf
Zitat von @Mystery-at-min:
Minderwertigkeitskomplexe oder warum musst du nach Schema "hallo, hallo, ich muss auch noch sinnloses wiederholend beitragen" dich einbringen?
Hast du schlecht geschlafen oder bist du immer beleidigend unterwegs?Minderwertigkeitskomplexe oder warum musst du nach Schema "hallo, hallo, ich muss auch noch sinnloses wiederholend beitragen" dich einbringen?
Zur Berechnung Verweise ich hierauf
Glückwunsch, du hast also gar nicht gerechnet sondern einfach eine abschreckend hohe Zahl in den Raum gestellt.Um das aber nicht ganz so sinnlos wie deinen Beitrag abzuschließen: Kostenlos ist nicht mal der Tod, denn der kostet nicht nur das Leben sondern richtig Asche.
Oh toll, noch ein Spruch aus Omas Grab zum Abschluß, ich bin entzückt.(LE Einrichtung und Wartung und Updates sind z.T teurer als Kaufzertifikate.)
Bei den von dir in den Raum gestellten Preisen wohl eher nichtAngenehmes Leben noch.
/Thomas
Leute last es doch bitte gut sein. Das spielt doch wirklich keine Rolle.
1Zitat von @Th0mKa:
Zitat von @Mystery-at-min:
Minderwertigkeitskomplexe oder warum musst du nach Schema "hallo, hallo, ich muss auch noch sinnloses wiederholend beitragen" dich einbringen?
Hast du schlecht geschlafen oder bist du immer beleidigend unterwegs?Minderwertigkeitskomplexe oder warum musst du nach Schema "hallo, hallo, ich muss auch noch sinnloses wiederholend beitragen" dich einbringen?
Nein, wunderbar, danke der Nachfrage.
Zur Berechnung Verweise ich hierauf
Glückwunsch, du hast also gar nicht gerechnet sondern einfach eine abschreckend hohe Zahl in den Raum gestellt.Warum abschreckend? Ich war für den Einsatz der Transportverschlüsselung/SSL und selbst diese abschreckend hohe Zahl (du kennst dich sicher nicht aus, aber bei 4.000 Nutzer im Internen Netz sind 10.000€ Invest "quasi" nichts) ist in Relation wenig. Darum die Kalkulation 10.000/4000/5 (Aufs Jahr! je Benutzer). Kannst oder willst du mir nicht folgen? Für den Rest schien es klar zu sein.
Um das aber nicht ganz so sinnlos wie deinen Beitrag abzuschließen: Kostenlos ist nicht mal der Tod, denn der kostet nicht nur das Leben sondern richtig Asche.
Oh toll, noch ein Spruch aus Omas Grab zum Abschluss, ich bin entzückt.Hast du schlecht geschlafen oder kommst du einfach nicht mit Widerspruch klar? Er trifft aber und ist werthaltiger als dein Beitrag, der bereits abgeschlossenes nochmals komplett unnötigerweise und halbgar aufgreift.
(LE Einrichtung und Wartung und Updates sind z.T teurer als Kaufzertifikate.)
Bei den von dir in den Raum gestellten Preisen wohl eher nichtDas kommt ganz drauf an wie die Struktur ist. Denn die Einrichtung von LE Zertifikaten funktioniert nicht immer straight forward (wie das Einbetten von vorgefertigen Zertifikaten). Aber extra für dich bzw den geneigten und interessierten BWLer; Wenn über ein langes Jahr von 240 Arbeitstagen auf die Systeme von 4.000 Nutzern nur 1/2-1/3 Monatsarbeitszeit in die Zertifizierungsgeschichte (Routing, Durchleitung, Updates, Checks etc) gesteckt werden muss (was durchaus realistisch sein kann bei der Größe) bist du bei Brutto-Arbeitgeber-Gehältern von 5-6000€ schon günstiger.
Stichwort Astronomisch...>1,5 Monatsgehälter sind für den AG bereits 10.000€ und das ist "eigentlich" auch nicht wirklich viel Geld.
Da muss ich nicht mal rechnen, da reicht ein einfacher Überschlag. Ich frage mich in welchem Umfeld du agierst?
Angenehmes Leben noch.
/Thomas
Hättest einfach den ganz richtigen Kommentar von Fabbezz mit den 500 stehen lassen können, der ergab wenigstens Mehrwert durch die Korrektur eines günstigeren Zertifikats. - Wobei es um den Preis eigentlich nicht mal ging.
Ganz ehrlich... Ich kann nicht verstehen, dass einige die unverschlüsselte Übertragung von Zugangsdaten verteidigen. Intranet hin oder her.
"consult your pentester!" möchte ich sagen.
"consult your pentester!" möchte ich sagen.
1Zitat von @it-fraggle:
Ganz ehrlich... Ich kann nicht verstehen, dass einige die unverschlüsselte Übertragung von Zugangsdaten verteidigen. Intranet hin oder her.
"consult your pentester!" möchte ich sagen.
Ganz ehrlich... Ich kann nicht verstehen, dass einige die unverschlüsselte Übertragung von Zugangsdaten verteidigen. Intranet hin oder her.
"consult your pentester!" möchte ich sagen.
Sehe ich auch so.
@Mystery-at-min hat es ja treffend verlinkt:
https://www.datenschutz-wiki.de/Technische_und_organisatorische_Ma%C3%9F ...
Gemäß § 9 Bundesdatenschutzgesetz (BDSG) sind alle Stellen, welche personenbezogene Daten verarbeiten, erheben oder nutzen verpflichtet, technische und/oder organisatorische Maßnahmen (kurz: TOM) zu treffen um zu gewährleisten, dass die Sicherheits- und Schutzanforderungen des BDSG erfüllt sind. Die Spezifizierung dieser Anforderungen ergibt sich aus der Anlage (zu § 9 Satz 1) BDSG. Hier wird explizit nicht unterschieden wo das stattfindet, ob in einem öffentlichen Netz oder einem internen Netz.
Die personenbezogenen Daten sind auch in einem internen Netz als schützenswert zu betrachten.
Grüße
Epi
