FinServ: So implementierst du die Funktion zur Aufgabentrennung von GitLab

Während der gesamten Softwareentwicklung sind robuste Sicherheits- und Compliance-Maßnahmen erforderlich, insbesondere in Branchen wie Finanzdienstleistungen, in denen Datenintegrität und Einhaltung der Vorschriften nicht verhandelbar sind. Ein kritischer Aspekt bei der Einhaltung dieser Standards ist die Aufgabentrennung (SoD, "Segregation of Duties").

SoD stellt sicher, dass keine Person die vollständige Kontrolle über einen Prozess vom Anfang bis zum Ende hat, wodurch das Risiko von Fehlern und unbefugten Aktivitäten verringert wird. SoD verringert die Risiken der Software-Lieferkette, indem externe und böswillige Handlungen verhindert werden, die die Integrität des Softwareentwicklungsprozesses beeinträchtigen könnten.

Bedeutung von SoD in der Finanzdienstleistungsbranche

Im Finanzdienstleistungssektor spielt SoD eine entscheidende Rolle beim Schutz sensibler Informationen und der Einhaltung der Vorschriften. So trägt SoD strategisch zur Branche bei:

• Risikominderung: Durch die Verteilung der Verantwortlichkeiten auf verschiedene Rollen verringert SoD das Risiko von Fehlern, Betrug und unbefugten Aktivitäten, die die Systemintegrität oder die Einhaltung der Vorschriften beeinträchtigen könnten.
• Verbesserte Verantwortlichkeit: Eine klare Aufteilung der Aufgaben garantiert, dass keine Person einen Prozess von Anfang bis Ende unabhängig initiieren, autorisieren und ausführen kann. Dies fördert Transparenz und Verantwortlichkeit, die für die Aufrechterhaltung des Vertrauens bei Stakeholdern und Aufsichtsbehörden von entscheidender Bedeutung sind.
• Einhaltung der Vorschriften: SoD ist durch die Finanzvorschriften vorgeschrieben, sodass sensible Vorgänge unter Aufsicht und Kontrolle durchgeführt werden. Die Einhaltung dieser Standards vermeidet nicht nur Strafen, sondern schützt auch den Ruf des Unternehmens.
• Betriebliche Widerstandsfähigkeit: Durch die Dezentralisierung der Entscheidungsfindung und -ausführung werden Unternehmen weniger anfällig für Störungen, die durch menschliche Fehler, böswillige Handlungen oder unerwartete Ereignisse verursacht werden.

GitLab für SoD und Best Practices

GitLab bietet eine durchgängige Aufgabentrennung für den DevSecOps-Workflow.

Das obige Diagramm veranschaulicht die Integration von Schlüsselelementen wie Genehmigungsrichtlinien für die Genehmigung von Merge Requests, geschützte Funktionen, Benutzerberechtigungen, Compliance-Frameworks und Audit-Ereignisse, die alle zusammenarbeiten, um die Prinzipien von SoD aufrechtzuerhalten. Jede dieser Komponenten wird in den folgenden Abschnitten beschrieben und zeigt, wie man eine sichere und konforme Entwicklungsumgebung einrichtet.

Merge-Request-Genehmigungsrichtlinien

Eine Herausforderung für die Finanzdienstleistungsbranche ist die Implementierung von Genehmigungsmechanismen, die verhindern, dass unbefugte oder unkontrollierte Änderungen integriert werden. Hier kommen Merge-Request-Genehmigungsrichtlinien ins Spiel. Diese Richtlinien erzwingen die Aufgabentrennung zwischen Sicherheit und Entwicklung und verhindern, dass einzelne Entwickler(innen) ihre eigenen Codeänderungen genehmigen, wenn sie Schwachstellen enthalten, und dass Entwicklungsteams ihren Code ohne angemessene Aufsicht direkt in Produktivumgebungen bereitstellen.

