Visão geral do SAP ERP
Para organizações que utilizam o SAP ERP (Enterprise Resource Planning, ou planejamento de recursos corporativos), ele costuma ser um dos sistemas mais críticos em execução. Ele coleta e atende pedidos de clientes, solicita e rastreia pagamentos, e entrega dados financeiros para executivos e investidores. Em resumo, é a espinha dorsal dos negócios. Se o SAP ERP cair ou ficar comprometido, os negócios podem parar.
Apesar de sua importância, alguns ambientes de SAP ERP ainda precisam se alinhar melhor com os padrões de segurança Zero Trust muitas vezes empregados por soluções modernas de nuvem e SaaS. Isso geralmente se deve à flexibilidade do SAP, o que significa que não há duas implementações idênticas e as alterações geralmente exigem um esforço significativo e especializado.
Como um arquiteto de identidade com vasta experiência em segurança SAP de vários pontos de vista diferentes, posso oferecer uma perspectiva sobre como é possível modernizar as implementações do SAP ERP para aproveitar os mais recentes benefícios de segurança.
Problemas/desafios comuns
Antes de tratarmos de como seria um estado futuro, vamos falar sobre algumas das áreas comuns que apresentam as maiores oportunidades de melhoria.
Nomenclatura e terminologia
Ao trabalhar com um fornecedor tão grande quanto a SAP, acertar a terminologia e a nomenclatura corretas pode ser um desafio. Eu tive dificuldades para encontrar um título apropriado para este blog porque queria ter certeza de que estava me referindo à tecnologia SAP correta.
A SAP oferece uma grande variedade de produtos. Algumas das ofertas mais recentes seguem modelos diferentes do que abordarei aqui. Nesta publicação, quando me refiro ao SAP ERP, estou me referindo ao conjunto de produtos que a SAP construiu e expandiu desde 1972. Normalmente, ele pode ser identificado por algumas palavras-chave: ABAP, S4/HANA, ECC, Basis ou Netweaver.
Autenticação legada
Apesar dos avanços da SAP na tecnologia de interface do usuário da web, ainda é comum que as organizações acessem o SAP por meio do cliente Windows tradicional conhecido como SAPGUI. Embora a autenticação Zero Trust seja possível para o SAPGUI (falaremos mais sobre isso adiante), é um desafio implantá-la e configurá-la. Como resultado, muitas organizações continuam a confiar em senhas para a autenticação.
Com as senhas, surgem todos os desafios familiares: uma experiência do usuário abaixo do ideal, a necessidade de ferramentas de sincronização de senhas e métodos de autenticação de baixa segurança.
Entretanto, a maior preocupação não é a experiência do usuário; é o risco de segurança em potencial. No SAPGUI, a criptografia de rede está intimamente associada à autenticação. Em muitas implantações, isso significa que nomes de usuário e senhas trafegam pela rede interna em texto sem criptografia. Se ferramentas de sincronização de senhas forem usadas, isso também poderá expor senhas do Active Directory. Finalmente, se o modo Entra ID Hybrid estiver habilitado, o mesmo risco pode se estender às credenciais do Entra ID.
O uso de uma VPN ou a habilitação da autenticação do Windows podem ajudar a reduzir parte desse risco, mas não são soluções completas. Uma verdadeira estratégia de Zero Trust presume que a rede está comprometida e impõe uma autenticação avançada em todas as camadas, sem depender unicamente de proteções baseadas na rede.
Projetos RBAC incompletos e desvio de configuração
O modelo de autorização SAP é altamente detalhado e complexo. No início da minha carreira como administrador, tive que fazer o curso ADM940 da SAP sobre segurança e autorizações. Não foi uma leitura leve, mas me ensinou como funciona a segurança SAP.
A segurança SAP é frequentemente pensada em termos de códigos de transação (T-codes), cada um associado a uma tarefa de negócios. No entanto, por trás de cada ação do usuário, dezenas ou até centenas de autorizações díspares são verificadas. Essas verificações de autorização podem ser diferentes dependendo das condições do usuário ou da versão do SAP que está sendo implantada (falaremos mais sobre isso mais tarde).
Complexidade é uma coisa; escala é outra. Agora que estabelecemos a complexidade das funções dentro do SAP, vamos falar sobre escala. Muitos projetos de controle de acesso baseado em função (RBAC, na sigla em inglês) enfrentam obstáculos ao tentar cobrir 100% do acesso com funções de trabalho dedicadas. Essa meta irreal pode levar a uma relação quase 1:1 entre o número de usuários e funções. Embora esse problema não seja específico para implementações SAP, ele se manifesta de várias maneiras, o que pode complicar um ambiente SAP.
O SAP fornece ferramentas para gerenciar funções que são úteis quando usadas de forma consistente. Mas, em muitos ambientes, a consistência é rara. O que funciona em um sistema SAP geralmente não funciona da mesma forma em outro local.
Como resultado, muitas organizações utilizam métodos de baixa garantia para atribuir acesso:
- Copiar de um usuário existente: o SAP até possui esse recurso de "model as" integrado.
- O acesso é atribuído com base em códigos de transação (T-codes). Os T-codes são um método simplista de determinar o nível de acesso de uma determinada função.
As duas abordagens trazem desafios. A modelagem de usuários com base no pessoal existente corre o risco de propagar acesso inadequado que pode ter se acumulado ao longo do tempo. Os T-codes dão apenas uma visão parcial do que um usuário pode fazer. Além disso, há um equívoco comum de que os T-codes podem ser atribuídos diretamente — eles não podem. Por fim, os módulos SAP mais recentes não são baseados em T-codes, o que faz com que esse método gradualmente se torne obsoleto.
Já percorremos esse caminho antes
Não deve ser surpresa que várias iterações de soluções para esse problema tenham sido empregadas no passado (e ainda estejam em uso hoje). Confira um exemplo de como os produtos de gerenciamento de identidades e de governança de identidade têm sido usados para fornecer soluções parciais:
Resumo do componente
Observação: estou usando termos genéricos propositalmente para esses componentes — muitas vezes, os produtos de identidade servirão para uma ou mais dessas funções.
Enterprise Directory Service
Esse componente é responsável pelos serviços de controle de acesso em tempo de execução. Para situações em que a autenticação SAP local ocorre, é aqui que a senha do usuário seria sincronizada. Para situações em que o SSO está configurado no SAP, os serviços de autenticação Kerberos legados seriam fornecidos por esse serviço.
Enterprise Provisioning Service
Esse componente é responsável por realizar o controle de acesso baseado em função e o provisionamento de acesso em todo o ambiente. O serviço ajuda a garantir que as contas de usuário corretas sejam configuradas nos sistemas corretos e que o acesso correto seja configurado nessas contas (incluindo o serviço de diretório).
Módulo SAP GRC
Esse módulo serve para muitos propósitos, incluindo assumir o provisionamento SAP automatizado do serviço de provisionamento global, realizar a análise de separação de funções e obter as aprovações de acesso adequadas para qualquer acesso SAP solicitado.
Embora possa ajudar a cumprir os requisitos de conformidade, esse design apresenta alguns desafios que talvez limitem o sucesso da implantação.
- As aprovações para acesso ao SAP são completamente diferentes daquelas para outros aplicativos corporativos. Isso significa diferentes sistemas de auditoria, diferentes mecanismos de fluxo de trabalho para administradores e diferentes processos de aprovação para aprovadores. Também pode significar uma experiência do usuário confusa — o usuário terá dificuldade para entender se os aprovadores não estiverem aprovando as tarefas rapidamente.
- O serviço de provisionamento corporativo tem visibilidade limitada do acesso existente em cada sistema SAP. Embora o SAP GRC possua mecanismos confiáveis para sincronizar dados entre ele e sistemas SAP individuais, o fato de o sistema de toda a empresa não ter acesso direto ao sistema de registro pode dificultar a identificação e o rastreamento de erros de sincronização quando ocorrerem.
- Esse design geralmente não permite a colaboração entre o acesso em tempo de execução controlado pelo serviço de diretório e o acesso em repouso gerenciado pelo serviço de provisionamento. Por exemplo:
- E se precisarmos conceder acesso temporário por apenas uma hora?
- E se quisermos que a autenticação mude com base no nível de acesso que um usuário tem?
- E se precisarmos de uma autenticação avançada para usuários avançados do SAP em comparação com usuários com acesso limitado?
Nesse modelo, duas plataformas separadas controlam dois tipos diferentes de acesso. Como resultado, casos de uso Zero Trust como esses normalmente só podem ser reunidos por meio de uma orquestração complexa e frágil — sem suporte nativo.
Existe uma maneira melhor!
Na Okta, nossa visão é permitir que qualquer organização use qualquer tecnologia com segurança. Isso significa que o SAP, como um componente crítico para as organizações que o empregam, deve ser gerenciado de forma padronizada que se preste a uma estratégia Zero Trust em toda a empresa.
Resumo do componente
Okta Platform
Aqui, a Okta oferece gerenciamento de identidades, governança de identidade e serviços de acesso privilegiado em toda a empresa. Ela ajuda a garantir que as identidades sejam devidamente sincronizadas e gerenciadas de acordo com a política. Além disso, oferece uma única experiência de solicitação/aprovação de acesso, uma única experiência de certificação de acesso e, por fim, uma plataforma de autenticação única e sensível ao contexto para a organização.
SAP GRC
Para implantações SAP maiores e focadas em conformidade, o SAP GRC desempenha um papel fundamental. Ele fornece os recursos de varredura de separação de tarefas com granularidade fina necessários para auxiliar nos requisitos de conformidade. Incorporada a essa capacidade está a expertise de domínio que a SAP está preparada para fornecer. O que caracteriza acesso inadequado? Qual acesso entra em conflito com qual outro acesso? Essas questões estão profundamente enraizadas no domínio do produto SAP e são melhor respondidas pela própria SAP. Eu argumentaria que esse conjunto de regras é um dos componentes mais valiosos do produto SAP GRC.
Embora tenha um papel importante nessa arquitetura, o GRC funciona mais como uma API e ferramenta administrativa — não algo com que os usuários finais ou aprovadores normalmente interajam.
Este diagrama ilustra, de forma geral, os papéis e responsabilidades da Okta e do GRC no padrão de implantação recomendado.
Na superfície, essa estratégia apresenta benefícios claros tanto para o usuário final quanto administrativos:
- Um sistema responsável por todas as tarefas de sincronização de identidade em toda a empresa.
- Um processo de aprovação, processo de solicitação e processo de auditoria em toda a empresa.
- Os controles críticos de segurança SAP são mantidos.
- As principais plataformas de auditoria recebem as informações mais recentes diretamente dos sistemas SAP, sem chance de falha intermediária.
Em alto nível, é uma questão de usar a ferramenta certa para o trabalho certo. Hoje, porém, operamos em um mundo onde a identidade e a segurança são equivalentes — e a Okta oferece uma estrutura de segurança de identidade que transforma ferramentas de identidade em ferramentas de segurança.
Você já deve ter ouvido o termo "plataforma de identidade convergente". É uma ferramenta reconhecida por líderes e analistas do setor. Quando colocado em prática, o conceito pode beneficiar a segurança não só da sua implantação SAP, mas também de toda a sua empresa.
Anteriormente, mencionei dois tipos de acesso: "em repouso" e "em tempo de execução".
- O acesso "em repouso" se refere aos usuários, contas, direitos e funções que são configurados em toda a sua empresa. No SAP, isso significa seus registros mestre de usuário e as atribuições de função. Eu me refiro a esse acesso como "em repouso" porque é relativamente estável e não considera nenhum contexto de tempo de execução quando está sendo avaliado pelas verificações de autorização do SAP.
- O acesso "em tempo de execução" ocorre quando um usuário realmente tenta realizar uma ação. Em qual dispositivo ele está? Qual é o estado desse dispositivo? De qual rede ele está se conectando? Existe algo de anormal no comportamento dele? Como ele se autenticou e há quanto tempo?
Para uma estratégia de defesa em profundidade Zero Trust de verdade, ambos os tipos de acesso precisam funcionar em conjunto. Não é suficiente que um usuário tenha acesso — ele deve usar esse acesso apenas nas condições adequadas.
Ao reunir tudo isso em uma única plataforma, como a Okta, é possível aplicar essas camadas de segurança de forma escalável. O resultado é uma abordagem moderna de Zero Trust que ajuda a garantir que o ambiente SAP seja protegido com o mesmo rigor que as demais infraestruturas críticas.
Resumo
Se você ainda está comigo — agradeço a companhia. Meu objetivo com esta publicação foi trazer clareza a três ideias principais:
- Uma visão geral rápida das oportunidades de modernização de identidade disponíveis para clientes SAP atualmente.
- Uma análise de por que as abordagens tradicionais e isoladas podem limitar a capacitação de um verdadeiro modelo de segurança de próximo nível.
- Uma abordagem de design moderna que usa os pontos fortes da SAP, incluindo seus recursos de segurança, enquanto conecta o SAP aos programas de segurança corporativa mais amplos que muitas organizações estão construindo hoje.
Se você quiser saber mais sobre como é uma plataforma de identidade convergente na prática, confira nosso último webinar aqui.
Este material e as recomendações contidas nele não constituem aconselhamento legal, de privacidade, de segurança, de conformidade ou de negócios. O material é destinado apenas para fins informativos gerais, não refletindo obrigatoriamente os desenvolvimentos legais, de segurança e privacidade mais recentes, nem todas as questões relevantes. Você é responsável por obter aconselhamento jurídico, de segurança, privacidade, conformidade ou negócios de seu próprio advogado ou outro consultor profissional e não deve confiar nas recomendações aqui contidas. A Okta não é responsável perante você por quaisquer perdas ou danos que possam resultar da implementação de recomendações contidas nestes materiais. A Okta não faz declarações ou oferece qualquer tipo de garantia em relação ao conteúdo destes materiais. Informações sobre as garantias contratuais da Okta para seus clientes podem ser encontradas em okta.com/agreements.
Este blog não representa necessariamente a posição, as estratégias ou a opinião da Okta.
