Acredito que a minha experiência de anos em torno deste assunto permite-me dizer que este é um tema negligenciado por boa parte das empresas e projetos.
Por Nelson Miller, Unit Director – ERP Solutions, Sowin
A discussão sobre práticas de segurança em ambientes SAP por vezes tem uma amplitude simplificada por profissionais que nem sempre possuem experiência suficiente no tema e que não sabem que as soluções de contorno podem trazer sérios problemas a médio-longo prazo.
De facto, o assunto é quase tão antigo quanto o próprio SAP R/3 e ainda possui pontos controversos como o melhor modelo de construção de perfis de acesso e a periodicidade ideal para atualização de support packages (que contêm as notas de segurança), para citar alguns.
Acredito que a minha experiência de anos em torno deste assunto permite-me dizer que este é um tema negligenciado por boa parte das empresas e projetos. Regra geral, a quase totalidade dos casos em que atuei ou que analisei tinha sérios problemas na construção da sua arquitetura de perfis de acesso (quando havia uma). Ainda assim, este cenário pode ser sensivelmente pior durante os «golives», pois os entraves na operação podem ser reportados como «problemas de acesso», com soluções que deixam os perfis ainda mais abertos e com mais riscos associados aos seus utilizadores.
Assim, em temas mais complexos como SoD (Segregação de Funções), Controle de Acessos Sensíveis e Arquitetura de acesso em novas aplicações e sistemas (como Fiori e HANA), a situação é ainda mais delicada. Além de exigirem um conhecimento mais refinado – e vale a pena reforçar que os conceitos envolvidos no acesso SAP padrão já não são algo totalmente trivial – também exigem um patrocínio ainda mais forte dos stakeholders dos processos de negócio, uma vez que a resistência dos utilizadores pode ser alta em muitos casos.
Infelizmente, um cenário bastante comum é atacar o problema só após vê-lo detetado e exposto por uma auditoria interna ou externa. Isso põe uma pressão imensa sobre os responsáveis para «resolver» o problema, uma vez que este tipo de relatório é entregue ao C-level. Assim, as equipas de TI são logo vistas como «culpadas» e pressionadas por uma solução as soon as possible (o famoso asap). Nestes casos, muitas vezes, só resta confiar numa Big4 e pagar (caro) para ter algum tipo de solução apresentável.
Pessoalmente, não acredito que as melhores soluções possam surgir deste cenário. Tipicamente, paga-se caro por uma solução limitada. Exemplo: um cliente contratou uma grande empresa de consultoria/auditoria por um valor alto após uma auditoria externa detetar um gap de SoD no seu SAP. Seguramente acreditava que a «marca» Big4 ia solucionar o problema. Porém, depois de muitas longas entrevistas com alguns profissionais com pouco domínio do tema, recebeu como principal deliverable um ficheiro com os seus «riscos» e um incentivo para implementá-la nos seus perfis.
Quando atuamos com pressa, por vezes não paramos para pensar no básico. No exemplo, qual seria a razão para implementar uma política de SOD? Dar maior proteção contra erros e fraudes que possam causar prejuízos à empresa, garantindo que diferentes profissionais participem em fases do processo onde a sua experiência é maior, contrabalançando a de outros recursos corporativos. Assim, é mais fácil corrigir um erro ou detetar um desvio. Um plano de implementação deveria ser pensado tendo como base o retorno que este tipo de medida pode oferecer.
A minha experiência com (boas) auditorias mostra que são recetivas a um bom plano. Um plano bem elaborado, mesmo que mais longo, pode ser mais efetivo para a empresa que projetos emergenciais. Algumas perguntas simples podem ajudar em casos desses:
Que departamentos deveriam ser priorizados? Os que mais têm potencial de gerar dano à empresa, por exemplo.
Os riscos, de qualquer criticidade, devem ser tratados ao mesmo tempo? É preferível focar-se nos mais críticos (porque trazem maior risco). Ou seja, não é preciso reinventar a roda (como no exemplo) sem qualquer ajuda prática ao final de muitos meses de projeto.
Uma matriz SOD robusta (com cerca de 200 riscos e outros 150 acessos críticos) é o padrão de todas as empresas de auditoria e segurança SAP. Gastar tempo a entrevistar keyusers importantes para confirmar que VA é incompatível com VF num mesmo perfil é um exemplo típico do que não se deve fazer: é uma perda de tempo para todos os envolvidos. Ferramentas como as da nossa parceira @SecurityWeaver já trazem isso de prateleira, garantindo que o esforço seja dedicado ao maior desafio (rever a arquitetura de acessos) sem que o negócio seja afetado.
Impossível? Na minha última palestra sobre o tema, no antigo SAP Forum Brasil, a primeira pergunta do público foi: «Como tens emprego depois deste projeto?». A resposta foi (e é) simples: não há magia. É preciso o timing certo, com conhecimento específico, as ferramentas corretas, mas – e acima de tudo – muita parceria com o negócio. Isto porque este não é um «Problema de TI». Os sistemas corporativos (ERP) são ativos da empresa e a sua segurança afeta a todos. Assim, cada departamento deve ajudar a definir e reforçar as regras a serem aplicadas.