Auditoria no Windows

https://www.flickr.com/photos/myxi/ / CC BY-NC-ND 2.0

Após ser questionado por vários clientes sobre auditoria no Windows, resolvi escrever sobre o assunto. Neste post o objetivo e esclarecer o que é uma politica de auditoria e quais são as melhores práticas. Em outros posts detalharei melhor como isso deve ser feito.

Hoje o mundo de TI é complexo, e a medida que a dependência da área de TI aumenta mais regras e processos são criados e maior a preocupação das empresas em relação a quem tem acesso aos dados. É justamente aqui que entra a auditoria em TI.

Não tenho a pretensão de conceituar auditoria em TI, pois existem diversas taxionomias de diferentes metodologias e autores. Entretanto, existe o consenso de que auditoria em TI é o processo de coletar e avaliar evidências. Seja em um sistema, atividades ou operação. Este post trata também da configuração do sistema para que se gere as evidências para que depois possa ser coletada e evaliada.

O primeiro passo é estabelecer uma política de auditoria no Windows. Isso significa definir quais evento são importantes e quais não são para que você possa gerar relatórios. Sugiro a leitura do documento Planning and Deploying Advanced Security Audit Policies

Existem nove diferentes categorias de eventos que definem os tipos que serão registrados no log de segurança.

As categorias são:

Account logon events: Os eventos de logon são gerados quando uma conta de usuário de domínio é autenticada em um controlador de domínio. O evento é registrado no log de segurança do controlador de domínio. Eventos de logon são gerados também quando um usuário local é autenticado em um computador local no log de segurança local. Os eventos de logoff de conta de usuários não são gerados.

Maiores informações em: https://technet.microsoft.com/en-us/library/cc787176(WS.10).aspx

Account management: Essas políticas geram eventos relacionados a inclusão, criação, alteração (incluindo de senha) e deleção dos usuarios e grupos do AD.

Maiores informações em: https://technet.microsoft.com/en-us/library/cc737542(WS.10).aspx

Directory service access: Para controladores de domínio, essa politica gera eventos para os objetos do AD que foram definidos com system access control lists (SACLs). O artigo https://technet.microsoft.com/en-us/library/cc773209(WS.10).aspx é um bom exemplo de como essa politica é aplicada.

Logon events: Logons que usam uma conta de domínio geram um evento de logon ou logoff na estação de trabalho ou servidor e geram um evento de logon no controlador de domínio. Quando o logon é local um evento é gerado apenas no log de segurança local da estação ou servidor.

Maiores informações em: https://technet.microsoft.com/en-us/library/cc787567(WS.10).aspx

Object access: Rastreia o acesso dos usuários quando acessam componentes do sistema operacional, como arquivos, diretórios, registry e impressoras, definidos por system access control lists (SACLs).

Maiores informações em: https://technet.microsoft.com/en-us/library/cc776774(WS.10).aspx

Policy change: Gera eventos de segurança quando são realizadas alterações nas configurações de segurança do computador, especificamente em: Audit policies, Trust policies e User rights

Maiores informações em: https://technet.microsoft.com/en-us/library/cc781549(WS.10).aspx

Privilege use: Audita cada instância de usuário quando o mesmo apresenta a sua credencias de acesso para algum recurso. Essa categoria tem que ser habilitada via registry key devido ao alto volume de informação que gera.

Maiores informações em: https://technet.microsoft.com/en-us/library/cc784501(WS.10).aspx

Process tracking: Gera eventos de auditoria quando um programa inicializa ou finaliza no computador auditado.

Maiores informações: https://technet.microsoft.com/en-us/library/cc775520(WS.10).aspx

System events: Audita os eventos de restart, shutdown ou quando um evento afeta a segurança do sistema operacional ou do security log.

Maiores informações em: https://technet.microsoft.com/en-us/library/cc782518(WS.10).aspx

-> IMPORTANTE! Os links acima mostram somente os eventos de auditoria do Windows Server 2003, a lista dos novos eventos de auditoria do Windows 7 e Windows Server 2008 R2 podem ser encontrados em formato Excel em: https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=3a15b562-4650-4298-9745-d9b261f35814.

Uma vez que se tenha os eventos gerados em cada um dos servidores, o próximo passo é coletar e armazenar os eventos do log de segurança em um único local.

A maneira rudimentar é desenvolver um programa em .NET utilizando as classe do System.Diagnostics Namespace para eventlog. (Eu fiz isso e posso dizer que a solução não é escalável e se torna complexa na geração de relatórios). A solução profissional é usar o ACS (Audit Collection Services). Poucos sabem que ele já vem no SCOM 2007 e tem como objectivo coletar e armazerar os eventos de segurança dos servidores.

O ACS é integrado ao Reporting Services do SQL e é altamente customizavel. Os relatórios interpretam os dados que estão dentro do evento permitindo uma granularidade e detalhes impressionantes.

O planejamento da implementação do ACS não é trivial como parece, pois deve se levar em conta na sua arquitetura: o crescimento da base de dados, o tempo em que um registro permanece na base, métodos para extrair relatórios de eventos que estão no backup, quantidade de eventos gerados por cada servidor para encontrar a melhor relação servidor x collector.

A novidade é que o ACS suporta coletar eventos das plataformas Unix e Linux. Com isso se tem em um único lugar a visão dos eventos de segurança de todo o seu ambiente.

Melhores práticas

Não habilite todas as opções de auditoria, saiba primeiro quais eventos são mais importantes e necessários pelo pessoal que vai realizar as auditorias.

Audite apenas os objetos que são realmente importantes. Não coloque auditoria em todos os arquivos de um servidor com milhões de arquivos acessados por milhares de usuários. Se possível, defina diretórios padrões aonde somentes os arquivos colocados lá serão auditados.

Contas de usuários e grupos devem ser auditadas com “Account Management”. Não é necessário implementar auditoria com “Directory service access”. Este último pode ser aplicável em OUs ou outros objetos do AD utilizando o Object Type e Attribute Type para restringir a regra ao objeto.

Habilite apenas o controle successful na auditoria. Acessos de falha são mais comuns do que parecem e frequentemente não indicam falhas de segurança, pois várias dessas falhas são requisições do sistema operacional e suas tentativas sucessivas, que na maioria das vezes não foram geradas diretamente pelo usuário. De acordo com a experiência de alguns colegas da Microsoft, auditar falhas só é valido para troubleshooting, não traz o mesmo benefício para segurança.

Sempre que possível aplique a regra de auditoria para o grupo "Everyone". Recomenda-se criar um grupo com as contas de serviço ou aplicações que geram muitos eventos de auditoria, para que seja criada uma regra evitando que essas contas sejam auditas, reduzindo o volume de informação que normalmente não é importante para a auditoria.

Outra forma de reduzir consideravelmente o volume de eventos armazenados é definir corretamente o tipo de acesso a ser auditado. De acordo com Eric Fitzgerald, um dos consultores mais ativos em ACS e auditoria em Windows, a relação de acesso de “read” em relação a de “write” (inclui alteração, deleção, mudança de permissão, etc.) é de 100:1. Dado esse fato, caso seja realmente necessário auditar os acessos de read, defina um lugar especifico onde esses objetos devam estar e habilite a auditoria de read somente lá.