Compartilhar via

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

  • Artigo

Este artigo complementa a introdução à segurança de cluster do Service Fabric e apresenta os detalhes da autenticação baseada em certificado nos clusters do Service Fabric. Consideramos que o leitor está familiarizado com os conceitos fundamentais de segurança e com os controles que o Service Fabric expõe para controlar a segurança de um cluster.

Tópicos cobertos por este artigo:

  • Noções básicas de autenticação baseada em certificado
  • As identidades e suas respectivas funções
  • Regras de configuração de 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 em relação a uma entidade (a entidade) e à sua posse de um par de chaves criptográficas assimétricas e, portanto, constitui um constructo principal da criptografia de chave pública. As chaves representadas por um certificado podem ser usadas para proteger dados ou para comprovar a identidade de titulares principais. Quando usado em conjunto com um sistema de PKI (Infraestrutura de Chave Pública), um certificado pode representar características adicionais da sua entidade, como a propriedade de um domínio da internet ou determinados privilégios concedidos pelo emissor do certificado (conhecido como Autoridade de Certificação ou AC). Um aplicativo comum de certificados é o suporte ao protocolo criptográfico TLS (Transport Layer Security), permitindo comunicações seguras em uma rede de computador. Especificamente, o cliente e o servidor usam certificados para garantir a privacidade e a integridade da comunicação deles e para conduzir a autenticação mútua.

No Service Fabric, a camada fundamental de um cluster (Federação) também é compilada em TLS (entre outros protocolos) para alcançar uma rede confiável e segura de nós participantes. As conexões no cluster por meio das APIs de cliente do Service Fabric também usam o protocolo TLS para proteger o tráfego e para estabelecer as identidades das partes. Especificamente, quando usado para autenticação no Service Fabric, um certificado pode ser usado para comprovar as seguintes declarações: a) o apresentador da credencial de certificado tem a posse da chave privada do certificado, b) o hash SHA-1 do certificado ('impressão digital') corresponde a uma declaração incluída na definição de cluster ou c) o Nome Comum de Entidade diferenciado do certificado corresponde a uma declaração incluída na definição do cluster e o emissor do certificado é conhecido ou confiável.

Na lista acima, 'b' geralmente é conhecido como "fixação de impressão digital"; nesse caso, a declaração se refere a um certificado específico e a força do esquema de autenticação se refere à premissa de que é inviável forjar por meio de computação um certificado que produz o mesmo valor de hash que outro, enquanto ainda é um objeto válido e bem formado em todos os outros aspectos. O item 'c' representa uma forma alternativa de declarar um certificado, na qual a força do esquema se baseia na combinação da entidade do certificado e da autoridade de emissão. Nesse caso, a declaração se refere a uma classe de certificados. Dois certificados com as mesmas características são considerados totalmente equivalentes.

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

As identidades e suas respectivas funções

Antes de mergulhar nos detalhes da autenticação ou proteger canais de comunicação, é importante listar os atores participantes e as funções correspondentes que eles desempenham em um cluster:

  • o runtime do Service Fabric, conhecido como "sistema": o conjunto de serviços que fornece as abstrações e funcionalidades representando o cluster. Ao fazer referência à comunicação no cluster entre instâncias do sistema, vamos usar o termo "identidade de cluster". Ao se referir ao cluster como o destinatário/destino do tráfego de fora do cluster, vamos usar o termo "identidade do servidor".
  • aplicativos hospedados, chamados de "aplicativos": código fornecido pelo proprietário do cluster, que é orquestrado e executado no cluster
  • clientes: entidades autorizadas a se conectar e executar a funcionalidade em um cluster, de acordo com a configuração do cluster. Distinguiremos entre dois níveis de privilégios, de "usuário" e "administrador", respectivamente. Um cliente “usuário” é restrito basicamente a operações somente leitura (mas nem todas as funcionalidades somente leitura), enquanto um cliente “administrador” 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 a operação e o gerenciamento dos clusters do Service Fabric, chamados simplesmente de "serviço". Dependendo do ambiente, esse serviço pode se referir ao Provedor de Recursos do Azure Service Fabric ou a outros Provedores de Recursos pertencentes 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 dá suporte à declaração de credenciais como certificados ou entidade de serviço baseada em domínio. (Identidades baseadas em Windows/Kerberos também são suportadas, mas estão fora do escopo deste artigo. Consulte Segurança baseada em Windows de clusters do Service Fabric.) As funções de cliente também podem ser declaradas em clusters do Azure como Identidades baseadas no Microsoft Entra ID.

Como mencionado acima, o runtime do Service Fabric define dois níveis de privilégio em um cluster: “administrador” e “usuário”. Um cliente de administrador e um componente do "sistema" operariam com privilégios de "administrador", e, portanto, eles são indistintos um do outro. Ao estabelecer uma conexão no/para o cluster, um chamador autenticado será concedido por uma das duas funções do runtime do Service Fabric como base para a autorização subsequente. Nas seções a seguir revisaremos a autenticação detalhadamente.

Regras de configuração de certificado

Regras de validação

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

  • o tipo de autenticação: essa é uma característica imutável e de tempo de criação do cluster. Exemplos dessas 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 (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 revisados em detalhes imediatamente abaixo.
  • configurações usadas para ajustar ou alterar sutilmente o resultado da autenticação; os exemplos aqui incluem sinalizadores para restringir ou cancelar a restrição da imposição de listas de revogação de certificado etc.

Observação

Os exemplos de configuração de cluster fornecidos abaixo são trechos do manifesto do cluster no formato XML, como o formato mais digerido que dá suporte diretamente à 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 do 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 de entidade

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

No caso das 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 conforme a seguir:

  • a credencial é um certificado válido e bem formado: sua cadeia pode ser criada, as assinaturas correspondem
  • o certificado está em tempo válido (NotBefore <= agora < NotAfter)
  • o hash SHA-1 do certificado corresponde à declaração, como uma comparação de cadeia de caracteres sem diferenciar maiúsculas de minúsculas, excluindo todos os espaços em branco

Os erros de confiança encontrados durante a criação ou validação de cadeias serão suprimidos para declarações baseadas em impressão digital, exceto para certificados expirados, embora também existam disposições para esse caso. Especificamente, a premissa para os casos de falhas relacionadas a: status de revogação sendo desconhecido ou offline, raiz não confiável, uso de chave inválida, cadeia parcial são consideradas erros não fatais, é a de que o certificado é apenas um envelope para um par de chaves. A segurança reside no fato de que o proprietário do cluster definiu medidas nos locais para proteger a chave privada.

O trecho de um manifesto do cluster a seguir 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 se refere a uma identidade específica conforme descrito anteriormente. Cada entrada permite também especificar vários valores, como lista separada por vírgulas de cadeias de caracteres. Neste exemplo, após 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". De modo inverso, um chamador autenticando com o certificado '7c8f... 01b0' receberá uma função de "usuário", restrita a operações de somente leitura basicamente. Um chamador de entrada que apresenta um certificado cuja impressão digital é 'abcd... 1234' ou 'ef01... 5678' será aceito como um nó par no cluster. Por fim, um cliente que se conecta a um ponto de extremidade de gerenciamento do cluster espera que a impressão digital do certificado do servidor seja 'ef01... 5678'.

Conforme mencionado, o Service Fabric tem provisões para aceitar certificados expirados e por esse motivo os certificados têm um tempo de vida limitado e, quando declarados por impressão digital (que se referem a uma instância de certificado específica), permitir que um certificado expire resultará em uma falha na conexão ao cluster ou em um colapso imediato do cluster. É muito fácil esquecer ou negligenciar a rotação de um certificado fixado por impressão digital e, infelizmente, é difícil se recuperar dessa situação.

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

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

Esse comportamento não se estende a certificados emitidos pela AC. Se esse fosse o caso, um certificado expirado revogado, conhecido por estar comprometido, poderia se tornar "válido" assim que ele não figurasse mais na lista de revogação de certificados da AC e, portanto, apresentaria um risco de segurança. Com certificados auto-assinados, o proprietário do cluster é considerado a única parte responsável por proteger a chave privada do certificado, o que não é o caso de certificados emitidos pela AC. O proprietário do cluster pode não estar ciente de como ou quando seu certificado foi declarado comprometido.

Declarações de validação de certificado comuns baseadas em nome

Declarações baseadas em nome comuns obtém um dos seguintes formulários:

  • nome comum da entidade (somente)
  • nome comum da entidade com fixação de emissor

Vamos primeiro considerar um trecho de um manifesto de cluster que exemplifica os dois 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 do servidor e do 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". Nas duas declarações, o “Nome” representa o nome comum da entidade diferenciado do certificado e o campo “Valor” representa o emissor esperado, conforme a seguir:

  • No primeiro caso, a declaração afirma que o elemento de nome comum do assunto diferenciado do certificado de servidor deve corresponder à cadeia de caracteres "server.demo.system.servicefabric.azure-int"; the empty; o campo “Valor” vazio indica a expectativa de que a raiz da cadeia de certificados seja confiável no nó/máquina em que o certificado do servidor está sendo validado e no Windows, isso significa que o certificado pode ser encadeado a qualquer um dos certificados instalados no armazenamento de “AC de raiz confiável”.
  • No segundo caso, a declaração afirma que o apresentador de um certificado é aceito como um nó par no cluster se o nome comum do certificado corresponde à cadeia de caracteres "cluster.demo.system.servicefabric.azure-int", e a impressão digital do emissor direto do certificado corresponde a uma das entradas separadas por vírgulas no campo “Value”. (Esse tipo de regra geralmente é conhecida como “nome comum com fixação de emissor”.)

Nesses casos, a cadeia do certificado é criada e não são esperados erros nela, 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á. A fixação de emissores resultará em considerar o status "raiz não confiável" como um erro não fatal. Apesar de não parecer, essa é uma forma mais rígida de validação, pois permite ao proprietário do cluster restringir o conjunto de emissores autorizados/aceitos para seu próprio PKI.

Depois que a cadeia de certificados é criada, ela é validada em uma política de protocolo TLS/SSL padrão com a entidade declarada como o nome remoto e um certificado será considerado uma combinação se seu nome comum de entidade ou um de seus nomes alternativos de entidade corresponder à declaração de NC do manifesto do cluster. Nesse caso, há suporte para caracteres curinga, e a correspondência de cadeias 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á criada 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 de autenticação do cliente ou a validação falhar, o runtime do Service Fabric criará e avaliará a cadeia de autenticação do servidor.)

Para concluir 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 do administrador e do usuário, respectivamente. A validação de certificados declarados dessa maneira é exatamente conforme o descrito para os exemplos anteriores, de certificados de cluster e servidor.

Observação

Declarações comuns baseadas em nome são destinadas a simplificar a rotação e, em geral, o gerenciamento de certificados de cluster. No entanto, é recomendável aderir às seguintes recomendações para garantir a disponibilidade contínua e a segurança do cluster:

  • preferir a fixação de emissor para depender de raízes confiáveis
  • evitar misturar emissores de PKIs diferentes
  • verificar se todos os emissores esperados estão listados na declaração de certificado, pois um emissor incompatível resultará em uma validação com falha
  • verificar se os pontos de extremidade da política de certificado do PKI estão descobertos, disponíveis e acessíveis. Isso significa que os pontos de extremidade do AIA, CRL ou OCSP são declarados no certificado folha e que eles são acessíveis para que a criação da cadeia de certificados possa ser concluída.

Ao reunir tudo isso, ao receber uma solicitação de uma conexão em um cluster protegido com certificados X.509, o runtime do Service Fabric usará as configurações de segurança do cluster para validar as credenciais da parte remota conforme descrito acima e se ele for bem-sucedido, o chamador/parte remota será considerado autenticado. Se a credencial corresponder a várias regras de validação, o runtime concederá ao chamador a função de maior privilégio de qualquer uma das regras correspondentes.

Regras de apresentação

A seção anterior descreve como a autenticação funciona em um cluster protegido por certificado. Esta seção explicará como o próprio runtime do Service Fabric descobre e carrega os certificados que ele usa para comunicação no cluster. Nós chamamos essas regras de "apresentação".

Assim como as regras de validação, as regras de apresentação especificam uma função e a declaração de credencial associada, expressa por impressão digital ou nome comum. Ao contrário das regras de validação, as declarações comuns baseadas em nomes não têm disposições para a fixação de emissor, e isso permite maior flexibilidade, bem como desempenho aprimorado. As regras de apresentação são declaradas nas seções “NodeType” do manifesto do cluster, para cada tipo de nó distinto e 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. Em clusters do Azure Service Fabric, as declarações de certificado de tipo de nó são padrão para 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 runtime do Service Fabric diferencia entre a 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 de forma distinta, mas, na prática, elas tendem a se alinhar. Para o restante deste artigo, vamos simplificar e supor que as configurações correspondem.

Vamos considerar o seguinte trecho de um manifesto do 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 mostram um formulário abreviado. 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 principal e o certificado “49e2..19d6” como secundário. Os dois certificados devem ser encontrados no armazenamento de certificados LocalMachine'My' (ou no caminho equivalente do Linux, var/lib/sfcerts).

Declarações de apresentação de certificado baseadas em nome comum

Os certificados de tipo de nó também podem ser declarados pelo nome comum de entidade, 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 fará a leitura da 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 último certificado emitido.)

Observação

Antes da versão 7.2.445 (7.2 CU4), o Service Fabric selecionou 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 nomes comuns, um certificado é considerado uma combinação se seu nome comum de entidade for igual ao campo X509FindValue (ou X509FindValueSecondary) da declaração como uma comparação de cadeia de caracteres exata e que diferencia maiúsculas de minúsculas. Isso contrasta com as regras de validação, que suportam correspondência de caracteres curinga, bem como comparações de cadeias de caracteres sem diferenciar maiúsculas de minúsculas.

Definições de configuração de certificado diversas

Foi mencionado 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 as 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 selecionadas aqui, para concluir a exposição completa da autenticação baseada em certificado. Para cada configuração, explicaremos a intenção, o valor/comportamento padrão, como ela afeta a autenticação e quais valores são aceitáveis.

Conforme mencionado, a validação de certificado sempre implica na criação e avaliação da cadeia do certificado. Para certificados emitidos pela AC, essa chamada aparentemente simples da API do sistema operacional normalmente envolve várias chamadas de saída para vários pontos de extremidade do PKI de emissão, armazenamento em cache de respostas e assim por diante. Dada a prevalência de chamadas de validação de certificado em um cluster do Service Fabric, todos os problemas nos pontos de extremidade da PKI podem resultar em uma disponibilidade reduzida do cluster ou no detalhamento imediata. Embora as chamadas de saída não possam ser suprimidas (consulte abaixo na seção Perguntas frequentes para saber mais), as configurações a seguir podem ser usadas para mascarar erros de validação causados por chamadas da CRL com falha.

  • CrlCheckingFlag: na seção "Segurança", cadeia de caracteres convertida em UINT. O valor dessa configuração é usado pelo Service Fabric para mascarar erros de status da cadeia de certificados alterando o comportamento de criação de cadeia. Ele é passado para a chamada Win32 CryptoAPI CertGetCertificateChain como o parâmetro “dwFlags” e pode ser definido como qualquer combinação válida de sinalizadores aceitos pela função. Um valor 0 força o runtime do Service Fabric a ignorar 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 sã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 mitigação em ambientes desconectados durante a transição entre PKIs.

