|
Navigation: Leitfaden für Administratoren nach der Installation |
Scroll
|
Erste Schritte
Nach Abschluss der Installation finden Sie das installierte VisShare-Verzeichnis im angegebenen Pfad. Zudem laufen vier Dienste:
Name des Dienstes |
Beschreibung / Details |
|---|---|
Kisters Nginx Service |
Der Nginx-Proxy zum Upgrade auf SSL (optional) und zur Weiterleitung des Datenverkehrs an die richtigen Ports für die Anwendung ▪Port 3000 für die Backend-REST-API ▪Port 80 für den VisShare-Client ▪Port 8080 für den WebViewer-Client (Websocket-Unterstützung erforderlich) |
Kisters VisShare Service |
Der Dienst zur Bereitstellung des VisShare-Servers und des Frontends ▪Benötigt Datenbank-Zugriff ▪Benötigt Zugriff auf den Mailserver ▪Benötigt Zugriff auf das Modell-Repository |
Kisters VisShare WebViewer Service |
Der Dienst zur Bereitstellung des WebViewer-Servers und des Frontends ▪Benötigt Zugriff auf das Modell-Repository |
Kisters VisShare Converter Service |
Die automatisierte Konvertierung von Dateien, die in das VisShare-System hochgeladen wurden ▪Benötigt Zugriff auf das Modell-Repository |
Wenn einer dieser Dienste nicht läuft, können Sie einen Fehler erwarten. Um ein reibungsloses Verhalten für den Endbenutzer zu gewährleisten, sollten Sie diese Dienste so einstellen, dass sie bei einem Fehler des Dienstes und beim Neustart des Servers neu gestartet werden (Sie können dies über die Eigenschaften der Windows-Dienste tun).
Eine übliche Vorgehensweise besteht darin, das Modell-Repository vom Standardpfad (innerhalb des VisShare-Installationsordners) zu ändern.
Dazu müssen Sie einige Einstellungen aktualisieren, damit sie auf den neuen Ort verweisen:
Dateiname |
Beschreibung / Details |
|---|---|
VisShare/server/datasources.json |
Ändern Sie den Eintrag root im Abschnitt filestorage auf den neuen Speicherort |
VisShare/server/config/settings.json |
Ändern Sie die Einstellungen DriveName und WVDriveName auf den neuen Speicherort |
VisShare_WebViewer/CRendererInstance.ini |
Ändern Sie die Einstellung ModelRepository auf den neuen Speicherort |
Fehlersuche
Wenn Sie auf Fehler stoßen, gibt es mehrere Verzeichnisse, in denen Sie nach Protokolldateien suchen können:
Speicherort |
Beschreibung / Details |
|---|---|
VisShare-Hauptverzeichnis |
Die Log-Datenerfassung des Setups wird in dieser Datei gespeichert. Hier finden Sie alle Fehler, die bei der Erstinstallation aufgetreten sind |
VisShare_Webviewer/logs |
Der WebViewer schreibt Log-Dateien in die Unterverzeichnisse unterhalb dieses Pfades ▪/server ▪Tägliche Log-Datenerfassung für den WebViewer Server ▪/instance ▪Eine Log-Datei pro Instanz |
VisShare/server/middleware/log |
▪Der VisShare-Server schreibt Log-Dateien in dieses Verzeichnis ▪Eine Datei pro Start des Dienstes |
VisShare_Nginx |
Weitere Informationen zur Fehlerbehebung finden Sie in der offiziellen Nginx-Dokumentation |
VisShare_Converter service |
▪/Log ▪Eine Datei pro Start des Dienstes |
Sicherheitstechnische Hinweise
Dieses Kapitel stellt Ihnen einige sicherheitstechnische Hinweise bereit, die Sie beachten sollten.
Rechte für Dienstkonten
Wir empfehlen Ihnen, die oben genannten Dienste mit speziellen Dienstkonten auszuführen. Sie sollten den Zugriff auf das Modell-Repository und den VisShare-Ordner nur auf dieses Dienstkonto beschränken, so dass andere Benutzer auf den Systemen die Modell- oder Konfigurationsdateien nicht lesen können (in den Konfigurationsdateien befinden sich eindeutige Informationen im Klartext).
Modell-Repository
Auch das Modell-Repository sollte immer gegen den Zugriff von nicht zugelassenen Benutzern/Diensten/Anwendungen gesichert werden. Wenn sich das Modell-Repository außerhalb des VisShare-Serversystems befindet, müssen Sie möglicherweise ein neues Dienstkonto auf dem VisShare-Rechner einrichten, das Zugriff auf das entfernte Modell-Repository hat, und dieses Konto für die VisShare Dienste festlegen.
VisShare-Benutzerzugriff
Der Benutzerzugriff auf VisShare ist in mehrere Layer unterteilt. Bei der Voreinstellung wird versucht, die höchste Sicherheit in Bezug auf die Beschränkung des Benutzerzugriffs zu verwenden.
Die Zugriffskontrolle kann über folgende Layer verwaltet werden:
1.Registrierung
Benutzer-Konten auf VisShare können über eine Registrierung (E-Mail + Passwort) erstellt werden. Es ist möglich, die Art und Weise der Registrierung über Einstellungen zu definieren:
Registrierungsmethode |
Beschreibung / Details |
|---|---|
LDAPOnly |
Wenn diese Einstellung aktiviert ist, sind Registrierungen deaktiviert und nur gültige LDAP-Benutzer können auf VisShare zugreifen |
InviteOnly |
Wenn diese Einstellung aktiv ist, können Registrierungen nur von gültigen Benutzern von VisShare über eine E-Mail-Einladung zu neuen Benutzerkonten ausgelöst werden |
AdminCreationOnly |
Wenn diese Einstellung aktiv ist, sind Registrierungen deaktiviert und nur Administratoren können neue Benutzerkonten erstellen |
2.Zugang zu VisShare selbst
In der Voreinstellung ist VisShare nur mit einem gültigen Login (E-Mail + Passwort) aus einer bestätigten Benutzer-Mail zugänglich (ein neu registrierter Benutzer muss auf einen Bestätigungslink klicken, der an diese E-Mail gesendet wird).
Neue Benutzerkonten können durch folgende Einstellungen weiter eingeschränkt werden:
Beschränkungsgrad |
Beschreibung / Details |
|---|---|
AdminVerification |
Konten müssen von einem Administrator verifiziert werden, bevor sie mit der Arbeit an VisShare beginnen können |
AllowGuests |
Nicht verifizierte Konten können auf öffentliche und Vorzeigeprojekte zugreifen |
Es gibt zwei Möglichkeiten, die Anmeldung zu umgehen. Die erste (und empfohlene) besteht darin, auf Dateiverknüpfungen zuzugreifen, die von VisShare-Benutzern erstellt wurden, und die andere Möglichkeit wäre, Option RemotePublic zu aktivieren.
Dies ermöglicht den Zugriff auf öffentliche Projekte über den Link <Server-URL>/remote-public/<ID des öffentlichen Projekts>. Diese Einstellung sollte nur dann auf true gesetzt werden, wenn diese Art des Zugriffs wirklich erforderlich ist.
3.Benutzer-Pools
Die nächste Ebene des Benutzerzugriffs (oder der Benutzertrennung) sind die Benutzer-Pools. Administratoren sind berechtigt, diese zu erstellen und ihnen Benutzerkonten zuzuordnen.
Benutzerkonten dürfen (z.B. bei der Zuordnung von Benutzern zu einem neuen Projekt) nur andere Benutzer sehen, die sich in einem ihrer Benutzer-Pools befinden. Ein Projekt muss einem Benutzer-Pool zugeordnet werden, um eine Trennung der Benutzer pro Projekt zu erzwingen.
Benutzer-Pools schränken den Zugriff auf die Projekte oder Dateien nicht ein, dies muss auf Projektebene selbst geschehen. Sie dienen lediglich dazu, die sichtbaren Benutzer für normale Konten zu begrenzen.
4.Projektzugriff
Der Projektzugriff sollte als das wichtigste Feature angesehen werden, um den Zugriff auf die wichtigen Daten (die Dateien) zu beschränken. Diese Zugriffsregeln werden auf Projektebene angewendet und auf alle Dateien und Ordner innerhalb des Projekts vererbt.
Projekte können auf einen der folgenden Typen eingestellt werden:
Typ |
Beschreibung / Details |
|---|---|
Öffentlich |
Jeder Benutzer kann dieses Projekt sehen und hat Schreibrechte |
Showcase |
Jeder Benutzer kann dieses Projekt sehen, aber der Schreibzugriff muss von den Projektadministratoren genehmigt werden |
Eingeschränkt |
Nur Benutzer mit mindestens Lesezugriff können dieses Projekt sehen, und der Schreibzugriff muss von den Projektadministratoren genehmigt werden |
Zusätzlich verfügt jedes Projekt über verschiedene Arten von Benutzerrollen für die Benutzer, die auf das Projekt zugreifen können:
Rolle |
Beschreibung / Details |
|---|---|
Projekt-Administratoren |
▪Projektadministratoren dürfen Benutzer zum Projekt hinzufügen und ihnen Rechte erteilen ▪In der Voreinstellung ist der Ersteller des Projekts ein Projektadministrator und der Eigentümer des Projekts |
Schreibzugriff |
▪Diese Benutzer können Dateien und Ordner sehen, ansehen, hochladen, einfügen, kopieren und löschen ▪Diese Benutzer können Dateien und Ordner herunterladen ▪Diese Benutzer können Dateien aus den WebViewer-Sitzungen im Projekt speichern |
Nur Lesezugriff |
Diese Benutzer können nur Dateien und Ordner sehen und anzeigen |
5. Rollen für Benutzerkonten
Es gibt drei Rollen, die einem Benutzerkonto zugewiesen werden können:
Rolle |
Beschreibung / Details |
|---|---|
Gast (falls aktiviert) |
Hat nur Zugang zu öffentlichen und Showcase-Projekten |
Normaler Benutzer |
▪Hat Zugang zu öffentlichen Projekten und Showcase-Projekten ▪Kann neue Projekte erstellen ▪Hat Zugriff auf Projekte, auf die dieses Konto zugreifen darf |
Admins |
▪Gleicher Zugang wie normale Benutzer ▪Kann Benutzer-Pools erstellen und zuweisen ▪Kann das VisShare-Theme ändern ▪Kann/muss neue Benutzer verifizieren (falls aktiviert) ▪Kann Benutzer erstellen, löschen und sperren (=unverifiziert Benutzer) ▪Kann E-Mails bestätigen (falls erforderlich) Beachten Sie: Kann nicht auf alle Projekte zugreifen (es gelten die gleichen Regeln wie für normale Benutzer) |
Es gibt zusätzliche Einstellungen zur Einschränkung von Features (wie z.B. dem Download) auf VisShare. Eine vollständige Liste finden Sie in der Dokumentation der Administrator-Einstellungen.
CSP und weitere HTTP-Header
Es wird empfohlen, einige HTTP-Header-Parameter festzulegen, um die Sicherheit zu verbessern.
Diese Header-Parameter müssen entweder auf dem Proxy-Server oder in der index.html (Installationsverzeichnis/www) eingestellt werden:
Die Proxy-Header haben keinen großen Einfluss auf die Ausführung des VisShare-Dienstes und sind daher in der Standardkonfiguration von Nginx implementiert. Wenn Sie einen anderen Proxy verwenden, wird empfohlen, zumindest die folgenden Header in der Proxy-Konfiguration zu aktivieren:
▪Content-Security-Policy: "frame-ancestors 'self';"
▪Access-Control-Allow-Origin: <VisShare FQN>
Die Kopfzeilen, die in der index.html des Clients gesetzt werden, können sich auf die Ausführung des VisShare-Dienstes auswirken. Sie werden daher hier nur beschrieben und sollten weiter getestet werden, bevor sie in der Live-Installation eingesetzt werden.
Außerdem muss für jede Version ein dynamischer Hash-Wert erzeugt werden. Dieser Header kann von den Entwicklungswerkzeugen des Browsers übernommen werden, nachdem VisShare im Browser geladen wurde (sie wird als fehlender Hash im Tab Konsole protokolliert).
Die folgende Header sollte in einem Meta-Tag in der index.htmlgeschrieben werden:
▪Content-Security-Policy:
▪default-src: 'none'
▪style-src: 'self' 'unsafe-inline'
▪script-src: <version depending SHA hash>
▪img-src: 'self' data:
▪font-src 'self'
▪script-src-elem: 'self' <version depending SHA hash>
▪object-src: 'none'
▪connect-src: 'self'
▪form-action: 'self'
▪base-uri: 'self'
▪worker-src: blob:
▪block-all-mixed-content
Zum Beispiel so:
<meta http-equiv="Content-Security-Policy" content=" default-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'sha256-X+U5Sd/3bd4dCP/omuUcZqp4zoblo0iOYTy3KKqhH2I='; img-src 'self' data:; font-src 'self'; script-src-elem 'self' 'sha256-RtvwbtYK3Z0+zSLo7typSexHqOElemnq3IuFC/AjvsM='; object-src 'none'; connect-src 'self'; form-action 'self'; base-uri 'self'; worker-src blob:; block-all-mixed-content;" > |
