Planear 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

O Gestor de configuração utiliza uma combinação de certificados autoassinados e certificados de infraestrutura de chaves públicas (PKI).

Como melhor prática de segurança, utilize certificados PKI sempre que possível. Para mais informações sobre os requisitos dos certificados PKI, consulte Requisitos de Certificado PKI para o Configuration Manager. Quando o Gestor de configuração pede os certificados PKI, durante a inscrição de dispositivos móveis e o aprovisionamento AMT por exemplo, é necessário utilizar os Serviços de Domínio do Active Directory e uma autoridade de certificação empresarial. Para todos os outros certificados PKI, é necessário implementá-los e geri-los separadamente do Gestor de configuração.

Os certificados PKI também são necessários quando os computadores cliente ligam a sistemas de sites baseados na Internet, sendo a sua utilização recomendada quando os clientes ligam a sistemas de sites com os Serviços de Informação Internet (IIS) em execução. Para mais informações sobre as comunicações de clientes, consulte Planear a Comunicação do Cliente no Configuration Manager.

Quando utiliza PKI, pode utilizar também IPsec para ajudar a proteger as comunicações servidor-servidor entre sistemas de sites, num site e entre sites, e para qualquer outro cenário quando transferir dados entre computadores. Tem de configurar e implementar o IPsec separadamente do Gestor de configuração.

O Gestor de configuração pode gerar automaticamente certificados autoassinados quando não estão disponíveis certificados PKI e alguns certificados no Gestor de configuração são sempre autoassinados. Na maioria dos casos, o Gestor de configuração gera automaticamente os certificados autoassinados, não sendo necessária qualquer ação adicional. Uma exceção possível é o certificado de assinatura do servidor do site. O certificado de assinatura do servidor do site é sempre autoassinado e assegura que as políticas de cliente que os clientes transferem a partir do ponto de gestão foram enviadas pelo servidor do site e que não foram adulteradas.

Os clientes podem obter com segurança uma cópia do certificado de assinatura do servidor do site a partir dos Serviços de Domínio do Active Directory e da instalação push do cliente. Se os clientes não conseguirem obter uma cópia do certificado de assinatura do servidor do site utilizando um destes mecanismos, como melhor prática de segurança, instale uma cópia do certificado de assinatura do servidor do site quando instalar o cliente. Isto é especialmente importante se a primeira comunicação do cliente com o site for efetuada a partir da Internet, dado que o ponto de gestão está ligado a uma rede não fidedigna e, por isso, vulnerável a ataques. Se não efetuar este passo adicional, os clientes transferirão automaticamente uma cópia do certificado de assinatura do servidor do site a partir do ponto de gestão.

Seguem-se alguns dos cenários em que os clientes não conseguem obter uma cópia do certificado do servidor do site de forma segura:

  • O cliente não é instalado utilizando a instalação push de cliente e qualquer uma das seguintes condições é verdadeira:

    • O esquema do Active Directory não foi expandido para o Gestor de configuração.

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

    • O cliente pertence a uma floresta ou um grupo de trabalho não fidedigno.

  • O cliente é instalado quando está na Internet.

Utilize o procedimento seguinte para instalar clientes juntamente com uma cópia do certificado de assinatura do servidor do site.

Para instalar clientes com uma cópia do certificado de assinatura do servidor do site

  1. Localize o certificado de assinatura do servidor do site no servidor de site primário do cliente. O certificado é armazenado no arquivo de certificados SMS e tem o nome de Requerente Servidor do Site e o nome amigável Certificado de Assinatura do Servidor do Site.

  2. Exporte o certificado sem a chave privada, guarde o ficheiro de forma segura e aceda ao mesmo apenas a partir de um canal protegido (por exemplo, utilizando a assinatura SMB ou IPsec).

  3. Instale o cliente utilizando a propriedade SMSSIGNCERT=<Nome e caminho completo do ficheiro> de Client.msi com o CCMSetup.exe.

Quando utilizar certificados PKI com o Gestor de configuração, planeie como e quando os clientes e servidores irão utilizar uma lista de revogação de certificados (CRL) para confirmar o certificado no computador que efetuar a ligação. A lista de revogação de certificados (CRL) é um ficheiro que é criado e assinado por uma autoridade de certificação (AC) e que contém uma lista dos certificados por ela emitidos, mas revogados. Os certificados podem ser revogados por um administrador de AC, por exemplo, caso se saiba ou suspeite que um certificado emitido está comprometido.

System_CAPS_importantImportante

Como a localização da CRL é adicionada a um certificado quando este é emitido por uma AC, certifique-se de que planeia a CRL antes de implementar quaisquer certificados PKI para utilização do Gestor de configuração.

Por predefinição, o IIS verifica sempre a existência de certificados de cliente na CRL e não é possível alterar esta configuração no Gestor de configuração. Por predefinição, os clientes do Gestor de configuração verificam sempre a existência de sistemas de sites na CRL; no entanto, é possível desativar esta definição especificando uma propriedade de site e uma propriedade de CCMSetup. Quando gere computadores baseados em Intel AMT fora de banda, também pode ativar a verificação da CRL para o ponto de serviço fora de banda e para computadores com a consola de Gestão Fora de Banda.

