Segregação de funções (SoD): como criar e aplicar a matriz

Muita empresa regulada tem uma matriz de segregação de funções: uma planilha produzida para uma auditoria e consultada uma vez por ano. Enquanto isso, o sistema concede qualquer combinação de acessos a quem pedir e tiver um gestor para aprovar.

Uma matriz que ninguém consulta na hora de conceder o acesso não reduz risco: documenta o risco. A segregação de funções (SoD, de Segregation of Duties) só sai do papel quando a matriz vira regra aplicada no momento da concessão e revisada depois dela.

A SoD é um dos pontos em que mais se vê diferença entre o que a política diz e o que o sistema permite.

O que é conflito de funções

Segregação de funções é o princípio de que nenhuma pessoa deve conseguir, sozinha, executar e esconder um ato que cause dano. O conflito de funções (ou conflito de acessos) aparece quando uma mesma pessoa reúne dois poderes que, juntos, permitem fraude ou erro sem que ninguém perceba.

Os exemplos mais claros estão fora da TI:

• Quem cadastra um fornecedor não deve aprovar o pagamento a ele.

• Quem solicita uma compra não deve ser quem a aprova nem quem recebe a mercadoria.

• Quem administra os acessos não deve ser quem audita os registros desses acessos.

O NIST SP 800-53 Rev. 5 trata o tema no controle AC-5 (Separation of Duties). Ele pede que a organização identifique e documente as funções que precisam ser separadas e defina as autorizações de acesso do sistema de modo a sustentar essa separação. O texto de apoio observa que violações de separação podem atravessar sistemas e domínios de aplicação, e por isso a política deve considerar o conjunto deles, e não cada aplicação isolada.

Da matriz de risco à regra técnica

Uma matriz útil não nasce de uma lista de papéis. Nasce de uma lista de riscos. O caminho tem quatro passos:

1. Mapear os processos críticos. Pagamentos, folha, cadastro de fornecedores, alteração de limites, liberação de código, administração de identidades.

2. Descrever, para cada processo, os pares de atividades incompatíveis. Exemplo: "cadastrar beneficiário" e "aprovar pagamento".

3. Traduzir cada atividade em permissões reais de cada sistema: papéis, grupos, perfis, transações.

4. Escrever a regra em forma executável: a combinação X + Y, em qualquer sistema do escopo, é proibida ou exige exceção aprovada.

   
   

O terceiro passo é o mais trabalhoso. "Aprovar pagamento" pode existir em um ERP, num banco digital e numa plataforma de tesouraria, com nomes diferentes. A matriz precisa dizer que as três permissões são a mesma atividade.

Imagine uma empresa hipotética de distribuição, com cerca de 3 mil pessoas. A auditoria interna lista, entre outros, o par "cadastrar fornecedor" e "liberar pagamento". Na planilha, o par está proibido.

No ERP, porém, os dois papéis são concedidos por fluxos diferentes, aprovados por gestores diferentes, e nenhum fluxo conhece o outro. Seis meses depois, uma analista que mudou de área acumula os dois acessos. Ninguém errou individualmente: cada aprovador viu apenas metade do quadro.

A correção não foi uma nova planilha, e sim levar a regra para o fluxo de solicitação. Agora, quando chega o pedido de um dos papéis, o sistema consulta o que a pessoa já possui, identifica o conflito e bloqueia a concessão ou a desvia para uma exceção formal.

Elemento	Na planilha	Como regra aplicada
Par de atividades incompatíveis	Linha da matriz	Regra consultada em cada pedido de acesso
Quem detecta o conflito	O auditor, no fim do ano	O fluxo de concessão, no momento do pedido
O que acontece	Achado e plano de ação	Bloqueio ou exceção com aprovação e prazo
Evidência	Tabela de ano passado	Registro de cada decisão, com data e aprovador

Quem é o dono da matriz: Riscos ou IAM

A discussão é antiga e a resposta curta é: a matriz tem dois donos com funções diferentes.

• Riscos e controles internos definem o quê. Eles decidem quais combinações são inaceitáveis, com base no apetite de risco e nas exigências regulatórias. Sem essa autoridade, a regra vira opinião do time de TI.

• IAM define o como. Traduz a decisão em permissões, mantém a regra no motor de concessão, mede os conflitos existentes e opera as exceções.

• O dono do processo de negócio valida. Só ele sabe se dois papéis são realmente incompatíveis na rotina da área.

Só com Riscos, a matriz fica elegante e inaplicável. Só com o IAM, fica aplicável, mas sem legitimidade para recusar o pedido de um diretor. Registre os três papéis, quem revisa a matriz, com que frequência e quem aprova mudanças.

Controle preventivo e controle detectivo

A SoD se aplica em dois momentos, e os dois são necessários.

Preventivo. O conflito é checado antes da concessão. É o controle mais forte, porque o risco não chega a existir. Exige que a regra esteja no fluxo de pedido e que o sistema enxergue os acessos atuais da pessoa em todas as aplicações do escopo.

Detectivo. Varre os acessos já concedidos em busca de combinações proibidas e produz um relatório de conflitos existentes.

É indispensável por três motivos: o legado nasceu antes da regra, os sistemas podem conceder acessos por fora do fluxo, e a própria matriz muda.

O preventivo sozinho deixa passar o que já estava lá. O detectivo sozinho vira uma sequência de relatórios que ninguém corrige. Juntos, um impede a entrada e o outro limpa o estoque.

Role mining e engenharia de papéis para reduzir exceções

Uma matriz aplicada com rigor sobre acessos concedidos de forma solta gera uma enxurrada de bloqueios. A saída é reduzir a necessidade de combinar permissões avulsas, não afrouxar a regra.

O modelo RBAC (Role-Based Access Control), formalizado pelo NIST e adotado como padrão INCITS 359, organiza o acesso em papéis: cada pessoa recebe papéis e cada papel reúne permissões. A proposta de padrão do NIST inclui relações de separação de funções. Na forma estática, as relações restringem a atribuição de usuários a papéis: pertencer a um papel pode impedir o pertencimento a outros. Na forma dinâmica, restringem os papéis que podem ser ativados na sessão do usuário. Para a matriz, a leitura é direta: um par de atividades incompatíveis vira um par de papéis que ninguém deve acumular.

Na prática, isso se constrói com duas atividades:

• Role mining. Analisa os acessos existentes para descobrir agrupamentos reais: que permissões as pessoas de uma mesma função costumam ter em comum. É uma abordagem de baixo para cima, que mostra o que a empresa faz hoje.

• Engenharia de papéis. Parte da estrutura de negócio e define, de cima para baixo, o que cada função deveria ter. Corrige o que o role mining só reflete.

  
  

Usadas juntas, produzem papéis que já nascem compatíveis com a matriz. Se o papel "Analista de contas a pagar" é desenhado sem a permissão de cadastrar fornecedores, o conflito deixa de ser exceção e vira impossibilidade de projeto. Isso também apoia o menor privilégio, tema do controle AC-6 do NIST SP 800-53, que pede apenas os acessos autorizados e necessários às tarefas atribuídas. O reforço AC-6(7) prevê revisar periodicamente os privilégios e remover os desnecessários. Sobre RBAC, ABAC, MAC e DAC, veja: https://www.identityacademy.com.br/post/quais-as-diferenças-entre-modelos-de-controle-de-acesso

Acúmulo de privilégios em movimentações internas

O maior gerador de conflitos não é o ingresso, é a mudança de área. A pessoa chega com o acesso do cargo novo, e o do cargo antigo permanece, porque ninguém solicitou a remoção. Com o tempo, ela vira a combinação perfeita de poderes que a matriz proíbe.

A medida central é simples:

• Tratar a movimentação como evento de IAM: ao mudar de cargo ou área, os acessos do cargo anterior são revisados e retirados, e a checagem de SoD considera o conjunto final, não só o pedido novo. Explicamos esse ciclo (entrada, movimentação e saída) em: https://www.identityacademy.com.br/post/processos-essenciais-no-ciclo-de-vida-da-identidade-jml-a-reconciliação-e-atestação

Exceções e controles compensatórios

Haverá casos em que a separação é impraticável. Uma equipe pequena, uma função rara, uma emergência. A exceção é aceitável quando é formal; é perigosa quando é um e-mail.

Uma exceção bem tratada tem:

• justificativa de negócio e aprovação do dono do risco, não apenas do gestor direto;

• prazo de validade imposto pelo sistema, com revisão obrigatória na renovação (a lógica é a dos acessos efêmeros: https://www.identityacademy.com.br/post/acessos-efêmeros-o-que-são-e-como-reforçam-a-segurança-na-gestão-de-acessos);

• um controle compensatório descrito e verificável, como aprovação de uma segunda pessoa para cada operação sensível, revisão mensal das transações realizadas por quem acumula as funções, ou alertas sobre valores acima de um limite;

  
  

O controle compensatório não anula o conflito: reduz a chance de ele passar despercebido. Conte as exceções como indicador do programa: se aumentam, a matriz ou os papéis estão mal desenhados.

Erros comuns

• Olhar um sistema de cada vez. O conflito entre o cadastro no ERP e o pagamento no banco não aparece em nenhum dos dois isoladamente.

• Exceção sem prazo. O acesso "temporário" que dura anos.

Quando a SoD não resolve

A segregação de funções reduz o risco de fraude e erro por uma só pessoa, mas não cobre tudo:

• Não impede complô entre duas pessoas que, somadas, reúnem os poderes. Esse risco pede monitoramento, rodízio e revisão de operações.

• Não funciona sem inventário confiável. Se o sistema não sabe quais acessos a pessoa tem, a regra nunca dispara.

Checklist rápido para o seu próximo projeto

1. Liste os cinco processos de maior risco financeiro ou operacional e os pares de atividades incompatíveis de cada um.

2. Traduza cada atividade em permissões reais de cada sistema do escopo.

3. Defina quem decide (Riscos), quem aplica (IAM) e quem valida (dono do processo), e registre.

4. Leve as regras para o fluxo de pedido de acesso, com bloqueio ou exceção formal.

5. Rode uma varredura detectiva dos conflitos existentes e classifique por gravidade.

6. Use role mining e engenharia de papéis para desenhar papéis que não carreguem conflitos.

7. Trate a movimentação interna como evento: revise e retire acessos do cargo anterior.

8. Exija, em toda exceção, aprovador, prazo e controle compensatório verificável.

Conclusão

Uma matriz de SoD vale pelo que o sistema faz com ela. Com regra na concessão, varredura dos acessos existentes e papéis bem desenhados, a segregação de funções deixa de ser documento de auditoria e vira controle. Quem para na planilha descobre o conflito depois do dano.

Para continuar acompanhando a série, assine a newsletter da Identity Academy e consulte o Glossário IAM, onde estão os termos usados neste texto.

No próximo texto, falamos de prova de identidade (identity proofing) e dos níveis IAL e FAL do NIST.

Referências

• NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (controles AC-5, Separation of Duties, e AC-6, Least Privilege): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

• NIST, Role Based Access Control (projeto arquivado; INCITS 359): https://csrc.nist.gov/projects/role-based-access-control

• NIST, Role Based Access Control, perguntas frequentes: https://csrc.nist.gov/projects/role-based-access-control/faqs

• Ferraiolo, Sandhu, Gavrila, Kuhn e Chandramouli, A Proposed Standard for Role-Based Access Control (NIST): https://csrc.nist.gov/csrc/media/projects/role-based-access-control/documents/rbac-std-draft.pdf