30
Windows Server Verschlüsselung
Hallo!
Wir benötigen einen neuen SBS 2011-Server und überlegen uns, wie wir darauf befindliche sensible Daten am sinnvollsten schützen können vor
(1) Diebstahl, Verlust oder Garantiereklamation einzelner oder aller Platten
(2) Diebstahl, Verlust oder Garantiereklamation des gesamten Systems
Sensible Daten sind für uns Windows- und Exchange-Kontendaten (Zugangsdaten, also Benutzername/Passwort), E-Mails und Files. Die Unmöglichkeit des Zugriffs auf Daten durch Dritte in Fall (1) ist unabdingbar für uns; ein Schutz in Fall (2) wäre wünschenswert.
Das System sollte ohne Passworteingabe bis zur Möglichkeit des Aufbaus einer Remotedesktopverbindung booten können, d.h. es ist durchaus akzeptabel, wenn man nach dem Booten verschlüsselte Bereiche erst durch Eingabe eines Passwortes o.Ä. mounten muss.
Wie würdet Ihr das System konzipieren?
Im Falle einer Verschlüsselung, die ausschließlich hardwareseitig implementiert ist (Platten und Controller), hätten wir keinen nennenswerten Schutz im Fall (2). Daher überlege ich, ob es nicht am besten wäre, das System teilweise softwareseitig zu verschlüsseln. Konkrete Idee: 3 RAID-Sets, eines Betriebssystem, eines Files, eines Exchange-Datenbanken. Die Exchange- und Files-Partition/RAID-Sets würde ich komplett verschlüsseln, bei der Betriebssystempartition bin ich mir nicht im Klaren darüber, was man sinnvollerweise verschlüsseln sollte, um Windows-/Exchange-Zugangsdaten geschützt zu haben.
Für Ideen wäre ich Euch dankbar, auch in Sachen Hardwareverschlüsselung (bspw. empfehlenswerte SAS-Platten). Bei Softwareverschlüsselung würde mich interessieren, ob mit Bitlocker eine sinnvolle Umsetzung möglich wäre. Selbst habe ich bisher nur Erfahrung mit Truecrypt und diskcryptor.
Vielen Dank und Grüße,
tantalos
Wir benötigen einen neuen SBS 2011-Server und überlegen uns, wie wir darauf befindliche sensible Daten am sinnvollsten schützen können vor
(1) Diebstahl, Verlust oder Garantiereklamation einzelner oder aller Platten
(2) Diebstahl, Verlust oder Garantiereklamation des gesamten Systems
Sensible Daten sind für uns Windows- und Exchange-Kontendaten (Zugangsdaten, also Benutzername/Passwort), E-Mails und Files. Die Unmöglichkeit des Zugriffs auf Daten durch Dritte in Fall (1) ist unabdingbar für uns; ein Schutz in Fall (2) wäre wünschenswert.
Das System sollte ohne Passworteingabe bis zur Möglichkeit des Aufbaus einer Remotedesktopverbindung booten können, d.h. es ist durchaus akzeptabel, wenn man nach dem Booten verschlüsselte Bereiche erst durch Eingabe eines Passwortes o.Ä. mounten muss.
Wie würdet Ihr das System konzipieren?
Im Falle einer Verschlüsselung, die ausschließlich hardwareseitig implementiert ist (Platten und Controller), hätten wir keinen nennenswerten Schutz im Fall (2). Daher überlege ich, ob es nicht am besten wäre, das System teilweise softwareseitig zu verschlüsseln. Konkrete Idee: 3 RAID-Sets, eines Betriebssystem, eines Files, eines Exchange-Datenbanken. Die Exchange- und Files-Partition/RAID-Sets würde ich komplett verschlüsseln, bei der Betriebssystempartition bin ich mir nicht im Klaren darüber, was man sinnvollerweise verschlüsseln sollte, um Windows-/Exchange-Zugangsdaten geschützt zu haben.
Für Ideen wäre ich Euch dankbar, auch in Sachen Hardwareverschlüsselung (bspw. empfehlenswerte SAS-Platten). Bei Softwareverschlüsselung würde mich interessieren, ob mit Bitlocker eine sinnvolle Umsetzung möglich wäre. Selbst habe ich bisher nur Erfahrung mit Truecrypt und diskcryptor.
Vielen Dank und Grüße,
tantalos
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 189099
Url: https://administrator.de/contentid/189099
Printed on: April 23, 2024 at 22:04 o'clock
30 Comments
Latest comment
Moin,
zwei Threads zu einem System
Wenn Du über Verschlüsselung nachdenkst, macht eine Single Core CPU wenig Sinn, irgendwer muß ja die Rechenarbeit auch machen...
Gruß
24
zwei Threads zu einem System
Wenn Du über Verschlüsselung nachdenkst, macht eine Single Core CPU wenig Sinn, irgendwer muß ja die Rechenarbeit auch machen...
Gruß
24
Servus!
Was spricht denn gegen Hardwareverschlüsselte HDDs? Man muss dann halt bei jedem booten das ATA Passwort eingeben...
Der Dieb hat dann nur eine Chance wenn er den Server mit USV im Betrieb klaut...
Was aber gefährlicher ist: Backups... die müsst ihr auch sicher verschlüsseln...
So eine Backup HDD hat man nämlich auch mal leicht in den Rucksack gesteckt - vor allem wenn man nur noch wenige Tage in der Firma ist und zur Konkurrenz wechselt!
Was spricht denn gegen Hardwareverschlüsselte HDDs? Man muss dann halt bei jedem booten das ATA Passwort eingeben...
Der Dieb hat dann nur eine Chance wenn er den Server mit USV im Betrieb klaut...
Was aber gefährlicher ist: Backups... die müsst ihr auch sicher verschlüsseln...
So eine Backup HDD hat man nämlich auch mal leicht in den Rucksack gesteckt - vor allem wenn man nur noch wenige Tage in der Firma ist und zur Konkurrenz wechselt!
Passworteingabe beim Booten will ich ja gerade vermeiden. Ich bin oft nicht vor Ort und muss mich remote um die Dinger kümmern und mit Zugriff via KVM habe ich nicht immer guter Erfahrungen gemacht.
@2hard4you: Mit diskcryptor und Truecrypt habe ich die Erfahrung gemacht, dass die Performance von Systemen kaum sinkt. Mit Bitlocker kenne ich mich bislang nicht aus. Kannst Du ungefähre Erfahrungswerte nennen?
@2hard4you: Mit diskcryptor und Truecrypt habe ich die Erfahrung gemacht, dass die Performance von Systemen kaum sinkt. Mit Bitlocker kenne ich mich bislang nicht aus. Kannst Du ungefähre Erfahrungswerte nennen?
Na und wie willst du einen Truecrypt Container entschlüsseln ohne Passworteingabe beim booten?
Wie geschrieben würde ich das System gerne nur teilweise verschlüsseln lassen wollen, so dass es ohne PW-Eingabe bootet. Ob und wie man das am sinnvollsten macht ist gerade eine relevante Frage.
Hallo,
also ich glaub das der Exchange dir das sehr krumm nehmen würde wenn er beim Start nicht auf seine Datenbanken zugreifen kann.
Es wird doch sicher eine "Vertrauenswürde" Person vor Ort sein die für dich dann das Passwort eingeben kann.
also ich glaub das der Exchange dir das sehr krumm nehmen würde wenn er beim Start nicht auf seine Datenbanken zugreifen kann.
Es wird doch sicher eine "Vertrauenswürde" Person vor Ort sein die für dich dann das Passwort eingeben kann.
Moin,
ich denke mal bei Bitlocker dürfte das gehen - ich hoffe mal das MS intelligent genug ist das Systemdienste auch dann laufen (das OS startet ja auch).
Ich frage mich dabei nur - macht es wirklich SINN einen Server zu verschlüsseln? Dieser hat ja üblicherweise auch Dateifreigaben - was sollte also einen Hacker daran hindern einfach darüber zu gehen? Und erst entschlüsseln NACH dem Anmelden ist auch ne blöde Idee - wenn du keinem vertraust das er nen Bios-PW eingibt dann dürfte es kaum in Frage kommen das sich jemand direkt am Server anmelden kann. DU kannst jedoch auch mal krank sein, Urlaub haben - oder z.B. durch einen Netzausfall bei dir lokal technisch ganz einfach nicht in der Lage sein dich am Server anzumelden. Trotzdem muss der Betrieb ja laufen... Ausserdem müsstest du dich ja sinnvollerweise wieder abmelden am Ende - und das würde (hoffentlich) dazu führen das der Container auch wieder geschlossen wird (wenn nicht kannst du dir das ganze auch sparen...).
Der nächste Punkt der m.E. da ein großes Problem gibt: Ich glaube heute geht kaum noch einer bei und klaut den Server um an die Daten zu kommen. Der Aufwand lohnt ganz einfach nicht - Trojaner auf nen USB-Stick, Stick vorm Laden auf den Boden legen und kurz warten -> DAS ist doch eigentlich der Klassiker... In welcher Form auch immer - soweit ich also einen Mitarbeiter habe der da unvorsichtig ist dann gehe ich doch gleich ganz elegant über die Internet-Leitung. Mich sieht keiner (anders als beim physikalischen Diebstahl bei dem ich ggf. auf ner Kamara auftauche...), mit etwas Intelligenz mache ich das auch gleich so das der Trojaner sich selbst killt und somit nur der Mitarbeiter alle Daten kopiert hat... Das ganze auf nen schönen russischen Server (oder Tortuga? ;) ) und du wirst nie rausfinden wer die Daten jetzt hat. An deiner Verschlüsselung bin ich dabei elegant vorbeigegangen weil ich die Windows-Freigabe genutzt habe...
Wenn du jetzt sorgen hast wegen einzelner Platten die durch Austausch u.ä. ggf. dann mit Daten in den Verkehr kommen könnten so gibt es da m.E. 2 einfache Optionen:
a) Ich tausche die Platten aus obwohl die noch laufen (z.B. regelmäßiger Austausch, Plattenvergrößerung,...): Platte vorher mal eben dezent mit einem der Security-Tools überschreiben lassen... Selbst nen einfaches Überschreiben der Platte mit 0/1 sorgt schon dafür das man mit normalen Tools nicht mehr ran kommt, im zweifel halt 2-x mal überschreiben lassen
b) ich tausche die Platte weil die alte defekt ist: Da ich diese nicht mehr überschreiben kann im Zweifel auf die Garantie verzichten und einfach ne neue kaufen. Für die alte bietet sich $EISENSÄGE an - selbst das beste Datenrettungsunternehmen wird danach nix mehr ausrichten können... einmal in 4 Teile gesägt die platte und es ist Ruhe.
Schönen Gruß,
Mike
ich denke mal bei Bitlocker dürfte das gehen - ich hoffe mal das MS intelligent genug ist das Systemdienste auch dann laufen (das OS startet ja auch).
Ich frage mich dabei nur - macht es wirklich SINN einen Server zu verschlüsseln? Dieser hat ja üblicherweise auch Dateifreigaben - was sollte also einen Hacker daran hindern einfach darüber zu gehen? Und erst entschlüsseln NACH dem Anmelden ist auch ne blöde Idee - wenn du keinem vertraust das er nen Bios-PW eingibt dann dürfte es kaum in Frage kommen das sich jemand direkt am Server anmelden kann. DU kannst jedoch auch mal krank sein, Urlaub haben - oder z.B. durch einen Netzausfall bei dir lokal technisch ganz einfach nicht in der Lage sein dich am Server anzumelden. Trotzdem muss der Betrieb ja laufen... Ausserdem müsstest du dich ja sinnvollerweise wieder abmelden am Ende - und das würde (hoffentlich) dazu führen das der Container auch wieder geschlossen wird (wenn nicht kannst du dir das ganze auch sparen...).
Der nächste Punkt der m.E. da ein großes Problem gibt: Ich glaube heute geht kaum noch einer bei und klaut den Server um an die Daten zu kommen. Der Aufwand lohnt ganz einfach nicht - Trojaner auf nen USB-Stick, Stick vorm Laden auf den Boden legen und kurz warten -> DAS ist doch eigentlich der Klassiker... In welcher Form auch immer - soweit ich also einen Mitarbeiter habe der da unvorsichtig ist dann gehe ich doch gleich ganz elegant über die Internet-Leitung. Mich sieht keiner (anders als beim physikalischen Diebstahl bei dem ich ggf. auf ner Kamara auftauche...), mit etwas Intelligenz mache ich das auch gleich so das der Trojaner sich selbst killt und somit nur der Mitarbeiter alle Daten kopiert hat... Das ganze auf nen schönen russischen Server (oder Tortuga? ;) ) und du wirst nie rausfinden wer die Daten jetzt hat. An deiner Verschlüsselung bin ich dabei elegant vorbeigegangen weil ich die Windows-Freigabe genutzt habe...
Wenn du jetzt sorgen hast wegen einzelner Platten die durch Austausch u.ä. ggf. dann mit Daten in den Verkehr kommen könnten so gibt es da m.E. 2 einfache Optionen:
a) Ich tausche die Platten aus obwohl die noch laufen (z.B. regelmäßiger Austausch, Plattenvergrößerung,...): Platte vorher mal eben dezent mit einem der Security-Tools überschreiben lassen... Selbst nen einfaches Überschreiben der Platte mit 0/1 sorgt schon dafür das man mit normalen Tools nicht mehr ran kommt, im zweifel halt 2-x mal überschreiben lassen
b) ich tausche die Platte weil die alte defekt ist: Da ich diese nicht mehr überschreiben kann im Zweifel auf die Garantie verzichten und einfach ne neue kaufen. Für die alte bietet sich $EISENSÄGE an - selbst das beste Datenrettungsunternehmen wird danach nix mehr ausrichten können... einmal in 4 Teile gesägt die platte und es ist Ruhe
.Schönen Gruß,
Mike
Moin.
Ich habe mich ausgiebig damit befasst und das Thema umgesetzt. Unter anderem habe ich mich hier beraten lassen und gemerkt, dass sich kaum jemand damit auskennt und die Antworten nicht sehr hilfreich waren. Warum ist das so? Weil Serverräume in der Regel gegen Einbruch ausreichend physikalisch gesichert werden. Wenn dem bei Euch nicht der Fall ist und das nicht geändert werden kann, lies weiter.
Dein Problem des Hochfahrens ohne Kennwort kann nur bedingt gelöst werden. Mehrere Verschlüsselungen, Beispiel Truecrypt und Diskcryptor (abgekürzt TC und DC) bieten die Option, zum Mounten ein Keyfile zu benutzen, was die Kennworteingabe erspart. Somit kannst Du einen Server starten und im Startskript lässt Du die Platten per Keyfile mounten. Das Verschlüsselungsprogramm muss dazu natürlich per Kommandozeile bedienbar sein (gegeben bei TC und DC) und das Keyfile muss widerum auf der Freigabe eines weiteren PCs liegen, der physikalisch ausreichend gesichert ist. Ebenso muss die Freigabe gegen Einsicht Dritter gesichert sein. Soweit so gut, aber wie geht man vor bei Platten, wo auch das Betriebssystemlaufwerk verschlüsselt werden soll? Hier bietet bislang nur Bitlocker eine Lösung, und die ist nur bedingt sicher (warum, sieht man hier ) - man kann den Server einfach mitnehmen und zu Hause Coldboot-Attacken ausführen. Bitlocker in der Ausführung von Server 2012, welcher noch in diesem Jahr erscheint, löst diese Unsicherheit mittels des Features "netunlock", siehe . Beide Methoden schützen davor, dass der Server mitgenommen wird, um die Verschlüsselung seelenruhig zu Hause auszuhebeln. Sie schützen beide nicht vor Coldboot-Attacks, die noch am Tatort ausgeführt werden - das Risiko bleibt!
Zum Problem des Mountens und dem Start von Diensten: Wenn Dienste den Pfad ihres Executables nicht finden, schlägt deren Start fehl. Liegen Dienste also auf einem verschlüsselten Volume, so können Sie erst nach dem Mounten des selben gestartet werden - soweit kein Problem, Startart einfach auf manuell setzen und den Dienstestart im Startskript hinter das Mounten setzen. Das selbe gilt, wenn man Inhaltsquellen, beispielsweise Datenbanken hat, die von Diensten angesteuert werden: erst mounten, dann den Dienst starten - alles kein Problem.
Für gewisse Fälle kann man auch mit Mountpoints arbeiten, welche auf verschlüsselte Partitionen zeigen.
Ich habe das alles umgesetzt bei:
-Fileservern
-Exchangeservern
-SQL-Servern
und keine Probleme dabei.
Bei Domänencontrollern habe ich es nicht umgesetzt. Grund: überleg mal, was Du nach dem Diebstahl eines DCs machen würdest - Du würdest ihn recovern und alle Kennwörter ändern - wo ist dann das Problem? Ist jemand jedoch tatsächlich in der Lage sich in der Firma stundenlang unbemerkt nach einem Einbruch aufzuhalten, kann er natürlich auch noch vor Ort das AD auslesen und sich die Daten umgehend zu Nutze machen.
Zu hardware-verschlüsselten Platten: Bringt nichts, da immer und in jedem Fall ein Kennwort vor dem Booten erforderlich ist. Ist dies in einer vermeintlich sicheren Konfiguration solcher verschlüsselter Platten nicht erforderlich, gilt die gleiche Unsicherheit wie hier schon beschrieben: cold boot attacks.
Zukunftsmusik: neben den Entwicklungen um Bitlocker der nächsten Generation solltest Du dies im Auge behalten: "Tresor": http://events.ccc.de/congress/2011/Fahrplan/events/4869.en.html (ist nicht für Windows umgesetzt, aber kann ja noch kommen) und auch den Artikel http://de.wikipedia.org/wiki/Kaltstartattacke bei Gegenmaßnahmen auf Änderungen prüfen.
Bedenke bitte auch folgendes: ist das AD auf einem Raidsystem, welches mit Striping arbeitet, enthält eine Einzelplatte nie zusammenhängend das ganze AD. Ob ein Schurke aus der Garantieabteilung der Festplattenfirma daraus (aus den unzusammenhängenden Stripes) etwas Verwertbares basteln kann, bleibt stark zu bezweifeln. Also ist dieser Fall etwas an den Haaren herbeigezogen und ist nur dann wirklich relevant, wenn alle Plattem gleichzeitig eingeschickt werden müssten, was quasi nie vorkommen wird.
Zu konkreten Umsetzungsfragen kannst Du mich gerne kontaktieren.
Ich habe mich ausgiebig damit befasst und das Thema umgesetzt. Unter anderem habe ich mich hier beraten lassen und gemerkt, dass sich kaum jemand damit auskennt und die Antworten nicht sehr hilfreich waren. Warum ist das so? Weil Serverräume in der Regel gegen Einbruch ausreichend physikalisch gesichert werden. Wenn dem bei Euch nicht der Fall ist und das nicht geändert werden kann, lies weiter.
Dein Problem des Hochfahrens ohne Kennwort kann nur bedingt gelöst werden. Mehrere Verschlüsselungen, Beispiel Truecrypt und Diskcryptor (abgekürzt TC und DC) bieten die Option, zum Mounten ein Keyfile zu benutzen, was die Kennworteingabe erspart. Somit kannst Du einen Server starten und im Startskript lässt Du die Platten per Keyfile mounten. Das Verschlüsselungsprogramm muss dazu natürlich per Kommandozeile bedienbar sein (gegeben bei TC und DC) und das Keyfile muss widerum auf der Freigabe eines weiteren PCs liegen, der physikalisch ausreichend gesichert ist. Ebenso muss die Freigabe gegen Einsicht Dritter gesichert sein. Soweit so gut, aber wie geht man vor bei Platten, wo auch das Betriebssystemlaufwerk verschlüsselt werden soll? Hier bietet bislang nur Bitlocker eine Lösung, und die ist nur bedingt sicher (warum, sieht man hier ) - man kann den Server einfach mitnehmen und zu Hause Coldboot-Attacken ausführen. Bitlocker in der Ausführung von Server 2012, welcher noch in diesem Jahr erscheint, löst diese Unsicherheit mittels des Features "netunlock", siehe . Beide Methoden schützen davor, dass der Server mitgenommen wird, um die Verschlüsselung seelenruhig zu Hause auszuhebeln. Sie schützen beide nicht vor Coldboot-Attacks, die noch am Tatort ausgeführt werden - das Risiko bleibt!
Zum Problem des Mountens und dem Start von Diensten: Wenn Dienste den Pfad ihres Executables nicht finden, schlägt deren Start fehl. Liegen Dienste also auf einem verschlüsselten Volume, so können Sie erst nach dem Mounten des selben gestartet werden - soweit kein Problem, Startart einfach auf manuell setzen und den Dienstestart im Startskript hinter das Mounten setzen. Das selbe gilt, wenn man Inhaltsquellen, beispielsweise Datenbanken hat, die von Diensten angesteuert werden: erst mounten, dann den Dienst starten - alles kein Problem.
Für gewisse Fälle kann man auch mit Mountpoints arbeiten, welche auf verschlüsselte Partitionen zeigen.
Ich habe das alles umgesetzt bei:
-Fileservern
-Exchangeservern
-SQL-Servern
und keine Probleme dabei.
Bei Domänencontrollern habe ich es nicht umgesetzt. Grund: überleg mal, was Du nach dem Diebstahl eines DCs machen würdest - Du würdest ihn recovern und alle Kennwörter ändern - wo ist dann das Problem? Ist jemand jedoch tatsächlich in der Lage sich in der Firma stundenlang unbemerkt nach einem Einbruch aufzuhalten, kann er natürlich auch noch vor Ort das AD auslesen und sich die Daten umgehend zu Nutze machen.
Zu hardware-verschlüsselten Platten: Bringt nichts, da immer und in jedem Fall ein Kennwort vor dem Booten erforderlich ist. Ist dies in einer vermeintlich sicheren Konfiguration solcher verschlüsselter Platten nicht erforderlich, gilt die gleiche Unsicherheit wie hier schon beschrieben: cold boot attacks.
Zukunftsmusik: neben den Entwicklungen um Bitlocker der nächsten Generation solltest Du dies im Auge behalten: "Tresor": http://events.ccc.de/congress/2011/Fahrplan/events/4869.en.html (ist nicht für Windows umgesetzt, aber kann ja noch kommen) und auch den Artikel http://de.wikipedia.org/wiki/Kaltstartattacke bei Gegenmaßnahmen auf Änderungen prüfen.
Bedenke bitte auch folgendes: ist das AD auf einem Raidsystem, welches mit Striping arbeitet, enthält eine Einzelplatte nie zusammenhängend das ganze AD. Ob ein Schurke aus der Garantieabteilung der Festplattenfirma daraus (aus den unzusammenhängenden Stripes) etwas Verwertbares basteln kann, bleibt stark zu bezweifeln. Also ist dieser Fall etwas an den Haaren herbeigezogen und ist nur dann wirklich relevant, wenn alle Plattem gleichzeitig eingeschickt werden müssten, was quasi nie vorkommen wird.
Zu konkreten Umsetzungsfragen kannst Du mich gerne kontaktieren.
Moin Maretz.
Du hast damals in meinem Thread Verschlüsselung im Serverraum auch mitgewirkt - meiner Ansicht nach ohne genug Hintergrundwissen zu besitzen, was beispielsweise technische Hintergründe des Mountings angeht. Setz' Dich jetzt mal damit auseinander. Bevor der nächste wieder solche Tipps erhält, empfehle Ich Dir, Dich selbst zunächst eingehender zu informieren.
Ich frage mich dabei nur - macht es wirklich SINN einen Server zu verschlüsseln?...
Lies mal meinen Erfahrungsbericht Windows Server Verschlüsselung - dort steht, wovor man schützen kann und wovor nicht und wie das geht....Dateifreigaben - was sollte also einen Hacker daran hindern einfach darüber zu gehen?
Richtig, aber das ist ein anderer Angriffspunkt. Die Freigaben musst Du eh schützen, hier ist die Rede von Angreifern, die die Platte in der Hand halten.Und erst entschlüsseln NACH dem Anmelden ist auch ne blöde Idee
Das löst man nicht über eine echte Anmeldung, sondern über ein Startskript/einen gepl. Task mit Trigger: "Systemstart"Ausserdem müsstest du dich ja sinnvollerweise wieder abmelden am Ende - und das würde (hoffentlich) dazu führen das der Container auch wieder geschlossen wird (wenn nicht kannst du dir das ganze auch sparen...).
Der Logik kann ich nicht folgen. Wenn ich etwas mounte, ist es danach verfügbar, egal, ob ich noch angemeldet bin, oder nicht. Der Crypto-Container soll ja bereit stehen und zwar dauerhaft, es ist ein Server. Nur soll er eben nicht verfügbar sein für Diebe, die an die Plattensysteme rangehen und das ist gewährleistet....Trojaner auf nen USB-Stick, Stick vorm Laden auf den Boden legen und kurz warten -> DAS ist doch eigentlich der Klassiker
Mein Kollege Meier hebt also den Stick auf, infiziert damit seinen Rechner und schon fließen alle Daten des Servers ab? Maximal fließen Meiers servergespeicherte Daten ab. [bei uns ginge nicht einmal das, da die Mitarbeiter nur über einen RDP-Internetzugang verfügen und auf dem RD-Session Host können keine Firmndokumente gelangen bis auf den Inhalt der Zwischenablage. Somit wäre die USB-Stick-Attacke bei uns nicht möglich).Du hast damals in meinem Thread Verschlüsselung im Serverraum auch mitgewirkt - meiner Ansicht nach ohne genug Hintergrundwissen zu besitzen, was beispielsweise technische Hintergründe des Mountings angeht. Setz' Dich jetzt mal damit auseinander. Bevor der nächste wieder solche Tipps erhält, empfehle Ich Dir, Dich selbst zunächst eingehender zu informieren.
Hallo Mike,
ich denke, Du bringst hier ein paar Sachen durcheinander. DerWoWusste ist schon darauf eingegangen.
Aber Kosten scheinen bei Dir ja nicht so die Rolle zu spielen, wenn Du Zeit für ne Sägenbehandlung hast. Ich wäre da eher der Hammer-Typ
Trotzdem Danke,
tantalos
ich denke, Du bringst hier ein paar Sachen durcheinander. DerWoWusste ist schon darauf eingegangen.
Zitat von @maretz:
Wenn du jetzt sorgen hast wegen einzelner Platten die durch Austausch u.ä. ggf. dann mit Daten in den Verkehr kommen
könnten so gibt es da m.E. 2 einfache Optionen:
a) Ich tausche die Platten aus obwohl die noch laufen (z.B. regelmäßiger Austausch,
Plattenvergrößerung,...): Platte vorher mal eben dezent mit einem der Security-Tools überschreiben lassen...
Selbst nen einfaches Überschreiben der Platte mit 0/1 sorgt schon dafür das man mit normalen Tools nicht mehr ran kommt,
im zweifel halt 2-x mal überschreiben lassen
b) ich tausche die Platte weil die alte defekt ist: Da ich diese nicht mehr überschreiben kann im Zweifel auf die Garantie
verzichten und einfach ne neue kaufen. Für die alte bietet sich $EISENSÄGE an - selbst das beste
Datenrettungsunternehmen wird danach nix mehr ausrichten können... einmal in 4 Teile gesägt die platte und es ist Ruhe
.
Bin mir nicht sicher, ob Du weißt, was schnelle SAS-Platten hoher Kapazität kosten: derzeit ca. 300-600 €. Ich und die meisten Leute, die ich kenne, fänden es nicht so lustig, solche Platten im Defektfall mit einer Eisensäge zu behandeln, wenn man im Rahmen der Herstellergarantie kostenfrei Ersatz bekommen könnte.Wenn du jetzt sorgen hast wegen einzelner Platten die durch Austausch u.ä. ggf. dann mit Daten in den Verkehr kommen
könnten so gibt es da m.E. 2 einfache Optionen:
a) Ich tausche die Platten aus obwohl die noch laufen (z.B. regelmäßiger Austausch,
Plattenvergrößerung,...): Platte vorher mal eben dezent mit einem der Security-Tools überschreiben lassen...
Selbst nen einfaches Überschreiben der Platte mit 0/1 sorgt schon dafür das man mit normalen Tools nicht mehr ran kommt,
im zweifel halt 2-x mal überschreiben lassen
b) ich tausche die Platte weil die alte defekt ist: Da ich diese nicht mehr überschreiben kann im Zweifel auf die Garantie
verzichten und einfach ne neue kaufen. Für die alte bietet sich $EISENSÄGE an - selbst das beste
Datenrettungsunternehmen wird danach nix mehr ausrichten können... einmal in 4 Teile gesägt die platte und es ist Ruhe
.Aber Kosten scheinen bei Dir ja nicht so die Rolle zu spielen, wenn Du Zeit für ne Sägenbehandlung hast. Ich wäre da eher der Hammer-Typ
Trotzdem Danke,
tantalos
Hallo Wissender,
danke für Deine kompetente Antwort.
Hardware-Verschlüsselung habe ich mittlerweile verworfen. Kennworteingabe vor dem Booten scheidet für mich aus und in allen anderen Fällen ist ein System letztlich nicht sicher im Diebstahlfall. Einerseits wegen des von Dir aufgeführten Problemkreises cold boot attacks, andererseits weil offenbar viele Hardware-seitigen Lösungen die Schlüssel von Sticks lesen, weshalb man noch nicht einmal mehr von Attacke reden muss. Der Schutz würde sich dann nur auf das Garantiefallszenario beschränken.
Was die Verschlüsselung der Systempartition mittels Bitlocker angeht: Ist hier eine Möglichkeit denkbar, bei der das System ohne Passworteingabe bis zum Login hochfährt, so dass eine Anmeldung via RDP erfolgen kann? Entschlüsselung dann letztlich wohl gekoppelt ans Windows-Passwort?!
Die von Dir vorgeschlagene Lösung mittels Skript, das die von den jeweiligen Diensten benötigten Volumes entschlüsselt, mountet und dann die Dienste startet, scheint mir ein sinnvoller Ansatz zu sein, den ich nun wohl weiterverfolgen werde.
Deine Sicht bzgl. Domänencontroller ist sehr plausibel.
Was ich nicht richtig einschätzen kann: Was an sensiblen Daten (Files, Exchange-Daten) in temporären Dateien und im Pagefile steht und wie man hier ggf. mittels Verschlüsselung für mehr Sicherheit sorgen kann, wieder unter der Prämisse, vor dem Booten kein Kennwort eingeben zu müssen. Ein Pagefile auf einem unverschlüsselten Systemvolume wäre ein Risiko, oder?
Und was das Entschlüsselungspasswort angeht: Wenn dieses im RAM vorgehalten wird, besteht dann grundsätzlich auch die Gefahr, dass es im Pagefile persistent ist? Also: Eine unverschlüsselte Systemplatte in einem RAID 1 fällt im laufenden Betrieb des Systems aus und soll zur Garantiereklamation an den Hersteller eingesendet werden. Problematisch was die Sicherheit des Keys angeht, oder? Sofern nicht gleichzeitig eine Platte aus einem Volume, auf dem die sensiblen Daten vorgehalten werden, ausfällt, freilich in praxi nicht dramatisch. Und man kann den Key ja auch ändern.
Wie siehst Du das?
Vielen Dank und Grüße,
tantalos
danke für Deine kompetente Antwort.
Hardware-Verschlüsselung habe ich mittlerweile verworfen. Kennworteingabe vor dem Booten scheidet für mich aus und in allen anderen Fällen ist ein System letztlich nicht sicher im Diebstahlfall. Einerseits wegen des von Dir aufgeführten Problemkreises cold boot attacks, andererseits weil offenbar viele Hardware-seitigen Lösungen die Schlüssel von Sticks lesen, weshalb man noch nicht einmal mehr von Attacke reden muss. Der Schutz würde sich dann nur auf das Garantiefallszenario beschränken.
Was die Verschlüsselung der Systempartition mittels Bitlocker angeht: Ist hier eine Möglichkeit denkbar, bei der das System ohne Passworteingabe bis zum Login hochfährt, so dass eine Anmeldung via RDP erfolgen kann? Entschlüsselung dann letztlich wohl gekoppelt ans Windows-Passwort?!
Die von Dir vorgeschlagene Lösung mittels Skript, das die von den jeweiligen Diensten benötigten Volumes entschlüsselt, mountet und dann die Dienste startet, scheint mir ein sinnvoller Ansatz zu sein, den ich nun wohl weiterverfolgen werde.
Deine Sicht bzgl. Domänencontroller ist sehr plausibel.
Was ich nicht richtig einschätzen kann: Was an sensiblen Daten (Files, Exchange-Daten) in temporären Dateien und im Pagefile steht und wie man hier ggf. mittels Verschlüsselung für mehr Sicherheit sorgen kann, wieder unter der Prämisse, vor dem Booten kein Kennwort eingeben zu müssen. Ein Pagefile auf einem unverschlüsselten Systemvolume wäre ein Risiko, oder?
Und was das Entschlüsselungspasswort angeht: Wenn dieses im RAM vorgehalten wird, besteht dann grundsätzlich auch die Gefahr, dass es im Pagefile persistent ist? Also: Eine unverschlüsselte Systemplatte in einem RAID 1 fällt im laufenden Betrieb des Systems aus und soll zur Garantiereklamation an den Hersteller eingesendet werden. Problematisch was die Sicherheit des Keys angeht, oder? Sofern nicht gleichzeitig eine Platte aus einem Volume, auf dem die sensiblen Daten vorgehalten werden, ausfällt, freilich in praxi nicht dramatisch. Und man kann den Key ja auch ändern.
Wie siehst Du das?
Vielen Dank und Grüße,
tantalos
Moin,
fange ich mal hier an..
Kosten: Doch, es ist mir schon bewusst das SAS-Platten einiges kosten... Ich kenne auch noch Preise von SCSI-Platten usw. - und was willst du mir damit sagen? Ich könnte jetzt darauf hinweisen das der Tausch einer einzelnen Platte aus einem RAID5-System eh eher kein Risiko ist, da du damit nichts anfangen kannst - egal welche Platte du davon nimmst, eine einzelne Platte hat nie genug Informationen um die Daten darauf wiederherzustellen... Glaubst du nicht? Gut, geh an euren Firmenserver und ziehe aus dem RAID5 alle Platten bis auf eine raus... Dies passiert im übrigen Automatisch - ohne Verschlüsselung oder sonst was. Wenn dir DAS jedoch nicht sicher genug ist dann hilft eben irgendwann nur noch die physikalische Vernichtung der Daten wenn die Platte sonst nicht mehr ansprechbar ist.
Jetzt geh ich mal eine Nummer höher:
[quote]
Zum Problem des Mountens und dem Start von Diensten: Wenn Dienste den Pfad ihres Executables nicht finden, schlägt deren Start fehl. Liegen Dienste also auf einem verschlüsselten Volume, so können Sie erst nach dem Mounten des selben gestartet werden - soweit kein Problem, Startart einfach auf manuell setzen und den Dienstestart im Startskript hinter das Mounten setzen. Das selbe gilt, wenn man Inhaltsquellen, beispielsweise Datenbanken hat, die von Diensten angesteuert werden: erst mounten, dann den Dienst starten - alles kein Problem.
[/quote]
Hier fängt das erste Problem an. Natürlich ist es generell kein Problem wenn man das macht sofern ein Admin dauerhaft zur Verfügung steht. Dann könnte ich auch das ganze geraffel mit der Keyfile umgehen indem ich eben doch auf ein Boot-Passwort setze. Hier hilft entweder ein Netzwerk-KVM zur Eingabe des Passworts - oder die Management-Oberfläche die gute Server bieten (wie kommst du wohl beim Server ins Bios z.B. ohne davor zu sitzen?). Was passiert aber wenn der Admin _NICHT_ erreichbar ist - z.B. weil der grad im Flugzeug sitzt oder einfach mal Krank ist? Einen "ungesicherten" Server kann - so er gut eingerichtet ist - jeder Depp neustarten bzw. der startet sich nach dem Stromausfall (wenn auch die USV versagt...). Der startet die Dienste eben automatisch - und die Leute können weiterarbeiten. Wenn das nicht passiert hast du am Ende zwar nen Server, der kann aber seine Daten nicht bereitstellen und die Leute stehen rum. Jetzt die Frage an die erleuchteten: Wo ist die Chance höher - das der Server neu gebootet wird (aus welchem Grund auch immer) oder das der geklaut wird?
[quote]
Richtig, aber das ist ein anderer Angriffspunkt. Die Freigaben musst Du eh schützen, hier ist die Rede von Angreifern, die die Platte in der Hand halten.
[/quote]
So liebe ich das - am besten nen dickes Schloss an die Haustür - aber um die offenen Fenster kümmert man sich irgendwann anders...
[quote]
Und erst entschlüsseln NACH dem Anmelden ist auch ne blöde Idee
Das löst man nicht über eine echte Anmeldung, sondern über ein Startskript/einen gepl. Task mit Trigger: "Systemstart"
[/quote]
Ich gehe davon aus du möchtest also damit das Startskript bereits starten lassen wenn da noch das lustige "Bitte drücken Sie Strg+Alt+Entf..." steht? Das würde ja nur dann eine Sicherheit bringen wenn du das Keyfile wirklich auf einen anderen Rechner gelegt hast. Auch hier gilt aber wieder: M.E. nur dann nutzbar wenn ein Admin ständig erreichbar ist. Was passiert wenn z.B. der Keyfile-Rechner nicht mehr erreichbar ist (abgeschmiert, defekt o.ä.)? Hast du hier nur einen Admin (oder gar keinen, sondern wegen Sparsamkeit nur die Hotline eines Systemhauses...) hast du auch hier wieder erhebliche Probleme...
Jetzt zu deinem Schlusssatz: Ja, du bist der erleuchtete... Und ja - so wie du es beschrieben hast kann es funktionieren, daran Zweifel ich auch nicht. Nur: Es erfordert eben eine ständige Bereitschaft einer IT-Person die sich in dem Bereich auskennt (da oftmals in Firmen auch die IT leider schon bei geht und sagt "sorry, word ist nicht mein Bereich, da kann ich nicht sagen wie sie drucken können"). Wenn man das hat - dann kann sich das auch lohnen. Jedoch muss man sich halt immer darüber im klaren sein wo die Risiken liegen - und das man eben ohne die Vorraussetzungen der IT-Personen damit schnell auch mal nen großen Ausfall produziert.
Denn natürlich muss man auch noch daran denken die Backups zu verschlüsseln (ist ja doof wenn man den Server verschlüsselt bis zum Ende und der Dieb einfach die teure Backup-Platte / das Backup-Band in die Hände bekommt weil es zum Austausch geschickt wurde... nicht das es wieder heisst ich würde Geld verschwenden wollen!). Und somit hat man das Problem das jede Datenrettung im Notfall eben auch erheblich schwerer wird (sichere ich nur den Container und die Kopie hat nen Defekt ist alles im Eimer... sichere ich alle Daten des Containers muss ich die Platte entsprechend schützen).
Weiterhin holt man sich natürlich noch andere Risiken ins Haus an die man dabei denken muss - was passiert z.B. wenn der Virenscanner plötzlich im Container ne Signatur zu erkennen glaubt (passiert nicht? Ich glaub es hat diverse Leute gegeben bei denen McAfee z.B. schon nen Win-Systemdienst als Virus erkannt hat...).
Und sollte man hier einen Fehler machen - dann ist es für einen Angreifer extrem leicht an die Daten zu kommen -> er kauft die aus der Insolvenz-Masse ...
fange ich mal hier an..
Kosten: Doch, es ist mir schon bewusst das SAS-Platten einiges kosten... Ich kenne auch noch Preise von SCSI-Platten usw. - und was willst du mir damit sagen? Ich könnte jetzt darauf hinweisen das der Tausch einer einzelnen Platte aus einem RAID5-System eh eher kein Risiko ist, da du damit nichts anfangen kannst - egal welche Platte du davon nimmst, eine einzelne Platte hat nie genug Informationen um die Daten darauf wiederherzustellen... Glaubst du nicht? Gut, geh an euren Firmenserver und ziehe aus dem RAID5 alle Platten bis auf eine raus... Dies passiert im übrigen Automatisch - ohne Verschlüsselung oder sonst was. Wenn dir DAS jedoch nicht sicher genug ist dann hilft eben irgendwann nur noch die physikalische Vernichtung der Daten wenn die Platte sonst nicht mehr ansprechbar ist.
Jetzt geh ich mal eine Nummer höher:
[quote]
Zum Problem des Mountens und dem Start von Diensten: Wenn Dienste den Pfad ihres Executables nicht finden, schlägt deren Start fehl. Liegen Dienste also auf einem verschlüsselten Volume, so können Sie erst nach dem Mounten des selben gestartet werden - soweit kein Problem, Startart einfach auf manuell setzen und den Dienstestart im Startskript hinter das Mounten setzen. Das selbe gilt, wenn man Inhaltsquellen, beispielsweise Datenbanken hat, die von Diensten angesteuert werden: erst mounten, dann den Dienst starten - alles kein Problem.
[/quote]
Hier fängt das erste Problem an. Natürlich ist es generell kein Problem wenn man das macht sofern ein Admin dauerhaft zur Verfügung steht. Dann könnte ich auch das ganze geraffel mit der Keyfile umgehen indem ich eben doch auf ein Boot-Passwort setze. Hier hilft entweder ein Netzwerk-KVM zur Eingabe des Passworts - oder die Management-Oberfläche die gute Server bieten (wie kommst du wohl beim Server ins Bios z.B. ohne davor zu sitzen?). Was passiert aber wenn der Admin _NICHT_ erreichbar ist - z.B. weil der grad im Flugzeug sitzt oder einfach mal Krank ist? Einen "ungesicherten" Server kann - so er gut eingerichtet ist - jeder Depp neustarten bzw. der startet sich nach dem Stromausfall (wenn auch die USV versagt...). Der startet die Dienste eben automatisch - und die Leute können weiterarbeiten. Wenn das nicht passiert hast du am Ende zwar nen Server, der kann aber seine Daten nicht bereitstellen und die Leute stehen rum. Jetzt die Frage an die erleuchteten: Wo ist die Chance höher - das der Server neu gebootet wird (aus welchem Grund auch immer) oder das der geklaut wird?
[quote]
Richtig, aber das ist ein anderer Angriffspunkt. Die Freigaben musst Du eh schützen, hier ist die Rede von Angreifern, die die Platte in der Hand halten.
[/quote]
So liebe ich das - am besten nen dickes Schloss an die Haustür - aber um die offenen Fenster kümmert man sich irgendwann anders...
[quote]
Und erst entschlüsseln NACH dem Anmelden ist auch ne blöde Idee
Das löst man nicht über eine echte Anmeldung, sondern über ein Startskript/einen gepl. Task mit Trigger: "Systemstart"
[/quote]
Ich gehe davon aus du möchtest also damit das Startskript bereits starten lassen wenn da noch das lustige "Bitte drücken Sie Strg+Alt+Entf..." steht? Das würde ja nur dann eine Sicherheit bringen wenn du das Keyfile wirklich auf einen anderen Rechner gelegt hast. Auch hier gilt aber wieder: M.E. nur dann nutzbar wenn ein Admin ständig erreichbar ist. Was passiert wenn z.B. der Keyfile-Rechner nicht mehr erreichbar ist (abgeschmiert, defekt o.ä.)? Hast du hier nur einen Admin (oder gar keinen, sondern wegen Sparsamkeit nur die Hotline eines Systemhauses...) hast du auch hier wieder erhebliche Probleme...
Jetzt zu deinem Schlusssatz: Ja, du bist der erleuchtete... Und ja - so wie du es beschrieben hast kann es funktionieren, daran Zweifel ich auch nicht. Nur: Es erfordert eben eine ständige Bereitschaft einer IT-Person die sich in dem Bereich auskennt (da oftmals in Firmen auch die IT leider schon bei geht und sagt "sorry, word ist nicht mein Bereich, da kann ich nicht sagen wie sie drucken können"). Wenn man das hat - dann kann sich das auch lohnen. Jedoch muss man sich halt immer darüber im klaren sein wo die Risiken liegen - und das man eben ohne die Vorraussetzungen der IT-Personen damit schnell auch mal nen großen Ausfall produziert.
Denn natürlich muss man auch noch daran denken die Backups zu verschlüsseln (ist ja doof wenn man den Server verschlüsselt bis zum Ende und der Dieb einfach die teure Backup-Platte / das Backup-Band in die Hände bekommt weil es zum Austausch geschickt wurde... nicht das es wieder heisst ich würde Geld verschwenden wollen!). Und somit hat man das Problem das jede Datenrettung im Notfall eben auch erheblich schwerer wird (sichere ich nur den Container und die Kopie hat nen Defekt ist alles im Eimer... sichere ich alle Daten des Containers muss ich die Platte entsprechend schützen).
Weiterhin holt man sich natürlich noch andere Risiken ins Haus an die man dabei denken muss - was passiert z.B. wenn der Virenscanner plötzlich im Container ne Signatur zu erkennen glaubt (passiert nicht? Ich glaub es hat diverse Leute gegeben bei denen McAfee z.B. schon nen Win-Systemdienst als Virus erkannt hat...).
Und sollte man hier einen Fehler machen - dann ist es für einen Angreifer extrem leicht an die Daten zu kommen -> er kauft die aus der Insolvenz-Masse ...
*full ack* @ Maretz
*damites30Zeichenwerden*
*damites30Zeichenwerden*
Hallo Maretz!
Ich fang mal hinten an und möchte etwas klar stellen:
Ich betreibe hier kein Klug###ertum und keine Selbstbeweihräucherung oder sonstwas, stell das also bitte nicht so hin.
Zur Sache:
Du stellst in Frage, ob man sich bei der Verschlüsselei Unsicherheit einhandelt, ob der Server unbeaufsichtigt überhaupt noch bootet. Die Frage ist mehr als berechtigt. Natürlich muss die Freigabe, welche die Keyfiles hält, redundant sein. Aber das ist nichts, was eine vernünftige Planung nicht wuppen kann. Steht meine Freigabe nicht zur Verfügung, wird eine andere genommen. Steht die nicht zur Verfügung, wird benachrichtigt und automatisch neu probiert, bis es klappt. Und ein Vertreter des Admins ist immer vorhanden, bei Euch nicht? Es gibt noch eine Menge andere Sachen, bei denen Vertreter einzuweisen sind, schätze ich mal.
Zu Erfahrungswerten hier: wir haben 8 Server so verschlüsselt und bei keinem gab es in den letzten 2 Jahren eine Downtime, die auf Verschlüsselung zurückzuführen war.
Dein Kommentar zu den Freigaben verstehe ich nicht:
Schönen Gruß!
DWW
Ich fang mal hinten an und möchte etwas klar stellen:
Ja, du bist der erleuchtete...
Fang nicht mit so einer Tour an. Du hattest vor 3 Jahren tüchtig mitgemischt ohne eigene Erfahrung auf dem Gebiet zu haben und Deine jetzigen Kommentare lassen weiter darauf schließen, dass Du nur eine Meinung zum Thema hast, ohne auf eigene Erfahrungen zu der Materie zurückgreifen zu können. Ganz einfach.Ich betreibe hier kein Klug###ertum und keine Selbstbeweihräucherung oder sonstwas, stell das also bitte nicht so hin.
Zur Sache:
Du stellst in Frage, ob man sich bei der Verschlüsselei Unsicherheit einhandelt, ob der Server unbeaufsichtigt überhaupt noch bootet. Die Frage ist mehr als berechtigt. Natürlich muss die Freigabe, welche die Keyfiles hält, redundant sein. Aber das ist nichts, was eine vernünftige Planung nicht wuppen kann. Steht meine Freigabe nicht zur Verfügung, wird eine andere genommen. Steht die nicht zur Verfügung, wird benachrichtigt und automatisch neu probiert, bis es klappt. Und ein Vertreter des Admins ist immer vorhanden, bei Euch nicht? Es gibt noch eine Menge andere Sachen, bei denen Vertreter einzuweisen sind, schätze ich mal.
Zu Erfahrungswerten hier: wir haben 8 Server so verschlüsselt und bei keinem gab es in den letzten 2 Jahren eine Downtime, die auf Verschlüsselung zurückzuführen war.
Dein Kommentar zu den Freigaben verstehe ich nicht:
So liebe ich das - am besten nen dickes Schloss an die Haustür - aber um die offenen Fenster kümmert man sich irgendwann anders...
Was soll das bedeuten? Ich habe darauf hingewiesen, dass wir hier einen bestimmten Angriffsfall behandeln. Dass man auch anders an die Daten kommen könnte, bleibt davon unbenommen, ist hier aber nicht Thema.Ich gehe davon aus du möchtest also damit das Startskript bereits starten lassen wenn da noch das lustige "Bitte drücken Sie Strg+Alt+Entf..." steht? Das würde ja nur dann eine Sicherheit bringen wenn du das Keyfile wirklich auf einen anderen Rechner gelegt hast
Ja, schrieb ich doch. Die Keyfiles liegen auf einer Freigabe eines anderen ausreichend zugangsgesicherten PCs.Schönen Gruß!
DWW
Moin tantalos.
... Verschlüsselung der Systempartition mittels Bitlocker ...
Bitlocker ist hier nicht wirklich brauchbar, wie schon erwähnt. Es ist zwar besser als nichts, aber der Dieb kann den Rechner mitnehmen und gemütlich zu Hause knacken per coldboot-Attacke. Das könnte er mit der Keyfile-Methode nicht, hier wäre er gezwungen, bereits am Tatort coldboot zu nutzen.Was an sensiblen Daten (Files, Exchange-Daten) in temporären Dateien und im Pagefile steht...
Warum sollten diese Dateien am Server temporär liegen? Arbeitest Du am Server per RDP? Die Dateien werden nicht in der Pagefile landen, und auch sonst nirgends.Und was das Entschlüsselungspasswort angeht: Wenn dieses im RAM vorgehalten wird, besteht dann grundsätzlich auch die Gefahr, dass es im Pagefile persistent ist?
Nein. Das bleibt im RAM. Wenn Du Angst hast, kannst Du die Pagefile verschlüsseln, diese Option ist in Windows schon eingebaut.Zitat von @maretz:
Kosten: Doch, es ist mir schon bewusst das SAS-Platten einiges kosten... Ich kenne auch noch Preise von SCSI-Platten usw. - und
was willst du mir damit sagen?
Kosten: Doch, es ist mir schon bewusst das SAS-Platten einiges kosten... Ich kenne auch noch Preise von SCSI-Platten usw. - und
was willst du mir damit sagen?
Dass es sich lohnt, defekte Platten im Rahmen eines Garantieaustausches kostenfrei ersetzt zu bekommen. Bei vorhandener Verschlüsselung ist auch die Security gewahrt. Wenn Security ein Thema ist, kann ich bei vorhandener Verschlüsselung eine Platte im Rahmen eines Garantieaustausches kostenfrei ersetzt bekommen, indem ich sie, wie sie ist, einsende.
Ich muss sie nicht zerhämmern (oder in Deinem Fall zersägen) und dann entsorgen.
Und das spart Geld, u. U. ein paar hundert Euro, wenn es sich um teure SAS-Platten handelt.
Zitat von @maretz:
Ich könnte jetzt darauf hinweisen das der Tausch einer einzelnen Platte aus einem RAID5-System
eh eher kein Risiko ist, da du damit nichts anfangen kannst - egal welche Platte du davon nimmst, eine einzelne Platte hat nie
genug Informationen um die Daten darauf wiederherzustellen... Glaubst du nicht? Gut, geh an euren Firmenserver und ziehe aus dem
RAID5 alle Platten bis auf eine raus... Dies passiert im übrigen Automatisch - ohne Verschlüsselung oder sonst was.
Ich könnte jetzt darauf hinweisen das der Tausch einer einzelnen Platte aus einem RAID5-System
eh eher kein Risiko ist, da du damit nichts anfangen kannst - egal welche Platte du davon nimmst, eine einzelne Platte hat nie
genug Informationen um die Daten darauf wiederherzustellen... Glaubst du nicht? Gut, geh an euren Firmenserver und ziehe aus dem
RAID5 alle Platten bis auf eine raus... Dies passiert im übrigen Automatisch - ohne Verschlüsselung oder sonst was.
Kannst Du mir plausibel darlegen, dass es nicht möglich ist, aus einer Platte eines RAID5 auch nur einen Datenblock erfolgreich lesen zu können (der ggf. eine sensible Information am Stück, wie ein Passwort enthält)?
Würde mich interessieren, auch wenn RAID5 im konkreten Fall nicht in Frage kommt (es muss aus verschiedenen Gründen ein bzw. mehrere RAID1 sein).
Zitat von @maretz:
Hier fängt das erste Problem an. Natürlich ist es generell kein Problem wenn man das macht sofern ein Admin dauerhaft
zur Verfügung steht.
Hier fängt das erste Problem an. Natürlich ist es generell kein Problem wenn man das macht sofern ein Admin dauerhaft
zur Verfügung steht.
In dem Szenario haben wir es zum Glück mit Menschen zu tun, die in der Lage sind, auf ein Icon zu klicken und auf eine Aufforderung hin, ein Passwort einzugeben, selbiges auch eingeben zu können. Im Keyfile-Einlesen-Fall würde auch dies entfallen.
Mag freilich sein, dass es in anderen Firmen bei der Bewältigung solcher Aufgaben zu Situationen der Überforderung kommt.
Generell sollte (und kann) es für "Notfälle" aller Art (Admin verreist, Admin tot, externer IT-Dienstleister pleite etc.) einen Plan geben.
Was Deine Bemerkung bzgl. Vorkehrungen gegen Diebstahl angeht: Wünschenswert, aber nicht Thema des Threads.
Grüße,
tantalos
Zitat von @DerWoWusste:
> Was an sensiblen Daten (Files, Exchange-Daten) in temporären Dateien und im Pagefile steht...
Warum sollten diese Dateien am Server temporär liegen? Arbeitest Du am Server per RDP? Die Dateien werden nicht in der
Pagefile landen, und auch sonst nirgends.
> Was an sensiblen Daten (Files, Exchange-Daten) in temporären Dateien und im Pagefile steht...
Warum sollten diese Dateien am Server temporär liegen? Arbeitest Du am Server per RDP? Die Dateien werden nicht in der
Pagefile landen, und auch sonst nirgends.
Ja, ich arbeite per RDP.
Ich habe nun mal keine Ahnung, was für Daten im Pagefile landen.
Danke für den Tipp mit der Möglichkeit der Verschlüsselung des Pagefiles. War mir neu.
Hallo tantalos,
ich schließe mich dem Beitrag von maretz an und würde sogar noch einen schritt weiter gehen.
1. Ein ausreichend dimensioniertes NAS oder SAS System kaufen und per Netzwerk anbinden.
2. Auf diesem die Verschlüsselung aktivieren.
Kostet natürlich eine Kleinigkeit, aber wenn der Fokus wie in deinem Fall auf Sicherheit ausgelegt ist sollte das von vorne herein klar sein. Der Server bietet die Dienste an und die Verschlüsselten Dateien liegen auf dem NAS / SAS System.
Sollte es einmal Probleme mit der Verschlüsselung geben, so ist der Server davon nicht betroffen und kann in Ruhe weiter laufen und Du hast ein Problem weniger. Und was ich gerne mal persönlich von Dir wissen möchte: "Wie bitte sieht deine Backup-Strategie in diesem Fall aus?" Auf die verschlüsselten Daten bezogen meine ich natürlich. Bei dem NAS oder SAS System kann ich mit Schattenkopien oder Snapshots arbeiten, bei dem Server ist das nur möglich wenn die Verbindung zur Datenbank gekappt wird, falls da eine Besteht.
ich schließe mich dem Beitrag von maretz an und würde sogar noch einen schritt weiter gehen.
1. Ein ausreichend dimensioniertes NAS oder SAS System kaufen und per Netzwerk anbinden.
2. Auf diesem die Verschlüsselung aktivieren.
Kostet natürlich eine Kleinigkeit, aber wenn der Fokus wie in deinem Fall auf Sicherheit ausgelegt ist sollte das von vorne herein klar sein. Der Server bietet die Dienste an und die Verschlüsselten Dateien liegen auf dem NAS / SAS System.
Sollte es einmal Probleme mit der Verschlüsselung geben, so ist der Server davon nicht betroffen und kann in Ruhe weiter laufen und Du hast ein Problem weniger. Und was ich gerne mal persönlich von Dir wissen möchte: "Wie bitte sieht deine Backup-Strategie in diesem Fall aus?" Auf die verschlüsselten Daten bezogen meine ich natürlich. Bei dem NAS oder SAS System kann ich mit Schattenkopien oder Snapshots arbeiten, bei dem Server ist das nur möglich wenn die Verbindung zur Datenbank gekappt wird, falls da eine Besteht.
Moin Dobby.
Kannst Du uns aufklären, wie die Schlüsseleingabe beim NAS erfolgt?
Kannst Du uns aufklären, wie die Schlüsseleingabe beim NAS erfolgt?
Hallo Dobby,
kann schon Vorteile haben, einzelne Dienste und/oder Daten auf verschiedene Maschinen zu verteilen. In diesem Fall ist es nicht angedacht.
Durch den Einsatz einer NAS sehe ich in diesem Fall aber auch keine Vorteile. Zum einen sehe ich keine Möglichkeit, dass sich die NAS den Schlüssel von einem anderen Rechner ziehen kann (Anpassen der Firmware der NAS aufwändig) und wenn es eine Möglichkeit zur Entschlüsselung durch Passworteingabe nach dem Hochfahren gäbe, sehe ich für uns keinen Vorteil gegenüber einer Ablage der Daten auf dem Server (wenn wir nicht auf die Daten zugreifen können, wird in jedem Fall erst einmal Feierabend gemacht, mich ausgenommen).
Deinen Einwand bzgl. Schattenkopien kann ich nicht nachvollziehen. Die Verschlüsselung, so wie ich sie bislang implementiert hatte, ist für das Betriebssystem transparent, so dass ich mit Schattenkopien und Snapshots arbeiten kann. Für die Backups plane ich, ein selbst entwickeltes Backup-Script zu verwenden, das auf ein paar Systemen zuverlässig läuft: es scriptet Windows Server Backup und speichert auf verschlüsselte Platten. Bei dem zu erwartenden Datenvolumen dürfte es erfahrungsgemäß bei einem Vollbackup (geplant am Wochenende) ca. 8-12 h laufen, für inkrementelle Backups unter der Woche ca. 45 Min. bis 2 h.
Viele Grüße,
tantalos
kann schon Vorteile haben, einzelne Dienste und/oder Daten auf verschiedene Maschinen zu verteilen. In diesem Fall ist es nicht angedacht.
Durch den Einsatz einer NAS sehe ich in diesem Fall aber auch keine Vorteile. Zum einen sehe ich keine Möglichkeit, dass sich die NAS den Schlüssel von einem anderen Rechner ziehen kann (Anpassen der Firmware der NAS aufwändig) und wenn es eine Möglichkeit zur Entschlüsselung durch Passworteingabe nach dem Hochfahren gäbe, sehe ich für uns keinen Vorteil gegenüber einer Ablage der Daten auf dem Server (wenn wir nicht auf die Daten zugreifen können, wird in jedem Fall erst einmal Feierabend gemacht, mich ausgenommen).
Deinen Einwand bzgl. Schattenkopien kann ich nicht nachvollziehen. Die Verschlüsselung, so wie ich sie bislang implementiert hatte, ist für das Betriebssystem transparent, so dass ich mit Schattenkopien und Snapshots arbeiten kann. Für die Backups plane ich, ein selbst entwickeltes Backup-Script zu verwenden, das auf ein paar Systemen zuverlässig läuft: es scriptet Windows Server Backup und speichert auf verschlüsselte Platten. Bei dem zu erwartenden Datenvolumen dürfte es erfahrungsgemäß bei einem Vollbackup (geplant am Wochenende) ca. 8-12 h laufen, für inkrementelle Backups unter der Woche ca. 45 Min. bis 2 h.
Viele Grüße,
tantalos
Zitat von @DerWoWusste:
Moin Dobby.
Kannst Du uns aufklären, wie die Schlüsseleingabe beim NAS erfolgt?
Moin Dobby.
Kannst Du uns aufklären, wie die Schlüsseleingabe beim NAS erfolgt?
1. Addonics Geräte
http://www.addonics.com/category/crt_dle.php
http://www.addonics.com/category/crt_rve.php
1. QNAP Geräte
http://www.qnap.com/de/index.php?lang=de&sn=375&c=292&sc=52 ...
http://www.qnap.com/de/index.php?lang=de&sn=375&c=292&sc=73 ...
http://www.qnap.com/de/index.php?lang=de&sn=375&c=292&sc=73 ...
Bei den QNAP Geräten ist es meiner Meinung nach etwas besser erklärt und man hat die Wahl
entweder durch die Benutzeranmeldung oder den direkten Schlüsselimport am Gerät.
Ok, anders gefragt... weißt DU, wie das funktioniert?
Der Threadopener wünscht eine Auto-Entschlüsselung, welche nur mit MS Bitlocker "next generation" oder meinem Ansatz über Keyfiles erreicht werden kann. Oder kann das NAS auch Vergleichbares?
Für diese simple Antwort mag ich mich nämlich nicht durch 5 Links wühlen, bitte habe dafür Verständnis.
Der Threadopener wünscht eine Auto-Entschlüsselung, welche nur mit MS Bitlocker "next generation" oder meinem Ansatz über Keyfiles erreicht werden kann. Oder kann das NAS auch Vergleichbares?
Für diese simple Antwort mag ich mich nämlich nicht durch 5 Links wühlen, bitte habe dafür Verständnis.
Habe gerade Zeit gehabt und es mal rausgesucht. Zitat von http://www.addonics.com/userguides/CDC4HESU.pdf
When the Cipher tower is restarted, the 4 cipher keys must be inserted again in order to gain access to the drives.
...passt nicht zur Anforderung - ist es bei QNap anders?Zitat von @DerWoWusste:
Ok, anders gefragt... weißt DU, wie das funktioniert?
Der Threadopener wünscht eine Auto-Entschlüsselung, welche nur mit MS Bitlocker "next generation" oder meinem
Ansatz über Keyfiles erreicht werden kann. Oder kann das NAS auch Vergleichbares?
Für diese simple Antwort mag ich mich nämlich nicht durch 5 Links wühlen, bitte habe dafür Verständnis.
Ok, anders gefragt... weißt DU, wie das funktioniert?
Der Threadopener wünscht eine Auto-Entschlüsselung, welche nur mit MS Bitlocker "next generation" oder meinem
Ansatz über Keyfiles erreicht werden kann. Oder kann das NAS auch Vergleichbares?
Für diese simple Antwort mag ich mich nämlich nicht durch 5 Links wühlen, bitte habe dafür Verständnis.
Auch OK ohne vernünftig "Hallo" zu sagen,
bleib mal bitte auf dem Teppich oder warst Du mit irgendetwas nicht einverstanden?
Bei Verschlüsselungssachen ist das eben nicht so einfach eine schnelle und gute Antwort abzugeben.
Daran ändert auch nichts, dass jemand eben ein solches Projekt gut umgesetzt hat, tut mir leid aber es ist nun mal so, mag sein dass ich dort ein bisschen sehr altmodisch bin aber bei Verschlüsselungssachen
würde ich mich eben immer richtig absichern wollen, nicht zuletzt mit einer Versicherung die dafür auch aufkommt. Hier geht Sicherheit im wahrsten Sinne eben über "Schubsität", hat zumindest hier im Forum mal einer geschrieben ;) Es gibt bestimmt unzählige Lösungen zu eben diesem Thema, aber die von mir vorgeschlagenen sind zertifizierte Lösungen und somit ist man als Firma und auch als Administrator auf der sicheren Seite. Die Geräte dieser beiden Hersteller sind zertifiziert!!!!!!!!!
Welche Zertifizierung habe ich denn bei Truecrypt, nicht das ich was gegen Truecrypt habe, aber im Unternehmenseinsatz und ohne Zertifizierung würde ich das nicht machen wollen, obwohl es mal eine Zeit gegeben hat in der ich das auch so hätte realisieren wollen, aber diese Zeiten sind schon etwas länger her und bei Schaden der entstehen kann gehen heute einige Firmen schnell dazu über den Admin zu feuern und zu verklagen und einen neuen einzustellen.
Addonics NAS Geräte mit der Gleichen Verschlüsselung an, aber auf zwei unterschiedliche Art und weise.
1. Ein Teil wird auf dem NAS verschlüsselt (für jeden Benutzer)
2. Das ganze NAS (Festplatten) werden verschlüsselt
Die Methode ist einfacher strukturiert da man Schlüssel als Hardwaretoken erhält, die meines Erachtens
sich auch besser und sicherer verwalten lassen, denn Sie stecken am NAS und das sollte in einem Server
oder IT Raum stehen der abschließbar ist. Sie können nicht zerstört werden oder verlustig gehen.
Die Benutzer bekommen auf dem NAS ein oder mehrere Verzeichnisse und können Sich dort anmelden.
Es gibt auch für größere Firmen (Bankenbereich weil sehr teuer) ein Gerät mit dem man sich beliebig viele Schlüssel selber machen kann.
QNAP NAS Geräte halten für den Benutzer zugängliche Ordner vor, der Zugriff (Lesbarkeit) auf die Daten die mittels Anmeldung und Passworteingabe geregelt werden oder aber über die Funktion eines Schlüsselimports ganz wie der Amin es wünscht.
Stand aber meine ich auch unter dem Link.
Zitat von D.o.b.by
entweder durch die Benutzeranmeldung oder den direkten Schlüsselimport am Gerät.
entweder durch die Benutzeranmeldung oder den direkten Schlüsselimport am Gerät.
Ich habe lediglich davon abgeraten alles auf einem Gerät zu erledigen.
Ich habe andere Geräte vorgeschlagen und zwar welche die zertifiziert sind.
Nun noch einmal zu uns beiden, Du schreibst mir dass Du keine Lust hast alles durch zu lesen und das soll ich dann für Dich übernehmen, na hör mal Du bist mir ja ein Schlawiner.
Hallöchen DerWoWusste,
ja und das steht wenn auch in Kurzform so unter dem Link:
".....entweder durch die Benutzeranmeldung oder den direkten Schlüsselimport am Gerät."
War aber wohl nicht so deutlich zu erkennen.
ja und das steht wenn auch in Kurzform so unter dem Link:
".....entweder durch die Benutzeranmeldung oder den direkten Schlüsselimport am Gerät."
War aber wohl nicht so deutlich zu erkennen.
Hallo D.o.b.b.y.
Ich verstehe die Aufregung nicht. Ich habe mich gefragt, ob Du über eigene Erfahrung mit diesen Geräten verfügst, denn technische Details, echte Details, sind eben nur schwer aus manchen Produktbeschreibungen zu entnehmen. Ich finde bei den QNaps keine hinreichende Erklärung, die meine Frage beantwortet, deshalb bleibt das für mich offen.
Zum Thema "keine Lust haben" - mitnichten. Ich bin daran interessiert, habe aber nicht immer ausreichend Zeit. Wenn Du es wissen solltest (und damit meine ich eben Info, die über "entweder durch die Benutzeranmeldung oder den direkten Schlüsselimport am Gerät" hinaus geht, da dies technisch nun nicht wirklich detailreich ist [finde ich]), dann wäre es nett, dies zu erläutern, natürlich nur, wenn es Dir keine Umstände macht.
Vorzügliche Grüße
DWW
Ich verstehe die Aufregung nicht. Ich habe mich gefragt, ob Du über eigene Erfahrung mit diesen Geräten verfügst, denn technische Details, echte Details, sind eben nur schwer aus manchen Produktbeschreibungen zu entnehmen. Ich finde bei den QNaps keine hinreichende Erklärung, die meine Frage beantwortet, deshalb bleibt das für mich offen.
Zum Thema "keine Lust haben" - mitnichten. Ich bin daran interessiert, habe aber nicht immer ausreichend Zeit. Wenn Du es wissen solltest (und damit meine ich eben Info, die über "entweder durch die Benutzeranmeldung oder den direkten Schlüsselimport am Gerät" hinaus geht, da dies technisch nun nicht wirklich detailreich ist [finde ich]), dann wäre es nett, dies zu erläutern, natürlich nur, wenn es Dir keine Umstände macht.
Vorzügliche Grüße
DWW
Hallo DerWoWusste,
na wenn Du halt keine Zeit hast, sieht das schon anders aus, ich dachte Du hast eher keine Lust.
Ich weiß halt nur das man bei einer großen und namhaften Bank in Frankfurt auf die Addonics Lösung gesetzt hat. Der Zertifizierung zum einen wegen und der Gegebenheit geschuldet das man die Schlüssel
auf kleinen USB Sticks hat, mit der zusätzlichen Möglichkeit eben solche mit einen extra Gerät selber erstellen zu können und ein extra Satz eben solcher Schlüssel befindet sich in einem Tresor dieser Bank als eine Art Backup und das man aus versicherungstechnischen Gründen diese Wahl getroffen hat.
Mehr darf ich auch leider dazu nicht schreiben und sagen, tut mir leid, so gerne ich auch möchte (Verschwiegenheitspflicht).
Die QNAPS Lösungen werden nicht nur für KMU´s beworben sie haben vielen anderen NAS Lösungen auch einen signifikanten Vorteil gegenüber es sind "echte" cpu´s wie intel i3-2120 Processor 3.3 GHz und keine
Atom´s (Leistung) und zum anderen mit bis zu 2 oder 4 GB RAM bestückbar was man bei der Verschlüsselung beides auch bemerkt. Mit dem gut beschrieben meinte ich auch nur das Sie auf Ihrer Seite beide Mechanismen deutlich anpreisen:
1. Der Benutzer meldet sich am System (NAS) an und hat Zugriff auf alle seine Dateien und die für Ihn freigegebenen Ordner und für alle anderen sind die Dateien nicht zu gebrauchen und verschlüsselt
außer dem Admin und dem Backup Admin natürlich.
2. Auf Datenträger mit FIPS 140-2-zertifizierter AES 256-Bit-Verschlüsselung kann nur
mit einem autorisierten Verschlüsselungskennwort oder Schlüssel zugegriffen werden.
Aus dem Manual des TS-1079: Nicht das größte NAS aber auch nicht das kleinste NAS im Sortiment.
Auf dieser Seite können Sie die verschlüsselten Datenträger auf dem NAS verwalten. Jedes
verschlüsselte Laufwerk wird über einen spezifischen Schlüssel gesperrt. Das verschlüsselte Laufwerk
kann auf folgende Weisen entsperrt werden:
Verschlüsselungskennwort: Geben Sie das Verschlüsselungskennwort ein, um das Laufwerk zu
entsperren. Das Standardkennwort lautet „admin“. Das Passwort muss 8-16 Zeichen lang sein.
Symbole (! @ # $ % ^ & * ( ) _ + = ?) sind zulässig.
Verschlüsselungsschlüsseldatei: Sie können die Verschlüsselungsdatei zu dem Server uploaden, um
das Laufwerk zu entsperren. Der Schlüssel kann von der Seite „Verschlüsselungsschlüsselverwaltung“ heruntergeladen werden, nachdem Sie das Laufwerk erfolgreich entsperrt haben.
Nun ich mal wieder also die Schlüssel können auf dem NAS gelassen werden oder aber auf die Klienten runter geladen werden.
Es handelt sich um die Verschlüsselung ganzer Festplatten auf den die Verzeichnisse liegen, der Zugriff auf die Verzeichnisse kann per Benutzer und die Größe via Quota´s geregelt werden.
Durch das hinzunehmen eines Weiteren QNAP Gerätes um die Datenintegrität und die Verschlüsselung
weiter zu gewährleisten ist auch gegeben.
Kurz um man meldet sich als Admin an sagt dem NAS was verschlüsselt werden soll, also einzelne Festplatte, JBOD, oder Raid´s und dann legt man die Verzeichnisse und Benutzer an und verteilt entweder Passwörter oder die Schlüssel beides geht.
Beim Verlust einzelner Platten oder des ganzen NAS sind die Daten also sicher, da immer eine "Sache"
fehlt entweder das Passwort oder der Key der auf dem Klient PC liegt.
Es kann auch als:
Samba Server
LDAP Server
Radius Server
http Server
Apache Web Server
File Server
Drucker Server
Syslog Server
Sicherungsserver
IPv4 & IPv6 Unterstützung
Beim Anstecken eins kompatiblen WLAN Sticks ist das NAS sogar über WLAN erreichbar.
Es hat zwei GB LAN Ports die über einen Intel Server Dual Port Adapter erweitert werden können, GB, Fiber oder 10 GB habe ich aber nicht raus lesen können.
Noch was zur Backupmöglichkeit:
ŃReal-time Remote Replication (RTRR)
- Fungiert sowohl als RTRR-Server als
auch -Client
- Unterstützt Echtzeit- und
zeitgesteuerte Sicherung
- Unterstützt Verschlüsselung,
Komprimierung und Dateifilter
Ń Apple Time Machine-Unterstützung
mit Sicherungsverwaltung
Ń QNAP QBack-Sicherungssoftware
(Windows-Client)
Ń Sicherung auf Cloud-Speicher (Amazon
S3, ElephantDrive und Symform)
ŃSicherung auf externes Speichergerät
Ń USB-Sicherung auf Knopfdruck
(Import/Export)*
ŃFernreplikation auf Blockebene:
- Fungiert sowohl als Rsync-Server als
auch -Client
- Verschlüsselte Replikation zu/von
QNAP NAS-Servern
Ń Unterstützte Sicherungssoftware
von Drittanbietern: Veeam Backup &
Replication, Acronis True Image, CA
BrightStor, ARCserve Backup, EMC
Retrospect, Symantec Backup Exec,
LaCie SilverKeeper ... und andere
Man kann auch mit Batch Dateien arbeiten als Admin und als Benutzer, allerdings nur in und über die für den Benutzer freigegebenen Ordner und Verzeichnisse.
na wenn Du halt keine Zeit hast, sieht das schon anders aus, ich dachte Du hast eher keine Lust.
Ich weiß halt nur das man bei einer großen und namhaften Bank in Frankfurt auf die Addonics Lösung gesetzt hat. Der Zertifizierung zum einen wegen und der Gegebenheit geschuldet das man die Schlüssel
auf kleinen USB Sticks hat, mit der zusätzlichen Möglichkeit eben solche mit einen extra Gerät selber erstellen zu können und ein extra Satz eben solcher Schlüssel befindet sich in einem Tresor dieser Bank als eine Art Backup und das man aus versicherungstechnischen Gründen diese Wahl getroffen hat.
Mehr darf ich auch leider dazu nicht schreiben und sagen, tut mir leid, so gerne ich auch möchte (Verschwiegenheitspflicht).
Die QNAPS Lösungen werden nicht nur für KMU´s beworben sie haben vielen anderen NAS Lösungen auch einen signifikanten Vorteil gegenüber es sind "echte" cpu´s wie intel i3-2120 Processor 3.3 GHz und keine
Atom´s (Leistung) und zum anderen mit bis zu 2 oder 4 GB RAM bestückbar was man bei der Verschlüsselung beides auch bemerkt. Mit dem gut beschrieben meinte ich auch nur das Sie auf Ihrer Seite beide Mechanismen deutlich anpreisen:
1. Der Benutzer meldet sich am System (NAS) an und hat Zugriff auf alle seine Dateien und die für Ihn freigegebenen Ordner und für alle anderen sind die Dateien nicht zu gebrauchen und verschlüsselt
außer dem Admin und dem Backup Admin natürlich.
2. Auf Datenträger mit FIPS 140-2-zertifizierter AES 256-Bit-Verschlüsselung kann nur
mit einem autorisierten Verschlüsselungskennwort oder Schlüssel zugegriffen werden.
Aus dem Manual des TS-1079: Nicht das größte NAS aber auch nicht das kleinste NAS im Sortiment.
Auf dieser Seite können Sie die verschlüsselten Datenträger auf dem NAS verwalten. Jedes
verschlüsselte Laufwerk wird über einen spezifischen Schlüssel gesperrt. Das verschlüsselte Laufwerk
kann auf folgende Weisen entsperrt werden:
Verschlüsselungskennwort: Geben Sie das Verschlüsselungskennwort ein, um das Laufwerk zu
entsperren. Das Standardkennwort lautet „admin“. Das Passwort muss 8-16 Zeichen lang sein.
Symbole (! @ # $ % ^ & * ( ) _ + = ?) sind zulässig.
Verschlüsselungsschlüsseldatei: Sie können die Verschlüsselungsdatei zu dem Server uploaden, um
das Laufwerk zu entsperren. Der Schlüssel kann von der Seite „Verschlüsselungsschlüsselverwaltung“ heruntergeladen werden, nachdem Sie das Laufwerk erfolgreich entsperrt haben.
Nun ich mal wieder also die Schlüssel können auf dem NAS gelassen werden oder aber auf die Klienten runter geladen werden.
Es handelt sich um die Verschlüsselung ganzer Festplatten auf den die Verzeichnisse liegen, der Zugriff auf die Verzeichnisse kann per Benutzer und die Größe via Quota´s geregelt werden.
Durch das hinzunehmen eines Weiteren QNAP Gerätes um die Datenintegrität und die Verschlüsselung
weiter zu gewährleisten ist auch gegeben.
Kurz um man meldet sich als Admin an sagt dem NAS was verschlüsselt werden soll, also einzelne Festplatte, JBOD, oder Raid´s und dann legt man die Verzeichnisse und Benutzer an und verteilt entweder Passwörter oder die Schlüssel beides geht.
Beim Verlust einzelner Platten oder des ganzen NAS sind die Daten also sicher, da immer eine "Sache"
fehlt entweder das Passwort oder der Key der auf dem Klient PC liegt.
Es kann auch als:
Samba Server
LDAP Server
Radius Server
http Server
Apache Web Server
File Server
Drucker Server
Syslog Server
Sicherungsserver
IPv4 & IPv6 Unterstützung
Beim Anstecken eins kompatiblen WLAN Sticks ist das NAS sogar über WLAN erreichbar.
Es hat zwei GB LAN Ports die über einen Intel Server Dual Port Adapter erweitert werden können, GB, Fiber oder 10 GB habe ich aber nicht raus lesen können.
Noch was zur Backupmöglichkeit:
ŃReal-time Remote Replication (RTRR)
- Fungiert sowohl als RTRR-Server als
auch -Client
- Unterstützt Echtzeit- und
zeitgesteuerte Sicherung
- Unterstützt Verschlüsselung,
Komprimierung und Dateifilter
Ń Apple Time Machine-Unterstützung
mit Sicherungsverwaltung
Ń QNAP QBack-Sicherungssoftware
(Windows-Client)
Ń Sicherung auf Cloud-Speicher (Amazon
S3, ElephantDrive und Symform)
ŃSicherung auf externes Speichergerät
Ń USB-Sicherung auf Knopfdruck
(Import/Export)*
ŃFernreplikation auf Blockebene:
- Fungiert sowohl als Rsync-Server als
auch -Client
- Verschlüsselte Replikation zu/von
QNAP NAS-Servern
Ń Unterstützte Sicherungssoftware
von Drittanbietern: Veeam Backup &
Replication, Acronis True Image, CA
BrightStor, ARCserve Backup, EMC
Retrospect, Symantec Backup Exec,
LaCie SilverKeeper ... und andere
Man kann auch mit Batch Dateien arbeiten als Admin und als Benutzer, allerdings nur in und über die für den Benutzer freigegebenen Ordner und Verzeichnisse.
Hi erneut und danke.
Ich habe das meiste schon beim Überfliegen der Seiten gesehen. Zwei Fragen habe ich weiterhin zu QNaps:
1 Der Nutzer greift auf eine Freigabe zu und dann wird er autorisiert (Zertifikat/Kennwort/"Schlüssel"?/whatever) und nur seine Freigabe wird entschlüsselt? Oder was meinst Du mit "1. Der Benutzer meldet sich am System (NAS) an... " -wie geht das von statten? Interesse deshalb, da ich mich natürlich Frage, ob so eine Entschlüsselung eines Teils des ganzen, ich nenne es mal Cryptocontainers, technisch möglich ist. Wenn nicht nur teilweise möglich, dann wäre der Schlüssel für das ganze Ding ja sofort im RAM des Gerätes (falls es RAM nutzt und nicht wie Tresor [siehe mein Link zuvor] arbeitet) und ist somit angreifbar für jemanden, der auch nur ein einziges kleines Nutzerkennwort kennt - also wären alle Daten für jeden Mitarbeiter angreifbar, der sich das NAS schnappt. Hmm.
2 hast Du schon ein QNaps System selbst benutzt? Dann würde ich einen neuen Thread starten und diesen entlasten wollen - falls Du Lust hast über technische Details zu reden.
Ich habe das meiste schon beim Überfliegen der Seiten gesehen. Zwei Fragen habe ich weiterhin zu QNaps:
1 Der Nutzer greift auf eine Freigabe zu und dann wird er autorisiert (Zertifikat/Kennwort/"Schlüssel"?/whatever) und nur seine Freigabe wird entschlüsselt? Oder was meinst Du mit "1. Der Benutzer meldet sich am System (NAS) an... " -wie geht das von statten? Interesse deshalb, da ich mich natürlich Frage, ob so eine Entschlüsselung eines Teils des ganzen, ich nenne es mal Cryptocontainers, technisch möglich ist. Wenn nicht nur teilweise möglich, dann wäre der Schlüssel für das ganze Ding ja sofort im RAM des Gerätes (falls es RAM nutzt und nicht wie Tresor [siehe mein Link zuvor] arbeitet) und ist somit angreifbar für jemanden, der auch nur ein einziges kleines Nutzerkennwort kennt - also wären alle Daten für jeden Mitarbeiter angreifbar, der sich das NAS schnappt. Hmm.
2 hast Du schon ein QNaps System selbst benutzt? Dann würde ich einen neuen Thread starten und diesen entlasten wollen - falls Du Lust hast über technische Details zu reden.
Hallo DDW,
neuer thread bitte
neuer thread bitte
