Referência técnica de controles criptográficos

Aplica-se a: Configuration Manager (branch atual)

O Configuration Manager usa assinatura e criptografia para ajudar a proteger o gerenciamento dos dispositivos na hierarquia do Configuration Manager. Com a assinatura, se os dados tiverem sido alterados em trânsito, eles serão descartados. A criptografia ajuda a impedir que um invasor leia os dados usando um analisador de protocolo de rede.

O principal algoritmo de hash que o Configuration Manager usa para assinatura é o SHA-256. Quando dois sites do Configuration Manager se comunicam entre si, eles assinam suas comunicações com SHA-256.

A partir da versão 2107, o algoritmo de criptografia primário usado pelo Configuration Manager é o AES-256. A criptografia ocorre principalmente nas duas áreas a seguir:

• Se você habilitar o site para Usar criptografia, o cliente criptografará seus dados de inventário e mensagens de estado enviadas ao ponto de gerenciamento.

• Quando o cliente baixa políticas secretas, o ponto de gerenciamento sempre criptografa essas políticas. Por exemplo, uma sequência de tarefas de implantação do sistema operacional que inclui senhas.

Ao usar a comunicação do cliente por HTTPS, configure sua PKI (infraestrutura de chave pública) para usar certificados com o máximo de algoritmos de hash e comprimentos de chave. Ao usar certificados CNG v3, os clientes do Configuration Manager dão suporte apenas a certificados que usam o algoritmo criptográfico RSA. Para obter mais informações, consulte Requisitos de certificado PKI e Visão geral dos certificados CNG v3.

Para segurança de transporte, tudo que usa TLS é compatível com AES-256. Esse suporte inclui quando você configura o site para HTTP aprimorado (E-HTTP) ou HTTPS. Para sistemas de sites locais, você pode controlar os pacotes de codificação TLS. Para funções baseadas em nuvem, como o CMG (gateway de gerenciamento de nuvem), se você habilitar o TLS 1.2, o Configuration Manager configurará os pacotes de codificação.

Para a maioria das operações criptográficas com sistemas operacionais baseados em Windows, Configuration Manager usa esses algoritmos da biblioteca CryptoAPI do Windows rsaenh.dll.

Para obter mais informações sobre funcionalidades específicas, consulte Operações de site.

Operações do site

As informações no Configuration Manager podem ser assinadas e criptografadas. Ele dá suporte a essas operações com ou sem certificados PKI.

Assinatura e criptografia de política

O site assina as atribuições de política do cliente com seu certificado autoassinado. Esse comportamento ajuda a impedir que o risco de segurança de um ponto de gerenciamento comprometido envie políticas violadas. Se você usar o gerenciamento de clientes baseado na Internet, esse comportamento será importante porque requer um ponto de gerenciamento voltado para a Internet.

Quando a política contém dados confidenciais, a partir da versão 2107, o ponto de gerenciamento os criptografa com AES-256. A política que contém dados confidenciais só é enviada a clientes autorizados. O site não criptografa políticas que não tenham dados confidenciais.

Quando um cliente armazena política, ele criptografa a política usando a DPAPI (interface de programação de aplicativos de proteção de dados do Windows).

Hash de política

Quando um cliente solicita uma política, ele primeiro obtém uma atribuição de política. Em seguida, ele sabe quais políticas se aplicam a ele e pode solicitar apenas esses órgãos de política. Cada atribuição de política contém o hash calculado para o corpo da política correspondente. O cliente baixa os corpos de política aplicáveis e calcula o hash para cada corpo de política. Se o hash no corpo da política não corresponder ao hash na atribuição de política, o cliente descartará o corpo da política.

O algoritmo de hash da política é SHA-256.

Hash de conteúdo

O serviço do gerenciador de distribuição no servidor do site faz hash dos arquivos de conteúdo de todos os pacotes. O provedor de política inclui o hash na política de distribuição de software. Quando o cliente do Configuration Manager baixa o conteúdo, o cliente regenera o hash localmente e o compara com o fornecido na política. Se os hashes corresponderem, o conteúdo não será alterado e o cliente o instalará. Se um único byte do conteúdo for alterado, os hashes não corresponderão e o cliente não instalará o software. Essa marca ajuda a garantir que o software correto esteja instalado porque o conteúdo real é comparado com a política.

O algoritmo de hash padrão para conteúdo é SHA-256.

Nem todos os dispositivos são compatíveis com o hash de conteúdo. As exceções incluem:

• Clientes Windows quando transmitem conteúdo do App-V.

Assinatura e criptografia de inventário

Quando um cliente envia o inventário de hardware ou software para um ponto de gerenciamento, ele sempre assina o inventário. Não importa se o cliente se comunica com o ponto de gerenciamento por E-HTTP ou HTTPS. Se eles usarem E-HTTP, você também poderá optar por criptografar esses dados, o que é recomendado.

Criptografia de migração de estado

Quando uma sequência de tarefas captura dados de um cliente para implantação do sistema operacional, ela sempre criptografa os dados. Na versão 2103 e posterior, a sequência de tarefas executa a USMT (Ferramenta de Migração de Estado do Usuário) com o algoritmo de criptografia AES-256 .

Criptografia para pacotes multicast

Para cada pacote de implantação do sistema operacional, você pode habilitar a criptografia ao usar multicast. Essa criptografia usa o algoritmo AES-256 . Se você habilitar a criptografia, nenhuma outra configuração de certificado será necessária. O ponto de distribuição habilitado para multicast gera automaticamente chaves simétricas para criptografar o pacote. Cada pacote tem uma chave de criptografia diferente. A chave é armazenada no ponto de distribuição habilitado para multicast usando APIs padrão do Windows.

Quando o cliente se conecta à sessão multicast, a troca de chaves ocorre por meio de um canal criptografado. Se o cliente usar HTTPS, ele usará o certificado de autenticação de cliente emitido pela PKI. Se o cliente usar E-HTTP, ele usará o certificado autoassinado. O cliente só armazena a chave de criptografia na memória durante a sessão multicast.

Criptografia para mídia de implantação do sistema operacional

Ao usar mídia para implantar sistemas operacionais, você deve sempre especificar uma senha para proteger a mídia. Com uma senha, as variáveis de ambiente da sequência de tarefas são criptografadas com AES-128. Outros dados na mídia, incluindo pacotes e conteúdo para aplicativos, não são criptografados.

Criptografia para conteúdo baseado em nuvem

Quando você habilita um CMG (gateway de gerenciamento de nuvem) para armazenar conteúdo, o conteúdo é criptografado com AES-256. O conteúdo é criptografado sempre que você o atualiza. Quando os clientes baixam o conteúdo, ele é criptografado e protegido pela conexão HTTPS.

Entrando em atualizações de software

Todas as atualizações de software devem ser assinadas por um fornecedor confiável para proteção contra adulterações. Em computadores cliente, o WUA (Windows Update Agent) verifica as atualizações do catálogo. Ele não instalará a atualização se não conseguir localizar o certificado digital no repositório de Fornecedores Confiáveis no computador local.

Quando você publica atualizações de software com o System Center Atualizações Publisher, um certificado digital assina as atualizações de software. Você pode especificar um certificado PKI ou configurar o Fornecedor de Atualizações para gerar um certificado autoassinado para assinar a atualização de software. Se você usar um certificado autoassinado para publicar o catálogo de atualizações, como o WSUS Publishers Autoassinado, o certificado também deverá estar no repositório de certificados de Autoridades de Certificação Raiz Confiáveis no computador local. O WUA também verifica se a configuração da política de grupo Permitir conteúdo assinado do local do serviço de atualização da intranet da Microsoft está habilitada no computador local. Essa configuração de política deve ser habilitada para que o WUA verifique as atualizações que foram criadas e publicadas com o Publicador de Atualizações do System Center.

Dados de configuração assinados para configurações de conformidade

Quando você importa dados de configuração, o Configuration Manager verifica a assinatura digital do arquivo. Se os arquivos não estiverem assinados ou se a verificação de assinatura marcar falhar, o console avisará você para continuar com a importação. Importe os dados de configuração somente se você confiar explicitamente no editor e na integridade dos arquivos.

Criptografia e hash para notificação do cliente

Se você usar a notificação do cliente, todas as comunicações usarão TLS e os algoritmos mais altos que o servidor e o cliente podem negociar. A mesma negociação ocorre para o hash dos pacotes que são transferidos durante a notificação do cliente, que usa SHA-2.

Certificados

Para obter uma lista dos certificados PKI (infraestrutura de chave pública) que podem ser usados pelo Configuration Manager, quaisquer requisitos ou limitações especiais e como os certificados são usados, consulte Requisitos de certificado PKI. Essa lista inclui os algoritmos de hash e os comprimentos de chave com suporte. A maioria dos certificados suporta SHA-256 e comprimento de chave de 2048 bits.

A maioria das operações do Configuration Manager que usam certificados também dá suporte a certificados v3. Para obter mais informações, consulte Visão geral dos certificados CNG v3.

O Configuration Manager requer certificados PKI para os seguintes cenários:

• Quando você gerencia clientes do Configuration Manager na Internet

• Quando você usa um CMG (gateway de gerenciamento de nuvem)

Para a maioria das outras comunicações que exigem certificados para autenticação, assinatura ou criptografia, o Configuration Manager usa automaticamente certificados PKI, se disponíveis. Se não estiverem disponíveis, o Configuration Manager gera certificados autoassinados.

Gerenciamento de dispositivos móveis e certificados PKI

Implantação do sistema operacional e certificados PKI

Quando você usa o Configuration Manager para implantar sistemas operacionais e um ponto de gerenciamento requer conexões de cliente HTTPS, o cliente precisa de um certificado para se comunicar com o ponto de gerenciamento. Esse requisito ocorre mesmo quando o cliente está em uma fase de transição, como a inicialização da mídia de sequência de tarefas ou de um ponto de distribuição habilitado para PXE. Para dar suporte a esse cenário, crie um certificado de autenticação de cliente PKI e exporte-o com a chave privada. Em seguida, importe-o para as propriedades do servidor do site e também adicione o certificado de autoridade de certificação raiz confiável do ponto de gerenciamento.

Se você criar a mídia inicializável, importará o certificado de autenticação do cliente ao criar a mídia inicializável. Para ajudar a proteger a chave privada e outros dados confidenciais configurados na sequência de tarefas, configure uma senha na mídia inicializável. Todo computador que inicializa a partir da mídia inicializável usa o mesmo certificado com o ponto de gerenciamento, conforme necessário para funções de cliente, como solicitar política de cliente.

Se você usar o PXE, importe o certificado de autenticação do cliente para o ponto de distribuição habilitado para PXE. Ele usa o mesmo certificado para cada cliente que inicializa a partir desse ponto de distribuição habilitado para PXE. Para ajudar a proteger a chave privada e outros dados confidenciais nas sequências de tarefas, exija uma senha para o PXE.

Se qualquer um desses certificados de autenticação do cliente estiver comprometido, bloqueie os certificados no nó Certificados no espaço de trabalho de Administração , nó Segurança . Para gerenciar esses certificados, você precisa ter permissão para gerenciar o certificado de implantação do sistema operacional.

Depois que o Configuration Manager implantar o sistema operacional e instalar o cliente, o cliente exigirá seu próprio certificado de autenticação de cliente PKI para comunicação de cliente HTTPS.

Soluções de proxy ISV e certificados PKI

Os ISVs (fornecedores independentes de software) podem criar aplicativos que estendem o Configuration Manager. Por exemplo, um ISV pode criar extensões para dar suporte a plataformas de cliente não Windows. No entanto, se os sistemas do site exigirem conexões de cliente HTTPS, esses clientes também deverão usar certificados PKI para comunicação com o site. O Configuration Manager inclui a capacidade de atribuir um certificado ao proxy ISV que permite comunicações entre os clientes de proxy ISV e o ponto de gerenciamento. Se você usar extensões que exigem certificados de proxy ISV, consulte a documentação desse produto.

Se o certificado ISV estiver comprometido, bloqueie-o no nó Certificados no espaço de trabalho de Administração , nó Segurança .

Copiar GUID para certificado de proxy ISV

A partir da versão 2111, para simplificar o gerenciamento desses certificados de proxy ISV, agora você pode copiar seu GUID no console do Configuration Manager.

1. No console do Configuration Manager, vá para o espaço de trabalho Administração.

2. Expanda Segurança e selecione o nó Certificados .

3. Classifique a lista dos certificados pela coluna Tipo .

4. Selecione um certificado do tipo Proxy ISV.

5. Na faixa de opções, selecione Copiar GUID do Certificado.

Essa ação copia o GUID desse certificado, por exemplo: aa05bf38-5cd6-43ea-ac61-ab101f943987

Inteligência de ativos e certificados

Desde novembro de 2021, substituímos o Asset Intelligence e recomendamos que os clientes desinstalem essa função.

Serviços e certificados do Azure

O CMG (gateway de gerenciamento de nuvem) requer certificados de autenticação de servidor. Esses certificados permitem que o serviço forneça comunicação HTTPS aos clientes pela Internet. Para obter mais informações, consulte Certificado de autenticação do servidor CMG.

Os clientes exigem outro tipo de autenticação para se comunicar com um CMG e o ponto de gerenciamento local. Eles podem usar o Microsoft Entra ID, um certificado PKI ou um token de site. Para obter mais informações, consulte Configurar a autenticação do cliente para o gateway de gerenciamento de nuvem.

Os clientes não exigem um certificado PKI do cliente para usar o armazenamento baseado em nuvem. Depois de autenticar no ponto de gerenciamento, o ponto de gerenciamento emite um token de acesso do Configuration Manager para o cliente. O cliente apresenta esse token ao CMG para acessar o conteúdo. O token é válido por oito horas.

Verificação CRL para certificados PKI

Uma CRL (lista de certificados revogados) PKI aumenta a segurança geral, mas exige alguma sobrecarga administrativa e de processamento. Se você habilitar a verificação de CRL, mas os clientes não puderem acessar a CRL, a conexão PKI falhará.

O IIS habilita a verificação de CRL por padrão. Se você usar uma CRL com sua implantação de PKI, não precisará configurar a maioria dos sistemas de site que executam o IIS. A exceção é para atualizações de software, que exigem uma etapa manual para habilitar a verificação de CRL para verificar as assinaturas em arquivos de atualização de software.

Quando um cliente usa HTTPS, ele habilita a verificação de CRL por padrão.

As conexões a seguir não dão suporte à verificação de CRL no Configuration Manager:

• Conexões de servidor para servidor

Comunicação do servidor

O Configuration Manager usa os seguintes controles criptográficos para comunicação do servidor.

Comunicação do servidor em um site

Cada servidor do sistema de sites usa um certificado para transferir dados para outros sistemas de sites no mesmo site do Configuration Manager. Algumas funções do sistema de sites também usam certificados para autenticação. Por exemplo, se você instalar o ponto proxy de registro em um servidor e o ponto de registro em outro servidor, eles poderão se autenticar usando esse certificado de identidade.

Quando o Configuration Manager usa um certificado para essa comunicação, se houver um certificado PKI disponível com o recurso de autenticação de servidor, o Configuration Manager o usará automaticamente. Caso contrário, o Configuration Manager gerará um certificado autoassinado. Esse certificado autoassinado tem funcionalidade de autenticação de servidor, usa SHA-256 e tem um comprimento de chave de 2048 bits. O Configuration Manager copia o certificado para o repositório Trusted People em outros servidores do sistema de sites que talvez precisem confiar no sistema de sites. Os sistemas de sites podem confiar uns nos outros usando esses certificados e o PeerTrust.

