Compartilhar via

Referência técnica de controles criptográficos

  • Artigo

Aplica-se a: Configuration Manager (branch atual)

Configuration Manager usa assinatura e criptografia para ajudar a proteger o gerenciamento dos dispositivos na hierarquia 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 algoritmo de hash primário que Configuration Manager usa para assinatura é SHA-256. Quando dois Configuration Manager sites se comunicam entre si, eles assinam suas comunicações com o SHA-256.

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

  • Se você habilitar o site a Usar criptografia, o cliente criptografa seus dados de inventário e mensagens de estado que ele envia para o 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.

Para clientes na versão 2103 e anterior, o algoritmo de criptografia primária é 3DES.

Observação

Se você configurar a comunicação HTTPS, essas mensagens serão criptografadas duas vezes. A mensagem é criptografada com o AES e, em seguida, o transporte HTTPS é criptografado com a AES.

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

Para segurança de transporte, qualquer coisa que use TLS dá suporte ao AES. Esse suporte inclui quando você configura o site para HTTP ou HTTPS aprimorados . Para sistemas de sites locais, você pode controlar os pacotes de criptografia TLS. Para funções baseadas em nuvem, como o CMG (gateway de gerenciamento de nuvem), se você habilitar o TLS 1.2, Configuration Manager configurará os pacotes de criptografia.

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

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

Operações do site

As informações em 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 atribuições de política de cliente com seu certificado autoassinado. Esse comportamento ajuda a evitar que o risco de segurança de um ponto de gerenciamento comprometido envie políticas adulteradas. 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 criptografa-os com o AES-256. Na versão 2103 e anterior, ele usa 3DES. A política que contém dados confidenciais é enviada apenas para clientes autorizados. O site não criptografa a política que não tem dados confidenciais.

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

Hash de política

Quando um cliente solicita política, ele primeiro obtém uma atribuição de política. Em seguida, ele sabe quais políticas se aplicam a ela, 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 órgãos de política aplicáveis e, em seguida, calcula o hash para cada corpo da 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 hashe os arquivos de conteúdo para todos os pacotes. O provedor de política inclui o hash na política de distribuição de software. Quando o Configuration Manager cliente baixa o conteúdo, o cliente regenera o hash localmente e o compara ao 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. Esse marcar 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 podem dar suporte ao hash de conteúdo. As exceções incluem:

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

  • Clientes do Windows Mobile, embora esses clientes verifiquem a assinatura de um aplicativo assinado por uma fonte confiável.

Assinatura e criptografia de inventário

Quando um cliente envia 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 HTTP ou HTTPS. Se eles usarem 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 . Na versão 2010 e anterior, ele usa 3DES.

Criptografia para pacotes multicast

Para cada pacote de implantação do sistema operacional, você pode habilitar a criptografia ao usar o multicast. Essa criptografia usa o algoritmo AES . 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 em um canal criptografado. Se o cliente usar HTTPS, ele usará o certificado de autenticação de cliente emitido pelo PKI. Se o cliente usar HTTP, ele usará o certificado autoassinado. O cliente armazena apenas a chave de criptografia na memória durante a sessão multicast.

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

Ao usar a mídia para implantar sistemas operacionais, você sempre deve especificar uma senha para proteger a mídia. Com uma senha, as variáveis de ambiente de sequência de tarefas são criptografadas com o 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 o 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.

Entrar em atualizações de software

Todas as atualizações de software devem ser assinadas por um editor confiável para proteger contra adulteração. Em computadores cliente, o WUA (Agente de Windows Update) 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 Editores 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 Atualizações Publisher 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 autoridades de certificação raiz confiáveis no computador local. O WUA também verifica se a configuração permitir conteúdo assinado da política de grupo de localização do serviço de atualização da Microsoft está habilitada no computador local. Essa configuração de política deve ser habilitada para que o WUA examine as atualizações criadas e publicadas com o System Center Atualizações Publisher.

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

Ao importar dados de configuração, Configuration Manager verifica a assinatura digital do arquivo. Se os arquivos não estiverem assinados ou se a assinatura marcar falhar, o console avisará você para continuar com a importação. Importe somente os dados de configuração 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, toda a comunicação usará o TLS e os algoritmos mais altos que o servidor e o cliente podem negociar. Por exemplo, todas as versões compatíveis do sistema operacional Windows podem usar pelo menos a criptografia AES-128 . A mesma negociação ocorre para 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 por Configuration Manager, quaisquer requisitos ou limitações especiais e como os certificados são usados, consulte Requisitos de certificado PKI. Esta lista inclui os algoritmos de hash com suporte e os comprimentos de chave. A maioria dos certificados dá suporte ao comprimento da chave SHA-256 e 2048 bits.

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

Observação

Todos os certificados que Configuration Manager usa devem conter apenas caracteres de bytes únicos no nome do assunto ou nome alternativo do assunto.

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

  • Quando você gerencia Configuration Manager clientes na Internet

  • Quando você gerencia Configuration Manager clientes em dispositivos móveis

  • Quando você gerencia computadores macOS

  • 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, Configuration Manager usa automaticamente certificados PKI se disponível. Se eles não estiverem disponíveis, Configuration Manager gerará certificados autoassinados.

Configuration Manager não usa certificados PKI quando gerencia dispositivos móveis usando o conector Exchange Server.

Gerenciamento de dispositivo móvel e certificados PKI

Se o dispositivo móvel não estiver bloqueado pela operadora móvel, você poderá usar Configuration Manager para solicitar e instalar um certificado de cliente. Esse certificado fornece autenticação mútua entre o cliente no dispositivo móvel e Configuration Manager sistemas de site. Se o dispositivo móvel estiver bloqueado, você não poderá usar Configuration Manager para implantar certificados.

Se você habilitar o inventário de hardware para dispositivos móveis, Configuration Manager também inventaria os certificados instalados no dispositivo móvel.

Implantação do sistema operacional e certificados PKI

Quando você usa 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 é mesmo quando o cliente está em uma fase transitória, como inicializar a mídia de sequência de tarefas ou 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 de site e também adicione o certificado de AC raiz confiável do ponto de gerenciamento.

Se você criar 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. Cada computador que inicializa da mídia inicializável usa o mesmo certificado com o ponto de gerenciamento conforme necessário para funções do cliente, como solicitar a política do 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 daquele 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 PXE.

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

Depois que Configuration Manager implanta o sistema operacional instala o cliente, o cliente requer seu próprio certificado de autenticação de cliente PKI para comunicação do cliente HTTPS.

Soluções de proxy ISV e certificados PKI

ISVs (fornecedores de software independentes) podem criar aplicativos que estendem Configuration Manager. Por exemplo, um ISV poderia criar extensões para dar suporte a plataformas cliente que não são do Windows, como o macOS. No entanto, se os sistemas de site exigirem conexões de cliente HTTPS, esses clientes também devem usar certificados PKI para comunicação com o site. Configuration Manager inclui a capacidade de atribuir um certificado ao proxy ISV que permite comunicações entre os clientes 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 certificado no nó Certificados no workspace Administração , nó segurança .

Copiar GUID para certificado 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 Configuration Manager.

  1. No console Configuration Manager, acesse o workspace 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 de Certificado.

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

Asset Intelligence e certificados

Configuration Manager instala com um certificado X.509 que o ponto de sincronização do Asset Intelligence usa para se conectar à Microsoft. Configuration Manager usa esse certificado para solicitar um certificado de autenticação do cliente do serviço de certificado da Microsoft. O certificado de autenticação do cliente é instalado no ponto de sincronização do Asset Intelligence e é usado para autenticar o servidor na Microsoft. Configuration Manager usa o certificado de autenticação do cliente para baixar o catálogo do Asset Intelligence e carregar títulos de software.

Esse certificado tem um comprimento de chave de 1024 bits.

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 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 que eles se autenticam no ponto de gerenciamento, o ponto de gerenciamento emite um token de acesso Configuration Manager ao cliente. O cliente apresenta esse token ao CMG para acessar o conteúdo. O token é válido por oito horas.

Verificação de CRL para certificados PKI

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

