Partilhar via

X.509 Autenticação baseada em certificado em clusters do Service Fabric

  • Artigo

Este artigo complementa a introdução à segurança de cluster do Service Fabric e aborda os detalhes da autenticação baseada em certificado em clusters do Service Fabric. Supomos que o leitor esteja familiarizado com conceitos fundamentais de segurança e também com os controles que o Service Fabric expõe para controlar a segurança de um cluster.

Tópicos cobertos por este título:

  • Noções básicas de autenticação baseada em certificado
  • Identidades e seus respetivos papéis
  • Regras de configuração do certificado
  • Solução de problemas e perguntas frequentes

Noções básicas de autenticação baseada em certificado

Como uma breve atualização, em segurança, um certificado é um instrumento destinado a vincular informações relativas a uma entidade (o sujeito) à sua posse de um par de chaves criptográficas assimétricas, constituindo assim uma construção central da criptografia de chave pública. As chaves representadas por um certificado podem ser utilizadas para proteger os dados ou para comprovar a identidade dos titulares das chaves; quando usado em conjunto com um sistema PKI (infraestrutura de chave pública), um certificado pode representar características adicionais de seu assunto, como a propriedade de um domínio da Internet ou certos privilégios concedidos a ele pelo emissor do certificado (conhecido como Autoridade de Certificação ou CA). Uma aplicação comum de certificados é o suporte ao protocolo criptográfico Transport Layer Security (TLS), permitindo comunicações seguras através de uma rede de computadores. Especificamente, o cliente e o servidor usam certificados para garantir a privacidade e integridade de sua comunicação, e também para realizar autenticação mútua.

No Service Fabric, a camada fundamental de um cluster (Federação) também se baseia no TLS (entre outros protocolos) para obter uma rede confiável e segura de nós participantes. As conexões com o cluster por meio das APIs do Service Fabric Client também usam TLS para proteger o tráfego e também para estabelecer as identidades das partes. Especificamente, quando utilizado para a autenticação no Service Fabric, um certificado pode ser utilizado para comprovar as seguintes afirmações: a) o apresentador da credencial do certificado possui a chave privada do certificado b) o hash SHA-1 do certificado (“thumbprint”) corresponde a uma declaração incluída na definição do cluster ou c) o Nome Comum único do Requerente do certificado corresponde a uma declaração incluída na definição do cluster e o emissor do certificado é conhecido ou fidedigno.

Na lista acima, “b” é coloquialmente conhecido como “afixação de thumbprint”; neste caso, a declaração refere-se a um certificado específico e a força do esquema de autenticação baseia-se na premissa de que é computacionalmente inviável falsificar um certificado que produza o mesmo valor de hash que outro certificado, sendo ainda um objeto corretamente formado e válido em todos os outros aspetos. A alínea c) representa uma forma alternativa de declaração de um certificado, em que a solidez do sistema assenta na combinação do objeto do certificado com a autoridade emissora. Neste caso, a declaração refere-se a uma classe de certificados - quaisquer dois certificados com as mesmas características são considerados totalmente equivalentes.

As seções a seguir explicarão detalhadamente como o tempo de execução do Service Fabric usa e valida certificados para garantir a segurança do cluster.

Identidades e seus respetivos papéis

Antes de mergulhar nos detalhes da autenticação ou da segurança dos canais de comunicação, é importante listar os atores participantes e os papéis correspondentes que desempenham em um cluster:

  • o tempo de execução do Service Fabric, referido como «sistema»: o conjunto de serviços que fornecem as abstrações e a funcionalidade que representam o cluster. Ao nos referirmos à comunicação em cluster entre instâncias do sistema, usaremos o termo "identidade do cluster"; Ao nos referirmos ao cluster como destinatário/destino do tráfego de fora do cluster, usaremos o termo 'identidade do servidor'.
  • Aplicativos hospedados, referidos como 'aplicativos': código fornecido pelo proprietário do cluster, que é orquestrado e executado no cluster
  • Clientes: entidades com permissão para se conectar e executar funcionalidades em um cluster, de acordo com a configuração do cluster. Distinguimos entre dois níveis de privilégios - 'utilizador' e 'administrador', respetivamente. Um cliente 'usuário' é restrito principalmente a operações somente leitura (mas não a todas as funcionalidades somente leitura), enquanto um cliente 'admin' tem acesso irrestrito à funcionalidade do cluster. (Para obter mais detalhes, consulte Funções de segurança em um cluster do Service Fabric.)
  • (somente Azure) os serviços do Service Fabric que orquestram e expõem controles para operação e gerenciamento de clusters do Service Fabric, referidos simplesmente como "serviço". Dependendo do ambiente, o 'serviço' pode se referir ao Provedor de Recursos do Azure Service Fabric ou a outros Provedores de Recursos de propriedade e operados pela equipe do Service Fabric.

