<%NOJS_WARNING%>

KISTERS Logo KISTERS logo

Leitfaden für Administratoren nach der Installation

Scroll PDF

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;"

>

English Version German Version Japanese Version Italian Version French Version Spanish Version Chinese Version File Format list-PDF Admin-PDF