Jakie procesy lub narzędzia umożliwiają podział obowiązków, gdy inżynierowie wdrażają i uruchamiają kod?

W ściśle regulowanych środowiskach, takich jak sektor usług finansowych, podział obowiązków jest niezbędnym mechanizmem unikania kolizji między osobami mającymi obowiązki rozwojowe i przywileje produkcyjne.

Tradycyjnie oznacza to, że programiści opracowują kod, a następnie przekazują go do Operacji, jednak w wielu modelach operacyjnych DevOps segregacja między Programowaniem a Operacjami jest co najmniej niewyraźna:

• W praktyce Google Site Reliability Engineering (SRE) istnieje oddzielna funkcja SRE w Google, jednak programiści są wprowadzani w celu zabezpieczenia SRE w czasie dużego obciążenia operacyjnego.

• W modelu „You Build It, You Run It” nie ma osobnej funkcji operacyjnej.

Po miesiącach spędzonych na zgłębianiu podstawowych przyczyn mechanizmu podziału obowiązków wydaje się, że przede wszystkim ma on zaspokoić Sarbanes Oxley Sekcja 404 : Ocena zarządzania kontrolą wewnętrzną:

(a) Wymagane zasady. Komisja określa zasady wymagające, aby każdy raport roczny wymagany zgodnie z sekcją 13 (a) lub 15 (d) Ustawy o giełdzie papierów wartościowych z 1934 r. Zawierał raport z kontroli wewnętrznej, który:

(1) określa odpowiedzialność kierownictwa za ustanowienie i utrzymanie odpowiedniej struktury kontroli wewnętrznej i procedur sprawozdawczości finansowej; i

(2) zawierają ocenę, na koniec ostatniego roku obrotowego emitenta, skuteczności struktury kontroli wewnętrznej i procedur emitenta w zakresie sprawozdawczości finansowej.

(b) Ocena i raportowanie kontroli wewnętrznej. Na podstawie oceny kontroli wewnętrznej wymaganej na mocy podsekcji (a) każda zarejestrowana publiczna firma księgowa, która przygotowuje lub wydaje sprawozdanie z audytu dla emitenta, poświadcza ocenę dokonaną przez kierownictwo emitenta i składa sprawozdanie z tej oceny. Poświadczenie dokonane zgodnie z niniejszą podsekcją powinno być wykonane zgodnie ze standardami dotyczącymi poświadczeń wydanymi lub przyjętymi przez zarząd. Każde takie zaświadczenie nie będzie przedmiotem odrębnego zlecenia.

W oparciu o komentarze ważne jest, aby podać kilka moich założeń :

• Rozważam przede wszystkim usługi finansowe na masowym rynku, tzn. Wolumeny transakcji są wysokie, ale ich wartość jest stosunkowo niska. Byłoby to w przeciwieństwie do komercyjnych usług finansowych, które mają inny profil wartości transakcji.
• Oferta online instytucji finansowej będzie się składać z wielu elementów o różnych względach ryzyka:
  • Przenieś pieniądze - przenoszenie pieniędzy między kontami lub transfery między kontami różnych właścicieli. Operacja, która musi wziąć pod uwagę przeciwdziałanie praniu pieniędzy, ochronie przed oszustwami i krajom objętym embargiem, aby wymienić tylko kilka.
  • Pozyskiwanie klientów - mniej „ryzykowne”, ponieważ ma niski wolumen transakcji w porównaniu do Move Money, ale nadal wymaga rozważenia.
  • Bankowość internetowa - obejmuje szeroki zakres usług o różnym poziomie ryzyka, ruchome pieniądze byłyby uważane za część tego.
• Można sobie wyobrazić inne podejście do każdego z nich w zależności od ryzyka, jednak w celu uproszczenia pracuję nad rozwiązaniem, które byłoby odpowiednie dla niektórych najbardziej ryzykownych operacji.

TL; DR : To jest odpowiedzialność kierownictwa w celu zapewnienia, że odpowiednie kontrole wewnętrzne są w miejscu, które spełniają KPWiG w przepisach .

Sarbanes Oxley 404 jest zwykle usatysfakcjonowany poprzez zakończenie odgórnej oceny ryzyka, której część oceni ryzyko zmowy i przedstawi strategie ograniczania ryzyka.

W firmie, która stosuje praktykę i kulturę DevOps, w której programiści rutynowo mają dostęp zarówno do kontroli źródła, jak i produkcji, w jaki sposób można osiągnąć Podział obowiązków, lub bardziej ogólnie, w jaki sposób można zminimalizować ryzyko zmowy.

