Partilhar via

Protegendo o Azure Functions

  • Artigo

De muitas maneiras, o planejamento para desenvolvimento, implantação e operação seguros de funções sem servidor é praticamente o mesmo que para qualquer aplicativo baseado na Web ou hospedado na nuvem. O Serviço de Aplicativo do Azure fornece a infraestrutura de hospedagem para seus aplicativos funcionais. Este artigo fornece estratégias de segurança para executar seu código de função e como o Serviço de Aplicativo pode ajudá-lo a proteger suas funções.

Os componentes da plataforma do Serviço de Aplicações, incluindo VMs do Azure, armazenamento, ligações de rede, arquiteturas Web, funcionalidades de gestão e integração, são protegidos ativamente. O Serviço de Aplicativo passa por verificações de conformidade vigorosas continuamente para garantir que:

  • Os recursos do seu aplicativo são protegidos dos recursos do Azure de outros clientes.
  • As instâncias de VM e o software de tempo de execução são atualizados regularmente para resolver vulnerabilidades recém-descobertas.
  • A comunicação de segredos (como cadeias de conexão) entre seu aplicativo e outros recursos do Azure (como o Banco de Dados SQL) permanece no Azure e não cruza nenhum limite de rede. Os segredos são sempre encriptados quando armazenados.
  • Toda a comunicação através dos recursos de conectividade do Serviço de Aplicativo, como conexão híbrida, é criptografada.
  • As conexões com ferramentas de gerenciamento remoto, como Azure PowerShell, CLI do Azure, SDKs do Azure, APIs REST, são todas criptografadas.
  • O gerenciamento de ameaças 24 horas protege a infraestrutura e a plataforma contra malware, negação de serviço distribuída (DDoS), man-in-the-middle (MITM) e outras ameaças.

Para obter mais informações sobre segurança de infraestrutura e plataforma no Azure, consulte Central de Confiabilidade do Azure.

Para obter um conjunto de recomendações de segurança que seguem o benchmark de segurança na nuvem da Microsoft, consulte Linha de base de segurança do Azure para Azure Functions.

Operação segura

Esta seção orienta você a configurar e executar seu aplicativo de função da forma mais segura possível.

Defender para a Cloud

O Defender for Cloud integra-se com a sua aplicação funcional no portal. Ele fornece, gratuitamente, uma avaliação rápida de possíveis vulnerabilidades de segurança relacionadas à configuração. Os aplicativos funcionais executados em um plano dedicado também podem usar os recursos de segurança aprimorados do Defender for Cloud por um custo extra. Para saber mais, consulte Proteger seus aplicativos Web e APIs do Serviço de Aplicativo do Azure.

Registar e monitorizar

Uma maneira de detetar ataques é por meio do monitoramento de atividades e análise de registro. O Functions integra-se com o Application Insights para coletar dados de log, desempenho e erros para seu aplicativo de função. O Application Insights deteta automaticamente anomalias de desempenho e inclui poderosas ferramentas de análise para ajudá-lo a diagnosticar problemas e entender como suas funções são usadas. Para saber mais, consulte Monitorar o Azure Functions.

O Functions também se integra aos Logs do Azure Monitor para permitir que você consolide logs de aplicativos funcionais com eventos do sistema para facilitar a análise. Você pode usar as configurações de diagnóstico para configurar a exportação de streaming de logs e métricas da plataforma para suas funções para o destino de sua escolha, como um espaço de trabalho do Logs Analytics. Para saber mais, consulte Monitorando o Azure Functions com o Azure Monitor Logs.

Para automação de deteção e resposta a ameaças em nível empresarial, transmita seus logs e eventos para um espaço de trabalho do Logs Analytics. Em seguida, você pode conectar o Microsoft Sentinel a esse espaço de trabalho. Para saber mais, consulte O que é o Microsoft Sentinel.

Para obter mais recomendações de segurança para observabilidade, consulte a linha de base de segurança do Azure para o Azure Functions.

Pontos de extremidade HTTP seguros