Se os computadores utilizarem a verificação de revogação de certificados, mas não conseguirem localizar a CRL, comportar-se-ão com se todos os certificados da cadeia de certificação estivessem revogados, uma vez que não é possível confirmar a sua ausência da lista. Neste cenário, todas as ligações que necessitem de certificados e utilizem uma CRL falharão.

A verificação da CRL sempre que é utilizado um certificado oferece mais segurança contra a utilização de um certificado revogado, mas provoca um atraso de ligação e processamento adicional no cliente. Esta verificação de segurança adicional é mais necessária quando os clientes se encontram na Internet ou numa rede não fidedigna.

Consulte os administradores de PKI antes de decidir se os clientes do Gestor de configuração devem verificar a CRL e, em seguida, considere manter esta opção ativada no Gestor de configuração quando as duas condições seguintes forem verdadeiras:

  • A sua infraestrutura de PKI suporta uma CRL, que é publicada onde todos os clientes do Gestor de configuração a possam localizar. Lembre-se de que estes poderão incluir clientes na Internet, se estiver a utilizar a gestão de clientes baseados na Internet, e clientes em florestas não fidedignas.

  • O requisito de verificação da CRL em cada ligação a um sistema de sites configurado para utilizar um certificado PKI é mais importante que o requisito de ligações mais rápidas e processamento eficiente no cliente e também é mais importante que o risco de os clientes não conseguirem ligar a servidores se não conseguirem localizar a CRL.

Se os sistemas de sites do IIS utilizarem certificados PKI de cliente para autenticação de clientes por HTTP ou autenticação e encriptação de clientes por HTTPS, poderá ter de importar certificados de AC de raiz como uma propriedade de site. Os dois cenários são os seguintes:

  • Implementa sistemas operativos utilizando o Gestor de configuração e os pontos de gestão só aceitam ligações de cliente HTTPS.

  • Utiliza certificados PKI de cliente que não encadeiam num certificado de autoridade de certificação (AC) de raiz considerado fidedigno pelos pontos de gestão.

    System_CAPS_noteNota

    Quando emite certificados PKI de cliente a partir da mesma hierarquia de AC que emite os certificados de servidor utilizados para os pontos de gestão, não é necessário especificar este certificado de AC de raiz. No entanto, se utilizar várias hierarquias de AC e não tiver a certeza se são mutuamente fidedignas, importe a AC de raiz para a hierarquia de AC dos clientes.

Se tiver de importar certificados de AC de raiz para o Gestor de configuração, exporte-os a partir da AC emissora ou do computador cliente. Se exportar o certificado a partir da AC emissora e esta também for a AC de raiz, certifique-se de que a chave privada não é exportada. Armazene o ficheiro de certificado exportado numa localização segura para impedir adulteração. Deve poder aceder ao ficheiro quando configurar o site e, se aceder através da rede, certifique-se de que a comunicação é protegida contra adulteração utilizando a assinatura SMB ou IPsec.

Se qualquer um dos certificados de AC de raiz que importar for renovado, terá de importar os certificados renovados.

Estes certificados de AC de raiz importados e o certificado de AC de raiz de cada ponto de gestão criam a lista de emissores de certificados que o computadores com o Gestor de configuração utilizam das seguintes formas:

  • Quando os clientes ligam aos pontos de gestão, o ponto de gestão verifica se o certificado de cliente encadeia num certificado de raiz fidedigna na lista de emissores de certificados do site. Caso não encadeie, o certificado é rejeitado e a ligação PKI falha.

  • Quando os clientes selecionam um certificado PKI, se tiverem uma lista de emissores de certificados, selecionarão um certificado de cliente que encadeie num certificado de raiz fidedigna na lista de emissores de certificados. Se não existir nenhuma correspondência, o cliente não selecionará um certificado PKI. Para mais informações sobre o processo de certificado de cliente, consulte a secção Planear a Seleção do Certificado PKI de Cliente deste tópico.

Independentemente da configuração do site, poderá também ter de importar um certificado de AC de raiz quando inscrever dispositivos móveis ou computadores Mac e quando aprovisionar computadores baseados em Intel AMT para redes sem fios.

Se pretender que os sistemas de sites do IIS utilizem certificados PKI de cliente para autenticação de clientes por HTTP ou autenticação e encriptação de clientes por HTTPS, planeie o modo como os clientes baseados em Windows irão selecionar o certificado a utilizar para o Gestor de configuração.

System_CAPS_noteNota

Nem todos os dispositivos suportam um método de seleção de certificado e, em vez disso, selecionam automaticamente o primeiro certificado que satisfaz os requisitos de certificado. Por exemplo, os clientes em computadores Mac e os dispositivos móveis não suportam um método de seleção de certificado.

