Questa applicazione self-hosted può supportare il vostro processo di approvazione? Un quadro pratico di valutazione

Perché una funzione di approvazione non equivale a un processo di approvazione controllato

Molte applicazioni possono contrassegnare un elemento come approvato, limitare una modifica di stato oppure avvisare un collega affinché lo esamini. Questo può essere utile, ma non fornisce automaticamente un processo controllato per un acquisto, una spesa, una richiesta di accesso, una modifica ai dati dei clienti o una decisione di pubblicazione.

Un processo di approvazione controllato richiede più di un'azione su una schermata. Richiede una decisione definita, decisori idonei, regole che stabiliscano quando si applica la loro autorità, una registrazione di ciò che hanno deciso e protezioni contro modifiche o aggiramenti successivi del processo. La domanda giusta non è “Questa applicazione dispone di approvazioni?”. È “Possiamo configurare e gestire questa applicazione affinché le decisioni richieste siano prese, applicate e documentate con evidenze?”.

NIST SP 800-53 considera i controlli flessibili e personalizzabili nell'ambito di un processo di gestione del rischio che coinvolge l'intera organizzazione. Applicate qui lo stesso principio: traducete i vostri requisiti aziendali, normativi e di rischio in verifiche osservabili. L'etichetta di una funzione generica non sostituisce questo lavoro.

• Considerate una funzione come un punto di partenza, non come prova dell'esistenza di un controllo.
• Distinguete le revisioni di semplice convenienza dalle decisioni che generano impegni finanziari, legali, di sicurezza o con impatto sui clienti.
• Documentate quali requisiti sono obbligatori, quali desiderabili e quali devono essere gestiti al di fuori dell'applicazione.

Partite dalla decisione del mondo reale

Iniziate dall'evento aziendale, non dalla configurazione del software. Descrivete un tipo di approvazione alla volta. “Acquisti” è di solito troppo generico: approvare il rinnovo ricorrente di un fornitore a basso valore può richiedere evidenze, autorità e gestione del rischio diverse rispetto all'approvazione di un nuovo impegno di valore elevato con un fornitore.

Per ogni decisione, identificate il richiedente, il record oggetto della decisione, le evidenze necessarie, i possibili esiti e l'azione che può avvenire solo dopo l'approvazione. Identificate inoltre le conseguenze di un'approvazione errata. Questo determina il livello di controllo, visibilità e revisione richiesto dal flusso di lavoro.

• Che cosa viene approvato: una richiesta, un documento, una modifica a un record, un pagamento, una pubblicazione, un'autorizzazione di accesso o un'azione sui dati dei clienti?
• Chi può richiederlo e quali campi o allegati devono essere completi prima dell'invio?
• Chi può approvarlo, rifiutarlo, rimandarlo indietro per modifiche o annullarlo?
• Quali soglie, categorie di rischio, reparti, sedi o classificazioni dei dati modificano il percorso?
• Quale azione diventa consentita dopo l'approvazione e chi la esegue?
• Per quanto tempo devono essere conservati il registro della decisione e le evidenze a supporto?

Mappate il flusso minimo prima di valutare il software

Scrivete in linguaggio semplice il più piccolo flusso completo, quindi rendete ogni passaggio verificabile nell'applicazione. Una base utile comprende richiesta, revisione, decisione, notifica, esecuzione e conservazione dei record. Se uno strumento proposto non può rappresentare un passaggio necessario o preservare le informazioni richieste, identificate esplicitamente il controllo compensativo anziché presumere che gli utenti se ne ricorderanno.

Mantenete distinta la decisione di approvazione dall'esecuzione a valle. Un approvatore può autorizzare, per esempio, un acquisto, mentre un'altra persona crea l'ordine. Questa distinzione è importante per la responsabilità e la separazione dei compiti.

• Richiesta: creare un elemento identificabile in modo univoco e acquisire dati ed evidenze obbligatori.
• Revisione: rendere l'elemento disponibile al revisore o ai revisori corretti.
• Decisione: registrare l'approvazione, il rifiuto o il rinvio per rilavorazione con l'identità responsabile.
• Notifica: comunicare al richiedente e alla successiva parte responsabile ciò che è avvenuto.
• Esecuzione: consentire o attivare l'azione successiva autorizzata solo quando le condizioni sono soddisfatte.
• Conservazione: preservare il record della decisione, gli allegati e la cronologia per il periodo richiesto.

Valutate stati e transizioni, incluse le modifiche dopo l'approvazione

Un flusso di lavoro è definito dai suoi stati e dalle transizioni consentite tra essi. Come minimo, verificate bozze, elementi inviati, elementi approvati ed elementi rifiutati. In molti processi servono anche gli stati rinviato per modifiche, annullato, scaduto, sostituito o eseguito.

La verifica più rivelatrice riguarda una modifica sostanziale dopo l'approvazione. Se cambiano l'importo, il fornitore, l'ambito, l'allegato, il livello di accesso o la finalità relativa ai dati dei clienti, l'applicazione blocca il record, invalida l'approvazione, crea una nuova revisione oppure conserva semplicemente una vecchia approvazione accanto a contenuti modificati? Il processo deve indicare quali modifiche richiedono una nuova approvazione, e l'applicazione deve rendere chiaro tale esito.

Verificate inoltre chi può spostare ciascuno stato. Un richiedente può poter modificare una bozza, ma non dovrebbe necessariamente poter contrassegnarla come inviata, approvata o eseguita senza le condizioni richieste.

• Gli utenti possono vedere lo stato attuale e l'intera cronologia degli stati precedenti?
• Le transizioni sono limitate in base a ruolo, assegnazione o condizioni del flusso?
• Gli elementi rifiutati vengono chiusi, sono modificabili per un nuovo invio o vengono rinviati per correzione?
• Una modifica post-approvazione attiva una nuova approvazione quando previsto dalla vostra politica?
• Un elemento approvato può essere annullato e vengono conservate l'identità e la motivazione dell'annullamento?
• Gli utenti possono distinguere un record approvato da un record in attesa, rivisto o sostituito?

Verificate le regole di autorità, non solo l'assegnazione dell'approvatore

Un approvatore nominativo è semplice da comprendere, ma può essere fragile. Una valutazione solida verifica se l'applicazione può rispecchiare il modello di autorità effettivamente utilizzato: revisori basati sui ruoli, soglie, percorsi condizionali e più di una fase di approvazione. Non presumete che un responsabile assegnato sia sempre la persona autorizzata per ogni decisione.

Usate casi rappresentativi. Verificate una richiesta ordinaria, una richiesta appena sotto e appena sopra una soglia monetaria, una richiesta ad alto rischio, una richiesta che coinvolge due reparti e una richiesta che necessita della revisione di legale, sicurezza o finanza. Registrate se l'instradamento è automatico, se può essere modificato e che cosa gli utenti possono vedere quando non sono i revisori correnti.

• Autorità nominativa: una specifica persona responsabile può approvare?
• Autorità basata sul ruolo: l'attuale titolare di un ruolo aziendale autorizzato può approvare?
• Autorità per soglia: il percorso cambia all'importo o al livello di rischio richiesto?
• Autorità multi-fase: i revisori obbligatori possono agire nell'ordine corretto?
• Autorità parallela: quando sono necessarie più revisioni, devono approvare tutti oppure ne basta uno?
• Autorità condizionale: i revisori obbligatori possono variare in base a reparto, tipo di dati, Paese, progetto o categoria della richiesta?

Verificate la separazione dei compiti e l'accesso privilegiato

La separazione dei compiti significa più che assegnare etichette diverse alle persone. Il controllo AC-5 di NIST richiede una separazione dei compiti definita e documentata, nonché autorizzazioni di accesso che la supportino. Trasformate questo principio in verifiche dirette: un richiedente può approvare la propria richiesta, modificare un record approvato, scegliere un approvatore non idoneo o aggirare un revisore obbligatorio?

Valutate separatamente i normali ruoli dell'applicazione e l'accesso operativo. In una distribuzione self-hosted, le persone con ampio accesso alla distribuzione o all'host possono modificare il funzionamento, i dati o la configurazione dell'applicazione al di fuori del flusso aziendale. Docker documenta che il suo modello di autorizzazione standard è del tipo tutto o niente per gli utenti autorizzati ad accedere al daemon Docker: tali utenti possono eseguire comandi del client Docker. Includete questo accesso nel vostro modello di minaccia e nella progettazione della governance.

