Bei Entwicklungsteams, welche im stark regulierten Umfeld tätig sind, entstehen an das Berechtigungskonzept für die Quellcodeverwaltung aus diversen Gründen spezielle Anforderungen. Eine Anforderung aus diesen Umfeld lautet beispielsweise:
Ist es möglich einem Teil der TFS-Administratoren des Leserecht auf den Quellcode in einem besonders zu schützenden Bereich der Quellcodeverwaltung zu entziehen?
Die Kurzfassung der Antwort lautet: Ja, es ist möglich. Kommt noch der Faktor Revisionssicherheit der Lösung hinzu, dann müssen noch zusätzliche Schritte eingeplant werden.
Zu Beginn steht die Frage im Raum: Git oder Team Foundation Version Control (TFVC)? Für das beschriebene Szenario ist Git weniger gut geeignet, da hier nur eine Berechtigungsvergabe auf das komplette Repository möglich ist. TFVC hingegen unterstützt diverse Berechtigungsarten und eine feingranulare Steuerung bis auf Dateiebene herab.
Im Folgenden wird die Umsetzung der eingangs genannten Anforderung Schritt für Schritt auf Basis von TFVC beschrieben.
Um die Berechtigungen für den zu schützenden Quellcode-Ordner einzugrenzen, wird im ersten Schritt die einzugrenzende TFS‑Berechtigungsgruppe (z.B. TFS_Admins_Deny) hinzugefügt (siehe Screenshot 1).
Als nächster Schritt wird dieser Gruppe dann das Leserecht explizit verweigert (siehe Screenshot 2)
Mit einem „Verweigern“(Deny) werden den Mitgliedern einer Gruppe die Rechte explizit entzogen, auch wenn sie an anderer Stelle (z.B. durch eine andere Gruppe) gegeben wurden. Es gilt der Grundsatz: Verweigern ist stärker als zulassen.
Ein Sonderfall sind die Gruppen „Team Foundation Administrators“ und „Project Collection Administrators“. Diese Gruppen haben grundsätzlich automatisch überall in der Quellcodeverwaltung das Leserecht.
Für TFS Admin-Gruppen gilt das explizite Verweigern in den meisten Bereichen des TFS nicht. Es wird damit verhindert, dass sich Administratoren selbst aussperren können. Von dieser Regelung gibt es aber Ausnahmen. Eine dieser Ausnahmen betrifft die Quellcodeverwaltung. Es ist sozusagen die Ausnahme von der Ausnahme.
„In version control permissions, explicit deny takes precedence over administrator group permissions.” Quelle: https://www.visualstudio.com/de-de/docs/setup-admin/permissions#tfvc-permissions-object-level
Die Folge ist deshalb, dass ein Administrator als Mitglieder der TFS Gruppe TFS_Admins_Deny kein Read-Recht auf den schützenswerten Quellcode-Ordner hat.
Im Fall von z.B. Anwendersupport, kann ihm aber das Leserecht auf den Quellcode, kurzfristig wieder gewährt werden. Eine Möglichkeit wäre, den Administrator temporär aus der Gruppe TFS_Admins_Deny zu entfernen.
Damit ist die Hälfte der Anforderung umgesetzt. TFS Administratoren können tatsächlich aus der Quellcodeverwaltung ausgeschlossen werden. Das ist aber noch nicht revisionssicher, da ein eingeschränkter Administrator jederzeit wieder der TFS-Gruppe das Read-Recht geben oder die Gruppenmitgliedschaft ändern kann.
Es gibt zwei Möglichkeiten die fehlende Anforderung umzusetzen. Die zwei Möglichkeiten sind in nachfolgender Tabelle dargestellt:
Legende:
- Bei der ersten Lösung werden alle Administratoren der TFS-Gruppe TFS_Admins_Deny hinzugefügt. Dieser Gruppe muss das Read-Recht auf den zu schützenden Quellcode verweigert werden.
- Bei der zweiten Lösung wird auch die Gruppe TFS_Admins_Deny erstellt, aber nur die Limited-Administrators hinzugefügt. Dieser Gruppe muss auch das Recht „Manage permissions“ verweigert werden. Es wird noch eine weitere Administratoren Gruppe benötigt, die TFS_Limited_Admins. Dieser Gruppe wird der entsprechende Personenkreis hinzugefügt und alle Rechte wie der originalen Gruppe Team Foundation Administrators gegeben, bis auf die Rechte „Edit collection-level information“ und „Edit project-level information“. Im Anschluss werden alle Benutzer der TFS_Limited_Admins aus der Gruppe Team Foundation Administrators entfernt. Mit dieser Lösung ist sichergestellt, dass beide Personenkreise die benötigten Berechtigungen für die tägliche Arbeit besitzen und mit minimalem Aufwand auch für den geschützten Quellcodebereich temporär berechtigt werden können.
Für die erste Lösung ist es unabdingbar, dass Berechtigungsänderungen und Änderungen der Gruppenmitgliedschaften protokolliert werden. Nur dann kann nachvollzogen werden, wer wann wem welches Recht eingeräumt hat. Dies lässt sich nicht mit Board-Mitteln bewerkstelligen. Für diese Anforderung ist es notwendig eine serverseitige TFS-Erweiterung zu entwickeln. Die Sicherheits-Events müssen am serverseitigen Eventhandler (TFS Requestfilter) über die TFS API revisionssicher in einer extra Datenbank protokolliert werden.
Bei der zweiten Lösung ist eine Protokollierung der Gruppenmitgliedschaften nicht zwingend erforderlich. „Echte“ Administratoren besitzen hier sowieso nur noch als einzige das Recht Berechtigungen ändern zu dürfen und verfügen aufgrund des TFS Designs sowieso über einen Vollzugriff auf alle TFS Daten.
Das besprochene Szenario kann man noch erweitern. Am Ende dieses Blogposts soll dies aber lediglich als Anregung dienen: Unabhängig ob die Lösung 1) oder 2) gewählt wurde bleibt noch die Frage offen:
Auf welche Teile des Quellcodes haben eingeschränkte Administratoren während ihres Anwendersupportfalls zugegriffen?
An diesen Stellen bietet sich auch wieder der Weg über die TFS API in Kombination mit serverseitigen Eventhandler (TFS Requestfilter) an, damit die entsprechenden Zugriffe protokolliert werden können. Dies ist hier schon fast zwingend notwendig, damit das ganze Szenario rund wird und die Protokollierung lückenlos und durchgängig ist.
Fazit
Es ist mit ein paar Handgriffen möglich Administratoren aus definierten Bereichen der Quellcodeverwaltung (TFVC) auszuschließen. Die notwendigen Zugriffe lassen sich sowohl bei der Rechtevergabe, als auch beim Zugriff der Quellcodeverwaltung protokollieren. Der Aufwand darf nicht unterschätzt werden, da für einige Teile der Lösung eigene Erweiterungen (serverseitiger TFSRequestfilter) geschrieben werden müssen.
Unabhängig von dem aktuellen Blog-Post sollte bei dieser extremen Art von Anpassungen immer kritisch hinterfragt werden, ob der Aufwand in einem angemessenen Verhältnis zum Schutzbedürfnis steht. Anpassungen können schnell zu neuen Problemen, erhöhten Aufwänden für andere Anpassungen (Bsp. Builds) und unnötigen Fehleranalysen führen.
Für ein umfassendes Sicherheitskonzept ist die Problemstellung aus diesen Blog-Post nur ein kleiner Baustein einer Sicherheitsarchitektur. Weitere Themenfelder für eine solche Architektur und ungewollte Zugriffe auf TFS Informationen sind exemplarisch: direkter Remotezugriff auf den Server via Remote Desktop, bekannte Servicekonten und -Passwörter oder direkter Datenbankzugriff.
Der Nutzen von einem Sicherheitstor bleibt schnell auf der Strecke, wenn links und rechts davon nur ein gewöhnlicher Gartenzaun um das Haus gebaut wurde.