Segurança de serviço e aplicativo do Service Fabric
Uma arquitetura de microsserviços pode trazer muitos benefícios. Porém, o gerenciamento da segurança de microsserviços é um desafio que difere do gerenciamento da segurança de aplicativos monolítica tradicional.
Com um monolito, o aplicativo normalmente é executado em um ou mais servidores em uma rede e é mais fácil identificar as portas expostas e as APIs e o endereço IP. Geralmente há um perímetro ou limite e um banco de dados para proteger. Se o sistema estiver comprometido devido a uma violação de segurança ou ataque, é provável que todos os itens dentro do sistema estarão disponíveis para o invasor. Com os microsserviços, o sistema é mais complexo. Os serviços são descentralizados e distribuídos em vários hosts e migram de um host para outro. Com a segurança adequada, limite os privilégios que um invasor pode ter e a quantidade de dados disponíveis em um único ataque se houver invasão de um serviço. A comunicação não é interna, mas ocorre em 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 ocorrem é crucial para a segurança de seu aplicativo.
Este artigo não é um guia de segurança de microsserviços, há muitos recursos disponíveis online, mas descreve como os diferentes aspectos de segurança podem ser realizados no Service Fabric.
Autenticação e autorização
É geralmente necessário limitar os recursos e as APIs expostos por um serviço a determinados usuários ou clientes confiáveis. A autenticação é o processo de atestar de maneira confiável a identidade de um usuário. A autorização é o processo que disponibiliza APIs ou serviços para alguns usuários autenticados, mas não para outros.
Autenticação
A primeira etapa para tomar decisões de confiança de nível de API é a autenticação. A autenticação é o processo de atestar de maneira confiável a identidade de um usuário. Em cenários de microsserviço, a autenticação é normalmente feita de forma centralizada. Se você estiver usando um Gateway de API, 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 Gateway da API), a menos que uma segurança extra seja adicionada para autenticar mensagens, independentemente de serem ou não provenientes do gateway.
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 funcionando como um STS (serviço de token de segurança), poderá ser usado para autenticar os usuários. As decisões de confiança são compartilhadas entre os serviços com tokens de segurança ou cookies.
Para o ASP.NET Core, o mecanismo principal para autenticar usuários é o sistema de associação da Identidade do ASP.NET Core. A Identidade do ASP.NET Core armazena informações de usuário (incluindo informações de logon, funções e declarações) em um repositório de dados configurado pelo desenvolvedor. A Identidade do ASP.NET Core dá suporte à autenticação de dois fatores. Também há suporte para provedores de autenticação externa, para que os usuários possam entrar usando processos de autenticação existentes de provedores como Microsoft, Google, Facebook ou X.
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 de autenticação, que é o processo de verificação de quem é um usuário. A autenticação pode criar uma ou mais identidades para o usuário atual.
A autorização do ASP.NET Core pode ser feita com base nas funções dos usuários ou com base em política personalizada, que pode incluir a inspeção de declarações ou outros fatores.
Restringir e proteger o acesso usando um gateway de API
Os aplicativos em nuvem geralmente precisam de um gateway front-end para fornecer um ponto de entrada único para usuários, dispositivos ou outros aplicativos. Um gateway de API fica entre clientes e serviços e é o ponto de entrada para todos os serviços que o seu aplicativo fornece. Ele atua como um proxy reverso, encaminhando as solicitações de clientes para serviços. Ele também pode executar várias tarefas detalhadas, como autenticação e autorização, terminação de TLS e a limitação de taxa. Se você não implantar um gateway, os clientes deverão enviar solicitações diretamente aos serviços front-end.
No Service Fabric, um gateway pode ser qualquer serviço sem 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 com o Service Fabric, permitindo que APIs sejam publicadas com um conjunto de regras de roteamento avançado para serviços de back-end do Service Fabric . Você pode proteger o acesso a serviços de back-end, evitar ataques de DOS usando limitação ou verificar chaves de API, tokens de JWT, certificados e outras credenciais. Para saber mais, leia Service Fabric com visão geral de Gerenciamento de API do Azure.
Gerenciar segredos do aplicativo
Os segredos podem ser informações confidenciais, como cadeias de conexão de armazenamento, senhas ou outros valores que não devem ser tratados como 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 de plataforma de nuvem para permitir que os aplicativos sejam implantados em um cluster hospedado em qualquer lugar.
A maneira recomendada de gerenciar as 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 atualizáveis e têm controle de versão por meio de atualizações sem interrupção gerenciadas com reversão automática e validação de integridade. Isso é preferível à configuração global, pois reduz as chances de uma interrupção de serviços globais. Segredos criptografados 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 a criptografia de certificado.
O diagrama a seguir ilustra o fluxo básico para 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 em seu cluster.
- Criptografe valores do segredo ao implantar um aplicativo com o certificado e coloque-os no arquivo de configuração Settings.xml de um serviço.
- Leia os valores criptografados de Settings.xml ao descriptografar com o mesmo certificado de codificação.
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 não estiver implantando no Azure, você não precisará usar o cofre de chaves para gerenciar segredos em aplicativos do Service Fabric.
Para obter um exemplo, veja Gerenciar segredos do aplicativo.
Segurança do ambiente de hospedagem
Usando o Azure Service Fabric, é possível proteger aplicativos em execução no cluster em contas de usuário diferentes. O Service Fabric também protege 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 protegidos uns dos outros.
O manifesto do aplicativo declara as entidades de segurança (usuários e grupos) necessárias para executar os serviços e os recursos de segurança. Essas entidades são referenciadas em políticas, por exemplo, o executar como, o ponto de extremidade de associação, o compartilhamento de pacote ou as políticas de acesso de segurança. As políticas são aplicadas aos recursos de serviço na seção ServiceManifestImport do manifesto do aplicativo.
Ao declarar entidades de segurança, também é possível definir e criar grupos de usuários para que um ou mais usuários possam ser adicionados a cada grupo para serem gerenciados em conjunto. Isso será útil quando houver vários usuários para pontos de entrada de serviço diferentes e eles precisarem de privilégios comuns disponíveis no nível do grupo.
Por padrão, os aplicativos de Service Fabric são executados na conta sob a qual o processo Fabric.exe está sendo executado. O Service Fabric também fornece a capacidade de executar aplicativos em uma conta de usuário local ou em uma conta de sistema local, especificada no manifesto do aplicativo. Para saber mais, veja Executar um serviço como uma conta de usuário ou conta de sistema local. Você também pode Executar um script de inicialização do serviço como uma conta de usuário ou sistema local.
Quando você estiver executando o Service Fabric em um cluster autônomo do Windows, você pode executar um serviço em Contas de domínio do Active Directory ou Contas de serviço gerenciado de grupo.
Contêineres de segurança
O Service Fabric fornece um mecanismo para serviços dentro de um contêiner para acessar um certificado que está instalado em nós em um cluster do Windows ou Linux (versão 5.7 ou superior). Esse certificado PFX pode ser usado para autenticar o aplicativo ou o serviço ou proteger a comunicação com outros serviços. Para saber mais, veja Importar um certificado para um contêiner.
Além disso, o Service Fabric também dá suporte a gMSA (Contas de Serviço Gerenciado do grupo) para contêineres do Windows. Para saber mais, veja Configurar gMSA para contêineres do Windows.
Proteger comunicações de serviço
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 as comunicações do 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 serviços, permitindo um canal seguro de ponta a ponta. A conexão aos serviços seguros tem suporte apenas quando o proxy reverso é configurado para escutar em HTTPS. Para saber mais sobre como configurar o proxy reverso, leia Proxy reverso no Azure Service Fabric. Conectar a um serviço seguro descreve como estabelecer uma conexão segura entre o proxy reverso e os serviços.
A estrutura de aplicativo dos Reliable Services fornece algumas pilhas e ferramentas de comunicação predefinidas que você pode usar para aprimorar a segurança. Aprenda a melhorar a segurança quando você estiver usando a comunicação remota do serviço (em C# ou Java) ou usando WCF.
Incluir um certificado de ponto de extremidade em aplicativos do Service Fabric
Para configurar o certificado de ponto de extremidade do aplicativo, inclua o certificado no manifesto do aplicativo adicionando um elemento EndpointCertificate junto com o elemento User da conta da entidade de segurança. Por padrão, a conta da entidade de segurança é NetworkService. Essa opção fornecerá o gerenciamento da ACL de chave privada de certificado de aplicativo à entidade de segurança definida.
<ApplicationManifest … >
...
<Principals>
<Users>
<User Name="Service1" AccountType="NetworkService" />
</Users>
</Principals>
<Certificates>
<EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
</Certificates>
</ApplicationManifest>
Criptografar dados de aplicativos em repouso
Cada tipo de nó em um cluster do Service Fabric sendo executado no Azure é respaldado por um conjunto de dimensionamento de máquinas virtuais. Usando um modelo do Azure Resource Manager, é possível anexar discos de dados para os conjuntos de dimensionamento que compõem o cluster do Service Fabric. Se os seus serviços salvarem dados em um disco de dados anexado, você poderá criptografar esses discos de dados para proteger os dados do aplicativo.