Por que revisões de acesso parecem punição e o que realmente precisa mudar

O Ciclo Samsara: Preso na Roda das Revisões Trimestrais

Samsara é o ciclo interminável de nascimento, morte e renascimento—preso na roda, repetindo os mesmos padrões até alcançar uma mudança fundamental e se libertar. Isso é avaliações de acesso.

Um de nossos clientes recentes em serviços financeiros descreveu seu processo anterior antes de usar a Zluri: “Estávamos passando mais de uma ou duas semanas para consolidar todos esses relatórios e validar tudo. Era mais de uma janela de 30 dias. E que 30 dias era todo trimestre.”

Todo trimestre. Para sempre. Preso na roda.

Semana 1 do ciclo: Você consolida dados de 30 aplicações. Isso é puro trabalho manual — login, exportar, copiar, colar, conciliar. Você não está tomando decisões estratégicas de segurança. Você está fazendo uma entrada de dados que deveria ser automatizada.

Semana 2: Você corre atrás de críticos que não respondem. Você responde perguntas de pessoas que não entendem o que estão analisando. Você está gerenciando um projeto de pessoas por meio de um processo que elas odeiam tanto quanto você.

Semana 3: Você revoga o acesso manualmente um usuário por vez em 30 aplicações. Você está clicando em botões que deveriam ser automatizados. O trabalho de TI de produção — abastecimento de novos funcionários, conserto de sistemas quebrados, suporte ao negócio — espera.

Semana 4: Você compila provas para a auditoria. Você está reconstruindo o que aconteceu a partir de mensagens e tópicos de e-mail do Slack porque nada capturou automaticamente.

Então começa o segundo trimestre. A roda gira novamente. Você renasce no mesmo ciclo.

‍

The cruel part: You’re working incredibly hard. You’re spending entire weeks on this. You’re doing exactly what compliance and security policy requires. And yet:

• Nothing gets easier
• A carga de trabalho cresce (mais apps, mais usuários, mais complexidade)
• Você está sempre atrasado
• Sempre alguém encontra algo que você perdeu
• Você é culpado pelas lacunas

Um de nossos clientes recentes em pesquisa em ciências da vida descreveu seu processo anterior antes de usar o Zluri: “Era manual, lento, propenso a erros.”

Resumindo, você é preparado para falhar, depois é culpado por falhar.

Estão sendo solicitados a fazer algo impossível (e depois culpados quando está incompleto)

Seu CEO faz uma pergunta simples: “Quem na empresa tem acesso administrativo aos nossos sistemas financeiros?”

Não é uma pergunta simples. Para responder, você precisaria:

• Faça login no NetSuite, QuickBooks, Bill.com, Expensify, Stripe, o portal do banco, o sistema de folha de pagamento e pelo menos outros cinco sistemas
• Navegue até o gerenciamento de usuários (caminho diferente em cada aplicação)
• Estado atual da exportação
• Cruze com dados do RH para ver quem essas pessoas realmente são
• Verifique se algum desses contratados é contratado cujos contratos terminaram
• Verifique se alguém recebeu autorização temporária de administrador que nunca foi revogado
• Repita isso para todo “sistema financeiro” (quais sistemas contam como financeiro?)

E mesmo depois de todo esse esforço, você só saberia o estado atual. Não em nenhum estado histórico. Não “que teve acesso há três meses durante o período de auditoria.”

O pedido parece razoável. A execução é impossível.

Um dos nossos clientes recentes na área da saúde descreveu seu desafio anterior antes de usar o Zluri: “Não sabíamos se alguém havia recebido permissões de administrador ou de usuário. Se um usuário tivesse acesso de administrador por um certo período, esqueceríamos de removê-lo depois.”

Isso não é negligência. Isso não é TI sendo preguiçoso ou descuidado. Essa é a consequência natural de pedir aos humanos que acompanhem manualmente milhares de decisões de acesso em centenas de aplicações sem nenhuma visibilidade automatizada.

Claro que você esquece. Claro que você deixa passar coisas. Claro que você não pode responder instantaneamente “quem tem que acesso”. Você não é um banco de dados. Você é um ser humano.

Mas quando o auditor encontra o contratado que ainda tem acesso seis meses após o término do contrato? Quando encontrarem o acesso de administrador esquecido da Sarah do projeto há 18 meses? Quando descobrirem que a segregação de deveres violou ninguém foi pego?

