O que é gestão de acesso e identidade (IAM) na prática
Gestão de acesso e identidade (IAM, do inglês Identity and Access Management) é o conjunto de práticas e controles para garantir que cada pessoa (ou serviço) tenha uma identidade única, que essa identidade seja verificada de forma adequada e que os acessos concedidos sejam exatamente os necessários para executar uma atividade autorizada. Na prática, IAM responde a quatro perguntas operacionais: quem é você (identidade), como você prova isso (autenticação), o que você pode fazer (autorização) e como eu demonstro que isso foi feito corretamente (evidências).
Quando o capítulo fala em “trilhas de aprovação e evidências”, o foco não é só controlar acesso, mas conseguir provar, com rastreabilidade, que: (1) o acesso foi solicitado por alguém legítimo, (2) foi aprovado por quem tem autoridade, (3) foi implementado conforme o padrão, (4) foi revisado quando necessário e (5) foi removido no momento certo. Essa rastreabilidade reduz risco de fraude, vazamento e erros operacionais, e também simplifica auditorias internas/externas porque a evidência já nasce junto com o processo.
Identidade, conta e credencial: termos que precisam estar claros
Para evitar confusão no dia a dia, vale separar três conceitos:
Identidade: a representação de uma pessoa, fornecedor, cliente, robô ou serviço. Exemplo: “Maria Silva, analista financeiro”, “Serviço de integração ERP->CRM”.
Conta: o objeto técnico em um sistema que materializa a identidade (login no AD, usuário no ERP, conta no banco de dados). Uma identidade pode ter várias contas (por sistema), mas deve existir um vínculo claro entre elas.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Credencial: o meio de autenticação (senha, token, certificado, chave SSH, biometria). Credencial não é identidade e não é conta; é o “segredo” ou fator que prova a identidade.
Por que trilhas de aprovação importam
Sem trilha de aprovação, o acesso vira um acordo informal: “me dá acesso aí”. Isso cria três problemas recorrentes: acessos excessivos (privilégios além do necessário), acessos órfãos (ninguém sabe por que existem) e acessos que não são removidos (ex-funcionários, mudanças de função, projetos encerrados). A trilha de aprovação cria um caminho verificável: solicitação → validação → aprovação → execução → evidência → revisão → revogação.
Princípios operacionais para IAM com evidências
1) Menor privilégio com linguagem de negócio
“Menor privilégio” funciona quando é traduzido em perfis e papéis compreensíveis. Em vez de conceder permissões avulsas, defina papéis como “Contas a pagar – operador”, “Contas a pagar – aprovador”, “Compras – consulta”. Isso reduz exceções e facilita revisão periódica.
2) Segregação de funções (SoD) aplicada a fluxos críticos
Segregação de funções significa evitar que uma mesma pessoa consiga executar sozinha um fluxo completo que permita fraude ou erro material sem detecção. Exemplo clássico: no financeiro, quem cadastra fornecedor não deve ser a mesma pessoa que aprova pagamento. Em IAM, isso vira regra de concessão: papéis conflitantes não podem coexistir na mesma identidade, ou exigem aprovação adicional e compensações.
3) JML: Joiner, Mover, Leaver
O ciclo de vida de acesso deve ser desenhado em três eventos:
Joiner (entrada): criação de identidade e concessão inicial baseada em função.
Mover (mudança): ajuste de acessos quando muda área, cargo, projeto ou localidade.
Leaver (saída): revogação rápida e completa, com tratamento de contas privilegiadas e acessos remotos.
Trilhas de aprovação e evidências devem existir nos três eventos, com ênfase especial em “Mover” (onde muitos acessos se acumulam) e “Leaver” (onde o risco é imediato).
4) Evidência “nativa” do processo
Evidência não deve ser um print improvisado. O ideal é que o próprio fluxo gere registros: ticket, formulário, logs de aprovação, logs de provisionamento, e relatórios de revisão. Quando prints forem inevitáveis (sistemas legados), padronize o que capturar, onde armazenar e como vincular ao pedido.
Desenhando o fluxo de acesso com trilha de aprovação
Componentes mínimos do fluxo
Um fluxo prático e auditável costuma ter os seguintes componentes:
Canal único de solicitação: portal de chamados, formulário corporativo ou sistema de IAM. Evite solicitações por e-mail ou chat sem registro.
Catálogo de acessos: lista de papéis/perfis disponíveis por sistema, com descrição, pré-requisitos e aprovadores.
Regras de aprovação: quem aprova o quê (gestor, dono do sistema, dono do dado, segurança, compliance). Para reduzir burocracia, use regras simples e automáticas para casos padrão.
Execução padronizada: provisionamento automático quando possível; quando manual, com checklist e registro do executor.
Registro e retenção de evidências: onde ficam os logs, tickets e relatórios, por quanto tempo, e como recuperar.
Revisões periódicas: recertificação de acessos por sistema, área ou papel, com trilha de aprovação.
Quem aprova: regra prática para não travar a operação
Uma regra que funciona bem é separar “aprovação por necessidade” e “aprovação por risco”:
Necessidade: o gestor direto confirma que a pessoa precisa do acesso para trabalhar.
Risco: o dono do sistema (ou dono do processo/dado) confirma que o acesso é apropriado e não viola segregação de funções.
Para acessos comuns e de baixo risco, a aprovação do gestor pode ser suficiente se o papel já estiver previamente aprovado e publicado no catálogo. Para acessos privilegiados (admin, alteração de parâmetros, extração massiva), exija aprovação adicional do dono do sistema e, quando aplicável, uma validação de segurança.
Passo a passo prático: implementando um processo de acesso com evidências
Passo 1: monte um catálogo de papéis por sistema
Comece pelos sistemas mais críticos ou mais usados. Para cada sistema, crie uma tabela simples de papéis:
Nome do papel (padrão de nomenclatura)
Descrição em linguagem de negócio
Permissões incluídas (resumo)
Quem pode solicitar (áreas elegíveis)
Aprovadores (gestor, dono do sistema, outros)
Prazo padrão (se temporário)
Conflitos SoD (papéis incompatíveis)
Exemplo: no ERP, “Financeiro – Pagamentos (Operador)” não pode coexistir com “Financeiro – Cadastro de Fornecedor (Administrador)”. Se coexistir por exceção, o fluxo deve exigir justificativa e aprovação reforçada.
Passo 2: defina o formulário de solicitação com campos que viram evidência
O formulário precisa coletar o mínimo necessário para decisão e auditoria. Campos recomendados:
Identidade do solicitante (quem está pedindo) e identidade do beneficiário (para quem é o acesso)
Sistema e papel/perfil solicitado (seleção do catálogo)
Justificativa objetiva (atividade, processo, demanda)
Tipo: novo, alteração, remoção
Prazo: permanente ou temporário com data de expiração
Local/escopo: filial, ambiente (produção/homologação), módulo
Confirmação de ciência (quando aplicável): termo de responsabilidade para acessos privilegiados
Esses campos evitam pedidos vagos e reduzem retrabalho. Além disso, viram evidência direta: a justificativa e o prazo explicam “por que existe” e “até quando”.
Passo 3: implemente regras de aprovação automáticas
Para reduzir burocracia, transforme regras em lógica:
Se papel é “padrão” e não conflita com SoD, aprova apenas gestor.
Se papel é “sensível” (ex.: exportação de dados, alteração de cadastro mestre), aprova gestor + dono do sistema.
Se papel é “privilegiado” (admin), aprova gestor + dono do sistema + segurança, e exige prazo temporário por padrão.
Mesmo sem ferramenta sofisticada, dá para aplicar isso com roteamento no sistema de chamados e listas de aprovadores por categoria.
Passo 4: padronize a execução (provisionamento) e registre quem fez
Quando o provisionamento for manual, crie um checklist por sistema. Exemplo de checklist para um sistema corporativo:
Validar se o ticket tem aprovações completas
Criar/ativar conta vinculada ao identificador corporativo
Atribuir papel conforme catálogo (sem permissões extras)
Configurar expiração (se temporário)
Registrar no ticket: data/hora, executor, o que foi aplicado
Solicitar validação do usuário (teste de acesso) quando necessário
Se houver automação (IAM/IGA), a evidência pode ser o log do job de provisionamento e o status do workflow. Em ambos os casos, o ponto é: a execução precisa ser rastreável e reproduzível.
Passo 5: defina o que é evidência aceitável e como armazenar
Crie um padrão simples de evidências por tipo de evento:
Concessão: ticket com solicitação + aprovações + registro de execução (ou log do IAM) + data de início.
Alteração: ticket com motivo da mudança + aprovações + registro do que foi removido e do que foi adicionado.
Revogação: ticket de desligamento/mudança + evidência de desativação (log, relatório, print padronizado) + data/hora.
Revisão periódica: lista de acessos revisados + decisão do aprovador (manter/remover) + data + exceções justificadas.
Armazenamento: idealmente, o próprio sistema de chamados/IAM é o repositório. Se for necessário exportar, use um repositório controlado (com permissão restrita e trilha de auditoria). Defina retenção alinhada a exigências internas e regulatórias, mas, operacionalmente, garanta que evidências de acessos críticos sejam recuperáveis por um período suficiente para auditorias e investigações.
Trilhas de aprovação: exemplos práticos por cenário
Acesso padrão a sistemas corporativos
Cenário: novo analista de vendas precisa acessar CRM com perfil “Vendas – Operador”.
Solicitação: gestor ou RH abre pedido selecionando papel do catálogo.
Aprovação: gestor direto (se o papel for padrão e pré-aprovado).
Execução: TI/IAM provisiona automaticamente ou manualmente.
Evidência: ticket com aprovação + log de provisionamento + data de ativação.
Boa prática: o papel padrão já deve conter apenas o necessário, evitando “ajustes finos” que viram exceções difíceis de revisar.
Acesso temporário para projeto
Cenário: analista de dados precisa acessar uma base por 30 dias para um estudo.
Solicitação: inclui justificativa do projeto e data de expiração.
Aprovação: gestor + dono do dado/sistema.
Execução: concessão com expiração automática.
Evidência: ticket + aprovações + configuração de expiração + confirmação de remoção ao final (automática ou verificada).
Boa prática: acessos temporários devem expirar por padrão; prorrogação exige novo pedido ou reaprovação.
Acesso privilegiado (admin) com controle reforçado
Cenário: administrador precisa de acesso elevado para manutenção em produção.
Solicitação: deve indicar janela de mudança, escopo e motivo.
Aprovação: gestor + dono do sistema + segurança (ou equivalente).
Execução: acesso privilegiado preferencialmente via conta nominativa com elevação temporária, ou conta administrativa separada, com MFA.
Evidência: workflow de aprovação + log de elevação/uso + registro da revogação ao fim da janela.
Boa prática: diferenciar conta de uso diário e conta administrativa; registrar uso privilegiado (logs) é parte essencial da evidência, não um “extra”.
Recertificação de acessos: evidência contínua, não evento raro
O que é recertificação e por que ela fecha o ciclo
Recertificação (ou revisão periódica de acessos) é o processo em que gestores e donos de sistemas confirmam, em intervalos definidos, que os acessos existentes ainda são necessários e apropriados. Ela resolve o problema do “acúmulo” ao longo do tempo: pessoas mudam de função, projetos acabam, permissões extras ficam esquecidas.
Como definir periodicidade sem exagero
Uma abordagem prática é variar a periodicidade por criticidade:
Sistemas críticos e acessos privilegiados: revisão mais frequente.
Sistemas de apoio e acessos padrão: revisão menos frequente.
O importante é que a periodicidade seja executável e que gere evidência consistente. Uma revisão perfeita que nunca acontece vale menos do que uma revisão simples que acontece sempre.
Passo a passo prático: rodando uma recertificação
1) Extração: gere a lista de usuários x papéis por sistema (idealmente com data de concessão e aprovador original).
2) Quebra por responsável: separe por gestor (para validar necessidade) e/ou por dono do sistema (para validar adequação).
3) Decisão: para cada acesso, o responsável marca “manter” ou “remover” e registra exceções com justificativa.
4) Execução: TI/IAM remove acessos marcados para remoção e registra a conclusão.
5) Evidência: mantenha o relatório assinado/aprovado (workflow) e o log/tickets de remoção vinculados.
Para evitar que a recertificação vire um “clique em massa”, inclua indicadores úteis na lista: último login, último uso de função crítica, data de concessão, e se é temporário. Isso melhora a qualidade da decisão.
Tratamento de exceções com rastreabilidade
Quando exceções são aceitáveis
Exceções acontecem: urgências, limitações de sistema, equipes pequenas. O problema não é a exceção em si, mas a exceção sem controle. Uma exceção aceitável precisa ter: justificativa, aprovação reforçada, prazo e compensações.
Modelo prático de exceção
Justificativa: por que o papel padrão não atende.
Aprovação: gestor + dono do sistema + (quando envolver SoD/privilegiado) aprovação adicional.
Prazo: data de expiração obrigatória.
Compensação: monitoramento extra, revisão mais frequente, dupla checagem no processo.
Exemplo: em uma filial pequena, a mesma pessoa pode precisar cadastrar fornecedor e lançar pagamento. Compensação possível: relatórios semanais revisados por um gestor regional, com evidência dessa revisão.
Evidências técnicas: o que coletar além do ticket
Logs de autenticação e autorização
Para acessos sensíveis, evidência não é só “quem aprovou”, mas também “quem usou”. Registros úteis:
Logs de login (sucesso/falha), com origem (IP, dispositivo quando disponível)
Eventos de elevação de privilégio
Alterações de grupos/papéis
Criação/desativação de contas
Esses logs ajudam em investigações e também demonstram controle operacional. O ponto-chave é garantir integridade e acesso restrito aos logs (para que não sejam alterados por quem administra o sistema).
Vínculo entre evidência de negócio e evidência técnica
Uma prática simples é sempre referenciar o identificador do ticket/chamado no registro de execução (comentário do admin, campo de auditoria do sistema, ou anotação no log quando possível). Assim, ao auditar, você consegue navegar do “por que foi concedido” (ticket) para o “como foi implementado” (registro técnico).
Indicadores operacionais para acompanhar IAM com trilhas de aprovação
Para manter o processo vivo e melhorar continuamente, acompanhe métricas que conectam operação e controle:
Tempo de atendimento por tipo de acesso (padrão, sensível, privilegiado)
% de acessos fora do catálogo (quanto maior, mais exceções e mais risco)
% de acessos temporários com expiração configurada
Tempo de revogação em desligamentos
Taxa de remoções na recertificação (sinal de acúmulo ou de revisão efetiva)
Incidentes relacionados a acesso: compartilhamento de conta, privilégios excessivos, acessos órfãos
Esses indicadores também ajudam a justificar automação: se o tempo de atendimento é alto e o volume de pedidos padrão é grande, o ganho de automatizar provisionamento e aprovações tende a ser imediato.
Modelos prontos (copiáveis) para padronizar pedidos e evidências
Modelo de registro mínimo no ticket (execução)
Execução de acesso - Registro do executor
- Sistema: [nome]
- Beneficiário: [nome / ID]
- Papel concedido/removido: [papel do catálogo]
- Tipo: [concessão | alteração | revogação]
- Data/hora: [timestamp]
- Executor: [nome / equipe]
- Evidência técnica: [log/evento/print padronizado]
- Observações: [expiração configurada? SoD verificado?]Modelo de justificativa objetiva (para reduzir idas e vindas)
Justificativa (padrão)
- Processo/atividade: [ex.: conciliação bancária]
- Motivo do acesso: [ex.: substituição temporária / nova função / projeto]
- Escopo: [módulo/filial/ambiente]
- Prazo: [permanente ou data de expiração]
- Dados envolvidos (se aplicável): [ex.: dados financeiros, dados pessoais]Modelo de recertificação (decisão do aprovador)
Recertificação de acessos - Decisão
- Responsável pela revisão: [nome]
- Sistema: [nome]
- Período de referência: [mês/ano]
- Decisões:
- [Usuário/ID] - [Papel] - [Manter/Remover] - [Justificativa se manter excepcional]
- Data/hora da aprovação: [timestamp]
