Proteger o Azure Functions
De muitas maneiras, planejar o desenvolvimento, a implantação e a operação seguros de funções sem servidor é muito parecido com o de qualquer aplicativo Web ou hospedado na nuvem. O Serviço de Aplicativo do Azure fornece a infraestrutura de hospedagem para seus aplicativos de funções. Este artigo fornece estratégias de segurança para executar o código de função e como o Serviço de Aplicativo pode ajudá-lo a proteger suas funções.
Os componentes de plataforma do Serviço de Aplicativo, incluindo VMs do Azure, armazenamento, conexões de rede, estruturas da Web, recursos de integração e gerenciamento, são ativamente seguros e protegidos. O Serviço de Aplicativo passa por verificações de conformidade rigorosas continuamente para garantir que:
- Os recursos do aplicativo estejam protegidos dos recursos do Azure de outros clientes.
- Instâncias de VM e software de runtime são atualizados regularmente para tratar vulnerabilidades recentemente descobertas.
- A comunicação de segredos (como cadeias de conexão) entre o aplicativo e outros recursos do Azure (como Banco de Dados SQL) permanece no Azure e não ultrapassa limites de rede. Segredos sempre são criptografados quando armazenados.
- Toda a comunicação sobre os 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, ataque de DDoS (negação de serviço distribuído), MITM (man-in-the-middle) e outras ameaças.
Para saber mais sobre segurança de plataforma e infraestrutura no Azure, confira Centro de Confiabilidade do Azure.
Para obter um conjunto de recomendações de segurança que seguem o Microsoft Cloud Security Benchmark, confira a Linha de Base de Segurança do Azure para Azure Functions.
Operação segura
Esta seção orienta você sobre como configurar e executar seu aplicativo de funções da maneira mais segura possível.
Defender para Nuvem
O Defender para Nuvem se integra ao aplicativo de funções no portal. Ele fornece, gratuitamente, uma avaliação rápida de possíveis vulnerabilidades de segurança relacionadas à configuração. Os aplicativos de funções em execução em um plano dedicado também podem usar os recursos de segurança aprimorados do Defender para Nuvem mediante um custo adicional. Para saber mais, confira Proteger seus aplicativos Web e APIs do Azure App Service.
Registrar e monitorar
Uma maneira de detectar ataques é por meio do monitoramento de atividades e da análise de logs. O Functions oferece integração com o Application Insights para coletar dados de log, de desempenho e de erro para seu aplicativo de funções. O Application Insights detecta automaticamente anomalias de desempenho e inclui ferramentas de análise avançadas para ajudar a diagnosticar problemas e entender como suas funções são usadas. Para saber mais, consulte Monitorar Azure Functions.
As funções também se integram aos logs do Azure Monitor para permitir que você consolide logs do aplicativo de funções com eventos do sistema para uma análise mais fácil. Você pode usar as configurações de diagnóstico para definir a exportação de streaming de logs e métricas de plataforma das suas funções para o destino de sua escolha, como um espaço de trabalho do Log Analytics. Para saber mais, confira Monitoramento do Azure Functions com Logs do Azure Monitor.
Para detecção de ameaças de nível empresarial e automação de resposta, transmita seus logs e eventos para um espaço de trabalho do Log Analytics. Depois você pode conectar o Microsoft Sentinel com este workspace. Para saber mais, confira O que é o Microsoft Azure Sentinel.
Para obter mais recomendações de segurança para a observação, consulte a Linha de base de segurança do Azure para Azure Functions.
Solicitar 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, pois 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, também deverá 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).
Chaves de acesso de função
As funções permitem o uso de chaves para dificultar o acesso aos pontos de extremidade de função HTTP durante o desenvolvimento. A menos que o nível de acesso HTTP em uma função disparada por HTTP seja definido como anonymous, as solicitações devem incluir uma chave de acesso à API na solicitação.
Embora as chaves forneçam um mecanismo de segurança padrão, talvez você queira considerar outras opções para proteger um ponto de extremidade HTTP em produção. Por exemplo, não é uma boa prática distribuir o segredo compartilhado em aplicativos públicos. Se sua função estiver sendo chamada de um cliente público, talvez seja aconselhável considerar a implementação de outro mecanismo de segurança. Para obter mais informações, confira Proteger um ponto de extremidade HTTP em produção.
Ao renovar os valores de chave de função, é necessário redistribuir manualmente os valores de chave atualizados para todos os clientes que chamam sua função.
Escopos de autorização (nível de função)
Há dois escopos de acesso para chaves de nível de função:
Função: essas chaves se aplicam apenas às funções específicas sob as quais elas foram definidas. Quando usadas como uma chave de API, elas permitem acesso apenas às funções em questão.
Host: As chaves com um escopo de host podem ser usadas para acessar todas as funções no aplicativo de funções. Quando usadas como uma chave de API, elas permitem acesso a qualquer função no aplicativo de funções.
Cada chave é nomeada para referência e há uma chave padrão (chamada "default") no nível de função e de host. As chaves de função têm precedência sobre as chaves de host. Quando duas chaves forem definidas com o mesmo nome, a chave de função sempre será usada.
Chave mestra (nível de administrador)
Cada aplicativo de funções também tem uma chave de host de nível de administrador chamada _master. Além de fornecer acesso em nível de host a todas as funções no aplicativo, a chave mestra também fornece acesso administrativo às APIs REST de tempo de execução. Não é possível revogar essa chave. Quando você define o nível de acesso como admin, as solicitações precisam usar a chave mestra. Nesse caso, o uso de outra chave resulta em falha no acesso.
Cuidado
Devido às permissões elevadas no aplicativo de funções concedidas pela chave mestra, você não deve compartilhar essa chave com terceiros nem distribuí-la em aplicativos cliente nativos. Tenha cuidado ao escolher o nível de acesso do administrador.
Chave do sistema
Extensões específicas podem exigir uma chave gerenciada pelo sistema para acessar pontos de extremidade de webhook. As chaves do sistema são projetadas para pontos de extremidade de função específicos da extensão que são chamados por componentes internos. Por exemplo, o gatilho de Grade de Eventos requer que a assinatura use uma chave do sistema ao chamar o ponto de extremidade do gatilho. O Durable Functions também usa as chaves do sistema para chamar APIs de extensão de tarefa durável.
O escopo das chaves do sistema é determinado pela extensão, mas geralmente se aplica a todo o aplicativo de funções. As chaves do sistema só podem ser criadas por extensões específicas e você não pode definir seus valores explicitamente. Assim como outras chaves, você pode gerar um novo valor para a chave do portal ou usar as APIs de chave.
Comparação de chaves
A tabela a seguir compara os usos para vários tipos de chaves de acesso:
| Ação | Escopo | Chaves válidas |
|---|---|---|
| Executar uma função | Função específica | Função |
| Executar uma função | Qualquer função | Função ou host |
| Chamar um ponto de extremidade de administrador | Aplicativo de funções | Host (somente mestre) |
| Chamar APIs de extensão de tarefa durável | Aplicativo de funções1 | Sistema2 |
| Chamar um webhook específico da extensão (interno) | Aplicativo de funções1 | sistema2 |
1Escopo determinado pela extensão.
2Nomes específicos definidos pela extensão.
Para saber mais sobre as chaves de acesso, consulte o Artigo de associação de gatilho HTTP.
Repositórios de segredos
Por padrão, as chaves são armazenadas em um contêiner de armazenamento de blobs na conta fornecida pela configuração AzureWebJobsStorage. Você pode usar a configuração AzureWebJobsSecretStorageType para substituir esse comportamento e armazenar chaves em um local diferente.
| Location | Valor | Descrição |
|---|---|---|
| Segunda conta de armazenamento | blob |
Armazena chaves no armazenamento de Blob de uma conta de armazenamento diferente, com base na URL SAS em AzureWebJobsSecretStorageSas. |
| Sistema de arquivos | files |
As chaves são mantidas no sistema de arquivos, que é o padrão em Functions v1.x. |
| Cofre de Chave do Azure | keyvault |
O Key Vault definido em AzureWebJobsSecretStorageKeyVaultUri é usado para armazenar chaves. |
| Segredos do Kubernetes | kubernetes |
O conjunto de recursos em AzureWebJobsKubernetesSecretName é usado para armazenar chaves. Com suporte apenas ao executar o tempo de execução do Functions em Kubernetes. O Azure Functions Core Tools gera os valores automaticamente durante a implantação no Kubernetes. |
Ao usar o Key Vault para armazenamento de chaves, as configurações de aplicativo necessárias dependem do tipo de identidade gerenciada. A versão 3.x de runtime do Functions só é compatível com identidades gerenciadas atribuídas pelo sistema.
| Nome da configuração | Atribuída pelo sistema | Atribuída pelo usuário | Registro do aplicativo |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
Autenticação/autorização
Embora as teclas de função possam fornecer alguma mitigação para acesso indesejado, a única maneira de realmente proteger os pontos de extremidade de função é implementar 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.
Habilitar a Autenticação/Autorização do Serviço de Aplicativo
A plataforma do Serviço de Aplicativo permite usar 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 trabalhar com informações de usuário por meio do código da função. Para saber mais, consulte Autenticação e autorização no Serviço de Aplicativo do Azure e Trabalhando com identidades do cliente.
Use o APIM (Gerenciamento de API do Azure) para autenticar solicitações
O APIM fornece uma variedade de opções de segurança de API para solicitações de entrada. Para saber mais, confira Políticas de autenticação do Gerenciamento de API. Com o APIM em vigor, você pode configurar o aplicativo de funções para aceitar solicitações somente do endereço IP da sua instância do APIM. Para saber mais, confira Restrições de endereço IP.
Permissões
Assim como ocorre com qualquer aplicativo ou serviço, a meta é executar seu aplicativo de funções com as permissões mais baixas possíveis.
Permissões de gerenciamento do usuário
O Functions dá suporte ao controle de acesso baseado em função (RBAC) do Azure interno. As funções do Azure compatíveis com o Functions são Colaborador, Proprietário e Leitor.
As permissões são efetivas no nível do aplicativo de funções. A função de Colaborador é necessária para executar a maioria das tarefas de nível de aplicativo de função. Você também precisa da função Colaborador e da permissão de Leitor de Monitoramento para exibir dados de log no Aplicativo Insights. Somente a função de Proprietário pode excluir um aplicativo 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ções 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ções separado. Você sempre pode usar técnicas como encadeamento de funções para passar dados entre funções em diferentes aplicativos de funções.
Identidades gerenciadas
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 é gerenciada pela plataforma do Azure e não exige provisionamento ou giro de nenhum segredo. Para saber mais sobre identidades gerenciadas no Microsoft Entra ID, confira Identidades gerenciadas para recursos do Azure.
Seu aplicativo pode receber dois tipos de identidades:
- Uma identidade atribuída pelo sistema é vinculada ao seu aplicativo e é excluída se o seu aplicativo for excluído. Um aplicativo só pode ter uma identidade atribuída pelo sistema.
- Uma identidade atribuída pelo usuário é um recurso independente do Azure que pode ser atribuído ao seu aplicativo. Um aplicativo pode ter várias identidades atribuídas pelo usuário.
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 CORS
O CORS (compartilhamento de recursos entre origens) é uma maneira de permitir que aplicativos Web em execução em outro domínio façam solicitações para seus pontos de extremidade de gatilho HTTP. O Serviço de Aplicativo fornece suporte interno para a entrega dos cabeçalhos CORS necessários em solicitações HTTP. As regras de CORS são definidas em um nível de aplicativo de funções.
Embora seja tentador usar um curinga que permite que todos os sites acessem seu ponto de extremidade, isso elimina a finalidade 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.
Gerenciamento de segredos
Para se conectar aos vários serviços e recursos que precisam executar seu código, os aplicativos de funções 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.
Configurações do aplicativo
Por padrão, armazene cadeias de conexão e segredos usados pelo seu aplicativo de funções e associações como configurações de aplicativo. Isso disponibiliza essas credenciais tanto para o código de função quanto para 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ções 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 cadeias de conexão são armazenadas e criptografadas no Azure. Elas são descriptografadas somente antes de serem injetadas na memória do processo do aplicativo quando o aplicativo é iniciado. As chaves de criptografia são giradas regularmente. Se você preferir gerenciar o armazenamento seguro de seus segredos, a configuração do aplicativo deverá, em vez disso, fazer referência a Azure Key Vault.
Você também pode criptografar as configurações por padrão no arquivo local.settings.json ao desenvolver funções em seu computador local. Para obter mais informações, confira Criptografar o arquivo de configurações local.
Referências de 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 é para um serviço de armazenamento de segredo central e usar referências a esse serviço em vez dos próprios segredos.
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 de Key Vault no lugar de uma cadeia de conexão ou chave em suas configurações de aplicativo. Para saber mais, consulte Usar as referências do Key Vault 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 auditoria e controle de acesso mais refinados.
Ao escrever um código que cria a conexão com os Serviços do Azure que dão suporte à autenticação do Microsoft Entra, opte por usar uma identidade em vez de um segredo ou cadeia de conexã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 gatilho e associação do Azure Functions podem ser configurados usando uma conexão baseada em identidade. Hoje, isso inclui o blob do Azure e as extensões de fila do Azure. Para obter informações sobre como configurar essas extensões para usar uma identidade, consulte Como usar conexões baseadas em identidade no Azure Functions.
Definir cotas de uso
Considere definir uma cota de uso em funções em execução em um plano de consumo. Quando você define um limite diário de GB por segundo na soma total de execução de funções em seu aplicativo de funções, a execução é interrompida quando o limite é atingido. Isso poderia ajudar a reduzir o código mal-intencionado que executa suas funções. Para saber como estimar o consumo para suas funções, consulte Estimar os custos do plano de consumo.
Validação de dados
Os gatilhos e as associações usadas pelas suas funções não fornecem validação de dados adicional. Seu código deve validar todos os dados recebidos de um gatilho ou uma associação de entrada. Caso um serviço de upstream esteja comprometido, você não quer que entradas não validadas fluam por meio 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 presuma que os dados que chegam à sua função já tenham sido validados ou corrigidos. Também é uma boa ideia verificar se os dados que estão sendo gravados em associações de saída são válidos.
Tratar erros
Embora pareça básico, é importante escrever um bom tratamento de erro em suas funções. Erros não tratados se acumulam para o host e são manipulados pelo tempo de execução. Associações diferentes tratam do processamento de erros de forma diferente. Para saber mais, consulte Tratamento de erro do Azure Functions.
Desabilitar depuração remota
Verifique se a depuração remota está desabilitada, exceto quando você estiver depurando ativamente suas funções. Você pode desabilitar a depuração remota na guia Configurações gerais do seu aplicativo de funções de Configuração no portal.
Restringir o acesso CORS
O Azure Functions oferece suporte a compartilhamento de recursos entre origens (CORS). O CORS está configurado no portal e por meio do CLI do Azure. A lista de origens permitidas pelo CORS aplica-se ao nível do aplicativo de funções. Com o CORS habilitado, as respostas incluem o cabeçalho Access-Control-Allow-Origin. Para obter mais informações, consulte Compartilhamento de recursos entre origens.
Não use caracteres curinga em 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 Criptografia do Armazenamento do Azure para dados em repouso.
Por padrão, os dados são criptografados com chaves gerenciadas pela Microsoft. Para obter controle adicional sobre as 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 para que o Functions possa acessar a conta de armazenamento. Para saber mais, confira Criptografia em repouso usando chaves gerenciadas pelo cliente.
Proteger recursos relacionados
Um aplicativo de funções geralmente depende de recursos adicionais, portanto, parte da proteção do aplicativo é proteger esses recursos externos. A maioria dos aplicativos de funções inclui, no mínimo, 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 diretrizes 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 todos os tipos de recursos dos quais a lógica do aplicativo depende, como gatilhos e associações, além do código de função.
Implantação segura
Agregar ferramentas do Azure Functions para uma integração facilitam 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 de uma topologia de Azure Functions.
Credenciais de implantaçã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ções. 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 e em qualquer assinatura que a conta do Azure tem permissão para acessar. É o conjunto padrão que aparece na GUI do portal (como a Visão geral e Propriedades da página de recursos do aplicativo). Quando um usuário recebe acesso ao aplicativo por meio de RBAC (Controle de Acesso Baseado na Função) ou permissões coadmin, esse usuário pode usar suas próprias credenciais em nível de usuário até que o acesso seja revogado. Não compartilhe essas credenciais com outros usuários do Azure.
Credenciais de nível de aplicativo: um conjunto de credenciais para cada aplicativo. Podem ser usadas para implantar nesse aplicativo somente. 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 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 pode acessar essas credenciais.
Neste momento, não há suporte para Key Vault para credenciais de implantação. Para obter mais informações sobre como configurar as credenciais de implantação, consulte Configurar as credenciais de implantação para o Serviço de Aplicativo do Azure.
Desabilitar FTP
Por padrão, cada aplicativo de funções tem um ponto de extremidade de FTP habilitado. O ponto de extremidade de FTP é acessado usando credenciais de implantação.
O FTP não é recomendado para implantação de código de função. As implantações de FTP são manuais e exigem a sincronização de gatilhos. Para saber mais, confira Implantação de FTP.
Quando não estiver planejando usar o FTP, você deverá desabilitá-lo no portal. Se você optar por usar o FTP, deverá impor FTPS.
Proteger o ponto de extremidade do scm
Cada aplicativo de funções tem um ponto de extremidade de serviço scm correspondente que é usado pelo serviço ferramentas avançadas (Kudu) em implantações e outras scm do Serviço de Aplicativo. O ponto de extremidade SCM para um aplicativo de funções é sempre uma URL no formulário https://<FUNCTION_APP_NAME.scm.azurewebsites.net>. Ao usar o isolamento de rede para proteger suas funções, você também deve considerar esse ponto de extremidade.
Tendo um ponto de extremidade SCM separado, você pode controlar as implantações e outras funcionalidades de ferramentas avançadas para o aplicativo de funções que estão isoladas ou em execução em uma rede virtual. O ponto de extremidade do SCM dá suporte à autenticação básica (usando credenciais de implantação) e ao logon único com suas credenciais de portal do Azure. Para saber mais, confira Acessar o serviço Kudu.
Avaliação contínua de segurança
Como a segurança precisa ser considerada a cada etapa do processo de desenvolvimento, faz sentido implementar também 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 que você integre 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 de rede
Restringir o acesso à rede para seu aplicativo de funções permite controlar quem pode acessar seus pontos de extremidade de funções. As funções aproveitam 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, confira Opções de rede do Azure Functions.
Definir restrições de acesso
As restrições de acesso permitem definir listas de regras de permissão/negação para controlar o tráfego para seu aplicativo. As regras são avaliadas em ordem de prioridade. Se não houver nenhuma regra definida, seu aplicativo aceitará o tráfego de qualquer endereço. Para saber mais, confira Restrições de acesso ao serviço do Serviço de Aplicativo do Azure .
Proteger a conta de armazenamento
Quando você cria um aplicativo de funções, é necessário criar ou vincular uma conta de Armazenamento do Azure de uso geral que dá ao armazenamento de Tabelas, Blobs e Filas. Você pode substituir essa conta de armazenamento por uma que seja protegida por pontos de extremidade de serviço ou pontos de extremidade privados. Para obter mais informações, confira Restringir a conta de armazenamento a uma rede virtual.
Acesso a site particular
O Ponto de Extremidade Privado do Azure é um adaptador de rede que conecta você de maneira privada e segura a um serviço que conta com o Link Privado do Azure. O Ponto de Extremidade Privado usa um endereço IP privado da rede virtual, colocando efetivamente o serviço na sua rede virtual.
É possível usar o ponto de extremidade privado para suas funções hospedadas nos planos de Serviço de aplicativo e Premium.
Se você quiser fazer chamadas para Pontos de extremidade privados, deverá certificar-se de que suas pesquisas de DNS sejam resolvidas em relação ao ponto de extremidades privado. Você pode impor esse comportamento de uma das seguintes maneiras:
- Integrar com as zonas privadas do DNS do Azure. Quando sua rede virtual não tem um servidor DNS personalizado, isso é feito automaticamente.
- Gerenciar o ponto de extremidade privado no servidor DNS usado pelo seu aplicativo. Para fazer isso, você precisa saber o endereço do ponto de extremidade privado e apontar o ponto de extremidade que está tentando acessar para esse endereço usando um registro A.
- Configure seu próprio servidor DNS para encaminhar para as zonas privadas do DNS do Azure.
Para saber mais, confira usar Pontos de extremidade privados para Aplicativos Web.
Implante o aplicativo de funções isoladamente
O ASE (Ambiente do Serviço de Aplicativo) do Azure fornece um ambiente de hospedagem dedicado para que você execute suas funções. O ASE permite configurar um único gateway de front-end que você pode usar para autenticar todas as solicitações de entrada. Para obter mais informações, confira Configurando um WAF (firewall do aplicativo Web) para o Ambiente do Serviço de Aplicativo.
Use um serviço do gateway
Os serviços de gateway, como Gateway de Aplicativo do Azure e Azure Front Door, permitem configurar um WAF (firewall do aplicativo Web). As regras WAF são usadas para monitorar ou bloquear ataques detectados, que fornecem uma camada extra de proteção para suas funções. Para configurar um WAF, seu aplicativo de funções precisa estar em execução em um ASE ou usando pontos de extremidade privados (versão prévia). Para saber mais, confira Usar pontos de extremidade privados.