Partilhar via

Proteção das Funções Azure

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 do Azure, incluindo máquinas virtuais (VMs) do Azure, armazenamento, conexões de rede, plataformas web e funcionalidades de gestão e integração, são ativamente protegidos e fortalecidos. O Serviço de Aplicativo passa por verificações de conformidade vigorosas continuamente para garantir que:

  • Os recursos da sua aplicação estão protegidos contra os 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 Banco de Dados SQL do Azure) 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 o Azure PowerShell, a CLI do Azure, os SDKs do Azure e as 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), ataques man-in-the-middle e outras ameaças.

Para obter mais informações sobre segurança de infraestrutura e plataforma no Azure, consulte a 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 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 obter mais informações, consulte Defender for App Service.

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 obter mais informações, consulte Monitorizar 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 um destino à sua escolha, como um espaço de trabalho do Logs Analytics. Para obter mais informações, consulte Monitorizar as Funções do Azure com os Registos do Azure Monitor.

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 obter mais informações, 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 acesso HTTP seguros

Os pontos de extremidade HTTP expostos publicamente fornecem um vetor de ataque para agentes maliciosos. 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 endpoints de função usando HTTP ou HTTPS. Você deve redirecionar HTTP para HTTPS porque HTTPS usa o protocolo 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 de TLS.

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

Teclas de acesso à função

As funções permitem-lhe utilizar chaves para dificultar o acesso aos endpoints das suas funções. 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 os seus endpoints de função é com a implementação da autenticação robusta dos clientes que acedem às 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 endpoints administrativos

As aplicações de funções podem servir pontos finais administrativos na rota /admin que podem ser usados para operações como obter informações de status do host e executar invocações de teste. Quando expostos, as solicitações contra estes pontos de extremidade devem incluir a chave mestra da aplicação. 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 desativar os /admin endpoints definindo a functionsRuntimeAdminIsolationEnabled propriedade do 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 que não sejam da Microsoft 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 obter mais informações, 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 obter mais informações, 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 obter mais informações, 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 suporta o controlo de acesso baseado em função (Azure RBAC) do Azure. 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 o papel de Proprietário pode excluir uma aplicação de funções.

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 plataforma Azure gere a identidade, portanto, não precisa de provisionar ou rodar quaisquer segredos. Para obter mais informações sobre identidades gerenciadas no Microsoft Entra ID, consulte Identidades gerenciadas para recursos do Azure.

Você pode conceder dois tipos de identidades ao seu aplicativo:

  • Uma identidade atribuída ao sistema é vinculada ao aplicativo e é excluída se o aplicativo for excluído. Um aplicativo pode ter apenas uma identidade atribuída ao 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. 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 geridas podem ser usadas para substituir segredos nas ligações de alguns gatilhos e associações. Consulte Conexões baseadas na identidade.

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

Restringir o acesso ao CORS

A partilha de recursos entre origens (CORS) é uma maneira de permitir que aplicações web executadas noutro 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.

É tentador usar um curinga que permita que todos os sites acessem seu endpoint. Essa abordagem 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 aplicação web que deve aceder ao 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. Essa abordagem 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 Azure Key Vault no lugar de uma cadeia de conexão ou chave nas configurações da aplicação. Para obter mais informações, consulte Referências do Azure Key Vault para App Service e Azure Functions.

Conexões baseadas em identidade

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

Quando escreve código que cria a ligação aos serviços do Azure que suportam a autenticação do Microsoft Entra, pode 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. Essa abordagem pode potencialmente 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 extra. 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 nas funções. Erros não tratados borbulham até o host e o tempo de execução lida com esses erros. Diferentes ligações lidam com o processamento de erros de forma diferente. Para obter mais informações, 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 depurando ativamente suas funções. Você pode desativar a depuração remota na aba 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 caracteres universais na lista das suas 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 mais controlo sobre chaves de criptografia, pode-se fornecer chaves geridas pelo cliente a utilizar na criptografia de dados blob e de ficheiros. Essas chaves devem estar presentes no Azure Key Vault for Functions para poder acessar a conta de armazenamento. Para saber mais, consulte Criptografar os dados do aplicativo em repouso usando chaves gerenciadas pelo cliente.

Um aplicativo de função frequentemente depende de outros recursos, portanto, parte da proteção do aplicativo é proteger esses recursos externos. No mínimo, a maioria das aplicações de funções inclui uma dependência do Application Insights e do Azure Storage. 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. A plataforma do Serviço de Aplicativo gerencia as credenciais de implantação. As credenciais 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. Essas credenciais podem ser usadas para implantar no App Service para qualquer aplicação em qualquer subscrição que a conta do Azure tenha permissão para aceder. Esse conjunto de credenciais é o padrão que aparece no ambiente gráfico do portal, como em Visão geral e Propriedades no painel de recursos do aplicativo. Quando um usuário recebe acesso ao aplicativo por meio de permissões de controle de acesso baseado em função (RBAC) ou coadministrador, ele pode usar suas 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. Essas credenciais podem ser usadas somente para implantar 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 conceder a um usuário acesso a credenciais no nível do aplicativo por meio do RBAC, esse usuário deve ter permissões de nível de Colaborador 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.

De momento, o Azure Key Vault 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 aplicação de funções tem um ponto de extremidade FTP ativado. O endpoint 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 obter mais informações, 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 função de aplicação tem um ponto de extremidade de serviço correspondente scm que é utilizado pelo serviço Ferramentas Avançadas (Kudu) para implementações e outras extensões de site no Serviço de Aplicações. O scm ponto de extremidade para uma aplicação de funções é sempre uma URL no formato https://<FUNCTION_APP_NAME>.scm.azurewebsites.net. Ao usar o isolamento de rede para proteger as tuas funções, deves também ter em consideração este endpoint.

Ao ter um ponto de extremidade separado scm, pode gerir implantações e outras funcionalidades das Ferramentas Avançadas para aplicações funcionais isoladas ou em execução numa 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 obter mais informações, 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. Essa abordagem às vezes é chamada 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 Proteger seus pipelines do Azure.

Segurança da rede

Restringir o acesso à rede à sua aplicação de função permite controlar quem pode aceder aos seus endpoints de funções. O Functions usa 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 obter mais informações, consulte Restrições de acesso do Serviço de Aplicativo do Azure.

Proteger a conta de armazenamento

Ao criar uma aplicação de funções, deve-se criar ou associar uma conta de Armazenamento do Azure de propósito geral que ofereça suporte ao armazenamento de Blobs, Filas e Tabelas. Você pode substituir esta conta de armazenamento por uma que seja protegida por uma rede virtual com acesso ativado por endpoints de serviço ou endpoints 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 Utilização de pontos de extremidade privados para aplicações 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 Integrar seu ambiente do Serviço de Aplicativo ILB com o Gateway de Aplicativo do Azure.

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, a sua aplicação de função precisa estar em execução num ASE ou usar pontos de extremidade privados (pré-visualização). Para obter mais informações, consulte Utilizar pontos finais privados.

Próximos passos