Controlar a integridade dos dispositivos Windows

Artigo
08/11/2023
Aplica-se a:

✅ Windows 11, ✅ Windows 10

Este artigo detalha uma solução de ponta a ponta que ajuda você a proteger ativos de alto valor aplicando, controlando e relatando a integridade dos dispositivos Windows.

Introdução

Para cenários BYOD (Bring Your Own Device), os funcionários trazem dispositivos disponíveis comercialmente para acessar recursos relacionados ao trabalho e seus dados pessoais. Os usuários querem usar o dispositivo de sua escolha para acessar os aplicativos, dados e recursos da organização não apenas da rede interna, mas também de qualquer lugar. Esse fenômeno também é conhecido como a consumização da TI.

Os usuários querem ter a melhor experiência de produtividade ao acessar aplicativos corporativos e trabalhar em dados da organização de seus dispositivos. Isso significa que eles não toleram ser solicitados a inserir suas credenciais de trabalho sempre que acessam um aplicativo ou um servidor de arquivo. Do ponto de vista de segurança, isso também significa que os usuários manipulam credenciais corporativas e dados corporativos em dispositivos não gerenciados.

Com o aumento do uso do BYOD, haverá mais sistemas não gerenciados e potencialmente não íntegros acessando serviços corporativos, recursos internos e aplicativos de nuvem.

Até mesmo dispositivos gerenciados podem ser comprometidos e se tornam prejudiciais. As organizações precisam detectar quando a segurança foi violada e reagir o mais cedo possível para proteger ativos de alto valor.

À medida que a Microsoft avança, os investimentos em segurança estão cada vez mais focados em defesas preventivas de segurança e também em recursos de detecção e resposta.

O Windows é um componente importante de uma solução de segurança de ponta a ponta que se concentra não apenas na implementação de defesas preventivas de segurança, mas adiciona recursos de atestado de integridade do dispositivo à estratégia de segurança geral.

Descrição de uma solução de segurança de ponta a ponta robusta

O cenário de ameaças de computação de hoje está aumentando a uma velocidade nunca encontrada antes. A sofisticação dos ataques criminosos está crescendo, e não há dúvida de que o malware agora tem como alvo consumidores e profissionais em todos os setores.

Nos últimos anos, uma categoria específica de ameaça tornou-se predominante: APTs (ameaças persistentes avançadas). O termo APT é comumente usado para descrever qualquer ataque que pareça ter como destino organizações individuais em andamento. Na verdade, esse tipo de ataque normalmente envolve adversários determinados que podem usar todos os métodos ou técnicas necessários.

Com os fenômenos BYOD, um dispositivo mal conservado representa um destino de escolha. Para um invasor, é uma maneira fácil de invadir o perímetro da rede de segurança, obter acesso e roubar ativos de alto valor.

Os invasores têm como alvo indivíduos, não especificamente por causa de quem eles são, mas por causa de para quem trabalham. Um dispositivo infectado traz malware para uma organização, mesmo que a organização tenha endurecido o perímetro de redes ou investido em sua postura defensiva. Uma estratégia defensiva não é suficiente contra essas ameaças.

Uma abordagem diferente

Em vez do foco tradicional na prevenção do compromisso, uma estratégia de segurança eficaz pressupõe que os adversários determinados violarão com êxito quaisquer defesas. Isso significa que é necessário desviar o foco dos controles de segurança preventivos para a detecção e resposta a problemas de segurança. A implementação da estratégia de gerenciamento de riscos, portanto, equilibra o investimento em prevenção, detecção e resposta.

Como os dispositivos móveis estão sendo cada vez mais usados para acessar informações corporativas, é necessário avaliar a segurança ou a integridade do dispositivo. Esta seção descreve como provisionar a avaliação de integridade do dispositivo de forma que ativos de alto valor possam ser protegidos contra dispositivos não íntegros.

Os dispositivos usados para acessar recursos corporativos devem ser confiáveis. Uma abordagem eficiente de segurança de ponta a ponta é capaz de avaliar a integridade do dispositivo e usar o estado de segurança atual ao conceder acesso a um ativo de alto valor.

figura 1.

Um design robusto precisa estabelecer a identidade do usuário, fortalecer o método de autenticação, se necessário, e aprender comportamentos como o local de rede do qual o usuário se conecta regularmente. Além disso, uma abordagem moderna deve ser capaz de liberar conteúdo confidencial somente se os dispositivos de usuário estiverem determinados a serem saudáveis e seguros.

A figura a seguir mostra uma solução criada para avaliar a integridade do dispositivo na nuvem. O dispositivo autentica o usuário por meio de uma conexão com um provedor de identidade na nuvem. Se o ativo gerenciado contiver informações altamente confidenciais, o mecanismo de acesso condicional do provedor de identidade poderá optar por verificar a conformidade de segurança do dispositivo móvel antes que o acesso seja concedido. O dispositivo do usuário é capaz de provar sua integridade status que podem ser enviadas a qualquer momento ou quando o MDM (gerenciamento de dispositivo móvel) o solicita.

figura 2.

Os dispositivos Windows podem ser protegidos contra kits de raiz de baixo nível e bootkits usando tecnologias de hardware de baixo nível, como a INICIALização segura da UEFI (Unified Extensible Firmware Interface).

A Inicialização Segura é um processo de validação de firmware que ajuda a evitar ataques de rootkit; faz parte da especificação UEFI. A intenção da UEFI é definir uma maneira padrão para o sistema operacional se comunicar com o hardware moderno, que pode executar funções de E/S (entrada/saída) mais rápidas e eficientes do que sistemas BIOS mais antigos e controlados por interrupção de software.

Um módulo de atestado de integridade do dispositivo pode comunicar dados de inicialização medidos protegidos por um TPM (Trusted Platform Module) a um serviço remoto. Depois que o dispositivo é inicializado com êxito, os dados de medição do processo de inicialização são enviados para um serviço de nuvem confiável (Serviço de Atestado de Integridade) usando um canal de comunicação mais seguro e resistente a adulterações.

O serviço de atestado de integridade remota executa uma série de verificações nas medidas. Ele valida os pontos de dados relacionados à segurança, incluindo o estado de inicialização (Inicialização Segura, Modo de Depuração e assim por diante) e o estado dos componentes que gerenciam a segurança (BitLocker, Device Guard e assim por diante). Em seguida, ele transmite o estado de integridade do dispositivo enviando um blob criptografado de integridade de volta para o dispositivo.

Uma solução MDM normalmente aplica políticas de configuração e implanta software em dispositivos. O MDM define a linha de base de segurança e sabe o nível de conformidade do dispositivo com verificações regulares para ver qual software está instalado e qual configuração é imposta e determinar a integridade status do dispositivo.

Uma solução MDM solicita que o dispositivo envie informações de integridade do dispositivo e encaminhe o blob criptografado para o serviço de atestado de integridade remota. O serviço de atestado de integridade remota verifica os dados de integridade do dispositivo, verifica se o MDM está se comunicando com o mesmo dispositivo e, em seguida, emite um relatório de integridade do dispositivo de volta à solução MDM.

Uma solução MDM avalia as declarações de integridade e, dependendo das regras de integridade pertencentes à organização, pode decidir se o dispositivo está saudável. Se o dispositivo estiver íntegro e compatível, o MDM passará essas informações para o provedor de identidade para que a política de controle de acesso da organização possa ser invocada para conceder acesso.

O acesso ao conteúdo é então autorizado ao nível apropriado de confiança para qualquer que seja o status de integridade e outros elementos condicionais indicarem.

Dependendo dos requisitos e da confidencialidade do ativo gerenciado, o status de integridade do dispositivo pode ser combinado com informações de identidade do usuário ao processar uma solicitação de acesso. Em seguida, o acesso ao conteúdo é autorizado ao nível apropriado de confiança. O mecanismo de Acesso Condicional pode ser estruturado para permitir mais verificação conforme necessário pela confidencialidade do ativo gerenciado. Por exemplo, se o acesso a dados de alto valor for solicitado, a autenticação de segurança adicional poderá precisar ser estabelecida consultando o usuário para atender a uma chamada telefônica antes que o acesso seja concedido.

Investimentos em segurança da Microsoft no Windows

No Windows, há três pilares de investimentos:

Proteger identidades. A Microsoft faz parte da aliança FIDO que visa fornecer um método interoperável de autenticação segura, afastando-se do uso de senhas para autenticação, tanto no sistema local quanto para serviços como recursos locais e recursos de nuvem.
Proteção de informações. A Microsoft está fazendo investimentos para permitir que as organizações tenham melhor controle sobre quem tem acesso a dados importantes e o que podem fazer com esses dados. Com o Windows, as organizações podem aproveitar as políticas que especificam quais aplicativos são considerados aplicativos corporativos e podem ser confiáveis para acessar dados seguros.
Resistência a ameaças. A Microsoft está ajudando as organizações a proteger melhor os ativos corporativos contra ameaças de malware e ataques usando defesas de segurança que dependem de hardware.

Proteger, controlar e relatar o status de segurança de dispositivos baseados no Windows

Esta seção é uma visão geral que descreve diferentes partes da solução de segurança de ponta a ponta que ajuda a proteger ativos de alto valor e informações de invasores e malware.

figura 3.

Número	Parte da solução	Descrição
1	Dispositivo baseado em Windows	Na primeira vez em que um dispositivo baseado no Windows é ativado, a tela OOBE (experiência fora de caixa) é exibida. Durante a instalação, o dispositivo pode ser registrado automaticamente em Microsoft Entra ID e registrado no MDM. Um dispositivo baseado no Windows com TPM pode relatar status de integridade a qualquer momento usando o Serviço de Atestado de Integridade disponível com todas as edições com suporte do Windows.
2	Provedor de identidade	Microsoft Entra ID contém usuários, dispositivos registrados e aplicativo registrado do locatário da organização. Um dispositivo sempre pertence a um usuário e um usuário pode ter vários dispositivos. Um dispositivo é representado como um objeto com atributos diferentes, como o status de conformidade do dispositivo. Um MDM confiável pode atualizar o status de conformidade. Microsoft Entra ID é mais do que um repositório. Microsoft Entra ID é capaz de autenticar usuários e dispositivos e também pode autorizar o acesso a recursos gerenciados. Microsoft Entra ID tem um mecanismo de controle de acesso condicional que usa a identidade do usuário, a localização do dispositivo e também o status de conformidade do dispositivo ao tomar uma decisão de acesso confiável.
3	Gerenciamento de dispositivos móveis	O Windows tem suporte a MDM que permite que o dispositivo seja gerenciado sem implantar nenhum agente. O MDM pode ser Microsoft Intune ou qualquer solução MDM de terceiros compatível com o Windows.
4	Atestado de integridade remota	O Serviço de Atestado de Integridade é um serviço de nuvem confiável operado pela Microsoft que executa uma série de verificações de integridade e relatórios para MDM quais recursos de segurança do Windows estão habilitados no dispositivo. A verificação de segurança inclui o estado de inicialização (WinPE, Modo Seguro, modos de depuração/teste) e componentes que gerenciam a segurança e a integridade das operações de runtime (BitLocker, Device Guard).
5	Ativo gerenciado da empresa	O ativo gerenciado da empresa é o recurso a ser protegido. Por exemplo, o ativo pode ser Office 365, outros aplicativos de nuvem, recursos Web locais publicados por Microsoft Entra ID ou até mesmo acesso VPN.

A combinação de dispositivos baseados no Windows, provedor de identidade, MDM e atestado de integridade remota cria uma solução de ponta a ponta robusta que fornece validação de integridade e conformidade de dispositivos que acessam ativos de alto valor.

Proteger dispositivos e credenciais corporativas contra ameaças

Esta seção descreve o que o Windows oferece em termos de defesas de segurança e a qual controle pode ser medido e relatado.

Defesas de segurança baseadas em hardware do Windows

As formas mais agressivas de malware tentam se inserir no processo de inicialização o mais cedo possível para que possam assumir o controle do sistema operacional precocemente e impedir que os mecanismos de proteção e o software antimalware funcionem. Esse tipo de código mal-intencionado geralmente é chamado de rootkit ou bootkit. A melhor maneira de evitar ter que lidar com malware de baixo nível é proteger o processo de inicialização para que o dispositivo seja protegido desde o início. O Windows dá suporte a várias camadas de proteção contra inicialização. Alguns desses recursos só estarão disponíveis se tipos específicos de hardware forem instalados. Para obter mais informações, consulte a seção Requisitos de hardware .

figura 4.

O Windows dá suporte a recursos para ajudar a evitar que malwares sofisticados de baixo nível, como rootkits e bootkits, sejam carregados durante o processo de inicialização:

Módulo plataforma confiável. Um TPM (Trusted Platform Module) é um componente de hardware que fornece recursos de segurança exclusivos.

O Windows usa características de segurança de um TPM para medir a sequência de integridade da inicialização (e, com base nisso, desbloquear automaticamente unidades protegidas pelo BitLocker), para proteger credenciais ou para atestado de integridade.

Um TPM implementa controles que atendem à especificação descrita pelo TCG (Grupo de Computação Confiável). No momento desta gravação, há duas versões da especificação TPM produzidas pelo TCG que não são compatíveis entre si:
- A primeira especificação TPM, versão 1.2, foi publicada em fevereiro de 2005 pelo TCG e padronizada sob o padrão ISO/IEC 11889.
- A especificação TPM mais recente, conhecida como TPM 2.0, foi lançada em abril de 2014 e foi aprovada pelo Comitê Técnico Conjunto iso/IEC (JTC) como ISO/IEC 11889:2015.
O Windows usa o TPM para cálculos criptográficos como parte do atestado de integridade e para proteger as chaves do BitLocker, Windows Hello, cartões inteligentes virtuais e outros certificados de chave pública. Para obter mais informações, confira Requisitos de TPM no Windows.

O Windows reconhece as especificações de TPM das versões 1.2 e 2.0 produzidas pelo TCG. Para os recursos de segurança mais recentes e modernos, o Windows dá suporte apenas ao TPM 2.0.

O TPM 2.0 fornece uma revisão importante para os recursos no TPM 1.2:
- Atualizar a força da criptografia para atender às necessidades de segurança modernas
  - Suporte para SHA-256 para PCRs
  - Suporte para o comando HMAC
- Flexibilidade de algoritmos criptográficos para dar suporte às necessidades do governo
  - O TPM 1.2 é severamente restrito em termos de quais algoritmos ele pode dar suporte
  - O TPM 2.0 pode dar suporte a algoritmos arbitrários com pequenas atualizações nos documentos de especificação do TCG
- Consistência entre implementações
  - A especificação TPM 1.2 permite aos fornecedores ampla latitude ao escolher detalhes da implementação
  - O TPM 2.0 padroniza grande parte desse comportamento
Inicialização Segura. Dispositivos com firmware UEFI podem ser configurados para carregar apenas inicializadores confiáveis do sistema operacional. A Inicialização Segura não requer um TPM.

A proteção mais básica é o recurso Inicialização Segura, que é uma parte padrão da arquitetura UEFI 2.2+. Em um computador com BIOS convencional, qualquer pessoa que possa assumir o controle do processo de inicialização pode inicializar usando um carregador de sistema operacional alternativo e potencialmente obter acesso aos recursos do sistema. Quando a Inicialização Segura estiver habilitada, você poderá inicializar usando apenas um carregador do sistema operacional assinado usando um certificado armazenado no DB de Inicialização Segura UEFI. Naturalmente, o certificado da Microsoft usado para assinar digitalmente os carregadores do sistema operacional Windows estão nesse repositório, o que permite que a UEFI valide o certificado como parte de sua política de segurança. A Inicialização Segura deve ser habilitada por padrão em todos os computadores certificados para Windows no Programa de Compatibilidade de Hardware do Windows.

A Inicialização Segura é um recurso baseado em firmware UEFI, que permite a assinatura e a verificação de arquivos de inicialização críticos e drivers na hora da inicialização. A Inicialização Segura verifica os valores de assinatura do Gerenciador de Inicialização do Windows, do repositório BCD, do arquivo do carregador do sistema operacional Windows e de outras DLLs críticas de inicialização no momento da inicialização antes que o sistema possa inicializar totalmente em um sistema operacional utilizável usando políticas definidas pelo OEM no momento do build. A Inicialização Segura impede muitos tipos de rootkit baseado em inicialização, malware e outros ataques relacionados à segurança contra a plataforma Windows. A Inicialização Segura protege o processo de inicialização do sistema operacional, seja inicializando do disco rígido local, USB, PXE ou DVD, ou no Ambiente de Recuperação do Windows ou windows completo (RE). A Inicialização Segura protege o ambiente de inicialização de uma instalação do Windows verificando as assinaturas dos componentes de inicialização críticos para confirmar que a atividade mal-intencionada não as comprometeu. A proteção contra inicialização segura termina após o arquivo kernel do Windows (ntoskrnl.exe) ter sido carregado.

Observação

A Inicialização Segura protege a plataforma até que o kernel do Windows seja carregado. Em seguida, proteções como ELAM assumem o comando.
Política de configuração de inicialização segura. Estende a funcionalidade de Inicialização Segura à configuração crítica do Windows.

Exemplos de informações de configuração protegidas incluem proteger a opção Executar bit (opção NX) ou garantir que a política de assinatura de teste (integridade de código) não possa ser habilitada. Essa ação de proteção garante que os binários e a configuração do computador possam ser confiáveis após a conclusão do processo de inicialização. A política de configuração de Inicialização Segura faz essa ação de proteção com a política UEFI. Essas assinaturas para essas políticas são assinadas da mesma forma que os binários do sistema operacional são assinados para uso com a Inicialização Segura.

A política de configuração de Inicialização Segura deve ser assinada por uma chave privada que corresponda a uma das chaves públicas armazenadas na lista KEK (Key Exchange Key). A Autoridade de Certificados da Microsoft (AC) estará presente na lista KEK de todos os sistemas de Inicialização Segura certificados pelo Windows. Por padrão, uma política assinada pelo Microsoft KEK deve funcionar em todos os sistemas de Inicialização Segura. BootMgr deve verificar a assinatura na lista KEK antes de aplicar uma política assinada. Com o Windows, a política padrão de configuração de Inicialização Segura está inserida no bootmgr.

O carregador de inicialização verifica a assinatura digital do kernel do Windows antes de carregá-lo. O kernel do Windows, por sua vez, verifica todos os outros componentes do processo de inicialização do Windows, incluindo os drivers de inicialização, os arquivos de inicialização e o componente ELAM. Essa etapa é importante e protege o restante do processo de inicialização verificando se todos os componentes de inicialização do Windows têm integridade e podem ser confiáveis.
Antimalware de Início Antecipado (ELAM). O ELAM testa todos os drivers antes que eles sejam carregados e impede que drivers não aprovados sejam carregados.

Os aplicativos antimalware tradicionais só começam depois que os drivers de inicialização são carregados, o que dá a um rootkit disfarçado de driver a oportunidade de trabalhar. ELAM é um mecanismo do Windows introduzido em uma versão anterior do Windows que permite que o software antimalware seja executado no início da sequência de inicialização. Assim, o componente antimalware é o primeiro componente de terceiros a executar e controlar a inicialização de outros drivers de inicialização até que o sistema operacional Windows esteja operacional. Quando o sistema é iniciado com um ambiente de runtime completo (acesso à rede, armazenamento e assim por diante), um antimalware completo é carregado.

O ELAM pode carregar um driver antimalware da Microsoft ou não Microsoft antes de todos os drivers de inicialização e aplicativos que não são da Microsoft, continuando assim a cadeia de confiança estabelecida pela Inicialização Segura e inicialização confiável. Como o sistema operacional ainda não foi iniciado e, como o Windows precisa inicializar o mais rápido possível, o ELAM tem uma tarefa simples: examinar cada driver de inicialização e determinar se ele está na lista de drivers confiáveis. Se não for confiável, o Windows não o carregará.

Observação

Windows Defender, o antimalware da Microsoft incluído por padrão no Windows, dá suporte a ELAM; ele pode ser substituído por uma solução compatível com antimalware de terceiros. O nome do driver ELAM Windows Defender é WdBoot.sys. Windows Defender usa seu driver ELAM para reverter quaisquer alterações mal-intencionadas feitas no driver de Windows Defender na próxima reinicialização. Isso impede que o malware do modo kernel faça alterações duradouras no driver de minifilfilamento do Windows Defender antes de desligar ou reiniciar.

O driver assinado pelo ELAM é carregado antes de outros drivers ou aplicativos de terceiros, o que permite que o software antimalware detecte e bloqueie qualquer tentativa de adulterar o processo de inicialização tentando carregar código não assinado ou não confiável.

O driver ELAM é um pequeno driver com um pequeno banco de dados de política que tem um escopo estreito, focado em drivers carregados mais cedo no lançamento do sistema. O banco de dados de política é armazenado em um hive de registro que também é medido para o TPM, para registrar os parâmetros operacionais do driver ELAM. Um driver ELAM deve ser assinado pela Microsoft e o certificado associado deve conter o EKU complementar (1.3.6.1.4.1.311.61.4.1).
Segurança baseada em virtualização (Hyper-V + Kernel Seguro). A segurança baseada em virtualização é um novo limite de segurança imposta que permite proteger partes críticas do Windows.

A segurança baseada em virtualização isola código confidencial, como Integridade do Código do Modo Kernel ou credenciais de domínio corporativo confidenciais do restante do sistema operacional Windows. Para obter mais informações, confira Seção de segurança baseada em virtualização .
HVCI (integridade de código protegida por hipervisor). A Integridade de Código protegida pelo hipervisor é um recurso do Device Guard que garante que apenas drivers, executáveis e DLLs que estejam em conformidade com a política de Integridade de Código do Device Guard sejam executadas.

Quando habilitado e configurado, o Windows pode iniciar os serviços de segurança baseados em virtualização do Hyper-V. O HVCI ajuda a proteger o núcleo do sistema (kernel), os drivers privilegiados e as defesas do sistema, como soluções antimalware, impedindo que o malware seja executado no início do processo de inicialização ou após a inicialização.

O HVCI usa a segurança baseada em virtualização para isolar a Integridade do Código, a única maneira de a memória do kernel se tornar executável é por meio de uma verificação de Integridade do Código. Essa dependência na verificação significa que as páginas de memória do kernel nunca podem ser graváveis e executáveis (W+X) e o código executável não pode ser modificado diretamente.

Observação

Os dispositivos do Device Guard que executam a Integridade do Código do Modo Kernel com segurança baseada em virtualização devem ter drivers compatíveis. Para obter informações adicionais, leia a compatibilidade do Driver com o Device Guard na postagem do blog do Windows .

O recurso Integridade de Código do Device Guard permite que as organizações controlem qual código é confiável para executar no kernel do Windows e quais aplicativos são aprovados para serem executados no modo de usuário. Ele é configurável usando uma política. A política de Integridade de Código do Device Guard é um arquivo binário que a Microsoft recomenda que você assine. A assinatura da política de Integridade de Código ajuda na proteção contra um usuário mal-intencionado com privilégios de administrador tentando modificar ou remover a política atual de Integridade do Código.
Credential Guard. O Credential Guard protege as credenciais corporativas com isolamento de credencial baseado em hardware.

No Windows, o Credential Guard visa proteger as credenciais corporativas de domínio contra roubo e reutilização por malware. Com o Credential Guard, o Windows implementou uma alteração arquitetônica que impede fundamentalmente as formas atuais do ataque ptH (pass-the-hash).

Esse estado sem ataque é realizado usando o Hyper-V e o novo recurso de segurança baseado em virtualização para criar um contêiner protegido em que códigos e segredos confiáveis são isolados do kernel do Windows. Essa realização significa que, mesmo que o kernel do Windows seja comprometido, um invasor não tem como ler e extrair os dados necessários para iniciar um ataque de PtH. O Credential Guard impede esse acesso não autorizado porque a memória em que os segredos são armazenados não está mais acessível do sistema operacional regular, mesmo no modo kernel - o hipervisor controla quem pode acessar a memória.
Atestado de integridade. O firmware do dispositivo registra o processo de inicialização e o Windows pode enviá-lo para um servidor confiável que pode marcar e avaliar a integridade do dispositivo.

O Windows usa medidas do firmware UEFI e cada um dos componentes do Windows e antimalware são feitos à medida que são carregados durante o processo de inicialização. Além disso, eles são tomados e medidos sequencialmente, não todos de uma vez. Quando essas medidas são concluídas, seus valores são assinados digitalmente e armazenados com segurança no TPM e não podem ser alterados a menos que o sistema seja redefinido.

Para obter mais informações, consulte Inicialização Protegida e Inicialização Medida: endurecendo componentes de inicialização antecipada contra malware.

Durante cada inicialização subsequente, os mesmos componentes são medidos, o que permite a comparação das medidas com uma linha de base esperada. Para obter mais segurança, os valores medidos pelo TPM podem ser assinados e transmitidos para um servidor remoto, que pode executar a comparação. Esse processo, chamado atestado de integridade remota do dispositivo, permite que o servidor verifique a integridade status do dispositivo Windows.

Embora a Inicialização Segura seja uma forma proativa de proteção, o atestado de integridade é uma forma reativa de proteção contra inicialização. O atestado de integridade é desabilitado no Windows e é habilitado por um antimalware ou um fornecedor de MDM. Ao contrário da Inicialização Segura, o atestado de integridade não interromperá o processo de inicialização e entrará em correção quando uma medida não funcionar. Mas com o controle de acesso condicional, o atestado de integridade ajudará a impedir o acesso a ativos de alto valor.

Segurança baseada em virtualização

A segurança baseada em virtualização fornece um novo limite de confiança para o Windows e usa a tecnologia de hipervisor Hyper-V para aprimorar a segurança da plataforma. A segurança baseada em virtualização fornece um ambiente de execução seguro para executar código confiável (trustlet) específico do Windows e proteger dados confidenciais.

A segurança baseada em virtualização ajuda a proteger contra um kernel comprometido ou um usuário mal-intencionado com privilégios de administrador. A segurança baseada em virtualização não está tentando proteger contra um invasor físico.

Os seguintes serviços windows são protegidos com segurança baseada em virtualização:

Credential Guard (LSA Credential Isolation): impede ataques de pass-the-hash e roubo de credencial empresarial que acontece lendo e despejando o conteúdo da memória lsass
Proteção de Dispositivo (Integridade de Código do Hyper-V): o Device Guard usa a nova segurança baseada em virtualização no Windows para isolar o serviço de Integridade de Código do próprio kernel do Windows, o que permite que o serviço use assinaturas definidas por sua política controlada pela empresa para ajudar a determinar o que é confiável. Na verdade, o serviço de Integridade de Código é executado ao lado do kernel em um contêiner protegido pelo hipervisor do Windows.
Outros serviços isolados: por exemplo, em Windows Server 2016, há o recurso vTPM que permite que você tenha VMs (máquinas virtuais criptografadas) em servidores.

Observação

A segurança baseada em virtualização só está disponível com a edição Enterprise. A segurança baseada em virtualização requer dispositivos com UEFI (2.3.1 ou superior) com Inicialização Segura habilitada, processador x64 com Extensões de Virtualização e SLAT habilitados. IOMMU, TPM 2.0. e o suporte para Memória Segura substituído são opcionais, mas recomendados.

O esquema abaixo é uma exibição de alto nível do Windows com segurança baseada em virtualização.

figura 5.

Credential Guard

No Windows, quando o Credential Guard está habilitado, o Serviço de Subsistema da Autoridade de Segurança Local (lsass.exe) executa um código confidencial em um modo de usuário isolado para ajudar a proteger dados de malware que podem estar em execução no modo de usuário normal. Essa execução de código ajuda a garantir que os dados protegidos não sejam roubados e reutilizados em computadores remotos, o que atenua muitos ataques no estilo PtH.

O Credential Guard ajuda a proteger as credenciais criptografando-as com uma chave por inicialização ou persistente:

A chave por inicialização é usada para qualquer credenciais na memória que não exijam persistência. Um exemplo de tal credencial seria uma chave de sessão TGT (tGT). Essa chave é negociada com um KDC (Key Distribution Center) sempre que a autenticação ocorre e é protegida com uma chave por inicialização.
A chave persistente, ou algum derivado, é usada para ajudar a proteger itens armazenados e recarregados após uma reinicialização. Essa proteção destina-se ao armazenamento de longo prazo e deve ser protegida com uma chave consistente. O Credential Guard é ativado por uma chave do registro e habilitado usando uma variável UEFI. Essa ativação é feita para proteger contra modificações remotas da configuração. O uso de uma variável UEFI implica que o acesso físico é necessário para alterar a configuração. Quando lsass.exe detecta que o isolamento de credencial está habilitado, ele gera LsaIso.exe como um processo isolado, o que garante que ele seja executado no modo de usuário isolado. A inicialização do LsaIso.exe é executada antes da inicialização de um provedor de suporte de segurança, o que garante que as rotinas de suporte do modo seguro estejam prontas antes do início de qualquer autenticação.

Device Guard

O Device Guard é um recurso do Windows Enterprise que permite que as organizações bloqueiem um dispositivo para ajudar a protegê-lo da execução de software não confiável. Nessa configuração, os únicos aplicativos autorizados a serem executados são os aplicativos confiáveis pela organização.

A decisão de confiança para executar o código é executada usando a Integridade de Código do Hyper-V, que é executada em segurança baseada em virtualização, um contêiner protegido pelo Hyper-V que é executado ao lado do Windows regular.

A Integridade do Código do Hyper-V é um recurso que valida a integridade de um driver ou arquivo do sistema sempre que ele é carregado na memória. A integridade do código detecta se um driver não assinado ou um arquivo do sistema está sendo carregado no kernel ou se um arquivo do sistema foi modificado por software mal-intencionado que está sendo executado por uma conta de usuário com privilégios de administrador. Em versões baseadas em x64 do Windows, os drivers do modo kernel devem ser assinados digitalmente.

Observação

Independentemente da ativação da Política de Proteção de Dispositivo, os drivers do Windows devem ser assinados pela Microsoft e, mais especificamente, pelo portal WHQL (Windows Hardware Quality Labs). Além disso, a partir de outubro de 2015, o portal do WHQL só aceitará envios de driver, incluindo envios de driver do kernel e do modo de usuário, que têm um certificado de assinatura de código válido de validação estendida ("EV").

Com o Device Guard, as organizações agora podem definir sua própria política de Integridade de Código para uso em sistemas x64 que executam o Windows Enterprise. As organizações têm a capacidade de configurar a política que determina o que é confiável para ser executado. Estes incluem drivers e arquivos do sistema e aplicativos e scripts tradicionais da área de trabalho. Em seguida, o sistema é bloqueado para executar apenas aplicativos em que a organização confia.

O Device Guard é um recurso interno do Windows Enterprise que impede a execução de códigos e aplicativos indesejados. O Device Guard pode ser configurado usando duas ações de regra – permitir e negar:

Permitir limita a execução de aplicativos a uma lista permitida de código ou editor confiável e bloqueia todo o resto.
Deny conclui a abordagem permitir o editor confiável bloqueando a execução de um aplicativo específico.

No momento desta escrita, e de acordo com a pesquisa mais recente da Microsoft, mais de 90% do malware não está totalmente assinado. Portanto, a implementação de uma política básica do Device Guard pode ajudar a bloquear o malware de maneira simples e eficaz. Na verdade, o Device Guard tem o potencial de ir mais longe e também pode ajudar a bloquear malware assinado.

O Device Guard precisa ser planejado e configurado para ser realmente eficaz. Não é apenas uma proteção habilitada ou desabilitada. O Device Guard é uma combinação de recursos de segurança de hardware e recursos de segurança de software que, quando configurados juntos, podem bloquear um computador para ajudar a garantir o sistema mais seguro e resistente possível.

Há três partes diferentes que compõem a solução Device Guard no Windows:

A primeira parte é um conjunto base de recursos de segurança de hardware introduzidos com a versão anterior do Windows. O TPM para operações criptográficas de hardware e UEFI com firmware moderno, juntamente com o Secure Boot, permite controlar o que o dispositivo está executando quando os sistemas começam.
Após o recurso de segurança de hardware, há o mecanismo de integridade de código. No Windows, a Integridade do Código agora é totalmente configurável e agora reside no modo de usuário isolado, uma parte da memória protegida pela segurança baseada em virtualização.
A última parte do Device Guard é a capacidade de gerenciamento. A configuração de integridade do código é exposta por meio de CSPs (objetos, cmdlets do PowerShell e CSPs) específicos de Política de Grupo.

Para obter mais informações sobre como implantar o Device Guard em uma empresa, consulte o guia de implantação do Device Guard.

Cenários do Device Guard

Conforme descrito anteriormente, o Device Guard é uma maneira poderosa de bloquear sistemas. O Device Guard não se destina a ser usado amplamente e pode nem sempre ser aplicável, mas há alguns cenários de alto interesse.

O Device Guard é útil e aplicável em sistemas de cargas de trabalho fixas, como caixas registradoras, quiosques, SAWs (estações de trabalho de segurança Administração) ou áreas de trabalho bem gerenciadas. O Device Guard é altamente relevante em sistemas que têm um software bem definido que deve ser executado e não é alterado com muita frequência. Ele também pode ajudar a proteger os IWs (Trabalhos de Informações) além de apenas SAWs, desde que o que eles precisam executar seja conhecido e o conjunto de aplicativos não seja alterado diariamente.

OS SAWs são computadores criados para ajudar a reduzir significativamente o risco de comprometimento de malware, ataques de phishing, sites falsos e ataques de PtH, entre outros riscos de segurança. Embora as SAWs não possam ser consideradas uma solução de segurança de "bala de prata" para esses ataques, esses tipos de clientes são úteis como parte de uma abordagem detalhada e em camadas para a segurança.

Para proteger ativos de alto valor, os SAWs são usados para fazer conexões seguras com esses ativos.

Da mesma forma, em estações de trabalho totalmente gerenciadas corporativas, em que os aplicativos são instalados usando uma ferramenta de distribuição como Microsoft Configuration Manager, Intune ou qualquer gerenciamento de dispositivo de terceiros, então o Device Guard é aplicável. Nesse tipo de cenário, a organização tem uma boa ideia do software que um usuário médio está executando.

Pode ser desafiador usar o Device Guard em estações de trabalho corporativas e levemente gerenciadas onde o usuário normalmente tem permissão para instalar software por conta própria. Quando uma organização oferece grande flexibilidade, é difícil executar o Device Guard no modo de execução. No entanto, o Device Guard pode ser executado no modo Auditoria e, nesse caso, o log de eventos conterá um registro de todos os binários que violaram a política do Device Guard. Quando o Device Guard é usado no modo Auditoria, as organizações podem obter dados avançados sobre drivers e aplicativos que os usuários instalam e executam.

Antes de se beneficiar da proteção incluída no Device Guard, a política de Integridade de Código deve ser criada usando ferramentas fornecidas pela Microsoft, mas a política pode ser implantada com ferramentas de gerenciamento comuns, como Política de Grupo. A política de Integridade de Código é um documento XML codificado por binário que inclui configurações para os modos Usuário e Kernel do Windows, juntamente com restrições em hosts de script do Windows. A política de Integridade de Código do Device Guard restringe qual código pode ser executado em um dispositivo.

Observação

A política do Device Guard pode ser assinada no Windows, o que adiciona proteção adicional contra usuários administrativos que alteram ou removem essa política.

A política do Device Guard assinada oferece uma proteção mais forte contra um administrador local mal-intencionado que tenta derrotar o Device Guard.

Quando a política é assinada, o GUID da política é armazenado em uma variável de segurança pré-sistema operacional UEFI que oferece proteção contra adulteração. A única maneira de atualizar a política do Device Guard posteriormente é fornecer uma nova versão da política assinada pelo mesmo signatário ou de um signatário especificado como parte da política do Device Guard na seção UpdateSigner.

A importância de assinar aplicativos

Em computadores com o Device Guard, a Microsoft propõe mudar de um mundo onde aplicativos não assinados podem ser executados sem restrições para um mundo em que apenas código assinado e confiável pode ser executado no Windows.

Com o Windows, as organizações disponibilizarão aplicativos LOB (linha de negócios) para membros da organização por meio da infraestrutura da Microsoft Store. Mais especificamente, os aplicativos LOB estarão disponíveis em uma loja privada dentro da Microsoft Store pública. A Microsoft Store assina e distribui aplicativos Universais do Windows e aplicativos clássicos do Windows. Todos os aplicativos baixados da Microsoft Store estão assinados.

Nas organizações de hoje, muitos aplicativos LOB não são assinados. A assinatura de código é frequentemente vista como um problema difícil de resolver por vários motivos, como a falta de experiência em assinatura de código. Mesmo que a assinatura de código seja uma prática recomendada, muitos aplicativos internos não serão assinados.

O Windows inclui ferramentas que permitem que profissionais de TI peguem aplicativos que já foram empacotados e os executem por meio de um processo para criar mais assinaturas que podem ser distribuídas junto com aplicativos existentes.

Por que as soluções de gerenciamento de dispositivos e antimalware ainda são necessárias?

Embora os mecanismos de lista de permissões sejam eficientes para garantir que apenas aplicativos confiáveis possam ser executados, eles não podem impedir o comprometimento de um aplicativo confiável (mas vulnerável) por conteúdo mal-intencionado projetado para explorar uma vulnerabilidade conhecida. O Device Guard não protege contra o código mal-intencionado do modo de usuário executado explorando vulnerabilidades.

Vulnerabilidades são fraquezas no software que podem permitir que um invasor comprometa a integridade, a disponibilidade ou a confidencialidade do dispositivo. Algumas das piores vulnerabilidades permitem que os invasores explorem o dispositivo comprometido fazendo com que ele execute código mal-intencionado sem o conhecimento do usuário.

É comum ver invasores distribuindo conteúdo especialmente criado na tentativa de explorar vulnerabilidades conhecidas no software de modo de usuário, como navegadores da Web (e seus plug-ins), máquinas virtuais Java, leitores de PDF ou editores de documentos. A partir de hoje, 90% das vulnerabilidades descobertas afetam aplicativos de modo de usuário em comparação com o sistema operacional e os drivers de modo kernel que os hospedam.

Para combater essas ameaças, o patch é o controle mais eficaz, com software antimalware formando camadas complementares de defesa.

A maioria dos softwares de aplicativo não tem nenhuma facilidade para se atualizar, portanto, mesmo que o fornecedor de software publique uma atualização que corrija a vulnerabilidade, o usuário pode não saber se a atualização está disponível ou como obtê-la e, portanto, permanece vulnerável a ataques. As organizações ainda precisam gerenciar dispositivos e corrigir vulnerabilidades.

As soluções MDM estão se tornando predominantes como uma tecnologia de gerenciamento de dispositivos leves. O Windows estende os recursos de gerenciamento que se tornaram disponíveis para MDMs. Um dos principais recursos que a Microsoft adicionou ao Windows é a capacidade dos MDMs de adquirir uma forte instrução de integridade do dispositivo de dispositivos gerenciados e registrados.

Atestado de integridade de dispositivo

O atestado de integridade do dispositivo usa o TPM para fornecer medidas criptograficamente fortes e verificáveis da cadeia de software usada para inicializar o dispositivo.

Para dispositivos baseados no Windows, a Microsoft apresenta uma nova API pública que permitirá que o software MDM acesse um serviço de atestado remoto chamado Serviço de Atestado de Integridade do Windows. Um resultado de atestado de integridade, além de outros elementos, pode ser usado para permitir ou negar acesso a redes, aplicativos ou serviços, com base em se os dispositivos se mostram saudáveis.

Para obter mais informações sobre o atestado de integridade do dispositivo, consulte a seção Detectar um dispositivo baseado em Windows não íntegro .

Edição do Windows e requisitos de licenciamento

A tabela a seguir lista as edições do Windows que dão suporte ao serviço de atestado de integridade do dispositivo:

Windows Pro	Windows Enterprise	Windows Pro Education/SE	Windows Education
Sim	Sim	Sim	Sim

Os direitos de licença de serviço de atestado de integridade do dispositivo são concedidos pelas seguintes licenças:

Windows Pro/Pro Education/SE	Windows Enterprise E3	Windows Enterprise E5	Windows Education A3	Windows Education A5
Sim	Sim	Sim	Sim	Sim

Para obter mais informações sobre o licenciamento do Windows, consulte Visão geral do licenciamento do Windows.

Requisitos de hardware

A tabela a seguir detalha os requisitos de hardware para serviços de segurança baseados em virtualização e o recurso de atestado de integridade. Para obter mais informações, consulte Requisitos mínimos de hardware.

Hardware	Motivação
UEFI 2.3.1 ou firmware posterior com a Inicialização Segura habilitada	Necessário para dar suporte à Inicialização Segura UEFI. A Inicialização Segura UEFI garante que o dispositivo inicialize apenas o código autorizado. Além disso, a Integridade da Inicialização (Inicialização Segura da Plataforma) deve ter suporte seguindo os requisitos na Especificação de Compatibilidade de Hardware para Sistemas para Windows sob a subseção: "System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby"
Extensões de virtualização, como Intel VT-x, AMD-V e SLAT devem estar habilitadas	Necessário para dar suporte à segurança baseada em virtualização. Nota: O Device Guard pode ser habilitado sem usar a segurança baseada em virtualização.
Processador X64	Necessário para dar suporte à segurança baseada em virtualização que usa o Windows Hypervisor. O Hyper-V tem suporte apenas no processador x64 (e não no x86). A proteção de DMA (Acesso Direto à Memória) pode ser habilitada para fornecer proteção de memória extra, mas exige que os processadores incluam tecnologias de proteção contra DMA.
IOMMU, como Intel VT-d, AMD-Vi	O suporte para o IOMMU no Windows aprimora a resiliência do sistema em relação a ataques DMA.
Trusted Platform Module (TPM)	Necessário para dar suporte ao atestado de integridade e necessário para outras proteções importantes para segurança baseada em virtualização. Há suporte para o TPM 2.0. O suporte ao TPM 1.2 foi adicionado a partir de Windows 10, versão 1607 (RS1)

Esta seção apresentou informações sobre vários controles intimamente relacionados no Windows . As defesas de várias camadas e a abordagem detalhada ajudam a erradicar o malware de baixo nível durante a sequência de inicialização. A segurança baseada em virtualização é uma alteração fundamental da arquitetura do sistema operacional que adiciona um novo limite de segurança. O Device Guard e o Credential Guard, respectivamente, ajudam a bloquear o código não confiável e proteger as credenciais de domínio corporativo contra roubo e reutilização. Esta seção também discutiu brevemente a importância de gerenciar dispositivos e corrigir vulnerabilidades. Todas essas tecnologias podem ser usadas para endurecer e bloquear dispositivos, limitando o risco de invasores comprometê-los.

Detectar um dispositivo não íntegro baseado no Windows

A partir de hoje, muitas organizações só consideram que os dispositivos estão em conformidade com a política da empresa depois de passarem por várias verificações que mostram, por exemplo, que o sistema operacional está no estado correto, configurado corretamente e tem a proteção de segurança habilitada. Infelizmente, com os sistemas atuais, essa forma de relatório não é totalmente confiável porque o malware pode falsificar uma instrução de software sobre a integridade do sistema. Um rootkit ou uma exploração de baixo nível semelhante pode relatar um estado falso e íntegro às ferramentas de conformidade tradicionais.

O maior desafio com os rootkits é que eles podem ser indetectáveis para o cliente. Como eles começam antes do antimalware e têm privilégios no nível do sistema, eles podem se disfarçar completamente enquanto continuam acessando recursos do sistema. Como resultado, computadores tradicionais infectados com rootkits parecem estar saudáveis, mesmo com antimalware em execução.

Conforme discutido anteriormente, o recurso de atestado de integridade do Windows usa o componente de hardware do TPM para registrar com segurança uma medida de todos os componentes relacionados à inicialização, incluindo firmware, kernel do Windows e até drivers de inicialização antecipados. Como o atestado de integridade usa as funcionalidades de segurança baseadas em hardware do TPM, o log de todos os componentes medidos pela inicialização permanece fora do alcance de qualquer malware.

Depois que os dispositivos atestam um estado de inicialização confiável, eles podem provar que não estão executando malware de baixo nível que pode falsificar verificações de conformidade posteriores. O atestado de integridade baseado em TPM fornece uma âncora confiável de confiança para ativos que contêm dados de alto valor.

Qual é o conceito de integridade do dispositivo?

Para entender o conceito de integridade do dispositivo, é importante saber as medidas tradicionais que os profissionais de TI tomaram para evitar a violação do malware. As tecnologias de controle de malware são altamente focadas na prevenção da instalação e distribuição.

No entanto, o uso de tecnologias tradicionais de prevenção de malware, como soluções antimalware ou patching, traz um novo conjunto de problemas para profissionais de TI: a capacidade de monitorar e controlar a conformidade dos dispositivos que acessam os recursos da organização.

A definição de conformidade do dispositivo variará de acordo com o antimalware instalado de uma organização, as configurações de configuração do dispositivo, a linha de base de gerenciamento de patchs e outros requisitos de segurança. Mas a integridade do dispositivo faz parte da política geral de conformidade do dispositivo.

A integridade do dispositivo não é binária e depende da implementação de segurança da organização. O Serviço de Atestado de Integridade fornece informações de volta ao MDM sobre quais recursos de segurança são habilitados durante a inicialização do dispositivo usando TPM de hardware confiável.

Mas o atestado de integridade fornece apenas informações, e é por isso que uma solução MDM é necessária para tomar e impor uma decisão.

Atestado de integridade do dispositivo remoto

No Windows, o atestado de integridade refere-se a um recurso em que os dados de inicialização medidos gerados durante o processo de inicialização são enviados para um serviço de atestado de integridade de dispositivo remoto operado pela Microsoft.

Essa abordagem é a mais segura disponível para dispositivos baseados no Windows detectarem quando as defesas de segurança estão em baixa. Durante o processo de inicialização, os valores do log TCG e dos PCRs são enviados para um serviço remoto de nuvem da Microsoft. Em seguida, os logs são verificados pelo Serviço de Atestado de Integridade para determinar quais alterações ocorreram no dispositivo.

Uma parte confiável como um MDM pode inspecionar o relatório gerado pelo serviço de atestado de integridade remota.

Observação

Para usar o recurso de atestado de integridade do Windows, o dispositivo deve ser equipado com um TPM discreto ou firmware. Não há restrição em nenhuma edição específica do Windows.

O Windows dá suporte a cenários de atestado de integridade permitindo que os aplicativos acessem o CSP (provedor de serviços de configuração de atestado de integridade) subjacente para que os aplicativos possam solicitar um token de atestado de integridade. A medida da sequência de inicialização pode ser verificada a qualquer momento localmente por um antimalware ou um agente MDM.

O atestado de integridade do dispositivo remoto combinado com um MDM fornece um método baseado em hardware para relatar a segurança atual status e detectar quaisquer alterações, sem precisar confiar no software em execução no sistema.

No caso em que o código mal-intencionado está sendo executado no dispositivo, o uso de um servidor remoto é necessário. Se um rootkit estiver presente no dispositivo, o antimalware não será mais confiável e seu comportamento poderá ser sequestrado por um código mal-intencionado em execução no início da sequência de inicialização. Esse motivo é o que torna importante usar o Secure Boot e o Device Guard para controlar qual código é carregado durante a sequência de inicialização.

O software antimalware pode pesquisar para determinar se a sequência de inicialização contém sinais de malware, como um rootkit. Ele também pode enviar o log TCG e os PCRs para um servidor de atestado de integridade remota para fornecer uma separação entre o componente de medida e o componente de verificação.

O atestado de integridade registra as medidas em vários registros de configuração de plataforma TPM (PCRs) e logs TCG durante o processo de inicialização.

figura 6.

Quando você inicia um dispositivo equipado com TPM, uma medida de componentes diferentes é executada. Esses componentes incluem firmware, drivers UEFI, microcódigo de CPU e também todos os drivers do Windows cujo tipo é Inicialização. As medidas brutas são armazenadas nos registros TPM PCR enquanto os detalhes de todos os eventos (caminho executável, certificação de autoridade e assim por diante) estão disponíveis no log TCG.

figura 7.

O processo de atestado de integridade funciona da seguinte maneira:

Os componentes de inicialização de hardware são medidos.
Os componentes de inicialização do sistema operacional são medidos.
Se o Device Guard estiver habilitado, a política atual do Device Guard será medida.
O kernel do Windows é medido.
O software antivírus é iniciado como o primeiro driver do modo kernel.
Os drivers de inicialização são medidos.
O servidor MDM por meio do agente MDM emite um comando de marcar de integridade usando o CSP do Atestado de Integridade.
As medidas de inicialização são validadas pelo Serviço de Atestado de Integridade

Observação

Por padrão, os últimos 100 logs de inicialização do sistema e todos os logs de currículo associados são arquivados na pasta %SystemRoot%\logs\measuredboot. O número de logs retidos pode ser definido com o valor de REG_DWORD de registro PlatformLogRetention na chave HKLM\SYSTEM\CurrentControlSet\Services\TPM . Um valor de 0 desativará o arquivo de log e um valor de 0xffffffff manterá todos os logs.

O processo a seguir descreve como as medidas de inicialização de integridade são enviadas para o serviço de atestado de integridade:

O cliente (um dispositivo baseado no Windows com TPM) inicia a solicitação com o serviço de atestado de integridade do dispositivo remoto. Como espera-se que o servidor de atestado de integridade seja um serviço de nuvem da Microsoft, o URI já está pré-provisionado no cliente.
Em seguida, o cliente envia o log TCG, os dados assinados pelo AIK (valores de PCR, contador de inicialização) e as informações do certificado AIK.
Em seguida, o serviço de atestado de integridade de dispositivo remoto:
1. Verifica se o certificado AIK é emitido por uma AC conhecida e confiável e o certificado é válido e não revogado.
2. Verifica se a assinatura nas aspas do PCR está correta e consistente com o valor de log TCG.
3. Analisa as propriedades no log do TCG.
4. Emite o token de integridade do dispositivo que contém as informações de integridade, as informações do AIK e as informações do contador de inicialização. O token de integridade também contém tempo de emissão válido. O token de integridade do dispositivo é criptografado e assinado, o que significa que as informações estão protegidas e acessíveis apenas ao serviço de atestado de integridade.
O cliente armazena o blob criptografado de integridade em seu repositório local. O token de integridade do dispositivo contém status de integridade do dispositivo, uma ID do dispositivo (o AIK do Windows) e o contador de inicialização.

figura 8.

Componentes de atestado de integridade do dispositivo

A solução de atestado de integridade do dispositivo envolve diferentes componentes que são TPM, Health Attestation CSP e o Serviço de Atestado de Integridade do Windows. Esses componentes são descritos nesta seção.

Trusted Platform Module

Esta seção descreve como PCRs (que contêm dados de configuração do sistema), EK (que atuam como uma cartão de identidade para TPM), SRK (que protegem chaves) e AIKs (que podem relatar o estado da plataforma) são usados para relatórios de atestado de integridade.

De forma simplificada, o TPM é um componente passivo com recursos limitados. Ele pode calcular números aleatórios, chaves RSA, descriptografar dados curtos, armazenar hashes tomadas ao inicializar o dispositivo.

Um TPM incorpora em um único componente:

Um gerador de chaves RSA de 2048 bits
Um gerador de número aleatório
Memória não complicada para armazenar chaves EK, SRK e AIK
Um mecanismo criptográfico para criptografar, descriptografar e assinar
Memória volátil para armazenar as chaves PCRs e RSA

Chave de endosso

O TPM tem uma chave criptográfica exclusiva inserida chamada chave de endosso. A chave de endosso do TPM é um par de chaves assimétricas (tamanho RSA 2048 bits).

A chave pública chave de endosso é usada para enviar parâmetros confidenciais com segurança, como ao tomar posse do TPM que contém o hash definidor da senha do proprietário. A chave privada EK é usada ao criar chaves secundárias como AIKs.

A chave de endosso atua como uma cartão de identidade para o TPM. Para obter mais informações, confira Entender a chave de endosso do TPM.

A chave de endosso geralmente é acompanhada por um ou dois certificados digitais:

Um certificado é produzido pelo fabricante do TPM e é chamado de certificado de endosso. O certificado de endosso é usado para provar a autenticidade do TPM (por exemplo, que é um TPM real fabricado por um fabricante de chips específico) para processos locais, aplicativos ou serviços de nuvem. O certificado de endosso é criado durante a fabricação ou na primeira vez que o TPM é inicializado comunicando-se com um serviço online.
O outro certificado é produzido pelo construtor de plataformas e é chamado de certificado de plataforma para indicar que um TPM específico está integrado a um determinado dispositivo. Para determinados dispositivos que usam o TPM baseado em firmware produzido pela Intel ou qualcomm, o certificado de endosso é criado quando o TPM é inicializado durante o OOBE do Windows.

Observação

A Inicialização Segura protege a plataforma até que o kernel do Windows seja carregado. Em seguida, proteções como Inicialização Confiável, Integridade do Código Hyper-V e ELAM assumem o comando. Um dispositivo que usa o Intel TPM ou o Qualcomm TPM obtém um certificado assinado online do fabricante que criou o chip e armazena o certificado assinado no armazenamento TPM. Para que a operação tenha êxito, se você estiver filtrando o acesso à Internet de seus dispositivos cliente, deverá autorizar as seguintes URLs:

Para o TPM de firmware da Intel: https://ekop.intel.com/ekcertservice
Para o TPM de firmware da Qualcomm: https://ekcert.spserv.microsoft.com/

Chaves de Identidade de Atestado

Como o certificado de endosso é exclusivo para cada dispositivo e não é alterado, o uso dele pode apresentar preocupações de privacidade porque, teoricamente, é possível rastrear um dispositivo específico. Para evitar esse problema de privacidade, o Windows emite uma âncora de atestado derivada com base no certificado de endosso. Essa chave intermediária, que pode ser atestada a uma chave de endosso, é a AIK (Chave de Identidade de Atestado) e o certificado correspondente é chamado de certificado AIK. Esse certificado AIK é emitido por um serviço de nuvem da Microsoft.

Observação

Antes que o dispositivo possa relatar sua integridade usando as funções de atestado do TPM, um certificado AIK deve ser provisionado em conjunto com um serviço de terceiros, como o serviço de AC do Microsoft Cloud. Depois de provisionada, a chave privada AIK pode ser usada para relatar a configuração da plataforma. O Windows cria uma assinatura sobre o estado do log da plataforma (e um valor de contador monotônico) em cada inicialização usando o AIK.

O AIK é um par de chaves assimétrico (público/privado) que é usado como um substituto para o EK como uma identidade para o TPM para fins de privacidade. A parte privada de um AIK nunca é revelada ou usada fora do TPM e só pode ser usada dentro do TPM para um conjunto limitado de operações. Além disso, ele só pode ser usado para assinatura e somente para operações limitadas definidas por TPM.

O Windows cria AIKs protegidos pelo TPM, se disponível, que são chaves de assinatura RSA de 2048 bits. A Microsoft está hospedando um serviço de nuvem chamado Microsoft Cloud CA para estabelecer criptograficamente que está se comunicando com um TPM real e que o TPM possui o AIK apresentado. Depois que o serviço de AC da Nuvem da Microsoft tiver estabelecido esses fatos, ele emitirá um certificado AIK para o dispositivo baseado no Windows.

Muitos dispositivos existentes que serão atualizados para Windows 10 não terão um TPM ou o TPM não conterá um certificado de endosso. Para acomodar esses dispositivos, Windows 10 permite a emissão de certificados AIK sem a presença de um certificado de endosso. Esses certificados AIK não são emitidos pela Microsoft Cloud CA. Esses certificados não são tão confiáveis quanto um certificado de endosso que é queimado no dispositivo durante a fabricação, mas fornecerá compatibilidade para cenários avançados como Windows Hello para Empresas sem TPM.

No certificado AIK emitido, um OID especial é adicionado para atestar que o certificado de endosso foi usado durante o processo de atestado. Essas informações podem ser usadas por uma parte confiável para decidir se rejeitam dispositivos que são atestados usando certificados AIK sem um certificado de endosso ou aceitá-los. Outro cenário pode ser não permitir o acesso a ativos de alto valor de dispositivos que são atestados por um certificado AIK que não é apoiado por um certificado de endosso.

Chave raiz de armazenamento

A chave raiz de armazenamento (SRK) também é um par de chaves assimétrica (RSA com um mínimo de 2048 bits de comprimento). O SRK tem uma função importante e é usado para proteger chaves TPM, para que essas chaves não possam ser usadas sem o TPM. A chave SRK é criada quando a propriedade do TPM é tomada.

Registros de Configuração da Plataforma

O TPM contém um conjunto de registros projetados para fornecer uma representação criptográfica do software e do estado do sistema inicializado. Esses registros são chamados de PCRs (Registros de Configuração de Plataforma).

A medida da sequência de inicialização é baseada no log de PCR e TCG. Para estabelecer uma raiz estática de confiança, quando o dispositivo está começando, o dispositivo deve ser capaz de medir o código de firmware antes da execução. Nesse caso, a Raiz Principal da Confiança para Medição (CRTM) é executada a partir da inicialização, calcula o hash do firmware e, em seguida, armazena-o expandindo o PCR[0] de registro e transfere a execução para o firmware.

Os PCRs são definidos como zero quando a plataforma é inicializada e é o trabalho do firmware que inicializa a plataforma para medir componentes na cadeia de inicialização e registrar as medidas nos PCRs. Normalmente, os componentes de inicialização pegam o hash do próximo componente que deve ser executado e registram as medidas nos PCRs. O componente inicial que inicia a cadeia de medidas é implicitamente confiável. Esse componente é o CRTM. Os fabricantes de plataforma são obrigados a ter um processo de atualização seguro para o CRTM ou não permitir atualizações para ele. Os PCRs registram um hash cumulativo dos componentes que foram medidos.

O valor de um PCR por conta própria é difícil de interpretar (é apenas um valor de hash), mas as plataformas normalmente mantêm um log com detalhes do que foi medido, e os PCRs apenas garantem que o log não foi adulterado. Os logs são chamados de log TCG. Sempre que um PCR de registro é estendido, uma entrada é adicionada ao log TCG. Assim, durante todo o processo de inicialização, um rastreamento dos dados de configuração e código executável é criado no log TCG.

Provisionamento TPM

Para que o TPM de um dispositivo baseado no Windows seja utilizável, ele deve primeiro ser provisionado. O processo de provisionamento difere com base nas versões do TPM, mas, quando bem-sucedido, resulta na usável TPM e nos dados de autorização do proprietário (ownerAuth) para o TPM que está sendo armazenado localmente no registro.

Quando o TPM for provisionado, o Windows tentará primeiro determinar os valores EK e ownerAuth armazenados localmente examinando o registro no seguinte local: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

Durante o processo de provisionamento, o dispositivo pode precisar ser reiniciado.

O cmdlet Get-TpmEndorsementKeyInfo PowerShell pode ser usado com privilégio administrativo para obter informações sobre a chave de endosso e certificados do TPM.

Se a propriedade TPM não for conhecida, mas o EK existir, a biblioteca de clientes provisionará o TPM e armazenará o valor ownerAuth resultante no registro se a política permitir que ele armazene a parte pública SRK no seguinte local: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Administração\SRKPub

Como parte do processo de provisionamento, o Windows criará um AIK com o TPM. Quando essa operação é executada, a parte pública AIK resultante é armazenada no registro no seguinte local: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub

Observação

Para provisionar certificados AIK e filtrar o acesso à Internet, você deve autorizar a seguinte URL curinga: https://\*.microsoftaik.azure.net

CSP do Atestado de Integridade do Windows

O Windows contém um CSP (provedor de serviços de configuração) especializado para interagir com o recurso de atestado de integridade. Um CSP é um componente que se conecta ao cliente MDM do Windows e fornece um protocolo publicado para como os servidores MDM podem configurar configurações e gerenciar dispositivos baseados no Windows. O protocolo de gerenciamento é representado como uma estrutura de árvore que pode ser especificada como URIs com funções a serem executadas nas URIs como "get", "set", "delete" e assim por diante.

A lista a seguir é a das funções executadas pelo CSP do Atestado de Integridade do Windows:

Coleta dados usados para verificar a integridade de um dispositivo status
Encaminha os dados para o Serviço de Atestado de Integridade
Provisiona o Certificado de Atestado de Integridade que ele recebe do Serviço de Atestado de Integridade
Após a solicitação, encaminha o Certificado de Atestado de Integridade (recebido do Serviço de Atestado de Integridade) e informações relacionadas de runtime para o servidor MDM para verificação

Durante uma sessão de atestado de integridade, o CSP do Atestado de Integridade encaminha os logs TCG e os valores de PCRs que são medidos durante a inicialização, usando um canal de comunicação seguro para o Serviço de Atestado de Integridade.

Quando um servidor MDM validar que um dispositivo atestou o Serviço de Atestado de Integridade, ele receberá um conjunto de instruções e declarações sobre como esse dispositivo foi inicializado, com a garantia de que o dispositivo não reinicializou entre o momento em que atestou sua integridade e a hora em que o servidor MDM o validou.

Serviço de Atestado de Integridade do Windows

A função do Serviço de Atestado de Integridade do Windows é essencialmente avaliar um conjunto de dados de integridade (valores de TCG log e PCR), fazer uma série de detecções (com base em dados de integridade disponíveis) e gerar blob de integridade criptografado ou produzir relatório para servidores MDM.

Observação

Servidores de dispositivo e MDM devem ter acesso a has.spserv.microsoft.com usando o protocolo TCP na porta 443 (HTTPS).

Verificar se um atestado TPM e o log associado são válidos adota várias etapas:

Primeiro, o servidor deve marcar que os relatórios sejam assinados por AIKs confiáveis. Essa verificação pode ser feita verificando se a parte pública do AIK está listada em um banco de dados de ativos ou talvez um certificado tenha sido verificado.
Após a verificação da chave, o atestado assinado (uma estrutura de aspas) deve ser verificado para ver se é uma assinatura válida sobre os valores de PCR.
Em seguida, os logs devem ser verificados para garantir que eles correspondam aos valores de PCR relatados.
Por fim, os próprios logs devem ser examinados por uma solução MDM para ver se eles representam configurações de segurança conhecidas ou válidas. Por exemplo, um marcar simples pode ser ver se os componentes do sistema operacional inicial medidos são conhecidos por serem bons, que o driver ELAM é como esperado e que o arquivo de política de driver ELAM está atualizado. Se todas essas verificações forem bem-sucedidas, uma instrução de atestado poderá ser emitida que posteriormente pode ser usada para determinar se o cliente deve ou não ter acesso a um recurso.

O Serviço de Atestado de Integridade fornece as seguintes informações a uma solução MDM sobre a integridade do dispositivo:

Habilitação de Inicialização Segura
Habilitação de depuração de inicialização e kernel
Habilitação do BitLocker
VSM habilitado
Medida de política de integridade de código do Device Guard não assinada ou não assinada
ELAM carregada
Inicialização do Modo Seguro, habilitação de DEP, habilitação de assinatura de teste
O TPM do dispositivo foi provisionado com um certificado de endosso confiável

Para concluir as medidas, consulte CSP do Atestado de Integridade.

A lista a seguir mostra alguns itens-chave que podem ser relatados de volta ao MDM para dispositivos baseados no Windows:

Medida PCR0
Inicialização segura habilitada
Inicialização segura corresponde ao esperado
O dbx de inicialização segura está atualizado
Guid de política de inicialização segura corresponde ao esperado
BitLocker habilitado
Segurança baseada em virtualização habilitada
ELAM foi carregada
A versão de Integridade do Código está atualizada
O hash da política de integridade de código corresponde ao esperado

Usar o MDM e o Serviço de Atestado de Integridade

Para tornar a integridade do dispositivo relevante, a solução MDM avalia o relatório de integridade do dispositivo e está configurada para os requisitos de integridade do dispositivo da organização.

Uma solução que usa o MDM e o Serviço de Atestado de Integridade consiste em três partes main:

Um dispositivo com atestado de integridade habilitado. Essa habilitação será feita como parte do registro com um provedor de MDM (o atestado de integridade será desabilitado por padrão).
Depois que esse serviço estiver habilitado e cada inicialização posteriormente, o dispositivo enviará medidas de integridade para o Serviço de Atestado de Integridade hospedado pela Microsoft e receberá um blob de atestado de integridade em troca.
A qualquer momento após esse ciclo, um servidor MDM pode solicitar o blob de atestado de integridade do dispositivo e pedir ao Serviço de Atestado de Integridade para descriptografar o conteúdo e validar que ele foi atestado.

A interação entre um dispositivo baseado no Windows, o Serviço de Atestado de Integridade e o MDM pode ser executada da seguinte maneira:

O cliente inicia uma sessão com o servidor MDM. O URI do servidor MDM faria parte do aplicativo cliente que inicia a solicitação. O servidor MDM neste momento poderia solicitar os dados de atestado de integridade usando o URI CSP apropriado.
O servidor MDM especifica um nó junto com a solicitação.
Em seguida, o cliente envia o nó citado AIK + o contador de inicialização e as informações de blob de integridade. Esse blob de integridade é criptografado com uma chave pública do Serviço de Atestado de Integridade que só o Serviço de Atestado de Integridade pode descriptografar.
O servidor MDM:
1. Verifica se o nó é conforme o esperado.
2. Passa os dados citados, o nó e o blob de integridade criptografado para o servidor do Serviço de Atestado de Integridade.
O Serviço de Atestado de Integridade:
1. Descriptografa o blob de integridade.
2. Verifica se o contador de inicialização na citação está correto usando o AIK no blob de integridade e corresponde ao valor no blob de integridade.
3. Verifica se o nó corresponde à cotação e à que é passada do MDM.
4. Como o contador de inicialização e o nó são citados com o AIK do blob de integridade, ele também prova que o dispositivo é o mesmo que aquele para o qual o blob de integridade foi gerado.
5. Envia dados de volta para o servidor MDM, incluindo parâmetros de integridade, frescor e assim por diante.

Observação

O servidor MDM (parte confiável) nunca executa a validação de contador de inicialização ou citação em si. Ele obtém os dados citados e o blob de integridade (que é criptografado) e envia os dados para o Serviço de Atestado de Integridade para validação. Dessa forma, o AIK nunca fica visível para o MDM, o que resolve as preocupações de privacidade.

Definir os requisitos para a conformidade do dispositivo é a primeira etapa para garantir que dispositivos registrados que não atendam aos requisitos de integridade e conformidade sejam detectados, rastreados e tenham ações impostas pela solução MDM.

Os dispositivos que tentam se conectar aos recursos devem ter sua integridade avaliada para que dispositivos não compatíveis e não compatíveis possam ser detectados e relatados. Para ser totalmente eficiente, uma solução de segurança de ponta a ponta deve impor uma consequência para dispositivos não íntegros, como recusar o acesso a ativos de alto valor. Essa consequência para um dispositivo não íntegro é a finalidade do controle de acesso condicional, que é detalhado na próxima seção.

Controlar a segurança de um dispositivo baseado no Windows antes que o acesso seja concedido

A tecnologia de controle de acesso atual, na maioria dos casos, se concentra em garantir que as pessoas certas obtenham acesso aos recursos certos. Se os usuários puderem se autenticar, eles obterão acesso a recursos usando um dispositivo que a equipe e os sistemas de TI da organização sabem pouco sobre. Talvez haja alguns marcar como garantir que um dispositivo seja criptografado antes de dar acesso ao email, mas e se o dispositivo estiver infectado com malware?

O processo de atestado de integridade do dispositivo remoto usa dados de inicialização medidos para verificar a integridade status do dispositivo. A integridade do dispositivo está disponível para uma solução MDM como Intune.

Observação

Para obter as informações mais recentes sobre Intune e suporte a recursos do Windows, confira Novidades no Microsoft Intune.

A figura abaixo mostra como o Serviço de Atestado de Integridade deve funcionar com o serviço MDM Intune baseado em nuvem da Microsoft.

figura 10.

Em seguida, uma solução MDM pode usar instruções de estado de integridade e levá-las para o próximo nível acoplamento com políticas de cliente que permitirão que o acesso condicional seja concedido com base na capacidade do dispositivo de provar que ele é livre de malware, seu sistema antimalware é funcional e atualizado, o firewall está em execução e o estado de patch de dispositivos está em conformidade.

Por fim, os recursos podem ser protegidos negando o acesso a pontos de extremidade que não podem provar que estão saudáveis. Esse recurso é muito necessário para dispositivos BYOD que precisam acessar recursos organizacionais.

Suporte interno do MDM no Windows

O Windows tem um cliente MDM que é enviado como parte do sistema operacional. Esse cliente MDM permite que os servidores MDM gerenciem dispositivos baseados no Windows sem exigir um agente separado.

Suporte a servidores MDM que não são da Microsoft

Servidores MDM não Microsoft podem gerenciar o Windows usando o protocolo MDM. O cliente de gerenciamento interno é capaz de se comunicar com um servidor compatível que dá suporte ao protocolo OMA-DM para executar tarefas de gerenciamento empresarial. Para obter mais informações, consulte Microsoft Entra integração ao MDM.

Observação

Os servidores MDM não precisam criar ou baixar um cliente para gerenciar o Windows. Para obter mais informações, consulte Gerenciamento de dispositivo móvel.

O servidor MDM de terceiros terá a mesma experiência consistente de usuário de primeira parte para registro, o que também fornece simplicidade para os usuários do Windows.

Gerenciamento de Windows Defender por MDM de terceiros

Essa infraestrutura de gerenciamento permite que profissionais de TI usem produtos com capacidade para MDM, como Intune, gerenciar atestado de integridade, Device Guard ou Windows Defender em dispositivos baseados no Windows, incluindo BYODs que não são ingressados no domínio. Os profissionais de TI poderão gerenciar e configurar todas as ações e configurações que estão familiarizados com a personalização usando Intune com Intune Endpoint Protection em sistemas operacionais de nível inferior. Os administradores que atualmente gerenciam apenas dispositivos ingressados no domínio por meio de Política de Grupo acharão fácil fazer a transição para o gerenciamento de dispositivos baseados no Windows usando o MDM porque muitas das configurações e ações são compartilhadas entre ambos os mecanismos.

Para obter mais informações sobre como gerenciar as configurações de segurança e sistema do Windows com uma solução MDM, consulte Configurações personalizadas de URI para dispositivos Windows.

Controle de acesso condicional

Na maioria das plataformas, o registro do dispositivo Microsoft Entra acontece automaticamente durante o registro. Os estados do dispositivo são gravados pela solução MDM em Microsoft Entra ID e lidos por Office 365 (ou por qualquer aplicativo autorizado do Windows que interaja com Microsoft Entra ID) na próxima vez que o cliente tentar acessar uma carga de trabalho compatível com Office 365.

Se o dispositivo não estiver registrado, o usuário receberá uma mensagem com instruções sobre como registrar (também conhecido como registro). Se o dispositivo não estiver em conformidade, o usuário receberá uma mensagem diferente que os redireciona para o portal da Web do MDM, onde poderá obter mais informações sobre o problema de conformidade e como resolve-lo.

Microsoft Entra ID autentica o usuário e o dispositivo, o MDM gerencia as políticas de conformidade e acesso condicional e o Serviço de Atestado de Integridade relata a integridade do dispositivo de forma atestada.

figura 11.

Office 365 controle de acesso condicional

Microsoft Entra ID impõe políticas de acesso condicional para garantir o acesso aos serviços de Office 365. Um administrador de locatário pode criar uma política de acesso condicional que bloqueia um usuário em um dispositivo não compatível de acessar um serviço Office 365. O usuário deve estar em conformidade com as políticas de dispositivo da empresa antes que o acesso possa ser concedido ao serviço. Como alternativa, o administrador também pode criar uma política que exige que os usuários registrem apenas seus dispositivos para obter acesso a um serviço Office 365. As políticas podem ser aplicadas a todos os usuários de uma organização ou limitadas a alguns grupos de destino e aprimoradas ao longo do tempo para incluir mais grupos de destino.

Quando um usuário solicita acesso a um serviço Office 365 de uma plataforma de dispositivo com suporte, Microsoft Entra autentica o usuário e o dispositivo do qual o usuário inicia a solicitação e concede acesso ao serviço somente quando o usuário está em conformidade com o conjunto de políticas do serviço. Os usuários que não têm seu dispositivo registrado recebem instruções de correção sobre como se registrar e se tornar compatíveis com o acesso aos serviços de Office 365 corporativos.

Quando um usuário se registra, o dispositivo é registrado com Microsoft Entra ID e registrado com uma solução MDM compatível, como Intune.

Observação

A Microsoft está trabalhando com ISVs MDM de terceiros para dar suporte a verificações de acesso baseadas em políticas e registro de MDM automatizados. As etapas para ativar o registro automático do MDM com Microsoft Entra ID e Intune são explicadas na postagem do blog Windows, Microsoft Entra ID And Microsoft Intune: Automatic MDM Enrollment Powered By The Cloud!.

Quando um usuário registra um dispositivo com êxito, o dispositivo se torna confiável. Microsoft Entra ID fornece logon único para acessar aplicativos da empresa e impõe a política de acesso condicional para conceder acesso a um serviço não apenas na primeira vez que o usuário solicita acesso, mas sempre que o usuário solicita para renovar o acesso.

O usuário terá acesso negado aos serviços quando as credenciais de entrada forem alteradas, um dispositivo for perdido/roubado ou a política de conformidade não for atendida no momento da solicitação de renovação.

Dependendo do tipo de aplicativo de email que os funcionários usam para acessar o Exchange online, o caminho para estabelecer o acesso seguro ao email pode ser um pouco diferente. No entanto, os principais componentes: Microsoft Entra ID, Office 365/Exchange Online e Intune, são os mesmos. A experiência de TI e a experiência do usuário final também são semelhantes.

figura 12.

Os clientes que tentarem acessar Office 365 serão avaliados para as seguintes propriedades:

O dispositivo é gerenciado por um MDM?
O dispositivo está registrado com Microsoft Entra ID?
O dispositivo está em conformidade?

Para chegar a um estado compatível, o dispositivo baseado no Windows precisa:

Registre-se com uma solução MDM.
Registre-se com Microsoft Entra ID.
Esteja em conformidade com as políticas de dispositivo definidas pela solução MDM.

Observação

No momento, as políticas de acesso condicional são aplicadas seletivamente aos usuários em dispositivos iOS e Android. Para obter mais informações, confira a postagem Microsoft Entra ID, Microsoft Intune e Windows – Usando a nuvem para modernizar a mobilidade corporativa!

Controle de acesso condicional de aplicativos locais e de nuvem

O controle de acesso condicional é um poderoso mecanismo de avaliação de política embutido em Microsoft Entra ID. Ele fornece aos profissionais de TI uma maneira fácil de criar regras de acesso além de Office 365 que avaliam o contexto da entrada de um usuário para tomar decisões em tempo real sobre quais aplicativos eles devem ser autorizados a acessar.

Os profissionais de TI podem configurar políticas de controle de acesso condicional para aplicativos SaaS de nuvem protegidos por aplicativos Microsoft Entra ID e até mesmo locais. As regras de acesso no Microsoft Entra ID usam o mecanismo de acesso condicional para marcar estado de integridade e conformidade do dispositivo relatado por uma solução MDM compatível como Intune para determinar se permite o acesso.

Para obter mais informações sobre o acesso condicional, consulte Prévia do Access Condicional do Azure para Aplicativos SaaS.

Observação

O controle de acesso condicional é um recurso Microsoft Entra ID P1 ou P2 que também está disponível com o EMS. Se você não tiver uma assinatura P1 ou P2 Microsoft Entra ID, poderá obter uma avaliação no site do Microsoft Azure.

Para aplicativos locais, há duas opções para habilitar o controle de acesso condicional com base no estado de conformidade de um dispositivo:

Para aplicativos locais que são publicados por meio do proxy do aplicativo Microsoft Entra, você pode configurar políticas de controle de acesso condicional como faria para aplicativos de nuvem. Para obter mais informações, consulte Usando Microsoft Entra proxy de aplicativo para publicar aplicativos locais para usuários remotos.
Além disso, Microsoft Entra Connect sincronizará as informações de conformidade do dispositivo de Microsoft Entra ID para o AD local. O ADFS no Windows Server 2016 oferecerá suporte ao controle de acesso condicional com base no estado de conformidade de um dispositivo. Os profissionais de TI configurarão políticas de controle de acesso condicional no ADFS que usam o estado de conformidade do dispositivo relatado por uma solução MDM compatível para proteger aplicativos locais.

figura 13.

O processo a seguir descreve como funciona Microsoft Entra Acesso Condicional:

O usuário já se registrou no MDM por meio da junção do Acesso/Azure AD do Local de Trabalho, que registra o dispositivo com Microsoft Entra ID.
Quando o dispositivo inicializa ou retoma da hibernação, uma tarefa "Tpm-HASCertRetr" é disparada para solicitar em segundo plano um blob de atestado de integridade. O dispositivo envia medidas de inicialização do TPM para o Serviço de Atestado de Integridade.
O Serviço de Atestado de Integridade valida o estado do dispositivo e emite um blob criptografado para o dispositivo com base no estado de integridade com detalhes sobre verificações com falha (se houver).
O usuário faz logon e o agente MDM entra em contato com o servidor Intune/MDM.
O servidor MDM reduz novas políticas se estiver disponível e consulta o estado do blob de integridade e outros estados de inventário.
O dispositivo envia um blob de atestado de integridade adquirido anteriormente e também o valor do outro inventário de estado solicitado pelo servidor Intune/MDM.
Intune/servidor MDM envia o blob de atestado de integridade para o Serviço de Atestado de Integridade a ser validado.
O Serviço de Atestado de Integridade valida que o dispositivo que enviou o blob de atestado de integridade é saudável e retorna esse resultado para Intune/servidor MDM.
Intune/servidor MDM avalia a conformidade com base na conformidade e no estado de atestado de inventário/integridade consultado do dispositivo.
Intune/servidor MDM atualiza o estado de conformidade em relação ao objeto do dispositivo no Microsoft Entra ID.
O usuário abre o aplicativo, tenta acessar um ativo gerenciado corporativo.
Acesso fechado por declaração de conformidade em Microsoft Entra ID.
Se o dispositivo estiver em conformidade e o usuário estiver autorizado, um token de acesso será gerado.
O usuário pode acessar o ativo gerenciado corporativo.

Para obter mais informações sobre Microsoft Entra ingressar, consulte Microsoft Entra ID & Windows: Better Together for Work ou School, um white paper.

O controle de acesso condicional é um tópico que muitas organizações e profissionais de TI podem não saber e devem. Os diferentes atributos que descrevem um usuário, um dispositivo, conformidade e contexto de acesso são poderosos quando usados com um mecanismo de acesso condicional. O controle de acesso condicional é uma etapa essencial que ajuda as organizações a proteger seu ambiente.

Takeaways e resumo

A lista a seguir contém chaves de alto nível para melhorar a postura de segurança de qualquer organização. No entanto, os poucos takeaways apresentados nesta seção não devem ser interpretados como uma lista exaustiva de práticas recomendadas de segurança.

Entender que nenhuma solução é 100% segura

Se adversários determinados com intenção mal-intencionada obtiverem acesso físico ao dispositivo, eles poderão eventualmente romper suas camadas de segurança e controlá-lo.
Usar atestado de integridade com uma solução MDM

Os dispositivos que tentam se conectar a ativos de alto valor devem ter sua integridade avaliada para que dispositivos não íntegros e não compatíveis possam ser detectados, relatados e eventualmente bloqueados.
Usar o Credential Guard

O Credential Guard é um recurso que ajuda muito a proteger as credenciais de domínio corporativo contra ataques pass-the-hash.
Usar o Device Guard

O Device Guard é um verdadeiro avanço na segurança e uma maneira eficaz de ajudar a proteger contra malware. O recurso Device Guard no Windows bloqueia aplicativos não confiáveis (aplicativos não autorizados pela sua organização).
Assinar política do Device Guard

A política do Device Guard assinada ajuda a proteger contra um usuário com privilégios de administrador tentando derrotar a política atual. Quando uma política é assinada, a única maneira de modificar o Device Guard posteriormente é fornecer uma nova versão da política assinada pelo mesmo signatário ou de um signatário especificar como parte da política do Device Guard.
Usar segurança baseada em virtualização

Quando você tem a Integridade do Código do Modo Kernel protegida pela segurança baseada em virtualização, as regras de integridade de código ainda serão impostas mesmo que uma vulnerabilidade permita acesso não autorizado à memória do modo kernel. Tenha em mente que os dispositivos do Device Guard que executam a Integridade do Código do Kernel com segurança baseada em virtualização devem ter drivers compatíveis.
Começar a implantar o Device Guard com o modo Audit

Implantar a política do Device Guard em computadores e dispositivos direcionados no modo auditoria. Monitore o log de eventos integridade do código que indica que um programa ou um driver teria sido bloqueado se o Device Guard estivesse configurado no modo De execução. Ajuste as regras do Device Guard até que um alto nível de confiança tenha sido atingido. Depois que a fase de teste for concluída, a política do Device Guard poderá ser alternada para o modo De execução.
Criar um computador de referência isolado ao implantar o Device Guard

Como a rede corporativa pode conter malware, você deve começar a configurar um ambiente de referência isolado de sua rede corporativa main. Depois disso, você pode criar uma política de integridade de código que inclua os aplicativos confiáveis que você deseja executar em seus dispositivos protegidos.
Usar o AppLocker quando fizer sentido

Embora o AppLocker não seja considerado um novo recurso do Device Guard, ele complementa a funcionalidade do Device Guard para alguns cenários, como poder negar um aplicativo Universal Específico do Windows para um usuário específico ou um grupo de usuários.
Bloquear firmware e configuração

Depois que o Windows for instalado, bloqueie o acesso às opções de inicialização de firmware. Esse bloqueio impede que um usuário com acesso físico modifique as configurações da UEFI, desabilite a Inicialização Segura ou inicialize outros sistemas operacionais. Além disso, para proteger contra um administrador que tenta desabilitar o Device Guard, adicione uma regra na política atual do Device Guard que negará e bloqueará a execução da ferramenta C:\Windows\System32\SecConfig.efi .

O atestado de integridade é um recurso fundamental do Windows que inclui componentes de cliente e nuvem para controlar o acesso a ativos de alto valor com base na identidade e na conformidade de seu dispositivo com a política de governança corporativa. As organizações podem optar por detectar e relatar dispositivos não íntegros ou configurar regras de aplicação da integridade com base em suas necessidades. O atestado de integridade fornece um modelo de segurança de ponta a ponta e pontos de integração, que fornecedores e desenvolvedores de software podem usar para criar e integrar uma solução personalizada.

Controlar a integridade dos dispositivos Windows

Introdução

Descrição de uma solução de segurança de ponta a ponta robusta

Uma abordagem diferente

Investimentos em segurança da Microsoft no Windows

Proteger, controlar e relatar o status de segurança de dispositivos baseados no Windows

Proteger dispositivos e credenciais corporativas contra ameaças

Defesas de segurança baseadas em hardware do Windows

Segurança baseada em virtualização

Credential Guard

Device Guard

Cenários do Device Guard

A importância de assinar aplicativos

Por que as soluções de gerenciamento de dispositivos e antimalware ainda são necessárias?

Atestado de integridade de dispositivo

Edição do Windows e requisitos de licenciamento

Requisitos de hardware

Detectar um dispositivo não íntegro baseado no Windows

Qual é o conceito de integridade do dispositivo?

Atestado de integridade do dispositivo remoto

Componentes de atestado de integridade do dispositivo

Trusted Platform Module

Chave de endosso

Chaves de Identidade de Atestado

Chave raiz de armazenamento

Registros de Configuração da Plataforma

Provisionamento TPM

CSP do Atestado de Integridade do Windows

Serviço de Atestado de Integridade do Windows

Usar o MDM e o Serviço de Atestado de Integridade

Controlar a segurança de um dispositivo baseado no Windows antes que o acesso seja concedido

Suporte interno do MDM no Windows

Suporte a servidores MDM que não são da Microsoft

Gerenciamento de Windows Defender por MDM de terceiros

Controle de acesso condicional

Office 365 controle de acesso condicional

Controle de acesso condicional de aplicativos locais e de nuvem

Takeaways e resumo

Tópicos relacionados

Comentários

Comentários

Recursos adicionais