Cobertura especial: Windows Server 2008

Auditoria e conformidade no Windows Server 2008

Rob Campbell e Joel Yoker

Visão geral:

• Importância crescente da conformidade
• Compreendendo as alterações no ambiente
• Desafios de auditar eventos de segurança
• Aspectos técnicos da auditoria

No mundo da tecnologia da informação, as alterações são constantes. Se a sua organização de TI é como a maioria, você está sob crescente pressão para entender as alterações que ocorrem no ambiente. O impacto de erros administrativos e divulgações acidentais de dados aumenta na

mesma proporção que a complexidade e a escala dos ambientes de TI. A sociedade atual exige responsabilidade sobre tais eventos, por isso as organizações passaram a ser responsabilizadas legalmente pela guarda das informações sob seus cuidados.

Com isso, a auditoria de alterações no ambiente ganhou importância. Por quê? A auditoria fornece os meios para compreender e gerenciar alterações nos ambientes de TI atuais, que são grandes e altamente distribuídos. Neste artigo, abordaremos desafios comuns enfrentados pela maioria das organizações,o panorama de conformidade e regulamentação, algumas noções básicas de auditoria no Windows® e como a funcionalidade do Windows Server® 2008 e do ACS (Serviços de Coleta de Auditoria) do Microsoft® System Center Operations Manager 2007 pode complementar uma estratégia de auditoria abrangente.

Desafios de auditoria

Uma olhada rápida nas manchetes dos jornais mostra que a divulgação de dados está se tornando um problema cotidiano. Muitos desses incidentes envolvem ações legais, perdas financeiras e assuntos de relações públicas para as organizações responsáveis. A capacidade de explicar quais alterações ocorreram ou identificar problemas rapidamente é fundamental para reduzir o impacto dos incidentes de divulgação de dados.

Por exemplo, digamos que a sua organização é responsável pelo gerenciamento de informações de identificação pessoal (PII) de uma determinada base de clientes. Embora haja várias formas de proteger as informações contidas nos sistemas que você gerencia, o comprometimento pode acontecer mesmo assim. A auditoria apropriada pode permitir que a organização saiba exatamente quais sistemas foram comprometidos e, talvez, quais dados foram perdidos. Sem a auditoria, o impacto da perda de dados pode ser muito maior, principalmente porque não haveria como estimar a extensão do comprometimento.

Então, por que as organizações de TI já não estão fazendo isso? O fato é que a maioria delas não compreende plenamente os aspectos técnicos da auditoria. Embora a diretoria geralmente entenda conceitos como backup e restauração, a complexidade inerente de auditar alterações no ambiente é uma mensagem difícil de transmitir. Com isso, é comum surgirem perguntas sobre auditoria após um incidente significativo. Por exemplo, a auditoria básica pode estar habilitada, mas se, por falha no planejamento, o sistema não estiver configurado para auditar uma determinada alteração, essa informação não será coletada.

Além disso, os eventos de segurança auditados têm alguns problemas inerentes com os quais os profissionais de TI devem lidar. Uma dessas dificuldades é a distribuição de sistemas dentro dos grandes ambientes computacionais atuais, o que representa desafios de coleta e agregação consideráveis, já que as alterações podem ocorrer em qualquer sistema ou conjunto de sistemas a qualquer momento. Isso leva a outro desafio: correlação. A conversão de relações entre eventos em um ou vários sistemas quase sempre é necessária para atribuir significado real ao que está acontecendo.

Outro problema é que a auditoria geralmente transcende as fronteiras organizacionais tradicionais. Diferentes estruturas de equipe ou de organização existem por diferentes motivos e pode não ser fácil uni-las. Muitas organizações têm uma equipe de serviços de diretório, uma equipe de infra-estrutura de mensagens e uma equipe de desktops, mas provavelmente há apenas uma equipe de segurança responsável por todas essas áreas. E mais: os funcionários de segurança dedicados da sua organização podem não estar fisicamente presentes em todas as localidades. Por exemplo, as filiais costumam ter uma única pessoa ou uma equipe pequena para todas as tarefas, inclusive o gerenciamento de log de eventos da Segurança.

