[vz-dev] Zugang zum Frontend absichern

Mon Jan 23 22:28:02 CET 2012

Hi Martin,

sorry für die späte Antwort - wollte ausführlich antworten.

Am 12.01.2012 um 17:16 schrieb Martin Jangowski:

> ich finde diese Diskussion interessant, aber nicht ganz zum Ziel führend. Die Volkszähler-Software ist ganz offenbar nicht mit starker Betonung des Sicherheitsaspekts entworfen worden, sondern eine völlig ungeschützte, wenn auch sehr interessante Lösung für das Intranet.
das hast Du sehr schön formuliert, danke :-)
Lass mich dazu kurz beschreiben, wie volkszaehler.org entstanden ist. Dann wirst Du sehen, dass die Darstellung nicht ganz korrekt ist.
Basiskonzept war, eine Plattform anzubieten, auf die Leute ihre Verbrauchsprofile loggen können und zwar - im Gegensatz zur Situation bei einem Messstellenbetreiber - anonym. 

Der klassische Ansatz zur Nutzung eines Webdienstes ist, dass man sich dazu gegenüber der Webseite identifiziert (Username) und anschliessend authentisiert (idR per Passwort). Haken an der Sache? Sobald man mit Passwörtern anfängt, sind Mailadressen im Spiel (Passwort vergessen -> per Mail zusenden...).
Das schien mir unpassend, da der Nutzer so eine Identität preisgeben muss. So bin ich auf die UUIDs gekommen.
Eine Zeichenkette, aus der sich kein Bezug zum Nutzer ableiten lässt. Die Zeichenkette ist so lang gewählt, dass praktisch eine Kollision (Erraten...) ausgeschlossen ist (Anm.: ob die UUID ggü. volkszaehler.org nun als Identifikation oder als Authentisierung verwendet wird, ist eine akademische Diskussion - das lass ich jetzt mal aussen vor).

Sprich:
- Szenario 1:
 - Nutzer nutzt volkszaehler.org (braucht keinen eigenen Server - hat ja nicht Jeder)
 - Nutzer verwendet die UUID, das erlaubt eine weitestgehend anonyme Nutzung (klar, er gibt immer noch die IP preis - wenn er sich daran stört, kann er zB TOR verwenden)

Dazu kam Szenario 2:
- Nutzer möchte seine Daten lieber ganz selbst behalten und ist bereit, dazu einen eigenen Server zu betreiben (den er vllt. schon hat)
- der Server steht im eigenen Heim (Daten selbst behalten...); hier war schnell klar, dass dockstar etc. ein Traumpartner ist

> Bei mir läuft sie seit eine paar Wochen sehr gut,
das freut mich! :-)

> und das Thema "wie gestatte ich Interessenten/Aussenstehende Zugriff, ohne allzuviel offen zulegen", ist bei mir ebenfalls ein Thema.
hm - lass uns über Szenario 3 sprechen :-)
Im Ernst: wir haben hier schon mal diskutiert, dass man sich manchmal öffentliche UUIDs wünscht, diese aber problematisch sind, da innerhalb der Applikation keine Berechtigungen vorgesehen sind (s.o.: wozu?). Die Zusatzanforderung (die sich mit Deiner zu decken scheint) war:
- Nutzer möchte trennen können zwischen Vollzugriffen (s.o.) und "nur lesenden" Zugriffen

Idee:
Es gibt 2 Arten von UUIDs
1. die UUID mit Vollzugriff; Du hast es erraten - das wären die, die wir schon haben
2. eine "Schatten-UUID"; diese unterscheidet sich von der Voll-UUID insofern, als die Middleware von dieser keine schreibenden Zugriffe erlaubt
Der Bezug entsteht über eine Zuordnung, die nur in eine Richtung erfolgt: eine Voll-UUID hat einen Bezug zu jeder ihrer Schatten-UUID - nicht aber umgekehrt.

In der DB steht dann natürlich nur eine Datenreihe; diese ist der Schatten-UUID zugeordnet. Von der Schatten-UUID ist also ein Rückschluss auf die Voll-UUID nicht möglich. Somit könnte man die Schatten-UUID bekannt geben ohne befürchten zu müssen, dass die Datenreihe (oder die UUID-Parameter) verändert würden, während die Voll-UUID weiterhin ganz normal genutzt werden kann.

Hierzu sind Anpassungen an der Middleware erforderlich - das erschien und aber lösbar.

Mir stellt sich die Frage, inwieweit es sich hierbei um ein exotisches Szenario handelt. Mein Verständnis von diesem Projekt ist, dass es keine grosse Rolle spielt, ob mir oder Jemand anderem eine Idee gefällt oder nicht: wenn sich Jemand hinsetzt und etwas baut, das ihm nützlich erscheint, dann tut er das eh. Wenn wir aber gemeinsam überlegen, wohin die Reise gehen soll, sollten wir uns anschauen, ob Erweiterungen für viele Nutzer - ähm - nützlich sind oder nicht. Über konkrete Szenarien kommen wir m.E. am Besten voran. Bisher haben die meisten Nutzer Ihren Weg zum volkszaehler gefunden über einen Satz in der Art "hm, nicht schlecht; aber da fehlt doch noch was...". Das erscheint mir kein schlechter Ansatz zu sein.

Nun zu Deiner Idee:
> Eine sinnvolle Lösung dürfte es sein, den VZ-Server hinter einen Firewall mit Reverse-Proxy und Authentifizierung zu legen.
da will ich gleich einhaken: dieses Szenario setzt voraus:
- ich habe meinen Server im LAN stehen; alle schreibenden Zugriffe erfolgen aus dem LAN und alle nur-lesenden Zugriffe erfolgen aus dem Internet oder
- ich habe meinen Server im Internet stehen und greife über einen zweiten Kanal auf den Server zu (VPN o.ä.)

Persönlich glaube ich, dass das ein sehr spezielles Szenario ist, welches zB für die Nutzer eines Hosting-Paketes nicht passt. Diese haben aber vllt. auch den Wunsch, nur-lesende Zugriffe zuzulassen.

> Datenlieferanten (bei mir Ethersex für 1Wire und S0) kommen von innen ohne Authentifizierung, Aussenstehende über den Firewall mit Authentifizierung. Letzteres macht der Proxy. Damit hat man das Thema "wie verhindere ich, daß mir jemand Schrott in die DB reinschreibt" noch nicht vom Hals, aber schonmal eine deutlicher Erleichterung. Es sollte möglich sein, die Auswertung und Anzeige komplett vom Datensammeln zu trennen (via DB-Replikation),
und spätestens hier glaube ich auch nicht mehr, dass es einfach (nach-)zu bauen sein wird.

Wie gesagt: wenn das für Dich passt, hält Dich Niemand ab, das so zu bauen.
Wenn wir uns allerdings ein Konzept ausdenken, welches für mehr Leute passt, haben alle was davon. Und: in dem Fall sollte es aus genau dem Grund auch deutlich einfacher werden, Mitstreiter zu finden.

> Mittelfristig wäre eine Erweiterung der Middleware in Richtung "ändern von Daten nur mit Token o.ä." sowie irgendeine Art von Rechtevergabe und Benutzerverwaltung sinnvoll.
s.o.: das sehe ich nicht so. Über die "Schatten-UUID" und SSL haben wir m.E. alle Themen in dieser Richtung abgedeckt, ohne die Middleware umzustricken. Hinzu kommt, dass sich mit einer Benutzer- und Berechtigungsverwaltung die Frage stellt: und wer administriert? Bei Deinem eigenen Server machst Du das, klar. Für volkszaehler.org würde das aber schon nicht mehr funktionieren. Hier bräuchten wir dann eine Mandantenfähigkeit...

> Mir schweben da einige Projekte vor dem geistigen Auge, bei denen z.B. Nutzer ihre eigenen gesammelten Daten (und nur diese!) abrufen können.
immer her damit! :-)
Ich freue mich, wenn wir gemeinsam nach besseren Konzepten suchen. Was aber auch hierhin gehört: mit dem Suchen alleine ist es nicht getan. Wir freuen uns über Patches/Pull-Requests...
M.E. haben wir inzwischen ziemlich viel Code im Verhältnis zur Anzahl aktiver Coder. *hint* :-)

> Da ist eine Lösung mit Security by Obscurity ("ach wie gut dass niemand weiss, wie meine UUIDs sind") gar nix.
da muss ich Dir jetzt nicht mehr widersprechen, nachdem Du das oben gelesen hast :-)
Deine Provokation hat aber funktioniert (wie Du siehst). Und es war wohl auch (mal wieder) an der Zeit, kurz auszuholen und das UUID-Konzept zu erläutern.

Rückmeldung erwünscht!

Gruss, J.