Mitigação da Autenticação do Sistema de Ficheiros de Registo Comum (CLFS)

Neste artigo

Resumo

Período de adoção da mitigação

Impacto do utilizador

Configuração

Atualizar Política de Grupo definição com o Editor de Política de Grupo Local

Atualizar a definição de Política de Grupo/MDM com Intune

Alterações à API CLFS

Perguntas mais frequentes (FAQ)

Glossário

Resumo

Foi introduzida uma nova mitigação de autenticação de proteção para o controlador CLFS (Common Log File System ), que adiciona um código de autenticação de mensagens (HMAC) baseado em hash aos ficheiros subjacentes de um ficheiro de registo CLFS. Os códigos de autenticação são criados ao combinar dados de ficheiros com uma chave criptográfica exclusiva do sistema, que é armazenada no registo e apenas acessível para Administradores e SISTEMA. Os códigos de autenticação permitirão ao CLFS verificar a integridade do ficheiro, garantindo que os dados dos ficheiros estão seguros antes de analisar as estruturas de dados internas. O CLFS pressupõe que este ficheiro foi modificado externamente, maliciosamente ou de outra forma, se a verificação de integridade falhar e se recusará a abrir o ficheiro de registo. Para continuar, tem de ser criado um novo logfile ou um Administrador terá de o autenticar manualmente com o comando fsutil.

Período de adoção da mitigação

Um sistema que recebe uma atualização com esta versão do CLFS provavelmente terá ficheiros de registo existentes no sistema que não têm códigos de autenticação. Para garantir que estes ficheiros de registo são transitados para o novo formato, o sistema colocará o controlador CLFS num "modo de aprendizagem" que irá instruir o CLFS a adicionar automaticamente códigos de autenticação a ficheiros de registo que não os tenham. A adição automática de códigos de autenticação ocorrerá no logfile aberto e apenas se o thread de chamada tiver o acesso necessário para escrever no ficheiro. Atualmente, o período de adoção dura 90 dias, a partir do momento em que o sistema foi iniciado pela primeira vez com esta versão do CLFS. Após este período de adoção de 90 dias ter caducado, o controlador passará automaticamente para o modo de imposição no próximo início, após o qual o CLFS espera que todos os ficheiros de registo contenham códigos de autenticação válidos. Tenha em atenção que este valor de 90 dias pode mudar no futuro.

Se um logfile não for aberto durante este período de adoção e, por conseguinte, não tiver sido automaticamente transitado para o novo formato, o utilitário fsutil clfs authenticate da linha de comandos pode ser utilizado para adicionar códigos de autenticação ao logfile. Esta operação requer que o autor da chamada seja um Administrador.

Impacto do utilizador

Esta mitigação pode afetar os consumidores da API CLFS das seguintes formas:

• Uma vez que a autenticação logfile é efetuada no tempo de abertura do logfile, o CLFS tem de ler todo o logfile do disco para validar os códigos de autenticação antes de as estruturas internas serem analisadas. Como resultado, as operações de abertura do logfile incorrem em E/S de leitura adicional proporcional ao tamanho do ficheiro de registo.

  • Um exemplo deste comportamento pode ser observado durante o início de sessão do utilizador e o encerramento do sistema. O Registo mantém um ficheiro de registo com suporte CLFS para o ramo de registo do utilizador (NTUSER.dat), que é aberto durante estas transições. Quando o logfile é aberto, a autenticação requer uma leitura completa do ficheiro de registo, o que resulta num aumento da E/S do disco durante o início de sessão e o encerramento.

• Uma vez que a chave criptográfica utilizada para tornar os códigos de autenticação exclusivos do sistema, os ficheiros de registo já não são portáteis entre sistemas. Para abrir um logfile criado num sistema remoto, um Administrador tem primeiro de utilizar o utilitário de autenticação fsutil clfs para autenticar o logfile com a chave criptográfica dos sistemas locais.

• Um novo ficheiro, com a extensão ".cnpf" será armazenado juntamente com o Ficheiro de Registo Binário (BLF) e os contentores de dados. Se o BLF para um ficheiro de registo estiver localizado em "C:\Users\User\example.blf", o respetivo "ficheiro de patch" deve estar localizado em "C:\Users\User\example.blf.cnpf". Se um ficheiro de registo não estiver fechado de forma limpa, o ficheiro de patch irá conter os dados necessários para que o CLFS recupere o ficheiro de registo. O ficheiro de patch será criado com os mesmos atributos de segurança que o ficheiro para o que fornece informações de recuperação. No máximo, este ficheiro terá o mesmo tamanho que "FlushThreshold" (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Parameters [FlushThreshold]).

• É necessário espaço adicional para armazenar códigos de autenticação. A quantidade de espaço necessário para os códigos de autenticação depende do tamanho do ficheiro. Veja a lista seguinte para obter uma estimativa sobre a quantidade de dados adicionais que serão necessários para os seus ficheiros de registo:

  • Os ficheiros de contentor de 512 KB requerem mais ~8192 bytes para códigos de autenticação.

  • Os ficheiros de contentor de 1024 KB requerem mais ~12288 bytes para códigos de autenticação.

  • Os ficheiros de contentor de 10 MB requerem mais ~90112 bytes para códigos de autenticação.

  • Os ficheiros de contentor de 100 MB requerem mais ~57344 bytes para códigos de autenticação.

  • Os ficheiros de contentor de 4 GB requerem mais ~2101248 bytes para códigos de autenticação.

• Devido ao aumento das operações de E/S para manter os códigos de autenticação, o tempo necessário para realizar as seguintes operações aumentou:

  O aumento do tempo de criação do logfile e da abertura do logfile depende inteiramente do tamanho dos contentores, com os ficheiros de registo maiores a terem um impacto muito mais evidente. Em média, a quantidade de tempo que demora a escrever num registo num ficheiro de registo duplicou.

  • criação do logfile

  • logfile aberto

  • escrita de novos registos

Configuração

As definições relacionadas com esta mitigação são armazenadas no registo em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication. Segue-se uma lista de valores de registo de chaves e a respetiva finalidade:

• Modo: o modo de funcionamento da mitigação

  • 0: A mitigação é imposta. O CLFS não conseguirá abrir ficheiros de registo com códigos de autenticação em falta ou inválidos. Após 90 dias a executar o sistema com esta versão do controlador, o CLFS transitará automaticamente para o modo de imposição.

  • 1: A mitigação está no modo de aprendizagem. O CLFS abrirá sempre os ficheiros de registo. Se um ficheiro de registo tiver códigos de autenticação em falta, o CLFS irá gerar e escrever os códigos no ficheiro (assumindo que o autor da chamada tem acesso de Escrita).

  • 2: Um Administrador desativou a mitigação.

  • 3: A mitigação foi desativada automaticamente pelo sistema. Um Administrador não deve definir o Modo para este valor, mas deve utilizar "2" se pretender desativar a mitigação.

• EnforcementTransitionPeriod: a quantidade de tempo, em segundos, que o sistema irá gastar no período de adoção. Se este valor for zero, o sistema não transitará automaticamente para a imposição.

• LearningModeStartTime: o carimbo de data/hora no qual o modo de aprendizagem começou no sistema. Este valor, em combinação com "EnforcementTransitionPeriod" determinará quando um sistema deve transitar para o modo de imposição.

• Chave: a chave criptográfica utilizada para criar códigos de autenticação (HMACs). Os administradores não devem modificar este valor.

Os administradores podem desativar completamente a mitigação ao alterar o valor modo para 2. Para prolongar o período de adoção da mitigação, um Administrador pode alterar EnforcementTransitionPeriod (segundos) para qualquer valor que escolha (ou 0 se quiser desativar a transição automática para o modo de imposição).

Atualizar Política de Grupo definição com o Editor de Política de Grupo Local

A Autenticação CLFS pode ser ativada ou desativada com a Definição de Política de Grupo:

1. Abra o Editor de Política de Grupo Local no Windows Painel de Controlo.
   
   

2. Em Configuração do Computador, selecione Modelo Administrativo > Sistema > Sistema sistema de ficheiros e, na lista Definições , faça duplo clique em Ativar/desativar a autenticação do ficheiro de registo CLFS.
   
   

3. Selecione Ativar ou Desativar e, em seguida, clique em OK. Se Não Configurado estiver selecionado, a mitigação está ativada por predefinição.
   
   

Atualizar a definição de Política de Grupo/MDM com Intune

Para atualizar Política de Grupo e configurar a Autenticação CLFS com Microsoft Intune:

1. Abra o portal do Intune (https://endpoint.microsoft.com) e inicie sessão com as suas credenciais.

2. Criar um perfil: 

   1. Selecione Dispositivos > Configuração do Windows >> Criar > Nova Política.

   2. Selecione Plataforma > Windows 10 e posterior.

   3. Selecione Tipo de perfil > Modelos.

   4. Procure e selecione Personalizado.
      
      

3. Defina um nome e uma descrição:
   
   

4. Adicione uma nova definição OMA-URI:
   
   

5. Editar definição OMA-URI: 

   1. Adicione um nome como ClfsAuthenticationCheck.

   2. Opcionalmente, adicione uma descrição.

   3. Defina o caminho OMA-URI para o seguinte:
      
      ./Vendor/MSFT/Policy/Config/FileSystem/ClfsAuthenticationChecking

   4. Defina o Tipo de dados como Cadeia.

   5. Defina o Valor como <ativado/> ou <desativado/>.

   6. Clique em Guardar.
      
      

6. Conclua a configuração restante de Etiquetas de âmbito e Atribuições e, em seguida, selecione Criar. ​​​​​​​

Alterações à API CLFS

Para evitar alterações interruptivas à API CLFS, os códigos de erro existentes são utilizados para comunicar falhas de verificação de integridade ao autor da chamada:

• Se CreateLogFile falhar, GetLastError devolverá o código de erro ERROR_LOG_METADATA_CORRUPT .

• Para ClfsCreateLogFile, o estado STATUS_LOG_METADATA_CORRUPT é devolvido quando o CLFS não verifica a integridade do ficheiro de registo.

Perguntas mais frequentes (FAQ)

Glossário

A proteção é um processo que ajuda a proteger contra acesso não autorizado, negação de serviço e outras ameaças ao limitar potenciais fraquezas que tornam os sistemas vulneráveis.

Os atributos de segurança são utilizados para armazenar informações e impor um controlo de acesso detalhado sobre recursos específicos.