Em um cluster seguro, cada uma dessas funções pode ser configurada com sua própria identidade distinta, declarada como o emparelhamento de um nome de função predefinido e sua credencial correspondente. O Service Fabric oferece suporte à declaração de credenciais como certificados ou entidade de serviço baseada em domínio. (As identidades baseadas em Windows/Kerberos também são suportadas, mas estão além do escopo deste artigo; consulte Segurança baseada no Windows em clusters do Service Fabric.) Nos clusters do Azure, as funções de cliente também podem ser declaradas como identidades baseadas em ID do Microsoft Entra.

Como mencionado acima, o tempo de execução do Service Fabric define dois níveis de privilégio em um cluster: 'admin' e 'user'. Um cliente administrador e um componente "sistema" operariam com privilégios de "administrador" e, portanto, são indistinguíveis um do outro. Ao estabelecer uma conexão no/para o cluster, um chamador autenticado receberá do tempo de execução do Service Fabric uma das duas funções como base para a autorização subsequente. Examinaremos a autenticação em profundidade nas seções a seguir.

Regras de configuração do certificado

Regras de validação

As configurações de segurança de um cluster do Service Fabric descrevem, em princípio, os seguintes aspetos:

  • o tipo de autenticação; Esta é uma característica imutável do cluster no tempo de criação. Exemplos de tais configurações são 'ClusterCredentialType', 'ServerCredentialType', e os valores permitidos são 'none', 'x509' ou 'windows'. Este artigo se concentra na autenticação do tipo x509.
  • as regras de validação (de autenticação); Essas configurações são definidas pelo proprietário do cluster e descrevem quais credenciais devem ser aceitas para uma determinada função. Os exemplos serão examinados em profundidade imediatamente a seguir.
  • configurações usadas para ajustar ou alterar sutilmente o resultado da autenticação; Os exemplos aqui incluem sinalizadores que restringem ou não restringem a aplicação de listas de revogação de certificados, etc.

Nota

Os exemplos de configuração de cluster fornecidos abaixo são trechos do manifesto do cluster em formato XML, como o formato mais digerido que suporta diretamente a funcionalidade do Service Fabric descrita neste artigo. As mesmas configurações podem ser expressas diretamente nas representações JSON de uma definição de cluster, seja um manifesto de cluster json autônomo ou um modelo de Gerenciamento de Recursos do Azure.

Uma regra de validação de certificado compreende os seguintes elementos:

  • A função correspondente: cliente, cliente administrador (função privilegiada)
  • a credencial aceita para a função, declarada por impressão digital ou nome comum do assunto

Declarações de validação de certificado baseadas em impressão digital

No caso de regras de validação baseadas em impressão digital, as credenciais apresentadas por um chamador solicitando uma conexão no/para o cluster serão validadas da seguinte forma:

  • A credencial é um certificado válido e bem formado: sua cadeia pode ser construída, as assinaturas correspondem
  • o certificado é válido por tempo (NotBefore <= agora < NotAfter)
  • o hash SHA-1 do certificado corresponde à declaração, como uma comparação de cadeia de carateres não sensível a maiúsculas e minúsculas, excluindo todos os espaços em branco

Quaisquer erros de confiança encontrados durante a construção ou validação da cadeia serão suprimidos para declarações baseadas em impressão digital, exceto para certificados expirados - embora existam disposições para esse caso também. Especificamente, falhas relacionadas a: status de revogação ser desconhecido ou offline, raiz não confiável, uso de chave inválido, cadeia parcial são considerados erros não fatais; A premissa, neste caso, é que o certificado é meramente um envelope para um par de chaves - a segurança reside no fato de que o proprietário do cluster definiu em locais medida para proteger a chave privada.

O seguinte trecho de um manifesto de cluster exemplifica esse conjunto de regras de validação baseadas em impressão digital:

<Section Name="Security">
  <Parameter Name="ClusterCredentialType" Value="X509" />
  <Parameter Name="ServerAuthCredentialType" Value="X509" />
  <Parameter Name="AdminClientCertThumbprints" Value="d5ec...4264" />
  <Parameter Name="ClientCertThumbprints" Value="7c8f...01b0" />
  <Parameter Name="ClusterCertThumbprints" Value="abcd...1234,ef01...5678" />
  <Parameter Name="ServerCertThumbprints" Value="ef01...5678" />
</Section>

Cada uma das entradas acima refere-se a uma identidade específica, conforme descrito anteriormente; Cada entrada também permite especificar vários valores, como uma lista de cadeias de caracteres separadas por vírgula. Neste exemplo, ao validar com êxito as credenciais de entrada, o apresentador de um certificado com a impressão digital SHA-1 'd5ec... 4264' receberá a função de "administrador"; Por outro lado, um chamador autenticando com o certificado '7C8F... 01b0' receberá uma função de 'usuário', restrita principalmente a operações somente leitura. Um chamador de entrada que apresenta um certificado cuja impressão digital é 'abcd... 1234» ou «ef01... 5678' será aceito como um nó de mesmo nível no cluster. Por fim, um cliente que se conecta a um ponto de extremidade de gerenciamento do cluster esperará que a impressão digital do certificado do servidor seja 'ef01... 5678'.

Como mencionado anteriormente, o Service Fabric faz provisões para aceitar certificados expirados; O motivo é que os certificados têm um tempo de vida limitado e, quando declarados por impressão digital (que se refere a uma instância de certificado específica), permitir que um certificado expire resultará em falha na conexão com o cluster ou em um colapso total do cluster. É muito fácil esquecer ou negligenciar a rotação de um certificado fixado em impressão digital e, infelizmente, a recuperação de tal situação é difícil.

Para esse fim, o proprietário do cluster pode declarar explicitamente que os certificados autoassinados declarados por impressão digital serão considerados válidos, da seguinte forma:

  <Section Name="Security">
    <Parameter Name="AcceptExpiredPinnedClusterCertificate" Value="true" />
  </Section>

Esse comportamento não se estende a certificados emitidos por CA; se fosse esse o caso, um certificado expirado revogado e conhecido por estar comprometido poderia tornar-se «válido» assim que deixasse de figurar na lista de revogação de certificados da AC e, por conseguinte, representaria um risco de segurança. Com certificados autoassinados, o proprietário do cluster é considerado a única parte responsável por proteger a chave privada do certificado, o que não é o caso dos certificados emitidos pela CA - o proprietário do cluster pode não saber como ou quando seu certificado foi declarado comprometido.

Declarações comuns de validação de certificados com base no nome

As declarações comuns baseadas no nome assumem uma das seguintes formas:

  • Nome comum do assunto (apenas)
  • Nome comum do assunto com fixação do emissor

Vamos primeiro considerar um trecho de um manifesto de cluster exemplificando ambos os estilos de declaração:

    <Section Name="Security/ServerX509Names">
      <Parameter Name="server.demo.system.servicefabric.azure-int" Value="" />
    </Section>
    <Section Name="Security/ClusterX509Names">
      <Parameter Name="cluster.demo.system.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

As declarações referem-se às identidades de servidor e cluster, respectivamente; observe que as declarações baseadas em NC têm suas próprias seções no manifesto do cluster, separadas do padrão 'Segurança'. Em ambas as declarações, o «Nome» representa o nome comum do sujeito distinto do certificado e o campo «Valor» representa o emitente esperado, da seguinte forma:

  • No primeiro caso, a declaração afirma que o elemento Common Name do assunto distinto do certificado do servidor deve corresponder à cadeia de caracteres "server.demo.system.servicefabric.azure-int"; o campo vazio 'Valor' indica a expectativa de que a raiz da cadeia de certificados é confiável no nó/máquina onde o certificado do servidor está sendo validado; no Windows, isso significa que o certificado pode ser encadeado até qualquer um dos certificados instalados no armazenamento 'CA raiz confiável';
  • no segundo caso, a declaração indica que o apresentador de um certificado é aceito como um nó de mesmo nível no cluster se o nome comum do certificado corresponder à cadeia de caracteres "cluster.demo.system.servicefabric.azure-int", e a impressão digital do emissor direto do certificado corresponder a uma das entradas separadas por vírgulas no campo 'Valor'. (Este tipo de regra é coloquialmente conhecido como "nome comum com fixação do emissor".)

Em ambos os casos, a cadeia do certificado é construída e espera-se que esteja livre de erros; ou seja, erros de revogação, cadeia parcial ou erros de confiança inválidos por tempo são considerados fatais e a validação do certificado falhará. Fixar os emissores resultará em considerar o status de 'raiz não confiável' como um erro não fatal; apesar das aparências, essa é uma forma mais rigorosa de validação, pois permite que o proprietário do cluster restrinja o conjunto de emissores autorizados/aceitos à sua própria PKI.

Depois que a cadeia de certificados é construída, ela é validada em relação a uma política TLS/SSL padrão com o assunto declarado como o nome remoto; um certificado será considerado uma correspondência se o nome comum da entidade ou qualquer um dos nomes alternativos da entidade corresponder à declaração CN do manifesto do cluster. Neste caso, há suporte para curingas e a correspondência de cadeia de caracteres não diferencia maiúsculas de minúsculas.

(Devemos esclarecer que a sequência descrita acima pode ser executada para cada tipo de uso de chave declarado pelo certificado; se o certificado especificar o uso da chave de autenticação do cliente, a cadeia será construída e avaliada primeiro para uma função de cliente. Em caso de sucesso, a avaliação é concluída e a validação é bem-sucedida. Se o certificado não tiver o uso da autenticação do cliente ou se a validação falhar, o tempo de execução do Service Fabric criará e avaliará a cadeia para autenticação do servidor.)

Para completar o exemplo, o trecho a seguir ilustra a declaração de certificados de cliente por nome comum:

    <Section Name="Security/AdminClientX509Names">
      <Parameter Name="admin.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>
    <Section Name="Security/ClientX509Names">
      <Parameter Name="user.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

As declarações acima correspondem às identidades de administrador e usuário, respectivamente; A validação de certificados declarados dessa maneira é exatamente como descrito para os exemplos anteriores, de certificados de cluster e servidor.

Nota

As declarações comuns baseadas em nome destinam-se a simplificar a rotação e, em geral, o gerenciamento de certificados de cluster. No entanto, recomenda-se aderir às seguintes recomendações para garantir a disponibilidade contínua e a segurança do cluster:

  • prefira a fixação do emissor a confiar em raízes confiáveis
  • evite misturar emissores de diferentes PKIs
  • assegurar que todos os emitentes previstos constam da lista da declaração de certificado; Um emissor incompatível resultará em uma validação com falha
  • garantir que os pontos de extremidade da política de certificado da PKI sejam detetáveis, disponíveis e acessíveis - isso significa que os pontos de extremidade AIA, CRL ou OCSP são declarados no certificado folha e que estão acessíveis para que a construção da cadeia de certificados possa ser concluída.

Vinculando tudo isso, ao receber uma solicitação de conexão em um cluster protegido com certificados X.509, o tempo de execução do Service Fabric usará as configurações de segurança do cluster para validar as credenciais da parte remota, conforme descrito acima; Se for bem-sucedido, o chamador/parte remota é considerado autenticado. Se a credencial corresponder a várias regras de validação, o tempo de execução concederá ao chamador a função mais privilegiada de qualquer uma das regras correspondentes.

Regras de apresentação

A seção anterior descreveu como a autenticação funciona em um cluster protegido por certificado; esta seção explicará como o próprio tempo de execução do Service Fabric descobre e carrega os certificados que usa para comunicação em cluster; chamamos a estas regras de "apresentação".

Tal como acontece com as regras de validação, as regras de apresentação especificam uma função e a declaração de credenciais associada, expressa por impressão digital ou nome comum. Ao contrário das regras de validação, as declarações comuns baseadas no nome não têm disposições para a fixação do emitente; Isso permite maior flexibilidade, bem como melhor desempenho. As regras de apresentação são declaradas na(s) seção(ões) 'NodeType' do manifesto do cluster, para cada tipo de nó distinto; as configurações são divididas das seções Segurança do cluster para permitir que cada tipo de nó tenha sua configuração completa em uma única seção. Nos clusters do Azure Service Fabric, as declarações de certificado do tipo de nó usam como padrão suas configurações correspondentes na seção Segurança da definição do cluster.

Declarações de apresentação de certificado baseadas em impressão digital

Conforme descrito anteriormente, o tempo de execução do Service Fabric distingue entre sua função como o par de outros nós no cluster e como o servidor para operações de gerenciamento de cluster. Em princípio, essas configurações podem ser configuradas distintamente, mas na prática tendem a se alinhar. Para o restante deste artigo, assumiremos que as configurações correspondem à simplicidade.

Vamos considerar o seguinte trecho de um manifesto de cluster:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindByThumbprint" X509FindValue="cc71...1984" X509FindValueSecondary="49e2...19d6" X509StoreName="my" Name="ClusterCertificate" />
        <ServerCertificate X509FindValue="cc71...1984" Name="ServerCertificate" />
        <ClientCertificate X509FindValue="cc71...1984" Name="ClientCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

O elemento 'ClusterCertificate' demonstra o esquema completo, incluindo parâmetros opcionais ('X509FindValueSecondary') ou aqueles com padrões apropriados ('X509StoreName'); as outras declarações apresentam uma forma abreviada. A declaração de certificado de cluster acima afirma que as configurações de segurança dos nós do tipo 'nt1vm' são inicializadas com o certificado 'cc71.. 1984' como primária, e o '49e2.. 19d6' certificado como secundário; espera-se que ambos os certificados sejam encontrados no armazenamento de certificados LocalMachine'My' (ou no caminho equivalente do Linux, var/lib/sfcerts).

Declarações comuns de apresentação de certificados com base no nome

Os certificados de tipo de nó também podem ser declarados pelo nome comum do assunto, conforme exemplificado abaixo:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindBySubjectName" X509FindValue="demo.cluster.azuredocpr.system.servicefabric.azure-int" Name="ClusterCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

Para qualquer tipo de declaração, um nó do Service Fabric lerá a configuração na inicialização, localizará e carregará os certificados especificados e os classificará em ordem decrescente de seu atributo NotBefore; os certificados expirados são ignorados e o primeiro elemento da lista é selecionado como a credencial do cliente para qualquer conexão do Service Fabric tentada por esse nó. (Na verdade, o Service Fabric favorece o certificado emitido mais recentemente.)

Nota

Antes da versão 7.2.445 (7.2 CU4), o Service Fabric selecionava o certificado de expiração mais distante (o certificado com a propriedade 'NotAfter' mais distante)

Observe que, para declarações de apresentação baseadas em nome comum, um certificado é considerado uma correspondência se seu nome comum de assunto for igual ao campo X509FindValue (ou X509FindValueSecondary) da declaração como uma comparação exata de cadeia de caracteres que diferencia maiúsculas de minúsculas. Isso contrasta com as regras de validação, que oferecem suporte à correspondência de curingas, bem como comparações de cadeia de caracteres que não diferenciam maiúsculas de minúsculas.

Definições de configuração de certificados diversos

Foi mencionado anteriormente que as configurações de segurança de um cluster do Service Fabric também permitem alterar sutilmente o comportamento do código de autenticação. Embora o artigo sobre configurações de cluster do Service Fabric represente a lista abrangente e mais atualizada de configurações, expandiremos o significado de algumas das configurações de segurança aqui, para concluir a exposição completa sobre a autenticação baseada em certificado. Para cada configuração, explicaremos a intenção, o valor/comportamento padrão, como isso afeta a autenticação e quais valores são aceitáveis.

Como mencionado, a validação do certificado implica sempre a construção e avaliação da cadeia do certificado. Para certificados emitidos por CA, essa chamada de API do sistema operacional aparentemente simples normalmente envolve várias chamadas de saída para vários pontos de extremidade da PKI emissora, cache de respostas e assim por diante. Dada a prevalência de chamadas de validação de certificado em um cluster do Service Fabric, quaisquer problemas nos pontos de extremidade da PKI podem resultar em disponibilidade reduzida do cluster ou quebra total. Embora as chamadas de saída não possam ser suprimidas (veja abaixo na seção Perguntas frequentes para saber mais sobre isso), as configurações a seguir podem ser usadas para mascarar erros de validação causados por chamadas de CRL com falha.

  • CrlCheckingFlag - na seção "Segurança", string convertida para UINT. O valor dessa configuração é usado pelo Service Fabric para mascarar erros de status da cadeia de certificados alterando o comportamento da construção da cadeia; ele é passado para a chamada Win32 CryptoAPI CertGetCertificateChain como o parâmetro 'dwFlags' e pode ser definido para qualquer combinação válida de sinalizadores aceitos pela função. Um valor de 0 força o tempo de execução do Service Fabric a ignorar quaisquer erros de status de confiança - isso não é recomendado, pois seu uso constituiria uma exposição de segurança significativa. O valor padrão é 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT).

Quando usar: para testes locais, com certificados autoassinados ou certificados de desenvolvedor que não estão totalmente formados/não têm uma infraestrutura de chave pública adequada para dar suporte aos certificados. Também pode ser usado como atenuação em ambientes com ar comprimido durante a transição entre PKIs.

Como usar: vamos pegar um exemplo que força a verificação de revogação para acessar apenas URLs armazenados em cache. Assumindo:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

Em seguida, a declaração no manifesto do cluster torna-se:

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError - na seção "Security", booleano com um valor padrão de 'false'. Representa um atalho para suprimir um status de erro de construção de cadeia 'revogação offline' (ou um status de erro de validação de política de cadeia subsequente).

Quando usar: teste local ou com certificados de desenvolvedor não apoiados por uma PKI adequada. Use como atenuação em ambientes com ar comprimido ou quando a PKI é conhecida por ser inacessível.

Modo de utilização:

  <Section Name="Security">
    <Parameter Name="IgnoreCrlOfflineError" Value="true" />
  </Section>

Outras configurações notáveis (todas na seção "Segurança"):

  • AcceptExpiredPinnedClusterCertificate - discutido na seção dedicada à validação de certificado baseada em impressão digital; Permite aceitar certificados de cluster autoassinados expirados.
  • CertificateExpirySafetyMargin - intervalo, expresso em minutos antes do carimbo de data/hora NotAfter do certificado, e durante o qual o certificado é considerado em risco de expiração. O Service Fabric monitora o(s) certificado(s) de cluster e emite periodicamente relatórios de integridade sobre sua disponibilidade restante. Dentro do intervalo de "segurança", estes relatórios de saúde são elevados ao estatuto de "aviso". O padrão é 30 dias.
  • CertificateHealthReportingInterval - controla a frequência dos relatórios de integridade relativos à validade do tempo restante dos certificados de cluster. Os relatórios só serão emitidos uma vez por este intervalo. O valor é expresso em segundos, com um padrão de 8 horas.
  • EnforcePrevalidationOnSecurityChanges - booleano, controla o comportamento da atualização do cluster ao detetar alterações nas configurações de segurança. Se definido como 'true', a atualização do cluster tentará garantir que pelo menos um dos certificados correspondentes a qualquer uma das regras de apresentação possa passar por uma regra de validação correspondente. A pré-validação é executada antes que as novas configurações sejam aplicadas a qualquer nó, mas é executada somente no nó que hospeda a réplica primária do serviço Gerenciador de Cluster no momento do início da atualização. No momento em que este artigo foi escrito, a configuração tem um padrão de 'false' e será definida como 'true' para novos clusters do Azure Service Fabric com uma versão de tempo de execução começando com 7.1.

Cenário de ponta a ponta (exemplos)

Analisámos as regras de apresentação, as regras de validação e os sinalizadores de ajustes, mas como é que tudo isto funciona em conjunto? Nesta seção, trabalharemos em dois exemplos completos demonstrando como as configurações de segurança podem ser aproveitadas para atualizações seguras de cluster. Observe que esta não pretende ser uma dissertação abrangente sobre o gerenciamento adequado de certificados no Service Fabric, procure um artigo complementar sobre esse tópico.

A separação entre as regras de apresentação e validação coloca a questão óbvia (ou preocupação) de saber se podem divergir e quais seriam as consequências. É, de fato, possível que a seleção de um certificado de autenticação por um nó não passe pelas regras de validação de outro nó. Na verdade, essa discrepância é a principal causa de incidentes relacionados à autenticação. Ao mesmo tempo, a separação dessas regras permite que um cluster continue operando durante uma atualização que altera as configurações de segurança do cluster. Considere que, aumentando primeiro as regras de validação como uma primeira etapa, todos os nós do cluster convergirão para as novas configurações enquanto ainda usam as credenciais atuais.

Lembre-se de que, em um cluster do Service Fabric, uma atualização progride através de (até 5) 'domínios de atualização', ou UDs. Somente nós na UD atual estão sendo atualizados/alterados em um determinado momento, e a atualização prosseguirá para a próxima UD somente se a disponibilidade do cluster permitir. (Consulte Atualizações de cluster do Service Fabric e outros artigos sobre o mesmo tópico para obter mais detalhes.) As alterações de certificado/segurança são particularmente arriscadas, pois podem isolar nós do cluster ou deixar o cluster à beira da perda de quórum.

Usaremos a seguinte notação para descrever as configurações de segurança de um nó:

Nk: {P:{TP=A}, V:{TP=A}}, onde:

  • 'Nk' representa um nó no domínio de atualização k
  • 'P' representa as regras de apresentação atuais do nó (assumindo que estamos nos referindo apenas a certificados de cluster);
  • 'V' representa as regras de validação atuais do nó (somente certificado de cluster)
  • «TP=A» representa uma declaração baseada em impressão digital (TP), sendo «A» uma impressão digital de certificado
  • «CN=B» representa uma declaração baseada no nome comum (NC), sendo «B» o nome comum do objeto do certificado

Rotação de um certificado de cluster declarado por impressão digital

A sequência a seguir descreve como uma atualização de 2 estágios pode ser usada para introduzir com segurança um certificado de cluster secundário, declarado por impressão digital; A primeira fase introduz a nova declaração de certificado nas regras de validação e a segunda fase introduz-a nas regras de apresentação:

  • estado inicial: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} - o cluster está em repouso, todos os nós compartilham uma configuração comum
  • ao concluir o domínio de atualização 0: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} - os nós em UD0 apresentarão o certificado A e aceitarão os certificados A ou B; todos os outros nós presentes e aceitam apenas o certificado A
  • ao concluir o último domínio de atualização: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} - todos os nós apresentam o certificado A, todos os nós aceitariam o certificado A ou B

Neste ponto, o cluster está novamente em equilíbrio, e a segunda fase da atualização/alteração das configurações de segurança pode começar:

  • ao concluir o domínio de atualização 0: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} - os nós em UD0 começarão a apresentar B, que é aceito por qualquer outro nó no cluster.
  • ao completar o último domínio de atualização: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A, TP=B}, V:{TP=A, TP=B}} - todos os nós mudaram para apresentar o certificado B. O certificado A agora pode ser retirado/removido da definição de cluster com um conjunto subsequente de atualizações.

Convertendo um cluster de impressões digitais para declarações de certificado baseadas em nome comum

Da mesma forma, alterar o tipo de declaração de certificado (de impressão digital para nome comum) seguirá o mesmo padrão acima. Observe que as regras de validação permitem declarar os certificados de uma determinada função por impressão digital e nome comum na mesma definição de cluster. Em contrapartida, porém, as regras de apresentação permitem apenas uma forma de declaração. Aliás, a abordagem segura para converter um certificado de cluster de impressão digital para nome comum é introduzir o certificado de destino pretendido primeiro por impressão digital e, em seguida, alterar essa declaração para uma declaração baseada em nome comum. No exemplo a seguir, assumiremos que a impressão digital 'A' e o nome comum do assunto 'B' se referem ao mesmo certificado.

  • estado inicial: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} - o cluster está em repouso, todos os nós compartilham uma configuração comum, com A sendo a impressão digital do certificado primário
  • ao concluir o domínio de atualização 0: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} - os nós em UD0 apresentarão o certificado A e aceitarão certificados com impressão digital A ou nome comum B; todos os outros nós presentes e aceitam apenas o certificado A
  • ao concluir o último domínio de atualização: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} - todos os nós apresentam o certificado A, todos os nós aceitariam o certificado A (TP) ou B (CN)

Neste ponto, podemos prosseguir com a alteração das regras de apresentação com uma atualização subsequente:

  • ao concluir o domínio de atualização 0: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} - os nós em UD0 apresentarão o certificado B encontrado pela CN e aceitarão certificados com impressão digital A ou nome comum B; todos os outros nós presentes e aceitam apenas o certificado A, selecionado por impressão digital
  • ao completar o último domínio de atualização: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{CN=B}, V:{TP=A, CN=B}} - todos os nós apresentam o certificado B encontrado pela CN, todos os nós aceitariam o certificado A (TP) ou B (CN)

A conclusão da fase 2 também marca a conversão do cluster em certificados comuns baseados em nomes; As declarações de validação baseadas em impressão digital podem ser removidas em uma atualização de cluster subsequente.

Nota

Nos clusters do Azure Service Fabric, os fluxos de trabalho apresentados acima são orquestrados pelo Provedor de Recursos do Service Fabric; O proprietário do cluster ainda é responsável pelo provisionamento de certificados no cluster de acordo com as regras indicadas (apresentação ou validação) e é incentivado a executar alterações em várias etapas.

Em um artigo separado, abordaremos o tópico de gerenciamento e provisionamento de certificados em um cluster do Service Fabric.

Solução de problemas e perguntas frequentes

Embora depurar problemas relacionados à autenticação em clusters do Service Fabric não seja fácil, esperamos que as dicas a seguir possam ajudar. A maneira mais fácil de iniciar investigações é examinar os logs de eventos do Service Fabric nos nós do cluster - não necessariamente aqueles que apresentam sintomas, mas também os nós que estão ativos, mas não conseguem se conectar a um de seus vizinhos. No Windows, os eventos significativos geralmente são registrados nos canais 'Logs de Aplicativos e Serviços\Microsoft-ServiceFabric\Admin' ou 'Operacional', respectivamente. Às vezes, pode ser útil habilitar o registro CAPI2, para capturar mais detalhes sobre a validação do certificado, recuperação de CRL / CTL etc. (Lembre-se de desativá-lo depois de concluir a reprodução, pode ser bastante detalhado.)

Os sintomas típicos que se manifestam em um cluster com problemas de autenticação são:

  • os nós estão inativos/em ciclo
  • As tentativas de conexão são rejeitadas
  • As tentativas de conexão estão expirando

Cada um dos sintomas pode ser causado por problemas diferentes, e a mesma causa raiz pode mostrar manifestações diferentes; Como tal, vamos apenas listar uma pequena amostra de problemas típicos, com recomendações para corrigi-los.

  • Os nós podem trocar mensagens, mas não podem se conectar. Uma possível causa para as tentativas de conexão serem encerradas é o erro 'certificado não correspondido' - uma das partes em uma conexão do Service Fabric-to-Service Fabric está apresentando um certificado que falha nas regras de validação do destinatário. Pode ser acompanhado por um dos seguintes erros:

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

    Para diagnosticar/investigar mais: em cada um dos nós que tentam a conexão, determine qual certificado está sendo apresentado; Examine o certificado e tente emular as regras de validação (verifique se há impressão digital ou igualdade de nome comum, verifique as impressões digitais do emissor, se especificado).

    Outro código de erro comum que acompanha pode ser:

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    Neste caso, o certificado é declarado por nome comum, aplicando-se uma das seguintes situações:

    • os emissores não são fixados e o certificado raiz não é confiável, ou
    • Os emitentes estão fixados, mas a declaração não inclui a impressão digital do emissor direto do presente certificado

  • Um nó está ativo, mas não pode se conectar a outros nós; outros nós não recebem tráfego de entrada do nó com falha. Nesse caso, é possível que o carregamento do certificado falhe no nó local. Procure os seguintes erros:

    • certificado não encontrado - certifique-se de que os certificados declarados nas regras de apresentação possam ser resolvidos pelo conteúdo do armazenamento de certificados LocalMachine\My (ou conforme especificado). As possíveis causas de falha podem incluir:

      • Caracteres inválidos na declaração de impressão digital
      • O certificado não está instalado
      • O certificado expirou
      • a declaração de nome comum inclui o prefixo «CN=»
      • a declaração especifica um curinga e não existe uma correspondência exata no armazenamento de certificados (declaração: CN=*.mydomain.com, certificado real: CN=server.mydomain.com)

    • Credenciais desconhecidas - indica uma chave privada ausente correspondente ao certificado, normalmente acompanhada de código de erro:

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Para remediar, verifique a existência da chave privada; verifique se o SFAdmins recebeu acesso 'read|execute' à chave privada.

    • tipo de provedor incorreto - indica um certificado Crypto New Generation (CNG) ("Microsoft Software Key Storage Provider"); no momento, o Service Fabric suporta apenas certificados CAPI1. Normalmente acompanhado por código de erro:

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      Para remediar, recrie o certificado de cluster usando um provedor CAPI1 (por exemplo, "Microsoft Enhanced RSA and AES Cryptographic Provider"). Para obter mais detalhes sobre provedores de criptografia, consulte Noções básicas sobre provedores criptográficos