Kritik bzgl. Ende des Self-Hostings

milux

Liebes ChurchTools-Team,

vor einigen Tagen hat uns eure Informations-E-Mail zum Ende des Self-Hostings erreicht.
Der Schritt ist aus Management-Sicht nachvollziehbar, aber ich möchte trotzdem ein wenig Kritik los werden, wobei ich gerne so konstruktiv wie möglich sein will und Wege aufzeigen möchte, wie man vielleicht trotz diesem Schritt einige Probleme "abfedern" könnte.

Meine Gedanken zu den Gründen aus eurer E-Mail:

Wir haben festgestellt, dass einige Self-Hoster Sicherheitsupdates nicht rechtzeitig einspielen, was die Daten von ChurchTools-Nutzern gefährden kann.

Dieses Problem ist in Ermangelung eines automatisierten Update-Prozesses zu 95 % hausgemacht. Wir (Dennis und ich von MEINE KIRCHE Regensburg) haben euch schon vor Jahren angeboten, dass ihr euch beim Code unseres Auto-Updaters bedienen könnt. Ich habe ebenfalls schon vor Jahren angeregt, ein Auto-Update in ChurchTools zu integrieren, wie es bei anderen Produkten wie WordPress, Matomo Analytics und dergleichen mehr schon seit vielen Jahren Standard ist.

Bei der Weiterentwicklung von ChurchTools müssen wir stets berücksichtigen, welche Server-Technologien die Self-Hoster einsetzen können. Das schränkt unsere Flexibilität bei der Auswahl neuer Technologien ein.

Mich würde hier ein konkretes Beispiel interessieren. Niemand hat euch jemals dazu gezwungen, euch selbst diesbezüglich in irgendeiner Weise zu beschränken, und das solltet ihr auch nicht tun. Würdet ihr eine neue Technologie einsetzen, müssten Gemeinden, die den notwendigen Stack auf ihrer Hardware nicht bereitstellen können, dann eben ins Hosting wechseln oder mehr Geld in die Hand nehmen.
An dieser Stelle sei angemerkt, dass ich 2 x mit großem zeitlichem Abstand nachgefragt habe, ob es denn möglich oder geplant sei, selbst eine eigene Synapse-Instanz für den CT-Chat zu betreiben, was klar verneint wurde. Wir hatten also Bock, noch deutlich mehr selber zu machen, aber Self-Hoster hier weiter zu "empowern" stand scheinbar nicht auf eurer Agenda.

Die Server-Infrastruktur von selbst gehosteten Installationen unterscheidet sich oft von der, die unser gehostetes ChurchTools verwendet. Das erschwert die Bearbeitung von Support-Anfragen und macht die Lösung von Problemen aufwendiger.

Diesen Punkt halte ich für nachvollziehbar. Auch hier hätte es aber eine Vielzahl an Möglichkeiten gegeben, mit milderen Mitteln gegenzusteuern. Ein Capabilities-Check wie ihn gängige CMS nutzen, der automatisch auf kompatible Versionen von PHP, MariaDB etc. prüft, wäre vorstellbar gewesen. Veraltete Versionen solltet ihr schnell ausphasen, und das habt ihr in der Vergangenheit ja auch getan. Den Support dieser Dinos würde ich mir nicht ans Bein binden.
Es hätte außerdem IMHO nichts dagegen gesprochen, z.B. eine Referenz-Laufzeit via Docker-Image bereitzustellen, wie das z.B. NextCloud tut.
Klar fallen dann bestimmte Kunden raus, aber ob diese das Know-How haben, um tatsächlich vom Selfhosting zu profitieren - aus meiner Sicht zumindest zweifelhaft.

Manche Self-Hoster haben Schwierigkeiten, ihr ChurchTools kontinuierlich am Laufen zu halten. Das kann zum Beispiel vorkommen, wenn ein Admin ausfällt oder nicht genügend Zeit für notwendige Server-Wartungen hat.

... und dann ist es völlig logisch, einen Umzug auf euer Hosting zu machen. Aber für den Fall der Fälle präventiv alle Self-Hoster in eure Cloud zu pullen, ist dafür ja nicht zwingend nötig, oder?

Meine Bedenken bzgl. dieses Schrittes:

Euer aktueller Vorschlag, um bestehende Domains via Proxy zu nutzen, hat aus meiner Sicht einige gravierende Nachteile.
Zum einen könnten viele Self-Hoster gar kein mod_proxy zur Verfügung haben, aber selbst wenn: Bei diesem Ansatz fließen die Daten durch den alten Server und eure Cloud, er verbindet also bzgl. Datensicherheit das schlechteste beider Systeme. Das gilt sowohl für die Server an sich, als auch für die TLS-Verschlüsselung, die vom Proxy "aufgebrochen" wird.
Ganz ehrlich: Als ich das im FAQ gelesen habe, haben sich mir als Security-Forscher die Nackenhaare aufgestellt.
Und damit hören die Probleme nicht auf: Falls ihr z.B. Echtzeit-Updates in der UI zukünftig per WebSocket statt Polling machen wollt, muss die Config von mod_proxy angepasst werden. Wolltet ihr nicht eigentlich den Support-Aufwand mit den Self-Hostern loswerden?
Und dass Proxies in diesem Betriebsmodus die Performance nicht gerade verbessern, ist davon abgesehen ja wohl offensichtlich...
Ja, ich weiß, das EULA verbietet die Modifikation des Codes von ChurchTools auf unseren Servern. Als ich allerdings jüngst erst wieder mal den CT-LDAP-Wrapper aktualisiert habe, war ich dann doch froh, dass ich einen Quirk bzgl. der "Pagenierung" der Ergebnisse genauer untersuchen und mir einen 2-Zeilen-Patch für euren API-Code ausdenken konnte, den ich euch BTW noch zuschicken werde.
Ohne Zugriff auf die Sources werde ich künftig vielleicht einfach mit diesen Problemen leben müssen, und kann sie weder in der Tiefe nachvollziehen, noch unentgeltlich mit Fixes eure Arbeit supporten.
Sicherheit:
Auf der Habenseite: Ich bin mir sicher, dass ihr generell mit den Daten gut umgeht und die auf euren Servern weit besser behütet werden als auf dem einen oder anderen Wald-und-Wiesen-Self-Hosting-Webspace.
Ein grundlegendes Problem bleibt aber: Wird eure Organisation erfolgreich angegriffen (durch die massive Bündelung interessanter Daten aus vielen Gemeinden ist sie ein viel lukrativeres Ziel als eine einzelne Ortsgemeinde), dann sind die Daten aller heutigen Self-Hoster auch weg. So müsste man die Self-Hoster einzeln finden und angreifen. Der Aufwand dafür wäre nochmal deutlich höher.
Sicherheitslücken: Der letzte Punkt führt mich auch noch direkt zu einem weiteren. Ich weiß aus zuverlässiger Quelle ( ) dass euch schon das eine oder andere Mal Sicherheitslücken gemeldet wurden. Und aus besagter Quelle weiß ich auch, dass das Auffinden besagter Lücken ohne Zugriff auf den Quellcode nicht mit vertretbarem Aufwand möglich gewesen wäre.
Die Sicherheit eurer Software hat also in der Vergangenheit schon mehrfach davon profitiert, dass euer Produkt eben nicht nur als "SaaS" in der Cloud verfügbar war.
Beim Beenden des Hosting-Angebotes wären somit dann evtl. auch die Zeiten vorbei, in denen motivierte externe Entwickler mit vertretbarem Aufwand eure Arbeit begutachten können.

Ein paar Gedanken, wie man die Nachteile (teilweise) auffangen könnte:

Eine bessere Methode für Alt-Domains: Ich denke, dass CNAME-Records im DNS hier eine Lösung sein könnten. Allerdings müsste es dann einen Prozess geben, wie ihr euren Server so konfigurieren könnt, dass er auch auf Anfragen gegen diese Domains reagiert, und sie auf dieselbe CT-Instanz mappt. Eigentlich sehr einfach. Sagt mir gerne, was ihr davon haltet, und welche Nachteile ihr vllt. bei diesem Ansatz seht.
Ein Prozess, über den ehrenamtlichen Entwickler auf Anfrage (natürlich mit Verschwiegenheitserklärung) auf euren Quellcode zugreifen dürfen - wenn nicht aktiv, dann vielleicht wenigstens lesend. Das würde IMHO viel helfen.
Ich dürfte vor einigen Jahren (auf eigenen Wunsch nur für wenige Monate) ein Teil eures Entwickler-Teams sein und habe später auch eine Erklärung unterschrieben, mit der eben genau das möglich sein sollte. Als ich dann vor einiger Zeit mal wieder etwas Zeit und Muße hatte und gerne mal wieder eine Kleinigkeit contributen wollte (s. oben), waren sämtliche Zugänge scheinbar nicht mehr funktionstüchtig. Ich weiß, ich habe mich schon lange nicht mehr gemeldet, aber die Zeit von vielen Ehrenamtlichen ist nunmal begrenzt, so ist leider das Leben.
Eine stärkere Isolierung der Instanzen verschiedener Kunden: Ich kann und möchte hier nicht Gefahr laufen, Details auszuplaudern, die besser zwischen uns bleiben sollten. Möglicherweise ist die Lage heute auch schon eine ganz andere wie "damals". Würde gerne darüber mit euch in Kontakt treten.

Danke mal soweit. Ich würde mich freuen, wenn ihr diese Anliegen aufnehmen würdet, und wir hier ggf. mit anderen Betroffenen über dieses Thema diskutieren können.

Gottes Segen euch und weiterhin viel Freude und Erfolg mit eurer Arbeit! (:

davidschilling

Hi @milux,

Danke für deine ausführlichen Gedanken.

Dieses Problem ist in Ermangelung eines automatisierten Update-Prozesses zu 95 % hausgemacht. Wir (Dennis und ich von MEINE KIRCHE Regensburg) haben euch schon vor Jahren angeboten, dass ihr euch beim Code unseres Auto-Updaters bedienen könnt. Ich habe ebenfalls schon vor Jahren angeregt, ein Auto-Update in ChurchTools zu integrieren, wie es bei anderen Produkten wie WordPress, Matomo Analytics und dergleichen mehr schon seit vielen Jahren Standard ist.

Hätten wir das Self-Hosting fortgesetzt, hätten wir sicherlich an dieser Stelle Verbesserungen eingeführt. Tatsächlich haben wir kürzlich darüber diskutiert. Das Problem ist jedoch, dass viele unserer Self-Hoster nicht besonders erfahren im Umgang mit Software-Hosting sind. Bei Rückfragen, ob es Fehler im Apache-Log gibt, erhalten wir oft nur Fragezeichen als Antwort. Das macht die Unterstützung dieser ChurchTools-Installationen sehr zeitintensiv.

Mich würde hier ein konkretes Beispiel interessieren. Niemand hat euch jemals dazu gezwungen, euch selbst diesbezüglich in irgendeiner Weise zu beschränken, und das solltet ihr auch nicht tun. Würdet ihr eine neue Technologie einsetzen, müssten Gemeinden, die den notwendigen Stack auf ihrer Hardware nicht bereitstellen können, dann eben ins Hosting wechseln oder mehr Geld in die Hand nehmen. An dieser Stelle sei angemerkt, dass ich 2 x mit großem zeitlichem Abstand nachgefragt habe, ob es denn möglich oder geplant sei, selbst eine eigene Synapse-Instanz für den CT-Chat zu betreiben, was klar verneint wurde. Wir hatten also Bock, noch deutlich mehr selber zu machen, aber Self-Hoster hier weiter zu "empowern" stand scheinbar nicht auf eurer Agenda.

Viele Self-Hoster nutzen kostengünstigen PHP-Webspace, um ChurchTools zu betreiben. Wenn wir mehr als PHP benötigen, wird das für sie schwierig. Es gab bereits erhebliche Probleme, als Chromium auf dem Server für die PDF-Erstellung benötigt wurde, und bei einigen funktioniert die PDF-Erstellung daher einfach nicht mehr.

Ein spezifisches Beispiel ist das Session Handling in ChurchTools. Wir verwenden mittlerweile Redis dafür, um das Self-Hosting zu unterstützen, bleibt die Datei-basierte Session-Handling-Option jedoch weiterhin in ChurchTools vorhanden. Das Gleiche gilt für das Rate-Limiting, das in ChurchTools über Redis läuft und im Self-Hosting meist über die Datenbank läuft.
Ich glaube gerne, dass ihr bereit seid, mehr zu tun, aber das entspricht nicht der Mehrheit.

Zum Thema eigene Domain:

Ich würde argumentieren, dass eine eigene Domain bei CT nicht nötig ist. Für eine Webseite ist das etwas anderes, aber wenn man ein Tool einer Firma nutzt ist es ziemlich normal, dass dieses nicht unter der eigenen Domain läuft. Di meisten User wissen am Schluss eh nicht welche Domain sie gerade nutzen und was eine Domain überhaupt ist.
Eine Weiterleitung der alten auf die neue Domain für Rückwärtskompatibilität ist natürlich sinnvoll. Die Lösung mit dem Proxy ist nicht optimal, aber die Alternative dazu ist, dass wir Zertifikate für eure Domains ziehen müssen und das macht unsere Infrastruktur wieder komplizierter und Fehleranfälliger für ein Feature, das wenig gewünscht wird und aus meiner Sicht nicht wirklich nötig ist.

Ehrenamtliche wollen Zugriff zum Code

Wir hatten immer mal wieder Anfragen von Usern die am code mitentwickeln wollten und bisher haben wir soweit ich mich erinnere noch nie Nein dazu gehabt, ne kurze Nachricht von dir hätte hier vermutlich gereicht

Schließlich kostet uns das Self-Hosting zu viel Mühe und nimmt uns Zeit und Möglichkeiten, ChurchTools weiterzuentwickeln. Wir sehen insgesamt einen größeren Nutzen darin, diese Zeit in die Weiterentwicklung von ChurchTools zu investieren.

Ich hoffe ich konnte damit einige Fragen klären und besser verständlich machen.

Zum Abschluss noch ein Dankeschön für den Auto-Updater der CT bei den Self-Hostern durch die einfachen Updates sicherer gemacht. Und auch Danke für den LDAP Wrapper. Beides Tools die CT vorangebracht haben.

Ich finde es immer toll wenn Tools und Erweiterungen für ChurchTools in der Community entstehen.

Simon2

@milux Magst du die uneingeweihten Nicht-Self-Hoster kurz aufklären?
CT unterstützt demnächst kein Self-Hosting mehr?
Oder bestimmte Form davon nicht mehr?
....

matthiasdupont

@simon2 Es kam eine Mail dazu an alle Self-Hoster. Self-Hosting wird zum 01.05.2024 eingestellt.

aschild

Hallo Alle,

danke für den Thread hier.

Auch wir sind aktuell noch Selbsthoster, das seit bald 5 Jahren.

Im Herbst 2018 haben wir uns aus den nachfolgenden Gründen dafür entschieden:

Datenstandort Schweiz
Als Teil der Landeskirche waren wir in der Vergangenheit aufgefordert worden, "Besonders Schützenswerte Personendaten" nicht ins Ausland zu übermitteln
Als Landeskirche sind wir vom Recht her dem (Berner) Kantonsrecht unterstellt und dieses übernimmt das neue Datenschutzrecht von der Bundeseben voraussichtlich erst Sommer 2025.
Es ist tatsächlich so, dass hier Kantonsrecht über dem Bundesrecht steht!
Zum Glück wurde zumindest im Kanton Bern eine Revion der Verordnungen gemacht, die nun das Ausland auch ermöglichen, solange das Datenschutzrecht auf mindestens gleichem Niveau liegt.
Somit ist es für uns auch möglich die Daten in der der EU zu Hosten, aber ganz klar nicht in Amerika
Direkter DB Zugriff ermöglicht viele Sachen die sonst nicht machbar sind
Das ist vor allem ein historisches Thema, dank dem gut Dokumentierten REST API ist das heutzutage kein Grund mehr

Somit sind für uns die Objektiven Gründe für's Selbsthosting in den letzten Jahren nach und nach entfallen.

Das Argument dass nur 5% das Selbsthosting machen ist natürlich eine Marketingaussage, interessanter wäre da ob eher die grossen Installationen selbst gehostet werden. (Das nehem ich zumindest an, da das Selbshosting finanziell gesehen nur Nachteile bringt)

Wir werden dem Selfhosting nicht nachtrauern, aber die Umstellung wird uns dann schon noch das eine oder andere abverlangen.

MichaelG

Kurzer Einschub für alle Mitleser, die zur Gruppe gehören, von der David spricht, Selbshoster sind, sich aber nur Semi auskennen und nun möglicherweise verunsichert sind, ob das nun gut oder schlecht ist was da kommt:

Wir sind schon sehr lange bei CT (damals wurde grad die Ressourcenbuchung eingeführt und einen Dienstplan gab es noch nicht; das waren Zeiten, wir konnten wir nur Gemeinde bauen ) und seit dem Self Hoster, vor allem wegen des Arguments der Kontrolle. Mittlerweile dürften wir zu einer der etwas größeren Installationen gehören (ich hab keine Vergleiche, aber das größte Paket haben wir weit überschritten). Vor einiger Zeit sind wir aber gewechselt, nach langem Fragen stellen und austarieren. Und: ich habe es seit dem keinen Moment bereut. Der Service klappt super, die Arbeit auf unserer Seite ist weniger geworden und es läuft einfach.

Bei all dem: ich kann die verstehen, die sich auskennen und gerne weiterhin alle Möglichkeiten haben wollen. Deswegen ist das ausdrücklich kein Gegenpost zum OT. Ich will nur dort „Ängste und Sorgen“ derer nehmen, die ihr System so am laufen haben, und eigentlich nichts verändert haben wollen, weil es ja läuft. Wir haben gute Erfahrungen gemacht und aus diesen kann ich sagen: es wird weiter laufen und euch Arbeit ersparen.

Zur Domain: wir hatten eine Subdomain auf unserer Instanz laufen. Die hab ich per Redirect/Weiterleitung auf die CT Domain gleitet. Ich frag mich bis heute, ob das jemals jemandem wirklich aufgefallen ist.
Deswegen der Tipp: Sucht euch am besten jetzt schon ne schöne CT Domain raus und spart eich ggf. auch hier unnötige Extraarbeit Domainhoster bieten meist einfache Weiterleitungen eurer bisherigen Subdomain auf die neue CT Domain an, so dass es den Usern möglicherweise nicht mal auffällt

andrea.schulz

@michaelg da ist ein super Tipp. Das kann man ja auf jeden Fall machen wobei der Churchtools Finder auch vielen sehr weiterhilft.

teleharry

Liebes ChurchTools-Team,

vor über 7 Jahren haben wir ChurchTools in unserer Gemeinde eingeführt. Hier gab es insbesondere kontroverse Diskussionen mit Geschwistern zum Datenschutz. Letztlich hat die Möglichkeit der Datenresidenz in Form eines Selfhosters uns dazu verholfen für viele kritische Stimmen einen Kompromiss zu finden. Wir betreiben den Server in unserer eigenen Gemeinde neben anderen Diensten. Dabei nutzen wir Verschlüsselung auf Filesystemebene, um selbst beim Einbruch/Diebstahl vorbeugen zu können. Bei einem Datenleck oder Schwachstelle in dem nunmehr nur noch zentralistisch möglichen Hosting durch Hetzner ist das Angriffspotentiel durch die geteilte übergreifende Umgebung auf alle Churchtools-Nutzer enorm.

Die Argumentation, daß viele Installationen nicht aktualisiert werden, oder unqualifizierte Supportanfragen hohen Aufwand generieren mag durchaus nachvollziehbar sein. Dennoch geiselt die daraus nun entstandene Entscheidung kein SelfHosting mehr anzubiten alle potentiell vorbildlich betriebene Umgebungen als SelfHoster.

Zu vielen Themen gibt es auch weniger radikale Lösungen, zum Beispiel:

Die Bereitstellung von ChuchTools ausschließlich als Container wie es bei vielen Anbietern allmählich zum Standard wird. Hier existiert auch geringere Streuwirkung von Fehlern durch das Gastsystem oder Fehler in der Bereitstellung. Natürlich erhöht dies auch die Komplexität aber damit wird es auch umso wahrscheinlicher, daß die Lösung entsprechend qualifiziert betrieben und zum Support zugearbeitet werden kann.
Auch sollte es ein leichtes sein deutliche Hinweise bis zu Funktionseinschränkungen für alte und nicht unterstützte Versionen global einblenden zu lassen oder gar Supportanfragen über die Churchtools-Oberfläche davon abhängig zu gestalten.
Wenn Supportaufwendungen bei SelfHoster tatsächlich höher sind, könnte man dies auch in unterschiedlichen Preisen umlegen.

In Summe reift hierzu vielmehr die persönliche Einschätzung, daß durch die enge Verzahnung zwischen einem Webhoster (Hetzner) und Churchtools darüber hinausgehende strategisch wirtschaftliche Ziele verfolgt werden.
Das an sich allein ist auch durchaus in Ordnung, es ist nur traurig daß dabei so wenig Rücksicht auf Nutzer in Minderheit genommen wird, da es sich nach wie vor um eine Lösung für christliche Einrichtungen handelt.

Meine Hoffnung bleibt hierbei noch einmal zu einem transparent und allseitig dienlichen Lösungsprozess anregen zu können.

Viele Grüße und Gottes Segen

sirdud

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

Zum Thema eigene Domain:

Ich würde argumentieren, dass eine eigene Domain bei CT nicht nötig ist. Für eine Webseite ist das etwas anderes, aber wenn man ein Tool einer Firma nutzt ist es ziemlich normal, dass dieses nicht unter der eigenen Domain läuft. Di meisten User wissen am Schluss eh nicht welche Domain sie gerade nutzen und was eine Domain überhaupt ist.
Eine Weiterleitung der alten auf die neue Domain für Rückwärtskompatibilität ist natürlich sinnvoll. Die Lösung mit dem Proxy ist nicht optimal, aber die Alternative dazu ist, dass wir Zertifikate für eure Domains ziehen müssen und das macht unsere Infrastruktur wieder komplizierter und Fehleranfälliger für ein Feature, das wenig gewünscht wird und aus meiner Sicht nicht wirklich nötig ist.

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

Klar, ich kann die User die mit der Website arbeiten per Redirect auf meinegemeinde.church.tools weiterleiten. Was ist aber mit den Usern, die die App nutzen? Da dürfte die Weiterleitung nicht funktionieren, oder?

Wie ich unseren Datenschutzkritikern antworten soll, dass zukünftig dann die Daten aller Mitglieder und Freunde der ChurchTools Kunden Gemeinden an einer zentralen Stelle von einem Unternehmen gehostet werden und damit dann Hackern oder wem auch immer auf dem Silbertablett zur Verfügung gestellt werden, weiß ich nicht. Ein Stichwort dass in dem Zusammenhang gefallen ist, war Christenverfolgung... Da gehen mir dann ehrlich gesagt auch die Gegenargumente aus.

Da wir als Gemeinde tatsächlich ChurchTools momentan nur für die Besetzung von Aufgaben während der Gottesdienste nutzen, sowie Kalender und Ressourcenverwaltung, stelle ich mir ernsthaft die Frage, ob wir uns nicht doch eine Alternative überlegen sollten. Vor unserer ChurchTools Zeit hat das auch funktioniert...

Andi 1

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

@davidschilling sagte in Kritik bzgl. Ende des Self-Hostings:
Ein Stichwort dass in dem Zusammenhang gefallen ist, war Christenverfolgung...

Das war/ist bei uns vereinzelt auch ein Thema.

narnitz

Disclaimer: Ich schreibe hier jetzt nicht als ChurchTools Mitarbeiter sondern als ehrenamtlicher CT Admin und Betreiber der IT Infrastruktur meiner Kirchengemeinde!

@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).

Klar, ich kann die User die mit der Website arbeiten per Redirect auf meinegemeinde.church.tools weiterleiten. Was ist aber mit den Usern, die die App nutzen? Da dürfte die Weiterleitung nicht funktionieren, oder?

In der App müssten die Benutzer entweder die *.church.tools URL angeben, oder man müsste die Redirect Funktionalität noch implementieren.

Wie ich unseren Datenschutzkritikern antworten soll, dass zukünftig dann die Daten aller Mitglieder und Freunde der ChurchTools Kunden Gemeinden an einer zentralen Stelle von einem Unternehmen gehostet werden und damit dann Hackern oder wem auch immer auf dem Silbertablett zur Verfügung gestellt werden, weiß ich nicht. Ein Stichwort dass in dem Zusammenhang gefallen ist, war Christenverfolgung... Da gehen mir dann ehrlich gesagt auch die Gegenargumente aus.

Ich hatte in meiner Gemeinde auch schon ähnliche Diskussionen. Meist sind aber genau diese Leute ganz vorne bei der Nutzung von Office 365 o.ä. dabei.
Insgesamt ist auch die Frage: "Benutzt du WhatsApp oder Facebook?" ein gutes Totschlagargument.

Ebenfalls habe ich die internen IT-Dienste von mehreren Kirchengemeinden gesehen und da ist von Sicherheit oft leider nur wenig die Rede. Von Webspaces mit Standardpasswort bis hin zu 'JesusIstUnserHerr2002' (nur ein erfundenes Beispiel) oder einer komplett fehlenden .htaccess Datei (inkl. Datenbankzugangsdaten im Klartext ) habe ich da schon einiges zu Augen bekommen.
Dementsprechend würde ich hier die Wahrscheinlichkeit höher sehen, "Daten auf einem Silbertablett" vor zu finden.

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.
Ist 1&1 oder der Feld-Wald-Wiesen-Shared-Webhost nicht ebenfalls eine gewinnorientierte Firma?

All in all kann ich als Ehrenamtlicher Admin bei uns sagen: Ich bin heidenfroh, das ich mich um einen Dienst weniger kümmern muss und für einen Dienst weniger sicherstellen muss, dass personenbezogene Daten DSGVO-konform gespeichert, gesichert und ggf. wieder gelöscht werden.
(Okay, dieser Punkt liest sich vielleicht etwas Paradox, weil ich Befruflich an der App arbeite, aber ich denke Ihr versteht was ich meine ^^)

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.