Finalmente, só a quantidade de eventos já é desafiadora. Os eventos de segurança auditados ocorrem com volumes muito maiores que outros tipos de log de eventos. O número de eventos coletados dificulta a retenção e a análise dos logs de modo eficiente. Além disso, ao estipular requisitos de retenção para essas informações, as regulamentações propostas e as atuais não ajudam a reduzir esse fardo nas infra-estruturas computacionais.

No passado, a auditoria de acesso a informações podia ser resumida como um desejo de saber e uma tentativa de se proteger. Hoje em dia, com as organizações – e a diretoria que responde por elas – sendo legalmente responsabilizadas pela perda de informações ou pela falta de medidas preventivas adequadas, é fundamental que os administradores de TI se familiarizem com as regulamentações aplicáveis a seus ambientes. No caso de empresas globais, os desafios são ainda mais complexos, já que cada país tem suas próprias regulamentações no tocante a informações e à proteção delas. Alguns exemplos de legislação já existente de conformidade a normas estão listados na Figura 1, juntamente com as respectivas expectativas para as organizações de TI.

Figure 1 Regulamentações e o que elas significam para profissionais de TI

Dada toda a pressão legal, o que se espera que os profissionais de TI façam? Os técnicos e gerentes de TI precisam criar uma história clara e concisa para apresentar a quem está dentro e fora da organização. Isso inclui o desenvolvimento de uma estratégia de auditoria apropriada, o que requer medidas pró-ativas e investimentos. O principal conceito aqui é que a auditoria não pode ser uma reflexão tardia no design, como quase sempre ocorre.

Desafios de TI desse tipo normalmente podem ser resolvidos por uma combinação de pessoal, processos e tecnologias. Com a auditoria, o que importa é o processo. Portanto, a primeira etapa deve ser dominar as noções básicas para poder responder às necessidades da organização e aos requisitos de conformidade a normas. Vamos abordar alguns dos fundamentos de auditoria no Windows e depois nos aprofundaremos nas alterações no Windows Server 2008 e no Windows Vista®.

Auditando eventos de segurança

Todos os eventos auditados são registrados no log de eventos da Segurança do Windows. Em geral, esses eventos não são podem ser acionados imediatamente e quase sempre são de natureza informativa. Cada evento registra um simples Êxito na Auditoria ou Falha na Auditoria para um tipo específico de acesso que tenha ocorrido. Isso é diferente dos logs de eventos do Sistema e do Aplicativo, nos quais os problemas podem ser identificados através da codificação de cores (dica: procure os eventos em vermelho para ir direto ao problema).

O log de eventos da Segurança é diferente porque é comum os eventos auditados serem ocultados pelo volume e, conforme observado anteriormente, a correlação de dados de segurança pode representar um desafio significativo. Mesmo uma simples violação de dados em um único sistema é problemática. O log de eventos da Segurança precisaria ser analisado para identificar qual conta foi usada para acessar os dados, exigindo que um administrador rastreasse o log para tentar localizar a conta. Infelizmente, os ataques sofisticados de hoje em dia costumam ser coordenados e distribuídos, tornando esse tipo de análise bem difícil para a vítima.

Isso posto, é importante compreender os elementos principais que permitem o registro de informações no log de eventos da Segurança no Windows: Diretiva de Auditoria e SACLs (listas de controle de acesso do sistema). As Diretivas de Auditoria são configurações para um computador local feitas através da Diretiva de Grupo ou da Diretiva de Segurança Local e definem a coleção de eventos de êxito e de falha para tipos específicos de acesso. Estas principais categorias de Diretiva de Auditoria estiveram presentes no Windows durante muitos anos (informações sobre a nova Diretoria de Auditoria Granular do Windows Server 2008 mais adiante):

• Eventos de logon de conta de auditoria
• Auditoria de gerenciamento de contas
• Auditoria de acesso ao serviço de diretório
• Eventos de logon de auditoria
• Acesso a objetos de auditoria
• Alteração de diretiva de auditoria
• Uso de privilégios de auditoria
• Auditoria de controle de processos
• Eventos de sistema de auditoria

A necessidade de definir Diretiva de Auditoria e suas respectivas categorias normalmente é bem compreendida pela maioria das organizações de TI, mas a Diretiva de Auditoria representa apenas uma parte da solução. As SACLs também desempenham um papel significativo na implementação de um plano de auditoria holístico. Duas categorias de Diretoria de Auditoria específicas – Auditoria de acesso ao serviço de diretório e Acesso a objetos de auditoria – são totalmente dependentes das SACLs para retornar informações sobre o log de eventos da Segurança. Então, o que são exatamente as SACLs?

Cada objeto – arquivo, Registro ou serviço de diretório – tem uma ACL (lista de controle de acesso) com uma ou mais ACEs (entradas de controle de acesso) divididas em dois tipos: uma DACL (lista de controle de acesso discricionário) e uma SACL (a qual define configurações que registram em log as tentativas de acesso a objetos protegidos). Cada ACE em uma SACL determina os tipos de tentativas de acesso por um objeto de confiança especificado que deverão ser registrados no log de eventos da Segurança. As ACEs definem o log de tentativas de acesso com êxito e/ou falha em relação a objetos especificados. A Figura 2 mostra o uso de uma SACL em um objeto para gerar eventos para tipos específicos de acesso.

Figura 2** Usando uma SACL em um objeto **(Clique na imagem para aumentar a exibição)

A compreensão da relação entre Diretiva de Auditoria e SACLs é fundamental, pois a configuração é necessária para capturar os eventos auditados "corretos", já que está relacionada a alterações no ambiente. Conforme mencionado, as diretivas Auditoria de acesso ao serviço de diretório e Acesso a objetos de auditoria permitem a geração de auditorias no log de eventos da Segurança apenas para essas categorias específicas, mas os eventos só serão gerados se um objeto tiver uma ACE de auditoria configurada em sua SACL. Depois de tudo implementado, os eventos de segurança são gerados pela autoridade de segurança local do Windows (LSA) e gravados no log de eventos da Segurança.

Os eventos consistem em duas áreas distintas: o cabeçalho, que é estático e predefinido para cada identificador de evento (ID do Evento), e o corpo, que é dinâmico e contém detalhes diferentes para diferentes eventos. A Figura 3 mostra esses dois elementos em um exemplo de evento de segurança do Windows Server 2008. Importante para a fase de análise de qualquer projeto de auditoria, a compreensão desses componentes de eventos é de particular interesse com respeito ao modo de retorno das informações em ferramentas como o ACS.

Figura 3** O cabeçalho e o corpo de um evento auditado **(Clique na imagem para aumentar a exibição)

Windows Eventing 6.0

Agora que compreendemos o problema, como o Windows Server 2008 ajuda as organizações a enfrentarem os desafios? O Windows Server 2008 é a primeira versão de servidor a conter o novo subsistema de eventos Windows Eventing 6.0, que melhorará expressivamente o panorama em torno do gerenciamento de eventos de segurança. Observe que, embora o foco aqui seja o Windows Server 2008, 95% do novo conjunto de recursos também existe no Windows Vista.

Uma das novidades no Windows Eventing 6.0 que muitas pessoas logo observarão é a interface do usuário. O novo snap-in MMC (Console de Gerenciamento Microsoft) de Visualizar Eventos oferece uma excelente página Visão Geral e Resumo, Modos de Exibição Personalizados flexíveis e Texto Explicativo amplamente aprimorado. Essas interfaces podem ajudar o usuário final ou administrador do sistema a localizar informações de eventos e configurar importantes opções de log de eventos diretamente no próprio Visualizar Eventos.

Um grande problema que costumava impactar os dados de segurança dentro do log de eventos era a retenção de dados. Anteriormente, o subsistema Log de Eventos (incluindo todos os logs) possuía limites de escalabilidade. Caso eles fossem excedidos, o subsistema inteiro parava de registrar eventos em log. Porém, esse não é o caso no Windows Eventing 6.0, e agora as organizações estão limitadas apenas pela quantidade de espaço em disco disponível. Mas observe que a análise de logs de eventos muito grandes pode ser complicada, já que cada entrada de log individual deve ser avaliada durante a filtragem. Por isso, é certo que você vai querer manter seu log em um tamanho gerenciável.

Obviamente, isso ainda deixa para o administrador de TI a tarefa de desenvolver um plano de arquivamento para logs de eventos em relação a muitos sistemas. Para ajudar a fazer isso no nível do servidor local, um recurso exposto no Windows Eventing 6.0 é a opção "Arquivar o log quando estiver cheio; não substituir eventos". Nas versões anteriores do Windows, essa opção podia ser definida através de modificação no valor do Registro AutoBackupLogFiles. Embora isso forneça um mecanismo para arquivo morto local de logs, não oferece uma solução para o gerenciamento desses arquivos ao longo do tempo, nem resolve o problema de agregação que ocorre em vários sistemas. Os Serviços de Coleta de Auditoria não oferecem uma solução completa para isso. Falaremos sobre esse assunto mais adiante.

A nova interface é apenas o começo. A verdadeira força do Windows Eventing 6.0 é o novo serviço Log de Eventos do Windows e o mecanismo subjacente baseado em XML. São esses componentes que geram as opções de gerenciamento, acessibilidade e escalabilidade aprimoradas. Os eventos passam a ser armazenados em um formato XML flexível que permite soluções personalizadas capazes de canalizar essas informações nativamente.

O Windows Eventing 6.0 também possibilita associar ações administrativas a eventos específicos. Ele faz isso integrando o serviço Coletor de Eventos do Windows ao Agendador de Tarefas para fornecer eventos baseados em tarefas. Esse é um novo paradigma do Agendador de Tarefas, que antes era limitado a eventos disparadores baseados em tempo. O assistente "Anexar Tarefa a este Evento" (disponível no menu de contexto de qualquer evento no Visualizar Eventos do Windows Server 2008) proporciona uma maneira fácil de iniciar um programa, enviar um email ou exibir uma mensagem sempre que um evento específico é registrado em log. Isso pode ser muito útil quando se tenta identificar ações específicas em andamento no ambiente que podem ser isoladas para um evento de segurança específico. Por exemplo, se você estiver auditando alterações na chave do Registro "Schema Update Allowed" em seus controladores de domínio, poderá criar uma tarefa que envie um email para administradores de segurança específicos a fim de notificá-los quando essa chave do Registro for modificada.

Além da nova capacidade de coletar e armazenar um grande número de entradas de evento, agora você também pode controlar melhor quais eventos são registrados no log de eventos. Isso é realizado através de um novo recurso chamado Diretoria de Auditoria Granular (GAP). Nas versões anteriores do Windows, era comum as nove categorias amplas de auditoria resultarem em sobrecarga de eventos. Agora, essas categorias de nível superior podem ser controladas por 50 subcategorias granulares, cada uma representando um subconjunto relacionado de eventos.

Isso permite filtrar informações não-críticas do log de eventos sem perder a visibilidade no nível de categoria. Por exemplo, se você quiser monitorar alterações em um determinado sistema apenas no Registro, mas não no sistema de arquivos, a única opção anteriormente era relatar êxito ou falha na categoria Acesso a Objeto. Com o GAP, é possível filtrar subcategorias como Sistema de Arquivos, Serviços de Certificação e Compartilhamento de Arquivos e só relatar eventos na subcategoria Registro. Para explorar as subcategorias do GAP em um sistema do Windows Server 2008, você deve executar o comando Auditpol a partir de um prompt de comando elevado. Para listar as subcategorias do GAP disponíveis, digite:

auditpol /list /subcategory:*

Para obter uma lista de subcategorias do GAP configuradas em seu sistema, digite:

auditpol /get /category:*

Observe que o GAP não pode ser configurado por meio da interface do usuário de Diretiva de Grupo padrão e deve ser gerenciado através de auditpol.exe. O artigo da Base de Dados de Conhecimento em support.microsoft.com/kb/921469 fornece diretrizes sobre como implantar configurações do GAP através da Diretiva de Grupo para subsistemas do Windows Server 2008 e do Windows Vista.

O Windows Server 2008 também pode capturar os valores antigos e novos dos tipos específicos no log de eventos da Segurança. Nas versões anteriores do Windows, o subsistema de auditoria só registrava em log o nome do valor do Registro ou do atributo de objeto do Active Directory® que tinha sido alterado, e não o valor anterior e o atual do atributo. Esse novo recurso se aplica aos Serviços de Domínio Active Directory, ao Active Directory Lightweight Directory Services e ao Registro do Windows. Com a habilitação de Êxito na Auditoria ou Falha na Auditoria nas subcategorias de "Registro" ou "Alterações no Serviço de Diretório" e a definição das SACLs associadas, os eventos detalhados serão gerados no log de eventos para ações nesses objetos. Isso pode ser feito com o uso dos seguintes comando auditpol:

auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service     
    Changes" /success:enable

No caso de alterações no Registro, elas aparecem como eventos com a identificação 4657, como mostra a Figura 4.

Figura 4** Antes e depois de uma alteração no Registro **(Clique na imagem para aumentar a exibição)

Este recurso é particularmente útil quando se tenta rastrear alterações em objetos do Active Directory. No caso de Alterações no Serviço de Diretório, elas aparecem em um par de eventos com a identificação 5136, como mostra a Figura 5. Cada evento tem um serviço de diretório de objeto, de atributo e de operação no corpo do evento. Para alterações em atributos com dados existentes, vemos duas operações: Valor Excluído e Valor Adicionado. Para atributos que não tenham sido populados, só veríamos a operação Valor Adicionado quando os dados fossem gravados nesse atributo. Por exemplo, quando uma operação de modificação é executada com êxito em um atributo de um objeto de usuário, como telephoneNumber, o Active Directory registra em log o valor anterior e o atual do atributo em entradas detalhadas do log de eventos.

Figura 5** Antes e depois de um evento Alterações no Serviço de Diretório **(Clique na imagem para aumentar a exibição)

Se um novo objeto for criado, os valores dos atributos que foram populados na época da criação do objeto serão registrados em log. Se um objeto for movido dentro de um domínio, o novo local e o anterior (na forma do nome distinto) serão registrados. Esse recurso "antigo e novo" é habilitado por padrão quando as configurações de Diretiva de Auditoria apropriadas são implementadas. Se você quiser manter um atributo em sigilo (como alterações no número de identificação dos funcionários, por exemplo), poderá excluir especificamente os atributos fazendo uma simples modificação de esquema. Modificando a propriedade searchFlags do atributo no esquema para 0x100 (valor 256 -NEVER_AUDIT_VALUE), como mostra a Figura 6, o evento Alterações no Serviço de Diretório não será gerado quando as alterações no atributo ocorrerem.

Figura 6** Excluindo um atributo de Alterações no Serviço de Diretório **(Clique na imagem para aumentar a exibição)

Finalmente, um dos novos recursos incríveis do Windows Eventing 6.0 é Inscrições de Eventos. Como mencionado anteriormente, o acesso ao log de eventos e sua análise é uma tarefa essencial de administração do sistema. Esse novo recurso permite encaminhar eventos entre sistemas. Ele consiste em um Coletor de Eventos que agrupa eventos e Fontes de Evento configurados para encaminhar eventos para hosts especificados. A capacidade de consumir eventos é fornecida pelo serviço Coletor de Eventos do Windows (novo no Windows Eventing 6.0), e a funcionalidade de assinante está integrada ao serviço Log de Eventos do Windows. Um coletor pode ser configurado para agrupar eventos de muitas fontes de evento, que podem ser os sistemas Windows Server 2008 ou Windows Vista.

Todos os dados coletados de fontes de evento residem em um Log de Eventos distinto, chamado Eventos Encaminhados (ForwardedEvents.evtx) e são gerenciados pelo serviço Log de Eventos no coletor. A configuração nos dois pontos de extremidade (coletor e fonte) é necessária e pode ser automatizada (winrm quickconfig –q na fonte; wecutil qc /q no coletor). É importante observar que esse recurso de inscrição de eventos não foi projetada para empresas ou para substituir sistemas que entregam eventos a um banco de dados externo.

Um exemplo de onde esse recurso pode ser aproveitado é uma pequena web farm. Suponha que você tem um conjunto pequeno de sistemas associado a um determinado site (inclusive servidores Web e servidores SQL). Esses sistemas podem consolidar as informações do seu log de eventos da Segurança em um único sistema usando o novo recurso Inscrições de Eventos. Ambientes maiores normalmente requerem um conjunto de ferramentas mais avançado para consolidação de log de eventos.

Serviços de Coleta de Auditoria

