Introdução

Este documento descreve como examinar o recurso Cisco Secure Endpoint Identity Persistence. 

O que é persistência de identidade?

A Persistência de identidade é um recurso que permite manter um registro de eventos consistente em ambientes virtuais ou quando os computadores são recriados. Você pode vincular um Conector a um endereço MAC ou nome de host para que um novo registro de conector não seja criado toda vez que uma nova sessão virtual for iniciada ou uma imagem do computador for recriada. Esse recurso foi projetado especificamente para ambientes de VM e de laboratório não persistentes. O método recomendado é o nome do host em toda a empresa e habilitar o recurso nas políticas em que você deseja sincronizar identidades.

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Acesso ao portal Cisco Secure Endpoints
• Você precisa entrar em contato com o Cisco TAC para que ele habilite o recurso de persistência de identidade na sua organização. 
• A Persistência de Identidade só tem suporte no Sistema Operacional Windows

Quando Você Precisa De Persistência De Identidade?

A Persistência de identidade é uma funcionalidade em endpoints seguros que ajuda na identificação de endpoints seguros no momento do registro inicial do conector e os compara com entradas conhecidas anteriormente com base em parâmetros de identidade, como endereço MAC ou nome de host para esse conector específico. A implementação desse recurso não só ajuda a manter uma contagem de licenças correta, mas também, e o mais importante, permite o rastreamento adequado de dados históricos em sistemas não persistentes.  

Implantação de endpoint virtual

O uso mais comum da persistência de identidade em implantações virtuais é a implantação da infraestrutura de desktop virtual (VDI) não persistente. Os ambientes de desktop do host VDI são implantados mediante solicitações ou necessidades do usuário final. Isso inclui fornecedores diferentes, como VMware, Citrix, AWS AMI Golden Image Deployment, etc.

O VDI persistente, também chamado de "VDI com informações de estado", é uma configuração em que o desktop de cada usuário individual é exclusivamente personalizável e "persiste" de uma sessão para outra. Esse tipo de Implantação virtual não precisa da funcionalidade da Persistência de identidade, pois essas máquinas não devem ter imagens criadas novamente regularmente. 

Como ocorre com todos os softwares que poderiam interagir com o desempenho do Secure Endpoint, os aplicativos de desktop virtual precisam ser avaliados quanto a possíveis exclusões para maximizar a funcionalidade e minimizar o impacto.   

Referência: https://docs.vmware.com/en/VMware-Horizon/2103/horizon-architecture-planning/GUID-AED54AE0-76A5-479B-8CD6-3331A85526D2.html

Implantação de endpoint físico

Há dois cenários que podem ser aplicados para a implantação da persistência de identidade em máquinas físicas de endpoints seguros:

• Quando você implanta ou recria um endpoint físico com uma imagem dourada com o conector Secure Endpoint pré-instalado, o Sinalizador Goldenimage deve ser ativado. A persistência de identidade pode ser usada para evitar duplicação em instâncias de máquinas com nova imagem, mas não é necessária. 

• Quando você implanta ou recria um endpoint físico com uma imagem de ouro e instala posteriormente o conector Secure Endpoint, a Persistência de identidade pode ser usada para evitar duplicação em instâncias de máquinas com nova imagem, mas não é necessária. 

Visão Geral do Processo de Persistência de Identidade

1. O conector é baixado com um token no arquivo policy.xml, que o vincula de volta à política em questão no lado da nuvem.
2. O conector é instalado, armazenando o token em local.xml, e o conector faz uma solicitação POST ao portal com o token em questão.
3. O lado da nuvem passa por essa ordem de operações:
   a. O computador verifica a política quanto à configuração da política de sincronização de ID. Sem isso, o registro ocorre normalmente.
   b. Dependendo das configurações da política, o Registro verifica o nome do host ou o endereço MAC no banco de dados existente.
        Entre empresas:todas as políticas são verificadas quanto a uma correspondência no nome do host ou no MAC, dependendo da configuração. O GUID do objeto correspondente é anotado e enviado de volta à máquina cliente final. A máquina cliente assume então o UUID e assume qualquer configuração de grupo/política do host correspondente anteriormente. Isso substitui as configurações de política/grupo instaladas.
        Entre políticas: o token corresponde à política no lado da nuvem e procura um objeto existente com o mesmo nome de host ou endereço MAC DENTRO dessa política apenas. Se existir algum, ele assume o UUID. Se não houver um objeto existente vinculado a essa política, um novo objeto será criado. Observação: podem existir duplicatas para o mesmo nome de host vinculado a outros grupos/políticas.
   c. Se não for possível fazer uma correspondência com um grupo/política devido a um token ausente (registrado anteriormente, prática de implantação incorreta etc.), o conector se enquadra no grupo/política de conector padrão definido na guia comercial. Com base na configuração do grupo/política, ele tenta revisar todas as políticas de uma correspondência (em toda a empresa), somente aquela política em questão (em toda a política) ou nenhuma (nenhuma). Com isso em mente, geralmente é aconselhável colocar seu grupo padrão para ser um que contenha suas configurações de sincronização de ID desejadas para que as máquinas sejam sincronizadas novamente corretamente no caso de um problema de token.

