Comuníquese de forma segura con Hana

Las arquitecturas de los entornos SAP han cambiado radicalmente con la introducción de SAP Hana. Hana se desarrolló inicialmente como una base de datos relacional para sistemas SAP basada en tecnología in-memory.

Todo el procesamiento y almacenamiento de datos tiene lugar en la memoria principal del entorno del sistema, lo que supone un enorme aumento del rendimiento en comparación con los sistemas de bases de datos convencionales.

Sin embargo, Hana también abre nuevas posibilidades en el uso empresarial, por lo que se está convirtiendo cada vez más en una plataforma de desarrollo en la que se ejecutan aplicaciones Java y HTML5 en entornos de ejecución.

La atención se centra ahora en las aplicaciones basadas en web que se comunican a través de HTTP.

Sin embargo, el núcleo de SAP en Hana ya no puede ser modificado por el propio usuario en términos de programación; Hana se considera por tanto un sistema cerrado y pone sus funciones a disposición a través de un gran número de conectores e interfaces, a los que se puede acceder mediante programas de aplicación de desarrollo propio.

En la actualidad, el núcleo de Hana cuenta con más de 2.000 conectores e interfaces de este tipo, y la tendencia va en fuerte aumento porque cada vez se cubren más áreas de aplicación. En general, en esta plataforma pueden distinguirse las siguientes vías de comunicación:

Conexiones a Hana a través del cliente de base de datos: Se utilizan principalmente para gestionar el sistema de base de datos -por ejemplo, Hana Cockpit o Hana Studio- o para realizar consultas clásicas a la base de datos, por ejemplo, con herramientas de inteligencia empresarial o incluso simplemente con Excel. La comunicación se realiza mediante el protocolo SQLDBC, que es un derivado de ODBC/JDBC.

Conexiones desde los llamados clientes web. Estos pueden ser, por ejemplo, aplicaciones que se ejecutan en el tiempo de ejecución Java de Hana XS y se incrustan directamente en el entorno de la base de datos.

Para ello es necesaria la extensión XS; la comunicación basada principalmente en web (HTTP/HTTPS) suele ejecutarse a través de los puertos TCP 3xx33, donde xx representa el número de instancia correspondiente. En esta configuración, XS proporciona la máquina de ejecución Java y el servidor web.

Esto acarrea una serie de problemas para la seguridad de la plataforma y las aplicaciones: Dentro de la plataforma, la comunicación es "texto plano", lo que significa que todos los datos se intercambian sin cifrar; esto se aplica tanto a la base de datos como a los clientes web.

Los componentes respectivos deben autenticarse mutuamente. Son posibles la autenticación básica (nombre de usuario/contraseña), las afirmaciones SAML y los certificados X.509. Sin embargo, la autenticación básica suele considerarse insegura. Sin embargo, la autenticación básica se considera generalmente insegura; SAML y X.509, a su vez, requieren una gestión de certificados adecuada, que sólo está disponible de forma limitada en el entorno de Hana.

De este modo, el tema de la "protección de datos" pasa a un primer plano. Qué ocurre exactamente, por ejemplo, cuando aplicaciones comprometidas acceden a datos a través de los conectores?

Actualmente, la plataforma Hana no proporciona cifrado de RAM. Por lo tanto, un atacante podría instalar una app que obtuviera acceso a todos los datos sin cifrar.

La solución obvia en este caso sería el cifrado de la memoria RAM, pero esto sólo está disponible con la última generación de procesadores y los módulos correspondientes en el sistema operativo.

El reto de la validación

Esto sitúa cada vez más el tema del desarrollo seguro de aplicaciones en el punto de mira de la seguridad, que, por ejemplo, da mucha prioridad a la validación y autorización de datos y flujos de datos.

En el pasado, cuando un entorno SAP aún era un sistema abierto, la mayoría de las funciones eran creadas por el propio desarrollo de Abap y luego se integraban en el núcleo de SAP.

Aunque aquí también podían surgir vulnerabilidades de seguridad, el impacto seguía siendo limitado porque el núcleo SAP proporcionaba cierto nivel de protección; en cualquier caso, toda una infraestructura no podía verse comprometida de este modo.

Ahora el desarrollador está trabajando en otro nivel en el que el sistema ya no le protege; su aplicación accede a los conectores e interfaces y si comete un error crítico para la seguridad aquí, en el peor de los casos toda la infraestructura está abierta a los atacantes, que entonces también pueden acceder a los conectores en cuestión.

Los desarrolladores de aplicaciones deben asegurarse de que sus flujos XML, por ejemplo, estén correctamente validados para que un atacante no obtenga acceso completo a la aplicación a través de las vulnerabilidades correspondientes, la modifique y, a su vez, obtenga acceso a todos los datos de la RAM.

Ahora hay que tener en cuenta la consideración y especificación de los requisitos de seguridad en la fase de diseño y concepción, pero también las inversiones en pruebas -por ejemplo, en pruebas estáticas de seguridad de las aplicaciones (SAST), pruebas dinámicas de seguridad de las aplicaciones y pruebas de penetración-.

En los grandes entornos SAP, los usuarios también tienen que ocuparse cada vez más de cuestiones de infraestructura, como los cortafuegos de aplicaciones web (WAF) y los cortafuegos XML.

Por ejemplo, los desarrolladores utilizan cada vez más microservicios basados en API REST para intercambiar datos, como ocurre con SAP Leonardo, la plataforma para intercambiar y analizar información de IoT.

Estos datos deben transmitirse de forma rápida y segura, y debe evitarse a toda costa que se pongan en peligro. Las firmas digitales, el cifrado del transporte mediante handshakes SSL bidireccionales, la validación XML, por ejemplo, son los medios elegidos para ello.

Muchos desarrolladores siguen absteniéndose de implantar ellos mismos estas medidas de seguridad en sus aplicaciones porque temen una reducción del rendimiento global de sus sistemas, pero, por otro lado, a veces los sistemas tampoco son capaces de soportar estas medidas a nivel de aplicación.

Por lo tanto, los componentes de infraestructura mencionados son indispensables para un funcionamiento seguro en un entorno Hana.

En principio, en el futuro habrá que prestar más atención a la seguridad a nivel de aplicación cuando se utilice Hana, paradójicamente precisamente porque Hana es un sistema cerrado programáticamente y por esta misma razón hay que centrarse en el tema de los canales de comunicación y los socios de comunicación.

En caso de ataque con éxito a las aplicaciones Hana, la plataforma podría convertirse en una puerta de entrada para que los atacantes accedan a cualquier dato de misión crítica.