Esse repositório não é oficial, criado, desenvolvido, afiliado, apoiado, mantido ou endossado pela organização Trend Micro.
A documentação oficial será sempre a sua melhor amiga: 😄
- https://cloudone.trendmicro.com/docs/workload-security/
- https://help.deepsecurity.trendmicro.com/12_0/on-premise/migration.html
Com esses pontos de atenção em mente, você pode ter uma estimativa de quanto tempo e esforço levará para migrar o seu ambiente!
Este Repositório está ARQUIVADO e possivelmente no momento que está lendo ele, a informação disponível aqui pode não estar mais correta/ atualizada/ valida com a tecnologia. Consulte a documentação oficial para mais e melhores informações
😄 CRIAÇÃO DA NOVA CONSOLE DO CLOUD ONE: WORKLOAD SECURITY
Os clientes precisarão migrar as permissões de usuário e roles do seu Deep Security para o Workload Security, para continuar dando suporte, visibilidade e gerenciamento.
- Cadastre-se para uma nova conta no Cloud One - Workload Security ao clicar em "Create an Account" no Portal do Cloud One.
As configurações de usuários e roles no Workload Security são quase idênticas à implementação no Deep Security.
- Permitir tráfego de saída para portas e URLs do Cloud One - Workload Security
Teste a conexão para o Cloud One - Workload Security
- test-netconnection relay.deepsecurity.trendmicro.com -Port 443
- test-netconnection app.deepsecurity.trendmicro.com -Port 443
- test-netconnection agents.deepsecurity.trendmicro.com -Port 443
- test-netconnection dsmim.deepsecurity.trendmicro.com -Port 443
❤️ MIGRAÇÃO DO(S) CONECTOR(ES)
Identifique Cloud Connectors e VMware (AWS, Azure e/ou GCP) para serem migrados. Embora o inventário e a configuração possam ser recuperados programaticamente, credenciais não podem. No caso de grandes volumes de conectores a serem migrados, avalie e discuta as possibilidades de automação.
- Identifique os Connectors a ser migrados;
- Colete as Credenciais;
- Add Connectors para o Workload Security;
🖖 MIGRAÇÃO DO(S) GRUPO(S)
Pode ser exigido a segmentação dos sistemas para gerenciar o inventário do host ou controle de acesso aos sistemas. A estrutura do grupo pode ser copiada como está ou reestruturada conforme considerado apropriado por você. Se a estrutura de grupo existente for recriada como está no Workload Security, e se desejável para aliviar a carga de uma hierarquia de um grande grupo, este processo pode ser automatizado via API.
- Pesquise grupos existentes para migração.
- Criar uma estrutura de grupo(s) no Workload Security.
- Valide a estrutura de grupo(s).
- Registre grupos que serão usados para hospedar sistemas Linux durante esta migração.
👌 CONFIGURAÇÃO DO PROXY
A configuração das comunicações de proxy para atualizar os Agents, Appliances, e Relays, quando necessário, é definida em Configurações de sistemas do Deep Security Manager ou na console do Workload Security. Essas configurações devem ser migradas antes da migração da(s) política(s) para que as referências fiquem intactas.
- Exportar configurações de proxy já existentes do Deep Security Manager;
- Exclua todas as configurações de proxy existentes do Workload Security Console (se aplicável);
- *** A etapa anterior só deve ser concluída durante o esforço de migração inicial e não deve ser repetida nas tentativas de importação subsequentes; ***
- Importar configurações de proxy para a console do Workload Security;
🏆 MIGRAÇÃO DA(S) POLITICA(S)
As Security Policies serão migradas do Deep Security para o Workload Security. A hierarquia e a estrutura organizacional das Security Policies podem ser complexas, por isso, estes pontos precisaram de detalhes adicionais após a revisão da estrutura da política atual para determinar o caminho mais adequado a seguir, e se esse texto faz sentido ou se adequa ao seu tipo de ambiente. Além das configurações de política, deve-se tomar cuidado e atenção com a migração de listas e objetos adicionais referenciados por, mas que não fazem parte do objeto da política.
*** É altamente Recomendado realizar uma revisão da política, listas, exceções e objetos antes de mudar para a nova plataforma. ***
Esta seção irá detalhar algumas observações em itens de configuração a serem revisados e possivelmente migrados:
-
Security Policy Module configurations
-
Anti-Malware Module configurations
-
Anti-Malware configuration
-
Anti-Malware scan schedule
-
Anti-Malware proxy configurations
-
Anti-Malware Directory Lists
-
Anti-Malware File Lists
-
Anti-Malware File Extension Lists
- Anti-Malware Process Image File Lists
- Web Reputation Module configurations
- Web Reputation configuration
- Web Reputation Allowed lists
- Web Reputation Blocked lists
- Web Reputation proxy configurations
- Application Control Module configuration
- Global Rules
- Integrity Monitoring Module configurations
- Integrity Monitoring configuration
- Integrity Monitoring Rules assigned
- Log Inspection Module configurations
- Log Inspection configuration
- Log Inspection Rules assigned
- Firewall Module configurations
- Firewall Module configuration
- Firewall rules assigned
-
IP lists
-
Port lists
-
MAC lists
-
Stateful Configurations
-
Interface Isolation Patterns
-
Contexts
- Intrusion Prevention configurations
- Intrusion Prevention configuration
- Intrusion Prevention rules assigned
-
Application Type custom rules or customizations
- Policy Interface Types customization
- Policy Settings
- Policy overrides
- Syslog Configurations
🏅 MIGRAÇÃO DO(S) USUÁRIO(S) E ROLES
Role Based Access Control em funções pode ser um mecanismo crítico para delegar o gerenciamento de sistemas e políticas específicas.
Não há mecanismo na console disponível para exportação ou importação de roles ou usuários.
As roles devem ser criadas antes dos usuários para que uma role possa ser atribuída durante a criação do usuário.
👓 CONFIGURAÇÕES ADICIONAIS
O Deep Security e o Workload Security têm várias configurações adicionais e opcionais que podem estar em uso. A recomendação é para revisar o uso dessas configurações e identificar aquelas que podem ser migradas.
- Integrity monitoring auto-tagging
- Event Forwarding
- Event Based Tasks
- Scheduled tasks
- User security requirements
🎯 AVALIAÇÃO E CONFIGURAÇÃO DE REDE
Dado que o Workload Security é entregue como uma plataforma SaaS, será necessária conectividade da sua infraestrutura para os sistemas da Trend Micro.
Esta seção se concentrará especificamente na conectividade do agente e não abordará os requisitos do navegador para a console de gerenciamento. Detalhes adicionais sobre as configurações de proxy podem ser encontrados aqui.
Os agentes exigirão, no mínimo, acesso aos seguintes URLs e portas
- agents.deepsecurity.trendmicro.com:443
- app.deepsecurity.trendmicro.com:443
- relay.deepsecurity.trendmicro.com:443
URLs adicionais podem ser necessários para recursos opcionais, incluindo Smart Scan, File Reputation e Web Reputation. A documentação completa de URLs e portas pode ser encontrada aqui.
☕ CONFIGURAÇÃO DE RELAY(S)
Alguns clientes podem ter uma infraestrutura de relay(s) já existente que pode ser replicada para gerenciar o consumo de largura de banda em toda a infraestrutura.
E é possível replicar a infraestrutura de relay(s) existente e a topologia para distribuição de atualização do Workload Security e avaliação de uma retransmissão "top of tree" adicional para replicar a update source primária existente.
🏁 TESTE DO AGENTE
O teste deve ser focado na validação da migração:
- Escolha um agente na já existente infraestrutura do Deep Security Manager.
- Execute o script de migração [Apêndice 1 item A]
- Valide o sucesso da reativação e da atribuição da Security Policy
- Verifique se o agente está disponível na aba Computers no Workload Security
- Verifique se a saída do comando no [Apêndice 1 item B] corresponde a URL esperada
- Verifique se o Workload Security mostra a política correta atribuída na console
- Verifique se a saída do comando no [Apêndice 1 item C] corresponde ao nome da Security Policy esperada
Este apêndice detalha referências adicionais, incluindo scripts e outras orientações de configuração, use conforme julgue necessário.
Este script foi projetado para facilitar a automação para a migração do agente. Em um alto nível, ele irá:
- Desativar a instalação atual do agente
- Reativar o agente no Workload Security com nova configuração
Este é um Script de exemplo. Os scripts com mais detalhes serão criados pela console do Workload Security para cada grupo de computador / Security Policy / local de rede.
Alguns detalhes, como policyid ou policyname ou groupid , são opcionais e podem ser inseridos nos novos comandos de ativação para reduzir o número de variações de script necessárias em todo o ambiente.
Outras configurações, como Proxy e Relay devem ser só usadas se estão implementadas no ambiente.
O exemplo abaixo serve para ser executado em máquinas Linux:
/opt/ds_agent/dsa_control -r
sleep 30
PROXY_ADDR_PORT='1.2.3.4:3128'
RELAY_PROXY_ADDR_PORT='1.2.3.4:3128'
/opt/ds_agent/dsa_control -x dsm_proxy://$PROXY_ADDR_PORT/
/opt/ds_agent/dsa_control -y relay_proxy://$RELAY_PROXY_ADDR_PORT/
/opt/ds_agent/dsa_control -a dsm://agents.deepsecurity.trendmicro.com:443/ "tenantID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" "token:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" "policyid:1" "policyname:mypolicy" "groupid:12345"
O exemplo abaixo serve para ser executado em máquinas Windows:
& $Env:ProgramFiles"\Trend Micro\Deep Security Agent\dsa_control" -r
Start-Sleep -s 50
& $Env:ProgramFiles"\Trend Micro\Deep Security Agent\dsa_control" -a dsm://agents.deepsecurity.trendmicro.com:443/ "tenantID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" "token:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" "policyid:1" "groupid:12345"
No caso acima, não estamos configurando Proxy e Relay no agente
Dependendo de como o seu ambiente está confirgurado, os comandos a seguir, podem necessitar serem executados como root
/opt/ds_agent/sendCommand --get GetConfiguration | grep SecurityProfile | awk -F"name='" '{printf $2}' | awk -F"'" '{print $1}'
Este comando produzirá a url da DSM no qual o agente está registrado atualmente. Use-o para validar se um agente foi reativado para o Workload Security corretamente. O dsmUrl esperado é https://agents.deepsecurity.trendmicro.com:443/
/opt/ds_agent/dsa_query --cmd GetAgentStatus | grep dsmUrl
Este comando retornará o nome e o ID da política de segurança atribuída ao DSA.
/opt/ds_agent/sendCommand --get GetConfiguration | grep SecurityProfile
Este é um exemplo do comando Curl que pode ser usado para listar Security Roles via API
curl -X GET $url/api/roles -H "api-secret-key: $secret" -H "api-version: v1" -k | json_pp
- -k é usado porque o DSM está usando um self-signed certificate
- json_pp é usado para exibir a saída no formato JSON
💯 OBSERVAÇÕES
- Depois de importar as políticas, cheque a direção da comunicação e se está definida como Agent-initiated;
- A comunicação bidirecional pode causar problemas de agentes offline se o Workload Security não for capaz de iniciar uma conexão com os hosts, especialmente quando usa um endereço de IP privado;