Erste Schritte

Nach Abschluss der Installation finden Sie das installierte VisShare-Verzeichnis im angegebenen Pfad. Zudem laufen vier Dienste:

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:

Fehlersuche

Wenn Sie auf Fehler stoßen, gibt es mehrere Verzeichnisse, in denen Sie nach Protokolldateien suchen können:

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:

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:

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:

Zusätzlich verfügt jedes Projekt über verschiedene Arten von Benutzerrollen für die Benutzer, die auf das Projekt zugreifen können:

5. Rollen für Benutzerkonten

Es gibt drei Rollen, die einem Benutzerkonto zugewiesen werden können:

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: