Cenários de segurança de cluster do Service Fabric

Artigo
10/15/2024

Um cluster do Azure Service Fabric é um recurso de sua propriedade. É sua responsabilidade proteger seus clusters para ajudar a impedir que usuários não autorizados se conectem a eles. Um cluster seguro é especialmente importante quando você está executando cargas de trabalho de produção no cluster. É possível criar um cluster não seguro, no entanto, se o cluster expõe pontos de extremidade de gerenciamento à Internet pública, os usuários anônimos podem se conectar a ele. Não há suporte para clusters não seguros para cargas de trabalho de produção.

Este artigo é uma visão geral dos cenários de segurança para clusters do Azure e clusters autônomos e as várias tecnologias que você pode usar para implementá-los:

Segurança nó a nó
Segurança cliente-a-nó
Controle de acesso baseado em função do Service Fabric

Segurança nó a nó

A segurança nó a nó ajuda a proteger a comunicação entre as VMs ou computadores em um cluster. Esse cenário de segurança garante que apenas os computadores autorizados a ingressar no cluster possam participar da hospedagem de aplicativos e serviços no cluster.

Diagrama de comunicação nó-a-nó

Os clusters em execução no Azure e os clusters autônomos em execução no Windows podem usar a segurança de certificado ou a segurança do Windows para computadores Windows Server.

Segurança do certificado nó a nó

O Service Fabric usa certificados de servidor X.509 que você especifica como parte da configuração do tipo de nó ao criar um cluster. Você pode configurar a segurança do certificado no portal do Azure, usando um modelo do Azure Resource Manager ou usando um modelo JSON autônomo. No final deste artigo, você pode ver uma breve visão geral do que são esses certificados e como você pode adquiri-los ou criá-los.

O comportamento padrão do SDK do Service Fabric é implantar e instalar o certificado com a data de expiração futura. Esse certificado primário deve ser diferente do cliente administrador e dos certificados de cliente somente leitura que você definiu para segurança de cliente para nó. O comportamento clássico do SDK permitiu a definição de certificados primários e secundários para permitir sobreposições iniciadas manualmente; não é recomendado para uso sobre a nova funcionalidade.

Para saber como configurar a segurança de certificados em um cluster para o Azure, consulte Configurar um cluster usando um modelo do Azure Resource Manager.

Para saber como configurar a segurança de certificados em um cluster para um cluster autônomo do Windows Server, consulte Proteger um cluster autônomo no Windows usando certificados X.509.

Segurança do Windows nó a nó

Nota

A autenticação do Windows é baseada em Kerberos. NTLM não é suportado como um tipo de autenticação.

Sempre que possível, use a autenticação de certificado X.509 para clusters do Service Fabric.

Para saber como configurar a segurança do Windows para um cluster autônomo do Windows Server, consulte Proteger um cluster autônomo no Windows usando a segurança do Windows.

Segurança cliente-a-nó

A segurança de cliente para nó autentica clientes e ajuda a proteger a comunicação entre um cliente e nós individuais no cluster. Esse tipo de segurança ajuda a garantir que apenas usuários autorizados possam acessar o cluster e os aplicativos implantados no cluster. Os clientes são identificados exclusivamente por meio de suas credenciais de segurança do Windows ou de suas credenciais de segurança de certificado.

Diagrama de comunicação cliente-a-nó

Os clusters em execução no Azure e os clusters autônomos em execução no Windows podem usar a segurança de certificado ou a segurança do Windows, embora a recomendação seja usar a autenticação de certificado X.509 sempre que possível.

Segurança de certificado de cliente para nó

Configure a segurança de certificado de cliente para nó ao criar o cluster, seja no portal do Azure, usando um modelo do Gerenciador de Recursos ou usando um modelo JSON autônomo. Para criar o certificado, especifique um certificado de cliente admin ou um certificado de cliente de usuário. Como prática recomendada, os certificados de cliente admin e cliente de usuário especificados devem ser diferentes dos certificados primários e secundários especificados para segurança nó a nó. Os certificados de cluster têm os mesmos direitos que os certificados de administrador do cliente. No entanto, eles devem ser usados apenas por cluster e não por usuários administrativos como uma prática recomendada de segurança.

Os clientes que se conectam ao cluster usando o certificado de administrador têm acesso total aos recursos de gerenciamento. Os clientes que se conectam ao cluster usando o certificado de cliente de usuário somente leitura têm acesso de leitura aos recursos de gerenciamento. Esses certificados são usados para o RBAC do Service Fabric descrito posteriormente neste artigo.

Para saber como configurar a segurança de certificados em um cluster para o Azure, consulte Configurar um cluster usando um modelo do Azure Resource Manager.

Para saber como configurar a segurança de certificados em um cluster para um cluster autônomo do Windows Server, consulte Proteger um cluster autônomo no Windows usando certificados X.509.

Segurança do Microsoft Entra de cliente para nó no Azure

O Microsoft Entra ID permite que organizações (conhecidas como locatários) gerenciem o acesso do usuário aos aplicativos. Os aplicativos são divididos em aqueles com uma interface do usuário de entrada baseada na Web e aqueles com uma experiência de cliente nativa. Se você ainda não criou um locatário, comece lendo Como obter um locatário do Microsoft Entra.

Para clusters em execução no Azure, você também pode usar a ID do Microsoft Entra para proteger o acesso aos pontos de extremidade de gerenciamento. Um cluster do Service Fabric oferece vários pontos de entrada para sua funcionalidade de gerenciamento, incluindo o Service Fabric Explorer baseado na Web e o Visual Studio. Como resultado, para controlar o acesso ao cluster, você cria dois aplicativos Microsoft Entra: um aplicativo Web e um aplicativo nativo. Para saber como criar os artefatos necessários do Microsoft Entra e como preenchê-los ao criar o cluster, consulte Configurar a ID do Microsoft Entra para autenticar clientes.

Recomendações de segurança

Para clusters do Service Fabric implantados em uma rede pública hospedada no Azure, a recomendação para autenticação mútua de cliente para nó é:

Usar o ID do Microsoft Entra para a identidade do cliente
Um certificado para identidade de servidor e criptografia TLS de comunicação http

Para clusters do Service Fabric implantados em uma rede pública hospedada no Azure, a recomendação para segurança nó a nó é usar um certificado de Cluster para autenticar nós.

Para clusters autônomos do Windows Server, se você tiver o Windows Server 2012 R2 e o Windows Ative Directory, recomendamos usar a segurança do Windows com Contas de Serviço Gerenciado de grupo. Caso contrário, use a segurança do Windows com contas do Windows.

Controle de acesso baseado em função do Service Fabric

Você pode usar o controle de acesso para limitar o acesso a determinadas operações de cluster para diferentes grupos de usuários. Isso ajuda a tornar o cluster mais seguro. Dois tipos de controle de acesso são suportados para clientes que se conectam a um cluster: Função de administrador e Função de usuário.

Os usuários aos quais é atribuída a função de Administrador têm acesso total aos recursos de gerenciamento, incluindo recursos de leitura e gravação. Os usuários aos quais é atribuída a função de usuário, por padrão, têm acesso de leitura apenas aos recursos de gerenciamento (por exemplo, recursos de consulta). Eles também podem resolver aplicativos e serviços.

Defina as funções de cliente Administrador e Usuário ao criar o cluster. Atribua funções fornecendo identidades separadas (por exemplo, usando certificados ou ID do Microsoft Entra) para cada tipo de função. Para obter mais informações sobre as configurações de controle de acesso padrão e como alterar as configurações padrão, consulte Controle de acesso baseado em função do Service Fabric para clientes do Service Fabric.

Certificados X.509 e Service Fabric

Os certificados digitais X.509 geralmente são usados para autenticar clientes e servidores. Eles também são usados para criptografar e assinar mensagens digitalmente. O Service Fabric usa certificados X.509 para proteger um cluster e fornecer recursos de segurança de aplicativos. Para obter mais informações sobre certificados digitais X.509, consulte Trabalhando com certificados. Você usa o Cofre da Chave para gerenciar certificados para clusters do Service Fabric no Azure.

Alguns aspetos importantes a considerar:

Para criar certificados para clusters que executam cargas de trabalho de produção, use um serviço de certificados do Windows Server configurado corretamente ou um de uma autoridade de certificação (CA) aprovada.
Nunca use certificados temporários ou de teste criados usando ferramentas como MakeCert.exe em um ambiente de produção.
Você pode usar um certificado autoassinado, mas somente em um cluster de teste. Não use um certificado autoassinado na produção.
Ao gerar a impressão digital do certificado, certifique-se de gerar uma impressão digital SHA1. SHA1 é o que é usado ao configurar as impressões digitais do certificado Cliente e Cluster.

Certificado de cluster e servidor (obrigatório)

Esses certificados (um primário e, opcionalmente, um secundário) são necessários para proteger um cluster e impedir o acesso não autorizado a ele. Esses certificados fornecem autenticação de cluster e servidor.

A autenticação de cluster autentica a comunicação nó a nó para federação de cluster. Somente os nós que podem provar sua identidade com esse certificado podem ingressar no cluster. A autenticação do servidor autentica os pontos de extremidade de gerenciamento de cluster em um cliente de gerenciamento, para que o cliente de gerenciamento saiba que está falando com o cluster real e não com um "homem no meio". Este certificado também fornece um TLS para a API de gerenciamento HTTPS e para o Service Fabric Explorer sobre HTTPS. Quando um cliente ou nó autentica um nó, uma das verificações iniciais é o valor do nome comum no campo Assunto . Esse nome comum ou um dos nomes alternativos de entidade (SANs) dos certificados deve estar presente na lista de nomes comuns permitidos.

O certificado deve satisfazer os seguintes requisitos:

O certificado deve conter uma chave privada. Esses certificados geralmente têm extensões .pfx ou .pem
O certificado deve ser criado para troca de chaves, que é exportável para um arquivo de troca de informações pessoais (.pfx).
O nome do assunto do certificado deve corresponder ao domínio que você usa para acessar o cluster do Service Fabric. Essa correspondência é necessária para fornecer um TLS para o ponto de extremidade de gerenciamento HTTPS do cluster e o Service Fabric Explorer. Não é possível obter um certificado TLS/SSL de uma autoridade de certificação (CA) para o domínio *.cloudapp.azure.com. Tem de obter um nome de domínio personalizado para o cluster. Quando pedir um certificado de uma AC, o nome de requerente do certificado tem de corresponder ao nome do domínio personalizado que utilizar para o cluster.

Algumas outras coisas a considerar:

O campo Assunto pode ter vários valores. Cada valor é prefixado com uma inicialização para indicar o tipo de valor. Normalmente, a inicialização é CN (para nome comum), por exemplo, CN = www.contoso.com.
O campo Assunto pode estar em branco.
Se o campo opcional Nome alternativo da entidade estiver preenchido, ele deverá ter o nome comum do certificado e uma entrada por SAN. Estes são introduzidos como valores de Nome DNS. Para saber como gerar certificados com SANs, consulte Como adicionar um nome alternativo de entidade a um certificado LDAP seguro.
O valor do campo Finalidades pretendidas do certificado deve incluir um valor apropriado, como Autenticação do Servidor ou Autenticação do Cliente.

Certificados de candidatura (opcional)

Qualquer número de certificados adicionais pode ser instalado em um cluster para fins de segurança do aplicativo. Antes de criar seu cluster, considere os cenários de segurança do aplicativo que exigem que um certificado seja instalado nos nós, como:

Encriptação e desencriptação de valores de configuração da aplicação.
Criptografia de dados entre nós durante a replicação.

O conceito de criação de clusters seguros é o mesmo, sejam eles clusters Linux ou Windows.

Certificados de autenticação de cliente (opcional)

Qualquer número de certificados adicionais pode ser especificado para operações de cliente de administrador ou usuário. O cliente pode usar esses certificados quando a autenticação mútua é necessária. Normalmente, os certificados de cliente não são emitidos por uma autoridade de certificação de terceiros. Em vez disso, o armazenamento pessoal do local do usuário atual normalmente contém certificados de cliente colocados lá por uma autoridade raiz. O certificado deve ter um valor de Finalidades Pretendidas de Autenticação de Cliente.

Por padrão, o certificado de cluster tem privilégios de cliente administrador. Esses certificados de cliente adicionais não devem ser instalados no cluster, mas são especificados como sendo permitidos na configuração do cluster. No entanto, os certificados de cliente precisam ser instalados nas máquinas cliente para se conectar ao cluster e executar quaisquer operações.