Proteja um serviço Pesquisa de IA do Azure

Este artigo apresenta as melhores práticas de segurança para ajudar a proteger o seu Pesquisa de IA do Azure service. És responsável por implementar estes controlos de segurança configuráveis pelo cliente. Para informações sobre as proteções incorporadas da Microsoft, como arquitetura de rede, encriptação e certificações de conformidade, consulte Dados, privacidade e proteções incorporadas em Pesquisa de IA do Azure.

Como arquiteto de soluções, deve configurar os controlos de segurança em três domínios:

  • Segurança de rede: Controla o tráfego de entrada e saída para a sua search service.
  • Autenticação e autorização: Defina como, quem e o que pode aceder ao seu serviço de pesquisa e dados.
  • Proteção de dados: Implementar encriptação, controlos de access e monitorização.

As recomendações de segurança neste artigo implementam os princípios do Confiança Zero: "Verificar explicitamente", "Usar acesso com privilégios mínimos" e "Assumir violação". Para obter orientações abrangentes sobre Confiança Zero, consulte o Centro de Orientação Confiança Zero.

Compreender os padrões de tráfego de rede

Antes de configurar a segurança de rede, compreenda os três padrões de tráfego de rede no Pesquisa de IA do Azure:

  • Tráfego de entrada: Pedidos de clientes para o seu search service, como consultas, indexação e operações de gestão. Este tráfego é configurável pelos clientes.

  • Tráfego de saída: Pedidos do seu serviço de pesquisa para recursos externos, como indexadores que se ligam a fontes de dados, vetorizadores e skills personalizadas. Este tráfego é configurável pelos clientes.

  • Tráfego interno: Chamadas serviço a serviço na rede backbone da Microsoft. Este tráfego é gerido pela Microsoft e não é configurável pelos clientes. Para mais informações, consulte Proteção interna de trânsito.

Configurar a segurança de rede

Use uma das seguintes abordagens para restringir o acesso inbound ao seu serviço de pesquisa. Estas abordagens estão listadas de menos segura para mais segura:

Criar regras de firewall IP

Crie regras de firewall de entrada para admitir pedidos apenas de endereços IP ou intervalos de endereços específicos. Todas as ligações ao cliente devem ser feitas através de um endereço IP permitido. Caso contrário, a ligação é negada.

Diagrama de arquitetura de exemplo para acesso restrito a IP.

Quando usar: Cenários básicos de proteção onde precisa de restringir access a endereços IP conhecidos.

Como começar: Consulte Como configurar regras de acesso de rede e de firewall para o Pesquisa de IA do Azure.

Criar um ponto final privado

Crie um endpoint privado para o Pesquisa de IA do Azure para permitir que clientes numa virtual network acessem de forma segura a dados num índice de pesquisa através de um Private Link. O endpoint privado utiliza um endereço IP do espaço de endereçamento da sua rede virtual.

O tráfego de rede entre o cliente e o serviço de pesquisa atravessa a rede virtual e uma ligação privada na rede backbone da Microsoft, eliminando a exposição à internet pública.

Diagrama de arquitetura de exemplo para acesso ao endpoint privado.

Quando utilizar: Cenários de alta segurança que exigem isolamento total da rede da internet pública.

Como começar: Ver Criar um endpoint privado para Pesquisa de IA do Azure.

Junte-se a um perímetro de segurança de rede

Crie um perímetro de segurança de rede em torno dos recursos da sua plataforma como serviço (PaaS) implantados fora de uma virtual network para estabelecer um limite lógico de rede. Isto estabelece um perímetro que controla o acesso à rede pública através de regras explícitas de acesso.

As ligações de cliente de entrada e as ligações serviço-a-serviço ocorrem dentro do limite, simplificando as defesas contra acessos não autorizados. No Pesquisa de IA do Azure, é comum as soluções utilizarem múltiplos recursos do Azure.

Quando usar: Soluções que utilizam múltiplos recursos Azure PaaS que necessitam de proteção coordenada da fronteira da rede.

Como começar:

Configurar autenticação e autorização

O Pesquisa de IA do Azure suporta duas abordagens de autenticação. Podes usar uma abordagem e desativar a outra, ou podes usar ambas com controlos apropriados.

Use a autenticação Microsoft Entra para estabelecer o chamador, em vez do pedido, como a identidade autenticada. As atribuições de funções no Azure determinam a autorização, fornecendo gestão centralizada de identidades, políticas de acesso condicional e trilhos de auditoria abrangentes.

O fluxo de trabalho para controlo de acesso baseado em funções é:

  1. Ativar o controlo de acesso baseado em papéis: Configure o seu serviço de pesquisa para aceitar autenticação Microsoft Entra ID em vez de (ou além de) chaves de API. Veja Ativar ou desativar o controlo de acesso baseado em funções no Pesquisa de IA do Azure.

  2. Atribuir papéis a utilizadores e grupos: Conceder acesso com privilégios mínimos usando funções integradas (Search Service Contributor, Search Index Data Contributor e Search Index Data Reader) para controlar quem pode gerir e consultar índices. Vê Liga-te a Pesquisa de IA do Azure usando roles.

  3. Ligue a sua aplicação usando identidades: Autentifique sem chaves API usando DefaultAzureCredential, que suporta identidades geridas, credenciais de programador e outros fluxos baseados em tokens. Veja Ligue a sua aplicação a Pesquisa de IA do Azure usando identidades.

Configurar autenticação de chave de API

Com a autenticação baseada em chaves, cada pedido deve incluir uma chave de API de administrador ou consulta para provar que se origina de uma fonte confiável. Esta abordagem é adequada para ambientes de desenvolvimento, compatibilidade retroativa com aplicações existentes ou cenários em que o Microsoft Entra ID não está disponível.

O fluxo de trabalho para autenticação baseada em chaves é:

  1. Forneça uma chave API em cada pedido: As chaves de administrador concedem access total a todas as operações. As chaves de consulta concedem acesso apenas de leitura à coleção de documentos de um índice. Veja Conectar a Pesquisa de IA do Azure usando chaves.

  2. Rodar as chaves de administração num calendário: Reduza o risco de comprometimento de chaves regenerando regularmente as chaves de administrador. Os serviços de pesquisa suportam duas chaves de administrador para rotação sem interrupções. Veja Regenerar chaves de administração.

Autorizar operações do plano de controlo

As operações do plano de controlo (criação, configuração e eliminação de serviços) são autorizadas através de Azure Resource Manager access control baseada em funções, o mesmo modelo utilizado em todos os serviços Azure. As chaves da API não se aplicam às operações do plano de controlo. Três funções incorporadas no Azure regem o acesso.

Função Permissions
Proprietário Controlo total, incluindo gestão de acessos.
Contributor Controlo total, exceto pela gestão de acessos.
Leitor Acesso apenas para visualização

O fluxo de trabalho para autorizar operações no plano de controlo é:

  1. Atribuir funções administrativas: Utilize funções incorporadas do Azure (Proprietário, Colaborador e Leitor) para conceder acesso com privilégios mínimos e controlar quem pode criar, configurar ou eliminar serviços de busca. Consulte Atribuir funções para administração de serviços.

  2. Aplicar bloqueios de recursos: Prevenir a eliminação acidental dos serviços de pesquisa de produção aplicando bloqueios de CanNotDelete ou ReadOnly. Veja Bloqueie os seus recursos de Azure para proteger a sua infraestrutura.

Autorizar operações no plano de dados

As operações no plano de dados direcionam-se para conteúdos alojados num search service, como criação de índice, carregamento de documentos e consultas. A autorização está disponível através de controlo de acesso baseado em funções, chaves API ou ambos. Para os passos de configuração, consulte as secções anteriores sobre controlo de acesso baseado em funções e autenticação de chaves API.

Conceder acesso a índices individuais

Restringa o acesso dos utilizadores a índices individuais criando definições de função personalizadas. Esta abordagem é essencial para cenários multi-inquilino onde os dados de cada inquilino devem ser isolados ao nível do índice. Consulte Conceder acesso a um único índice.

Para soluções que requerem limites de segurança ao nível do índice, veja padrões de design para aplicações SaaS multitenant e Pesquisa de IA do Azure.

Observação

As chaves API fornecem apenas acesso ao nível de serviço. Qualquer pessoa com uma chave admin pode ler, modificar ou eliminar qualquer índice no search service. Para isolamento ao nível de índice, utilize access control baseado em funções ou implemente isolamento no nível intermédio da sua aplicação.

Configurar ligações de saída

Os pedidos de saída originam-se de um serviço de busca para outras aplicações, sendo normalmente feitos por indexadores, skills personalizadas e vetorizadores. Configure estas ligações para usar autenticação segura e acesso à rede.

Crie uma identidade gerida para o seu search service para autenticar com outros recursos do Azure sem armazenar credenciais no seu código. Uma identidade gerida elimina a necessidade de armazenar e rodar cadeias de ligação com credenciais.

O fluxo de trabalho para usar uma identidade gerida é:

  1. Configure uma identidade gerida para o search service: Escolha entre uma identidade gerida atribuída pelo sistema ou atribuída pelo utilizador. Veja Configure um serviço de pesquisa para se conectar usando uma identidade gerida.

  2. Liga-te a recursos externos usando a identidade gerida: As ligações suportadas incluem Armazenamento do Azure, Azure Cosmos DB, Base de Dados SQL do Azure, SQL Managed Instance e Funções do Azure.

Acesso seguro a dados externos

Configure ligações seguras com base em como os recursos externos são protegidos:

Sugestão

Se o Armazenamento do Azure e o Pesquisa de IA do Azure estiverem na mesma região, o tráfego de rede é automaticamente encaminhado através de um endereço IP privado através da rede backbone da Microsoft, eliminando a necessidade de configuração do firewall. Para mais informações, consulte Same-region Armazenamento do Azure e Pesquisa de IA do Azure.

Ligações seguras para processamento externo de IA

Os pedidos de saída para enriquecimento e vetorização por IA requerem consideração especial:

Funcionamento Configuração
Indexadores a conectar-se a fontes de dados Acesso seguro a dados externos.
Habilidades personalizadas que chamam código externo Ligações seguras a Funções do Azure, web apps ou outros hosts.
Vetorização durante a indexação Liga-te a modelos Azure OpenAI ou modelos de incorporação personalizados.
Azure Key Vault Ligue-se à Azure Key Vault para geridas pelo cliente.

Para padrões básicos de geração aumentada por recuperação (RAG), onde a sua aplicação cliente chama um modelo de conclusão de chat, a ligação utiliza a identidade do cliente ou utilizador, e não a identidade do serviço de pesquisa. Para recuperação autónoma usando bases de conhecimento, o pedido de saída é efetuado pela identidade gerida do serviço de pesquisa.

Implementar controlo de acesso ao nível do documento

O controlo de acesso ao nível do documento, também conhecido como segurança ao nível da linha, restringe que documentos um utilizador pode obter com base na sua identidade. Os metadados de permissão são capturados durante a indexação e aplicados no momento da consulta, o que é essencial para sistemas de IA agente, aplicações RAG e soluções de pesquisa empresarial que exigem verificações de autorização ao nível do documento. Para uma visão abrangente de todas as abordagens suportadas, consulte Controlo de acesso ao nível do documento.

Use ACL e RBAC do tipo POSIX (visualização prévia)

Para o conteúdo do Azure Data Lake Storage (ADLS) Gen2, configure indexadores ou fontes de conhecimento para preservar permissões ACL semelhantes a POSIX e escopos RBAC durante a ingestão. No momento da consulta, os resultados são filtrados com base no token Microsoft Entra do chamador. Para mais informações, consulte Metadados de permissão Index ADLS Gen2.

Usar SharePoint nas ACLs do Microsoft 365 (pré-visualização)

Configurar o indexador do SharePoint no Microsoft 365 para extrair permissões de documentos diretamente das ACLs do SharePoint durante a importação. No momento da consulta, os resultados são filtrados com base no token Microsoft Entra do chamador. Durante esta pré-visualização, as ACLs são capturadas apenas durante a indexação inicial, pelo que deve reindexar documentos afetados se as permissões de origem mudarem para evitar acesso obsoleto. Para mais informações, consulte Indexar metadados de permissões do SharePoint.

Usar etiquetas de sensibilidade (pré-visualização)

Configure um indexador para detetar automaticamente etiquetas de sensibilidade do Microsoft Purview durante a indexação e aplique controlos de acesso baseados em etiquetas quando as consultas são executadas. Esta funcionalidade alinha a autorização Pesquisa de IA do Azure com o modelo Microsoft Information Protection da sua empresa. Para mais informações, veja Índice de etiquetas de sensibilidade do Microsoft Purview.

Usar filtros de segurança

Para cenários em que a integração nativa com ACL não é viável, implemente filtros de segurança para cortar resultados com base nas identidades dos utilizadores ou grupos. Armazena a informação de identidade num campo de string no teu índice e depois passa a identidade do chamador como uma string de filtro no momento da consulta para excluir documentos que não coincidam. Esta abordagem funciona com modelos de acesso personalizados ou frameworks de segurança não Microsoft. Para obter mais informações, consulte filtros de segurança para filtragem de resultados.

Configurar criptografia de dados

O Pesquisa de IA do Azure encripta automaticamente todos os dados usando chaves geridas pela Microsoft. Para informações sobre encriptação incorporada, veja Encriptação de dados.

Para uma proteção de dados reforçada, pode implementar os seguintes controlos de encriptação.

(Opcional) Adicionar encriptação de chaves gerida pelo cliente

Adicione uma camada extra de encriptação para índices e mapas de sinónimos, gerindo as suas próprias chaves de encriptação no Azure Key Vault. As chaves geridas pelo cliente (CMK) destinam-se a organizações com requisitos de conformidade que exigem o controlo do cliente sobre chaves de encriptação ou capacidades de revogação de chaves. Veja Configure chaves geridas pelo cliente para encriptação de dados em Pesquisa de IA do Azure.

Também pode configurar as seguintes opções:

Importante

  • A encriptação CMK aumenta o tamanho do índice e pode degradar o desempenho da consulta entre 30 a 60%. Ativar apenas para índices que o exigem.
  • O CMK em discos temporários requer serviços criados após 13 de maio de 2021. Os serviços anteriores suportam CMK apenas em discos de dados.

Indexar conteúdo de blob encriptado

Configure um indexador para processar conteúdo do Armazenamento de Blobs do Azure que esteja encriptado em repouso, o que é separado da encriptação CMK do índice de pesquisa. Veja Tutorial: Indexar e enriquecer blobs encriptados.

(Opcional) Permitir computação confidencial

Computação confidencial protege os dados em utilização contra acessos não autorizados, incluindo por parte da Microsoft, através de atestação de hardware e cifra. Este tipo de computação só é configurável durante a criação do serviço. Veja Escolher um tipo de computação.

Recomendamos apenas computação confidencial para organizações cuja conformidade ou requisitos regulatórios exijam proteção de dados em uso. Para uso diário, o tipo de computação padrão é suficiente.

Tipo de computação Description Limitações Custo Disponibilidade
Predefinido VMs padrão com encriptação incorporada para dados em repouso e em trânsito. Nenhum isolamento baseado em hardware para dados em uso. Sem limitações. Nenhuma alteração no custo base de níveis gratuitos ou pagos. Disponível em todas as regiões.
Confidential VMs confidenciais (DCasv5 ou DCesv5) em ambiente de execução confiável baseado em hardware. Isola cálculos e memória do sistema operacional host e de outras VMs. Desabilita ou restringe a recuperação agêntica, o ranqueador semântico, a reescrita de consulta, a execução de competências e os indexadores executados no ambiente multi-arrendatário1. Adiciona 10% de sobretaxa ao custo base dos escalões faturáveis. Para mais informações, consulte a página preços. Disponível em algumas regiões. Para obter mais informações, consulte a lista de regiões suportadas.

1 Quando você habilita esse tipo de computação, os indexadores só podem ser executados no ambiente de execução privada, o que significa que eles são executados a partir dos clusters de pesquisa hospedados em computação confidencial.

Permitir monitorização e registo

Acompanhe operações, detete anomalias e apoie auditorias de segurança ativando o registo e monitorização do seu search service. Para informações sobre o que Pesquisa de IA do Azure regista por padrão, veja Registo de dados.

Manter a conformidade

Para informações sobre certificações de conformidade Pesquisa de IA do Azure e o modelo de responsabilidade partilhada, consulte Conformidade e certificações.

Utilize a Política Azure

Aplicar tags de recursos

Aplique etiquetas de recurso para categorizar os serviços de pesquisa por ambiente, sensibilidade de dados, centro de custos ou requisitos de conformidade para melhorar a governação. Veja Use etiquetas para organizar os seus recursos do Azure e a hierarquia de gestão de recursos.

Lista de verificação de segurança

Use esta lista de verificação para garantir que configurou os controlos de segurança adequados:

Segurança de rede:

  • [ ] Regras de firewall IP configuradas, endpoint privado ou perímetro de segurança de rede
  • [ ] Acesso de entrada restrito a clientes ou redes conhecidas
  • [ ] Configurações de ligações seguras de saída usando identidades geridas

Autenticação e autorização:

  • [ ] Ativado o controlo de acesso baseado em funções
  • [ ] Atribuíram papéis apropriados aos utilizadores e aplicações
  • [ ] Implementou o cronograma de rotação de chaves de administração (se estiver a usar chaves)
  • [ ] Permissões ao nível do índice configuradas (se necessário)

Proteção de dados:

  • [ ] Controlo de acesso ao nível do documento configurado (se necessário):
    • [ ] ACLs semelhantes a POSIX para conteúdo ADLS Gen2
    • [ ] SharePoint em Microsoft 365 ACLs
    • [ ] Etiquetas de sensibilidade Microsoft Purview
    • [ ] Filtros de segurança para cenários personalizados
  • [ ] Encriptação CMK implementada (se necessário)
  • [ ] Avaliou os requisitos confidenciais de computação (se aplicável)

Monitorização e conformidade:

  • [ ] Ativação do registo de diagnóstico
  • [ ] Configurar monitorização e alertas para identificar atividade anómala
  • [ ] Etiquetas de recursos aplicadas para governação
  • [ ] Atribuí Azure Policy para registo de recursos
  • [ ] Revisou certificações de conformidade com os requisitos

Conteúdo relacionado

  • Last updated on