Sicherer Betrieb von SharePoint 2013 - Logische Absicherung

Article
11/18/2014

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:

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.
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.
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.
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.
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:

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.

Share via