다음을 통해 공유

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: