A plataforma de IGA de um fornecedor de serviços de tecnologia estava configurada para propagar os eventos do ciclo de vida das identidades (provisionamento, mudanças de função e desprovisionamento) a todas as aplicações conectadas por meio de conectores SCIM e de sincronização de diretório. A lista de aplicações conectadas do IGA incluía dezessete sistemas. Durante uma auditoria de integração para o projeto de um novo cliente, a equipe de segurança do fornecedor constatou que um engenheiro recentemente desligado ainda tinha acesso ativo ao espaço de trabalho compartilhado do projeto do cliente no Confluence. A investigação concluiu que o cliente havia implantado uma nova instância auto-hospedada do Confluence seis semanas antes do desligamento do engenheiro para apoiar um projeto específico. A nova instância havia sido adicionada ao ambiente pela equipe do projeto sem notificar os administradores do IGA e sem ser incluída na lista de conectores do IGA. Quando o engenheiro foi desprovisionado, o IGA desprovisionou corretamente todos os dezessete sistemas conectados. O décimo oitavo sistema, a nova instância do Confluence, não foi afetado porque o IGA não sabia que ele existia. O acesso do engenheiro ao Confluence persistiu não porque o processo de desprovisionamento tenha falhado, mas porque o sistema estava fora do escopo do processo.
Qual é, de fato, o risco de propagação de identidades entre sistemas?
A propagação de identidades entre sistemas é o processo pelo qual os eventos do ciclo de vida das identidades (criação de usuários, mudanças de função e desprovisionamento) são comunicados de uma fonte central de identidade (normalmente um IdP ou uma plataforma de IGA) a todos os sistemas conectados, garantindo que o estado das identidades seja consistente em todo o conjunto de aplicações. Quando um funcionário entra, o provisionamento cria contas em todos os sistemas relevantes. Quando uma função muda, as alterações de acesso são aplicadas de forma consistente. Quando um funcionário sai, o desprovisionamento remove o acesso de todos os sistemas simultaneamente. As falhas de propagação ocorrem quando alguns sistemas não recebem esses eventos de ciclo de vida, seja porque o caminho de propagação está incompleto, seja porque sistemas foram adicionados ao ambiente sem serem registrados para receber eventos de ciclo de vida.
A lacuna no inventário de conectores é o principal modo de falha da propagação. As plataformas de IGA propagam eventos para os sistemas que conhecem, ou seja, sistemas que foram integrados como conectores e configurados para receber eventos de ciclo de vida. Os sistemas adicionados ao ambiente sem integração ao IGA são invisíveis para o processo de propagação. Em ambientes corporativos dinâmicos, nos quais as equipes implantam regularmente novas aplicações, serviços em nuvem e ferramentas de desenvolvimento, a lacuna entre a lista de conectores do IGA e o inventário real de aplicações cresce continuamente, a menos que exista um processo ativo que vincule a implantação de novos sistemas à integração ao IGA.
O problema dos sistemas paralelos amplia a lacuna de conectores. Aplicações implantadas por equipes individuais para fins específicos de projetos (uma nova ferramenta de colaboração para o projeto de um cliente, um ambiente de desenvolvimento para uma sprint, um painel de monitoramento para a implantação de um sistema) frequentemente contornam por completo o processo de provisionamento da área de TI. A equipe implanta a aplicação, cria contas e a utiliza sem notificar a área de TI nem a equipe de IGA. Quando membros da equipe saem, o desprovisionamento do IGA não chega à aplicação, porque ela nunca foi registrada. As contas persistem indefinidamente e, às vezes, são descobertas meses depois, durante uma auditoria não relacionada.
- Novos sistemas não registrados na lista de conectores do IGA: aplicações implantadas sem notificar os administradores do IGA
- Aplicações paralelas implantadas pelas equipes: sistemas criados fora do processo de provisionamento da área de TI, sem integração com eventos de ciclo de vida
- Lista de conectores não mantida em linha com o inventário atual de aplicações: o escopo do IGA fica defasado em relação ao escopo real do ambiente
- Nenhum processo de descoberta de novas aplicações: nenhum mecanismo para identificar sistemas fora da lista de conectores do IGA
- Completude da propagação não verificada: suposição de que o desprovisionamento do IGA cobre todos os sistemas
Por que isso importa
A propagação de identidades entre sistemas é relevante para TPRM porque os fornecedores que acessam ambientes de clientes por meio de vários sistemas (espaços de trabalho de projetos, ferramentas de colaboração com clientes, ambientes de desenvolvimento compartilhados) podem ter lacunas de desprovisionamento no IGA para os sistemas adjacentes ao ambiente do cliente que foram implantados especificamente para o projeto. São justamente esses os sistemas com maior probabilidade de estar fora da lista padrão de conectores do IGA: implantados rapidamente para uma finalidade específica, gerenciados por uma equipe de projeto e não pela área de TI, e não registrados no IGA antes do término do projeto.
A janela de acesso após o desligamento é a dimensão de consequências mais imediatas. Quando um funcionário do fornecedor que gerenciava um projeto para um cliente se desliga, o desprovisionamento do IGA remove seu acesso corporativo. Mas a ferramenta de colaboração implantada para o projeto, o ambiente de desenvolvimento compartilhado e o espaço de trabalho do projeto específico do cliente podem estar todos fora da lista de conectores do IGA, e o acesso a todos eles persiste até que alguém o identifique e o remova especificamente.
Onde a maioria das equipes erra
A falha mais recorrente é tratar a automação de IGA como um desprovisionamento abrangente sem verificar se a lista de conectores do IGA corresponde ao inventário atual de aplicações. O IGA é abrangente para os sistemas da sua lista de conectores. Verificar a completude exige comparar a lista de conectores com o inventário real de aplicações, uma conciliação que a maioria das organizações realiza com pouca frequência ou não realiza.
- Tratar a automação de IGA como abrangente sem verificar a lista de conectores
- Nenhuma conciliação do inventário de aplicações com a lista de conectores do IGA
- Implantação de novas aplicações sem acionar o registro no IGA
- Descoberta de aplicações paralelas não realizada
- Verificação de acessos após o desligamento que não abrange sistemas fora do IGA
Como é uma boa prática
Programas maduros de propagação de identidades mantêm uma lista atualizada de conectores do IGA que corresponde ao inventário real de aplicações, por meio de processos que vinculam a implantação de novas aplicações ao registro no IGA, da conciliação periódica da lista de conectores com o conjunto de aplicações e de varreduras de descoberta de sistemas fora do escopo do IGA.
- A implantação de novas aplicações aciona o registro no IGA: processo que exige a integração ao IGA antes da conclusão da implantação da aplicação
- Conciliação periódica da lista de conectores: comparação do escopo do IGA com o inventário atual de aplicações
- Descoberta de aplicações paralelas: varredura de aplicações fora da lista de conectores do IGA
- Verificação de acessos após o desligamento: confirmação de que o desprovisionamento cobriu todos os sistemas, incluindo aplicações fora do IGA
- Inventário de aplicações como artefato de governança: lista atualizada de todas as aplicações com o status de conexão ao IGA
Ferramentas
Descoberta de SaaS: Grip Security, Nudge Security, BetterCloud
As plataformas de descoberta de SaaS identificam as aplicações em uso em toda a organização, incluindo aplicações paralelas implantadas por equipes sem registro na área de TI. Essas plataformas detectam o acesso a aplicações por meio de telemetria de extensões de navegador, análise de tráfego de rede ou análise de logs do provedor de identidade. Para profissionais de TPRM, perguntar se o fornecedor usa descoberta de SaaS para identificar aplicações fora do escopo do seu IGA constitui uma pergunta específica sobre detecção de aplicações paralelas.
IGA com descoberta de aplicações: SailPoint, Saviynt
As plataformas modernas de IGA oferecem recursos de descoberta de aplicações, identificando aplicações em que os usuários têm contas não gerenciadas pelo IGA. Para profissionais de TPRM, perguntar se o IGA do fornecedor inclui descoberta de aplicações que identifique sistemas não registrados com contas de usuários constitui uma pergunta específica sobre detecção de lacunas de propagação.
Desafios de governança
O desafio de governança da completude da propagação de identidades é o problema da mudança contínua do ambiente. Os inventários de aplicações mudam constantemente: novas ferramentas são implantadas, as antigas são desativadas e o escopo das implantações existentes muda. A lista de conectores do IGA que estava correta na última conciliação torna-se progressivamente menos precisa à medida que o ambiente evolui. Manter a completude exige uma descoberta automatizada que identifique continuamente novos sistemas ou um processo que vincule cada nova implantação de aplicação ao registro no IGA antes que a aplicação entre em uso.
- Exigir o registro no IGA antes da implantação de novas aplicações: um ponto de controle de governança no processo de implantação
- Implementar descoberta de SaaS para detectar aplicações paralelas
- Conciliação periódica da lista de conectores com o inventário atual de aplicações
- Verificação de acessos após o desligamento incluindo sistemas fora do IGA
- Incluir a completude da propagação na avaliação da governança de acessos
Se você faz parte de uma equipe pequena
Após o próximo desligamento de um funcionário do fornecedor, faça uma verificação que a maioria das organizações nunca faz: peça ao fornecedor que confirme que o desprovisionamento cobriu todos os sistemas aos quais o funcionário desligado tinha acesso, não apenas os sistemas gerenciados pelo IGA, mas também quaisquer ferramentas específicas de projetos, plataformas de colaboração com clientes e aplicações implantadas pelas equipes. A resposta revelará tanto os sistemas fora do escopo do IGA quanto se o fornecedor tem um processo para identificá-los.
- Pedir aos fornecedores que confirmem, a cada desligamento, que o desprovisionamento cobriu todos os sistemas, incluindo aplicações fora do IGA
- Perguntar se o fornecedor tem um processo para identificar aplicações fora do escopo do seu IGA
- Perguntar com que frequência a lista de conectores do IGA é conciliada com o inventário real de aplicações
- Perguntar se a implantação de novas aplicações aciona o registro no IGA
O que exigir
Pergunte diretamente:
“Quando vocês desprovisionam um funcionário que tinha acesso ao nosso ambiente, esse desprovisionamento cobre todos os sistemas aos quais ele tinha acesso, incluindo ferramentas específicas de projetos, plataformas de colaboração com clientes e aplicações implantadas pelas equipes que não são gerenciadas pelo seu IGA central?”
“Com que frequência a sua lista de conectores do IGA é conciliada com o seu inventário real de aplicações para identificar sistemas em que os usuários têm contas não gerenciadas pelo processo de ciclo de vida do IGA?”
O que esperar como evidência
- Lista de conectores do IGA com a data da última conciliação
- Capacidade ou processo de descoberta de aplicações paralelas
- Processo de verificação de acessos após o desligamento que abranja sistemas fora do IGA
- Processo de registro no IGA na implantação de novas aplicações
Um fornecedor que confirma ter desprovisionamento automatizado no IGA deve ser questionado especificamente se essa automação cobre aplicações implantadas para fins específicos de projetos que podem não estar na lista de conectores do IGA. A automação cobre o que o IGA conhece. A questão é o que o IGA não conhece.
Como comprovar
- Registros de conciliação da lista de conectores do IGA
- Registros de descoberta de aplicações paralelas
- Verificação de acessos após o desligamento incluindo sistemas fora do IGA
- Processo de registro no IGA na implantação de novas aplicações
Principal conclusão
O IGA desprovisionou o usuário de dezessete sistemas. O décimo oitavo sistema, a instância do Confluence implantada seis semanas antes pela equipe do projeto, nunca esteve na lista de conectores. A automação funcionou. O escopo estava incompleto. A completude da propagação de identidades exige que o IGA conheça todos os sistemas em que os usuários têm contas, não apenas os sistemas registrados quando o IGA foi implantado, mas todos os sistemas adicionados ao ambiente desde então. A lista de conectores é o escopo de governança. O inventário de aplicações é o escopo real. A lacuna entre os dois é onde usuários desligados mantêm acesso. Concilie as listas. Registre as novas implantações. Verifique a completude após cada desligamento. A automação só é tão completa quanto aquilo que ela conhece.