Planejando a segurança 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

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.

Use as informações a seguir para ajudá-lo a planejar a segurança no Microsoft System Center 2012 Configuration Manager.

• Planejando certificados (autoassinados e PKI)

  • Planejando a revogação de certificados PKI

  • Planejando certificados PKI de raiz confiável e a lista de emissores de certificados

  • Planejando a seleção de certificado PKI de cliente

  • Planejando uma estratégia de transição para certificados PKI e gerenciamento de clientes baseados na Internet

• Planejando a chave de raiz confiável

• Planejando para assinatura e criptografia

• Planejando a administração baseada em funções

Além dessas seções, consulte Segurança e privacidade para administração de site no Configuration Manager.

Para obter informações adicionais sobre como o Gerenciador de Configurações usa certificados e controles criptográficos, consulte Referência técnica para controles de criptografia usados no Configuration Manager.

Planejando certificados (autoassinados e PKI)

O Gerenciador de Configurações usa uma combinação de certificados autoassinados e certificados PKI (infraestrutura de chave pública).

Como prática recomendada de segurança, use certificados PKI sempre que possível. Para obter mais informações sobre os requisitos de certificado PKI, consulte Requisitos de certificado PKI para o Configuration Manager. Quando o Gerenciador de Configurações solicita certificados PKI, como durante o registro de dispositivos móveis e provisionamento AMT, você deve usar os Serviços de Domínio Active Directory e uma autoridade de certificação corporativa. Para todos os outros certificados PKI, você deve implantar e gerenciá-los independentemente do Gerenciador de Configurações.

Os certificados PKI também são solicitados quando computadores cliente se conectam a sistemas de áreas baseados na Internet, e recomenda-se usá-los quando os clientes se conectam a sistemas de site que executam o IIS (Serviços de Informações da Internet). Para obter mais informações sobre comunicação do cliente, consulte Planejando comunicação do cliente no Configuration Manager.

Quando você usa uma PKI, também pode usar IPsec para ajudar a proteger a comunicação de servidor para servidor entre sistemas de site em um site e entre sites, e para qualquer cenário quando você transferir dados entre computadores. Você deve configurar e implementar o IPsec independentemente do Gerenciador de Configurações.

O Gerenciador de Configurações gerar automaticamente certificados autoassinados quando certificados PKI não estiverem disponíveis, e alguns certificados no Gerenciador de Configurações são sempre autoassinados. Na maioria dos casos, o Gerenciador de Configurações gerencia automaticamente os certificados autoassinados, e você não precisa tomar uma ação adicional. Uma possível exceção é o certificado de autenticação do servidor do site. O certificado de autenticação do servidor do site é sempre autoassinado e assegura que as políticas do cliente que os clientes baixam do ponto de gerenciamento foram enviadas do servidor do site e não foram violadas.

Planejando o certificado de autenticação (autoassinado) do servidor do site

Os clientes podem obter com segurança uma cópia do certificado de autenticação do servidor do site dos Serviços de Domínio Active Directory e da instalação do cliente por push. Se os clientes não conseguirem obter uma cópia do certificado de autenticação do servidor do site usando um desses mecanismos, como prática recomendada de segurança, instale uma cópia do certificado de autenticação do servidor do site ao instalar o cliente. Isso é especialmente importante se a primeira comunicação do cliente com o site for da Internet, pois o ponto de gerenciamento está conectado a uma rede não confiável e, portanto, vulnerável a ataque. Se você não seguir essa etapa adicional, os clientes baixarão automaticamente uma cópia do certificado de autenticação do servidor do site do ponto de gerenciamento.

Os cenários nos quais os clientes não conseguem obter com segurança uma cópia do certificado do servidor do site incluem o seguinte:

• Você não instala o cliente usando o push de cliente, e nenhuma das condições a seguir é verdadeira:

  • O esquema do Active Directory não foi estendido para o Gerenciador de Configurações.

  • O site do cliente não é publicado nos Serviços de Domínio Active Directory.

  • O cliente é de uma floresta ou de um grupo de trabalho não confiável.

• Você instala o cliente quando ele está na Internet.

Use o procedimento a seguir para instalar clientes junto com uma cópia do certificado de autenticação do servidor do site.

Para instalar clientes com uma cópia do certificado de autenticação do servidor do site

1. Localize o certificado de autenticação do servidor do site no servidor do site principal do cliente. O certificado é armazenado no repositório de certificados SMS e tem como nome da Entidade Servidor do Site e como nome amigável Certificado de Autenticação do Servidor do Site.

2. Exporte o certificado sem a chave privada, armazene o arquivo com segurança e acesso-o somente de um canal protegido (por exemplo, usando assinatura SMB ou IPsec).

3. Instale o cliente usando a propriedade de Client.msi SMSSIGNCERT=<Caminho completo e nome do arquivo> com o CCMSetup.exe.

Planejando a revogação de certificados PKI

Ao usar certificados PKI com o Gerenciador de Configurações, planeje como e se os clientes e servidores usarão uma CRL (lista de certificados revogados) para verificar o certificado no computador que está se conectando. A CRL é um arquivo criado e assinado por uma CA (autoridade de certificação) e contém uma lista de certificados emitidos, mas revogados. Os certificados podem ser revogados por um administrador da CA, por exemplo, se um certificado emitido for conhecido ou tiver suspeita estar comprometido.

Importante
Como o local da CRL é adicionada ao certificado quando ele é emitido por uma CA, assegure o planejamento da CRL antes de implantar quaisquer certificados PKI que o Gerenciador de Configurações usará.

Por padrão, o IIS sempre verifica a CRL para certificados de cliente, e você não pode alterar essa configuração no Gerenciador de Configurações. Por padrão, os clientes do Gerenciador de Configurações sempre verificam a CRL para sistemas de site; no entanto, você pode desabilitar essa configuração especificando uma propriedade do site e uma propriedade CCMSetup. Ao gerenciar computadores Intel AMT fora de banda, você também pode habilitar a verificação da CRL para o ponto de serviço fora de banda e para computadores que executam o console de gerenciamento fora de banda.

Se os computadores usam a verificação de revogação de certificados, mas não podem localizar a CRL, eles se comportam como se todos os certificados na cadeia de certificados fossem revogados, pois sua ausência da lista não pode ser verificada. Nesse cenário, todas as conexões que requerem certificados e usam uma CRL falham.

A verificação da CRL sempre que um certificado é usado oferece mais segurança contra o uso de um certificado revogado, mas gera atraso de conexão e processamento adicional no cliente. É mais provável que você solicite essa verificação de segurança adicional quando os clientes estão na Internet ou em uma rede não confiável.

Consulte seus administradores PKI antes de decidir se os clientes do Gerenciador de Configurações devem verificar a CLR; em seguida, considere manter essa opção habilitada no Gerenciador de Configurações quando ambas das seguintes condições forem verdadeiras:

• Sua infraestrutura PKI oferece suporte a uma CRL e é publicada onde todos os clientes do Gerenciador de Configurações podem localizá-la. Lembre-se que isso poderá incluir clientes na Internet se você estiver usando gerenciamento de clientes baseado na Internet e clientes em florestas não confiáveis.

• O requisito para verificar a CRL para cada conexão a um sistema de site configurado para usar um certificado PKI é maior do que o requisito para conexões mais rápidas e eficientes que são processadas no cliente, e também é maior do que o risco de os clientes não conseguirem se conectar a servidores se eles não puderem localizar a CRL.

Planejando certificados PKI de raiz confiável e a lista de emissores de certificados

Se os sistemas de site do IIS usam certificados de cliente PKI para autenticação do cliente via HTTP ou para autenticação do cliente e criptografia via HTTPS, você deve importar certificados de CA raiz como uma propriedade do site. Os dois cenários são os seguintes:

• Você implanta sistemas operacionais usando o Gerenciador de Configurações, e os pontos de gerenciamento só aceitam conexões de cliente HTTPS.

• Você usa certificados de cliente PKI que não se encadeiam a um certificado de autoridade de certificação raiz que é confiável por pontos de gerenciamento.

  Observação
  Ao emitir certificados PKI de clientes da mesma hierarquia de CA que emite os certificados do servidor que você usa para pontos de gerenciamento, você não precisa especificar esse certificado de CA raiz. No entanto, se você usar várias hierarquias de CA e não tiver certeza se elas têm confiança entre si, importe a CA raiz para a hierarquia de CA dos clientes.

Se você tiver de importar certificados de CA raiz para o Gerenciador de Configurações, exporte-os da CA emissora ou do computador cliente. Se você exportar o certificado da CA emissora que também é a CA raiz, verifique se a chave privada não foi exportada. Armazene o arquivo de certificado exportado em um local seguro para impedir a violação. Você deve ser capaz de acessar o arquivo ao configurar o site; assim, se você acessar o arquivo pela rede, verifique se a comunicação está protegida contra violação usando a assinatura SMB ou IPsec.

Se algum dos certificados de CA raiz que você importa for renovado, você deverá importar os certificados renovados.

Esses certificados de CA raiz importados e o certificado de CA raiz de cada ponto de gerenciamento criam a lista de emissores do certificado que o computador do Gerenciador de Configurações usa das seguintes maneiras:

• Quando clientes se conectam a pontos de gerenciamento, o ponto de gerenciamento verifica se o certificado do cliente se encadeia a um certificado de raiz confiável na lista de emissores do certificado do site. Caso não se encadeie, o certificado será rejeitado e ocorrerá falha na conexão PKI.

• Quando clientes selecionam um certificado PKI, se eles tiverem uma lista de emissores do certificado, eles selecionam um certificado que se encadeie a um certificado de raiz confiável na lista de emissores do certificado. Se não houver nenhuma correspondência, o cliente não selecionará um certificado PKI. Para obter mais informações sobre o processo de certificado de cliente, consulte a seção Planejando a seleção de certificado PKI de cliente neste tópico.

Independentemente da configuração do site, você também pode precisar importar um certificado de CA raiz ao registrar dispositivos móveis ou computadores Mac e ao provisionar computadores Intel AMT para redes sem fio.

Planejando a seleção de certificado PKI de cliente

Se os sistemas de site do IIS usarem certificados de cliente PKI para autenticação via HTTP ou para autenticação do cliente e criptografia via HTTPS, planeje como os clientes Windows selecionarão o certificado para usá-lo para o Gerenciador de Configurações.

Observação
Nem todos os dispositivos oferecem suporte ao método de seleção de certificado, mas, em vez disso, selecionam automaticamente o primeiro certificado que preencha os requisitos do certificado. Por exemplo, clientes em computadores Mac e dispositivos móveis não oferecem suporte a um método de seleção de certificado.

Em muitos casos, a configuração padrão e o comportamento serão suficientes. O Gerenciador de Configurações cliente em computadores Windows filtra vários certificados usando os seguintes critérios:

1. A lista de emissores do certificado: o certificado está encadeado a uma autoridade de certificação raiz confiável pelo ponto de gerenciamento.

2. O certificado está no repositório de certificados padrão Pessoal.

3. O certificado é válido, não revogado e não expirou. A verificação da validade inclui verificar se a chave privada é acessível e se o certificado não foi criado usando um modelo de certificado versão 3, que não é compatível com o Gerenciador de Configurações.

4. O certificado tem um recurso de autenticação do cliente ou é emitido para o nome do computador.

5. O certificado tem o período de validade mais longo.

Os clientes podem ser configurados para usar a lista de emissores do certificado por meio dos seguintes mecanismos:

• Ele é publicado como informações do site do Gerenciador de Configurações para os Serviços de Domínio Active Directory.

• Os clientes são instalados usando a instalação por push.

• Os clientes baixam o certificado do ponto de gerenciamento, depois que eles são atribuídos com êxito ao site.

• Ele é especificado durante a instalação do cliente, como uma propriedade CCMSetup client.msi de CCMCERTISSUERS.

Se os clientes não tiverem a lista de emissores do certificado quando forem instalados pela primeira vez e ainda não estiverem atribuídos ao site, eles irão ignorar essa verificação. Quando eles tiverem a lista de emissores do certificado e não tiverem um certificado PKI que se encadeie a um certificado de raiz confiável na lista de emissores do certificado, ocorrerá falha na seleção do certificado, e os clientes não continuarão com os outros critérios de seleção do certificado.

Na maioria dos casos, o cliente do Gerenciador de Configurações identifica corretamente um certificado PKI único e apropriado a ser usado. No entanto, quando esse não for o caso, em vez de selecionar o certificado baseado no recurso de autenticação do cliente, você pode configurar dois métodos de seleção alternativos:

• Uma correspondência parcial de cadeia de caracteres no nome da entidade do certificado do cliente. Essa é uma correspondência que não diferencia maiúscula de minúsculas e apropriada se você está usando o FQDN (nome de domínio totalmente qualificado) de um computador no campo da entidade e deseja que a seleção do certificado seja baseada no sufixo do domínio, por exemplo, contoso.com. Entretanto, você pode usar esse método de seleção para identificar alguma cadeia de caracteres sequencial no nome da entidade do certificado que diferencia o certificado dos outros no repositório de certificados do cliente.

  Observação

  Você não pode usar a correspondência parcial de cadeia de caracteres com o SAN (Nome de Alternativo da Entidade) como uma configuração do site. Embora você possa especificar uma correspondência parcial de cadeia de caracteres para o SAN usando CCMSetup, ela será substituída pelas propriedades do site nos seguintes cenários: Clientes recuperam informações do site que são publicadas nos Serviços de Domínio Active Directory. Clientes são instalados por push. Use uma correspondência parcial de cadeia de caracteres na SAN somente ao instalar clientes manualmente e quando eles não recuperarem informações de site dos Serviços de Domínio Active Directory. Por exemplo, essas condições só se aplicam a clientes da Internet.

• Uma correspondência nos valores de atributo de nome da Entidade do certificado do cliente ou valores de atributo da SAN (Nome Alternativo da Entidade). Essa é uma correspondência com diferenciação de maiúsculas e minúsculas que é apropriada se você estiver usando um nome diferenciado X500 ou OIDs (Identificadores de Objeto) equivalentes em conformidade com a RFC 3280, e se desejar que a seleção do certificado seja baseada em valores de atributos. Você só pode especificar os atributos e seus valores necessários para identificar ou validar com exclusividade o certificado e diferenciá-lo de outros no armazenamento de certificados.

