oHub Base TI Cibersegurança e Proteção de Dados Gestão de Acessos e Identidade

Segregação de funções (SoD): princípios e aplicação

Princípios de segregação de funções e aplicação em acessos a sistemas corporativos.
Atualizado em: 24 de abril de 2026
Neste artigo: Como este tema funciona na sua empresa Os quatro olhos do controle interno Conflitos críticos em sistemas ERP Mapeamento de SoD por sistema Detecção de violações Remediação e exceções documentadas Comunicação de achados para liderança Sinais de que SoD não está funcionando Próximos passos por porte de empresa Perguntas frequentes Referências
Compartilhar:
Este conteúdo foi gerado por IA e pode conter erros. ⚠️ Reportar | 💡 Sugerir artigo

Como este tema funciona na sua empresa

Pequena empresaSoD conceitual. Poucos sistemas, overlap aceitável. Compliance manual.
Média empresaImplementação em ERP. Regras SoD definidas. Violações documentadas como exceções.
Grande empresaSoD é mandato. Matriz robusta. Ferramentas de análise contínua. Exceções formalizadas.

Segregação de funções (SoD) — Separation of Duties é um princípio de controle interno que impede que uma única pessoa requisite, aprove, execute e audite uma transação. Previne fraude interna ao distribuir responsabilidades críticas entre múltiplos atores. Para gestores de TI e compliance, SoD é tanto mandato regulatório (SOX, LGPD) quanto barreira técnica contra fraude.

Os quatro olhos do controle interno

O princípio de SoD repousa em quatro funções distintas que não devem convergir em uma só pessoa: requisitar (quem pede), aprovar (quem autoriza), executar (quem realiza) e auditar (quem verifica). Em um cenário de compra, exemplo clássico em ERP: o analista não pode requisitar e aprovar a mesma PO; quem aprova não pode receber a mercadoria; quem recebe não pode pagar. Cada etapa tem custódia diferente.

Requisita: Gera ordem de compra
Aprova: Autoriza gasto (gestor)
Recebe: Verifica entrega
Paga: Executa transferência
Audita: Revisa transação completa

Conflitos críticos em sistemas ERP

Sistemas integrados (SAP, Oracle, Dynamics) amplificam risco porque transações fluem entre módulos. Um conflito SoD em Financeiro impacta Contas a Pagar, Tesouraria e Contabilidade simultaneamente1. Os conflitos mais críticos são:

Compras: Requisita + Aprova mesma PO
Contas a Pagar: Aprova fatura + Paga (sem verificação)
Tesouraria: Executa transferência + Concilia banco
Contabilidade: Lança débito + Crédito na mesma transação
Acesso de Sistema: Administrador cria conta + Aprova acesso crítico

Mapeamento de SoD por sistema

Cada ERP define suas funções de forma diferente. Em SAP MM (Gestão de Materiais), roles críticas são: Criar PO, Aprovar PO, Receber Mercadoria, Faturar. Auditorias de SoD comparam direitos de acesso contemporâneos contra uma matriz de conflitos definida. A matriz varia por contexto: um usuário pode ter ambas funções em sistemas desconectados, mas não em um mesmo fluxo integrado2.

Detecção de violações

Ferramentas de análise (SailPoint, SAP Access Control) scanneiam permissões de cada usuário e comparam contra a matriz SoD. Violações são classificadas por criticidade: Crítica (Requisita + Aprova), Alta (Executa + Audita), Média (funções de suporte conflitantes), Baixa (conflito em área não-crítica). Processos manuais de audit, relatórios HANA e query direto no banco também detectam violações, mas escalam lentamente em ambientes complexos.

Crítica: Risco imediato de fraude
Alta: Risco de erro não-detectado
Média: Supervisão fraca
Baixa: Risco de controle mitigado

Remediação e exceções documentadas

Remediação envolve revogar acesso ou implementar controles compensatórios: se impossível separar funções (p.ex., pequena empresa com um contabilista), monitorar transações dessa pessoa mais rigorosamente, com revisão periódica de auditoria. Exceções formalizadas — com aprovação de compliance e data de sunset — são legítimas; o problema é violação oculta. Documentação de exceção deve incluir: motivo de negócio, controle compensatório, aprovante, validade.

Comunicação de achados para liderança

Relatórios periódicos (semestral ou anual) para compliance/audit devem indicar: total de usuários analisados, total de violações encontradas, distribuição por criticidade, remediação completada, violações em aberto com justificativa. Frequência de análise varia por porte: grande empresa faz trimestral; média, anual; pequena, ad-hoc quando auditada. Tendência regulatória aponta para análise contínua, não apenas snapshots3.

Sinais de que SoD não está funcionando

  • Usuário com acesso a criar, aprovar e pagar transações
  • Exceções de SoD nunca revisadas ou aprovadas
  • Sem matriz de conflitos documentada para seu ERP
  • Auditoria encontra violações que TI não conhecia
  • Fraude interna descoberta sem detecção por SoD

Próximos passos por porte de empresa

Pequena: Documentar matriz SoD (mesmo que manual), revisar exceções anualmente, treinar proprietário de TI.
Grande: Implementar ferramenta de análise, automatizar detecção, integrar com SIEM para auditoria contínua.

Perguntas frequentes

O que é segregação de funções (SoD) e por que importa?
SoD impede que uma pessoa requisite, aprove, execute e audite a mesma transação. Importa porque detecta e previne fraude interna, atendendo mandatos regulatórios como SOX e LGPD.
Quais são os principais conflitos SoD em sistemas ERP?
Requisita + Aprova (compras), Aprova Fatura + Paga (financeiro), Executa Transação + Concilia (tesouraria), Cria Conta + Aprova Acesso (sistema).
Como detectar e remediar violações de SoD?
Use ferramentas de análise (SailPoint, SAP Access Control) para comparar permissões contra matriz de conflitos. Remedie revogando acesso ou implementando controles compensatórios com documentação e aprovação.
SoD é exigência regulatória (SOX, LGPD)?
Sim. SOX Section 404 exige; LGPD Art. 32 exige adequação técnica que inclui SoD; ISO 27001 recomenda.
Como equilibrar SoD com produtividade?
Exceções documentadas são legítimas se acompanhadas de controle compensatório (auditoria, monitoramento). O desafio é documentar, aprovar e revisar periodicamente.
Qual o impacto de SoD em outsourcing e terceirizados?
Terceiros frequentemente acumulam funções; contrato deve especificar requisitos SoD e como terceiro atesta conformidade (certificação, auditoria).

Referências

  • 1 COSO Internal Control — Integrated Framework: https://www.coso.org/guidance-on-ic
  • 2 NIST SP 800-53 — AC-5 (Separation of Duties): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
  • 3 ISO/IEC 27001:2022 — A.6.1 (Access Management): https://www.iso.org/standard/27001