Guia de implantação do Device Guard

Artigo
04/01/2016

Microsoft Device Guard é um conjunto de recursos que consiste em recursos de proteção à integridade do sistema de hardware e software que revolucionam a segurança do sistema operacional Windows. O Windows 10 emprega o Device Guard, bem como recursos de hardware avançados e de integridade de código, como extensões de virtualização de CPU, Trusted Platform Module e conversão de endereço de segundo nível para oferecer ampla segurança moderna aos seus usuários. Este guia explora os recursos individuais do Device Guard, bem como o planejamento, a configuração e a implantação desses recursos.

Introdução ao Device Guard

O cenário de ameaças de segurança atual é mais agressivo do que nunca. Ataques mal intencionados modernos se concentram na geração de receita, no roubo de propriedade intelectual e na degradação do sistema-alvo, o que resulta em perda financeira. Muitos desses invasores modernos são patrocinados por estados nacionais com motivos desconhecidos e grandes orçamentos de terrorismo cibernético. Essas ameaças podem entrar em uma empresa por meio de algo tão simples quanto uma mensagem de email e podem danificar permanentemente a reputação em proteger os ativos de software, bem como ter um impacto financeiro significativo. O Windows 10 introduz vários novos recursos de segurança que ajudam a reduzir uma grande porcentagem das ameaças conhecidas atualmente.

Estima-se que mais de 300.000 novas variantes de malware sejam descobertas diariamente. Infelizmente, as empresas usam atualmente um método antigo para descobrir esses softwares infecciosos e impedir seu uso. Na verdade, os computadores atuais confiam em tudo o que é executado até que assinaturas de malware determinem se existe uma ameaça; então, o software antimalware tenta limpar o computador, normalmente após o efeito do software mal-intencionado já ter sido observado. Esse sistema baseado em assinatura se concentra em reagir a uma infecção e garantir que a infecção específica não aconteça novamente. Nesse modelo, o sistema que conduz a detecção de malware depende da descoberta do software mal-intencionado; só então uma assinatura pode ser fornecida para o cliente para corrigi-lo, o que implica um computador ser infectado primeiro. O tempo entre a detecção do malware e a emissão de uma assinatura para o cliente pode significar a diferença entre a perda de dados e a segurança.

Além das soluções antimalware, existem algumas tecnologias de "lista branca" disponíveis, inclusive AppLocker. Essas tecnologias executam regras de instância única, ou de permissão ou negação amplas, para aplicativos em execução. Embora seja mais preventivo do que a detecção baseada em assinatura, isso requer uma manutenção contínua significativa. No Windows 10, esses aplicativos são mais efetivos quando implantados com o Microsoft Device Guard.

O Device Guard quebra o modelo atual de detectar primeiro e bloquear depois, e permite que apenas os aplicativos confiáveis sejam executados, ponto. Essa metodologia é consistente com a estratégia de prevenção bem sucedida para a segurança do telefone celular. Com o Device Guard, a Microsoft mudou a forma como o sistema operacional Windows manipula aplicativos não confiáveis, o que torna suas defesas difíceis para um malware penetrar. Esse novo modelo de prevenção versus o modelo de detecção oferece aos clientes do Windows a segurança necessária contra ameaças modernas e, quando implementado, torna a maioria das ameaças atuais totalmente obsoleta desde o início.

Os recursos do Device Guard revolucionam a segurança do sistema operacional Windows, usufruindo as novas opções de segurança baseada em virtualização (VBS) e o modelo do sistema operacional de dispositivo móvel de não confiar em nada, que deixa as defesas muito mais difíceis para o malware penetrar. Usando políticas de integridade de código configuráveis, as organizações podem escolher exatamente quais aplicativos podem ser executados no ambiente. A integridade de código configurável não está limitada a aplicativos da Windows Store e pode ser usada com aplicativos Win32 não assinados ou assinados existentes, sem o requisito de que o aplicativo seja reempacotado. Além disso, a integridade de código configurável pode ser implantada como um recurso individual caso as organizações não possuam o hardware necessário para o Device Guard. Com a integridade de código, o Windows 10 aproveita os recursos de hardware avançado como extensões de virtualização de CPU, unidades de gerenciamento de memória de entrada/saída (IOMMUs), Trusted Platform Module (TPM) e conversão de endereços de segundo nível (SLAT) para oferecer uma ampla segurança moderna aos usuários. O Device Guard implantado com uma integridade de código configurável e o Credential Guard estarão entre as implantações de segurança do lado do cliente mais impactantes que uma organização pode implementar atualmente. Neste guia, você saberá mais sobre os recursos individuais encontrados no Device Guard, bem como a maneira como se planejar para, configurar e implantá-los. O Device Guard com integridade de código configurável se destina à implantação com recursos do Windows de redução das ameaças adicionais, como Credential Guard e AppLocker.

Visão geral do Device Guard

O Device Guard é um conjunto de recursos que consiste em recursos de proteção à integridade do sistema de hardware e software. Esses recursos revolucionam a segurança do sistema operacional Windows, usufruindo as novas opções de segurança baseada em virtualização e o modelo do sistema operacional de dispositivo móvel de não confiar em nada. Um recurso-chave nesse modelo se chama integridade de código configurável, que permite à organização escolher exatamente quais software ou fornecedores de software confiáveis têm permissão para executar código nos computadores cliente – exatamente o que causou o sucesso da segurança em telefones celulares. Além disso, o Device Guard oferece às organizações uma maneira de assinar aplicativos de linha de negócios (LOB) existentes, de maneira que eles possam confiar no próprio código, sem o requisito de que o aplicativo seja reempacotado. Além disso, esse mesmo método de assinatura oferece às organizações uma maneira de confiar em aplicativos de terceiros individuais. O Device Guard – com integridade de código configurável, Credential Guard e AppLocker – é a defesa de segurança mais completa que qualquer produto Microsoft jamais ofereceu a um cliente do Windows.

Os recursos de hardware avançados, como extensões de virtualização de CPU, IOMMUs e SLAT, determinam essas novas ofertas de segurança de cliente. Integrando esses recursos de hardware adicionais ao sistema operacional básico, o Windows 10 os aproveita de novas maneiras. Por exemplo, a mesma tecnologia de hipervisor tipo 1 usada para executar máquinas virtuais no Microsoft Hyper-V é usada para isolar os serviços básicos do Windows em um contêiner protegido, baseado em virtualização. Este é apenas um exemplo de como o Windows 10 integra recursos de hardware avançados mais profundamente no sistema operacional para oferecer uma segurança moderna abrangente aos usuários. Esses recursos de hardware agora estão disponíveis nos mercados de PCs para consumidores e corporativos e são abordados em detalhes na seção Considerações sobre hardware.

Além desses novos recursos, alguns componentes do Device Guard são ferramentas ou tecnologias existentes que foram incluídas nesta oferta estratégica de segurança para fornecer aos clientes o sistema operacional Windows mais seguro possível. O Device Guard destina-se a ser um conjunto de recursos de segurança do cliente a ser usado junto com outros recursos de resistência a ameaças disponíveis no sistema operacional Windows, alguns dos quais são mencionados neste guia. Além de uma visão geral de cada recurso, este guia orienta você em meio à configuração e à implantação deles.

Integridade de código configurável

O sistema operacional Windows consiste em dois modos de operação: modo de usuário e modo kernel. A base do sistema operacional é executada no modo kernel, que é onde o sistema operacional Windows faz interface diretamente com os recursos de hardware. O modo de usuário é responsável principalmente por executar aplicativos e intermediar informações para e do modo kernel para solicitações de recursos de hardware. Por exemplo, quando um aplicativo em execução no modo de usuário precisa de mais memória, o processo de modo de usuário deve solicitar os recursos do kernel, e não diretamente da RAM.

Código de integridade é o componente do sistema operacional Windows que verifica se o código que o Windows está executando é confiável e seguro. Como o sistema operacional, o código de integridade do Windows também contém dois componentes principais: a integridade de código do modo kernel (KMCI) e a integridade de código do modo de usuário (UMCI). A KMCI tem sido usada em versões recentes do sistema operacional Windows para proteger o modo kernel da execução de drivers não assinados. Embora eficazes, os drivers não são a única rota que esse malware pode usar para penetrar no espaço do modo kernel do sistema operacional. Entretanto, no Windows 10, a Microsoft criou o padrão para código do modo kernel integrado, bem como forneceu às empresas uma maneira de definir os próprios padrões UMCI e KMCI. Começando pelo próprio serviço de integridade de código e continuando com as políticas que um cliente Windows usa para verificar se um aplicativo deve ter permissão para ser executado, a Microsoft tornou o Windows 10 mais seguro do que qualquer versão anterior do Windows. Historicamente, a UMCI esteve disponível somente no Windows RT e em dispositivos com Windows Phone, o que dificultou a infecção desses dispositivos por vírus e malware. No Windows 10, esses mesmos padrões UMCI bem-sucedidos estão disponíveis.

Historicamente, a maioria dos malware não é assinada. Com a simples implantação de políticas de integridade de código, as organizações se protegerão imediatamente de malware não assinados, responsáveis por mais de 95 por cento dos ataques atuais, estima-se. Usando políticas de integridade de código, uma empresa pode selecionar exatamente quais binários têm permissão para execução nos modos de usuário e kernel, do assinante ao nível de hash. Quando totalmente imposta, ela faz o modo de usuário no Windows funcionar como um telefone móvel, permitindo que somente aplicativos específicos ou assinaturas especiais sejam confiáveis e executados. Sozinho, esse recurso muda fundamentalmente a segurança em uma empresa. Essa segurança adicional não é limitada aos aplicativos do Windows e não exige que um aplicativo seja reescrito para ser compatível com os aplicativos não assinados existentes. Você pode implementar a integridade de código configurável sem habilitar o Device Guard, mas ela deverá ser executada com o Device Guard quando houver hardware compatível disponível. Para obter mais informações sobre como configurar, implantar e gerenciar políticas de integridade de código, consulte a seção Políticas de integridade de código.

Recursos de segurança de hardware e segurança baseada em virtualização

A funcionalidade básica do Device Guard e a proteção começam no nível do hardware. Dispositivos com processadores equipados com tecnologias SLAT e extensões de virtualização, como Intel Virtualization Technology (VT-x) e AMD-V, poderão usufruir recursos de segurança baseada em virtualização (VBS) que melhoram a segurança do Windows. O Device Guard aproveita a VBS para isolar serviços básicos do Windows críticos para a segurança e a integridade do sistema operacional. Esse isolamento remove a vulnerabilidade desses serviços dos modos de usuário e kernel e funciona como uma barreira impenetrável para a maioria dos malware usados atualmente. Um desses serviços isolados, chamado de serviço de integridade de código do Windows, comanda o recurso de integridade de código configurável do modo kernel do Device Guard. Isso evita que o código que penetrou as operações de modo kernel comprometa o serviço de integridade de código.

Outro recurso do Windows 10 que usa a VBS é o Credential Guard. O Credential Guard oferece proteção adicional para usuários de domínio do Active Directory, armazenando credenciais de domínio dentro do contêiner de virtualização que hospeda os serviços de segurança do Windows, como integridade de código. Isolando-se essas credenciais de domínio do modo de usuário ativo e do modo kernel, elas correm um risco muito menor de serem roubadas. Para obter mais informações sobre como o Credential Guard complementa o Device Guard, consulte a seção Device Guard com Credential Guard. Para obter informações sobre como habilitar o Credential Guard, consulte a seção Habilitar o Credential Guard.

Device Guard com AppLocker

Embora o AppLocker não seja considerado um novo recurso do Device Guard, ele complementa a funcionalidade do Device Guard quando a integridade de código imposta não pode ser totalmente implementada ou a funcionalidade não abrange todos os cenários desejados. Há muitos cenários em que políticas de integridade de código seriam usadas com regras do AppLocker. Como melhor prática, você deve impor políticas de integridade de código no nível mais restritivo possível para a organização e, assim, poder usar o AppLocker para ajustar as restrições em um nível ainda mais baixo.

Observação Um exemplo em que a funcionalidade do Device Guard precisa da suplementação do AppLocker acontece quando a organização gostaria de limitar aplicativos universais. Os aplicativos universais já foram validados pela Microsoft como sendo confiáveis para execução, mas uma organização talvez não queira permitir que aplicativos universais específicos sejam executados no ambiente. Você pode fazer essa imposição usando uma regra do AppLocker.

O AppLocker e o Device Guard devem ser executados lado a lado na organização, o que oferece o melhor dos dois recursos de segurança ao mesmo tempo e fornece a segurança mais abrangente ao máximo de dispositivos possível. Além desses recursos, a Microsoft recomenda que você continue mantendo uma solução de antivírus corporativa para ter um portfólio de segurança corporativa bem consistente.

Device Guard com Credential Guard

Embora o Credential Guard não seja um recurso do Device Guard, muitas organizações provavelmente implantarão o Credential Guard com o Device Guard para ter uma proteção adicional contra o roubo de credenciais. Semelhante à proteção baseada em virtualização da integridade de código do modo kernel, o Credential Guard aproveita a tecnologia do hipervisor para proteger credenciais de domínio. Essa mitigação é direcionada para resistir ao uso de técnicas pass-the-hash e pass-the-ticket. Empregando uma autenticação multifator com o Credential Guard, as organizações podem obter proteção adicional contra essas ameaças. Para obter informações sobre como implantar o Credential Guard nos clientes do Windows 10 Enterprise, consulte a seção Habilitar o Credential Guard. Além da habilitação do lado do cliente do Credential Guard, as organizações podem implantar mitigações na CA e no nível de controlador de domínio para ajudar a evitar o roubo de credenciais. A Microsoft divulgará detalhes sobre essas mitigações adicionais no futuro.

Capacidade de gerenciamento unificada

Você pode gerenciar facilmente os recursos do Device Guard usando as ferramentas familiares de gerenciamento do cliente e corporativas que o profissionais de TI usam todos os dias. Use as seguintes ferramentas de gerenciamento para habilitar e gerenciar o Device Guard:

Política de Grupo. O Windows 10 oferece um modelo administrativo para configurar e implantar as políticas de integridade de código configurável para a organização. Esse modelo também permite que você especifique quais recursos de segurança baseada em hardware você gostaria de habilitar e implantar. Você pode gerenciar essas configurações com os Objetos de Política de Grupo (GPOs) existentes, simplificando a implementação dos recursos do Device Guard. Além desses recursos de segurança baseada em hardware e da integridade de código, você pode usar Política de Grupo para ajudar a gerenciar os arquivos de catálogo. Para obter mais informações sobre arquivos de catálogo, consulte a seção Arquivos de catálogo.
Microsoft System Center Configuration Manager. Você pode usar o System Center Configuration Manager para simplificar a implantação e o gerenciamento de arquivos de catálogo, as políticas de integridade de código e os recursos de segurança baseados em hardware, bem como fornecer controle de versão. Para obter mais informações sobre como implantar arquivos de catálogo usando o System Center Configuration Manager, consulte a seção Implantar arquivos de catálogo com o System Center Configuration Manager.
Microsoft Intune. Em uma versão futura do Microsoft Intune, as organizações poderão usufruir o Intune para implantação e gerenciamento de políticas de integridade de código e arquivos de catálogo.
Windows PowerShell. O Windows PowerShell é usado principalmente para criar e oferecer políticas de integridade de código. Essas políticas representam o componente mais poderoso do Device Guard. Para ver um passo a passo de como criar, auditar, oferecer, impor e implantar políticas de integridade de código, consulte a seção Políticas de integridade de código.

Essas opções oferecem a mesma experiência a que você está acostumado para gerenciar as soluções de gerenciamento corporativo existentes. Para obter mais informações sobre como gerenciar e implantar um hardware do Device Guard e recursos de integridade de código na organização, consulte a seção Implantação do Device Guard.

Planejar-se para o Device Guard

Nesta seção, você saberá mais sobre os seguintes tópicos:

Abordagem da implantação de integridade de código corporativa. A implantação do Device Guard na organização requer uma abordagem planejada. Nesta seção, você obtém recomendações de alto nível quanto à abordagem da implantação de integridade de código corporativa na organização.
Cenários de implantação do Device Guard. Quando você planeja a implantação do Device Guard, a Microsoft recomenda que você categorize cada dispositivo na organização em um cenário de implantação. Esses cenários fornecerão um mapa para a implantação do Device Guard.
Adoção da assinatura de código. A assinatura de código é importante para a segurança que o Device Guard oferece. Esta seção descreve as opções de assinatura de código e as vantagens e desvantagens de cada método.
Considerações sobre hardware. Diversos recursos do Device Guard exigem hardware avançado. Esta seção descreve os requisitos para cada um desses recursos e o que procurar durante a próxima atualização de hardware.

Abordagem da implantação de integridade de código corporativa

As empresas que desejam usar o Device Guard não devem esperar uma implantação em toda a organização da noite para o dia. A implementação do Device Guard requer que você se planeje para o impacto do usuário final e do profissional de TI. Além disso, a implantação de recursos do Device Guard na empresa requer uma abordagem planejada, em fases, para garantir que os sistemas de usuário final sejam totalmente compatíveis e estejam prontos para impor essas novas restrições de segurança. Realize as seguintes tarefas de alto nível para abordar a implantação do Device Guard na empresa:

Agrupar dispositivos em funções semelhantes. Categorize computadores nos grupos descritos na seção Cenários de implantação do Device Guard. Isso inicia o mapa para a implantação do Device Guard e oferece grupos de implementações mais fáceis e mais difíceis. A partir daí, avalie a quantidade de políticas do Device Guard necessárias. A solução mais fácil é bloquear toda a empresa, mas isso talvez não atenda às necessidades dos departamentos individuais.

Para descobrir um número apropriado de políticas para a organização, tente separar os grupos definidos em departamentos ou funções. Em seguida, faça algumas perguntas: de qual software cada departamento ou função precisa para fazer seu trabalho? Ele devem ser capazes de instalar e executar software de outros departamentos? Precisamos criar uma política de integridade de código base que se alinhe com nosso catálogo de aplicativos? Os usuários devem ser capazes de instalar qualquer aplicativo ou apenas escolher um em uma lista de "permissões"? Permitimos que os usuários utilizem os próprios dispositivos periféricos? Essas perguntas ajudarão você a descobrir o número de políticas necessárias para a organização. Por fim, tente se concentrar em quais pessoas ou departamentos exigiriam um nível adicional de privilégios. Por exemplo, o departamento x pode instalar e executar o aplicativo xyz, mesmo que nenhum outro departamento possa? Se a resposta for sim e justificável, você precisará de uma política de integridade de código secundária para esse grupo. Do contrário, você provavelmente poderá mesclar diversas políticas para simplificar o gerenciamento. Para obter mais informações sobre políticas de integridade de código configuráveis, consulte a seção Políticas de integridade de código.
Criar políticas de integridade de código com base em computadores "ouro". Depois de criar os grupos de dispositivos, você poderá criar políticas de integridade de código a serem alinhadas com esses grupos, algo semelhante à maneira como você gerenciaria imagens corporativas. Quando você tiver separado esses grupos e definido computadores ouro imitando o software e o hardware que esses grupos individuais exigem, crie políticas de integridade de código em cada um deles. Depois de criá-las, você poderá mesclar essas políticas de integridade de código para criar uma política mestre, ou gerenciar e implantá-las individualmente. Para obter instruções passo a passo sobre como criar políticas de integridade de código, consulte a seção Criar políticas de integridade de código com base em computadores "ouro".
Auditar e mesclar políticas de integridade de código. A Microsoft recomenda testar políticas de integridade de código no modo de auditoria antes de impô-las. O modo de auditoria permite que os administradores executem a política de integridade de código em um sistema, mas não bloqueiem nada. Em vez de não permitir a execução de aplicativos, os eventos são registrados em log com cada exceção à política. Dessa forma, você pode realçar facilmente todos os problemas que não foram descobertos durante a verificação inicial. Você pode criar políticas de integridade de código adicional usando os eventos de auditoria e mesclá-las na política existente. Para obter mais informações sobre como auditar políticas de integridade, consulte a seção Auditar políticas de integridade de código.
Avaliar aplicativos LOB que não são estejam assinados no momento e criar um arquivo de catálogo para eles. Os arquivos de catálogo permitem que as organizações assinem aplicativos que não possuem binários assinados digitalmente no momento ou aplicativos a que um cliente adicionaria uma assinatura secundária. Esses aplicativos podem ser aplicativos internos ou de terceiros partes, e o processo não requer reempacotamento do aplicativo. Ao criar políticas de integridade de código em um nível de regra acima dos valores de hash, você não descobrirá aplicativos não assinados. Para incluir esses aplicativos nas políticas de integridade de código, basta criar, assinar e implantar um arquivo de catálogo. Para obter informações sobre arquivos de catálogo, consulte a seção Arquivos de catálogo.
Habilitar recursos de segurança de hardware desejados. Cada tipo de dispositivo encontrado na seção Cenários de implantação do Device Guard tira proveito das diferentes configurações de integridade de hardware e software. Você deve avaliar os recursos de segurança baseada em hardware separadamente das políticas de integridade de código porque eles oferecem uma funcionalidade complementar. Para obter informações sobre como configurar recursos de segurança baseada em hardware do Device Guard, consulte a seção Configurar recursos de segurança baseada em hardware.
Implantar políticas de integridade de código e arquivos de catálogo. Depois que tiver criado e assinado os arquivos de catálogo necessários, além de criado e auditado as políticas de integridade de código, você estará pronto para implantá-los em fases. É altamente recomendável pela Microsoft implantar esses componentes em um grupo de usuários de teste, mesmo depois que a organização de TI os tiver testado e vetado. Isso oferece uma validação de controle de qualidade final antes de implantar os arquivos de catálogo e as políticas de maneira mais ampla. Para obter informações sobre como implantar arquivos de catálogo com Política de Grupo, consulte a seção Implantar arquivos de catálogo com Política de Grupo. Para obter informações adicionais sobre como implantar políticas de integridade de código, consulte a seção Implantar políticas de integridade de código com Política de Grupo.

Cenários de implantação do Device Guard

Para ajudar a simplificar a implantação do Device Guard na organização, a Microsoft recomenda agrupar dispositivos nos cenários de implantação descritos nesta seção. O Device Guard não é um recurso que as organizações simplesmente "ativarão"; em vez disso, ele normalmente requer uma abordagem de implementação em fases. Para ver onde esses cenários se enquadram em uma abordagem de implantação do Device Guard geral, consulte a seção Abordagem da implantação de integridade de código corporativa.

Dispositivos de carga de trabalho fixa

As listas de aplicativos aprovados em dispositivos de carga de trabalho fixa raramente mudam à medida que executam as mesmas tarefas dia após dia. Entre os exemplos desses dispositivos estão quiosques, sistemas de ponto de venda e computadores de call center. Esses dispositivos podem facilmente empregar todos os recursos do Device Guard e exigiriam pouco gerenciamento ou modificação de política. A Implementação do Device Guard nesses dispositivos é tranquila e requer pouca administração contínua. Com o Device Guard totalmente implementado, os usuários são capazes de executar apenas os aplicativos que o departamento de TI instala, gerencia e confia

Entre os componentes do Device Guard que são aplicáveis a dispositivos de carga de trabalho fixa estão:

Proteção VBS KMCI

Política UMCI imposta

Dispositivos totalmente gerenciados

Dispositivos totalmente gerenciados são aqueles para os quais o departamento de TI restringe o software que é instalado e executado, mas permite que os usuários solicitem a instalação de software adicional ou fornece uma lista de software aprovados em um catálogo de aplicativos. Entre os exemplos desses dispositivos estão desktops e laptops bloqueados e próprios da empresa. Com esses dispositivos, estabeleça uma política de integridade de código de linha de base inicial e imponha a política de integridade de código. O departamento de TI gerencia as políticas e atualiza os dispositivos quando novos aplicativos são aprovados ou fornecidos no catálogo do System Center Configuration Manager.

Entre os componentes do Device Guard que são aplicáveis a dispositivos totalmente gerenciados estão:

Proteção VBS KMCI
Política UMCI imposta

Neste cenário, uma lista de aplicativos é fornecida e confiável, e a política de confiança é constantemente reavaliada quando um usuário solicita um novo aplicativo. Quando um aplicativo é confiável em todos esses dispositivos, novas solicitações de usuário para esse aplicativo não exigem uma atualização de política (alinhamento com o catálogo de aplicativos). Além disso, você pode somar a isso um processo de inclusão de novos aplicativos que você deve adicionar ao catálogo de aplicativos central. A implementação inicial do Device Guard para dispositivos totalmente gerenciados é simples, mas exige mais sobrecarga administrativa para gerenciar assinaturas confiáveis de aplicativos recém-solicitados e aprovados.

Dispositivos levemente gerenciados

Dispositivos levemente gerenciados são computadores de propriedade da empresa por meio das quais os usuários têm controle completo, o que inclui o que é instalado neles. Esses dispositivos executam a solução antivírus e as ferramentas de gerenciamento cliente da organização, mas não são restringidos por políticas de solicitação ou conformidade de software.

Entre os componentes do Device Guard que são aplicáveis a dispositivos levemente gerenciados estão:

Proteção VBS KMCI
Política UMCI no modo de auditoria

Traga seu próprio dispositivo

O Device Guard não é uma boa maneira de gerenciar dispositivos em um modelo Traga seu próprio dispositivo (BYOD). Quando os funcionários têm permissão para trazer os próprios dispositivos, o gerenciamento de aplicativos no modo de usuário neles pode dificultar para que os usuários usem os próprios dispositivos quando não estiverem no trabalho. Além disso, é difícil manter a funcionalidade do Device Guard do ponto de vista administrativo. Para dispositivos desse grupo, explore os recursos de segurança e proteção alternativos com as soluções de acesso condicional com base em MDM, como o Microsoft Intune.

Adoção da assinatura de código

A assinatura de código é crucial para a implementação bem-sucedida das políticas de integridade de código configurável. Essas políticas podem confiar nos certificados de assinatura de fornecedores independentes de software e clientes. No Windows 10, todos os aplicativos da Windows Store são assinados. Além disso, você pode confiar facilmente em qualquer outro aplicativo assinado adicionando o certificado de assinatura à política de integridade de código.

Para aplicativos não assinados, os clientes têm várias opções para assiná-los de maneira que as políticas de integridade de código possam confiar neles. A primeira opção é a assinatura de código inserida tradicional. As organizações com equipes de desenvolvimento internas podem incorporar a assinatura de código binário ao processo de desenvolvimento de aplicativos e, em seguida, bastará adicionar o certificado de assinatura às políticas de integridade de código. A segunda opção para assinar aplicativos não assinados é usando arquivos de catálogo. No Windows 10, os clientes têm a capacidade de criar arquivos de catálogo à medida que monitoram a instalação e a execução inicial de um aplicativo. Para obter mais informações sobre como assinar aplicativos LOB não assinados ou aplicativos de terceiros, consulte a seção Aplicativos de linha de negócios existentes.

Aplicativos de linha de negócios existentes

Até agora, eram difícil confiar em aplicativos LOB existentes caso eles fossem assinados por uma fonte diferentes da Windows Store ou sequer fossem assinados. Com o Windows 10, a assinatura dos aplicativos LOB existentes e não assinados de terceiros está simplificada. Esse novo método de assinatura não exige que os aplicativos sejam reempacotados de nenhuma forma. Com arquivos de catálogo, os administradores podem assinar esses aplicativos não assinados simplesmente monitorando uma instalação e uma inicialização. Usando essas informações de monitoramento, um administrador pode gerar um arquivo de catálogo. Arquivos de catálogo são apenas listas de hashes Secure Hash Algorithm 2 (SHA2) de binários descobertos. Os valores de hash desses binários são atualizados sempre que um aplicativo é atualizado e, assim, exigem um arquivo de catálogo atualizado. Para obter uma administração simplificada, leve em consideração a possibilidade de inserir a assinatura de código no processo de desenvolvimento de aplicativos. Para obter mais informações sobre como gerar arquivos de catálogo, consulte a seção Arquivos de catálogo.

Observação

Arquivos de catálogo são listas de valores de hash de binários individuais. Se o aplicativo digitalizado for atualizado, você precisará criar um novo arquivo de catálogo. Dito isso, assinar binários continua sendo altamente recomendável para quaisquer aplicativos futuros, de maneira que nenhum arquivo de catálogo é necessário.

Ao criar um arquivo de catálogo, você deve assiná-lo usando a infraestrutura de chave pública (PKI) corporativa ou um certificado de assinatura de código comprado. Quando assinado, as políticas de integridade de código podem confiar no signatário ou no certificado de assinatura desses arquivos. Para obter informações sobre assinatura de arquivos de catálogo, consulte a seção Arquivos de catálogo.

Desenvolvimento de aplicativos

Embora aplicativos internos possam ser assinados depois do empacotamento usando-se arquivos de catálogo, a Microsoft recomenda que a assinatura de código inserido ser incorporada ao processo de desenvolvimento de aplicativos. Ao assinar aplicativos, basta adicionar o certificado de assinatura do código usado para assinar os aplicativos segundo a política de integridade de código. Isso garante que a política de integridade de código confiará em qualquer aplicativo futuro assinado com esse certificado. A inserção da assinatura de código em qualquer processo de desenvolvimento de aplicativos interno é benéfica para a organização de TI à medida que você implementa políticas de integridade de código.

Considerações sobre hardware

Uma consideração atenta sobre de qual fornecedor de hardware e quais modelos específicos comprar durante a próxima atualização de hardware é extremamente importante para o êxito das iniciativas de implementação do Device Guard da organização. Segundo o ciclo de vida de hardware atual, leve em consideração o processo abordado na seção Abordagem da implantação de integridade de código corporativa quando você determinar a ordem apropriada de substituição do hardware na organização. O Device Guard deve ser implantado em fases; por isso, você tem tempo para planejar a implementação de maneira metódica.

Recursos de hardware diferentes são necessárias para implementar os diversos recursos de Device Guard. Provavelmente haverá alguns recursos individuais que você poderá habilitar com o hardware atual e alguns que você não poderá. No entanto, para organizações que queiram implementar o Device Guard na íntegra, diversos recursos de hardware avançado será necessários. Para obter detalhes adicionais sobre os recursos de hardware que são necessários para componentes do Device Guard, consulte a tabela a seguir.

Requisito	Descrição
Windows 10 Enterprise	O computador deve executar o Windows 10 Enterprise.
Firmware UEFI versão 2.3.1 ou superior e Inicialização Segura	Para verificar se o firmware está usando UEFI versão 2.3.1 ou superior e Inicialização Segura, você pode validá-lo em relação ao requisito do Programa de Compatibilidade de Hardware do Windows System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby.
Extensões de virtualização	As seguintes extensões de virtualização são necessárias para dar suporte à segurança baseada em virtualização: Intel VT-x ou AMD-V Conversão de Endereços de Segundo Nível
Bloqueio de firmware	A configuração de firmware deve ser bloqueada para impedir a inicialização de outros sistemas operacionais e alterações nas configurações de UEFI. Você também deve desabilitar métodos de inicialização que não sejam do disco rígido.
Arquitetura x64	Os recursos usados pela segurança baseada em virtualização no hipervisor do Windows podem ser executados apenas em um computador de 64 bits.
Um VT-d ou AMD Vi IOMMU (Unidade de gerenciamento de memória de entrada/saída)	No Windows 10, uma IOMMU aprimora a resiliência do sistema contra ataques à memória. ¹
Processo de atualização de firmware seguro	Para verificar se o firmware está em conformidade com o processo de atualização de firmware seguro, você pode validá-lo em relação ao requisito do Programa de Compatibilidade de Hardware do Windows System.Fundamentals.Firmware.UEFISecureBoot.

Implantação do Device Guard

Nesta seção, você saberá mais sobre os seguintes tópicos:

Configurar recursos de segurança baseada em hardware. Esta seção explica como habilitar os recursos de segurança baseada em hardware no Device Guard. Além disso, você verifica se os recursos estão habilitados usando a Infraestrutura de Gerenciamento do Windows (WMI) e Msinfo32.exe.
Arquivos de catálogo. Nesta seção, você cria, assina e implanta arquivos de catálogo. Você implanta os arquivos de catálogo usando Política de Grupo e System Center Configuration Manager. Além disso, use o System Center Configuration Manager para inventariar os arquivos de catálogo implantados para fins de relatório.
Políticas de integridade de código. Esta seção fornece informações sobre como criar, auditar, manter, mesclar, implantar e remover políticas de integridade de código configurável não assinado.

Configurar recursos de segurança baseada em hardware

Os recursos de segurança baseada em hardware constituem uma grande parte das opções de segurança do Device Guard. VBS reforça o recurso mais importante do Device Guard: integridade de código configurável. Há três etapas para configurar recursos de segurança baseada em hardware no Device Guard:

Verifique se os requisitos de hardware são atendidos e habilitados. Verifique se os computadores cliente possuem o hardware necessário para executar esses recursos. Uma lista de requisitos de hardware para os recursos de segurança baseada em hardware está disponível na seção Considerações sobre hardware. Além disso, caso você esteja procurando um novo hardware, leve em consideração os dispositivos abordados na seção Dispositivos prontos para Device Guard.
Habilite os recursos do Windows necessários. Há várias maneiras de habilitar os recursos do Windows necessários para segurança baseada em hardware. Para obter detalhes sobre quais recursos do Windows são necessários, consulte a seção Requisitos do recurso do Windows para segurança baseada em virtualização.
Habilite os recursos desejados. Quando o hardware e os recursos do Windows necessários tiverem sido habilitados, você estará pronto para habilitar os recursos de segurança baseada em hardware desejados. Para a Inicialização Segura da UEFI, consulte a seção Habilitar Inicialização Segura da UEFI. Para obter informações sobre como habilitar a proteção VBS do serviço KMCI, consulte a seção Habilitar proteção baseada em virtualização da integridade de código do modo kernel. Por fim, para obter informações sobre como habilitar o Credential Guard, consulte a seção Habilitar o Credential Guard.

Requisitos do recurso do Windows para segurança baseada em virtualização

Além dos requisitos de hardware encontrados na seção Considerações sobre hardware, você deve habilitar determinados recursos do sistema operacional para poder habilitar VBS: Microsoft Hyper-V e o modo de usuário isolado (mostrado na Figura 1).

Observação

Você pode configurar esses recursos manualmente usando o Windows PowerShell ou Gerenciamento e Manutenção de Imagens de Implantação. Para obter informações específicas sobre esses métodos, consulte a Documentação do Credential Guard.

Figura 1

Figura 1. Habilitar recursos do sistema operacional para VBS

Depois de habilitar esses recursos, você poderá configurar todos os recursos de segurança baseada em hardware desejados. Para obter informações sobre como habilitar a proteção baseada em virtualização da integridade de código do modo kernel, consulte a seção Habilitar proteção baseada em virtualização da integridade de código do modo kernel. Para obter informações sobre como habilitar a Inicialização Segura da UEFI, consulte a seção Habilitar Inicialização Segura da Unified Extensible Firmware Interface. Por fim, para obter informações adicionais sobre como habilitar o Credential Guard, consulte a seção Habilitar o Credential Guard.

Habilitar Inicialização Segura da Unified Extensible Firmware Interface

Antes de começar este processo, verifique se o dispositivo de destino atende aos requisitos de hardware para a Inicialização Segura da UEFI que estão descritos na seção Considerações sobre hardware. Há duas opções para configurar a Inicialização Segura da UEFI: configuração manual das chaves do Registro apropriadas e implantação de Política de Grupo. Conclua as seguintes etapas para configurar manualmente a Inicialização Segura da UEFI em um computador no qual o Windows 10 esteja em execução:

Observação

Há dois níveis de segurança de plataforma para a Inicialização Segura: Inicialização Segura autônoma e Inicialização Segura com a proteção de DMA. A proteção de DMA oferece proteção de memória adicional, mas só será habilitada em sistemas cujos processadores incluam tecnologias de proteção (IOMMU) de DMA. Sem a presença de IOMMUs e com a proteção de DMA desabilitada, os clientes perderão a proteção contra ataques baseados em driver.

Navegue até a subchave do Registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.
Defina o valor EnableVirtualizationBasedSecurity DWORD como 1.
Defina o valor RequirePlatformSecurityFeatures DWORD conforme apropriado:
- Defina esse valor como 1 para habilitar a opção Inicialização Segura.
- Defina esse valor como 2 para habilitar a opção Secure Boot with DMA Protection.
Reinicie o computador cliente.

Infelizmente, seria demorado realizar essas etapas manualmente em todos os computadores protegidos na empresa. A Política de Grupo oferece uma maneira muito mais simples de implantar a Inicialização Segura da UEFI na organização. Este exemplo cria uma unidade organizacional (UO) de teste chamada DG Enabled PCs. Caso prefira vincular a política a uma UO existente e acabar analisando o GPO usando grupos de segurança de computador devidamente nomeados, você certamente pode fazer isso.

Observação

A Microsoft recomenda testar habilitando esse recurso em um grupo de computadores de teste antes de implantá-lo em computadores que atualmente implantados em usuários.

Usar Política de Grupo para implantar Inicialização Segura

Para criar um novo GPO, clique com o botão direito do mouse na UO à qual você deseja vincular o GPO e clique em Criar um GPO neste domínio e fornecer um link para ele aqui.

Figura 2. Criar um novo GPO vinculado à UO
Dê ao novo GPO o nome Contoso Secure Boot GPO Test. Este exemplo usa Contoso Secure Boot GPO Test como o nome do GPO. Você pode escolher qualquer nome para esse exemplo. O ideal seria que o nome estivesse alinhado com a convenção de nomenclatura do GPO existente.
Para abrir o Editor de Gerenciamento de Política de Grupo, clique com o botão direito do mouse no novo GPO e clique em Editar.
Dentro do GPO selecionado, navegue até o Configuração do Computador\Modelos Administrativos\Sistema\Device Guard. Em seguida, clique com o botão direito do mouse em Ativar Segurança Baseada em Virtualização e clique em Editar.

Figura 3. Habilitar VBS
Selecione a opção Habilitado e Inicialização segura e a proteção de DMA na lista Selecione o Nível de Segurança da Plataforma.

Figura 4. Habilitar Inicialização Segura

Observação

A Inicialização Segura do Device Guard é maximizada quando combinada com a proteção de DMA. Caso o hardware contenha as IOMMUs necessárias para proteção de DMA, não se esqueça de selecionar o nível de segurança da plataforma Inicialização segura e a proteção de DMA. Caso o hardware não contenha uma IOMMU, há diversas mitigações oferecidas pelo aproveitamento da Inicialização Segura sem proteção de DMA.
Feche o Editor de Gerenciamento de Política de Grupo e reinicie o computador de teste do Windows 10. Depois que você definir essa configuração, a Inicialização Segura da UEFI será habilitada durante a reinicialização.
Verifique o log de eventos do computador de teste em busca de GPOs do Device Guard.

As políticas do Device Guard processadas são registradas em log no Visualizador de Eventos em Logs de Aplicativos e Serviços\Microsoft\Windows\DeviceGuard-GPEXT\Operacional. Quando a política Ativar Segurança Baseada em Virtualização é processada com êxito, a ID de evento 7000 é registrada em log, que contém as configurações selecionadas dentro da política.

Habilitar a segurança baseada em virtualização de integridade de código de modo kernel

Antes de começar este processo, verifique se o computador desejado atende aos requisitos de hardware para VBS encontrados na seção Considerações sobre hardware e habilite os recursos do Windows abordados na seção Requisitos do recurso do Windows para segurança baseada em virtualização. Quando validado, você poderá habilitar a proteção baseada em virtualização de KMCI de das duas maneiras: configuração manual das subchaves do Registro apropriadas e implantação de Política de Grupo.

Observação

Todos os drivers no sistema devem ser compatíveis com a proteção baseada em virtualização de integridade de código; do contrário, o sistema pode falhar. A Microsoft recomenda que você habilite esse recurso em um grupo de computadores de teste antes de ativá-lo em máquinas implantadas.

Para configurar a proteção baseada em virtualização de KMCI manualmente:

Navegue até a subchave do Registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.
Defina o valor HypervisorEnforcedCodeIntegrity DWORD como 1.
Reinicie o computador cliente.

Seria demorado realizar essas etapas manualmente em todos os computadores protegidos na empresa. Em vez disso, use a Política de Grupo para implantar a proteção baseada em virtualização de KMCI. Este exemplo cria uma UO de teste chamada DG Enabled PCs, que você usará para vincular o GPO. Caso você prefira vincular a política a uma UO existente, em vez de criar uma UO de teste e analisar a política usando grupos de segurança do computador devidamente nomeados, essa é outra opção.

Observação

A Microsoft recomenda testar habilitando esse recurso em um grupo de computadores de teste antes de implantá-lo em computadores que atualmente implantados em usuários. Caso não seja testado, existe a possibilidade de que esse recurso possa causar instabilidade no sistema e acabar causando uma falha no sistema operacional do cliente.

Para usar Política de Grupo a fim de configurar VBS de KMCI:

