Las empresas líderes adoptan las funcionalidades de SAP para cubrir sus requisitos empresariales y responder rápidamente a los cambios constantes que se producen en el mercado. Y a medida que SAP transforma los procesos empresariales con la automatización inteligente con su renovado conjunto de productos, también aumenta el riesgo de seguridad.
Como especialistas en entornos SAP y AWS y siendo conscientes de la relevancia que esta cuestión tiene para todos, Mario de Felipe, nuestro director de Desarrollo de Negocio, inicia con este artículo una serie de cinco posts en los que profundizará en las opciones que ofrece la plataforma cloud para garantizar la seguridad de SAP S/4HANA.
Las nuevas implementaciones de sistemas SAP, las actualizaciones de SAP y las conversiones a S/4HANA se realizan ahora en la nube, y el panorama de las amenazas está cambiando. En cualquier proveedor cloud, los clientes deben adoptar un enfoque holístico para asegurar los sistemas SAP, protegiendo todos los datos SAP generados por los dispositivos, los endpoints, los usuarios, las aplicaciones, las bases de datos y los sistemas de terceros en entornos locales, híbridos y multi-cloud.
A principios de 2021, SAP anunció un programa Go-To-Market llamado Rise with SAP, que da un mensaje a los clientes, con un camino fácil para actualizar sus sistemas SAP a S/4HANA utilizando los proveedores cloud.
Los proveedores cloud facilitan la migración de los sistemas SAP de las instalaciones a la nube, prometiendo un menor coste total de propiedad y agilidad de TI. Por lo tanto, los clientes tienen que decidir si seguir desplegando las aplicaciones en sus propios centros de datos o trasladarlas a la nube para liberar a los empleados del mantenimiento de las TI para que realicen tareas más innovadoras, lo que se traduce en una transformación digital más rápida y una mayor competitividad para la empresa. No es una decisión fácil si se tiene en cuenta que hay que desplegar varias soluciones de seguridad de red.
AWS aprovecha su amplia inteligencia sobre amenazas, una sólida cartera y una seguridad de inteligencia artificial (IA) y aprendizaje automático (ML) de última generación para ofrecer una experiencia de seguridad sin fisuras en nuestros entornos SAP. Automatiza los controles de seguridad, lo que facilita la administración, la respuesta y la automatización de las capacidades de SecOps.
Si la seguridad de SAP no era una gran preocupación antes, debería serlo ahora
Según Canalys, en 2020 se produjo un gasto récord en ciberseguridad, pero también un récord de violaciones de datos, y en 2020 se produjeron más ciberataques que en los 15 años anteriores juntos.
Fuente: Canalys.
Mientras que la protección de las soluciones SAP es lo más importante, los daños globales por ciberdelincuencia alcanzarán los 6 billones de dólares en 2021 y en los años venideros, según Canalys.
Con S/4HANA, y otras soluciones SAP, llega SAP Fiori, una interfaz web para los usuarios que sustituye cada vez más a la GUI de SAP. Fiori, un front-end basado en HTML5, es un objetivo de ataques.Existen riesgos de seguridad para SAP.
Actualmente, SAP no proporciona orientación sobre la seguridad de la infraestructura. No proporciona ninguna norma sobre cómo los sistemas SAP pueden prevenir los ataques de seguridad con las tecnologías actuales disponibles para los ciberdelincuentes.
Algunas de las vulnerabilidades de SAP han sido explotadas en los últimos tiempos, como vemos en la imagen. Las autoridades tuvieron que dar a estas vulnerabilidades nombres en clave como RECON o 10KBLAZE. Cada mes, SAP publica avisos de seguridad sobre vulnerabilidades o errores actuales que podrían poner en peligro todo el entorno de SAP. Estos avisos deben implementarse en los sistemas SAP lo antes posible, y algunos otros a intervalos regulares para garantizar un funcionamiento seguro. Recordemos que la tarea de seguridad de las aplicaciones siempre queda bajo la responsabilidad del cliente.
RECON (publicado en 2020) comparte similitudes con 10KBLAZE, publicado en 2019 y ambos ponen en riesgo la confidencialidad, integridad y disponibilidad de los datos y procesos de SAP. ¿Qué tienen en común estos dos exploits? Aprovechan la falta de visibilidad y control para tener éxito. Hay una razón por la que estos exploits se centran en la creación de cuentas de administrador: porque una vez que alguien es administrador (legítimo o no), tiene el control.
Ataques modernos como el Hafnium chino dirigido a Microsoft Exchange (robando buzones de correo enteros) o el hackeo ruso de Solarwinds, donde los atacantes explotaron la identidad de la víctima obteniendo su información personal, suplantando al usuario y obteniendo acceso a las cuentas de Azure y Microsoft 365 de la víctima, dando un mensaje: nadie está a salvo de una campaña de ciberataque global, y el objetivo es afectar a tantas empresas como sea posible.
¿Por qué es importante para los clientes de SAP?
- Impacto en el negocio. Supongamos que un atacante puede acceder a un sistema SAP desprotegido explotando una aplicación vulnerable orientada a Internet o ejecutando un ataque desde dentro de la organización en sistemas inseguros. En ese caso, el impacto empresarial podría ser crítico. En muchos escenarios, el atacante accedería al sistema SAP vulnerable con los mayores privilegios (Administrador/SAP_ALL), saltándose todos los controles de acceso y autorización (como la segregación de funciones, la gestión de identidades y las soluciones GRC). Esto significa que el atacante podría obtener el control completo del sistema SAP afectado, sus datos empresariales subyacentes y sus procesos. Tener acceso administrativo al sistema permitiría al atacante gestionar (leer/modificar/borrar) cada registro, archivo e informe del sistema.
- Impacto en el cumplimiento de la normativa. Para muchas organizaciones, las aplicaciones SAP de misión crítica están bajo la supervisión de regulaciones específicas de la industria y del gobierno, así como de requisitos financieros y de otro tipo. Cualquier control reforzado que se eluda a través de la explotación de las amenazas comentadas en este informe podría causar deficiencias de cumplimiento normativo y reglamentario en áreas críticas como GDPR o Sarbanes-Oxley debido a cambios no autorizados en los datos financieros o a la elusión de los controles internos. Para las organizaciones que deben cumplir con los mandatos de cumplimiento normativo, esto desencadenaría un fallo de auditoría y violaría el cumplimiento. El resultado podría llevar a una posible revelación de la violación, costosas auditorías de terceros y sanciones que podrían incluir multas y acciones legales.
En este post presenté las mejores prácticas y recomendaciones para implementar un SAP S/4HANA seguro con las tecnologías inteligentes de AWS. También destaco los vectores de ataque más comunes en SAP y cómo la cartera de AWS puede hacer frente a esos vectores adoptando un papel preventivo y de detección en los entornos SAP. No se trata de un blog de seguridad SAP generalista, sino de cómo AWS puede ayudar a asegurar los sistemas SAP.
Fuente: Linke
Introducción a la serie
Las recomendaciones o normas específicas relativas a la seguridad de la red, el sistema operativo o el cliente (seguridad de la infraestructura) son relevantes. Sin embargo, SAP no proporciona ninguna norma sobre cómo los sistemas SAP pueden evitar los ataques de seguridad con las tecnologías actuales de las que disponen los ciberdelincuentes. Aquí es donde AWS añade valor para garantizar un entorno SAP seguro.
Cualquier cliente de SAP que funcione en AWS tiene derecho a cubrir su parte de responsabilidad en el modelo de responsabilidad compartida.
Cuando empezamos a trabajar en AWS, el principio de seguridad (y, hasta cierto punto, operativo) más crítico que debemos entender es quién es responsable de qué. ¿Quién es responsable de poner parches al sistema operativo? ¿Quién es responsable de cifrar los datos en reposo? ¿Quién es responsable de la seguridad de las aplicaciones? ¿Quién es responsable del cumplimiento de la normativa? Resulta que nosotros somos… para todo esto.
Bajo el modelo de responsabilidad compartida de AWS, AWS proporciona una infraestructura global segura y servicios básicos de computación, almacenamiento, redes y bases de datos. Esencialmente, todo hasta el hipervisor es responsabilidad de AWS. Nosotros, los usuarios, somos responsables de proteger la confidencialidad, la integridad y la disponibilidad de los datos en la nube y de cumplir los requisitos empresariales y de conformidad específicos.
En esta serie de posts, nos centraremos principalmente en la seguridad del entorno y de las aplicaciones de SAP Secure Operations Map, al tiempo que nos centraremos en el ecosistema que lo rodea, incluyendo la segmentación, la seguridad del firewall de aplicaciones web (WAF) y las prácticas de seguridad de red recomendadas.
IAM (Identity Access Management)
Fuente: Linke
IAM trata de la identidad de las cuentas de AWS, usuarios, grupos, roles y políticas. Todo esto puede ser complejo, y es fácil hacerlo incorrectamente. Las aplicaciones que se ejecutan en una instancia de Amazon EC2 necesitan credenciales para acceder a otros servicios de AWS. Por ejemplo, necesitamos crear un rol para que una instancia de SAP HANA acceda al bucket de S3 para configurar el AWS Backint. Para permitir que nuestra instancia de Amazon EC2 acceda a un bucket de Amazon S3 de destino, debemos crear o actualizar una política de IAM en línea con los permisos y adjuntarla al rol de servicio de EC2. Debemos proteger todos los accesos, desde las aplicaciones hasta los usuarios.
Gestión y separación de cuentas de AWS
La recomendación es separar las cargas de trabajo y agrupar las cuentas basándose en la función, los requisitos de conformidad o un conjunto estándar de controles en lugar de reflejar la estructura de informes de nuestra organización. En AWS, las cuentas son un límite rígido, un contenedor de confianza cero, para los recursos. Por ejemplo, se recomienda encarecidamente la separación a nivel de cuenta para aislar las cargas de trabajo de producción de las de desarrollo y prueba.
Hay muchos aspectos para asegurar nuestras cuentas de AWS, incluyendo la obtención, la no utilización del usuario raíz, y mantener la información de contacto actualizada. Podemos utilizar AWS Organizations para administrar y gobernar de forma centralizada nuestras cuentas a medida que crecemos y escalamos nuestras cargas de trabajo en AWS.
El servicio de AWS Control Tower ofrece una forma simplificada de configurar y controlar varias cuentas. Automatiza la configuración de las cuentas en nuestra organización de AWS, automatiza el aprovisionamiento, aplica barreras de protección (que incluyen la prevención y la detección) y proporciona un panel de control para la visibilidad.
Mantener los entornos SAP Prod separados de los entornos SAP no Prod es un enfoque cada vez más utilizado por los clientes. Hoy en día, muchos clientes de AWS utilizan cuentas de AWS separadas (normalmente junto con la facturación consolidada) para sus recursos de desarrollo y producción. Esta separación les permite separar los diferentes tipos de recursos de forma limpia y proporcionar beneficios de seguridad y conformidad.
Fuente: Linke
Gestión de identidades
Hay dos tipos de identidades que necesitamos gestionar cuando nos acercamos a operar cargas de trabajo seguras en AWS.
- Identidades humanas: Los administradores, desarrolladores, operadores y consumidores de SAP necesitan una identidad para acceder a los entornos de AWS. Pueden ser miembros de nuestra organización o usuarios externos a través de navegadores web, aplicaciones cliente, apps móviles o herramientas interactivas de línea de comandos.
- Identidades de máquina: Las cargas de trabajo de SAP que requieren una identidad para interactuar con los servicios de AWS, por ejemplo, para leer datos. Estas identidades incluyen máquinas que se ejecutan en nuestro entorno de AWS, como instancias de Amazon EC2 o funciones de AWS Lambda.
Podemos utilizar identidades centralizadas para AWS con un proveedor basado en SAML 2.0 con AWS IAM para la federación con cuentas individuales de AWS.
Podemos utilizar SAP como proveedor ya que es compatible con el protocolo SAML 2.0 o Active Directory utilizando AWS Directory Service, y federar nuestra cuenta de AWS con el proveedor que hayamos elegido para conceder acceso a las operaciones de la API de AWS con la aserción de SAML y obtener credenciales de seguridad temporales.
Para gestionar a los usuarios finales o consumidores de nuestras cargas de trabajo, como una aplicación móvil, podemos utilizar Amazon Cognito. Proporciona autenticación, autorización y gestión de usuarios para nuestras aplicaciones web y móviles.
Patrick Leung, arquitecto de soluciones en AWS, creó un interesante post sobre la integración de AWS Single Sign-On con SAP Fiori en S/4HANA. El artículo describe cómo aprovechar AWS SSO, un servicio de Amazon que recientemente ofrece integraciones SSO incorporadas a SAP, permitiendo a los usuarios de SAP acceder a la plataforma de lanzamiento de Fiori sin tener que iniciar y cerrar sesión cada vez.
Un paso más allá es implementar MFA para Fiori. Para ello, los arquitectos de soluciones de AWS Ferry Mulyadi y Kyaw Soe Hlaing crearon un post, Securing SAP Fiori with Multi-Factor Authentication on AWS. En él se describe una guía para que los clientes de SAP implementen la autenticación multifactor (MFA) para SAP Fiori utilizando Microsoft Active Directory como servicio de directorio y AWS Single Sign-On (AWS SSO) para gestionar los dispositivos MFA.
Sin embargo, si planeamos utilizar AWS Single Sign-On con otros productos SAP, no sólo con Fiori, el arquitecto de soluciones de AWS Manoj Muthukrishnan ha creado dos interesantes posts que permiten la integración de SAP Single Sign-On con SAP NetWeaver Java y ABAP (WebDynpros).
AWS Secrets Manager
AWS Secrets Manager ayuda a proteger los secretos necesarios para acceder a las aplicaciones y servicios, rotando, administrando y recuperando las credenciales de la base de datos, las claves de la API y otros secretos a lo largo de su ciclo de vida.
Los arquitectos de AWS Kenny Rajan y Marcel Toerpe muestran cómo utilizar las herramientas de AWS DevOps para configurar una canalización simplificada de CI/CD para SAP Fiori mientras se almacenan los secretos de SAP con AWS Secrets Manager, manteniendo como secretos el nombre de usuario, la contraseña y el nombre de host del entorno ABAP de SAP NetWeaver.
Otra idea para aprovechar AWS Secrets Manager con SAP se describe en el post de los arquitectos de AWS Arjun Venkateswarlu y Chris Williams, «Extracting data from SAP HANA using AWS Glue and JDBC».
Utilizando AWS Secrets Manager para almacenar nuestras credenciales de SAP, cumplimos los requisitos de seguridad y conformidad rotando los secretos de forma segura sin necesidad de volver a implementar el código. El objetivo es administrar el acceso con políticas de grano fino de AWS Identity and Access Management (IAM) y asegurar y auditar los secretos de manera centralizada cifrándolos con claves que operamos con AWS Key Management Service (KMS).
Nuestros expertos diseñan la hoja de ruta adecuada para que cada cliente lleve a cabo su migración a la nube con éxito y con la máxima seguridad. Si quieres que te ayudemos en tu proceso digital, contacta con nosotros.
