Review settimanale completata — 3 account AWS (produzione, staging, sviluppo). 🔴 ALTO: 1 drift. 🟡 MEDIO: 3 drift. ⚪ BASSO: 3 drift.
AGENTE · CONFIGURATION AUDIT
Le configurazioni cloud restano allineate alla baseline di sicurezza.
Configuration Audit esegue settimanalmente la review delle configurazioni cloud del cliente (AWS, Azure, GCP). Confronta con la baseline di sicurezza dichiarata, segnala drift, propone azioni di rimedio. Coerente con framework di sicurezza pubblici (CIS Benchmark, NIS2, DORA).
Configuration Audit al lavoro.
🔴 Nuovo bucket S3 in produzione configurato come pubblico. Contiene file con riferimenti a clienti aziendali. Azione richiesta: blocco accesso pubblico immediato.
Bucket S3 pubblico: blocchiamo adesso. I 3 medi li metto in sprint della prossima settimana.
Azioni registrate. Rimedio applicato. Sprint task generati. Evento tracciato per audit ISO 27001.
Perché esiste.
Le configurazioni cloud delle aziende mid-large sono complesse: account multipli, regioni multiple, decine o centinaia di servizi (compute, storage, networking, IAM, monitoring). La sicurezza dipende dalla coerenza delle configurazioni con le baseline dichiarate. Il drift è costante: configurazioni modificate manualmente, nuovi servizi non configurati secondo standard, aggiornamenti di policy non propagati su tutti gli account.
Come porta la review nel canale del team security.
Il problema operativo non è la mancanza di strumenti — i CSPM esistono — è l'integrazione del segnale nel flusso operativo del team security. La review manuale settimanale è lenta e dipende dalla disponibilità delle persone. Il drift critico emerge spesso solo all'incident. Configuration Audit porta la review nel canale del team security con cadenza dichiarata, a severity già classificata, con azioni proposte pronte per la decisione del responsabile.
I rimedi sono pre-approvati e tracciati.
Per rimedi a basso rischio pre-approvati dal team security, l'agente applica il rimedio con notifica. Per rimedi su produzione o con impatto operativo, l'agente propone l'azione e il responsabile sicurezza decide. La regola di auto-rimedio è dichiarativa.
Security cloud, DevOps, compliance: tre prospettive sul drift.
Responsabile sicurezza cloud (CISO)
Recupera il tempo della review manuale settimanale degli account. La capacità del team si concentra sui drift che richiedono giudizio: il CISO non legge trecento configurazioni, legge il quadro strutturato che l'agente ha già classificato per severity.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
Responsabile DevOps
Vede in modo strutturato il drift dalle baseline. Le azioni di rimedio diventano task nella pipeline di patching standard, non emergenze gestite con urgenza fuori dai processi.
Proposta n. 2024-081 In revisione
Disclosure mancante
art. 21 TUF · strumento finanziario regolato
Alt. 1 …nel rispetto dell'art. 21 TUF e delle disposizioni Consob vigenti.
Alt. 2 …con disclosure completa allegata al documento di offerta.
Traccia audit registrata · 14:31
Responsabile compliance
Ha la traccia ispezionabile delle review per audit di sicurezza (ISO 27001, NIS2 per energia/telco/PA, DORA per banking). La query sul registro restituisce ogni drift identificato, ogni decisione presa, ogni rimedio applicato.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
Domenica sera. La sintesi è pronta per il CISO prima del lunedì mattina.
L'agente è schedulato ogni domenica alle 20:00.
Per un'azienda B2B SaaS con tre account AWS (produzione, staging, sviluppo), l'agente è schedulato ogni domenica alle 20:00. Legge la configurazione dei servizi rilevanti in tutti gli account. L'integrazione con le API AWS è realizzata in fase di delivery dal team Exelab. Confronta con la baseline dichiarata dal team security (basata su CIS Benchmark e regole interne aziendali).
Sette drift identificati, classificati per severity.
Identifica sette drift. Tre bassi: log retention ridotta manualmente su tre bucket S3. Tre medi: security group con porta aperta, volume senza encryption, IAM policy con permission eccessive. Uno alto: nuovo bucket in produzione configurato come pubblico per errore, contenente file con riferimenti a clienti.
Il CISO autorizza il blocco e schedula i rimedi.
La sintesi arriva al canale Slack domenica sera. Il CISO autorizza il blocco immediato del bucket pubblico, schedula i tre drift medi per la settimana, accetta i tre bassi con nota motivata. L'evento completo resta nel registro audit per audit ISO 27001.
Configurazione e risorse tecniche.
Le regole di Configuration Audit sono dichiarative. Il team security cloud del cliente definisce le baseline di configurazione per servizio (basate su CIS Benchmark, NIS2, framework interno), le soglie di severity per drift, le regole di rimedio (cosa è auto-rimediabile con notifica, cosa richiede approvazione manuale). Le regole vivono nel repository del cliente, versionate.
L'integrazione con i cloud provider (AWS, Azure, GCP) si realizza in fase di delivery dal team Exelab tramite adapter dedicati che usano le API ufficiali dei provider con accesso IAM read-only (più azioni di rimedio configurate per i casi pre-approvati). Il perimetro di accesso è dichiarato e negoziato in delivery con il team security del cliente.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, credential-detector, tool-rate-limit
- Canali nativi
- Slack, Telegram, HTTP OpenAI-compatible
- Integrazione AWS, Azure, GCP
- adapter dedicato realizzato in fase di delivery (via API cloud provider con accesso IAM read-only + rimedi pre-approvati)
- Baseline di sicurezza
- dichiarative, versionate, scritte dal team security cloud (compatibili con CIS Benchmark)
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS sui pattern di configurazione storica
- Registro
- immutabile, interrogabile con client SQL standard
Domande frequenti sull'agente.
Per rimedi a basso rischio pre-approvati dal team security (es. disabilitazione dell'accesso pubblico su un bucket appena creato in staging), l'agente può applicare il rimedio con notifica. Per rimedi su produzione o con impatto operativo, l'agente propone l'azione e il responsabile sicurezza decide. La regola di auto-rimedio è dichiarativa e configurata dal team.
I CSPM (Prisma Cloud, Wiz, Lacework) forniscono il monitoraggio delle configurazioni cloud come servizio dedicato. Configuration Audit copre la stessa funzione ma è integrato in Polyant come parte della squadra IT del cliente, sotto la governance unica del runtime. Per i clienti che già usano un CSPM, Configuration Audit può lavorare in aggregazione (lettura dell'output del CSPM) oppure sostituire la funzione di review per casi specifici.
Il pattern tipico è 6-10 settimane. Discovery e configurazione delle baseline 1-2 settimane, scrittura delle regole di severity 2-3 settimane, integrazione con i cloud provider del cliente 2-3 settimane, hand-off al team security cloud 1-2 settimane.
L'agente gestisce account multipli e cloud provider diversi nella stessa istanza. Ogni account e provider ha il proprio adapter; la sintesi settimanale aggrega i drift cross-account in un unico quadro per il CISO. La configurazione del perimetro di accesso per ciascun provider viene concordata in fase di delivery.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Configuration Audit si configurerebbe sul caso del cliente. Quali account cloud, quali baseline di sicurezza, quali framework di riferimento.