Protegendo o Azure Functions
De muitas maneiras, o planejamento para desenvolvimento, implantação e operação seguros de funções sem servidor é muito semelhante ao de 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 adicional. 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.
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
O Functions permite que você use teclas para dificultar o acesso aos pontos de extremidade da função HTTP durante o desenvolvimento. 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 à API na solicitação.
Embora as chaves forneçam um mecanismo de segurança padrão, convém considerar outras opções para proteger um ponto de extremidade HTTP em produção. Por exemplo, não é uma boa prática distribuir segredo compartilhado em aplicativos públicos. Se a sua função estiver a ser chamada a partir de um cliente público, poderá considerar a implementação de outro mecanismo de segurança. Para saber mais, consulte Proteger um ponto de extremidade HTTP em produção.
Ao renovar os valores de chave de função, você deve 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: Estas teclas aplicam-se apenas às funções específicas sob as quais estão definidas. Quando usados como uma chave de API, eles só permitem o acesso a essa função.
Host: As teclas com um escopo de host podem ser usadas para acessar todas as funções dentro do aplicativo de função. Quando usados como uma chave de API, eles permitem o acesso a qualquer função dentro do aplicativo de função.
Cada chave é nomeada para referência, e há uma chave padrão (chamada "padrão") no nível da função e do host. As teclas de função têm precedência sobre as teclas de host. Quando duas teclas são definidas com o mesmo nome, a tecla de função é sempre usada.
Chave mestra (nível de administrador)
Cada aplicativo de função 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. Esta chave não pode ser revogada. Quando você define um nível de acesso de , as solicitações devem usar a chave mestra, qualquer outra chave resulta em falha de adminacesso.
Atenção
Devido às permissões elevadas em seu aplicativo de função concedidas pela chave mestra, você não deve compartilhar essa chave com terceiros ou distribuí-la em aplicativos cliente nativos. Tenha cuidado ao escolher o nível de acesso de administrador.
Chave do sistema
Extensões específicas podem exigir uma chave gerenciada pelo sistema para acessar pontos de extremidade webhook. As chaves do sistema são projetadas para pontos de extremidade de função específicos de 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. Durable Functions também usa 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ção. As chaves do sistema só podem ser criadas por extensões específicas e você não pode definir explicitamente seus valores. Como outras chaves, você pode gerar um novo valor para a chave a partir do portal ou usando 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 | Âmbito | Teclas válidas |
|---|---|---|
| Executar uma função | Função específica | Function |
| Executar uma função | Qualquer função | Função ou host |
| Chamar um ponto de extremidade de administrador | Aplicação de funções | Host (somente mestre) |
| Chamar APIs de extensão de tarefa durável | AplicaçãoFunção 1 | Sistema2 |
| Chamar um Webhook específico da extensão (interno) | AplicaçãoFunção 1 | sistema2 |
1 Âmbito determinado pela extensão.
2 Nomes específicos definidos por extensão.
Para saber mais sobre chaves de acesso, consulte o artigo Vinculação de gatilho HTTP.
Repositórios secretos
Por padrão, as AzureWebJobsStorage chaves são armazenadas em um contêiner de armazenamento de Blob na conta fornecida pela configuração. Você pode usar a configuração AzureWebJobsSecretStorageType para substituir esse comportamento e armazenar chaves em um local diferente.
| Localização | Valor | Descrição |
|---|---|---|
| Segunda conta de armazenamento | blob |
Armazena chaves no Armazenamento de blobs de uma conta de armazenamento diferente, com base no URL da SAS no AzureWebJobsSecretStorageSas. |
| Sistema de ficheiros | files |
As chaves persistem no sistema de ficheiros, que é a predefinição nas Funções v1.x. |
| Azure Key Vault | keyvault |
O cofre de chaves definido em AzureWebJobsSecretStorageKeyVaultUri é utilizado para armazenar chaves. |
| Segredos de Kubernetes | kubernetes |
O conjunto de recursos no AzureWebJobsKubernetesSecretName é utilizado para armazenar chaves. Suportado apenas ao executar o runtime das Funções no Kubernetes. O Azure Functions Core Tools gera os valores automaticamente durante a implementação no Kubernetes. |
Ao utilizar o Key Vault para o armazenamento de chaves, as definições da aplicação de que precisa dependem do tipo de identidade gerida. A versão 3.x do runtime de funções suporta apenas identidades geridas atribuídas pelo sistema.
| Nome da definição | Atribuída pelo sistema | Atribuída pelo utilizador | Registo de aplicações |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
Autenticação/autorização
Embora as teclas de função possam fornecer alguma atenuação para acessos indesejados, a única maneira de realmente proteger 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.
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 uma variedade de 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 pelo sistema está associada à aplicação e será eliminada se a aplicação for eliminada. 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. Uma aplicação pode ter várias identidades atribuídas pelo utilizador.
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, em vez disso, você preferir gerenciar o armazenamento seguro de seus segredos, a configuração do aplicativo deve ser referências ao Cofre da Chave do Azure.
Você também pode criptografar configurações por padrão no arquivo local.settings.json ao desenvolver funções em seu 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 é um serviço central de armazenamento secreto e usar 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 gatilho e vinculação do Azure Functions podem ser configuradas usando uma conexão baseada em identidade. Hoje, isso inclui as extensões de Blob do Azure e Filado 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 quotas de utilização
Considere definir uma cota de uso em funções executadas em um plano de consumo. Quando você define um limite diário de GB-s na soma total de execução 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 para o host e são manipulados pelo tempo de execução. Diferentes associaçõ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.
Proteja os recursos relacionados
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
As ferramentas do Azure Functions 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 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.
Proteja o ponto de extremidade do scm
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 ponto de extremidade scm 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 scm separado, você pode controlar implantações e outras funcionalidades de ferramentas avançadas para aplicativos funcionais que estão isolados 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 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 não houver regras definidas, 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 que esteja protegida com 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.
O acesso a sites privados
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 Premium e do Serviço de Aplicativo.
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 fazer isso, você deve saber o endereço do ponto de extremidade privado e, em seguida, apontar o ponto de extremidade que você está tentando alcançar para esse endereço usando um registro A.
- 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 (ASE) fornece um ambiente de hospedagem dedicado no qual executar suas funções. O ASE permite 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.