Welche Prozesse oder Tools ermöglichen die Aufgabentrennung, wenn Ingenieure Code bereitstellen und ausführen?

In stark regulierten Umgebungen wie dem Finanzdienstleistungssektor ist die Aufgabentrennung ein wesentlicher Mechanismus zur Vermeidung von Kollisionen zwischen Personen mit Entwicklungsverantwortung und Produktionsprivilegien.

Traditionell bedeutete dies, dass Entwickler Code entwickeln und dann an Operations übergeben. In vielen DevOps-Betriebsmodellen ist die Trennung zwischen Entwicklung und Operations jedoch zumindest verschwommen:

• In der SRE-Praxis ( Site Reliability Engineering) von Google gibt es eine separate SRE-Funktion in Google. Entwickler werden jedoch dazu gebracht, die SREs in Zeiten hoher Betriebslast zu stoppen.

• Im Modell "Sie erstellen es, Sie führen es aus" gibt es keine separate Operationsfunktion.

Nach monatelangen Recherchen zu den Ursachen eines Segregation-of-Duties-Mechanismus scheint es vorwiegend zu bestehen, um Sarbanes Oxley Section 404 : Bewertung des Managements der internen Kontrollen zu erfüllen :

(a) Erforderliche Regeln. Die Kommission schreibt Regeln vor, nach denen jeder gemäß Abschnitt 13 (a) oder 15 (d) des Securities Exchange Act von 1934 vorgeschriebene Jahresbericht einen internen Kontrollbericht enthalten muss, der

(1) die Verantwortung des Managements für die Einrichtung und Aufrechterhaltung einer angemessenen internen Kontrollstruktur und angemessener Verfahren für die Finanzberichterstattung angeben; und

(2) zum Ende des letzten Geschäftsjahres des Emittenten eine Beurteilung der Wirksamkeit der internen Kontrollstruktur und der Verfahren des Emittenten für die Finanzberichterstattung enthalten.

(b) Evaluierung und Berichterstattung der internen Kontrolle. Jede registrierte Wirtschaftsprüfungsgesellschaft, die den Prüfungsbericht für den Emittenten erstellt oder herausgibt, muss die von der Geschäftsführung des Emittenten vorgenommene Beurteilung der internen Kontrolle nach Buchstabe a bestätigen und darüber Bericht erstatten. Eine nach diesem Unterabschnitt ausgestellte Bescheinigung muss gemäß den vom Board herausgegebenen oder angenommenen Standards für Bescheinigungsaufträge ausgestellt werden. Eine solche Bescheinigung ist nicht Gegenstand eines gesonderten Auftrags.

Ausgehend von den Kommentaren ist es wichtig, einige Annahmen hervorzuheben, die ich mache:

• Ich denke hauptsächlich an Finanzdienstleistungen für den Massenmarkt, dh das Transaktionsvolumen ist hoch, aber relativ niedrig. Dies wäre im Gegensatz zu kommerziellen Finanzdienstleistungen, die ein anderes Transaktionswertprofil aufweisen.
• Das Online-Angebot eines Finanzinstituts besteht aus vielen Komponenten, die unterschiedliche Risikohinweise enthalten:
  • Geld verschieben - Verschieben von Geld zwischen Konten oder Überweisungen zwischen Konten verschiedener Eigentümer. Eine Operation, die sich mit der Bekämpfung von Geldwäsche, Betrugsbekämpfung und Embargoländern befasst, um nur einige zu nennen.
  • Kundenakquise - Weniger "riskant", da das Transaktionsvolumen im Vergleich zu Move Money gering ist, aber noch berücksichtigt werden muss.
  • Internet-Banking - Umfasst eine breite Palette von Diensten mit unterschiedlichem Risiko, wird Move Money als Teil davon betrachtet.
• Es ist vorstellbar, dass je nach Risiko ein anderer Ansatz gewählt wird. Um dies jedoch einfach zu halten, arbeite ich an einer Lösung, die für einige der riskantesten Vorgänge gilt.

TL; DR : Es liegt in der Verantwortung des Managements sicherzustellen, dass angemessene interne Kontrollen vorhanden sind, die den Vorschriften der Securities and Exchange Commission entsprechen .

Sarbanes Oxley 404 ist in der Regel durch die Durchführung einer Top-Down-Risikobewertung zufrieden, in der zum Teil das Risiko von Kollusionen bewertet und Strategien zur Schadensminderung vorgeschlagen werden.

In einem Unternehmen, das DevOps-Praxis und -Kultur einsetzt und in dem Entwickler routinemäßig sowohl auf die Quellcodeverwaltung als auch auf die Produktion zugreifen können, wie kann eine Aufgabentrennung erreicht werden, oder allgemeiner, wie kann das Risiko einer Kollusion verringert werden.

Ihre Frage scheint keine Vermutung über die Plattform / das Betriebssystem zu machen, um die es geht. Aus diesem Grund kann es sinnvoll sein, eine Antwort darüber hinzuzufügen, wie dies normalerweise in einer Mainframe-Umgebung getan / angegangen wird, in der die "Ingenieure" (wie in Ihrem Fragentitel) tatsächlich Gruppen von Menschen sind, die Dutzende (möglicherweise Hunderte) von Menschen sind beteiligt. Meine Antwort basiert auf der Verwendung des SCM-Produkts, mit dem ich am besten vertraut bin (ich bin nicht sicher, ob es zur Offenlegung des Produktnamens erforderlich ist).

---

1. Architektur

---

Hier sind die Highlights, wie ich Ihre Frage beantworten würde:

• Sämtlicher Code (und verwandte Artefakte wie ausführbare Dateien usw.) werden in Dateien gespeichert, die wir zusammen die Bibliotheksstruktur nennen .
• Für jede Umgebung auf jedem (möglicherweise entfernten) Zielsystem gibt es einen Server (eine "gestartete Task" in Mainframe-Sprache), der für ALLE (repeat: ALL) Aktualisierungen in der Bibliotheksstruktur sorgt. Es gibt einige Ausnahmen (wie Sicherheitspersonal oder Space-Management-Team), aber abgesehen davon hat niemand (wiederholen: niemand) die Berechtigung, Aktualisierungen auf Dateien in dieser Bibliotheksstruktur anzuwenden. Mit anderen Worten: Der Server erhält die exklusive Aktualisierungsberechtigung für die gesamte Bibliotheksstruktur . Achtung: OPS-Leute werden verrückt, wenn Sie hereinkommen, um ihren Zugang zu beschränken (zuerst werden sie Widerstand leisten ...). Stellen Sie also sicher, dass Sie vom oberen Management (CxO) gedeckt sind, um diese Zugangsregeln durchzusetzen ...
• Die eigentlichen Software-Änderungen bestehen aus einer einzelnen Komponente (einem winzigen Code-Fix mitten in der Nacht ...), oder es kann sich auch um Hunderte oder Tausende von Quellen, ausführbaren Dateien oder sonstigen Artefakten handeln (während eines Veröffentlichungswochenendes). Um sie handhabbar zu machen, werden Dinge, die gleichzeitig (mehr oder weniger) zusammen verschoben werden sollen, in einem sogenannten Software-Änderungspaket gebündelt .

Mit dem oben Gesagten ist jede Art von Aktualisierung, die vom Server auf die Bibliotheksstruktur angewendet werden soll, nur über einen genau definierten Workflow möglich, den wir den Lebenszyklus eines Software-Änderungspakets (SDLC, wenn Sie es vorziehen) nennen. Um die verschiedenen Schritte in diesem Workflow tatsächlich auszuführen, ist Folgendes erforderlich:

• Nur der Server führt die erforderlichen (und vorkonfigurierten) Schritte aus.
• Der Server wird nur einen bestimmten Schritt ausführen (= irgendwo in der Bibliotheksstruktur etwas aktualisieren), nachdem die erforderlichen Genehmigungen (von Menschen) gesammelt wurden, um einen solchen Schritt auszuführen.
• Die Genehmigungen können nur von Benutzern erteilt werden, die eine Rolle haben , mit der sie (= Berechtigung) solche Genehmigungen erteilen können.

---

2. Rollen und Berechtigungen

---

Der Server stellt sicher, dass der Benutzer, der versucht, etwas zu tun (z. B. "etwas zu genehmigen"), dies nur tun kann, wenn die Berechtigungen des Benutzers angemessen sind. Dieser Teil ist einfach. Sie möchten jedoch nicht das SCM-System verwenden, um alle diese Berechtigungen für alle beteiligten Benutzer zu verwalten. Dies gehört zu Ihrem Sicherheitssystem (nicht zum SCM-System!), Sodass Sie Ihren Workflow (in Ihrem SCM-System) anpassen können. Überprüfen Sie diese Berechtigungen, wann immer dies angebracht ist. Die folgenden Schritte enthalten einige weitere Details dazu.

Schritt 1: Konfigurieren Sie die Berechtigungen (im Sicherheitssystem)

• Definieren Sie Sicherheitseinheiten in Ihrem Sicherheitssystem, mit gut für diese Unternehmen definierten Namen. Einige Beispiele (fügen Sie so viele ähnliche hinzu, wie Sie möchten):

  • PrmUnit, Verwendet für die Erlaubnis bekommen ein zu beantragen Förderung sagen Einheit -Testen.
  • PrmQA, Für das Erhalten Genehmigung ein beantragen Förderung sagen Qa -Testen (nehmen wir an , das die höchste Stufe der Prüfung ist).
  • PrdEnduserwird von Endbenutzern verwendet, die an bestimmten Teststufen beteiligt sind, um anzuzeigen, dass sie mit den Ergebnissen zufrieden sind, die bei bestimmten Tests erzielt wurden. Aus diesem Grund stimmen diese Endbenutzer der voranschreitenden Änderung in der Bibliotheksstruktur zu.
  • PrdRelmgnt, wird von Release-Managern verwendet, um eine Aktivierung in der Produktion zu autorisieren (= die letzte / höchste Ebene in der Bibliotheksstruktur).

• Definieren Sie Benutzergruppen in Ihrem Sicherheitssystem. Einige Beispiele (fügen Sie so viele ähnliche hinzu, wie Sie möchten):

  • GrpDevs, was (sagen wir) Ihren Entwicklern entspricht (wahrscheinlich mehr als nur 1).
  • GrpEnduser, die (sagen wir) Ihren Endbenutzern entspricht (mindestens 1, vorzugsweise mit ähnlicheren Benutzern).
  • GrpRelMgnt, was (sagen wir) Ihren Release-Managern entspricht (mindestens 1, vorzugsweise ein paar mehr Benutzer).

• Gewähren Sie Berechtigungen , auch unter Verwendung Ihres Sicherheitssystems, um ausgewählten " Sicherheitsentitäten " Zugriff auf ausgewählte " Benutzergruppen " zu gewähren . Um mit dem obigen Beispiel fortzufahren, ist Folgendes angebracht (passen Sie es an Ihre eigenen Bedürfnisse an):

  • Gruppe GrpDevserhält Zugriff auf (nur!) Sicherheitseinheit PrmUnit.
  • Gruppe GrpEndusererhält Zugriff auf (nur!) Sicherheitseinheit PrdEnduser.
  • Gruppe GrpRelMgnterhält Zugriff auf (beide!) Sicherheitseinheit PrmQAund PrdRelmgnt.

Schritt 2: Konfigurieren Sie den Workflow (im SCM-System)

Nachdem die Berechtigungen in Ihrem Sicherheitssystem konfiguriert wurden (wie in Schritt 1), müssen Sie in Ihrem SCM-System nur noch konfigurieren, wie die verschiedenen Schritte im Lebenszyklus mit den zugehörigen Sicherheitseinheiten in Ihrem Sicherheitssystem übereinstimmen. Das heißt, nur die Benutzer, die über den entsprechenden Zugriff auf die erforderliche Sicherheitseinheit verfügen, dürfen den Server auffordern, den entsprechenden Schritt im Workflow auszuführen.

Hier einige Beispiele, wie Sie Ihr SCM-System so konfigurieren, dass etwas Magisches passiert:

• Wenn ein Benutzer Zugriff hat PrmUnit, dann ist eine solche Benutzer erlaubt eine beantragen Förderung zu Einheit -Testen. Offensichtlich sind die Benutzer in der Gruppe GrpDevsdie dazu berechtigten Benutzer (Hinweis: nicht zB die Benutzer in der Gruppe GrpRelMgnt).
• Wenn ein Benutzer Zugriff hat PrmQA, dann ist eine solche Benutzer erlaubt eine beantragen Förderung zu QA -Testen. Offensichtlich sind die Benutzer in der Gruppe GrpRelMgntdie dazu berechtigten Benutzer (Hinweis: nicht zB die Benutzer in der Gruppe GrpDevsoder in der Gruppe GrpEnduser).
• Wenn ein Benutzer Zugriff auf hat PrdEnduser, kann dieser Benutzer die Änderung in der Bibliotheksstruktur autorisieren (dies ist in der Regel eine Voraussetzung dafür, dass Benutzer in einer Gruppe GrpRelMgntsogar eine Änderung überprüfen können). Offensichtlich sind die Benutzer in der Gruppe GrpEnduserdie (einzigen) dafür autorisierten Benutzer.
• Wenn ein Benutzer Zugriff darauf hat PrdRelmgnt, kann dieser Benutzer eine Aktivierung in der Produktion (= die letzte / höchste Ebene in der Bibliotheksstruktur) autorisieren .

---

3. Erwarten Sie das Unerwartete und seien Sie bereit dafür

---

Das obige ist nur eine Blaupause, die hoffentlich hilft zu verstehen, wie letztendlich der Server für die Aufgabentrennung sorgt ... vorausgesetzt, Sie haben die CxO-Deckung, um einige Zugriffsregeln auferlegen zu können, die nicht jedem gefallen werden.

Um das Bild wie oben beschrieben zu vervollständigen, erstellt der Server einen Audit-Trail (Protokollierung) von allen Vorgängen im System. Damit ist es jederzeit möglich Fragen wie zu beantworten

Was ist wann und warum passiert und welcher autorisierte Benutzer hat es tatsächlich genehmigt ... im Voraus?

Am schwierigsten ist es jedoch wahrscheinlich, geeignete Berichterstellungstools zur Verfügung zu haben (und zu wissen, wie man sie verwendet). Zumindest, um Anfragen von IT-Auditoren (leicht) zu befriedigen (ihre Fragen können sehr herausfordernd sein). Sie können aber auch auf relevante Protokollsätze in Ihrem SCM-System verweisen, um alle Arten von "Was ist passiert" -Fragen in Krisensituationen zu beantworten, in denen (ein Teil der) Produktion ausfällt.

---

PS: Ich überlasse es jedem selbst, ob meine Antwort Ja oder Nein DevOps-konform ist.

Aufgrund meiner Kenntnisse der französischen "internen Kontroll" -Vorschriften, die den von Ihnen genannten SEC-Vorschriften in etwa entsprechen, gehe ich davon aus, dass eine Verknüpfung mit einem französischen Rechtstext hier nicht wirklich nützlich wäre und mir keine gute Übersetzung bekannt ist.

In einem idealen Modell "Sie bauen es, Sie führen es aus" ist jeder im Team für die Änderung verantwortlich. Die Risikobewertung kann nicht durch eine Aufgabentrennung erzwungen werden. Die einzige Möglichkeit, die Einhaltung der Vorschriften zu gewährleisten, besteht in einer regelmäßigen Prüfung der Transaktionen innerhalb eines kurzen Zyklus sowie einer unveränderlichen Verfolgung der Maßnahmen, um zu der Person zurückzukehren, die die Freigabe vorgenommen hat .
Dies bedeutet, dass alle Transaktions- und Aktionsprotokolle in einen eingeschränkten Bereich verschoben werden, auf den das Team keinen Zugriff hat, und dass eine Änderung der protokollierten Daten durch Funktionstests abgefangen wird, auf die das Team keinen Zugriff hat durch die Prüfung und verfolgt zu seinem Autor.

Dies gilt nicht für alle Produkte. Zum Zeitpunkt des Schreibens in Frankreich muss jedes Unternehmen, das Geld ausgeben darf (hauptsächlich Banken), sicherstellen, dass jede Transaktion erfasst wird, und kann daher nicht das Risiko eingehen, eine Transaktion zu verpassen.
Auf der anderen Seite besteht keine rechtliche Verpflichtung, ein kommerzielles Angebot oder eine Risikobewertung nachzuverfolgen, wenn jemand um einen Kredit bittet. Daher lassen sich die Produkte, die für diese Kundenauswahl und die Berechnung der Gebühren im Angebot zuständig sind, leichter in eine Stelle einfügen -Release-Audit-Modell.

Die Hauptidee ist, dass das Freigabemodell gemäß den Risikobewertungspflichten angepasst werden muss.

Eine verwandte Ressource ist die Norm ISO27001 .

IMHO, Developers & Operations könnten durch nichts anderes als zwei Git-Repositorys für dieselbe Codebasis mit jeweils unterschiedlichen Berechtigungsmodellen dargestellt werden, so dass Teams sich überhaupt nicht gegenseitig in die Arbeit einmischen.

Nennen wir sie Dev.mygithub.co & ops.mygithub.co , nur als Beispiel.

Die Idee ist, dass Entwickler können zum Erstellen / Zweig / merge Inhalt ihres Herzens -git vollständige Rückverfolgbarkeit bietet und das ist , was hier- mittlerweile zählt, in den Momenten , dass Rechtsrahmen impliziert eine Bewertung Aufwand Pull - Request kann angehoben werden, die Verschmelzung geschieht auf kontrollierte Weise.

Ein Entwicklungszweig, der dieses Konzept auf die nächste Stufe hebt, kann über einen weiteren Pull-Request- Act in die Produktion der Remote-Ops übertragen werden . Der letzte Teil muss durch die Hände und Augen des Betriebs geschehen, da sie die Verantwortung haben, ihn in die Produktion zu überführen, und sie den Überprüfungsgrad auswählen.

Ein solches System ermöglicht uneingeschränkte Flexibilität, vollständige Rückverfolgbarkeit, die frühzeitige Erkennung von Problemen über eine Vielzahl von Prozessen, die Trennung von Bedenken und eine sehr vernünftige Benutzererfahrung im Prozess !

NB Das oben beschriebene Modell kann befolgt werden, auch wenn sich Ops & Dev vollständig überlappen!

höher ist teurer:

• Unterschiedliche Entwicklungs- und Betriebsseiten und Methoden, um die Arbeit von einer zur anderen zu übertragen
• verschiedene dev and ops Systeme & Methoden wie oben
• verschiedene dev und ops git / vcs Repositories & verwandte Methoden
• verschiedene dev und ops git / vcs Zweige (geschützt) & verwandte Methoden

Je nachdem, was Sie tun, sind einige Lösungen besser als andere. Wenn Sie beispielsweise zwei Teams mit unterschiedlichen Rollen bedienen müssen, die jeweils Eigentümer sind und vollständige Nachverfolgbarkeit bieten, bewegen Sie sich über die ersten drei.

Kurz gesagt, alles, was einen Mann oder eine Frau dazu zwingt, kann den Ball nicht alleine nehmen und damit rennen, und er / sie überschreitet eine eindeutige explizite Grenze zwischen Entwicklern. Je nach Risikograd kann diese Grenze nun durchgesetzt werden oder nicht.