Controlar o estado de funcionamento dos dispositivos Windows

• Aplica-se a:

  ✅ Windows 11, ✅ Windows 10

Este artigo detalha uma solução ponto a ponto que o ajuda a proteger recursos de alto valor ao impor, controlar e comunicar o estado de funcionamento dos dispositivos Windows.

Introdução

Para cenários ByOD (Bring Your Own Device), os utilizadores trazem dispositivos disponíveis comercialmente para aceder aos recursos relacionados com o trabalho e aos respetivos dados pessoais. Os utilizadores querem utilizar o dispositivo à sua escolha para aceder às aplicações, dados e recursos da organização, não só a partir da rede interna, mas também a partir de qualquer lugar. Este fenómeno também é conhecido como a consumação de TI.

Os utilizadores querem ter a melhor experiência de produtividade ao aceder a aplicações empresariais e trabalhar em dados da organização a partir dos respetivos dispositivos. Isto significa que não toleram que lhes seja pedido que introduzam as credenciais de trabalho sempre que acedem a uma aplicação ou a um servidor de ficheiros. Do ponto de vista da segurança, também significa que os utilizadores manipulam credenciais empresariais e dados empresariais em dispositivos não geridos.

Com o aumento da utilização do BYOD, haverá sistemas mais não geridos e potencialmente em mau estado de funcionamento a aceder a serviços empresariais, recursos internos e aplicações na cloud.

Até mesmo os dispositivos geridos podem ser comprometidos e tornar-se prejudiciais. As organizações precisam de detetar quando a segurança foi violada e reagir o mais cedo possível para proteger recursos de alto valor.

À medida que a Microsoft avança, os investimentos em segurança concentram-se cada vez mais em defesas preventivas de segurança e também em capacidades de deteção e resposta.

O Windows é um componente importante de uma solução de segurança ponto a ponto que se foca não só na implementação de defesas preventivas de segurança, mas adiciona capacidades de atestado de estado de funcionamento do dispositivo à estratégia de segurança geral.

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

O panorama das ameaças à computação de hoje está a aumentar a uma velocidade nunca antes encontrada. A sofisticação dos ataques criminais está a aumentar e não há dúvida de que o software maligno tem agora como alvo consumidores e profissionais em todas as indústrias.

Nos últimos anos, uma categoria específica de ameaça tornou-se predominante: ameaças persistentes avançadas (APTs). O termo APT é normalmente utilizado para descrever qualquer ataque que pareça visar organizações individuais de forma contínua. Na verdade, este tipo de ataque envolve normalmente adversários determinados que podem utilizar quaisquer métodos ou técnicas necessários.

Com os fenómenos BYOD, um dispositivo mal conservado representa um destino de eleição. Para um atacante, é uma forma fácil de ultrapassar o perímetro da rede de segurança, obter acesso e, em seguida, roubar ativos de alto valor.

Os atacantes têm como alvo indivíduos, não especificamente por causa de quem são, mas por causa de quem trabalham. Um dispositivo infetado traz software maligno para uma organização, mesmo que a organização tenha endurecido o perímetro das redes ou tenha investido na sua postura defensiva. Uma estratégia defensiva não é suficiente contra estas 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 adversários determinados violarão com sucesso quaisquer defesas. Significa que é necessário mudar o foco dos controlos de segurança preventivos para a deteção e resposta a problemas de segurança. Por conseguinte, a implementação da estratégia de gestão de riscos equilibra o investimento na prevenção, deteção e resposta.

Uma vez que os dispositivos móveis estão a ser cada vez mais utilizados para aceder a informações empresariais, é necessária alguma forma de avaliar a segurança ou o estado de funcionamento do dispositivo. Esta secção descreve como aprovisionar a avaliação do estado de funcionamento do dispositivo de forma a que os recursos de alto valor possam ser protegidos contra dispositivos em mau estado de funcionamento.

Os dispositivos que são utilizados para aceder a recursos empresariais têm de ser fidedignos. Uma abordagem de segurança ponto a ponto eficiente é capaz de avaliar o estado de funcionamento do dispositivo e utilizar o estado de segurança atual ao conceder acesso a um recurso de alto valor.

Uma estrutura robusta tem de estabelecer a identidade do utilizador, reforçar o método de autenticação, se necessário, e aprender o comportamento como a localização de rede a partir da qual o utilizador se liga regularmente. Além disso, uma abordagem moderna tem de ser capaz de libertar conteúdo confidencial apenas se os dispositivos de utilizador forem determinados como estando em bom estado de funcionamento e seguros.

A figura seguinte mostra uma solução criada para avaliar o estado de funcionamento do dispositivo a partir da cloud. O dispositivo autentica o utilizador através de uma ligação a um fornecedor de identidade na cloud. Se o recurso gerido contiver informações altamente confidenciais, o motor de acesso condicional do fornecedor de identidade poderá optar por verificar a conformidade de segurança do dispositivo móvel antes de o acesso ser concedido. O dispositivo do utilizador consegue provar o estado de funcionamento que pode ser enviado em qualquer altura ou quando a gestão de dispositivos móveis (MDM) o solicita.

Os dispositivos Windows podem ser protegidos contra rootkits e bootkits de baixo nível através de tecnologias de hardware de baixo nível, como o Arranque Seguro ueFI (Unified Extensible Firmware Interface).

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

Um módulo de atestado de estado de funcionamento do dispositivo pode comunicar dados de arranque medidos protegidos por um Trusted Platform Module (TPM) para um serviço remoto. Depois de o dispositivo arrancar com êxito, os dados de medição do processo de arranque são enviados para um serviço cloud fidedigno (Serviço de Atestado de Estado de Funcionamento) através de um canal de comunicação mais seguro e resistente a adulterações.

O serviço de atestado de estado de funcionamento remoto efetua uma série de verificações nas medidas. Valida pontos de dados relacionados com segurança, incluindo o estado de arranque (Arranque Seguro, Modo de Depuração, etc.) e o estado dos componentes que gerem a segurança (BitLocker, Device Guard, etc.). Em seguida, transmite o estado de funcionamento do dispositivo ao enviar um blob encriptado pelo estado de funcionamento de volta para o dispositivo.

Normalmente, uma solução MDM aplica políticas de configuração e implementa software em dispositivos. A MDM define a linha de base de segurança e conhece o nível de conformidade do dispositivo com verificações regulares para ver que software está instalado e que configuração é imposta e determinar o estado de funcionamento do dispositivo.

Uma solução MDM pede ao dispositivo para enviar informações de estado de funcionamento do dispositivo e reencaminhar o blob encriptado para o serviço de atestado de estado de funcionamento remoto. O serviço de atestado de estado de funcionamento remoto verifica os dados de estado de funcionamento do dispositivo, verifica se a MDM está a comunicar com o mesmo dispositivo e, em seguida, emite um relatório de estado de funcionamento do dispositivo novamente para a solução mdm.

Uma solução mdm avalia as asserções do estado de funcionamento e, dependendo das regras de estado de funcionamento que pertencem à organização, pode decidir se o dispositivo está em bom estado de funcionamento. Se o dispositivo estiver em bom estado de funcionamento e em conformidade, a MDM transmite essas informações ao fornecedor de identidade para que a política de controlo de acesso da organização possa ser invocada para conceder acesso.

Em seguida, o acesso ao conteúdo é autorizado ao nível de confiança adequado para o estado de funcionamento e outros elementos condicionais que indiquem.

Consoante os requisitos e a sensibilidade do recurso gerido, o estado de funcionamento do dispositivo pode ser combinado com as informações de identidade do utilizador ao processar um pedido de acesso. Em seguida, o acesso ao conteúdo é autorizado para o nível de confiança adequado. O motor de Acesso Condicional pode ser estruturado para permitir mais verificação conforme necessário pela confidencialidade do recurso gerido. Por exemplo, se for pedido acesso a dados de alto valor, poderá ser necessário estabelecer uma autenticação de segurança adicional ao consultar o utilizador para atender uma chamada telefónica antes de o acesso ser concedido.

Investimentos de segurança da Microsoft no Windows

No Windows, existem três pilares de investimentos:

• Identidades seguras. A Microsoft faz parte da aliança FIDO que visa fornecer um método interoperável de autenticação segura, afastando-se da utilização de palavras-passe para autenticação, tanto no sistema local como para serviços como recursos no local e recursos na cloud.
• Proteção de informações. A Microsoft está a fazer investimentos para permitir que as organizações tenham um melhor controlo sobre quem tem acesso a dados importantes e o que podem fazer com esses dados. Com o Windows, as organizações podem tirar partido de políticas que especificam que aplicações são consideradas aplicações empresariais e que podem ser consideradas fidedignas para aceder a dados seguros.
• Resistência a ameaças. A Microsoft está a ajudar as organizações a proteger melhor os recursos empresariais contra ameaças de software maligno e ataques através da utilização de defesas de segurança que dependem de hardware.

Proteger, controlar e comunicar o estado de segurança dos dispositivos baseados no Windows

Esta secção é uma descrição geral que descreve diferentes partes da solução de segurança ponto a ponto que ajuda a proteger recursos e informações de alto valor contra atacantes e software maligno.

Número	Parte da solução	Descrição
1	Dispositivo baseado no Windows	Quando um dispositivo baseado no Windows é ligado pela primeira vez, é apresentado o ecrã de experiência inicial (OOBE). Durante a configuração, o dispositivo pode ser registado automaticamente no ID do Microsoft Entra e inscrito na MDM. Um dispositivo baseado no Windows com TPM pode comunicar o estado de funcionamento em qualquer altura através do Serviço de Atestado de Estado de Funcionamento disponível com todas as edições suportadas do Windows.
2	Fornecedor de identidade	O ID do Microsoft Entra contém utilizadores, dispositivos registados e aplicação registada do inquilino da organização. Um dispositivo pertence sempre a um utilizador e um utilizador pode ter vários dispositivos. Um dispositivo é representado como um objeto com atributos diferentes, como o estado de conformidade do dispositivo. Uma MDM fidedigna pode atualizar o estado de conformidade. O ID do Microsoft Entra é mais do que um repositório. O Microsoft Entra ID é capaz de autenticar utilizadores e dispositivos e também pode autorizar o acesso a recursos geridos. O Microsoft Entra ID tem um motor de controlo de acesso condicional que utiliza a identidade do utilizador, a localização do dispositivo e também o estado de conformidade do dispositivo ao tomar uma decisão de acesso fidedigno.
3	Gerenciamento de dispositivos móveis	O Windows tem suporte de MDM que permite que o dispositivo seja gerido de forma inicial sem implementar qualquer agente. A MDM pode ser o Microsoft Intune ou qualquer solução de MDM de terceiros compatível com o Windows.
4	Atestado de estado de funcionamento remoto	O Serviço de Atestado de Estado de Funcionamento é um serviço cloud fidedigno operado pela Microsoft que efetua uma série de verificações de estado de funcionamento e comunica à MDM que funcionalidades de segurança do Windows estão ativadas no dispositivo. A verificação de segurança inclui o estado de arranque (WinPE, Modo de Segurança, Modo de Depuração/teste) e componentes que gerem a segurança e integridade das operações de runtime (BitLocker, Device Guard).
5	Recurso gerido pelo Enterprise	O recurso gerido pelo Enterprise é o recurso a proteger. Por exemplo, o recurso pode ser o Office 365, outras aplicações na nuvem, recursos Web no local publicados pelo Microsoft Entra ID ou até mesmo acesso VPN.

A combinação de dispositivos baseados no Windows, fornecedor de identidade, MDM e atestado de estado de funcionamento remoto cria uma solução ponto a ponto robusta que fornece validação do estado de funcionamento e conformidade dos dispositivos que acedem a recursos de alto valor.

Proteger dispositivos e credenciais empresariais contra ameaças

Esta secção descreve o que o Windows oferece em termos de defesas de segurança e que controlo pode ser medido e comunicado.

Defesas de segurança baseadas em hardware do Windows

As formas mais agressivas de software maligno tentam inserir-se no processo de arranque o mais cedo possível para que possam assumir o controlo do sistema operativo mais cedo e impedir que os mecanismos de proteção e o software antimalware funcionem. Este tipo de código malicioso é frequentemente denominado rootkit ou bootkit. A melhor forma de evitar ter de lidar com software maligno de baixo nível é proteger o processo de arranque para que o dispositivo esteja protegido desde o início. O Windows suporta várias camadas de proteção de arranque. Algumas destas funcionalidades só estão disponíveis se forem instalados tipos específicos de hardware. Para obter mais informações, veja a secção Requisitos de hardware .

O Windows suporta funcionalidades para ajudar a impedir o carregamento de software maligno sofisticado de baixo nível, como rootkits e bootkits, durante o processo de arranque:

• Trusted Platform Module( Módulo de Plataforma Fidedigno). Um Trusted Platform Module (TPM) é um componente de hardware que fornece funcionalidades de segurança exclusivas.

  O Windows utiliza características de segurança de um TPM para medir a sequência de integridade de arranque (e, com base nisso, desbloquear automaticamente unidades protegidas pelo BitLocker), para proteger credenciais ou para atestado de estado de funcionamento.

  Um TPM implementa controlos que cumprem a especificação descrita pelo Trusted Computing Group (TCG). No momento da escrita, existem 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 ao abrigo da norma ISO/IEC 11889.
  • A última especificação TPM, referida 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 utiliza o TPM para cálculos criptográficos como parte do atestado de estado de funcionamento e para proteger as chaves do BitLocker, Windows Hello, smart cards virtuais e outros certificados de chave pública. Para obter mais informações, veja Requisitos do TPM no Windows.

  O Windows reconhece as especificações TPM das versões 1.2 e 2.0 produzidas pelo TCG. Para as funcionalidades de segurança mais recentes e modernas, o Windows suporta apenas o TPM 2.0.

  O TPM 2.0 fornece uma revisão importante das capacidades através do TPM 1.2:

  • Atualizar a força criptográfica para satisfazer as necessidades de segurança modernas

    • Suporte para SHA-256 para PCRs
    • Suporte para o comando HMAC

  • Flexibilidade de algoritmos criptográficos para apoiar as necessidades governamentais

    • O TPM 1.2 é severamente restrito em termos dos algoritmos que pode suportar
    • O TPM 2.0 pode suportar algoritmos arbitrários com pequenas atualizações aos documentos de especificação do TCG

  • Consistência entre implementações

    • A especificação TPM 1.2 permite aos fornecedores uma ampla latitude ao escolher os detalhes de implementação
    • O TPM 2.0 uniformiza grande parte deste comportamento

• Inicialização Segura. Os dispositivos com firmware UEFI podem ser configurados para carregar apenas carregadores de arranque de sistema operativo fidedignos. O Arranque Seguro não requer um TPM.

  A proteção mais básica é a funcionalidade Arranque Seguro, que é uma parte padrão da arquitetura UEFI 2.2 ou superior. Num PC com BIOS convencional, qualquer pessoa que possa assumir o controlo do processo de arranque pode arrancar com um carregador de SO alternativo e potencialmente obter acesso aos recursos do sistema. Quando o Arranque Seguro está ativado, pode arrancar apenas com um carregador de SO assinado com um certificado armazenado na Base de Dados de Arranque Seguro ueFI. Naturalmente, o certificado da Microsoft utilizado para assinar digitalmente os carregadores do SO Windows está nesse arquivo, o que permite ao UEFI validar o certificado como parte da política de segurança. O Arranque Seguro tem de estar ativado por predefinição em todos os computadores certificados para Windows no Programa de Compatibilidade de Hardware do Windows.

  O Arranque Seguro é uma funcionalidade baseada em firmware UEFI, que permite a assinatura e verificação de controladores e ficheiros de arranque críticos no momento do arranque. O Arranque Seguro verifica os valores de assinatura do Gestor de Arranque do Windows, da loja BCD, do ficheiro do carregador do SO Windows e de outros DLLs críticos de arranque no momento do arranque antes de o sistema poder arrancar totalmente num sistema operativo utilizável através de políticas definidas pelo OEM no momento da compilação. O Arranque Seguro impede muitos tipos de rootkit baseado em arranque, software maligno e outros ataques relacionados com segurança contra a plataforma Windows. O Arranque Seguro protege o processo de arranque do sistema operativo, quer esteja a arrancar a partir do disco rígido local, USB, PXE ou DVD, ou em Ambiente de Recuperação do Windows (RE) completo. O Arranque Seguro protege o ambiente de arranque de uma instalação do Windows ao verificar as assinaturas dos componentes de arranque críticos para confirmar que a atividade maliciosa não os comprometeu. A proteção de Arranque Seguro termina após o carregamento do ficheiro kernel do Windows (ntoskrnl.exe).

  Observação

  O Arranque Seguro protege a plataforma até que o kernel do Windows seja carregado. Em seguida, as proteções como ELAM assumem o controlo.

• Política de configuração de Arranque Seguro. Expande a funcionalidade de Arranque Seguro para a configuração crítica do Windows.

  Exemplos de informações de configuração protegida incluem proteger Desativar Executar bit (opção NX) ou garantir que a política de assinatura de teste (integridade do código) não pode ser ativada. Esta ação de proteção garante que os binários e a configuração do computador podem ser considerados fidedignos após a conclusão do processo de arranque. A política de configuração de Arranque Seguro efetua esta ação de proteção com a política UEFI. Estas assinaturas para estas políticas são assinadas da mesma forma que os binários do sistema operativo são assinados para utilização com o Arranque Seguro.

  A política de configuração de Arranque Seguro tem de ser assinada por uma chave privada que corresponda a uma das chaves públicas armazenadas na lista Chave do Exchange de Chaves (KEK). A Autoridade de Certificação (AC) da Microsoft estará presente na lista KEK de todos os sistemas de Arranque Seguro certificados pelo Windows. Por predefinição, uma política assinada pela Microsoft KEK deve funcionar em todos os sistemas de Arranque Seguro. O BootMgr tem de verificar a assinatura na lista KEK antes de aplicar uma política assinada. Com o Windows, a política de configuração de Arranque Seguro predefinida é incorporada no bootmgr.

  O carregador de inicialização verifica a assinatura digital do kernel do Windows antes de carregá-lo. Por sua vez, o kernel do Windows verifica todos os outros componentes do processo de arranque do Windows, incluindo os controladores de arranque, os ficheiros de arranque e o componente ELAM. Este passo é importante e protege o resto do processo de arranque ao verificar se todos os componentes de arranque do Windows têm integridade e podem ser considerados fidedignos.

• 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.

  As aplicações antimalware tradicionais só são iniciadas depois de os controladores de arranque terem sido carregados, o que dá a um rootkit disfarçado de controlador a oportunidade de trabalhar. O ELAM é um mecanismo do Windows introduzido numa versão anterior do Windows que permite que o software antimalware seja executado no início da sequência de arranque. Assim, o componente antimalware é o primeiro componente de terceiros a ser executado e a controlar a inicialização de outros controladores de arranque até que o sistema operativo Windows esteja operacional. Quando o sistema é iniciado com um ambiente de runtime completo (acesso à rede, armazenamento, etc.), é carregado um antimalware completo.

  O ELAM pode carregar um controlador antimalware da Microsoft ou não microsoft antes de todos os controladores de arranque e aplicações que não sejam da Microsoft, continuando assim a cadeia de confiança estabelecida pelo Arranque Seguro e Arranque Fidedigno. Uma vez que o sistema operativo ainda não começou e porque o Windows precisa de arrancar o mais rapidamente possível, o ELAM tem uma tarefa simples: examinar todos os controladores de arranque e determinar se está na lista de controladores fidedignos. Se não for fidedigno, o Windows não o carregará.

  Observação

  O Windows Defender, o antimalware da Microsoft incluído por predefinição no Windows, suporta ELAM; pode ser substituído por uma solução compatível com antimalware de terceiros. O nome do controlador ELAM do Windows Defender é WdBoot.sys. O Windows Defender utiliza o controlador ELAM para reverter quaisquer alterações maliciosas efetuadas ao controlador do Windows Defender no próximo reinício. Isto impede que o software maligno do modo kernel faça alterações duradouras ao controlador de minifiltro do Windows Defender antes do encerramento ou reinício.

  O controlador assinado com ELAM é carregado antes de quaisquer outros controladores ou aplicações de terceiros, o que permite que o software antimalware detete e bloqueie quaisquer tentativas de adulteração do processo de arranque ao tentar carregar código não assinado ou não fidedigno.

  O controlador ELAM é um pequeno controlador com uma base de dados de política pequena que tem um âmbito estreito, focado nos controladores que são carregados mais cedo no início do sistema. A base de dados de políticas é armazenada num ramo de registo que também é medido para o TPM, para registar os parâmetros operacionais do controlador ELAM. Um controlador ELAM tem de ser assinado pela Microsoft e o certificado associado tem de 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 imposto que lhe 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 empresarial confidenciais do resto do sistema operativo Windows. Para obter mais informações, veja a secção Segurança baseada em virtualização .

• Integridade de Código (HVCI) protegida por hipervisor. A Integridade do Código protegida pelo hipervisor é uma funcionalidade do Device Guard que garante que apenas os controladores, executáveis e DLLs que estejam em conformidade com a política de Integridade do Código do Device Guard têm permissão para serem executados.

  Quando ativado e configurado, o Windows pode iniciar os serviços de segurança baseados na Virtualização do Hyper-V. O HVCI ajuda a proteger o núcleo do sistema (kernel), os controladores privilegiados e as defesas do sistema, como soluções antimalware, ao impedir que o software maligno seja executado no início do processo de arranque ou após o arranque.

  O HVCI utiliza a segurança baseada em Virtualização para isolar a Integridade do Código. A única forma de a memória do kernel se tornar executável é através de uma verificação de Integridade do Código. Esta dependência na verificação significa que as páginas de memória de 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 Device Guard que executam a Integridade do Código do Modo Kernel com segurança baseada em virtualização têm de ter controladores compatíveis. Para obter informações adicionais, leia a mensagem de blogue Compatibilidade do Controlador com o Device Guard no Windows .

  A funcionalidade Integridade do Código do Device Guard permite que as organizações controlem que código é fidedigno para ser executado no kernel do Windows e que aplicações são aprovadas para serem executadas no modo de utilizador. É configurável através de uma política. A política de Integridade do Código do Device Guard é um ficheiro binário que a Microsoft recomenda que assine. A assinatura da política de Integridade do Código ajuda na proteção contra um utilizador malicioso com privilégios de Administrador a tentar modificar ou remover a política de Integridade do Código atual.

• Credential Guard. O Credential Guard protege as credenciais empresariais com isolamento de credenciais baseado em hardware.

  No Windows, o Credential Guard tem como objetivo proteger as credenciais empresariais do domínio contra roubo e reutilização por software maligno. Com o Credential Guard, o Windows implementou uma alteração de arquitetura que impede fundamentalmente as formas atuais do ataque pass-the-hash (PtH).

  Este estado sem ataques é conseguido com o Hyper-V e a nova funcionalidade de segurança baseada em Virtualização para criar um contentor protegido onde o código e os segredos fidedignos estão isolados do kernel do Windows. Esta realização significa que, mesmo que o kernel do Windows esteja comprometido, um atacante não tem forma de ler e extrair os dados necessários para iniciar um ataque PtH. O Credential Guard impede este acesso não autorizado porque a memória onde os segredos são armazenados já não está acessível a partir do SO normal, mesmo no modo kernel – o hipervisor controla quem pode aceder à memória.

• Atestado de estado de funcionamento. O firmware do dispositivo regista o processo de arranque e o Windows pode enviá-lo para um servidor fidedigno que pode verificar e avaliar o estado de funcionamento do dispositivo.

  O Windows efetua medições do firmware UEFI e cada um dos componentes do Windows e antimalware são feitos à medida que são carregados durante o processo de arranque. Além disso, são tomadas e medidas sequencialmente, nem todas de uma só vez. Quando estas medições estiverem concluídas, os respetivos valores são assinados digitalmente e armazenados de forma segura no TPM e não podem ser alterados a menos que o sistema seja reposto.

  Para obter mais informações, veja Arranque Seguro e Arranque Medido: Proteção de Componentes de Arranque Antecipado Contra Software Maligno.

  Durante cada arranque 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, o que pode efetuar a comparação. Este processo, denominado atestado de estado de funcionamento do dispositivo remoto, permite ao servidor verificar o estado de funcionamento do dispositivo Windows.

  Embora o Arranque Seguro seja uma forma proativa de proteção, o atestado de estado de funcionamento é uma forma reativa de proteção de arranque. O atestado de estado de funcionamento está desativado no Windows e é ativado por um fornecedor de MDM ou antimalware. Ao contrário do Arranque Seguro, o atestado de estado de funcionamento não para o processo de arranque e introduz a remediação quando uma medição não funciona. No entanto, com o controlo de acesso condicional, o atestado de estado de funcionamento ajuda a impedir o acesso a recursos 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 utiliza a tecnologia de hipervisor Hyper-V para melhorar a segurança da plataforma. A segurança baseada em virtualização fornece um ambiente de execução seguro para executar código fidedigno (trustlet) específico do Windows e para proteger dados confidenciais.

A segurança baseada em virtualização ajuda a proteger contra um kernel comprometido ou um utilizador malicioso com privilégios de Administrador. A segurança baseada em virtualização não está a tentar proteger contra um atacante físico.

Os seguintes serviços do Windows estão protegidos com segurança baseada em Virtualização:

• Credential Guard (Isolamento de Credenciais LSA): impede ataques de passagem do hash e roubo de credenciais empresariais que ocorrem ao ler e capturar o conteúdo da memória lsass
• Device Guard (Integridade do Código do Hyper-V): o Device Guard utiliza a nova segurança baseada em Virtualização no Windows para isolar o serviço Integridade do Código do próprio kernel do Windows, o que permite ao serviço utilizar assinaturas definidas pela sua política controlada pela empresa para ajudar a determinar o que é fidedigno. Com efeito, o serviço Integridade do Código é executado juntamente com o kernel num contentor protegido por hipervisor do Windows.
• Outros serviços isolados: por exemplo, no Windows Server 2016, existe a funcionalidade vTPM que lhe permite ter máquinas virtuais (VMs) encriptadas nos servidores.

Observação

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

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

Credential Guard

No Windows, quando o Credential Guard está ativado, o Serviço de Subsistema de Autoridade de Segurança Local (lsass.exe) executa um código confidencial num modo de utilizador Isolado para ajudar a proteger dados contra software maligno que possa estar em execução no modo de utilizador normal. Esta execução de código ajuda a garantir que os dados protegidos não são roubados e reutilizados em máquinas remotas, o que mitiga muitos ataques ao estilo PtH.

O Credential Guard ajuda a proteger as credenciais ao encriptá-las com uma chave por arranque ou persistente:

• A chave por arranque é utilizada para quaisquer credenciais dentro da memória que não exijam persistência. Um exemplo dessa credencial seria uma chave de sessão de permissão de concessão de permissão (TGT). Esta chave é negociada com um Centro de Distribuição de Chaves (KDC) sempre que a autenticação ocorre e é protegida com uma chave por arranque.
• A chave persistente, ou algum derivado, é utilizada para ajudar a proteger itens armazenados e recarregados após um reinício. Essa proteção destina-se ao armazenamento a longo prazo e tem de ser protegida com uma chave consistente. O Credential Guard é ativado por uma chave de registo e, em seguida, ativado através de uma variável UEFI. Esta ativação é feita para proteger contra modificações remotas da configuração. A utilização de uma variável UEFI implica que o acesso físico é necessário para alterar a configuração. Quando lsass.exe deteta que o isolamento de credenciais está ativado, gera LsaIso.exe como um processo isolado, o que garante que é executado no modo de utilizador isolado. O arranque do LsaIso.exe é realizado antes da inicialização de um fornecedor de suporte de segurança, o que garante que as rotinas de suporte do modo seguro estão prontas antes de qualquer autenticação começar.

Device Guard

O Device Guard é uma funcionalidade do Windows Enterprise que permite que as organizações bloqueiem um dispositivo para ajudar a protegê-lo contra a execução de software não fidedigno. Nesta configuração, as únicas aplicações autorizadas a executar são as aplicações que são consideradas fidedignas pela organização.

A decisão de fidedignidade para executar o código é executada com a Integridade de Código do Hyper-V, que é executada na segurança baseada em Virtualização, um contentor protegido por Hyper-V que é executado juntamente com o Windows normal.

A Integridade do Código hyper-V é uma funcionalidade que valida a integridade de um controlador ou ficheiro de sistema sempre que é carregado para a memória. A integridade do código deteta se um ficheiro de sistema ou controlador não assinado está a ser carregado para o kernel ou se um ficheiro de sistema foi modificado por software malicioso que está a ser executado por uma conta de utilizador com privilégios de Administrador. Nas versões baseadas em x64 do Windows, os controladores de modo kernel têm de estar assinados digitalmente.

Observação

Independentemente da ativação da Política do Device Guard, os controladores do Windows têm de 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 WHQL só aceitará submissões de controladores, incluindo submissões de controladores de kernel e de modo de utilizador, que tenham um Certificado de Assinatura de Código de Validação Alargada ("EV") válido.

Com o Device Guard, as organizações podem agora definir a sua própria política de Integridade do Código para utilização em sistemas x64 com o Windows Enterprise. As organizações têm a capacidade de configurar a política que determina o que é fidedigno para ser executado. Estes incluem controladores e ficheiros de sistema, bem como aplicações e scripts de ambiente de trabalho tradicionais. Em seguida, o sistema é bloqueado para executar apenas aplicações nas quais a organização confia.

O Device Guard é uma funcionalidade incorporada do Windows Enterprise que impede a execução de códigos e aplicações indesejados. O Device Guard pode ser configurado com duas ações de regra – permitir e negar:

• Permitir limita a execução de aplicações a uma lista permitida de código ou fabricante fidedigno e bloqueia tudo o resto.
• Negar conclui a abordagem permitir fabricante fidedigno ao bloquear a execução de uma aplicação específica.

No momento da escrita, e de acordo com as mais recentes pesquisas da Microsoft, mais de 90% do software maligno não está assinado completamente. Assim, implementar uma política básica do Device Guard pode ajudar a bloquear software maligno de forma simples e eficaz. Na verdade, o Device Guard tem o potencial de ir mais longe e também pode ajudar a bloquear software maligno assinado.

O Device Guard tem de ser planeado e configurado para ser verdadeiramente eficaz. Não é apenas uma proteção que está ativada ou desativada. O Device Guard é uma combinação de funcionalidades de segurança de hardware e funcionalidades de segurança de software que, quando configuradas em conjunto, podem bloquear um computador para ajudar a garantir o sistema mais seguro e resistente possível.

Existem três partes diferentes que constituem a solução Device Guard no Windows:

• A primeira parte é um conjunto base de funcionalidades de segurança de hardware introduzidas com a versão anterior do Windows. O TPM para operações criptográficas de hardware e UEFI com firmware moderno, juntamente com o Arranque Seguro, permite-lhe controlar o que o dispositivo está a executar quando os sistemas são iniciados.
• Depois da funcionalidade de segurança de hardware, existe o motor de integridade do código. No Windows, a Integridade do Código é agora totalmente configurável e agora reside no modo de utilizador Isolado, uma parte da memória protegida pela segurança baseada em Virtualização.
• A última parte do Device Guard é a capacidade de gestão. A configuração da Integridade do Código é exposta através de Objetos de Política de Grupo específicos, cmdlets do PowerShell e fornecedores de serviços de configuração MDM (CSPs).

Para obter mais informações sobre como implementar o Device Guard numa empresa, veja o Guia de implementação do Device Guard.

Cenários do Device Guard

Conforme descrito anteriormente, o Device Guard é uma forma avançada de bloquear sistemas. O Device Guard não se destina a ser utilizado amplamente e pode nem sempre ser aplicável, mas existem alguns cenários de elevado interesse.

O Device Guard é útil e aplicável em sistemas de cargas de trabalho fixas, como caixas registadoras, máquinas de quiosque, Estações de Trabalho de Administração Segura (SAWs) ou ambientes de trabalho bem geridos. O Device Guard é altamente relevante em sistemas que têm um software bem definido que se espera que seja executado e que não é alterado com muita frequência. Também pode ajudar a proteger os Trabalhadores da Informação (IWs) para além de apenas SAWs, desde que o que precisam de executar seja conhecido e o conjunto de aplicações não mude diariamente.

As SAWs são computadores criados para ajudar a reduzir significativamente o risco de comprometimento de software maligno, ataques de phishing, sites falsos e ataques PtH, entre outros riscos de segurança. Embora as SAWs não possam ser consideradas uma solução de segurança "marca de prata" para estes ataques, estes tipos de clientes são úteis como parte de uma abordagem de segurança em camadas e de defesa em profundidade.

Para proteger recursos de alto valor, as SAWs são utilizadas para efetuar ligações seguras a esses recursos.

Da mesma forma, em estações de trabalho totalmente geridas pela empresa, em que as aplicações são instaladas através de uma ferramenta de distribuição como o Microsoft Configuration Manager, o Intune ou qualquer gestão de dispositivos de terceiros, é aplicável o Device Guard. Neste tipo de cenário, a organização tem uma boa ideia do software que um utilizador médio está a executar.

Pode ser difícil utilizar o Device Guard em estações de trabalho empresariais e geridas de forma leve, onde normalmente o utilizador tem permissão para instalar software por conta própria. Quando uma organização oferece uma grande flexibilidade, é difícil executar o Device Guard no modo de imposição. No entanto, o Device Guard pode ser executado no modo de Auditoria e, nesse caso, o registo de eventos contém um registo de quaisquer binários que violaram a política do Device Guard. Quando o Device Guard é utilizado no modo de Auditoria, as organizações podem obter dados avançados sobre controladores e aplicações que os utilizadores instalam e executam.

Antes de poder beneficiar da proteção incluída no Device Guard, a política de Integridade do Código tem de ser criada através de ferramentas fornecidas pela Microsoft, mas a política pode ser implementada com ferramentas de gestão comuns, como a Política de Grupo. A política de Integridade do Código é um documento XML codificado em binários que inclui definições de configuração para os modos Utilizador e Kernel do Windows, juntamente com restrições nos anfitriões de scripts do Windows. A política de Integridade do Código do Device Guard restringe o código que pode ser executado num dispositivo.

Observação

A política do Device Guard pode ter sessão iniciada no Windows, o que adiciona proteção adicional contra utilizadores administrativos que alteram ou removem esta política.

A política de Device Guard assinada oferece uma proteção mais forte contra um administrador local malicioso que tenta derrotar o Device Guard.

Quando a política é assinada, o GUID da política é armazenado numa variável segura ueFI pré-SO que oferece proteção contra adulteração. A única forma de atualizar a política do Device Guard mais tarde é 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 para a secção UpdateSigner.

A importância de assinar aplicações

Em computadores com o Device Guard, a Microsoft propõe passar de um mundo onde as aplicações não assinadas podem ser executadas sem restrições para um mundo em que apenas é permitido executar código assinado e fidedigno no Windows.

Com o Windows, as organizações disponibilizam aplicações de linha de negócio (LOB) aos membros da organização através da infraestrutura da Microsoft Store. Mais especificamente, as aplicações LOB estão disponíveis numa loja privada na Microsoft Store pública. A Microsoft Store assina e distribui aplicações Universais do Windows e aplicações Clássicas do Windows. Todas as aplicações transferidas a partir da Microsoft Store estão assinadas.

Atualmente, em organizações, muitas aplicações LOB não estão assinadas. A assinatura de código é frequentemente vista como um problema difícil de resolver por vários motivos, como a falta de conhecimentos de assinatura de código. Mesmo que a assinatura de código seja uma melhor prática, muitas aplicações internas não são assinadas.

O Windows inclui ferramentas que permitem aos profissionais de TI utilizar aplicações que já foram empacotadas e executá-las através de um processo para criar mais assinaturas que podem ser distribuídas juntamente com aplicações existentes.

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

Embora os mecanismos de lista de permissões sejam eficientes para garantir que apenas as aplicações fidedignas podem ser executadas, não podem impedir o comprometimento de uma aplicação fidedigna (mas vulnerável) por conteúdo malicioso concebido para explorar uma vulnerabilidade conhecida. O Device Guard não protege contra código malicioso em modo de utilizador executado através da exploração de vulnerabilidades.

As vulnerabilidades são vulnerabilidades no software que podem permitir que um atacante comprometa a integridade, disponibilidade ou confidencialidade do dispositivo. Algumas das piores vulnerabilidades permitem que os atacantes explorem o dispositivo comprometido, fazendo com que executem código malicioso sem o conhecimento do utilizador.

É comum ver atacantes a distribuir conteúdo especialmente concebido numa tentativa de explorar vulnerabilidades conhecidas no software de modo de utilizador, como browsers (e os respetivos plug-ins), máquinas virtuais Java, leitores de PDF ou editores de documentos. A partir de hoje, 90% das vulnerabilidades detetadas afetam as aplicações de modo de utilizador em comparação com o sistema operativo e os controladores do modo kernel que as alojam.

Para combater estas ameaças, a aplicação de patches é o controlo mais eficaz, com software antimalware a formar camadas complementares de defesa.

A maioria do software de aplicação não tem instalações para atualizar a si próprio, por isso, mesmo que o fornecedor de software publique uma atualização que corrija a vulnerabilidade, o utilizador poderá não saber que a atualização está disponível ou como obtê-la e, por conseguinte, permanece vulnerável a ataques. As organizações ainda precisam de gerir dispositivos e corrigir vulnerabilidades.

As soluções mdm estão a tornar-se predominantes como uma tecnologia de gestão de dispositivos leve. O Windows expande as capacidades de gestão que ficaram disponíveis para MDMs. Uma das principais funcionalidades que a Microsoft adicionou ao Windows é a capacidade de os MDMs adquirirem uma declaração forte do estado de funcionamento do dispositivo a partir de dispositivos geridos e registados.

Atestado de integridade de dispositivo

O atestado de estado de funcionamento do dispositivo utiliza o TPM para fornecer medições criptograficamente fortes e verificáveis da cadeia de software utilizada para arrancar o dispositivo.

Para dispositivos baseados em Windows, a Microsoft introduz uma nova API pública que permitirá que o software MDM aceda a um serviço de atestado remoto denominado Serviço de Atestado de Estado de Funcionamento do Windows. Um resultado de atestado de estado de funcionamento, além de outros elementos, pode ser utilizado para permitir ou negar o acesso a redes, aplicações ou serviços, com base no facto de os dispositivos se revelarem em bom estado de funcionamento.

Para obter mais informações sobre o atestado de estado de funcionamento do dispositivo, consulte a secção Detetar um dispositivo baseado no Windows em mau estado de funcionamento.

Edição do Windows e requisitos de licenciamento

A tabela seguinte lista as edições do Windows que suportam o serviço de atestado estado de funcionamento do dispositivo:

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

Os direitos de licença do serviço de atestado de estado de funcionamento 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 seguinte detalha os requisitos de hardware para os serviços de segurança baseados em Virtualização e a funcionalidade de atestado de estado de funcionamento. Para obter mais informações, veja Requisitos mínimos de hardware.

Hardware	Motivação
Firmware UEFI 2.3.1 ou posterior com Arranque Seguro ativado	Necessário para suportar o Arranque Seguro UEFI. O Arranque Seguro UEFI garante que o dispositivo arranca apenas o código autorizado. Além disso, a Integridade de Arranque (Arranque Seguro da Plataforma) tem de ser suportada ao seguir os requisitos em Especificação de Compatibilidade de Hardware para Sistemas para Windows na subsecção: "System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby"
As extensões de virtualização, como Intel VT-x, AMD-V e SLAT, têm de estar ativadas	Necessário para suportar a segurança baseada em Virtualização. Nota: O Device Guard pode ser ativado sem utilizar a segurança baseada em Virtualização.
Processador X64	Necessário para suportar a segurança baseada em Virtualização que utiliza o Windows Hypervisor. O Hyper-V só é suportado no processador x64 (e não no x86). A proteção do Acesso Direto à Memória (DMA) pode ser ativada para fornecer proteção de memória adicional, mas requer que os processadores incluam tecnologias de proteção do DMA.
IOMMU, como Intel VT-d, AMD-Vi	O suporte para a IOMMU no Windows melhora a resiliência do sistema contra ataques DMA.
Trusted Platform Module (TPM)	Necessário para suportar o atestado de estado de funcionamento e necessário para outras proteções chave para a segurança baseada em Virtualização. O TPM 2.0 é suportado. O suporte para o TPM 1.2 foi adicionado a partir do Windows 10, versão 1607 (RS1)

Esta secção apresentou informações sobre vários controlos intimamente relacionados no Windows. As defesas de várias camadas e a abordagem aprofundada ajudam a erradicar software maligno de baixo nível durante a sequência de arranque. A segurança baseada em virtualização é uma alteração fundamental da arquitetura do sistema operativo que adiciona um novo limite de segurança. O Device Guard e o Credential Guard ajudam, respetivamente, a bloquear código não fidedigno e a proteger as credenciais de domínio empresarial contra roubo e reutilização. Esta secção também abordou brevemente a importância de gerir dispositivos e corrigir vulnerabilidades. Todas estas tecnologias podem ser utilizadas para proteger e bloquear dispositivos ao mesmo tempo que limitam o risco de os atacantes os comprometerem.

Detetar um dispositivo baseado no Windows em mau estado de funcionamento

A partir de hoje, muitas organizações apenas consideram que os dispositivos estão em conformidade com a política da empresa depois de terem passado várias verificações que mostram, por exemplo, que o sistema operativo está no estado correto, devidamente configurado e tem a proteção de segurança ativada. Infelizmente, com os sistemas atuais, esta forma de relatórios não é totalmente fiável porque o software maligno pode falsificar uma declaração de software sobre o estado de funcionamento do sistema. Um rootkit, ou uma exploração de baixo nível semelhante, pode comunicar um estado de funcionamento falso às ferramentas de conformidade tradicionais.

O maior desafio dos rootkits é que podem ser indetectáveis para o cliente. Uma vez que começam antes do antimalware e têm privilégios ao nível do sistema, podem disfarçar-se completamente enquanto continuam a aceder aos recursos do sistema. Como resultado, os computadores tradicionais infetados com rootkits parecem estar em bom estado de funcionamento, mesmo com antimalware em execução.

Conforme abordado anteriormente, a funcionalidade de atestado de estado de funcionamento do Windows utiliza o componente de hardware TPM para registar de forma segura uma medição de todos os componentes relacionados com o arranque, incluindo firmware, kernel do Windows e até controladores de arranque antecipado. Uma vez que o atestado de estado de funcionamento utiliza as capacidades de segurança baseadas em hardware do TPM, o registo de todos os componentes medidos pelo arranque permanece fora do alcance de qualquer software maligno.

Depois de os dispositivos atestarem um estado de arranque fidedigno, podem provar que não estão a executar software maligno de baixo nível que possa falsificar verificações de conformidade posteriores. O atestado de estado de funcionamento baseado em TPM fornece uma âncora fiável de confiança para recursos que contêm dados de alto valor.

Qual é o conceito de estado de funcionamento do dispositivo?

Para compreender o conceito de estado de funcionamento do dispositivo, é importante conhecer as medidas tradicionais que os profissionais de TI tomaram para evitar a violação do software maligno. As tecnologias de controlo de software maligno estão muito focadas na prevenção da instalação e distribuição.

No entanto, a utilização de tecnologias tradicionais de prevenção de software maligno, como soluções antimalware ou de aplicação de patches, traz um novo conjunto de problemas para profissionais de TI: a capacidade de monitorizar e controlar a conformidade dos dispositivos que acedem aos recursos da organização.

A definição de conformidade do dispositivo varia consoante o antimalware instalado de uma organização, as definições de configuração do dispositivo, a linha de base de gestão de patches e outros requisitos de segurança. No entanto, o estado de funcionamento do dispositivo faz parte da política geral de conformidade do dispositivo.

O estado de funcionamento do dispositivo não é binário e depende da implementação de segurança da organização. O Serviço de Atestado de Estado de Funcionamento fornece informações à MDM sobre as funcionalidades de segurança ativadas durante o arranque do dispositivo através do TPM de hardware fidedigno.

No entanto, o atestado de estado de funcionamento apenas fornece informações, razão pela qual é necessária uma solução mdm para tomar e impor uma decisão.

Atestado de estado de funcionamento do dispositivo remoto

No Windows, o atestado de estado de funcionamento refere-se a uma funcionalidade em que os dados de Arranque Medido gerados durante o processo de arranque são enviados para um serviço de atestado de estado de funcionamento do dispositivo remoto operado pela Microsoft.

Esta abordagem é a mais segura disponível para os dispositivos baseados em Windows detetarem quando as defesas de segurança estão inativas. Durante o processo de arranque, o registo TCG e os valores dos PCRs são enviados para um serviço cloud remoto da Microsoft. Em seguida, os registos são verificados pelo Serviço de Atestado de Estado de Funcionamento para determinar que alterações ocorreram no dispositivo.

Uma entidade confiadora como uma MDM pode inspecionar o relatório gerado pelo serviço de atestado de estado de funcionamento remoto.

Observação

Para utilizar a funcionalidade de atestado de estado de funcionamento do Windows, o dispositivo tem de estar equipado com um TPM discreto ou de firmware. Não existem restrições a nenhuma edição específica do Windows.

O Windows suporta cenários de atestado de estado de funcionamento ao permitir que as aplicações acedam ao fornecedor de serviços de configuração do atestado de estado de funcionamento subjacente (CSP) para que as aplicações possam pedir um token de atestado de estado de funcionamento. A medição da sequência de arranque pode ser verificada localmente a qualquer momento por um agente antimalware ou MDM.

O atestado de estado de funcionamento do dispositivo remoto combinado com uma MDM fornece um método com root de hardware para comunicar o estado de segurança atual e detetar quaisquer alterações, sem ter de confiar no software em execução no sistema.

No caso de código malicioso estar em execução no dispositivo, é necessária a utilização de um servidor remoto. Se estiver presente um rootkit no dispositivo, o antimalware já não é fiável e o respetivo comportamento pode ser sequestrado por um código malicioso em execução no início da sequência de arranque. Este motivo é o que torna importante utilizar o Arranque Seguro e o Device Guard, para controlar que código é carregado durante a sequência de arranque.

O software antimalware pode procurar para determinar se a sequência de arranque contém sinais de software maligno, como um rootkit. Também pode enviar o registo TCG e os PCRs para um servidor de atestado de estado de funcionamento remoto para fornecer uma separação entre o componente de medição e o componente de verificação.

O atestado de estado de funcionamento regista as medições em vários Registos de Configuração da Plataforma TPM (PCRs) e registos TCG durante o processo de arranque.

Quando inicia um dispositivo equipado com TPM, é efetuada uma medição de diferentes componentes. Estes componentes incluem firmware, controladores UEFI, microcódigo da CPU e também todos os controladores do Windows cujo tipo é Arranque Inicial. As medições não processadas são armazenadas nos registos de PCR do TPM, enquanto os detalhes de todos os eventos (caminho executável, certificação de autoridade, etc.) estão disponíveis no registo TCG.

O processo de atestado de estado de funcionamento funciona da seguinte forma:

1. Os componentes de arranque de hardware são medidos.
2. Os componentes de arranque do sistema operativo são medidos.
3. Se o Device Guard estiver ativado, a política do Device Guard atual é medida.
4. O kernel do Windows é medido.
5. O software antivírus é iniciado como o primeiro controlador de modo kernel.
6. Os controladores de arranque são medidos.
7. O servidor MDM através do agente MDM emite um comando de verificação de estado de funcionamento com o CSP do Atestado de Estado de Funcionamento.
8. As medições de arranque são validadas pelo Serviço de Atestado de Estado de Funcionamento

Observação

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

O processo seguinte descreve como as medições de arranque do estado de funcionamento são enviadas para o serviço de atestado de estado de funcionamento:

1. O cliente (um dispositivo baseado no Windows com TPM) inicia o pedido com o serviço de atestado de estado de funcionamento do dispositivo remoto. Uma vez que se espera que o servidor de atestado de estado de funcionamento seja um serviço cloud da Microsoft, o URI já está pré-aprovisionado no cliente.

2. Em seguida, o cliente envia o registo TCG, os dados assinados pelo AIK (valores PCR, contador de arranque) e as informações do certificado AIK.

3. Em seguida, o serviço de atestado de estado de funcionamento do dispositivo remoto:

   1. Verifica se o certificado do AIK é emitido por uma AC conhecida e fidedigna 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 registo do TCG.
   3. Analisa as propriedades no registo TCG.
   4. Emite o token de estado de funcionamento do dispositivo que contém as informações de estado de funcionamento, as informações do AIK e as informações do contador de arranque. O token de estado de funcionamento também contém um tempo de emissão válido. O token de estado de funcionamento do dispositivo está encriptado e assinado, o que significa que as informações estão protegidas e só estão acessíveis para emitir o serviço de atestado de estado de funcionamento.

4. O cliente armazena o blob encriptado de estado de funcionamento no respetivo arquivo local. O token de estado de funcionamento do dispositivo contém o estado de funcionamento do dispositivo, um ID do dispositivo (o Windows AIK) e o contador de arranque.

Componentes do atestado de estado de funcionamento do dispositivo

A solução de atestado de estado de funcionamento do dispositivo envolve diferentes componentes que são TPM, Health Attestation CSP e Windows Health Attestation Service. Estes componentes estão descritos nesta secção.

Trusted Platform Module

Esta secção descreve como os PCRs (que contêm dados de configuração do sistema), a chave de endossamento (EK) (que funcionam como um bilhete de identidade para TPM), SRK (que protegem chaves) e AIKs (que podem comunicar o estado da plataforma) são utilizados para relatórios de atestado de estado de funcionamento.

De forma simplificada, o TPM é um componente passivo com recursos limitados. Pode calcular números aleatórios, chaves RSA, desencriptar dados curtos, armazenar hashes tirados ao arrancar o dispositivo.

Um TPM incorpora um único componente:

• Um gerador de chaves RSA de 2048 bits
• Um gerador de números aleatórios
• Memória não complexa para armazenar chaves EK, SRK e AIK
• Um motor criptográfico para encriptar, desencriptar e assinar
• Memória volátil para armazenar os PCRs e as chaves RSA

Chave de endossamento

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

A chave pública da chave de endossamento é utilizada para enviar parâmetros confidenciais de forma segura, como quando toma posse do TPM que contém o hash de definição da palavra-passe do proprietário. A chave privada EK é utilizada ao criar chaves secundárias, como AIKs.

A chave de endossamento funciona como um bilhete de identidade para o TPM. Para obter mais informações, veja Compreender a chave de endossamento do TPM.

A chave de endossamento é frequentemente acompanhada por um ou dois certificados digitais:

• Um certificado é produzido pelo fabricante do TPM e é denominado certificado de endossamento. O certificado de endossamento é utilizado para provar a autenticidade do TPM (por exemplo, que é um TPM real fabricado por um fabricante de chips específico) para processos locais, aplicações ou serviços cloud. O certificado de endossamento é criado durante o fabrico ou a primeira vez que o TPM é inicializado através da comunicação com um serviço online.
• O outro certificado é produzido pelo construtor de plataformas e é denominado certificado de plataforma para indicar que um TPM específico está integrado num determinado dispositivo. Para determinados dispositivos que utilizam o TPM baseado em firmware produzido pela Intel ou pela Qualcomm, o certificado de endossamento é criado quando o TPM é inicializado durante o OOBE do Windows.

Observação

O Arranque Seguro protege a plataforma até que o kernel do Windows seja carregado. Em seguida, as proteções como o Arranque Fidedigno, a Integridade do Código hyper-V e a tomada de controlo do ELAM. Um dispositivo que utilize Intel TPM ou Qualcomm TPM obtém um certificado assinado online do fabricante que criou o chip e, em seguida, armazena o certificado assinado no armazenamento TPM. Para que a operação seja bem-sucedida, se estiver a filtrar o acesso à Internet a partir dos seus dispositivos cliente, tem de autorizar os seguintes URLs:

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

Chaves de Identidade do Atestado

Uma vez que o certificado de endossamento é exclusivo para cada dispositivo e não é alterado, a utilização do mesmo pode apresentar preocupações de privacidade porque é teoricamente possível controlar um dispositivo específico. Para evitar este problema de privacidade, o Windows emite uma âncora de atestado derivada com base no certificado de endossamento. Esta chave intermédia, que pode ser atestada para uma chave de endossamento, é a Chave de Identidade do Atestado (AIK) e o certificado correspondente é denominado certificado AIK. Este certificado AIK é emitido por um serviço cloud da Microsoft.

Observação

Antes de o dispositivo poder comunicar o seu estado de funcionamento com as funções de atestado do TPM, tem de ser aprovisionado um certificado AIK em conjunto com um serviço de terceiros, como o serviço de AC da Microsoft Cloud. Depois de aprovisionada, a chave privada do AIK pode ser utilizada para comunicar a configuração da plataforma. O Windows cria uma assinatura sobre o estado de registo da plataforma (e um valor de contador monotónico) em cada arranque com o AIK.

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

O Windows cria AIKs protegidos pelo TPM, se disponíveis, que são chaves de assinatura RSA de 2048 bits. A Microsoft está a alojar um serviço cloud chamado AC da Microsoft Cloud para estabelecer criptograficamente que está a comunicar com um TPM real e que o TPM possui o AIK apresentado. Depois de o serviço de AC da Microsoft Cloud ter estabelecido estes factos, emitirá um certificado AIK para o dispositivo baseado no Windows.

Muitos dispositivos existentes que irão atualizar para o Windows 10 não terão um TPM ou o TPM não conterá um certificado de endossamento. Para acomodar esses dispositivos, o Windows 10 permite a emissão de certificados AIK sem a presença de um certificado de endossamento. Estes certificados AIK não são emitidos pela AC do Microsoft Cloud. Estes certificados não são tão fidedignos como um certificado de endossamento que é queimado no dispositivo durante o fabrico, mas fornecerá compatibilidade para cenários avançados como o Windows Hello para Empresas sem TPM.

No certificado AIK emitido, é adicionado um OID especial para atestar que o certificado de endossamento foi utilizado durante o processo de atestado. Estas informações podem ser utilizadas por uma entidade confiadora para decidir se pretende rejeitar dispositivos que são atestados com certificados AIK sem um certificado de endossamento ou aceitá-los. Outro cenário pode ser não permitir o acesso a recursos de alto valor a partir de dispositivos que são atestados por um certificado AIK que não é apoiado por um certificado de endossamento.

Chave raiz de armazenamento

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

Registos de Configuração da Plataforma

O TPM contém um conjunto de registos concebidos para fornecer uma representação criptográfica do software e estado do sistema que arrancou. Estes registos são denominados Registos de Configuração da Plataforma (PCRs).

A medição da sequência de arranque baseia-se no registo PCR e TCG. Para estabelecer uma raiz estática de fidedignidade, quando o dispositivo está a iniciar, o dispositivo tem de ser capaz de medir o código de firmware antes da execução. Neste caso, a Raiz Principal de Confiança para Medição (CRTM) é executada a partir do arranque, calcula o hash do firmware e, em seguida, armazena-o ao expandir o PCR de registo[0] e transfere a execução para o firmware.

Os PCRs são definidos como zero quando a plataforma é iniciada e é o trabalho do firmware que inicia a plataforma para medir os componentes na cadeia de arranque e registar as medidas nos PCRs. Normalmente, os componentes de arranque assumem o hash do componente seguinte que vai ser executado e registam as medidas nos PCRs. O componente inicial que inicia a cadeia de medição é implicitamente fidedigno. Este componente é o CRTM. Os fabricantes da plataforma têm de ter um processo de atualização seguro para o CRTM ou não permitir atualizações para o mesmo. Os PCRs registam um hash cumulativo dos componentes que foram medidos.

O valor de um PCR por si só é difícil de interpretar (é apenas um valor hash), mas as plataformas normalmente mantêm um registo com detalhes do que foi medido e os PCRs apenas garantem que o registo não foi adulterado. Os registos são referidos como um registo TCG. Sempre que um PCR de registo é expandido, é adicionada uma entrada ao registo TCG. Assim, ao longo do processo de arranque, é criado um rastreio do código executável e dos dados de configuração no registo TCG.

Aprovisionamento do TPM

Para que o TPM de um dispositivo baseado no Windows possa ser utilizável, primeiro tem de ser aprovisionado. O processo de aprovisionamento difere consoante as versões do TPM, mas, quando é bem-sucedido, resulta na utilização do TPM e nos dados de autorização do proprietário (ownerAuth) para o TPM que está a ser armazenado localmente no registo.

Quando o TPM é aprovisionado, o Windows tentará primeiro determinar os valores de EK e ownerAuth armazenados localmente ao procurar no registo na seguinte localização: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

Durante o processo de aprovisionamento, o dispositivo poderá ter de ser reiniciado.

O cmdlet do PowerShell Get-TpmEndorsementKeyInfo pode ser utilizado com privilégios administrativos para obter informações sobre a chave de endossamento e os certificados do TPM.

Se a propriedade do TPM não for conhecida, mas o EK existir, a biblioteca de cliente aprovisionará o TPM e armazenará o valor ownerAuth resultante no registo se a política permitir que armazene a parte pública do SRK na seguinte localização: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub

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

Observação

Para aprovisionar certificados AIK e filtrar o acesso à Internet, tem de autorizar o seguinte URL de caráter universal: https://\*.microsoftaik.azure.net

Windows Health Attestation CSP

O Windows contém um fornecedor de serviços de configuração (CSP) especializado para interagir com a funcionalidade de atestado de estado de funcionamento. Um CSP é um componente que se liga ao cliente MDM do Windows e fornece um protocolo publicado para saber como os servidores MDM podem configurar definições e gerir dispositivos baseados no Windows. O protocolo de gestão é representado como uma estrutura de árvore que pode ser especificada como URIs com funções a executar nos URIs, como "get", "set", "delete", etc.

A lista seguinte é a das funções executadas pelo CSP do Atestado de Estado de Funcionamento do Windows:

• Recolhe dados utilizados para verificar o estado de funcionamento de um dispositivo
• Reencaminha os dados para o Serviço de Atestado de Estado de Funcionamento
• Aprovisiona o Certificado de Atestado de Estado de Funcionamento que recebe do Serviço de Atestado de Estado de Funcionamento
• A pedido, reencaminha o Certificado de Atestado de Estado de Funcionamento (recebido do Serviço de Atestado de Estado de Funcionamento) e as informações de runtime relacionadas para o servidor MDM para verificação

Durante uma sessão de atestado de estado de funcionamento, o CSP do Atestado de Estado de Funcionamento reencaminha os registos do TCG e os valores dos PCRs que são medidos durante o arranque, utilizando um canal de comunicação seguro para o Serviço de Atestado de Estado de Funcionamento.

Quando um servidor MDM valida que um dispositivo foi atestado para o Serviço de Atestado de Estado de Funcionamento, ser-lhe-á fornecido um conjunto de instruções e afirmações sobre como esse dispositivo foi iniciado, com a garantia de que o dispositivo não foi reiniciado entre o momento em que atestava o seu estado de funcionamento e a hora em que o servidor MDM o validou.

Serviço de Atestado de Estado de Funcionamento do Windows

A função do Serviço de Atestado de Estado de Funcionamento do Windows é essencialmente avaliar um conjunto de dados de estado de funcionamento (registo TCG e valores PCR), fazer uma série de deteções (com base nos dados de estado de funcionamento disponíveis) e gerar blob de estado de funcionamento encriptado ou produzir relatórios para servidores MDM.

Observação

Os servidores de dispositivos e MDM têm de ter acesso a has.spserv.microsoft.com através do protocolo TCP na porta 443 (HTTPS).

A verificação de que um atestado TPM e o registo associado são válidos efetua vários passos:

1. Primeiro, o servidor tem de verificar se os relatórios são assinados por AIKs fidedignos. Esta verificação pode ser feita ao verificar se a parte pública do AIK está listada numa base de dados de recursos ou talvez tenha sido verificado um certificado.
2. Após a verificação da chave, o atestado assinado (uma estrutura de cotações) deve ser verificado para ver se é uma assinatura válida sobre os valores de PCR.
3. Em seguida, os registos devem ser verificados para garantir que correspondem aos valores de PCR comunicados.
4. Por fim, os próprios registos devem ser examinados por uma solução mdm para ver se representam configurações de segurança conhecidas ou válidas. Por exemplo, uma verificação simples pode ser ver se os componentes do SO precoce medidos são conhecidos como bons, se o controlador ELAM é o esperado e se o ficheiro de política de controlador ELAM está atualizado. Se todas estas verificações forem efetuadas com êxito, pode ser emitida uma instrução de atestado que pode ser utilizada posteriormente para determinar se o cliente deve ou não ter acesso a um recurso.

O Serviço de Atestado de Estado de Funcionamento fornece as seguintes informações a uma solução mdm sobre o estado de funcionamento do dispositivo:

• Ativação do Arranque Seguro
• Ativação da depuração de kernel e arranque
• Habilitação do BitLocker
• VSM ativado
• Medida da política de Integridade do Código do Device Guard assinada ou não assinada
• ELAM carregado
• Arranque do Modo de Segurança, ativação de DEP, ativação de assinatura de teste
• O TPM do dispositivo foi aprovisionado com um certificado de endossamento fidedigno

Para obter a conclusão das medições, veja Health Attestation CSP (CSP do Atestado de Estado de Funcionamento).

A lista seguinte mostra alguns itens principais que podem ser comunicados de volta à MDM para dispositivos baseados no Windows:

• Medição PCR0
• Arranque Seguro Ativado
• A base de dados de Arranque Seguro corresponde ao Esperado
• O DBX de Arranque Seguro está atualizado
• O GUID da política de Arranque Seguro corresponde ao Esperado
• BitLocker ativado
• Segurança baseada em virtualização ativada
• ELAM foi carregado
• A versão da Integridade do Código está atualizada
• Correspondências esperadas do hash da política de Integridade do Código

Utilizar a MDM e o Serviço de Atestado de Estado de Funcionamento

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

Uma solução que utiliza a MDM e o Serviço de Atestado de Estado de Funcionamento consiste em três partes principais:

1. Um dispositivo com o atestado de estado de funcionamento ativado. Esta ativação será feita como parte da inscrição com um fornecedor de MDM (o atestado de estado de funcionamento será desativado por predefinição).

2. Depois de ativar este serviço e de cada arranque posteriormente, o dispositivo enviará medidas de estado de funcionamento para o Serviço de Atestado de Estado de Funcionamento alojado pela Microsoft e receberá um blob de atestado de estado de funcionamento em troca.

3. A qualquer momento após este ciclo, um servidor MDM pode pedir o blob de atestado de estado de funcionamento do dispositivo e pedir ao Serviço de Atestado de Estado de Funcionamento para desencriptar o conteúdo e validar que foi atestado.

   

A interação entre um dispositivo baseado no Windows, o Serviço de Atestado de Estado de Funcionamento e a MDM pode ser realizada da seguinte forma:

1. O cliente inicia uma sessão com o servidor MDM. O URI do servidor MDM faria parte da aplicação cliente que inicia o pedido. Neste momento, o servidor MDM pode pedir os dados do atestado de estado de funcionamento com o URI CSP adequado.

2. O servidor MDM especifica um nonce juntamente com o pedido.

3. Em seguida, o cliente envia o AIK quoted nonce + o contador de arranque e as informações do blob de estado de funcionamento. Este blob de estado de funcionamento é encriptado com uma chave pública do Serviço de Atestado de Estado de Funcionamento que apenas o Serviço de Atestado de Estado de Funcionamento pode desencriptar.

4. O servidor MDM:

   1. Verifica se o nonce é o esperado.
   2. Transmite os dados citados, o nonce e o blob de estado de funcionamento encriptado para o servidor do Serviço de Atestado de Estado de Funcionamento.

5. O Serviço de Atestado de Estado de Funcionamento:

   1. Desencripta o blob de estado de funcionamento.
   2. Verifica se o contador de arranque na aspa está correto ao utilizar o AIK no blob de estado de funcionamento e corresponde ao valor no blob de estado de funcionamento.
   3. Verifica se o nonce corresponde à cotação e à que é transmitida da MDM.
   4. Uma vez que o contador de arranque e o nonce são citados com o AIK do blob de estado de funcionamento, também prova que o dispositivo é o mesmo para o qual o blob de estado de funcionamento foi gerado.
   5. Envia dados de volta para o servidor MDM, incluindo parâmetros de estado de funcionamento, atualização, etc.

Observação

O servidor MDM (entidade confiadora) nunca efetua a própria validação da proposta ou do contador de arranque. Obtém os dados citados e o blob de estado de funcionamento (que é encriptado) e envia os dados para o Serviço de Atestado de Estado de Funcionamento para validação. Desta forma, o AIK nunca é visível para a MDM, o que, assim, aborda questões de privacidade.

Definir os requisitos de conformidade do dispositivo é o primeiro passo para garantir que os dispositivos registados que não cumprem os requisitos de estado de funcionamento e conformidade são detetados, controlados e têm ações impostas pela solução mdm.

Os dispositivos que tentam ligar-se aos recursos têm de ter o respetivo estado de funcionamento avaliado para que os dispositivos em mau estado de funcionamento e não conformes possam ser detetados e comunicados. Para ser totalmente eficiente, uma solução de segurança ponto a ponto tem de impor uma consequência para dispositivos em mau estado de funcionamento, como recusar o acesso a ativos de alto valor. Essa consequência para um dispositivo em mau estado de funcionamento é a finalidade do controlo de acesso condicional, que é detalhado na secção seguinte.

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

A tecnologia de controlo de acesso atual, na maioria dos casos, concentra-se em garantir que as pessoas certas tenham acesso aos recursos certos. Se os utilizadores conseguirem autenticar-se, obterão acesso aos recursos através de um dispositivo que a equipa de TI e os sistemas da organização pouco conhecem. Talvez haja alguma verificação, como garantir que um dispositivo é encriptado antes de dar acesso ao e-mail, mas e se o dispositivo estiver infetado com software maligno?

O processo de atestado de estado de funcionamento do dispositivo remoto utiliza dados de arranque medidos para verificar o estado de funcionamento do dispositivo. Em seguida, o estado de funcionamento do dispositivo está disponível para uma solução mdm como o Intune.

Observação

Para obter as informações mais recentes sobre o suporte de funcionalidades do Intune e do Windows, consulte Novidades no Microsoft Intune.

A figura abaixo mostra como o Serviço de Atestado de Estado de Funcionamento deverá funcionar com o serviço MDM do Intune baseado na cloud da Microsoft.

Uma solução MDM pode, em seguida, utilizar instruções de estado de funcionamento e levá-las para o nível seguinte ao acoplar com políticas de cliente que permitirão que o acesso condicional seja concedido com base na capacidade do dispositivo de provar que é gratuito para software maligno, o sistema antimalware está funcional e atualizado, a firewall está em execução e o estado de patch de dispositivos está em conformidade.

Por fim, os recursos podem ser protegidos ao negar o acesso a pontos finais que não conseguem provar que estão em bom estado de funcionamento. Esta funcionalidade é muito necessária para dispositivos BYOD que precisam de aceder a recursos organizacionais.

Suporte incorporado da MDM no Windows

O Windows tem um cliente MDM que é fornecido como parte do sistema operativo. Este cliente MDM permite que os servidores MDM giram dispositivos baseados no Windows sem que seja necessário um agente separado.

Suporte de servidor MDM não Microsoft

Os servidores MDM que não sejam da Microsoft podem gerir o Windows através do protocolo MDM. O cliente de gestão incorporado consegue comunicar com um servidor compatível que suporta o protocolo OMA-DM para realizar tarefas de gestão empresarial. Para obter mais informações, veja Microsoft Entra integration with MDM (Integração do Microsoft Entra com a MDM).

Observação

Os servidores MDM não precisam de criar ou transferir um cliente para gerir o Windows. Para obter mais informações, consulte Gestão de dispositivos móveis.

O servidor MDM de terceiros terá a mesma experiência de utilizador original consistente para inscrição, o que também proporciona simplicidade aos utilizadores do Windows.

Gestão do Windows Defender por MDM de terceiros

Esta infraestrutura de gestão permite que os profissionais de TI utilizem produtos compatíveis com MDM, como o Intune, para gerir o atestado de estado de funcionamento, o Device Guard ou o Windows Defender em dispositivos baseados no Windows, incluindo BYODs que não estão associados a um domínio. Os profissionais de TI poderão gerir e configurar todas as ações e definições que estão familiarizados com a personalização através do Intune com o Intune Endpoint Protection em sistemas operativos de nível inferior. Atualmente, os administradores que gerem apenas dispositivos associados a um domínio através da Política de Grupo irão achar fácil fazer a transição para gerir dispositivos baseados no Windows através da MDM, uma vez que muitas das definições e ações são partilhadas em ambos os mecanismos.

Para obter mais informações sobre como gerir as definições de segurança e sistema do Windows com uma solução de MDM, veja Definições personalizadas de URI para dispositivos Windows.

Controlo de acesso condicional

Na maioria das plataformas, o registo de dispositivos do Microsoft Entra ocorre automaticamente durante a inscrição. Os estados do dispositivo são escritos pela solução MDM no Microsoft Entra ID e, em seguida, lidos pelo Office 365 (ou por qualquer aplicação autorizada do Windows que interage com o Microsoft Entra ID) da próxima vez que o cliente tentar aceder a uma carga de trabalho compatível com o Office 365.

Se o dispositivo não estiver registado, o utilizador receberá uma mensagem com instruções sobre como se registar (também conhecido como inscrição). Se o dispositivo não estiver em conformidade, o utilizador receberá uma mensagem diferente que os redireciona para o portal Web da MDM, onde pode obter mais informações sobre o problema de conformidade e como resolvê-lo.

O Microsoft Entra ID autentica o utilizador e o dispositivo, a MDM gere as políticas de conformidade e acesso condicional e o Serviço de Atestado de Estado de Funcionamento comunica o estado de funcionamento do dispositivo de forma atestada.

Controlo de acesso condicional do Office 365

O Microsoft Entra ID impõe políticas de acesso condicional para proteger o acesso aos serviços do Office 365. Um administrador de inquilinos pode criar uma política de acesso condicional que bloqueia o acesso de um utilizador num dispositivo não conforme a um serviço do Office 365. O utilizador tem de estar em conformidade com as políticas de dispositivos da empresa antes de poder conceder acesso ao serviço. Em alternativa, o administrador também pode criar uma política que exige que os utilizadores apenas inscrevam os respetivos dispositivos para obter acesso a um serviço do Office 365. As políticas podem ser aplicadas a todos os utilizadores de uma organização ou limitadas a alguns grupos de destino e melhoradas ao longo do tempo para incluir mais grupos de destino.

Quando um utilizador pede acesso a um serviço do Office 365 a partir de uma plataforma de dispositivos suportada, o Microsoft Entra autentica o utilizador e o dispositivo a partir do qual o utilizador inicia o pedido; e concede acesso ao serviço apenas quando o utilizador está em conformidade com o conjunto de políticas do serviço. Os utilizadores que não tenham o respetivo dispositivo inscrito recebem instruções de remediação sobre como se inscrever e tornar-se conformes para aceder aos serviços empresariais do Office 365.

Quando um utilizador se inscreve, o dispositivo é registado no Microsoft Entra ID e inscrito numa solução de MDM compatível, como o Intune.

Observação

A Microsoft está a trabalhar com ISVs de MDM de terceiros para suportar a inscrição automatizada de MDM e verificações de acesso baseadas em políticas. Os passos para ativar a inscrição de MDM automática com o Microsoft Entra ID e o Intune são explicados na mensagem de blogue Windows, Microsoft Entra ID e Microsoft Intune: Inscrição MDM Automática Com Tecnologia da Cloud! .

Quando um utilizador inscreve um dispositivo com êxito, o dispositivo torna-se fidedigno. O Microsoft Entra ID fornece início de sessão único para aceder às aplicações da empresa e impõe a política de acesso condicional para conceder acesso a um serviço não só na primeira vez que o utilizador pede acesso, mas sempre que o utilizador pedir para renovar o acesso.

Será negado ao utilizador o acesso aos serviços quando as credenciais de início de sessão forem alteradas, um dispositivo for perdido/roubado ou a política de conformidade não for cumprida no momento do pedido de renovação.

Dependendo do tipo de aplicação de e-mail que os funcionários utilizam para aceder ao Exchange online, o caminho para estabelecer o acesso seguro ao e-mail pode ser ligeiramente 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 utilizador final também são semelhantes.

Os clientes que tentarem aceder ao Office 365 serão avaliados relativamente às seguintes propriedades:

• O dispositivo é gerido por uma MDM?
• O dispositivo está registado com o Microsoft Entra ID?
• O dispositivo está em conformidade?

Para chegar a um estado de conformidade, o dispositivo baseado no Windows tem de:

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

Observação

Atualmente, as políticas de acesso condicional são aplicadas seletivamente aos utilizadores em dispositivos iOS e Android. Para obter mais informações, consulte a mensagem de blogue Microsoft Entra ID, Microsoft Intune e Windows – Utilizar a cloud para modernizar a mobilidade empresarial !.

Controlo de acesso condicional de aplicações na cloud e no local

O controlo de acesso condicional é um poderoso motor de avaliação de políticas incorporado no Microsoft Entra ID. Proporciona aos profissionais de TI uma forma fácil de criar regras de acesso para além do Office 365 que avaliam o contexto do início de sessão de um utilizador para tomarem decisões em tempo real sobre as aplicações a que devem ser autorizados a aceder.

Os profissionais de TI podem configurar políticas de controlo de acesso condicional para aplicações SaaS na cloud protegidas pelo Microsoft Entra ID e até mesmo aplicações no local. As regras de acesso no Microsoft Entra ID utilizam o motor de acesso condicional para verificar o estado de funcionamento e conformidade do dispositivo comunicados por uma solução de MDM compatível, como o Intune, para determinar se deve permitir o acesso.

Para obter mais informações sobre o acesso condicional, veja Pré-visualização do Acesso Condicional do Azure para Aplicações SaaS.

Observação

O controlo de acesso condicional é uma funcionalidade do Microsoft Entra ID P1 ou P2 que também está disponível com o EMS. Se não tiver uma subscrição do Microsoft Entra ID P1 ou P2, pode obter uma avaliação a partir do site do Microsoft Azure .

Para aplicações no local, existem duas opções para ativar o controlo de acesso condicional com base no estado de conformidade de um dispositivo:

• Para aplicações no local publicadas através do proxy de aplicações do Microsoft Entra, pode configurar políticas de controlo de acesso condicional como faria para aplicações na cloud. Para obter mais informações, veja Utilizar o proxy de aplicações do Microsoft Entra para publicar aplicações no local para utilizadores remotos.
• Além disso, o Microsoft Entra Connect sincronizará as informações de conformidade do dispositivo do Microsoft Entra ID com o AD no local. O ADFS no Windows Server 2016 suportará o controlo de acesso condicional com base no estado de conformidade de um dispositivo. Os profissionais de TI irão configurar políticas de controlo de acesso condicional no ADFS que utilizam o estado de conformidade do dispositivo comunicado por uma solução mdm compatível para proteger aplicações no local.

O seguinte processo descreve como funciona o Acesso Condicional do Microsoft Entra:

1. O utilizador já se inscreveu na MDM através do Acesso à Área de Trabalho/associação ao Azure AD, que regista o dispositivo com o Microsoft Entra ID.
2. Quando o dispositivo arranca ou retoma a partir da hibernação, é acionada uma tarefa "Tpm-HASCertRetr" para pedir em segundo plano um blob de atestado de estado de funcionamento. O dispositivo envia as medições de arranque do TPM para o Serviço de Atestado de Estado de Funcionamento.
3. O Serviço de Atestado de Estado de Funcionamento valida o estado do dispositivo e emite um blob encriptado para o dispositivo com base no estado de funcionamento com detalhes sobre verificações falhadas (se existirem).
4. O utilizador inicia sessão e o agente MDM contacta o servidor Intune/MDM.
5. O servidor MDM envia novas políticas se disponíveis e consulta o estado de funcionamento do blob e outro estado de inventário.
6. O dispositivo envia um blob de atestado de estado de funcionamento anteriormente adquirido e também o valor do outro inventário de estado pedido pelo servidor Intune/MDM.
7. O servidor Intune/MDM envia o blob de atestado de estado de funcionamento para o Serviço de Atestado de Estado de Funcionamento para ser validado.
8. O Serviço de Atestado de Estado de Funcionamento valida que o dispositivo que enviou o blob de atestado de estado de funcionamento está em bom estado de funcionamento e devolve este resultado ao servidor Intune/MDM.
9. O servidor Intune/MDM avalia a compatibilidade com base na conformidade e no estado de atestado de estado de funcionamento/inventário consultado do dispositivo.
10. O servidor Intune/MDM atualiza o estado de conformidade em relação ao objeto de dispositivo no Microsoft Entra ID.
11. O utilizador abre a aplicação e tenta aceder a um recurso gerido pela empresa.
12. Acesso fechado por afirmação de conformidade no ID do Microsoft Entra.
13. Se o dispositivo estiver em conformidade e o utilizador estiver autorizado, será gerado um token de acesso.
14. O utilizador pode aceder ao recurso gerido pela empresa.

Para obter mais informações sobre a associação ao Microsoft Entra, consulte Microsoft Entra ID & Windows: Better Together for Work or School, um documento técnico.

O controlo de acesso condicional é um tópico que muitas organizações e profissionais de TI podem não saber e devem saber. Os diferentes atributos que descrevem um utilizador, um dispositivo, a conformidade e o contexto de acesso são poderosos quando utilizados com um motor de acesso condicional. O controlo de acesso condicional é um passo essencial que ajuda as organizações a proteger o seu ambiente.

Takeaways e resumo

A lista seguinte contém conclusões importantes de alto nível para melhorar a postura de segurança de qualquer organização. No entanto, as poucas conclusões apresentadas nesta secção não devem ser interpretadas como uma lista exaustiva das melhores práticas de segurança.

• Compreender que nenhuma solução é 100% segura

  Se determinados adversários com intenções maliciosas obtiverem acesso físico ao dispositivo, poderão eventualmente interromper as camadas de segurança e controlá-lo.

• Utilizar o atestado de estado de funcionamento com uma solução de MDM

  Os dispositivos que tentam ligar a recursos de alto valor têm de ter o seu estado de funcionamento avaliado para que os dispositivos em mau estado de funcionamento e não conformes possam ser detetados, comunicados e eventualmente bloqueados.

• Utilizar o Credential Guard

  O Credential Guard é uma funcionalidade que ajuda muito a proteger as credenciais de domínio empresarial contra ataques pass-the-hash.

• Usar o Device Guard

  O Device Guard é um avanço real na segurança e uma forma eficaz de ajudar a proteger contra software maligno. A funcionalidade Device Guard no Windows bloqueia aplicações não fidedignos (aplicações não autorizadas pela sua organização).

• Assinar política do Device Guard

  A política de Device Guard assinada ajuda a proteger contra um utilizador com privilégios de administrador que tenta derrotar a política atual. Quando uma política é assinada, a única forma de modificar o Device Guard mais tarde é fornecer uma nova versão da política assinada pelo mesmo signatário ou a partir de um signatário especificar como parte da política do Device Guard.

• Utilizar a segurança baseada em virtualização

  Quando tem a Integridade do Código do Modo Kernel protegida pela segurança baseada em Virtualização, as regras de integridade do código continuam a ser impostas mesmo que uma vulnerabilidade permita o acesso não autorizado à memória do modo kernel. Tenha em atenção que os dispositivos Device Guard que executam a Integridade do Código Kernel com segurança baseada em Virtualização têm de ter controladores compatíveis.

• Começar a implementar o Device Guard com o modo auditoria

  Implemente a política device guard em computadores e dispositivos visados no modo de Auditoria. Monitorize o registo de eventos da Integridade do Código que indica que um programa ou um controlador teria sido bloqueado se o Device Guard estivesse configurado no modo de Imposição. Ajuste as regras do Device Guard até que seja atingido um elevado nível de confiança. Após a conclusão da fase de teste, a política do Device Guard pode ser mudada para o Modo de imposição.

• Criar um computador de referência isolado ao implementar o Device Guard

  Uma vez que a rede empresarial pode conter software maligno, deve começar a configurar um ambiente de referência isolado da sua rede empresarial principal. Depois disso, pode criar uma política de integridade de código que inclua as aplicações fidedignas que pretende executar nos seus dispositivos protegidos.

• Utilizar o AppLocker quando fizer sentido

  Embora o AppLocker não seja considerado uma nova funcionalidade do Device Guard, complementa a funcionalidade Device Guard para alguns cenários, como poder negar uma aplicação Universal do Windows específica para um utilizador específico ou um grupo de utilizadores.

• Bloquear o firmware e a configuração

  Após a instalação do Windows, bloqueie o acesso às opções de arranque de firmware. Este bloqueio impede que um utilizador com acesso físico modifique as definições de UEFI, desative o Arranque Seguro ou arranque de outros sistemas operativos. Além disso, para proteger contra um administrador que tenta desativar o Device Guard, adicione uma regra na política do Device Guard atual que irá negar e bloquear a execução da ferramenta C:\Windows\System32\SecConfig.efi .

O atestado de estado de funcionamento é uma funcionalidade fundamental do Windows que inclui componentes de cliente e cloud para controlar o acesso a ativos de alto valor com base num utilizador e a identidade e conformidade do respetivo dispositivo com a política de governação empresarial. As organizações podem optar por detetar e comunicar dispositivos em mau estado de funcionamento ou configurar regras de imposição de estado de funcionamento com base nas suas necessidades. O atestado de estado de funcionamento fornece um modelo de segurança ponto a ponto e pontos de integração, que os fornecedores e programadores de software podem utilizar para criar e integrar uma solução personalizada.

Artigos relacionados

• Proteger as credenciais de domínio derivadas com o Credential Guard
• Guia de implementação do Device Guard
• Descrição geral da tecnologia trusted Platform Module