Como auditar recursos em múltiplos ambientes Microsoft utilizando serviços da AWS

Por Neuton Assis, Enterprise Solutions Architect, AWS WWCS

Efetuar auditoria dos mais diversos recursos de uma organização demanda esforço. O desafio aumenta quando tentamos centralizar esses registros de auditoria, buscando obter uma observabilidade e controles centralizados, visando sustentar as tomadas de decisão, sejam elas automatizadas ou manuais.

Nesta postagem, vamos apresentar como é possível utilizar os serviços da AWS para auditar importantes recursos em um ambiente híbrido de workloads Microsoft, centralizando o fluxo de entrada de eventos e aplicando processo de ETL para geração de logs padronizados. Os logs padronizados são enviados para um serviço de análise de dados, que permite a retenção pelo período desejado e a criação de dashboards personalizados, permitindo uma visão centralizada do ambiente.

Visão geral da solução

O cenário de ambiente auditado que será apresentado é composto por:

• Uma floresta do Active Directory representando o ambiente on-premises, com um controlador de domínio hospedado em uma instância do serviço Amazon EC2.
• AWS Managed AD, um serviço de diretório gerenciado da AWS para o Microsoft Active Directory.
• Amazon FSx para Windows File Server, um serviço de armazenamento de arquivos totalmente gerenciado da AWS, compatível com Windows File Server.

Visão da arquitetura

Passos que serão apresentados

Neste blog, iremos demonstrar os seguintes tópicos:

• Configuração do domínio on-premises do Active Directory
• Criação de uma instância do AWS Managed Microsoft AD
• Configuração do Amazon FSx
• Configuração do Amazon OpenSearch Service
• Configuração da coleta de eventos
• Criação de dashboard no Amazon OpenSearch Dashboards
• Conclusão

Pré-requisitos

Para criação deste ambiente, você precisará de:

• Uma conta ativa na nuvem da AWS
• Conhecimento técnico em administração do Active Directory
• Conexão de rede entre seu ambiente e a sua conta na nuvem AWS

Caso ainda não tenha uma conexão rede entre o ambiente on-premises e a rede virtual da sua conta na nuvem, veja como estabelecer uma conexão de VPN com sua conta na AWS, a fim de estabelecer uma conexão de rede entre os dois ambientes.

Configure o domínio on-premises do Active Directory

Para o cenário apresentado, é necessário que você tenha previamente o ambiente on-premises e também sua extensão híbrida na nuvem AWS, que é o controlador de domínio em uma Amazon EC2, que faz parte do domínio on-premises. Caso contrário, crie uma instância apropriada de Windows Server no serviço Amazon EC2, ingresse o servidor no domínio on-premises e promova-o em seguida a um controlador de domínio.

Adicionalmente, crie registros de resolução de nomes no Amazon Route 53 Resolver, a fim de tornar possível a comunicação via DNS entre os diferentes domínios que você decidir.

Será necessário também criar um Group Policy Object ou Objeto de Política de Grupo (GPO) com as configurações de auditoria requeridas e aplicar sobre os controladores de domínio (OU Domain Controllers). Desta forma, as políticas de segurança locais de cada controlador serão habilitadas conforme requerido e o servidor estará apto a gerar eventos de auditoria quando ações forem realizadas no serviço de diretório.

Crie uma GPO e habilite as categorias de evento relacionadas ao serviço de diretório e objetos que deseja gerenciar. Veja os detalhes sobre como planejar e implantar alterações nas configurações de auditoria, baseado nas orientações da Microsoft.

Veja os detalhes do propósito de cada item das categorias em Configurações de Política de Auditoria de Segurança Avançada.

Para esta demonstração, foram habilitadas as categorias mencionadas na imagem abaixo:

A árvore de objetos do AD possui uma configuração de auditoria específica, semelhante às configurações possíveis de serem realizadas em uma estrutura de pastas. Identifique e aplique as configurações de auditoria que melhor se aplica ao seu caso de uso.

Para alterar seguindo as configurações de exemplo que utilizamos para esta demonstração, abra o ADSIEdit em um controlador de domínio e faça as alterações, conforme apresentadas abaixo:

1. Na raiz do domínio, clique com o botão direito do mouse e selecione “Properties”, ou o equivalente no idioma configurado.

2. Selecione a aba “Security” e clique no botão “Advanced”, depois selecione a aba “Auditing” e clique no botão “Add”.

3. Adicione o usuário “Everyone”, selecione o tipo “Success” e aplique em “This object and all descendant objects”.
4. Desmarque as opções de leitura que estavam selecionadas por padrão e marque as opções selecionadas conforme imagem abaixo. Note que, ao selecionar as opções indicadas abaixo, as demais serão automaticamente marcadas.

Crie uma instância do AWS Managed Microsoft AD

O AWS Managed Microsoft AD é um serviço de diretório totalmente gerenciado pela AWS, que permite ingressar instâncias Windows EC2, servidores Windows on-premises, usuários, grupos e diversos outros serviços da AWS como membros de um domínio do Active Directory. Isso torna possível todo o mecanismo de autenticação e controle de acesso oferecidos nativamente por esse serviço de diretório.

Siga estas orientações para criar um serviço de diretório gerenciado.

Observe os limites de utilização gratuito e as condições oferecidas para o AWS Managed Microsoft AD.

Caso queira aproveitar o repositório de identidade (usuários) já existente no domínio on-premises, é possível estabelecer uma relação de confiança entre os dois domínios, permitindo que usuários do domínio on-premises acessem recursos membros do domínio gerenciado da AWS.

Como se trata de um serviço que não é gratuito, lembre-se de mapear os recursos criados para exclusão posterior, a fim de não incorrer em cobranças desnecessárias. Consulte a página de preços do AWS Managed Microsoft AD para verificar os detalhes da utilização do limite gratuito (Free Tier) e a forma de precificação do serviço.

Configure o Amazon FSx

O Amazon FSx é um serviço gerenciado que permite que você inicie, execute e escale sistemas de arquivos de alto desempenho na nuvem com confiabilidade e segurança, tirando proveito de um amplo conjunto de recursos. Você pode escolher entre quatro sistemas de arquivos amplamente utilizados: NetApp ONTAP, OpenZFS, Windows File Server e Lustre.

Para efeito de demonstração do ambiente Microsoft auditado, iremos utilizar nesta postagem o Amazon FSx para Windows File Server.

Crie um servidor de arquivos compatível com Windows Server no Amazon FSx (como demonstrado neste link), habilitando a opção de auditoria de acesso a arquivos.

Como nos demais tópicos, mapeie os recursos criados para que seja possível excluí-los posteriormente. Veja os valores desse serviço na página de preços do Amazon FSx para Windows File Server.

Configuração do Amazon OpenSearch Service

O Amazon OpenSearch Service é um serviço gerenciado para pesquisa, monitoramento e análise em tempo real de dados comerciais e operacionais. Trata-se de um conjunto de pesquisa e análise de código aberto distribuído, derivado do Elasticsearch.

Oferece suporte a 19 versões do Elasticsearch, bem como recursos de visualização fornecidos pelo OpenSearch Dashboards e Kibana. Isso permite que você facilmente execute tarefas como a execução de análise de logs interativa, monitoramento de aplicações em tempo real, pesquisas de sites e muito mais.

Nesta postagem, vamos utilizar o Amazon OpenSearch Service para análise e visualização dos logs extraídos dos eventos que vieram dos ambientes monitorados, através do Amazon CloudWatch.

Caso ainda não possua, crie um domínio no Amazon OpenSearch Service.

Não esqueça de mapear os recursos criados para que seja possível removê-los após os testes. Verifique os detalhes sobre valores do serviço na página de preços do Amazon OpenSearch Service.

Configure a coleta de eventos

Instale e configure o agente do ClowdWatch no controlador de domínio, utilizando o AWS System Manager.

1. Altere o arquivo de configuração do CloudWatch para coletar eventos e métricas específicas e enviar os dados para a região desejada. O exemplo do arquivo de configuração a seguir está configurado para que o CloudWatch envie eventos para a região do Norte da Virgínea (us-east-1), para controladores de domínio em instâncias EC2:

{

"IsEnabled": false,

"EngineConfiguration": {

"PollInterval": "00:00:15",

"Components": [

{

"Id": "ApplicationEventLog",

"FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",

"Parameters": {

"LogName": "Application",

"Levels": "1"

}

},

{

"Id": "SystemEventLog",

"FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",

"Parameters": {

"LogName": "System",

"Levels": "7"

}

},

{

"Id": "SecurityEventLog",

"FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",

"Parameters": {

"LogName": "Security",

"Levels": "7"

}

},

{

"Id": "ETW",

"FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",

"Parameters": {

"LogName": "Microsoft-Windows-WinINet/Analytic",

"Levels": "7"

}

},

{

"Id": "IISLogs",

"FullName": "AWS.EC2.Windows.CloudWatch.CustomLog.CustomLogInputComponent,AWS.EC2.Windows.CloudWatch",

"Parameters": {

"LogDirectoryPath": "C:\\inetpub\\logs\\LogFiles\\W3SVC1",

"TimestampFormat": "yyyy-MM-dd HH:mm:ss",

"Encoding": "UTF-8",

"Filter": "",

"CultureName": "en-US",

"TimeZoneKind": "UTC",

"LineCount": "3"

}

},

{

"Id": "CustomLogs",

"FullName": "AWS.EC2.Windows.CloudWatch.CustomLog.CustomLogInputComponent,AWS.EC2.Windows.CloudWatch",

"Parameters": {

"LogDirectoryPath": "C:\\CustomLogs\\",

"TimestampFormat": "MM/dd/yyyy HH:mm:ss",

"Encoding": "UTF-8",

"Filter": "",

"CultureName": "en-US",

"TimeZoneKind": "Local"

}

},

{

"Id": "PerformanceCounter",

"FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",

"Parameters": {

"CategoryName": "Memory",

"CounterName": "Available MBytes",

"InstanceName": "",

"MetricName": "Memory",

"Unit": "Megabytes",

"DimensionName": "",

"DimensionValue": ""

}

},

{

"Id": "CloudWatchLogs",

"FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch",

"Parameters": {

"AccessKey": "",

"SecretKey": "",

"Region": "us-east-1",

"LogGroup": "DomainControllers-Log-Group",

"LogStream": "{ip_address}-{hostname}"

}

},

{

"Id": "CloudWatch",

"FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch",

"Parameters":

{

"AccessKey": "",

"SecretKey": "",

"Region": "us-east-1",

"NameSpace": "Windows/Default"

}

}

],

"Flows": {

"Flows":

[

"(ApplicationEventLog,SystemEventLog,SecurityEventLog),CloudWatchLogs",

"PerformanceCounter,CloudWatch"

]

}

}

}

2. Aplique o arquivo de configuração no servidor controlador de domínio a ser auditado, através da execução do comando AWS-ConfigureCloudWatch do AWS Systems Manager.
   • Para servidores que não estão na AWS, siga estas etapas de configuração.

Configure o diretório do AWS Managed AD para encaminhar os eventos gerados pelas instâncias para o CloudWatch. Logo depois, configure o encaminhamento de logs do CloudWatch Logs para o Amazon OpenSearch, para cada grupo de log gerado pelo agente do CloudWatch nos controladores de domínio nas instâncias EC2 e pelos serviços gerenciados (AWS Managed AD e Amazon FSx).

Customize a função Lambda gerada automaticamente após a configuração do encaminhamento de logs, para um processo de ETL personalizado. O nome da função Lambda gerada inicia com “LogsToElasticsearch_”, seguido do domínio do Amazon OpenSearch Service selecionado no momento da configuração do encaminhamento dos grupos de log.

Todos os grupos de logs configurados enviarão os logs para a mesma função Lambda, onde passarão por um processo centralizado de ETL.

Para este exemplo, utilizamos um código que consome um arquivo de configuração JSON, responsável por mapear os eventos gerados pelos ambientes monitorados, como o Microsoft Active Directory:

{

"captureAllEvents": false,

"windowsEvent":{

"default": {

"indexPrefixName": "auditlog-default",

"category": "Default Event Auditing",

"action": "{default}",

"eventDataMap": {

"user": "Event/EventData/Data/[0]",

"computerName": "Event/System/Computer",

"affectedResource": "Event/EventData/Data/[0]",

"detail": "Event/RenderingInfo/Message"

}

},

"4670": {

"indexPrefixName": "auditlog-fs",

"category": "Object Access",

"action": "Permissions on an object were changed",

"eventDataMap": {

"user": "Event/EventData/Data/[5]+\\+Event/EventData/Data/[4]",

"computerName": "Event/System/Computer",

"affectedResource": "Event/EventData/Data/[1]+\\+Event/EventData/Data/[0]",

"detail": "Event/RenderingInfo/Message"

}

},

"4726": {

"indexPrefixName": "auditlog-ad",

"category": "Active Directory Auditing",

"action": "{default}",

"eventDataMap": {

"user": "Event/EventData/Data/[5]+\\+Event/EventData/Data/[4]",

"computerName": "Event/System/Computer",

"affectedResource": "Event/EventData/Data/[1]+\\+Event/EventData/Data/[0]",

"detail": "Event/RenderingInfo/Message"

}

}

}

}

O arquivo JSON acima orienta o código sobre como fazer o mapeamento dos dados do evento para o novo formato de log, para aqueles tipos de dados que não estão sempre em um mesmo local nos eventos.

Os eventos do Windows chegam em formato XML até à função Lambda, onde tem as principais informações extraídas. Como a maior parte dos dados contidos no XML do evento não é mandatória para o propósito de conformidade em auditoria de sistema, é recomendado avaliar e limitar-se às informações necessárias ao seu caso de uso.

Isso diminuirá drasticamente o volume de dados a serem armazenados, somado também ao fato de que alguns eventos gerados podem ser completamente descartados, de acordo com o objetivo da auditoria.

Uma estrutura de log de auditoria precisa conter informações básicas sobre a ação realizada que permitam, por exemplo, responder perguntas como:

• Quem realizou a ação?
• Quando realizou a ação?
• O que fez?
• Onde a ação foi realizada?

Com isso em mente, abaixo temos um exemplo de log gerado a partir do ETL realizado, como demonstração:

{

"@timestamp": "2022-11-10T17:27:06.363Z",

"@user": "AnyCompany\\amznfsxaa72r7vf$",

"@computerName": "WIN-3N63JPN084X",

"@IP": null,

"@windowsEventID": "4724",

"@source": "10.0.1.108",

"@category": "User Account Management",

"@action": "An attempt was made to reset an account's password",

"@affectedResource": "AnyCompany\\amznfsxaa72r7vf$",

"@detail": "An attempt was made to reset an account's password.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-21-1808963962-929642046-3816600178-1611\r\n\tAccount Name:\t\tamznfsxaa72r7vf$\r\n\tAccount Domain:\t\tAnyCompany\r\n\tLogon ID:\t\t0x1B316C90B\r\n\r\nTarget Account:\r\n\tSecurity ID:\t\tS-1-5-21-1808963962-929642046-3816600178-1611\r\n\tAccount Name:\t\tamznfsxaa72r7vf$\r\n\tAccount Domain:\t\tAnyCompany",

"@auditSuccess": true

}

Criação de dashboard no Amazon OpenSearch

No Amazon OpenSearch Dashboards, crie visualizações customizadas, de acordo com a necessidade de visualização dos logs. Iremos demonstrar aqui a criação de duas visualizações, sendo a primeira em formato gráfico e a segunda no formato de lista.

Primeiramente, iremos criar um índice:

1. Para começar, abra o menu do Amazon OpenSearch e acesse “Stack Management”, na seção “Management”.

2. Selecione “Index Patterns” e clique sobre o botão “Create Index Pattern” para criar um novo padrão de índice.

3. Em “Index pattern name”, digite “auditlog*” e selecione “Next”.
4. Na seção seguinte, selecione o campo “@timestamp” e clique no botão “Create index pattern”.

Cria uma visualização de gráfico, no formato pizza:

1. Navegue até “Dashboard”, na seção “OpenSearch Dashboards”.

2. Clique em “Create dashboard” e, na página seguinte, clique em “Create new”. Selecione o tipo “Pie” para a visualização de um gráfico de pizza.

3. Selecione o índice criado no passo anterior.

4. Por precaução, certifique-se de que o intervalo de datas para exibição, no canto superior esquerdo da tela, esteja configurado para exibir dados dos último 30 dias.

5. Na seção “Buckets”, clique em “Add” e selecione “Split chart”.

6. Para “Aggregation”, selecione “Term” e, em “Field”, selecione “@source.keyword”.

7. Novamente na seção “Buckets”, clique em “Add” e selecione “Split slices”.

8. Para “Aggregation”, selecione “Term” e, em “Field”, selecione “@action.keyword”.

9. Clique no botão “Update” no canto inferior direito da tela e o gráfico será atualizado.
10. Não esqueça de salvar a visualização clicando no botão “Save” no canto superior direito da tela, definindo um nome significativo para a visualização criada. Save”, no canto superior direito da tela, definindo um nome significativo para a visualização criada.

Crie uma visualização em lista para visualizar os dados como preferir:

1. Na sessão “OpenSearch Dashboards”, selecione “Discover”.

2. Escolha o índice criado e, em “Available fields”, selecione os campos que deseja exibir na lista, clicando no ícone “+” que surge ao passar o mouse sobre o campo.

3. Para filtrar um valor de um campo que não deseja exibir no resultado da lista, passe o mouse sobre a célula que possui o valor e clique no ícone “–”.

Como se trata de um serviço que não é gratuito, lembre-se de mapear os recursos criados para exclusão posterior, a fim de não incorrer em cobranças desnecessárias. Consulte a página de preços do  Amazon OpenSearch Service para verificar os detalhes da utilização do limite gratuito (Free Tier) e a forma de precificação do serviço.

Conclusão

Esta solução apresenta como implementar observabilidade ao ambiente de workloads Microsoft, utilizando serviços nativos da AWS e reduzindo o custo de licenciamento.

Os eventos tratados no processo de ETL, alternativamente poderão ser encaminhados para um serviço de fila com tópicos, como o Amazon Simple Notification Service (Amazon SNS), viabilizando ações em tempo real, como análise comportamental e envio para sistemas SIEM (Security Information and Event Management), além do armazenamento na base do Amazon OpenSearch.

Sobre o autor

Neuton Assis é Arquiteto de Soluções na AWS  para o segmento de Enterprise. Antes disso, trabalhou por mais de 10 anos na arquitetura e desenvolvimento de softwares voltados para automação de atividades de TI, auditoria de sistemas e gestão de identidade e acesso, atuando principalmente em ambientes Microsoft. Atualmente, auxilia clientes e parceiros da AWS a terem sucesso na jornada para computação em nuvem.

Revisores

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 15 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias a fim de ajudar os clientes em seus desafios diários.

Ibrahim Cezar é Arquiteto de Soluções na AWS para o segmento de Enterprise. Builder, atua a mais de 15 anos no mercado de tecnologia, tendo experiência desde o desenvolvimento até a gestão. É entusiasta do Well-Architected Framework como ferramenta para avaliação e melhoria dos projetos na nuvem. Fora do trabalho, é um leitor voraz e participa ativamente de iniciativas open-source.