Controlar a integridade dos dispositivos baseados em Windows 10

Aplicável ao

• Windows 10

Este artigo detalha uma solução de ponta a ponta que ajuda você a proteger ativos de alto valor impondo, controlando e relatando a integridade de dispositivos baseados em Windows 10 dados.

Introdução

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

Os usuários querem ter a melhor experiência de produtividade ao acessar aplicativos corporativos e trabalhar em dados da organização de seus dispositivos. Isso significa que eles não tolerarão ser solicitados a inserir suas credenciais de trabalho sempre que acessarem um aplicativo ou um servidor de arquivos. De uma perspectiva de segurança, isso também significa que os usuários manipularão credenciais corporativas e dados corporativos em dispositivos não gerenciados.

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

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

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

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

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

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

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

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

Os invasores são alvos de indivíduos, não especificamente por causa de quem são, mas por causa de quem trabalham. Um dispositivo infectado trará malware para uma organização, mesmo que a organização tenha protegido o perímetro das redes ou tenha investido em sua postura defensiva. Uma estratégia defensiva não é suficiente contra essas ameaças.

Uma abordagem diferente

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

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

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

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

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

Windows dispositivos podem ser protegidos contra rootkits e bootkits de baixo nível usando tecnologias de hardware de baixo nível, como a Inicialização Segura da UEFI (Unified Extensible Firmware Interface).

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

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

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

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

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

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

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

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

Investimentos em segurança da Microsoft em Windows 10

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

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

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

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

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

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

Proteger dispositivos e credenciais corporativas contra ameaças

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

Windows 10 de segurança baseadas em hardware

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

Windows 10 oferece suporte a recursos para ajudar a impedir que malware sofisticado de baixo nível, como rootkits e bootkits, seja carregado durante o processo de inicialização:

• Trusted Platform Module. Um TPM (Trusted Platform Module) é um componente de hardware que fornece recursos de segurança exclusivos.

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

  Um TPM implementa controles que atendem à especificação descrita pelo TCG (Trusted Computing Group). No momento da redação deste artigo, há duas versões da especificação do TPM produzidas pelo TCG que não são compatíveis entre si:

  • A primeira especificação do TPM, versão 1.2, foi publicada em fevereiro de 2005 pelo TCG e padronizada no padrão ISO/IEC 11889.
  • A especificação mais recente do TPM, conhecida como TPM 2.0, foi lançada em abril de 2014 e foi aprovada pelo JTC (Joint Technical Committee) da ISO/IEC como ISO/IEC 11889:2015.

  Windows 10 usa o TPM para cálculos criptográficos como parte do atestado de integridade e para proteger as chaves do BitLocker, Windows Hello, cartões inteligentes virtuais e outros certificados de chave pública. Para obter mais informações, consulte os requisitos do TPM Windows 10.

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

  O TPM 2.0 fornece uma revisão importante para os recursos no TPM 1.2:

  • Atualizar a força da criptografia para atender às necessidades de segurança modernas

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

  • Flexibilidade de algoritmos criptográficos para dar suporte às necessidades do governo

    • O TPM 1.2 é severamente restrito em termos de quais algoritmos ele pode dar suporte
    • O TPM 2.0 pode dar suporte a algoritmos arbitrários com atualizações secundárias para os documentos de especificação do TCG

  • Consistência entre implementações

    • A especificação do TPM 1.2 permite que os fornecedores de latitude ampla ao escolher os detalhes da implementação
    • O TPM 2.0 padroniza grande parte desse comportamento

• Inicialização Segura. Dispositivos com firmware UEFI podem ser configurados para carregar apenas carregadores de inicialização confiáveis do sistema operacional. A Inicialização Segura não requer um TPM.

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

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

  Observação

  A Inicialização Segura protege a plataforma até que Windows kernel seja carregado. Em seguida, proteções como ELAM assumirão o controle.

• Política de configuração de Inicialização Segura. Estende a funcionalidade de Inicialização Segura para uma configuração Windows 10 crítica.

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

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

  O carregador de inicialização verifica a assinatura digital do kernel do Windows 10 antes de carregá-lo. O Windows 10 kernel, por sua vez, verifica todos os outros componentes do processo de inicialização do Windows, incluindo os drivers de inicialização, os arquivos de inicialização e o componente ELAM. Essa etapa é importante e protege o restante do processo de inicialização verificando se todos os Windows de inicialização têm integridade e podem ser confiáveis.

• Antimalware de Início Antecipado (ELAM). O ELAM testa todos os drivers antes que eles sejam carregados e impede que drivers não aprovados sejam carregados.

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

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

  Observação

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

  O driver assinado do ELAM é carregado antes de qualquer outro aplicativo ou drivers de terceiros, o que permite que o software antimalware detecte e bloqueie quaisquer tentativas de adulteração no processo de inicialização tentando carregar código não assinado ou não confiável.

  O driver ELAM é um driver pequeno com um pequeno banco de dados de política que tem um escopo muito estreito, focado em drivers que são carregados no início da inicialização do sistema. O banco de dados de política é armazenado em um hive do Registro que também é medido para o TPM, para registrar os parâmetros operacionais do driver ELAM. Um driver ELAM deve ser assinado pela Microsoft e o certificado associado deve conter o EKU complementar (1.3.6.1.4.1.311.61.4.1).

• Segurança baseada em virtualização (Hyper-V + Kernel Seguro). A segurança baseada em virtualização é um limite de segurança imposto completamente novo que permite proteger partes críticas de Windows 10.

  A segurança baseada em virtualização isola o código confidencial, como Integridade do Código do Modo Kernel ou credenciais confidenciais de domínio corporativo do restante do Windows operacional. Para obter mais informações, consulte a seção de segurança baseada em virtualização .

• HVCI (integridade de código protegida por hipervisor). A Integridade de Código protegida por hipervisor é um recurso do Device Guard que garante que somente drivers, executáveis e DLLs que estejam em conformidade com a política de integridade de código do Device Guard têm permissão para execução.

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

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

  Observação

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

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

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

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

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

• Atestado de integridade. O firmware do dispositivo registra em logs o processo de inicialização e Windows 10 pode enviá-lo para um servidor confiável que pode verificar e avaliar a integridade do dispositivo.

  Windows 10 usa medidas do firmware UEFI e cada um dos componentes Windows e antimalware é feito conforme eles são carregados durante o processo de inicialização. Além disso, elas são tomadas e medidas sequencialmente, não todas de uma só vez. Quando essas medidas são concluídas, seus valores são assinados digitalmente e armazenados com segurança no TPM e não podem ser alterados, a menos que o sistema seja redefinido.

  Para obter mais informações, consulte Inicialização segura e inicialização medida: proteção de componentes de inicialização antecipada contra malware.

  Durante cada inicialização subsequente, os mesmos componentes são medidos, o que permite a comparação das medidas em relação a 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 executar a comparação. Esse processo, chamado de atestado de integridade do dispositivo remoto, permite que o servidor verifique o status de integridade do Windows dispositivo.

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

Segurança baseada em virtualização

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

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

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

• Credential Guard (isolamento de credencial LSA): impede ataques de passagem de hash e roubo de credenciais corporativas que ocorre lendo e despejando o conteúdo da memória lsass
• Device Guard (integridade de código do Hyper-V): o Device Guard usa a nova segurança baseada em virtualização no Windows 10 para isolar o serviço de Integridade de Código do próprio kernel do Windows, que permite ao serviço usar assinaturas definidas pela política controlada pela empresa para ajudar a determinar o que é confiável. Na verdade, o serviço de Integridade de Código é executado junto com o kernel Windows contêiner protegido por hipervisor.
• Outros serviços isolados: por exemplo, no Windows Server 2016, há o recurso vTPM que permite que você tenha VMs (máquinas virtuais) criptografadas em servidores.

Observação

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

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

Credential Guard

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

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

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

Device Guard

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

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

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

Observação

Independentemente da ativação da Política do Device Guard, Windows 10 por padrão eleva a barra do que é executado no kernel. Windows 10 drivers devem ser assinados pela Microsoft e, mais especificamente, pelo portal WHQL (Windows Hardware Quality Labs). Além disso, a partir de outubro de 2015, o portal WHQL aceitará apenas envios de driver, incluindo envios de driver de kernel e de usuário, que têm um Certificado de Assinatura de Código válido de Validação Estendida ("EV").

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

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

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

No momento da redação deste artigo, e de acordo com a pesquisa mais recente da Microsoft, mais de 90% do malware não foi assinado completamente. Portanto, implementar uma política básica do Device Guard pode ajudar a bloquear malware de forma simples e eficaz. Na verdade, o Device Guard tem o potencial de ir além e também pode ajudar a bloquear malware assinado.

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

Há três partes diferentes que compõem a solução device guard em Windows 10:

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

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

Cenários do Device Guard

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

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

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

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

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

Pode ser um desafio usar o Device Guard em estações de trabalho corporativas e pouco gerenciadas em que o usuário normalmente tem permissão para instalar o software por conta própria. Quando uma organização oferece 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 log de eventos conterá um registro de todos os binários que violaram a política do Device Guard. Quando o Device Guard é usado no modo de auditoria, as organizações podem obter dados avançados sobre drivers e aplicativos que os usuários instalam e executam.

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

Observação

A política do Device Guard pode ser conectada Windows 10, o que adiciona proteção adicional contra usuários administrativos alterando ou removendo essa política.

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

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

A importância de assinar aplicativos

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

Com Windows 10, as organizações disponibilizam aplicativos de linha de negócios (LOB) para membros da organização por meio da infraestrutura Microsoft Store cliente. Mais especificamente, os aplicativos LOB estarão disponíveis em um repositório particular dentro do Microsoft Store. Microsoft Store assina e distribui aplicativos Windows Universal e aplicativos Windows clássicos. Todos os aplicativos baixados do Microsoft Store são assinados.

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

Windows 10 inclui ferramentas que permitem que os profissionais de TI pegue aplicativos que já foram empacotados e execute-os por meio de um processo para criar assinaturas adicionais que podem ser distribuídas junto com aplicativos existentes.

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

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

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

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

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

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

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

Atestado de integridade de dispositivo

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

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

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

Requisitos de hardware

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

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

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

Detectar um dispositivo Windows 10 não íntegro

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

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

Conforme discutido anteriormente, o recurso de atestado de integridade do Windows 10 usa o componente de hardware do TPM para registrar com segurança uma medida de cada componente relacionado à inicialização, incluindo firmware, kernel Windows 10 e até mesmo drivers de inicialização antecipados. Como o atestado de integridade aproveita os recursos de segurança baseados em hardware do TPM, o log de todos os componentes medidos de inicialização permanece fora do alcance de qualquer malware.

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

Qual é o conceito de integridade do dispositivo?

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

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

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

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

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

Atestado de integridade do dispositivo remoto

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

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

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

Observação

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

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

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

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

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

O atestado de integridade registra as medidas em vários PCRs (Registros de Configuração da Plataforma TPM) e logs de TCG durante o processo de inicialização.

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

O processo de atestado de integridade funciona da seguinte maneira:

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

Observação

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

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

