Proteja a implementação do seu Azure MCP Server

O Azure MCP Server liga agentes de IA aos serviços Azure, executa ferramentas em seu nome e gera o acesso aos seus recursos Azure através dos tokens que autorizam cada chamada. Como o Azure MCP Server situa-se entre os seus agentes e os seus recursos cloud, deve proteger o próprio Azure MCP Server, os tokens que autorizam o acesso e as entradas e saídas da ferramenta que fluem através dos seus agentes.

Este artigo fornece orientações sobre como proteger da melhor forma a implementação do seu servidor Azure MCP.

Autenticação e autorização

O Azure MCP Server utiliza o Microsoft Entra ID através da biblioteca Azure Identity para autenticar os chamadores. A especificação de autorização MCP requer OAuth 2.1, por isso trate o Azure MCP Server como um servidor de recursos OAuth 2.1. Os clientes devem usar PKCE (Proof Key for Code Exchange) ao executar fluxos de código de autorização. Aplicar as seguintes práticas:

  • Valide todos os tokens de autorização. Verifique o emissor, público e expiração de cada token de autorização recebido antes de permitir a execução da ferramenta. Não confie em tokens que não têm reivindicações obrigatórias ou que foram emitidos para um recurso diferente.

  • Vincule os tokens de autorização ao seu público-alvo. Use tokens vinculados ao público para que um token emitido para um serviço não possa ser repetido contra outro.

  • Aplicar a correspondência rigorosa de redirecionamento e URI e consentimento por cliente. Para fluxos de código de autorização, permitam apenas URIs de redirecionamento exatos pré-registados e requerem consentimento por cliente, para que um código de autorização interceptado não possa ser resgatado por outro cliente.

  • Siga o RBAC de menor privilégio. Conceda a cada chamador apenas os papéis Azure RBAC necessários para a sua tarefa. O Azure MCP Server reflete as suas permissões de subscrição no Azure – os chamadores que têm acesso amplo à subscrição podem invocar um conjunto vasto de ferramentas. Atribui funções de âmbito o mais restrito possível. Ativa apenas as ferramentas de que cada chamador precisa, porque cada ferramenta acessível acrescenta à tua superfície de ataque.

  • Prefiro identidades de carga de trabalho. Em cenários agentes, use identidades geridas ou identidades de carga de trabalho em vez de segredos duradouros ou credenciais partilhadas. Quando credenciais estáticas são inevitáveis – por exemplo, chaves API para serviços de terceiros que não suportam identidade de carga de trabalho – armazene-as no Azure Key Vault e faça referência a partir da sua configuração de implementação. Nunca armazene credenciais em código-fonte ou ficheiros de configuração em texto simples, e roda-as num calendário regular.

  • Evita o padrão do adjunto confuso. Defina a identidade Azure e as permissões do Azure Servidor MCP ao mínimo necessário para funcionar. Não deixe que o servidor atue como um adjunto que empresta os seus amplos privilégios a um chamador com privilégios mais baixos: separe a identidade de execução do servidor da autorização do chamador e faça cumprir verificações de permissões por chamador em vez de depender apenas das credenciais do servidor.

Remote Azure MCP Server Protection

Quando implementa o Azure MCP Server como um servidor remoto e auto-hospedado, considere colocá-lo atrás do API Management do Azure (APIM) como um gateway de aplicação:

  • Coloque o Azure MCP Server atrás de um gateway de aplicação. O APIM pode validar tokens Entra ID antes que os pedidos cheguem ao seu Azure MCP Server, o que elimina a necessidade de o seu código de aplicação inspecionar tokens.

  • Aplique políticas de gateway para limitação de taxas e auditoria. Use políticas APIM para limitar a frequência com que os chamadores podem fazer pedidos, restringir caminhos de ferramentas permitidos e registar todos os pedidos para efeitos de auditoria.

  • Centralize o controlo de acesso num único ponto de estrangulamento. Um gateway fornece um único ponto de estrangulamento para controlo de acesso e observabilidade através de múltiplas ferramentas MCP a jusante.

Proteja o endpoint ao qual os clientes Azure MCP Server se ligam. Uma URL substituída ou falsificada pode receber pedidos de execução de ferramentas e expor credenciais ou dados de recursos do Azure. Para reduzir esse risco:

  • Ligue-se apenas a endpoints confiáveis do Azure MCP Server. Use apenas endpoints que tenha provisionado ou que a sua equipa expõe através do APIM. Não derive o URL do Azure MCP Server a partir de entradas fornecidas pelo utilizador ou respostas de descoberta não autenticadas.

  • Verifique o certificado TLS do Azure MCP Server. Garante que o endpoint corresponde ao host esperado. Ao usar APIM, encaminhe os clientes através do gateway para que o endpoint de apoio não possa ser redirecionado silenciosamente.

  • Fail closed devido a erros de certificado. Trate um certificado do Azure MCP Server não verificado ou não reconhecido como uma falha de ligação, e não como um aviso para contornar.

Para opções de autoalojamento, veja Implementar um servidor Azure MCP auto-hospedado.

Fortalecimento de implantação local

Um servidor Azure MCP local corre no seu ambiente de desenvolvimento para uso de desenvolvimento. Como pode funcionar com a sua identidade Azure, veja o que a sua conta iniciada pode aceder antes de ligar um agente aos recursos do Azure:

  • Revise as suas permissões do Azure. Verifique as funções Azure RBAC atribuídas à sua conta de programador e remova permissões amplas de subscrição ou grupos de gestão que não são necessárias para a tarefa.

  • Limite o acesso local. Executa o servidor Azure MCP local a partir de uma estação de trabalho ou contentor de confiança, e não exponhas o endpoint local a redes não confiáveis ou a outros utilizadores na máquina.

  • Mantenha o servidor local atualizado. Use os pacotes atuais de Azure MCP Server e dependências corrigidas, especialmente antes de testar contra recursos Azure não produtivos.

  • Execução local em sandbox. Execute o Azure MCP Server local num contentor ou sandbox com acesso restrito ao sistema de ficheiros e à rede, e mantenha a cadeia de ferramentas atualizada, para limitar o impacto na injeção de comandos e na percorrência de caminhos quando as ferramentas geram subprocessos.

Não use um servidor Azure MCP local para gerir dados de produção ou credenciais de produção.

Intoxicação por ferramentas e injeção rápida

As descrições e respostas das ferramentas MCP são entradas para o contexto do seu agente. Se os metadados ou a saída da ferramenta forem maliciosos, podem influenciar um agente que tem acesso às ferramentas do Azure MCP Server e às permissões do Azure por detrás delas.

Para reduzir este risco nas implementações do Azure MCP Server:

  • Prefiro o Azure MCP Server oficial mantido pela Microsoft. Use o servidor Azure MCP de primeira parte para serviços Azure em vez de um servidor não verificado que expõe ferramentas Azure semelhantes. Trate as alterações no esquema da ferramenta como alterações de dependência que requerem revisão.

  • Confia mas verifica o contexto da ferramenta. Trate as descrições e respostas das ferramentas como entrada não confiável para o agente. Revise as definições das ferramentas antes do uso em produção e valide ou higienize os dados que as respostas das ferramentas repassam para o contexto do agente.

  • Definições de ferramentas de controlo de alterações. Revê e fixa esquemas e descrições de ferramentas conhecidas como bons, e exige reaprovação antes de os metadados atualizados da ferramenta entrarem em vigor, para que um servidor não possa mudar silenciosamente o comportamento após a aprovação (um "rug pull" na cadeia de abastecimento).

  • Usa os controlos de segurança do Azure onde se encaixam na tua arquitetura. Avalie os controlos nos controlos de segurança da Microsoft para inspecionar o contexto do agente, detetar fluxos de dados sensíveis e monitorizar cargas de trabalho de IA do Azure. Verifique cada caminho de integração antes de confiar nele em produção.

Confiança de servidores MCP de terceiros