Wygląda na to, że twoje pytanie nie zawiera żadnych założeń dotyczących platformy / systemu operacyjnego, na których jest ono oparte. Dlatego sensowne może być dodanie odpowiedzi na temat tego, jak zazwyczaj robi się to / rozwiązuje w środowisku komputerów mainframe, gdzie „inżynierowie” (jak w tytule twojego pytania) to tak naprawdę grupy ludzi, których dziesiątki (być może setki) ludzi są zaangażowany. Moja odpowiedź opiera się na użyciu produktu SCM, z którym jestem najbardziej zaznajomiony (nie jestem pewien, czy jest to konieczne do ujawnienia nazwy produktu).

---

1. Architektura

---

Oto najważniejsze informacje, w jaki sposób odpowiedziałbym na twoje pytanie:

• Cały kod (i powiązane artefakty, takie jak pliki wykonywalne itp.) Są przechowywane w plikach, które razem nazywamy strukturą biblioteki .
• Dla każdego środowiska w każdym (ewentualnie zdalnym) systemie docelowym jest serwer („uruchomione zadanie” w mowie na komputerze mainframe), który dba o WSZYSTKIE aktualizacje (powtarzanie: WSZYSTKO) w dowolnej strukturze biblioteki. Istnieje kilka wyjątków (np. Pracownicy ochrony lub zespół zarządzania przestrzenią), ale poza tym nikt (powtórz: nikt) nie ma uprawnień do stosowania aktualizacji do dowolnego pliku w tej strukturze biblioteki. Innymi słowy: serwer otrzymuje wyłączne uprawnienia do aktualizacji całej struktury biblioteki . Uwaga: ludzie OPS wpadną w szał, jeśli wejdziesz, aby ograniczyć ich dostęp (na początku będą się opierać ...), więc upewnij się, że jesteś objęty wyższym kierownictwem (CxO), aby narzucić te zasady dostępu ...
• Rzeczywiste zmiany oprogramowania składają się z jednego komponentu (drobna poprawka kodu w środku nocy ...), lub mogą to być setki lub tysiące źródeł, plików wykonywalnych lub dowolnych innych artefaktów (podczas weekendu wydania). Aby można było nimi zarządzać, rzeczy, które powinny być przenoszone (mniej więcej) jednocześnie, są pakowane razem w tak zwany pakiet zmian oprogramowania .

Po wprowadzeniu powyższego wszelkie aktualizacje serwera, które zostaną zastosowane w strukturze biblioteki, będą możliwe tylko poprzez dobrze zdefiniowany przepływ pracy, który nazywamy cyklem życia pakietu zmian oprogramowania (SDLC, jeśli wolisz). Aby faktycznie wykonać różne kroki w tym przepływie pracy, wystarczy, aby tak się stało:

• Tylko serwer wykona wymagane (i wstępnie skonfigurowane) kroki.
• Serwer wykona tylko określony krok (= zaktualizuje coś gdzieś w strukturze biblioteki), po zebraniu wymaganych zatwierdzeń (od ludzi) do wykonania takiego kroku.
• Zezwolenia mogą być wydawane tylko przez użytkowników, którzy mają rolę, która pozwala im (= pozwolenie) na wydawanie takich zatwierdzeń.

---

2. Role i uprawnienia

---

Serwer zapewni, że użytkownik próbujący dokonać czegoś (np. „Zatwierdzić coś”) będzie mógł to zrobić tylko wtedy, gdy uprawnienia użytkownika będą odpowiednie. Ta część jest łatwa. Ale nie chcesz używać systemu SCM do administrowania wszystkimi uprawnieniami dla wszystkich zaangażowanych użytkowników, to właśnie należy do twojego systemu bezpieczeństwa (nie do systemu SCM!), Abyś mógł dostosować swój przepływ pracy (w systemie SCM) w razie potrzeby sprawdź te uprawnienia. Poniższe kroki zawierają więcej szczegółowych informacji na ten temat.

Krok 1: Skonfiguruj uprawnienia (w systemie bezpieczeństwa)

• Zdefiniuj jednostki bezpieczeństwa w swoim systemie bezpieczeństwa, używając dobrze zdefiniowanych nazw dla tych jednostek. Kilka próbek (dodaj tyle podobnych do własnych potrzeb):

  • PrmUnitStosowane dla uzyskania uprawnienia do żądania Promuj powiedzieć Jednostka -testing.
  • PrmQAStosowane dla uzyskania uprawnienia do żądania Promuj powiedzieć Qa -testing (załóżmy, jest to najwyższy poziom testowania).
  • PrdEnduser, wykorzystywane przez użytkowników końcowych zaangażowanych w pewien poziom testów, aby wskazać, że są zadowoleni z wyników uzyskanych w wyniku pewnego rodzaju testów. Z tego powodu ci użytkownicy końcowi zgadzają się z postępem zmian w strukturze biblioteki.
  • PrdRelmgnt, używane przez menedżerów wydań do autoryzacji aktywacji w produkcji (= ostatni / najwyższy poziom w strukturze biblioteki).

• Zdefiniuj grupy użytkowników w systemie bezpieczeństwa. Kilka próbek (dodaj tyle podobnych do własnych potrzeb):

  • GrpDevs, co (powiedzmy) odpowiada Twoim programistom (prawdopodobnie więcej niż tylko 1).
  • GrpEnduser, który (powiedzmy) odpowiada użytkownikom końcowym (co najmniej 1, najlepiej z podobnymi użytkownikami).
  • GrpRelMgnt, co (powiedzmy) odpowiada menedżerom wydań (co najmniej 1, najlepiej kilku innym użytkownikom).

• Udziel uprawnień , także przy użyciu systemu zabezpieczeń, aby umożliwić dostęp do wybranych „ podmiotów bezpieczeństwa ” dla wybranych „ grup użytkowników ”. Aby kontynuować powyższy przykład, oto, co wydaje się właściwe (dostosuj do własnych potrzeb):

  • Grupa GrpDevsuzyskuje dostęp do (tylko!) Jednostki bezpieczeństwa PrmUnit.
  • Grupa GrpEnduseruzyskuje dostęp do (tylko!) Jednostki bezpieczeństwa PrdEnduser.
  • Grupa GrpRelMgntuzyskuje dostęp do (zarówno!) Jednostki bezpieczeństwa, jak PrmQAi PrdRelmgnt.

Krok 2: Skonfiguruj przepływ pracy (w systemie SCM)

Po skonfigurowaniu uprawnień w systemie bezpieczeństwa (jak w kroku 1), wszystko, co pozostało do zrobienia w systemie SCM, to skonfigurowanie, w jaki sposób poszczególne kroki w cyklu życia pasują do powiązanych jednostek bezpieczeństwa w systemie bezpieczeństwa. Oznacza to, że tylko ci użytkownicy, którzy mają odpowiedni dostęp do wymaganej jednostki bezpieczeństwa, mogą poprosić serwer o wykonanie odpowiedniego kroku w przepływie pracy.

Oto kilka przykładów konfiguracji systemu SCM, aby magia się wydarzyła:

• Jeśli użytkownik ma dostęp do PrmUnit, wówczas użytkownik może poprosić o Promuj się Jednostka -testing. Oczywiście, użytkownicy w grupie GrpDevssą użytkownikami upoważnionymi do tego (uwaga: nie, np. Użytkownicy w grupie GrpRelMgnt).
• Jeśli użytkownik ma dostęp do PrmQA, wówczas użytkownik może poprosić o Promuj do QA -testing. Oczywiście, użytkownicy w grupie GrpRelMgntsą użytkownikami upoważnionymi do tego (uwaga: nie, np. Użytkownicy w grupie GrpDevslub w grupie GrpEnduser).
• Jeśli użytkownik ma dostęp PrdEnduser, może zezwolić na zmianę w strukturze biblioteki (co jest zwykle warunkiem wstępnym dla użytkowników w grupie, GrpRelMgntaby mogli przejrzeć zmianę). Oczywiście, użytkownicy w grupie GrpEndusersą (jedynymi) użytkownikami upoważnionymi do tego.
• Jeśli użytkownik ma dostęp do PrdRelmgnttakiego konta, może autoryzować Aktywację w produkcji (= ostatni / najwyższy poziom w strukturze biblioteki).

---

3. Spodziewaj się nieoczekiwanego i przygotuj się na to

---

Powyższe jest tylko schematem, który, mam nadzieję, pomoże zrozumieć, w jaki sposób ostatecznie serwer zajmuje się podziałem obowiązków ... pod warunkiem, że masz CxO narzucające ci zasady dostępu, które nie wszystkim się spodobają.

Aby uzupełnić obraz, jak wyjaśniono powyżej, serwer tworzy ścieżkę audytu (rejestrowanie) wszystkiego, co dzieje się w systemie. Aby w dowolnym momencie zawsze można było odpowiedzieć na pytania takie jak

Co się stało, kiedy i dlaczego, i który autoryzowany użytkownik faktycznie zatwierdził to ... z góry?

Ale prawdopodobnie najtrudniejszą częścią jest posiadanie odpowiednich narzędzi do raportowania (i umiejętność ich używania). Przynajmniej w celu (łatwego) spełnienia wymagań audytorów IT (ich pytania mogą być bardzo trudne). Ale również wskaż odpowiednie zapisy dziennika w twoim systemie SCM, aby odpowiedzieć na wszelkiego rodzaju pytania „co się stało” w sytuacjach kryzysowych, w których produkcja (części) spada.

---

PS: Pozostawiam to każdemu do oceny, jeśli moja odpowiedź brzmi „tak” lub „nie” zgodna z DevOps.

Odpowiedź oparta na mojej znajomości francuskiego rozporządzenia „Kontrola wewnętrzna”, coś w rodzaju odpowiednika przepisów SEC, na które wskazujesz, zakładam, że link tutaj do francuskiego tekstu prawnego nie byłby naprawdę przydatny i nie znam dobrego tłumaczenia tego.

W idealnym modelu „Budujesz, uruchamiasz” wszyscy w zespole będą odpowiedzialni za zmianę. Ocena ryzyka nie może być wymuszona przez podział obowiązków, a jedynym sposobem, w jaki wiem, aby zachować zgodność z przepisami, jest przeprowadzanie okresowej kontroli krótkiego cyklu transakcji wraz z niezmiennym śledzeniem działań, aby wrócić do osoby, która dokonała zwolnienia .
Oznacza to, że wszystkie dzienniki transakcji i działań są przekazywane do ograniczonego obszaru, do którego zespół nie ma dostępu, zmiana w tym, co jest rejestrowane „powinna” zostać przechwycona przez testy funkcjonalne, do których zespół nie ma dostępu, a co gorsza, zostanie złapana przez audyt i śledzone przez autora.

Nie dotyczy to wszystkich produktów, podczas pisania we Francji każda firma, która może emitować pieniądze (głównie banki), musi dopilnować, aby każda transakcja została zarejestrowana, a zatem nie może podjąć ryzyka pominięcia transakcji.
Z drugiej strony nie mają prawnego obowiązku śledzenia żadnej oferty handlowej ani oceny ryzyka, gdy ktoś poprosi o pożyczkę, a zatem produkty obsługujące tę selekcję klientów i obliczające opłaty, które będą w ofercie, łatwiej zmieścić na stanowisku -release model audytu.

Główną ideą jest to, że model wydania musi zostać dostosowany zgodnie z obowiązkami oceny ryzyka.

Pokrewnym zasobem jest norma ISO27001 .

IMHO, Developers & Operations mogą być reprezentowane jedynie przez dwa repozytoria git dla tej samej bazy kodów , z odrębnymi modelami uprawnień, tak aby zespoły w ogóle nie przeszkadzały sobie w pracy.

Nazwijmy je Dev.mygithub.co & ops.mygithub.co , jako przykład.

Chodzi o to, że deweloperzy mogą swobodnie tworzyć / oddział / scalanie do syta -git jest zapewnienie pełnej identyfikowalności i że liczy się tutaj- międzyczasie, w momentach, że ramy regulacyjne implikuje wysiłek przeglądu Zapytanie Pull mogą być podniesione, na połączenie nastąpi w kontrolowany sposób.

Przenosząc tę ​​koncepcję na wyższy poziom: rozwijać gałąź można rozmnażać w kierunku zdalnych ops' produkcji poprzez kolejną Pull żądanie czynu. Ta ostatnia część musi odbywać się rękami i oczami operatorów, ponieważ mają oni obowiązek zweryfikować ją w produkcji i wybierają poziom recenzji.

Taki schemat pozwala na nieskończoną elastyczność, pełną identyfikowalność, zdolność do wczesnego wychwytywania problemów za pomocą różnych procesów, oddzielenie problemów i bardzo rozsądne doświadczenie użytkownika w tym procesie !

Uwaga: Model opisany powyżej może być zastosowany, nawet jeśli Ops & Dev całkowicie się pokrywają!

wyższy jest droższy:

• odrębne strony deweloperów i operatorów oraz metody przenoszenia pracy z jednej strony na drugą
• odrębne systemy i metody deweloperów i operatorów operacyjnych, jak wyżej
• odrębne repozytoria dev i ops git / vcs i powiązane metody
• odrębne gałęzie dev i ops git / vcs (chronione) i powiązane metody

W zależności od tego, co robisz, niektóre rozwiązania są lepsze niż inne, na przykład jeśli potrzebujesz obsługiwać dwa zespoły z odrębnymi rolami, a każdy z nich ma własność i zapewnia pełną identyfikowalność, przesuwasz się nad pierwszymi trzema.

Krótko mówiąc, wszystko, co wymusza to, że jeden facet lub gal nie może wziąć piłki samotnie i biegać z nią, a on / ona przekracza wyraźną wyraźną granicę między deweloperami i operatorami. Teraz, w zależności od poziomu ryzyka, granica ta może być egzekwowana lub nie.