Azure Arc–Gerenciamento integrado Multi-cloud

22 julho 2020 msincic Advisor, Azure, Azure Sentinel, Log Analytics, Microsoft Azure, Hardware, Windows Server 2019, Windows 2012, Virtualizaçao
O Azure Arc é um produto em preview que tem a função de padronizar e permitir utilizar recursos do Azure para gerenciamento de VMs e Clusters Kubernets hospedados em ambientes on-premisse ou outras clouds integrado. https://azure.microsoft.com/en-us/services/azure-arc/ Habilitando o Serviço por Registrar os Componentes O primeiro passo é acessar as subscrições onde irá hospedar os serviços do Arc. Uma vez escolhida a subscrição, deve-se registrar os recursos de Hybrid como abaixo. Em geral o recurso ADHybridHS já estará habilitado e tem a ver especificamente com a sincronização de AD, mas os recursos de Compute, Data e Network precisam ser habilitados antes de incluir recursos: Registrando Computadores e Recursos Ao criar o recurso do Arc, escolha uma subscrição e um Resource Group para servir de base e que futuramente após o Preview irá ter o débito (se existir) dos serviços. Logo após habilitar clique no botão Adicionar do primeiro print deste artigo e baixe o script para executar nos servidores. Caso queira abrir o script ele é bem simples e basicamente faz o download de um msi e o executa com os dados da subscrição. A primeira execução do script mostra a obrigatoriedade de ativar os recursos, que foi o primeiro tópico desse artigo, e será um erro recorrente já que ao habilitar o Arc esse processo deveria ser automático. Note que na execução do script ele gera um código que deverá ser confirmado no site indicado https://microsoft.com/devicelogin Utilizando Politicas e Iniciativas Assim que vinculados, já podem ser criadas e habilitadas as diferentes Politicas e iniciativas que serviriam para criar alertas e definir padronização de recursos no que geralmente chamamos de Compliance. Por default as politicas acima são configuradas, mas é possivel criar novas para gerar reports de compliance. Para isso utilize as regras pré-existentes que irão facilitar diversos tipos diferentes de alertas como backup, antivirus, ASR, etc. Já para as Iniciativas não estamos apenas verificando, mas implementando alguns tipos de padrões como o nivel de auditoria ou requisitos legais/padrões regulatórios: Habilitando o Log Analytics Para que os recursos funcionem corretamente é importante o auxilio do Log Analytics que irá capturar os dados do servidor para gerar alertas e mapas de relacionamento. Para isso acesse os servidores e clique no aviso na tarja que é exibida e com isso poderá habilitar os recursos para cada servidor ou em Insights. Uma caracteristica interessante é que cada servidor pode utilizar subscrições diferentes ou até workspaces diferentes de Log Analytics. A partir da integração que irá demorar de 5 a 10 minutos, já é possivel usar os monitores, alertas e até o mapa de relacionamento: CONCLUSÃO Em comporações com servidores fisicos, servidores virtuais e maquinas em clous ter a facilidade de integrar as funções de gerenciamento do Azure irá ajudar muito. Grande parte do trabalho já é possivel no Log Analytics mas de forma passiva. Com a integração simples com as politicas, iniciativas e interface o uso do Azure Arc irá ser uma ferramenta excelente para profissionais de TI com ambientes multiplos de hospedagem.

Azure Sentinel - Conheça esse novo produto de segurança agora disponível

29 setembro 2019 msincic Azure, Azure OMS, Log Analytics, Azure Sentinel, Cloud computing
O Azure Sentinel já estava em Preview a algum tempo (desde março) mas já se mostrava um produto bem interessante https://azure.microsoft.com/pt-br/blog/azure-sentinel-general-availability-a-modern-siem-reimagined-in-the-cloud/?wt.mc_id=4029139 Sua função é analisar os dados coletados pelo Log Analytics e gerar dashboards, reports e alertas customizados com base no Machine Learning. Nesse primeiro post vamos falar da configuração inicial do Sentinel e seu custo. Nota: Em um segundo artigo falaremos dos Incidentes (casos), Busca, Notebook, Analise e Guias Estratégicos. Como Habilitar o Azure Sentinel Para criar uma instancia do Sentinel é necessário ter o Log Analytics (antigo OMS) habilitado e executando. Se você não o conhece, pode ver o que já abordamos anteriormente em http://www.marcelosincic.com.br/post/Operations-Management-System-(OMS)-agora-e-Azure-Log-Insights.aspx Não é necessário fazer toda a configuração do Log Analytics, dependerá do que você irá analisar. Por exemplo se analisar DNS mas usa o Azure DNS, Office 365, Azure Activity e outros recursos que já fazem parte do Azure os dados são analisados sem a necessidade de agentes. Por outro lado se for analisar threats de segurança em geral, login e logoff de AD e segurança de ambiente é necessário ter o agente instalado no Windows ou Linux para coleta dos dados de log. Uma vez criado o workspace do Log Analytics já é possivel fazer o vinculo. Com o workspace aberto já é possivel ter um overview dos dados coletados, nada muito sofisticado mas o suficiente para acompanhar o que está sendo analisado Ao clicar em qualquer um dos itens resumidos pode-se abrir o log do que gerou os alertas ou anomalias Como Definir o Que Será Analisado No console do Sentinel é possivel ver a aba “Conectores” onde temos diversos conectores já criados e disponiveis, alguns como preview e indicados quais já foram vinculados. Veja no ultimo item que a cada diferente conector o custo passa a ser vigente, ou seja conforme o numero ou tipo de conector haverá a cobrança do processamento dos dados. Para cada conector é necessário abrir a pasta de trabalho e configurar a conexão, por exemplo se for Azure indicar a subscrição e se for Office 365 o usuário para logar e capturar os dados. Como cada um dos conectores tem wizard é um processo bem simples de ser realizado. Consumindo os Reports e Dashboards Na aba do Sentinel veja a opção “Pastas de Trabalho” onde podemos escolher quais os dashboards que queremos deixar disponiveis ou criar os seus próprio. Por exemplo se eu clicar no conector de Exchange Online posso exibir ou salvar a pasta de trabalho com os seus reports já prontos. No caso acima veja que a opção de Salvar não aparece e sim a Excluir, uma vez que já salvei anteriormente como um dos dashboards (pasta de trabalho) mais utilizados. Ao clicar em Exibir podemos ver os detalhes do dashboard de analise de Identidade que fornece informações de login e segurança do meu ambiente O nivel e detalhamento dos dados nos fornece uma visão real do que está acontecendo em determinado item de segurança conectado. Compartilhando e Acessando os Reports (Dashboards) Na mesma aba de “Pastas de Trabalho” mude para “Minhas pastas de trabalho” e poderá ver os que já salvou anteriormente ou customizou. Neste exemplo já estão salvos 7 pastas (1 é customizada) com 31 modelos. As pastas são customizadas ou as já importadas dos modelos, enquanto o numero de “31 modelos” é porque um mesmo grupo de conectores tem mais de uma pasta, como é o caso do Office 365 que tem um conjunto de 3 diferentes reports. Ao acessar um dos reports é possivel ver o botão “Compartilhar” onde podemos gerar um link e enviar a outros ou utilizar para acesso fácil Já para “pinar” ou fixar no painel inicial do portal do Azure um atalho utilize o icone de pasta na tela de preview e a opção “Fixar no painel” como abaixo Quanto Custo o Azure Sentinel Sabemos que os recursos de Azure são em sua maioria cobrados e o Azure Sentinel já tem seu valor divulgado em https://azure.microsoft.com/pt-br/pricing/details/azure-sentinel/ A primeira opção é adquirir em pacotes de 100 a 500GB por dia em modelo antecipado iniciando ao custo de $200/dia. Claro que o modelo antecipado é mais barato, mas só é útil se você consumir 100GB por dia, o que daria $7200/mês. A segunda opção e util para quem irá analisar menos de 100GB por dia é o modelo de pagamento pós-uso ou por consumo ao valor de $4 por GB analisado. Para saber o quanto está sendo analisado, veja a segunda imagem nesse artigo onde temos o total de dados “ingeridos”. Importante: Se você coletar dados do Log Analytics o valor deve ser somado, já que o Log Analytics é uma solução independente.

Azure Virtual Datacenter (VDC) Parte I- Migração AS IS e TO BE

06 março 2019 msincic Azure, Cloud computing, Hardware, Log Analytics, Microsoft Azure, Virtualizaçao
Quando trabalhamos em um projeto de migração para Public Cloud e o desenho é voltado a Azure, é muito comum os cenários de “AS IS”. AS IS Para os não iniciados com este termo, “AS IS” significa levar como está me ingles, ou seja copiar as VMs de um ambiente a outro sem qualquer alteração, utilizando o Azure como um virtualizador. Em geral os modelos de migração AS IS não são eficientes, pois consomem muito recursos em IaaS (VMs) que custam caro, não aproveitando nada de serviços (SaaS ou PaaS) que são mais baratos. Porem, a vantagem é que é mais rápido e não exige mudanças. TO BE (ou LIft and Shift) Já as boas migrações são as “TO BE”, que em tradução livre seria “SERÁ” no sentido de transformação. O modelo de migração TO BE tem como premissa usar os serviços e não apenas migrar VMs. Migrações TO BE são trabalhosas e mais demoradas, uma vez que esse mapeamento envolve entender o que está DENTRO DAS VMs. O custo de execução é muito menor pois SaaS e PaaS tem vantagens financeiras grandes quando comparados ao modelo de IaaS. Por exemplo, no AS IS um servidor IIS e outro de SQL serão simplesmente copiados os discos virtuais e iniciados. Já no modelo TO BE iremos isolar cada uma das aplicaçÕes que o IIS executa e criar Web Plan para isolamento e Web Services para cada site, e no caso do SQL Server usariamos o serviço de Banco de Dados (SaaS ou PaaS). Utilizando o Service MAP O primeiro passo para fazer uma migração é mapear o que cada VMs ou servidor fisico executa no ambiente. Para isso utilizamos o Service MAP: http://www.marcelosincic.com.br/post/Azure-Log-Insigths-Service-Map.aspx Com ele será possivel ver as interligações e serviços que cada servidor utiliza entre no ambiente e mapear qual serviço temos para substituir. Entendendo o Conceito de Datacenter do Azure Para desenhar um datacenter usando VMWare, Hyper-V ou KVM é necessário que o desenho dos hosts, rede e outros detalhes sejam feitos por especialistas no hypervisor. O mesmo vale para Azure, precisamos entender os diferentes componentes para desenhar um datacenter com seus recursos. Para isso, é necessário estudar, e muito.   Tambem é necessário quebrar os paradigmas de datacenter fisico e pensar em serviços. Uma das formas de fazer isso é utilizar o Guide da própria Microsoft disponivel em https://docs.microsoft.com/en-us/azure/architecture/vdc/ Esse guia tem todas as perspectivas de um datacenter virtual, o ajudará a entender a camada de virtualização, rede, segurança, serviços e o lift and shift, ou seja a transformação para um modelo mais eficiente. Para começar baixe a apresentação disponivel em https://aka.ms/VDC/Deck Conclusão Não é fácil fazer uma migração correta, mas é possivel e o resultado será muito melhor. Ao longo do mês iremos explorar os itens que compõe o VDC e verá que é possivel fazer esse tipo de migração com recursos novos, mais eficientes e custos apropriados.

Azure Log Insights–Service Map

03 julho 2018 msincic Log Analytics, Azure, Azure OMS
Muitos já conhecem o Log Insights que antes era chamado de Operations Management Suite. Nesse post vou destacar um dos muitos plug-ins de solução do Log Insights (chamados de Solutions no portal) que é o Service MAP NECESSIDADE Migrar um Datacenter não se resume a levar servidores de um lado para outro, muitas vezes é necessário migrar ambientes por perfil de aplicações. O objetivo nestes casos é saber quais servidores devem ser migrados juntos para não ter problemas de comunicação tanto entre a mesma aplicação como tambem entre o serviço e os clientes. O problema muitas vezes é conseguir mapear isso, pois poucas empresas possuem um mapa de aplicaçoes onde conste os servidores e serviços utilizados em cada aplicação, principalmente aplicações Web e Bancos de Dados. SOLUÇÃO A Solution Service Map do Log Insights resolve este problema! Ela mapeia todas as comunicações que são realizadas com os servidores com o agente instalado e monta um mapa completo do uso detalhando portas, nomes, serviços e permitindo drill-down para visualizar as conexões e um painel de detalhes para cada item selecionado. Segue abaixo alguns prints que utilizo para demonstrar o recurso: Visualização dos serviços em um dos servidores e detalhes do servidor selecionado. Note que do lado esquerdo é possivel ver a barra de detalhes do servidor mapeado a partir de outros Solutions ativos em seu Log Insights. Detalhes de um dos servidores que se comunica com o host, com detalhes da comunicação e do servidor. Ao abrir o servidor selecionado na tela anterior posso ver os detalhes dele, incluindo agora os desktops e outros servidores que tambem utilizam o target selecionado. Visualizando os detalhes de comunicação entre o servidor target e o servidro com SQL Server onde podemos ver as comunicações do SQL para autenticação, já que o target é meu Domain Controller. Aqui podemos visualizar no conceito de grupos onde os servidores que inclui o grupo são mapeados e pode ser utilizado para criar os mapas de determinada aplicação. Baseado no gráfico acima, consigo visualizar que o host T110 possui duas VMs principais que se comunicam com todos os clientes e entre eles constantemente. Se for criar um plano de migração do meu ambiente já saberia que elas são as duas principais VMs que precisam ser ativadas juntas na migração. UTILIZANDO O SERVICE MAP Para utilizar o Service Map você obviamente deve ter uma conta Log Analytics já habilitada e incluir a Solution. O levantamento dos dados não é realizado pelo agente normal do Log Insigths, é necessário baixar um agente especifico que pode ser encontrado no link abaixo: https://docs.microsoft.com/en-us/azure/monitoring/monitoring-service-map-configure Logo após instalar o agente do Service Map já será possivel visualizar os mapas e utilizar grupos. Importante: O Service Map só mantem dados de 1 hora no máximo, portanto é um portal para visualização imediata já que não possui histórico nem relatórios analíticos. Referencia completa: https://docs.microsoft.com/en-us/azure/monitoring/monitoring-service-map

Utilizando o Azure Log Analytics (OMS) e o SCOM na Mesma Maquina

09 julho 2016 msincic Microsoft Azure, System Center, Operations Manager, Windows Azure, OMS, Azure, Log Analytics
Para utilizar o Log Analytics, antigo Operational Insights, junto com o System Center Operations Manager é possível fazer isso pelo console do próprio SCOM. Essa forma de integração já em Março/2014: http://www.marcelosincic.com.br/post/Integrando-o-SCOM-ao-System-Center-Advisor.aspx Apesar de ter alterado o nome de System Center Advisor, depois para Operational Insights e agora Log Analytics, o processo de integração com o SCOM se manteve o mesmo. Porem a uma limitação no processo de integração do SCOM, pois ele só permite uma conta de OMS/Log Analytics por organização. Em muitos casos é necessário usar mais de uma conta, por exemplo: Provedores de serviço e CSC em que cada cliente tem uma conta diferente no Azure Quando utilizamos múltiplas assinaturas para monitorar um mesmo ambiente físico Quando uma das contas é beneficio de Visual Studio com créditos limitados e desejamos separar os servidores em contas diferentes Nestes casos podemos utilizar os dois métodos os mesmo tempo, instalar o agente do SCOM e não vincular a uma conta do Log Analytics e fazer o processo apenas nas maquinas desejadas. Para isso, o primeiro passo é abrir o Log Analytics e copiar o Workspace ID e o Primary Key. Veja no exemplo abaixo que já tenho meu SCOM integrado ao Log Analytics. O passo seguinte é ir até a maquina que deseja monitorar e abrir o agente de monitoração do SCOM (Microsoft Monitoring Agent): Ao abrir as configurações do agente note a aba Azure Operational Insigths (nome anterior a Log Analytics). Veja nesse print que já tenho a maquina sendo reportada ao SCOM: Insira os dados da sua conta do Log Analytics e pronto, agora é possível ter a monitoração com várias contas ou individual: Agora os meus dados de Active Directory que antes não estavam sendo populados passam a estar devidamente preenchidos e monitorados: