Cos'è il policy as code (PaC)?

Invece di affidarsi agli umani per verificare la conformità o ricordare le regole di sicurezza, queste regole esistono come logiche eseguibili che si eseguono ogni volta che uno sviluppatore o un sistema propone una modifica o una richiesta. Se qualcuno invia una modifica, un motore di policy valuta automaticamente la modifica rispetto alle regole codificate e la consente, la rifiuta o la segnala.

Questo processo sposta le pratiche di gestione delle policy da documenti statici a una superficie di controllo dinamica e costantemente applicata, integrata nella delivery pipeline del software.

Le regole basate sul codice aiutano a garantire che le stesse policy vengano applicate ovunque, in modo ripetibile e scalabile. I motori di policy possono eseguire controlli automatici in pochi secondi durante build o distribuzioni, riducendo i cicli di feedback e aiutando i team DevOps a evitare sorprese di sicurezza o conformità nelle fasi avanzate.

Il PaC consente alle aziende di migliorare la postura complessiva di cybersecurity e di mantenere la conformità agli standard del settore e normativi. Inoltre, trattare le policy come codice si allinea con una più ampia transizione verso il concetto di "tutto come codice", che trasforma elementi come le richieste di infrastruttura in file di codice revisionabili sui quali i team di sviluppo possono collaborare.

In termini DevOps, una policy è una regola chiara e applicabile su come l'infrastruttura IT e le applicazioni devono essere configurate, accessibili o eseguite. Più precisamente, le policy stabiliscono quali azioni sono consentite, richieste o vietate affinché i sistemi continuino a funzionare nel loro stato ideale. 

Ad esempio, "tutti i bucket di storage devono essere criptati" o "nessun servizio pubblico può esporre la porta 22" sono policy, perché specificano vincoli concreti sul comportamento del sistema.

Con il PaC, le policy vengono scritte in un linguaggio di programmazione strutturato, in modo che i motori di policy e gli strumenti di automazione possano analizzarle e valutarle in modo deterministico. In questo modo, le policy diventano guardrail eseguibili che i sistemi e gli ingegneri devono soddisfare, piuttosto che linee guida che le persone potrebbero interpretare in modo diverso.

Gli strumenti policy as code permettono agli sviluppatori di scrivere codice eseguibile in ambienti di esecuzione e pipeline di integrazione continua/consegna continua (CI/CD), così ogni modifica viene automaticamente controllata per l'aderenza.

Tecnicamente, la maggior parte delle configurazioni PaC segue gli stessi passaggi fondamentali:

• Gli sviluppatori scrivono le policy sotto forma di file di codice. Possono utilizzare una gamma di linguaggi imperativi e dichiarativi di alto livello, tra cui Python, YAML, JavaScript Object Notation (JSON) o Rego, tipicamente utilizzato insieme all'Open Policy Agent (OPA), un motore di policy open source. Ogni file di policy dichiara gli input interessati ("resource.kind", "metadata.labels", ad esempio) e codifica le condizioni, dette anche "predicati", e gli esiti (consenti/nega, gravità, messaggi).

• Il codice viene inviato a un sistema di controllo versioni, come Git o GitHub, e segue gli stessi workflow del codice applicazione, tra cui pull request, recensioni e rigorosi test di sintassi.

• Un motore di policy legge il file di codice, lo analizza e lo trasforma in strutture di dati e istruzioni comprensibili internamente. Queste strutture e istruzioni vengono quindi convertite in un formato di istruzioni compatto e di basso livello (bytecode) per una valutazione rapida.

• Un chiamante, il pezzo di codice che chiede al motore di policy una decisione, normalizza gli input dati. Il chiamante elabora diversi formati di input, inclusi file HashiCorp Configuration Language (HCL) e template JSON da strumenti IaC, manifesti YAML da Kubernetes e piattaforme cloud, richieste HTTP da chiamate API e dati di app, e dati di telemetria da ambienti di esecuzione e produzione. Pulisce e rimodella l'input grezzo in un'unica struttura standard, così che le policy possano leggere gli input in modo coerente.

• Il chiamante restituisce i dati normalizzati al motore delle policy, che avvia l'esecuzione del codice della policy sugli input.  

• Il motore delle policy esamina le regole e confronta i predicati di ciascuna regola rispetto all'input per capire quali predicati si applicano. Il motore delle policy è come un sistema che chiede: "Cosa dice questa regola riguardo a questo input?"

• Il motore delle policy prende i risultati di tutte le regole e li combina in un'unica decisione di policy, un processo chiamato aggregazione decisionale, e crea un elenco di messaggi. I messaggi forniscono maggiori dettagli (quale regola è stata violata e quale oggetto l'ha violata) sul codice che ha generato l'errore e talvolta offrono suggerimenti su come applicare le correzioni.

• Il motore delle policy restituisce la decisione, inclusi messaggi pertinenti, tag e informazioni sulla gravità. Se la decisione è "rifiuta", il motore delle policy blocca tutte le pull request e le unioni di codice e interrompe la distribuzione finché gli sviluppatori non risolvono la violazione delle policy. Se la decisione è "consenti", il motore crea un artefatto di compilazione (un file di codice compilato, impacchettato e testato) e distribuisce il codice. Se sono presenti avvisi, il codice viene comunque eseguito, ma il motore include gli avvisi nei file di log o nei commenti. 

I controlli delle policy possono avvenire in qualsiasi momento del ciclo di vita dello sviluppo del software (SDLC), dall'integrazione del codice alla produzione e al monitoraggio in tempo reale.

Poiché le policy sono codice, possono anche essere trattate come qualsiasi altro artefatto software.

I team di sviluppo possono scrivere test automatizzati che inseriscono input di esempio nelle policy e verificano le decisioni che ne derivano, accelerando così i cicli di feedback quando le policy cambiano.

Quando le policy vengono codificate, gli sviluppatori possono estrarre la logica comune in moduli o funzioni riutilizzabili. Più policy di livello superiore possono quindi richiamare policy condivise invece di duplicare le condizioni ovunque.

Gli sviluppatori possono anche rinominare, ristrutturare o suddividere le policy di grandi dimensioni in policy più piccole senza modificare il loro comportamento, proprio come rifattorizzare una grande funzione dell'app in altre più piccole.

Queste funzionalità consentono ai team di applicare le pratiche di ingegneria del software esistenti alla logica di governance, il che li aiuta a mantenere i requisiti di sicurezza e conformità man mano che le architetture IT si scalano ed evolvono.

Supponiamo che l'Azienda X voglia implementare una policy "solo HTTPS" in cui ogni servizio web deve usare HTTPS, non HTTP semplice. Per codificare la policy, un ingegnere di piattaforma scrive una regola semplice che dice:

• Se il protocollo di un servizio è HTTP, la modifica deve essere rifiutata.
• Se il protocollo di un servizio è HTTPS, la modifica è consentita.

L'ingegnere inserisce questo file di policy in una cartella "policies" all'interno dello stesso repository di codice dell'applicazione e apre una pull request per aggiungere la policy. Quella pull request attiva un controllo automatico della sintassi del file policy e una recensione del codice da parte di un altro ingegnere. Solo dopo che la policy ha superato i test necessari, viene integrata nel ramo principale.

Nella pipeline di integrazione continua (CI), tutti i file di policy vengono caricati nel motore di policy dalla cartella "policies". Il motore delle policy legge la policy, la converte in una rappresentazione interna e la compila in una forma compatta di basso livello. Questa forma compatta permette al motore di rispondere rapidamente alla domanda "consentire o rifiutare?" per ogni servizio controllato dalla pipeline.

Indipendentemente dal formato del file, un processo CI prende il file di configurazione esistente, estrae i campi importanti (nome, protocollo, porta) e crea una semplice descrizione JSON di ogni servizio.

Il chiamante richiede una decisione al motore delle policy inviando la descrizione standardizzata del servizio come input e indicando che deve essere applicato il pacchetto di policy per "solo HTTPS".

Il motore delle policy valuta quindi l'input rispetto alle regole. Controlla il campo del protocollo del servizio. Se il protocollo è HTTP, significa che l'input corrisponde alla condizione "rifiuta" nella policy. Il motore indica che la modifica deve essere rifiutata e crea un messaggio che informa lo sviluppatore che il servizio deve utilizzare HTTPS invece di HTTP. Se il servizio utilizza HTTPS, nessuna delle condizioni di rifiuto viene soddisfatta e il motore indica che la modifica è consentita.

Successivamente, il motore delle policy riassume le valutazioni delle regole in un unico oggetto decisionale per il servizio. Gli oggetti decisionali in genere specificano se la decisione complessiva è "consentire" o "rifiutare" e quanto è grave il problema (alto, medio, basso). Includono anche un elenco di messaggi che spiegano perché l'input è stato negato e gli eventuali avvisi rilevati dal motore nel processo di valutazione. Se tutto è conforme, l'oggetto decisionale dice che la modifica è consentita e arriva solo con note informative (o nessun messaggio).

Infine, gli strumenti CI applicano la decisione. Se la decisione è "rifiuta", la modifica non viene unita al ramo principale del codice. L'ingegnere vede un messaggio di errore che indica che il servizio deve utilizzare HTTPS e subire modifiche specifiche. Se la decisione è "consenti", l'artefatto viene impacchettato e implementato, e la pipeline CI continua normalmente.

Il policy as code è nato da un più ampio movimento "tutto come codice" nel DevOps moderno e nell'ingegneria del cloud.

In origine, l'infrastructure as code (IaC) è stato il grande cambiamento. Invece di far cliccare gli amministratori di sistema sulle interfacce utente o seguire i runbook, i team descrivevano server, reti e altre risorse in file di codice dichiarativo. Questi file vengono memorizzati nei sistemi di controllo delle versioni e applicati tramite pipeline automatizzate.

Man mano che le aziende ne vedevano i benefici, l'approccio si è diffuso ad altri componenti delle architetture IT. La configurazione delle applicazioni si sposta verso approcci basati sul codice. Le pipeline CI/CD sono diventate script che vivono in repository di codice. Anche le regole di monitoraggio e di allerta hanno iniziato a risiedere nel codice. Insieme, queste pratiche divennero note come "tutto come codice".

L'idea centrale del "tutto come codice" è che, se una parte del sistema può essere descritta, dovrebbe essere descritta come codice e gestita allo stesso modo delle applicazioni software.

La PaC è essenzialmente l'applicazione di questa filosofia alle regole, alla governance e alla conformità. Tradizionalmente, le policy vivevano in PDF e wiki o venivano decise da un comitato e venivano applicate dagli esseri umani. Questo processo funzionava quando i cicli di rilascio erano lenti e l'infrastruttura relativamente statica.

Con l'arrivo delle architetture cloud-native e dei microservizi, e i team che hanno iniziato a distribuire codice più volte al giorno, i processi manuali non riuscivano a tenere il passo. PaC ha affrontato questa sfida esprimendo le policy in formati leggibili dalla macchina, così da poter essere versionate in Git, revisionate come file di codice, testate in CI e applicate automaticamente nelle pipeline o al tempo di esecuzione.

La policy as code è una pratica per gestire le policy IT come se fossero codice software. Infrastructure as code (IaC) è simile, ma con un focus diverso. Consente ai team di ingegneri di definire e gestire l'infrastruttura IT utilizzando il codice dell'applicazione.

Invece di creare e configurare manualmente asset di rete come macchine virtuali (VM) e bilanciatori di carico, l'IaC consente agli sviluppatori di scrivere codice per descrivere lo stato desiderato di queste risorse. Uno strumento IaC prende quindi quel codice e crea o modifica le risorse specificate.

L'IaC semplifica notevolmente la scalabilità e l'automazione dell'infrastruttura. Se un team ha bisogno di più server, può semplicemente modificare un numero nel codice (da sei istanze a nove, ad esempio). Gli strumenti di automazione gestiscono i dettagli dell'approvvigionamento di tali risorse extra.

A livello generale, l'IaC determina quale infrastruttura dovrebbe esistere e come deve essere configurata, mentre il PaC si concentra sulle regole e i vincoli che l'infrastruttura deve rispettare. Il codice IaC crea e configura risorse, e il codice PaC aiuta a garantire che tali risorse (e i modi in cui vengono utilizzate) rispettino requisiti di sicurezza definiti, standard di conformità e guardrail operativi.

In molte architetture IT moderne e configurazioni CI/CD, IaC e PaC offrono benefici complementari. IaC automatizza il provisioning, mentre PaC aggiunge una governance automatizzata.

Quando uno sviluppatore modifica un file IaC, un motore PaC può ispezionare il nuovo piano o configurazione. Se tutto è conforme alle policy stabilite, la modifica può procedere e l'infrastruttura viene aggiornata. Se qualcosa viola una regola, la pipeline fallisce e nulla viene implementato finché il problema non viene risolto.

DevSecOps riguarda l'integrazione di sicurezza e conformità nel ciclo di vita DevOps, invece di aggiungerle alla fine. Si tratta di un approccio di sviluppo in cui i processi di sicurezza sono prioritari ed eseguiti durante ogni fase del ciclo di vita dello sviluppo del software.

PaC supporta le pratiche DevSecOps attraverso:

PaC aiuta i team a dare priorità alla sicurezza spostando i controlli di sicurezza nelle prime fasi del processo di sviluppo, invece di aspettare di eseguire controlli dopo la distribuzione, quando i problemi possono colpire gli utenti. Se uno sviluppatore introduce una configurazione rischiosa o uno schema non sicuro, le policy automatizzate possono aiutare a rilevare il problema e a interrompere la build.

Gli strumenti PaC automatizzano l'applicazione mediante l'embedding delle regole di sicurezza direttamente nelle pipeline CI/CD e nel tempo di esecuzione, quindi i controlli avvengono automaticamente ogni volta che il codice o l'infrastruttura cambiano. Invece di affidarsi agli esseri umani per ricordare ogni standard di sicurezza e rivedere manualmente ogni modifica, il sistema valuta costantemente le modifiche per assicurarsi che nessuna fase venga saltata accidentalmente.

Il PaC aiuta gli sviluppatori a mantenere la velocità di distribuzione senza sacrificare coerenza e sicurezza. Esegue le stesse definizioni di policy in ogni ambiente e in ogni fase: sviluppo, test, staging e produzione. Questa funzione consente ai team di rilasciare aggiornamenti frequentemente, poiché possono essere certi che lo stesso insieme di regole venga applicato ovunque. Li aiuta anche a evitare situazioni in cui ambienti diversi si allontanano o utilizzano interpretazioni leggermente diverse delle regole.

PaC tratta le policy di sicurezza dell'applicazione come qualsiasi altro artefatto di codice che vive in un sistema di controllo versioni. I team di sviluppo, operazioni e sicurezza possono tutti revisionare, discutere e aggiornare le policy attraverso workflow familiari (recensioni del codice, strategie di ramificazione), il che rende le discussioni sulle policy più trasparenti e integrate nel lavoro quotidiano di sviluppo.

Il policy as code ha una vasta gamma di applicazioni per le architetture IT aziendali.

Sviluppatori e professionisti della sicurezza stanno esplorando il policy as code come modo per creare modelli di guardrail stratificati che coprono l'intero ciclo di vita di un workflow AI o agentico. Sebbene la pratica sia ancora in fase di sviluppo, le prime indagini hanno rivelato numerose possibili applicazioni del PaC nei workflow di AI.

Il PaC può aiutare a stabilire una chiara separazione tra il ragionamento dell'AI e il sistema che decide quali azioni può effettivamente eseguire. Lo strumento AI può proporre azioni o piani, ma un motore di policy valuta tali proposte rispetto a regole codificate prima che venga toccato qualsiasi sistema sottostante.

Nella fase di input, il PaC può aiutare a filtrare o trasformare i prompt degli utenti, oscurare dati sensibili, imporre l'isolamento del tenant e bloccare i pattern di attacco noti. Durante la pianificazione, il PaC può richiedere agli agenti AI di produrre piani strutturati e convalidare ogni fase rispetto agli strumenti, alle azioni e alle condizioni di rischio consentiti prima che l'esecuzione sia consentita.

Al momento dell'esecuzione, ogni invocazione di uno strumento o chiamata API può essere verificata dal livello di enforcement delle policy. Lo strato decide se consentire, rifiutare o modificare un'azione o trasformarla in un essere umano. Dopo l'esecuzione, le policy possono guidare la registrazione, le audit trail, le regole di conservazione e i filtri post-operatori sugli output dei modelli per aiutare a garantire che le risposte rispettino i requisiti necessari.

• Coerenza. Con il PaC, le policy vengono applicate allo stesso modo in tutti gli ambienti, perché lo stesso codice viene eseguito ovunque. Questa uniformità riduce le configurazioni uniche e "anomale" e impedisce ai team di dover ricordare processi manuali leggermente diversi per ogni ambiente.

• Efficienza. Quando le policy sono codificate, possono essere applicate automaticamente nelle pipeline CI/CD o al momento della distribuzione, eliminando la necessità di controlli e approvazioni manuali.

• Automazione. Il PaC consente la validazione automatica e il test delle policy, che aiutano i team a minimizzare l'impatto degli errori umani, individuare configurazioni errate e gestire le vulnerabilità di sicurezza prima che entrino in produzione.

• Visibilità. Con le policy scritte nel codice e memorizzate centralmente, gli stakeholder possono vedere esattamente quali regole sono in atto invece di fare affidamento su documenti sparsi e sui ricordi delle persone.

• Scalabilità. La valutazione delle policy è automatizzata, così le organizzazioni possono applicare policy su larga scala su molti servizi, cluster o account senza aumenti proporzionali del personale.

• Collaborazione. PaC semplifica la collaborazione sul codice delle policy. Questi workflow condivisi abbattono i silos, allineano la sicurezza e la governance alle pratiche DevOps e rendono le discussioni sulle policy più concrete e verificabili.