Quali sono le possibili implementazioni (o esempi) del principio dei quattro occhi?

Michael Grünewald ha recentemente pubblicato questo commento :

Un metodo molto importante che non menzionate è il "principio dei quattro occhi" che viene utilizzato nella finanza - sia come obbligo regolamentare che come protezione. Nell'industria del software è implementato in vari modi, come ad esempio recensioni di codici, ma può anche essere utilizzato per convalidare i comandi che influenzano i sistemi live.

Correggimi se sbaglio, ma mi è stato insegnato che il "principio dei quattro occhi" riguarda qualcosa che è "approvato per accadere", dopo che almeno 2 esseri umani (e / o processi automatizzati) hanno dato la loro precedente benedizione. O per usare la formulazione (leggermente corretta) sulla "regola dei due (guai)" da Wikipedia :

La regola del doppio è un meccanismo di controllo progettato per raggiungere un elevato livello di sicurezza per materiale o operazioni particolarmente critici. In base a questa regola, tutti gli accessi e le azioni richiedono la presenza di due persone autorizzate in ogni momento.

Gli obblighi normativi sono, ovviamente, fuori tema, ma nel contesto di "protezione sicura", quali sono le possibili implementazioni concettuali di questo principio a quattro occhi, che probabilmente potrebbero applicarsi a qualsiasi piattaforma / sistema operativo / hardware utilizzato?

Una delle implementazioni sul codice è il modello Pull Request (PR) reso popolare da GitHub.

Il ragionamento principale alla base è che solo un piccolo insieme di manutentori del prodotto sarà autorizzato a unire il codice nel ramo di rilascio. Ogni nuova funzionalità / correzione di bug accadrà su un nuovo ramo e una volta fatto sarà definito come una richiesta pull.

Ciò consente di testare l'unione dal codice di rilascio (principale) effettivo con il codice nel PR in modo automatico (Travis è il più popolare per il progetto pubblico in realtà) e fornire un primo feedback sulla qualità del codice. Travis CI (ad esempio) può essere eseguito sul risultato del master effettivo con il codice dalla richiesta pull unita in esso, quindi fallirà se l'unione è impossibile o se i comandi definiti in travisci.yml restituiscono un'uscita diversa da zero codice

Una volta superati i test automatici, per il principio dei 4 occhi, è ancora necessario un numero configurabile di persone per riesaminare e approvare la modifica prima che venga unita, ovviamente, almeno 1 persona (che non è l'autore di PR) per imporre che 4 occhi riesaminino il i cambiamenti.

Esiste una vasta gamma di opzioni per unire automaticamente una volta raggiunto il quorum di revisori o per aver ancora bisogno di un'unione manuale da parte di un manutentore.

Le autorizzazioni per la revisione e l'unione possono essere separate, il che aiuta a dare a più persone il diritto di "votare" sullo stato di unione mantenendo la possibilità di limitare chi può effettivamente fare l'unione.

Recensioni di codice

Si tratta di avere almeno un'altra persona a guardare il codice scritto da qualcuno, ad esempio per valutare se soddisfa alcuni criteri predefiniti come:

• Standard di codifica (rientri, ecc.).
• Documentazione in linea.
• Manutenibilità del codice.
• Gestione degli errori.
• Completezza (ad es. if/then/elseO case/whencostrutti coprono tutti i casi possibili).

Omologazioni per l'aggiornamento di alcuni ambienti target

Si tratta di avere almeno 2 conferme da parte di una persona e / o di un sistema automatizzato prima che gli sia permesso di aggiornare un ambiente di destinazione (che potrebbe essere attivo o potrebbe essere qualcosa come un file master / libreria di base). Alcuni esempi sono:

• È consentito solo un numero limitato di avvisi quando si trasformano (costruendo) componenti di origine in componenti eseguibili.
• Alcuni set di test automatizzati devono essere stati completati senza problemi.
• Alcuni esseri umani devono aver indicato la loro approvazione preventiva (e senza di ciò, qualsiasi tentativo di aggiornamento degli ambienti target fallirà automaticamente).

Queste sono strategie / modelli che mi vengono in mente:

Separazione del dovere

DevOps, almeno secondo me, non significa incarnare sia gli sviluppatori che le operazioni in una sola persona. Quindi è ancora possibile separare il dovere in modo che quello che scrive il codice (dev) non sia quello che lo esegue (ops).

Ad esempio, se un'istruzione SQL deve essere eseguita nell'ambiente live, uno scrive l'SQL e un altro lo esegue. Ciò che presuppone è quello che gli esecutori devono avere anche una comprensione dell'SQL e non solo eseguire.

Distribuire il trigger

Mentre ci sono meriti da distribuire continuamente. Il team di un settore più regolamentato può nominare un'altra parte (separata) per attivare la distribuzione anziché la distribuzione automatica. Elenco di controllo, test automatizzati, checksum sono possibili controlli prima di avviare la distribuzione.

Una volta attivato, l'automazione può procedere per eseguire la distribuzione.

Coppia di programmazione

Personalmente non ho citato questa tecnica come metodo per il revisore dei conti per soddisfare il principio del controllo e dell'equilibrio. Ma potenzialmente penso che possa essere una strategia.

MFA

Potrei allungare un po 'con questo, ma è possibile che, per qualche motivo, non si desideri un ingresso unilaterale in un sistema, qualcuno può conservare la password e un'altra persona detenere il token o il dispositivo per un time code. In modo che, 2 persone devono essere presenti per valutare il sistema.