Em muitos casos, a configuração e o comportamento predefinidos serão suficientes. O cliente do Gestor de configuração em computadores baseados em Windows filtra vários certificados utilizando os seguintes critérios:

  1. A lista de emissores de certificados: o certificado encadeia numa AC de raiz que é considerada fidedigna pelo ponto de gestão.

  2. O certificado está no arquivo de certificados predefinido Pessoal.

  3. O certificado é válido, não foi revogado e não expirou. A verificação da validade inclui a confirmação de que a chave privada é acessível e de que o certificado não foi criado com um modelo de certificado de versão 3, que não é compatível com o Gestor de configuração.

  4. O certificado tem capacidade de autenticação de cliente ou foi emitido para o nome do computador.

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

Os clientes podem ser configurados para utilizar a lista de emissores de certificados com os seguintes mecanismos:

  • Está publicada como informações do site do Gestor de configuração nos Serviços de Domínio do Active Directory.

  • Os clientes são instalados utilizando a instalação push de cliente.

  • Os clientes transferem-na a partir do ponto de gestão depois de atribuídos com êxito ao respetivo site.

  • É especificada durante a instalação de cliente como uma propriedade CCMCERTISSUERS de client.msi do CCMSetup.

Se os clientes não tiverem a lista de emissores de certificados quando forem instalados pela primeira vez e ainda não estiverem atribuídos ao site, ignorarão esta verificação. Quando tiverem a lista de emissores de certificados e não tiverem um certificado PKI de cliente que encadeie num certificado de raiz fidedigna na lista de emissores de certificados, a seleção de certificado falhará e os clientes não avançarão com os restantes critérios de seleção de certificado.

Na maioria dos casos, o cliente do Gestor de configuração identifica corretamente um certificado PKI exclusivo e adequado para utilizar. No entanto, quando não for este o caso, em vez de selecionar o certificado com base na capacidade de autenticação de cliente, poderá configurar dois métodos de seleção alternativos:

  • Uma correspondência parcial no nome de Requerente do certificado de cliente. Esta é uma correspondência não sensível a maiúsculas e minúsculas adequada se estiver a utilizar o nome de domínio completamente qualificado (FQDN) de um computador no campo do requerente e pretender que a seleção de certificado seja baseada no sufixo de domínio, por exemplo contoso.com. No entanto, pode utilizar este método de seleção para identificar qualquer cadeia de carateres sequenciais no nome de Requerente do certificado que o diferencie de outros no arquivo de certificados do cliente.

    System_CAPS_noteNota

    Não é possível utilizar a correspondência de cadeia parcial com o nome alternativo do requerente (SAN) como definição do site. Apesar de ser possível especificar uma correspondência de cadeia parcial para o SAN utilizando o CCMSetup, esta será substituída pelas propriedades do site nos cenários seguintes:

    • Os clientes obtém informações do site que estão publicadas nos Serviços de Domínio do Active Directory.

    • Os clientes são instalados utilizando a instalação push do cliente.

    Apenas utilize uma correspondência parcial de cadeia no SAN quando instalar clientes manualmente e quando estes não obterem informações do site a partir dos Serviços de Domínio do Active Directory. Por exemplo, estas condições aplicam-se a clientes apenas de Internet.

  • Uma correspondência nos valores do atributo do nome do requerente do certificado do cliente ou nos valores do atributo do nome alternativo do requerente (SAN). Esta é uma correspondência sensível a maiúsculas e minúsculas apropriada se estiver a utilizar um nome único X500 ou identificadores de objeto (OID) equivalentes em conformidade com RFC 3280 e se pretender que a seleção do certificado se baseie nos valores do atributo. É possível especificar apenas os atributos e os respetivos valores necessários para identificar ou validar exclusivamente o certificado e distinguir o certificado de outros num arquivo de certificados.

A tabela seguinte apresenta os valores do atributo que o Gestor de configuração suporta para os critérios de seleção de certificados do cliente.

Atributo OID

Atributo de nome único

Definição do atributo

0.9.2342.19200300.100.1.25

DC

Componente do domínio

1.2.840.113549.1.9.1

E ou E-mail

Endereço de correio eletrónico

2.5.4.3

CN

Nome comum

2.5.4.4

SN

Nome do requerente

2.5.4.5

SERIALNUMBER

Número de série

2.5.4.6

C

Código de país

2.5.4.7

L

Localidade

2.5.4.8

S ou ST

Nome do estado ou distrito

2.5.4.9

STREET

Morada

2.5.4.10

O

Nome da organização

2.5.4.11

OU

Unidade organizacional

2.5.4.12

T ou Title

Título

2.5.4.42

G ou GN ou GivenName

Nome próprio

2.5.4.43

I ou Initials

Iniciais

2.5.29.17

(sem valor)

Nome alternativo do requerente

Se forem localizados mais do que um certificado apropriado após a aplicação dos critérios de seleção, é possível substituir a configuração predefinida para selecionar o certificado que tiver o maior prazo de validade e, em vez disso, especificar que não está selecionado qualquer certificado. Neste cenário, o cliente não pode comunicar com os sistemas de sites do IIS utilizando um certificado PKI. O cliente envia uma mensagem de erro ao respetivo ponto de estado de contingência atribuído para o alertar sobre a falha na seleção do certificado para que possa modificar o refinar os seus critérios de seleção de certificados. Em seguida, o comportamento do cliente depende se a falha de ligação falha através de HTTPS ou HTTP:

  • Se a falha de ligação ocorreu através de HTTPS: O cliente tenta estabelecer uma ligação através de HTTP e utiliza o certificado autoatribuído do cliente.

  • Se a falha de ligação ocorreu através de HTTP: O cliente tenta estabelecer outra ligação através de HTTP utilizando o certificado de cliente autoatribuído.

Para ajudar a identificar um certificado de cliente PKI único, também é possível especificar um arquivo personalizado, diferente da predefinição de Pessoal no arquivo do Computador. No entanto, tem de criar este arquivo independentemente do Gestor de configuração e tem de poder implementar certificados neste arquivo personalizado e renová-los antes do final do período de validade.

Para obter informações sobre como configurar as definições para certificados de cliente, consulte a secção Configurar Definições para Certificados PKI de Cliente do tópico Configurar a Segurança para o Configuration Manager.

As opções de configuração flexíveis no Gestor de configuração permitem-lhe fazer a transição gradual de clientes e do site para utilizar certificados PKI para ajudar a proteger pontos finais de cliente. Os certificados PKI proporcionam uma maior segurança e permitem que os clientes sejam geridos quando estão na Internet.

Devido ao número de opções e escolhas de configuração no Gestor de configuração, não existe uma única forma de efetuar a transição de um site de forma que todos os clientes utilizem ligações HTTPS. No entanto, pode seguir estes passos como orientação:

  1. Instale o site do Gestor de configuração e configure-o de forma que os sistemas de sites aceitem ligações de cliente através de HTTPS e HTTP.

  2. Configure o separador Comunicação com o computador cliente nas propriedades do site de forma que o campo Definições do Sistema de Site seja HTTP ou HTTPS e selecione a caixa de verificação Utilizar um certificado de cliente PKI (capacidade de autenticação de cliente), se estiver disponível. Configure todas as outras definições necessárias neste. Para obter mais informações, consulte a secção Configurar Definições para Certificados PKI de Cliente do tópico Configurar a Segurança para o Configuration Manager.

  3. Efetue uma implementação PKI para os certificados de cliente. Para ver um exemplo de implementação, consulte a secção Implementar o Certificado de Cliente em Computadores com Windows do tópico Exemplo Passo a Passo de Implementação dos Certificados PKI para o Configuration Manager: Autoridade de Certificação do Windows Server 2008.

  4. Instale clientes utilizando o método de instalação push do cliente. Para obter mais informações, consulte a secção Como Instalar Clientes do Configuration Manager Utilizando Push de Cliente do tópico Como Instalar Clientes em Computadores Baseados no Windows no Configuration Manager.

  5. Monitorize a implementação do cliente e o estado utilizando os relatórios e as informações na consola do Gestor de configuração.

  6. Verifique quantos clientes estão a utilizar um certificado PKI de cliente visualizando a coluna Certificado de Cliente na área de trabalho Ativos e Compatibilidade, nó Dispositivos.

    Também é possível implementar a Ferramenta de Avaliação de Preparação do HTTPS do Gestor de configuração (cmHttpsReadiness.exe) em computadores e utilizar os relatórios para verificar quantos computadores podem utilizar um certificado PKI de cliente com o Gestor de configuração.

    System_CAPS_noteNota

    Quando o cliente do Gestor de configuração é instalado em computadores cliente, a ferramenta cmHttpsReadiness.exe é instalada na pasta %windir%\CCM. Quando executa esta ferramenta em clientes, é possível especificar as seguintes opções:

    • /Store:<nome>

    • /Issuers:<lista>

    • /Criteria:<critérios>

    • /SelectFirstCert

    Estas opções mapeiam as propriedades CCMCERTSTORE, CCMCERTISSUERS, CCMCERTSEL e CCMFIRSTCERT Client.msi, respetivamente. Para mais informações sobre estas opções, consulte Acerca das Propriedades da Instalação do Cliente no Configuration Manager.

  7. Quando tem a certeza de que um número suficiente de clientes está a utilizar o respetivo certificado PKI de cliente para autenticação através de HTTP, efetue o seguinte:

    1. Implemente um certificado de servidor Web PKI para um servidor membro que vai executar um ponto de gestão adicional para o site e configurar esse certificado no IIS. Para obter mais informações, consulte a secção Implementar o Certificado do Servidor Web para Sistemas de Sites que Executam o IIS do tópico Exemplo Passo a Passo de Implementação dos Certificados PKI para o Configuration Manager: Autoridade de Certificação do Windows Server 2008.

    2. Instale a função do ponto de gestão neste servidor e configure a opção Ligações de cliente nas propriedades do ponto de gestão para HTTPS.

  8. Monitorize e certifique-se de que os clientes que tenham um certificado PKI utilizam o novo ponto de gestão utilizando HTTPS. É possível utilizar contadores de registo ou desempenho do IIS para verificar isto.

  9. Reconfigure as outras funções do sistema de site para utilizar ligações de cliente HTTPS. Se pretender gerir clientes na Internet, certifique-se de que os sistemas de sites possuem um FQDN de Internet e configure os pontos de gestão e os pontos de distribuição individuais para aceitarem ligações de cliente a partir da Internet.

    System_CAPS_importantImportante

    Antes de configurar as funções do sistema de site para aceitar ligações a partir da Internet, verifique as informações de planeamento e os pré-requisitos da gestão de clientes baseados na Internet. Para obter mais informações, consulte a secção Planear a Gestão de Clientes Baseada na Internet do tópico Planear a comunicações no Configuration Manager.

  10. Expanda a implementação do certificado PKI para clientes e sistemas de sites que executem o IIS e configure as funções do sistema de site para ligações de cliente HTTPS e ligações de Internet, consoante o necessário.

  11. Para garantir a máxima segurança: Se tiver a certeza de que todos os clientes estão a utilizar um certificado PKI de cliente para autenticação e encriptação, altere as propriedades do site para utilizar apenas HTTPS.

