Was sind mögliche Implementierungen (oder Beispiele) des Vier-Augen-Prinzips?

Michael Grünewald hat diesen Kommentar kürzlich gepostet :

Eine sehr wichtige Methode, die Sie nicht erwähnen, ist das Vier-Augen-Prinzip, das in der Finanzierung angewendet wird - entweder als aufsichtsrechtliche Verpflichtung oder als Schutz. In der Softwareindustrie wird es auf verschiedene Arten implementiert, wie z. B. Codeüberprüfungen, kann aber auch zur Validierung von Befehlen verwendet werden, die sich auf Live-Systeme auswirken.

Korrigieren Sie mich, wenn ich falsch liege, aber mir wurde beigebracht, dass es sich beim "Vier-Augen-Prinzip" um etwas handelt, das "zugelassen" ist, nachdem mindestens 2 Menschen (und / oder automatisierte Prozesse) ihren vorherigen Segen gegeben haben. Oder um den (leicht korrigierten) Wortlaut über die "Zwei- (Wo-) Mann-Regel" aus Wikipedia zu verwenden :

Die Zwei-Mann-Regel ist ein Kontrollmechanismus, mit dem ein hohes Maß an Sicherheit für besonders kritische Materialien oder Vorgänge erreicht werden soll. Nach dieser Regel sind für alle Zugriffe und Aktionen immer zwei befugte Personen erforderlich.

Zwar sind regulatorische Auflagen hier nicht in Frage zu stellen, aber was sind im Zusammenhang mit "safe-guard" die möglichen konzeptionellen Implementierungen dieses Vier-Augen-Prinzips, die wahrscheinlich für jede Plattform / Betriebssystem / Hardware gelten könnten, die verwendet wird?

Eine der Implementierungen im Code ist das von GitHub verbreitete Pull Request Model (PR).

Der Hauptgrund dafür ist, dass nur eine kleine Gruppe von Betreuern des Produkts Code in den Release-Zweig einbinden darf. Jedes neue Feature / Bugfix findet in einem neuen Zweig statt und wird, sobald es fertig ist, als Pull-Anfrage definiert.

Dies ermöglicht es, die Zusammenführung von aktuellem Release-Code (Master-Code) mit dem Code in der PR auf automatische Weise zu testen (Travis ist derzeit das beliebteste öffentliche Projekt) und einen ersten Rückschluss auf die Codequalität zu geben. Travis CI kann beispielsweise auf dem Ergebnis des tatsächlichen Masters mit dem Code aus der darin zusammengeführten Pull-Anforderung ausgeführt werden. Wenn die Zusammenführung nicht möglich ist oder wenn die in travisci.yml definierten Befehle einen Exit ungleich Null zurückgeben, schlägt dies fehl Code

Nachdem die automatischen Tests für das 4-Augen-Prinzip bestanden wurden, muss noch eine konfigurierbare Anzahl von Personen die Änderung überprüfen und genehmigen, bevor sie zusammengeführt wird. Dies erfordert offensichtlich mindestens eine Person (die nicht der PR-Autor ist), um die 4-Augen-Überprüfung zu erzwingen Änderungen.

Es gibt eine Vielzahl von Optionen, die automatisch zusammengeführt werden können, sobald das Quorum der Prüfer erfüllt ist, oder die weiterhin manuell von einem Betreuer zusammengeführt werden müssen.

Die Berechtigungen zum Überprüfen und Zusammenführen können getrennt werden, wodurch mehr Personen das Recht erhalten, über den Zusammenführungsstatus abzustimmen, während die Möglichkeit erhalten bleibt, einzuschränken, wer die Zusammenführung tatsächlich durchführen kann.

Code-Überprüfungen

Es geht darum, dass mindestens eine andere Person den von jemandem geschriebenen Code betrachtet, um beispielsweise zu bewerten, ob er vordefinierten Kriterien entspricht, wie:

• Kodierungsstandards (Einrückungen usw.).
• Inline-Dokumentation.
• Wartbarkeit des Codes.
• Fehlerbehandlung.
• Vollständigkeit (zB if/then/elseoder case/whenKonstrukte decken alle möglichen Fälle ab).

Genehmigungen zum Aktualisieren einiger Zielumgebungen

Hier geht es darum, dass mindestens zwei Bestätigungen von einer Person und / oder einem automatisierten System vorliegen, bevor eine bestimmte Zielumgebung aktualisiert werden darf (die live sein kann oder so etwas wie eine Masterdatei / Baseline-Bibliothek sein kann). Einige Beispiele sind:

• Beim Umwandeln (Erstellen) von Quellkomponenten in ausführbare Komponenten ist nur eine begrenzte Anzahl von Warnungen zulässig.
• Einige automatisierte Tests müssen ohne Probleme abgeschlossen worden sein.
• Einige Menschen müssen ihre vorherige Zustimmung angegeben haben (und ohne diese Zustimmung schlagen Versuche, die Zielumgebungen zu aktualisieren, automatisch fehl).

Dies sind Strategien / Muster, die ich mir vorstellen kann:

Aufgabentrennung

Zumindest für mich bedeutet DevOps nicht, sowohl Entwickler als auch Operatoren in einer Person zu verkörpern. Es ist also immer noch möglich, die Aufgabe so zu trennen, dass derjenige, der den Code schreibt (dev), nicht derjenige ist, der ihn ausführt (ops).

Wenn zum Beispiel eine SQL-Anweisung in der Live-Umgebung ausgeführt werden soll, schreibt eine die SQL und eine andere führt sie aus. Dies setzt voraus, dass der Ausführende auch die SQL versteht und nicht nur ausführt.

Trigger bereitstellen

Zwar gibt es Verdienst, kontinuierlich bereitzustellen. Teams in einer stärker regulierten Branche können eine andere (separate) Partei bestimmen, die die Bereitstellung auslöst, anstatt sie automatisch bereitzustellen. Checkliste, automatisierte Tests, Prüfsummen sind mögliche Prüfungen vor dem Auslösen der Bereitstellung.

Nach dem Auslösen kann die Automatisierung die Bereitstellung ausführen.

Paar-Programmierung

Persönlich habe ich diese Technik nicht als Methode für Prüfer angeführt, um das Check-and-Balance-Prinzip zu erfüllen. Aber möglicherweise denke ich, dass es eine Strategie sein kann.

MFA

Ich würde mich vielleicht ein wenig mit diesem strecken, aber es ist möglich, dass aus irgendeinem Grund, dass Sie keinen einseitigen Zugang zu einem System wünschen, jemand das Passwort und eine andere Person das Token oder Gerät für einen Zeitcode halten kann. Damit müssen 2 Personen anwesend sein, um das System beurteilen zu können.