Identifique duplicatas em sua organização

Scripts GitHub disponíveis externamente

Localize os UUIDs duplicados: https://github.com/CiscoSecurity/amp-04-find-duplicate-guids

Motivos pelos quais as duplicatas são criadas

Há algumas instâncias comuns que podem fazer com que as duplicatas sejam vistas no seu lado:

1. Se estas etapas foram seguidas enquanto o Pool de VDI: 

• A implantação inicial em uma VM/VDI não persistente é feita com a persistência de identidade desativada (use uma imagem dourada, por exemplo).
• A política é atualizada na nuvem para ter a Persistência de Identidade habilitada, que, durante o dia, a atualiza no endpoint.
• As máquinas são atualizadas/recriadas (use a mesma imagem dourada), que coloca a política original de volta no endpoint sem a Persistência de identidade.
• A política localmente não tem Persistência de Identidade, portanto o servidor de registro não verifica registros anteriores.
• Esse fluxo resulta em Duplicatas.

2. O usuário implanta a gold image original com a persistência de identidade ativada na política em um grupo e, em seguida, move um endpoint para outro grupo no portal de endpoints seguros. Em seguida, ele tem o registro original no grupo ‘movido para’, mas cria novas cópias no grupo original quando as VMs são recriadas/reimplantadas.

Observação: esta não é uma lista completa de cenários que podem causar duplicatas, mas algumas das mais comuns.

Problemas comuns/sintomas com implantação de persistência de identidade incorreta

A implementação incorreta da persistência de identidade pode causar estes problemas/sintomas:

• Contagem de assento do conector incorreta
• Resultados Incorretos Relatados
• Incompatibilidade de dados da trajetória do dispositivo
• Trocas de nome de máquina dentro dos logs de auditoria
• Os conectores registram e cancelam o registro aleatoriamente do console
• Os conectores não se reportam corretamente à nuvem
• Duplicação de UUID
• Duplicação do nome da máquina
• Inconsistência de dados
• As máquinas são registradas na política/grupo comercial padrão após a recomposição

• Implantação manual com a Persistência de identidade habilitada na política.

- Se você implantar o ponto de extremidade manualmente por meio da opção de linha de comando com a Persistência de Identidade já habilitada na política e, em seguida, desinstalar o ponto de extremidade e tentar reinstalar com o pacote de um Grupo/Política diferente, o ponto de extremidade voltará automaticamente para a política original.

- Saída de logs SFC mostrando que o switch de política está ativado sozinho em 1-10seg

(167656, +0 ms) Dec 14 11:37:17 [1308]: Util::VerifyOsVersion: ret 0
(167656, +0 ms) Dec 14 11:37:17 [1308]: ERROR: ETWEnableConfiguration::IsETWEnabled: ETW not initialized due to incompatibile OS 
(167656, +0 ms) Dec 14 11:37:17 [1308]: UiPublisher::PublishPolicyInfo: Name -UTMB-WinServer-Protect Serial 819 << ---------------------- Freshly Installed
(167656, +0 ms) Dec 14 11:37:17 [1308]: UiPublisher::PublishLastPolicyUpdateTime: Publish Last Policy Update time 1670439264
(167656, +0 ms) Dec 14 11:37:17 [1308]: UiPublisher::PublishAgentVersion: Agent Version 7.5.7.21234
(167656, +0 ms) Dec 14 11:37:17 [1308]: HeartBeat::PolicyNotifyCallback: EXIT
(167656, +0 ms) Dec 14 11:37:17 [1308]: AmpkitRegistrationHandler::PolicyCallback: EXIT (0)
.
.
.
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitRegistrationHandler::UpdateConfiguration: Enter
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitRegistrationHandler::UpdateConfiguration: Aborting - not registered
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitRegistrationHandler::ConnectionStateChanged: Starting Proxy Discovery
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendPolicyReloaded sending policy reloaded to UI. ui.data.policy.policyName -UTMB-WinServer-Audit << --------- Auto Switch to Old Policy
(173125, +0 ms) Dec 14 11:37:22 [4704]: PipeSend: sending message to user interface: 28, id: 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus: notifying UI: No Product
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus: notifying UI: No Product
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus: notifying UI: No Product
(173125, +0 ms) Dec 14 11:37:22 [4704]: UIPipe::SendStatus : engine1 (0, 0), engine2 (0, 0)
(173125, +0 ms) Dec 14 11:37:22 [4704]: PipeSend: sending message to user interface: 1, id: 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiStatusHandler::ConnectionStateChangedState: 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiPublisher::PublishConnectionStatus: State 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpApiServer.cpp:AmpApiServer::PublishScanAvailable:223: Cloud connection status 0, Tetra Available 0
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig: Enter
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig proxy server is NULL
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig: Direct connection detected
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitProxyHelper::LoadProxyFromConfig: Exit(1)
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiAgentGuidUpdater::ConnectionStateChanged
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiAgentGuidUpdater::RefreshAgentGuidUi: Agent GUID: e1a756e2-65ab-4cd6-a886-ff826d74f05d
(173125, +0 ms) Dec 14 11:37:22 [4704]: UiPublisher::PublishAgentGuid: Agent GUID did not change (e1a756e2-65ab-4cd6-a886-ff826d74f05d)
(173125, +0 ms) Dec 14 11:37:22 [4704]: AmpkitSubscriptionThread::NotificationWorker: Waiting on queue

O outro efeito colateral é tentar instalar um conector que pertence a um grupo diferente. Você verá no portal que o conector está atribuído ao grupo correto, mas com a política "errada" original

Isso se deve ao fato de como a persistência de identidade (ID SYNC) funciona.

Sem ID SYNC uma vez que o conector é completamente desinstalado ou usando a opção de linha de comando de registro novamente. Você deve ver a nova Data de criação e o GUID do conector em caso de desinstalação ou apenas o novo GUID do conector em caso de comando de novo registro. No entanto, com a ID SYNC, não é possível que a ID SYNC seja substituída pela antiga GUID e DATE. É assim que "sincronizamos" o host.

Se esse problema for observado, a correção deverá ser implementada por meio da alteração de política. Você precisará mover os pontos de extremidade afetados de volta para o Grupo/Política original e verificar se a política está sincronizada. Em seguida, mova o(s) endpoint(s) de volta para o Grupo/Política desejado

Práticas recomendadas de implantação

Configurar arquivo snapvol

Caso você use Volumes de Aplicativos para sua Infraestrutura de VDI, é recomendável fazer essas alterações de configuração na configuração do snapvol.cfg

Essas exclusões devem ser implementadas no arquivo snapvol.cfg:

Caminhos:

• C:\Program Files\Cisco\AMP
• C:\ProgramData\Cisco
• C:\Windows\System32\drivers
• C:\Windows\System32\drivers\ImmunetNetworkMonitor.sys
• C:\Windows\System32\drivers\immunetprotect.sys
• C:\Windows\System32\drivers\immunetselfprotect.sys
• C:\Windows\System32\drivers\ImmunetUtilDriver.sys
• C:\Windows\System32\drivers\trufos.sys

Chaves do Registro:

• HKEY_LOCAL_MACHINE\SOFTWARE\Immunet Protect
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Immunet proteger
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CiscoAMP
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CiscoAMPCEFWDriver
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CiscoAMPELAMDriver
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CiscoAMPHeurDriver
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CiscoOrbital
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CiscoSAM
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CiscoSCMS
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ImmunetProtectDriver
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ImmunetSelfProtectDriver
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Trufos

Em sistemas x64, adicione estes:

• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Immunet proteger
• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Immunet proteger

Referências: 

• https://docs.vmware.com/en/VMware-App-Volumes/index.html
• https://docs.vmware.com/en/VMware-App-Volumes/2103/app-volumes-admin-guide/GUID-0B588F2C-4054-4C5B-B491-F55BDA33A028.html

Planejamento de política do portal

Estas são algumas das práticas recomendadas que devem ser seguidas ao implementar a persistência de identidade no Secure Endpoint Portal:

1. É altamente recomendável usar políticas/grupos separados para endpoints de persistência de identidade para uma segregação mais fácil.

