Proteggere la distribuzione del server MCP Azure

Azure MCP Server connette gli agenti di intelligenza artificiale ai servizi di Azure, esegue strumenti per conto dell'utente e broker l'accesso alle risorse Azure tramite i token che autorizzano ogni chiamata. Poiché il server MCP Azure si trova tra gli agenti e le risorse cloud, è necessario proteggere l'Azure server MCP stesso, i token che autorizzano l'accesso e gli input e gli output dello strumento che passano attraverso gli agenti.

Questo articolo fornisce indicazioni su come proteggere al meglio la distribuzione del server MCP Azure.

Autenticazione e autorizzazione

Il server MCP Azure usa Microsoft Entra ID tramite la libreria di identità Azure per autenticare i chiamanti. La specifica di autorizzazione MCP richiede OAuth 2.1, quindi considerare il server MCP Azure come server di risorse OAuth 2.1. I client devono usare PKCE (Proof Key for Code Exchange) durante l'esecuzione di flussi di codice di autorizzazione. Applicare le procedure seguenti:

  • Convalidare ogni token di autorizzazione. Verificare l'autorità di certificazione, il gruppo di destinatari e la scadenza per ogni token di autorizzazione in ingresso prima di consentire l'esecuzione dello strumento. Non considerare attendibili i token mancanti o emessi per una risorsa diversa.

  • Associare i token di autorizzazione ai destinatari previsti. Usare i token associati al gruppo di destinatari in modo che un token emesso per un servizio non possa essere riprodotto su un altro.

  • Applicare la rigorosa corrispondenza dell'URI di reindirizzamento e il consenso per client. Per i flussi di codice di autorizzazione, consentire solo URI di reindirizzamento preregistrati e esatti e richiedere il consenso per client, in modo che un codice di autorizzazione intercettato non possa essere riscattato da un client diverso.

  • Seguire il controllo degli accessi in base al ruolo con privilegi minimi. Concedere a ogni chiamante solo i ruoli controllo degli accessi in base al ruolo Azure necessari per l'attività. Il server MCP Azure riflette le autorizzazioni di sottoscrizione Azure: i chiamanti che dispongono di accesso generale alle sottoscrizioni possono richiamare un ampio set di strumenti. Definire l'ambito delle assegnazioni di ruolo il più piccolo possibile. Abilitare solo gli strumenti necessari per ogni chiamante, perché ogni strumento raggiungibile aggiunge alla superficie di attacco.

  • Preferisce le identità del carico di lavoro. Negli scenari agentic usare identità gestite o identità del carico di lavoro anziché segreti di lunga durata o credenziali condivise. Quando le credenziali statiche non sono inevitabili, ad esempio le chiavi API per i servizi di terze parti che non supportano l'identità del carico di lavoro, archiviarle in Azure Key Vault e farvi riferimento dalla configurazione della distribuzione. Non archiviare mai le credenziali nel codice sorgente o nei file di configurazione in testo normale e ruotarle in base a una pianificazione regolare.

  • Evitare il modello confuso-vice. Definire l'ambito dell'identità e delle autorizzazioni Azure del server MCP del Azure al minimo necessario. Non consentire al server di fungere da assistente che concede i propri privilegi generali a un chiamante con privilegi inferiori: separare l'identità di esecuzione del server dall'autorizzazione del chiamante e applicare i controlli delle autorizzazioni per ogni chiamante anziché basarsi esclusivamente sulle credenziali del server.

Protezione remota del server MCP Azure

Quando si distribuisce Azure server MCP come server self-hosted remoto, è consigliabile posizionarlo dietro Gestione API di Azure (GESTIONE API) come gateway di imposizione:

  • Posizionare il server MCP Azure dietro un gateway di imposizione. Gestione API può convalidare Entra ID token prima che le richieste raggiungano il server MCP Azure, eliminando la necessità del codice dell'applicazione di controllare i token.

  • Applicare i criteri del gateway per la limitazione della frequenza e il controllo. Usare i criteri di Gestione API per limitare la frequenza con cui i chiamanti possono effettuare richieste, limitare i percorsi degli strumenti consentiti e registrare ogni richiesta a scopo di controllo.

  • Centralizzare il controllo di accesso in un singolo punto di soffocamento. Un gateway fornisce un singolo punto di soffocamento per il controllo di accesso e l'osservabilità tra più strumenti MCP downstream.

Proteggere l'endpoint a cui si connettono i client del server MCP Azure. Un URL sostituito o spoofing può ricevere richieste di esecuzione degli strumenti ed esporre credenziali o Azure dati delle risorse. Per ridurre il rischio:

  • Connettersi solo agli endpoint del server MCP attendibili Azure. Usare solo gli endpoint di cui è stato effettuato il provisioning o che il team espone tramite Gestione API. Non derivare l'URL del server MCP Azure dall'input fornito dall'utente o dalle risposte di individuazione non autenticate.

  • Verificare il certificato TLS del server MCP Azure. Verificare che l'endpoint corrisponda all'host previsto. Quando si usa Gestione API, instradare i client attraverso il gateway in modo che l'endpoint di backup non possa essere reindirizzato automaticamente.

  • Esito negativo chiuso in caso di errori del certificato. Considerare un certificato Azure del server MCP non verificato o non riconosciuto come un errore di connessione, non un avviso da ignorare.

Per le opzioni di self-hosting, vedere Distribuire un server mcp self-hosted Azure.

Protezione avanzata della distribuzione locale

Un server MCP Azure locale viene eseguito nell'ambiente di sviluppo per l'uso dello sviluppo. Poiché può agire con l'identità Azure, esaminare l'accesso all'account connesso prima di connettere un agente alle risorse di Azure:

  • Esaminare le autorizzazioni di Azure. Controllare i ruoli controllo degli accessi in base al ruolo Azure assegnati all'account per sviluppatore e rimuovere le autorizzazioni generali di sottoscrizione o gruppo di gestione non necessarie per l'attività.

  • Limitare l'accesso locale. Eseguire il server MCP Azure locale da una workstation o un contenitore attendibile e non esporre l'endpoint locale a reti non attendibili o ad altri utenti nel computer.

  • Mantenere aggiornato il server locale. Usare i pacchetti del server MCP corrente Azure e le dipendenze con patch, soprattutto prima di eseguire test su risorse non di produzione Azure.

  • Esecuzione locale sandbox. Eseguire il server MCP Azure locale in un contenitore o in una sandbox con accesso limitato al file system e alla rete e mantenere la toolchain con patch, per limitare l'impatto di inserimento dei comandi e l'attraversamento del percorso quando gli strumenti generano sottoprocessi.

Non usare un server MCP Azure locale per gestire i dati di produzione o le credenziali di produzione.

Avvelenamento da strumento e inserimento di richieste

Le descrizioni degli strumenti e le risposte degli strumenti MCP sono input per il contesto dell'agente. Se l'output degli strumenti o dei metadati degli strumenti è dannoso, può influenzare un agente che ha accesso agli strumenti del server MCP Azure e le autorizzazioni Azure dietro di esse.

Per ridurre questo rischio per le distribuzioni del server MCP Azure:

  • Preferisce l'Microsoft ufficiale Azure server MCP. Usare il server MCP Azure di prima parte per i servizi Azure anziché un server non verificato che espone strumenti di Azure simili. Considerare le modifiche dello schema dello strumento come modifiche alle dipendenze che richiedono la revisione.

  • Considerare attendibile ma verificare il contesto dello strumento. Considerare le descrizioni e le risposte degli strumenti come input non attendibile per l'agente. Esaminare le definizioni degli strumenti prima dell'uso in produzione e convalidare o purificare i dati che le risposte degli strumenti passano di nuovo nel contesto dell'agente.

  • Definizioni degli strumenti di controllo delle modifiche. Esaminare e aggiungere descrizioni e schemi di strumenti validi noti e richiedere la riapplicazione prima che i metadati aggiornati degli strumenti vengano applicati, in modo che un server non possa modificare automaticamente il comportamento dopo l'approvazione (una catena di approvvigionamento "rug pull").

  • Usare Azure controlli di sicurezza in cui si adattano all'architettura. Valutare i controlli in Microsoft controlli di sicurezza per esaminare il contesto dell'agente, rilevare i flussi di dati sensibili e monitorare Azure carichi di lavoro di intelligenza artificiale. Verificare ogni percorso di integrazione prima di basarsi su di esso nell'ambiente di produzione.

Attendibilità del server MCP di terze parti

Molti ambienti di sviluppo eseguono più server MCP contemporaneamente. Per Azure lavoro, preferire il Microsoft ufficiale gestito Azure MCP Server rispetto alle alternative della community per i servizi Azure.

Se si aggiunge un server MCP di terze parti accanto a Azure server MCP:

  • Verificare il server di pubblicazione e il percorso di aggiornamento. Usare i server di autori attendibili con un contatto di sicurezza pubblico. Esaminare i log delle modifiche e gli aggiornamenti dei pacchetti prima di consentire il server di terze parti in un ambiente agente che può raggiungere anche Azure strumenti del server MCP.

  • Mantenere separati i contesti delle credenziali. Non consentire a un server non verificato di condividere le credenziali, il file system o l'accesso alla rete usato da Azure server MCP. Eseguire server non attendibili con privilegi minimi in un ambiente isolato.

  • Esaminare gli strumenti nel contesto completo dell'agente. Un server dannoso può usare le descrizioni degli strumenti per influenzare il comportamento dell'agente verso altri server attendibili nello stesso contesto, incluso Azure SERVER MCP. Controllare le descrizioni degli strumenti per ogni server configurato, non solo gli strumenti di Azure.

Governance e monitoraggio

Tenere traccia delle Azure istanze del server MCP eseguite nell'ambiente e monitorarne l'attività:

  • Server approvati per l'inventario. Mantenere una baseline valida nota degli endpoint del server MCP registrati Azure, ad esempio con Azure Centro API, in modo da poter rilevare server "shadow" non registrati che rientrano nella governance.

  • Monitorare l'attività e conservare le prove. Correlare Azure'attività del server MCP in Microsoft Sentinel e conservare i log di controllo Microsoft Purview in modo da poter analizzare le chiamate di strumenti sospette.

Microsoft controlli di sicurezza

Usare i seguenti Microsoft servizi di sicurezza per aggiungere una difesa approfondita per i carichi di lavoro del server MCP Azure. L'applicabilità di ogni controllo alla distribuzione specifica dipende dall'architettura. Valutare ogni controllo nel contesto del proprio ambiente:

  • Esaminare il contesto dell'agente con Prompt Shields. Usare Sicurezza dei contenuti di Azure AI Prompt Shields per controllare il contenuto immettendo il contesto dell'agente, incluse le descrizioni degli strumenti e gli output degli strumenti, e rilevare potenziali tentativi di inserimento delle richieste. È consigliabile integrare Prompt Shields nella pipeline dell'agente quando si usano metadati dello strumento caricati dinamicamente. Per altre informazioni, vedere Prompt Shields.For more information, see Prompt Shields.

  • Rilevare i flussi di dati sensibili con Purview DLP. Quando il carico di lavoro è integrato in modo esplicito con Microsoft Purview, usare i criteri di prevenzione della perdita dei dati di Purview per rilevare e contrassegnare i dati sensibili nei flussi di dati associati agli agenti. La copertura dei parametri arbitrari di chiamata agli strumenti non è automatica. Dipende dall'architettura di distribuzione e dai connettori Purview usati dal carico di lavoro. Valutare se il percorso di integrazione specifico supporta i controlli necessari prima di basarsi sulla prevenzione della perdita dei dati per i carichi di lavoro dell'agente. Per altre informazioni, vedere la documentazione di Microsoft Purview.

  • Monitorare i carichi di lavoro di intelligenza artificiale con Defender per il cloud. Usare Microsoft Defender per il cloud protezione dalle minacce di intelligenza artificiale per il rilevamento delle minacce in fase di runtime nei carichi di lavoro di intelligenza artificiale, inclusi gli avvisi sulle attività sospette in Azure OpenAI e Azure chiamate API del servizio di inferenza del modello di intelligenza artificiale. La copertura non si estende automaticamente agli output arbitrari degli strumenti MCP. Si applica al livello del servizio di intelligenza artificiale Azure nell'architettura. Per altre informazioni, vedere Protezione dalle minacce per l'intelligenza artificiale.

Note

I controlli elencati in precedenza sono servizi di sicurezza generali Azure. Verificare che il percorso di integrazione di ogni controllo sia supportato per l'architettura di distribuzione del server MCP Azure specifica prima di abilitarla nell'ambiente di produzione.

Contenuti correlati

  • Last updated on