Crie um novo GPO: clique com o botão direito do mouse na UO à qual você deseja vincular o GPO e clique em Criar um GPO neste domínio e fornecer um link para ele aqui.

Figura 5. Criar um novo GPO vinculado à UO
Dê ao novo GPO o nome Contoso VBS CI Protection GPO Test.

Este exemplo usa Contoso VBS CI Protection GPO Test como o nome do GPO. Você pode escolher qualquer nome de que sua preferência para este exemplo. O ideal seria que o nome estivesse alinhado com a convenção de nomenclatura do GPO existente.
Abra o Editor de Gerenciamento de Política de Grupo: clique com o botão direito do mouse no novo GPO e clique em Editar.
Dentro do GPO selecionado, navegue até o Configuração do Computador\Modelos Administrativos\Sistema\Device Guard. Em seguida, clique com o botão direito do mouse em Ativar Segurança Baseada em Virtualização e clique em Editar.

Figura 6. Habilitar VBS
Selecione a opção Habilitado e marque a caixa de seleção Habilitar Proteção com Base em Virtualização de Integridade de Código.

Figura 7. Habilitar VBS de KMCI
Feche o Editor de Gerenciamento de Política de Grupo e reinicie o computador de teste do Windows 10. Com essa configuração definida, a VBS da KMCI entrará em vigor após a reinicialização.
Verifique o log de eventos do cliente de teste para GPOs do Device Guard.

As políticas do Device Guard processadas são registradas em log no Visualizador de Eventos em Logs de Aplicativos e Serviços\Microsoft\Windows\DeviceGuard-GPEXT\Operacional. Quando a política Ativar Segurança Baseada em Virtualização tiver sido processada com êxito, a ID de evento 7000 será registrada em log, que contém as configurações selecionadas dentro da política.

Habilitar o Credential Guard

O Credential Guard oferece uma camada adicional de proteção de credencial especificamente para usuários de domínio, armazenando as credenciais dentro do contêiner virtualizado, fora do kernel e do sistema operacional do modo de usuário. Isso dificulta até mesmo para um sistema comprometido obter acesso às credenciais. Além da habilitação do Credential Guard do lado do cliente, você pode implantar mitigações adicionais na autoridade de certificação e no nível do controlador de domínio para evitar o roubo de credenciais. A Microsoft divulgará detalhes sobre essas mitigações adicionais no futuro.

Antes de começar este processo, verifique se o sistema desejado atende aos requisitos de hardware para VBS encontrados na seção Considerações sobre hardware e se você habilitou os recursos do Windows descritos na seção Requisitos do recurso do Windows para segurança baseada em virtualização. Quando validada, você poderá habilitar o Credential Guard manualmente, configurando as subchaves do Registro apropriadas, ou por meio da implantação de Política de Grupo.

Para configurar a VBS do Credential Guard manualmente:

Navegue até a subchave do Registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
Defina o valor LsaCfgFlags DWORD como 1.
Reinicie o computador cliente.

Para evitar perder um tempo desnecessário em implantações manuais, use Política de Grupo para implantar o Credential Guard na organização. Este exemplo cria uma UO de teste chamada DG Enabled PCs. Para habilitar o Credential Guard, você pode se vincular a qualquer UO e analisar o GPO do aplicativo usando grupos de segurança.

Observação

A Microsoft recomenda que você habilite o Credential Guard para adicionar um computador ao domínio e garantir que todas as credenciais estejam devidamente protegidas. Definir as subchaves do Registro apropriadas durante o processo de geração de imagens seria ideal para conseguir essa proteção.

Para usar Política de Grupo e habilitar o Credential Guard:

Crie um novo GPO: clique com o botão direito do mouse na UO à qual você deseja vincular o GPO e clique em Criar um GPO neste domínio e fornecer um link para ele aqui.

Figura 8. Criar um novo GPO vinculado à UO
Dê ao novo GPO o nome Contoso Credential Guard GPO Test.

Este exemplo usa Contoso Credential Guard GPO Test como o nome do GPO. Você pode escolher qualquer nome de que sua preferência para este exemplo. O ideal seria que o nome estivesse alinhado com a convenção de nomenclatura do GPO existente.
Abra o Editor de Gerenciamento de Política de Grupo: clique com o botão direito do mouse no novo GPO e clique em Editar.
Dentro do GPO selecionado, navegue até o Configuração do Computador\Modelos Administrativos\Sistema\Device Guard. Clique com o botão direito do mouse em Ativar Segurança Baseada em Virtualização e clique em Editar.

Figura 9. Habilitar VBS
Selecione a opção Habilitado e marque a caixa de seleção Habilitar Credential Guard.

Figura 10. Habilitar Credential Guard
Feche o Editor de Gerenciamento de Política de Grupo e reinicie o computador de teste do Windows 10.

Observação

O nível de segurança da plataforma padrão é Inicialização Segura. Caso IOMMUs estejam disponíveis em máquinas protegidas, é recomendável selecionar Inicialização segura e a proteção de DMA para maximizar as mitigações disponíveis por meio do Credential Guard.
Verifique o log de eventos do cliente de teste para GPOs do Device Guard.

Observação

Todas as políticas do Device Guard processadas são registradas em log no Visualizador de Eventos em Logs de Aplicativos e Serviços\Microsoft\Windows\DeviceGuard-GPEXT\Operacional.

Para obter informações adicionais sobre como funciona o Credential Guard, bem como outras opções de configuração, consulte a Documentação do Credential Guard.

Validar recursos de segurança baseada em hardware habilitados do Device Guard

O Windows 10, o Windows Server 2016 e as versões posteriores têm uma classe WMI para propriedades e recursos relacionados ao Device Guard: Win32_DeviceGuard. Essa classe pode ser consultada em uma sessão do Windows PowerShell com privilégios elevados usando-se o seguinte comando:

Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard

Observação

A classe WMI Win32_DeviceGuard só está disponível na edição Enterprise do Windows 10.

A saída desse comando dá detalhes sobre os recursos de segurança baseados em hardware, bem como os recursos habilitados no momento. Para obter informações detalhadas sobre o que significa cada propriedade, consulte a Tabela 1.

Tabela 1. Propriedades de Win32_DeviceGuard

Propriedades	Descrição	Valores válidos
AvailableSecurityProperties	Este campo ajuda a enumerar e relatar o estado das propriedades de segurança relevantes do Device Guard.	0. Caso presente, não há propriedades relevantes no dispositivo. 1. Caso presente, há suporte ao hipervisor disponível. 2. Caso presente, a Inicialização Segura está disponível. 3. Caso presente, a proteção de DMA está disponível.
InstanceIdentifier	Uma cadeia de caracteres exclusiva de um dispositivo específico.	Determinado por WMI.
RequiredSecurityProperties	Este campo descreve as propriedades de segurança necessárias para habilitar a segurança baseada em virtualização.	0. Não é necessário fazer nada. 1. Caso presente, Inicialização Segura é necessária. 2. Caso presente, a proteção de DMA é necessária. 3. Caso presente, a Inicialização Segura e a proteção de DMA são necessárias.
SecurityServicesConfigured	Este campo indica se o Credential Guard ou o serviço HVCI foi configurado.	0. Não há serviços configurados. 1. Caso presente, o Credential Guard está configurado. 2. Caso presente, HVCI está configurado.
SecurityServicesRunning	Este campo indica se o Credential Guard ou o serviço HVCI está em execução.	0. Não há serviços em execução. 1. Caso presente, o Credential Guard está em execução. 2. Caso presente, o HVCI está em execução.
Version	Este campo lista a versão da classe WMI.	Agora o único valor válido é 1.0.
VirtualizationBasedSecurityStatus	Este campo indica se a VBS está habilitada e em execução.	0. A VBS não está habilitada. 1. A VBS está habilitada, mas não está em execução. 2. VBS está habilitada e em execução.
PSComputerName	Este campo lista o nome do computador.	Todos os valores válidos para o nome do computador.

Outro método para determinar os recursos disponíveis e habilitados para o Device Guard é executar msinfo32.exe em uma sessão do PowerShell com privilégios elevados. Quando você executa o programa, as propriedades do Device Guard são exibidas na parte inferior da seção Resumo do sistema, conforme mostrado na Figura 11.

Figura 11

Figura 11. Propriedades do Device Guard no Resumo do sistema

Arquivos de catálogo

A imposição do Device Guard em um sistema exige que todos os aplicativos confiáveis tenham uma assinatura ou seus hashes binários adicionados à política de integridade de código. Para muitas organizações, isso pode ser um problema quando se levam em consideração os aplicativos LOB não assinados. Para evitar o requisito de que as organizações reempacotarem e assinarem esses aplicativos, o Windows 10 inclui uma ferramenta chamada Package Inspector que monitora um processo de instalação para quaisquer arquivos binários implantados e executados. Caso a ferramenta descubra esses arquivos, ela os discrimina em um arquivo de catálogo. Esses arquivos de catálogo oferecem uma maneira de confiar em aplicativos não assinados existentes, independentemente de terem sido desenvolvidos internamente ou por terceiros, bem como confiar em assinados aplicativos para os quais você não deseja confiar no signatário, e sim no aplicativo específico. Quando criados, esses arquivos podem ser assinados, os certificados de assinatura adicionados às políticas de integridade de código existentes e os arquivos de catálogo propriamente ditos distribuídos para os clientes.

Observação

A edição Enterprise do Windows 10 ou do Windows Server 2016 é necessária para criar e usar arquivos de catálogo.

Criar arquivos de catálogo

A criação de arquivos de catálogo é a primeira etapa para adicionar um aplicativo não assinado a uma política de integridade de código. Para criar um arquivo de catálogo, copie todos os seguintes comandos em uma sessão do Windows PowerShell com privilégios elevados e conclua as etapas:

Observação

Estabelece uma convenção de nomenclatura facilita detectar arquivos de catálogo implantados no futuro. Neste guia, você usará *-Contoso.cat como a convenção de nomenclatura. Para obter mais informações sobre por que essa prática é útil para inventariar ou detectar arquivos de catálogo, consulte a seção Inventariar arquivos de catálogo com o System Center Configuration Manager.

Certifique-se de que uma política de integridade de código esteja em execução em modo de auditoria no momento.

Inspetor de pacote não detecta sempre arquivos de instalação que foram removidos da máquina durante o processo de instalação. Para garantir que esses binários também sejam confiáveis, a política de integridade de código criada e auditada nas seções Criar políticas de integridade de código com base em computadores "ouro" e Auditar políticas de integridade de código deve ser implantada, em modo de auditoria, no sistema no qual você está executando o Package Inspector.

Observação

Esse processo não deve ser realizado em um sistema no qual uma política do Device Guard imposta esteja em execução, somente com uma política em execução em modo de auditoria. Se uma política estiver sendo imposta no momento, você não poderá instalar e executar o aplicativo.
Inicie o Package Inspector e verifique a unidade C:

PackageInspector.exe Start C:

Observação

O Package Inspector pode monitorar instalações em qualquer unidade local. Neste exemplo, instalamos o aplicativo na unidade C, mas qualquer outra unidade pode ser usada.
Copie a mídia de instalação para a unidade C.

Copiando a mídia de instalação para a unidade C, você garante que Package Inspector detecte e catalogue o instalador real. Caso você ignore esta etapa, a política de integridade de código futura pode confiar na execução do aplicativo, mas não na instalação.
Instale e inicie o aplicativo.

Instale o aplicativo na unidade C. Quando a instalação estiver concluída, inicie o aplicativo e verifique se há atualizações do produto instaladas e se algum conteúdo para baixar foi capturado durante o exame. Quando terminar, feche e reabra o aplicativo novamente para garantir que o exame tenha capturado todos os binários.

Observação

Todo binário executado enquanto o Package Inspector estiver em execução será capturado no catálogo. Por isso, lembre-se de não executar instalações adicionais ou atualizações durante o exame para minimizar o risco de confiar nos binários incorretos. Como alternativa, se você quiser adicionar vários aplicativos a um único arquivo de catálogo, basta repetir a instalação e executar o processo enquanto o exame atual estiver em execução.
Pare a verificação e gere arquivos de definição e catálogo. Quando a instalação e a configuração inicial do aplicativo terminarem, pare o exame do Package Inspector e gere os arquivos de catálogo e de definição na área de trabalho usando os seguintes comandos:

$ExamplePath=$env:userprofile+"\Desktop"

$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"

$CatDefName=$ExamplePath+"\LOBApp.cdf"

PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName

Observação

Essa exame cataloga os valores de hash de cada arquivo binário descoberto. Caso os aplicativos que tiverem sido examinados estejam atualizados, conclua esse processo novamente para confiar nos valores de hash dos novos binários.

Quando terminar, os arquivos serão salvos na área de trabalho. Para confiar nesse arquivo de catálogo dentro de uma política de integridade de código, o catálogo deve ser primeiramente assinado. Em seguida, o certificado de assinatura pode ser incluído na política de integridade de código e o arquivo de catálogo pode ser distribuído para os computadores cliente individuais. Os arquivos de catálogo podem ser assinados usando-se um certificado e SignTool.exe, uma ferramenta gratuita disponível no SDK do Windows. Para obter mais informações sobre como assinar arquivos de catálogo com SignTool.exe, consulte a seção Assinatura do catálogo com SignTool.exe.

Assinatura do catálogo com SignTool.exe

O Device Guard facilita para as organizações assinarem e confiarem em aplicativos LOB não assinados existentes. Nesta seção, você assina um arquivo de catálogo gerado em uma seção anterior usando PackageInspector.exe. Para obter informações sobre como criar arquivos de catálogo, consulte a seção Criar arquivos de catálogo. Neste exemplo, você precisa do seguinte:

SignTool.exe, encontrado no Software Development Kit do Windows (SDK do Windows) (SDK – Windows 7 ou posterior)
O arquivo de catálogo que você gerou na seção Criar arquivos de catálogo ou outro arquivo de catálogo que tenha criado
Certificado de assinatura de código da autoridade de certificação (CA) interno ou certificado de assinatura de código comprado

Caso você não tenha um certificado de assinatura de código, consulte a seção Criar um certificado de assinatura de código do Device Guard para um passo a passo de como criar um. Além de usar o certificado que você criou na seção Criar um certificado de assinatura de código do Device Guard, este exemplo assina o arquivo de catálogo que criou na seção Criar arquivos de catálogo. Caso você esteja usando um certificado alternativo ou um arquivo de catálogo, atualize as etapas a seguir usando as variáveis apropriadas e o certificado. Para assinar o arquivo de catálogo existente, copie cada um dos seguintes comandos em uma sessão do Windows PowerShell com privilégios elevados:

Inicialize as variáveis que serão usadas:
```
$ExamplePath=$env:userprofile+"\Desktop"

$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
```
Observação

Neste exemplo, você usa o arquivo de catálogo que criou na seção Criar arquivos de catálogo. Caso você esteja assinando outro arquivo de catálogo, não se esqueça de atualizar as variáveis $ExamplePath e $CatFileName com as informações corretas.
Importe o certificado de assinatura de código. Importe o certificado de assinatura de código que será usado para assinar o arquivo de catálogo no repositório pessoal do usuário de assinatura. Neste exemplo, você usa o certificado que criou na seção Criar um certificado de assinatura de código do Device Guard.
Assine o arquivo de catálogo usando Signtool.exe:
```
<Path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
```
Observação

A variável <Path to signtool.exe> deve ser o caminho completo para o utilitário Signtool.exe. ContosoDGSigningCert é o nome do requerente do certificado que será usado para assinar o arquivo de catálogo. Esse certificado deve ser importado para o repositório de certificados pessoais no computador no qual você está tentando assinar o arquivo de catálogo.

Observação

Para obter informações adicionais sobre Signtool.exe e todas as opções adicionais, visite Página da Ferramenta de Assinatura no MSDN.
Verifique a assinatura digital do arquivo de catálogo. Clique com o botão direito do mouse no arquivo de catálogo e clique em Propriedades. Na guia Assinaturas Digitais, verifique se o certificado de assinatura existe usando um algoritmo sha256, conforme mostrado na Figura 12.

Figura 12. Verificar se o certificado de assinatura existe
Copie o arquivo de catálogo para C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.

Para fins de teste, você pode copiar manualmente os arquivos de catálogo assinados para a pasta desejada. Para implementações em grande escala, a Microsoft recomenda usar Preferências do Arquivo de Política do Grupo para copiar os arquivos de catálogo apropriados para todos os computadores desejados ou um produto de gerenciamento de sistemas corporativos como System Center Configuration Manager. Isso também simplifica o gerenciamento de versões de catálogo.

Implantar arquivos de catálogo com Política de Grupo

Para simplificar o gerenciamento de arquivos de catálogo, você pode usar as preferências de Política de Grupo para implantar arquivos de catálogo nos computadores apropriados da organização. O processo a seguir orienta você em meio à implantação de um arquivo de catálogo assinado chamado LOBApp-Contoso.cat em uma UO de teste chamada DG Enabled PCs com um GPO chamado Contoso DG Catalog File GPO Test.

Observação

Este passo a passo requer que você tenha criado anteriormente um arquivo de catálogo assinado e tenha um computador cliente com Windows 10 no qual testa uma implantação de Política de Grupo. Para obter mais informações sobre como criar e assinar um arquivo de catálogo, consulte a seção Arquivos de catálogo.

Para implantar um arquivo de catálogo com usando Política de Grupo:

Em um controlador de domínio ou um PC cliente com Ferramentas de Administração de Servidor Remoto (RSAT) instaladas, abra o Console de Gerenciamento de Política de Grupo (GPMC) executando GPMC.MSC ou procurando Gerenciamento de Política de Grupo.
Crie um novo GPO: clique com o botão direito do mouse na UO DG Enabled PCs e clique em Criar um GPO neste domínio e fornecer um link para ele aqui, conforme mostrado na Figura 13.

Observação

A UO DG Enabled PCs é apenas um exemplo de onde vincular o GPO que você criou nesta seção. Você pode usar qualquer nome de UO. Além disso, a filtragem do grupo de segurança é uma opção quando você leva em consideração as opções de particionamento da política com base na estratégia abordada na seção Abordagem da implantação de integridade de código corporativa.

Figura 13. Criar um novo GPO
Dê ao novo GPO o nome Contoso DG Catalog File GPO Test.

Este exemplo usa Contoso DG Catalog File GPO Test como o nome do GPO. Você pode escolher qualquer nome de que sua preferência para este exemplo.
Abra o Editor de Gerenciamento de Política de Grupo: clique com o botão direito do mouse no novo GPO e clique em Editar.
Dentro do GPO selecionado, navegue até Configuração do Computador\Preferências\Configurações do Windows\Arquivos. Clique com o botão direito do mouse em Arquivos, aponte para Novo e clique em Arquivo, conforme mostrado na Figura 14.

Figura 14. Criar um novo arquivo
Configure o compartilhamento de arquivos de catálogo.

Para usar essa configuração a fim de oferecer uma implantação consistente de LOBApp-Contoso.cat, o arquivo de origem deve estar em um compartilhamento que seja acessível para a conta de computador de qualquer computador implantado. Este exemplo usa um compartilhamento em um computador cliente do Windows 10 chamado \\Contoso-Win10\Share. O arquivo de catálogo que está sendo implantado é copiado para esse compartilhamento.
Para manter as versões consistentes, na caixa de diálogo Novas Propriedades de Arquivo (Figura 15), selecione Substituir na lista Ação de maneira que a versão mais recente seja sempre usada.

Figura 15. Definir as novas propriedades de arquivo
Na caixa Arquivo de Origem, digite o nome do compartilhamento acessível, com o nome de arquivo do catálogo incluído (por exemplo, \\Contoso-Win10\share\LOBApp-Contoso.cat).
Na caixa Arquivo de Destino, digite C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-Contoso.cat.

Observação

LOBApp-Contoso.cat não é um nome de catálogo necessário: esse nome foi usado na seção Criar arquivos de catálogo, e por isso foi usado aqui também.
Na guia Comum da caixa de diálogo Novas Propriedades de Arquivo, selecione a opção Remover este item quando ele não for mais aplicado. Isso garante que o arquivo de catálogo seja removido de todos os sistemas, caso você precise deixar de confiar nesse aplicativo.
Clique em OK para concluir a criação do arquivo.
Feche o Editor de Gerenciamento de Política de Grupo e atualize a política no computador de teste do Windows 10 executando GPUpdate.exe. Quando a política tiver sido atualizada, verifique se o arquivo de catálogo existe em C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} no computador com o Windows 10.

Implantar arquivos de catálogo com o System Center Configuration Manager

Como uma alternativa a Política de Grupo, você pode usar o System Center Configuration Manager para implantar arquivos de catálogo em computadores gerenciados no ambiente. Essa abordagem pode simplificar a implantação e o gerenciamento de vários arquivos de catálogo, bem como fornecer relatórios relacionados ao catálogo que cada cliente ou coleção implantou. Além da implantação desses arquivos, o System Center Configuration Manager também pode ser usado para inventariar os arquivos de catálogo implantados no momento para fins de relatório e conformidade. Conclua as seguintes etapas para criar um novo pacote de implantação para arquivos de catálogo:

Observação

O exemplo a seguir usa um compartilhamento de rede chamado \\Shares\CatalogShare como uma origem para os arquivos de catálogo. Caso você tenha arquivos de catálogo específicos da coleção ou prefira implantá-los individualmente, use a estrutura de pastas que funcione melhor para a organização.

Abra o console do Configuration Manager e selecione o espaço de trabalho da Biblioteca de Software.
Navegue até Visão Geral\Gerenciamento de Aplicativo, clique com o botão direito do mouse em Pacotes e clique em Criar Pacote.
Nomeie o pacote, defina a organização como o fabricante e selecione um número de versão apropriado (Figura 16).

Figura 16. Especificar informações sobre o novo pacote
Clique em Avançar e selecione Programa padrão como o tipo de programa.
Na página Programa Padrão, selecione um nome e defina a propriedade Linha de Comando como XCopy \\Shares\CatalogShare C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y.
Na página Programa Padrão, selecione as seguintes opções (Figura 17):
- Em Nome, digite Contoso Catalog File Copy Program.
- Em Linha de comando, navegue até o local do programa.
- Em Pasta de inicialização, digite C:\Windows\System32.
- Na lista Executar, selecione Oculto.
- Na lista O programa pode ser executado, selecione Se um usuário tiver ou não efetuado logon.
- Na lista Modo de unidade, selecione Executa com nome UNC.
Figura 17. Especificar as informações sobre o programa padrão
Aceite os padrões para o restante do assistente e feche o assistente.

Depois de criar o pacote de implantação, implante-o em uma coleção de maneira que os clientes recebam os arquivos de catálogo. Neste exemplo, você implanta o pacote que acabou de criar em uma coleção de teste:

Na área de trabalho Biblioteca de Software, navegue até Visão Geral\Gerenciamento de Aplicativo\Pacotes, clique com o botão direito do mouse no pacote do arquivo de catálogo e clique em Implantar.
Na página Geral, selecione a coleção de teste na qual os arquivos de catálogo serão implantados e clique em Avançar.
Na página Conteúdo, clique em Adicionar para selecionar o ponto de distribuição que fornecerá conteúdo para a coleção selecionada e clique em Avançar.
Na página Configurações da Implantação, selecione Obrigatório na caixa Finalidade.
Na página Agendamento, clique em Novo.
Na caixa de diálogo Agendamento de Atribuição, selecione Atribuir imediatamente após este evento, defina o valor como O mais rápido possível e clique em OK.
Na página Agendamento, clique em Avançar.
Na página Experiência do Usuário (Figura 18), defina as seguintes opções e clique em Avançar:
- Marque a caixa de seleção Instalação de software.
- Marque a caixa de seleção Confirmar as alterações no prazo ou durante uma janela de manutenção (requer reinicializações).
Figura 18. Especificar a experiência do usuário
Na página Pontos de Distribuição, na caixa Opções de Implantação, selecione Executar programa do ponto de distribuição e em Avançar.
Na página Resumo, examine as seleções e clique em Avançar.
Feche o assistente.

Inventariar arquivos de catálogo com o System Center Configuration Manager

Quando arquivos de catálogo tiverem sido implantados nas máquinas dentro do ambiente, usando Política de Grupo ou System Center Configuration Manager, você poderá inventariá-los com o recurso de inventário de software do System Center Configuration Manager. O processo a seguir orienta você em meio à habilitação do inventário de software para descobrir arquivos de catálogo nos sistemas gerenciados por meio da criação e da implantação de uma nova política de configurações do cliente.

Observação

Uma convenção de nomenclatura padrão para os arquivos de catálogo simplificará de maneira significativa o processo de inventário de software do arquivo de catálogo. Neste exemplo, -Contoso foi adicionado a todos os nomes de arquivo de catálogo.

Abra o console do Configuration Manager e selecione o espaço de trabalho Administração.
Navegue até Visão Geral\Configurações do Cliente, clique com o botão direito do mouse em Configurações do Cliente e clique em Criar Configurações Personalizadas do Dispositivo do Cliente.
Nomeie a nova política e marque a caixa de seleção Inventário de Software na lista Selecionar e configurar as configurações padrão para dispositivos cliente, conforme mostrado na Figura 19.

Figura 19. Selecionar configurações personalizadas
No painel de navegação, clique em Inventário de Software e em Definir Tipos, conforme mostrado na Figura 20.

Figura 20. Definir o inventário de software
Na caixa de diálogo Definir a Configuração do Cliente, clique no botão Iniciar para abrir a caixa de diálogo Inventories File Properties.
Na caixa Nome, digite *Contoso.cat e clique em OK.

Observação

*Contoso.cat é a convenção de nomenclatura usada neste exemplo. Ela deve imitar a convenção de nomenclatura que você usa para os arquivos de catálogo.
Na caixa de diálogo Propriedades de Caminho, selecione Nome de variável ou do caminho e digite C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} na caixa, conforme mostrado na Figura 21.

Figura 21. Defina as propriedades do caminho
Clique em OK.
Agora que você criou a política de configurações do cliente, clique com o botão direito do mouse a nova política, clique em Implantar e escolha a coleção na qual você gostaria de inventariar os arquivos de catálogo.

No momento do próximo ciclo de inventário de software, quando os clientes segmentados receberem a nova política de configurações do cliente, você será capaz de exibir os arquivos inventariados nos relatórios internos do System Center Configuration Manager ou o Gerenciador de Recursos. Para exibir os arquivos inventariados em um cliente dentro do Gerenciador de Recursos, conclua as seguintes etapas:

Abra o console do Gerenciador de Recursos e selecione o espaço de trabalho Ativos e Conformidade.
Navegue até Visão Geral\Dispositivos e procure o dispositivo no qual você deseja exibir os arquivos inventariados.
Clique com o botão direito do mouse no computador, aponte para Iniciar e clique em Gerenciador de Recursos.
No Gerenciador de Recursos, navegue até Software\Detalhes do Arquivo para exibir os arquivos de catálogo inventariados.

Observação

Caso nada seja exibido nesse modo de exibição, navegue até Software\Última Verificação de Software no Gerenciador de Recursos para confirmar que o cliente concluiu recentemente um exame de inventário de software.

Políticas de integridade de código

As políticas de integridade de código mantêm os padrões segundo os quais um computador no qual o Windows 10 esteja em execução determina se um aplicativo é confiável e pode ser executado. Para obter uma visão geral da integridade de código, consulte a seção Integridade de código configurável.

Uma prática de geração de imagens do sistema comum na organização de TI atual é estabelecer uma imagem "ouro" como uma referência para o que deve ser um sistema ideal e usar essa imagem para clonar ativos da empresa adicionais. As políticas de integridade de código seguem uma metodologia semelhante, que começa com o estabelecimento de um computador "ouro". Assim como acontece durante a geração de imagens, você pode ter vários computadores "ouro" com base em modelo, departamento, conjunto de aplicativos etc. Embora o processo de concepção em torno da criação de políticas de integridade de código seja semelhante ao da geração de imagens, essas políticas devem ser mantidas de maneira independente. Avalie a necessidade de políticas de integridade de código adicionais com base no que deve ser permitido instalar e executar e para quem.

Observação

Cada computador só pode ter uma política de integridade de código por vez. Independentemente da maneira como você implante essa política, ele é renomeada para SIPolicy.p7b e copiada para C:\Windows\System32\CodeIntegrity. Tenha isso em mente ao criar as políticas de integridade de código.

Como opção, as políticas de integridade de código podem estar alinhadas ao catálogo de software, bem como a quaisquer aplicativos aprovados pelo departamento de TI. Um método simples de implementar políticas de integridade de código é usar imagens existentes para criar uma política de integridade de código mestre. Você faz isso criando uma política de integridade de código com base em cada imagem e mesclando as políticas. Dessa forma, o que for instalado em todas essas imagens poderá ser executado, se os aplicativos estiverem instalados em um computador com base em uma imagem diferente. Você também pode optar por criar uma política de aplicativos base e adicionar políticas com base na função do computador ou no departamento. As organizações têm uma opção de como as políticas são criadas, mescladas ou mantidas, além de gerenciadas.

Observação

A seção a seguir pressupõe que você implantará políticas de integridade de código como parte da implantação do Device Guard. A integridade de código configurável também está disponível sem a habilitação do Device Guard.

Regras de política de integridade de código

As políticas de integridade de código consistem em diversos componentes. Os dois componentes principais, que são configuráveis, são chamados de regras de política e regras de arquivo, respectivamente. As regras de política de integridade de código são opções que o criador de política de integridade de código pode especificar na política. Entre essas opções estão a habilitação do modo de auditoria, a UMCI e assim por diante. Você pode modificar essas opções em uma política de integridade de código nova ou existente. As regras de arquivo são o nível no qual o exame de política de integridade de código vincula cada confiança binária. Por exemplo, o nível de hash discriminará cada hash descoberto no sistema dentro da política de integridade de código gerado. Dessa forma, quando um binário se preparar para ser executado, o serviço de integridade de código validará seu valor de hash em relação aos hashes confiáveis encontrados na política de integridade de código. Com base nesse resultado, o binário terá ou não permissão para ser executado.

Para modificar as opções da regra de uma política de integridade de código existente, use o cmdlet do Windows PowerShell conjunto RuleOption. Observe os seguintes exemplos de como usar esse cmdlet para adicionar e remover uma opção de regra em uma política de integridade de código existente:

Para habilitar a UMCI, adicione a opção de regra 0 a uma política existente executando o seguinte comando:

Set-RuleOption -Option 0 -FilePath <Path to policy>
Para desabilitar a UMCI em uma política de integridade de código existente, remova a opção de regra 0 executando o seguinte comando:

Set-RuleOption -Option 0 -FilePath <Path to policy> -Delete

Você pode definir diversas opções de regra dentro de uma política de integridade de código. A Tabela 2 lista cada regra e o significado em alto nível.

Tabela 2. Política de integridade de código – opções de regra de política

Opção de regra	Descrição
0 Enabled:UMCI	As políticas de integridade de código restringem binários dos modos kernel e de usuário. Por padrão, somente binários do modo kernel são restritos. Habilitar essa opção de regra valida executáveis do modo de usuário e scripts.
1 Enabled:Boot Menu Protection	Esta opção não é compatível no momento.
2 Required:WHQL	Por padrão, os drivers herdados que não sejam assinados por Windows Hardware Quality Labs (WHQL) têm permissão para serem executados. Habilitar essa regra requer que todo driver executado seja assinado por WHQL e remova o suporte ao driver herdado. Futuramente, todo novo driver compatível com o Windows 10 deve ser certificado pelo WHQL.
3 Enabled:Audit Mode (padrão)	Permite a execução de binários fora da política de integridade de código, mas registra em log toda ocorrência no log de eventos CodeIntegrity, que pode ser usado para atualizar a política existente antes da imposição. Para impor uma política de integridade de código, remova essa opção.
4 Disabled:Flight Signing	Se habilitadas, as políticas de integridade de código não confiarão em binários assinados por raiz de versão de pré-lançamento. Isso seria usado no cenário no qual as organizações só desejam executar binários lançados, e não versões de pré-lançamento.
5 Enabled:Inherent Default Policy	Esta opção não é compatível no momento.
6 Enabled:Unsigned System Integrity Policy (padrão)	Permite que a política permaneça não assinada. Quando essa opção é removida, a política deve ser assinada e ter UpdatePolicySigners adicionado à política para habilitar futuras modificações de política.
7 Allowed:Debug Policy Augmented	Esta opção não é compatível no momento.
8 Required:EV Signers	Além de ser assinada por WHQL, esta regra requer que os drivers devam ter sido enviados por um parceiro com um certificado de verificação estendida (EV). Todos os drivers futuros do Windows 10 e posteriores atenderão a esse requisito.
9 Enabled:Advanced Boot Options Menu	O menu de pré-inicialização F8 permanece desabilitado por padrão para todas as políticas de integridade de código. Definir essa opção de regra permite que o menu F8 seja exibido para usuários presentes fisicamente.
10 Enabled:Boot Audit on Failure	Usada quando a política de integridade de código está em modo de imposição. Quando um driver falha durante a inicialização, a política de integridade de código é colocada no modo de auditoria de maneira que o Windows seja carregado. Os administradores podem validar o motivo da falha no log de eventos CodeIntegrity.

Os níveis de regra de arquivo permitem que os administradores especifiquem o nível no qual desejam confiar nos aplicativos. Esse nível de confiança pode ser tão baixo quanto o hash de cada binário e tão alto quanto um certificado PCA. Os níveis de regra de arquivo são especificados quando você cria uma nova política de integridade de código com base em um exame e quando você cria uma política com base em eventos de auditoria. Além disso, para integrar níveis de regra encontrados em várias políticas, você pode mesclar as políticas. Quando mescladas, as políticas de integridade de código integram as regras de arquivo. Cada nível de regra de arquivo tem vantagens e desvantagens. Use a Tabela 3 para selecionar o nível de proteção apropriado para os recursos administrativos disponíveis e o cenário de implantação do Device Guard.

Tabela 3. Política de integridade de código – níveis de regra de arquivo

Nível da regra	Descrição
Hash	Especifica valores de hash individuais para cada binário descoberto. Embora seja específico, esse nível pode causar uma sobrecarga administrativa adicional ao manter os valores de hash do produto das versões de produto atuais. Sempre que um binário é atualizado, o valor de hash muda, logo, exigindo uma atualização de política.
FileName	Especifica nomes de arquivo binário individuais. Embora os valores de hash de um aplicativo sejam modificados quando atualizados, os nomes de arquivo normalmente não são. Isso oferece menos segurança específica que o nível de hash, mas normalmente não exige uma atualização de política quando um binário é modificado.
SignedVersion	Integra a regra do editor ao número de versão de um arquivo. Essa opção permite que qualquer coisa do editor especificado, com uma versão de arquivo igual ou superior à do número de versão especificado, seja executada.
Publisher	Trata-se de uma combinação do certificado PCA e do nome comum (CN) no certificado secundário. No cenário em que um certificado PCA seja usado para assinar aplicativos de várias empresas (como VeriSign), esse nível de regra permite que organizações confiem no certificado PCA, mas apenas da empresa cujo nome esteja no certificado secundário (por exemplo, Intel para drivers de dispositivo). Esse nível confia em um certificado com um período de validade longo, mas somente quando integrado a um certificado secundário confiável.
FilePublisher	Trata-se de uma combinação do nível de regra de arquivo do editor e do nível de regra SignedVersion. Qualquer arquivo assinado do editor confiável que seja da versão especificada ou mais recente é confiável.
LeafCertificate	Adiciona signatários confiáveis no nível de certificado de assinatura individual. A vantagem de usar esse nível em comparação com o nível de hash individual é que novas versões do produto terão valores de hash diferentes, mas normalmente o mesmo certificado de assinatura. Usando esse nível, nenhuma atualização de política seria necessária para executar a nova versão do aplicativo. No entanto, certificados secundários têm períodos de validade muito mais curtos do que os de certificados PCA, logo, uma sobrecarga administrativa adicional é associada à atualização da política de integridade de código quando esses certificados expiram.
PcaCertificate	Adiciona o certificado mais alto na cadeia de certificados fornecida aos signatários. Esse costuma ser um certificado abaixo do certificado raiz, porque que o exame não valida nada acima da assinatura apresentada online ou verificando-se os repositórios raiz locais.
RootCertificate	Atualmente incompatível.
WHQL	Confie em binários caso eles tenham sido validados e assinados por WHQL. Isso acontece principalmente para binários de kernel.
WHQLPublisher	Trata-se de uma combinação do WHQL e do CN no certificado secundário e é basicamente para binários de kernel.
WHQLFilePublisher	Especifica que os binários estão validados e assinados por WHQL, com um editor específico (WHQLPublisher), e que o binário é a versão especificada ou mais recente. Isso acontece principalmente para binários de kernel.

Observação

Ao criar políticas de integridade de código com o cmdlet New-CIPolicy, você pode especificar um nível de regra de arquivo primário, inclusive o parâmetro –Level. Para binários descobertos que não possam ser confiáveis com base em critérios de regra de arquivo primário, use o parâmetro –Fallback. Por exemplo, caso o nível de regra de arquivo primário seja PCACertificate, mas você queira confiar também nos aplicativos não assinados, usar o nível de regra Hash como fallback adiciona os valores de hash de binários que não tinham um certificado de assinatura.

Criar políticas de integridade de código com base em computadores "ouro"

O processo para criar uma política de integridade de código "ouro" com base em um sistema de referência é simples. Esta seção descreve o processo necessário para criar com êxito uma política de integridade de código com o Windows PowerShell. Primeiro, para este exemplo, você deve iniciar variáveis a serem usadas durante o processo de criação. Em vez de usar variáveis, você pode simplesmente usar os caminhos de arquivo completos no comando. Em seguida, você cria a nova política de integridade de código examinando o sistema em busca de aplicativos instalados. Quando criado, o arquivo de política é convertido em formato binário de maneira que o Windows possa consumir o conteúdo.

Observação

Antes de iniciar este procedimento, verifique se o computador de referência está livre de vírus ou malware. Todas as partes do software instalado devem ser validadas como confiáveis antes de você criar essa política. Além disso, certifique-se de que qualquer software que você gostaria de examinar esteja instalado no sistema antes de criar a política de integridade de código.

Para criar uma política de integridade de código, copie cada um dos seguintes comandos para uma sessão do Windows PowerShell com privilégios elevados, na ordem:

Inicialize as variáveis que você usará:

$CIPolicyPath=$env:userprofile+"\Desktop\"

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"
Crie uma nova política de integridade de código examinando o sistema em busca de aplicativos instalados:

New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt

Observação

Especificando o parâmetro –UserPEs, a opção de regra 0 Enabled:UMCI é adicionada automaticamente à política de integridade de código. Caso você não especifique esse parâmetro, use o seguinte comando para habilitar a UMCI:

Set-RuleOption -Option 0 -FilePath $InitialCIPolicy

Observação

Você pode adicionar o parâmetro –Fallback para capturar todos os aplicativos não detectados usando o nível de regra de arquivo primário especificado pelo parâmetro –Level. Para obter mais informações sobre opções de regra de nível de arquivo, consulte a seção Regras de política de integridade de código.

Observação

Se quiser especificar o exame de política de integridade de código para analisar apenas uma unidade específica, você poderá fazer isso usando o parâmetro –ScanPath. Sem esse parâmetro, conforme mostrado no exemplo, todo o sistema é examinado.
Converta a política de integridade de código em um formato binário:

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

Depois que você concluir essas etapas, o arquivo binário do Device Guard (DeviceGuardPolicy.bin) e o arquivo .xml original (IntialScan.xml) estarão disponíveis na área de trabalho. Você pode usar a versão binária como uma política de integridade de código ou assiná-la para segurança adicional.

Observação

A Microsoft recomenda manter o arquivo .xml original da política a ser usado quando você precisar mesclar a política de integridade de código com outra política ou atualizar as opções de regra. Você também pode precisar criar uma nova política com base em um novo exame para manutenção. Para obter mais informações sobre como mesclar políticas de integridade, consulte a seção Mesclar políticas de integridade de código.

A Microsoft recomenda que todas as políticas de integridade de código sejam executada em modo de auditoria antes de serem impostas. Isso permite que os administradores descubram quaisquer problemas com a política sem receber caixas de diálogo de mensagem de erro. Para obter informações sobre como auditar uma política de integridade, consulte a seção Auditar políticas de integridade de código.

Auditar políticas de integridade de código

Quando as políticas de integridade de código são executadas em modo de auditoria, ela permite que os administradores descubram todos os aplicativos que foram perdidos durante um exame de política inicial e identifiquem quaisquer novos aplicativos que tenham sido instalados e executados desde que a política original foi criada. Enquanto uma política de integridade de código está em execução em modo de auditoria, qualquer binário executado e cuja negação da imposição da política é registrado no log de eventos Logs de Aplicativos e Serviços\Microsoft\CodeIntegrity\Operacional. Quando esses binários conectados tiverem sido validados, eles poderão ser facilmente adicionados a uma nova política de integridade de código. Quando a nova política de exceção é criada, você pode mesclá-la com as políticas de integridade de código existentes.

Observação

Antes de começar este processo, você precisa criar um arquivo binário da política de integridade de código. Caso você ainda não tenha feito isso, consulte a seção Criar uma política de integridade de código para obter um passo a passo do processo de criação de uma política de integridade de código e da conversão em formato binário.

Para auditar uma política de integridade de código com política local:

Copie o arquivo DeviceGuardPolicy.bin que você criou na seção Criar políticas de integridade de código com base em computadores "ouro" para C:\Windows\System32\CodeIntegrity.
No sistema em que você deseja executar o modo de auditoria, abra o Editor de Política de Grupo Local executando GPEdit.msc.
Navegue até Configuração do Computador\Modelos Administrativos\Sistema\Device Guard e selecione Implantar política de integridade de código. Habilite essa configuração usando o caminho de arquivo C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, conforme mostrado na Figura 22.

Observação

DeviceGuardPolicy.bin não é um nome de política necessário. Esse nome foi simplesmente usado na seção Criar políticas de integridade de código com base em computadores "ouro" e, assim, foi usado aqui. Além disso, esse arquivo de política não precisa ser copiado para todos os sistemas. Você também pode copiar as políticas de integridade de código para um compartilhamento de arquivos a que todas as contas de computador tenham acesso.

Observação

Todas as políticas selecionadas aqui são convertidas em SIPolicy.p7b quando ele é implantado em computadores individuais.

Figura 22. Implantar a política de integridade de código

Observação

Você deve ter percebido que a configuração do GPO referencia um arquivo .p7b e que essa política usa um arquivo .bin. Independentemente do tipo de política que implantar (.bin, .p7b ou .p7), elas são todas convertidas em SIPolicy.p7b quando removidas para os computadores com Windows 10. A Microsoft recomenda verificar as políticas de integridade de código amigáveis e permitir que o sistema converta os nomes de política para você. Isso garante que as políticas sejam facilmente distinguíveis quando exibidas em um compartilhamento ou em qualquer outro repositório central.
Reinicie o sistema de referência para que a política de integridade de código entre em vigor.
Monitore o log de eventos CodeIntegrity. Enquanto estiver no modo de auditoria, qualquer exceção à política de integridade de código implantada será registrada em log no log de eventos Logs de Aplicativos e Serviços\Microsoft\CodeIntegrity\Operacional, conforme mostrado na Figura 23.

Figura 23. Exceções à política de integridade de código implantada
Valide todas as exceções de política de integridade de código.

Depois de executar uma política de integridade de código no modo de auditoria, a Microsoft recomenda que cada exceção registrada em log seja pesquisada e validada. Além de descobrir qual aplicativo está causando a exceção e garantir que ele deva ser adicionado à política de integridade de código, certifique-se de verificar qual nível de arquivo deve ser usado para confiar em cada aplicativo. Embora o nível de regra de arquivo de hash capture todas essas exceções, talvez não seja a melhor maneira de confiar em todas as exceções. Para obter informações sobre níveis de regra de arquivo e as finalidades, consulte a seção Regras de política de integridade de código.
Crie uma política de integridade de código com base em eventos de auditoria.

Para obter informações sobre como criar políticas de integridade de código com base em eventos de auditoria, consulte a seção Criar políticas de integridade de código com base em computadores "ouro".

Observação

Um método alternativo para testar uma política é renomear o arquivo de teste para SIPolicy.p7b e removê-lo para C:\Windows\System32\CodeIntegrity, em vez de implantá-lo com a política de máquina local.

Criar uma política de integridade de código de auditoria

Ao executar políticas de integridade de código em modo de auditoria, valide todas as exceções e determine se você precisará adicioná-las à política de integridade de código que deseja auditar. Use o sistema como você faria normalmente para garantir que todas as exceções de uso sejam registradas em log. Quando você estiver pronto para criar uma política de integridade de código com base nos eventos de auditoria, execute as seguintes etapas em uma sessão do Windows PowerShell com privilégios elevados:

Inicialize as variáveis que serão usadas:

$CIPolicyPath=$env:userprofile+"\Desktop\"

$CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"
Analise os resultados da auditoria.

Antes de criar uma política de integridade de código com base em eventos de auditoria, a Microsoft recomenda que toda exceção seja analisada, conforme abordado nas etapas 5 e 6 da seção Auditar políticas de integridade de código.
Gere uma nova política de integridade de código com base em eventos de auditoria registrados em log:

New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt

Observação

Ao criar políticas com base em eventos de auditoria, você deve levar em consideração atentamente o nível de regra de arquivo em que você opta por confiar. Neste exemplo, você usa o nível de regra Hash, que deve ser usado como último recurso.

Depois que você concluir essas etapas, o arquivo .xml de política de auditoria do Device Guard (DeviceGuardAuditPolicy.xml) estará disponível na área de trabalho. Agora você pode usar esse arquivo para atualizar a política de integridade de código existente que você executou em modo de auditoria mesclando as duas políticas. Para obter instruções sobre como mesclar essa política de auditoria com a política de integridade de código existente, consulte a seção Mesclar políticas de integridade de código.

Observação

Você deve ter percebido que não gerou uma versão binária dessa política como você fez na seção Criar políticas de integridade de código com base em computadores "ouro". Isso porque as políticas de integridade do código criadas com base em um log de auditoria não se destinam à execução de políticas autônomas, e sim de atualizar as políticas de integridade de código existentes.

Mesclar políticas de integridade de código

Ao desenvolver políticas de integridade de código, você acabará precisando mesclar duas políticas. Um exemplo comum é quando uma política de integridade de código é inicialmente criada e auditada. Outro exemplo é quando você cria uma única política mestre usando várias políticas de integridade de código criadas anteriormente com base em computadores "ouro". Como cada computador com Windows 10 pode ter apenas uma política de integridade de código, é importante manter corretamente essas políticas. Neste exemplo, os eventos de auditoria foram salvos em uma política de integridade de código secundário que você acaba mesclando com a política de integridade de código inicial.

Observação

O exemplo a seguir usa arquivos .xml da política de integridade de código que você criou nas seções Criar políticas de integridade de código com base em computadores "ouro" e Auditar políticas de integridade de código. Você pode seguir esse processo, no entanto, com duas políticas de integridade de código que gostaria de combinar.

Para mesclar duas políticas de integridade de código, conclua as seguintes etapas em uma sessão do Windows PowerShell com privilégios elevados:

Inicialize as variáveis que serão usadas:

$CIPolicyPath=$env:userprofile+"\Desktop\"

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

$AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

$MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"

$CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"

Observação

As variáveis nesta seção devem especificamente encontrar uma política inicial na área de trabalho chamada InitialScan.xml e uma política de integridade de código de auditoria chamada DeviceGuardAuditPolicy.xml. Caso você queira mesclar outras políticas de integridade de código, atualize as variáveis de acordo.
Mescle duas políticas para criar uma nova política de integridade de código:

Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy
Converta a política de integridade de código mesclada em um formato binário:

ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin

Agora que criou uma nova política de integridade de código chamada NewDeviceGuardPolicy.bin, você pode implantar a política em sistemas manualmente ou usando Política de Grupo ou soluções de gerenciamento cliente Microsoft. Para obter informações sobre como implantar essa nova política com Política de Grupo, consulte a seção Implantar e gerenciar políticas de integridade de código com Política de Grupo.

Impor políticas de integridade de código

Cada política de integridade de código é criada com o modo de auditoria habilitado. Depois que você tiver implantado e testado com êxito uma política de integridade de código em modo de auditoria e estiver pronto para testar a política em modo imposto, conclua as seguintes etapas em uma sessão do Windows PowerShell com privilégios elevados:

Observação

Toda política de integridade de código deve ser testada em modo de auditoria primeiro. Para obter informações sobre como auditar políticas de integridade, consulte a seção Auditar políticas de integridade de código.

Inicialize as variáveis que serão usadas:

$CIPolicyPath=$env:userprofile+"\Desktop\"

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

$EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"

$CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"

Observação

A política de integridade de código inicial nesta seção referenciada foi criada na seção Criar políticas de integridade de código com base em computadores "ouro". Caso você esteja usando uma política de integridade de código diferente, atualize as variáveis CIPolicyPath e InitialCIPolicy.
Copie o arquivo inicial para manter uma cópia original:

cp $InitialCIPolicy $EnforcedCIPolicy
Remova a opção de regra de modo de auditoria:

Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete

Observação

Em vez de adicionar uma opção Imposta, as políticas de integridade de código são impostas implicitamente caso nenhuma opção Modo de Auditoria C2 Habilitado esteja presente.
Converta a nova política de integridade de código em formato binário:

ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin

Observação

É altamente recomendável pela Microsoft habilitar as opções de regra 9 e 10 antes de executar qualquer política imposta pela primeira vez. Caso já esteja presente na política, não a remova. Isso permite que o Windows seja iniciado caso a política de integridade de código impeça a execução de um driver de modo kernel e ofereça aos administradores um prompt de comando de pré-inicialização. Quando estiver pronto para implantação corporativa, você poderá remover essas opções.

Agora que essa política foi aplicada, você pode implantá-la nos computadores de teste. Renomeie a política para SIPolicy.p7b e a copie para C:\Windows\System32\CodeIntegrity para testes ou implante a política por meio de Política de Grupo seguindo as instruções na seção Implantar e gerenciar políticas de integridade de código com Política de Grupo, ou por meio do software de gerenciamento de cliente seguindo as instruções na seção "Implantação e gerenciamento de políticas de integridade de código usando soluções de gerenciamento cliente Microsoft".

Assinatura de políticas de integridade de código com SignTool.exe

As políticas de integridade de código assinadas dão às organizações o nível mais alto de proteção contra malware disponível no Windows 10. Além das regras de política imposta, as políticas assinadas não podem ser modificadas ou excluídas por um usuário ou um administrador no computador. Essas políticas foram projetadas para evitar a violação administrativa e o acesso de exploração do modo de kernel. Com isso em mente, é muito mais difícil remover políticas de integridade de código assinadas do que aquelas não assinadas. Antes de assinar e implantar uma política de integridade de código assinada, a Microsoft recomenda auditar a política para descobrir todos os aplicativos bloqueados que devem ter permissão para serem executados. Para obter mais informações sobre como auditar políticas de integridade, consulte a seção Auditar políticas de integridade de código.

Assinar políticas de integridade de código usando um certificado gerado pela CA no local ou um certificado de assinatura de código comprado é simples. Caso você não tenha um certificado de assinatura de código exportado no formato .pfx no momento (contendo chaves privadas, extensões e certificados raiz), consulte Criar um certificado de assinatura de código do Device Guard para criar um com a CA no local. Antes de assinar políticas de integridade de código pela primeira vez, não se esqueça de habilitar as opções de regra 9 e 10 para disponibilizar opções de solução de problemas a administradores de teste. Quando validada e pronta para implantação corporativa, você pode remover essas opções. Para obter informações sobre como adicionar opções de regra, consulte a seção Regras de política de integridade de código.

Observação

Assinar políticas de integridade de código é a última etapa em uma implantação de integridade de código. É muito mais difícil remover uma política de integridade de código assinada do que uma não assinada. Antes de implantar uma política de integridade de código assinada em computadores cliente implantados, não se esqueça de testar o efeito sobre um subconjunto de computadores.

Para assinar uma política de integridade de código com SignTool.exe, você precisa dos seguintes componentes:

SignTool.exe, encontrada no SDK do Windows (Windows 7 ou posterior)
O formato binário da política de integridade de código gerado na seção Criar políticas de integridade de código com base em computadores "ouro" ou outra política de integridade de código que você tenha criado
Um certificado de assinatura de código de CA interno ou um certificado de assinatura de código comprado

Caso você não tenha um certificado de assinatura de código, consulte a seção Criar um certificado de assinatura de código do Device Guard para instruções sobre como criar um. Caso você use um certificado alternativo ou uma política de integridade do código, não se esqueça de atualizar as etapas a seguir com as variáveis apropriadas e o certificado de maneira que os comandos funcionem corretamente. Para assinar a política de integridade de código existente, copie cada um dos seguintes comandos para uma sessão do Windows PowerShell com privilégios elevados:

Inicialize as variáveis que serão usadas:

$CIPolicyPath=$env:userprofile+"\Desktop\" $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

Observação

Este exemplo usa a política de integridade de código que você criou na seção Criar políticas de integridade de código com base em computadores "ouro". Caso você esteja assinando outra política, não se esqueça de atualizar as variáveis $CIPolicyPath e $CIPolicyBin com as informações corretas.
Importe o certificado de assinatura de código .pfx. Importe o certificado de assinatura de código que você usará para assinar a política de integridade de código no armazenamento pessoal do usuário de assinatura na máquina que fará a assinatura. Neste exemplo, você usa o certificado que foi criado na seção Criar um certificado de assinatura de código do Device Guard.
Exporte o certificado de assinatura de código .cer. Depois que o certificado de assinatura de código tiver sido importado, exporte a versão .cer para a área de trabalho. Essa versão será adicionada à política de maneira que possa ser atualizada mais tarde.
Navegue até a área de trabalho como o diretório de trabalho:

cd $env:USERPROFILE\Desktop
Adicione um certificado de signatário de atualização à política de integridade de código:

Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update

Observação

<Path to exported .cer certificate> deve ser o caminho completo para o certificado que você exportou na etapa 3.

Observação

Adicionar signatários de atualização é crucial para poder modificar ou desabilitá-la no futuro. Para obter mais informações sobre como desabilitar políticas de integridade de código assinadas, consulte a seção Desabilitar políticas de integridade de código assinadas dentro do Windows.
Remova a opção de regra de política não assinada:

Set-RuleOption -Option 6 -FilePath $InitialCIPolicy -Delete
Converta a política em formato binário:

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
Assine a política de integridade de código usando SignTool.exe:

<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin

Observação

A variável <Path to signtool.exe> deve ser o caminho completo para o utilitário SignTool.exe. ContosoDGSigningCert é o nome do requerente do certificado que será usado para assinar a política de integridade de código. Você deve importar esse certificado para o repositório de certificados pessoais no computador usado para assinar a política.
Valide o arquivo assinado. Quando terminar, os comandos deverão gerar um arquivo de política assinada chamado DeviceGuardPolicy.bin.p7 na área de trabalho. Você pode implantar esse arquivo da mesma maneira como implanta uma política imposta ou não imposta. Para obter informações sobre como implantar políticas de integridade de código, consulte a seção Implantar e gerenciar políticas de integridade de código com Política de Grupo.

Desabilitar políticas de integridade de código não assinado

Pode haver um momento em que um administrador queira desabilitar uma política de integridade de código. Para políticas de integridade de código não assinado, esse processo é simples. Dependendo de como a política de integridade de código foi implantada, políticas não assinadas podem ser desabilitadas de duas maneiras. Caso uma política de integridade de código tenha sido habilitada e copiada para o local da pasta de integridade de código manualmente, basta excluir o arquivo e reiniciar o computador. Os seguintes locais podem conter políticas de integridade de código em execução:

<Partição de Sistema EFI>\Microsoft\Boot\
<Volume do SO>\Windows\System32\CodeIntegrity\

Caso a política de integridade de código tenha sido implantada usando-se Política de Grupo, o GPO que atualmente está habilitando e implantando a política deve ser definido como desabilitado. Em seguida, a política de integridade de código será desabilitada na próxima reinicialização do computador.

Desabilitar políticas de integridade de código assinadas dentro do Windows

As políticas assinadas protegem o Windows da manipulação administrativa, bem como de que o malware obtenha acesso de nível administrativo ao sistema. Por esse motivo, as políticas de integridade de código assinadas são intencionalmente mais difíceis de remover do que políticas não assinadas. Elas se protegem de maneira inerente da modificação ou da remoção e, assim, são difíceis de remover até mesmo para administradores. Caso a política de integridade de código assinada seja habilitada e copiada para a pasta CodeIntegrity manualmente, para remover a política, você deve concluir as seguintes etapas:

Observação

Para referência, as políticas de integridade de código assinadas devem ser substituídas e removidas dos seguintes locais:

<Partição de Sistema EFI>\Microsoft\Boot\
<Volume do SO>\Windows\System32\CodeIntegrity\

Substitua a política existente por outra política assinada com a opção de regra 6 Enabled: Unsigned System Integrity Policy habilitada.

Observação

Para entrar em vigor, essa política deve ser assinada com um certificado adicionado anteriormente à seção UpdatePolicySigners da política assinada original que deseja substituir.
Reinicie o computador cliente.
Verifique se a nova política assinada existe no cliente.

Observação

Caso a política assinada contendo a opção de regra 6 não tenha sido processada no cliente, a adição de uma política não assinada pode causar falhas na inicialização.
Exclua a nova política.
Reinicie o computador cliente.

Caso a política de integridade de código assinada tenha sido implantada usando-se Política de Grupo, você deve concluir as seguintes etapas:

Substitua a política existente no GPO por outra política assinada com a opção de regra 6 Enabled: Unsigned System Integrity Policy habilitada.

Observação

Para entrar em vigor, essa política deve ser assinada com um certificado adicionado anteriormente à seção UpdatePolicySigners da política assinada original que deseja substituir.
Reinicie o computador cliente.
Verifique se a nova política assinada existe no cliente.

Observação

Caso a política assinada contendo a opção de regra 6 não tenha sido processada no cliente, a adição de uma política não assinada pode causar falhas na inicialização.
Defina o GPO como desabilitado.
Exclua a nova política.
Reinicie o computador cliente.

Desabilitar políticas de integridade de código assinadas dentro do BIOS

Talvez haja um momento em que as políticas de integridade de código assinadas causem uma falha na inicialização. Como políticas de integridade de código impõem drivers de modo kernel, é importante que elas sejam totalmente testadas em todas as configurações de hardware e software antes de serem impostas e assinadas. As políticas de integridade de código assinadas são validadas na sequência de pré-inicialização usando-se Inicialização Segura. Quando você desabilita o recurso Inicialização Segura no BIOS e exclua o arquivo dos seguintes locais no disco do sistema operacional, ele permite que o sistema seja inicializado no Windows:

<Partição de Sistema EFI>\Microsoft\Boot\
<Volume do SO>\Windows\System32\CodeIntegrity\

Implantar e gerenciar políticas de integridade de código com Política de Grupo

As políticas de integridade de código podem ser facilmente implantadas e gerenciadas com Política de Grupo. Um modelo administrativo do Device Guard estará disponível no Windows Server 2016 permitindo simplificar a implantação dos recursos de segurança baseada em hardware do Device Guard e das políticas de integridade de código. O procedimento a seguir orienta você em meio a como implantar uma política de integridade de código chamada DeviceGuardPolicy.bin em UO de teste chamada DG Enabled PCs usando um GPO chamado Contoso GPO Test.

Observação

Este passo a passo requer que você tenha criado anteriormente uma política de integridade de código e tenha um computador cliente com Windows 10 no qual testar uma implantação de Política de Grupo. Para obter mais informações sobre como criar uma política de integridade de código, consulte a seção Criar políticas de integridade de código com base em computadores "ouro".

Observação

As políticas de integridade de código assinadas podem causar falhas na inicialização quando implantadas. A Microsoft recomenda que políticas de integridade de código assinadas sejam completamente testadas em todas as plataformas de hardware antes da implantação corporativa.

Para implantar e gerenciar uma política de integridade de código com a Política de Grupo:

Em um controlador de domínio em um computador cliente no qual a RSAT esteja instalada, abra o GPMC executando GPMC.MSC ou procurando "Gerenciamento de Política de Grupo" em Windows Search.
Crie um novo GPO: clique com o botão direito do mouse na UO DG Enabled PCs e clique em Criar um GPO neste domínio e fornecer um link para ele aqui, conforme mostrado na Figura 24.

Observação

A UO DG Enabled PCs é apenas um exemplo de onde vincular o GPO criado nesta seção. Qualquer nome de UO pode ser usado. Além disso, a filtragem do grupo de segurança é uma opção quando se levam em consideração as opções de particionamento da política com base na estratégia abordada na seção Abordagem da implantação de integridade de código corporativa.

Figura 24. Criar um GPO
Dê ao novo GPO o nome Contoso GPO Test. Este exemplo usa Contoso GPO Test como o nome do GPO. Você pode escolher qualquer nome de que sua preferência para este exemplo.
Abra o Editor de Gerenciamento de Política de Grupo: clique com o botão direito do mouse no novo GPO e clique em Editar.
No GPO selecionado, navegue até o Configuração do Computador\Modelos Administrativos\Sistema\Device Guard. Em seguida, clique com o botão direito do mouse em Implantar política de integridade de código e clique em Editar.

Figura 25. Editar a política de integração de código
Na caixa de diálogo Display Code Integrity Policy, selecione a opção Habilitada e especifique o caminho de implantação de política de integridade de código.

Nessa configuração de política, você pode especificar o caminho local no qual a política existirá no computador cliente ou um caminho UNC que os computadores cliente procurarão recuperar a versão mais recente da política. Este exemplo copiou o arquivo DeviceGuardPolicy.bin para o computador de teste e habilitará essa configuração e usará o caminho do arquivo C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, conforme mostrado na Figura 26.

Observação

DeviceGuardPolicy.bin não é um nome de política obrigatório: ele foi simplesmente usado na seção Criar políticas de integridade de código com base em computadores "ouro" e, logo, é usado aqui também. Além disso, esse arquivo de política não precisa ser copiado para todos os computadores. Você também pode copiar as políticas de integridade de código para um compartilhamento de arquivos a que as contas de computador tenham acesso. Todas as políticas selecionadas aqui são convertidas em SIPolicy.p7b quando ele é implantado em computadores cliente individuais.

Figura 26. Habilitar a política de integridade de código

Observação

Você deve ter percebido que a configuração do GPO referencia um arquivo .p7b e que esse exemplo usa um arquivo .bin para a política. Independentemente do tipo de política que implantar (.bin, .p7b ou .p7), elas são todas convertidas em SIPolicy.p7b quando removidas para os computadores cliente com Windows 10. Deixe as políticas de integridade de código amigáveis e deixe o sistema converter os nomes de política para garantir que as políticas sejam facilmente distinguíveis quando exibidas em um compartilhamento ou em qualquer outro repositório central.
Feche o Editor de Gerenciamento de Política de Grupo e reinicie o computador de teste do Windows 10. Reiniciar o computador cliente atualiza a política de integridade de código. Para obter informações sobre como auditar políticas de integridade, consulte a seção Auditar políticas de integridade de código.

Criar um certificado de assinatura de código do Device Guard

Para assinar arquivos de catálogo ou políticas de integridade de código internamente, você precisará de um certificado de assinatura de código emitido publicamente ou uma CA interna. Caso tenha comprado um certificado de assinatura de código, você pode ignorar estas etapas e ir para as seções que descrevam as etapas para assinar arquivos de catálogo e políticas de integridade de código. Caso você não tenha comprado um certificado, mas tenha uma CA interna, execute estas etapas para criar um certificado de assinatura de código:

Abra o snap-in Console de Gerenciamento Microsoft (MMC) Autoridade de Certificação e selecione a CA emissora.
Quando conectado, clique com o botão direito do mouse Modelos de Certificado e clique em Gerenciar para abrir o Certification Templates Console.

Figura 27. Gerenciar os modelos de certificado
No painel de navegação, clique com o botão direito do mouse no certificado de assinatura de código e clique em Modelo Duplicado.
Na guia Compatibilidade, desmarque a caixa de seleção Mostrar alterações resultantes. Selecione Windows Server 2012 na lista Autoridade de Certificação e Windows 8 / Windows Server 2012 na lista Destinatário do Certificado.
Na guia Geral, especifique o Nome de exibição do modelo e Nome do modelo. Este exemplo usa DG Catalog Signing Certificate.
Na guia Tratamento de Solicitação, marque a caixa de seleção Permitir que a chave privada seja exportada.
Na guia Extensões, marque a caixa de seleção Restrições Básicas e clique em Editar.
Na caixa de diálogo Editar Extensão das Restrições Básicas, marque a caixa de seleção Habilitar esta extensão, conforme mostrado na Figura 28.

Figura 28. Habilitar restrições no novo modelo
Caso um gerenciador de certificados seja necessário para aprovar algum certificado emitido, na guia Requisitos de Emissão, selecione Aprovação do gerenciador de certificados de autoridade de certificação.
Na guia Nome do Requerente, selecione Fornecer na solicitação.
Na guia Segurança, verifique se alguma conta será usada para solicitar o certificado tem o direito de registrar o certificado.
Clique em OK para criar o modelo e feche o Certificate Template Console.

Quando esse modelo de certificado tiver sido criado, você deverá publicá-lo no repositório de modelos publicados da CA. Para isso, conclua as seguintes etapas:

No snap-in Autoridade de Certificação do MMC, clique com o botão direito do mouse em Modelos de Certificação, aponte para Novo e clique em Modelo de Certificado a Ser Emitido, conforme mostrado na Figura 29.

Uma lista de modelos disponíveis a serem emitidos é exibida, inclusive o modelo que você acabou de criar.

Figura 29. Selecione o novo modelo de certificado a ser emitido
Selecione o certificado de assinatura do catálogo DG e clique em OK.

Agora que o modelo está disponível para ser emitido, você deve solicitar um do computador Windows 10 que usa para criar e assinar arquivos de catálogo. Para começar, abra o MMC e conclua as seguintes etapas:

No MMC, no menu Arquivo, clique em Adicionar/remover snap-in. Clique duas vezes em Certificados e selecione My user account.
No snap-in Certificados, clique com o botão direito do mouse na pasta de armazenamento Pessoal, aponte para All Tasks e clique em Solicitar novo certificado.
Clique em Avançar duas vezes para acessar a lista de seleção de certificado.
Na lista Solicitar Certificado, selecione o certificado de assinatura de código recém-criado e o texto azul que solicita informações adicionais, conforme mostrado na Figura 30.

Figura 30. Obter mais informações para o certificado de assinatura de código
Na caixa de diálogo Propriedades do Certificado, para Tipo, selecione Nome comum. Para Valor, selecione ContosoDGSigningCert e clique em Adicionar. Quando adicionado, clique em OK.
Registre e conclua.

Observação

Se um gerenciador de certificados for necessário para aprovar quaisquer certificados emitidos e você tiver optado por exigir aprovação de gerenciamento no modelo, a solicitação precisará ser aprovada na CA antes de ser emitida para o cliente.

Esse certificado deve ser instalado no armazenamento pessoal do usuário no computador que assinará os arquivos de catálogo e as políticas de integridade de código. Se a assinatura ocorrer no computador em que você acabou de solicitar o certificado, exportar o certificado para um arquivo .pfx não será necessário porque ele já existe no armazenamento pessoal. Se assinar em outro computador, você precisará exportar o certificado .pfx com as chaves necessárias e as propriedades. Para isso, conclua as seguintes etapas:

Clique com o botão direito do mouse no certificado, aponte para All Tasks e clique em Exportar.
Clique em Avançar e selecione Sim, exportar a chave privada.
Escolha as configurações padrão e selecione Exportar todas as propriedades estendidas.
Defina uma senha, selecione um caminho de exportação e selecione DGCatSigningCert.pfx como o nome do arquivo.

Quando o certificado tiver sido exportado, importe-o para o armazenamento pessoal do usuário que assinará os arquivos de catálogo ou as políticas de integridade de código no computador específico que as assinará.