Já a algum tempo que o OMS é uma ferramenta que sempre abordo em clientes e eventos.

É um produto muito bom, com analises ricas e que evoluiu bastante neste ultimo ano, chegando a ser o produto que muitos acham que substituirá no futuro o System Center.

O que mudou na interface?

A interface anterior era mais simples e em um portal a parte como está no post abaixo:

http://www.marcelosincic.com.br/post/Adquirindo-e-Licenciamento-o-Azure-OMS-Operation-Management-Suite.aspx

Agora a interface é integrada no painel do Azure, permite criar novos dashboards facilmente. Alem disso é possivel acessar individualmente cada um dos monitores.

Com essa integração na interface do Azure ficou muito mais fácil e funcional.

E como ficou o licenciamento?

No post onde já havia abordado o OMS falamos sobre a aquisição que era complexa pois cada modulo fazia parte de um bundle, e cada bundle se soluções era pago separado. Havia a opção de comprar por nó ou por upload de log, mas havia limitação de soluções e modulos no modelo de pagamento por upload.

Agora ficou muito mais fácil, só existe um modo de cobrança que é por upload de dados.

Ou seja, agora você pode pagar pelo tamanho dos logs que envia, o que é bem mais prático e simples!

https://azure.microsoft.com/pt-br/blog/introducing-a-new-way-to-purchase-azure-monitoring-services/

Se não utiliza o Log Insights por não entender como pagar, agora ficou simples e bem mais barato!

Já falamos anteriormente sobre o Microsoft ATA (Advanced Threat Analytics) em http://www.marcelosincic.com.br/post/Microsoft-Advanced-Thread-Analytics-(ATA).aspx

Agora houve uma grande atualização com a versão 9 que tornou o ATA mais leve em demanda de recursos e visualização dos reports.

Porem, durante a migração é possivel que ocorram perdas de conexão ao MongoDB e ser necessário fazer o backup e restore.

O mesmo processo talvez seja necessário quando se troca de servidor ATA.

Importante: Os dados do Security Log do Windows é enviado ao Machine Learning para gerar os incidentes e alertas, mas ficam hospedados localmente. Portanto se perder o servidor não terá mais os reports e incidentes já registrados.

Realizando o Backup do ATA

Para fazer o backup da configuração do ATA é utilizado a cópia do arquivo SystemProfile_yyyymmddhhmm.json que fica na pasta de instalação do ATA em um subdiretório Backup junto com as ultimas 300 cópias dos dados.

Esse arquivo SystemProfile é a base de dados do MongoDB em formato JSON, eliminando a necessidade de fazer backup a partir do Atlas ou outra ferramenta especifica para administração do MongoDB. Isso é muito bom, pois não é comum conhecermos adminsitração do MongoDB.

Para funcionar deve-se ter a cópia do certificado usado para criptografia do arquivo JSON, que é gerado durante a instalação (Self-signed).

A cópia do certificado só precisa ser feita uma vez, abra o console do MMC com o snap-in Certificados e encontre o certificado de nome Central do ATA na área de certificados Pessoas em Local Machine.

Com estes passos temos o backup das configurações do servidor que são o JSON e o certificado. Mas e os dados do ATA?

Para fazer backup do ATA é necessário como já falado conhecer as ferramentas do MongoDB e talvez você deva pensar se precisará deles uma vez já resolvidos.

Se a sua necessidade é manter os alertas e incidentes, siga a documento em https://docs.mongodb.com/manual/core/backups/ de como fazer backups da base.

Realizando o Restore do ATA

A parte de restore do ATA em um novo servidor ou configuração de uma nova versão é um pouco mais complicado que o backup que é bem simples.

Primeiro é necessário importar o certificado exportado no passo anterior na mesma árvore da qual fez no passo anterior.

Em seguida é necessário reinstalar normalmente o novo servidor ATA com o mesmo nome e IP anterior e no momento que ele pedir o certificado desativar a opção Create Self-signed” para escolher o certificado original.

Em sequencia precisamos parar o serviço Centro ATA para podermos abrir o MongoDB e importar o arquivo JSON com os seguintes comandos:

• mongo.exe ATA
• db.SystemProfile.remove({})
• mongoimport.exe --db ATA --collection SystemProfile --file "<Arquivo JSON> --upsert

Observação: Primeiro comando abre a instancia, o segundo remove as configurações vazias e o terceiro importa a nova configuração.

Não é necessário recriar os Gateways pois eles são mapeados automaticamente quando se restaura as configurações.

Caso você tenha feito backup da base de dados do MongoDB siga o procedimento de restore da base antes de reiniciar o serviço do ATA.

Referencia: https://docs.microsoft.com/pt-br/advanced-threat-analytics/disaster-recovery

Como já é conhecido, o ciclo de vida de produtos da Microsoft para 2019 incluem o Windows e SQL 2008 RTM e R2.

Fonte: https://support.microsoft.com/pt-br/lifecycle/search 

Porque isso é importante?

Esse é um problema típico nas grandes empresas, controlar o ciclo de vida do suporte dos produtos que estão implementados.

Esse assunto não é de menos importancia, pois ter o suporte finalizado implica:

• Novas ameaças de segurança, mesmo as que envolvem brechas de software, não são mais disponibilizadas para os sistemas expirados
• Novos recursos em novos produtos não tem garantia de funcionamento nos produtos expirados

O primeiro item é importantissimo. Imagine que sua empresa está vulnerável a um ataque como muitos que vimos, pois apenas UM SERVIDOR em seu ambiente é expirado!!!

O que fazer se tenho produtos que expiram?

Obviamente que a melhor opção é migrar (“TO-BE”), mas sabemos que nem sempre é possivel. O que pode ajudar é usar produtos como o Service Map do Log Insights (http://www.marcelosincic.com.br/post/Azure-Log-Insigths-Service-Map.aspx).

Mas para quem não pode fazer o upgrade, uma das opções é comprar o suporte via Premier para mais 3 anos, que não é barato mas é possivel negociar através do seu time de contas Microsoft.

O custo para extender o suporte POR ANO é equivalente a 75% do software full na versão mais atual.

Porem, a Microsoft disponibilizou uma opção bem interessante que é migrar para Azure “AS-IS”!!!!

Isso mesmo, quem migrar para Azure o Windows 2008 e SQL Server 2008 não precisará se preocupar pois terão gratuitamente o suporte por 3 anos adicionais.

https://azure.microsoft.com/pt-br/blog/announcing-new-options-for-sql-server-2008-and-windows-server-2008-end-of-support/

Não precisamos nem discutir que é uma estratégia para aumentar o uso de Azure, mas muito boa financeiramente para qualquer workload que possua.