O IIS habilita a verificação de CRL por padrão. Se você usar um CRL com sua implantação PKI, não precisará configurar a maioria dos sistemas de site que executam o IIS. A exceção é para atualizações de software, o que requer 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. Para clientes macOS, você não pode desabilitar a verificação de CRL.

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

  • Conexões servidor a servidor

  • Dispositivos móveis registrados por Configuration Manager.

Comunicação do servidor

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

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

Além desse certificado para cada servidor do sistema de site, Configuration Manager gera um certificado autoassinado para a maioria das funções do sistema de site. 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 Pessoas Store em servidores do sistema de sites que talvez precisem confiar nele. As seguintes funções do sistema de sites geram este certificado:

  • Ponto de sincronização do Asset Intelligence

  • Ponto de registro de certificado

  • Ponto de Proteção de Ponto de Extremidade

  • Ponto de registro

  • Ponto de status de fallback

  • Ponto de gerenciamento

  • Ponto de distribuição habilitado para multicast

  • Ponto de serviços de relatório

  • Ponto de atualização de software

  • Ponto de migração de estado

Configuration Manager gera e gerencia automaticamente esses certificados.

Para enviar mensagens status do ponto de distribuição para o ponto de gerenciamento, 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 HTTP, você poderá usar um certificado PKI. Ele também pode usar um certificado autoassinado com a funcionalidade de autenticação do cliente, usa SHA-256 e tem um comprimento de chave de 2048 bits.

Comunicação do servidor entre sites

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

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

Os servidores de site estabelecem a comunicação site a site usando uma troca de chaves segura que acontece automaticamente. O servidor de 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 eles corresponderem, o site de recebimento aceitará os dados replicados. Se os valores não corresponderem, 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 estiver disponível, ele usará certificados PKI com a funcionalidade de autenticação do servidor. Ele só usa certificados no repositório de certificados pessoal do computador.

  • SQL Service Broker: esse serviço usa certificados autoassinados com 2.048 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 o SHA-256 para assinar dados que não são criptografados e não contêm dados confidenciais. Para criptografar esses dados, use o IPsec, que você implementa independentemente de Configuration Manager.

Clientes que usam HTTPS

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

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

Importante

Os certificados PKI que Configuration Manager usam para comunicação do cliente protegem a comunicação somente entre o cliente e alguns sistemas de site. Eles não protegem o canal de comunicação entre o servidor do site e os sistemas de site ou entre servidores de site.

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

Quando os clientes se comunicam com sistemas de site por HTTPS, a maioria 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 de serviços de relatório para usar HTTP ou HTTPS independentemente do modo de comunicação do cliente.

Clientes que usam HTTP

Quando os clientes usam a comunicação HTTP para funções do sistema de sites, eles podem usar certificados PKI para autenticação do cliente ou certificados autoassinados que Configuration Manager gera. Quando Configuration Manager gera certificados autoassinados, eles 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.

Implantação do sistema operacional e certificados autoassinados

Quando você usa 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 é mesmo se o computador estiver em uma fase transitória, como inicializar a mídia de sequência de tarefas ou um ponto de distribuição habilitado para PXE. Para dar suporte a esse cenário para conexões de cliente HTTP, 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, impeça que os invasores os usem para representar clientes confiáveis. Bloqueie os certificados no nó Certificados no workspace Administração , nó segurança .

Autenticação de cliente e servidor

Quando os clientes se conectam por HTTP, eles autenticam os pontos de gerenciamento usando Active Directory Domain Services ou usando a chave raiz confiável 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 primeiro um cliente 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. Aprovar apenas computadores confiáveis, automaticamente por 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 de seus Configuration Manager clientes e servidores, execute as seguintes ações:

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

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

  • Reordene os pacotes de criptografia relacionados ao TLS.

Para saber mais, confira os seguintes artigos:

Esses procedimentos não afetam Configuration Manager funcionalidade.

Observação

Atualizações para Configuration Manager baixar da CDN (rede de entrega de conteúdo) do Azure, que tem requisitos de pacote de criptografia. Para obter mais informações, consulte Perguntas frequentes sobre a configuração do Azure Front Door: TLS.