Se seguir este plano para introduzir gradualmente os certificados PKI, primeiro para autenticação apenas por HTTP e depois para autenticação e encriptação por HTTPS, reduz o risco de os clientes se tornarem não geridos. Além disso, beneficia da mais elevada segurança suportada pelo Gestor de configuração.

A chave de raiz fidedigna do Gestor de configuração fornece um mecanismo para que os clientes do Gestor de configuração verifiquem se os sistemas de sites pertencem à respetiva hierarquia. Cada servidor de site gera uma chave de troca de site para comunicar com outros sites. A chave de troca de site do site de nível superior na hierarquia chama-se chave de raiz fidedigna.

A função da chave de raiz fidedigna no Gestor de configuração assemelha-se a um certificado de raiz numa infraestrutura de chave pública na qual tudo o que é assinado pela chave privada da chave de raiz fidedigna é fidedigna ao longo de toda a hierarquia. Por exemplo, assinando o certificado do ponto de gestão com a chave privada do par de chaves de raiz fidedignas e fazendo uma cópia da chave da chave pública do par de chaves de raiz fidedignas disponíveis para os clientes, é possível os clientes diferenciarem entre os pontos de gestão que existem na respetiva hierarquia e os pontos de gestão que não existem na respetiva hierarquia. Os clientes utilizam o WMI para arquivar uma cópia da chave de raiz fidedigna no espaço de nomes do root\ccm\locationservices.

É possível os clientes obterem automaticamente a cópia pública da chave de raiz fidedigna através de dois mecanismos:

  • O esquema do Active Directory é expandido para o Gestor de configuração, o site é publicado nos Serviços de Domínio do Active Directory e os clientes podem obter estas informações do site a partir de um servidor de catálogo global.

  • Os clientes são instalados utilizando a instalação push de cliente.

Se não for possível os clientes obterem a chave de raiz fidedigna através de um destes mecanismos, os clientes confiam na chave de raiz fidedigna que é fornecida pelo primeiro ponto de gestão com o qual comunicam. Neste cenário, um cliente poderia ser redirecionado para um ponto de gestão de um atacante, onde receberia a política do ponto de gestão não autorizado. Provavelmente, esta seria a ação de um atacante sofisticado e a sua ocorrência seria possível apenas por um período de tempo limitado antes de o cliente obter a chave de raiz fidedigna de um ponto de gestão válido. No entanto, para reduzir o risco de um atacante redirecionar clientes para um ponto de gestão não autorizado, é possível pré-aprovisionar os clientes utilizando a chave de raiz fidedigna.

Utilize os seguintes procedimentos para pré-aprovisionar e verificar a chave de raiz fidedigna para um cliente do Gestor de configuração:

  • Pré-aprovisione um cliente com a chave de raiz fidedigna utilizando um ficheiro.

  • Pré-aprovisione um cliente com a chave de raiz fidedigna sem utilizar um ficheiro.

  • Verifique a chave de raiz fidedigna num cliente.

System_CAPS_noteNota

Não é necessário pré-aprovisionar o cliente utilizando a chave de raiz fidedigna se for possível o cliente obter esta chave a partir dos serviços de domínio do Active Directory ou se for instalado utilizando a instalação push do cliente. Além disso, não é necessário pré-aprovisionar os clientes se estes utilizarem a comunicação por HTTPS para pontos de gestão porque a confiança é estabelecida através dos certificados PKI.

É possível remover a chave de raiz fidedigna de um cliente através da propriedade Client.msi RESETKEYINFORMATION = TRUE com o CCMSetup.exe. Para substituir a chave de raiz fidedigna, reinstale o cliente em conjunto com a nova chave de raiz fidedigna, por exemplo, utilizando a instalação push do cliente ou especificando a propriedade Client.msi SMSPublicRootKey através do CCMSetup.exe.

Para pré-aprovisionar um cliente com a chave de raiz fidedigna utilizando um ficheiro

  1. Num editor de texto, abra o ficheiro <diretório do Configuration Manager>\bin\mobileclient.tcf.

  2. Localize a entrada SMSPublicRootKey=, copie a chave dessa linha e feche o ficheiro sem guardar alterações.

  3. Crie um novo ficheiro de texto e cole as informações da chave que copiou do ficheiro mobileclient.tcf.

  4. Guarde o ficheiro e coloque-o num local onde todos os computadores possam aceder, mas onde o ficheiro esteja protegido para impedir a adulteração.

  5. Instale o cliente utilizando um método de instalação que aceite propriedades Client.msi e especifique a propriedade Client.msi SMSROOTKEYPATH=<Caminho completo e nome do ficheiro>.

    System_CAPS_importantImportante

    Como medida adicional de segurança, quando especificar a chave de raiz fidedigna, também tem de especificar o código do site utilizando a propriedade Client.msi SMSSITECODE=<código do site>.

Para pré-aprovisionar um cliente com a chave de raiz fidedigna sem utilizar um ficheiro

  1. Num editor de texto, abra o ficheiro <diretório do Configuration Manager>\bin\mobileclient.tcf.

  2. Localize a entrada SMSPublicRootKey=, anote a chave dessa linha ou copie-a para a área de transferência e depois feche o ficheiro sem guardar alterações.

  3. Instale o cliente utilizando um método de instalação que aceite propriedades Client.msi e especifique a propriedade Client.msi SMSPublicRootKey=<chave>, em que <chave> é a cadeia que copiou de mobileclient.tcf.

    System_CAPS_importantImportante

    Como medida adicional de segurança, quando especificar a chave de raiz fidedigna, também tem de especificar o código do site utilizando a propriedade Client.msi SMSSITECODE=<código do site>.

Para verificar a chave de raiz fidedigna num cliente

  1. No menu Iniciar, clique em Executar e depois escreva Wbemtest.

  2. Na caixa de diálogo do Recurso de Teste do Windows Management Instrumentation, clique em Ligar.

  3. Na caixa de diálogo Ligar, na caixa Espaço de nomes, escrevaroot\ccm\locationservices e depois clique em Ligar.

  4. Na caixa de diálogo Recurso de Teste do Windows Management Instrumentation, na secção IWbemServices, clique em Classes Enum.

  5. Na caixa de diálogo Informações sobre a Superclasse, selecione Recursiva e depois clique em OK.

  6. Na janela Resultados da Consulta, desloque até ao final da lista e depois faça duplo clique em TrustedRootKey ().

  7. Na caixa de diálogo Editor de objetos TrustedRootKey, clique em Instâncias.

  8. Na nova janela Resultados da Consulta, que apresenta as instâncias de TrustedRootKey, faça duplo clique em TrustedRootKey=@

  9. Na caixa de diálogo Editor de objetos TrustedRootKey=@, na secção Propriedades, desloque para baixo até TrustedRootKey CIM_STRING. A cadeia na coluna da direita é a chave de raiz fidedigna. Confirme que esta chave corresponde ao valor de SMSPublicRootKey no ficheiro <diretório do Configuration Manager>\bin\mobileclient.tcf.

Quando utiliza certificados PKI para todas as comunicações de cliente, não é necessário planear a assinatura e encriptação para ajudar a proteger a comunicação de dados de cliente. No entanto, se configurar sistemas de sites com IIS para permitir ligações de cliente HTTP, tem de decidir como ajudará a proteger a comunicação de cliente para o site.

Para ajudar a proteger os dados que os clientes enviam para os pontos de gestão, é possível requerer que os dados sejam assinados. Além disso, é possível requerer que todos os dados assinados de clientes que utilizam HTTP sejam assinados utilizando o algoritmo SHA-256. Embora esta definição seja mais segura, ative esta opção apenas se todos os clientes suportarem SHA-256. Muitos sistemas operativos suportam SHA-256 de forma nativa, mas os sistemas operativos mais antigos poderão necessitar de uma atualização ou de uma correção. Por exemplo, os computadores com o Windows Server 2003 SP2 têm de instalar uma correção que é mencionada no artigo KB 938397.

Enquanto a assinatura ajuda a proteger os dados contra adulteração, a encriptação ajuda a proteger os dados contra a divulgação de informações. Pode ativar a encriptação 3DES para os dados de inventário e as mensagens de estado que os clientes enviam para os pontos de gestão do site. Não é necessário instalar qualquer atualização nos clientes para suportarem esta opção, mas tenha em atenção a utilização adicional da CPU que será necessária nos clientes e no ponto de gestão para efetuar a encriptação e a desencriptação.

Para obter informações sobre como configurar as definições de assinatura e encriptação, consulte a secção Configurar a Assinatura e Encriptação do tópico Configurar a Segurança para o Configuration Manager.

A administração baseada em funções permite conceber e implementar a segurança administrativa para a hierarquia do System Center 2012 Configuration Manager utilizando qualquer uma ou todas as seguintes definições:

  • Funções de segurança

  • Coleções

  • Âmbitos de segurança

Estas definições são combinadas para definir um âmbito administrativo para um utilizador administrativo. O âmbito administrativo controla os objetos que um utilizador administrativo pode ver na consola do Gestor de configuração e as permissões que esse utilizador tem nesses objetos. As configurações da administração baseada em funções são replicadas para cada site da hierarquia como dados globais e são depois aplicadas a todas as ligações administrativas.

System_CAPS_importantImportante

Os atrasos na 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 monitorizar a replicação de bases de dados entre locais, consulte a secção Como Monitorizar Ligações de Replicação de Base de Dados e o Estado da Replicação do tópico Monitorizar os sites e a hierarquia do Configuration Manager.

Utilize funções de segurança para conceder permissões de segurança a utilizadores administrativos. As funções de segurança são grupos de permissões de segurança que são atribuídas aos utilizadores administrativos para que estes possam desempenhar as suas tarefas administrativas. Estas permissões de segurança definem as ações administrativas que um utilizador administrativo pode executar e as permissões que são concedidas para tipos de objetos específicos. Como melhor prática de segurança, atribua as funções de segurança que proporcionam menos permissões.

O System Center 2012 Configuration Manager possui várias funções de segurança incorporadas para suportar agrupamentos comuns de tarefas administrativas e é possível criar funções de segurança personalizadas para suportar necessidades comerciais específicas. Exemplos das funções de segurança incorporadas:

  • Administrador Total: Esta função de segurança concede todas as permissões no Gestor de configuração.

  • Analista de Ativos: Esta função de segurança permite que os utilizadores administrativos visualizem os dados recolhidos através da utilização do Asset Intelligence, inventário de software, inventário de hardware e medição de software. Os utilizadores administrativos podem criar regras de medição e categorias, famílias e etiquetas do Asset Intelligence.

  • Gestor de Atualizações de Software: Esta função de segurança concede permissões para definir e implementar atualizações de software. Os utilizadores administrativos que estão associados a esta função podem criar coleções, grupos de atualizações de software, implementações, modelos e permitir atualizações de software para NAP (Proteção de Acesso à Rede).

System_CAPS_tipSugestão

A lista de funções de segurança incorporadas e de funções de segurança personalizadas criadas, incluindo as suas descrições, pode ser consultada na consola do Gestor de configuração. Para tal, na área de trabalho Administração, expanda Segurança e selecione Funções de Segurança.

Cada função de segurança tem permissões específicas para tipos de objetos diferentes. Por exemplo, a função de segurança Administrador de Aplicações tem as seguintes permissões para aplicações: Aprovar, Criar, Eliminar, Modificar, Modificar Pastas, Mover Objetos, Ler/Implementar, Definir Âmbito de Segurança. Não é possível alterar as permissões das funções de segurança incorporadas, mas é possível copiar a função, alterá-la e guardar as alterações como uma nova função de segurança personalizada. Também é possível importar funções de segurança exportadas de outra hierarquia (por exemplo, de uma rede de teste). Reveja as funções de segurança e as respetivas permissões para determinar se irá utilizar as funções de segurança incorporadas ou se terá de criar as suas próprias funções de segurança personalizadas.

Utilize os passos seguintes para o ajudar a planear funções de segurança:

  1. Identifique as tarefas que os utilizadores administrativos executam no System Center 2012 Configuration Manager. Estas tarefas podem estar relacionadas com um ou mais grupos de tarefas de gestão, tais como a implementação de aplicações e pacotes, a implementação de sistemas operativos e definições de compatibilidade, a configuração de sites e da segurança, auditorias, o controlo remoto de computadores e a recolha de dados de inventário.

  2. Mapeie estas tarefas administrativas para uma ou mais das funções de segurança incorporadas.

  3. Se alguns utilizadores administrativos executam as tarefas de várias funções de segurança, atribua-as a estes utilizadores administradores em vez de criar uma nova função de segurança que combine todas as tarefas.

  4. Se as tarefas identificadas não mapearem para as funções de segurança incorporadas, crie e teste novas funções de segurança.

Para obter informações sobre como criar e configurar funções de segurança para a administração baseada em funções, consulte as secções Criar Funções de Segurança Personalizadas e Configurar Funções de Segurança do tópico Configurar a Segurança para o Configuration Manager.

As coleções especificam os recursos de utilizador e de computador que um utilizador administrativo pode ver ou gerir. Por exemplo, para poderem implementar aplicações ou efetuar o controlo remoto, os utilizadores administrativos devem ter atribuída uma função de segurança que conceda acesso a uma coleção que contenha esses recursos. É possível selecionar coleções de utilizadores ou dispositivos.

Para mais informações sobre coleções, consulte Introdução às coleções de sites no Configuration Manager.

Antes de configurar a administração baseada em funções, verifique se criou novas coleções por qualquer um dos seguintes motivos:

  • Organização funcional. Por exemplo, coleções separadas de servidores e de estações de trabalho.

  • Alinhamento geográfico. Por exemplo, coleções separadas para a América do Norte e para a Europa.

  • Requisitos de segurança e processos empresariais. Por exemplo, coleções separadas para computadores de produção e de teste.

  • Alinhamento organizacional. Por exemplo, coleções separadas para cada unidade de negócio.

Para obter informações sobre como configurar coleções para a administração baseada em funções, consulte a secção Configurar Coleções para Gerir a Segurança do tópico Configurar a Segurança para o Configuration Manager.

Utilize âmbitos de segurança para fornecer aos utilizadores administrativos acesso a objetos com capacidade de segurança. Os âmbitos de segurança são um conjunto nomeado de objetos com capacidade de segurança que são atribuídos a utilizadores administrativos como um grupo. Todos os objetos com capacidade de segurança têm de ser atribuídos a um ou mais âmbitos de segurança. Gestor de configuração tem dois âmbitos de segurança incorporados:

  • Todos: este âmbito de segurança incorporado concede acesso a todos os âmbitos. Não é possível atribuir objetos a este âmbito de segurança.

  • Predefinido: este âmbito de segurança incorporado é utilizado para todos os objetos por predefinição. Quando instala o System Center 2012 Configuration Manager pela primeira vez, os objetos são todos atribuídos a este âmbito de segurança.

Se pretender restringir os objetos que os utilizadores administrativos podem ver e gerir, tem de criar e utilizar os seus próprio âmbitos de segurança personalizados. Os âmbitos de segurança não suportam uma estrutura hierárquica e não podem ser aninhados. Os âmbitos de segurança podem conter um ou mais tipos de objetos, nomeadamente:

  • Subscrições de alertas

  • Aplicações

  • Imagens de arranque

  • Grupos de limites

  • Itens de configuração

  • Definições de cliente personalizadas

  • Pontos de distribuição e grupos de pontos de distribuição

  • Pacotes de controladores

  • Condições globais

  • Tarefas de migração

  • Imagens de sistema operativo

  • Pacotes de instalação de sistema operativo

  • Pacotes

  • Consultas

  • Sites

  • Regras de medição de software

  • Grupos de atualizações de software

  • Pacotes de atualizações de software

  • Pacotes de sequências de tarefas

  • Pacotes e itens de definição de dispositivos Windows CE

Existem também alguns objetos que não podem ser incluídos em âmbitos de segurança porque apenas são protegidos por funções de segurança. O acesso administrativo às funções de segurança não pode ser limitado a um subconjunto dos objetos disponíveis. Por exemplo, pode ter um utilizador administrativo que cria grupos de limites que são utilizados para um site específico. Uma vez que o objeto de limite não suporta âmbitos de segurança, não é possível atribuir a este utilizador um âmbito de segurança que forneça acesso apenas aos limites que possam estar associados a esse site. Dado que não é possível associar um objeto de limite a um âmbito de segurança, quando é atribuída a um utilizador uma função de segurança que inclui acesso a objetos de limites, esse utilizador pode aceder a todos os limites na hierarquia.

Exemplos de objetos que não são limitados por âmbitos de segurança:

  • Florestas do Active Directory

  • Utilizadores administrativos

  • Alertas

  • Políticas Antimalware

  • Limites

  • Associações de computador

  • Predefinições de cliente

  • Modelos de implementação

  • Controladores de dispositivo

  • Conector do Exchange Server

  • Mapeamentos site a site de migração

  • Perfis de inscrição de dispositivos móveis

  • Funções de segurança

  • Âmbitos de segurança

  • Endereços de sites

  • Funções do sistema de sites

  • Títulos de software

  • Atualizações de software

  • Mensagens de estado

  • Afinidades de dispositivo do utilizador

Crie âmbitos de segurança quando tiver de limitar o acesso a instâncias de objetos separadas. Por exemplo:

  • Tem um grupo de utilizadores administrativos que deve poder ver aplicações de produção e não aplicações de teste. Crie um âmbito de segurança para aplicações de produção e outro para as aplicações de teste.

  • Utilizadores administrativos diferentes necessitam de acesso diferente a algumas instâncias de um tipo de objeto. Por exemplo, um grupo de utilizadores administrativos necessita da permissão de Leitura para grupos de atualizações de software específicos e outro grupo de utilizadores administrativos necessita das permissões Modificar e Eliminar para outros grupos de atualização de software. Crie âmbitos de segurança diferentes para estes grupos de atualizações de software.

Para obter informações sobre como configurar âmbitos de segurança para a administração baseada em funções, consulte a secção Configurar Âmbitos de Segurança para um Objeto do tópico Configurar a Segurança para o Configuration Manager.

Mostrar: