Segregação de funções: por que a sua matriz de SoD não impede nada

A segregação de funções existe em quase toda empresa auditada. Está na política, na matriz de controles e na ata do comitê. O problema começa quando alguém pede acesso. O pedido chega por e-mail, o gestor responde "aprovado" e ninguém cruza o acesso novo com o que a pessoa já tinha.

Nesse momento o controle vira texto. Ninguém impede o conflito de acesso. Ele aparece depois, quando a auditoria interna exporta perfis do ERP e descobre que o mesmo usuário cadastra fornecedor e libera pagamento.

Este artigo trata SoD (segregation of duties, a separação de tarefas incompatíveis) como regra executável. Quais pares proibidos importam, como montar a matriz, quando aceitar controle compensatório e por que bloquear na origem vale mais do que detectar no relatório.

O que é segregação de funções e por que ela existe

Segregação de funções é o controle que impede que a mesma pessoa execute e valide etapas incompatíveis de um mesmo processo. Separa quem cria de quem aprova, quem executa de quem confere. O objetivo é reduzir risco de fraude interna e erro não detectado, exigindo duas mãos para completar uma operação sensível.

O princípio vem do controle interno contábil. Mudou o meio: a incompatibilidade hoje está em dois perfis de sistema, não em duas assinaturas de papel.

Os critérios de acesso lógico dos Trust Services Criteria, usados em SOC 2, e os controles de acesso do Anexo A da ISO/IEC 27001 pedem evidência de que o acesso concedido é compatível com a função exercida. O auditor quer ver a decisão registrada.

Segregação de funções em TI

É a camada que mais escapa do radar, porque o time técnico é enxuto e resolve tudo com privilégio amplo. O desenvolvedor com deploy em produção altera regra de negócio sem revisão. O analista que cria a conta também aprova o grupo privilegiado dela. O DBA administra o banco e também o log que registraria a alteração.

Onde o controle quebra: a aprovação sem contexto

A quebra não acontece na política. Acontece na aprovação. Quando o pedido chega por e-mail, chat ou planilha, o gestor decide com informação incompleta.

Ele vê o que a pessoa pediu. Não vê o que ela já tem, nem o perfil equivalente em outro sistema, nem o acesso temporário de dezembro que continua ativo. E não sobra registro para reconstruir a decisão seis meses depois.

O resultado é o padrão descrito nos riscos ocultos da gestão de acessos: privilégio excessivo acumulado, acesso órfão sem dono e trilha de auditoria frágil. Sem uma camada de governança de acessos acima do IAM, a validação de criticidade cruzada não acontece.

Pares conflitantes que aparecem em qualquer empresa

Conflitos recorrentes em ambiente corporativo, com risco associado e tratamento sugerido. Use como ponto de partida: a matriz final depende das transações dos seus sistemas.

Como construir a matriz de segregação de funções passo a passo

A matriz não nasce de workshop de risco. Nasce do inventário de transações reais. O caminho prático tem cinco passos.

1. 1Levante as transações. Extraia de cada sistema crítico as transações, perfis, grupos do Active Directory e permissões efetivas. Trabalhe com o que está concedido, não com o que a documentação diz.
2. 2Agrupe por função de negócio. Traduza transação técnica em linguagem de negócio: aprovar pagamento, cadastrar fornecedor, publicar em produção. Esse agrupamento é a base da modelagem de papéis em RBAC e evita uma matriz ilegível.
3. 3Defina os pares proibidos. Para cada função, liste com quais outras ela não pode coexistir no mesmo usuário. Faça isso com o dono do processo, não só com TI.
4. 4Classifique a criticidade. Separe em crítica, alta e média conforme impacto financeiro, regulatório e de imagem. A criticidade define o tratamento e a alçada de aprovação.
5. 5Defina o tratamento de cada par. Cada linha termina em uma decisão: bloqueio preventivo, alçada superior ou controle compensatório com exceção registrada. Par sem tratamento é par que ninguém aplica.

Depois de pronta, a matriz precisa virar regra de decisão dentro do fluxo de solicitação. Planilha compartilhada envelhece em semanas.

Bloqueio preventivo ou detecção posterior

A diferença é o momento da intervenção. O bloqueio preventivo age antes da concessão, na etapa de decisão. A detecção posterior age no relatório, quando o acesso já foi provisionado e usado. Nesse ponto o dano possível está consumado e a única saída é remediação.

A detecção posterior continua necessária. Ela pega legado, conflito criado fora do fluxo e desvio de configuração. O erro é usar apenas ela.

O conflito por acumulação silenciosa

O conflito mais comum não vem de má intenção. Vem de promoção e transferência.

O analista sai do Financeiro para Compras e recebe os acessos da nova área no primeiro dia. Ninguém revoga os antigos, porque entrada e saída são processos distintos. O usuário passa a concentrar um par proibido inteiro.

Esse é o ponto cego do ciclo joiner mover leaver. O joiner e o leaver recebem atenção, o mover quase nunca. Sem gatilho de revisão na mudança de cargo e sem recertificação de acessos periódica, a acumulação segue invisível até a próxima auditoria.

Duas medidas resolvem a maior parte disso: vigência obrigatória em todo acesso temporário e reavaliação automática do perfil completo quando o cargo muda.

Controle compensatório quando o conflito é inevitável

Em times pequenos alguns conflitos não têm saída estrutural: um único analista fiscal, um único administrador de rede. Contratar gente só para segregar raramente se justifica.

O conflito então é aceito de forma consciente e recebe controle compensatório: um segundo mecanismo que detecta abuso, já que a prevenção por separação não é viável. Opções aplicáveis:

• Revisão independente de todas as transações acima de um valor definido.
• Conferência por amostragem executada por outra área, com evidência arquivada.
• Alerta automático ao gestor a cada uso da transação sensível.
• Log imutável em repositório que o próprio executor não administra.

Como registrar a exceção

Exceção sem documento equivale a controle ausente. Toda exceção de SoD precisa de cinco campos, no mínimo.

1. 1Par conflitante e criticidade, exatamente como estão na matriz.
2. 2Justificativa de negócio, com o motivo pelo qual a separação não é viável hoje.
3. 3Dono da exceção, uma pessoa nomeada, nunca uma área.
4. 4Controle compensatório aplicado, com periodicidade e responsável pela execução.
5. 5Prazo de validade, com data de reavaliação obrigatória.

Sem prazo, a exceção se torna permanente e o auditor a trata como conflito não tratado. Com dono e prazo, ela passa a ser risco aceito e monitorado.

Como o AuditAcesso bloqueia o conflito na etapa de Decisão

O AuditAcesso é uma camada de governança auditável acima do IAM. Não substitui o diretório nem o provisionador. Controla a decisão que vem antes deles, dentro de um ciclo de vida do acesso em cinco etapas: Entrada, Solicitação, Decisão, Execução e Revisão.

O SoD atua na etapa de Decisão. Quando a solicitação entra, o motor de validação de SoD e criticidade compara o escopo pedido com tudo que o usuário já possui nos sistemas integrados. Se a combinação cair em um par proibido da matriz, a aprovação é bloqueada de forma preventiva, antes de qualquer provisionamento. O aprovador vê qual par foi violado e qual acesso preexistente causou o conflito.

Conforme a criticidade, o fluxo escala a decisão para o proprietário da aplicação ou para a alçada superior, em vez de bloquear em definitivo. Quando existe exceção formal, ela fica amarrada ao pedido com dono, prazo e justificativa, e a automação de vigência força a reavaliação no vencimento.

O dashboard de conflitos consolida a visão de gestão: pares em violação, exceções vigentes com prazo de expiração, aprovações pendentes e usuários com acumulação após mudança de área. A auditoria interna prioriza remediação sem extração manual de perfis.

A leitura de permissões vem das integrações nativas homologadas, de Active Directory a Okta, Microsoft 365, ServiceNow e GitHub. Isso importa: o par proibido quase sempre nasce da soma de dois sistemas, não de um perfil isolado.

Checklist prático de SoD

• A matriz cobre transações reais extraídas dos sistemas, não apenas o desenho documentado.
• Cada par proibido tem criticidade classificada e tratamento definido.
• Cada aplicação crítica tem owner nomeado que aprova acesso ao seu escopo.
• A validação de conflito roda antes da concessão, não em relatório trimestral.
• O aprovador enxerga o acesso já existente do solicitante no momento da decisão.
• Mudança de cargo dispara reavaliação do perfil completo.
• Todo acesso temporário tem data de término compulsória.
• Toda exceção tem dono, prazo, justificativa e controle compensatório ativo.
• A trilha reconstrói quem pediu, quem aprovou, por quê e por quanto tempo.

Perguntas frequentes

O que é segregação de funções na prática?

É separar tarefas incompatíveis entre pessoas diferentes para que ninguém execute e valide a mesma operação sensível. Na prática, significa impedir que um usuário acumule permissões como cadastrar fornecedor e aprovar pagamento. O controle reduz risco de fraude interna e aumenta a chance de detectar erro antes do impacto financeiro.

Qual a diferença entre SoD e least privilege?

Least privilege limita a quantidade de acesso: cada usuário recebe o mínimo necessário para a função. SoD trata da combinação, porque acessos individualmente legítimos podem ser proibidos juntos. Um usuário pode estar em least privilege perfeito em dois sistemas e ainda violar a separação de tarefas pela soma dos perfis.

Como montar uma matriz de segregação de funções?

Levante as transações de cada sistema, agrupe em funções de negócio, defina com o dono do processo quais funções não podem coexistir, classifique a criticidade e defina o tratamento: bloqueio, alçada superior ou controle compensatório. Depois implemente a matriz dentro do fluxo de aprovação, não em planilha isolada.

O que fazer quando a equipe é pequena demais para segregar?

Aceite o conflito de forma formal e aplique controle compensatório. Revisão independente das transações críticas, conferência por amostragem de outra área, alerta automático ao gestor e log administrado por terceiro. Registre a exceção com dono nomeado, justificativa de negócio e prazo de reavaliação. Risco aceito e monitorado é defensável em auditoria.

Detectar conflito em relatório trimestral é suficiente?

Não. O relatório mostra um conflito que já esteve ativo por semanas ou meses, com o acesso disponível para uso nesse período. A detecção posterior serve para legado e desvio de configuração. Para o auditor avaliar o controle como operante, a validação precisa acontecer antes da concessão.

Próximo passo

Se a matriz de segregação de funções vive em planilha e a aprovação continua em e-mail, o controle não está operante. A correção começa por mover a decisão para um fluxo que consulte a matriz antes de conceder.

Marque uma reunião técnica para ver o bloqueio preventivo de SoD e o dashboard de conflitos aplicados aos sistemas que a sua empresa já usa.

==============================================================