Bertil Syamken's Blog https://docs.microsoft.com/archive/blogs/bertilsy/feed.xml Wed, 17 Apr 2019 03:39:44 GMT en-US hourly 1 Sicherer Betrieb von SharePoint 2013 - Physische Absicherung https://docs.microsoft.com/archive/blogs/bertilsy/sicherer-betrieb-von-sharepoint-2013-physische-absicherung Tue, 18 Nov 2014 04:52:00 GMT https://blogs.msdn.microsoft.com/bertilsy/2014/11/18/sicherer-betrieb-von-sharepoint-2013-physische-absicherung/ Eine SharePoint Farm besteht aus mehreren Servern mit unterschiedlichen Rollen und Aufgaben, die auf physischer Ebene abzusichern sind.

Diese Beitrag ist Teil einer Reihe von mehreren Blogbeiträgen zu diesem Thema:

Einleitung: Sicherer Betrieb von SharePoint 2013

Teil 1: Logische Absicherung

Teil 2: Physische Absicherung

2.1 Netzwerksicherheit

2.1.1 Überblick

Die Server kommunizieren untereinander und mit der restlichen Infrastruktur über die Netzwerk Ports und nutzen dabei die Netzwerkprotokolle, die in dem folgenden Diagramm dargestellt sind:

NetzwerkPortsNetzwerkprotokolle

Abbildung 3: Netzwerk Ports und Netzwerkprotokolle in einer SharePoint 2013 Farm

Protocol

Port

Usage

Comment

TCP

80

http

Client to SharePoint web server traffic
(SharePoint - Office Web Apps communication)

TCP

443

https/ssl

Encrypted client to SharePoint web server traffic
(Encrypted SharePoint - Office Web Apps communication)

TCP

1433

SQL Server default communication port.

May be configured to use custom port for increased security

TCP

<wählbar>

Der Port für die SQL Server Kommunikation

Wenn die Kommunikation nicht über den Default Port 1433 gehen soll, kann ein anderer Port eingestellt werden.

UDP

1434

SQL Server default port used to establish connection

May be configured to use custom port for increased security

TCP

445

SQL Server using named pipes

When SQL Server is configured to listen for incoming client connections by using named pipes over a NetBIOS session, SQL Server communicates over TCP port 445

TCP

2382

Analysis Services in SharePoint Mode (PowerPivot)

Dieser Port muss in der Firewall freigeschaltet werden, da PowerPivot für SharePoint Server 2013 als eine externe Komponente gilt.

TCP

25

SMTP for e-mail integration

Cannot be configured

TCP

16500-16519

Ports used by the search index component

Intra-farm only
Inbound rule Added to Windows firewall by SharePoint

TCP

22233-22236

Ports required for the AppFabric Caching Service

Distributed Cache…

TCP

808

Windows Communication Foundation communication

WCF

TCP

32843

Communication between Web servers and service applications

http (default) To use custom port, see references section
Inbound rule Added to Windows firewall by SharePoint

TCP

32844

Communication between Web servers and service applications

https
Inbound rule Added to Windows firewall by SharePoint

TCP

32845

net.tcp binding: TCP 32845 (only if a third party has implemented this option for a service application)

Custom Service Applications
Inbound rule Added to Windows firewall by SharePoint

TCP

32846

Microsoft SharePoint Foundation User Code Service (for sandbox solutions)

Inbound on all Web Servers
Inbound rule Added to Windows firewall by SharePoint
Outbound on all Web and App servers with service enabled.

TCP

5725

User Profile Synchronization Service(FIM)

Synchronizing profiles between SharePoint 2013 and Active Directory Domain Services (AD DS) on the server that runs the Forefront Identity Management agent

TCP + UDP

389

User Profile Synchronization Service(FIM)

LDAP Service

TCP + UDP

88

User Profile Synchronization Service(FIM)

Kerberos

TCP + UDP

53

User Profile Synchronization Service(FIM)

DNS

UDP

464

User Profile Service(FIM)

Kerberos change password

TCP

809

Office Web Apps

Intra-farm Office Web Apps communication.

Tabelle 1: SharePoint 2013 Netzwerk Ports und Netzwerkprotokolle

2.1.2 Firewalls und IPSec

