Ter um acesso aprovado não significa, necessariamente, ter um acesso seguro.

Em ambientes SAP que evoluem durante anos, usuários mudam de área, assumem novas responsabilidades, recebem perfis adicionais e acumulam permissões. Cada concessão pode fazer sentido isoladamente. O risco aparece quando permissões legítimas, combinadas, permitem que uma mesma pessoa execute etapas incompatíveis de um processo.

É aí que entra a Segregação de Funções, conhecida pela sigla SoD (Segregation of Duties). A SAP define o princípio como uma forma de reduzir riscos de erro e fraude por meio da distribuição adequada de direitos de acesso e responsabilidades entre diferentes usuários.

Para a empresa, porém, o desafio não termina em encontrar um conflito. É preciso entender se o acesso é realmente necessário, qual é o impacto do risco, se ele pode ser eliminado, se exige controle compensatório e como a situação será acompanhada depois.

O que é Segregação de Funções no SAP?

Segregação de Funções no SAP é a aplicação do princípio de separação de responsabilidades ao modelo de autorizações do ambiente. Na prática, a análise cruza atividades de negócio, transações, objetos de autorização, funções, perfis e usuários para identificar combinações que representem risco.

A análise não deve se limitar a perguntar se um usuário “pode acessar” determinada transação. A pergunta relevante é se o conjunto de acessos concedidos permite que ele concentre etapas que deveriam possuir revisão, aprovação ou execução independente.

Uma avaliação consistente conecta pelo menos:

·        processo de negócio;

·        atividade ou função de negócio;

·        transações e permissões relacionadas;

·        funções e perfis SAP;

·        usuários impactados;

·        regra de conflito;

·        nível de risco ou criticidade;

·        tratamento recomendado;

·        controle compensatório, quando a segregação não puder ser feita.

O que é um conflito SoD?

Um conflito SoD ocorre quando um usuário, função ou combinação de funções reúne permissões que, juntas, podem permitir uma operação incompatível com o modelo de controle da organização.

O conflito é contextual. Duas permissões podem ser aceitáveis em determinadas estruturas organizacionais e inadequadas em outras. Por isso, uma matriz SoD eficaz precisa refletir processos, responsabilidades e regras reais da empresa — não apenas uma lista genérica de transações.

No SAP Access Control, a própria análise de risco diferencia violações de Segregação de Funções de outros riscos de acesso e permite avaliar autorizações em funções e combinações entre funções.

Exemplos de conflitos que merecem análise

Os exemplos abaixo são ilustrativos. A regra final deve ser validada com as áreas de negócio, auditoria e responsáveis pelo processo, porque a criticidade depende do desenho real de cada organização.

Matriz SoD SAP: o que ela precisa responder

A matriz de Segregação de Funções é a estrutura que transforma o princípio de controle em regras analisáveis e auditáveis. Ela não deve ser apenas uma planilha de pares de transações. Precisa explicar o risco em linguagem de negócio e mostrar como tratá-lo.

Uma matriz madura tende a responder:

·        qual processo está envolvido;

·        qual risco existe;

·        quais atividades ou funções entram em conflito;

·        quais transações, objetos ou permissões materializam esse conflito;

·        qual é a severidade;

·        quais usuários ou funções estão expostos;

·        qual é a justificativa para manter uma exceção;

·        qual controle compensatório reduz o risco;

·        quem é o responsável pelo controle;

·        com qual periodicidade a situação deve ser revista.

A documentação do SAP Access Control trata riscos de acesso com atributos como tipo, nível de risco, processo de negócio e funções associadas. Também prevê priorização das violações, investigação da causa, remoção de acessos quando possível e uso de controles mitigadores quando o risco não pode ser eliminado.

Por que uma matriz SoD fica desatualizada

Mesmo empresas que já possuem uma matriz podem perder aderência ao longo do tempo. O ambiente muda mais rápido do que a governança quando novos projetos, funções, transações próprias e exceções são incorporados sem revisão estruturada.

·        novos perfis são criados sem atualizar as regras de risco;

·        funções compostas acumulam permissões de origens diferentes;

·        transações próprias e desenvolvimentos Z não entram na avaliação;

·        usuários mudam de cargo e mantêm acessos anteriores;

·        exceções permanecem ativas sem revisão periódica;

·        criticidades e descrições de risco deixam de refletir a operação atual;

·        controles compensatórios existem no papel, mas não têm responsável ou evidência de execução.

Essa necessidade de atualização aparece também em práticas de mercado: projetos de revisão de matriz normalmente tratam nomenclatura, criticidade, riscos e alinhamento entre negócio, TI e auditoria, não apenas a existência de uma lista de conflitos.

Menor privilégio: reduzir acesso excessivo antes de mitigar risco

O princípio do menor privilégio busca conceder somente as autorizações necessárias para que cada pessoa cumpra suas responsabilidades. No desenho de SoD, isso significa investigar a causa do conflito e, sempre que possível, eliminar o acesso desnecessário na origem.

A SAP orienta que, depois de identificar e priorizar violações, a organização avalie a causa específica das autorizações e determine se o acesso é realmente necessário. Quando o risco puder ser eliminado, a recomendação é corrigir a causa no nível mais baixo possível.