Como usar: vamos usar um exemplo que força a verificação de revogação para acessar somente URLs armazenadas em cache. Considerando:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

que a declaração no manifesto do cluster se torne:

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError: na seção "Segurança", booleano com um valor padrão de "false". Representa um atalho para suprimir um status de erro de construção de cadeia "offline" de revogação (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 com suporte de uma PKI adequada. Use como mitigação em ambientes desconectados ou quando o PKI for conhecido como inacessível.

Como usar:

  <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 data/hora de NotAfter do certificado e durante o qual o certificado é considerado em risco de expiração. O Service Fabric monitora certificados de cluster e periodicamente emite relatórios de integridade sobre a disponibilidade restante. Dentro do intervalo de "segurança", esses relatórios de integridade são elevados ao status de "aviso". O valor padrão é 30 dias.
  • CertificateHealthReportingInterval: controla a frequência de relatórios de integridade referentes ao tempo de validade restante de certificados de cluster. Os relatórios serão emitidos somente uma vez por esse intervalo. O valor é expresso em segundos, com um padrão de 8 horas.
  • EnforcePrevalidationOnSecurityChanges: booleano, controla o comportamento da atualização de cluster ao detectar alterações de configurações de segurança. Se definido como 'true', a atualização do cluster tentará fazer com que pelo menos um dos certificados que correspondem a uma das regras de apresentação possa transmitir uma regra de validação correspondente. A pré-validação é executada antes que as novas configurações sejam aplicadas a algum nó, mas é executada somente no nó que hospeda a réplica primária do serviço do Gerenciador de Cluster no momento da inicialização da atualização. A partir dessa gravação, 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 runtime começando com 7.1.

Cenário de ponta a ponta (exemplos)

Analisamos as regras de apresentação, as regras de validação e os sinalizadores de ajuste, mas como tudo isso funciona em conjunto? Nesta seção, trabalharemos por meio de dois exemplos de ponta a ponta demonstrando como as configurações de segurança podem ser aproveitadas para atualizações seguras de cluster. Observe, a seção não pretende discutir de forma abrangente sobre o gerenciamento adequado de certificados do Service Fabric, procure um artigo sobre esse tópico.

A separação das regras de apresentação e validação representa a pergunta óbvia (ou preocupação) de se elas podem divergir e quais seriam as consequências. Na verdade, é possível que a seleção de um nó de um certificado de autenticação não passe nas regras de validação de outro nó. De fato, 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, ao aumentar primeiro as regras de validação como uma primeira etapa, todos os nós do cluster irão convergir nas novas configurações enquanto ainda usam as credenciais atuais.

Lembre-se de que, em um cluster do Service Fabric, uma atualização progride por (até 5) "domínios de atualização" ou DAs. Somente nós na DA atual estão sendo atualizados/alterados em um determinado momento, e a atualização prosseguirá para a próxima DA somente se a disponibilidade do cluster permitir. (Veja 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 os nós do cluster ou deixar o cluster próximo de uma perda de quorum.

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

Nk: {P:{TP=A}, V:{TP=A}}, em que:

  • “Nk” representa um nó no domínio de atualização k
  • “P” representa as regras atuais de apresentação do nó (supondo que estamos nos referindo somente 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), com “A” sendo uma impressão digital de certificado
  • “CN=B” representa uma declaração comum baseada em nome (CN), com “B” sendo o nome comum da entidade 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 dois 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 a introduz 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 em 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}} - nós na UD0 apresentarão o certificado A e aceitarão certificados A ou B; todos os outros nós apresentam e aceitam somente 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 das configurações de segurança de atualização/alteração 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}} - nós na UD0 começarão a apresentar B, que é aceito por qualquer outro nó no cluster.
  • ao concluir 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.

