Ungelöst 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. 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?
-
Gibt es hierzu eigentlich inzwischen einen FR? Sonst kann vielleicht jemand diese Frage bitte verschieben. Ich würde das auch gern unterstützen.
-
Aus meiner Sicht kann das ganze durch konsequente Verwendung von Gruppen und Zugriffsberechtigung für Gruppen gelöst werden. Bei mir funktioniert das Problemlos
Eine neue Wiki-Seite für alle sind dann halt noch ein, zwei oder drei Klicks mehr.Dem superadmin muss vertraut werden, der sieht ja auch alle hochsensiblen persönlichen Daten..
-
@jrnussdorf Das mit „dem Admin vertrauen“ ist schon heikel - immerhin kann sich jeder, der in die Rechteverwaltung kommt, das Recht auf jedes Wiki besorgen und aus verschiedenen Gründen ist es schlau, mehrere Admins zu haben.
Das Problem kann auch durchaus rechtliche Konsequenzen haben…
(Auch das Einsehen in personenbezogenen Daten)Da kann man mit Passwort oder (besser) Mehraugenprinzip noch Manches besser machen.
Der CT-Support braucht ja auch immer eine besondere „Freischaltung durch den Dateneigner“.
-
@Simon2
jeder muss hier selbst entscheiden, was verantwortbar ist
ob churchtools oder Banksafe.... -
@jrnussdorf Sicher.
Aber mit dem Argument braucht man in CT gar keine Absicherung.
Es wäre relativ einfach (und auch recht üblich), eine weitere Sicherheitstechnik einzubauen und so den Bedarf an „Banksafes“ bei 2900 nutzenden Gemeinden deutlich zu reduzieren.
Und da finde ich es nicht ungebührlich, sich das zu wünschen.
