Como as organizações podem aplicar a separação de funções nos controles de acesso?

Separação de funções nos controles de acesso

Separação de funções e segregação de funções são o mesmo controle com dois nomes. Auditores tendem a dizer "segregação." As equipes de TI tendem a dizer "separação." Significam a mesma coisa: nenhuma pessoa deve ser capaz de realizar um processo sensível do início ao fim sem uma segunda verificação.

Se o mesmo funcionário puder criar um fornecedor, aprovar o pagamento desse fornecedor e reconciliar a conta, ninguém verifica essa transação de forma independente. SoD quebra a cadeia atribuindo cada etapa a um papel diferente. SOX exige isso para tudo que envolve relatórios financeiros, e os auditores querem prova de que os conflitos são monitorados continuamente, não apenas documentados uma vez e arquivados.

Como aplicar a separação de funções

Mapeie seus conflitos primeiro. Crie uma matriz de responsabilidades listando os pares de funções ou permissões que não devem estar com uma única pessoa: criar um vendor e aprovar pagamentos ao vendor, criar uma ordem de compra e aprovar essa compra, solicitar acesso e aprovar esse mesmo acesso. Um par é negligenciado mais do que deveria: administrar controles de acesso e administrar os logs de auditoria que os revisam. Um admin que pode conceder acesso e editar os logs destinados a detectar abusos anulou todo o propósito da auditoria.

Construa funções com base na função do trabalho, não nas pessoas. Depois de saber quais são os conflitos, atribua permissões por função em vez de por indivíduo e dê a cada função apenas o que ela precisa. O princípio do menor privilégio faz duas coisas aqui: reduz o número de combinações conflitantes que você precisa monitorar e limita o impacto se uma conta for comprometida.

Decida o que você vai prevenir versus o que vai detectar. Controles estáticos impedem uma atribuição conflitante antes que ela aconteça, bloqueando que alguém assuma dois papéis incompatíveis. Controles dinâmicos permitem a atribuição, mas a sinalizam, ou exigem que uma segunda pessoa aprove a transação específica depois. A maioria das organizações precisa de ambos. Bloqueie os conflitos óbvios imediatamente. Use aprovação independente para as áreas cinzentas que uma regra geral seria muito rígida para lidar.

Exija uma segunda pessoa para ações de alto risco. Para tudo que não pode ser totalmente separado por função, exija aprovação independente antes da conclusão. Uma pessoa inicia, outra aprova. Aplique isso à liberação de pagamentos, implantação de código ou qualquer alteração que envolva um controle financeiro.

Centralize onde puder. Quanto mais sistemas estiverem em uso, mais difícil será aplicar as regras de forma consistente. Um usuário bloqueado em um sistema por um papel restrito ainda pode ter acesso ativo em outro lugar que ninguém lembrou de verificar. Sempre que possível, gerencie o acesso por meio de uma única camada para que a mesma política se aplique em todos os lugares, em vez de ser reinventada sistema por sistema.

Revise o acesso conforme um cronograma, não apenas quando algo falhar. Os papéis mudam. As pessoas mudam de função, assumem responsabilidades temporárias e acumulam acessos que ninguém lembra de ter concedido. Defina uma revisão recorrente, confirme que cada papel ainda corresponde ao trabalho e corrija qualquer acesso suspeito.

Documente controles compensatórios quando a separação real não for possível. Equipes pequenas às vezes não conseguem separar completamente cada função. Se uma pessoa precisa criar e aprovar pedidos de compra porque não há ninguém mais, não apenas dê de ombros e siga em frente. Implemente uma revisão independente por um gerente e mantenha registro.

Separação de funções no NetSuite

O modelo nativo de funções e permissões do NetSuite não sinaliza conflitos SoD para você. Você pode criar funções e atribuir níveis de permissão, mas nada na plataforma indica que duas funções atribuídas à mesma pessoa estão em conflito, nem impede que essa atribuição seja salva. Assim, SoD vira um exercício de planilha: alguém cruza cada função, cada nível de permissão, cada funcionário com a matriz de deveres, e faz isso novamente sempre que uma função muda. É lento, fácil de errar, e os auditores não aceitam uma limpeza pontual como controle contínuo. Um conflito perdido, uma pessoa que pode criar e aprovar o mesmo pagamento a fornecedor, é o tipo de coisa que transforma uma auditoria limpa em uma lista de remediação.

StrongpointO módulo Advanced SoD da Strongpoint traz essa aplicação diretamente para o NetSuite. Comece com uma biblioteca de regras predefinidas construída ao longo de anos de trabalho com clientes e auditores, cobrindo as necessidades da maioria das organizações desde o início. Ative apenas as regras que você precisa e crie suas próprias regras baseadas em função, permissão ou ambas, para um controle mais refinado sobre registros personalizados sensíveis quando algo estiver faltando. Os controles de bloqueio impedem uma atribuição incompatível no momento em que alguém tenta salvá-la, para que a prevenção ocorra em tempo real, em vez de na próxima revisão trimestral. Para conflitos que você não pode bloquear totalmente, a Strongpoint registra o incidente e encaminha qualquer isenção por meio de uma solicitação de alteração e aprovação documentadas, para que cada controle compensatório deixe um rastro. O modo de teste permite modelar uma nova regra contra funções ou funcionários existentes antes que ela entre em vigor, para que você possa ajustá-la antes que comece a funcionar. E a Strongpoint registra cada alteração de regra, isenção e violação, para que o Relatório de Auditoria SoD e relatórios relacionados forneçam evidências contínuas para auditorias SOX, em vez de uma reconstrução de última hora de quem teve qual acesso e quando.