Bei der Erstellung einer Richtlinie ist es ratsam zu überlegen, wer eine geeignete Person für die Genehmigung wäre. Dies kann als ein(e) einzelne(r) Benutzer(in), eine Gruppe wie das Anwendungssicherheitsteam oder ein Rollentyp wie ein(e) Betreuer(in) definiert werden. Um weitere Einschränkungen zu implementieren, beachte bitte diese wichtigen Richtlinienmerkmale:

• Verhindern der Genehmigung durch den bzw. die Autor(in): Diese Richtlinie legt Leitlinien fest, sodass ein(e) Merge-Request-Autor(in) seine eigenen Änderungen nicht genehmigen kann. Indem diese Richtlinie eine unabhängige Überprüfung erfordert, hilft sie, Objektivität und Unparteilichkeit im Genehmigungsprozess aufrechtzuerhalten.

• Verhindern von Genehmigungen durch Benutzer(innen), die Commits hinzufügen: Benutzer(innen), die Commits zu einem Merge Request hinzugefügt haben, werden ebenfalls daran gehindert, diesen zu genehmigen. Dadurch wird das Prinzip der unabhängigen Überprüfung weiter durchgesetzt, sodass Änderungen von Teammitgliedern überprüft werden, die nicht direkt an den Änderungen beteiligt sind.

• Verhindern des Bearbeitens von Genehmigungsregeln: Um die Integrität des Genehmigungsprozesses aufrechtzuerhalten, ermöglicht GitLab Administrator(inn)en, das Bearbeiten von Genehmigungsregeln auf Projekt- oder Merge-Request-Ebene zu verhindern. Dies garantiert, dass einmal definierte Genehmigungsrichtlinien nicht von unbefugten Benutzer(inne)n umgangen oder geändert werden können.

• Benutzerpasswort zum Genehmigen anfordern: Für eine zusätzliche Sicherheitsebene kann GitLab von Benutzer(inne)n verlangen, dass sie ihr Passwort eingeben, um einen Merge Request zu genehmigen.

Um eine klare Aufgabentrennung aufrechtzuerhalten, ist es ratsam, eine separate Hauptgruppe zu erstellen, die sich mit der Unterbringung deiner Sicherheitsrichtlinien befasst, einschließlich der Richtlinien für die Genehmigung von Merge Requests. Dieses Setup minimiert die Anzahl der Benutzer(innen), die Berechtigungen erben, und erzwingt eine strengere Kontrolle über die Richtlinienverwaltung. Von dieser separaten Gruppe aus kannst du auf der höchsten Gruppenebene, die mit deinen Zielen übereinstimmt, den Verwaltungsaufwand für Richtlinien reduziert und eine umfassende Abdeckung Ihrer Entwicklungsumgebung bietet, Sicherheitsrichtlinienprojekte verlinken.

Du solltest auch beachten, dass eine Richtlinie, die standardmäßig aktiviert ist, für alle Projekte innerhalb der verlinkten Gruppen, Untergruppen und einzelnen Projekte gilt. Wenn du Richtlinien selektiver durchsetzen möchtest, empfiehlt GitLab, deine Richtlinien auf ein Compliance-Framework-Label auszudehnen. In der Regel werden unsere stark regulierten Kund(inn)en Compliance-Labels entwerfen, die den regulatorischen Anforderungen entsprechen, wie „SOX“ und „PCI“. Dieser Link zu einem Framework ermöglicht es dem nativen Compliance-Center auch, Sicherheitsrichtlinien zu verwalten, die auf verschiedene Anwendungsfälle zugeschnitten sind.

Compliance-Frameworks und -Kontrollen

Kund(inn)en in regulierten Branchen stehen vor großen Herausforderungen bei der Einhaltung der Vorschriften in großen Unternehmen. Manuelle Prozesse sind fehleranfällig, und die konsistente Durchsetzung von Richtlinien über Teams hinweg kann schwierig sein.

Durch die Verwendung der Compliance-Frameworks von GitLab können Unternehmen Präventionsmaßnahmen automatisieren und verwalten, Risiken systematisch verwalten und die Einhaltung gesetzlicher Vorschriften nahtlos durchsetzen. Diese Frameworks können Sicherheitsprotokolle und benutzerdefinierte Jobs in jeder Pipeline erzwingen.

Um die Compliance-Einstellungen auf Organisationsebene zu schützen, ermöglicht GitLab nur Gruppen- oder Projekteigentümer(innen), Compliance Frameworks hinzuzufügen oder zu entfernen. Diese Maßnahme verhindert, dass Entwicklungsteams oder Führungskräfte Compliance-Konfigurationen ohne die entsprechenden Berechtigungsstufen ändern, und bietet auf diese Weise eine zusätzliche Sicherheitsebene. Dabei sollte Folgendes beachtet werden: Wenn Personen mit Betreuerberechtigung eine Untergruppe erstellen können, werden sie zu Eigentümer(innen) der jeweiligen Untergruppe und können das Compliance-Framework ändern. Dies kann verhindert werden, indem begrenzt wird, welche Personen Untergruppen erstellen können, und zwar unter den Berechtigungen und Gruppeneinstellungen.

SoD durch Berechtigungen und Rollen

Um die Aufgabentrennung in der Finanzdienstleistungsbranche auf effektive Weise durchzusetzen, ist entscheidend, dass eine klare und präzise Zugriffskontrolle etabliert wird. GitLab bietet ein abgestuftes Berechtigungsmodell mit vordefinierten Rollen, zum Beispiel Gast, Reporter(in), Entwickler(in), Betreuer(in) und Eigentümer(in). Jede Rolle verfügt über eine bestimmte Reihe von Berechtigungen, damit Personen ihre Aufgaben erfüllen können, ohne Grenzen zu überschreiten, was wiederum zu Interessenskonflikten oder Sicherheitsrisiken führen könnte. GitLab empfiehlt eine entsprechende Zuweisung der jeweiligen Rollen für einen Zugriff gemäß dem Prinzip der geringsten Privilegien.

Was Unternehmen mit granularen Anforderungen betrifft (dies gilt besonders für alle, die GitLab Ultimate nutzen), bieten benutzerdefinierte Rollen noch mehr Flexibilität. Diese Rollen ermöglichen Unternehmen, spezifische Berechtigungen festzulegen, die ganz auf ihre individuellen Workflows und Compliance-Anforderungen zugeschnitten sind. Dies ist besonders nützlich, wenn es darum geht, die Aufgabentrennung durchzusetzen, da auf diese Weise keine Person unvereinbare Aufgaben ausführen kann.

Ein gängiger Anwendungsfall ist die Notwendigkeit einer Bereitstellungsrolle – dies betrifft Personen, die Jobs bereitstellen müssen, aber keinen Zugriff für das Bearbeiten oder Pushen von Code haben sollten. GitLab berücksichtigt diese Anforderung durch den Einsatz von geschützten Umgebungen. Geschützte Umgebungen ermöglichen dir, Gruppen einzuladen, die zur Bereitstellung von Jobs zugelassen wurden, während die Rolle der Nutzer(innen) auf Reporter(innen) beschränkt wird. Dabei sollte beachtet werden, dass der Bereitstellungsjob auch das Keyword für die Umgebung umfassen sollte. Mit dieser Konfiguration können Nutzer(innen) Jobs bereitstellen, ohne den Code bearbeiten zu können. Damit wird sichergestellt, dass die Compliance-Anforderungen erfüllt werden.

Durch sorgfältige Festlegung und Durchsetzung von Rollen und Berechtigungen können Unternehmen eine sichere und konforme Entwicklungsumgebung schaffen. Wenn du deine Berechtigungen für Nutzer(innen) in einem breiteren Rahmen überprüfen möchtest, kannst du diesen Bericht für Gruppenmitglieder nutzen, um festzustellen, wie viele Mitglieder einer Rolle in deiner Umgebung sind, und die nächsten Schritte entsprechend beurteilen.

Geschützte Funktionen

GitLab bietet mehrere „geschützte” Funktionen, mit denen zusätzliche Ebenen für die Kontrolle über deinen Entwicklungsprozess durchgesetzt werden können. Diese Funktionen können entscheidend für die Aufrechterhaltung der SoD sein, sodass nur bestimmte Personen wesentliche Änderungen vornehmen können.

• Geschützte Branches: Ein geschützter Branch beschränkt, welche Personen zum Branch pushen oder zusammenführen oder einen Push erzwingen können. Dies ist besonders vorteilhaft für Branches wie „Main“ oder „Produktion“. So können nur autorisierte Nutzer(innen) Änderungen vornehmen.
• Geschützte Git-Tags: Diese Tags ermöglichen Kontrolle darüber, welche Personen zur Erstellung von Tags berechtigt sind. Dies verhindert versehentliche Updates oder Löschungen, nachdem das Tag erstellt wurde, sodass die Integrität deiner Versionsverwaltung erhalten bleibt.
• Geschützte Umgebungen: Der Schutz bestimmter Umgebungen (besonders Produktionen) vor unbefugtem Zugriff ist unerlässlich. In einer geschützten Umgebung können nur Nutzer(innen) mit den entsprechenden Berechtigungen bereitstellen, wodurch die Umgebung vor unbeabsichtigten Änderungen geschützt wird. Dies basiert auf der bereits erwähnten Funktionalität der Bereitstellungsrolle, bei der Personen zwar Jobs bereitstellen, aber den Code nicht bearbeiten können, sodass Compliance und Sicherheit gewährleistet werden.
• Geschützte Pakete: Mithilfe von Schutzregeln für Pakete wird eingeschränkt, welche Nutzer(innen) Änderungen an deinen Paketen vornehmen können. Diese geschützten Funktionen tragen zusammen zur Aufrechterhaltung einer sicheren und konformen Entwicklungsumgebung bei, die mit den Grundsätzen der SoD übereinstimmt.

Audit Event und Compliance Center

Nachdem wir nun die Approvalrichtlinien, Compliance Frameworks, Rollen und geschützten Funktionen behandelt haben, kommen wir zum letzten Schritt: die Frage, wie du mithilfe von GitLab diese Implementierungen überwachen und überprüfen kannst, um die Einhaltung sicherzustellen.

GitLabs Audit Events bieten Eigentümer(innen) und Administrator(innen) eine detaillierte Aufzeichnung der Aktivitäten und Änderungen, darunter die Aktivität der Nutzer(innen) und Projektänderungen. Diese Protokollierung ist entscheidend, wenn es darum geht, die Aktionen der Nutzer(innen) zu verfolgen und unbefugtes Verhalten zu erkennen.

Das Streaming von Audit Events verbessert diesen Aspekt zusätzlich, indem es Unternehmen ermöglicht, Audit Events zur Echtzeitanalyse und Alarme an externe Systeme zu streamen. Auf diese Weise werden jegliche Änderungen oder Verstöße erkannt, was wiederum eine schnelle Behebung ermöglicht.

Das Compliance Center in GitLab ist ein zentraler Punkt für die Verwaltung und Überwachung von Compliance-Aktivitäten. Es bietet einen Überblick zum Compliance-Status über diverse Projekte und Gruppen hinweg und zeigt Verstöße gegen die Approvalregeln für Merge Requests oder andere Richtlinien. Administrator(innen) können Probleme direkt beheben und sich vergewissern, dass die vordefinierten Compliance-Standards eingehalten werden. Dieser zentralisierte Ansatz vereinfacht das Compliance-Management, wobei ein hohes Maß an Beaufsichtigung und Kontrolle gewährleistet wird.

Weitere Informationen von GitLab zu den Themen SoD und Compliance findest du unter GitLab-Regulierung der Produktrichtung und der GitLab-Compliance-Dokumentation.

Weiterlesen

• Erfülle regulatorische Standards mit dem Compliance- und Sicherheitsrichtlinien-Management von GitLab (Englischsprachiger Artikel)
• Die Erstellung von GitLab mithilfe von GitLab: Erweiterung unseres Portfolios an Sicherheitszertifizierungen (Englischsprachiger Artikel)
• Der Online-Händler Bol erfüllt die wachsenden Compliance-Anforderungen mit GitLab (Englischsprachiger Artikel)