LGPD disponivel no painel de Compliance do Office 365
Hoje tivemos o anuncio de que a suíte de segurança agora contempla os modelos legais de novos países e incluiu o LGPD (Lei Geral de Proteção de Dados).
https://www.microsoft.com/en-us/microsoft-365/blog/2020/01/27/microsoft-compliance-score-address-changing-data-privacy-landscape/
Como Utilizar o Compliance Score
Para utilizar o novo painel de Compliance utilize o link https://servicetrust.microsoft.com/ComplianceManager/V3
Importante: Lembre-se de usar o painel em preview pois o painel clássico não permitirá incluir.
Nesse link clique em Adicionar Avaliação para incluir o módulo de avaliação do LGPD para o Office 365:
Após isso já poderá ver o widget do LGPD no seu painel:
O que é possível fazer e como usar o Compliance Manager?
A ideia do Compliance Manager é permitir que o administrador e a equipe de segurança e conformidade avaliem se estão usando corretamente as regras de uma lei nacional de proteção de dados ou norma internacional como ISO, HIPAA e PCI.
No meu exemplo na tela acima está aplicado o modelo de proteção de dados básica, HIPAA (segurança de dados para saúde) e o LGPD.
Veja que para cada um dos modelos eu tenho uma nota do que já foi implementado pela Microsoft e o que eu já fiz de itens de segurança.
Pergunta importante: O score no Compliance Manager é igual ao Score do painel Segurança e Conformidade do Office 365 (https://protection.office.com)?
A resposta é NÃO!!! Enquanto o painel do Segurança e Conformidade se refere a itens técnicos onde você escolhe o que irá ou não implementar e com isso reduzir ou aumentar o seu Score total, no painel do Compliance Manager não temos essa possibilidade, já que ele mede a aplicação dos itens da lei/norma.
Como Avaliar o meu Nível de Compliance?
A cada item do modelo que pode ser acessado em Itens de Ação ou Informações de Controle você verá uma lista com os itens cobertos pela Microsoft e os que você como corporação deverá fazer:
Ao clicar em Review será possível você indicar em que estágio está com aquele determinado Item de Ação.
Para isso informe o estágio, data que irá implementar, se os testes com a ação foram bem sucedidos e a data do teste. Também poderá incluir observações sobre como o teste foi feito, anexar os documentos e atribuir a um usuário.
Com isso você passa a ter um painel onde para auditoria será muito mais fácil levantar os dados e comprovar a aplicação do modelo de lei ou norma que você está se sujeitando:
Na parte seguinte das análises em Informações de Controle você terá uma visão como a abaixo onde terá acesso aos diferentes itens que deverá implementar conforme a lei, com destaque para o artigo que a impõe.
No caso de leis “cruzadas”, o resumo irá indicar as diferentes leis e normas com seus artigos onde é necessário implementar determinado controle:
Assim como na parte de Itens de Ação aqui você poderá abrir os itens e ver quais os controles que precisam ser implementados por você ou já são satisfeitos pela segurança do próprio Office 365:
Quem Pode Utilizar o Compliance Manager?
Essa ferramenta está disponível no EMS E5 que compõe o Microsoft 365 E5.
É possivel adquirir para pacotes de produtos Office 365 como um add-on que é o Office 365 Advanced Compliance que pode ser agregado ao O365 E1, E3 ou E5.
https://docs.microsoft.com/en-us/office365/admin/subscriptions-and-billing/buy-or-edit-an-add-on
Azure Sentinel - Conheça esse novo produto de segurança agora disponível
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.
Instancia Reservada no Azure–Mudanças Importantes
A algum tempo que já temos disponivel o recurso de comprar antecipadamente uma instância de maquina virtual, chamado de Reserved Instance.
Basicamente o processo se mantem (http://www.marcelosincic.com.br/post/Reducao-de-Custos-com-Azure-Reserved-Instance.aspx) mas temos algumas novidades e alertas:
- Alteração do tipo de VM
- Outros recursos que podem ser reservados
- Mudança na forma de cobrança
- O que não está incluido em uma reserva
Possibilidade de Alteração da Instância (perfil de VM)
Essa mudança é importante, pois na primeira versão (link acima) não era possivel mudar o tipo de VM.
O processo para mudar era pedir o reembolso da instância já paga (lembrar que existia um penalty) e refazer com outro tipo de VM da mesma familia, como por exemplo de D2 para D4.
Para isso basta utilizar o botão Exchange em uma reserva e será possivel escolher o novo tipo de VM como abaixo sem o penalty dos aproximadamente 12% do cancelamento.
Porem, obviamente que o custo de uma D2 é diferente de uma D4 e para isso temos uma tabela que pode ser usada no calculo para saber o valor da diferença que será pago quando trocar entre os tipos de VM em https://docs.microsoft.com/en-us/azure/virtual-machines/windows/reserved-vm-instance-size-flexibility?wt.mc_id=4029139
Outros Tipos de Recursos Alem das VMs
Na versão inicial as RIs eram apenas VMs, mas agora é possivel fazer com diversos tipos de serviços. Atualmente segue a lista dos que são suportados:
- Reserved Virtual Machine Instance
- Azure Cosmos DB reserved capacity
- SQL Database reserved vCore
- SQL Data Warehouse
- App Service stamp fee
Essa lista é alterada conforme novos recursos podem ser agregados e está disponivel em https://docs.microsoft.com/en-us/azure/billing/billing-save-compute-costs-reservations?wt.mc_id=4029139
Importante: Veja o tópico abaixo sobre o que é incluido ou não no RI.
Forma de Pagamento Mensal
Até 8/Setembro/19 só era possivel o pagamento antecipado a partir de créditos do Enterprise Agreeement ou pagamento em cartão de crédito.
Agora é possivel o pagamento mensal, ou seja todos os meses irá consumir o valor com desconto igual ao anual como se fosse uma subscrição mensal e não anual. O melhor para entender é que o compromisso continua anual, mas pago mensal ao invés de upfront.
As outras regras continuam as mesmas, penalty em caso de cancelamento, mudança do tipo de VM ou serviço, etc.
Para os que já tem reservas será necessário aguardar o prazo da compra, uma vez que foi pago antecipado e por isso haveria a cobrança da taxa de cancelamento.
https://docs.microsoft.com/en-us/azure/billing/billing-monthly-payments-reservations?wt.mc_id=4029139
Importante: O pagamento mensal não mudou a forma de reserva ser anual, ou seja haverá o penalty em caso de cancelamento.
Recursos Cobrados em Separado
Uma confusão muito comum nos clientes que compraram RIs é o fato de continuar havendo outras cobranças para as VMs e recursos aparecendo em seus extratos.
O que precisa estar claro é que reservas se referem apenas aos recursos computacionais e não os recursos agregados como licenças, armazenamento e trafego de rede.
Por exemplo, no tipo de reserva para VMs que são as mais comum:
- Incluido no RI: CPU, memória e alocação
- Não incluido no RI: Armazenamento (storage), tráfego de rede (network) e licenciamento do SO se não foi utilizado o AHUB
O motivo é que estes recursos não incluidos fazem parte da subscrição e são compartilhados ou opcionais (como é o caso da licença do Windows ou SQL) e não haveria como limitar ao uso apenas daquelas reservas especificas, alem de serem voláteis diferente do tipo de uma VM por exemplo.
Conclusão
Com os novos recursos que podem ser reservados, flexibilidade na alteração, a nova forma de cobrança e o entendimento correto pode-se gerar uma economia substancial para aqueles que migraram serviços.
Azure File Sync–Otimizando seu File Server e Storage
Duas aplicações mais consomem storage em ambientes de TI:
- Banco de dados – Por conterem dados analiticos e indexados podemos utilizar tecnicas de drill down para separar os dados analiticos dos dados resumidos facilitando o acesso e otimizando custos
- File Server – Ao longo dos anos as empresas acumulam milhares de arquivos, o que custa caro e raramente é agrupado ou tierizado
| Tierização: Tecnologia onde os dados são separados conforme regras de performance em discos mais caros ou mais baratos. Por exemplo, arquivos pouco usados ficam em discos SATA, arquivos com acesso ocasional em discos SAS e arquivos que são acessados diariamente em discos SSD. |
Vamos abordar como utilizar o Azure File Sync para criar uma tierização dos dados em um File Server para permitir que arquivos mais acessados fiquem localmente guardados e os mais antigos apenas em nuvem.
Cenários Frequentes
O primeiro cenário é o de diminuir o tamanho total de espaço ocupado por arquivos antigos.
Nesse caso utilizamos as configurações de data do arquivo e espaço livre desejado para diminuir o espaço em disco que o File Server ocupa, liberando para uso com outras necessidades.
O segundo cenário é servidor de arquivos distribuidos, onde em cada filial da empresa é necessário ter um servidor para acessar os dados.
Nesse exemplo todos os servidores replicam a mesma pasta, o que não cria problemas de saturação local, já que o cache é apenas dos arquivos recentes e controlado pelo percentual desejado de espaço livre a ser mantido.
Componentes do Azure File Sync
- Storage Account – Um storage virtual onde os dados serão armazenados
- File Share no Storage Account – Pasta dentro do Storage Account para receber os arquivos que serão enviados
- Azure File Sync Service no Market Place – É o serviço e deve ser habilitado, diferente de outros serviços nativos. Porem, apesar de estar no Market Place o AFS não tem um custo, trata-se apenas da inclusão de um serviço
- File Sync Service – É o serviço no painel do Azure onde podemos criar os grupos, incluir os servidores e configurar storage
- Registered Services (servidores) – São os servidores que serão sincronizados, onde os arquivos estão armazenados e servirão de cache
- Sync Group – Forma a lista de servidores que irá receber a cópia dos arquivos a serem copiados e dar acesso aos arquivos em qualquer localidade
Criando um Storage
Esse é o primeiro passo e bem conhecido de quem já utiliza o Azure, uma vez que para tudo precisamos de um storage.
Para usar o AFS não é necessário qualquer configuração adicional, você poderá escolher qual região, tipo de storage e replicação que melhor se aplique ao seu ambiente. Obviamente algumas coisas precisam ser levadas em conta:
- O tipo de conta envolve a performance maxima e irá afetar tanto o download quanto upload quando os usuários utilizam os arquivos
- Replicação é importante se você terá servidores em várias localidades/paises
- Camada Hot or Cold envolve a performance diretamente e tambem o custo, já que o acesso é bem lento em discos Cold e não recomendaria para uma solução como essa
Na sequencia é necessário criar o File Share para onde os arquivos irão quando sincronizados, e o conceito é o mesmo de um servidor comum:
Quando sincronizado, os arquivos irão aparecer primeiro na pasta Sincronization e depois na pasta principal como podemos ver abaixo.
Lembrando que as duas telas acima se referem a sincronização já finalizada, a primeira para ver os arquivos sendo copiados e a segunda quando a primeira sincronização já finalizou.
Habilitando o Azure File Sync
Procure no Marketplace pelo Azure File Sync ou Serviço de Sincronização do Azure em portugues:
Nesse momento pode-se optar por utilizar um Resource Group existente ou um novo, não importando em qual Resource Group o Storage foi criado, uma vez que ele pode ter varios outros serviços atribuidos.
Criando o Serviço de Sincronização
A criação do grupo de sincronização é bem simples, bastante indicar a assinatura, storage e a pasta compartilhada definida anteriormente.
Registrando Servidores de Arquivos
Você poderá indicar servidores:
- Novos servidores que não tenham arquivos e incluí-los em um grupo já sincronizado para que ele sirva de cache dos arquivos que já estão na pasta compartilhada do Storage no Azure
- Servidor com dados onde o conteudo será copiado para o Azure e acrescentado
O primeiro passo é instalar as bibliotecas PowerShell do Azure (AZ) no servidor, o que pode ser feito seguindo os passos na página https://docs.microsoft.com/pt-br/powershell/azure/install-az-ps?view=azps-2.6.0&wt.mc_id=4029139
Após ter o Azure CLI instalado, baixe e instale o Agente de Sincronização que é muito simples de ser feito.
Após isso, já será possivel ver o servidor no painel do Azure:
Nesse passo não é necessário configurações nem qualquer definição adicional, já que se trata de uma operação simples de agente.
Criando o Endpoint (Servidores Cache)
Aqui é onde realmente criamos o serviço e vemos a mágica acontecer!
Entrando dentro do grupo de sincronização que criamos anteriormente e usar a opção Adicionar ponto de extremidade ou Add Endpoint para incluir o servidor no grupo que criamos.
Vamos ver as opções que estão listadas:
- Caminho – É o diretório que queremos que fique sincronizado, lembrando que se estiver vazio para um grupo já existente ele irá baixar o conteudo conforme for sendo utilizado. Se for um servidor que já contem arquivos, esses serão carregadso para o Azure.
Importante: Não é possivel usar a unidade root (C:) e sim um disca parte por conta dos arquivos de sistema. - Percentual livre no volume – Não definimos quanto irá ser usado para cache e sim quanto de espaço no volume deverá ficar livre. Pode parecer um calculo invertido mas não é por conta de outros arquivos que o mesmo disco contenha. Por exemplo, se o volume é de 100GB e contem outros arquivos totalizando 40GB e definirmos que queremos deixar 50% do disco livre, apenas 10GB será usado pelo cache (50% de 100GB=50GB sempre livre) e conforme o uso de outros arquivos aumentar que não sejam sincronizados, menos irá ter espaço para o cache.
Dica: Por conta dessa dificuldade, prefira utilizar um volume dedicado para fazer o File Sync - Cache apenas de arquivos acessados ou modificados a x dias – Vimos que temos a opção de preservar um percentual do disco. Mas e se arquivos antigos ocupam muito espaço não irá adiantar muito. Nesse caso do meu exemplo qualquer arquivo com mais de 60 dias irá automaticamente para o Azure e será deletado no disco do servidor, ganhando espaço livre mesmo que o percentual de cache ainda esteja disponivel.
Ao finalizar essa configuração já é possivel acompanhar a sincronização clicando no servidor:
Assim que sincronizado, podemos usar os paineis de metricas abaixo da tela para criar alertas quando ocorrerem erros ou distorções:
No meu exemplo posso utilizar uma regra que se o numero de arquivos sincronizados for maior que 100 para upload no intervalo de 15 minutos pode ser uma alteração em massa causada por uma cópia indevida ou mesmo um malware.
System Center 2019 e Windows Server 2019 – Upgrade in place II
Com o lançamento oficial do System Center 2019 semana passada agora já podemos testar a migração da versão final.
https://cloudblogs.microsoft.com/windowsserver/2019/03/07/coming-soon-microsoft-system-center-2019?wt.mc_id=4029139
Nova Politica de Versões
Na nova politica de versões do System Center, não haverá os canais Semi-Anuais como Windows.
Ou seja, você terá a versão 2019 por aproximadamente 3 anos com os updates que em geral ocorrem 3 vezes por ano.
Isso significa que diferente das primeiras versões que foram o 1801 e 1807, daqui em diante não teremos mais esse mesmo tipo de nomenclatura retornando ao antigo modelo de versões com updates (2019 UR 99).
Importante: System Center Configuration Manager continua com o canal Semi-Anual
https://docs.microsoft.com/en-us/system-center/ltsc-and-sac-overview?wt.mc_id=4029139
Executando o Upgrade
No mesmo documento acima, vemos o suporte para upgrade in-place que é garantido até as ultimas 2 versões.
Isso significa que os usuários das versões 2012 R2 precisarão primeiro fazer o upgrade para a 1801 e depois para o SC 2019.
Importante: System Center Configuration Manager terá as regras de update diferentes, dependendo do canal escolhido
Assim como o upgrade da versão 2016 para a 1801 foi tranquila e já demonstrei aqui http://www.marcelosincic.com.br/post/System-Center-2019-e-Windows-Server-2019-Upgrade-in-place.aspx, a migração do 2019 tambem foi bem satisfatória.
Todos eles precisamos apenas confirmar a instalação, apenas com excessão do SCOM e VMM que é necessário o upgrade de agentes.
O DPM não executei o upgrade pois atualmente utilizo o Microsoft Azure Backup que é um subset especializado para backup no Azure.
System Center Operations Manager (SCOM)
_thumb.jpg "SCOM (2)")
_thumb.jpg "SCOM (3)")
No caso do SCOM uma mudança é agora poder ativar pela interface no “About”, antes era necessário fazer pelo PowerShell com o comando Set-SCOMLicense.
_thumb.jpg "SCOM (1)")
Lembrando que no caso do SCOM é necessário autorizar o upgrade do agente para todos os servidores logo após a instalação. Caso não o faça continuará havendo comunicação, mas ele irá criar alertas constantes de aviso e novos recursos podem ocasionar falha nos agentes.
System Center Service Manager (SCSM) e System Center Orchestrator (SCO)
Literalmente nada precisou ser feito ou alterado e o mesmo aconteceu com o Orchestrator.
_thumb.jpg "Service Manager (1)")
_thumb.jpg "Service Manager (2)")
System Center Virtual Machine Manager (SCVMM ou VMM)
O VMM já exigiu um pouco mais de trabalho, pois é necessário rever as contas no “Run-AS” que agora limita contas locais e reinstalar os agentes.
No meu caso, fiz o exercicio de desinstalar para validar se apenas utilizando o banco de dados retornaria e funcionou!
_thumb.jpg "VMM (1)")
_thumb.jpg "VMM (2)")
_thumb.jpg "VMM (3)")
_thumb.jpg "VMM (4)")