Considerando todos os novos recursos do Windows Server 2008, a solução real para gerenciamento a longo prazo e arquivamento de informações do log de eventos da Segurança reside em um banco de dados centralizado de informações de auditoria. Os Serviços de Coleta de Auditoria são um dos principais recursos do System Center Operations Manager 2007. O ACS fornece um mecanismo para o encaminhamento, a coleta, o armazenamento e a análise de dados de eventos de segurança. Os eventos de segurança são coletados quase em tempo real e armazenados em um repositório central do SQL. O ACS também oferece às organizações um método de conceder acesso de privilégio mínimo para auditar informações, já que não é necessário nenhum acesso físico aos sistemas que realmente estão sendo auditados. Vejamos como o ACS funciona.

O ACS possui três componentes principais. O primeiro é o Encaminhador, que é a parte do agente do Operations Manager que transmite os dados do log de eventos do cliente para a infra-estrutura do ACS. Os encaminhadores transmitem dados para o segundo componente, o Coletor, que é o ouvinte do servidor. Os Encaminhadores ACS se conectam pela porta TCP 51909 a fim de se comunicarem com o Coletor atribuído de forma segura. Antes da transmissão, os dados do log de eventos são normalizados no XML, o que significa que o excesso de informações será removido e as informações de eventos serão resumidas em campos mapeados com base em informações de cabeçalho e de corpo específicas do evento. Quando as informações chegam ao coletor, elas são enviadas para o terceiro e último componente – o banco de dados ACS. Ele se torna o repositório para armazenamento a longo prazo de informações de eventos de segurança. Depois de armazenadas, as informações podem ser extraídas através de consultas SQL ou processadas por meio de relatórios HTML usando o SQL Server® Reporting Services. O ACS fornece três exibições padrão, como mostra a Figura 7.

Figure 7 Exibições do ACS

Do ponto de vista de desempenho, um único coletor ACS pode processar um pico máximo de 100.000 eventos por segundo e um número máximo constante de 2.500 eventos por segundo. Para fins de planejamento, um único coletor ACS pode dar suporte a até 150 controladores de domínio, 3.000 servidores membros ou 20.000 estações de trabalho com base nas configurações de Diretiva de Auditoria padrão. Em um cenário real testado, cerca de 150 controladores de domínio mostraram um máximo de aproximadamente 140 eventos por segundo, com um pico médio de 500.000 eventos por hora. Em apenas 14 dias (a configuração de retenção padrão do ACS), mais de 150 GB de dados de eventos de segurança foram armazenados no banco de dados do SQL Server. Obviamente, uma Diretiva de Auditoria mais agressiva e a configuração SACL associada irão gerar ainda mais dados (por hora, por dia e geral).

O importante a perceber aqui é que, com esse volume de dados, seria impossível qualquer ser humano analisar cada evento em um grande ambiente corporativo normal. Por outro lado, as organizações não devem temer os números apresentados aqui. A compreensão das alterações em andamento no ambiente impacta a análise de uma grande quantidade de dados.

É aí que o ACS faz diferença. Através do SQL Server Reporting Services e do ACS, é possível transformar problemas que normalmente jazem enterrados no log de eventos da Segurança em algo facilmente identificável, como os eventos codificados por cores encontrados no log de eventos do Aplicativo. Embora o ACS inclua um conjunto de relatórios padrão, é simples estendê-los para atender às necessidades específicas do ambiente.

Considere o seguinte cenário: devido à sensibilidade das relações de confiança externas no ambiente, a diretoria pediu que desenvolvêssemos um relatório detalhando a criação de Relações de Confiança do Active Directory. Após um pouco de pesquisa, sabemos que, quando uma Relação de Confiança é criada, um objeto trustedDomain é gerado no contêiner cn=System dentro do contexto de nomeação de domínio específico no Active Directory. Depois de editar a SACL nesse contêiner para auditar a criação bem-sucedida de qualquer objeto de domínio confiável, poderemos capturar eventos de segurança sempre que um objeto desse tipo for criado. Isso é processado em um evento 566 no log de eventos da Segurança no controlador de domínio em que a criação de relação de confiança foi executada. Podemos então escrever uma consulta SQL simples para recuperar essas informações do ACS:

select * from AdtServer.dvAll 
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc

Para compilar esses dados em um relatório, use a versão do Visual Studio® 2005 incluída no SQL Server 2005 Reporting Services, que é específica para o desenvolvimento de relatórios. Após a conclusão do assistente, será fácil criar relatórios semelhantes ao exibido na Figura 8. E mais: qualquer alteração no ambiente que possa ser representada no log de eventos da Segurança pode ser resumida em um relatório com aparência bem semelhante.

Figura 8** Exemplo de relatório do ACS **(Clique na imagem para aumentar a exibição)

Desenvolvendo um plano de auditoria

Agora que compreendemos os desafios e os aspectos legais e técnicos da auditoria, como os administradores de TI devem proceder para desenvolver um "plano de auditoria" para a organização deles? O desenvolvimento de uma diretiva de auditoria abrangente é um processo em várias etapas. A primeira é determinar o que deve ser auditado. Isso inclui analisar o ambiente e determinar que tipos de eventos e alterações devem gerar auditorias. Pode incluir itens simples (como bloqueios de conta, alterações em grupos confidenciais, criação de relação de confiança) ou alterações complexas, como modificações de elementos de configuração em aplicativos no ambiente. O principal aqui é que a diretoria deve se envolver na determinação do "que" em um plano de auditoria. Este exercício precisa ser feito no papel e deve ser repetido em intervalos regulares, e não somente após incidentes significativos.

A segunda etapa envolve identificar como as informações de auditoria relativas a alterações específicas são retornadas na forma de eventos de segurança. Às vezes, essas informações estão cifradas e ilegíveis. Antes da implementação, devem ser estabelecidas correlações entre eventos de segurança e várias ações para entender o que esses eventos significam na realidade. Após um incidente não é hora de descobrir as relações entre eventos e ações.

A terceira etapa é quando o pneu encontra a estrada, ou seja, quando você implementa sua Diretiva de Auditoria e as SACLs. Conforme discutido anteriormente, você precisará definir as configurações da Diretiva de Auditoria (para habilitar a geração de eventos de segurança) e as SACLs (para gerar trilhas de auditoria referentes a ações associadas) no diretório, no sistema de arquivos e no Registro para obter um panorama completo das alterações nessas áreas.

Tudo isso nos conduz à quarta e última etapa – coleta, disparo e análise. Dependendo do tamanho e das necessidades da sua organização, eles podem ser cobertos pelos recursos nativos do Windows Server 2008 ou por soluções avançadas, como a funcionalidade Serviços de Coleta de Auditoria do System Center Operations Manager. Um erro comum cometido pela maioria das organizações é configurar apenas a Diretiva de Auditoria, sem definir as SACLs. A última etapa é toda sobre a implementação de uma solução de tecnologia para relatar e compartilhar dados com os participantes dentro da organização. Como mencionado anteriormente, boa parte das organizações tem uma entidade estabelecida responsável pela segurança, e um plano de auditoria precisa ser estruturado em torno dos elementos organizacionais existentes para ser eficaz. O principal nesta última etapa é coletar e apresentar informações de forma clara a todos os responsáveis pela compreensão das alterações no ambiente.

A maior parte das organizações de TI está à distância de um evento significativo de meramente pensar sobre um plano de auditoria abrangente até realmente precisar de um. Em comparação com as plataformas anteriores, o Windows Server 2008 fornece mecanismos avançados para a coleta e análise de dados de eventos de segurança. Tecnologias avançadas de coleta e relatório como o ACS expõem problemas antes ocultos pela distribuição e pelo volume de eventos, tornando essas alterações imediatamente óbvias.

Como a maioria dos problemas de TI, o processo é o principal desafio. Configuração e análise adicionais são sempre necessárias para capturar o que os gerentes de TI esperam, por isso o desenvolvimento de uma compreensão profunda dos requisitos do ambiente e dos recursos da plataforma do Windows lhe permitirão responder a esses desafios de cabeça erguida. Boa sorte!

Rob Campbell e Joel Yoker Rob Campbell é especialista técnico sênior e Joel Yoker é consultor sênior da equipe Microsoft Federal. Rob e Joel estão concentrados no desenvolvimento e na implantação de soluções de segurança para clientes do governo federal dos Estados Unidos.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..