Quando usar controles compensatórios

Nem todo conflito pode ser removido imediatamente. Estruturas enxutas, particularidades operacionais ou atividades muito especializadas podem exigir que determinado acesso permaneça.

Nesses casos, a decisão não deveria ser simplesmente “aceitar o risco”. É necessário definir um controle compensatório capaz de reduzir a exposição e produzir evidência verificável.

Um controle compensatório precisa deixar claro:

·        qual risco está sendo mitigado;

·        qual atividade de controle será executada;

·        quem é o responsável;

·        qual é a frequência;

·        qual evidência precisa ser gerada;

·        o que deve acontecer se o controle detectar uma violação.

A SAP cita mecanismos como trilhas de auditoria, relatórios, logs e revisões por supervisão como formas de mitigação quando a separação completa das funções não é possível.

Fonte SAP: Segregação de funções — SAP Help Portal

Falso positivo em SoD: por que contexto organizacional importa

Uma análise pode apontar um conflito tecnicamente possível que, na prática, esteja separado por estruturas organizacionais — por exemplo, empresa, centro ou organização de compras. Esse é um dos motivos pelos quais SoD não pode ser tratado como uma simples comparação mecânica de transações.

No SAP Access Control, regras organizacionais podem ser usadas como filtro para reduzir falsos positivos. A própria SAP recomenda cautela: uma regra mal configurada pode ocultar riscos reais, e a orientação é evitar filtros excessivos.

Como executar um projeto de Segregação de Funções SAP

A abordagem abaixo reflete o escopo efetivamente estruturado pela QAMetrik para um projeto de SoD em ambiente SAP ECC. Ela é apresentada aqui como referência metodológica; volumes, módulos e profundidade precisam ser dimensionados para cada cliente.

1. Mobilização e planejamento

Confirmar escopo, acessos de trabalho, documentos existentes, pontos focais, agenda de workshops, governança do projeto e critérios de priorização.

2. Diagnóstico do ambiente atual

Levantar funções simples e compostas, perfis, objetos relevantes, transações críticas, conflitos existentes, redundâncias, excesso de autorização e inconsistências estruturais.

3. Mapeamento de processos e caminhos críticos

Relacionar acessos às atividades reais de negócio. No escopo de referência da QAMetrik, entram processos de módulos como MM, WM, FI, SD, ST e CO, com expansão conforme validação do cliente.

4. Desenho do modelo-alvo

Racionalizar funções, separar papéis e responsabilidades, aplicar o princípio do menor privilégio e estruturar as regras de conflito e a matriz de risco.

5. Validação com negócio e auditoria

Revisar conflitos, exceções, severidade e controles compensatórios com donos de processo, áreas funcionais e auditoria.

6. Consolidação e plano de remediação

Entregar a matriz versionada, o diagnóstico, o redesenho de perfis, as evidências de validação e um backlog priorizado para execução posterior.

7. Monitoramento periódico

Reexecutar análises em ciclos definidos, acompanhar riscos mitigados, revisar exceções e verificar se novas alterações de acesso recriaram conflitos.

Quais entregáveis um projeto SoD deve produzir?

No modelo estruturado pela QAMetrik, os principais entregáveis são:

·        relatório de diagnóstico do ambiente atual de acessos;

·        inventário consolidado de funções simples e compostas, classificado por criticidade;

·        mapa de transações críticas e processos sensíveis;

·        matriz de Segregação de Funções revisada, validada e versionada;

·        matriz de risco com descrição, impacto, transações correlatas, regras de conflito e controles compensatórios sugeridos;

·        proposta de redesenho do modelo de perfis e responsabilidades;

·        evidências dos workshops de validação;

·        plano de remediação priorizado;

·        handover e transferência de conhecimento.

Por que o monitoramento precisa continuar depois do projeto

A matriz SoD não é um documento de encerramento. Novos usuários, mudanças organizacionais, ajustes de função, projetos e acessos emergenciais podem recriar conflitos depois da remediação.

A documentação do SAP Access Control prevê execução periódica de controles mitigadores e análise de histórico de violações, riscos não mitigados e revisões SoD. Isso reforça uma ideia importante: governança de acessos é um processo contínuo, não uma fotografia tirada antes da auditoria.

Sinais de que sua empresa precisa revisar a Segregação de Funções

·        a matriz SoD existe, mas não é revisada há muito tempo;

·        auditoria encontrou conflitos recorrentes ou dificuldade para obter evidências;

·        há muitas funções compostas, perfis redundantes ou acessos acumulados;

·        usuários mudam de cargo sem revisão estruturada das permissões anteriores;

·        a empresa depende de planilhas para controlar exceções e conflitos;

·        não existe clareza sobre quais transações são críticas por processo;

·        controles compensatórios não possuem dono, periodicidade ou evidência consistente;

·        novos projetos, customizações ou reorganizações alteraram o modelo de acesso;

·        a equipe consegue dizer quem tem um perfil, mas não consegue explicar o risco de negócio associado à combinação de acessos.

Auditoria de acessos SAP: as perguntas que a empresa precisa conseguir responder

Uma governança auditável precisa permitir respostas objetivas a perguntas como:

·        quais riscos SoD estão ativos no ambiente;

·        quais usuários e funções estão associados a cada risco;

·        qual é a criticidade de cada conflito;

·        quem aprovou a exceção;

·        por que o acesso ainda é necessário;

·        qual controle compensatório está em vigor;

·        quem executa esse controle;

·        quando ele foi executado pela última vez;

·        qual evidência comprova a execução;

·        qual é o plano para eliminar ou reduzir o risco na origem.

Segregação de Funções é a mesma coisa que SAP GRC?

Não. Segregação de Funções é um princípio de controle e uma prática de governança de acessos. SAP Access Control é uma solução da SAP que pode automatizar partes da análise e da gestão desses riscos.

É possível executar um projeto de diagnóstico, revisão de matriz, redesenho e governança SoD sem que a implantação de SAP GRC Access Control faça parte do escopo. Essa distinção é especialmente importante na oferta da QAMetrik: o serviço atual está centrado em consultoria especializada, matriz de risco, revisão de perfis, validação e monitoramento, e não na implantação de uma ferramenta dedicada.

Onde a QAMetrik atua

A QAMetrik atua na camada de diagnóstico, desenho e governança dos riscos de acesso em ambientes SAP. O trabalho conecta SAP Security, processos de negócio e auditoria para transformar conflitos técnicos em uma matriz de riscos entendida, validada e tratável.

A atuação pode contemplar:

·        análise de funções e perfis existentes;

·        mapeamento de transações e processos críticos;

·        identificação de combinações incompatíveis;

·        revisão e atualização da matriz SoD;

·        desenho da matriz de risco de acesso;

·        redesenho de funções pelo princípio do menor privilégio;

·        classificação de exceções e controles compensatórios;

·        workshops com negócio e auditoria;

·        plano de remediação priorizado;

·        monitoramento periódico da matriz consolidada.

Próximo passo

Se a sua empresa possui uma matriz SoD que não acompanha mais o ambiente, recebeu apontamentos de auditoria ou simplesmente não consegue demonstrar com clareza quais combinações de acesso representam risco, o primeiro passo é criar uma linha de base confiável.

A QAMetrik pode avaliar o cenário atual, revisar as regras de conflito e transformar o resultado em uma matriz de risco auditável, com prioridades claras para remediação e monitoramento.

Se o objetivo for ampliar a leitura do ambiente antes da remediação, conheça o QAAssessment. Quando a correção dos riscos exigir ajustes técnicos ou desenvolvimento, veja a Engenharia de Software SAP. Para governança e rastreabilidade das mudanças que seguem até produção, conheça o QADevOps.

Falar com um especialista em SAP Security

Perguntas frequentes

O que é Segregação de Funções SAP?

É a aplicação do princípio de separação de responsabilidades ao modelo de acessos do SAP. O objetivo é evitar combinações de permissões que permitam a uma mesma pessoa executar atividades incompatíveis dentro de um processo.

O que significa SoD no SAP?

SoD significa Segregation of Duties, ou Segregação de Funções. No contexto SAP, o termo é usado para analisar conflitos entre acessos, funções, perfis e atividades críticas de negócio.

O que é uma matriz SoD SAP?

É a estrutura que relaciona processos, atividades incompatíveis, regras de conflito, riscos, criticidade e formas de tratamento. Uma matriz bem mantida também registra exceções e controles compensatórios.

Como identificar um conflito SoD?

É necessário comparar as permissões efetivas de usuários e funções com regras de conflito definidas a partir dos processos de negócio. A análise deve considerar transações, objetos de autorização, papéis e contexto organizacional.

Qual a diferença entre conflito SoD e acesso crítico?

Conflito SoD normalmente envolve a combinação de duas ou mais capacidades incompatíveis. Acesso crítico pode existir mesmo de forma isolada, quando uma única permissão possui elevado potencial de impacto.

O que é controle compensatório em SoD?

É um controle usado para reduzir um risco que não pode ser removido imediatamente. Deve ter responsável, procedimento, frequência, evidência e ação definida para o caso de violação.

SoD é a mesma coisa que SAP GRC Access Control?

Não. SoD é um princípio e um processo de governança de acessos. SAP Access Control é uma solução que pode automatizar análises e fluxos relacionados a riscos de acesso.

Uma matriz SoD precisa ser revisada?

Sim. Mudanças de função, novos perfis, transações próprias, reorganizações, projetos e exceções podem alterar a exposição ao risco. A matriz deve acompanhar a evolução do ambiente.

É possível fazer um projeto SoD sem reconstruir todos os perfis do SAP?

Sim. Um projeto pode priorizar diagnóstico, matriz de riscos, racionalização, desenho-alvo e backlog de remediação. A reconstrução massiva de perfis pode ser tratada como uma etapa posterior.

A QAMetrik implanta SAP GRC Access Control neste serviço?

Não no escopo-base atual. O serviço está estruturado para diagnóstico, revisão e desenho SoD, matriz de riscos, validação com negócio e auditoria, documentação, plano de remediação e monitoramento periódico.