No artigo anterior, falamos muito sobre segurança de sistemas ERP. Agora queremos falar sobre maneiras de protegê-los.
A proteção dos sistemas ERP é um desafio. Um bom projeto abrangente pode levar anos para ser concluído, especialmente quando se lida com grandes paisagens. No entanto, vale a pena investir. Aqui estão algumas etapas básicas que ajudarão você a projetar com segurança sua implementação SAP quando estiver no estágio de planejamento. Você também pode aplicar essa metodologia para proteger seus sistemas dos ataques mais comuns.
1. Proteja-se contra ataques externos, desative serviços não seguros
Qualquer aplicativo mais ou menos complexo possui uma grande funcionalidade necessária em geral, mas desnecessária em casos específicos. Quase toda essa funcionalidade em um sistema ERP típico é ativada por padrão.
Como de costume, a instalação do SAP inclui aproximadamente 1500 vários serviços da Web, disponíveis remotamente em nome de qualquer usuário registrado, se o serviço estiver ativado por padrão. Além disso, cerca de 40 serviços são acessíveis mesmo para usuários anônimos. Alguns trabalhos de pesquisa apontaram 13 serviços críticos. Como mencionado acima, esses são apenas serviços básicos.
Recomendamos que você aplique recomendações da diretriz mencionada acima o mais rápido possível - desabilite todos os serviços acessíveis a usuários anônimos, analise quais dos serviços instalados são necessários e restrinja adicionalmente o acesso implementando verificações de autorização.
A arquitetura do sistema SAP deve incluir um proxy baseado na Web (SAP Web Dispatcher) que restringirá o acesso a todos os serviços desnecessários externos e permitirá o acesso apenas aos necessários.
O expedidor da Web do SAP fica entre a Internet e o seu sistema SAP. É o ponto de entrada para solicitações HTTP (s) em seu sistema, que consiste em um ou mais servidores de aplicativos SAP NetWeaver. O SAP Web Dispatcher, portanto, contribui para a segurança e equilibra a carga no seu sistema SAP.
Informações adicionais sobre o SAP Web Dispatcher podem ser encontradas aqui .
2. Aplique os princípios SoD
As soluções SAP têm várias oportunidades funcionais, implementadas por meio de programas, transações e relatórios. O acesso a esses objetos deve ser estritamente regulamentado com base nos valores de autorização que definem usuários, métodos e objetos permitidos para acesso. O acesso a ações críticas (por exemplo, direitos de acesso para modificar transações ou ler tabelas) permite que os usuários realizem ataques aos sistemas SAP, aumentem seus privilégios ou roubem dados críticos.
A segregação de deveres (SoD) é um método de segurança para evitar conflitos de interesses, ou seja, para evitar mais dois direitos de acesso que - sendo concedidos juntos - podem gerar risco de ações fraudulentas (por exemplo, o direito de criar e aprovar) uma ordem de pagamento).
A primeira etapa é minimizar o número de usuários com perfil SAP_ALL ou usuários com acesso a transações críticas, como SE16, SM59 e SE38. Como próxima etapa, aplique os controles SoD, pelo menos os mencionados nas diretrizes da ISACA .
3. Separe o desenvolvimento do teste e verifique se há vulnerabilidades
Para se proteger de desenvolvedores mal-intencionados, primeiro, crie uma separação entre o desenvolvimento de teste e a infraestrutura de produção e depois controle todas as solicitações de transporte do desenvolvimento à produção. Parece fácil; no entanto, o assunto é exatamente o que deve ser controlado. Para arquitetar com segurança a separação entre o desenvolvimento de teste e os sistemas de produção, verifique se não há conexões com credenciais armazenadas dos sistemas com alta prioridade (sistemas de produção) para os sistemas com baixa prioridade (sistemas de desenvolvimento). Essas conexões são permitidas apenas para armazenar configurações técnicas de conectividade e autenticar o usuário para cada acesso.
Como você deve saber, o OWASP (Projeto de segurança de aplicativo da web aberto, focado em melhorar o conhecimento em segurança de aplicativo da web) fornece sua lista dos 10 principais das vulnerabilidades mais perigosas que afetam os aplicativos da web. Quando lidamos com aplicativos corporativos, não é tarefa tão trivial entender quais problemas precisamos verificar. Felizmente, existe o EAS-SEC (eas-sec.org) - uma organização sem fins lucrativos que visa aumentar a conscientização no espaço de segurança de aplicativos corporativos. O EAS-SEC consiste em projetos separados e um deles abrange a segurança do código. É chamado de Guia de desenvolvimento de aplicativos de sistemas de aplicativos corporativos, ou EASAD. Este guia descreve 9 categorias gerais de problemas de código-fonte para idiomas comerciais.
Categorias:
- Injeções (código, SQL, SO)
- Chamadas críticas (para DB, para OS)
- Verificações de controle de acesso ausentes ou incorretas (falta de autenticação, erros)
- Passagem de diretório (gravação, leitura, SMBRelay)
- Modificação do conteúdo exibido (XSS, CSRF)
- Backdoors (credenciais codificadas)
- Canais secretos (soquetes abertos, chamadas HTTP, SSRFs)
- Divulgação de informações (usuários codificados, senhas)
- Instruções obsoletas (READ TABLE, métodos do kernel)
Essas categorias são universais e iguais para a maioria dos aplicativos de negócios, como SAP, Oracle, Microsoft Dynamics e Infor e seus idiomas personalizados.
Um processo de desenvolvimento seguro deve incluir pelo menos a verificação de vulnerabilidades de código dessas nove categorias.
4. Conexões seguras
Como cada sistema é conectado com outros, é essencial entender qual sistema pode ser atacado, como o SAP está conectado a outros aplicativos corporativos, como um invasor pode escalar privilégios e que ativo você deve proteger primeiro. Devemos analisar qual sistema é o mais importante e começar a resolver problemas nesse sistema específico.
Primeiro de tudo, precisamos atribuir gravidade para cada ativo. Em seguida, analise as conexões entre os ativos, estejam eles seguros ou não e, finalmente, priorize os ativos pelo impacto geral em toda a segurança do cenário. Por exemplo, você tem um ativo de baixo risco, por exemplo, um sistema de teste sem dados críticos. Este sistema tem uma conexão com o sistema de produção, e esse sistema de produção, por sua vez, tem uma conexão com a infraestrutura do ICS. Levando em conta todas as conexões, esse sistema de teste pode ter um alto impacto em todo o cenário e devemos nos preocupar com sua segurança.
Além dos mecanismos de um servidor de aplicativos, os servidores geralmente podem estar conectados a vários outros mecanismos. Por exemplo, as soluções SAP podem ser instaladas em servidores Windows, que fazem parte de um único domínio e são executados com privilégios de uma conta comum. Nesse caso, obter acesso a um servidor quase sempre significa acesso a todos os outros servidores, não importa quão adequadamente eles estejam protegidos no nível do aplicativo. Também é possível quando links ou conexões confiáveis são implementados via DBMS . O DBMS geralmente armazena referências a outros bancos de dados com dados de autenticação predefinidos, tornando assim outros DBMS acessíveis. Além disso, o escopo de tais mecanismos inclui quaisquer outros métodos possíveis para penetrar no sistema vizinho, que os auditores geralmente usam em testes de penetração, ou seja, uma tentativa de efetuar login em um sistema vizinho com senhas iguais ou semelhantes nos níveis de sistema operacional, DBMS e aplicativo , bem como todos os tipos de pesquisa de senhas em texto sem formatação no sistema de arquivos; atualização, integração, scripts de backup, etc. Todas essas opções devem ser verificadas para eliminar qualquer risco de penetração com um link fraco para todos os sistemas.
Outro risco de conexões inseguras é o vazamento de dados. Os sistemas SAP devem criptografar os dados durante a transferência. Está claro que o tráfego HTTP deve ser protegido por SSL, mas a maior parte do tráfego é transferida usando os protocolos proprietários da SAP, que são inseguros por padrão, como RFC (Protocolo para conectar sistemas SAP), DIAG (Protocolo para conectar cliente SAP ao servidor SAP) e protocolo do servidor de mensagens. Infelizmente, não há como proteger o tráfego do servidor de mensagens; portanto, simplesmente colocar esse serviço no firewall será a única opção. Quanto aos protocolos DIAG e RFC, a criptografia pode ser implementada via SNC.
O SNC sem capacidade de conexão única está disponível para todos os clientes do SAP NetWeaver para SAP GUI usando criptografia de cliente SNC e para toda a comunicação RFC entre servidores SAP. Os recursos básicos de logon único estão disponíveis em ambientes em que os servidores SAP e clientes SAP GUI executam a Microsoft.
Sumário
O ERP Security é uma tarefa complexa. No entanto, apenas essas quatro etapas de alto nível podem melhorar significativamente o nível de segurança do seu sistema ERP. Somente depois de implementar a arquitetura com segurança, faz sentido adotar outras etapas, como gerenciamento de vulnerabilidades e resposta a incidentes.