Além desse certificado para cada servidor do sistema de sites, o Configuration Manager gera um certificado autoassinado para a maioria das funções do sistema de sites. Quando há mais de uma instância da função do sistema de sites no mesmo site, elas compartilham o mesmo certificado. Por exemplo, você pode ter vários pontos de gerenciamento no mesmo site. Esse certificado autoassinado usa SHA-256 e tem um comprimento de chave de 2048 bits. Ele é copiado para o Trusted People Store em servidores do sistema de sites que talvez precisem confiar nele. As seguintes funções do sistema de sites geram esse certificado:

• Ponto de sincronização do Asset Intelligence

• Ponto do Endpoint Protection

• Ponto de status de fallback

• Ponto de gerenciamento

• Ponto de distribuição habilitado para multicast

• Ponto do Reporting Services

• Ponto de atualização de software

• Ponto de migração de estado

O Configuration Manager gera e gerencia automaticamente esses certificados.

Para enviar mensagens de status do ponto de distribuição para o ponto de gerenciamento, o Configuration Manager usa um certificado de autenticação do cliente. Quando você configura o ponto de gerenciamento para HTTPS, ele requer um certificado PKI. Se o ponto de gerenciamento aceitar conexões E-HTTP, você poderá usar um certificado PKI. Ele também pode usar um certificado autoassinado com funcionalidade de autenticação de cliente, usa SHA-256 e tem um comprimento de chave de 2048 bits.

Comunicação do servidor entre sites

O Configuration Manager transfere dados entre sites usando a replicação de banco de dados e a replicação baseada em arquivo. Para obter mais informações, consulte Transferências de dados entre sites e Comunicações entre pontos de extremidade.

O Configuration Manager configura automaticamente a replicação do banco de dados entre sites. Se disponível, ele usa certificados PKI com funcionalidade de autenticação de servidor. Se não estiver disponível, o Configuration Manager criará certificados autoassinados para autenticação do servidor. Em ambos os casos, ele se autentica entre sites usando certificados no repositório Trusted People que usa PeerTrust. Ele usa esse repositório de certificados para garantir que apenas os SQL Servers da hierarquia do Configuration Manager participem da replicação site a site.

Os servidores do site estabelecem a comunicação site a site usando uma troca de chave segura que ocorre automaticamente. O servidor do site de envio gera um hash e o assina com sua chave privada. O servidor do site receptor verifica a assinatura usando a chave pública e compara o hash com um valor gerado localmente. Se elas corresponderem, o site receptor aceita os dados replicados. Se os valores não corresponderem, o Configuration Manager rejeitará os dados de replicação.

A replicação de banco de dados no Configuration Manager usa o SQL Server Service Broker para transferir dados entre sites. Ele usa os seguintes mecanismos:

• SQL Server para SQL Server: essa conexão usa credenciais do Windows para autenticação de servidor e certificados autoassinados com 1024 bits para assinar e criptografar os dados com o algoritmo AES. Se disponível, ele usa certificados PKI com funcionalidade de autenticação de servidor. Ele usa apenas certificados no armazenamento de certificados particulares do computador.

• SQL Service Broker: esse serviço usa certificados autoassinados com 2048 bits para autenticação e para assinar e criptografar os dados com o algoritmo AES. Ele usa apenas certificados no banco de dados SQL Server master.

A replicação baseada em arquivo usa o protocolo SMB (bloco de mensagens do servidor). Ele usa SHA-256 para assinar dados que não estão criptografados e não contêm dados confidenciais. Para criptografar esses dados, use o IPsec, que você implementa independentemente do Configuration Manager.

Clientes que usam HTTPS

Quando as funções do sistema de sites aceitam conexões de cliente, você pode configurá-las para aceitar conexões HTTPS e HTTP ou apenas conexões HTTPS. As funções do sistema de sites que aceitam conexões da Internet aceitam apenas conexões de cliente por HTTPS.

As conexões de cliente por HTTPS oferecem um nível mais alto de segurança ao se integrarem a uma PKI (infraestrutura de chave pública) para ajudar a proteger a comunicação entre cliente e servidor. No entanto, configurar conexões de cliente HTTPS sem uma compreensão completa do planejamento, implantação e operações de PKI ainda pode deixá-lo vulnerável. Por exemplo, se você não proteger sua CA (autoridade de certificação) raiz, os invasores poderão comprometer a confiança de toda a sua infraestrutura PKI. Deixar de implantar e gerenciar os certificados PKI usando processos controlados e seguros pode resultar em clientes não gerenciados que não podem receber atualizações ou pacotes de software críticos.

Comunicação não criptografada quando os clientes usam HTTPS

Quando os clientes se comunicam com os sistemas do site por HTTPS, a maior parte do tráfego é criptografada. Nas seguintes situações, os clientes se comunicam com sistemas de site sem usar criptografia:

• O cliente não consegue fazer uma conexão HTTPS na intranet e volta a usar HTTP quando os sistemas de site permitem essa configuração.

• Comunicação com as seguintes funções do sistema de sites:

  • O cliente envia mensagens de estado para o ponto de status de fallback.

  • O cliente envia solicitações PXE para um ponto de distribuição habilitado para PXE.

  • O cliente envia dados de notificação para um ponto de gerenciamento.

Você configura pontos do Reporting Services para usar HTTP ou HTTPS independentemente do modo de comunicação do cliente.

Clientes que usam E-HTTP

Quando os clientes usam a comunicação E-HTTP com funções do sistema do site, eles podem usar certificados PKI para autenticação de cliente ou certificados autoassinados gerados pelo Configuration Manager. Quando o Configuration Manager gera certificados autoassinados, ele tem um identificador de objeto personalizado para assinatura e criptografia. Esses certificados são usados para identificar exclusivamente o cliente. Esses certificados autoassinados usam SHA-256 e têm um comprimento de chave de 2048 bits.

Implantação de sistema operacional e certificados autoassinados

Quando você usa o Configuration Manager para implantar sistemas operacionais com certificados autoassinados, o cliente também deve ter um certificado para se comunicar com o ponto de gerenciamento. Esse requisito é válido mesmo que o computador esteja em uma fase de transição, como a inicialização por meio de uma mídia de sequência de tarefas ou de um ponto de distribuição habilitado para PXE. Para dar suporte a esse cenário para conexões de cliente E-HTTP, o Configuration Manager gera certificados autoassinados que têm um identificador de objeto personalizado para assinatura e criptografia. Esses certificados são usados para identificar exclusivamente o cliente. Esses certificados autoassinados usam SHA-256 e têm um comprimento de chave de 2048 bits. Se esses certificados autoassinados forem comprometidos, evite que invasores os usem para representar clientes confiáveis. Bloqueie os certificados no nó Certificados no espaço de trabalho de Administração , nó Segurança .

Autenticação de cliente e servidor

Quando os clientes se conectam por E-HTTP, eles autenticam os pontos de gerenciamento usando o Active Directory Domain Services ou usando a chave raiz confiável do Configuration Manager. Os clientes não autenticam outras funções do sistema de sites, como pontos de migração de estado ou pontos de atualização de software.

Quando um ponto de gerenciamento autentica um cliente pela primeira vez usando o certificado de cliente autoassinado, esse mecanismo fornece segurança mínima porque qualquer computador pode gerar um certificado autoassinado. Use a aprovação do cliente para aprimorar esse processo. Aprove apenas computadores confiáveis, automaticamente pelo Configuration Manager ou manualmente por um usuário administrativo. Para obter mais informações, consulte Gerenciar clientes.

Sobre vulnerabilidades SSL

Para melhorar a segurança dos clientes e servidores do Configuration Manager, execute as seguintes ações:

• Habilite o TLS 1.2 em todos os dispositivos e serviços. Para habilitar o TLS 1.2 para o Configuration Manager, consulte Como habilitar o TLS 1.2 para o Configuration Manager.

• Desabilite o SSL 3.0, o TLS 1.0 e o TLS 1.1.

• Reordene os pacotes de codificação relacionados ao TLS.

Para saber mais, confira os seguintes artigos:

• Restringir o uso de determinados algoritmos e protocolos criptográficos em Schannel.dll
• Priorizando pacotes de codificação Schannel

Esses procedimentos não afetam a funcionalidade do Configuration Manager.