Nei nostri tre articoli precedenti abbiamo gettato le basi per un ecosistema Model Context Protocol (MCP) protetto analizzando l'attuale panorama delle minacce informatiche, implementando un'autenticazione e un'autorizzazione solide ed esplorando misure fondamentali di logging e sicurezza del runtime. Questi articoli si sono concentrati su chi può accedere a cosa e su come monitorare tali interazioni. Ora sposteremo l'attenzione sugli ambienti fisici e virtuali in cui risiedono questi sistemi.
Naturalmente, lo sviluppo incentrato sulla sicurezza rappresenta solo metà della sfida. Il deployment di un server MCP con misure di sicurezza deboli può vanificare anche il codice più solido, come dimostrato da recenti incidenti come gli attacchi "NeighborJack" in cui i malintenzionati hanno sfruttato server non autenticati ed esposti pubblicamente semplicemente perché associati a interfacce di rete non sicure. Mentre il settore si muove verso un'IA agentica altamente autonoma, la posta in gioco per proteggere e mettere in sicurezza i deployment non è mai stata così alta.
In questo articolo vedremo come sfruttare la tecnologia Red Hat, in particolare la containerizzazione e Red Hat OpenShift, per creare un deployment "incentrato sulla sicurezza" che utilizzi container non root, file system di sola lettura e policy di rete restrittive, in modo da proteggere in modo più efficace i tuoi server MCP in produzione.
Proteggi la tua infrastruttura
Sebbene un codice solido sia essenziale, la sicurezza del tuo server MCP dipende dall'ambiente in cui si trova. Red Hat consiglia di distribuire i server MCP all'interno dei container per sfruttare l'isolamento integrato e le funzionalità di sicurezza a livello del kernel. Grazie all'integrazione con OpenShift, ottieni l'accesso immediato a impostazioni predefinite avanzate, incentrate sulla sicurezza, che possono contribuire a rafforzare notevolmente il tuo deployment. Per un deployment MCP davvero "incentrato sulla sicurezza", la tua strategia deve concentrarsi su tre aspetti fondamentali.
1. Rafforza l'ambiente di runtime
Per evitare che un utente malintenzionato trovi spazio d’azione, è necessario limitare ciò che il container può fare a livello di sistema operativo (OS).
- Esegui come non root: i server MCP non devono mai utilizzare privilegi root durante l'esecuzione. Questo garantisce che, anche se uno strumento viene compromesso, ad esempio tramite prompt injection, l'autore dell'attacco non possa accedere ai file a livello di host o alle interfacce dei dispositivi.
- Applica un file system di sola lettura: il montaggio del file system root in modalità sola lettura protegge dall'"avvelenamento degli strumenti" e dalla persistenza non autorizzata. Limitando le scritture a directory specifiche come
/tmp, per un utente malintenzionato sarà più difficile modificare il comportamento del server o installare malware. - Rimuovi le funzionalità pericolose: la maggior parte delle funzioni MCP, come le chiamate API o l'I/O dei file, non richiede autorizzazioni avanzate del kernel. Rimuovendo esplicitamente tutte le funzionalità Linux, ad esempio utilizzando
capDrop: ["ALL"]), previeni l'escalation dei privilegi tramite il kernel.
2. Riduci al minimo la superficie di attacco
La riduzione del "raggio d'impatto" di una potenziale compromissione inizia dalla stessa immagine del container.
Utilizza immagini di base minimePagina disponibile in Inglese (Italiano non disponibile) : crea i tuoi server utilizzando immagini Universal Base Image (UBI) "minimal" o "distroless". Escludendo shell, compilatori e utility non necessarie, si eliminano proprio gli strumenti di cui un utente malintenzionato avrebbe bisogno per muoversi lateralmente dopo una violazione.- Scansione automatizzata con Red Hat Quay: l'hosting delle tue immagini in Quay consente una scansione continua delle vulnerabilità. In questo modo ti assicuri che le tue dipendenze Python o Node.js non introducano vulnerabilità ed esposizioni comuni note (CVE) nell'ambiente di produzione.
- Rafforzamento del kernel: su OpenShift, dovresti mantenere l'applicazione predefinita di
SELinuxPagina disponibile in Inglese (Italiano non disponibile) e applicare profili seccomp che limitano il server alle chiamate di sistema essenziali per le operazioni di rete e sui file.
3. Isolamento della rete e controllo del traffico
Infine, occorre controllare rigorosamente il modo in cui il server MCP comunica con il resto dell'infrastruttura.
- Zero trust networking: utilizza OpenShift NetworkPolicies per accertarti che solo i servizi autorizzati, come un gateway dell'agente specifico, possano raggiungere il tuo server MCP.
- Egress protetto: se il tuo server deve inoltrare chiamate ad API esterne, ad esempio uno strumento meteo o di dati, limita il traffico in uscita solo a quei domini specifici.
- Protezione avanzata: per gli ambienti ad alta sensibilità, Red Hat OpenShift Service Mesh può fornire la sicurezza mTLS (mutual Transport Layer Security) e l'autenticazione per client, aggiungendo un livello di sicurezza basato sull'identità in aggiunta al tuo OAuth a livello di applicazione.
Andando oltre il semplice deployment e adottando queste funzionalità native di OpenShift incentrate sulla sicurezza, crei una base resiliente che ti aiuta a proteggere i tuoi strumenti MCP da minacce esterne e attacchi interni.
Considerazioni finali
Per distribuire un server MCP non basta far semplicemente funzionare del codice. È necessario creare un perimetro protetto in grado di resistere alle pressioni specifiche di un ecosistema basato sull'IA. Come abbiamo visto in questo articolo, l'integrazione di Red Hat OpenShift e della containerizzazione aiuta a fornire la protezione necessaria, dall'esecuzione non root a rigide policy di rete, per evitare che i tuoi strumenti diventino vulnerabili.
Tratta il tuo ambiente di deployment con lo stesso rigore incentrato sulla sicurezza del tuo codice sorgente. In questo modo, contribuirai a colmare il divario tra un proof of concept funzionale e un servizio resiliente e pronto per la produzione. Man mano che sviluppi sistemi di IA basati su agenti sempre più potenti, attenerti a queste best practice per l'infrastruttura ti aiuterà a difenderti sia dalle vulnerabilità attuali sia dalle minacce emergenti di domani.
Prova prodotto
Red Hat OpenShift AI (autogestito) | Versione di prova del prodotto
Sull'autore
Huzaifa Sidhpurwala is a Senior Principal Product Security Engineer - AI security, safety and trustworthiness, working for Red Hat Product Security Team.
Altri risultati simili a questo
Le minacce dell'IA si muovono rapidamente. Anche le tue difese dovrebbero farlo.
Dal metallo all'agente: perché l'IA basata sugli agenti è un'evoluzione delle applicazioni
Technically Speaking | Defining sovereign AI with open source
Technically Speaking | Inside open source AI strategy
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Virtualizzazione
Il futuro della virtualizzazione negli ambienti aziendali per i carichi di lavoro on premise o nel cloud