Planejar a segurança no Gerenciador de Configurações

Aplica-se a: Gerenciador de Configurações (branch atual)

Este artigo descreve os seguintes conceitos a serem considerados ao planejar a segurança com a implementação do Gerenciador de Configurações:

• Certificados (autoassinados e PKI)

• A chave raiz confiável

• Assinatura e criptografia

• Administração baseada em funções

• Microsoft Entra ID

• Autenticação de Provedor SMS

Antes de começar, familiarize-se com os conceitos básicos de segurança no Gerenciador de Configurações.

Certificados

O Gerenciador de Configurações usa uma combinação de certificados digitais autoassinados e PKI (infraestrutura de chave pública). Use certificados PKI sempre que possível. Alguns cenários requerem certificados PKI. Quando os certificados PKI não estão disponíveis, o site gera automaticamente certificados autoassinados. Alguns cenários sempre usam certificados autoassinados.

Para obter mais informações, consulte Planejar certificados.

A chave raiz confiável

A chave raiz confiável do Gerenciador de Configurações fornece um mecanismo para que os clientes do Gerenciador de Configurações verifiquem se os sistemas de sites pertencem à sua hierarquia. Cada servidor de site gera uma chave de troca de site para se comunicar com outros sites. A chave de troca de sites do site de nível superior na hierarquia é chamada de chave raiz confiável.

A função da chave raiz confiável no Gerenciador de Configurações é semelhante a um certificado raiz em uma infraestrutura de chave pública. Qualquer coisa assinada pela chave privada da chave raiz confiável é confiável mais abaixo na hierarquia. Os clientes armazenam uma cópia da chave raiz confiável do site no root\ccm\locationservices namespace WMI.

Por exemplo, o site emite um certificado para o ponto de gerenciamento, que ele assina com a chave privada da chave raiz confiável. O site compartilha com os clientes a chave pública de sua chave raiz confiável. Em seguida, os clientes podem diferenciar entre pontos de gerenciamento que estão em sua hierarquia e pontos de gerenciamento que não estão em sua hierarquia.

Os clientes obtêm automaticamente a cópia pública da chave raiz confiável usando dois mecanismos:

• Você estende o esquema do Active Directory para o Gerenciador de Configurações e publica o site no Active Directory Domain Services. Em seguida, os clientes recuperam essas informações do site de um servidor de catálogo global. Para obter mais informações, consulte Preparar o Active Directory para publicação em site.

• Ao instalar clientes usando o método de instalação por push do cliente. Para obter mais informações, consulte Instalação de push do cliente.

Se os clientes não conseguirem obter a chave raiz confiável usando um desses mecanismos, eles confiarão na chave raiz confiável fornecida pelo primeiro ponto de gerenciamento com o qual se comunicam. Nesse cenário, um cliente pode ser direcionado incorretamente para o ponto de gerenciamento de um invasor, onde receberia a política do ponto de gerenciamento fraudulento. Essa ação requer um invasor sofisticado. Esse ataque é limitado ao curto período de tempo antes que o cliente recupere a chave raiz confiável de um ponto de gerenciamento válido. Para reduzir o risco de um invasor direcionar incorretamente os clientes para um ponto de gerenciamento fraudulento, provisione previamente os clientes com a chave raiz confiável.

Para obter mais informações e procedimentos para gerenciar a chave raiz confiável, consulte Configurar segurança.

Assinatura e criptografia

Ao usar certificados PKI para todas as comunicações do cliente, você não precisa planejar a assinatura e a criptografia para ajudar a proteger a comunicação de dados do cliente. Se você configurar algum sistema de site que executa o IIS para permitir conexões de cliente HTTP, decida como ajudar a proteger a comunicação do cliente para o site.

Para ajudar a proteger os dados que os clientes enviam aos pontos de gerenciamento, é possível exigir que os clientes assinem os dados. Você também pode exigir o algoritmo SHA-256 para assinatura. Essa configuração é mais segura, mas não requer SHA-256, a menos que todos os clientes ofereçam suporte. Muitos sistemas operacionais suportam nativamente esse algoritmo, mas sistemas operacionais mais antigos podem exigir uma atualização ou um hotfix.

