Controlar a integridade dos dispositivos baseados em Windows 10

Este artigo fornece detalhes sobre uma solução de ponta a ponta que ajuda a proteger os ativos de alto valor ao impor, controlar e relatar a integridade dos dispositivos baseados no Windows 10.

Introdução

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

Os usuários desejam ter a melhor experiência de produtividade quando acessam os aplicativos corporativos e trabalham nos dados da organização de seus dispositivos. Isso significa que eles não tolerarão serem solicitados a inserir suas credenciais de trabalho cada vez que acessam um aplicativo ou servidor de arquivos. Do ponto de vista da 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 de BYOD, haverá mais sistemas não gerenciados e potencialmente não íntegros acessando serviços corporativos, recursos internos e aplicativos na nuvem.

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

Com os avanços da Microsoft, os investimentos em segurança estão cada vez mais concentrados nas defesas preventivas de segurança e também nas funcionalidades de detecção e resposta.

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

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

O cenário de ameaças à computação hoje está aumentando a uma velocidade inédita. A sofisticação dos ataques criminosos está crescendo e é claro que o malware agora visa tanto consumidores como profissionais em todos os setores.

Durante os últimos anos, uma categoria específica de ameaça tornou-se predominante: APTs (Ameaças Persistentes Avançadas). O termo APT costuma ser usado para descrever qualquer ataque contínuo que pareça destinado a organizações individuais. Na verdade, esse tipo de ataque normalmente envolve determinados adversários que podem usar qualquer método ou técnica necessários.

Com o fenômeno BYOD, um dispositivo mantido indevidamente representa um alvo preferencial. Para um invasor, isso é uma maneira fácil de violar o perímetro da rede de segurança, obter acesso e depois roubar os ativos de alto valor.

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

Uma abordagem diferente

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

Como os dispositivos móveis estão sendo usados cada vez mai para acessar informações corporativas, alguma forma de avaliar a segurança ou integridade dos dispositivos é necessária. Esta seção descreve como provisionar a avaliação de integridade de dispositivos de tal forma que os ativos de alto valor possam ser protegidos de dispositivos de risco.

Os dispositivos usados para acessar recursos corporativos devem ser confiáveis. Uma abordagem de segurança de ponta a ponta eficiente é capaz de avaliar a integridade do dispositivo e usar o estado atual de segurança ao conceder o 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 conhecer comportamentos, como o local de rede do qual o usuário se conecta regularmente. Além disso, uma abordagem moderna deve ser capaz de liberar conteúdo confidencial somente se os dispositivos do usuário forem considerados adequados e seguros.

A figura a seguir mostra uma solução desenvolvida para avaliar a integridade dos dispositivos na nuvem. O dispositivo autentica o usuário por 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, o qual pode ser enviado a qualquer momento ou quando o MDM (gerenciamento de dispositivos móveis) solicitar.

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

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

Um módulo de atestado de integridade do dispositivo pode comunicar os dados de inicialização medidos que estão protegido por um Trusted Platform Module (TPM) a um serviço remoto. Depois que o dispositivo é inicializado com êxito, os dados de medição do processo de inicialização são enviados a 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 remoto executa uma série de verificações nas medidas. Ele valida os pontos de dados relacionados à segurança, incluindo o estado de inicialização (Inicialização Segura, Modo de Depuração etc.) e o estado dos componentes que gerenciam a segurança (BitLocker, Device Guard etc.). 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 é obrigatória, além de determinar o status de integridade do dispositivo.

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

Uma solução MDM avalia as declarações de integridade e, dependendo das regras de integridade pertencentes à organização, pode decidir se o dispositivo é adequado. Se o dispositivo for adequado e estiver 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 em seguida para o nível adequado de confiança seja qual for a indicação do status de integridade e de outros elementos condicionais.

Dependendo dos requisitos e da confidencialidade do ativo gerenciado, o status de integridade do dispositivo pode ser combinado a informações de identidade do usuário ao processar uma solicitação de acesso. O acesso ao conteúdo é autorizado então para o nível de confiança apropriado. O mecanismo de acesso condicional pode ser estruturado para permitir verificação adicional, conforme exigido pela confiabilidade do ativo gerenciado. Por exemplo, se o acesso a dados de alto valor for solicitado, talvez seja necessário estabelecer uma autenticação de segurança adicional, pedindo ao usuário para responder a uma consulta por telefone antes de o acesso ser concedido.

Investimentos em segurança da Microsoft no Windows 10

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

• Identidades seguras. A Microsoft faz parte da Aliança FIDO que busca fornecer um método interoperavel de autenticação segura, eliminando o uso de senhas na autenticação do sistema local, bem como de todos os serviços, como recursos locais e recursos na nuvem.

• Proteção de informações. A Microsoft está fazendo investimentos para permitir que as organizações tenham maior controle sobre quem tem acesso a dados importantes e o que essas pessoas podem fazer com esses dados. Com o Windows 10, as organizações podem aproveitar as políticas que especificam quais aplicativos são considerados corporativos e 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 ataques e ameaças de malware usando defesas de segurança que contam com hardware.

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

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

Número	Parte da solução	Descrição
1	Dispositivo baseado no Windows 10	Na primeira vez que um dispositivo baseado no Windows 10 é ligado, a tela de apresentação (OOBE) é exibida. Durante a instalação, o dispositivo pode ser registrado automaticamente no Active Directory (AD) do Azure e inscrito no MDM. Um dispositivo baseado no Windows 10 com um TPM 2.0 pode relatar seu 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	O AD do Azure contém os usuários, dispositivos registrados e aplicativos registrados 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. O Azure AD é mais do que um repositório. O Azure AD é capaz de autenticar usuários e dispositivos, além de autorizar o acesso a recursos gerenciados. O Azure AD tem um mecanismo de controle de acesso condicional que utiliza a identidade do usuário, a localização do dispositivo e também o status de conformidade do dispositivo ao tomar uma decisão de acesso confiável.
3	Gerenciamento de dispositivos móveis	O Windows 10 tem suporte do MDM, o que significa que ele permite que o dispositivo seja gerenciado de imediato sem implantar qualquer agente. O MDM pode ser o Microsoft Intune ou qualquer solução MDM de terceiros que seja compatível com o Windows 10.
4	Atestado de integridade remoto	O Serviço de Atestado de Integridade do Windows é um serviço de nuvem confiável administrado pela Microsoft que executa uma série de verificações de integridade e relata para a solução MDM quais recursos de segurança do Windows 10 estão habilitados no dispositivo. A verificação de segurança inclui o estado da inicialização (WinPE, Modo de Segurança, modos de depuração e teste) e componentes que gerenciam a segurança e a integridade das operações de tempo de execução (BitLocker, Device Guard).
5	Ativo gerenciado empresarial	O ativo gerenciado empresarial é o recurso de proteção. Por exemplo, o ativo pode ser o Office 365, outros aplicativos na nuvem, recursos da web locais publicados pelo AD do Azure ou até mesmo acesso VPN.

 

