A gestão de identidade e acesso – IAM muitas vezes é vista como uma etapa técnica de conceder e revogar acessos, uma simples consequência de contratações e demissões, no entanto, essa é uma visão muito simplista e perigosa. A segregação de funções (SoD) é um bom exemplo disso, pois muitas vezes é negligenciada.
A definição de segregação, frente a lei Sarbanes-Oxley (SOX) dos EUA é que “nenhum funcionário ou grupo de funcionários deve estar em posição de perpetrar e ocultar erros ou fraudes no curso normal”.
Ela é uma técnica de classificação de riscos de acessos a sistemas, que permite que sejam identificadas e mapeadas combinações de telas/funções que causariam riscos de fraudes, apropriação indébita e distorções financeiras/contábeis.
A SoD é exigida para alcançar conformidade regulatória com normas como SOX / PCI-DSS, recomendada por frameworks como ISO 27.001 / COBIT e fundamental na estratégia para o gerenciamento de riscos da empresa.
Na prática, a norma exige que os processos realizados nos sistemas, ao longo do ciclo de vida da informação, sejam entendidos de maneira transversal e que os acessos não permitam a alteração/aprovação em mais de uma etapa do processo por uma mesma pessoa. Os exemplos disso são inúmeros, mas o mais clássico é de alguém programar um pagamento para si mesmo e ter permissão para aprovar a efetivação.
Onde aplicar
Como a legislação obriga sua aplicação apenas a sistemas financeiros/contábeis, dificilmente vemos a aplicação da SoD em outros escopos, o que é um erro, uma vez que atividades mal-intencionadas ocasionadas pelo excesso de permissões podem ocorrer em qualquer sistema.
Em escala menos frequente, mas muito relevante, podemos citar a possibilidade de aplicação da técnica para administração de nuvens (Azure/AWS/GCP), Active Directory, repositórios de arquivos locais/nuvem (Windows server/Sharepoint), repositório de código fonte (Github) e diversos sistemas SAAS (Sales force).
Qual a importância
A importância de não limitar a aplicação da SoD a sistemas financeiros é que existem diversos riscos inerentes a cada nicho de mercado que pode estar atrelado a aplicações operacionais e/ou customizadas. Por exemplo, uma empresa de planos de saúde pode ter fraudes de planos vendidos abaixo do preço de mercado, reembolsos aprovados indevidamente, cobertura de procedimentos não homologados autorizados e etc. O bom resultado desse mapeamento de riscos depende de dois fatos, um consultor experiente e entrevistas com gestores operacionais para entender os riscos específicos do nicho de mercado da empresa.
Fraudes sempre poderão ocorrer, é claro, mas se o indivíduo mal-intencionado tem ferramentas disponíveis, sabe que não existe nada que o impeça, os controles de detectivos são falhos ou inexistentes e há um benefício financeiro, então é quase certo que, se não ocorreu, ocorrerá em breve. Para minimizar esse risco, são implantadas uma série de medidas, sendo a primeira e mais óbvia, garantir que ninguém tenha permissões de perpetrar a fraude, segregando o processo em duas ou mais etapas em que pessoas diferentes são responsáveis por avaliar a licitude das informações e dar a aprovação ou não da continuidade do processo. É claro que isso não impede que duas ou mais pessoas não possam agir em conluio, mas diminui drasticamente os riscos.
Existem alguns sistemas de mercado que possuem processos automáticos de alçada de aprovação, que em conjunto com o organograma de cargos da empresa, faixas de valores e respectivos cargos de aprovação, fazem com que um, dois ou até três superiores hierárquicos precisem aprovar para a efetivação da operação, independente de medidas de controle manual. Essa é uma solução ideal, mas muitas vezes inexistente e cabe ao consultor avaliar as medidas mitigatórias existentes.
Outras ameaças
A SoD também tem função importante na defesa contra-ataques cibernéticos, pois em ambientes híbridos, com VPNs e acessos web às aplicações, os vazamentos de credenciais por phishing e outras técnicas de engenharia social faz com que seja ainda mais relevante, pois quando a conta está corretamente segregada, mesmo que a credencial seja roubada, dificilmente o atacante conseguirá concretizar operações graves nos sistemas invadidos ou acessar outros repositórios através delas.
A LGPD é outro tema em que a segregação não é devidamente aplicada, pois o roubo de dados pessoais é tema muito relevante e muitas vezes é completamente ignorada em permissões de ferramentas de exportação/impressão de bases cadastrais, sendo um risco muito grande tanto quanto a um funcionário mal-intencionado, quanto para um atacante que queira chantagear a companhia para não divulgar os dados roubados.
Como documentar
Cada risco encontrado deve ser colocado em uma matriz gráfica (semelhante ao desenho de batalha naval) onde as diferentes combinações de telas/funções causadoras dos conflitos são indicadas, para facilitar a visualização. Além disso, é preciso montar uma tabela que se relacione cada conflito e se detalhe qual a atividade de cada tela, o que pode ocorrer se houver o uso indevido, quais as medidas mitigatórias previstas para tratar o risco e indicadores de tipo de risco (financeiro/contábil/operacional) e nível de risco (alto/médio/baixo).
Esse material deve ser uma base de trabalho o time de concessão de acessos, uma vez que a cada novo usuário ou a cada nova permissão a ser acrescida, deve-se consultá-lo para validar se a combinação das permissões não fere esse regulamento.
Felizmente hoje existem ferramentas de IGA que são adaptadas a impedir esses conflitos de forma que mesmo automatizando a concessão de acessos, a própria ferramenta impede a concessão conflituosa.
Conclusão
Dessa forma a SOD é uma importante ferramenta para todo programa de IAM sendo fundamental para a estratégia da empresa em reduzir seus riscos e não apenas uma obrigação regulatória, que pode e deve ser aplicada a todas as principais aplicações da empresa.
