Permalink

off

HowTo: SharePoint Farm Sicherheitsüberlegungen

Aus einem Projekt heraus entstanden ein paar Listen zum Thema „Sicherheit und SharePoint Farmen“. Ich habe aus dieser Arbeit das wichtigste herausgenommen und in komprimierter Form in diesen Beitrag gepackt.   

Office SharePoint Server Security Konten

Service Accounts

Farm Level

Server Farm Account Dieses Konto wird erstellt wenn man das Setup des SharePoint Servers ausführt. Dieses Konto wird gebraucht um den Application Pool zu sehen, die Zentraladministration und er hat die Berechtigung um innerhalb des SQL Servers Datenbanken zu erstellen.
SQL Server Service Account Dies ist das Konto das gebraucht wird um den SQL Server Service zu betreiben. Es muss ein Domänen Konto sein. Dazu muss aber Kerberos in der Domäne konfiguriert sein.
Office SharePoint Search Service Account Auch dieses Konto muss ein Domänenkonto sein. Es hat Zugriff auf den Inhalt des SQL Servers für den Crawling Prozess.
Windows SharePoint Service Search Service Account Dieses Konto wird für das Durchsuchen des Hilfe Inhalts von MOSS gebraucht.

SSP Level

SSP Service Account Dieses Konto ist verantwortlich für die Ausführung der SSP Timer Jobs. Dieses Konto sollte auch ein Domänen Konto und nicht ein „built in“ Konto sein. Wie etwa der Netzwerk Service.
Default Content Access Account Unter diesem Konto läuft der Indexer um den Inhalt zu „crawlen“. Dieses Konto hat per defaut lese und schreib Rechte auf alle Site Collections innerhalb der Farm. Wenn weitere Datenbanken durchsucht werden müssen wie etwa Exchange Public Folder, muss sichergestellt werden, dass dieses Konto die Berechtigung auch auf diese Quellen hat. Wenn das nicht möglich sein sollte, kann man in den „Crawl Rules“ für die Datenbank ein spezielles Konto für diese Datenbank definieren.
Profile Import default Access Acount Dieses Konto gibt es zwar. Standardmässig wird aber der „Deafult Content Access Account“ benutzt. Dieses Konto wird auch benutzt um Benutzer Profile aus dem AD in das Profile System von SharePoint zu importieren.
Excel Service unattended Service Account Dieses Konto wird benutzt, wenn für den Empfang von Daten keine andere Benutzer Credentials definiert worden sind. So zum Beispiel aus dem SSO System.

Farm Administrator Konten und die Farm Administrator Gruppe

Farm Administrator Standardmässig ist das Konto das SharePoint installiert, der Farm Administrator. Dieses Konto hat Zugriff auf die Zentral Administration und alle ihre Funktionen. Dieses Konto hat auch die Berechtigung weitere Konten zu der Gruppe der Farm Administratoren hinzuzufügen.
Server Administrator Hat die Berechtigung über den lokalen Server. Es gibt Gegebenheiten in denen man Farm Administrator wie auch Server Administrations Rechte braucht. So etwa wenn man eine neue Web Applikation oder einen neuen Application Pool erstellen möchte. Man braucht ebenfalls beide Konten wenn man ein SSP löschen möchte. Es gibt aber nicht viele solche Task in denen man beide Konten braucht.

Passwörter ändern

Wenn Passwörter geändert werden müssen, ist das nicht ganz so trivial unter SharePoint. Die Einstellungen der Konten liegen an diversen Orten verstreut. Grundsätzlich gilt, wenn die folgenden Konten Passwörter geändert wurden, müssen diese in SharePoint nachgetragen werden.

  • SQL Server Account
  • Application Pool Account
  • Search Service Account
  • Share Service Provider Account
  • Single Sign-On Account
  • Profile Import Account

In der Zentral Administration gibt es zwar eine grafische Oberfläche um einige Konten zu konfigurieren jedoch nicht alle. Die Einstellungen findet man unter: Central Administration -> Operations -> Service Accounts (Abbildung 1)

secure_1.jpg
Abbildung 1

Application Pool Konten müssen im IIS Manager konfiguriert werden (Abbildung 2)

secure_2.jpg
Abbildung 2

Alle an anderen Einstellungen müssen in der Zentral Administration nachgetragen werden. Es gibt zwar zwei STSADM.EXE Funktionen die nennen sich „UpdateFarmCredentials“ und „UpdateAccountPassword“. Diese ändern aber nur Konto und/oder Passwort des Farm Administrators und das der Web Applikation.

SharePoint Inhalt Absichern

SharePoint unterstützt verschiedene Methoden für die Authentifizierung. Diese sind: Basic, NTLM, Kerberos. ASP.NET Form Based Authentication und Web SSO. Ich möchte hier nicht auf diese eingehen, sondern diesbezüglich ein paar Sicherheitsaspekte genauer betrachten.

Zonen für Web Applikationen

Jede Web Applikation die erstellt wird, erhält standardmässig die Zone „default“ zugewiesen. Web Applikationen können aber erweitert werden und können so über Zonen hinweg trotzdem auf denselben Inhalt zugreifen (Abbildung 3). Über diese Zonen Definitionen können dann unterschiedliche Authentifizierungsmechanismen verwendet werden (Abbildung 4). So können zum Beispiel die Extranet Benutzer in einer SQL Datenbank verwaltet werden und die Intranet Benutzer im Active Directory selber. Trotzdem muss der Inhalt nicht zwischen unterschiedlichen Web Applikation hin und her synchronisiert werden.

 secure_3.jpg
Abbildung 3

secure_4.jpg
Abbildung 4

Unterschiedliche Zonen, müssen dabei unterschiedliche URL’s haben. Das Handling dieser unterschiedlichen URL für die vorhandenen Zonen geschieht dabei über „Alternate Access Mapping“. Dadurch wird die originale URL zurück gerendert auf die dem Benutzer und Zone entsprechenden URL.

Benutzer und Gruppen Berechtigungsstufen anpassen

Benutzerrechte werden in SharePoint am einfachsten über Benutzergruppen und Berechtigungsstufen verwaltet:

Benutzer Gruppen (User Groups) Eine Gruppe von Benutzern die auf der Seite eine gewisse Rolle einnehmen
Berechtigungsstufe (Permissions Levels) Eine Definition von Berechtigung

Innerhalb einer Site Collection können, neben den standardmässigen Gruppen, neue Gruppen definiert werden. Diesen Gruppen kann man über die Listen Einstellungen in „Benutzer und Gruppen“ weitere Berechtigungsstufen hinzufügen (Abbildung 5)

secure_5.jpg
Abbildung 5

Diese Berechtigungsstufen sind dabei sehr fein granulierbar (Abbildung 6). Zum Beispiel; darf eine Liste erstellen, oder darf eine Ansicht erstellen.

secure_6.jpg
Abbildung 6

Die Benutzer werden dann entweder einzeln einer Gruppe hinzugefügt, oder basierend auf einer bestehenden Active Directory Gruppe.

Server Hardening

Mal abgesehen von den klassischen Tips wie Virusschutz aktivieren (ausser auf dem Indexer) und „IIS lockdown„, macht es zusätzlich vor allem Sinn auf dem Datenbank Server ein paar Vorkehrungen zu treffen.

Windows Integrated Seit MOSS 2007 kann man nun auch mit Windows Integrated Security verwenden um Front End und andere Server mit dem SQL zu verbinden. Wenn man SQL Security brauchen muss, sollte man auf jeden Fall darauf achten, dass die Verbindung verschlüsselt ist und das im web.config die entsprechenden Einträge ebenfalls verschlüsselt sind.
Keine Standard Ports Wenn SQL Server in der DMZ stehen, macht es durchaus Sinn die Standard Ports nicht zu verwenden.
SQL Alias auf den Web Front End Servers Die SQL Alias die man auf dem SQL Server angelegt hat, nachdem man die Standard Ports um konfiguriert hat, müssen auf jedem Front End Server (und andere) natürlich auch eingetragen werden. Ansonsten kann die SQL Instanz nicht mehr angesprochen werden.

Autor: Christoph Müller

Christoph Müller ist Consultant, Blogger und Podcaster rund ums Thema SharePoint, Digital Transformation, Cloud, Mobile und Netzpolitik.

Kommentare sind geschlossen.