Control Panel als SaaS

[DerMitSkill]

Hallo!

Würdet ihr ein Control Panel (für (v)Server) nutzen, welches als Software as a Service angeboten wird?

Das könnte zum Beispiel so aussehen: Man registriert sich für die (kostenpflichtige) Nutzung des Control Panels. Dort gibt es eine Funktion, mit der man einen (v)Server zur Verwaltung hinzufügen kann. Man gibt die SSH-Zugangsdaten (Benutzer und Keyfile oder Passwort) an. Entweder wird der Server anschließend mit vorher ausgewählter Software installiert oder es werden diverse Pfade zu den entsprechenden Konfigurationsdateien, die nicht automatisch gefunden wurden, abgefragt, um den Server zu verwalten. Anschließend ist es ein Control Panel wie die typischen Control Panels Confixx, Plesk, ispCP usw. (bzw. im Idealfall besser ), nur eben bei dem Anbieter gehostet.

Von dem Anbieter des Control Panels als SaaS nehmen wir an, dass er seriös ist, einen guten Ruf hat und für die Sicherheit gesorgt ist. Service ist auch bestens.. alles in allem macht es einen guten Eindruck.

Einen Preis lassen wir mal außer acht.

Vorteil einer SaaS-Lösung wäre, dass das Update-Theater wie mit Plesk & Co. entfällt und das Control Panel den Server nicht so sehr beeinflusst.

Gerne auch ein Kommentar zur Teilnahme an der Umfrage

 

[JaEgErmEistEr]

Hätte da doch erhebliche Sicherheitsbedenken

 

[memphis]

Also ich finde das etwas kritisch. Was mache ich, wenn der Server des Anbieters nicht erreichbar ist? Funktioniert das Panel dann? Wenn nein, ist das ganz klar ein Grund, dies nicht einzusetzen, da eine autarke Funktion des Servers nicht gegeben ist... Sonst bin ich ja auf 2 Anbieter angewiesen. Meinen Serveranbieter und meinen Control-Panel-Anbieter...

Interessant wäre es, wenn sich dieses Panel sowohl beim Anbieter läuft als auch lokal auf das System kopiert und die Domain, unter der das Panel erreichbar ist bei einem ausfall umschwenkt. Damit könnte man die eigenen Systeme entlasten und wäre bei einem Ausfall des Anbieters dennoch erreichbar...

Und der Datenbestand in dem Control-Panel müsste auch ständig gesichert werden, am besten auch auf den Localen Maschinen, damit man auch ständig an die Daten kommt.

 

[DerMitSkill]

Hätte da doch erhebliche Sicherheitsbedenken

Wie könnte man diese aus dem Weg räumen?

Also ich finde das etwas kritisch. Was mache ich, wenn der Server des Anbieters nicht erreichbar ist? Funktioniert das Panel dann? Wenn nein, ist das ganz klar ein Grund, dies nicht einzusetzen, da eine autarke Funktion des Servers nicht gegeben ist... Sonst bin ich ja auf 2 Anbieter angewiesen. Meinen Serveranbieter und meinen Control-Panel-Anbieter...

Einem Ausfall wird auf Seiten des Anbieters durch Redundanz entgegengewirkt.
Andererseits: Wie oft ändert man etwas am eigenen Server? Will man so dringend ein E-Mail-Postfach anlegen oder einen Wert in der php.ini ändern, dass man nicht eine Stunde warten kann?
Natürlich ein Extremfall, wovon man in der Regel nicht ausgehen kann.

Wenn der Anbieter sein Angebot einstellen würde (ob Insolvenz, Aufgabe des Produktes, oder oder..) ist man dennoch nicht verloren, da man immer noch von Hand (wie es viele tun) seinen Server verwalten oder ein anderes Control Panel installieren kann.

Interessant wäre es, wenn sich dieses Panel sowohl beim Anbieter läuft als auch lokal auf das System kopiert und die Domain, unter der das Panel erreichbar ist bei einem ausfall umschwenkt. Damit könnte man die eigenen Systeme entlasten und wäre bei einem Ausfall des Anbieters dennoch erreichbar...

Prinzipiell machbar. Aber inwiefern entlastet man die eigenen Systeme? In dem Fall würde das Control Panel immer auf dem Server liegen und es nur im Falle eines Aufalls benutzt werden, um den Server zu verwalten. Es ist nichts anderes, als sich durch eine Website zu klicken. Ich denke, von Entlastung kann man da wohl kaum sprechen.

Und der Datenbestand in dem Control-Panel müsste auch ständig gesichert werden, am besten auch auf den Localen Maschinen, damit man auch ständig an die Daten kommt.

Die Konfigurationsdateien werden ja auf den verwalteten Servern gespeichert. Natürlich kann man seitens des Anbieters und auch lokal diese sichern.


Mal an Dich (und alle anderen), als Anbieter: Denkst Du, Deine Kunde würden ein solches System nutzen, wenn Du es für von Dir vermietete Server anbietest? Natürlich läuft es dann nicht bei einem externen Anbieter, sondern auf einem Server bei Dir als Anbieter. Quasi als Reseller, nur für eigene Kunden. Ggf. wäre ja auch ein Management vom Control Panel-Anbieter möglich, damit Du Dich nicht mit Updates des Control Panels rumschlagen musst.

 

[Roger Wilco]

Wie könnte man diese aus dem Weg räumen?

Das kann man prinzipbedingt nicht – zumindest meiner Meinung nach.

Wenn in deiner ISP-Panel-aaS-Lösung eine Sicherheitslücke gefunden wird, kann ein Angreifer ggf. auf alle (sic!) damit verwalteten Systeme mit Administratorrechten zugreifen.

Dieses Risiko kann man mit einer lokalen Lösung verringern, die man entsprechend gegenüber dem bösen Internet absichert.

Will man so dringend ein E-Mail-Postfach anlegen oder einen Wert in der php.ini ändern, dass man nicht eine Stunde warten kann?

Ja, will man. Rede einfach mal mit diversen Anbietern darüber, was die Kunden wollen und welche Lappalien für diese einen Kündigungsgrund darstellen können.

Wenn der Anbieter sein Angebot einstellen würde (ob Insolvenz, Aufgabe des Produktes, oder oder..) ist man dennoch nicht verloren, da man immer noch von Hand (wie es viele tun) seinen Server verwalten oder ein anderes Control Panel installieren kann.

Ja, stimmt. Dann braucht man deine Lösung aber erst gar nicht in Betracht ziehen. Hast du schonmal versucht, eine entsprechende Lösung eines Herstellers mit einem Produkt eines anderen Herstellers zu ersetzen? Ohne das System neu zu installieren oder die Einstellungen ggf. manuell übernehmen zu müssen?

Die Konfigurationsdateien werden ja auf den verwalteten Servern gespeichert. Natürlich kann man seitens des Anbieters und auch lokal diese sichern.

Und was ist mit anständigem Change Management? Mit revisionssicherer Speicherung der Konfiguration? Wir reden ja sicherlich nicht von den Kinderzimmerprovidern mit 2 dedizierten Servern.

 

[DerMitSkill]

Wenn in deiner ISP-Panel-aaS-Lösung eine Sicherheitslücke gefunden wird, kann ein Angreifer ggf. auf alle (sic!) damit verwalteten Systeme mit Administratorrechten zugreifen.

Dieses Risiko kann man mit einer lokalen Lösung verringern, die man entsprechend gegenüber dem bösen Internet absichert.

Um das Risiko zu senken, gibt's da schon einige Möglichkeiten:
- eigener Benutzer für das Control Panel, welcher nur auf bestimmte Dateien zugreifen und nur bestimmte Befehle ausführen kann.
- Zugriff per SSH nur von der IP des Control Panel-Servers (wie man das nun macht, damit der Server-Inhaber noch manuell per SSH auf dem Server arbeiten kann, muss man genauer planen; nur mal so als Grundidee; mit der extra-Benutzer-Variante kombiniert würde es ja gehen)

Alternativ, damit das oben genannte Szenario nicht eintreten kann:
1. Man meldet sich im Contol Panel an, setzt alle Einstellungen, und überträgt am Ende die Änderungen an den Server. Dazu werden extra die SSH-Zugangsdaten (User und Keyfile bzw. Passwort) abgefragt und nicht gespeichert.
2. Man meldet sich im Control Panel an, die Zugangsdaten werden nur für die Session gespeichert und nach dem ausloggen oder nach einer bestimmten Zeit (Timeout, wenn der Benutzer sich nicht ausgeloggt hat) gelöscht.

Variante 1 wäre die sicherere.

Insgesamt muss man sagen, dass man viel Aufwand betreiben muss, um das Control Panel abzusichern, was aber getan würde.

Herausforderung wäre dann auf jeden Fall, die Sicherheitsbemühungen für das Produkt zu präsentieren.

Ja, will man. Rede einfach mal mit diversen Anbietern darüber, was die Kunden wollen und welche Lappalien für diese einen Kündigungsgrund darstellen können.

Da hast Du Recht. Da muss man eben mit entsprechender Redundanz entgegenwirken.

Ja, stimmt. Dann braucht man deine Lösung aber erst gar nicht in Betracht ziehen. Hast du schonmal versucht, eine entsprechende Lösung eines Herstellers mit einem Produkt eines anderen Herstellers zu ersetzen? Ohne das System neu zu installieren oder die Einstellungen ggf. manuell übernehmen zu müssen?

Das wäre der Worst-Case-Fall..

Und was ist mit anständigem Change Management? Mit revisionssicherer Speicherung der Konfiguration? Wir reden ja sicherlich nicht von den Kinderzimmerprovidern mit 2 dedizierten Servern.

Um Details der Software geht es zur Zeit hier nicht. Eher um die Sicherheit, bis so eine Software erstmal interessant wird.

In erster Linie zielt es auf Kunden mit einzelnen Server ab. Wenn ein Provider die Software für seine Kunden einsetzten möchte, ist über eine eigene Provider-interne Installation nachzudenken.

 

[BruceLee]

Ich persönlich halte die Idee für nicht tragfähig.
Schon dein erstes Argument, welches einen Vorteil verschaffen soll, sehe ich nicht.

Vorteil einer SaaS-Lösung wäre, dass das Update-Theater wie mit Plesk & Co. entfällt und das Control Panel den Server nicht so sehr beeinflusst.

Auch die ominöse SaaS-Lösung bedarf Updates. Und selbstverständlich muss die Lösung für alle Distributionen, Versionen und Kombinationen immer passen. Da kommt so viel ins Spiel, dass ich es einem Anbieter nie zutrauen würde. Am Ende muss man wieder so viel manuell anpassen, dass man auch auf die Lösung verzichten kann.
Hypothetisch: Stell dir mal vor die spielst ein Update ein und die Konfiguration wird gut an den Server übermittelt, aber nur auf einem Debian System. Unter Centos oder Suse gibts einen Fehler. Schon geht der Spaß los. Nicht umsonst werden von vielen ControlPanel Hersteller nur bestimmte Distributionen unterstützt. Hinzu kommen unzählige Fälle, die ebenfalls dadurch als zusätzliche Fehlerquelle hinzukommen. Ganz zu schweigen von den Sicherheitsaspekten.

Also mein ganz persönliches Fazit: born to die

 

[Ben.]

Wäre die lokale Absicherung nicht genauso fehleranfällig wie eine Plesk-Konfiguration?

Ich würde diesen Dienst nicht nutzen, aufgrund der genannten Dinge.

Wenn dann eher einen Client-Service auf dem Server installieren, der sich mit dem SaaS-Host verbindet und Konfigurationsdaten bezieht.

Aber ist nicht weiter gedacht ob genauso unsicher oder nicht.

 

[DerMitSkill]

Auch die ominöse SaaS-Lösung bedarf Updates.

Die sind aber Sache des Anbieters, nicht des Server-Inhabers. Und das ist der Vorteil für den Nutzer.

Und selbstverständlich muss die Lösung für alle Distributionen, Versionen und Kombinationen immer passen. Da kommt so viel ins Spiel, dass ich es einem Anbieter nie zutrauen würde. Am Ende muss man wieder so viel manuell anpassen, dass man auch auf die Lösung verzichten kann.
Hypothetisch: Stell dir mal vor die spielst ein Update ein und die Konfiguration wird gut an den Server übermittelt, aber nur auf einem Debian System. Unter Centos oder Suse gibts einen Fehler. Schon geht der Spaß los. Nicht umsonst werden von vielen ControlPanel Hersteller nur bestimmte Distributionen unterstützt. Hinzu kommen unzählige Fälle, die ebenfalls dadurch als zusätzliche Fehlerquelle hinzukommen.