Embora a assinatura ajude a proteger os dados contra adulteração, a criptografia ajuda a proteger os dados contra a divulgação de informações. Você pode habilitar a criptografia para os dados de inventário e mensagens de estado que os clientes enviam para pontos de gerenciamento no site. Você não precisa instalar nenhuma atualização nos clientes para dar suporte a essa opção. Clientes e pontos de gerenciamento exigem mais uso da CPU para criptografia e descriptografia.

Para obter mais informações sobre como definir as configurações de assinatura e criptografia, consulte Configurar assinatura e criptografia.

Para obter mais informações sobre os algoritmos criptográficos usados para assinatura e criptografia, consulte Referência técnica de controles criptográficos.

Administração baseada em funções

Com o Gerenciador de Configurações, você usa a administração baseada em função para proteger o acesso que os usuários administrativos precisam para usar o Gerenciador de Configurações. Você também protege o acesso aos objetos que gerencia, como coleções, implantações e sites.

Com a combinação de funções de segurança, escopos de segurança e coleções, você separa as atribuições administrativas que atendem aos requisitos da sua organização. Usados juntos, eles definem o escopo administrativo de um usuário. Esse escopo administrativo controla os objetos que um usuário administrativo exibe no console do Gerenciador de Configurações e controla as permissões que um usuário tem sobre esses objetos.

Para obter mais informações, consulte Fundamentos da administração baseada em funções.

Microsoft Entra ID

O Gerenciador de Configurações se integra ao Microsoft Entra ID para permitir que o site e os clientes usem autenticação moderna.

Para obter mais informações sobre o Microsoft Entra ID, consulte a documentação do Microsoft Entra.

A integração de seu site com o Microsoft Entra ID dá suporte aos seguintes cenários do Gerenciador de Configurações:

Cenários do cliente

• Gerenciar clientes na Internet por meio do gateway de gerenciamento de nuvem

• Gerenciar dispositivos ingressados no domínio de nuvem

• Cogerenciamento

• Implantar aplicativos disponíveis para o usuário

• Aplicativos online da Microsoft Store para Empresas

• Gerenciar o Microsoft 365 Apps para Grandes Empresas

Cenários do servidor

• Anexar locatário

• Análise de ponto de extremidade

• Análise de Logs do Azure

• Centro da Comunidade

• Descoberta do usuário

Autenticação de Provedor SMS

Você pode especificar o nível mínimo de autenticação para os administradores acessarem os sites do Gerenciador de Configurações. Esse recurso impõe que os administradores entrem no Windows com o nível necessário antes de poderem acessar o Gerenciador de Configurações. Ela se aplica a todos os componentes que acessam o provedor de SMS. Por exemplo, o console do Gerenciador de Configurações, métodos SDK e cmdlets do Windows PowerShell.

O Gerenciador de Configurações dá suporte aos seguintes níveis de autenticação:

• autenticação do Windows: exigir autenticação com credenciais de domínio do Active Directory. Esta configuração é o comportamento anterior e a configuração padrão atual.

• Autenticação de certificado: exija autenticação com um certificado válido emitido por uma autoridade de certificação PKI confiável. Você não configura esse certificado no Gerenciador de Configurações. O Gerenciador de Configurações requer que o administrador esteja conectado ao Windows usando a PKI.

• Autenticação do Windows Hello para Empresas: exija autenticação com autenticação forte de dois fatores vinculada a um dispositivo e que use biometria ou um PIN. Para obter mais informações, consulte Windows Hello para Empresas.

  Importante

  Quando você seleciona essa configuração, o Provedor SMS e o serviço de administração exigem que o token de autenticação do usuário contenha uma declaração de MFA (autenticação multifator) do Windows Hello para Empresas. Em outras palavras, um usuário do console, do SDK, do PowerShell ou do serviço de administração precisa se autenticar no Windows com seu PIN ou biometria do Windows Hello para Empresas. Caso contrário, o site rejeita a ação do usuário.

  Esse comportamento é para o Windows Hello para Empresas, não para o Windows Hello.

Para obter mais informações sobre como definir essa configuração, consulte Configurar autenticação de provedor SMS.

Próximas etapas

• Certificados no Gerenciador de Configurações

• Planejar certificados PKI

• Configurar a segurança

• Referência técnica de controles criptográficos