Kritik bzgl. Ende des Self-Hostings

Andi 1

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

Und letztendlich verstehe ich nicht ganz , warum es für bestimmte "Datenschutzkritiker" einen großen Unterschied macht, ob der PHP Code von CT nun auf einem von CT, 1&1 oder einem Hobby-Admin verwalteten Server läuft.

Ich sehe schon einen gewissen Unterschied. Sofern man ein Interesse an möglichst vielen persönlichen Daten von Christen hat (warum auch immer), ist es doch wesentlich attraktiver, den/die CT-Server anzugeifen und auf einen Schlag tausende Daten zu erhalten (inkl. hunderte Daten von Leitern), als sich mit jeder Gemeinde einzeln zu beschäftigen.

Oder anders ausgedrückt: bevor ich versuche 1000 Leuten 100 Euro zu stehlen, sprenge ich lieber einen Geldautomaten in die Luft.

Auch wenn CT um ein Vielfaches sicherer als die eigene Webseite ist (über WhatsApp und Co brauchen wir nicht sprechen), sehe ich ebenfalls die größte Gefahr darin, dass eben so viele schützenswerte Daten an einem Ort gespeichert sind.

aschild

@andi-1 sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

Und letztendlich verstehe ich nicht ganz , warum es für bestimmte "Datenschutzkritiker" einen großen Unterschied macht, ob der PHP Code von CT nun auf einem von CT, 1&1 oder einem Hobby-Admin verwalteten Server läuft.

Ich sehe schon einen gewissen Unterschied. Sofern man ein Interesse an möglichst vielen persönlichen Daten von Christen hat (warum auch immer), ist es doch wesentlich attraktiver, den/die CT-Server anzugeifen und auf einen Schlag tausende Daten zu erhalten (inkl. hunderte Daten von Leitern), als sich mit jeder Gemeinde einzeln zu beschäftigen.

Oder anders ausgedrückt: bevor ich versuche 1000 Leuten 100 Euro zu stehlen, sprenge ich lieber einen Geldautomaten in die Luft.

Auch wenn CT um ein Vielfaches sicherer als die eigene Webseite ist (über WhatsApp und Co brauchen wir nicht sprechen), sehe ich ebenfalls die größte Gefahr darin, dass eben so viele schützenswerte Daten an einem Ort gespeichert sind.
Das mit dem "Cloud is sicherer" oder "Grosse haben mehr Ressourcen zum Abwehren von Angriffen" wurde ja letztens ganz schön als Marketing BlahBlah entlarvt.

Bei Microsoft kam ja einer der Hauptschlüssel abhanden, so dass die Angreifer in sehr sehr viele MS Dienste eindringen konnten(können?).

Die Absolute Sicherheit werden wir nie haben, aber Shared Cloudlösungen sind halt ein lohnenswerteres Ziel als Einzelinstallationen...

narnitz

@andi-1

@andi-1 sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

Und letztendlich verstehe ich nicht ganz , warum es für bestimmte "Datenschutzkritiker" einen großen Unterschied macht, ob der PHP Code von CT nun auf einem von CT, 1&1 oder einem Hobby-Admin verwalteten Server läuft.

Ich sehe schon einen gewissen Unterschied. Sofern man ein Interesse an möglichst vielen persönlichen Daten von Christen hat (warum auch immer), ist es doch wesentlich attraktiver, den/die CT-Server anzugeifen und auf einen Schlag tausende Daten zu erhalten (inkl. hunderte Daten von Leitern), als sich mit jeder Gemeinde einzeln zu beschäftigen.

Oder anders ausgedrückt: bevor ich versuche 1000 Leuten 100 Euro zu stehlen, sprenge ich lieber einen Geldautomaten in die Luft.

Auch wenn CT um ein Vielfaches sicherer als die eigene Webseite ist (über WhatsApp und Co brauchen wir nicht sprechen), sehe ich ebenfalls die größte Gefahr darin, dass eben so viele schützenswerte Daten an einem Ort gespeichert sind.

An diesem Punkt muss man sich meiner Meinung nach eine Kosten/Nutzen Analyse und Gedanken über OpSec (Operations Security) machen.
Das heißt: Inwiefern dürfen wir irgendwelche Daten von Christen bei cloudbasierten SaaS (Software as a Service) Anbietern speichern? Und da fällt z.B. die Landeskirche Baden sofort schon einmal raus, weil die z.B. Office 365 benutzen....

Bei unserer Gemeinde sind wir zu diesem Thema zum Schluss gekommen: Die Nutzen, die wir aus CT als Softwareplatform ziehen, sind größer als die Risiken (Datenschutz) die wir dabei eingehen und es ist unseren Gemeindegliedern lieber, das Ihre Daten auf deutschen Servern von einer Firma direkt um die Ecke (Karlsruhe) gespeichert und geschützt werden.

Andi 1

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

Bei unserer Gemeinde sind wir zu diesem Thema zum Schluss gekommen: Die Nutzen, die wir aus CT als Softwareplatform ziehen, sind größer als die Risiken (Datenschutz) die wir dabei eingehen

Sehe ich persönlich ja genauso
In diesem Thread geht es aber nicht um den Vergleich CT vs. MS 365, sondern um den Unterschied zwischen "CT auf einem zentralen Server" oder "CT auf einem eigenen / auf verteilten Servern". Und in diesem Punkt gehe ich mit, dass das Risiko enorm steigt, je mehr Daten gebündelt gespeichert werden. Die CT Server werden als Angriffsziel umso attraktiver, je mehr Gemeinden dort zu finden sind.

narnitz

@andi-1 sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

Bei unserer Gemeinde sind wir zu diesem Thema zum Schluss gekommen: Die Nutzen, die wir aus CT als Softwareplatform ziehen, sind größer als die Risiken (Datenschutz) die wir dabei eingehen

Sehe ich persönlich ja genauso
In diesem Thread geht es aber nicht um den Vergleich CT vs. MS 365, sondern um den Unterschied zwischen "CT auf einem zentralen Server" oder "CT auf einem eigenen / auf verteilten Servern". Und in diesem Punkt gehe ich mit, dass das Risiko enorm steigt, je mehr Daten gebündelt gespeichert werden. Die CT Server werden als Angriffsziel umso attraktiver, je mehr Gemeinden dort zu finden sind.

Ich verstehe bei dieser Diskussion beide Seiten zu einem gewissen Grad.

Jedoch muss ich aus Sicht eines CT Mitarbeiters (welcher keine Ahnung von den wirtschaftlichen Dingen etc. hat, nur von der IT Infrastruktur und Entwicklung) auch sagen, dass ich den Standpunkt von CT auch sehr gut verstehe. Supportaufwand, zukünftige Features werden schwieriger zu implementieren die über den Standard PHP Webspace hinaus gehen, man müsste aufwändige Checks implementieren um überhaupt Fehlermeldungen sauber anzeigen zu können und ich weiß nicht ob sich dieser Aufwand eben für einen sehr kleinen Anteil an Installationen lohnt.

milux

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

@sirdud sagte in Kritik bzgl. Ende des Self-Hostings:

Wo ist das Problem mit dem Ziehen der Zertifikate? Es gibt genug Scriptbeispiele zum automatisierten Zertifikatshandling z.B. mit LetsEncrypt. Klar, es ist natürlich viel einfacher mit nur einem Wildcard Zertifikat für *.church.tools zu arbeiten. Da hat man mit den Zertifikaten für die Subdomains nichts mehr am Hut... Aber den riesen Supportauffwand dürfte das nicht darstellen

Zwei Punkte zur Automatisierung aus Sicht von mir:

Eine jede Automatisierung muss auch zur restlichen Infrastruktur eines Gesamtsystems kompatibel gemacht und gehalten werden -> Mit einem 0815 Certbot ist es also vermutlich nicht erledigt

Wenn man dann eine der Infrastruktur kompatiblen Automatisierung gebaut hat, hat man noch ein Problem: Die Endnutzer. Ja, nicht jeder Endnutzer ist wie unten beschrieben. Aber leider sind die Supportkontaktaufnahmen nach meinen Erfahrungen bei einem ehemaligen Arbeitgeber, meist wie folgt:

"Was ist dieses DNS?"

"Ja und wo muss ich diesen 'A-record' denn jetzt anlegen?"

"Seit gestern ist die Website nicht mehr erreichbar" "Es sieht so aus, als wäre Ihre Domain ausgalaufen" "Oh, ja das haben wir gekündigt :)"
[...]
Ergo: Ein riesen Support Aufwand (zumindest nach meiner Erfahrung).

Wieso nicht? Was soll denn bitte die "restliche Infrastruktur des Gesamtsystems" in diesem Fall sein?
Alle Zertifikate, die ich aktuell auf den CT-Servern sehe, scheinen von Let's Encrypt zu kommen. Vermutlich kommt bereits Certbot oder ein vergleichbares Tool zum Einsatz, um sie automatisch zu erneuern.
Die weitergeleitete Domain könnte man easy mit der guten alten HTTP-01-Challenge (https://letsencrypt.org/docs/challenge-types/#http-01-challenge) validieren. Keine DNS-Spezialitäten oder sowas wären erforderlich.
Also ich bin absolut bei @sirdud, mir erschließt sich dieses Argument nicht im geringsten.

narnitz

@milux

Naja, man müsste in die Infrastruktur Mechanismen einbauen um sauber die DNS Einstellungen der eigen genutzten Domains zu checken, dann Benachrichtigungen falls diese nicht mehr passen.

Denn damit die HTTP-01 Challenge funktioniert, muss der DNS setup auch passen…
Das dann die Aquirierung eines Zertifikats eher trivial ist, ist mir klar.

Naja, es ist halt im Schnitt vermutlich erheblich mehr Support Aufwand diese DNS Geschichte unter Kontrolle zu halten.
Klar, für uns erschließt sich das super easy, aber das ist nicht für alle so.

Vielleicht wäre ja ein Weg, wie bei anderen SaaS Anbietern, einen mtl. Preis für custom Domains und deren durchschnittlichen Arbeitsaufwand für die Infra und DEV Teams einzuführen?

Weil sonst wird es vermutlich wirtschaftlich schwer rechtfertigbar für vergleichsweise sehr wenige Kunden einen vergleichsweise hohen Mehraufwand dauerhaft zu haben…

Aber das müsstet Ihr dann mit dem Support klären

milux

@narnitz Nein, müsst ihr nicht. Wieso solltet ihr sowas tun müssen?

Wenn das DNS kaputt ist, dann muss eben die Hosting-Domain direkt genutzt werden, und gut is.
Tatsächlich regelt das LE bzw. Certbot AFAIK schon sehr vorteilhaft, denn man bekommt meines Wissens bei einer unvollständigen Validierung trotzdem ein Cert, nur sind da dann eben nur die Domains drin, bei denen es funktioniert hat.

Wenn ihr besonders cool sein wollt, könnt ihr für eure Kunden eine UI basteln, über die man (eine) eigene Domain(s) eintragen und entfernen und das Cert neu anfragen kann.
Das müsst ihr aber nicht, ihr könnt das im Fehlerfall auch einfach ignorieren.

Kannst du mir bitte nochmal erklären, wo du diesen "vergleichsweise hohen Mehraufwand" siehst?

milux

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

Vielleicht wäre ja ein Weg, wie bei anderen SaaS Anbietern, einen mtl. Preis für custom Domains und deren durchschnittlichen Arbeitsaufwand für die Infra und DEV Teams einzuführen?

Und nein, das ist leider keine Lösung, denn wir (und vmtl. so ziemlich alle in einer vergleichbaren Situation) betreiben CT ja nicht über eine dedizierte public suffix domain sondern als Subdomain.

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Nein, müsst ihr nicht. Wieso solltet ihr sowas tun müssen?

Wenn das DNS kaputt ist, dann muss eben die Hosting-Domain direkt genutzt werden, und gut is.
Tatsächlich regelt das LE bzw. Certbot AFAIK schon sehr vorteilhaft, denn man bekommt meines Wissens bei einer unvollständigen Validierung trotzdem ein Cert, nur sind da dann eben nur die Domains drin, bei denen es funktioniert hat.

Wenn ihr besonders cool sein wollt, könnt ihr für eure Kunden eine UI basteln, über die man (eine) eigene Domain(s) eintragen und entfernen und das Cert neu anfragen kann.
Das müsst ihr aber nicht, ihr könnt das im Fehlerfall auch einfach ignorieren.

Kannst du mir bitte nochmal erklären, wo du diesen "vergleichsweise hohen Mehraufwand" siehst?

Vorab: "Einfach die Hosting Domain verwenden" ist nicht so einfach, mit kaputtem DNS kann dabei kein Redirect etc. passieren, d.h. wenn Gemeindeglied XY jede woche churchtools.mustergemeinde.de eingebe und das plötzlich nicht mehr funktioniert kommt Gemeindeglied XY vermutlich nicht auf die Idee mustergemeinde.church.tools aufzurufen, ohne darauf hingewiesen zu werden.

Vielleicht habe ich mich etwas kryptisch ausgedrückt, sorry dafür:
Um das ganze Thema auch aus Produkt- und Kundensicht sauber abzubilden wäre genau diese UI, das du beschreibst, etwas was IMO nötig wäre.

D.h.

Es würde eine Managementoberfläche aus Kundensicht benötigen inkl. Verbindung der Zertifikatinfrastruktur und dem Backend -> Arbeitsaufwand 1
Es würde ein Monitoring benötigen für zwei Dinge (welches dann auch wieder mit dem Management und ggf. E-Mail Alerts verbunden ist)
1. Passen die DNS Records aller Installationen die eine Custom Domain nutzen?
2. Haben alle Custom Domain Instanzen ein valides Zertifikat (das ist zum Glück ein Thema das sich gut automatisieren lässt) -> Arbeitsaufwand 2

Dazu gehören dann: Produkt- und UI-Konzeption, Einplanung, Entwicklung und langfristiges maintainen dieses Features.

Und an diesem Punkt bin ich mir unsicher, inwiefern das wirtschaftlich für CT sein würde.

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

Vielleicht wäre ja ein Weg, wie bei anderen SaaS Anbietern, einen mtl. Preis für custom Domains und deren durchschnittlichen Arbeitsaufwand für die Infra und DEV Teams einzuführen?

Und nein, das ist leider keine Lösung, denn wir (und vmtl. so ziemlich alle in einer vergleichbaren Situation) betreiben CT ja nicht über eine dedizierte public suffix domain sondern als Subdomain.

Domain oder Subdomain ist technisch gesehen jetzt eher ein geringfügiger Unterschied (einziger unterschied: Subdomains können CNAME Records, was das ganze doch wieder etwas einfacher machen würde, wobei "root-domains" das nicht können), welchen Ich im Kopf schon mit dabei hatte, aber nicht aufgeschrieben hatte. Sorry dafür.
Subdomains waren natürlich auch mit vorgesehen.

milux

@narnitz Aber genau dieses Problem gibt es doch auch, wenn der Admin den Redirect via mod_rewrite, den 301-Redirect oder was auch immer vergeigt?
Und wieso sollten die Gemeindemitglieder in der Situation überhaupt euer Problem sein? Die wenden sich doch in aller Regel nicht direkt an euch, sondern an ihre Admins/GL/whatever, wodurch das ganze sowieso erst beim Sysadmin aufschlägt, der ja dann bitte hoffentlich weiß, was er verbockt hat?

Und diesbezüglich:
@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

D.h.

Es würde eine Managementoberfläche aus Kundensicht benötigen inkl. Verbindung der Zertifikatinfrastruktur und dem Backend -> Arbeitsaufwand 1

Es würde ein Monitoring benötigen für zwei Dinge (welches dann auch wieder mit dem Management und ggf. E-Mail Alerts verbunden ist)

Passen die DNS Records aller Installationen die eine Custom Domain nutzen?

Haben alle Custom Domain Instanzen ein valides Zertifikat (das ist zum Glück ein Thema das sich gut automatisieren lässt) -> Arbeitsaufwand 2

Das wäre in der Tat sinnvoll, und man könnte es direkt in ChurchTools selbst in den Admin-Einstellungen integrieren. Dann braucht man keine extra Oberfläche und vor allem keine extra Authentisierung. Entwicklungsaufwand ist vorhanden, aber überschaubar.
Sehe ich nicht so, ihr seid null in der Pflicht hier irgendwas außerhalb eurer eigenen Domain zu monitoren. Aber wenn du unbedingt meinst, dass das sein muss: Mit Uptime Kuma (https://github.com/louislam/uptime-kuma) lässt sich in 5 Minuten eine Statusseite realisieren, die das alles kann. "Aufwand 2" damit praktisch gleich null.

Das Traurige ist, dass ich eigentlich nicht mehr erwarte, dass hier von deiner/eurer Seite noch ein Einsehen kommt. Am Ende wird es vermutlich ein 301-Redirect werden, weil alles andere eigentlich Quatsch ist, insbesondere der Reverse-Proxy, den ihr offiziell kommuniziert habt.
Manchmal frage ich mich schon, ob es bei 1,7 k€ pro Jahr (für unsere Kirche allein) wirklich zu viel verlangt ist, minimalen Effort zu investieren, um den erzwungenen Umzug in eure Cloud ein wenig angenehmer zu gestalten.

milux

@narnitz Diese Antwort ergibt AFAIK keinen Sinn. Wie willst du denn eine Subdomain nebst Administration an uns verkaufen, wenn die übergeordnete Domain bei irgendeinem Provider oder Registrar rum gammelt?

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Diese Antwort ergibt AFAIK keinen Sinn. Wie willst du denn eine Subdomain nebst Administration an uns verkaufen, wenn die übergeordnete Domain bei irgendeinem Provider oder Registrar rum gammelt?

Subdomain Kunde zeigt auf CT-Server -> CT hat zusätzlichen Aufwand wegen Management etc. -> Kunde bezahlt dafür. (Was bei anderen SaaS Produkten auch so geregelt wird)

Das war meine Idee und dabei ist es irrelevant ob es sich um eine Sub- oder normale Domain handelt.

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

Das Traurige ist, dass ich eigentlich nicht mehr erwarte, dass hier von deiner/eurer Seite noch ein Einsehen kommt. Am Ende wird es vermutlich ein 301-Redirect werden, weil alles andere eigentlich Quatsch ist, insbesondere der Reverse-Proxy, den ihr offiziell kommuniziert habt.
Manchmal frage ich mich schon, ob es bei 1,7 k€ pro Jahr (für unsere Kirche allein) wirklich zu viel verlangt ist, minimalen Effort zu investieren, um den erzwungenen Umzug in eure Cloud ein wenig angenehmer zu gestalten.

Bitte wende dich hiermit an den Support.
Ich kann da letztendlich nix tun und habe auch nur mit Vorschlägen/Erklärungen versucht die Entscheidung von CT etwas verständlicher zu Machen.

milux

@narnitz Also ist das bloß eine persönliche Meinung von dir und völlig losgelöst von dem, was deine Kollegen denken?
Es wäre etwas müßig, ein Ticket aufzumachen, wenn die Antwort ohnehin feststeht.

milux

OK, "monatlicher Preis für Custom Domain" hatte sich angehört, als wolltet ihr die Domain dann verwalten, was ja Sinn ergeben hätte.

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Diese Antwort ergibt AFAIK keinen Sinn. Wie willst du denn eine Subdomain nebst Administration an uns verkaufen, wenn die übergeordnete Domain bei irgendeinem Provider oder Registrar rum gammelt?

Subdomain Kunde zeigt auf CT-Server -> CT hat zusätzlichen Aufwand wegen Management etc. -> Kunde bezahlt dafür. (Was bei anderen SaaS Produkten auch so geregelt wird)

Das war meine Idee und dabei ist es irrelevant ob es sich um eine Sub- oder normale Domain handelt.

Ich dachte, das würde nicht gehen, wegen zu viel Aufwand, wenn die Domain ausläuft oder die DNS-Records falsch gesetzt sind? Ja was denn jetzt?
Oder willst du damit sagen, wenn wir nochmal ein bisschen mehr Geld einwerfen (neben den 143,20 € monatlich für XL) wäre es dann doch möglich?

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Also ist das bloß eine persönliche Meinung von dir und völlig losgelöst von dem, was deine Kollegen denken?
Es wäre etwas müßig, ein Ticket aufzumachen, wenn die Antwort ohnehin feststeht.

Was meine Kollegen denken können sie, aber müssen sie nicht hier selbst schreiben.
Aber ja, ist meine persönliche Meinung.

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

OK, "monatlicher Preis für Custom Domain" hatte sich angehört, als wolltet ihr die Domain dann verwalten, was ja Sinn ergeben hätte.

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Diese Antwort ergibt AFAIK keinen Sinn. Wie willst du denn eine Subdomain nebst Administration an uns verkaufen, wenn die übergeordnete Domain bei irgendeinem Provider oder Registrar rum gammelt?

Subdomain Kunde zeigt auf CT-Server -> CT hat zusätzlichen Aufwand wegen Management etc. -> Kunde bezahlt dafür. (Was bei anderen SaaS Produkten auch so geregelt wird)

Das war meine Idee und dabei ist es irrelevant ob es sich um eine Sub- oder normale Domain handelt.

Ich dachte, das würde nicht gehen, wegen zu viel Aufwand, wenn die Domain ausläuft oder die DNS-Records falsch gesetzt sind? Ja was denn jetzt?
Oder willst du damit sagen, wenn wir nochmal ein bisschen mehr Geld einwerfen (neben den 143,20 € monatlich für XL) wäre es dann doch möglich?

Ich habe es nie verneint, das es technisch möglich ist, Custom (Sub-)Domains anzubieten, was ich anzweifelte war ob es wirtschaftlich ist, eine solche Funktionalität generell oder ohne Aufpreis (analog zum Sync z.B.) anzubieten.

Was ich vorgeschlagen habe ist ein möglicher Weg. Der ist aber nur eine Idee von mir.

Wenn du da offiziell Feedback geben willst oder ein Statement haben willst, melde dich bitte beim Support.

milux

@narnitz Sorry, aber falls wir von ctldap reden, das ist ein ganz blödes Beispiel.
Diese Anwendung verbraucht quasi null Server-Ressourcen und wurde von euch mit minimalem Aufwand so erweitert, dass man mit einer einzigen Instanz beliebig viele Kunden (ergo alle) bedienen kann.
Wenn das für irgendetwas ein Beispiel ist, dann dafür, dass die CT Inno GmbH viel von der Vermarkung von FOSS profitiert, der Community aber erstaunlich wenig zurück gibt. Siehe Ende des Self-Hostings.