Os pontos de extremidade HTTP expostos publicamente fornecem um vetor de ataque para atores mal-intencionados. Ao proteger seus pontos de extremidade HTTP, você deve usar uma abordagem de segurança em camadas. Essas técnicas podem ser usadas para reduzir a vulnerabilidade de pontos de extremidade HTTP expostos publicamente, ordenados do mais básico para o mais seguro e restritivo:

Exigir HTTPS

Por padrão, os clientes podem se conectar a pontos de extremidade de função usando HTTP ou HTTPS. Você deve redirecionar HTTP para HTTPS porque HTTPS usa o protocolo SSL/TLS para fornecer uma conexão segura, que é criptografada e autenticada. Para saber como, consulte Impor HTTPS.

Quando você precisar de HTTPS, você também deve exigir a versão mais recente do TLS. Para saber como, consulte Impor versões TLS.

Para obter mais informações, consulte Conexões seguras (TLS).

Teclas de acesso à função

As funções permitem-lhe utilizar teclas para dificultar o acesso aos seus pontos finais de função. A menos que o nível de acesso HTTP em uma função acionada por HTTP esteja definido como anonymous, as solicitações devem incluir uma chave de acesso na solicitação. Para obter mais informações, consulte Trabalhar com chaves de acesso no Azure Functions.

Embora as chaves de acesso possam fornecer alguma atenuação para acessos indesejados, a única maneira de proteger verdadeiramente seus pontos de extremidade de função é implementando a autenticação positiva de clientes que acessam suas funções. Em seguida, você pode tomar decisões de autorização com base na identidade.

Para obter o mais alto nível de segurança, você também pode proteger toda a arquitetura do aplicativo dentro de uma rede virtual usando pontos de extremidade privados ou executando isoladamente.

Desativar pontos de extremidade administrativos

Os aplicativos de função podem servir pontos de extremidade administrativos sob a /admin rota que podem ser usados para operações como a obtenção de informações de status do host e a execução de invocações de teste. Quando expostas, as solicitações contra esses pontos de extremidade devem incluir a chave mestra do aplicativo. As operações administrativas também estão disponíveis por meio da API do Azure Resource ManagerMicrosoft.Web/sites, que oferece o Azure RBAC. Você pode desabilitar os /admin pontos de extremidade definindo a functionsRuntimeAdminIsolationEnabled propriedade site como true. Essa propriedade não pode ser definida para aplicativos executados na SKU de Consumo do Linux e não pode ser definida para aplicativos executados na versão 1.x do Azure Functions. Se você estiver usando a versão 1.x, você deve primeiro migrar para a versão 4.x.

Habilitar autenticação/autorização do Serviço de Aplicativo

A plataforma do Serviço de Aplicativo permite que você use o Microsoft Entra ID e vários provedores de identidade de terceiros para autenticar clientes. Você pode usar essa estratégia para implementar regras de autorização personalizadas para suas funções e pode trabalhar com informações do usuário do seu código de função. Para saber mais, consulte Autenticação e autorização no Serviço de Aplicativo do Azure e Trabalhando com identidades de cliente.

Usar o Gerenciamento de API do Azure (APIM) para autenticar solicitações

O APIM fornece várias opções de segurança de API para solicitações de entrada. Para saber mais, consulte Políticas de autenticação de gerenciamento de API. Com o APIM em vigor, você pode configurar seu aplicativo de função para aceitar solicitações somente do endereço IP da sua instância do APIM. Para saber mais, consulte Restrições de endereço IP.

Permissões

Como em qualquer aplicativo ou serviço, o objetivo é executar seu aplicativo de função com as menores permissões possíveis.

Permissões de gerenciamento de usuários

O Functions dá suporte ao controle de acesso baseado em função interno do Azure (Azure RBAC). As funções do Azure suportadas pelo Functions são Colaborador, Proprietário e Leitor.

As permissões são efetivas no nível do aplicativo de função. A função de Colaborador é necessária para executar a maioria das tarefas funcionais no nível do aplicativo. Você também precisa da função de Colaborador junto com a permissão de Leitor de Monitoramento para poder exibir dados de log no Application Insights. Somente a função Proprietário pode excluir um aplicativo de função.

Organizar funções por privilégio

As cadeias de conexão e outras credenciais armazenadas nas configurações do aplicativo dão a todas as funções no aplicativo de função o mesmo conjunto de permissões no recurso associado. Considere minimizar o número de funções com acesso a credenciais específicas movendo funções que não usam essas credenciais para um aplicativo de função separado. Você sempre pode usar técnicas como encadeamento de funções para passar dados entre funções em diferentes aplicativos de função.

Identidades geridas

Uma identidade gerenciada do Microsoft Entra ID permite que seu aplicativo acesse facilmente outros recursos protegidos pelo Microsoft Entra, como o Azure Key Vault. A identidade é gerida pela plataforma do Azure e não precisa de aprovisionar nem rodar segredos. Para obter mais informações sobre identidades gerenciadas no Microsoft Entra ID, consulte Identidades gerenciadas para recursos do Azure.

Pode conceder dois tipos de identidades à aplicação:

  • Uma identidade atribuída ao sistema é vinculada ao aplicativo e é excluída se o aplicativo for excluído. Uma aplicação só pode ter uma identidade atribuída pelo sistema.
  • Uma identidade atribuída pelo utilizador é um recurso autónomo do Azure que pode ser atribuído à aplicação. Um aplicativo pode ter várias identidades atribuídas pelo usuário e uma identidade atribuída pelo usuário pode ser atribuída a vários recursos do Azure, como dois aplicativos do Serviço de Aplicativo.

As identidades gerenciadas podem ser usadas no lugar de segredos para conexões de alguns gatilhos e associações. Consulte Conexões baseadas em identidade.

Para obter mais informações, consulte Como usar identidades gerenciadas para o Serviço de Aplicativo e o Azure Functions.

Restringir o acesso ao CORS

O compartilhamento de recursos entre origens (CORS) é uma maneira de permitir que aplicativos Web executados em outro domínio façam solicitações aos seus pontos de extremidade de gatilho HTTP. O Serviço de Aplicativo fornece suporte interno para entregar os cabeçalhos CORS necessários em solicitações HTTP. As regras do CORS são definidas em um nível de aplicativo de função.

Embora seja tentador usar um curinga que permite que todos os sites acessem seu endpoint, isso derrota o objetivo do CORS, que é ajudar a evitar ataques de script entre sites. Em vez disso, adicione uma entrada CORS separada para o domínio de cada aplicativo Web que deve acessar seu ponto de extremidade.

Gestão de segredos

Para poder se conectar aos vários serviços e recursos necessários para executar seu código, os aplicativos de função precisam ser capazes de acessar segredos, como cadeias de conexão e chaves de serviço. Esta seção descreve como armazenar segredos exigidos por suas funções.

Nunca armazene segredos no seu código de função.

Definições da aplicação

Por padrão, você armazena cadeias de conexão e segredos usados pelo seu aplicativo de função e associações como configurações do aplicativo. Isso torna essas credenciais disponíveis para o código da função e as várias associações usadas pela função. O nome da configuração do aplicativo (chave) é usado para recuperar o valor real, que é o segredo.

Por exemplo, cada aplicativo de função requer uma conta de armazenamento associada, que é usada pelo tempo de execução. Por padrão, a conexão com essa conta de armazenamento é armazenada em uma configuração de aplicativo chamada AzureWebJobsStorage.

As configurações do aplicativo e as cadeias de conexão são armazenadas criptografadas no Azure. Eles são descriptografados somente antes de serem injetados na memória de processo do seu aplicativo quando o aplicativo é iniciado. As chaves de encriptação são alternadas regularmente. Se preferir gerir o armazenamento seguro dos seus segredos, as definições da aplicação devem, em vez disso, ser referências aos segredos do Cofre da Chave do Azure.

Você também pode criptografar as configurações por padrão no local.settings.json arquivo ao desenvolver funções no computador local. Para obter mais informações, consulte Criptografar o arquivo de configurações locais.

Referências do Key Vault

Embora as configurações do aplicativo sejam suficientes para a maioria das funções, talvez você queira compartilhar os mesmos segredos em vários serviços. Nesse caso, o armazenamento redundante de segredos resulta em mais vulnerabilidades potenciais. Uma abordagem mais segura consiste em utilizar um serviço central de armazenamento secreto e utilizar referências a este serviço em vez dos próprios segredos.

O Azure Key Vault é um serviço que fornece gerenciamento centralizado de segredos, com controle total sobre políticas de acesso e histórico de auditoria. Você pode usar uma referência do Cofre da Chave no lugar de uma cadeia de conexão ou chave nas configurações do aplicativo. Para saber mais, consulte Usar referências do Cofre da Chave para o Serviço de Aplicativo e o Azure Functions.

Conexões baseadas em identidade

As identidades podem ser usadas no lugar de segredos para se conectar a alguns recursos. Isso tem a vantagem de não exigir o gerenciamento de um segredo e fornece controle de acesso e auditoria mais refinados.

Quando estiver a escrever código que cria a ligação aos serviços do Azure que suportam a autenticação do Microsoft Entra, pode optar por utilizar uma identidade em vez de um segredo ou cadeia de ligação. Os detalhes de ambos os métodos de conexão são abordados na documentação de cada serviço.

Algumas extensões de vinculação do Azure Functions podem ser configuradas para acessar serviços usando conexões baseadas em identidade. Para obter mais informações, consulte Configurar uma conexão baseada em identidade.

Definir quotas de utilização

Considere definir uma cota de uso para funções em execução em um plano de consumo. Quando você define um limite diário de GB-seg na execução total de funções em seu aplicativo de função, a execução é interrompida quando o limite é atingido. Isso pode ajudar a mitigar contra códigos mal-intencionados que executam suas funções. Para saber como estimar o consumo para suas funções, consulte Estimando os custos do plano de consumo.

Validação de dados

Os gatilhos e ligações usados por suas funções não fornecem nenhuma validação de dados adicional. Seu código deve validar todos os dados recebidos de um gatilho ou associação de entrada. Se um serviço upstream for comprometido, você não quer entradas não validadas fluindo através de suas funções. Por exemplo, se sua função armazena dados de uma fila de Armazenamento do Azure em um banco de dados relacional, você deve validar os dados e parametrizar seus comandos para evitar ataques de injeção de SQL.

Não assuma que os dados que entram na sua função já foram validados ou higienizados. Também é uma boa ideia verificar se os dados que estão sendo gravados nas ligações de saída são válidos.

Processar erros

Embora pareça básico, é importante escrever um bom tratamento de erros em suas funções. Os erros não tratados borbulham até o host e são manipulados pelo tempo de execução. Diferentes ligações lidam com o processamento de erros de forma diferente. Para saber mais, consulte Tratamento de erros do Azure Functions.

Desativar depuração remota

Certifique-se de que a depuração remota está desativada, exceto quando você estiver ativamente depurando suas funções. Você pode desativar a depuração remota na guia Configurações gerais da configuração do seu aplicativo de função no portal.

Restringir o acesso ao CORS

O Azure Functions dá suporte ao compartilhamento de recursos entre origens (CORS). O CORS é configurado no portal e por meio da CLI do Azure. A lista de origens permitidas do CORS aplica-se ao nível da função app. Com o CORS ativado, as respostas incluem o Access-Control-Allow-Origin cabeçalho. Para obter mais informações, consulte Partilha de recursos de várias origens.

Não use curingas na sua lista de origens permitidas. Em vez disso, liste os domínios específicos dos quais você espera obter solicitações.

Armazenar dados criptografados

O Armazenamento do Azure criptografa todos os dados em uma conta de armazenamento em repouso. Para obter mais informações, consulte Encriptação do Armazenamento do Microsoft Azure para dados inativos.

Por padrão, os dados são criptografados com chaves gerenciadas pela Microsoft. Para obter controle adicional sobre chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para usar para criptografia de dados de blob e arquivo. Essas chaves devem estar presentes no Azure Key Vault for Functions para poder acessar a conta de armazenamento. Para saber mais, consulte Criptografia em repouso usando chaves gerenciadas pelo cliente.

Um aplicativo de função frequentemente depende de recursos adicionais, portanto, parte da proteção do aplicativo é proteger esses recursos externos. No mínimo, a maioria dos aplicativos de função inclui uma dependência do Application Insights e do Armazenamento do Azure. Consulte a linha de base de segurança do Azure para o Azure Monitor e a linha de base de segurança do Azure para Armazenamento para obter orientação sobre como proteger esses recursos.

Importante

A conta de armazenamento é usada para armazenar dados importantes do aplicativo, às vezes incluindo o próprio código do aplicativo. Você deve limitar o acesso de outros aplicativos e usuários à conta de armazenamento.

Você também deve consultar as diretrizes para quaisquer tipos de recursos dos quais sua lógica de aplicativo depende, tanto como gatilhos e associações quanto a partir do seu código de função.

Implementação segura

A integração de ferramentas do Azure Functions facilita a publicação do código do projeto de função local no Azure. É importante entender como a implantação funciona ao considerar a segurança para uma topologia do Azure Functions.

Credenciais de implementação

As implantações do Serviço de Aplicativo exigem um conjunto de credenciais de implantação. Essas credenciais de implantação são usadas para proteger suas implantações de aplicativo de função. As credenciais de implantação são gerenciadas pela plataforma do Serviço de Aplicativo e são criptografadas em repouso.

Há dois tipos de credenciais de implantação:

  • Credenciais de nível de usuário: um conjunto de credenciais para toda a conta do Azure. Ele pode ser usado para implantar no Serviço de Aplicativo para qualquer aplicativo, em qualquer assinatura, que a conta do Azure tenha permissão para acessar. É o conjunto padrão que aparece na GUI do portal (como Visão geral e Propriedades da página de recursos do aplicativo). Quando um usuário recebe acesso ao aplicativo por meio de permissões RBAC (Controle de Acesso Baseado em Função) ou coadministrador, esse usuário pode usar suas próprias credenciais de nível de usuário até que o acesso seja revogado. Não compartilhe essas credenciais com outros usuários do Azure.

  • Credenciais no nível do aplicativo: um conjunto de credenciais para cada aplicativo. Ele pode ser usado para implantar somente nesse aplicativo. As credenciais de cada aplicativo são geradas automaticamente na criação do aplicativo. Eles não podem ser configurados manualmente, mas podem ser redefinidos a qualquer momento. Para que um usuário tenha acesso às credenciais no nível do aplicativo via (RBAC), esse usuário deve ser contribuidor ou superior no aplicativo (incluindo a função interna de Colaborador do Site). Os leitores não têm permissão para publicar e não podem acessar essas credenciais.

No momento, o Cofre da Chave não é suportado para credenciais de implantação. Para saber mais sobre como gerenciar credenciais de implantação, consulte Configurar credenciais de implantação para o Serviço de Aplicativo do Azure.

Desativar FTP

Por padrão, cada aplicativo de função tem um ponto de extremidade FTP habilitado. O ponto de extremidade FTP é acessado usando credenciais de implantação.

FTP não é recomendado para implantar seu código de função. As implantações de FTP são manuais e exigem que você sincronize gatilhos. Para saber mais, consulte Implantação de FTP.

Quando você não está planejando usar o FTP, você deve desativá-lo no portal. Se você optar por usar o FTP, você deve impor o FTPS.

Proteger o scm ponto de extremidade

Cada aplicativo de função tem um ponto de extremidade de serviço correspondente scm que é usado pelo serviço de Ferramentas Avançadas (Kudu) para implantações e outras extensões de site do Serviço de Aplicativo. O scm ponto de extremidade para um aplicativo de função é sempre uma URL no formato https://<FUNCTION_APP_NAME>.scm.azurewebsites.net. Ao usar o isolamento de rede para proteger suas funções, você também deve levar em conta esse ponto de extremidade.

Ao ter um ponto de extremidade separado scm , você pode controlar implantações e outras funcionalidades de Ferramentas Avançadas para aplicativos de função isolados ou em execução em uma rede virtual. O scm ponto de extremidade dá suporte à autenticação básica (usando credenciais de implantação) e ao logon único com suas credenciais do portal do Azure. Para saber mais, consulte Acessando o serviço Kudu.

Validação de segurança contínua

Como a segurança precisa ser considerada em cada etapa do processo de desenvolvimento, faz sentido também implementar validações de segurança em um ambiente de implantação contínua. Isso às vezes é chamado de DevSecOps. Usar o Azure DevOps para seu pipeline de implantação permite integrar a validação ao processo de implantação. Para obter mais informações, consulte Saiba como adicionar validação de segurança contínua ao seu pipeline de CI/CD.

Segurança da rede

Restringir o acesso à rede ao seu aplicativo de função permite controlar quem pode acessar seus pontos de extremidade de funções. O Functions aproveita a infraestrutura do Serviço de Aplicativo para permitir que suas funções acessem recursos sem usar endereços roteáveis pela Internet ou para restringir o acesso à Internet a um ponto de extremidade de função. Para saber mais sobre essas opções de rede, consulte Opções de rede do Azure Functions.

Definir restrições de acesso

As restrições de acesso permitem-lhe definir listas de regras de permissão/negação para controlar o tráfego para a sua aplicação. As regras são avaliadas por ordem de prioridade. Se nenhuma regra for definida, seu aplicativo aceitará tráfego de qualquer endereço. Para saber mais, consulte Restrições de acesso ao Serviço de Aplicativo do Azure.

Proteger a conta de armazenamento

Ao criar um aplicativo funcional, você deve criar ou vincular a uma conta de Armazenamento do Azure de uso geral que ofereça suporte ao armazenamento de Blob, Fila e Tabela. Você pode substituir essa conta de armazenamento por uma protegida por uma rede virtual com acesso habilitado por pontos de extremidade de serviço ou pontos de extremidade privados. Para obter mais informações, veja Restringir a conta de armazenamento a uma rede virtual.

Implantar seu aplicativo de função em uma rede virtual

O Ponto Final Privado do Azure é uma interface de rede que o liga em privado e com segurança a um serviço com a tecnologia do Azure Private Link. O Ponto Final Privado utiliza um endereço IP privado a partir da rede virtual, o que leva de forma eficaz o serviço até à sua rede virtual.

Você pode usar o Private Endpoint para suas funções hospedadas nos planos Flex Consumption, Elastic Premium e Dedicated (App Service).

Se você quiser fazer chamadas para pontos de extremidade privados, então você deve certificar-se de que suas pesquisas de DNS resolvem para o ponto de extremidade privado. Você pode impor esse comportamento de uma das seguintes maneiras:

  • Integre com zonas privadas de DNS do Azure. Quando sua rede virtual não tem um servidor DNS personalizado, isso é feito automaticamente.
  • Gerencie o ponto de extremidade privado no servidor DNS usado pelo seu aplicativo. Para gerenciar um ponto de extremidade privado, você deve saber o endereço do ponto de extremidade e usar um registro A para fazer referência ao ponto de extremidade que está tentando alcançar.
  • Configure seu próprio servidor DNS para encaminhar para zonas privadas do DNS do Azure.

Para saber mais, consulte Usando pontos de extremidade privados para aplicativos Web.

Implante seu aplicativo de função de forma isolada

O Ambiente do Serviço de Aplicativo do Azure fornece um ambiente de hospedagem dedicado no qual executar suas funções. Esses ambientes permitem configurar um único gateway front-end que você pode usar para autenticar todas as solicitações de entrada. Para obter mais informações, consulte Configurando um firewall de aplicativo Web (WAF) para ambiente do Serviço de Aplicativo.

Usar um serviço de gateway

Os serviços de gateway, como o Azure Application Gateway e o Azure Front Door , permitem configurar um WAF (Web Application Firewall). As regras WAF são usadas para monitorar ou bloquear ataques detetados, que fornecem uma camada extra de proteção para suas funções. Para configurar um WAF, seu aplicativo de função precisa estar em execução em um ASE ou usando pontos de extremidade privados (visualização). Para saber mais, consulte Usando pontos de extremidade privados.

Próximos passos