Ungelöst Wikiseite Passwortschutz
-
@simon2 sagte in Wikiseite Passwortschutz:
Das macht für sensible Informationen keinen Unterschied. Letztlich muss ich den (Super)Admins darauf vertrauen, dass sie da nicht reinschauen.
Natürlich macht das einen Unterschied. Wenn der Superadmin keinen Zugriff hat, muß ich nicht darauf vertrauen, daß er nicht reinschaut, weil er's nicht kann. Ich muß höchstens darauf vertrauen, daß er sich das Recht nicht verschafft. Das kann man mit einem geeigneten Monitoring sogar vollautomatisiert kontrollieren (dafür reichen ein paar Zeilen Python-Skript & ein Cron-Job). Bei Zuwiderhandlung kann man dann Maßnahmen ergreifen.
Unbestritten ist der Ansatz nicht perfekt ist und mit Zusatzaufwand verbunden. Und wie Du schreibst, hat eine Verschlüsselung oder ein Paßwortschutz (bei dem Schlüssel/Paßwort nicht auf dem Server liegt, auch Tücken, insbesondere was den Cybersecurity-Aspekt der Verfügbarkeit der Informationen angeht. Einen Feature-Request in der Richtung würde ich aber auch unterstützen.
Eine weitere mögliche Alternative könnte sein, die Anforderung mit einer (per LDAP angebundenen) Nextcloud (mit serverseitiger Verschlüsselung) umzusetzen.
Da habe ich aber keine praktische Erfahrung. -
@bemigro sagte in Wikiseite Passwortschutz:
...weil er's nicht kann. ...Ich muß höchstens darauf vertrauen, daß er sich das Recht nicht verschafft. ...
Das ist nur eine Frage der Klicks, die er macht, um an das Ziel zu kommen.
Der Zweite Weg ist nicht mehr "nicht können" als der erste, denn er stellt keine technische Hürde dar.
Es bleibt: Vertraust du dem Admin nicht, kannst du dich auf die Vertraulichkeit der Informationen nicht verlassen.@bemigro sagte in Wikiseite Passwortschutz:
...Das kann man mit einem geeigneten Monitoring ...
Sowas kannst du ebenso auf den Wikizugriff selbst etablieren - und greift erst, wenn das Kind in den Brunnen gefallen ist.
BTW: Wer soll die Audits durchführen und "... dann Maßnahmen ergreifen..."? Wie stellst du sicher, dass der Admin deinen Auditprozess nicht unterbricht? ...Aber klar, anwenderseitige Verschlüsselung wäre natürlich eine Option: Vertrauenswürdige Informationen legen die Gruppenmitglieder nur verschlüsselt im Wiki ab und sorgen sich um die Schlüsselverteilung selbst.
... ist aber halt auch hart unhandlich und nimmt dem Wiki viel an seinen Vorteilen. -
@simon2 Vertraust Du dem Admin nicht, solltest Du Dir einen anderen Admin suchen...
Aber abgesehen davon:
- Wo kann man tatsächlich monitoren, wer auf einen Wiki zugreift? Soweit ich weiß, loggt CT Wiki-Zugriffe nicht mit
- Richtig, ich kann den Vertraulichkeitsverlust nicht verhindern, aber ich kann ihn hinterher entdecken; in meinem beruflichen Umfeld ist das bei den Cybersecurity-Kollegen in bestimmten Fällen ein anerkannter Ansatz im Rahmen einer risikobasierten Abwägung der Möglichkeiten, die man hat
- Dagegen kann der Super-Admin nicht verhindern, daß die Berechtigungsänderung in CT mitgeloggt wird und auch den entsprechenden Log-Eintrag nicht entfernen (afaik)
- Das Monitoring muß natürlich von außerhalb durch eine dritte (vertrauenswürdige) Person erfolgen; ein entsprechendes (rudimentäres) Python-Skript kann ich gerne gelegentlich zur Verfügung stellen; die Info könnte z.B. per E-Mail an die Gemeindeleiter verteilt werden
Die Unterbrechung des Auditprozesses ist also kein Problem. Wer welche Maßnahmen ergreift, hängt vom Einzelfall ab. Diese Diskussion würde hier m.E. auch zu weit gehen.
Sofern also der Daß der A
-
@bemigro sagte in Wikiseite Passwortschutz:
@simon2 Vertraust Du dem Admin nicht, solltest Du Dir einen anderen Admin suchen...
Dann brauchst du aber auch kein Audit.
Auch ich habe beruflich mit Sicherheit zu tun und da gibt es IMMER eine Kombination aus technischer Sicherheit (= "Kann nicht") und Mehr-Augenprinzip zusätzlich zu Audit, Rollenträgerkonzepten, ....
Dass CT das halt nicht bietet, ist die eigentliche Schwachstelle und alles andere Flickwerk/Provisorium.
@Auditprozess: Dein "Logauswertungsskript" muss allerdings Zugriff auf die Logeinträge des Admins haben - da sehe ich schon eine Eingriffsmöglichkeit.
-
@simon2 Ich selbst kenne kein System, das die Konzepte "Superadmin" und "Kann nicht" - ohne Ende-zu-Ende-Verschlüsselung mit Keys auf der Client-Seite und einhergehenden Kompromissen bei der Verfügbarkeit - in Reinstform zusammenbringt. Aber ich bin auch weder ausgebildeter Sicherheitsexperte oder Kryptologe noch habe ich einen vollständigen Marktüberblick.
Wie ich bereits erwähnte, würde ich einen FR durchaus unterstützen.
Hier geht es m.E. aber um eine Frage, bei der ich versucht habe zu helfen, eine "andere Lösung" aufzuzeigen, den Schutz sensibler Daten anderweitig zu verbessern.
Wenn nur 100%-Lösungen interessant sind, bleibt aus meiner Sicht tatsächlich nur die E2E-Verschlüsselung (wenn man Client-seitige Risken ignoriert - was dann evtl. wieder "Flickwerk" ist).
-
@bemigro sagte in Wikiseite Passwortschutz:
@simon2 Ich selbst kenne kein System, das die Konzepte "Superadmin" und "Kann nicht" - ohne Ende-zu-Ende-Verschlüsselung mit Keys auf der Client-Seite und einhergehenden Kompromissen bei der Verfügbarkeit - in Reinstform zusammenbringt....
Ich schon (wir bringen solche Kryptohardwaresysteme mit FIPS-140 Level4 zum Einsatz).
Sind allerdings richtig teuer, im Handling sehr anspruchsvoll und brauchen ein recht ausgetüfteltes (auch bauliches) Umfeld.Aber sowas bräuchte es hier gar nicht - wie gesagt: CT könnte hier durchaus mit ein paar softwaremäßigen Klimmzügen (Erweiterungen im Rechtesystem) schon einiges absichern. Ich kann ja mal einen FR einstellen...
Und wer mit dem bestehenden CT-System noch ein paar "Sonderschleifen" einziehen möchte, dem will ich auch gar nicht in den Arm fallen - ich sehe nur spontan keine Möglichkeiten für einen echten Sicherheitsgewinn, weswegen wir uns dagegen entschieden haben.
Uns reichen die derzeitigen Möglichkeiten im Moment noch aus - wobei wir gerade noch in Diskussion bei ein Dingen sind, ob wir das wirklich dem CT-Wiki anvertrauen wollen (allerdings spielt da mehr rein als nur die "Admin-Sichtbarkeit").
-
Ist es denn so kompliziert passwortgeschützte Seiten im Wiki zu implementieren?
Was das Kennwort vergessen angeht, sollte man keine Gnade haben.
Ich nutze private auch KeePass und eWallet und da ist es auch so, wenn man das Masterkennwort vergessen hat, hat man Pech gehabt.
So würde ich es auch bei der Wiki-Seite sehen.
Natürlich könnte ich auf andere Clouddienste ausweichen.
Ich fände es jedoch besser alles in ChurchTools abzubilden.
Das Thema mit den sensiblen Daten hat doch jede Gemeinde... -
@d-stobbe sagte in Wikiseite Passwortschutz:
Gesprächsprotokolle, Notizen usw.
Werden die direkt ins Wiki getippt?
Bei uns arbeitet man in diesem Bereich primär mit PDF-Dateien und die kann man verschlüsselt hochladen. -
@andy sagte in Wikiseite Passwortschutz:
@d-stobbe sagte in Wikiseite Passwortschutz:
Gesprächsprotokolle, Notizen usw.
Werden die direkt ins Wiki getippt?
Also ich fände das schon gut, auch direkt im Wiki lesen, in der Suchfunktion finden, ... zu können (gerade auch bei der zunehmenden App-Nutzung wird alles andere lästiger/problematischer).
-
Wir würden da Word, Excel und PDF Dateien speichern wollen.
Deshalb die ganze Wiki Seite unter ein Kennwort legen... -
Ich verstehe euch durchaus, ja. Und ich halte es sogar für einen guten Selbstschutz für den Super-Admin.
Für mich persönlich hat das jetzt keine hohe Prio, aber einen Feature-Vorschlag in der Richtung fände ich schon charmant. Nimmt das einer von euch in die Hand? Meine Stimme lasse ich dann auf jeden Fall da.
Man könnte dann auch noch mal über die Art und Weise nachdenken. Ein Passwortschutz ist vielleicht gar nicht der richtige Weg. Möglicherweise fallen uns noch andere Umsetzungsvarianten ein.
-
Verschiebt es einer in Feature-Wünsche rein oder soll ich da den selben Beitrag nochmal Posten?