1. O cliente (um Windows 10 baseado em Windows 10 com TPM) inicia a solicitação com o serviço de atestado de integridade do dispositivo remoto. Como o servidor de atestado de integridade deve ser um serviço de nuvem da Microsoft, o URI já está pré-provisionado no cliente.

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

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

   1. Verifica se o certificado AIK é emitido por uma AC conhecida e confiável e o certificado é válido e não revogado.
   2. Verifica se a assinatura nas aspas PCR está correta e consistente com o valor de log do TCG.
   3. Analisa as propriedades no log do TCG.
   4. Emite o token de integridade do dispositivo que contém as informações de integridade, as informações do AIK e as informações do contador de inicialização. O token de integridade também contém o tempo de emissão válido. O token de integridade do dispositivo é criptografado e assinado, o que significa que as informações estão protegidas e só podem ser acessadas para emitir o serviço de atestado de integridade.

4. O cliente armazena o blob criptografado de integridade em seu repositório local. O token de integridade do dispositivo contém o status de integridade do dispositivo, uma ID do dispositivo (o Windows AIK) e o contador de inicialização.

Componentes de atestado de integridade do dispositivo

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

Trusted Platform Module

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

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

Um TPM incorpora em um único componente:

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

Chave de endosso

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

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

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

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

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

Observação

A Inicialização Segura protege a plataforma até que Windows kernel seja carregado. Em seguida, proteções como Inicialização Confiável, Integridade de Código do Hyper-V e ELAM assumirão o controle. Um dispositivo que usa 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 do TPM. Para que a operação seja bem-sucedida, se você estiver filtrando o acesso à Internet de seus dispositivos cliente, deverá autorizar as seguintes URLs:

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

Chaves de identidade de atestado

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

Observação

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

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

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

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

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

Armazenamento raiz

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

Registros de configuração de plataforma

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

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

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

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

Provisionamento do TPM

Para que o TPM de um Windows 10 baseado em Windows 10 seja utilizável, ele deve primeiro ser provisionado. O processo de provisionamento difere um pouco com base nas versões do TPM, mas, quando bem-sucedido, ele faz com que o TPM seja utilizável e os dados de autorização do proprietário (ownerAuth) para o TPM sejam armazenados localmente no Registro.

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

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

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

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

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

Observação

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

CSP de Atestado de Integridade do Windows 10

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

A seguir está uma lista de funções executadas pelo CSP Windows 10 Health Attestation:

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

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

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

Windows de Atestado de Integridade do Windows

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

Observação

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

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

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

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

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

Para obter a integridade das medidas, consulte CSP de Atestado de Integridade.

A tabela a seguir apresenta alguns itens-chave que podem ser relatados de volta ao MDM, dependendo do tipo de Windows 10 baseado em dispositivo.

Tipo de sistema operacional

Itens de chave que podem ser relatados

Windows 10 para edições da área de trabalho

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

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

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

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

1. Um dispositivo com atestado de integridade habilitado. Isso geralmente será feito como parte do registro com um provedor de MDM (o atestado de integridade será desabilitado por padrão).

2. Depois que isso estiver habilitado e cada inicialização depois disso, o dispositivo enviará medidas de integridade para o Serviço de Atestado de Integridade hospedado pela Microsoft e receberá um blob de atestado de integridade em troca.

3. A qualquer momento depois disso, um servidor MDM pode solicitar o blob de atestado de integridade do dispositivo e pedir ao Serviço de Atestado de Integridade para descriptografar o conteúdo e validar se ele foi atestado.

   

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

1. O cliente inicia uma sessão com o servidor MDM. O URI do servidor MDM faria parte do aplicativo cliente que inicia a solicitação. No momento, o servidor MDM pode solicitar os dados de atestado de integridade usando o URI do CSP apropriado.

2. O servidor MDM especifica um nonce junto com a solicitação.

3. Em seguida, o cliente envia o nonce entre aspas do AIK + o contador de inicialização e as informações do blob de integridade. Esse blob de integridade é criptografado com uma chave pública do Serviço de Atestado de Integridade que somente o Serviço de Atestado de Integridade pode descriptografar.

4. O servidor MDM:

   1. Verifica se o nonce é o esperado.
   2. Passa os dados entre aspas, o nonce e o blob de integridade criptografado para o servidor do Serviço de Atestado de Integridade.

5. O Serviço de Atestado de Integridade:

   1. Descriptografa o blob de integridade.
   2. Verifica se o contador de inicialização na cotação está correto usando o AIK no blob de integridade e corresponde ao valor no blob de integridade.
   3. Verifica se o nonce corresponde à cotação e à que é passada do MDM.
   4. Como o contador de inicialização e o nonce são citados com o AIK do blob de integridade, ele também prova que o dispositivo é o mesmo para o qual o blob de integridade foi gerado.
   5. Envia dados de volta para o servidor MDM, incluindo parâmetros de integridade, atualização e assim por diante.

Observação

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

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

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

Controlar a segurança de um Windows 10 baseado em dispositivos antes que o acesso seja concedido

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

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

Observação

Para obter as informações mais recentes sobre Intune e Windows 10 suporte a recursos do Microsoft Intune, confira o blog do Microsoft Intune e as novidades do Microsoft Intune.

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

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

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

Suporte interno do MDM no Windows 10

Windows 10 tem um cliente MDM que é fornecido como parte do sistema operacional. Isso permite que os servidores MDM gerenciem Windows 10 dispositivos baseados em Windows 10 sem a necessidade de um agente separado.

Suporte a servidor MDM de terceiros

Servidores MDM de terceiros podem gerenciar Windows 10 usando o protocolo MDM. O cliente de gerenciamento interno é capaz de se comunicar com um servidor compatível que dá suporte ao protocolo OMA-DM para executar tarefas de gerenciamento corporativo. Para obter informações adicionais, consulte Azure Active Directory integração com o MDM.

Observação

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

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

Gerenciamento de Windows Defender por MDM de terceiros

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

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

Controle de acesso condicional

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

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

Azure AD autentica o usuário e o dispositivo, o MDM gerencia as políticas de conformidade e acesso condicional e o Serviço de Atestado de Integridade relata **** sobre a integridade do dispositivo de maneira atestado.

Office 365 controle de acesso condicional

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

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

Quando um usuário se registra, o dispositivo é registrado no Azure AD e registrado com uma solução de MDM compatível, como Intune.

Observação

A Microsoft está trabalhando com ISVs de MDM de terceiros para dar suporte a verificações automatizadas de acesso baseado em políticas e registro de MDM. As etapas para ativar o registro de MDM automático com Azure AD e Intune são explicadas no Windows 10, no Azure AD e no Microsoft Intune: Registro automático de MDM alimentado pela nuvem! Blog.

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

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

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

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

• O dispositivo é gerenciado por um MDM?
• O dispositivo está registrado com Azure AD?
• O dispositivo está em conformidade?

Para chegar a um estado compatível, o Windows 10 baseado em Windows 10 precisa:

• Registre-se com uma solução de MDM.
• Registre-se Azure AD.
• Estar em conformidade com as políticas de dispositivo definidas pela solução MDM.

Observação

No momento, as políticas de acesso condicional são impostas seletivamente aos usuários em iOS e Android dispositivos. Para obter mais informações, consulte Azure AD, Microsoft Intune e Windows 10 – Usando a nuvem para modernizar a mobilidade empresarial! Blog.

Controle de acesso condicional de aplicativos locais e de nuvem

O controle de acesso condicional é um poderoso mecanismo de avaliação de política integrado Azure AD. Ele oferece aos profissionais de TI uma maneira fácil de criar regras de acesso além do Office 365 que avaliam o contexto do logon de um usuário para tomar decisões em tempo real sobre quais aplicativos eles devem ter permissão para acessar.

Os profissionais de TI podem configurar políticas de controle de acesso condicional para aplicativos SaaS na nuvem protegidos por Azure AD e até mesmo aplicativos locais. As regras de acesso no Azure AD aproveitam o mecanismo de acesso condicional para verificar a integridade e o estado de conformidade do dispositivo relatados por uma solução de MDM compatível, como Intune, para determinar se o acesso deve ser permitido.

Para obter mais informações sobre acesso condicional, consulte a Visualização de Acesso Condicional do Azure para aplicativos SaaS.

Observação

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

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

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

O processo a seguir descreve como funciona Azure AD acesso condicional:

1. O usuário já se registrou no MDM por meio do Workplace Access/Azure AD que registra o dispositivo com Azure AD.
2. Quando o dispositivo é inicializado ou retomado da hibernação, uma tarefa "Tpm-HASCertRetr" é disparada para solicitar em segundo plano um blob de atestado de integridade. O dispositivo envia medidas de inicialização do TPM para o Serviço de Atestado de Integridade.
3. O Serviço de Atestado de Integridade valida o estado do dispositivo e emite um blob criptografado para o dispositivo com base no estado de integridade com detalhes sobre verificações com falha (se houver).
4. O usuário faz logon e o agente MDM entra em contato com o Intune/servidor MDM.
5. O servidor MDM envia por push novas políticas, se disponível, e consulta o estado do blob de integridade e outro estado de inventário.
6. O dispositivo envia um blob de atestado de integridade adquirido anteriormente e também o valor do outro inventário de estado solicitado pelo servidor Intune/MDM.
7. Intune/servidor MDM envia o blob de atestado de integridade para o Serviço de Atestado de Integridade a ser validado.
8. O Serviço de Atestado de Integridade valida se o dispositivo que enviou o blob de atestado de integridade está íntegro e retorna esse resultado para Intune/servidor MDM.
9. Intune/servidor MDM avalia a conformidade com base na conformidade e no estado de inventário/atestado de integridade consultado do dispositivo.
10. Intune/servidor MDM atualiza o estado de conformidade em relação ao objeto de dispositivo Azure AD.
11. O usuário abre o aplicativo, tenta acessar um ativo gerenciado corporativo.
12. Acesso restringido por declaração de conformidade Azure AD.
13. Se o dispositivo estiver em conformidade e o usuário estiver autorizado, um token de acesso será gerado.
14. O usuário pode acessar o ativo gerenciado corporativo.

Para obter mais informações sobre Azure AD, consulte Azure AD & Windows 10: Better Together for Work or School, um white paper.

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

Resumo e takeaways

A lista a seguir contém capturas de chave de alto nível para melhorar a postura de segurança de qualquer organização. No entanto, as poucas considerações apresentadas nesta seção não devem ser interpretadas como uma lista completa de práticas recomendadas de segurança.

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

  Se determinados adversários com intenção mal-intencionada obtêm acesso físico ao dispositivo, eles podem eventualmente interromper suas camadas de segurança e controlá-lo.

• Usar atestado de integridade com uma solução MDM

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

• Usar o Credential Guard

  O Credential Guard é um recurso que ajuda muito a proteger as credenciais de domínio corporativo contra ataques de passagem de hash.

• Usar o Device Guard

  O Device Guard é um avanço real na segurança e uma maneira eficaz de ajudar a proteger contra malware. O novo recurso do Device Guard Windows 10 aplicativos não confiáveis (aplicativos não autorizados pela sua organização).

• Assinar política do Device Guard

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

• Usar segurança baseada em virtualização

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

• Começar a implantar o Device Guard com o modo de auditoria

  Implante a política do Device Guard em computadores e dispositivos direcionados no modo de auditoria. Monitore o log de eventos de Integridade de Código que indica que um programa ou um driver teria sido bloqueado se o Device Guard estivesse configurado no modo de imposição. Ajuste as regras do Device Guard até que um alto nível de confiança seja atingido. Depois que a fase de teste for concluída, a política do Device Guard poderá ser alternada para o modo de imposição.

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

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

• Usar o AppLocker quando fizer sentido

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

• Bloquear firmware e configuração

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

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

Tópicos relacionados

• Proteger as credenciais de domínio derivadas com o Credential Guard
• Guia de implantação do Device Guard
• Visão geral da tecnologia Trusted Platform Module