Da muss die Software eben entsprechend entwickelt werden. Sie muss auf die Distribution, Version, verschiedene Zusammenstellungen, Module/Erweiterungen und manuelle Veränderungen achten.

Anfangs kann man die SaaS-Lösung ebenfalls auf bestimmte Distributionen und bestimmte Software beschränken. Bei der httpd.conf kann man nicht so viel falsch machen, wie bei bestimmten anderen Dingen.

Hier sollte man nicht von einem blinden Control Panel ausgehen, was Änderungen in die Leere schießt und einfach hofft, dass sie schon passen. Alleine schon, weil der Anbieter eine große Verantwortung hat.

Absichern kann man es mit der Garantie des Anbieters, welcher durch vertragliche Zusicherung entstandene Fehlkonfiguration manuell behebt; ohne zusätzliche Kosten.

 

[DerMitSkill]

Wäre die lokale Absicherung nicht genauso fehleranfällig wie eine Plesk-Konfiguration?

Du meinst die von memphis genannte? Nicht genauso, aber eher als die SaaS-Lösung, wobei dann auch jeglicher Vorteil entfällt. Eine lokale Kopie ist meiner Meinung nach keine sinnvolle Lösung.

Wenn dann eher einen Client-Service auf dem Server installieren, der sich mit dem SaaS-Host verbindet und Konfigurationsdaten bezieht.

Das ist eine gute Idee und zur alltäglichen Verwaltung des Server eine bessere Lösung, als per SSH. So könnte man die anfänglich genannte Erstinstallation eines Server (bei der auch der Client-Service übertragen wird; oder eben optional und der Client-Service manuell vom Server-Inhaber) über SSH durchführen, wobei die SSH-Zugangsdaten nach der Installation gelöscht werden. Ein dickes plus für die Sicherheit (man kann die Kommunikation zwischen Client (der einzelne Server) und Server (der Control-Panel-Server) verschlüsselt, getunnelt übertragen; hat alle Möglichkeiten zur sicheren Authentifizierung (nur von bestimmter IP, Verschlüsselung) und kann die Rechte auf dem einzelnen Server kontrollieren) und sicherlich eine genauere Ausführung Wert.

 

[fbartels]

Hi,

ich habe mir deine Umfrage ein zwei Momente durch den Kopf gehen lassen. Das was in deinem Konzept fehlt ist der wirkliche Mehrwert für den Nutzer. Klar der lokale Admin muss sich nicht um die Updates für das ControlPanel kümmern, aber im Gegenzug liefert er sich dem CP auch vollkommen aus um den Betrieb seines Servers zu gewährleisten.

Interessanter fände ich folgendes Konzept (geht eher in Richtung Managed):

• Nutzung eines Configuration-Management-Systems wie z.B. Puppet als Basis
• Lokale Nutzerverwaltung über LDAP
• Integration einer Monitoring Lösung

Der Kunde installiert sich bei seinem Provider ein Minimal-Image einer (von dir) bestimmten Distribution und führt anschließend ein Initalisierungsskript auf dem (v)Server aus (Richtet OpenLDAP ein, fügt deine Repositories ein, installiert Basis Monitoring). Anschließend kann der Kunde über ein von dir bereit gestelltes Interface ein Profil für seinen Server auswählen (z.B. Mail oder Webserver). Anschließend wird der Server Einzugsfertig eingerichtet.

Die Komplette Nutzerverwaltung läuft über LDAP, welches für jeden Kunden Einzigartig ist (eigene Datenbank) und ständig zwischen den Kunden Rechner und deinem Verwaltungssystem repliziert wird. Als i-Tüpfelchen werden die Nutzdaten des Kunden regelmäßig gesichert, sodass im Worst-Case der Kunde den Server neu einrichten kann ohne das Daten verloren gehen oder erst einmal jemand Stundenlang das System per Hand einrichten muss. Für die Nutzerverwaltung brauchst du dann natürlich auch noch ein Interface das parallel auf deinem System und dem Kundensystem laufen kann (Dank der LDAP-Replizierung).

Das ganze ist halt eher ein Full-Service Ansatz für Nutzer und Unternehmen die zwar einen Server brauchen sich aber nicht um die Einrichtung kümmern können/wollen. Funktioniert aber auch mit On-Site Installationen (ganz im Sinne des Cloud-Computing).

Gruß Felix

PS: wenn ich den nächsten sechs Monaten aus diesem Konzept Geld machen will erwarte ich einen Anteil

 

[DerMitSkill]

Vielen Dank für Dein ausführliches Feedback

Die Grenzen des Services sind nahezu unerschöpflich. Dazu gehört auch die Ersteinrichtung, Aktualisierung und Monitoring. Wie genau man das umsetzten kann, ist später zu klären, Deine Lösung wäre eine Möglichkeit.

Was meinst Du mit der Nutzerverwaltung, die auf dem lokalem System (also auf dem Server von Kunden) läuft? Mir erschließt sich nicht ganz, was mit dieser gemacht wird bzw. was in der LDAP-"Datenbank" gespeichert werden soll.

 

[fbartels]

Mit LDAP lassen sich einfach Benutzerkennungen zwischen Servern synchronisiert werden.

In das LDAP kommen alle Benutzerdaten, also Shell-Logins, FTP-Daten, E-Mail Adressen, VPN-Kennungen, Home Verzeichnisse...

 

[Huschi]

Hier sollte man nicht von einem blinden Control Panel ausgehen, was Änderungen in die Leere schießt und einfach hofft, dass sie schon passen. Alleine schon, weil der Anbieter eine große Verantwortung hat.

Das ist der Teil, der mir am Meisten auf stößt, aber Dich anscheinend irgendwie kalt lässt.

Wir kennen (fast) alle Plesk. Plesk hat mehrere Millionen Installationen. Und wenn ein Update kommt, funktioniert es bei den meisten. Nur bei Einigen nicht.
Handelt Parallels hier Veranwortungslos?
Oder haben diese paar Fälle nur irgendeine Kombination die die Entwickler in ihren Testsystemen nicht nachvollziehen können?
Was will ein SaaS-Anbieter wirklich anders/besser machen um erst gar nicht in diese Bredouille zu kommen?

Das ist die wesentliche Frage die hier immer wieder aufgeworfen wird!

Eine Garantie auf Funktionsfähigkeit kann der Anbieter gar nicht geben. Denn sobald er einmal auf finanziellen Schadensersatz verklagt wurde, dürfte er wahrscheinlich seinen Laden dicht machen.


Auch der echte Mehrwert ist bisher nicht wirklich erkennbar.
Mehrwert wäre meiner Meinung nach z.B. Tarifabrechnung nach Nutzungszeit, Online-Migration von einem Server auf den Anderen, externes Backup-System, etc.

huschi.

 

[daemotron]

Ich sehe noch kein wirkliches Einsatzfeld für ein SaaS-Adminpanel (davon mal abgesehen, dass ich nie einer dritten Person meinen SSH-Schlüssel anvertrauen würde). Für den Kleinstbereich (1-2 (v)Server) kann man den Aufwand ganz gut von Hand oder mit ein paar Shell-Skripten wuppen, oder eben Plesk verwenden, wenn man's lieber grafisch hat.

Für größere Setups braucht man IMHO maßgeschneiderte Lösungen, da die Software sich am Vertriebsprozess des Providers ausrichten muss - eine Schwäche, die von sämtlichen derzeit verfügbaren Standard-Lösungen konsequent ignoriert wird. Infolgedessen arbeiten alle größeren Provider, deren interne Tools und Abläufe mir zumindest dem Namen nach bekannt sind, mit individuell programmierter Software.

Unter Sicherheitsaspekten ist schon ein externer Konfigurationsgenerator für mich die äußerste Grenze des gerade noch erträglichen - selbst die am besten auditierte Software (bei einem kommerziellen Produkt eher unwahrscheinlich) weist am Ende doch die eine oder andere sicherheitskritische Lücke auf. Allein der Übertragungsweg bietet zahllose Möglichkeiten eines Fail. Darüber hinaus ist die Infrastruktur des SaaS-Anbieters für mich eine Black Box und somit ein (potenziell) unkalkulierbares Risiko.

 

[DerMitSkill]

Wie ich sehe, sind die Sicherheitsbedenken im Allgemeinen sehr groß und es bestünde eine mehr als geringe Chance, dass eine solche SaaS-Lösung Anklang findet, auch wenn sie einen Mehrwert hätte.

Danke an Alle