Minimale Berechtigungen für Dienstkonten bei Sharepoint 2010, Teil 1
6. Mai 2010
In den letzten Jahren haben sich Unternehmen das Sicherheitskonzept “Least Privilege” zu eigen gemacht. Dabei bekommt ein Konto immer nur gerade so viele Rechte eingeräumt, wie es für die Bewältigung der anstehenden Aufgabe(n) notwendig ist. Dieses Konzept der „minimal nötigen Berechtigungen“ hat sich für viele Bereiche als sehr sinnvoll erwiesen:
Die generelle Sicherheit der IT-Infrastruktur profitiert davon, Überwachungsaufgaben (also das Auditing) gestalten sich einfacher und nicht zuletzt lassen sich Regularien oder spezielle Vorgaben – Stichwort Compliance – besser einhalten. Dabei darf man eines nicht außer Acht lassen: Least Privilege sollte sich nicht nur auf die Konten von „echten“ Benutzern beziehen, sondern auch die Dienstkonten (Service Accounts) mit einschließen.
Dieses Thema spricht der Autor Dan Holme intensiv auf dem zweitägigen Workshop zu Sharepoint Server 2010, den Dan Holme MasterClasses an. Anmeldiungen dazu sind zum Frühbucherpreis im Mai 2010 noch möglich.
Generell empfiehlt es sich für Unternehmen, den Dienstkonten eine größere Aufmerksamkeit zu widmen. In vielen Organisationen gibt es immer noch die Option, dass für ein Dienstkonto angelegt wird und dann für dieses Konto das Kennwort niemals abläuft. Die Sicherheitsrichtlinien von Unternehmen sollten dieser Konfiguration einen Riegel vorschieben und ein derartiges Vorgehen explizit verbieten. Denn mit einer derartigen Einstellung öffnet man Angreifern Tür und Tor.
Speziell wenn man Sharepoint Server 2010 in seinem Unternehmen einsetzen möchte, kann man das Konzept der “Least Privilege” umsetzen. Dazu gehört dann auch das Verwalten der Sharepoint-Dienstkonten. Der primäre Fokus in diesem Beitrag liegt auf der Vermeidung von häufigen Fehlern, die im Umfeld des SQL Servers, der Sharepoint-Verwaltung und von Konten für Server-Farmen gemacht werden. Zudem ist einiges an Verwirrung aufzuklären – dabei stammt diese Verwirrung nicht zuletzt von dem Assistenten, der für das Setup von Sharepoint verantwortlich zeichnet.
Microsoft beschreibt zwar die Verwaltungs- und Dienstkonten, die für das erstmalige Aufsetzen von Sharepoint Server 2010 nötig sind. Doch dabei werden einige wichtige Dinge übersprungen. Daher sollen diese drei Konten in diesem zweiteiligen Beitrag genauer herausgestellt werden.
Das Konto für den SQL-Server-Dienst
Das erste Dienstkonto, das unter Sharepoint zu installieren ist, ist ein SQL-Server-Dienstkonto. Im weiteren Verlauf soll es die Bezeichnung SVC_SQL als Benutzername tragen. Bei der Installation des SQL Servers wird dieses Konto den Diensten MSSQLSERVER und SQLSERVERAGENT zugewiesen.
Es mag durchaus möglich sein, dass in einigen enger gefassten Einsatzszenarien man ein lokales Konto oder ein Dienstkonto dafür verwenden kann. Doch die beste Vorgehensweise lautet hier: Ein Benutzerkonto ist einzusetzen, das in der Active-Directory-Domäne liegt. Dieses Konto sollte nach den üblichen Sicherheitsrichtlinien des Unternehmens abgesichert werden.
Mittlerweile besitzt das Active Directory (AD) bei den neueren Windows-Server-Versionen die Möglichkeit, sehr feingliedrige Kennwort-Richtlinien vorzugeben. Des Weiteren gibt es die Managed Service Accounts (MSAs, Verwaltete Dienstkonten, die ab Windows Server 2008 Release 2 und Windows 7 ins Spiel kommen), die bereits in einer zweiteiligen Artikelreihe vorgestellt wurden. Das Prinzip dahinter verdeutlicht der erste Teil, der zweite kümmert sich um das Arbeiten mit den MSAs.
Die feingliedrigen Kennwort-Richtlinien erlauben es, stärkere und komplexere Kennworte zu verwenden, öfter einen Wechsel der Kennwörter zu erzwingen und das vor allem für besonders wichtige Konten vorzugeben – wie zum Beispiel die MSAs. Die verwalteten Dienstkonten dagegen helfen beim Kennwortwechsel und vereinfachen diese Aktion. Eine Neukonfiguration eines Dienstes ist dabei nicht mehr nötig. Somit brauchen Administratoren nicht mehr auf die Option „Kennwort läuft nie ab“ zurückgreifen.
Speziell SVC_SQL benötigt keine besonderen Berechtigungen – und sollte somit auch nichts Derartiges zugewiesen bekommen. Die nötigen Berechtigungen werden im Verlauf des Setups für den SQL Server zugewiesen.
Das Konto für den Setup User
Das nächste Benutzerkonto für Sharepoint ist das Konto, an dem man sich am Server anmeldet, um Sharepoint zu installieren – sprich „Setup User Account“. Es soll im weiteren Verlauf die Bezeichnung SP_Admin tragen. Sind alle Vorbereitungen für die Installation von Sharepoint getroffen, meldet sich der Administrator als SP_Admin an und startet den Assistenten für die Konfiguration von Sharepoint (SharePoint Products Configuration Wizard).
Auch alle Aktualisierungen sowie Patches nach der erfolgreichen Installation oder das Einspielen von Erweiterungen – wie etwa spezielle Language Packs – sollte man über dieses Konto ausführen. Generell ist dieses Konto für das Verwalten der kompletten Sharepoint-Server-Farm sinnvoll und hat dazu auch alle nötigen Berechtigungen.
Dazu sollte der Administrator ein Domänenbenutzer-Konto anlagen und es jeder lokalen Administratorgruppe eines jeden Sharepoint-Servers in der Sharepoint-Server-Farm hinzufügen. Dabei darf es – wegen der Least-Privilege-Vorgabe – über keine besonderen Rechte auf dem SQL-Server-System verfügen, solange der SQL-Server auf anderen Systemen als den Sharepoint-Server(n) läuft. Anders ausgedrückt: Agiert der SQL Server auf einem eigenen (virtuellen oder physischen) System, darf der SP_Admin keinen administrativen Durchgriff auf den SQL Server haben.
Allerdings benötigt der SP_Admin durchaus einige Berechtigungen auf dem SQL Server. Beim Setup von Sharepoint und der Konfiguration mit dem Konto SP_Admin verwenden die Setup- und Psconfig.exe-Prozesse die entsprechenden Anmeldeinformationen, um die Datenbanken anzulegen und SQL-Anmeldungen für die Sharepoint-Konten zu erstellen.
Ehe der Administrator das Sharepoint-Setup ausführt, muss das Konto SP_Admin die Serverrollen securityadmin und dbcreator auf den SQL Server zugewiesen bekommen. Des Weiteren benötigt SP_Admin auch die Datenbankrolle SharePoint_Shell_Access für jede Datenbank, die man mit Hilfe der Windows-Powershell erzeugen oder ändern möchte. Diese Rolle entspricht derzeit zwar dem dbowner, wird aber als eine eigene Rolle geführt.
Das eigene Admin-Konto bleibt außen vor
Und hier gilt es für den Administrator besonders aufzupassen: Er sollte Sharepoint nicht von seinem eigenen administrativen Konto aus installieren! Denn das Konto SP_Admin wird praktisch gesehen zur kompletten Oberhoheit, dem „Owner“, der Sharepoint-Farm. Zum Beispiel wird das Konto zum dbowner der Sharepoint-Config-Datenbank.
Und es gibt eine Vielzahl von anderen Stellen, an denen das Konto und die zugehörige Mail-Adresse in die Farm integriert werden. Daher empfiehlt sich ein spezielles SP_Admin-Konto, damit die Sharepoint-Farm nicht von einem Konto beherrscht wird, das anderweitige, privilegierte Rechte besitzt.
Im zweiten Teil des Beitrags (zugängig für Abonnementen von www.nt4admins.de) sowie am Sharepoint-Tag der Dan Holmes MasterClasses 2010 stellt der Referent weitere wichtige Konten für das Arbeiten im Umfeld von Sharepoint Server 2010 vor.events/dan-holmes-masterclasses-2010.ht
