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

Últimos posts

Categorias

Tags

Acesso Condicional com Uso de GPS

Uma mudança importante implantada em Preview no final de Novembro no Azure Active Directory é a localização por GPS.

Anteriormente só tinhamos a opção de usar o endereço IP, porem se a empresa utilizasse proxies externos ou o funcionário estivesse em uma rede com VPN como é o caso agora de muitos antivirus modernos com Web Protection, temos um problema!

Agora é possivel incluir nas politicas de acesso condicional que o usuário habilite o GPS do celular e com isso ter a localização geográfica real ao invés do IP.

Para isso entre nas politicas de Localizações e utilize a opção Determinar localização por coordenadas GPS:

image

Compliance com Termo de Uso no Azure AD Acesso Condicional

Uma necessidade das empresas com a LGPD (Lei Geral de Proteção de Dados) é que os funcionários, terceiros e contratados com logins no ambiente é ter um termo de aceite.

Algumas empresas já o fazem na admissão de colaborados ou contratação quando terceiros. Esses termos de uso frequentemente se tornam obsoletos e enviar por email nem sempre se tem a “prova” de que o colaborador leu os novos termos.

Por outro lado, mesmo que não tenha renovação dos termos, um registro de que o colaborador leu periodicamente para relembrá-lo das normas de segurança é desejável para muitas empresas ou corporações.

Criando os Termos de Uso

O termo de uso precisa ser alinhado com o departamento legal junto com RH, uma vez que existem padrões e termos obrigatórios.

Uma vez definidos, gere um PDF que fará upload no portal do Azure em Acesso Condicional em Gerenciamento – Termos de Uso:

image

Veja que nessa opção já será onde poderemos auditar quem leu os termos e também fazer upload em diversos idiomas!

Importante: Veja a opção Periodicidade onde deixei como Mensal para que todos os meses (a cada 30 dias) os usuários tenham que aceitar novamente os termos. Outro item importante é a opção Exigir que os Termos sejam Expandidos.

Criando a Regra de Acesso Condicional para Termos de Uso

Para criar a Politica de Acesso, use o menu Politicas:

image

Nas politicas defina como regra de Permissão o Termo de Uso criado anteriormente. Veja que se houverem diversos termos de uso por conta de colaboradores e terceiros terem diferentes regras, poderá escolher qual se aplica.

image

No exemplo acima, seguimos a recomendação de termos uma politica de acesso especifica para os Termos de Uso e obrigando a leitura.

Claro que existem outras opções como a quem se aplica, regras combinadas, etc.

Resultado

E aqui o resultado, a cada 30 dias eu preciso expandir o Termo de Uso para acessar os recursos do Office 365:

Marcelo Sincic 
0365sincic Terms of Use 
In order to access 03-65sincic resource(s). you must read the Terms of use. 
Termo de uso 
Please click Accept to confirm that you have read and the terms of use,

No caso, eu já havia expandido os termos para que o botão Acessar estivesse habilitado  Winking smile

E-book recursos de segurança e Suporte a LGPD do Microsoft Office 365

Com a entrada em vigor da LGPD (Lei Geral de Proteção de Dados) em 19/Setembro/2020, a procura por produtos que deem suporte a vazamentos de dados se tornou prioritária.

Na prática já deveríamos ter essa preocupação a muito tempo, mas agora com a Lei aprovada é necessário implementar algumas regras.

Sabemos que nem todos os artigos tem a ver com regras técnicas, por exemplo ter metodologias implementadas que comprovem o cuidado que a empresa tem no dia a dia que pode ser ISOs, ITIL e outras que já sejam praticadas e reconhecidas.

Porem a proteção do vazamento por e-mail, ferramentas de IM e até roubo de equipamentos físicos é sim uma caraterística técnica. Sem falar em arquivamento de dados legais que não tem a ver com a LGPD mas sim com normas jurídicas e fiscais (retenção de 7 anos por exemplo).

Sendo assim, quais ferramentas o Microsoft Office 365 contem e podem ser habilitadas?

Nesse e-book abordamos as diferentes ferramentas e pacotes que as contem, lembrando que não é um guia de implementação com telas, mas sim descrição dos recursos.

image

Clique aqui para baixar!

Azure Virtual Datacenter (VDC) Parte II-Conceitos Básicos

No post anterior falamos sobre a migração para Cloud http://www.marcelosincic.com.br/post/Azure-Virtual-Datacenter-(VDC)-Parte-I-Migracao-AS-IS-e-TO-BE.aspx 

Neste post vamos entender os conceitos básicos, que são representados por esse diagrama:

image

Cada parte representa um dos pilares que sustentam um Datacenter Virtual:

  • Encriptação – Todos os dados trafegados dentro de um datacenter onde vários clientes se hospedam precisam ser protegidos de forma que um não tenha acesso aos dados de outros. Isso envolve criptografia de comunicação, discos e trafégo
  • Identity – Um modelo consistente de identidade onde os clientes consigam se logar e ver seus objetos com todos os recursos disponiveis. No caso do Azure isso é feito pelo Active Directory multi-tenant (multi locatário). Como já conhecido no mercado sistemas de diretório permitem que multiplas empresas estejam hospedadas e compartilhem o modelo de banco de dados e autenticação com total isolamento
  • Software-Defined Networks – Como hospedar vários clientes se todos querem ter o mesmo range de IP e se comunicam pelos mesmos conjuntos de cabos?
    Esse é o desafio das SDNs, permitir trafego isolado. No passado faziamos isso com o recurso de VLAN mas era limitado a 65535. Hoje isso é feito de forma lógica por usar recursos como o NVRE e outros onde os pacotes de rede são tageados (marcados) a quem pertence, similar ao que a VLAN fazia mas sem o limite de 32 bits.
    Isso permite que multiplos clientes tenha o mesmo range de IP 10.0.0.0/24, já que cada rede virtual recebe um diferente TAG nos pacotes, com a criptografia e identidade garantindo a confiabilidade na entrega dos pacotes de dados
  • Compliance – De nada adiantaria se ao migrar para um datacenter público você ficasse preso a padrões que só funcionam lá. As clouds publicas precisam adotar os padrões de mercado para as redes se comunicarem. Isso não quer dizer que a forma como o Machine Learning da Microsoft é codificado é igual ao Machine Learning da AWS, mas sim que a parte básica segue padrões de interoperabilidade.
    Por exemplo, uma VMs na AWS pode se comunicar por IP com uma VM no Azure ou no Google Cloud, pois todas usam os mesmos protocolos, mesmo que um provedor tenha serviços agregados diferentes.
    O mesmo vale para uma aplicação em Moodle ou SAP, se está no Azure ou AWS não importa pois seguem os padrões de rede e comunicação (interchange) identicos.
    Por conta do compliance que posso deixar metade dos meus servidores local e os outros espalhados em 3 diferentes datacenter publicos e todos se comunicando normalmente.
  • Logging, Audit e Report – Ao migrar de uma nuvem privada (local) para uma pública preciso saber os custos e ter certeza que meus dados estão seguros e acessados só pelos meus usuários.
    Aqui não estamos tratando de log, auditoria e reports para o cliente e sim a infra interna para que o provedor tenha certeza que não há vazamento de dados, quem fez cada operação e reportar isso quando necessário.
    Por isso os cockpits de provedores de cloud pública são gigantescos. Precisam controlar e serem capazas de se refazer em qualquer tipo de falha que ocorra.
    Os primeiros datacenters surgiram do conceito de hosting, ou seja você tirava os servidores do seu rack em casa para levar ao provedor onde a eletrica, links e segurança fisica ficam por conta deles. Nesse modelo toda a responsabilidade de comunicação, segurança lógica e relatórios é sua.
    No modelo público uma boa parte dos recursos são alocados para controlar os recursos, por exemplo ao criar o antigo Microsoft Azure Pack (atualmente descontinuado) várias VMs eram criadas com o objetivo de fornecer os itens de controle.

Conclusão

Nesse segundo post falamos sobre os componentes básicos que formam uma cloud pública.

Sinta-se seguro ao colocar seus dados nesses provedores, eles são preparados para garantir o isolamento e segurança dos seus dados.

Microsoft ATA–Recuperação e Migração

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

Posted: out 24 2018, 15:02 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Login