I plugin di autorizzazione Docker possono prendere decisioni di consenso o rifiuto in base all'autenticazione e al contesto del comando, ma Docker documenta anche limiti all'ambito della loro applicazione. Se intendete fare affidamento su questi controlli, verificate il loro ambito rispetto alle azioni amministrative rilevanti per il vostro processo. Non deducete che le sole restrizioni del flusso di lavoro a livello applicativo limitino gli amministratori dell'infrastruttura.

• Usate account di prova separati per richiedente, approvatore, esecutore, amministratore dell'applicazione e amministratore dell'infrastruttura.
• Tentate l'auto-approvazione, l'approvazione da parte di un ruolo non autorizzato e l'approvazione dopo una riassegnazione.
• Tentate di modificare campi chiave e allegati dopo l'approvazione.
• Identificate chi può modificare regole del flusso, ruoli, impostazioni di audit, archivi dati, container e backup.
• Definite chi esamina gli accessi privilegiati e con quale frequenza.
• Assicuratevi che il processo riconosca il rischio residuo quando un piccolo team tecnico deve necessariamente disporre di un ampio accesso operativo.

Valutate delega, assenze e attività scadute senza perdere la responsabilità

I flussi di approvazione spesso falliscono in circostanze ordinarie: un approvatore è in ferie, ha cambiato ruolo o semplicemente non agisce. Un processo praticabile richiede un percorso deliberato per delega, riassegnazione ed escalation. L'obiettivo è garantire continuità senza oscurare chi disponeva dell'autorità e chi ha preso la decisione finale.

Verificate se l'applicazione registra l'assegnatario originale, la persona o la regola che ha riassegnato il lavoro, la decisione del delegato e la tempistica di ciascun evento. Se la delega viene gestita al di fuori dell'applicazione, stabilite come documentare tale istruzione e come verificare l'autorità del nuovo approvatore.

• Un approvatore può delegare solo all'interno di un ruolo o livello di autorità consentito?
• Il sistema conserva l'assegnatario originale e la cronologia delle deleghe?
• Un responsabile di processo può riassegnare un elemento scaduto e viene registrato il motivo?
• Promemoria ed escalation sono configurabili in modo sufficiente per il tempo di risposta richiesto?
• Che cosa accade se l'account di un approvatore viene disabilitato o rimosso mentre sono in attesa attività?
• Esiste un percorso di emergenza documentato, con riesame successivo, per decisioni che non possono attendere?

Valutate le evidenze di approvazione e i record di audit

Il record della decisione dovrebbe rispondere a domande fondamentali senza fare affidamento sulla memoria di qualcuno: cosa è accaduto, quando e dove è accaduto, cosa o chi lo ha causato, quale è stato l'esito e quali identità vi erano associate. Questi elementi sono coerenti con gli elementi dei record di audit nel controllo AU-3 di NIST.

Per ogni decisione, esaminate l'effettivo output conservato anziché fare affidamento su una dashboard. Stabilite se include la versione della richiesta, la decisione, data e ora, l'identità dell'approvatore, commenti, evidenze allegate, assegnazioni e tutte le modifiche significative. Verificate poi se un utente può esportare o recuperare le evidenze in una forma che resti comprensibile al di fuori dell'applicazione.

Le evidenze sono utili solo se restano affidabili. NIST AU-9 tratta la protezione delle informazioni di audit e la limitazione della gestione delle funzioni di registrazione a un sottoinsieme appropriato di utenti privilegiati. Chiedete chi può modificare, eliminare, disabilitare o sostituire record e log di approvazione e come tali azioni vengano a loro volta rilevate o riesaminate.

• Identificativo della richiesta e versione o revisione approvata.
• Tipo di evento, ora, fonte o luogo pertinente, esito e identità associate.
• Commenti alla decisione, motivazioni del rifiuto e allegati collegati, quando richiesti.
• Cronologia completa di assegnazioni, deleghe e modifiche di stato.
• Procedure di conservazione, esportazione e recupero che sono state verificate.
• Controlli di accesso sui record di approvazione e sulla registrazione di audit, inclusa la governance degli utenti privilegiati.