none
Automatisches Update der gesamten Website RRS feed

  • Frage

  • Hi,

    wir haben eine Website entwickelt, die für jeden Kunden individuell in einer eigenen Subdomain aufgerufen werden kann und muss (Kunden möchten keine generelle Seite und sich kundenspezifisch einloggen, sondern eine komplette eigene Umgebung: dahinter steckt auch jeweils eine für jeden Kunden eigene DB, da die Daten komplett zu anderen Kunden abgschottet sein muss).

    Wenn nun eine neue Version der Website existiert, möchten wir ungern X Mal an X Orten die Website publishen.

    Die Idee ist, der Kunde kann bei sich feststellen, wenn es eine neuere Version gibt. Dann besteht hier die Idee, das der KundenAdmin auf einen z.B. Button zu klicken kann und sämtliche neuen Komponenten werden über Webservice-Zugriffe und -Prüfungen dann per FTP von einen zentralen Ort, wo die neueste Version existiert in das aktualle C:\wwwroot\inetpub\{kunde-software}\ Verzeichnis überspielt. Sperrmechanismen für andere User des Kunden etc sind auch vorhanden. Der Vorgang soll z.B. über eine externe DLL mit Parametern, direkt in der Website serverseitig oder per Assembly (ext. Zugriff) in einer SP der DB eingebunden geschehen.

    Wie ist diese Idee zu bewerten oder gibt es eine bessereund evtl. sichere Lösung?

    Gruß Hipp


    Gruß Hipp

    Freitag, 1. Januar 2016 16:53

Antworten

  • Hi,
    am Anfang sollte ein Konzept erarbeitet werden, in dem die wesentlichen Vorgaben formuliert sind. Darin ist dann auch festgelegt, wie die Daten unterschiedlicher Kunden gegeneinander geschützt werden. Wenn jeder Kunde seine eigene Serverinstanz hat, dann braucht man keine mandantenfähige DB. Es gibt dann lediglich eine zentrale Datenbank, die einen Parametersatz für jeden Mandanten enthält. Der vorgeschaltete Handler wählt je Sitzung den Parametersatz aus und stellt ihn als Sitzungsobjekt bereit.

    Da das html-Protokoll statuslos ist, ist es egal, wie viele Mandanten in einem Pool arbeiten. Wichtig für die Performance sind die Workloads, d.h. die Anzahl der Requests und die Last (Ressourcen), die ein Request im Mittel erzeugt. Daraus leiten sich die benötigten Hardware-Ressourcen ab. Wenn diese nicht ausreichen, dann muss das System entsprechend angepasst werden: mehrere Pools, mehrere Server als Farm.

    Da alle Kunden den gleichen Code der Webanwendung benutzen, crashen alle Kunden, egal, ob die fehlerhafte Assembly vielfach kopiert wird, oder alle Anwender die gleiche Assembly nutzen. Deshalb ist der Fehlertoleranz und der Qualitätssicherung natürlich besondere Aufmerksamkeit zu widmen.

    Das gesamte Sicherheitskonzept beinhaltet auch die Authentifizierung. Wenn FBA genutzt wird und die Kunden über den Hostheader unterschieden werden, dann ist es kein Problem, wenn bei unterschiedlichen Kunden auch gleichlautenden Kennungen für die Authentifizierung genutzt werden. Auch ist es üblich, dass Anwender bei der ihrer Ersterfassung eine Kennung bekommen (z.B. Nummer oder selbst erfasster Spitzname), die sich nicht ändert, wenn sich ihre Daten in der Firma ändern (Nachname, Abteilung usw.), oder auch von den dazugehörenden Daten unabhängig sind und durch den Anwender beliebig geändert werden können, wobei innerhalb des Kunden immer nur unikate Kennungen zulässig sind. Der Versuch, einen vorhandenen Spitznamen durch einen anderen Anwender zu bekommen, wird verhindert.

    Um schnell vorwärts zu kommen, sollte ein Berater oder eine Beraterfirma in Anspruch genommen werden, mit der dann gemeinsam die benötigten Konzepte ausgearbeitet werden.

    Die Schilderung der Aufgabenstellung lässt vermuten, dass es ein recht komplexes Projekt werden soll, ähnlich wie ein SharePoint, für den bestimmt mehrere hunderttausend Stunden Entwicklungsleistungen investiert wurden. Deshalb steht die Frage, warum nicht ein solch skalierbares, mandantenfähiges System eingesetzt wird.


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks
    Kommas richtig setzen!
    Schüler sagen, Lehrer haben es gut.
    Schüler, sagen Lehrer, haben es gut

    • Als Antwort markiert Hipp1010 Donnerstag, 7. Januar 2016 15:22
    Montag, 4. Januar 2016 11:23

Alle Antworten

  • Hi,
    warum baut Ihr nicht multi-tenent-fähige Webs und einen Hander dazu, der zu jeder Anfrage einen Parametersetz aus der Datenbank holt? Jede Version des Webs existiert nur ein Mal und wertet die Parameter aus, um dann die für den Kunden spezifischen Angaben (Datenbank usw.) zu nutzen. Alternativ wäre auch ein SharePoint nutzbar, der die grundlegenden Dinge für multi-tenent Anwendungen bereits mitbringt. 

    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks
    Kommas richtig setzen!
    Schüler sagen, Lehrer haben es gut.
    Schüler, sagen Lehrer, haben es gut

    Freitag, 1. Januar 2016 17:39
  • Hi,

    vielen Dank für den Denkanstoss. Doch noch eine kurze ergänzende Erklärung zur Website. Es handelt sich eigentlich um eine Applikation. Jeder Kunde hat viele Mitarbeiter, die sich in das System einloggen können. Doch gibt es bisher 4 von 5 der Kunden, die es nicht zulassen, dass die User und weitere kundenspezifische Daten in einer gemeinsamen DB abgelegt sind (Mandantenfähig). Das war natürlich unser erster Gedanke, doch der ist leider nicht machbar. Die 4 von 5 Kunden erwarten ein komplett abgeschottetes System, da es sich hier um hochbrisante Wettberwerbsdaten handelt.

    Also was tun?

    Gruß Hipp


    Gruß Hipp

    Freitag, 1. Januar 2016 18:41
  • Hi,
    zuerst sollte das Konzept der Abschottung geklärt werden, d.h., was darunter zu verstehen ist. Da die Webanwendung im Webserver auf die Datenbanken zugreifen muss, muss sie auch die Zugangsdaten kennen. Wenn also jeder Kunde seinen eigenen Datenbankserver innerhalb seiner Firma hat, auf die die Webanwendung zugreift, muss die Webanwendung auch die Zugangsdaten kennen. Ob das nun eine Webanwendung ist, die parametergesteuert die Zugriffe auf die Infrastruktur des Kunden realisiert, oder ab das viele WebAnwendungen sind, wo jede WebAnwendung seinen eigenen Parametersatz hat, ist aus Sicherheitsgründen nur bedingt von Bedeutung. Die Sicherheit vieler Webanwendungen zu prüfen und zu zertifizieren, ist garantiert aufwendiger, als nur eine begrenzte Zahl von mandantenfähigen Webanwendungen zu prüfen und zu zertifizieren.

    Ich würde verschiedene Instanzen des Datenbankservers erstellen, für jeden Kunden, der separat abgeschottet werden soll, eine eigene Instanz mit eigenen Dienstkonten und separatem Rechtesystem, was der Kunde mindestens einsehen kann oder besser noch selbst pflegen kann. Wenn die Sicherheitsaspekte so brisant sind und die Webanwendung nur eine einfache Authentifizierung durchführen soll, dann kann man die Webanwendung so einrichten, dass mit der Anmeldung des Nutzers auf die Datenbank zugegriffen wird. Das vereinfacht zwar die Webanwendung, verkompliziert aber den Prozess der Pflege der Nutzerberechtigungen.

    Um eine Webanwendung mehrnutzerfähig zu machen, wird ein Handler angewandt, der bei jedem Sitzungsbeginn den betreffenden Parametersatz der Sitzung zuweist, so dass je nach angemeldeten Anwender die zugehörige Datenbank angesprochen wird. So etwas lässt sich einmalig prüfen und zertifizieren und sollte dem Anwender eigentlich reichen. Solch eine mehrnutzerfähige Webanwendung läuft dann für alle Kunden im gleichen Pool. Das könnte dem Sicherheitskonzept widersprechen, vor allem wenn Caches zur Geschwindigkeitsbeschleunigung genutzt werden. Aber auch dafür kann man Lösungen implementierten, prüfen und zertifizieren lassen.


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks
    Kommas richtig setzen!
    Schüler sagen, Lehrer haben es gut.
    Schüler, sagen Lehrer, haben es gut

    Samstag, 2. Januar 2016 07:56
  • Hi,

    vielen Dank für die Infos.

    ich würde gerne auf den 2. Abschnitt zu sprechen kommen. Wenn ich das richtig verstehe, so müsste wir eine sperate Db esretellen, die mandantenfähig ist und sämtliche kundenübergreifende User beinhaltet. Diese User, die der Kunde in unserem Fall selbst einpflegen will, würden dann entsprechend den Mandanten (Kunden) inne halben und die dazu passende eigene DB. Da es heute schon Import und Export von Daten gibt, die in eigenen Verzeichnissen abgeklegt sind, würde es hier keine weiteren Probleme geben. Wir müssten nur all diese Zugriffe Mandantenfähig machen.

    Doch stellt sich die Frage, wenn wir viele Kunden haben, mit vielen Mitarbeitern, die die gleiche Webandwendungen verwenden, wie verhält es sich mit der Performance?

    Außerdem ergibt sich in meinen Augen noch ein Problem: Ja, wenn wir für jeden Kunden die SELBE  Webanwendung hinstellen, so hätten wir in dem Fall, dass wenn die Webanwendung einen Fehler hätte, die bei allen Kunden (im schlimmsten Fall mehrere Dutzend, wie geplant) crashed. Natürlich sollte das durch entsprechende Vorkehrungen verhindert werden, doch gibt es keine 100%-ige Software.
    Wenn jeder Kunde seine eigene (sicherlich reduntante!) Webanwendung besitzt, so könnten wir hier noch eingreifen und die automatischen Updates bei den Kunden über unsere Lizenz-DB anhalten.

    Vielleicht fehlt uns noch etliches Verständnis. Wenn ja, so würden wir uns freuen, wenn man uns den einen oder anderen Tip geben könnte, wo es vernünftige Literatur, evtl. mit Besipielen gibt. Ja wer googeln kann ist im Vorteil, doch gibt es hier viel Müll, der uns nicht wieterbingt.

    Nachtrag:
    Die Kunden verwenden LoginNamen, die sie u.A. auch in ihren internen System haben. Ob gut oder nicht, sei dahin gestellt. Nun gibt es Kunden, die haben identische LoginNamen. Was ist nun , wenn sich ein z.B. Herr M.Mayer (den es doppelt gibt) anmelden möchte. Dies würde ja nur über z. Email-name gehen, denn "mmayer" ginge nicht. Und beim Anmelden noch die Firma angeben, wäre nicht machbar. Schon gar nicht als Dropdown, denn so würde die Konkurrenz sichtbar. Emailname wäre aber wiederum so eine Sache, denn der dürfte nicht statisch sein. Wer heiratet, ändert u.U. den Namen und somit die Email, alles schon da.

    Man müsste sich evtl. doch überlegen, ob man ein Domain nimmt. Werde das intern klären.

    Nun ich sehe, da muss noch einiges an Hirnschmalz hineingesteckt werden.

    Viele Grüße Hipp


    • Bearbeitet Hipp1010 Sonntag, 3. Januar 2016 10:38
    Samstag, 2. Januar 2016 09:47
  • Hi,
    am Anfang sollte ein Konzept erarbeitet werden, in dem die wesentlichen Vorgaben formuliert sind. Darin ist dann auch festgelegt, wie die Daten unterschiedlicher Kunden gegeneinander geschützt werden. Wenn jeder Kunde seine eigene Serverinstanz hat, dann braucht man keine mandantenfähige DB. Es gibt dann lediglich eine zentrale Datenbank, die einen Parametersatz für jeden Mandanten enthält. Der vorgeschaltete Handler wählt je Sitzung den Parametersatz aus und stellt ihn als Sitzungsobjekt bereit.

    Da das html-Protokoll statuslos ist, ist es egal, wie viele Mandanten in einem Pool arbeiten. Wichtig für die Performance sind die Workloads, d.h. die Anzahl der Requests und die Last (Ressourcen), die ein Request im Mittel erzeugt. Daraus leiten sich die benötigten Hardware-Ressourcen ab. Wenn diese nicht ausreichen, dann muss das System entsprechend angepasst werden: mehrere Pools, mehrere Server als Farm.

    Da alle Kunden den gleichen Code der Webanwendung benutzen, crashen alle Kunden, egal, ob die fehlerhafte Assembly vielfach kopiert wird, oder alle Anwender die gleiche Assembly nutzen. Deshalb ist der Fehlertoleranz und der Qualitätssicherung natürlich besondere Aufmerksamkeit zu widmen.

    Das gesamte Sicherheitskonzept beinhaltet auch die Authentifizierung. Wenn FBA genutzt wird und die Kunden über den Hostheader unterschieden werden, dann ist es kein Problem, wenn bei unterschiedlichen Kunden auch gleichlautenden Kennungen für die Authentifizierung genutzt werden. Auch ist es üblich, dass Anwender bei der ihrer Ersterfassung eine Kennung bekommen (z.B. Nummer oder selbst erfasster Spitzname), die sich nicht ändert, wenn sich ihre Daten in der Firma ändern (Nachname, Abteilung usw.), oder auch von den dazugehörenden Daten unabhängig sind und durch den Anwender beliebig geändert werden können, wobei innerhalb des Kunden immer nur unikate Kennungen zulässig sind. Der Versuch, einen vorhandenen Spitznamen durch einen anderen Anwender zu bekommen, wird verhindert.

    Um schnell vorwärts zu kommen, sollte ein Berater oder eine Beraterfirma in Anspruch genommen werden, mit der dann gemeinsam die benötigten Konzepte ausgearbeitet werden.

    Die Schilderung der Aufgabenstellung lässt vermuten, dass es ein recht komplexes Projekt werden soll, ähnlich wie ein SharePoint, für den bestimmt mehrere hunderttausend Stunden Entwicklungsleistungen investiert wurden. Deshalb steht die Frage, warum nicht ein solch skalierbares, mandantenfähiges System eingesetzt wird.


    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks
    Kommas richtig setzen!
    Schüler sagen, Lehrer haben es gut.
    Schüler, sagen Lehrer, haben es gut

    • Als Antwort markiert Hipp1010 Donnerstag, 7. Januar 2016 15:22
    Montag, 4. Januar 2016 11:23