Um die Kommunikation innerhalb der Farm effektiv abzusichern, sollen zwischen den einzelnen Servern immer Firewalls aufgesetzt werden und dort nur die notwendigen Netzwerk Ports freigeschaltet werden. Für maximale Sicherheit, insbesondere bei den Extranet Farmen, wo die einzelnen Server aus dem Internet erreichbar sein müssen, sollte das Netzwerk zusätzlich mit Hilfe von IPSec und Network Access and Policies Services (NPAS) abgesichert sein. Das SQL Server Backend unterstützt die Verwendung von IPSec für die Kommunikation mit den SharePoint Servern (siehe https://technet.microsoft.com/en-us/library/ms189067(v=SQL.105).aspx).

Empfehlung

Schalten Sie nur die notwendigen Netzwerk Ports und Netzwerkprotokolle frei und sperren Sie alle anderen Ports, Protokolle und Verbindungen. Verwenden Sie IPSec und MPAS um die Kommunikation zwischen den Rechner in der Farm weiter zu beschränken.

2.1.3 Absicherung des SQL Server Backends

Das SQL Server Backend für eine SharePoint Farm besteht mindestens aus einem Relationalen Datenbank Server, einem Relationalen Datenbank Server Failover Cluster oder einer AlwaysOn Avalailbility Group.

Microsoft SQL Server verwendet standardmäßig die folgenden Netzwerk Ports und Protokolle:

  • TCP 1433 für den Datenaustausch zwischen dem SQL Server und der Anwendung
  • UDP 1434 für den SQL Server-Auflösungsdienst (SQL Server Browser)

Standardmäßig wird auf Clientcomputern, die eine Verbindung mit SQL Server herstellen, zuerst eine Verbindung mithilfe von TCP 1433 hergestellt. Wenn diese Kommunikation nicht erfolgreich ist, fragen die Clientcomputer den UDP 1434 abhörenden SQL Server-Auflösungsdienst ab, um den von der Datenbankinstanz abgehörten Port zu ermitteln. Weitere Informationen dazu finden Sie unter:

Bei den beiden von SQL Server standardmäßig verwendeten Ports handelt es sich um wohlbekannte Ports. Sie werden daher bei Angriffen als erstes ausgetestet. Bei der Angabe des Servers kann auch der konfigurierte Port in der Notation <Server>,<Port> bzw. <Server>\<Instanz>,<Port> angegeben werden. Dadurch kann man auch auf den SQL Server Browser Dienst verzichten, dessen Aufgabe u.a. sonst wäre, das Mapping des eingehenden Verkehrs über den Standard Port 1433 auf die tatsächlichen Ports der SQL Server Instanzen sicherzustellen. Die Notation mit der Portangabe kann auch mit dem Alias Mechanismus kombiniert werden. Daher sieht die Empfehlung für eine Serverfarm vor:

  • Den von der SQL Server Standardinstanz verwendeten Port TCP 1433 neu zuzuweisen und TCP 1433 zu blockieren.
  • Den Port UDP 1434 zu blockieren, um potenzielle Angreifer am Zugreifen auf den SQL Server-Auflösungsdienst zu hindern.
  • Grundsätzlich nur die benannten Instanzen von SQL Server zu verwenden und diesen statische Portnummern zuzuweisen, dabei soll der Standard Port 1433 nicht verwendet werden.
  • Auf allen Servern in der Farm, die eine Verbindung mit dem SQL Server herstellen, einen SQL Server Client Alias konfigurieren, der den TCP-Port mit angibt, der von der benannten SQL Server Instanz abgehört wird.

Empfehlung

Blockieren Sie die SQL Server Standard Ports TCP 1433 und UDP 1434 und leiten Sie die Kommunikation zwischen den Servern in der Farm und dem SQL Server auf andere Ports um.

Je nach Farmkonfiguration kommen gegebenenfalls Analysis Services Server (PowerPivot Engine) und Reporting Services (SharePoint Modus) Instanzen hinzu. Für diese Dienste müssen ebenfalls die notwendigen Ports freigeschaltet sein und die Kommunikationskanäle abgesichert sein.

Für den Zugriff auf Analysis Services muss der Port 2382 freigeschaltet werden, da SharePoint Server 2013 die PowerPivot Engine als eine externe Komponente nutzt. Siehe hierzu:

Für die Reporting Services gelten die selben Anforderungen und Konfigurationsmöglichkeiten wie für die übrigen SharePoint Farm Komponenten.

2.1.4 Weiterführende Informationen

Weiterführende Informationen zu diesem Thema finden Sie unter den folgenden Links:

2.2 Sicherheit von Dienstanwendungen

2.2.1 Kommunikation zwischen Dienstanwendungen

Standardmäßig findet die Kommunikation zwischen Webservern und Dienstanwendungen in einer Farm über HTTP mit einer Bindung an TCP Port 32843 statt. Beim Veröffentlichen einer Dienstanwendung können Sie entweder HTTP oder HTTPS mit folgenden Bindungen auswählen:

  • HTTP-Bindung: TCP 32843
  • HTTPS-Bindung: TCP 32844

Daneben können Drittanbieter, die Dienstanwendungen entwickeln, eine dritte Möglichkeit implementieren:

  • net.tcp-Bindung: TCP 32845

In einer produktiven Farm sollte unbedingt die Kommunikation zwischen den Dienstanwendungen immer über HTTPS konfiguriert werden. Eigenentwickelte Dienstanwendungen können auch die net.tcp Bindung über den Port 32845 verwenden, sollten dabei allerdings die Nachrichten entsprechend verschlüsseln.

Sie können die Protokoll- und Portbindung für jede Dienstanwendung ändern. Wählen Sie auf der Seite Dienstanwendungen in der Zentraladministration die Dienstanwendung aus, und klicken Sie dann auf Veröffentlichen.

Die HTTP/HTTPS/net.tcp-Bindungen können auch mit den PowerShell-Cmdlets "Get-SPServiceHostConfig" und "Set-SPServiceHostConfig" angezeigt und geändert werden.

Empfehlung

Konfigurieren Sie die HTTPS Verbindung bei allen Dienstanwendungen in der Farm.

2.2.2 Benutzerprofildienst

Die Benutzerprofildienst-Anwendung synchronisiert mithilfe des Verwaltungs-Agents für Forefront Identity Manager Profile zwischen SharePoint 2013 und Active Directory oder einem LDAP-Verzeichnisdienst (Lightweight Directory Access-Protokoll). Der Verwaltungs-Agent für Forefront Identity Manager wird auf allen Servern in einer SharePoint-Farm installiert, ist jedoch nur auf dem Server erforderlich, der für die Synchronisierung mit dem Verzeichnisspeicher eingerichtet wurde.

Der Verwaltungs-Agent für Forefront Identity Manager enthält die folgenden beiden Dienste, die auf dem Server aktiviert bleiben müssen, der für die Durchforstung von Active Directory oder eines anderen Verzeichnisspeichers eingerichtet wurde:

  • Forefront Identity Manager-Dienst
  • Forefront Identity Manager-Synchronisierungsdienst

Zudem muss TCP 5725 auf dem Server geöffnet sein, auf dem der Verwaltungs-Agent für Forefront Identity Manager ausgeführt wird und der für die Durchforstung eines Verzeichnisspeichers eingerichtet wurde.

In Active Directory-Umgebungen müssen die folgenden Ports für die Kommunikation zwischen dem Server mit SharePoint 2013, der die Synchronisierung mit dem Verzeichnisspeicher ausführt, und dem Server, auf dem Active Directory ausgeführt wird, geöffnet sein:

  • TCP und UDP 389 (LDAP-Dienst)
  • TCP und UDP 88 (Kerberos)
  • TCP und UDP 53 (DNS)
  • UDP 464 (Kerberos - Kennwort ändern)

Weitere Informationen zu Anforderungen für das Verstärken der Sicherheit des Verwaltungs-Agents für Forefront Identity Manager und Portanforderungen für andere Verzeichnistypen finden Sie unter Ports, Rechte und Berechtigungen für die Kommunikation mit Verwaltungs-Agents (https://go.microsoft.com/fwlink/p/?LinkId=186832).

Empfehlung

Starten Sie die Forefront Identity Manager Dienste nur auf dem Server, der für die Synchronisierung mit dem Verzeichnisspeicher eingerichtet wurde. Schalten Sie nur auf diesem Server die Ports für die Kommunikation mit dem Verzeichnisspeicher frei.

Ein weiterer Punkt bezüglich des Benutzerprofildienstes sind die Profilattribute, die aus dem externen Verzeichnisspeicher (AD, LDAP, …) in SharePoint importiert werden. Achten Sie dabei nur die Attribute zu importieren, die für den Betrieb vom SharePoint und Custom Lösungen notwendig sind. Die Attribute, die verwendet werden aber aus Datenschutzgründen nicht für alle sichtbar sein dürfen, müssen ihre Sichtbarkeit auf "Nur Ich" konfiguriert haben, so dass sie nur der Benutzer selbst ansehen und ggf. bearbeiten kann.

Empfehlung

Importieren Sie nur die Benutzerattribute aus dem Verzeichnisspeicher die Sie im SharePoint benötigen. Stellen Sie die Sichtbarkeit der Attribute die sensible Benutzerinformationen beinhalten auf "Nur Ich" damit sie von anderen Benutzern nicht angesehen werden können.

2.2.3 Verbindungen mit externen Servern

Verschiedene Features von SharePoint Server 2013 können für den Zugriff auf Daten konfiguriert werden, die sich auf Servern außerhalb der Serverfarm befinden. Wenn Sie den Zugriff auf Daten auf externen Servercomputern konfigurieren, sollten Sie sicherstellen, dass die Kommunikation zwischen den entsprechenden Computern aktiviert ist. In den meisten Fällen sind die verwendeten Ports, Protokolle und Dienste von der externen Ressource abhängig. Zum Beispiel:

  • Für Verbindungen mit Dateifreigaben wird der Datei- und Druckerfreigabedienst verwendet.
  • Bei Verbindungen mit externen SQL Server-Datenbanken werden die standardmäßigen oder angepassten Ports für die SQL Server-Kommunikation verwendet. Eine Verschlüsselung der Kommunikation per SSL wird hier empfohlen (siehe unten).
  • Für die Verbindungen mit externen Analysis Services Instanzen - Multidimensionale Engine oder Tabular Engine - werden die jeweiligen Ports genutzt, die für die Kommunikation konfiguriert worden sind. Die Kommunikation dabei ist verschlüsselt.
  • Für Verbindungen mit externen Reporting Services Instanzen greifen ebenfalls die dort konfigurierten Ports. Eine Verschlüsselung der Kommunikation per SSL wird hier empfohlen (siehe unten).
  • Für Verbindungen mit Oracle-Datenbanken wird normalerweise OLE DB verwendet.
  • Für Verbindungen mit Webdiensten werden sowohl HTTP als auch HTTPS verwendet.

In der folgenden Tabelle sind die Features aufgeführt, die für den Zugriff auf Daten, die sich auf Servercomputern außerhalb der Serverfarm befinden, konfiguriert werden können:

Feature

Beschreibung

Inhaltscrawling

Sie können Durchforstungsregeln für das Durchforsten von Daten auf externen Ressourcen, wie Websites, Dateifreigaben, öffentlichen Exchange-Ordnern und Branchenanwendungen, konfigurieren. Beim Durchforsten externer Datenquellen kommuniziert die Durchforstungsrolle direkt mit diesen externen Ressourcen.

Weitere Informationen finden Sie unter Verwalten der Durchforstung in SharePoint 2013.

Business Data Connectivity-Verbindungen

Webserver und Anwendungsserver kommunizieren direkt mit Computern, die für Business Data Connectivity-Verbindungen konfiguriert sind.

Weitere Informationen finden Sie unter Planen von Business Connectivity Services in SharePoint 2013.

Empfangen von Microsoft Office Excel-Arbeitsblättern

Wenn Arbeitsmappen, die in der Excel Services-Anwendung geöffnet sind, eine Verbindung mit einer externen Datenquelle (z. B. Analysis Services und SQL Server) herstellen, müssen geeignete TCP/IP-Ports zum Verbinden mit dieser externen Datenquelle geöffnet werden. Weitere Informationen finden Sie unter Übersicht über Excel Services in SharePoint Server 2013.

Wenn UNC-Pfade (Universal Naming Convention) in der Excel Services-Anwendung als vertrauenswürdige Websites konfiguriert sind, verwendet die Anwendungsrolle Dienste für Excel-Berechnungen die Protokolle und Ports des Datei- und Druckerfreigabediensts zum Empfangen von Office Excel-Arbeitsmappen über einen UNC-Pfad.

Arbeitsmappen, die in Inhaltsdatenbanken gespeichert sind oder durch Benutzer auf Websites hochgeladen bzw. von Websites heruntergeladen werden, sind von dieser Kommunikation nicht betroffen.

Tabelle 2: SharePoint 2013 mit Verbindungen zu externen Servern

2.2.4 E-Mail Integration

Für die E-Mail-Integration ist die Verwendung von zwei Diensten erforderlich:

Dienst

Beschreibung

SMTP-Dienst

Für die E-Mail-Integration muss auf mindestens einem der Front-End-Webserver in der Serverfarm der SMTP-Dienst (Simple Mail Transfer-Protokoll) verwendet werden. Der SMTP-Dienst ist für die eingehende E-Mail-Kommunikation erforderlich. Für ausgehende E-Mail-Nachrichten können Sie entweder den SMTP-Dienst verwenden oder die Nachrichten über einen dedizierten E-Mail-Server in Ihrem Unternehmen weiterleiten, z. B. einen Computer mit Microsoft Exchange Server.

Microsoft SharePoint-Verzeichnisverwaltungsdienst

SharePoint 2013 umfasst einen internen Dienst, den Microsoft SharePoint-Verzeichnisverwaltungsdienst, zum Erstellen von E-Mail-Verteilergruppen. Wenn Sie die E-Mail-Integration konfigurieren, haben Sie die Möglichkeit zur Aktivierung des Verzeichnisverwaltungsdienst-Features, mit dem Benutzer Verteilerlisten erstellen können. Wenn Benutzer eine SharePoint-Gruppe erstellen und die Option zum Erstellen einer Verteilerliste auswählen, erstellt der Microsoft SharePoint-Verzeichnisverwaltungsdienst die entsprechende Active Directory-Verteilerliste in der Active Directory-Umgebung.

In Umgebungen mit verstärkter Sicherheit wird empfohlen, den Zugriff auf den Microsoft SharePoint-Verzeichnisverwaltungsdienst durch Schützen der diesem Dienst zugeordneten Datei, SharePointEmailws.asmx, einzuschränken. Lassen Sie beispielsweise den Zugriff auf diese Datei nur für das Serverfarmkonto zu.

Darüber hinaus sind für diesen Dienst Berechtigungen in der Active Directory-Umgebung erforderlich, um Active Directory-Verteilerlistenobjekte zu erstellen. Es wird empfohlen, eine separate Organisationseinheit (OU) für Objekte der SharePoint 2013 in Active Directory einzurichten. Nur diese Organisationseinheit sollte Schreibzugriff auf das vom Microsoft SharePoint-Verzeichnisverwaltungsdienst verwendete Konto gewähren.

Tabelle 3: Dienste für die E-Mail Integration

2.2.5 Dienstanforderungen für den Sitzungsstatus

Sowohl Project Server 2013 als auch InfoPath Forms Services behalten den Sitzungsstatus bei. Wenn Sie diese Features oder Produkte innerhalb der Serverfarm bereitstellen, sollten Sie den ASP.NET-Statusdienst nicht deaktivieren. Wenn Sie InfoPath Forms Services bereitstellen, sollten Sie den Dienst Ansichtstatus ebenfalls nicht deaktivieren.

2.2.6 Inhaltscrawling

Die SharePoint Suche indiziert die Daten in allen konfigurierten Inhaltsquellen, z.B. SharePoint Seiten, File Shares, externe Datenbanken usw. Das Konto, das vom SharePoint 2013-Suchdienst standardmäßig zum Durchforsten aller Inhaltsquellen verwendet wird, wird als Standardkonto für den Inhaltszugriff bezeichnet und muss mindestens lesend auf alle Inhaltsquellen zugreifen können. Sollte der Angreifer dieses Konto kompromittieren, könnte er darüber lesend auf alle Daten in allen Inhaltsquellen zugreifen. Deswegen empfehlen wir für jede Inhaltsquelle ein anders Konto für den Inhaltszugriff beim Durchforsten zu verwenden.

Empfehlung

Beim Durchforsten der Inhaltsquellen verwenden Sie für den Zugriff auf jede Inhaltsquelle ein eigenes Konto und geben Sie diesem Konto nur lesenden Zugriff auf die jeweilige Inhaltsquelle.

2.2.7 Secure Store Dienst

Der Secure Store Dienst ermöglicht das einmalige Anmelden ("Single Sign-On") beim Zugriff auf externe Datenquellen aus z.B. Excel Services oder BCS Modellen. Dabei werden die SharePoint Benutzerkonten beim Zugriff auf eine externe Datenquelle in ein anderes Konto passend zu der Datenquelle umgewandelt. Die Umwandlung von SharePoint Benutzeridentitäten wird häufig so konfiguriert, dass alle SharePoint Benutzerkonten auf ein einziges technisches Dienstkonto gemappt werden. In diesem Szenario finden alle Zugriffe auf die externe Datenquelle immer unter demselben Dienstkonto statt, unabhängig davon, welcher Benutzer am SharePoint angemeldet ist. Um alle Anwendungsszenarien zu erfüllen, werden so einem Dienstkonto in der Regel sehr hohe Berechtigungen in der externen Datenquelle zugeteilt, so dass es meistens alle Daten lesen und ändern kann. Das vereinfacht zwar den Betrieb, kann jedoch dazu führen, dass manche SharePoint Benutzer durch Fehler in der Anwendung oder Konfiguration mehr Zugriffsrechte auf die externen Datenquellen bekommen als sie sollen. Wir empfehlen deswegen beim Mapping von Benutzerkonten im Secure Store Dienst so zu konfigurieren, dass kein SharePoint Benutzer mehr Zugriffsrechte auf die externe Datenquelle bekommen kann als es soll. Im Idealfall soll jeder SharePoint Benutzer zu einem anderen Benutzer in der externen Datenquelle gemappt werden (1:1). Wenn das nicht möglich ist, sollen mehrere Dienstkonten mit unterschiedlichen Berechtigungen in der externen Datenquell verwendet werden und die SharePoint Benutzer - je nach Anwendungsszenario - zu dem für ihre Rolle passenden Dienstkonto gemappt werden.

Empfehlung

Wenn Sie den Secure Store Dienst für die Umwandlung von Benutzerkonten beim Zugriff auf externe Datenquellen verwenden, konfigurieren Sie das Mapping von Benutzerkonten so, dass jeder SharePoint Benutzer nur die Daten aus der externen Datenquelle sehen und bearbeiten kann auf die er auch außerhalb vom SharePoint Anwendungskontext berechtigt ist.

Bevor Sie Secure Store Service verwenden, müssen Sie einen Verschlüsselungsschlüssel generieren. Der Schlüssel dient zum Verschlüsseln und Entschlüsseln der Anmeldeinformationen, die in der Datenbank für einmaliges Anmelden gespeichert werden.

Empfehlung

Sichern Sie den Verschlüsselungsschlüssel für den Secure Store Dienst und geben Sie ihn nicht weiter, da mit diesem Schlüssel alle Passwörter in der Secure Store Dienstdatenbank verschlüsselt werden. Behandeln Sie diesen Schlüssel wie die Passwörter für die Dienstkonten und ändern Sie ihn in regelmäßigen Zeitabständen.

Mehr Info zur Konfiguration des Secure Store Dienstes finden Sie unter https://technet.microsoft.com/de-de/library/ee806866%28v=office.15%29.aspx

2.3 Sicherheit der Farm und Webanwendungen

2.3.1 Authentifizierung und Autorisierung

Die Authentifizierung ist ein Vorgang in welchem die Benutzeridentität von einem vertraulichen Referenzsystem überprüft und bestätigt wird. Die Autorisierung ist der komplementäre Prozess der nach einer erfolgreichen Authentifizierung stattfindet, die bestätigte Benutzeridentität entgegen nimmt und dieser Identität Berechtigungen für den Zugriff auf SharePoint Ressourcen erteilt oder verweigert.

Beim SharePoint 2013 gibt es drei unterschiedlichen Authentifizierungsszenarien:

  • Benutzerauthentifizierung: Findet statt, wenn ein Benutzer auf eine Ressource innerhalb des SharePoints zugreift .
  • App Authentifizierung: Findet statt, wenn eine SharePoint App auf eine Ressource innerhalb des SharePoints zugreift.
  • S2S Authentifizierung: Wird sowohl bei bestimmten Arten von SharePoint Apps verwendet, als auch bei der Kommunikation zwischen den SharePoint Servern und den Servern, auf welchen Lync, Exchange, Workflow Manager oder Office Web Apps laufen.

SharePoint verwendet für die Benutzerauthentifizierung externe Authentifizierungsanbieter wie Active Directory (AD), ADFS, Azure Access Control, usw. Je nach Konfiguration kann eine Webanwendung mehrere Zugriffs-URLs ("Zonen") haben und jede Zone kann einen oder mehrere unterschiedliche Authentifizierungsanbieter unterstützen:

  • Windows-Authentifizierung: Hier stehen NTLM, Kerberos und Basisauthentifizierung als Unteroptionen zur Verfügung
  • Formularbasierte Authentifizierung
  • Vertrauenswürdiger Identitätsanbieter: Hier können beliebige externe Identitätsanbieter wie ADFS, Site Minder usw. konfiguriert werden.

Empfehlung

Bei der Auswahl von Windows Authentifizierung sollte man die Option Kerberos wählen. Mehr über Kerberos Authentifizierung im SharePoint 2013 finden Sie unter https://technet.microsoft.com/de-de/library/ee806870(v=office.15).aspx.

Warnung

Falls Sie Drittherstellerlösungen verwenden, die eigenentwickelte Mitgliedschaftsanbieter für die Formularbasierte Authentifizierung oder eigenentwickelte Identitätsanbieter installieren, versichern Sie sich, dass diese Ihren Sicherheitsstandards entsprechen. Vereinbaren Sie einen Code Review und stellen Sie sicher, dass keine vertraulichen Benutzerinformationen protokoliert oder anderweitig missbraucht werden.

Weiterführende Informationen: Weitere Information zur Planung der Authentifizierung im SharePoint 2013 finden Sie unter https://technet.microsoft.com/de-de/library/ee794879%28v=office.15%29.aspx.

2.3.2 Benutzerrichtlinien

Benutzerrichtlinien auf der Webanwendungsebene werden verwendet, um den Zugriff auf alle Webseitensammlungen innerhalb einer Webanwendung von einer zentralen Stelle aus zu verwalten. Zugleich sind die Webanwendung-Benutzerrichtlinien die einzige Möglichkeit den Zugriff für bestimmte Benutzer oder Benutzergruppen auf die Inhalte einer Webanwendung explizit zu sperren, bestimmten technischen Konten (z.B. Suche) den Zugriff auf alle Inhalte explizit zu erlauben und/oder ihnen die hohen System Account Berechtigungen zu erteilen. Die Sicherheitseinstellungen, die über die Benutzerrichtlinien konfiguriert werden überschreiben die Sicherheitseinstellungen auf der Webseitensammlungs- und Webseitenebene und können von Webseitensammlungs- und Webseitenadministratoren weder angesehen, noch geändert werden.

Vorsicht

Verwenden Sie die Benutzerrichtlinien mit Vorsicht und stellen Sie sicher, dass alle Änderungen an den Benutzerrichtlinien protokolliert und nur nach einer Genehmigung geändert werden dürfen.

2.3.3 Antivirensoftware

Die Server der SharePoint Farm sollten wie Desktop Clients mittels Antivirensoftware zusätzlich abgesichert werden. Allerdings sollte diese nicht mit den Standard Policies/Profilen betrieben werden, wie sie für die Desktop Clients in den meisten Unternehmen eingestellt sind. Dadurch können sich in der Regel Konflikte ergeben, die zu Performanceeinbußen und Instabilität führen können. Für die SharePoint Server Dienste sind die Vorgaben und Ausnahmen ausführlich dokumentiert, um genau solche Effekte zu vermeiden ohne auf einen Schutz verzichten zu müssen:

2.3.4 SSL

Um "Man in the middle" Angriffe zu verhindern, sollten alle Webanwendungen in der SharePoint Farm grundsätzlich für den Zugriff über SSL (https) konfiguriert werden. Insbesondere gilt das für:

  • Die Zentraladministration, weil dort viele sensitive Informationen (die Dienstkontenpasswörter, die Datenbanknamen usw. ) vom Browser zum Server übermittelt werden und auf dem Weg abgehört werden könnten.
  • Die Seiten in einer Webanwendung, die die Formularbasierte Authentifizierung verwendet. Bei solchen Webanwendungen melden sich die Benutzer an, in dem sie ihre Benutzernamen und Passwörter an SharePoint senden. Diese Informationen könnten ohne SSL problemlos abgehört werden
  • Office Web Apps: Diese laden ein Dokument vom SharePoint zum Office Web Apps Server, konvertieren das Dokument in HTML und JSON und schicken diese als Klartext zurück zum Browser um das Dokument anzuzeigen. Um zu verhindern, dass der Inhalt von Dokumenten, die mithilfe von Office Web Apps im Browser angezeigt werden, von Dritten abgehört werden, sollte unbedingt die Kommunikation mit dem Office Web App Server und zwischen dem Office Web App und dem SharePoint Server immer über SSL stattfinden.
  • Server, die die SharePoint Apps hosten: SharePoint Apps verwenden das OAuth 2.0 Protokoll, um sich am SharePoint anzumelden und übermitteln die Anmeldedaten als Access Tokens im http Header als Base64 Encoded Text. Deswegen sollte diese Kommunikation immer über SSL gesichert werden.

2.3.5 Dienstkonten

Alle Dienste in einer SharePoint Farm laufen unter speziellen Dienstkonten, die für den normalen Betrieb Zugriffsberechtigungen auf die Server in der Farm, Active Directory, Netzwerk oder Datenbanken brauchen. Die detaillierte Auflistung aller Dienstkonten in einer SharePoint 2013 Farm und den Berechtigungen die sie benötigen finden Sie unter https://technet.microsoft.com/de-de/library/cc263445%28v=office.15%29.aspx.

Um die Sicherheit der SharePoint Farm zu erhöhen, sollten die Passwörter für die Dienstkonten vom SharePoint automatisch verwaltet und regelmäßig geändert werden. Die Informationen und Best Practices zu diesem Thema finden Sie unter https://technet.microsoft.com/de-DE/library/ff724278%28v=office.15%29.aspx,

In besonderes sicheren Umgebungen empfiehlt es sich den Dienstkonten bestimmte Berechtigungen, die sie normalerweise haben, bewusst zu entnehmen und nur bei Bedarf und temporär wieder zu erteilen. Damit kann bspw. verhindert werden, dass neue SharePoint Seiten angelegt werden, Datenbanken oder Seiten aus einem Backup wiederhergestellt werden usw. Die Informationen dazu finden Sie unter https://technet.microsoft.com/de-DE/library/hh377944%28v=office.15%29.aspx und unter https://blogs.msdn.com/b/briangre/archive/2013/02/20/least-privilege-configuration-for-windows-azure-workflow-with-sharepoint-2013.aspx.

2.4 Sicherheit des SQL Server Backends

Die grundlegenden Regelungen und Empfehlungen bezogen auf die übrigen Server einer SharePoint Farm gelten ebenso für das SQL Server Backend. Darüber hinaus gibt es spezifische Anforderungen, die eine gesonderte Betrachtung erforderlich machen, weil hier der State einer SharePoint Farm zusammenläuft, den es zu schützen gilt.

Das impliziert, dass der physikalische Zugriff auf die Server, das Storage System und der Ort für die Backup Medien kontrolliert und abgesichert ist. Es ist auch eine Grundannahme für eine Common Criteria zertifizierte Lösung ist, dass der physikalische Zugriff auf die Server des SQL Server Backends abgesichert ist (siehe Assumption A.PHYSICAL). Grundsätzliche Empfehlungen finden Sie hier:

Checkliste

Database Engine Security Configuration (https://msdn.microsoft.com/en-us/library/ff848786(v=sql.105).aspx)

2.4.1 Authentifizierung und Autorisierung

SQL Server unterstützt neben der Windows Integrated Security noch ein weiteres Authentifizierungsverfahren mittels Benutzer/Passwort Kombination. Es wird empfohlen, die Datenbankserver so zu konfigurieren, dass sie Windows Integrated Security als alleiniges Verfahren unterstützen. Somit entfällt zwangsläufig die Notwendigkeit Benutzer/Password Kombinationen in der Konfiguration hinterlegen zu müssen. Und die Accounts können zentral im AD kontrolliert und verwaltet werden. Sollte die SQL Server Authentifizierung zusätzlich unterstützt werden (Mixed Authentification), so sollten unbedingt die Passwort Policies vom Active Directory (AD) für die Logins aktiviert werden, damit sichergestellt ist, dass die Passwörter dieselben Komplexitätsanforderungen und Gültigkeitsregeln erfüllen müssen wie sie für das übrige Firmennetzwerk gelten.

Die SQL Server Analysis Services (PowerPivot) unterstützt ausschließlich Windows Integrated Security. Ebenso unterstützen die SQL Server Reporting Services (SharePoint Modus) nur Windows Integrated Security.

Empfehlung

Aktivieren Sie beim SQL Server im Zusammenhang mit SharePoint als Authentifizierung nur Windows Integrated. Aktivieren Sie unbedingt die Password Policies für alle SQL Server Logins, wenn Sie Mixed Authentification nutzen müssen.

Das Standard Login sa existiert zunächst in jeder SQL Server Installation. Da es sich um einen wohlbekannten Account handelt, wird er zu Beginn eines jeden Angriffsversuches ausgetestet. Daher sollte er für Systeme aller Schutzklassen umbenannt werden und deaktiviert werden. Ist SQL Server Authentifizierung freigeschaltet (Mixed Authentification), sollte jedes SQL Server Login, das Mitglied der sysadmins Rolle ist, unbedingt mit einem komplexen Passwort versehen werden.

Empfehlung

Deaktivieren Sie im SQL Server das sa Login.

Alle SQL Server Services (Relationale Engine, Analysis Services, Reporting Services) unterstützen Kerberos Constraint Delegation (KDC). Wird der Empfehlung gefolgt, Kerberos Authentifizierung in SharePoint zu verwenden, so muss SQL Server für die Unterstützung von Kerberos konfiguriert werden. Details dazu, welche Voraussetzungen erfüllt werden müssen und was insbesondere in einer Failover Cluster Konfiguration zu berücksichtigen ist, finden Sie hier:

Die Analysis Services (PowerPivot) Engine funktioniert ohne Kerberos Authentifizierung im Kontext einer SharePoint Farm, weshalb eine zusätzliche Konfiguration entfällt. Werden von der SharePoint Farm, die Kerberos nutzt, aus aber auf externe Analysis Services Instanzen zugegriffen, so müssen diese entsprechend konfiguriert werden. Was hier zu beachten ist, ist hier beschrieben:

Die Reporting Services unterstützen ebenfalls Kerberos. Was zu berücksichtigen ist und wie die Konfiguration durchzuführen ist, finden Sie hier beschrieben:

Checkliste

Limiting Access to Data (https://msdn.microsoft.com/en-us/library/ff848752(v=sql.105).aspx)

2.4.2 Verschlüsselung

Die Möglichkeit, Daten zu verschlüsseln, dient in der Regel als letzte Barriere bei einem möglichen ungewollten Zugriff auf die Daten.

Auf Volume Ebene kann BitLocker Drive Encryption eingesetzt werden. Bitlocker ist ein Verschlüsselungsfeature, das bei den Server Betriebssystemen ab Windows Server 2008 zur Verfügung steht. Dieses Feature kann hierbei zum Schutz gegen Offline Angriffe auf den Storage des SQL Server Backends genutzt werden. Das heißt, wenn der Server ausgeschaltet ist, ist das Volume gesperrt und verschlüsselt. Sobald der Server gestartet ist, ist das Volume entsperrt, bleibt aber verschlüsselt. Die Vorteile sind die Einfachheit der Administration, Abstraktion des Schlüsselmanagements und die Transparenz bei der Nutzung. Die Nachteile dagegen sind, dass der Einsatz von Bitlocker einen negativen Einfluss auf die Latenz hat und nur das Volume umfasst. Wenn man also Backups oder Datenbankfiles von diesem Volume auf ein nicht verschlüsseltes Volume überträgt, geht der Schutz durch die Verschlüsselung systematisch verloren. Dadurch, dass es das Volume umfasst, bleiben die Inhalte aller Datenbankdateien und Backups prinzipiell lesbar, sofern man den Zugriff auf das Volume erlangen kann.

Aus der Notwendigkeit heraus, sich mittels Backups gegen Datenverlust absichern zu müssen, ergibt sich immer ein möglicher Angriffspunkt, wenn die Backups ausgelagert werden, wenn sie weniger gut abgesichert sind als die eigentlichen Datenbankdateien oder auch von einem größeren Nutzerkreis gehandhabt werden müssen als den der Datenbankadministratoren. Um sicherzugehen, dass die erzeugten Backups der SharePoint Server Datenbanken auch dann nicht ausgelesen werden können, wenn sie in die falschen Hände geraten, sollten sie unbedingt verschlüsselt abgespeichert werden. Dies ist über den SQL Server Backup Mechanismus möglich, wobei auf die folgenden Algorithmen zurückgegriffen werden kann: AES 128, AES 192, AES 256 und Triple DES. Die Backup Encryption umfasst auch die Inhalte, die per FILESTREAM abgelegt sind. Die Backup Encryption wird ab der Standard Edition ab SQL Server 2014 unterstützt. Weitere Informationen dazu:

Die Notwendigkeit für Backups entfällt für die Analysis Services Datenbanken in einer PowerPivot Instanz, da diese lediglich Kopien von Inhalten aus Excel Workbooks sind, die in der Content Datenbank abgelegt sind. SharePoint kontrolliert intern das Anhängen und Abhängen der Datenbanken (Attach/Detach). Alle anderen Analysis Services Engines (Multidimensional, Tabular) außerhalb des SharePoint Kontextes unterstützen Backup Encryption. Siehe hierzu:

Die Datenbanken von Reporting Services (SharePoint Modus) enthalten in verschlüsselter Form Verbindungskonfigurationen für den Zugriff auf die diversen Datenquellen. Diese Encryption Keys müssen unbedingt ebenso wie die Datenbanken selber gesichert werden. Dies geschieht ab Reporting Services 2012 über die SharePoint PowerShell CMDLETs Update-SPRSEncryptionKey, Restore-SPRSEncryptionKey und Backup-SPRSEncryptionKey (siehe: https://msdn.microsoft.com/en-us/library/gg492249.aspx).

Empfehlung

Sichern Sie unbedingt die Encryption Keys für Reporting Services und bewahren Sie diese getrennt von den Backups der SharePoint Datenbanken auf.

Während die Backup Verschlüsselung ausschließlich die erzeugten Backup Dateien verschlüsselt und die Datenbankdateien selber unverschlüsselt im Storage vorliegen, stellt die Transparent Data Encryption (TDE) sicher, dass die Datenbank permanent verschlüsselt im Storage vorliegt. Damit kann man sich dagegen absichern, dass jemand, der sich einen physischen Zugriff auf die Datenbankdateien oder deren Backups verschaffen konnte, diese auch lesen kann.

Die TDE kann für alle SharePoint Datenbanken aktiviert werden. Die Datenbankdateien werden dann mit einem symmetrischen Schlüssel (Database Encryption Key), der mit Hilfe eines Zertifikates abgesichert wird, verschlüsselt. Die Datenbank bleibt aber weiterhin im SQL Server Prozess unverschlüsselt und man kann über die SQL Server APIs jederzeit abgefragt werden. Sobald eine Datenbank in einer SQL Server Instanz per TDE verschlüsselt wird, wird automatisch auch die tempdb mit verschlüsselt, um sicherzugehen, dass auch Zwischenergebnisse nicht unverschlüsselt im Storage landen. Die TDE kann noch zusätzlich mit einem Extensible Key Management (EKM) kombiniert werden, um auch noch die Zertifikate und deren Management physisch vom SQL Server trennen zu können. Weitere Informationen dazu finden Sie unter:

Die Nutzung von TDE im Zusammenhang hat seine Grenzen hinsichtlich Verschlüsselung, da die transparente Verschlüsselung nicht die per FILESTREAM abgelegten Daten umfasst. Davon betroffen wäre die Remote Blob Storage (RBS) Unterstützung in SharePoint, die aus diesen Gründen nicht für sensitive Daten genutzt werden sollte, bei denen man auf die Verschlüsselung im Storage angewiesen ist. Darüber hinaus konterkariert der Einsatz von TDE die effektive Nutzung von Kompression innerhalb der Datenbank und beim Backup, weswegen beides in Kombination mit TDE lediglich Ressourcen verschwendet. Der Zugewinn an Sicherheit geht einher mit einem höheren Storage Bedarf für die Datenbankdateien und die Backups. Ebenso greift nicht die Instant File Initialization bei per TDE verschlüsselte Datenbanken. Die Zertifikate und Schlüssel müssen mit gesichert werden, sonst lassen sich die Datenbanken im Desaster Recovery (DR) Fall nicht wiederherstellen oder auf eine andere Datenbank Server Instanz spiegeln. Sie müssen aber unbedingt getrennt von den Backups gelagert werden. Weitere Informationen zum Umgang mit den Schlüsseln finden Sie hier:

Empfehlung

Verschlüsseln Sie die SharePoint Datenbanken, die Daten mit High Business Impact enthalten, per Transparent Data Encryption (TDE). Nutzen Sie Backup Encryption, wenn Sie die SharePoint Datenbanken nicht per TDE absichern können.

TDE und Bitlocker bieten nur einen Schutz gegen Offline Angriffe. Beide Mechanismen hängen vom Mechanismus der Zugriffskontrolle ab, bei Bitlocker die Windows File Berechtigungen und bei TDE die Datenbank Berechtigungen.

2.4.3 Verschlüsselung der SQL Server Kommunikation

Die Kommunikation zwischen den SharePoint Servern einer Farm und dem Relationalen SQL Server Backend kann zusätzlich per SSL Verschlüsselung abgesichert werden. SQL Server bietet diese Art der Verschlüsselung mit Hilfe von Zertifikaten an, die man auf dem Server einrichten und aktivieren kann. Weitere Informationen dazu finden Sie unter:

Empfehlung

Verschlüsseln Sie die Kommunikation zwischen SharePoint Servern und SQL Server per SSL.

Die Kommunikation zwischen den SharePoint Servern einer Farm oder einer Client Anwendung und der Analysis Services Engine ist standardmäßig verschlüsselt.

Für die Kommunikation mit den Reporting Services im SharePoint Modus greift die SSL Konfiguration, wie sie auf Ebene von SharePoint konfiguriert ist, sodass die Kommunikation verschlüsselt wird. Eine Reporting Services Instanz (Native Mode), auf die von der Farm aus zugegriffen werden soll, sollte dahingehend konfiguriert werden, dass sie die Kommunikation über HTTPS abwickelt. Siehe hierzu:

Checkliste

Enhancing the Security of Database Engine Connections (https://msdn.microsoft.com/en-us/library/ff848785(v=sql.105).aspx)

2.4.4 Patching

Alle Security Hotfixes für SharePoint Server, SQL Server und Windows Server sollten unbedingt so schnell wie möglich nach ihrer Veröffentlichung eingespielt werden. Diese sind vorher in einer Test-/Staging- oder Abnahmeumgebung zu testen. Es wird empfohlen, Service Packs so schnell wie möglich zu testen und einzuspielen. Dabei sind vor allem die Auswirkungen auf die Supportbarkeit der Konfiguration hin zu berücksichtigen. Siehe hierzu https://support.microsoft.com/lifecycle/. Die Installation von Cumulative Updates (CU) wird fallweise empfohlen, wenn Sie damit Probleme beheben oder die Performance verbessern können.

Empfehlung

Alle Security Hotfixes für SharePoint Server, SQL Server und Windows Server müssen so schnell wie möglich nach ihrer Veröffentlichung eingespielt werden.

2.4.5 Trennung der Verantwortlichkeiten

Bei den Berechtigungen bei Administration und Betrieb des SQL Server Backends sollten Sie die Möglichkeit einer sauberen Trennung der Verantwortlichkeiten unbedingt nutzen. Die Mitglieder der lokalen Administratorengruppe sind per Default nicht automatisch Datenbankadministratoren, also Mitglieder der sysadmin Rolle. Diese Trennung sollte unbedingt aufrechterhalten. Gleichzeitig sollten die Datenbankadministratoren ebensowenig automatisch Mitglied der lokalen Administratorengruppe sein. Sowohl auf Betriebsystemebene als auch Datenbankserverebene können die Rechte für die verschiedenen Gruppen granular eingeräumt werden.

Innerhalb der SQL Server Administration sind einige Rollen vordefiniert, die bereits eine erste Trennung ermöglichen, die unbedingt genutzt werden sollte. Diese sind hier im Detail dokumentiert:

Diese lassen sich auch mit Hilfe des SQL Server Best Practice Analyzer (BPA) Tools auswerten und überwachen. Ab SQL Server 2012 können Server-weite Rechte auch zu eigenen Server-Rollen zusammengefasst werden, womit eine noch bessere Trennung möglich ist. Siehe hierzu:

Der Betrieb und Administration von SharePoint baut sinnvoll auf diesem Rollenmodell auf, um das Einräumen von zu vielen Rechten zu vermeiden, was im Konflikt mit einem sicheren Betrieb stünde. Über die von SharePoint dokumentierten Rechte sollte im Sinne eines sicheren Betriebes auch nicht hinausgegangen werden. Für den SharePoint Farm Account reichen daher auch nur die Mitgliedschaft in den Rollen securityadmin und dbcreator aus.

Für die Analysis Services (PowerPivot) sind die minimalen Rechte für die benötigten Konten hier beschrieben:

 

2.4.6 Antivirensoftware

Die Server des SQL Server Backends sollten wie Desktop Clients mittels Antivirensoftware zusätzlich abgesichert werden. Allerdings sollte diese nicht mit den Standard Policies/Profilen betrieben werden, wie sie für die Desktop Clients in den meisten Unternehmen eingestellt sind. Dadurch können sich in der Regel Konflikte ergeben zwischen den SQL Server Diensten und der Antivirensoftware, die zu Performanceeinbußen und Instabilität führen können. Für die SQL Server Dienste sind die Vorgaben und Ausnahmen ausführlich dokumentiert, um genau solche Effekte zu vermeiden ohne auf einen Schutz verzichten zu müssen:

 

2.4.7 Lagerung von Backups

Die Backup Dateien sollten unbedingt sicher gelagert werden, um zum einen sicherzugehen, dass sie auch im Zugriff sind, wenn sie im Desaster Recovery (DR) Fall auch wirklich zur Verfügung stehen müssen und zum anderen, dass die darin enthaltenen Daten nicht in die falschen Hände geraten. Neben den üblichen Sicherungsansätzen kann aber hier auch ein Cloud Speicher wie Microsoft Azure Blob Storage genutzt werden, sofern sichergestellt ist, dass entweder die Backups verschlüsselt sind oder die Backups von per TDE verschlüsselten Datenbanken erzeugt worden sind. Der Vorteil ist hier, dass dadurch eine sichere und kostengünstige Speicherung möglich ist, die gleichzeitig eine Geo-Redundanz kostengünstig mitbringt. Die verschlüsselten Dateien bleiben somit von den Schlüsseln bzw. Zertifikaten getrennt, solange diese On-Premise gespeichert bleiben.

2.4.8 Instant File Initialization

Wenn SQL Server eine Datenbankdatei anlegt oder vergrößert, wird diese dann mit 0 initialisiert. Damit wird sichergestellt, dass jeder Inhalt auf der Disk überschrieben wird, der nach eventuell vorangegangenen Löschoperationen u.U. noch übriggeblieben ist. Dieser Vorgang kann je nach Leistungsfähigkeit des IO Systems einige Zeit in Anspruch nehmen, in der alle weiteren IO Operationen ausgebremst werden. Diese Situation ergibt sich immer beim Anlegen einer Datenbank, wenn bspw. eine Content Datenbank angelegt wird oder ein neuer Application Service konfiguriert wird, eine weitere Datenbankdatei angelegt wird und wenn die Datenbank oder das Transaction Log File wachsen. Dies kann aber durch entsprechende Planung während des regulären Betriebs vermieden werden oder in lastarme Zeiten verlagert werden. Im Desaster Recovery Fall allerdings, wenn die SharePoint Datenbanken per Backup wiederhergestellt werden müssen, werden die Datenbankdateien neu angelegt, was die Wiederherstellungszeit verlängert. Um dies zu beschleunigen, kann man die sog. Database Instant File Initialization aktivieren, indem man dem SQL Server Dienstkonto das Windows Recht SE_MANAGE_VOLUME_NAME einräumt. Das Verhalten zu aktivieren sollte gegen die möglichen Implikationen abgewogen werden, die der Umstand mit sich bringt, dass die Datenbankdateien u.U. noch schützenswerte Inhalte umfassen, die bereits im Dateisystem gelöscht worden sind. Weitere Details dazu finden Sie unter:

 

2.4.9 Dienstkonten

Die Dienstkonten für die jeweiligen SQL Server Dienste sollten nach Möglichkeit mit den geringstmöglichen Rechten ausgestattet werden. Wenn keine Kerberos Authentifizierung benötigt wird, so sollte nach Möglichkeit immer mit Virtual Accounts (z.B. NT SERVICE\MSSQLSERVER) für die verschiedenen Dienste gearbeitet werden, die ab Windows Server 2008 R2 unterstützt werden. Sie werden vom SQL Server Setup standardmäßig vorgeschlagen. Das Setup bzw. die SQL Server Konfigurationstools und -APIs stellen sicher, dass diese mit den geringstmöglichen Rechten ausgestattet werden, die für den Betrieb gebraucht werden.

Empfehlung

Es sollte unbedingt für jeden Dienst auf jedem Server ein separates Dienstkonto verwendet werden. Es ist dringend davon abzuraten, für alle Dienste nur ein Konto zu verwenden. Ausnahme von dieser Regel sind die Analysis Services (PowerPivot Engine), bei denen in einer Scale-Out Topologie dasselbe Dienstkonto verwendet werden muss.

Bei einer Installation als Failover Cluster oder AlwaysOn Availability Group sollten die verwendeten Domain Accounts mit den geringstmöglichen Rechten ausgestattet werden. Für jeweiligen SQL Server Dienste sind die hier aufgeführten Rechte auf Betriebssystemebene und Dateisystem nötig:

Configure Windows Service Accounts and Permissions (https://msdn.microsoft.com/en-us/library/ms143504.aspx)

Empfehlung

Verwenden Sie auf keinen Fall Local System oder Network Service als Dienstkonten oder Dienstkonten, die Mitglied der lokalen Administratorengruppe sind. Nutzen Sie nach Möglichkeit Virtual Accounts.

Alle Änderungen an den Dienstkonten müssen über die SQL Server Konfigurationstools oder die Management API durchgeführt werden, damit sichergestellt ist, dass die korrekten Berechtigungen gesetzt werden:

SQL Server Service

Permissions granted by SQL Server Setup

SQL Server Database Engine:

(All rights are granted to the per-service SID. Default instance: NT SERVICE\MSSQLSERVER. Named instance: NT SERVICE\MSSQL$InstanceName.)

Log on as a service (SeServiceLogonRight)

Replace a process-level token (SeAssignPrimaryTokenPrivilege)

Bypass traverse checking (SeChangeNotifyPrivilege)

Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)

Permission to start SQL Writer

Permission to read the Event Log service

Permission to read the Remote Procedure Call service

SQL Server Agent:

(All rights are granted to the per-service SID. Default instance: NT Service\SQLSERVERAGENT. Named instance: NT Service\SQLAGENT$InstanceName.)

Log on as a service (SeServiceLogonRight)

Replace a process-level token (SeAssignPrimaryTokenPrivilege)

Bypass traverse checking (SeChangeNotifyPrivilege)

Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)

SQL Server Analysis Services:

(All rights are granted to a local Windows group. Default instance: SQLServerMSASUser$ComputerName$MSSQLSERVER. Named instance: SQLServerMSASUser$ComputerName$InstanceName. PowerPivot for SharePoint instance: SQLServerMSASUser$ComputerName$PowerPivot.)

Log on as a service (SeServiceLogonRight)

For tabular only:

Increase a process working set (SeIncreaseWorkingSetPrivilege)

Adjust memory quotas for a process (SeIncreaseQuotaSizePrivilege)

For failover cluster installations only:

Increase scheduling priority (SeIncreaseBasePriorityPrivilege)

SQL Server Reporting Services:

(All rights are granted to the per-service SID. Default instance: NT SERVICE\ReportServer. Named instance: NT SERVICE\$InstanceName.)

Log on as a service (SeServiceLogonRight)

SQL Server Integration Services:

(All rights are granted to the per-service SID. Default instance and named instance: NT SERVICE\MsDtsServer120. Integration Services does not have a separate process for a named instance.)

Log on as a service (SeServiceLogonRight)

Permission to write to application event log.

Bypass traverse checking (SeChangeNotifyPrivilege)

Impersonate a client after authentication (SeImpersonatePrivilege)

Full-text search:

(All rights are granted to the per-service SID. Default instance: NT Service\MSSQLFDLauncher. Named instance: NT Service\ MSSQLFDLauncher$InstanceName.)

Log on as a service (SeServiceLogonRight)

Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)

Bypass traverse checking (SeChangeNotifyPrivilege)

SQL Server Browser:

(All rights are granted to a local Windows group. Default or named instance: SQLServer2005SQLBrowserUser$ComputerName. SQL Server Browser does not have a separate process for a named instance.)

Log on as a service (SeServiceLogonRight)

SQL Server VSS Writer:

(All rights are granted to the per-service SID. Default or named instance: NT Service\SQLWriter. SQL Server VSS Writer does not have a separate process for a named instance.)

The SQLWriter service runs under the LOCAL SYSTEM account which has all the required permissions. SQL Server setup does not check or grant permissions for this service.

Tabelle 4: Notwendige Berechtigungen für die SQL Server Dienste

Empfehlung

Ändern Sie regelmäßig die Passwörter für die Dienstkonten und verwenden Sie dabei unbedingt komplexe Passwörter. Nutzen Sie für jedes Dienstkonto ein eigenes Passwort.

Das Dienstkonto für die Reporting Services (SharePoint Modus) sollte ein Domän Account sein. Das Dienstkonto wird bei der Anlage der Service Application festgelegt. Auch hier gilt, dass das Konto die geringstmöglichen Rechte haben sollte und diese im Laufe der Zeit nicht ausgeweitet werden. Bei einer Scale-Out Topologie ist ein Domän Account zwingend vorgeschrieben. Siehe hierzu:

Empfehlung

Für die Erzeugung einer Reporting Services Service Application muss der SharePoint Farm Service Account lediglich vorübergehend in der lokalen Administratorengruppe sein. Entfernen Sie nach der Anlage der Service Application diese Mitgliedschaft wieder.

Das Dienstkonto für die Analysis Services (PowerPivot) in einer SharePoint Farm kann durch das Setup, die SharePoint Central Administration, per PowerShell oder über das mitgeliefert PowerPivot Configuration Tool gesetzt bzw. geändert werden. Als Dienstkonto kann ausschließlich ein Domän Account verwendet werden. Weitere Informationen dazu siehe:

]]> Sicherer Betrieb von SharePoint 2013 - Logische Absicherung https://docs.microsoft.com/archive/blogs/bertilsy/sicherer-betrieb-von-sharepoint-2013-logische-absicherung Tue, 18 Nov 2014 04:51:41 GMT https://blogs.msdn.microsoft.com/bertilsy/2014/11/18/sicherer-betrieb-von-sharepoint-2013-logische-absicherung/ Die Logische Absicherung des SharePoint Dienstes definiert alle Prozesse und Rollen, die für den sicheren Betrieb einer SharePoint Umgebung zu empfehlen sind. In diesem Beitrag werden die wichtigsten Prozesse beschrieben und Empfehlungen getroffen wie man sie umsetzen sollte.

Diese Beitrag ist Teil einer Reihe von mehreren Blogbeiträgen zu diesem Thema:

Einleitung: Sicherer Betrieb von SharePoint 2013

Teil 1: Logische Absicherung

Teil 2: Physische Absicherung

1.1 Protokollierung aller Zugriffe, inklusive Zugriffe durch den Administrator

In einer sicheren SharePoint Umgebung sollten alle Zugriffe auf Daten und Änderungen der Farmkonfiguration protokolliert werden und diese Protokolle regelmäßig analysiert werden um mögliche Angriffsversuche frühzeitig erkennen zu können.

Die Zugriffe auf im SharePoint gespeicherte Daten lassen sich durch die Auditing Funktionen im SharePoint protokolieren und in Form eines Audit Logs auswerten. Eine detaillierte Beschreibung dieses Features finden Sie unter https://office.microsoft.com/en-001/sharepoint-help/configure-audit-settings-for-a-site-collection-HA102866204.aspx.

Änderungen an der Farmkonfiguration und administrative Zugriffe über die Zentraladministration oder PowerShell werden vom SharePoint nicht direkt protokolliert. Es werden zwar Einträge im ULS Log generiert, für eine bessere Überwachung kann man aber auf Werkzeuge von Drittherstellern zugreifen.

Änderungen im SQL Server Backend werden standardmäßig im SQL Server Error Log und dem Default Trace protokolliert. Um eine weitergehende Überwachung zu erhalten, sollte auf den eingebauten Audit Mechanismus vom SQL Server zurückgegriffen werden. Mit Hilfe von diesem Mechanismus kann man eine sehr weitreichende Protokollierung einrichten. Weitere Informationen hierzu finden Sie unter: SQL Server Audit (https://msdn.microsoft.com/en-us/library/cc280386.aspx). Der Audit Mechanismus sollte zumindest für Systeme mit High Business Impact Daten genutzt werden.

1.2 Zeitlich beschränkte ("Just In Time") Vergabe von administrativen Berechtigungen

Im regulären Betrieb sollte niemand auf die SharePoint Farm, die Konfiguration oder die Daten mit administrativen Rechten zugreifen dürfen. Der administrative Zugriff sollte über einen Genehmigungsprozess nur bei Bedarf (z.B. Installation eines Patches, Troubleshooting usw.) und nur für eine kurze Zeit vergeben werden.

Dieser Genehmigungsprozess sollte wie folgt aufgebaut werden:

  • Die Genehmigung für weniger kritische administrative Vorgänge (z.B. die Analyse von ULS Logs) kann automatisch erteilt werden.
  • Bei kritischen Vorgängen, oder wenn der Administrator auf die Kundendaten im SharePoint zugreifen muss, sollte der Zugriff nach dem vier Augen Prinzip von mindestens einer anderen Person genehmigt werden.
  • Alle Zugriffsanforderungen und Genehmigungen sollten sicher protokolliert werden, und die Protokolle sollten regelmäßig oder automatisiert nach Anomalien untersucht werden (z.B. auffällig viele Zugriffsanforderungen von dem selben Administrator).
  • Für den Zugriff auf die Farmkonfigurationsdaten sollten Skripte entwickelt werden, die einem Administrator eine minimale Angriffsfläche anbieten. Zum Beispiel, anstatt dem Administrator den Zugriff auf den ULS Log Ordner zu geben, sollte ein PowerShell Skript entwickelt werden, das dem Administrator die letzte ULS Datei liefert, ohne dass er sich interaktiv auf dem Log Rechner anmelden muss.
  • Jeder administrative Zugriff sollte im Umfang und zeitlich beschränkt sein. Die administrative Session sollte nach Ablauf der vordefinierten Zeit automatisch abgebrochen werden. Für den erneuten Zugriff ist dann eine neue Genehmigung notwendig. Dieser Prozess lässt sich z.B. über die automatische Passwortänderung im AD realisieren.
  • Um die Anzahl der administrativen Zugriffe zu minimieren, sollen im normalen Betrieb alle relevanten Betriebsdaten und Parameter (ULS Logs, Performance Counter) - ohne die Notwendigkeit sich administrativ in der Farm anzumelden - über ein Dashboard sichtbar gemacht werden. Dafür eignet sich z.B. der System Center 2012 R2 (https://www.microsoft.com/en-us/server-cloud/products/system-center-2012-r2) mit dem Management Pack für SharePoint 2013 (https://www.microsoft.com/en-us/download/details.aspx?id=35590)
  • Im SQL Server Backend sollte man die administrativen Berechtigungen immer dann zeitlich begrenzen, wenn dies möglich ist. Darunter fällt auch die nur vorrübergehend notwendige Mitgliedschaft des SharePoint System Account in der Gruppe der lokalen Administratoren bei der Einrichtung einer Reporting Services Service Application.

 

1.3 Höchstmögliche Automatisierung

Um menschliche Fehler zu minimieren, sollten alle technischen Aufgaben im SharePoint Betrieb mittels PowerShell Skripting automatisiert werden. Alle Änderungen im SQL Server sollten per T-SQL Skripte oder - wo es möglich ist - per PowerShell umgesetzt werden und dokumentiert werden. Für die Änderungen bei den Analysis Services (PowerPivot Engine) und den Reporting Services (SharePoint Modus) gilt die Vorgabe wie für die übrige SharePoint Komponenten, da auch hier die Konfiguration mittels PowerShell durchgeführt werden kann.

Damit wird sichergestellt, dass alle Prozesse und Vorgänge reproduzierbar und nachvollziehbar ausgeführt werden können. Gleichzeitig wird die Notwendigkeit für manuelle Zugriffe auf die SharePoint Farm und die Daten minimiert.

1.4 Change Management

Alle Änderungen an der Farmkonfiguration und an allen beteiligten Soft- oder Hardwarekomponenten (inklusive Drittherstellerprodukten, Betriebssystem, Hardwaretreiber…) sollten getestet, genehmigt und protokolliert werden bevor sie in der Farm umgesetzt werden dürfen.

1.5 Datenklassifizierung und Informationsarchitektur

In einer SharePoint Farm entstehen mit der Zeit große Datenmengen mit unterschiedlichen Sicherheitsmerkmalen. Dabei beinhalten viele Daten in der Regel keine geheimen oder geschäftskritischen Informationen, und müssen nicht durch dieselben Sicherheitsmechanismen geschützt werden wie die hochsensiblen Daten.

Die Daten sollten deswegen in folgende Kategorien untergeteilt werden:

  • Low Business Impact (LBI): Geeignet für wenig oder nicht sensible Daten. Diese Kategorie passt zu den meisten Abteilungsteamseiten mit Teamkalendern, Besprechungsseiten, Teamfotos usw. Auch die persönlichen OneDrive Seiten gehören in der Regel in diese Kategorie.
  • Medium Business Impact (MBI): Trifft bei den Daten zu, die zum Teil geheim sind und nur firmenintern verwendet werden dürfen. Diese Daten werden jedoch in der Regel durch die SharePoint Suche indiziert und stehen auch über die Suche allen berechtigten Benutzern ohne weitere Genehmigung zur Verfügung.
  • High Business Impact (HBI): Geeignet für streng geheime oder geschäftskritische Daten und Daten mit persönlichen Kunden- oder Mitarbeiterdaten. Diese Daten werden häufig aus der Suche ausgeschlossen und stehen nur einer kleinen Benutzergruppe zur Verfügung. Der Zugriff auf diese Daten wird durch zwei-Wege Authentifizierung oder Smartcards zusätzlich geschützt.

Diese Einteilung ist vergleichbar mit den Schutzbedarfskategorien "normal", "hoch" und "sehr hoch", wie sie im IT-Grundschutz durch das Bundesamt für Sicherheit in der Informationstechnik (BSI) definiert sind. Siehe hierzu Kapitel 4.3 der IT-Grundschutz-Vorgehensweise (BSI-Standard 100-2) (https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/ITGrundschutzstandards/standard_1002_pdf.pdf?__blob=publicationFile).

Um zwischen der Sicherheit und den Betriebskosten eine Balance zu schaffen, sollte man die Daten in diesen drei Kategorien physikalisch trennen und für jede Datenklasse ein eigenes Betriebs- und Sicherheitskonzept ausarbeiten. Damit die Daten getrennt gespeichert werden, empfehlen wir einen Seitenanlageprozess zu etablieren, über welchen neue SharePoint Seiten automatisiert und nach einer Genehmigung angelegt werden. Dieser Prozess sieht in der Regel die folgenden Schritte vor:

  1. Ein Benutzer erstellt einen Antrag für eine neue SharePoint Webseitensammlung (Site Collection). Dafür sollte ein Webportal entwickelt werden wo solche Anträge gestellt werden können.
  2. In dem Antrag muss der Benutzer die Datenklasse für seine neue Webseitensammlung angeben (siehe oben) und die Personen nennen, die als Besitzer (Site Owner) für die neue Webseite eingetragen werden.
  3. Bevor die Webseitensammlung erstellt wird, muss diese genehmigt werden. Die Genehmigung kann - je nach Datenklasse - entweder vollautomatisiert oder über mehrere manuelle Genehmigungsschritte erteilt werden. Dieser Prozess kann entweder als ein SharePoint oder ein BizTalk Workflow technisch realisiert werden.
  4. Nach einer erfolgreichen Genehmigung wird die neue Webseitensammlung automatisch erstellt. Je nach Datenklasse wird diese Webseitensammlung in der entsprechenden Datenbank, Webanwendung und/oder Farm erstellt und es werden die notwendigen SharePoint Features (de)aktiviert. Bei hochsicheren Seiten soll z.B. verhindert werden, dass die Listen und Dokumentenbibliotheken durch die Suche indiziert werden.
  5. Der Antragssteller wird entsprechend der Datenklasse in der neuen Seite berechtigt. Bei den unkritischen Seiten kann er die Site Owner Rechte bekommen, bei den hochsicheren Seiten soll er nur die Member Rechte haben, um jegliche Änderungen an der Seitenkonfiguration durch den Benutzer zu verhindern. Es ist auch möglich eigene Berechtigungsstufen zu definieren und einzusetzen.

Grundsätzlich sollten alle Dokumente, die in dem hochsicheren Bereich verwaltet werden, zusätzlich durch den Rights Management Server (RMS) geschützt werden. Dabei werden die Dokumente verschlüsselt, und der Zugriff auf die Inhalte wird nur einem kontrollierten Personenkreis gestattet, auch wenn das Dokument außerhalb vom SharePoint geöffnet wird. Mehr über den Einsatz vom Rights Management Server im SharePoint finden Sie unter https://blogs.office.com/2013/09/10/collaborate-confidently-using-rights-management.

SharePoint verfügt über keine eingebauten Mechanismen, die es verhindern können, aus fachlicher Sicht hochsensible Daten bspw. in "Low Business Impact" Seiten zu speichern. Durch die Benutzerschulung und regelmäßige Audits kann das Risiko jedoch minimiert werden.

Beim Löschen einer Webseitensammlung sollte ein ähnlicher Genehmigungsprozess etabliert werden. Die Benutzer sollen nicht in der Lage sein eine Webseitensammlung eigenmächtig zu löschen. Wenn das Löschen einer Webseitensammlung genehmigt wurde, sollte diese aus der Content Datenbank restlos entfernt werden. Nach dem Löschen einer Webseitensammlung bleibt diese vorerst 30 Tage in der Content Datenbank und kann wiederhergestellt werden. Verwenden Sie das Remove-SPDeletedSite PowerShell Kommando, um eine gelöschte Webseitensammlung aus der Content Datenbank vollständig zu löschen.

1.6 Regelmäßiges Testen

Die Art und Weise, wie die Angriffe auf die IT Systeme getätigt werden, ändert sich dauernd. Deswegen müssen alle sicherheitsrelevanten Prozesse ständig weiterentwickelt und überprüft werden. Das gelingt bspw. durch regelmäßige Sicherheitsaudits von unabhängigen zertifizierten Unternehmen oder auch Tool basierte Angriffssimulationen wie Lasttests, um einen Denial-of-Service (DoS) Angriff zu simulieren.

1.7 Sicherheitsstrategie bei der Entwicklung von SharePoint Erweiterungen

Eigenentwickelte oder durch einen externen Partner entwickelte SharePoint Erweiterungen (Apps oder "Full Trust Solutions") bringen potenziell eine zusätzliche Gefahr in das System. Generell sollte die Anzahl solcher Erweiterungen minimiert werden, und in hochsicheren Datenbereichen sollten keine Erweiterungen erlaubt werden.

Beim Umgang mit eigenentwickelten Erweiterungen sollten die folgenden Teilprozesse etabliert werden:

  • Code Reviews: Der Quellcode von allen eigenentwickelten oder zugekauften Erweiterungen sollte zuerst überprüft werden bevor er in der Farm installiert wird. Der Quellcode sollte nach bekannten Sicherheitslücken durchsucht werden, und - nur wenn keine sicherheits- oder leistungsrelevanten Probleme gefunden wurden - in der Farm installiert werden. Dasselbe gilt für alle Updates.
  • Verwendung von Security Development Lifecycle (SDL): "Security Development Lifecycle" ist eine Sammlung von Best Practices, Regeln, Prozessen und Werkzeugen für die Entwicklung von Anwendungen nach den höchsten IT Sicherheitsstandards. Alle eigenentwickelte Anwendungen sollten unbedingt diesem Prozess folgen und bei der Auswahl von externen Partner sollte darauf geachtet werden, dass alle externen Entwickler diesen Prozess verstehen und verwenden. Die Details zum SDL Prozess finden Sie unter https://www.microsoft.com/security/sdl/default.aspx.
  • Entwicklerrichtlinien: Alle generischen und kunden- oder projektspezifischen Richtlinien für die Entwicklung von SharePoint Erweiterungen sollten in einem formellen Dokument erfasst werden. Diese Regeln sollten für alle Entwickler bindend sein. Durch die Team Foundation Server (TFS) Check-In Regeln können viele Richtlinien automatisiert überprüft werden. Somit kann sehr früh in der Entwicklungsphase verhindert werden, dass unsicherer Quellcode in die Produktion kommt.
  • Testing: Softwaretesting ist eine der wichtigsten Maßnahmen, um alle Arten von Fehler frühzeitig zu entdecken und zu beheben. Neben den klassischen Code Unit Tests, kommen noch Lasttests, Coded UI Tests und Penetration Tests zum Einsatz. Diese Tests sollten als Teil der Qualitätssicherung etabliert werden und nach jeder Änderung im Quellcode wiederholt werden.

Tipp

Microsoft Premier Services for Developers (PSfD) hat jahrelange Erfahrung in diesem Bereich und kann beim Aufbau dieses Prozesses in allen Phasen qualifiziert unterstützen.

1.8 Einsatz von Drittherstellerlösungen

Der Einsatz von Drittherstellersoftware in einer SharePoint Farm sollte gesondert genehmigt und bewertet werden. Nur die Produkte, die vorher geprüft, getestet und freigegeben wurden, sollten installiert werden dürfen. Generell soll so wenig wie möglich Drittherstellersoftware in einer SharePoint Farm installiert werden und in hochsicheren Datenbereichen sollten möglichst Drittherstellerlösungen nur nach einer intensiven Prüfung installiert werden.

Die Drittherstellerprodukte sollten regelmäßig aktualisiert werden, und alle sicherheitsrelevanten Updates oder Fehlerkorrekturen sollten schnellstmöglich, nachdem sie vom Hersteller zur Verfügung gestellt wurden, eingespielt werden. Es sollte klar definiert werden, wer für die Wartung von jedem Drittherstellerprodukt, das in der Farm verwendet wird, verantwortlich ist.

Verwenden sie AppLocker auf allen Rechnern in der Farm und auf allen Klienten um die Installation von unerlaubter Fremdsoftware zu verhindern. Mehr über den AppLocker finden Sie unter https://technet.microsoft.com/library/hh831409.aspx.

1.9 Umgang mit dem Office Store und SharePoint Apps

Ein neues Feature von SharePoint 2013 sind die SharePoint Apps. SharePoint Apps können über den offiziellen Microsoft Office App Store und über den firmeninternen App Catalog vom Site Owner auf seiner Webseite installiert und deinstalliert werden. Jede App fragt bei der Installation nach den Berechtigungen, die sie zur Laufzeit benötigt. Erst wenn der Site Owner diese Anfrage bestätigt, wird die App installiert. Die SharePoint Apps haben viele Vorteile gegenüber klassischen "Full Trust" Farm Lösungen:

  • Die Apps laufen außerhalb vom SharePoint, und Fehler oder Abstürze in einer App haben keinen Einfluss mehr auf den SharePoint Prozess.
  • Der IIS muss nicht neu gestartet werden, wenn eine App installiert oder deinstalliert wird.
  • Da die Apps außerhalb vom SharePoint laufen, verhindern oder erschweren sie nicht mehr die Migration vom SharePoint auf eine neue Version.
  • Die Kommunikation zwischen einer App und SharePoint findet ausschließlich über http(s) statt.
  • Es werden keine Fremdkomponenten oder Dateien mehr auf den Servern in der Farm gespeichert. Alle App Artefakte befinden sich entweder in der Content Datenbank oder auf einem separaten Server außerhalb der SharePoint Farm.
  • Die Apps werden vom Site Owner auf seiner Webseite installiert. Jeder Site Owner entscheidet selbst welche Apps er auf seiner Webseite haben möchte, und der Administrator muss nicht mehr jede Erweiterung selbst installieren.
  • Die App Updates werden auch über den App Store verteilt. Der Site Owner kann seine Apps selbst aktualisieren.

Neben vielen Vorteilen ergeben sich auch einige Nachteile:

  • Die Apps können vom Site Owner in dem offiziellen Microsoft Office App Store gekauft und installiert werden. Die Möglichkeit, die Apps im Microsoft Office App Store zu kaufen, lässt sich administrativ ausschalten, es besteht jedoch keine Möglichkeit einzelne Apps selektiv zu sperren.
  • Alle Apps, die über den firmeninternen App Catalog verteilt werden, stehen jedem Site Owner zur Auswahl. Die Installation kann jedoch von einem Lizenzschlüssel abhängig gemacht werden, so dass nur die Benutzer, die einen solchen Schlüssel haben, die betreffende App installieren dürfen.
  • Pro Webanwendung im SharePoint 2013 muss jeweils ein App Catalog für firmeninterne Apps konfiguriert werden. Ein App Catalog ist immer zu einer Webanwendung zugeordnet und kann nicht für mehrere SharePoint Webanwendungen verwendet werden. Das heißt, dass die Apps, die in allen Webanwendungen zur Verfügung stehen, vom Administrator in alle App Catalogs hochgeladen werden müssen.

Die Apps geben dem Endbenutzer generell viel Flexibilität in der Auswahl von SharePoint Erweiterungen für seine Webseite und entlasten den Administrator. Bösartige Apps können jedoch die Daten aus SharePoint an fremde Webseiten hochladen oder manipulieren. Die Apps, die über den offiziellen Microsoft Office App Store vertrieben werden, werden in einem strengen Verfahren sorgfältig geprüft bevor sie in dem Store angeboten werden. Für die Apps, die über den firmeninternen App Catalog vertrieben werden (selbstentwickelte oder zugekaufte Apps), sollten die selben Kontrollmechanismen wie bei allen SharePoint Erweiterungen etabliert werden (siehe Abschnitt 1.7).

Für den sicheren Betrieb von SharePoint Seiten empfiehlt sich daher folgendes:

  • Die Installation von Apps aus dem Microsoft Office App Store und aus dem App Catalog in dem "Low Business Impact” Bereich können im allgemeinen Fall allen Site Owners erlaubt werden.
  • In den "Medium Business Impact" und "High Business Impact" Bereichen sollte die App Installation durch einen Genehmigungsprozess kontrolliert werden. Optional kann der Administrator die Installation von Apps aus dem Microsoft Store per Konfiguration sperren. Dies empfiehlt sich vor allem im "High Business Impact" Bereich.

 

1.10 Überwachung

Um die Angriffe und andere Probleme in der Farm so früh wie möglich zu erkennen, sollten alle betriebsrelevanten Parameter dauerhaft und automatisiert überwacht werden. Die so gesammelten Daten und Logs sollten jedoch keine Benutzerdaten oder andere sensible Informationen beinhalten. Erlaubt sind nur die technischen Parameter, die es dem Administrator ermöglichen den Zustand einzelnen Server in der Farm - ohne sich direkt mit dem Server verbinden zu müssen - zu überwachen.

Für die Überwachung empfiehlt sich der Einsatz von Systems Center 2012 R2 mit dem SharePoint 2013 Management Pack und dem SQL Server 2014 Management Pack. Mehr Informationen zu dem Systems Center 2012 R2 finden Sie unter https://www.microsoft.com/en-us/server-cloud/products/system-center-2012-r2 und das Management Pack für SharePoint 2013 finden Sie unter https://www.microsoft.com/en-us/download/details.aspx?id=35590. Das Management Pack für SQL Server 2014 finden Sie unter https://www.microsoft.com/en-us/download/details.aspx?id=42573.

1.11 Schulung von Personal und Benutzer

Eine der wichtigsten Maßnahmen für den sicheren Betrieb einer SharePoint Farm ist die Schulung für alle Benutzer und Administratoren vom SharePoint und dem SQL Server Backend. Die Schulungen sollten regelmäßig wiederholt werden, vor allem wenn neue SharePoint Versionen oder Drittherstellererweiterungen zur Verfügung gestellt werden.

Eine Grundannahme ist daher auch bei einer Common Criteria (CC) zertifizierten Lösung, dass die Administratoren geschult sind und sich mit dem zu betreuenden System vertraut sind (siehe Assumption A.NO_EVIL). Siehe hierzu: https://download.microsoft.com/download/9/2/3/9238F04A-56E9-475E-894F-C81AB1A528DB/MS_SQL_AGD_ADD_1.0.pdf in Kombination mit https://www.commoncriteriaportal.org/files/ppfiles/pp_dbms_v1.3.pdf.

Die Benutzer, die auf die Daten im hochsicheren Bereich zugreifen, sollten über die besonderen Einschränkungen und Richtlinien, die in diesem Bereich gelten, unbedingt im Voraus informiert werden und mit diesen einverstanden sein.

1.12 Einsatz von Mobilen Geräten im Unternehmen

Immer mehr Benutzer verwenden mobile Geräte für den Zugriff auf Firmendaten, die im SharePoint gespeichert sind. Diese Daten werden auf den mobilen Geräten häufig zwischengespeichert und verlassen auf diesem Wege das Unternehmen - häufig auch unbewusst oder ungewollt.

Um das Risiko für den Datenverlust durch den Diebstahl oder den Verlust von mobilen Geräten zu minimieren, müssen bestimmte Richtlinien für den Umgang mit den mobilen Geräten eingeführt werden:

  • Alle Dokumente, die im SharePoint liegen und auf die der Zugriff von mobilen Geräten möglich ist, sollten unbedingt durch den Einsatz vom Rights Management Server geschützt werden, unabhängig von der Datenklassifizierung (LBI, MBI, HBI). Nur so kann sichergestellt werden, dass diese Dokumente von unautorisierten Personen nicht geöffnet werden können.
  • Alle mobilen Geräte, die im Unternehmen verwendet werden, sollten verschlüsselt sein. Die Geräte, die nicht verschlüsselt sind, sollten keinen Zugriff auf die Daten im SharePoint bekommen.
  • Alle Zugriffe von mobilen Geräten sollten gesondert protokolliert werden, um einen Missbrauch frühzeitig zu erkennen.

 

1.13 Umgang mit persönlichen und sensiblen Daten

Wenn im SharePoint Dokumente oder andere Daten gespeichert werden, die persönliche oder andere sensible Daten beinhalten, dann sollten diese immer im hochsicheren Bereich und durch den Rights Management Server verschlüsselt abgelegt werden.

Benutzerprofile, die aus den externen Identitätsquellen wie Active Directory (AD) oder LDAP nach SharePoint importiert werden, können auch sensible Informationen beinhalten. Best Practice ist hier nur die Attribute zu importieren, die für den Betrieb vom SharePoint notwendig sind. Alle anderen Attribute sollen zur Laufzeit über andere Mechanismen (z.B. Webservices oder AD Lookup) ausgelesen werden.

Diese Daten sollen zudem von der SharePoint Suche ausgeschlossen werden, um den Datenklau über die Personensuche zu verhindern.

1.14 Umgang mit sozialen Funktionen im SharePoint

SharePoint 2013 bietet eine große Auswahl von sozialen Features, unter anderem:

  • Blogs
  • Tagging
  • Chat und Kommentare
  • Like
  • My Sites/Meine Website
  • Communities (Foren)

Diese Features sollten prinzipiell in allen Bereichen von SharePoint verwendet werden dürfen. Da jedoch ein Teil von sozialen Aktivitäten, die in der My Site jedes Benutzers gespeichert wird (z.B. Kommentare), wird empfohlen die Social Features bei den hochsichern Seiten nicht zu verwenden, oder - alternativ - die My Sites auch als hochsicheren Bereich zu klassifizieren.

In den Blogs und Communities sollen keine sicherheitsrelevanten oder geschäftskritischen Informationen verbreitet werden. Um das zu verhindern, sollten alle Benutzer entsprechend geschult werden.

1.15 OneDrive for Business

Jeder SharePoint Benutzer bekommt als Teil seiner My Site eine Dokumentenbibliothek, die als Ablage für alle Arten von eigenen Dateien verwendet werden kann. Durch das Synchronisieren dieser Dokumentenbibliothek auf die lokale Festplatte oder auf das Mobilgerät wird das offline Arbeiten an den Dateien auch außerhalb des Firmennetzes möglich. Das gilt auch für alle anderen Dokumentenbibliotheken, auf die der Benutzer zugreifen kann. Die Dateien, die in dem OneDrive abgelegt werden, können mit anderen Benutzern geteilt werden.

Alle Geräte, auf dem die Dateien aus SharePoint offline synchronisiert werden, sollten verschlüsselt sein (z.B. mit BitLocker). Außerdem sollen alle geschäftskritischen Dateien zusätzlich durch den Rights Management Server geschützt werden.

Wenn ein Mitarbeiter das Unternehmen verlässt, wird sein Profil im AD und im SharePoint gelöscht. Wenn das Profil eines Benutzers gelöscht wurde, wird "Meine Website" des Benutzers nach vierzehn Tagen zum Löschen gekennzeichnet. Damit Datenverluste verhindert werden, kann dem Manager des Benutzers Zugriff auf "Meine Website" erteilt werden. In Ermangelung eines Managers kann dies auch für einen sekundären Besitzer von "Meine Website" erfolgen. Auf diese Weise kann der Manager oder der sekundäre Besitzer Inhalte von "Meine Website" abrufen, bevor diese gelöscht wird. Legen Sie einen sekundären Besitzer fest, um dann Zugang zu erhalten, wenn der Manager eines Benutzers nicht ermittelt werden kann.

Grundsätzlich empfiehlt es sich aus Datenschutzgründen die Daten eines Benutzers in seinem OneDrive, nachdem sein Profil gelöscht wurde, durch einen automatisierten Prozess sofort zu löschen.

1.16 Erlaubte Dateitypen

Der Administrator kann im SharePoint konfigurieren welche Dateitypen hochgeladen werden dürfen. Es empfiehlt sich alle ausführbaren Dateien (z.B. .exe, .dll, .com, .bat, .ps1) zu sperren. Die Archive wie .zip oder .rar sollen nur nach einer Prüfung gegen Viren hochgeladen werden dürfen. Die verschlüsselten Archive, die passwortgeschützt sind, können von manchen Antivirus Programmen nicht korrekt überprüft werden und sollen daher nicht hochgeladen werden dürfen.

1.17 Berechtigungskonzept für den Zugriff auf SharePoint Seiten

Die Daten im SharePoint sollen in drei Sicherheitsklassen LBI, MBI und HBI verteilt werden. Für jede Sicherheitsklasse sollte ein separates Berechtigungskonzept entwickelt und umgesetzt werden. Das Berechtigungskonzept ist ein zentraler Bestendteil des gesamten Sicherheitskonzeptes und sollte klar dokumentiert, regelmäßig überprüft und bei Bedarf angepasst werden.

Bei der Entwicklung des Berechtigungskonzeptes sollten die folgenden Fragen beantwortet werden:

  • Welche Berechtigungen können die Endbenutzer maximal bekommen?
  • Dürfen die Benutzer andere Benutzer zu ihrer Seite einladen ("Share") und die Berechtigungen verwalten?
  • Wer kann die Einstellungen der Seite und der Webseitensammlung ansehen oder ändern?
  • Wer kann die Struktur der Seite ändern, z.B. neue Subseiten oder Listen anlegen, Content Types verwalten, Seiten editieren und die Webparts hinzufügen usw.?
  • Wer kann die Sucheinstellungen ändern?
  • Dürfen die neuangelegten Elemente (Listen, Subseiten…) von der Suche durchforstet werden?
  • Wer kann SharePoint Features aktivieren oder deaktivieren?
  • Darf der Site Owner SharePoint Apps aus dem Microsoft Office App Store installieren?
  • Dürfen die Endbenutzer das Recycle Bin leeren?
  • Sollen in der Webseite die SharePoint Standardberechtigungsgruppen ("Owners", "Members", "Visitors", …) und Standardberechtigungsstufen ("Full Control", "Contribute", "Design", "Edit", …) verwendet werden, oder eigene Gruppen und Berechtigungsstufen angelegt werden?
  • Gibt es Einschränkungen im Umgang mit Webparts? Sollen die Benutzer die Webpartseiten anlegen oder Anpassen dürfen?

 

1.18 SharePoint Designer

Generell soll die Nutzung von SharePoint Designer nur dem Administrator erlaubt werden. Die Endbenutzer sollen nicht direkt auf produktive Seiten mit dem SharePoint Designer zugreifen dürfen.

Alle Änderungen, die ein Administrator mit dem SharePoint Designer auf einer Seite macht, sollten protokolliert und vorher genehmigt werden.

1.19 Zugang für anonyme Benutzer

Der Zugang für anonyme Benutzer auf SharePoint Seiten sollte prinzipiell nicht erlaubt werden. Die Ausnahmen können aber folgende Szenarien sein:

  • Intranetportale mit allgemeinen Informationen ohne besonderen Schutzwert (Speiseplan, Wetter, Nachrichten, Fahrpläne für öffentliche Verkehrsmitteln usw.)
  • Seiten mit anonymen Umfragen
  • Technische Seiten oder Webservices im SharePoint, die bestimmte allgemeine Daten an andere Anwendungen oder Systeme liefern
  • Bibliotheken mit Firmeninformationen, Standardformularen, Standortplänen, usw.

Die Seiten, die anonym erreichbar sind, können z.B. den Firmenbesuchern und externen Mitarbeitern ohne ein Firmenkonto zur Verfügung gestellt werden.

1.20 Langzeitarchivierung und Aufbewahrungsrichtlinien

Falls in einer SharePoint Umgebung die Dokumente in einem SharePoint Archiv aufbewahrt werden, sollte unbedingt sichergestellt werden, dass für dieses Archiv dieselben Zugriffsregeln und dieselbe Datenklassifizierung implementiert wird wie auf dem ursprünglichen Ort. Für jede Datensicherheitsstufe soll ein separates Archiv angelegt werden.

In jedem Archiv sollen die Aufbewahrungsrichtlinien definiert werden, um die archivierten Dokumente nach dem Ablauf der gesetzlichen Aufbewahrungsfrist restlos zu löschen. Alle Zugriffe auf die Dokumente im Archiv sollten mithilfe der SharePoint Auditing Funktionen protokolliert und diese Protokolle regelmäßig überwacht werden.

1.21 Prävention und Erholung von Angriffen

In einer hochsicheren SharePoint Umgebung sollten nicht nur die Prozesse für die Prävention von Angriffen entwickelt werden, sondern auch die Maßnahmen entwickelt werden, die es ermöglichen im Falles eines erfolgreichen Angriffs den regulären Betrieb und die Sicherheit der Umgebung schnellstmöglich wiederherzustellen:

UmgangMitAngriffen

Abbildung 2: Umgang mit Angriffen

  • Angriff verhindern: Ständige Weiterentwicklung von technischen und organisatorischen Maßnahmen um Angriffe auf SharePoint zu verhindern
  • Angriff erkennen: Prozesse und Maßnahmen für die frühe Erkennung von einem möglichen Hackerangriff oder Datenverlust anhand von Mustern in Logfiles und Überwachungssystemen
  • Auf Angriff reagieren: Wenn ein Angriff passiert sollten schnellstmöglich alle technischen und organisatorischen Maßnahmen getroffen werden, um die betroffenen Bereiche zu identifizieren, den Zugriff auf die Daten zu sperren, den Angriff zu stoppen und seine Verbreitung im System zu verhindern.
  • Vom Angriff erholen: Nachdem ein Angriff verhindert oder abgewehrt wurde sollte der normale Betrieb schnellstmöglich wiederhergestellt werden. Die Erkenntnisse aus dem Angriff sollten unbedingt für die Verbesserung des Prozesses verwendet werden, um ähnliche Angriffe in Zukunft schneller zu erkennen und zu verhindern.
]]> Sicherer Betrieb von SharePoint 2013 https://docs.microsoft.com/archive/blogs/bertilsy/sicherer-betrieb-von-sharepoint-2013 Tue, 18 Nov 2014 01:38:49 GMT https://blogs.msdn.microsoft.com/bertilsy/2014/11/18/sicherer-betrieb-von-sharepoint-2013/

Publiziert: November 2014
Autoren: Robert Seso, Bertil Syamken

Informationssicherheit ist ein wesentlicher Faktor für alle IT-Organisationen auf der ganzen Welt. Der Zugriff auf Daten findet von immer mehr unterschiedlichen Geräten, Plattformen und Orten statt und stellt eine immer größere Herausforderung für die IT Sicherheit dar. Die meisten Angriffe mit Datenverlust als Folge passieren heute nicht mehr durch Schadsoftware, sondern als Folge des Benutzerfehlers - der Benutzer hat sich zum zentralen Element jedes Sicherheitskonzeptes entwickelt und dies muss bei der Entwicklung von Sicherheitsmaßnahmen besonderes berücksichtigt werden.

Diese Beitrag ist Teil einer Reihe von mehreren Blogbeiträgen zu diesem Thema:

Einleitung: Sicherer Betrieb von SharePoint 2013

Teil 1: Logische Absicherung

Teil 2: Physische Absicherung

Die Sicherheit in SharePoint Server 2013 ist ein permanenter Prozess und keine einmalige Aktion. Ein Sicherheitskonzept bestehend aus technischen und organisatorischen Maßnahmen und Prozessen sollte deswegen ständig überprüft, analysiert, getestet und weiterentwickelt werden.

GestaffelteSicherheitsebenen

Abbildung 1: Gestaffelte Sicherheitsebenen

Die einzelnen Ebenen in diesem Konzept ergänzen sich untereinander und stellen dadurch sicher, dass wenn eine Ebene durch einen Angriff kompromittiert wurde, die anderen Ebenen ihre Funktion übernehmen und den Zugriff zu den geschützten Daten verhindern können.

Das Hauptziel dieses Sicherheitskonzeptes ist externe und interne Angriffe und den daraus resultierenden Datenverlust von vorneherein zu verhindern. Um dieses Ziel zu erreichen, sollten die Sicherheitsmaßnahmen und Prozesse auf allen Ebenen dauerhaft überprüft, weiterentwickelt und verbessert werden.

Wichtig

Um die Sicherheit in einer SharePoint Umgebung zu erhalten sollten alle relevanten Maßnahmen und Prozesse ständig verbessert und weiterentwickelt werden.

Die Physikalische Ebene beschreibt alle technischen Maßnahmen zur Absicherung einer SharePoint Umgebung, wie:

  • Absicherung des Rechenzentrums
  • Netzwerkabsicherung und Überwachung
  • Absicherung der Farm, Webanwendungen und Seiten
  • Antivirenschutz
  • Authentifizierung
  • Verschlüsselung aller Kommunikationswege in der SharePoint Umgebung
  • Verwendung von Rights Management Server

Die Logische Ebene beinhaltet alle Prozesse und Rollen die für den sicheren Betrieb einer SharePoint Umgebung notwendig sind, wie:

  • Protokollierung aller Zugriffe, inklusive Zugriffe durch den Administrator
  • Zeitlich beschränkte ("Just In Time") Vergabe von administrativen Berechtigungen
  • Höchstmögliche Automatisierung
  • Change Management
  • Datenklassifizierung und Informationsarchitektur
  • Regelmäßiges Testen
  • Klar definierte Sicherheitsstrategie bei der Entwicklung von eigenen Anwendungen
  • Kontrollmechanismen beim Einsatz von Drittherstellerlösungen
  • Umgang mit dem Office Store und SharePoint Apps
  • Ständige Überwachung aller technischen und operativen Parameter
  • Schulung von Personal und Benutzer
  • Klare Regeln beim Einsatz von mobilen Geräten im Unternehmen
  • Geregelter Umgang mit persönlichen und sensiblen Daten, inklusive Kundendaten
  • Umgang mit sozialen Funktionen im SharePoint
  • Berechtigungskonzept für den Zugriff auf SharePoint Seiten
  • Zugangsregeln für externe und/oder anonyme Benutzer

Der Schutz auf der Datenebene ist der Kern des Konzeptes und beinhaltet alle technischen Maßnahmen und Prozesse beim Umgang mit den SharePoint Datenbanken:

  • Verschlüsselung aller Datenbanken
  • Verwendung von BitLocker
  • Zugriffskontrolle und Überwachung auf Datenbankebene
  • Backup und Restore Strategie und Umgang mit Datensicherungen
  • Rechtskonforme Langzeitarchivierung und Aufbewahrungsrichtlinien
  • Mandantenfähigkeit
  • Sicheres Löschen von Daten

Diese Punkte werden in den folgenden Blogbeiträgen detailliert beschrieben:

Teil 1: Logische Absicherung

Teil 2: Physische Absicherung

]]>