Muitos ambientes de desenvolvimento executam vários servidores MCP ao mesmo tempo. Para trabalho no Azure, prefira o Azure MCP Server oficial mantido pela Microsoft em vez de alternativas comunitárias para serviços Azure.

Se adicionar um servidor MCP de terceiros ao lado do Azure MCP Server:

  • Verifica o editor e atualiza o caminho. Use servidores de editores de confiança com um contacto público de segurança. Revise os registos de alterações e as atualizações dos pacotes antes de permitir que o servidor de terceiros entre num ambiente de agente que também possa aceder às ferramentas do Azure MCP Server.

  • Mantenha os contextos das credenciais separados. Não deixe que um servidor não verificado partilhe as credenciais, o sistema de ficheiros ou o acesso à rede usados pelo Azure MCP Server. Executa servidores não confiáveis com menos privilégios num ambiente isolado.

  • Analise ferramentas em todo o contexto do agente. Um servidor malicioso pode usar as descrições das suas ferramentas para influenciar o comportamento dos agentes em relação a outros servidores de confiança no mesmo contexto, incluindo o Azure MCP Server. Audite as descrições das ferramentas para cada servidor que configurar, não apenas para as ferramentas do Azure.

Governação e monitorização

Acompanhe quais as instâncias do Azure MCP Server que correm no seu ambiente e monitorize a sua atividade:

  • Servidores aprovados pelo inventário. Mantenha uma base conhecida-boa dos endpoints registados do Azure MCP Server, por exemplo com o Azure API Center, para que possa detetar servidores "sombra" não registados que estejam fora da governação.

  • Monitorizar a atividade e reter provas. Correlacione a atividade do Azure MCP Server no Microsoft Sentinel e mantenha os registos de auditoria do Microsoft Purview para que possa investigar chamadas de ferramenta suspeitas.

Controlos de segurança da Microsoft

Utilize os seguintes serviços de segurança da Microsoft para adicionar uma defesa aprofundada para cargas de trabalho do Azure MCP Server. A aplicabilidade de cada controlo à sua implementação específica depende da sua arquitetura. Avalie cada controlo no contexto do seu próprio ambiente:

  • Inspecionar o contexto do agente com Prompt Shields. Use o Segurança de conteúdo de IA do Azure Prompt Shields para inspecionar conteúdos que entram no contexto do seu agente – incluindo descrições e saídas de ferramentas – e detetar potenciais tentativas de injeção de prompt. Considera integrar Prompt Shields no teu pipeline de agentes quando estiveres a usar metadados de ferramentas carregadas dinamicamente. Para mais informações, consulte Escudos de Prompt.

  • Detetar fluxos de dados sensíveis com o DLP Purview. Quando a sua carga de trabalho estiver explicitamente integrada com o Microsoft Purview, utilize políticas de Prevenção de Perda de Dados da Purview para ajudar a detetar e sinalizar dados sensíveis nos fluxos de dados associados aos seus agentes. A cobertura de parâmetros arbitrários de chamada de ferramenta não é automática – depende da tua arquitetura de implementação e dos conectores Purview que a tua carga de trabalho utiliza. Avalie se o seu caminho de integração específico suporta os controlos de que precisa antes de depender do DLP para cargas de trabalho dos agentes. Para obter mais informações, consulte a documentação do Microsoft Purview.

  • Monitorizar cargas de trabalho de IA com o Defender para a Cloud. Use Microsoft Defender para a Cloud proteção contra ameaças por IA para deteção de ameaças em tempo de execução em cargas de trabalho de IA, incluindo alertas sobre atividade suspeita em chamadas Azure OpenAI e Azure AI Model Inference Service. A cobertura não se estende automaticamente a saídas arbitrárias da ferramenta MCP – aplica-se à camada de serviços de IA do Azure na sua arquitetura. Para mais informações, consulte proteção contra ameaças por IA.

Note

Os controlos listados anteriormente são serviços gerais de segurança Azure. Verifique se o caminho de integração de cada controlo é suportado para a sua arquitetura específica de implementação do Azure MCP Server antes de o ativar em produção.

Conteúdo relacionado

  • Last updated on