Segurança de aplicativos e serviços do Service Fabric
Uma arquitetura de microsserviços pode trazer muitos benefícios. Gerenciar a segurança de microsserviços, no entanto, é um desafio e diferente de gerenciar a segurança de aplicativos monolíticos tradicionais.
Com um monólito, o aplicativo normalmente é executado em um ou mais servidores dentro de uma rede e é mais fácil identificar as portas expostas, APIs e endereço IP. Muitas vezes, há um perímetro ou limite e um banco de dados para proteger. Se esse sistema for comprometido devido a uma violação de segurança ou ataque, é provável que tudo dentro do sistema esteja disponível para o invasor. Com os microsserviços, o sistema é mais complexo. Os serviços são descentralizados e distribuídos em muitos hosts e migram de host para host. Com segurança adequada, você limita os privilégios que um invasor pode obter e a quantidade de dados disponíveis em um único ataque violando um serviço. A comunicação não é interna, mas acontece através de uma rede, e há muitas portas expostas e interações entre serviços. Saber quais são essas interações de serviço e quando elas acontecem é crucial para a segurança do seu aplicativo.
Este artigo não é um guia para a segurança de microsserviços, há muitos desses recursos disponíveis online, mas descreve como diferentes aspetos da segurança podem ser realizados no Service Fabric.
Autenticação e autorização
Muitas vezes, é necessário que os recursos e APIs expostos por um serviço sejam limitados a determinados usuários ou clientes confiáveis. A autenticação é o processo de verificação confiável da identidade de um usuário. Autorização é o processo que torna APIs ou serviços disponíveis para alguns usuários autenticados, mas não para outros.
Autenticação
A primeira etapa para tomar decisões de confiança no nível da API é a autenticação. A autenticação é o processo de verificação confiável da identidade de um usuário. Em cenários de microsserviços, a autenticação normalmente é tratada centralmente. Se você estiver usando um API Gateway, poderá descarregar a autenticação para o gateway. Se você usar essa abordagem, certifique-se de que os serviços individuais não possam ser acessados diretamente (sem o API Gateway), a menos que haja segurança adicional para autenticar mensagens, sejam elas provenientes do gateway ou não.
Se os serviços puderem ser acessados diretamente, um serviço de autenticação como o Microsoft Entra ID ou um microsserviço de autenticação dedicado atuando como um serviço de token de segurança (STS) poderá ser usado para autenticar usuários. As decisões de confiança são partilhadas entre serviços com tokens de segurança ou cookies.
Para ASP.NET Core, o principal mecanismo para autenticar usuários é o sistema de associação ASP.NET Core Identity. ASP.NET Identidade Principal armazena informações do usuário (incluindo informações de entrada, funções e declarações) em um armazenamento de dados configurado pelo desenvolvedor. ASP.NET Core Identity suporta autenticação de dois fatores. Provedores de autenticação externos também são suportados, para que os usuários possam entrar usando processos de autenticação existentes de provedores como Microsoft, Google, Facebook ou Twitter.
Autorização
Após a autenticação, os serviços precisam autorizar o acesso do usuário ou determinar o que um usuário é capaz de fazer. Esse processo permite que um serviço disponibilize APIs para alguns usuários autenticados, mas não para todos. A autorização é ortogonal e independente da autenticação, que é o processo de determinar quem é um usuário. A autenticação pode criar uma ou mais identidades para o usuário atual.
ASP.NET autorização principal pode ser feita com base nas funções dos usuários ou com base na política personalizada, que pode incluir a inspeção de declarações ou outras heurísticas.
Restrinja e proteja o acesso usando um gateway de API
Geralmente, as aplicações da cloud precisam de um gateway de front-end que forneça um único ponto de entrada para utilizadores, dispositivos ou outras aplicações. Um gateway de API fica entre clientes e serviços e é o ponto de entrada para todos os serviços que seu aplicativo está fornecendo. Ele atua como um proxy reverso, roteando solicitações de clientes para serviços. Ele também pode executar várias tarefas transversais, como autenticação e autorização, terminação TLS e limitação de taxa. Se você não implantar um gateway, os clientes deverão enviar solicitações diretamente para os serviços front-end.
No Service Fabric, um gateway pode ser qualquer serviço sem monitoração de estado, como um aplicativo ASP.NET Core, ou outro serviço projetado para entrada de tráfego, como Traefik, Hubs de Eventos, Hub IoT ou Gerenciamento de API do Azure.
O Gerenciamento de API integra-se diretamente ao Service Fabric, permitindo que você publique APIs com um rico conjunto de regras de roteamento para seus serviços back-end do Service Fabric. Você pode proteger o acesso a serviços de back-end, evitar ataques DOS usando limitação ou verificar chaves de API, tokens JWT, certificados e outras credenciais. Para saber mais, leia Visão geral do Service Fabric com Gerenciamento de API do Azure.
Gerir segredos da aplicação
Os segredos podem ser qualquer informação confidencial, como cadeias de conexão de armazenamento, senhas ou outros valores que não devem ser manipulados em texto sem formatação. Este artigo usa o Azure Key Vault para gerenciar chaves e segredos. No entanto, o uso de segredos em um aplicativo é independente da plataforma de nuvem para permitir que os aplicativos sejam implantados em um cluster hospedado em qualquer lugar.
A maneira recomendada de gerenciar definições de configuração de serviço é por meio de pacotes de configuração de serviço. Os pacotes de configuração são versionados e atualizáveis por meio de atualizações contínuas gerenciadas com validação de integridade e reversão automática. Isso é preferível à configuração global, pois reduz as chances de uma interrupção global do serviço. Os segredos encriptados não são exceção. O Service Fabric tem recursos internos para criptografar e descriptografar valores em um arquivo Settings.xml do pacote de configuração usando criptografia de certificado.
O diagrama a seguir ilustra o fluxo básico para o gerenciamento de segredos em um aplicativo do Service Fabric:
Há quatro etapas principais nesse fluxo:
- Obtenha um certificado de codificação de dados.
- Instale o certificado no cluster.
- Criptografe valores secretos ao implantar um aplicativo com o certificado e injete-os no arquivo de configuração Settings.xml de um serviço.
- Leia valores criptografados fora de Configurações.xml descriptografando com o mesmo certificado de criptografia.
O Azure Key Vault é usado aqui como um local de armazenamento seguro para certificados e como uma maneira de obter certificados instalados em clusters do Service Fabric no Azure. Se você não estiver implantando no Azure, não precisará usar o Cofre da Chave para gerenciar segredos em aplicativos do Service Fabric.
Para obter um exemplo, consulte Gerenciar segredos do aplicativo.
Proteja o ambiente de hospedagem
Usando o Azure Service Fabric, você pode proteger aplicativos que estão sendo executados no cluster em diferentes contas de usuário. O Service Fabric também ajuda a proteger os recursos usados pelos aplicativos no momento da implantação nas contas de usuário, por exemplo, arquivos, diretórios e certificados. Isso torna os aplicativos em execução, mesmo em um ambiente hospedado compartilhado, mais seguros uns dos outros.
O manifesto do aplicativo declara as entidades de segurança (usuários e grupos) necessárias para executar o(s) serviço(s) e os recursos seguros. Essas entidades de segurança são referenciadas em políticas, por exemplo, as diretivas run-as, endpoint binding, package sharing ou security access. As políticas são então aplicadas aos recursos de serviço na seção ServiceManifestImport do manifesto do aplicativo.
Ao declarar entidades de segurança, você também pode definir e criar grupos de usuários para que um ou mais usuários possam ser adicionados a cada grupo a ser gerenciado em conjunto. Isso é útil quando há vários usuários para diferentes pontos de entrada de serviço e eles precisam ter certos privilégios comuns que estão disponíveis no nível do grupo.
Por padrão, os aplicativos do Service Fabric são executados na conta na qual o processo .exe malha é executado. O Service Fabric também fornece a capacidade de executar aplicativos em uma conta de usuário local ou conta de sistema local, que é especificada no manifesto do aplicativo. Para obter mais informações, consulte Executar um serviço como uma conta de usuário local ou conta de sistema local. Você também pode executar um script de inicialização de serviço como um usuário local ou conta do sistema.
Ao executar o Service Fabric em um cluster autônomo do Windows, você pode executar um serviço em contas de domínio do Ative Directory ou contas de serviço gerenciado de grupo.
Proteger contentores
O Service Fabric fornece um mecanismo para que os serviços dentro de um contêiner acessem um certificado instalado nos nós em um cluster Windows ou Linux (versão 5.7 ou superior). Este certificado PFX pode ser usado para autenticar o aplicativo ou serviço ou comunicação segura com outros serviços. Para obter mais informações, consulte Importar um certificado para um contêiner.
Além disso, o Service Fabric também oferece suporte a gMSA (contas de serviço gerenciado de grupo) para contêineres do Windows. Para obter mais informações, consulte Configurar o gMSA para contêineres do Windows.
Comunicação de serviço segura
No Service Fabric, um serviço é executado em algum lugar em um cluster do Service Fabric, normalmente distribuído entre várias VMs. O Service Fabric fornece várias opções para proteger suas comunicações de serviço.
Você pode habilitar pontos de extremidade HTTPS em seus serviços Web ASP.NET Core ou Java .
Você pode estabelecer uma conexão segura entre o proxy reverso e os serviços, permitindo assim um canal seguro de ponta a ponta. A conexão a serviços seguros é suportada somente quando o proxy reverso está configurado para escutar em HTTPS. Para obter informações sobre como configurar o proxy reverso, leia Proxy reverso no Azure Service Fabric. Conectar-se a um serviço seguro descreve como estabelecer uma conexão segura entre o proxy reverso e os serviços.
A estrutura do aplicativo Reliable Services fornece algumas pilhas de comunicação pré-criadas e ferramentas que você pode usar para melhorar a segurança. Saiba como melhorar a segurança quando estiver usando comunicação remota de serviço (em C# ou Java) ou usando WCF.
Incluir certificado de ponto de extremidade em aplicativos do Service Fabric
Para configurar o certificado de ponto de extremidade do aplicativo, inclua o certificado adicionando um elemento EndpointCertificate junto com o elemento User da conta principal ao manifesto do aplicativo. Por padrão, a conta principal é NetworkService. Isso fornecerá gerenciamento da ACL de chave privada do certificado de aplicativo para a entidade fornecida.
<ApplicationManifest … >
...
<Principals>
<Users>
<User Name="Service1" AccountType="NetworkService" />
</Users>
</Principals>
<Certificates>
<EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
</Certificates>
</ApplicationManifest>
Criptografar dados do aplicativo em repouso
Cada tipo de nó num cluster do Service Fabric em execução no Azure é suportado por um conjunto de dimensionamento de máquinas virtuais. Ao utilizar um modelo do Azure Resource Manager, pode anexar discos de dados aos conjuntos de dimensionamento que compõem o cluster do Service Fabric. Se seus serviços salvarem dados em um disco de dados anexado, você poderá criptografar esses discos de dados para proteger os dados do aplicativo.