Converter um cluster de declarações de certificado baseados em impressão digital para baseadas em nome comum

Da mesma forma, a alteração do 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. Por outro lado, as regras de apresentação permitem somente uma forma de declaração. Por acaso, a abordagem segura para converter um certificado de cluster de impressão digital em nome comum é introduzir o certificado de destino pretendido primeiro por impressão digital e, depois, alterar essa declaração para um baseado em nome comum. No exemplo a seguir, vamos supor que a impressão digital “A” e o nome comum da entidade “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, sendo A a impressão digital principal do certificado
  • 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}} - nós na UD0 apresentarão o certificado A e aceitarão certificados com a impressão digital A ou o nome comum B; todos os outros nós apresentam e aceitam somente 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 alterando as 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}} - nós na UD0 apresentarão o certificado B encontrado pelo CN e aceitarão certificados com a impressão digital A ou o nome comum B; todos os outros nós apresentam e aceitam somente o certificado A, selecionado pela impressão digital
  • ao concluir 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 pelo 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 para certificados comuns baseados em nome. As declarações de validação baseadas em impressão digital podem ser removidas em uma atualização de cluster subsequente.

Observação

Em 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 realizar 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 a depuração de problemas relacionados à autenticação em clusters do Service Fabric não seja fácil, esperamos que as dicas e truques a seguir possam ajudar. A maneira mais fácil de começar investigações é examinar os logs de eventos do Service Fabric nos nós do cluster, não necessariamente aqueles que mostram sintomas, mas também nós que estão ativos, mas não conseguem se conectar a um dos seus vizinhos. No Windows, os eventos de significância geralmente são registrados nos canais "Logs de Aplicativos e Serviços\Microsoft-ServiceFabric\Admin" ou "Operacional", respectivamente. Pode ser útil, às vezes, habilitar o log de CAPI2 para capturar mais detalhes sobre a validação do certificado, a recuperação de CRL/CTL etc. (Lembre-se de desabilitá-lo depois de concluir a reprodução, ele pode ser bastante detalhado.)

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

  • nós estão inoperantes/em ciclo
  • tentativas de conexão são rejeitadas
  • tentativas de conexão são excedidas

Cada um dos sintomas pode ser causado por problemas diferentes, e a mesma causa raiz pode mostrar diferentes manifestações, para tanto, vamos listar somente um pequeno exemplo de problemas comuns, com recomendações para corrigi-los.

  • Nós podem trocar mensagens, mas não podem se conectar. O encerramento das tentativas de conexão pode ocorrer devido ao erro “certificado não correspondente”: uma das partes em uma da conexão de Service Fabric para Service Fabric está apresentando um certificado que falha nas regras de validação do destinatário. Ele pode ser acompanhado pelos erros a seguir:

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

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

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

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    Nesse caso, o certificado é declarado pelo nome comum e um dos seguintes é aplicável:

    • os emissores não são fixados e o certificado raiz não é confiável ou
    • os emissores são fixados, mas a declaração não inclui a impressão digital do emissor direto deste 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: verifique se os certificados declarados nas regras de apresentação podem ser resolvidos pelo conteúdo do repositório 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 nenhuma combinação exata no repositório 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 pelo código de erro:

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Para solucionar, verifique a existência da chave privada; verifique se SFAdmins concede acesso à chave privada para “ler|executar”.

    • tipo de provedor incorreto: indica um certificado CNG (Crypto New Generation) ("Software da Microsoft de Provedor de Armazenamento de Chaves "). Neste momento, o Service Fabric oferece suporte somente para certificados CAPI1. Normalmente acompanhado pelo código de erro:

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      Para solucionar, crie o certificado de cluster usando um provedor CAPI1 (por exemplo, "Provedor Criptográfico RSA e AES aprimorado da Microsoft"). Para obter mais detalhes sobre provedores de criptografia, consulte Noções básicas sobre Provedores de Criptografia