Security checklist per distribuire AI on‑premise nella tua rete: controlli essenziali e best practice

Distribuire modelli di AI on‑premise (o in ambienti “self‑hosted”) può darti maggiore controllo su dati, latenza e conformità. Ma porta anche nuove superfici d’attacco: modelli e pesi, pipeline di training/inference, container, GPU, API interne, dataset e log. Questa checklist ti guida nei controlli essenziali e nelle best practice per ridurre il rischio, allinearti ai requisiti di sicurezza e creare un percorso operativo ripetibile per andare in produzione.

1) Definisci perimetro, minacce e requisiti (prima di installare)

Allinea obiettivi e responsabilità

• Identifica use case e dati coinvolti (personali, sensibili, segreti industriali).
• Definisci owner e responsabilità: IT, Security, Data/AI, Compliance.
• Stabilisci security baseline e criteri di accettazione del rischio.

Threat modeling “AI-aware”

Integra nel threat modeling rischi tipici dei sistemi AI: data poisoning, model inversion, prompt injection, esfiltrazione via output, abuso delle API, supply chain del modello. Un riferimento utile per la gestione del rischio AI è il framework di NIST, AI RMF 1.0, che struttura governance e controlli di rischio lungo il ciclo di vita secondo NIST.

2) Architettura e rete: segmentazione, esposizione minima, zero trust

Segmentazione e micro‑segmentazione

• Separa rete AI (inference/training) da rete utente e da produzione core.
• Applica regole deny-by-default tra segmenti.
• Se usi Kubernetes/Openshift: NetworkPolicies per namespace e workload.

Esposizione controllata

• Evita endpoint AI direttamente esposti su Internet se non indispensabile.
• Pubblica le API dietro reverse proxy/WAF, rate limiting e autenticazione forte.
• Usa mTLS tra servizi interni per ridurre MITM e lateral movement.

Controlli su DNS, egress e aggiornamenti

• Consenti egress solo verso repository necessari (es. registry interno, mirror approvati).
• Se possibile, crea mirror interni (OS packages, container images, model artifacts).

3) Identità e accessi: least privilege per umani e servizi

IAM per utenti

• MFA obbligatoria.
• Ruoli separati: amministratore piattaforma, operatore, data steward, sviluppatore.
• Accesso ai dati basato su need-to-know (non solo su team).

Service identity e segreti

• Credenziali e token con scadenza breve e rotazione.
• Usa un vault (es. HashiCorp Vault, cloud KMS on‑prem compatibile) e evita segreti in:
• variabili d’ambiente persistenti
• file di configurazione nel repo
• immagini container

Controlli specifici per Kubernetes

• RBAC restrittivo (no cluster-admin per default).
• Disabilita privilegi inutili: privileged, hostPath, CAP_SYS_ADMIN.

4) Hardening di host, container e GPU

Sistemi operativi e hypervisor

• Baseline CIS dove applicabile.
• Patch management con SLA (es. patch critiche entro X giorni).
• Disabilita servizi non necessari.

Container security

• Immagini minimali, firmate e scansionate.
• Esegui come non-root.
• File system in sola lettura quando possibile.
• Limita capacità Linux e syscalls (seccomp/apparmor).

Considerazioni per GPU

• Isola i workload GPU (MIG dove disponibile, policy di scheduling).
• Monitora driver e runtime (CUDA/NVIDIA) e aggiorna regolarmente.

5) Supply chain: modello, dipendenze e artefatti (punto più sottovalutato)

Origine e integrità dei modelli

• Scarica modelli/pesi solo da fonti approvate e versionate.
• Verifica hash e firma degli artefatti.
• Mantieni un registro interno di modelli (Model Registry) con:
• versione
• provenienza
• licenza
• data di approvazione
• valutazioni di sicurezza

SBOM e scansione vulnerabilità

• Genera SBOM per immagini e dipendenze.
• Scansiona CVE e applica policy di blocco per severity alta/critica.

Pipeline CI/CD e MLOps

• Separazione ambienti (dev/test/prod).
• Approvals per promozione di modelli in produzione.
• Artefatti immutabili e tracciabilità end‑to‑end.

6) Data security & privacy: minimizzazione, cifratura, controlli di accesso

Classificazione e minimizzazione

• Classifica dataset e prompt/risposte salvate.
• Minimizza: non usare dati personali se non necessario.

Cifratura

• At rest: cifratura su storage, database, backup.
• In transit: TLS 1.2+ (meglio 1.3) e mTLS tra microservizi.

Retention e log

• Definisci retention per:
• prompt e completions
• log applicativi
• telemetria
• Redazione (masking) di PII nei log.

7) Sicurezza applicativa per LLM e sistemi RAG

Protezione da prompt injection e data exfiltration

• Se usi RAG (retrieval-augmented generation), separa:
• documenti indicizzati
• policy di accesso
• contesto inviato al modello
• Applica filtri su input e output.
• Imposta guardrails (policy, regex, classificatori, allow/deny list).

Validazione degli strumenti (tool use)

• Se il modello può chiamare tool (es. DB, file system, ticketing):
• consenti solo comandi/azioni whitelisted
• richiedi autorizzazione per azioni ad impatto
• registra ogni chiamata con contesto

Limiti e rate control

• Quota per utente/app.
• Rate limiting e circuit breaker per prevenire DoS e runaway costs (anche on‑prem: GPU saturation).

8) Monitoraggio, logging, rilevamento e risposta

Logging sicuro e utile

• Centralizza log e metriche (SIEM/observability).
• Collega eventi IAM, cluster, API gateway e applicazione.

Detection engineering

• Alert su: