MVP: System Center Cloud and Datacenter Management, MCT, MCSE, MCITP, MCPD, MCDBA
MVP Logo

Últimos posts

Categorias

Arquivo

Tags

Lançamento do System Center 2022–Ainda Vale a Pena? Será descontinuado?

A primeira vez que recebi o premio de MVP foi na categoria System Center, que depois alterou para Cloud and Datacenter Management (CDM).

Com o crescimento exponencial das clouds publicas os ambientes on-premises passaram a ser integrados também aos recursos disponíveis em cloud publica e/ou migrados.

Então recebo constantemente a pergunta “O System Center vai morrer?” e até afirmações “System Center foi descontinuado”.

Com o lançamento do System Center 2022 em 1o de Abril voltamos estas perguntas https://cloudblogs.microsoft.com/windowsserver/2022/04/01/system-center-2022-is-now-generally-available?WT.mc_id=AZ-MVP-4029139

Sendo assim vamos a algumas questões e usarei uma apresentação que fiz no MVPConf.

O que levou a essas conclusões?

  • Atualizações semestrais foram descontinuadas (1801, 1909, etc), as atualizações seguiram o modelo anterior de Update Rollups a cada 12 a 18 meses e novas versões a cada 3 ou 4 anos
  • Configuration Manager teve sua ultima versão 2012 R2 como a ultima que fazia parte da suíte System Center e passou a ser Enpoint Manager na familia do Intune
  • Service Manager teve um comunicado do time de produtos em 2018 onde afirmavam que o produto não seria descontinuado
  • Operations Manager não tinha uma integração com o Azure Monitor
  • Virtual Machine Manager não dava suporte a recursos novos do Hyper-V e suporte limitado ao Azure
  • Orchestrator com poucos pacotes de integração para 3rd partners

Configuration e Endpoint Data Protection Manager

  • Foi deslocado da família System Center para a família Endpoint Management
  • Integração com Intune e novos recursos do Azure como Analytics (Log e Desktop)
  • Possibilidade de utilizar roles diretamente na web (CMG)
  • Licenciamento foi integrado nas licenças de Microsoft 365, Enterprise Mobility Suite (EMS), Intune add-on e CoreCal Bridge

Conclusão: O produto não foi descontinuado nem se tornou uma nova família para se “desprender”, e sim um reposicionamento para o time de gerenciamento de Windows.

Operations Manager

  • Os Management Packs foram todos atualizados para os produtos novos (Windows Server 2019, Exchange, SharePoint, etc)
  • Foi disponibilizado um Management Pack para Azure que permite fazer toda a monitoração e dashboards, recebeu integração com o Log Analytics, que alimenta os dados para uso no Azure Monitor
  • Reduz custos e tem melhor performance nos alertas para servidores on-premisse, quando o ambiente é integrado com o Azure Monitor
  • Projeto Aquila permitirá usar o SCOM como SaaS (fonte: ZDNET e Directions)

Conclusão: Continua como uma ferramenta importante para ambientes on-premisse. Para ambiente cloud o Azure Monitor e outros são indicados.

Virtual Machine Manager

  • Está sendo atualizado com os recursos novos do Windows 2019, mas o timeline entre novos recursos do Windows e a inclusão seguem os Update Rollups, de 12 a 18 meses
  • Ainda é muito importante por conta de recursos em Cluster de Hyper-V e monitoração para quem utiliza
  • Windows Admin Center vem incluindo diversos dos recursos que o VMM possui, mas os wizards do VMM são superiores

Conclusão: Para grandes Clusters o VMM é indispensável, mas para gerenciamento de servidores Hyper-V segregados o Admin Center é uma boa opção.

Data Protection Manager

  • Manteve as características principais de backup apenas de produtos Microsoft on-premisse (SQL, Hyper-V, Exchange, etc) e VMWare. Não tem previsão de inclusão para produtos de terceiros
  • Não suporta serviços do Azure, cada serviço do Azure possui ferramentas próprias de backup. Aceita agentes em Azure VMs, porem deve-se levar em conta custo de download
  • Possui a versão gratuita Microsoft Azure Recovery System (MARS) que é um subset do DPM sem suporte a fitas

Conclusão: Para ambientes Microsoft on-premisse ou Azure VMs para discos locais ou fitas ainda é importante, mas ambientes Azure utilizar os recursos nativos de cada serviço.

Service Manager

  • Portal de autoatendimento agora em HTML 5
  • Suporta integração com BMC, ServiceNow e outros, mas alguns conectores são pagos (3rd SW)
  • Manteve-se fiel ao modelo ITIL v3
  • A construção de workflows foi melhorada incluindo uma interface mais amigável e mais recursos de integração com o Orchestrator

Conclusão: É uma ferramenta da suíte que recebeu poucos avanços e manteve sua dependência do Orchestrator, que torna mais complexa a administração. Mas como faz parte da suíte é financeiramente justificável no conjunto.

Orchestrator

  • Os Integration Packs foram todos atualizados para os produtos novos (Windows Server 2019, Exchange, SharePoint, etc)
  • Integration Packs de 3rd SW nem todos possuem atualizações, na maioria são pagos
  • Agora suportando PowerShell v4 permite que se crie novas funcionalidades por código, o que remove as limitações dos Integration Packs

Conclusão: Continua como uma ferramenta importante para ambientes on-premisse. Para ambiente cloud o Azure Monitor e outros são indicados.

Alternativas ao System Center

Com os avanços das ferramentas integradas como Hybrid usando Azure Arc e Azure Automation, você poderá estender os mesmos recursos nos servidores on-premises equivalentes ao System Center.

image

Microsoft Defender for Cloud Secure Posture

Já em preview privado a algumas semanas, hoje a Microsoft liberou para o público (GA) as alterações do Defender for Cloud para a postura de segurança.

Porque renomear de Secure Score para Secure Posture?

Dizer que você está 100% seguro não quer dizer que realmente não corre risco, e dizer que você possui uma postura 100% segura não quer dizer que não tem vulnerabilidades.

Vamos usar como analogia um motorista e seu veiculo. Esse motorista é cuidadoso e tem todas as manutenções em dia. Ele dirige com prudencia e raramente cometeria uma infração. Porem quantas vezes já não vimos alguem perder o controle porque um pneu furou, um buraco ou deslizamento na pista, defeito no motor, quebra de roda ou eixo, falha no freio e até um mal estar súbito?

Ou seja, sua POSTURA DE SEGURANÇA indica que você segue as recomendações para evitar ter problemas conhecidos, mas um brecha de segurança de um sistema operacional, aplicativo ou device não é um item que você tem como prever, apenas remediar…

Então renomear o “Secure Score” para “Secure Posture” mostra que você segue e tem os itens SOB O SEU CONTROLE remediados e  controlados. Mas você ainda está sujeito aos problemas externos, vide os exemplo recenter de vulnerabilidades do iOS, Log4j, SolarWinds, Mikrotik, etc.

Agora o Secure Posture inclui AWS e GCP

Anteriormente já era possivel ingressar com contas AWS e GCP mas elas não refletiam no Score e nem permitiam aplicar as regras de compliance. Assim, era necessário que olhasse separadamente e extraisse dados em mais de uma plataformas para gerar um report de compliance único.

O que mudou é que o Secure Posture mostra todas as Clouds integradas e você verá isso ao entrar no Defender for Cloud a partir de hoje!

p1

p2

p2B

Quais as politicas e regras avaliadas?

Esse é um item bem interessante, pois as regras de compliance que você já aplicou ao Azure serão automaticamente duplicadas para representar a mesma postura de segurança no AWS.

Veja abaixo que os mesmos conjuntos de regras aplicadas nas subscrições Azure agora estão aplicadas e adaptadas ao AWS.

p3

p4

Porem é importante ressaltar que apenas de ser possivel exportar os relatórios de compliance não é possivel gerar os reports de auditoria (Audit reports). O motivo é que os relatórios de auditoria é baseado em regras de segurança do datacenter e não apenas do que é serviços, ou seja controle do provedor e do cliente. Por conta disso, cada provedor precisa ter seus próprios relatórios atestando a segurança lógica e física da infraestrutura.

Onboarding de contas AWS

Fazer o onboarding da conta AWS não é um processo trivial pois envolve criar um objeto no CloudWatch e configurar permissões. Mas fazer o processo pelo Azure é simples e ele possui o passo a passo do que deve ser feito e valida ao final.

p5

Ao adicionar uma conta AWS será possivel escolher avaliar apenas a postura ou instalar automaticamente o Azure Arc nas VMs e capturar os logs com o Log Analytics.

p6

Importante lembrar que você poderá usar as politicas e iniciativas do Azure agora no AWS, então os mesmos requisitos customizados que você possua será avaliado nos dois ambientes.

Conclusão

Para clientes com ambiente multicloud agora será possivel ter uma visualização unica da postura baseada nas regras customizadas ou regulamentares únicas.

Anuncio oficial: Security posture management and server protection for AWS and GCP are now generally available - Microsoft Tech Community

Azure Sentinel–Log Search & Restore Preview

Um dos programas que a Microsoft disponibiliza a MVPs e parceiros é participar de previews privados para funcionalidades de Cloud Security.

Um destes recursos liberados para Public Preview recentemente foi o Log Search and Restore onde pode-se estender o tempo de log do Analytics alem de utilizar o próprio Sentinel para ler os dados destes logs armazenados.

Limitação Atual

Na versão GA o Sentinel guarda os logs por até 2 anos, sendo que pela interface visual é possivel configurar 90 dias e via PowerShell para até 755 dias.

Alem disso, ao configurar para 2 anos o log acaba gerando um custo mais alto por estar vinculado ao preço de armazenamento do Log Analytics que é por Giga.

Novos Limites e Custo

Neste Preview o log agora poderá ser guardado por 7 anos (2520 dias) alem de ter um custo menor que será divulgado no GA, porem muito menor que o atual.

Assim como no GA atual, a alteração pode ser feita via PowerShell para os 7 anos.

Mas para ajudar, vc pode usar o aplicativo disponibilizado no GitHub onde poderá escolher as tabelas e o tempo de arquivo para operação. Ou seja você pode colocar a tabela de alertas por 5 anos e a tabela de incidentes por 2 anos.

Link para o aplicativo de configuração: Azure-Sentinel/Tools/Archive-Log-Tool/ArchiveLogsTool-PowerShell at master · Azure/Azure-Sentinel · GitHub

Usando o Recurso

Vou demonstrar com prints abaixo do meu Preview como fiz o processo de Restore, Search e o resultado final.

Executando um Restore com o nome da tabela que desejo, a data inicial e final:

image

Na sequencia executei uma consulta abordando o tempo que configurei do Restore da tabela SecurityEvents com o nome do meu servidor:

image

Por fim, o resultado é uma nova Custom Table no Log Analytics com o nome indicado acima e os mais de 3 anos de eventos restaurados!!!

image

Anuncio do Preview: What's New: Search, Basic Ingestion, Archive, and Data Restoration are Now in Public Preview - Microsoft Tech Community

Azure Purview como Ferramenta de Governança e Compliance

Desde a muito mantemos diagramas de bancos de dados em arquivos lógicos, que são utilizados pelos DBAs e desenvolvedores para criação de aplicações e recentemente de outras funções para dashboards.

Porem com o avanço de leis de compliance como GDPR e LGPD conhecer quem tem acesso e como acessa dados sensíveis se tornou um recurso essencial.

Muitas ferramentas de DLP já fazem com o uso de conectores esse mapeamento, como por exemplo o Security Center pode estender para SQL Server nos planos pagos.

Mas e se possuimos multiplas bases de dados em diferentes produtos, plataformas e serviços?   Neste caso temos o Azure Purview.

O que o Purview oferece?

Com o catálogo de conectores você poderá incluir diversas fontes de dados que vão de SQL e Oracle a AWS S3 e Azure BLOB e descobrir o que está sendo disponibilizado e automaticamente mapear classificações e sensibilidade dos dados.

Por exemplo, quem são os usuários que consomem no Power BI uma determinada base de dados que contem cartões de crédito?    Quais storage accounts possuem dados não estruturados contendo documentos pessoais dos clientes ou exames médicos?

Nessa linha de atuação é que teremos o Purview atuando, tanto para catalogar dados sensiveis como funcionar como um dicionário de dados e mapeamento de acesso aos dados da empresa pelo Power BI, por exemplo.

Requisitos do Purview

Para utilizar o Purview será necessário criar uma instancia de execução (começa com C1 de 4 “unidades”), um Hub de Eventos e uma Storage Account

image

image

O custo do Purview é computado pelas unidades e tambem pelos scans que são efetuados, sendo que alguns ainda estão em preview e com custo zero até 02/Agosto quando escrevo este artigo Pricing - Azure Purview | Microsoft Azure

Acessando o Purview Studio

Toda a administração é feita pelo Studio, onde criamos os conectores e realizamos os scans.

Importante: O acesso aos dados é utilizado a managed account com o nome do recurso que você criou e seguindo os passos para cada tipo de recurso que irá mapear.

clip_image001

Registrando as Fontes de Dados

O Purview já traz uma série de conectores:

clip_image001[5]

O passo a passo abaixo é a conexão com a fonte de dados SQL Database. Primeiro definimos a fonte de dados e a coleção, que nada mais é do que antes da conexão criar agrupamentos como podem ser visto na tela anterior.

clip_image001[7]

Na sequencia definimos como será acessado os dados, pois na configuração acima vemos o servidor e banco de dados mas ainda não fizemos o acesso. Para isso será definido o tipo de identidade, sendo que no exemplo utilizei a managed account dando as permissões de read no SQL Server Management Studio (link no see more):

clip_image001[11]

Essa configuração de acesso são os SCANS, onde vão as definições do que será acessado, no exemplo por ser uma conexão SQL Server o database. Na sequencia verá que selecionei as tabelas e quais classificações quero mapear (note que são as mesmas do Office 365):

clip_image001[13]

clip_image001[15]

Uma vez configurados os scans você poderá definir se ele será executado uma unica vez ou de forma recorrente, sendo que isso pode ser feito abrindo os objetos abaixo da coleção, onde podem ser visto a lista, acessados os diferentes processos e os detalhes:

clip_image001[19]

clip_image001[22]

clip_image001[17]

Classificando e detalhando os dados mapeados

Uma vez os scans executados, automaticamente o Purview irá criar os assets como pode ser visto na função Browse Assets como a sequencia abaixo:

clip_image001[24]

clip_image001[26]

Uma vez aberta uma base de dados mapeada podemos definir detalhes, por exemplo criar uma classificação de dados para a base inteira, definindo quem são os donos/arquitetos dos dados e até definir para cada coluna um tipo especifico:

clip_image001[28]

clip_image001[30]

clip_image001[32]

clip_image001[34]

clip_image001[36]

clip_image001[38]

Nessa sequencia de telas podemos ver que os contatos são importantes para identificar quem conhece e mapeou aquela base de dados. Tambem vemos como definir descrição e classificação de dados individualmente, alem das que o Purview automaticamente já detectou.

Ainda nos assets posso vizualizar uso de dados, por exemplo quais bases de dados estão sendo usadas no Power BI de usuários PRO?   O Purview permitirá que vc tenha essa visualização como abaixo:

clip_image001[40]

clip_image001[42]

Customizando dados sensíveis e criando o glossário

Nos exemplos acima e na interface do Purview podem ser vistos dois itens, um já conhecido que é a classificação automática de sensibilidade e outra que é o glossário.

A classificação já tem pré-carregados os dados do Office 365 que são padrão dos compliances que a Microsoft já fornece, mas você poderá customizar novos assim como é feito no Compliance do Office 365:

clip_image001[44]

Alem disso poderá criar termos de glossário que nada mais são do que um dicionário de dados para consulta. É importantíssimo que isso seja feito, pois será uma base de dados para que administradores e outros especialistas consigam saber por exemplo, de bases de dados especificas.

Uma vez criado os verbetes do glossário, em cada fonte de dados, tabela e coluna será possivel identificar essa classificação como já mostrado na tela de dados da tabela.

clip_image001[46]

Interessante que para os itens é possível incluir atributos, ou seja indicar que se classificar uma tabela ou coluna como confidencial indicar um atributo obrigatório para escrever o motivo:

clip_image002

CONCLUSÃO

Uma vez mapeados com o Purview é possivel ter visibilidade de uso dos dados sensiveis, classificação dos dados em geral e montar um dicionario de dados moderno.

Posted: fev 20 2022, 21:15 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Auditando acesso a dados sensiveis no Azure SQL Database

A algumas semanas atrás publiquei o artigo sobre o uso do Azure Purview como Ferramenta de Compliance (marcelosincic.com.br) e recebi varios questionamentos sobre auditoria no acesso a dados sensiveis.

Essa é uma duvida comum, pois o Purview identifica dados sensiveis nas diversas fontes de dados mas ele não faz auditoria do acesso a estes dados com log das consultas.

Para auditar o acesso é necessário usar as ferramentas de cada fonte de dados, uma vez que são diferentes. Por exemplo acesso a arquivos ou troca de dados é feito pelo DLP do Office 365 (Information Protection), acesso no SQL Server, etc.

Azure SQL Data Discovery & Classification

Parte da solução do Log Analytics, uma vez configurado terá acesso a estatisticas e detalhamento dos acessos.

As duas primeiras capturas abaixo são o meu painel do LAW com os 6 quadros do Solution onde posso identificar quem foram os IPs, usuários e dados acessados.

01

02

E ao clicar em qualquer um dos quadros terá acesso a consulta que gerou os dados, o que irá incluir um dado muito importante que é o SQL utilizado para acessar os dados, permitindo visualizar em detalhes o que foi visto pela sintaxe do comando!

03

Configurando o SQL Data Discovery & Classification

A configuração do recurso não é complexa e pode ser feita em poucos minutos através do próprio portal do Azure.

04

Existem duas formas de classificar os dados, a primeira é manual. Para isso acesse a opção Classification no painel acima e inclua manualmente as tabelas e respectivas colunas.

A fazer isso irá identificar o grupo e a criticidade dos dados da coluna para serem categorizados.

05

A segunda forma de categorizar dados é utilizando as regras de classificação automáticas que ainda está em Preview mas já é possivel visualizar os resultados.

Clique no botão Configure no painel do recurso e terá acesso aos labels de criticidade, que são os mostrados quando no modo manual incluimos as colunas.

06

Veja que no exemplo acima eu criei a minha própria classificação como “LGPD” e nela inclui alguns nomes de colunas que entendo serem necessárias (apenas como exemplo).

Para criar os conteudos que irão fazer parte automática da classificação, clique no botão Manage information types e verá os tipos já criados e poderá incluir novos tipos. No exemplo abaixo inclui RG, CPF e CNPJ mas poderia ter colocado alias como, por exemplo “raz%soci%” ou outros com coringas (%).

07

Importante: Aqui estamos classificando NOMES DE COLUNAS e não DADOS.

Log Analytics Solutions

Uma vez definidas as regras ou colunas com dados sensiveis, o Log Analytics ao qual o banco de dados está mapeado irá mostrar a solução instalada para gerar os gráficos que inclui no inicio deste artigo.

08

09

Porem, notará que no painel de monitoração irá aparecer uma mensagem dizendo que este tipo de painel (View) está sendo depreciado e que vc deveria criar um Workbook com as consultas. Isso não é necessário fazer agora, pois o recurso da solução irá funcionar normalmente.

Mas se desejar criar um workbook, clique nos quadros de recurso abrindo as consultas e as copie em um workbook customizado.

Login