Purview Insider Risk Management (IRM) Agora Integrado com ENTRA Conditional Access 25 março 2024 msincic Active Directory, Azure, Cloud computing, Cybersecurity, Microsoft 365, Microsoft Defender, Office 365, Purview, ENTRA Uma novidade bem interessante anunciada em preview a poucos dias é a integração [Leia mais]
Acesso Condicional com Uso de GPS 05 janeiro 2022 msincic Active Directory, Cloud computing, Governança, Office 365, Segurança Uma mudança importante implantada em Preview no final de Novembro no Azure Active Directory é a loca [Leia mais]
Compliance com Termo de Uso no Azure AD Acesso Condicional 05 janeiro 2022 msincic Active Directory, Cloud computing, Governança, Office 365, Segurança Uma necessidade das empresas com a LGPD (Lei Geral de Proteção de Dados) é que os funcionários, terc [Leia mais]
E-book recursos de segurança e Suporte a LGPD do Microsoft Office 365 28 setembro 2020 msincic Active Directory, Cloud computing, Governança, Office 365, Segurança, Sharepoint, Windows Azure, Azure 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. Clique aqui para baixar!
Azure Virtual Datacenter (VDC) Parte II-Conceitos Básicos 18 março 2019 msincic Active Directory, Azure Stack, Cloud computing, Microsoft Azure, Windows Azure Pack 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: 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 24 outubro 2018 msincic Active Directory, Windows ATA, Azure 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
Windows Defender ATP–Entenda o Novo Produto 24 julho 2016 msincic Active Directory, Azure, Microsoft Azure, System Center, Windows 10, Segurança, Windows ATP, Windows ATA Parte dos novos recursos do Windows 10 é a capacidade de detalhamento na segurança e integração com recursos do Microsoft DCU (Digital Crime Unit), que é a unidade da Microsoft que trabalha com o departamento de defesa para gerar e identificar ataques ao redor do mundo (https://blogs.windows.com/windowsexperience/2016/03/01/announcing-windows-defender-advanced-threat-protection/). Tipos de Proteção Disponiveis Em geral os antivírus são baseados em DAT que são arquivos com assinaturas de vírus e conseguem identificar programas que tenham atividades ou parte destes códigos considerados perigosos. Nessa categoria estão todos os antivírus atuais, o que inclui o Windows Defender. Já os sistemas de proteção avançados contem com análise comportamental interna e externa, ou seja, eles identificam potenciais ameaças por comportamentos como fazem alguns produtos da Symantec e McAfee, que identifica maquinas enviando pacotes para outras maquinas, logins com força bruta, etc. Já os sistemas de proteção comportamental com análise externa são produtos bem diferentes. Eles analisam comportamentos de maquinas no ambiente e comunicações externas. Com isso é possível identificar: Um grupo de maquinas recebendo pacotes de uma determinada maquina com conteúdo suspeito Pacotes oriundos de países onde o ataque de phishing e similares são comuns Pacotes oriundos de maquinas já identificadas como “zumbi” Ou seja, com base na análise do próprio ambiente e de comportamento de hackers, é possível identificar que determinado hacker está tentando invadir uma empresa ao analisas que este hacker está enviando pacotes para a rede da empresa alvo. O que é o ATA e o ATP Nos produtos Microsoft esse produto é o ATA (Advanced Thread Analisys) que trabalha no Active Directory e logins, e o ATP (Advanced Thread Protection) que trabalha com Machine Learning (análise de dados) sobre os logs das maquinas individuais. Na prática o Windows Defender ATP trabalha com o mesmo log que o Windows Defender, mas online e com base nas análises e dados do DCU. Com isso é possível identificar ameaças que não são encontradas nos tradicionais DAT ou com base apenas em uma única maquina que é a forma como os antivírus tradicionais trabalham. O ATA é parte do EMS (Enterprise Mobility Suite), mas pode ser adquirido a parte: https://www.microsoft.com/pt-br/server-cloud/products/advanced-threat-analytics/overview.aspx O ATP ainda está em preview com acesso por solicitação: https://www.microsoft.com/en-us/WindowsForBusiness/windows-atp Overview do ATP Como já possuo acesso ao ATP, vamos ver como ele funciona. Para pedir esse acesso, entre na página acima e complete com seus dados. É possível incluir maquinas de seu ambiente, mas o sistema gera algumas maquinas com vírus e problemas para testes automaticamente. Note nas telas abaixo que o usuário utilizado é gerado pela Microsoft para os testes. Ao receber o acesso, o primeiro passo é indicar tempo de retenção e perfil da empresa que serve para elaborar threads por tipo de segmento: Na sequencia geramos o pacote ou o script para distribuição das configurações. Note que é possível criar os pacotes para distribuição por GPO, SCCM, Intune ou Local que é o que utilizarei nos meus testes: O passo seguinte é baixar o pacote, no meu caso o Local Script: O script contem um arquivo CMD para ser executado manualmente nas maquinas que desejo que o log do Defender seja enviado para o ATP. Esse script cria uma chave no registro para indicar o meu tenant e ativar o ATP: A partir de agora as suas maquinas passarão a enviar dados para o ATP em algumas horas. No caso do meu teste, posso utilizar os dados da maquina que a Microsoft gera com testes e ver os alertas e o dashboard. A primeira tela é o Dashboard que indica o comportamento geral no ambiente monitorado: Neste caso não tenho alertas gerados nos últimos 30 dias, mas tenho os de criação do tenant para demonstrar como utilizar o gerenciamento de alertas: Cada alerta pode ser ignorado, marcado como resolvido ou suprimido em todo o tenant ou apenas para esta maquina específica: Conclusão Este tipo de análise dos dados é essencial para a segurança da corporação. Em breve disponível como serviço no Azure, o ATP é uma nova forma de analisar e garantir seu ambiente.
Novo Azure AD Connect 29 junho 2015 msincic Microsoft Azure, Active Directory, Windows Azure Na semana passada a Microsoft liberou a nova ferramenta para sincronização de AD local com o Azure AD. Essa nova ferramenta tem as mesmas funcionalidades das anteriores DirSync e ADDSync, mas acrescesta facilidade na administração do serviço e acesso aos conectores. Para baixar e ver detalhes: https://azure.microsoft.com/en-gb/documentation/articles/active-directory-aadconnect/ Instalação e Upgrade do Dirsync Para quem já tem o Dirsync ou o ADDSync instalado o Azure AD Connect irá fazer o upgrade e solicitar apenas a credencial do Azure para configurar, mas após o upgrade é possivel alterar facilmente as configurações. A sequencia abaixo mostra o upgrade, sendo bem simples pedindo apenas as contas online e on-premisse: Configuração Pós-Instalação A interface do Azure AD Connect é realizada com ferramentas gráficas acessiveis pelo Menu Iniciar: A ferramenta que torna mais fácil configurar como comentado no inicio do artigo é o Synchronization Service, onde ao abrir já é possivel ver os conectores habilitados, o estado da sincronização, log das ultimas sincronizações e utilitários na lateral: Por exemplo, para sincronizar manualmente basta clicar sobre uma das conexões e escolher como quer sincronizar (Connectors –> Run): Visualização, Atualização e Criação de Conectores Ao clicar em qualquer um dos conectores abre-se um wizard onde podemos alterar os conectores básicos ou criar novos conectores. O wizard é muito simples e funcional, como mostram as imagens abaixo utilizando o Properties: E para criar novos conectores, ao clicar em Create temos criar os diversos tipos de conectores on-premisse ou online utilizando o wizard das imagens acima. Vale a pena fazer o upgrade para quem tem o Dirsync e o AADSync, pois esta nova ferramenta é muito completa e simples facilitando o acesso aos configurações, alterações e log das operações.
Alteração no Kerberos do Windows 2012 pode causar Acesso Negado 28 outubro 2012 msincic Active Directory, Windows, Windows 2003, Windows 2008, Windows 2012 Em uma reunião com os Microsoft PFEs Gilson Banin e Marcelo Ferratti foi comentado sobre uma alteração no método como o Windows 2012 gera um Ticket de autenticação pelo Kerberos, chamado de “KDC Resource SID Compression”. Situação Atual Como já é sabido, um Ticket de autenticação leva o SID do usuário e dos grupos do qual ele faz parte, além do SID History em casos de migração anterior. Em alguns casos, principalmente dominios muito grandes, o Ticket podia estourar o limite padrão de 12 Kb e gerar problemas na autenticação. Vale lembrar que pelo mesmo motivo um usuário não pode fazer parte de mais do que 1024 grupos. Atuamente o Ticket (PAC) é composto por SIDs completos: Os valores padrão de identificação (S-1-5), o SID do dominio e o RID individual do objeto no ultimo bloco: S-1-5-21-3419695430-3854377854-1234 S-1-5-21-3419695430-3854377854-1466 S-1-5-21-3419695430-3854377854-1675 S-1-5-21-4533280865-6432248977-6523 S-1-5-21-4533280865-6432248977-6578 Alteração no Windows 2012 A mudança no KDC consiste em não mais incluir no Ticket dados repetidos, com isso o Ticket gerado por um Domain Controller com Windows 2012 fica com menor tamanho e resolve o problema de ser necessário a alteração do tamanho do Ticket. Assim, o mesmo exemplo anterior de Ticket ficaria: S-1-5-21-3419695430-3854377854-1234 -1466 -1675 S-1-5-21-4533280865-6432248977-6523 -6578 O problema é que servidores anteriores ao Windows 2012 não “entendem” o novo Ticket e só permitirá acesso as ACEs que sejam completas, portanto o usuário conseguiria acessar locais onde a permissão foi concedida nos casos 1 e 4 do exemplo, mas não acessaria caso a permissão seja de um dos outros SIDs. Conclusão Em um dominio onde ainda existam servidores anteriores ao Windows 2012, o que inclui o Windows 2008 R2, o acesso ao servidor de arquivos, Exchange e qualquer outro que seja baseado no Kerberos terá problemas de acesso negado. Remediação Crie a chave de Registry Dword DisableResourceGroupsFields em HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kdc\Parameters para desabilitar este recurso. Mais Informações: http://support.microsoft.com/kb/2774190
Artigos no Wiki MIVP #12–System Center Orchestrator Automatizando Tarefas 12 julho 2012 msincic Active Directory, Orchestrator, System Center Continuando a parceria com a agência de publicidade para a montagem de 20 artigos referentes a Private Cloud com System Center 2012, esta semana publicamos o artigo no portal MIVP do Wiki, desta vez focados no System Center Orchestrator http://social.technet.microsoft.com/wiki/contents/articles/12298.system-center-orchestrator-automatizando-tarefas-pt-br.aspx O artigo aborda a instalação, configuração, importação de Integration Packs, criação de Runbooks, gerenciamento no console web e uma demo em video. Em breve os próximos artigos que irão abordar App Controller e SCVMM: System Center AppController - Monitore Aplicações System Center Virtual Machine Manager 2012 - Instalação, Configuração e Administração System Center Virtual Machine Manager 2012 - Administrando Multiplos Hypervisors System Center Virtual Machine Manager 2012 - Serviços, Automação de Storage e Network Series: http://www.marcelosincic.com.br/blog/post/Artigos-no-Wiki-1-e-2-O-que-e-uma-Nuvem-Privada-e-Nuvem-Privada-Microsoft-e28093-beneficios-para-as-organizacoes.aspx http://www.marcelosincic.com.br/blog/post/Artigos-no-Wiki-MIVP-3-4-e-5-Conheca-a-Suite-System-Center-2012-Instalacao-e-Configuracao-do-DPM-2012-e-Uso-de-Fitas-no-DPM-2012.aspx http://www.marcelosincic.com.br/blog/post/Artigos-no-Wiki-MIVP-6-7-8-e-9-System-Center-Configuration-Manager-2012e28093Da-Instalacao-ao-Endpoint-Protection.aspx http://www.marcelosincic.com.br/blog/post/Artigos-no-Wiki-MIVP-10-e-11-System-Center-Operations-Manager-2012e28093Instalacao-Configuracao-e-Novos-Recursos.aspx