O que é a segregação de funções (SoD)? Definição e exemplos

Um único colaborador que consiga criar o registo de um fornecedor e depois aprovar a fatura desse fornecedor não precisa da ajuda de mais ninguém para fazer passar um pagamento indevido. Não é necessário conluio nem é preciso falsificar nada: basta, por si só, uma única conta com acessos excessivos. A segregação de funções (SoD) é o controlo que fecha essa lacuna. Divide um processo sensível em etapas que têm de ser concluídas por pessoas diferentes, para que ninguém consiga executar uma transação do início ao fim sem verificação.

O princípio está na base da maioria dos quadros de controlo interno nas áreas financeira, de TI e de operações de segurança. Os auditores perguntam por ele pelo nome. Os reguladores citam-no em cláusulas específicas. E o custo de o ignorar continua a aumentar: o caso mediano de fraude ocupacional custou 104 000 dólares em 2026 e o caso médio prolongou-se durante cerca de 12 meses até ser detetado, segundo o relatório da ACFE Occupational Fraud 2026: A Report to the Nations.

Pontos principais

• A SoD reparte a autorização, a custódia e a manutenção de registos por pessoas diferentes, para que uma única conta não consiga concluir sozinha um processo sensível.
• É distinta do princípio do menor privilégio e do RBAC. O menor privilégio limita a quantidade de acesso que uma pessoa tem, o RBAC é o mecanismo e a SoD é a regra de conceção que decide que combinação de funções uma única conta pode deter.
• O caso mediano de fraude ocupacional custou 104 000 dólares em 2026 e prolongou-se durante cerca de 12 meses até ser detetado (ACFE).
• O NIST AC-5, o anexo A 5.3 da ISO 27001 e o art. 21(2)(i) da NIS2 preveem controlos de SoD documentados, embora o peso legal varie consoante o setor.
• As equipas sem uma plataforma dedicada de governação e administração de identidades (IGA) ou de governação, risco e conformidade (GRC) podem aplicar a SoD através de controlos compensatórios: funções de administração não removíveis, encaminhamento de aprovações, registo de auditoria e revisão periódica.

O que é a segregação de funções (SoD)?

A segregação de funções (SoD) é um controlo interno que divide um processo sensível em etapas, normalmente autorização, custódia ou execução, e registo ou reconciliação, e atribui cada etapa a uma pessoa diferente. Nenhum indivíduo inicia e aprova a mesma transação, nem manuseia um ativo e regista o seu próprio movimento. O objetivo é que a fraude ou o erro passem a exigir conluio, e não apenas uma oportunidade.

A SoD não é o mesmo que um organograma. Uma linha hierárquica mostra quem gere quem, mas não diz nada sobre quem pode criar um fornecedor, aprovar o respetivo pagamento e reconciliar o razão sem que uma segunda pessoa reveja alguma vez a transação. Duas pessoas podem reportar ao mesmo gestor e cumprir a SoD, desde que nenhuma delas consiga concluir sozinha o processo completo. O princípio dos quatro olhos, que exige que pelo menos duas pessoas aprovem uma ação sensível, é a expressão mais simples desta ideia.

Segregação de funções vs. menor privilégio vs. RBAC

A SoD não é o menor privilégio, e o menor privilégio não é o RBAC. O menor privilégio limita a quantidade de acesso que uma pessoa tem. A SoD limita a possibilidade de uma pessoa concluir sozinha um processo sensível completo, mesmo dentro do acesso que lhe é permitido. O RBAC (controlo de acesso baseado em funções) é o mecanismo que normalmente aplica ambos, ao associar permissões a funções em vez de a indivíduos.

As três ideias falham de forma diferente quando aplicadas isoladamente. O menor privilégio sem SoD continua a permitir que uma conta com um âmbito restrito crie e aprove o mesmo tipo de registo, porque restrito não significa isolado. O RBAC sem SoD pode, discretamente, atribuir a uma pessoa duas funções que nunca se deveriam sobrepor, como um técnico de contas a pagar que substitui um aprovador durante uma semana de férias. As definições de funções parecem corretas, mas a combinação anula o controlo.

Nada disto torna o RBAC desnecessário. É a ferramenta que torna a SoD aplicável em grande escala. Consulte como o RBAC atribui acessos por função para conhecer o modelo subjacente: em vez de acompanhar permissões individuais, um administrador define funções e as regras de SoD decidem que funções uma única conta pode deter em simultâneo.

Conflitos comuns de segregação de funções (com exemplos)

Existe um conflito de segregação de funções sempre que uma conta ou uma pessoa detém duas funções que, combinadas, lhe permitem concluir um processo sensível sem a intervenção de uma segunda parte. Os exemplos mais claros encontram-se nas finanças e nas compras, mas o mesmo padrão de falha surge em pipelines de DevOps, sistemas de RH e cofres de credenciais.

Os requisitos formais de SoD remontam aos escândalos contabilísticos da Enron e da WorldCom no início da década de 2000, que levaram diretamente à Lei Sarbanes-Oxley e à sua exigência de controlos internos da secção 404. Essa história continua a moldar a forma como os auditores abordam este controlo: a SoD existe porque a confiança informal deixa de funcionar quando uma empresa ultrapassa uma certa dimensão.

Quando uma pessoa pode criar um fornecedor e aprovar o respetivo pagamento, a fraude não exige qualquer conluio.

Se uma das linhas desta tabela descreve o funcionamento atual do cofre, essa lacuna pode ser corrigida. Experimentar o Passwork gratuitamente para ver como as políticas de cofres a fecham.

Como construir uma matriz de segregação de funções

Uma matriz de segregação de funções cruza as funções com as ações que essas funções podem executar, para que os conflitos fiquem visíveis antes de causarem problemas. A construção de uma matriz envolve cinco passos.

1. Identificar os processos críticos. Comece por tudo o que movimenta dinheiro, altera acessos ou afeta a produção: pagamentos a fornecedores, alterações salariais, implementação de código, administração de credenciais e de cofres.
2. Listar todas as funções envolvidas. Inclua lado a lado as funções correspondentes a cargos (técnico de contas a pagar, engenheiro de DevOps) e as funções de sistema (administrador de cofres, aprovador).
3. Cruzar funções com ações. Construa uma grelha com as funções num eixo e as ações, como criar, aprovar, executar e registar, no outro. Assinale todas as ações que cada função pode executar atualmente.
4. Assinalar as sobreposições. Qualquer função que possa iniciar e aprovar o mesmo processo, ou executá-lo e registá-lo, constitui um conflito.
5. Resolver cada conflito. Reatribua a função, divida o processo por duas funções ou, quando a reatribuição não for viável, documente um controlo compensatório.

Um pequeno exemplo prático, com três funções e três ações num processo de contas a pagar:

Nenhuma linha tem todas as colunas assinaladas. É assim que a matriz deve funcionar.

Controlos de SoD preventivos vs. de deteção (e controlos compensatórios para equipas reduzidas)

Os controlos de SoD preventivos impedem uma atribuição incompatível antes de esta acontecer, normalmente através do bloqueio de uma combinação de funções no próprio sistema de acessos. Os controlos de deteção identificam os conflitos a posteriori, através de registos de auditoria e da revisão periódica de acessos. Os controlos compensatórios substituem uns e outros quando uma equipa é demasiado pequena para separar totalmente um processo.

Os controlos preventivos são os mais fortes, porque eliminam totalmente a oportunidade. Um sistema de funções que se recusa a permitir que uma conta detenha simultaneamente as funções de «aprovador» e de «requerente» no mesmo fluxo de trabalho nunca deixa que o conflito chegue a formar-se.

Os controlos de deteção aceitam que alguma sobreposição é inevitável e, em vez de a impedirem, detetam-na. Um registo de auditoria que documenta quem criou uma entrada, quem a aprovou e quem lhe acedeu depois permite a um revisor identificar um conflito durante uma certificação de acessos, mesmo que o sistema o tenha permitido.

A maioria das orientações sobre SoD pressupõe uma plataforma dedicada de governação e administração de identidades (IGA) ou de GRC a executar verificações contínuas de conflitos. As pequenas equipas de TI raramente dispõem desse orçamento, e a maioria das orientações omite o que fazer em alternativa.

Quatro controlos compensatórios cobrem a maior parte da lacuna. Trata-se da base de SoD de quatro controlos:

• Separar funções sempre que o número de colaboradores o permita
• Encaminhar para um segundo aprovador tudo o que não possa ser separado
• Registar todas as ações privilegiadas num registo de auditoria exportável
• Rever os acessos segundo um calendário fixo, em vez de nunca o fazer

Nenhum dos quatro exige uma plataforma de GRC. Os quatro exigem que alguém seja responsável pelo calendário.

Segregação de funções e quadros de conformidade

A segregação de funções aparece, pelo nome ou como requisito, na maioria dos principais quadros de conformidade, embora o peso legal varie consoante o setor e a jurisdição. A SOX associa-a aos controlos sobre o relato financeiro, o NIST e a ISO enquadram-na como um controlo de segurança geral e a NIS2 integra-a nos requisitos de política de controlo de acesso para entidades essenciais e importantes na UE.

Nenhum destes quadros fornece uma matriz de SoD já pronta. Exigem que a organização tenha uma e que consiga demonstrar como os conflitos são resolvidos.

A exigência da secção 404 da SOX é a que a maioria dos programas de SoD orientados para a conformidade cita por reflexo, embora se aplique especificamente aos controlos sobre o relato financeiro das empresas cotadas, e não a todos os quadros desta tabela. A obrigatoriedade legal da SoD para uma determinada organização depende do setor, da jurisdição e dos quadros aplicáveis. A equipa de conformidade ou a equipa jurídica é a fonte adequada para essa determinação. Esta tabela é um mapa, não um parecer jurídico.

Como o Passwork aplica a segregação de funções no cofre

O Passwork integra a segregação de funções no cofre através de quatro mecanismos: funções de administração não removíveis, funções RBAC personalizadas, sincronização de grupos AD/LDAP e um registo de auditoria exportável. Em conjunto, separam quem cria um cofre de quem o controla permanentemente e fazem da revisão de acessos uma exportação agendada, em vez de uma recolha manual.

As políticas de cofres atribuem administradores ao nível do tipo de cofre, e não a quem quer que crie o cofre. Uma política de cofre define que administradores corporativos obtêm acesso automático e não removível a todos os cofres desse tipo, para que a pessoa que cria um novo cofre de departamento não possa, mais tarde, retirar discretamente a supervisão. Trata-se de um controlo preventivo: o conflito entre «criador» e «administrador permanente» nunca tem oportunidade de se formar.

As funções RBAC personalizadas separam a administração da conta e dos utilizadores do acesso diário aos cofres. O Passwork inclui três funções predefinidas, Proprietário, Administrador e Membro, e permite um número ilimitado de funções personalizadas com âmbito nas definições da conta, na gestão de cofres, na gestão de utilizadores, nos métodos de autenticação e no acesso à API. Consulte como conceber uma política de RBAC empresarial para saber como estruturar as funções antes da implementação. Uma função criada para um técnico de helpdesk não precisa de autoridade sobre políticas de cofres, nem tem de a ter.

A sincronização de grupos AD/LDAP aplica o controlo preventivo em grande escala. Em vez de um administrador verificar manualmente quem pertence a cada grupo do Passwork, é a pertença aos grupos do diretório que o determina. Quando os RH transferem alguém para outra equipa no Active Directory, o acesso dessa pessoa no Passwork acompanha automaticamente a mudança, e a revogação de acessos incompatíveis quando as funções mudam deixa de depender de alguém se lembrar de abrir um pedido.

O Registo de atividade é a camada de deteção. Regista eventos ao nível de cofres, pastas, palavras-passe e conta, filtráveis por data, utilizador e tipo de ação, e exportáveis para Syslog, Windows Event Viewer ou um SIEM. Para um auditor que pede provas da revisão de acessos, um registo exportável faz a diferença entre uma resposta concreta e uma promessa. A descrição completa das capacidades de gestão de acessos do Passwork explica como estas peças se articulam.

Lista de verificação de segregação de funções

Utilize esta lista de verificação para passar de uma configuração de acessos improvisada para um programa documentado de segregação de funções, com ou sem uma plataforma de GRC dedicada.

1. Mapeie todos os processos críticos que movimentam dinheiro, alteram acessos ou afetam a produção
2. Construa uma matriz de segregação de funções e assinale todas as funções que possam iniciar e aprovar a mesma ação
3. Atribua administradores não removíveis por tipo de cofre ou de política, para que a supervisão não dependa de quem criou o recurso
4. Ative a sincronização de grupos AD/LDAP, para que as alterações de acesso acompanhem as atualizações do diretório em vez de dependerem de pedidos manuais
5. Ative o registo de auditoria exportável para todas as ações privilegiadas
6. Agende revisões periódicas de acessos, mais frequentes para as funções de alto risco do que para as funções padrão
7. Documente os controlos compensatórios sempre que a separação estrita não seja viável e registe o responsável por cada um

Conclusão

A segregação de funções funciona como uma disciplina de conceção contínua: sempre que uma função muda, um cofre é criado ou um novo pipeline entra em produção, a pergunta é a mesma. Uma única conta consegue concluir isto sozinha? Se sim, trata-se de um conflito à espera de que um incidente o revele.

A matriz e as referências de conformidade são importantes, mas o trabalho diário é operacional: administradores não removíveis, grupos sincronizados e um registo de auditoria que alguém realmente lê. É aí que a SoD se mantém ou, discretamente, deixa de ter importância.

Comece por abrir o cofre mais sensível e verificar quem pode criar, aprovar e auditar acessos nesse cofre sem qualquer controlo.

Se um administrador desse cofre pode criar, aprovar e auditar acessos sem qualquer controlo, corrija a situação antes que uma auditoria a detete. Iniciar um teste gratuito do Passwork para configurar políticas de cofres que separem essas funções desde o primeiro dia.

Perguntas frequentes sobre a segregação de funções

O que é o RBAC e como resolve o problema de acessos

A proliferação de permissões não acontece de um dia para o outro: acumula-se a cada contratação não auditada. Este guia explica como o controlo de acesso baseado em funções (RBAC) resolve a integração de colaboradores, a saída de colaboradores e as auditorias, e como o Passwork aplica o mesmo modelo às palavras-passe e aos segredos partilhados.

PassworkAlex Muntyan

Políticas de cofres do Passwork: um guia para CIOs sobre segurança empresarial

Os Tipos de Cofre do Passwork associam os direitos de administrador à própria política do cofre, e não a quem o criou, e fecham assim uma lacuna que a maioria das empresas nem sequer sabe que existe. Este guia oferece a CIOs e CISOs um modelo de trabalho para a governação de cofres, alinhado com os requisitos da NIS2 e da ISO 27001.

PassworkPasswork Team

Saída de colaboradores: Guia de revogação segura de acessos 2026

Desativar uma conta SSO não revoga o acesso. As chaves de API, as credenciais de agentes de IA e as palavras-passe partilhadas sobrevivem-lhe. Este guia abrange o procedimento completo de saída de colaboradores, dos desencadeadores à hora zero até à limpeza de NHI.

PassworkAlex Muntyan