Você é culpado. Não o sistema. Você.

O Problema do Revisor: Você é responsável por decisões que não controla

Você envia ao gerente de Engenharia uma lista: 47 usuários da AWS para revisar. Eles têm três colunas para trabalhar: Nome, E-mail, Vaga.

O gerente olha para funções como “IAM:PassRole” e “EC2:FullAccess” e não faz ideia do que significam. Eles não sabem quais permissões são necessárias para o trabalho. Eles não sabem se o empreiteiro que saiu ainda está na lista. Eles não sabem se Emily ainda deve ter acesso após a transferência.

Então eles fazem uma de três coisas:

1. Aprove tudo (não quero atrapalhar a produção)
2. Revogar tudo que parecer estranho (pode atrapalhar a produção)
3. Ignore o pedido até correr atrás deles

Nenhuma dessas opções traz bons resultados de segurança.

Um de nossos clientes recentes em pesquisas em ciências da vida identificou o problema em seu processo anterior antes de usar o Zluri: “Os revisores não tinham contexto. Eles precisavam de sinais claros como papéis privilegiados, última atividade e custo.”

Mas aqui está a parte dolorosa: Quando a revisão deixa passar algo, quando a aprovação cria uma lacuna de segurança, quando o auditor encontra um problema — você é responsabilizado.

Não o revisor que aprovou sem olhar. Não o sistema que lhes deu informações insuficientes para tomar boas decisões. Você.

Você é responsável pela qualidade das decisões tomadas por pessoas que:

• Não têm as informações que precisam
• Não tenho tempo para investigar a fundo
• Não entendo totalmente o que eles estão aprovando
• Não são responsabilizados quando cometem erros

Você é dono do resultado, mas não controla o processo.

O Pesadelo da Trilha de Auditoria: Prove que Você Fez Algo Que Mal Consegue Lembrar

Seu auditor pergunta: “Mostre-me provas de que você revisou o acesso do John ao Salesforce no segundo trimestre, incluindo quem aprovou, quando e a justificativa do negócio.”

Seu coração afunda. Você sabe que fez isso. Você lembra das discussões. Definitivamente teve um tópico no Slack. Ou foi um e-mail? Ou Jira? Ou aquela planilha que alguém atualizou?

Você procura. Você encontra fragmentos: uma mensagem do Slack que diz “Parece bom ✓” (mas de quem? aprovando o quê exatamente?). Uma conversa de e-mails discutindo algo relacionado (mas será que foi no segundo ou terceiro trimestre?). Um ticket do Jira que pode ser relevante (mas não está claro se essa foi a aprovação final).

Duas horas depois, você já compilou algo. Você espera que seja suficiente.

Um de nossos clientes recentes na área de tecnologia descreveu sua situação anterior antes de usar a Zluri: “Nossas evidências de auditoria estavam espalhadas por Jira, Slack e Okta. Precisávamos de todas as informações históricas para apoiar as decisões de acesso.”

Aqui está o motivo de isso ser tão desanimador: Você fez o trabalho. Você passou semanas rodando a resenha. Você conseguiu aprovação do gerente. Você revogou o acesso. Você fez tudo o que a apólice exige.

Mas porque as evidências nunca foram capturadas sistematicamente, porque estão espalhadas por cinco ferramentas diferentes, porque ninguém projetou o processo para gerar provas — você não pode provar que fez o que fez.

O auditor escreve uma constatação. Não porque você não fez a revisão. Mas porque você não pode provar que fez isso.

Você está sendo cobrado por um padrão de prova de que o sistema não foi projetado para gerar.

A Lacuna na Remediação: O Trabalho Nunca É Concluído

Sua revisão do primeiro trimestre terminou. Os gerentes identificaram 200 usuários que precisam de acesso revogado em 30 aplicações. Você pensa: “Ótimo, encontramos as questões. Agora vamos consertá-los.”

Então a realidade bate.

Você precisa entrar em 30 aplicativos diferentes. Navegue para o gerenciamento de usuários em cada um (caminho diferente a cada vez). Encontre cada usuário (pesquise por e-mail? por nome? por ID?). Clique pelo fluxo de trabalho de desativação (2 cliques aqui, 5 cliques ali). Confirme. Documente. Avance para o próximo.

200 revogações. Um de cada vez. Manualmente.

Um cliente da área da saúde nos disse: “Quando temos auditorias, precisamos remover os usuários do software manualmente. Vamos em cada ferramenta, baixamos o arquivo Excel, verificamos se elas estão presentes, e então temos que removê-las.”

Semana 1: Você remove 50 usuários. Bom progresso.

Semana 2: Você remove mais 30. Estou desacelerando porque surgiram problemas de produção.

Semana 3: Você remove mais 15. Está demorando mais do que esperava.

Semana 4: Você ainda tem 105 usuários para remover.

Semana 5: A revisão do segundo trimestre é lançada.

Você nunca terminou de remediar o primeiro trimestre. Agora o segundo trimestre identificou mais 180. Seu agrafo é de 285 usuários. Você fica mais para trás a cada trimestre.

Um prospect em serviços financeiros descreveu o que está procurando: “Queremos descobrir visibilidade e depois a correção, abordando-a. Também estamos buscando adotar a abordagem automatizada para remediação.”

A ironia é que você encontrou os problemas de segurança. Você identificou exatamente quem precisa de acesso revogado. Você fez o trabalho duro da investigação. E então você fica preso em semanas de clicar manualmente entediante porque a remediação não está ligada à avaliação.

O valor do título estava na descoberta e na decisão. A remediação deve ser automatizada. Em vez disso, você está fazendo manualmente a parte mais tediosa, cheia de erros e que esmaga a alma. E quando não está pronta a tempo? Você é culpado pelo atraso.

O Problema da Cobertura Impossível: Você é julgado por Aplicações às quais não pode acessar

Você implementou uma ferramenta de revisão de acesso. Ele se conecta ao SSO e automatiza revisões para 20 candidaturas. Incrível! Você reduz o tempo de avaliação de 6 semanas para 15 dias nesses apps.

Mas você ainda tem 50 inscrições que não estão atrás do SSO. Sistemas legados. Ferramentas gerenciadas pelo fornecedor. Aplicativos construídos por contratantes. Plataformas específicas do setor.

Um cliente da área da saúde disse: “32 de 60 aplicações não estão atrás de um SSO adequado. Esses 50% são aplicativos críticos que exigem mais atenção, e precisamos de intervenção manual.”

50% das suas inscrições. Os mais críticos. Ainda manual. Ainda são planilhas. Ainda assim, 2 semanas de trabalho a cada trimestre.

Agora você tem dois sistemas paralelos:

• Automatizado (20 apps): Clique no botão, pronto em 15 dias
• Manual (50 apps): Login, exportar, planilha, enviar e-mail, perseguir, revogar — 6 semanas de trabalho

Aqui está a punição: Sua política de conformidade diz “revisões trimestrais de acesso para todas as aplicações.” Não “para aplicações atrás do SSO.” Todas aplicações críticas.

Você está sendo julgado pela cobertura completa. Mas a cobertura total é tecnicamente impossível para 70% do seu conjunto. Esses aplicativos nunca vão se integrar. Os fornecedores oferecem SSO, mas ele exige um plano empresarial que custa 4 vezes o de um plano padrão (também chamado de imposto SSO). Os sistemas legados não podem ser modificados. O negócio não vai acabar com eles.

Você está sendo cobrado por um padrão tecnicamente impossível de alcançar. E quando a cobertura está incompleta? Quando o auditor escolhe um dos 50 aplicativos que você não pode automatizar e pede provas? Você é culpado.

A Falha de Reserva: Você É Responsável pela Disponibilidade dos Outros

Você lançou a revisão de acesso do primeiro trimestre. Você designou o VP de Vendas como revisor principal do Salesforce. O prazo é sexta-feira. É quarta-feira. Sem resposta.

Você verifica o Slack. Eles estão de férias. Por duas semanas.

Você designou um revisor de recurso. Mas o plano B nunca foi notificado. Eles não sabem que são o backup. Eles não sabem que há uma revisão pendente. Eles não têm contexto.

Você manda mensagem freneticamente: “Você pode avaliar 73 usuários do Salesforce até sexta-feira?”

Resposta: “O quê? Eu não sabia que tinha sido designado para isso. Não tenho acesso. O que estou revisando?”

É quarta-feira. O prazo é sexta-feira. Você está recomeçando.

Um de nossos clientes no setor bancário descreveu exatamente esse cenário em seu sistema anterior: “Precisamos entrar em contato manualmente com o revisor de reserva e dizer: ‘Você é um revisor de backup, por favor, tome uma atitude.’ O proprietário da certificação precisa informar o revisor de backup.”

A falha do sistema: O revisor principal é responsável por concluir a avaliação. Mas o sistema não notificou o revisor de reserva. Não dei contexto para eles. Não escalou automaticamente quando o médico principal não respondeu. Não deu tempo para eles estarem mentalmente preparados.

E claro, o revisor de replio estava apenas esperando por essa tarefa urgente. Eles não tinham outros projetos, nenhum prazo, nenhuma outra responsabilidade. Eles esperavam ansiosamente que alguém colocasse 73 usuários para avaliarem em seu colo com 48 horas de antecedência.

Obviamente, eles vão largar tudo em que estão trabalhando — o lançamento do produto, o incidente de segurança, a apresentação executiva — para revisar acessos ao Salesforce que nem sabiam que eram responsáveis.

Você precisa monitorar manualmente cada revisor. Acompanhe quem está respondendo. Descubra quem está de férias. Escale manualmente para backups. Forneça contexto. Perseguir pessoas.

Você está fazendo um trabalho de gerenciamento de projetos que deveria ser automatizado. E quando a revisão atrasa porque o plano B não foi notificado? Você é culpado por perder o prazo.

O pesadelo das notificações: você responde as mesmas 50 perguntas a cada trimestre

Você envia um e-mail para 20 gerentes: “Por favor, conclua sua revisão de acesso ao primeiro trimestre até 15 de março.”

Em menos de uma hora, 20 respostas:

• “O que estou revisando?”
• “Onde está o elo?”
• “Estou de férias naquela semana.”
• “Alguém mais pode fazer isso?”
• “O que isso significa?”
• “Quanto tempo isso vai levar?”
• “Por que estou recebendo isso?”
• “Isso é urgente?”

Você passa a semana seguinte respondendo as mesmas perguntas de 20 pessoas diferentes. Perguntas que você respondeu no último trimestre. E o trimestre anterior. E o trimestre anterior a esse.

Um dos nossos clientes do setor bancário nos contou sobre a solução anterior de IGA autônomo: “Era muito genérica — as notificações não informavam aos avaliadores o que deveriam revisar ou o que precisavam fazer. Os avaliadores não tinham contexto, então simplesmente ignoraram os e-mails. Tivemos que fazer um acompanhamento manual com as pessoas no Slack mesmo depois que a plataforma enviou notificações.”

A punição: O sistema envia uma notificação genérica. A notificação carece de contexto. Os revisores não entendem o que deveriam fazer. Eles te perguntam. Você explica. Individualmente. Repetidamente. Todo trimestre.

Você está compensando um design ruim do sistema com comunicação manual. E quando as avaliações são atrasadas porque os revisores não entenderam as instruções? Você é culpado pela má comunicação.

A Pressão de Conformidade: Você está se preparando para um exame que nunca acaba

Sua auditoria ISO 27001 é em duas semanas. O auditor solicitará evidências de revisões trimestrais de acesso.

Você fez isso. Mais ou menos. Você tem: uma planilha do primeiro trimestre (talvez do segundo trimestre?). Algumas mensagens no Slack. Tópicos de e-mail. Tickets do Jira para alguns pedidos. Uma planilha do terceiro trimestre parcialmente concluída. Q4… Você pode ter pulado o quarto trimestre por causa do incidente.

Você passa o fim de semana compilando “provas”. Procurando no Slack. Vasculhando e-mails. Reconstruindo linhas do tempo. Tirando capturas de tela. Construindo uma apresentação.

Você passa. Por pouco. O auditor escreve: “O processo de revisão de acesso precisa de melhorias. A documentação é inconsistente.”

You promise to fix it. You don’t. Because you’re too busy doing the next review.

A prospect we are talking to recently told us: “After the ISO 27001 certification last year—they now need something more reliable and efficient. Auditors may randomly pick one to see what it looks like.”

The pattern repeats: 

3 meses antes da auditoria: Deve começar a planejar 2 meses antes da auditoria: Realmente deve começar 1 mês antes da auditoria: Lançar revisões AGORA 2 semanas antes da auditoria: Pânico, correndo Fim de semana antes da auditoria: Trabalhar até tarde compilando evidências Dia da auditoria: Espero que seja suficiente

Você não está fazendo governança contínua. Você está estudando para uma prova. Todo trimestre. Para sempre.

E quando o auditor encontra lacunas? Quando a documentação está incompleta? Quando você não consegue apresentar provas de algo que definitivamente fez, mas não capturou? Você é culpado pela falha no controle.

Você está preparado para falhar (A Realidade Frustrante)

Vamos deixar claro o que está acontecendo aqui:

Estão sendo solicitados a:

• Descubra manualmente o acesso em 50+ aplicações a cada trimestre
• Tome boas decisões com informações incompletas
• Faça os gestores ocupados revisarem coisas que eles não entendem
• Execute centenas de ações de remediação manualmente
• Prove que você fez tudo isso com evidências espalhadas por cinco ferramentas
• Faça tudo isso enquanto lida com suas responsabilidades reais de TI
• Conclua tudo dentro de prazos rígidos de conformidade
• Alcançar cobertura perfeita mesmo para aplicações que não conseguem integrar

E quando essa tarefa impossível está incompleta, imperfeita ou atrasada, você é culpado.

Não o sistema projetado para exigir esforço sobre-humano. Não é a abordagem que torna a cobertura abrangente tecnicamente impossível. Não o processo que fornece informações insuficientes para boas decisões.

Você.

É por isso que parece um castigo. Porque você está sendo responsabilizado por resultados que não pode controlar, usando ferramentas que não foram feitas para ter sucesso, com expectativas que não são realistas.

O que realmente precisa ser consertado (e não é você)

O problema não é que você precisa se esforçar mais. Você já está trabalhando incrivelmente duro.

O problema não é que você precise de planilhas melhores ou procedimentos mais detalhados. A documentação não corrige falhas sistêmicas de projeto.

O problema não é que os revisores precisam de um treinamento melhor. O treinamento não resolve a falta de informação.

O problema é que toda a abordagem de revisão de acesso é projetada de forma errada.

O que precisa mudar:

Parem de reconstruir o estado de acesso a cada trimestre. Você não deveria gastar 2 semanas consolidando dados. Você deve ter visibilidade contínua sobre quem tem que acesso, automaticamente, o tempo todo. A fase de “consolidação” de 30 dias não deveria existir.

Pare de pedir para os avaliadores adivinharem. Revisores não devem tomar decisões baseadas em nomes e cargos sem contexto. Eles devem ver: data de último login, indicadores de acesso privilegiado, o que mudou desde a última revisão, se essa pessoa mudou de departamento, definições claras de funções. Forneça a eles as informações necessárias para tomar boas decisões.

Pare de tratar revisões e remediação como fases separadas. Quando um gerente clica em “revover”, essa ação deve ser executada automaticamente via API ou criar uma tarefa rastreada com propriedade clara. O intervalo entre “decisão tomada” e “acesso removido” deveria ser de minutos, não de semanas.

Parem de espalhar evidências pelo Slack, e-mail e Jira. Cada revisão, cada decisão, cada ação, cada aprovação deve ser registrada automaticamente em um único sistema, com carimbos de tempo e contexto. Quando o auditor pedir provas, você deve exportar um relatório, não gastar 2 horas reconstruindo o histórico.

Pare de fazer o TI gerenciar manualmente a escalonada. Quando um revisor primário não responde por 3 dias (assumindo que o cronograma da campanha seja de 1 semana), o plano B deve ser notificado automaticamente. Com contexto. Com acesso. Sem que o TI precise monitorar e intervir manualmente.

Pare de enviar notificações genéricas. Os avaliadores devem receber instruções claras e específicas: “Você está avaliando 23 usuários no Salesforce. Aqui está o motivo pelo qual você foi designado. Aqui está o que procurar. Aqui está o prazo. Clique aqui para começar.” Não “Por favor, complete sua revisão de acesso.”

Pare de manter dois sistemas paralelos. Um fluxo de trabalho deve lidar tanto com aplicativos integrados com SSO (automatizados) quanto com aplicativos não SSO (tarefas manuais com rastreamento). Mesmo processo, mesma trilha de auditoria, caminhos de execução diferentes.

Pare de estudar para auditorias. A conformidade deve ser um estado sempre pronto. O relatório de auditoria deve ser um clique de botão, não um projeto de fim de semana.

Veja o que isso significa na prática:

Se você tiver visibilidade de acesso contínua, a fase de consolidação de 2 semanas desaparece. Se os revisores tiverem informações prontas para a decisão, a aprovação diminui e a qualidade das avaliações melhora. Se a remediação estiver vinculada a revisões, a fase manual de limpeza que dura semanas desaparece. Se as evidências forem capturadas automaticamente, a correria do fim de semana anterior à auditoria desaparece.

O ciclo trimestral de 30 dias passa a ser de 3 a 5 dias. Não porque você está trabalhando mais rápido. Porque você não está fazendo um trabalho que não deveria existir.

Como Explicar Isso para a Liderança

Seu CEO acha que as revisões de acesso são simples: “Basta pedir para os gerentes revisarem quem tem acesso trimestralmente. Quão difícil é isso?”

Seu CFO acha que é um problema de eficiência: “Você não pode automatizar isso com uma ferramenta melhor?”

Seu CISO acha que é um problema de rigor: “Precisamos ser mais minuciosos.”

Todos estão errados. E eles estão errados porque não entendem os problemas sistêmicos de design que tornam isso impossível.

Veja como explicar:

Ao seu CEO: “Estamos dedicando 120 dias por ano — 6 meses de tempo de TI — em revisões de acesso. Não porque sejamos lentos, mas porque a abordagem exige reconstruir manualmente nosso estado de acesso do zero a cada trimestre, e depois executar manualmente centenas de revogações uma a uma. É como pedir para alguém contar manualmente todos os itens do estoque todo mês, em vez de usar um sistema de inventário. A abordagem está errada.”

Para o seu CFO: “Ferramentas que automatizam 30% do trabalho ainda deixam 70% manual. Temos 50 aplicações que nunca vão se integrar — sistemas legados, ferramentas gerenciadas pelo fornecedor, aplicativos não federados. Precisamos de uma abordagem que lide com aplicativos automatizados e manuais em um único fluxo de trabalho unificado. Caso contrário, pagamos pela automação, mas ainda fazemos 2 semanas de trabalho manual a cada trimestre.”

Ao seu CISO: “As avaliações estão incompletas não porque não sejamos minuciosas, mas porque os revisores não têm as informações necessárias para tomar boas decisões. Eles estão tentando chutar com base em nomes e títulos de funções. Quando fornecemos dados de atividade, indicadores de risco e mudamos o contexto, a qualidade das avaliações melhora drasticamente. O problema é informação, não esforço.”

Ao seu Conselho: “Nosso processo de revisão de acesso tem três falhas fundamentais de projeto: primeiro, ele exige coleta manual de dados que deve ser contínua e automatizada. Segundo, desconecta decisões de revisão das ações de remediação, criando semanas de limpeza manual. Terceiro, não gera evidências sistematicamente, tornando as auditorias dolorosas. Não estamos falhando em executar o processo. O processo foi projetado para falhar.”

O Trabalho que Você Não Está Fazendo

Você está gastando 120 dias por ano em revisões de acesso. Esse é metade de um produto que você poderia construir. Uma arquitetura de segurança que você poderia redesenhar. Um sistema que você poderia transformar.

Para uma empresa com 500 funcionários e 50 aplicativos, isso equivale a 120 dias × custo de TI totalmente carregado por hora = $144.000 por ano gasto em revisões de acesso.

O que você conseguiria construir com $144.000?

Em vez disso, você clica manualmente em “revoke” 200 vezes em 30 aplicações. Compilando evidências de mensagens do Slack. Explicando a mesma coisa para 20 gerentes que não entendem o que estão revisando. Vendo a roda girar de novo.

A punição não é o trabalho. É o que você não está construindo enquanto está preso no samsara.

Na próxima segunda-feira, seu lembrete no calendário vai aparecer: “Revisão de Acesso do 2º trimestre – Começar hoje.”

Seu estômago vai despencar.

A menos que você pare de girar o volante.