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

Piattaforma di apprendimento automatico (ML) open source per il cloud ibrido.

Sull'autore

Huzaifa Sidhpurwala is a Senior Principal Product Security Engineer - AI security, safety and trustworthiness, working for Red Hat Product Security Team.

 
UI_Icon-Red_Hat-Close-A-Black-RGB

Ricerca per canale

automation icon

Automazione

Novità sull'automazione IT di tecnologie, team e ambienti

AI icon

Intelligenza artificiale

Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque

open hybrid cloud icon

Hybrid cloud open source

Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido

security icon

Sicurezza

Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti

edge icon

Edge computing

Aggiornamenti sulle piattaforme che semplificano l'operatività edge

Infrastructure icon

Infrastruttura

Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale

application development icon

Applicazioni

Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili

Virtualization icon

Virtualizzazione

Il futuro della virtualizzazione negli ambienti aziendali per i carichi di lavoro on premise o nel cloud