A tabela a seguir mostra os valores de atributo que o Gerenciador de Configurações suporta como critérios de seleção de certificado do cliente.

Atributo OID	Atributo de nome diferenciado	Definição de atributo
0.9.2342.19200300.100.1.25	DC	Componente do domínio
1.2.840.113549.1.9.1	E ou email	Endereço de e-mail
2.5.4.3	CN	Nome comum
2.5.4.4	SN	Nome da entidade
2.5.4.5	SERIALNUMBER	Número de série
2.5.4.6	C	Código do país
2.5.4.7	L	Localidade
2.5.4.8	S ou ST	Nome do estado ou província
2.5.4.9	RUA	Endereço
2.5.4.10	O	Nome da organização
2.5.4.11	OU	Unidade organizacional
2.5.4.12	T ou Título	Título
2.5.4.42	G ou GN ou GivenName	Nome
2.5.4.43	I ou Iniciais	Iniciais
2.5.29.17	(nenhum valor)	Nome alternativo da entidade

Se mais de um certificado apropriado for localizado após a aplicação dos critérios de seleção, você poderá substituir a configuração padrão para selecionar o certificado com o período de validade mais longo e, em vez disso, especificar que nenhum certificado foi selecionado. Neste cenário, o cliente não será capaz de se comunicar com sistemas de site IIS usando um certificado PKI. O cliente envia uma mensagem de erro ao seu ponto de status de fallback atribuído para alertá-lo sobre a falha na seleção do certificado para que você possa modificar ou aperfeiçoar seus critérios de seleção. O comportamento do cliente, então, depende se a falha da conexão foi em HTTPS ou HTTP:

• Se a conexão falhou em HTTPS: O cliente tenta fazer uma conexão via HTTP e usa seu certificado autoassinado.

• Se a conexão falhou em HTTP: O cliente tenta fazer uma conexão via HTTP usando seu certificado autoassinado.

Para ajudar a identificar um certificado PKI único de cliente, você também pode especificar um repositório personalizado, diferente do padrão Pessoal no repositório do Computador. No entanto, você deve criar esse repositório independentemente do Gerenciador de Configurações e deve ser capaz de implantar certificados neste repositório personalizado e renová-los antes que o prazo de validade expire.

Para obter informações sobre como definir as configurações para certificados de cliente, consulte a seção Definir configurações para certificados PKI de clientes no tópico Configurando a segurança do Configuration Manager.

Planejando uma estratégia de transição para certificados PKI e gerenciamento de clientes baseados na Internet

As opções de configuração flexíveis no Gerenciador de Configurações permitem que você faça a transição gradual dos clientes e do site para usar certificados PKI e ajudar a proteger os pontos de extremidades do cliente. Certificados PKI fornecem maior segurança e permitem que os clientes sejam gerenciados quando estão na Internet.

Por causa do grande número de opções de configuração e escolhas no Gerenciador de Configurações, não há uma maneira de fazer a transição para um site para que todos os clientes usem conexões HTTPS. No entanto, você pode seguir estas etapas como orientação:

1. Instale o site do Gerenciador de Configurações e configure-o para que os sistemas de site aceitem conexões de clientes via HTTPS e HTTP.

2. Configure a guia Comunicação do Computador Cliente nas propriedades do site para que as Configurações do Sistema de Site sejam HTTP ou HTTPS, e marque a caixa de seleção Usar certificado de cliente PKI (Recurso de Autenticação de Cliente) quando disponível. Defina outras configurações necessárias nesta guia. Para obter mais informações, veja a seção Definir configurações para certificados PKI de clientes no tópico Configurando a segurança do Configuration Manager.

3. Coordene uma distribuição de PKI para certificados de cliente. Para um exemplo de implantação, consulte a seção Implantando o certificado do cliente para computadores com Windows no tópico Exemplo passo a passo para implantação dos certificados PKI para o Configuration Manager: Autoridade de certificação do Windows Server 2008.

4. Instale clientes usando o método de instalação por push do cliente. Para obter mais informações, veja a seção Como instalar clientes do Configuration Manager usando push de cliente no tópico Como instalar clientes em computadores com base em Windows no Configuration Manager.

5. Monitore a implantação e o status do cliente usando os relatórios e as informações de console do Gerenciador de Configurações.

6. Controle quantos clientes estão usando um certificado PKI de cliente visualizando a coluna Certificado do Cliente no espaço de trabalho Ativos e Conformidade, nó Dispositivos.

   Você também pode implantar a Ferramenta de avaliação de prontidão do HTTPS (Gerenciador de Configurações (cmHttpsReadiness.exe) em computadores e usar os relatórios para ver quantos computadores podem usar um certificado PKI de cliente com o Gerenciador de Configurações.

   Observação

   Quando o cliente do Gerenciador de Configurações instala em computadores cliente, a ferramenta cmHttpsReadiness.exe é instalada na pasta %windir%\CCM. Quando você executa essa ferramenta em clientes, pode especificar as seguintes opções: /Store: Quando estiver confiante de que um número suficiente de clientes está usando com sucesso o certificado PKI de cliente para autenticação em HTTP, faça o seguinte: Implante um certificado PKI de servidor Web em um servidor membro que irá executar um ponto de gerenciamento adicional para o site, e configure o certificado no IIS. Para obter mais informações, veja a seção Implantando o certificado do servidor Web para sistemas de sites que executam IIS no tópico Exemplo passo a passo para implantação dos certificados PKI para o Configuration Manager: Autoridade de certificação do Windows Server 2008. Instale a função de ponto de gerenciamento no servidor e configure a opção Conexões de Cliente nas propriedades do ponto de gerenciamento de HTTPS. Monitore e verifique se os clientes que têm um certificado PKI usam o novo ponto de gerenciamento ao usar o HTTPS. Você pode usar o registro em log do IIS ou contadores de desempenho para verificar isso. Reconfigure as outras funções de sistema de site para usar conexões de cliente HTTPS. Se você quiser gerenciar clientes na Internet, verifique se os sistemas do site têm um FQDN de Internet e configure pontos de gerenciamento individuais e pontos de distribuição para aceitar conexões de clientes da Internet. Importante Para configurar as funções do sistema de site para aceitar conexões da Internet, verifique as informações de planejamento e os pré-requisitos para gerenciamento de clientes baseados na Internet. Para obter mais informações, veja a seção Planejando o gerenciamento de clientes baseado na Internet no tópico Planejamento de comunicações no Configuration Manager. Estenda a distribuição de certificado PKI a clientes e sistemas de site que executam IIS, e configure as funções do sistema de site para conexões de cliente HTTPS e conexões de Internet, conforme necessário. Para maior segurança: Quando estiver seguro de que todos os clientes estão usando um certificado PKI de cliente para autenticação e criptografia, altere as propriedades do site para usar somente HTTPS. Quando você segue este plano para introduzir gradualmente certificados PKI, primeiro para autenticação somente por HTTP, e depois para autenticação e criptografia HTTPS, reduz o risco dos clientes ficarem sem gerenciamento. Além disso, você será beneficiado com a maior segurança que o Gerenciador de Configurações suporta. Planejando a chave de raiz confiável A chave de raiz confiável do Gerenciador de Configurações fornece um mecanismo para clientes do Gerenciador de Configurações verificarem se os sistemas de site pertencem à sua hierarquia. Cada servidor de site gera uma chave de troca de site para se comunicar com outros sites. A chave de troca do site de nível superior na hierarquia é chamada de chave de raiz confiável. A função da chave de raiz confiável no Gerenciador de Configurações se assemelha a um certificado raiz em uma infraestrutura de chave pública em que qualquer coisa assinada pela chave privada da chave de raiz confiável é de confiança abaixo na hierarquia. Por exemplo, ao assinar o certificado do ponto de gerenciamento com a chave privada do par de chaves de raiz confiável e ao disponibilizar uma cópia da chave pública do par de chaves de raiz confiável para os clientes, eles podem diferenciar entre os pontos de gerenciamento que estão em sua hierarquia e os que não estão. Os clientes usam WMI para armazenar uma cópia da chave raiz confiável no namespace root\ccm\locationservices. Clientes podem recuperar automaticamente a cópia pública da chave de raiz confiável usando dois mecanismos: O esquema Active Directory é estendido para o Gerenciador de Configurações, o site é publicado nos Serviços de Domínio Active Directory e os clientes podem recuperar informações do site por meio de um servidor de catálogo global. Os clientes são instalados usando a instalação por push. Se os clientes não puderem recuperar a chave de raiz confiável usando um desses mecanismos, eles confiarão na chave de raiz confiável fornecida pelo primeiro ponto de gerenciamento com o qual se comunicarem. Neste cenário, um cliente pode ser direcionado erroneamente para um ponto de gerenciamento de um invasor, onde receberia política do ponto de gerenciamento não autorizado. Isso seria, provavelmente, a ação de um invasor sofisticado e só poderia ocorrer em um tempo limitado antes de o cliente recuperar a chave de raiz confiável de um ponto de gerenciamento válido. No entanto, para reduzir esse risco de um invasor direcionar clientes para um ponto de gerenciamento não autorizado, você pode pré-provisionar os clientes usando a chave de raiz confiável. Use os seguintes procedimentos para pré-provisionar e verificar a chave de raiz confiável para o cliente do Gerenciador de Configurações: Pré-provisionar um cliente usando a chave de raiz confiável com um arquivo. Pré-provisionar um cliente usando a chave de raiz confiável sem um arquivo. Verificar a chave de raiz confiável em um cliente. Observação Não é necessário pré-provisionar cliente usando a chave de raiz confiável se ele puder obtê-la dos Serviços de Domínio Active Directory ou se estiverem instaladas usando push de cliente. Além disso, não é necessário pré-provisionar clientes quando eles usam a comunicação HTTPS em pontos de gerenciamento, porque a confiança é estabelecida usando certificados PKI. É possível remover a chave raiz confiável de um cliente usando a propriedade RESETKEYINFORMATION = TRUE do Client.msi com o CCMSetup.exe. Para substituir a chave raiz confiável, reinstale o cliente juntamente com a nova chave raiz confiável, por exemplo, usando o push de cliente ou especificando a propriedade SMSPublicRootKey do Client.msi por meio do CCMSetup.exe. Para pré-provisionar um cliente com a chave de raiz confiável usando um arquivo Em um editor de texto, abra o arquivo <Diretório do Configuration Manager>\bin\mobileclient.tcf. Localize a entrada SMSPublicRootKey=, copie a chave por meio dessa linha e feche o arquivo sem quaisquer alterações. Crie um novo arquivo de texto e cole as informações da chave que você copiou do arquivo mobileclient.tcf. Salve o arquivo e coloque-o em algum lugar onde todos os computadores possam acessá-lo, mas o arquivo é protegido para evitar violação. Instale o cliente usando qualquer método de instalação que aceite as propriedades de Client.msi e especifique a propriedade de Client.msi SMSROOTKEYPATH=<Caminho completo e nome do arquivo>. Importante Ao especificar a chave de raiz confiável para segurança adicional durante a instalação do cliente, você também deve especificar o código do site, usando a propriedade SMSSITECODE= Para pré-provisionar um cliente com a chave de raiz confiável sem usar um arquivo Em um editor de texto, abra o arquivo <Diretório do Configuration Manager>\bin\mobileclient.tcf. Localize a entrada SMSPublicRootKey=, anote a chave dessa linha ou copie-a na área de transferência, e feche o arquivo sem quaisquer alterações. Instale o cliente usando qualquer método de instalação que aceite as propriedades de Client.msi e especifique a propriedade de Client.msi SMSPublicRootKey=<chave>, em que <chave> é a cadeia de caracteres que você copiou de mobileclient.tcf. Importante Ao especificar a chave de raiz confiável para segurança adicional durante a instalação do cliente, você também deve especificar o código do site, usando a propriedade SMSSITECODE= Para verificar a chave de raiz confiável em um cliente No menu Iniciar, clique em Executar, e digite Wbemtest. Na caixa de diálogo Testador de Instrumentação de Gerenciamento do Windows, clique em Conectar. Na caixa de diálogo Conectar, em Namespace, digite root\ccm\locationservices, e depois clique em Conectar. Na caixa de diálogo Testador de Instrumentação de Gerenciamento do Windows, na seção IWbemServices, clique em Enumerar Classes. Na caixa de diálogo Informações de Superclasse, selecione Recursivo e clique em OK. Na janela Resultado da Consulta, role para o final da lista e clique duas vezes em TrustedRootKey (). Na caixa de diálogo Editor de objeto para TrustedRootKey, clique em Instâncias. Na nova janela Resultado da Consulta que exibe as instâncias de TrustedRootKey, clique duas vezes em TrustedRootKey=@ Na caixa de diálogo Editor de objeto para TrustedRootKey=@, na seção Propriedades, role para baixo até TrustedRootKey CIM_STRING. A cadeia de caracteres na coluna da direita é a chave de raiz confiável. Verifique se ele corresponde ao valor SMSPublicRootKey no arquivo <Diretório do Configuration Manager>\bin\mobileclient.tcf. Planejando para assinatura e criptografia Quando você usa certificados PKI para todas as comunicações do cliente, não precisa planejar assinatura e criptografia para ajudar a proteger o cliente nas comunicação de dados. No entanto, se você configurar qualquer sistema de site que execute IIS para permitir conexões de cliente HTTP, deverá decidir como ajudar a proteger a comunicação do cliente com o site. Para ajudar a proteger os dados que os clientes enviam aos pontos de gerenciamento, é possível requerer que eles sejam assinados. Além disso, você pode requerer que todos os dados assinados de clientes que usam HTTP utilizem o algoritmo SHA-256. Embora esta seja uma configuração mais segura, não habilite esta opção, a menos que todos os clientes deem suporte ao SHA-256. Muitos sistemas operacionais dão suporte nativo ao SHA-256, mas os sistemas operacionais mais antigos podem exigir uma atualização ou hotfix. Por exemplo, computadores que executam Windows Server 2003 SP2 devem instalar um hotfix que é referido no KB artigo 938397. Enquanto a assinatura ajuda a proteger os dados contra violação, a criptografia ajuda a proteger os dados contra a divulgação de informações. Você pode habilitar a criptografia de 3DES para dados de inventário e mensagens de estado que os clientes enviam para pontos de gerenciamento no site. Não é necessário instalar nenhuma atualização em clientes para oferecerem suporte para essa opção, mas considere o uso adicional de CPU necessário nos clientes e o ponto de gerenciamento para executar criptografia e decriptografia. Para obter informações sobre como definir as configurações para assinatura e criptografia, consulte a seção Configurar assinatura e criptografia no tópico Configurando a segurança do Configuration Manager. Planejando a administração baseada em funções A administração baseada em funções permite que você designe e implante segurança administrativa para a hierarquia do System Center 2012 Configuration Manager usando alguma ou todas as seguintes: Funções de segurança Coleções Escopos de segurança Essas configurações se combinam para definir um escopo administrativo para um usuário administrativo. O escopo administrativo controla os objetos que um usuário administrativo pode exibir no console do Gerenciador de Configurações e as permissões que possui nesses objetos. Configurações de administração baseadas em funções replicam em cada site na hierarquia como dados globais e, em seguida, são aplicadas a todas as conexões administrativas. Importante Atrasos de replicação entre sites podem impedir que um site receba alterações para a administração baseada em funções. Para obter informações sobre como monitorar replicação de banco de dados entre sites, consulte a seção Como monitorar o status de replicação e links de replicação de banco de dados no tópico Monitorar sites e hierarquia do Configuration Manager. Planejando funções de segurança Use as funções de segurança para conceder permissões de segurança a usuários administrativos. Funções de segurança são grupos de permissões de segurança atribuídas a usuários administrativos para que eles executem suas tarefas administrativas. Essas permissões de segurança definem as ações administrativas que um usuário administrativo pode executar e as permissões concedidas a tipos de objetos particulares. Como uma prática recomendada de segurança, atribua as funções de segurança que fornecem o mínimo de permissões. O System Center 2012 Configuration Manager possui diversas funções de segurança internas para suporte de agrupamentos típicos de tarefas administrativas, e é possível criar suas próprias funções de segurança personalizadas para oferecer suporte a seus requisitos específicos de negócios. Exemplos de funções de segurança interna: Administrador Completo: Essa função de segurança concede todas as permissões no Gerenciador de Configurações. Analista de Ativos: Essa função de segurança permite que usuários administrativos exibam dados coletados usando o Asset Intelligence, inventário de software, inventário de hardware e medição de software. Usuários administrativos podem criar regras de medição e categorias de Asset Intelligence, famílias e rótulos. Gerenciador de Atualização de Software: Essa função de segurança concede permissões para definir e implantar atualizações de software. Usuários administrativos que estão associados a essa função podem criar coleções, grupos de atualização de software, implantações, modelos e habilitar atualizações de software para NAP (Proteção de Acesso à Rede). Dica Você pode exibir a lista de funções de segurança internas e funções de segurança personalizadas que você cria, incluindo suas descrições, no console do Gerenciador de Configurações. Para isso, no espaço de trabalho Administração, expanda Segurança e selecione Funções de Segurança. Cada função de segurança tem as permissões específicas para diferentes tipos de objeto. Por exemplo, a função de segurança Administrador de Aplicativos possui as seguintes permissões para aplicativos: Aprovar, Criar, Excluir, Modificar, Modificar Pastas, Mover Objetos, Ler/Implantar, Definir Escopo de Segurança. Você não pode alterar as permissões das funções de segurança internas, mas pode copiar a função, fazer alterações e então salvar essas alterações como uma nova função de segurança personalizada. Também é possível importar funções de segurança que você exportou de outra hierarquia (por exemplo, de uma rede de teste). Reveja as funções de segurança e suas permissões para determinar se usará as funções de segurança internas ou precisará criar suas próprias funções de segurança personalizadas. Use as etapas a seguir para ajudá-lo a planejar as funções de seguranças: Identificar as tarefas que os usuários administrativos executam em System Center 2012 Configuration Manager. Essas tarefas podem estar relacionadas a um ou mais grupos de tarefas de gerenciamento, como implantação de aplicativos e pacotes, implantação de sistemas operacionais e configurações para conformidade, configuração de sites e segurança, auditoria, controle de computadores remotamente e coleta de dados de inventário. Mapear essas tarefas administrativas a uma ou mais funções de segurança internas. Se algum dos usuários administrativos executar as tarefas de diversas funções de segurança, atribua-as a esses usuários administrativos em vez de criar uma nova função de segurança que combine as tarefas. Se as tarefas identificadas não mapearem para as funções de segurança internas, crie e teste novas funções de segurança. Para obter informações sobre como criar e configurar funções de segurança para administração baseada em função, consulte as seções Criar funções de segurança personalizadas e Configurar funções de segurança no tópico Configurando a segurança do Configuration Manager. Planejando coleções Coleções especificam os recursos de usuário e computador que um usuário administrativo pode exibir ou gerenciar. Por exemplo, para usuários administrativos implantarem aplicativos ou executarem controle remoto, eles devem ser atribuídos a uma função de segurança que conceda acesso a uma coleção que contenha esses recursos. Você pode selecionar coleções de usuários ou dispositivos. Para obter mais informações sobre coleções, consulte Introdução às coleções do Configuration Manager. Para configurar administração baseada em funções, verifique se você precisa criar novas coleções por algum dos seguintes motivos: Organização funcional. Por exemplo, separar as coleções de servidores e estações de trabalho. Alinhamento geográfico. Por exemplo, separar as coleções para América do Norte e Europa. Requisitos de segurança e processos de negócios. Por exemplo, separar coleções para computadores de teste e de produção. Alinhamento da organização. Por exemplo, separar as coleções para cada unidade de negócios. Para obter informações sobre como configurar coleções para administração baseada em função, consulte a seção Configurar coleções para gerenciar a segurança no tópico Configurando a segurança do Configuration Manager. Planejando escopos de segurança Use escopos de segurança para fornecer aos usuários administrativos acesso a objetos protegidos. Escopos de segurança são um conjunto denominado objetos protegidos que são atribuídos a usuários administradores como um grupo. Todos os objetos protegíveis devem ser atribuídos a um ou mais escopos de segurança. O Gerenciador de Configurações tem dois escopos de segurança internos: Todos: Esse escopo de segurança interno concede acesso a todos os escopos. Você não pode atribuir objetos a este escopo de segurança. Padrão: Esse escopo de segurança interno é usado para todos os objetos, por padrão. Ao instalar primeiro o System Center 2012 Configuration Manager, todos os objetos são atribuídos a esse escopo de segurança. Se deseja restringir os objetos que os usuários administrativos podem ver e gerenciar, você deve criar e usar seus próprios escopos de segurança personalizados. Escopos de segurança não oferecem suporte a uma estrutura hierárquica e não podem ser aninhados. Escopos de segurança podem conter um ou mais tipos de objeto, que incluem o seguinte: Inscrições de alertas Aplicativos Imagens de inicialização Grupos de limites Itens de configuração Configurações personalizadas do cliente Pontos de distribuição e grupos de ponto de distribuição Pacotes de driver Condições globais Trabalhos de migração Imagens do sistema operacional Pacotes de instalação do sistema operacional Pacotes Consultas Sites Regras de medição de software Grupos de atualização de software Pacotes de atualizações de software Pacotes de sequência de tarefas Pacotes e itens de configuração de dispositivo do Windows CE Há também alguns objetos que não podem ser incluídos em escopos de segurança porque eles são usados somente pelas funções de segurança. O acesso administrativo a estas funções não pode ser limitado a um subconjunto dos objetos disponíveis. Por exemplo, você pode ter um usuário administrativo que cria grupos de limites que são usados para um site específico. Como esse objeto de limite não suporta escopos de segurança, não é possível atribuir a esse usuário um escopo de segurança que forneça acesso somente aos limites que podem ser associados a esse site. Como o objeto de limite não pode estar associado a um escopo de segurança, quando você atribui uma função de segurança que inclui acesso a objetos de limite a um usuário, este pode acessar cada limite na hierarquia. Objetos que não são limitados por escopos de segurança incluem o seguinte: Florestas do Active Directory Usuários administrativos Alertas Políticas antimalware Limites Associações de computador Configurações de cliente padrão Modelos de implantação Drivers de dispositivo Conector do Exchange Server Mapeamentos site a site da migração Perfis de registro do dispositivo móvel Funções de segurança Escopos de segurança Endereços de sites Funções do sistema de site Títulos de software Atualizações de software Mensagens de status Afinidades de dispositivo de usuário Crie escopos de segurança quando precisar limitar o acesso ao separar instâncias de objetos. Por exemplo: Você possui um grupo de usuários administrativos que devem ser capazes de ver aplicativos de produção e não aplicativos de teste. Crie um escopo de segurança para aplicativos de produção e outro para os aplicativos de teste. Diferentes usuários administrativos necessitam de acesso distinto para algumas instâncias de um tipo de objeto. Por exemplo, um grupo de usuários administrativos requer permissão de Leitura para grupos de atualização de software específicos, e outro grupo de usuários administrativos requer permissões de Modificar e Excluir para outros grupos de atualização de software. Crie escopos de segurança diferentes para esses grupos de atualização de software. Para obter informações sobre como configurar escopos de segurança para administração baseada em função, consulte a seção Configurar escopos de segurança para um objeto no tópico Configurando a segurança do Configuration Manager. Consulte também Planejamento de hierarquia e de sites do Configuration Manager