A combinação dos dispositivos baseados no Windows 10 com o provedor de identidade, o MDB e o atestado de integridade remoto 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 de empresa contra ameaças

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

Defesas de segurança baseadas no hardware Windows 10

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 logo de início e impedir o funcionamento de mecanismos de proteção e software antimalware. Esse tipo de código mal-intencionado geralmente é chamado um rootkit ou bootkit. A melhor maneira de evitar a necessidade de lidar com malware de baixo nível é proteger o processo de inicialização para que o dispositivo fique seguro desde o início.

O Windows 10 dá suporte a várias camadas de proteção de inicialização. Alguns desses recursos só estarão disponíveis se tipos específicos de hardware forem instalados. Para saber mais, veja a seção Requisitos de hardware.

O Windows 10 oferece suporte a recursos para ajudar a impedir que malwares de baixo nível sofisticados como rootkits e bootkits sejam carregados 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.

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

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

  • A primeira especificação TPM, versão 1.2, foi publicada em fevereiro de 2005 pelo TCG e padronizada sob o padrão ISO / IEC 11889.

  • A especificação mais recente do TPM, conhecida como TPM 2.0, foi lançada em abril de 2014 e foi aprovada pelo ISO/IEC Joint Technical Committee (JTC) como ISO/IEC 11889:2015.

  O Windows 10 usa o TPM para cálculos criptográficos como parte do atestado de integridade e para proteger as chaves de BitLocker, Microsoft Passport, cartões inteligentes virtuais e outros certificados de chave pública. Para saber mais, veja Requisitos de TPM no Windows 10.

  O Windows 10 reconhece especificações do TPM 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 somente ao TPM 2.0. O TPM 2.0 é necessário para atestado de integridade do dispositivo.

  O TPM 2.0 oferece uma revisão importante dos recursos em relação ao TPM 1.2:

  • Atualização da força criptográfica para atender às necessidades de segurança modernas

    • Support a SHA-256 para PCRs

    • Suporte ao comando HMAC

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

    • O TPM 1.2 é extremamente restrito em termos de quais algoritmos ele pode dar suporte

    • O TPM 2.0 pode dar suporte a algoritmos arbitrários com pequenas atualizações para os documentos de especificação TCG

  • Manter a consistência entre implementações

    • A especificação TPM 1.2 dá grande amplitude aos fornecedores ao escolher detalhes de 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 capaz de controlar o 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 que é assinado com um certificado armazenado no banco de dados da Inicialização Segura UEFI. Naturalmente, o certificado da Microsoft usado para assinar digitalmente os carregadores de sistema operacional do Windows 10 estão nesse repositório, o que permite ao UEFI validar o certificado como parte da sua política de segurança. A Inicialização Segura deve ser habilitada por padrão em todos os computadores que sejam certificados para o Windows 10 sob o Programa de Compatibilidade de Hardware do Windows.

  A Inicialização Segura é um recurso baseado no firmware do UEFI, que permite a assinatura e a verificação de arquivos e drivers de inicialização crítica no momento da inicialização. A Inicialização Segura verifica os valores de assinatura do Gerenciador de Inicialização do Windows, o repositório BCD, o arquivo de carregador de sistema operacional Windows, e outras DLLs de inicialização críticas no momento da inicialização antes de o sistema operacional ter permissão para inicializar totalmente em um sistema operacional utilizável, usando as políticas que são definidas pelo OEM no momento da compilação. A Inicialização Segura evita vários tipos de rootkits baseados na inicialização, malwares e outros ataques relacionados à segurança contra a plataforma Windows. A Inicialização Segura protege o processo de inicialização do sistema operacional seja inicializando do disco rígido local, USB, PXE ou DVD, ou no Windows completo ou no Ambiente de Recuperação do Windows (RE).

  A Inicialização Segura protege o ambiente de inicialização de uma instalação do Windows 10, verificando as assinaturas dos componentes de inicialização crítica para confirmar que a atividade maliciosa não os comprometeu. A proteção da Inicialização Segura termina depois que o arquivo de kernel do Windows (ntoskrnl.exe) é carregado.

  Observação  

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

   

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

  Exemplos de informações de configuração protegida incluem a proteção do bit Disable Execute (opção NX) ou garantindo que a política de assinatura de teste (integridade do código) não pode ser habilitada. Isso garante que é possível confiar nos binários e na configuração do computador depois que o processo de inicialização estiver concluído.

  A política de configuração de Inicialização Segura faz isso com a política de UEFI. Estas assinaturas para essas políticas são assinadas da mesma forma 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 corresponde a uma das chaves públicas armazenadas na lista KEK (chave de troca de chave). A Autoridade de Certificação da Microsoft (CA) estará presente na lista KEK de todos os sistemas de Inicialização Segura certificados do Windows. Por padrão, uma política assinada pela KEK da Microsoft deve funcionar em todos os sistemas de Inicialização Segura. O BootMgr deve verificar a assinatura em relação à lista KEK antes de aplicar uma política assinada. No 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 kernel do Windows 10, 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. Esta etapa é importante e protege o restante do processo de inicialização, verificando que todos os componentes de inicialização do Windows têm integridade e são confiáveis.

• ELAM (Antimalware de Inicialização Antecipada). O ELAM testa todos os drivers antes que eles sejam carregados e impede que drivers não aprovados sejam carregados.

  Os aplicativos antimalware tradicionais só serão iniciados depois que os drivers relacionados à inicialização tiverem sido carregados, o que dá a um rootkit disfarçado como um driver a chance de funcionar. O ELAM é um mecanismo do Windows introduzido em uma versão anterior do Windows que permite que o software antimalware seja executado muito cedo na sequência de inicialização. Dessa forma, o componente antimalware é o primeiro componente de terceiros a ser executado e controla a inicialização de outros drivers de inicialização até que o sistema operacional Windows esteja funcionando. Quando o sistema é iniciado com um ambiente de tempo de execução 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 aplicativos e drivers de inicialização que não são da Microsoft, continuando, portanto, 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  

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

   

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

  O driver do ELAM é um pequeno driver com um banco de dados de políticas pequeno que tem um escopo muito estreito, concentrado nos drivers que são carregados no início da inicialização do sistema. O banco de dados de políticas é armazenado em um hive do registro que também é medido para o TPM, para registrar os parâmetros operacionais do driver do ELAM. Um driver do 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 que você proteja partes essenciais do Windows 10.

  A segurança baseada em virtualização isola o código confidencial como a Integridade de Código do Modo Kernel ou as credenciais confidenciais do domínio corporativo do resto do sistema operacional Windows. Para saber mais, veja a seção Segurança baseada em virtualização.

• Integridade de Código do Hyper-V (HVCI). A Integridade do Código do Hyper-V é um recurso do Device Guard que garante que apenas drivers, arquivos executáveis e DLLs que estejam em conformidade com a política de Integridade do Código do Device Guard sejam executados.

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

  O HVCI usa a segurança baseada em virtualização para isolar a integridade do código, a única maneira de a memória do kernel se tornar executável é através de uma verificação de integridade do código. Isso significa que as páginas da memória 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 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 postagem de blog sobre Compatibilidade de driver com o Device Guard no Windows 10.

   

  O recurso Integridade de Código do Device Guard permite que as organizações controlem qual código é confiável para ser executado no kernel do Windows e quais aplicativos são aprovados para serem executados no modo de usuário. Ele é configurável por meio de 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 do código ajuda na proteção contra um usuário mal intencionado com privilégios de administrador tentando modificar ou remover a política de integridade do código atual.

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

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

  Isso é feito com o Hyper-V e o novo recurso de segurança baseado em virtualização para criar um contêiner protegido, no qual o código confiável e os segredos são isolados do kernel do Windows. Isso significa que, mesmo se o kernel do Windows for comprometido, um invasor não tem como ler e extrair os dados necessários para iniciar um ataque de PtH. O Credential Guard evita isso porque a memória onde os segredos são armazenados não está mais acessível no sistema operacional normal, mesmo no modo de kernel. O hipervisor controla quem podem acessar a memória.

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

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

  Para saber mais, veja: Inicialização Segura e Inicialização Medida: protegendo componentes de inicialização com antecedência 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 ter mais segurança, os valores medidos pelo TPM podem ser conectados e transmitidos para um servidor remoto, que pode então executar a comparação. Esse processo, chamado atestado de integridade do dispositivo remoto, permite que o servidor verifique o status de integridade do dispositivo Windows.

  O atestado de integridade requer a presença do TPM 2.0. No Windows 10, o TPM 2.0 também requer firmware UEFI.

  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 vem desabilitado no Windows e é habilitado por um fornecedor de MDM ou um antimalware. Ao contrário da Inicialização Segura, o atestado de integridade não interrompe o processo de inicialização e insere a correção quando uma medida não funciona. Mas, com o controle de acesso condicional, o atestado de integridade ajudará a impedir o acesso aos ativos de alto valor.

Segurança baseada na virtualização

A segurança baseada em virtualização fornece um novo limite de confiança para o Windows 10. aproveita a tecnologia de hipervisor do Hyper-V para melhorar a segurança da plataforma. A segurança baseada em virtualização oferece um ambiente de execução seguro para executar código confiável do Windows 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. Observe que a segurança baseada em virtualização não está tentando proteger contra um invasor físico.

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

• Credential Guard (isolamento de credenciais LSA): impede ataques "pass-the-hash" e roubo de credenciais empresariais que acontece ao ler e despejar o conteúdo da memória de lsass

• Device Guard (Integridade de Código do Hyper-V): o Device Guard usa a nova segurança com base em virtualização no Windows 10 para isolar o serviço de integridade do código do próprio kernel do Windows, o que permite que o serviço use assinaturas definidas por sua política empresarial controlada para ajudar a determinar o que é confiável. Na verdade, o serviço de Integridade do Código é executado junto com o kernel em um contêiner protegido pelo hipervisor do Windows.

• Outros serviços isolados: por exemplo, no Windows Server Technical Preview 2016, há o recurso de vTPM que permite que você tenha máquinas virtuais (VMs) criptografadas em servidores.

Observação  

A segurança baseada em virtualização só está disponível no Windows 10 Enterprise. A segurança baseada em virtualização requer dispositivos com UEFI (2.3.1 ou superior) com a 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 sobregravada são opcionais, mas recomendados.

 

O esquema abaixo é uma visã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 LSASS (lsass.exe) executa código confidencial em um modo de usuário isolado para ajudar a proteger os dados contra malwares que podem estar em execução no modo de usuário normal. Isso ajuda a garantir que os dados protegidos não sejam roubados e reutilizados em computadores remotos, o que reduz muitos os ataques do estilo PtH.

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

• A chave por inicialização é usada para quaisquer credenciais na memória que não necessitam de persistência. Um exemplo de tal credencial seria uma chave de sessão do TGT (Tíquete de Concessão de Tíquete). Essa chave é negociada com um KDC (Centro de Distribuição de Chaves) sempre que ocorre autenticação e está protegida com uma chave por inicialização.

• A chave persistente, ou algum derivado, é usada para ajudar a proteger os itens que estão armazenados e são 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, em seguida, habilitado por meio de uma variável UEFI. Isso é feito para proteger contra modificações remotas da configuração. O uso de uma variável UEFI implica em que o acesso físico é necessário para alterar a configuração. Quando o lsass.exe detecta que o isolamento de credenciais está habilitado, ele gera o LsaIso.exe como um processo isolado, o que garante que ele seja executado no modo de usuário isolado. A inicialização dos LsaIso.exe é executada antes da inicialização de um provedor de suporte de segurança, o que garante que as rotinas de suporte de 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. Nesta configuração, os únicos aplicativos com permissão para serem executados são aqueles nos quais a organização confia.

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

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

Observação  

Independentemente da ativação da política do Device Guard, o Windows 10 por padrão eleva o nível do que é executado no kernel. Os drivers do Windows 10 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 drivers, incluindo envios de drivers do modo de usuário e de kernel, que têm um Certificado de Autenticação de Código de Validação Estendida ("EV").

 

Com o Device Guard no 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 o Windows 10 Enterprise. As organizações têm a capacidade de configurar a política que determina o que é confiável para ser executado. Isso inclui drivers e arquivos do sistema, bem como scripts e aplicativos da área de trabalho tradicionais. O sistema, em seguida, é bloqueado para executar apenas aplicativos em que a organização confie.

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

• Permitir limita a execução de aplicativos a uma lista de permissões de código ou editores confiáveis e bloqueia todo o resto.

• Negar conclui a abordagem de permissão de editor confliável, bloqueando a execução de um aplicativo específico.

No momento da redação deste artigo e de acordo com as pesquisas mais recentes da Microsoft, mais de 90% do malware é totalmente não assinado. Portanto, implementar uma política básica do Device Guard pode simples e eficientemente ajudar a bloquear a grande maioria dos malwares. Na verdade, o Device Guard tem o potencial para ir além e também pode ajudar a bloquear um malware assinado.

O Device Guard precisa ser planejado e configurado para ser realmente eficiente. Não é apenas uma proteção que é 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, pode bloquear um computador para garantir um sistema o mais seguro e resistente possível.

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

• A primeira parte é um conjunto base de recursos de segurança de hardware introduzido com a versão anterior do Windows. O TPM para operações de criptografia de hardware e UEFI com firmware moderno, juntamente com a Inicialização Segura, permite que você controle o que o dispositivo está executando quando os sistemas iniciam.

• Após o recurso de segurança de hardware, há o mecanismo de integridade do código. No Windows 10, a integridade do código agora é totalmente configurável e reside no modo de usuário isolado, uma parte da memória que está protegida pela segurança baseada em virtualização.

• A última parte do Device Guard é o gerenciamento. A configuração de integridade do código é exposta por meio de objetos de política de grupo específicos, os cmdlets do PowerShell e provedores de serviço de configuração do MDM (CSPs).

Para saber mais 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 eficiente de bloquear sistemas. O Device Guard não se destina a ser usado amplamente e pode nem sempre ser aplicável, mas existem alguns cenários de alto interesse.

O Device Guard é útil e aplicável em sistemas de cargas de trabalho fixas como caixas registradoras, máquinas de quiosque, SAWs (Secure Admin Workstations) ou áreas de trabalho bem gerenciadas. O Device Guard é altamente relevante em sistemas que tenham software muito bem definido que espera-se que seja executado e não seja alterado frequentemente. Ele também poderia ajudar a proteger os operadores de informações (IWs) além de apenas SAWs, desde que o que eles precisam 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 PtH, entre outros riscos de segurança. Embora os SAWs não possam ser considerados uma solução de segurança "definitiva" a esses ataques, esses tipos de clientes são úteis como parte de uma abordagem de defesa em camadas à segurança.

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

Da mesma forma, em estações de trabalho corporativas totalmente gerenciadas, nas quais os aplicativos são instalados por meio de uma ferramenta de distribuição como o System Center Configuration Manager, o Intune, ou qualquer outra ferramenta de gerenciamento de dispositivo de terceiros, o Device Guard é muito 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 parcialmente gerenciadas, nas quais o usuário geralmente tem permissão para instalar o software por eles próprios. Quando uma organização oferece uma grande flexibilidade, é muito difícil executar o Device Guard no modo de imposição. Apesar disso, o Device Guard pode ser executado no modo de auditoria e, nesse caso, o log de eventos conterá um registro de quaisquer 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 detalhados sobre drivers e aplicativos que os usuários instalam e executam.

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

Observação  

A política do Device Guard pode ser assinada no Windows 10, o que adiciona proteção extra contra usuários administrativos que alterem ou removam essa política.

 

A política assinada do Device Guard oferece maior proteção contra um administrador local mal intencionado tentando vencer o Device Guard.

Quando a política é assinada, o GUID da política é armazenado em uma variável segura UEFI pré-sistema operacional que oferece proteção contra violaçã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 para a seção UpdateSigner.

A importância da assinatura de aplicativos

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

Com o Windows 10, as organizações disponibilizarão aplicativos de linha de negócios (LOB) aos membros da organização por meio da infraestrutura da Windows Store. Mais especificamente, os aplicativos LOB estarão disponíveis em um repositório particular dentro da Windows Store pública. A Windows Store assina e distribui aplicativos Universais do Windows e aplicativos Clássicos do Windows. Todos os aplicativos baixados da Windows Store são assinados.

Nas organizações de hoje em dia, a vasta maioria dos aplicativos LOB não são assinados. A assinatura de código com frequência é vista como um problema difícil de resolver por uma variedade de razões, como a falta de conhecimento em assinatura de código. Mesmo se a assinatura de código for uma prática recomendada, muitos aplicativos internos não são assinados.

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

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

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

As vulnerabilidades são pontos fracos do software que poderiam permitir que um invasor comprometesse 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 os invasores distribuindo conteúdo especialmente criados na tentativa de explorar vulnerabilidades conhecidas no modo de usuário, como navegadores da Web (e seus plug-ins), máquinas virtuais Java, leitores de PDF ou editores do documento. Hoje em dia, 90% das vulnerabilidades descobertas afetam os aplicativos de modo de usuário em comparação com os drivers de modo kernel e do sistema operacional que os hospeda.

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

A maioria dos softwares de aplicativo não têm recursos para atualizar a si mesmos, mesmo se o fornecedor de software publicar uma atualização que corrige 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 a corrigir vulnerabilidades.

As soluções MDM estão se tornando predominantes como uma tecnologia leve de gerenciamento de dispositivos. O Windows 10 estende os recursos de gerenciamento que foram disponibilizados para MDMs. Um recurso essencial que a Microsoft adicionou ao Windows 10 é a capacidade dos MDMs de adquirir uma declaração forte de integridade de dispositivos gerenciados e registrados.

Atestado de integridade de dispositivo

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

Para dispositivos 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 Serviço de Atestado de Integridade do Windows. 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 em se a integridade dos dispositivos pode ser comprovada.

Para saber mais sobre o atestado de integridade do dispositivo, veja a seção Detectar um dispositivo baseado no Windows 10 não íntegro.

Requisitos de hardware

A tabela a seguir detalha os requisitos de hardware dos serviços de segurança baseada em virtualização e o recurso de atestado de integridade. Para saber mais, veja 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 de UEFI. A Inicialização Segura UEFI garante que o dispositivo inicialize somente código autorizado. Além disso, a Integridade de Inicialização (Inicialização Segura de Plataforma) deve ter suporte além dos requisitos da Especificação de Compatibilidade de Hardware para Sistemas para Windows 10 sob a subseção: "System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby"
Extensões de virtualização, como Intel VT-x, AMD-V e SLAT devem estar habilitadas	Necessário para dar suporte à segurança baseada em virtualização. Observação   O Device Guard pode ser habilitado sem o uso de segurança baseada em virtualização.
Processor X64	Necessário para dar suporte à segurança baseada em virtualização que usa o Hipervisor do Windows. O Hyper-V tem suporte apenas em processadores x64 (e não em x86). A proteção de DMA (Acesso Direto à Memória) pode ser habilitada para fornecer proteção adicional à memória, mas requer processadores para incluir tecnologias de proteção de DMA.
IOMMU, tal como Intel VT-d, AMD-Vi	O suporte para o IOMMU no Windows 10 aprimora a resiliência do sistema contra ataques de DMA.
Trusted Platform Module (TPM) 2.0	Necessário para dar suporte ao atestado de integridade e para proteções essenciais adicionais para a segurança baseada em virtualização.

 

Esta seção apresentadou informações sobre vários controles estreitamente relacionados no Windows 10. A abordagem detalhada e de desefas em várias camandas ajuda a excluir malwares de baixo nível durante a sequência de inicialização. A segurança baseada em virtualização é uma alteração de arquitetura do sistema operacional fundamental que adiciona um novo limite de segurança. O Device Guard e o Credential Guard respectivamente ajudam a bloquear códigos não confiáveis e a proteger credenciais de domínio corporativas contra roubo e reutilização. Esta seção também discutiu resumidamente a importância do gerenciamento de dispositivos e a correção das vulnerabilidades. Todas essas tecnologias podem ser usadas para proteger e bloquear dispositivos limitando o risco de invasores comprometê-los.

Detectar um dispositivo não íntegro baseado no Windows 10

Hoje em dia, muitas organizações apenas consideram que os dispositivo estejam em conformidade com a política da empresa depois que eles passaram por uma variedade de verificações que mostram, por exemplo, se o sistema operacional está no estado correto, está configurado de forma apropriada e tem a proteção de segurança habilitada. Infelizmente, com os sistemas de hoje, essa forma de relatório não é totalmente confiável porque um malware pode simular 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 de integridade falso para ferramentas de conformidade tradicionais.

O maior desafio com os rootkits é que eles podem não ser detectados pelo cliente. Como eles iniciam antes do antimalware e têm privilégios de nível do sistema, eles podem se disfarçar completamente enquanto continuam a acessar os recursos do sistema. Como resultado, computadores tradicionais infectados por rootkits parecem estar íntegros, mesmo com o antimalware em execução.

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

Atestando o estado de inicialização confiável, os dispositivos podem provar que não estão executando malware de baixo nível que poderia 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.

O que é o conceito de integridade do dispositivo?

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

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

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

A integridade do dispositivo não é binária e depende de implementação de segurança da organização. O serviço de atestado de integridade fornece informações de volta para o MDM no qual os recursos de segurança estão habilitados durante a inicialização do dispositivo, aproveitando o TPM de hardware confiável.

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

Atestado de integridade de dispositivo remoto

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

Essa é a abordagem mais segura disponível para os dispositivos baseados em Windows 10 detectarem quando as defesas de segurança estão inativas. Durante o processo de inicialização, o log TCG e os valores de PCRs 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.

Um terceiro como um MDM pode inspecionar o relatório gerado pelo serviço de atestado de integridade remoto.

Observação  

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

 

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

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

No caso em que um código malicioso está em execução no dispositivo, é necessário o uso de um servidor remoto. Se um rootkit estiver presente no dispositivo, o antimalware não é mais confiável e seu comportamento pode ser sequestrado por um código malicioso 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 o PCRs para um servidor de atestado de integridade remoto para fornecer uma separação entre o componente de medição e o componente de verificação.

O atestado de integridade registra as medições em vários registros de configuração de plataforma (PCRs) do TPM e em logs de TGC durante o processo de inicialização.

Ao iniciar um dispositivo equipado com um TPM, uma medição de componentes diferentes é executada. Isso inclui o firmware, os drivers UEFI, o microcódigo da CPU e também todos os drivers do Windows 10 cujo tipo é Iniciar Reinicialização. As medidas brutas são armazenadas em registros PCR do TPM enquanto os detalhes de todos os eventos (caminho do arquivo executável, autoridade de certificação e assim por diante) estão disponíveis no log de 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 é medida.

4. O kernel do Windows é medido.

5. O software antivírus é iniciado como o primeiro driver de modo kernel.

6. Os drivers de inicialização são medidos.

7. O servidor MDM por meio do agente MDM emite um comando de verificação de integridade usando o CSP de atestado de integridade.

8. As medições 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 respectivos logs de retomada são arquivados na pasta %SystemRoot%\logs\measuredboot.

O número de logs mantidos pode ser definido com o registro REG_DWORD valor PlatformLogRetention sob a chave HKLM\SYSTEM\CurrentControlSet\Services\TPM. Um valor 0 desativará o arquivamento de logs e um valor 0xffffffff manterá todos os logs.

 

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

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

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

3. O serviço de atestado de integridade de dispositivo remoto então:

   1. Verifica se o certificado de AIK é emitido por uma autoridade de certificação conhecida e confiável e o certificado é válido e não revogado.

   2. Verifica se a assinatura nas citações de PCR está correta e consistente com o valor de log de TCG.

   3. Analisa as propriedades no log de TCG.

   4. Emite o token de integridade do dispositivo que contém as informações de integridade, as informações de 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, isso significa que as informações são protegidas e só estão acessíveis para a emissão de 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, a ID do dispositivo (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 de Atestado de Integridade do Windows. Esses componentes são descritos nesta seção.

Trusted Platform Module

É tudo sobre TPM 2.0 e certificados de endosso. Esta seção descreve como PCRs (que contêm dados de configuração do sistema), chaves de endosso (EK) (que atuam como um cartão de identidade para TPM), SRKs (que protegem chaves) e AIKs (que podem informar o estado da plataformas) são usados para relatar o atestado de integridade.

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

Um TPM incorpora em um único componente:

• Um gerador de chaves RSA de 2048 bits

• Um gerador de números aleatórios

• Memória não volátil para armazenar as 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 de criptografia única inserida chamada de chave de endosso. A chave de endosso do TPM é um par de chaves assimétricas (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 EK é usada durante a criação de chaves secundárias como AIKs.

A chave de endosso age como um cartão de identidade para o TPM. Para saber mais, veja Entender a chave de endosso do TPM.

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

• Um certificado é produzido pelo fabricante do TPM e é chamado de certificado de endosso. O certificado de endosso é usado para comprovar a autenticidade do TPM (por exemplo, que é um TPM real fabricado por um fabricante de chips específico) para processos locais, aplicativos ou serviços de nuvem. O certificado de endosso é criado durante a fabricação ou na primeira vez em 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 é integrado a um determinado dispositivo.

Para certos dispositivos que usam o TPM baseados no firmware produzido pela Intel ou Qualcomm, o certificado de endosso é criado quando o TPM é inicializado durante a tela de apresentação do Windows 10.

Observação  

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

• Para o TPM do firmware da Intel: https://ekop.intel.com/ekcertservice

• Para o TPM do firmware da Qualcomm: https://ekcert.spserv.microsoft.com/

 

Chaves de Identidade de Atestado

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

Observação  

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

 

A AIK é um par de chaves assimétrico (pública e privada) que é usado como um substituto para a chave de endosso como uma identidade para o TPM para fins de privacidade. A parte privada de umaAIK 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, ela só pode ser usada para assinar e apenas para operações limitadas definidas peloTPM.

O Windows 10 cria AIKs protegidas pelo TPM, se disponível, que são as chaves de assinatura de RSA de 2048 bits. A Microsoft está hospedando um serviço de nuvem chamado Microsoft Cloud CA para estabelecer criptograficamente que ela está se comunicando com um TPM real e o TPM possui a AIK apresentada. Depois que o serviço Microsoft Cloud CA estabeleceu esses fatos, ele emitirá um certificado de AIK para o dispositivo baseado no Windows 10.

Muitos dispositivos existentes que atualizarão para o Windows 10 não terão um TPM, ou o TPM não conterá um certificado de endosso. Para acomodar esses dispositivos, o Windows 10 permite a emissão de certificados de AIK sem a presença de um certificado de endosso. Tais certificados de AIK não são emitidos pelo Microsoft Cloud CA. Observe que isso não é tão confiável quanto um certificado de endosso que é gravado no dispositivo durante a fabricação, mas fornecerá compatibilidade para cenários avançados, como o Microsoft Passport sem TPM.

No certificado de AIK emitido, um OID especial é adicionado para confirmar que esse certificado de endosso foi usado durante o processo de certificação. Essas informações podem ser usadas por um terceiro parte para decidir se os dispositivos que são atestados por certificados de AIK sem um certificado de endosso serão rejeitados ou aceitos. Outro cenário pode ser não permitir o acesso aos ativos de alto valor de dispositivos que são atestados por um certificado de AIK que não é endossado por um certificado de endosso.

Chave raiz de armazenamento

A chave raiz de armazenamento (SRK) também é um par de chaves assimétricas (RSA com um tamanho mínimo de 2048 bits). A SRK tem uma função importante e é usada para proteger as chaves do TPM, para que essas chaves não sejam usadas sem o TPM. A chave SRK é criada quando a propriedade do TPM é retirada.

Registros de Configuração de Plataforma

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

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

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

O valor de um PCR por si é difícil de interpretar (é apenas um valor de hash), mas as plataformas normalmente mantêm um log com detalhes sobre o que foi medido, e os PCRs simplesmente garantem que o log não foi violado. Os logs são conhecidos como um log de TCG. Cada vez que um PCR de registro é estendido, uma entrada é adicionada ao log de TCG. Sendo assim, durante o processo de inicialização, um rastreamento dos dados de configuração e do código executável é criado no log de TCG.

Provisionamento de TPM

Para o TPM de um dispositivo baseado no Windows 10 ser usado, 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 é provisionado, o Windows 10 primeiro tenta determinar a chave de endosso e os valores ownerAuth armazenados localmente, examinando o registro no seguinte local: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

Durante o processo de provisionamento, o dispositivo talvez precise ser reiniciado.

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

Se a propriedade do TPM não é conhecida, mas a chave de endosso existe, a biblioteca cliente provisionará o TPM e armazenará o valor ownerAuth resultante no registro. Se a política permitir, ele armazenará a parte da pública SRK no seguinte local: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub

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

Observação  

Para provisionar certificados de 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

O Windows 10 contém um provedor de serviços de configuração (CSP) 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 sobre como os servidores MDM podem definir configurações e gerenciar dispositivos baseados no Windows. O protocolo de gerenciamento é representado como uma estrutura em árvore que pode ser especificada como URIs com funções para executar os URIs como "obter", "definir", "excluir" e assim por diante.

A seguir está uma lista de funções executadas pelo CSP de Atestado de Integridade do Windows 10:

• Coleta dados que são usados para verificar o status de integridade do dispositivo

• Encaminha os dados para o serviço de atestado de integridade

• Configura o certificado de atestado de integridade que ele recebe do serviço 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 tempo de execução relacionadas para o 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 que são medidos durante a inicialização, usando um canal de comunicação seguro para o serviço de atestado de integridade.

Quando um servidor MDM validar que um dispositivo tem o atestado para o serviço de atestado de integridade, ele receberá um conjunto de instruções e declarações sobre como esse dispositivo foi inicializado, com a garantia de que o dispositivo não foi reinicializado entre a hora em que foi atestada a sua integridade e a hora em que o servidor MDM o validou.

Serviço de Atestado de Integridade do Windows 10

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

Observação  

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

 

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

1. Primeiro, o servidor deve verificar se os relatórios foram assinados por AIKs confiáveis. Isso pode ser feito, verificando-se se a parte pública da AIK está listada em um banco de dados de ativos, ou talvez se um certificado foi verificado.

2. Depois que a chave foi verificada, o atestado assinado (uma estrutura de citação) deve ser verificado para ver se é uma assinatura válida sobre os valores de PCR.

3. Em seguida, os logs devem ser verificados para garantir que eles correspondem aos valores de PCR relatados.

4. Finalmente, os logs propriamente ditos devem ser examinados por uma solução MDM para ver se eles representam configurações de segurança conhecidas ou válidas. Por exemplo, uma verificação simples pode ver se os componentes de sistema operacional medidos anteriormente são conhecidos por serem válidos, se o driver de ELAM é o esperado e se o arquivo de política de driver de ELAM está atualizado. Se todas essas verificações tiverem êxito, pode ser emitida uma instrução de atestado que posteriormente pode ser usada para determinar se o acesso a um recurso deve ou não ser concedido para o cliente.

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

• A Inicialização Segura está habilitada.

• Depuração da inicialização e do kernel habilitada

• Habilitação do BitLocker

• MFV habilitado

• Medição da política de Integridade de Código do Device Guard assinada ou não assinada

• ELAM carregado

• Inicialização no Modo de Segurança, habilitação de DEP, habilitação de assinatura de teste

• O dispositivo TPM foi provisionado com um certificado de endosso confiável

Para obter as medições completas, veja CSP de Atestado de Integridade.

A tabela a seguir apresenta alguns itens essenciais que podem ser relatados de volta para o MDM dependendo do tipo de dispositivo baseado no Windows 10.

Tipo de sistema operacional	Itens essenciais que podem ser relatados
Windows 10 Mobile	Medição de PCR0 Inicialização Segura habilitada O banco de dados de Inicialização Segura é padrão O dbx de Inicialização Segura está atualizado O GUID da política de Inicialização Segura é padrão Criptografia de Dispositivo habilitada A versão/carimbo de data/hora da lista de revogações da integridade de código está atualizada
Windows 10 para edições de área de trabalho	Medição de 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 politica de Inicialização Segura corresponde ao esperado BitLocker habilitado Segurança baseada em virtualização habilitada: O ELAM foi carregado A versão da Integridade do Código está atualizada O hash da política de Integridade do Código corresponde ao esperado

 

Usar o MDM e o serviço de atestado de integridade

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

Uma solução que usa 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 em um provedor MDM (o atestado de integridade será desabilitado por padrão).

2. Depois de habilitado, e a cada inicialização daí em diante, o dispositivo enviará medições de integridade para o serviço de atestado de saúde hospedado pela Microsoft, e receberá um blob de atestado de integridade de volta.

3. A qualquer momento depois disso, um servidor MDM pode solicitar o blob de atestado de integridade do dispositivo e solicitar que o serviço de atestado de integridade descriptografe o conteúdo e valide que ele foi atestado.

A interação entre um dispositivo baseado no 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 seria parte do aplicativo cliente que inicia a solicitação. O servidor MDM neste momento poderia solicitar os dados de atestado de integridade usando o URI CSP apropriado.

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

3. O cliente envia o nonce entre aspas da AIK + o contador de inicializações e as informações do blob de integridade. Esse blob de integridade é criptografado com uma chave pública de serviço de atestado de integridade que apenas o serviço de atestado de integridade pode descriptografar.

4. O servidor MDM:

   1. Verifica se o nonce está conforme 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 atesatdo de integridade:

   1. Descriptografa o blob de integridade.

   2. Verifica se o contador de inicialização entre aspas está correto usando a AIK no blob de integridade e compara ao valor no blob de integridade.

   3. Verifica se o nonce entre aspas corresponde ao outro que é passado pelo MDM.

   4. Como o contador de inicialização e o nonce estão entre aspas com a AIK do blob de integridade, ele também prova que o dispositivo é o mesmo para o qual o blob de integrirade 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 (terceiro) nunca realiza a validação do contador de inicialização ou das aspas 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, a AIK nunca fica visível para o MDM, que, assim, lida com as 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, controlados e tenham as 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 sem conformidade 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 aos 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 dispositivo baseado no Windows 10 antes que o acesso seja concedido

A tecnologia de controle de acesso de hoje, na maioria dos casos, se concentra em garantir que as pessoas certas tenham acesso aos recursos corretos. Se os usuários puderem se autenticar, eles obterão acesso aos recursos usando um dispositivo que a equipe de TI da organização e os sistemas conhecem muito pouco. Talvez haja alguma verificação como garantir que um dispositivo seja criptografado antes de conceder 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, em seguida, está disponível para uma solução MDM como o Intune.

Observação  

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

 

A figura a seguir mostra como o serviço de atestado de integridade deve funcionar com o serviço MDM do Intune baseado em nuvem da Microsoft.

Uma solução MDM pode usar as instruções de estado de integridade e levá-las para o próximo nível, juntando com as políticas do cliente que habilitarão o acesso condicional a ser concedido com base na capacidade do dispositivo de provar que está livre de malware, o sistema antimalware está atualizado e funcional, o firewall está em execução e o estado do patch de dispositivos está em conformidade.

Por fim, os recursos podem ser protegidos, negando-se 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

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

Suporte ao servidor MDM de terceiros

Os servidores MDM de terceiros podem gerenciar o 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 empresarial. Para obter informações adicionais, veja Integração do Active Directory do Azure com o MDM.

Observação  

Os servidores MDM não precisam criar ou baixar um cliente para gerenciar o Windows 10. Para saber mais, veja Gerenciamento de dispositivos móveis.

 

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

Gerenciamento do Windows Defender por MDM de terceiros

Essa infraestrutura de gerenciamento torna possível para os profissionais de TI usar produtos compatíveis com MDM, como o Intune, para gerenciar o atestado de integridade, o Device Guard ou o Windows Defender em dispositivos baseados no Windows 10, incluindo BYODs que não ingressaram no domínio. Os profissionais de TI poderão gerenciar e configurar todas as ações e configurações que estão acostumados a personalizar, usando o Intune com Intune Endpoint Protection em sistemas operacionais de baixo nível. Os administradores que atualmente apenas gerenciam dispositivos ingressados no domínio através da Política de Grupo acharão fácil fazer a transição para o gerenciamento de dispositivos baseado no Windows 10 usando MDM, pois muitas das configurações e ações são compartilhadas entre os dois mecanismos.

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

Controle de acesso condicional

Na maioria das plataformas, o registro de dispositivo do Active Directory do Azure (Azure AD) ocorre automaticamente durante o registro. Os estados de dispositivo são gravados pela solução MDM no Azure AD e, em seguida, lidos pelo Office 365 (ou por qualquer aplicativo Windows autorizado que interage com o Azure AD) na próxima vez em que o cliente tenta acessar uma carga de trabalho compatível do 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 redirecionará para o portal da Web do MDM, onde ele pode obter mais informações sobre o problema de conformidade e como resolvê-lo.

O Azure AD autentica o usuário e o dispositivo, o MDM gerencia a conformidade e as políticas de acesso condicional e o serviço de atestado de integridade relata sobre a integridade do dispositivo de maneira a atestá-lo.

Controle de acesso condicional do Office 365

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

Quando um usuário solicita o acesso a um serviço do Office 365 em uma plataforma de dispositivo compatível, 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 o dispositivo inscrito recebem instruções de correção sobre como registrar e ficar em conformidade para acessar os serviços corporativos do Office 365.

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

Observação  

A Microsoft está trabalhando com ISVs MDM de terceiros para dar suporte ao registro no MDM e às verificações de acesso baseadas em política. As etapas para ativar o registro automático no MDM com o Azure AD e o Intune são explicadas na postagem de blog sobre Windows 10, Azure AD e Microsoft Intune: registro automático no MDM habilitado pela nuvem!.

 

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

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

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

Os clientes que tentam acessar o Office 365 serão avaliados em relação às seguintes propriedades:

• O dispositivo é gerenciado por um MDM?

• O dispositivo está registrado no Azure AD?

• O dispositivo está em conformidade?

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

• Registrar-se em uma solução MDM.

• Registrar-se no 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 dispositivos iOS e Android. Para saber mais, veja a postagem de blog sobre Azure AD, Microsoft Intune e Windows 10 – usando a nuvem para modernizar a mobilidade corporativa!.

 

Controle de acesso condicional de aplicativos na nuvem e locais

O controle de acesso condicional é um mecanismo de avaliação de política poderoso integrado no Azure AD. Isso oferece aos profissionais de TI uma maneira fácil de criar regras de acesso além do Office 365 que avaliam o contexto de logon do 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 da nuvem protegidos pelo Azure AD e até mesmo aplicativos locais. As regras de acesso no Azure AD usam o mecanismo de acesso condicional para verificar o estado de integridade e conformidade do dispositivo relatado por uma solução MDM compatível como o Intune para determinar se deve permitir o acesso.

Para saber mais sobre o acesso condicional, veja Azure Conditional Access Preview para aplicativos SaaS.

Observação  

O controle de acesso condicional é um recurso do Azure AD Premium que também está disponível com o EMS. Caso não tenha uma assinatura do Azure AD Premium, você pode obter uma versão de avaliação no site do Microsoft Azure.

 

Existem duas opções para habilitar o controle de acesso condicional para aplicativos locais baseado no estado de conformidade do dispositivo:

• Para aplicativos locais que são publicados através do proxy de aplicativos do Azure AD, você pode configurar políticas de controle de acesso condicional como faria para aplicativos em nuvem. Para obter mais detalhes, veja a postagem de blog sobre Azure AD Conditional Access Preview atualizado: agora dá suporte a aplicativos LOB personalizados e locais.

• Além disso, o Azure AD Connect sincronizará as informações de conformidade do dispositivo do Azure AD com o AD local. O ADFS no Windows Server Technical Preview 2016 dará suporte ao controle de acesso condicional baseado no estado de conformidade do dispositivo. Os profissionais de TI configurarão políticas de controle de acesso condicional no ADFS que usam o estado de conformidade do dispositivo relatado por uma solução MDM compatível para proteger aplicativos locais.

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

1. O usuário já se inscreveu no MDM por meio de associação ao Workplace Access/Azure AD, que registra o dispositivo no Azure AD.

2. Quando o dispositivo for inicializado ou sair da hibernação, uma tarefa "Tpm-HASCertRetr" será acionada para solicitar em segundo plano um blob de atestado de integridade. O dispositivo envia medições 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 baseado no estado de integridade com os detalhes sobre as verificações falhas (se houver).

4. O usuário faz logon e o agente MDM contata o servidor Intune/MDM.

5. O servidor MDM envia novas políticas, se houver, e consulta o estado do blob de integridade e outro estado do 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. O servidor Intune/MDM envia o blob de atestado de integridade para o serviço de atestado de integridade para 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 o servidor Intune/MDM.

9. O servidor Intune/MDM avalia a conformidade com base na conformidade e no estado do atestado de integridade/inventário consultado do dispositivo.

10. O servidor Intune/MDM atualiza o estado de conformidade com base no objeto do dispositivo no Azure AD.

11. O usuário abre o aplicativo, tenta acessar um ativo gerenciado corporativo.

12. Acesso concedido por declaração de conformidade no 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 corporativo gerenciado.

Para saber mais sobre o ingresso no Azure AD, veja o white paper sobre Azure AD & Windows 10: melhor juntos para trabalho ou escola.

O controle de acesso condicional é um tópico sobre o qual muitas organizações e profissionais de TI talvez não saibam como deveriam. 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 protegerem seu ambiente.

Resumo e argumentos

A lista a seguir contém argumentos essenciais de alto nível para melhorar a postura de segurança de qualquer organização. No entanto, alguns argumentos apresentados nesta seção não devem ser interpretados como uma lista completa das práticas recomendadas de segurança.

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

  Se determinados adversários com más intenções tiverem acesso físico ao dispositivo, eles podem eventualmente passar por suas camadas de segurança e controlá-lo.

• Usar o 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 sem conformidade possam ser detectados, relatados e eventualmente bloqueados.

• Usar o Credential Guard

  O Credential Guard é um recurso que ajuda muito a proteger as credenciais corporativas do domínio contra ataques "pass-the-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 Device Guard no Windows 10 bloqueia aplicativos não confiáveis (aplicativos não autorizados por sua organização).

• Assinar política do Device Guard

  A política assinada do Device Guard 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 específico como parte da política do Device Guard.

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

  Quando você tiver a integridade de código do modo kernel protegida pela segurança baseada em virtualização, as regras do código de integridade ainda serão impostas, se uma vulnerabilidade permitir o acesso à memória no modo kernel não autorizado. Tenha em mente que os dispositivos do Device Guard que executam a integridade de código do kernel com a segurança baseada em virtualização devem ter drivers compatíveis.

• Comece a implantar o Device Guard no modo de auditoria

  Implante a política do Device Guard em computadores e dispositivos de destino 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 tivesse sido configurado no modo de imposição. Ajuste as regras do Device Guard até que um alto nível de confiança seja atingido. Após a conclusão da fase de teste, a política do Device Guard pode 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 que seja 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 AppLocker quando isso faz sentido

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

• Bloquear firmware e configuração

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

O atestado de integridade é um recurso essencial do Windows 10 que inclui componentes de cliente e na nuvem para controlar o acesso aos ativos de alto valor com base em um usuário e na identidade do dispositivo dele e na conformidade com a política de governança corporativa. As empresas 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 os fornecedores e os desenvolvedores de software podem usar para criar e integrar uma solução personalizada.

Tópicos relacionados

Credential Guard

Guia de implantação do Device Guard

Visão geral da tecnologia Trusted Platform Module