Jakie są możliwe wdrożenia (lub przykłady) zasady czterech oczu?

Michael Grünewald opublikował ostatnio ten komentarz :

Bardzo ważną metodą, o której nie wspominasz, jest „zasada czterech oczu” stosowana w finansach - albo jako obowiązek regulacyjny, albo jako ochrona. W branży oprogramowania jest on wdrażany na różne sposoby, np. Recenzje kodu, ale może być również wykorzystywany do sprawdzania poprawności poleceń wpływających na systemy na żywo.

Popraw mnie, jeśli się mylę, ale nauczono mnie, że „zasada czterech oczu” dotyczy czegoś, co jest „zatwierdzone na wydarzenie”, po tym, jak co najmniej 2 istoty ludzkie (i / lub zautomatyzowane procesy) udzieliły wcześniejszego błogosławieństwa. Lub użyć (nieznacznie poprawionego) sformułowania o „regule dwóch (wo) ludzi” z Wikipedii :

Reguła dwóch osób to mechanizm kontrolny zaprojektowany w celu osiągnięcia wysokiego poziomu bezpieczeństwa szczególnie krytycznych materiałów lub operacji. Zgodnie z tą zasadą wszelki dostęp i działania wymagają obecności dwóch upoważnionych osób przez cały czas.

Obowiązki regulacyjne są tutaj całkiem pewne, ale w kontekście „bezpiecznej ochrony”, jakie są możliwe koncepcyjne wdrożenia tej zasady czterech oczu, które prawdopodobnie mogłyby mieć zastosowanie do dowolnej używanej platformy / systemu operacyjnego / sprzętu?

Jedną z implementacji kodu jest spopularyzowany przez GitHub model żądania żądania (PR).

Głównym powodem jest to, że tylko niewielki zestaw opiekunów produktu będzie mógł scalić kod z gałęzią wydania. Każda nowa funkcja / poprawka pojawi się w nowej gałęzi, a po jej zakończeniu zostanie zdefiniowana jako żądanie ściągnięcia.

Pozwala to na automatyczne testowanie scalenia kodu z rzeczywistego wydania (głównego) z kodem w PR (Travis jest najbardziej popularny w publicznym projekcie) i daje pierwszą informację zwrotną na temat jakości kodu. Travis CI (na przykład) może działać na wyniku rzeczywistego wzorca z połączonym z nim kodem z żądania ściągnięcia, więc zawiedzie, jeśli scalenie jest niemożliwe lub jeśli polecenia zdefiniowane w travisci.yml zwrócą niezerowe wyjście kod

Po automatycznych testach, zgodnie z zasadą 4 oczu, nadal wymagana jest konfigurowalna liczba osób do przeglądu i zatwierdzenia zmiany, zanim zostanie ona scalona, ​​oczywiście co najmniej 1 osoba (która nie jest autorem PR), aby wymusić 4 oczy oceniające zmiany.

Istnieje szeroki zakres opcji automatycznego scalania po osiągnięciu kworum recenzentów lub ciągłego ręcznego scalania przez opiekuna.

Zezwolenia na przeglądanie i scalanie można rozdzielić, co pomaga większej liczbie osób w „głosowaniu” nad statusem scalania, zachowując jednocześnie możliwość ograniczenia, kto może faktycznie scalić.

Recenzje kodu

Chodzi o to, aby przynajmniej 1 inna osoba spojrzała na kod napisany przez kogoś, np. W celu oceny, czy spełnia on określone wcześniej kryteria, takie jak:

• Standardy kodowania (wcięcia itp.).
• Dokumentacja wbudowana.
• Utrzymywalność kodu.
• Obsługa błędów.
• Kompletność (np if/then/elselub case/whenkonstrukty obejmują wszystkie możliwe przypadki).

Zatwierdzenia do aktualizacji niektórych środowisk docelowych

Chodzi o posiadanie co najmniej 2 potwierdzeń od jakiejś osoby i / lub zautomatyzowanego systemu, zanim będzie można zaktualizować jakieś środowisko docelowe (które może być aktywne lub może być czymś w rodzaju biblioteki plików głównych / podstawowej). Oto niektóre przykłady:

• Podczas przekształcania (budowania) komponentów źródłowych w komponenty wykonywalne dozwolony jest tylko ograniczony zestaw ostrzeżeń.
• Pewien zestaw testów automatycznych musiał zostać zakończony bez żadnych problemów.
• Niektóre istoty ludzkie musiały wcześniej wyrazić zgodę (i bez tego wszelkie próby aktualizacji środowisk docelowych automatycznie nie powiodą się).

Oto strategie / wzorce, o których mogę myśleć:

Rozdzielenie cła

DevOps, przynajmniej moim zdaniem, nie oznacza ucieleśnienia zarówno deweloperów, jak i operatów w jednej osobie. Tak więc nadal można rozdzielić ten obowiązek tak, aby ten, który pisze kod (dev), nie był tym, który go wykonuje (ops).

Na przykład, jeśli instrukcja SQL ma być wykonywana w środowisku na żywo, jeden zapisuje SQL, a drugi go wykonuje. To, co zakłada, to ta, która wykonuje, musi także rozumieć SQL, a nie tylko wykonywać.

Wdróż wyzwalacz

Chociaż istnieją zalety ciągłego wdrażania. Zespół z bardziej uregulowanej branży może wyznaczyć inną (oddzielną) stronę do uruchomienia wdrożenia zamiast wdrażania automatycznego. Lista kontrolna, testy automatyczne, sumy kontrolne są możliwymi kontrolami przed uruchomieniem wdrażania.

Po uruchomieniu automatyzacja może rozpocząć wdrażanie.

Programowanie par

Osobiście nie cytowałem tej techniki jako metody służącej audytorowi do spełnienia zasady kontroli i równowagi. Ale potencjalnie myślę, że może to być strategia.

MSZ

Być może rozciągam się nieco przy tym, ale możliwe jest, że z jakiegoś powodu nie chcesz jednostronnego wejścia do systemu, ktoś może przechowywać hasło, a inna osoba może posiadać token lub urządzenie dla jednego kodu czasowego. Aby więc ocenić system, muszą być obecne 2 osoby.