[linux-l] Netzwerk-Dateisysteme
Lutz Willek
lutz.willek at belug.de
So Jan 30 18:41:44 CET 2011
Hi,
Kurze Fragen vorweg, wieso sind die Anforderungen so hoch?
Um wie viele Clients geht es? (Gesamt/Windows/Linux/osX)
Wie viele Mitarbeiter?
In welcher Branche ist das Unternehmen tätig?
Wie hoch ist die gesamte Datenmenge?
Wie hoch ist die Datenmenge, die ständig im Zugriff ist?
Wie hoch ist das geschätzte Datenwachstum?
> Konkret suchen wir(bzw. unser Admin fuer uns) gerade nach einer Loesung
> fuer Nutzerverzeichnisse, bei denen der Client FS-basiert oder (besser)
> Volume-basiert Verschluesselung macht.
Vorschlag:
Die Verzeichnisse liegen Dateibasiert verschlüsselt auf einem zentralen
Server. Die Entschlüsselung erfolgt über einen Automounter, der bekommt
die nötigen credentials von Kerberos. Die nötige Zuordnung zu
Verzeichnis und nötigem Schlüssel kommt aus dem ldap.
Variante1: Die Dateien werden bereits entschlüsselt über NFS/CIFS
freigegeben. Variante 2: Der Client entschlüsselt.
In beiden Fällen: Die nötigen credentials kommen von Kerberos, der Rest
aus dem Ldap.
> 1-2 dieser Verzeichnisse sollen wiederrum von mehreren gleichzeitig
> nutzbar sein, da ist dann auch keine Verschluesselung noetig.
Diese Verzeichnisse werden auch verschlüsselt, Verfahren wie oben
erläutert. Einziger Unterschied: mehrere Nutzer haben Zugriff auf das
gleiche credential. Das wird zentral auf dem Server eingestellt und ist
transparent für den Nutzer/Client. Damit wird die Vertraulichkeit und
Authentizität der Daten sicher gestellt.
> Fuer alle Verzeichnisse soll es access control(ldap) geben aber die
acl gibt es ja schon über ldap.
> Nutzer sollen kein VPN instalieren/starten muessen.(Chefs sind faul.)
Dann wird zwangsweise der Netzwerkverkehr unverschlüsselt sein, es sei
denn jede Verbindung verschlüsselt extra für sich, was irgendwann extrem
aufendig ist.
Vorschlag: Was spricht dagegen beim starten des Rechners eine
automatische VPN-Verbindung aufzubauen? Das dazu nötige Zertifikat ist
Rechnerbezogen hinterlegt, kein Passwort.
Dienste werden nur über das aufgebaute VPN angeboten. Das VPN dient so
daher allein dem Schutz der Verläßlichkeit gegenüber dem Netzwerk, nicht
mehr.
> Clients sind Windows, Linux und OSX.
Zumindest für Windows und Linux ist sowohl ldap/Kerberos/nfs/cifs
machbar. Für OSX habe ich das noch nie umsetzen müssen, es sollte jedoch
funktionieren.
Das beste ist hier ein kleines Testnetzwerk aufzubauen und die
Funktionen einmal abzubilden, um konkrete Aussagen machen zu können.
>
> Ich sehe bisher im wesentlichen zwei Szenarien:
>
> 1)
> - iSCSI zum Client und der Client macht TrueCrypt/DMcrypt/...
Also blockbasierte clientverschlüsselung: Gedanken dazu: was würde das
für die Sicherung bedeuten? Wie sichert ihr dann die Daten? Über den
Client? Wer gibt dann das Paswort ein? Oder über den Server? Man könnte
natürlich als Datenbackend bspw. eine Netapp nehmen und die
Datensicherung über snapshots und deduplizierung erledigen, zumindest
egalisiert sich dadurch das Platzproblem der Sicherungen etwas. Was
bleibt ist aber das Problem wenn ein User _nur_ eine Datei von gestern
haben möchte, nicht alles auf einmal. Durch blockverschlüsselung kommst
Du sehr schlecht an die Daten (nicht unmöglich, nur sehr schlecht)
Fazit für mich: blockbasierte Verschlüsselung scheidet aus, weil nicht
vernünfig zu sichern.
Weitere Punkte:
Was passiert, wenn zwei Rechner gleichzeitig auf verschlüsselte Daten
zugreifen müssen? M.W. nicht über Betriebssystemgrenzen möglich.
> - public dirs ueber webdav
würde gehen. Mir ist aber kein Automatismus bekannt der
nachgewiesenermaßen sicher _und_ funktionierend ist. Das "beste" was ich
dann kenne wäre ntlm über den Apache, in dem Fall kommen die credentials
wieder von Kerberos: das funktioniert gut, ist aber nicht wirklich
sicher... und ich habe keine Ahnung ob das auch für osx funktioniert.
> 2)
> - Alles per webdav und der Client legt image-files an
Das verstehe ich nicht ganz. Sagst Du noch 2 Sätze mehr dazu?
> Problem mit 1) ist, dass iSCSI nicht sicher ist. Zwar werden die Daten
> wiederrum verschluesselt, aber ein Angreifer koennte das
> iSCSI-Protokoll manipulieren um die Nutzerverzeichnisse logisch kaputt
> zu machen. Ausserdem muss man zwei verschiedene Loesungen fahren.
iscsi ist für alle BS nativ verfügbar und beherscht eine Verschlüsselung
der Daten übers Netz, das ist also lösbar. Ich halte es bspw. aus
Gründen der Datensicherung für nicht akzeptabel.
> Generell kann man bei 1) ausserdem ein natives FS benutzen und aergert
> sich nicht mit Datei-Rechten und -Eigenschaften rum.
Mit denen wirst Du Dich zwangsweise beschäftigen müssen.
> Problem mit 2) ist der random access innerhalb einzelner Dateien.
Auf dem ersten Blick: nööö, das kommt ja stark auf die Art der
Implementierung an. Außerdem gilt dieses Argument nicht, beziehungsweise
gild es immer: Im Endeffekt sprichst Du damit die Verfügbarkeit eines
Dienstes an, nur Du wirst immer auf eine gute Verfügbarkeit achten
müssen, egal welche Lösung Du nun präferierst. Dazu gehört natürlich
auch ein ausreichender i/o.
> Vorschlaege?
>
> /steffen
Ja.
Vorher:
Du solltest nicht den Fehler machen und das Pferd von hinten aufzäumen
und auch nichts größer und schwieriger machen als die momentanen
Anforderungen sind. Manchmal ist es einfacher _und_ wesentlich günstiger
einfach die Anforderungen vernünftig zu definieren und ggf. dafür
Strukturen anzupassen, als alles durch Technik zu erschlagen. Sicher ist
alles möglich, ob es sinnvoll oder bezahlbar ist entscheiden immer die
Anforderungen bzw. das vorhandene Know-How im Haus. Sicherlich sinnvoll
ist auch ab einer gewissen Größe eine Beratung durch eine/mehrere
unabhängige externe. Wenn Du dazu Ansprechpartner suchst bitte eine PM,
ich kann Dir einige Firmen vermitteln. (Und ja, wir beraten auch.)
Ein möglicher Plan, da ich die Anforderungen nicht kenne geplant für
mehr als 100 Mitarbeiter oder 50 Clients:
Zuerst eine Zentralisierung der Nutzerverwaltung, also eine Einführung
von Kerberos/Ldap oder eben AD. Über AD solltet Ihr ernsthaft nachdenken
wenn ihr einen erheblichen Anteil Windows-Clients habt.
Zweitens eine Zentralisierung der Nutzerdaten. Dazu schlage ich ein
getrenntes Datenbackend und einen Verbund aus 2 oder mehr Servern vor,
aus Kostengründen vorstellbar wäre bspw. ein HA-Linux mit Samba/NFS.
Drittens die Einführung eines Disaster Recovery für die Clients, später
eventuell auch für die Server. Danach, naja, damit eigentlich
einhergehend: die Einführung einer zentralen, dateibasierten Sicherung.
Clients werden nicht gesichert, da auf ihnen keine Nutzdaten mehr liegen
und diese durch das Disaster Recovery wiederhergestellt werden können.
Viertens die Einführung einer durchgehenden Verschlüsselung auf
Netzwerkseite. Denkbar dafür wäre openvpn (Vorsicht Durchsatz bei
Windows!) oder eben ipsec. Cisco implementiert das übrigens sehr nett,
Erfahrungsgemäß gibt es wenig Probleme mit Windows und roadwarrior
Szenarien, sollte das für Euch ein Punkt sein.
Dann kann man sich dann über eine Verschlüsselung der Daten einen Kopf
machen. Die dazu nötigen Schlüsseldaten würde ich aber immer zentral
vorhalten und verwalten. (Warum? Denk nach: Was passiert wenn ein
Mitarbeiter krank ist und nötige Projektdaten nicht im Zugriff sind? Was
passiert bei Verlust eines Schlüssels, vergessen des Passwortes?)
Die Verschlüsselung würde ich persönlich Dateibasiert aufbauen, mögliche
Kandidaten dafür sind mir spontan einfallend encfs, oder bei
Windowsclients sharedrive (abylon) oder oder oder... in
http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
findet sich bestimmt etwas passendes.
Ob die Verschlüsselung Server/Clientbasiert erfolgen soll bestimmt das
mögliche Einsatzszenario, denkbar ist beides. Da ich persönlich dazu
neige die Clients so dumm wie möglich zu halten würde ich als erstes die
Serverseite evaluieren.
Hilft das? Sicher etwas viel, naja hoffe es ging nicht zu weit an dem
vorbei was Du suchst.
Freundliche Grüße / Best Regards
Lutz Willek
--
________________________________privat
lutz.willek at belug.de skype: lutz.willek
mobil: +49 160 98340520 icq : 409046111
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Have you tried turning it off and on again? ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mehr Informationen über die Mailingliste linux-l