[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