Referência técnica para controles de criptografia usados no Configuration Manager
Aplica-se a: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1
.jpeg "System_CAPS_note"){kind=icon} Observação |
|---|
Este tópico é exibido na nos guias Administração de site do System Center 2012 Configuration Manager e Segurança e privacidade no System Center 2012 Configuration Manager. |
O System Center 2012 Configuration Manager usa assinatura e criptografia para ajudar a proteger o gerenciamento dos dispositivos na hierarquia do Gerenciador de Configurações. A assinatura garante que, se dados foram alterados em trânsito, os dados serão descartados. A criptografia impede que um invasor leia os dados usando um analisador de protocolo de rede.
O principal algoritmo de hash usado pelo Gerenciador de Configurações para a assinatura é SHA-256. Quando dois sites do Gerenciador de Configurações se comunicam entre si, eles assinam suas comunicações usando o SHA-256. O principal algoritmo de criptografia implementado no Gerenciador de Configurações é o 3DES. Ele é usado para armazenar dados no banco de dados do Gerenciador de Configurações e quando os clientes se comunicam usando HTTP. Ao usar comunicação do cliente via HTTPS, você pode configurar sua PKI (infraestrutura de chave pública) para usar certificados RSA com o máximo de algoritmos de hash e comprimentos de chave que estão documentados no Requisitos de certificado PKI para o Configuration Manager.
Para a maioria das operações de criptografia para sistemas operacionais baseados no Windows, o Configuration Manager usa os algoritmos SHA-1, SHA-2, 3DES, AES e RSA do rsaenh.dll da biblioteca CryptoAPI do Windows.
Use as seções a seguir para obter mais informações.
Controles de criptografia para operações do Configuration Manager
Certificados usados pelo Configuration Manager
Controles de criptografia para a comunicação do servidor
Controles de criptografia para clientes que usam comunicação HTTPS para sistemas de site
Controles de criptografia para clientes que usam comunicação HTTP para sistemas de site
.jpeg "System_CAPS_important") Importante |
|---|
Obtenha informações sobre as alterações recomendadas em resposta às vulnerabilidades do SSL em Sobre as vulnerabilidades do SSL. |
Controles de criptografia para operações do Configuration Manager
Você pode assinar e criptografar as informações no Gerenciador de Configurações independentemente do uso ou não de certificados PKI com o Gerenciador de Configurações.
Criptografia e assinatura de política
As atribuições de política do cliente são assinadas pelo certificado de assinatura do servidor do site autoassinado para ajudar a evitar o risco de segurança de um ponto de gerenciamento comprometido enviando políticas que foram violadas. Essa proteção é particularmente relevante se você estiver usando gerenciamento de clientes baseado na Internet, pois este ambiente requer um ponto de gerenciamento exposto à comunicação da Internet.
A política é criptografada usando 3DES quando ele contém dados confidenciais. A política que contém dados confidenciais é enviada somente aos clientes autorizados. A política que não tem dados confidenciais não é criptografada.
Ao armazenar a política em clientes, ela é criptografada usando a DPAPI (Interface de programação de aplicativo de Proteção de Dados).
Hash de política
Quando os clientes do Gerenciador de Configurações solicitam a política, primeiro eles obtêm uma atribuição da política para que conheçam aquelas que se aplicam a eles e, em seguida, solicitam somente os corpos dessas políticas. Cada atribuição de política contém o hash calculado para o corpo da política correspondente. O cliente recupera o corpo de política aplicável e, em seguida, calcula o hash nesse corpo. Se o hash no corpo da política baixada não corresponder ao hash na atribuição da política, o cliente descartará o corpo da política.
O algoritmo de hash para a política é SHA-1 e SHA-256.
Hash de conteúdo
O serviço do gerenciador de distribuição no servidor do site mistura 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 cliente do Gerenciador de Configurações baixa o conteúdo, o cliente regenera o hash localmente e o compara a um fornecido na política. Se os hashes corresponderem, o conteúdo não foi alterado e o cliente o instala. Se um único byte do conteúdo foi alterado, os hashes não irão corresponder e o software não será instalado. Essa verificação ajuda a garantir que o software correto seja instalado, pois o conteúdo real está comparado com a política.
O algoritmo de hash padrão para o conteúdo é o SHA-256. Para alterar este padrão, veja a documentação do Software Development Kit (SDK) do Gerenciador de Configurações.
Nem todos os dispositivos podem oferecer suporte a conteúdo de hash. As exceções incluem o seguinte:
Clientes do Windows quando transmitem conteúdo do App-V.
Clientes do Windows Phone: No entanto, esses clientes verificam a assinatura de um aplicativo que está assinado por uma fonte confiável.
Clientes do Windows RT: No entanto, esses clientes verificam a assinatura de um aplicativo que está assinado por uma fonte confiável e também usam validação PFN (nome completo do pacote).
iOS: No entanto, esses dispositivos verificam a assinatura de um aplicativo que está assinado por algum certificado do desenvolvedor de uma fonte confiável.
Clientes da Nokia: No entanto, esses clientes verificam a assinatura de um aplicativo que usa um certificado autoassinado. Ou, a assinatura de um certificado de uma fonte confiável e o certificado podem assinar aplicativos SIS (Symbian Installation Source) da Nokia.
Android. Além disso, esses dispositivos não usam a validação de assinatura para instalação do aplicativo.
Clientes que executam versões do Linux e UNIX que não dão suporte ao SHA-256. Para obter mais informações, veja a seção Sobre o Linux e UNIX sistemas operacionais que fazer não suporte SHA-256 no tópico Planejamento de implantação de cliente para servidores Linux e UNIX.
Criptografia e assinatura de inventário
O inventário que os clientes enviam para pontos de gerenciamento sempre é assinado por dispositivos, independentemente de eles se comunicarem com pontos de gerenciamento via HTTP ou HTTPS. Se eles usam HTTP, você pode optar por criptografar esses dados, que é uma prática recomendada de segurança.
Criptografia de migração de estado
Os dados armazenados em pontos de migração de estado para implantação do sistema operacional sempre são criptografados pela USMT (Ferramenta de Migração de Estado do Usuário) usando 3DES.
Criptografia de pacotes de multicast para implantar sistemas operacionais
Para cada pacote de implantação de sistema operacional, você pode habilitar a criptografia quando o pacote é transferido para o computador usando multicast. A criptografia usa AES (Advanced Encryption Standard). Se você habilitar a criptografia, nenhuma configuração de certificado adicional 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 a uma sessão de multicast, a troca de chaves ocorre em um canal criptografado com o certificado de autenticação do cliente emitido pela PKI (quando o cliente usa HTTPS) ou o certificado autoassinado (quando o cliente usa HTTP). O cliente armazena a chave na memória somente pela duração da sessão de multicast.
Criptografia de mídia para implantar sistemas operacionais
Quando você usa mídia para implantar sistemas operacionais e especificar uma senha para proteger a mídia, as variáveis de ambiente são criptografadas usando AES. Outros dados na mídia, incluindo pacotes e conteúdo para aplicativos, não são criptografados.
Criptografia de conteúdo hospedado nos pontos de distribuição com base em nuvem
A partir do System Center 2012 Configuration Manager SP1, ao usar pontos de distribuição baseados em nuvem, o conteúdo carregado nesses pontos de distribuição é criptografado por meio da criptografia AES com um tamanho de chave de 256 bits. O conteúdo é criptografado novamente sempre que você atualizá-lo. Quando os clientes baixam o conteúdo, ele é criptografado e protegido pela conexão HTTPS.
Assinando atualizações de software
Todas as atualizações de software devem ser assinadas por um editor confiável para proteção contra violação. Em computadores cliente, o WUA (Windows Update Agent) verifica atualizações do catálogo, mas não irá instalar a atualização se não conseguir localizar o certificado digital na loja de Editores Confiáveis no computador local. Se um certificado autoassinado foi usado para publicar o catálogo de atualizações, como os Editores WSUS autoassinados, o certificado também deve estar na loja de certificados das Autoridades de Certificação Raiz Confiável no computador local para verificar a validade do certificado. O WUA também verifica se a configuração Permitir conteúdo assinado da política de grupo de local do serviço de atualização da intranet da Microsoft está habilitada no computador local. Essa configuração da política deve ser habilitada para que o WUA procure atualizações que foram criadas e publicadas com o Updates Publisher.
Quando as atualizações do software são publicadas no System Center Updates Publisher, um certificado digital assina as atualizações de software quando elas são publicadas em um servidor de atualização. Você pode especificar um certificado PKI ou configurar o Updates Publisher para gerar um certificado autoassinado para assinar a atualização de software.
Dados de configuração assinados para configurações de conformidade
Quando você importa dados de configuração, o Gerenciador de Configurações verifica a assinatura digital do arquivo. Se os arquivos não foram assinados, ou se a verificação da assinatura digital falhar, você será avisado e consultado se deseja continuar a importação. Continue a importar os dados de configuração somente se você confiar totalmente no editor e na integridade dos arquivos.
Criptografia e hash para notificação do cliente
Se você usa notificação do cliente, todas as comunicações usam TLS e a criptografia máxima que o servidor e os sistemas operacionais do cliente podem negociar. Por exemplo, um computador cliente que executa Windows 7 e um ponto de gerenciamento que executa o Windows Server 2008 R2 podem oferecer suporte à criptografia AES de 128 bits, enquanto um computador cliente que executa Vista para o mesmo ponto de gerenciamento, mas irá negociar para a criptografia 3DES. A mesma negociação ocorre para misturar os pacotes que são transferidos durante a notificação do cliente, que usa SHA-1 ou SHA-2.
Certificados usados pelo Configuration Manager
Para ver uma lista de certificados PKI que podem ser usados pelo Gerenciador de Configurações, requisitos especiais ou limitações e saber como os certificados são usados, consulte Requisitos de certificado PKI para o Configuration Manager. Essa lista inclui os algoritmos de hash e os comprimentos de chave com suporte. A maioria dos certificados tem suporte a SHA-256 e 2048 bits de comprimento de chave.
| Observação |
|---|
Todos os certificados que o Gerenciador de Configurações usa devem conter comente caracteres de byte único no nome da entidade ou no nome alternativo da entidade. |
Certificados PKI são necessários para os seguintes cenários:
Quando você gerencia clientes do Gerenciador de Configurações na Internet.
Quando você gerencia clientes do Gerenciador de Configurações em dispositivos móveis.
Quando você gerencia computadores Mac.
Quando você usa pontos de distribuição com base em nuvem.
Quando você gerencia computadores baseados no Intel AMT fora da banda.
Para a maioria das outras comunicações do Gerenciador de Configurações que requerem certificados para autenticação, assinatura ou criptografia, o Gerenciador de Configurações usa certificados PKI automaticamente se estiverem disponíveis. Se não estiverem disponíveis, o Gerenciador de Configurações irá gerar certificados autoassinados.
O Gerenciador de Configurações não usa certificados PKI quando gerencia dispositivos móveis usando o conector do Exchange Server.
Gerenciamento de dispositivos móveis e certificados PKI
Se o dispositivo móvel não foi bloqueado pelo operador móvel, você pode usar o Gerenciador de Configurações ou o Microsoft Intune para solicitar e instalar um certificado do cliente. Esse certificado fornece autenticação mútua entre o cliente no dispositivo móvel e os sistemas do site do Gerenciador de Configurações ou os serviços do Microsoft Intune. Se o dispositivo móvel estiver bloqueado, você não poderá usar o Gerenciador de Configurações nem o Intune para implantar certificados. Para obter mais informações, consulte Como instalar clientes em dispositivos Windows Mobile e Nokia Symbian usando o Configuration Manager.
Se você habilitar inventário de hardware para dispositivos móveis, o Gerenciador de Configurações ou o Intune também preparará inventários dos certificados instalados no dispositivo móvel.
Gerenciamento fora da banda e certificados PKI
O gerenciamento fora da banda para computadores baseados em Intel AMT usa pelo menos dois tipos de certificados emitidos pela PKI: um certificado de provisionamento AMT e um certificado do servidor Web.
O ponto de serviço fora da banda usa um certificado de provisionamento AMT para preparar computadores para gerenciamento fora da banda. Os computadores AMT que serão provisionados deve confiar no certificado apresentado pelo ponto de gerenciamento fora da banda. Por padrão, os computadores AMT são configurados pelo fabricante do computador para usar CAs (autoridades de certificação), como VeriSign, Go Daddy, Comodo e Starfield. Se você comprar um certificado de provisionamento de uma das CAs externas e configurar o Gerenciador de Configurações para usar esse certificado de provisionamento, os computadores AMT irão confiar na CA do certificado de provisionamento e o provisionamento pode ter êxito. No entanto, é uma prática recomendada secundária usar sua própria CA interna para emitir o certificado de provisionamento AMT. Para obter mais informações, consulte Práticas recomendadas de segurança para gerenciamento fora da banda.
Os computadores AMT executam um componente do servidor Web dentro do firmware e esse componente criptografa o canal de comunicação com o ponto de serviço fora da banda usando TLS (Segurança de Camada de Transporte). Não há nenhuma interface do usuário no AMT BIOS para configurar manualmente um certificado, por isso você deve ter uma autoridade de certificação empresarial da Microsoft que aprove automaticamente as solicitações de certificado de computadores AMT. A solicitação usa PKCS#10 para o formato da solicitação que, por sua vez, usa PKCS#7 para transmitir as informações do certificado para o computador AMT.
Embora o computador AMT seja autenticado para o computador que o gerencia, não há nenhum certificado PKI correspondente do cliente no computador que o gerencia. Em vez disso, essas comunicações usam autenticação Kerberos ou HTTP Digest. Quando HTTP Digest é usado, ele é criptografado usando TLS.
Um tipo de certificado adicional pode ser necessário para gerenciar computadores baseados em AMT fora de banda: um certificado do cliente opcional para redes com fio e sem fio autenticadas pelo 802.1X. O certificado do cliente pode ser solicitado pelo computador AMT para a autenticação para o servidor RADIUS. Quando o servidor RADIUS estiver configurado para autenticação EAP-TLS, sempre será necessário um certificado do cliente. Quando o servidor RADIUS estive configurado para EAP-TTLS/MSCHAPv2 ou PEAPv0/EAP-MSCHAPv2, a configuração RADIUS irá especificar se um certificado do cliente é necessário ou não. Esse certificado é solicitado pelo computador AMT usando os mesmos processos da solicitação do certificado do servidor Web.
Implantação do sistema operacional e certificados PKI
Quando você usa o Gerenciador de Configurações para implantar sistemas operacionais e um ponto de gerenciamento exigir conexões de cliente HTTPS, o computador cliente também deve ter um certificado para se comunicar com o ponto de gerenciamento, mesmo que seja em uma fase de transição, como a inicialização de mídia de sequência de tarefas ou um ponto de distribuição habilitado para PXE. Para oferecer suporte a este cenário, você deve criar um certificado de autenticação de cliente PKI, exportá-lo com a chave privada e, em seguida, importá-lo para as propriedades do servidor do site, além de adicionar o certificados de raiz confiáveis CA do ponto de gerenciamento.
Se você criar uma mídia inicializável, importe o certificado de autenticação de cliente durante a criação da mídia inicializável. Configure uma senha na mídia inicializável para ajudar a proteger a chave privada e outros dados confidenciais configurados na sequência de tarefas. Cada computador que inicia por meio da mídia inicializável apresentará o mesmo certificado ao ponto de gerenciamento, conforme exigido para as funções de cliente, como a solicitação da política do cliente.
Se você usar inicialização PXE, importará o certificado de autenticação do cliente para o ponto de distribuição habilitado para PXE e ele usará o mesmo certificado para cada cliente que iniciar por meio daquele ponto de distribuição habilitado para PXE. Como prática recomendada de segurança, peça que os usuários que conectam seus computadores a um serviço PXE para fornecer uma senha para ajudar a proteger a chave privada e outros dados confidenciais nas sequências de tarefas.
Se um desses certificados de autenticação do cliente estiver comprometido, bloqueie os certificados no nó Certificados no espaço de trabalho Administração, no nó Segurança. Para gerenciar esses certificados, você deve ter direitos para Gerenciar certificado de implantação de sistema operacional.
Depois que o sistema operacional é implantado e o Gerenciador de Configurações é instalado, o cliente exigirá seu próprio certificado PKI de autenticação de cliente para comunicação do cliente HTTPS.
Soluções de Proxy de ISV e certificados PKI
ISVs (Fornecedores de Software independentes) podem criar aplicativos que estendem o Gerenciador de Configurações. Por exemplo, um ISV pode criar extensões para dar suporte a plataformas de cliente não Windows, como computadores Macintosh ou UNIX. No entanto, se os sistemas de sites exigirem conexões de cliente HTTPS, esses clientes também devem usar certificados PKI para a comunicação com o site. O Gerenciador de Configurações inclui a capacidade de atribuir um certificado ao proxy de ISV que permite a comunicação entre os clientes de proxy de ISV e o ponto de gerenciamento. Se você usa extensões que requerem certificados de proxy de ISV, consulte a documentação do produto. Para mais informações sobre como criar certificados de proxy de ISV, consulte o SDK (Software Developer Kit) do Gerenciador de Configurações.
Se um desses certificados ISV estiver comprometido, bloqueie os certificados no nó Certificados no espaço de trabalho Administração, no nó Segurança.
Asset Intelligence e certificados
O Gerenciador de Configurações instala um certificado X.509 usado pelo ponto de sincronização do Asset Intelligence para se conectar à Microsoft. O Gerenciador de Configurações usa este certificado para solicitar um certificado de autenticação de cliente do serviço de certificado da Microsoft. O certificado de autenticação do cliente é instalado no servidor de sistema de site do ponto de sincronização do Asset Intelligence e é usado para autenticar o servidor na Microsoft. O Configuration Manager usa o certificado de autenticação do cliente para baixar o catálogo do Asset Intelligence e carregar os títulos do software.
Esse certificado tem um comprimento de chave de 1.024 bits.
Pontos de distribuição e certificados baseados em nuvem
A partir do System Center 2012 Configuration Manager SP1, os pontos de distribuição baseados em nuvem exigem um certificado de gerenciamento (autoassinado ou PKI) que você carrega no Microsoft Azure. Esse certificado de gerenciamento requer recursos de autenticação de servidor e um comprimento de chave de certificado de 2.048 bits. Além disso, você deve configurar um certificado de serviço para cada ponto de distribuição baseado em nuvem, que não pode ser autoassinado, mas também tenha recurso de autenticação de servidor e um comprimento mínimo de chave de certificado de 2.048 bits.
| Observação |
|---|
O certificado de gerenciamento autoassinado é para fins apenas de teste e não para uso em redes de produção. |
Os clientes não necessitam de um certificado PKI para usar os pontos de distribuição baseados em nuvem; eles se autenticam no gerenciamento usando um certificado autoassinado ou um certificado PKI de cliente. O ponto de gerenciamento emite então um token de acesso ao Gerenciador de Configurações ao cliente, que o cliente apresenta ao ponto de distribuição baseado em nuvem. O token é válido por 8 horas.
O conector e os certificados do Microsoft Intune
Quando o Microsoft Intune registra dispositivos móveis, você pode gerenciá-los no Gerenciador de Configurações criando um conector do Microsoft Intune. O conector usa um certificado de autenticação PKI com recurso de autenticação de cliente para autenticar o Gerenciador de Configurações no Microsoft Intune e transferir todas as informações entre eles usando SSL. O tamanho da chave do certificado é de 2.048 bits e usa o algoritmo de hash SHA-1.
Ao instalar o conector, um certificado de assinatura é criado e armazenado no servidor do site para as chaves de sideload, e um certificado de criptografia é criado e armazenado no ponto de registro de certificado a fim de criptografar o desafio do Protocolo SCEP. Esses certificados também têm um tamanho de chave de 2048 bits e usam o algoritmo de hash SHA-1.
Quando o Intune registra dispositivos móveis, ele instala um certificado PKI no dispositivo móvel. Esse certificado tem recurso de autenticação do cliente, usa um tamanho de chave de 2.048 bits e usa o algoritmo de hash SHA.
Esses certificados PKI são solicitados automaticamente, gerados e instalados pelo Microsoft Intune.
Verificação CRL de certificados PKI
Uma CRL (Lista de Certificados Revogados) aumenta a sobrecarga administrativa e o processamento, mas é mais segura. No entanto, se a verificação de CRL estiver habilitada, mas a CRL estiver inacessível, a conexão de PKI falhará. Para obter mais informações, veja a seção Planejando a revogação de certificados PKI no tópico Planejando a segurança no Configuration Manager.
A verificação da CRL é habilitada por padrão no IIS, por isso, se você estiver usando uma CRL com a implantação de PKI, não há nada adicional para configurar na maioria dos sistemas de site do Gerenciador de Configurações que executa IIS. A exceção são as atualizações de software, que requerem uma etapa manual para permitir a verificação da CRL para verificar as assinaturas nos arquivos de atualização de software.
A verificação da CRL é habilitada por padrão em computadores cliente quando eles usam conexões de cliente HTTPS. A verificação da CRL não é habilitada por padrão quando você executa o console de gerenciamento fora da faixa para se conectar a um computador baseado em AMT, e você pode habilitar essa opção. Não é possível desabilitar a verificação CRL para clientes em computadores Mac no Gerenciador de Configurações SP1 ou posterior.
A verificação da CRL não tem suporte nas seguintes conexões do Gerenciador de Configurações:
Conexões de servidor para servidor.
Dispositivos móveis registrados pelo Gerenciador de Configurações.
Dispositivos móveis registrados pelo Microsoft Intune.
Controles de criptografia para a comunicação do servidor
O Gerenciador de Configurações usa os seguintes controles de criptografia para comunicação do servidor.
Comunicação do servidor dentro de um site
Cada servidor do sistema de site usa um certificado para transferir dados para outros sistemas de site no mesmo site do Gerenciador de Configurações. Algumas funções do sistema de site 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 um ao outro usando este certificado de identidade. Quando o Gerenciador de Configurações usa um certificado para essa comunicação, se houver um certificado PKI disponível com recurso de autenticação do servidor, o Gerenciador de Configurações o usará automaticamente. Se não, o Gerenciador de Configurações gerará um certificado autoassinado. Este certificado autoassinado tem uma funcionalidade de autenticação de servidor, usa o SHA-256 e tem um comprimento de chave de 2.048 bits. O Gerenciador de Configurações copia o certificado no repositório de Pessoas Confiáveis nos outros servidores do sistema de sites que podem precisar confiar no sistema de sites. Os sistemas de site, então, podem confiar um outro usando esses certificados e PeerTrust.
Além desse certificado para cada servidor do sistema de site, o Gerenciador de Configurações 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 site no mesmo site, elas compartilham o mesmo certificado. Por exemplo, você pode ter vários pontos de gerenciamento ou vários pontos de registro no mesmo site. Este certificado autoassinado também usa o SHA-256 e tem um comprimento de chave de 2.048 bits. Ele também é copiado no armazenamento de pessoas confiáveis nos servidores do sistema de site que podem precisar confiar nele. As seguintes funções do sistema de site geram este certificado:
Ponto de serviços Web do Catálogo de Aplicativos
Ponto de sites da Web do catálogo de aplicativos
Ponto de sincronização do Asset Intelligence
Ponto de registro de certificado
Ponto do Endpoint Protection
Ponto de registro
Ponto de status de fallback
Ponto de gerenciamento
Ponto de distribuição habilitado para multicast
Ponto de serviço fora da banda
Ponto do Reporting Services
Ponto de atualização de software
Ponto de migração de estado
Ponto do Validador da Integridade do Sistema
Conector do Microsoft Intune
Esses certificados são gerenciados automaticamente pelo Gerenciador de Configurações, e, quando necessário, são gerados automaticamente.
O Gerenciador de Configurações também usa um certificado de autenticação de cliente para enviar mensagens de status do ponto de distribuição para o ponto de gerenciamento. Quando o ponto de gerenciamento é configurado para conexões de cliente HTTPS somente, você deve usar um certificado PKI. Se o ponto de gerenciamento aceitar conexões HTTP, você pode usar um certificado PKI ou selecionar a opção para usar um certificado autoassinado com recurso de autenticação do cliente, SHA-256, e com um comprimento de chave de 2.048 bits.
Comunicação de servidor entre sites
O Gerenciador de Configurações 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 Referência técnica para comunicações local no Configuration Manager.
O Gerenciador de Configurações configura automaticamente a replicação de dados entre os sites e usa certificados PKI com recurso de autenticação de servidor se estiverem disponíveis; se não, o Gerenciador de Configurações cria certificados autoassinados para autenticação do servidor. Em ambos os casos, a autenticação entre os sites é estabelecida pelo uso de certificados no armazenamento de Pessoas Confiáveis que usam o PeerTrust. Esse armazenamento de certificados é usado para garantir que apenas computadores SQL Server usados pela hierarquia do Gerenciador de Configurações participem da replicação entre sites. Considerando que os sites primários e o site de administração central podem replicar alterações de configuração em todos os sites na hierarquia, os sites secundários só podem replicar alterações de configuração em seu site pai.
Servidores de site estabeleçam comunicação entre sites usando uma troca segura de chaves 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 forem iguais, o site receptor aceitará os dados replicados. Se os valores não coincidirem, o Gerenciador de Configurações rejeitará os dados de replicação.
Replicação de dados no Gerenciador de Configurações utiliza o SQL Server Service Broker para transferir dados entre sites usando os seguintes mecanismos:
Conexão entre SQL Servers: Usa as credenciais do Windows para autenticação do servidor e certificados autoassinados com 1.024 bits para assinar e criptografar os dados usando AES (Advanced Encryption Standard). Se houver certificados PKI com recurso de autenticação de servidor, esses serão usados. O certificado deve estar localizado no armazenamento pessoal de certificados do computador.
SQL Service Broker: Usa certificados autoassinados com 2.048 bits para autenticação e para assinar e criptografar os dados usando AES (Advanced Encryption Standard). O certificado deve estar localizado no banco de dados mestre do SQL Server.
Replicação baseada em arquivo usa o protocolo SMB (Server Message Block) e usa SHA-256 para assinar esses dados que não são criptografados, mas não contêm dados confidenciais. Se você quiser criptografar esses dados, pode usar o IPsec e deve implementar isso independentemente do Gerenciador de Configurações.
Controles de criptografia para clientes que usam comunicação HTTPS para sistemas de site
Quando as funções do sistema de site aceitam conexões de clientes, você pode configurá-las para aceitar conexões HTTPS e HTTP, ou apenas as conexões HTTPS. Funções do sistema de site que aceitam conexões da Internet só aceitam conexões de cliente via HTTPS.
Conexões do cliente em HTTPS oferecem maior nível de segurança pela integração com uma PKI para ajudar a proteger a comunicação cliente-servidor. No entanto, a configuração de conexões do cliente HTTPS sem uma compreensão completa de planejamento, implantação e operações de PKI ainda poderiam deixá-lo vulnerável. Por exemplo, se você não proteger sua raiz CA, os invasores podem comprometer a confiança de toda a sua infraestrutura de PKI. Deixar de implantar e gerenciar certificados PKI usando processos controlados e seguros pode resultar em clientes não gerenciados que não podem receber atualizações críticas de software ou pacotes.
| Importante |
|---|
Certificados PKI usados para comunicação com o 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 do site. |
Comunicação não criptografada quando os clientes usam comunicação HTTPS
Quando os clientes se comunicam com sistemas de site usando HTTPS, as comunicações geralmente são criptografadas pelo SSL. No entanto, nas situações a seguir, o clientes se comunicam com sistemas de site sem usar criptografia:
O cliente não consegue fazer uma conexão HTTPS na intranet e voltará a usar HTTP quando os sistemas de site permitirem essa configuração
Comunicação com as seguintes funções do sistema de site:
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
Pontos de serviços de relatório são configurados para usar HTTP ou HTTPS, independentemente do modo de comunicação do cliente.
Controles de criptografia para clientes que usam comunicação HTTP para sistemas de site
Quando os clientes usam comunicação HTTP para funções do sistema de site, eles podem usar certificados PKI para autenticação do cliente, ou certificados autoassinados que o Gerenciador de Configurações gera. Quando o Gerenciador de Configurações gera certificados autoassinados, eles possuem um identificador de objeto personalizado para assinatura e criptografia e esses certificados são usados exclusivamente para identificar o cliente. Para todos os sistemas operacionais com suporte exceto o Windows Server 2003, esses certificados autoassinados usam o SHA-256 e têm comprimento de chave de 2048 bits. Para o Windows Server 2003, o SHA1 é usado com um comprimento de chave de 1024 bits.
Implantação do sistema operacional e certificados autoassinados
Quando você usa o Gerenciador de Configurações para implantar sistemas operacionais com certificados autoassinados, o computador cliente também deve ter um certificado para se comunicar com o ponto de gerenciamento, mesmo que o computador esteja em uma fase de transição, como inicialização de mídia de sequência de tarefas ou um ponto de distribuição habilitado para PXE . Para dar suporte a este cenário para conexões de cliente HTTP, o Gerenciador de Configurações gera certificados autoassinados que possuem um identificador de objeto personalizado para assinatura e criptografia e esses certificados são usados exclusivamente para identificar o cliente. Para todos os sistemas operacionais com suporte exceto o Windows Server 2003, esses certificados autoassinados usam o SHA-256 e têm comprimento de chave de 2048 bits. Para o Windows Server 2003, o SHA1 é usado com um comprimento de chave de 1024 bits. Se esses certificados autoassinados estiverem comprometidos, para evitar que invasores os usem para representar clientes confiáveis, será necessário bloquear os certificados no nó Certificados no espaço de trabalho Administração, nó Segurança.
Autenticação de servidor e cliente
Quando os clientes se conectam via HTTP, eles autenticam os pontos de gerenciamento usando os Serviços de Domínio Active Directory ou usando a chave de raiz confiável do Gerenciador de Configurações. Clientes não autenticam outras funções do sistema de site, como pontos de migração de estado ou pontos de atualização de software.
Quando um ponto de gerenciamento primeiro autentica um cliente usando o certificado de cliente autoassinado, esse mecanismo fornece segurança mínima, pois qualquer computador pode gerar um certificado autoassinado. Nesse cenário, o processo de identidade do cliente deve ser aumentado pela aprovação. Somente computadores confiáveis devem ser aprovados, automaticamente pelo Gerenciador de Configurações ou manualmente por um usuário administrativo. Para obter mais informações, consulte a seção de aprovação em Comunicações iniciadas por clientes.
Sobre as vulnerabilidades do SSL
Recomendamos a desabilitação do SSL 3.0, a habilitação do TLS 1.1 e 1.2 e a reordenação de pacotes de codificação relacionados ao TLS, para melhorar a segurança dos servidores do Configuration Manager. É possível saber como executar estas ações neste artigo da base de dados. Esta ação não afetará a funcionalidade do Configuration Manager.