2. Se você planeja usar o Isolamento de Ponto Final e implementar a ação Mover Computador para Grupo mediante comprometimento. O grupo de destino também deve ter a Persistência de identidade habilitada e deve ser usado somente para computadores VDI.

3. Não é recomendável habilitar a Persistência de Identidade no Grupo/Política Padrão nas configurações da organização, a menos que a Persistência de Identidade tenha sido habilitada em Todas as políticas com o escopo de configurações em Toda a Organização.  

Configuração

Siga estas etapas para implantar o conector de Ponto Final Seguro com Persistência de Identidade:

Etapa 1. Aplique a definição de Persistência de Identidade desejada às suas políticas:

• No portal Secure Endpoint, navegue até Management > Policies.
• Selecione a política desejada na qual deseja habilitar a Persistência de identidade e clique emEditar.
• Navegue até a guiaConfigurações avançadas e clique na guia Persistência de identidade na parte inferior.
• Selecione a lista suspensa Persistência de identidade e escolha a opção que faça mais sentido para o seu ambiente. Consulte esta imagem.

Teste - 123

Há cinco opções que você pode escolher.

• Observe que o recurso não está habilitado. Os UUIDs do conector não são sincronizados com as novas instalações do conector sob nenhuma circunstância. Cada nova instalação gera um novo objeto de máquina.
• Por endereço MAC na empresa: instalações novas ou atualizadas buscam o registro de conector mais recente que tenha o mesmo endereço MAC para sincronizar dados históricos anteriores com o novo registro. Esta configuração examina todos os registros comerciais

  em todas as políticas na organização que têm a Sincronização de Identidade definida com um valor diferente de Nenhum. O Conector pode atualizar sua política para refletir a instalação anterior se ela for diferente da nova.  

• Por endereço MAC na política: instalações novas ou atualizadas buscam o registro de conector mais recente que tenha o mesmo endereço MAC para sincronizar dados históricos anteriores com o novo registro. Essa configuração procura apenas os registros associados à política usada na implantação. Se o Conector não tiver sido instalado anteriormente nesta diretiva, mas tiver estado ativo anteriormente em outra diretiva, ele poderá criar duplicatas.  
• Por nome de host entre empresas: instalações novas ou atualizadas procuram o registro de conector mais recente que tenha o mesmo nome de host para sincronizar dados históricos anteriores com o novo registro. Essa configuração procura todos os registros de negócios, independentemente das configurações de Persistência de Identidade em outras políticas, e o Conector pode atualizar sua política para refletir a instalação anterior se ela for diferente da nova. O nome de host inclui o FQDN para que possam ocorrer duplicatas se o conector se mover regularmente entre as redes (como um laptop).  
• Por nome de host na política: instalações novas ou atualizadas procuram o registro de conector mais recente que tem o mesmo nome de host para sincronizar dados históricos anteriores com o novo registro. Essa configuração procura apenas os registros associados à política usada para a implantação. Se o Conector não tiver sido instalado anteriormente nesta diretiva, mas tiver estado ativo anteriormente em outra diretiva, ele poderá criar duplicatas. O nome de host inclui o FQDN, de modo que as duplicatas também podem ocorrer se o conector se mover regularmente entre as redes (como um laptop). 

Observação: se você optar por usar a Persistência de identidade, a Cisco sugere que você use Por nome de host na empresa ou na política. Uma máquina tem um nome de host, mas pode ter mais de um endereço MAC e muitas VMs clonam os endereços MAC.

Etapa 2. Baixe o conector de endpoint seguro.

• Navegue para Gerenciamento > Conector de Download.
• Selecione o grupo para a política editada na Etapa 1. 
• Clique em Download para o Conector do Windows conforme mostrado na imagem.

Etapa 3. Implante o Conector nos endpoints.

• Agora você pode usar o conector baixado para instalar o Secure Endpoint (com a Persistência de identidade agora habilitada) manualmente em seus endpoints.
• Caso contrário, você também pode implantar o conector usando uma imagem dourada (consulte a imagem)

Observação: você precisa selecionar o instalador redistribuível. Esse é um arquivo de ~57 MB (o tamanho pode variar com as versões mais recentes) que contém os instaladores de 32 e 64 bits. Para instalar o conector em vários computadores, você pode colocar esse arquivo em um compartilhamento de rede ou enviá-lo para todos os computadores de acordo. O instalador contém um arquivo policy.xml que é usado como arquivo de configuração para a instalação.

Criação de imagem dourada

Siga as diretrizes de práticas recomendadas do documento do Fornecedor (VMware, Citrix, AWS, Azure e assim por diante) ao criar uma Imagem Dourada a ser usada no processo de Clonagem de VDI. 

Por exemplo, VMware Golden Image Process: https://docs.vmware.com/en/VMware-Horizon/2106/virtual-desktops/GUID-D9C46AEF-1C41-4711-BF9E-84362EBE6ABF.html.

Como você identificou o VMware, o processo de composição do AWS reinicia o Clonado (VMs filho) várias vezes antes da finalização da configuração da VM, o que causa problemas com o processo de registro do Secure Endpoint, pois nesse momento o Clonado (VMs filho) não tem os nomes de host finais/corretos atribuídos e isso faz com que o Clonado (VMs filho) use o nome de host Golden Image e registre na Secure Endpoint Cloud. Isso interrompe o processo de clonagem e causa problemas.

Isso não é um problema com o processo do conector de endpoint seguro, mas sim com a incompatibilidade com o processo de clonagem e o registro de endpoint seguro. Para evitar esse problema, identificamos algumas alterações a serem implementadas no processo de clonagem que ajudam a resolver esses problemas.

Essas são as alterações que precisam ser implementadas na VM Golden Image antes que a imagem seja congelada para clonagem

1. Use sempre o indicador Goldenimage na Imagem Dourada no momento da instalação do Ponto Final Seguro. 

2. Implemente as seções Script de Configuração de Imagem Dourada e Script de Inicialização de Imagem Dourada para localizar os scripts que ajudariam a ATIVAR o serviço de Ponto Final somente quando tivermos um nome de host final implementado nas VMs Clonadas (Filhas). Consulte a seção Problemas de Duplicação do VMware Horizon para obter mais detalhes.

Sinalizador de Substituição de Imagem Dourada

Quando você usa o instalador, o sinalizador a ser usado para imagens douradas é /goldenimage 1.

O flag de imagem de ouro impede que o conector seja iniciado e registrado na imagem base e, assim, no próximo início da imagem, o conector estará no estado funcional em que foi configurado pela política atribuída a ele.

Para obter informações sobre outros Sinalizadores, você pode usar o, consulte este artigo.

Quando você usa o instalador, o novo sinalizador a ser usado para imagens douradas é /goldenimage [1|0]

0 - Valor padrão - esse valor não acionará a opção de imagem de ouro e funcionará como se o instalador tivesse sido executado sem a opção. Não ignore o registro e a inicialização iniciais do conector na instalação.

C:\> CiscoInstaller_goldenimage.exe /R /S /goldenimage 0 [other options…]

1 - Instalar como uma imagem dourada. Essa é a opção típica usada com o sinalizador e é o único uso esperado. Ignora o registro inicial do Conector e a Inicialização na instalação.

C:\> CiscoInstaller_goldenimage.exe /R /S /goldenimage 1 [other flags here…]

Etapas da criação da imagem dourada

É uma prática recomendada instalar o conector por último para a preparação da Imagem Dourada.

1. Prepare a imagem do Windows de acordo com seus requisitos; instale todos os softwares e configurações necessários para a imagem do Windows, exceto o conector.
2. Instale o conector Cisco Secure Endpoint.

Use o sinalizador/goldenimage 1 para indicar ao instalador que esta é uma implantação de imagem dourada.

C:\> CiscoInstaller_goldenimage.exe /R /S /goldenimage 1

3. Implemente a lógica do script (se necessário) conforme descrito aqui

4. Instalação completa

5. Congelar sua imagem dourada

Depois que a Golden Image tiver aplicativos instalados, o sistema preparado e o Secure Endpoint tiver sido instalado com o sinalizador/goldenimageflag, o host estará pronto para ser congelado e distribuído. Depois que o host clonado é inicializado, o Secure Endpoint é iniciado e registrado na nuvem. Nenhuma outra ação é necessária em relação à configuração do conector, a menos que haja alterações que você queira fazer na política ou no host. Se forem feitas alterações após a conclusão do registro da imagem de ouro, esse processo deverá ser reiniciado. O sinalizador impede que o conector seja iniciado e registrado na imagem base. Na próxima inicialização da imagem, o conector estará no estado funcional em que foi configurado pela política atribuída a ele.

Observação: se a Golden Image for registrada na Secure Endpoint Cloud antes que você possa congelar a VM, é recomendável desinstalar e reinstalar o Secure Endpoint na Golden Image VM e depois congelar a VM novamente para evitar problemas de registro e conexão duplicada. Não é recomendável modificar nenhum valor de registro do Secure Endpoint como parte desse processo de desinstalação.

Atualize a imagem dourada

Você tem duas opções quando precisa atualizar uma imagem dourada para reter um conector não registrado.

Processo recomendado

1. Desinstale o conector.
2. Instalar as atualizações/upgrades do host.
3. Reinstale o conector após o processo da imagem de ouro usando os sinalizadores da imagem de ouro.
4. O host não deve iniciar o conector se o processo for seguido.
5. Congelar a imagem.
6. Antes de ativar os clones, verifique se a Golden Image não se registrou no portal para evitar hosts duplicados indesejados.

Processo Alternativo

1. Certifique-se de que o host não tenha conectividade com a Internet para impedir que o conector seja registrado.
2. Interrompa o serviço de conector.
3. Instale as atualizações.
4. Congelar a imagem após a conclusão das atualizações
5. O conector precisa ser impedido de se registrar para evitar a ocorrência de hosts duplicados. Quando você remove a conectividade, isso evita que ela alcance para se registrar na nuvem. Além disso, o conector que está sendo interrompido o manterá nesse estado até a próxima reinicialização, o que permitirá que os clones se registrem como hosts exclusivos.
6. Antes de ativar os clones, verifique se a Golden Image não se registrou no portal para evitar hosts duplicados indesejados.

Código de imagem dourado

Esta seção consiste em trechos de código que podem ajudar a suportar o Processo Golden Image e ajudariam a evitar duplicatas de conectores ao implementar a Persistência de identidade. 

Script de configuração de imagem dourada

Descrição do script de instalação

O primeiro script, 'Setup', é executado na Imagem Dourada antes de ser clonado. Ele deve ser executado manualmente apenas uma vez. Seu principal objetivo é estabelecer configurações iniciais que permitirão que o seguinte script funcione corretamente nas máquinas virtuais clonadas. Essas configurações incluem:

• Alterar a inicialização do serviço Cisco Secure Endpoint para manual para evitar a inicialização automática.
• Criar uma tarefa agendada que executa o seguinte script (Inicialização) na inicialização do sistema com os privilégios mais altos.
• Criar uma variável de ambiente de sistema chamada "AMP_GOLD_HOST" que armazena o nome de host da Golden Image. Isso seria usado pelo script de inicialização para verificar se temos que reverter as alterações

Configurar código de script

rem Turn AMP to manual start
sc config CiscoAMP start=demand

rem Add host name to a system variable that we can check on startup
setx -m AMP_GOLD_HOST %COMPUTERNAME%

rem Add the startup script to the startup scripts
rem /rp password when there is a password
schtasks /create /tn "Startamp" /tr "C:\Users\XXXXXX\Desktop\VMWareHorizonAMPStartup.bat" /sc onstart /rl highest /np

O código do script de instalação é bastante simples:

Linha 2: Altera o tipo de inicialização do serviço de proteção contra malware para manual.

Linha 5: Cria uma nova variável de ambiente chamada "AMP_GOLD_HOST" e salva o nome de host do computador atual nela.

Linha 9: Cria uma tarefa programada denominada "Startamp" que executa o script 'Startup' especificado durante a inicialização do sistema com os privilégios mais altos, sem precisar de uma senha.

Script de inicialização de imagem dourada

Descrição do script de inicialização

O segundo script, 'Startup', é executado em cada inicialização do sistema nas máquinas virtuais clonadas. Seu principal objetivo é verificar se a máquina atual tem o nome de host da 'Imagem Dourada':

• Se a máquina atual for a imagem dourada, nenhuma ação será tomada e o script será encerrado. O Secure Endpoint continuará em execução na inicialização do sistema, já que mantemos a tarefa agendada.
• Se a máquina atual NÃO for a imagem 'Dourada', as alterações feitas pelo primeiro script serão redefinidas:
  • Alterando a configuração de inicialização do serviço Cisco Secure Endpoint para automática.
  • Iniciando o serviço Cisco Secure Endpoint.
  • Removendo a variável de ambiente "AMP_GOLD_HOST".
  • Excluindo a tarefa agendada que executa o script de inicialização e excluindo o próprio script.

Código do script de inicialização

echo "Current hostname: %COMPUTERNAME% vs %AMP_GOLD_HOST%"

if "%COMPUTERNAME%" == "%AMP_GOLD_HOST%" ( goto same ) else ( goto notsame )

:same
rem Do nothing as we are still the golden image name
goto exit

:notsame
rem Turn AMP to autostart 
sc config CiscoAMP start=auto

rem Turn on AMP
sc start CiscoAMP

rem Remove environment variable
REG delete "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /F /V AMP_GOLD_HOST
schtasks /delete /tn Startamp

goto exit
:exit

Linha 2: Compara o nome do host atual com o valor armazenado "AMP_GOLD_HOST"; se eles forem iguais, o script salta para o rótulo "mesmo"; caso contrário, ele salta para o rótulo "não igual".

Linha 4-6: Quando o rótulo "mesmo" é alcançado, o script não faz nada, uma vez que ainda é a Imagem Dourada e prossegue para o rótulo "saída".

Linha 8-16: se o rótulo "notsame" for alcançado, o script executa as seguintes ações:

• Altera o tipo de inicialização do serviço de proteção contra malware para automático.
• Inicia o serviço de proteção contra malware.
• Remove a variável de ambiente "AMP_GOLD_HOST".
• Exclui a tarefa agendada chamada "Carimbo"

Observação: observe que os scripts contidos neste documento não são oficialmente suportados pelo TAC.

Observação: esses dois scripts permitem a inicialização do serviço Cisco AMP em ambientes de máquina virtual clonados. Configurando corretamente a imagem Golden e usando os scripts de inicialização, ele garante que o Cisco Secure Endpoint seja executado em todas as máquinas virtuais clonadas com a configuração correta.

Processo do AWS Workspace

Esta solução consiste em um script 'Setup' executado na Imagem de ouro antes da clonagem e um script 'Startup' executado em cada máquina virtual clonada durante a inicialização do sistema. O principal objetivo desses scripts é garantir a configuração adequada do serviço e, ao mesmo tempo, reduzir a intervenção manual. Esses dois scripts permitem a inicialização do serviço Cisco Secure Endpoint em ambientes de máquina virtual clonados. Configurando corretamente a imagem Golden e usando os scripts de inicialização, ele garante que o conector Cisco Secure Endpoint seja executado em todas as máquinas virtuais clonadas com a configuração correta

Consulte as seções Golden Image Setup Script Code e Golden Image Startup Script Code para obter o código de script necessário para implementar a Golden Image no AWS Workspace.

Depois de executar o script de instalação, podemos verificar se as alterações de configuração foram implantadas com êxito.

Como executamos essa ação na imagem de ouro, todas as novas ocorrências terão essa configuração e executarão o script de inicialização na inicialização.

Problemas de duplicação do VMware Horizon

Com o VMware Horizon, pudemos identificar que as máquinas VMs filhas, quando estão sendo criadas, são reinicializadas várias vezes como parte do processo de composição do Horizon. Isso causa problemas quando os serviços de Ponto de Extremidade Seguro são ativados quando as VMs Filho não estão prontas (elas não têm o Nome NetBios final/correto atribuído). Isso causa mais problemas com o Secure Endpoint sendo confundido e, portanto, o processo é interrompido. Para evitar que esse problema ocorresse, criamos uma solução para essa incompatibilidade com o Horizon Process, que envolve a implementação dos scripts anexados na máquina virtual Golden Image e o uso da funcionalidade do script de pós-sincronização para o VMware Horizon: https://docs.vmware.com/en/VMware-Horizon/2103/published-desktops-applications.pdf.

Configurações/alterações não mais necessárias

• Não será mais necessário desinstalar e reinstalar o Secure Endpoint se desejar fazer alterações na Imagem dourada após a primeira implantação.
• Não há necessidade de definir o Secure Endpoint Service como Delayed Start.

Metodologia de script

Exemplos dos scripts podem ser encontrados abaixo. 

• Script Golden Image Setup: este script deve ser implementado quando o conector Secure Endpoint estiver instalado, conforme descrito anteriormente com os sinalizadores documentados anteriormente. Este script modificou o serviço Secure Endpoint para Início manual e salva o nome de host Golden Image como uma Variável de ambiente para referência na próxima etapa.

• Script de inicialização de imagem dourada: esse script é uma verificação lógica em que correspondemos o nome de host nas VMs clonadas (filhas) com o armazenado na etapa anterior para garantir que identificamos quando a VM clonada (filha) obtém um nome de host diferente da VM da imagem dourada (que seria o nome de host final da máquina) e, em seguida, você inicia o Secure Endpoint Service e altera esse nome para Automático. Você também remove a Variável de ambiente do script mencionado anteriormente. Isso normalmente é implementado com o uso dos mecanismos disponíveis na solução de implantação, como o VMware. No VMware, você pode usar os parâmetros de pós-sincronização: https://docs.vmware.com/en/VMware-Horizon-7/7.13/virtual-desktops/GUID-E177899E-023D-4E61-B058-AFE3822158AA.html  Da mesma forma para o AWS, você pode usar os Scripts de inicialização da mesma maneira: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html.

Configuração do VMware Horizon

1. A VM Golden Image é preparada e todos os aplicativos necessários para a implantação inicial do pool são instalados na VM.
2. Um endpoint seguro é instalado com essa sintaxe de linha de comando para incluir a flag goldenimage. Por exemplo, <ampinstaller.exe> /R /S /goldenimage 1. Observe que o Sinalizador de Imagem Dourada garante que o serviço de Ponto de Extremidade Seguro não seja executado até uma reinicialização, o que é essencial para que esse processo funcione corretamente. Consulte https://www.cisco.com/c/en/us/support/docs/security/sourcefire-fireamp-endpoints/118587-technote-fireamp-00.html
3. Após a instalação do Secure Endpoint, execute o script VMWareHorizonAMPSetup.bat na máquina virtual Golden Image primeiro. Essencialmente, esse script altera o Secure Endpoint Service para Manual Start e cria uma Variável de ambiente que armazena o nome de host Golden Image para uso posterior.
4. Você precisa copiar o VMWareHorizonAMPStartup.bat para um caminho universal na máquina virtual Golden Image como "C:\ProgramData" pois isso seria usado nas etapas posteriores.
5. A Golden Image VM agora pode ser desativada e o processo de composição pode ser iniciado no VMware Horizon.
6. Estas são as informações passo a passo sobre sua aparência do ponto de vista do VMware Horizon:

Selecionando "Pool de desktops automatizado"

Consulte: https://docs.vmware.com/en/VMware-Horizon/2106/virtual-desktops/GUID-6C3AB7F3-0BCF-4423-8418-30CA19CFC8FC.html

Seleção de "clones instantâneos"

Consulte: https://docs.vmware.com/en/VMware-Horizon-7/7.13/virtual-desktops/GUID-D7C0150E-18CE-4012-944D-4E9AF5B28347.html

Seleção do tipo "Flutuante"

Consulte: https://docs.vmware.com/en/VMware-Horizon-Cloud-Service-on-IBM-Cloud/21.1/horizoncloudhosted.deploy/GUID-34C260C7-A63E-452E-88E9-6AB63DEBB416.html

Nomes de Pool de Área de Trabalho

Padrão de nomenclatura do VMware Horizon: https://docs.vmware.com/en/VMware-Horizon/2103/virtual-desktops/GUID-26AD6C7D-553A-46CB-B8B3-DA3F6958CD9C.html

Imagem dourada: essa é a VM real da imagem dourada.

Instantâneo: esta é a imagem que você deseja usar para implantar a VM filha. Este é o valor que é atualizado quando você atualiza a Imagem Dourada com qualquer alteração. Rest são algumas das configurações específicas do VMware Environment.

7. Como mencionado anteriormente, a Etapa 10. do assistente é onde você define o caminho do script.

8. Depois que o VMware Horizon for concluído e enviado, sua composição será iniciada e as VMs filhas serão criadas.

Observação: consulte o guia da VMware para obter informações sobre essas etapas, mas elas são autoexplicativas.

Removendo Entradas Duplicadas

Há algumas maneiras disponíveis pelas quais podemos remover as entradas duplicadas do conector:

1. Utilize o Recurso de Remoção Automatizada no Secure Endpoint Portal para remover Entradas Duplicadas (Inativas):

Você poderá encontrar essa configuração em Admin > Configurações da organização

O Limite de computadores inativos permite especificar por quantos dias um conector pode ficar sem fazer check-in na nuvem da Cisco antes de ser removido da lista da página Gerenciamento do computador. A configuração padrão é 90 dias. Os computadores inativos só serão removidos da lista e todos os eventos gerados por eles permanecerão na sua organização de endpoint seguro. O computador reaparecerá na lista se o conector fizer check-in novamente.

2. Utilize os fluxos de trabalho de orquestração disponíveis: https://ciscosecurity.github.io/sxo-05-security-workflows/workflows/secure-endpoint/0056-remove-inactive-endpoints

3. Use o script disponível externamente para remover os UUIDs antigos/obsoletos: https://github.com/CiscoSecurity/amp-04-delete-stale-guids