Seguridad en SAP HANA Cloud

El foco principal de los temas relacionados a la seguridad de SAP HANA Cloud es el control de acceso. Cuando hablamos sobre encriptado de datos y cómo se implementa la encriptación para los datos físicos guardados (datos en reposo) o para los datos que son transferidos mediante un network (datos en tránsito), nuestra preocupación es el acceso no autorizado de hackers y fisgones. De manera similar, cuando hablamos de autentificación y autorización, nuestras preocupaciones se reducen a controlar quién puede acceder a qué. Password policies, SSO, proveedores de autentificación, y certificados son todos derivados de esta precupación. Incluso la auditoria, que mantiene un registro sobre quien hizo qué en la base de datos, en última instancia, sirve para los mismos fines, aunque a posteriori, para gobernar, requerimientos legales o arreglar errores con el ajuste actual de seguridad.

Puedes pensar que un servicio gestionado de base de datos (con tus datos guardados en alguna parte en un centro de datos de otro y con acceso a los datos desde el Internet público) es inherentemente menos seguro que una base de datos localizada en el centro de datos de tu propia compañía. Sin embargo, como veremos, con el encriptado habilitado por defecto, y restricciones en vigor que prohiba acceso a los archivos del sistema, por ejemplo, no es necesariamente el caso. Como un servicio gestionado, SAP toma cierta responsabilidad y garantía de la seguridad de tus datos. Sin embargo, necesitarás proporcionar listas de IP permitidas, desactivar los superusuarios de la base de datos, e implementar las best practices de seguridad recomendadas por SAP.

De muchas maneras, la configuración de seguridad para SAP HANA Cloud es similar a la configuración de SAP HANA, platform edition (on-premise). Asumo que estás familiarizado con los temas de seguridad de SAP HANA, por lo que nos enfocaremos más en las diferencias entre los dos sistemas y menos en las funcionalidades comunes de ambos entornos.

Continuaremos con nuestro enfoque práctico y cambiaremos a la vista Security y User Management de la app Database Overviewen el cockpit de SAP HANA, como se muestra en la imagen. Después de hacer el tour por las cards, apps y enlaces, abordaremos varios aspectos de seguridad de SAP HANA como servicio y lo envolveremos con algunas recomendaciones de seguridad.

Data Encryption

La card Data Encryption en la app Database Overview, que se muestra en la siguiente imagen, muestra el estado del volumen de los datos, log de repetición, y cifrado de backup con el timestamp del cambio de la última clave raíz. El on/off mostrado para el cockpit de SAP HANA, platform edition, no está disponible para la base de datos de SAP HANA Cloud. Con la app Data Encryption, no encontrarás la capacidad de reciclar claves raíces, crear claves maestras, o gestionar los backups de estos maestros o claves raíces. Similar a la app Backup Catalog, los datos mostrados en esta app sólo son con propósitos informativos, destacar la diferencia entre utilizar un servicio gestionado y hacerlo uno mismo.

El cifrado de datos y gestión de datos para sistemas on-premise debe gestionarse apropiadamente para evitar sorpresas si necesitas restaurar backups de la base de datos.

La replicación del sistema y el escalado, los sistemas de host múltiple tienen requerimientos específicos con respecto a la gestión de cifrado de los datos en reposo y los datos en tránsito, que también aplica a otros add-ons y funciones. Más recientemente, un LSS con un sistema de gestión de claves externo (KMS) se introdujo como alternativa a la tecnología de almacenamiento seguro más antiguo en el sistema de archivos (SSFS) ¿Cómo se protegen los datos en tus sistemas on-premise? Una ventaja clara de usar un servicio gestionado es que tus datos, incluyendo backups, siempre están encriptados y completamente gestionados por SAP.

El cockpit de SAP HANA, platform edition, también incluye la app de Network Security Details con información sobre proveedores criptográficos y ajustes para comunicaciones de clientes SQL externos e internos. Para SAP HANA Cloud, esta app se ha eliminado ya que todo este tráfico del network ahora tiene lugar detrás de la infraestructura de seguridad del proveedor del cloud. Aunque conceptualmente aun puedes distinguir entre conexiones externas hechas por la administración del sistema, provisionamiento de datos, clientes de la base de datos usando la interfaz SQL, y clientes web, técnicamente, todos se conectan usando el mismo API endpoint del servicio. En otras palabras, con SAP HANA Cloud, todos los clientes son clientes web que comunica con el servicio exclusivamente usando HTTPS, con todo el tráfico encriptado. A través de las herramientas de administración incluida con el servicio, el cockpit SAP HANA y el explorador de la base de datos SAP HANA, el acceso al servicio es gestionado y seguro. Tu responsabilidad será cuidar de las cuentas de usuario de la base de datos.

Por defecto, todos los accesos de todas las API endpoint a las intancias SAP HANA Cloud son rechazados. Sin embargo, puedes reconfigurar el servicio para permitir direcciones IP específicas o rangos de direcciones. De esta manera, puedes restringir el acceso sólo a las oficinas corporativas o desde hosts específicos usados como recursos remotos. Esta conexión donde se permiten IP específicas puede definirse cuando se crea la instancia o en cualquier momento después desde el cockpit de BTP o con el comando del CLI de Cloud Foundry cf update-service:

cf update-service mi_hana_db -c ‘{“data”:{“whitelistIPs”:[“10.2.3.0/24”, “20.3.4.0/24”]}}’

Cambiar los parámetros del servicio de Cloud Foundry requiere el rol SPACE DEVELOPER pero no requiere ningún privilegio en la base de datos SAP HANA.

Una tercera opción es permitir todas las direcciones IP, pero este ajuste solo se recomienda para sistemas que no contengan datos de usuario, como test o sistemas de formación que se usan con tiempo limitado.

El endpoint consiste en el nombre del host y el puerto HTTPS 443, como se muestra en la cabecera del cockpit de SAP HANA. El siguiente código es un ejemplo de configuración para ODBC, y la siguiente es un ejemplo de configuración para JDBC. Otros clientes que son soportados incluyen Microsoft ADO.NET, Python, y Node.js, todos los que que usan una configuración similar con el endpoint como servidor y con el encriptado habilitado.

[HANADB1]
driver=/usr/dsp/hdbclient/libodbcHDB.so
serverNode=7c7bac9c-aaab-4670-9d18-4024dab63fa7.hana.prod-eu10.hanacloud.ondemand.com:443
encrypt=Yes
DESCRIPTION=SAP HANA Cloud

java -jar ngdbc.jar -u DBADMIN,Secret1! -n7c7bac9c-aaab-4670-9d18-4024dab63fa7.hana.prod-eu10.hanacloud.ondemand.com:443 -o encrypt=true -c "SELECT * FROM SYS.DUMMY"

 

Data Access

El encriptado de datos, en reposo o en tránsito, se centra en el acceso no autorizado de los datos, debes recurrir a la gestión de usuarios y abordar la autenticación y la autorización. Para estas tareas, la app Database Overview incluye una card y una app pra Authentication, más una card User & Role Management con una colección de enlaces. La autentificación usando proveedores externos, por ejemplo, Security Assertion Markup Language (SAML) o JSON Web Token (JWT), se pueden configurar usando las apps Certificate Store y Certificate Collection.

[wp-svg-icons icon=”pencil-2″ wrap=”i”] El cockpit de SAP HANA y el explorador de base de datos SAP HANA no son las únicas herramientas que puedes usar para ejecutar las tareas de administración de usuario para SAP HANA Cloud. Ambas herramientas interactúan con la base de datos SAP HANA usando SQL, y para la automatización y scripting, puedes usar también directamente el terminal interactivo de SAP HANA (HDBSQL) incluido con el cliente SAP HANA o usar cualquier otra herramienta de selecciones SQL (de código abierto). Para diseñar roles, puedes usar SAP Web IDE o el más reciente SAP Business Application Studio. Para entornos de SAP ya existentes, puedes también integrar SAP HANA Cloud con SAP Identity Management y SAP Access Control u otras soluciones de gestión de identidades de terceros.

Authentication

Empecemos con la forma de autentificación de usuario más básica utilizando el mecanismo de contraseña incorporado. Cuando creas un nuevo usuario, como mínimo, debes proporcionar dos parámetros: un nombre de usuario y una contraseña. La contraseña debe adherirse a un conjunto de reglas definidas en la política de contraseña, que puedes gestionar en la app Authentication. Puedes controlar el número mínimo de caracteres y especificar si se requieren letras minúsculas, números y caracteres especiales para gestionar el ciclo de vida del password, ajustes de bloqueos de usuario, y otros ajustes, que son idénticos a SAP HANA, platform edition. También se incluye una lista negra de contraseñas para evitar patrones comunes (como “Qwerty123”) o contraseñas aparentemente complejas pero fácilmente hackeables (como “lq2w3e4r”).  No tiene sentido cerrar la puerta principal con cifrado de datos si se deja la puerta trasera abierta de par en par.

Como complemento o como alternativa el mecanismo de contraseña integrado, también puedes habilitar autentificación SAML y JWT, que se configuran fácilmente usando las apps de SAML Identity Provider y JWT Identity Provider. Sólo necesitarás el ID del proveedor de identidades SAML la URL emisora de JWT, más un certificado con un propósito SAML o JWT asignado. Para estos ítems, puedes usar las apps Certificate Store y Certificate Collection. Estos almacenes de certificados de base de datos reemplazan a los almacenes trust basados en sistema de archivos, llamados entornos de seguridad personal (PSEs), para comunicaciones externas.

[wp-svg-icons icon=”pencil-2″ wrap=”i”] Tanto SAML como JWT permiten single sign-on (SSO), y si prefieres usar un lenguaje de marcas basado en XML o JavaScript Object Notation (JSON) típicamente depende de los estándares usados en tu negocio. SAML está bien establecido, casi dos décadas de antigüedad, y es de hecho el estándar para SSO. JSON remote function calls (RFCs) data desde 2014 y se originó de las redes sociales. Técnicamente, SAML es un protocolo mientras JWT es una especificación para un token, pero deberás irte a la documentación para más detalles de configuración e implementación.

La autentificación de usuario usando Lightweight Directory Protocol (LDAP), Kerberos, SAP logon y tickets de aserción, o certificados X.509 sólo están disponibles para SAP HANA, platform edition, y no se soportan en SAP HANA Cloud.

Users

Para crear usuarios de base de datos, puedes usar la caja de diálogo Create User de la app User Management, que se muestra en la siguiente imagen, o la sentencia CREATE [RESTRICTED] USER correspondiente. Necesitarás una cuenta de usuario de la base de datos antes de que puedas conectarte a la base de datos incluso al delegar la autentificación a proveedores externos SAML o JWT.

Puedes distinguir entre 3 tipos de usuarios: usuarios interactivos, usuarios técnicos, y usuarios restringidos. Usuarios interactivos, también conocidos como usuarios finales (o humanos), se conectan a la base de datos para consultar o manipular datos directamente. Por defecto, estos usuarios tienen el privilegio de crear objetos en su propio schema, que en el caso de SAP HANA pueden visualizarse como una caja (o container, por usar un término más de moda). Un usuario interactivo puede crear tablas y otros objectos como vistas, triggers, o precidimientos en esta caja y dar a otros usuarios el privilegio de consultar esa tabla en particular o usar una función. Este usuario puede dar también a otros usuarios el privilegio de crear sus objetos en su caja, y viceversa. Cuando se borra este usuario, también se borra la caja (aunque la propiedad de los objetos se puede traspasar). Ya que los usuarios interactivos vienen y van, olvidan contraseñas, y pueden cometer errores, no son buenos candidatos para ser propietarios de objetos de base de datos de las aplicaciones ERP, aquí es donde entran los usuarios “técnicos” de base de datos.

Técnicamente, los usuarios técnicos son igual que los usuarios interactivos. No hay ningún checkbox en la caja de diálogo Create User o ninguna cláusula que identifique la sentencia SQL para crear el usuario como tal. La base de datos de SAP HANA viene con un número predefinido de usuarios técnicos. El primer usuario técnico es SYS, que es propietario del catálogo de base de datos y de las vistas de monitorización del sistema. También hay un numero de las cuentas relacionadas como _SYS_AFL, propietario de los objetos AFL; _SYS_DATA_ANONYMIZATION, el propietario de los objetos de anonimización de datos; y _SYS_HDL, para objetos relacionados con SAP HANA Cloud, data lake. Existen muchos otros usuarios técnicos, y vale la pena mencionar también el usuario asociado con el mecanismo de monitorización interna de la base de datos SAP HANA, _SYS_STATISTICS, que agrupa la información del uso de los recursos y las alertas de problemas.

Además de estos usuarios predefinidos, los usuarios técnicos pueden crearse para propósitos específicos de la aplicación o para hacer conexiones a recursos de datos remotos y replicación de datos. HDI hace extensivo el uso de usuarios técnicos de base de datos para dar privilegios y convertir artefactos en tiempo de diseño a catálogos de la base de datos en tiempo de ejecución.

En algunas arquitecturas de aplicación, sólo interactúa con la base de datos el usuario técnico, con la autentificación y la autorización gestionada por la capa de aplicación. Este enfoque es común para tipos de aplicación “anydb”, que necesitan soportar varias implementaciones de base de datos. Una alternativa es aprovechar la gestión de usuarios de base de datos pero restringir el usuario en sus interacciones con la base de datos. Como muestra la imagen anterior, los radio buttons Creation of Objects in Own Schema y PUBLIC Role dan el privilegio de consultar el catálogo de base de datos y descubrir, por ejemplo, qué tablas están presentes en todas esas cajas. Sólo puedes ver el metadata: para acceder a los datos, necesitarás el privilegio SELECT para el objeto. Da ambos privilegios, y el usuario se convierte en un usuario estándar. Borra los privilegios, y el usuario se convierte en un usuario restringido. Los usuarios restringidos normalmente reciben los privilegios que necesitan a través de roles y sólo se conectan usando HTTPS, aunque también puedes habilitar lo que se llama “acceso ODBC/JDBC”. Un término mejor hubiera sido “acceso SQL”, porque como mencionamos antes, todos los clientes son clientes web. Esta opción tiene que ver con el acceso a base de datos usando ODBC/JDBC de clientes como Python, Node.js, o Java.

Además de usar la app User Management en el cockpit de SAP HANA, también puedes lograr lo mismo usando SQL. Por ejemplo, para deshabilitar la conexión de un usuario al cliente de base de datos, ejecuta la siguiente sentencia en la Consola SQL:

ALTER USER <user_name> DISABLE CLIENT CONNECT

También puedes asignar periodos de validez a usuarios y activarlos/desactivarlos directamente. Los usuarios también pueden desactivarse a si mismos introduciendo contraseñas incorrectas un numero de veces, como se configura en la política de contraseñas. Los estatus, válido, activo y bloqueado son parte de la validación de la autentificación del logon. La imagen anterior muestra cómo puedes buscar el catálogo de usuarios usando estos atributos también. Fíjate en el número de usuarios predefinidos de la base datos. La mayoría de las cuentas están desactivadas, lo que significa que esas cuentas no pueden usarse para conectar a la base de datos.

User Groups

Los grupos de usuario te permite gestionar usuarios relacionados juntos y separar tareas de gestión. Con grupos de usuarios, puedes distinguir usuarios interactivos de usuarios técnicos de la base de datos, por ejemplo, asociar políticas de contraseñas con los grupos de usuarios. Tu política de contraseña, por ejemplo, podría deshabilitar el requerimiento de cambio de contraseña en el primer logon o solicitar un string aleatorio de 40 caracteres como contraseña. También puedes deshabilitar conexiones para grupos de usuario específicas, por ejemplo, durante el mantenimiento, permitiendo así a los usuarios técnicos conectarse mientras los usuarios finales tendrán que esperar. Algunos de los ejemplos de sentencias de grupos de usuario:

ALTER USERGROUP Applications SET PARAMETER 'password_layout' = 'A1a!', 'minimal_password_length' = '40' ENABLE PARAMETER SET 'password policy;'
ALTER USERGROUP Humans DISABLE CLIENT CONNECT;

El cockpit de SAP HANA incluye el wizard Base Setup para ejecutar la configuración recomendada de los grupos de usuario. Para nuestro tenant de base de datos SAP HANA Cloud, este ajuste se ha completado con el grupo de usuario DEFAULT propiedad de SYSTEM y otros grupos de usuarios creados para el HDI  y propiedad del usuario técnico BROKER_PO_USER.

Para crear usuarios, debes tener los privilegios de USER ADMIN o USERGROUP ADMIN. Para las bases de datos SAP HANA Cloud, sólo el usuario SYSTEM tiene privilegios de USER ADMIN, y este usuario es gestionado por SAP.

El usuario DBADMIN es el grupo de usuario administrador del grupo de usuario DEFAULT con el privilegio de crear nuevos grupos usuarios y dar este privilegio a otros. DBADMIN no puede gestionar usuarios fuera de su scope de grupo de usuario, que incluye el usuario SYSTEM (y la concesión de privilegio de USER ADMIN). Esta limitación previene al DBADMIN de hacer cambios al usuario predefinido gestionado por SAP. Como adjudicatario de privilegios de todo el sistema menos uno, el usuario DBADMIN está definido como super usuario. Como el usuario SYSTEM para SAP HANA, platform edition (on-premise), DBADMIN sólo necesita usarse para la gestión de actividades iniciales para ajustar los usuarios y roles necesarios con un scope de privilegios más limitados, después de lo cual DBADMIN debe ser desactivado. Para asegurar que DBADMIN se desactiva, también recomiendo crear una política de auditoría a las sentencias ATER USER.

Puedes deshabilitar DBADMIN por el cockpit de SAP HANA o con la siguiente sentencia SQL:

ALTER USER DBADMIN DEACTIVATE USER NOW;

Authorization

Después de un logon satisfactorio, el sistema validará si el usuario tiene las autorizaciones necesarias para ejecutar la actividad requerida. Aunque se soporta la asignación directa de privilegios a los usuarios, el enfoque recomendado es dar privilegios por roles para permitir un enfoque más estructurado. Puedes crear roles usando la app Role Management en el cockpit de SAP HANA, que se muestra en la siguiente imagen y corresponde a la sentencia CREATE ROLE:

Un rol puede formar parte de otro y puede contener los siguienes tipos de privilegios:

• System privileges
  Los privilegios del sistema controlan lo que un usuario puede hacer en el “sistema” (en este caso, la base de datos), por ejemplo, crear roles con el privilegio de sistema ROLE ADMIN. Los privilegios del sistema normalmente tienen que ver con actividades de administración.
• Object privileges
  Los privilegios de objeto controlan lo que un usuario puede hacer en un objeto, por ejemplo, SELECT en una tabla o EXECUTE en un procedimiento. Cada sentencia SQL tiene un privilegio de objeto diferente, e inicialmente, sólo el propietario del objeto y el propietario del schema donde se encuentra pueden acceder y dar privilegios de objeto a otros usuarios. Como resultado, ni el usuario SYSTEM ni el usuario DBADMIN tendrán acceso a tus datos a menos y hasta que les des permiso explícitamente. Como mencionamos anteriormente, cuando se borra un usuario, sus objetos también se borran así como cualquier privilegio. En otras palabras, cuando creas una tabla en otro schema y das privilegios al usuario DBADMIN para dar acceso a otros usuarios a esa tabla, este acceso será revocado, y el objeto se borra cuando la cuenta de usuario se elimina – por lo que la importancia de usar cuentas de usuarios técnicos para el aprovisionamiento tal y como lo aplica HDI. Para procedimientos, también están los modos DEFINER e INVOKER, que controlan cada vez que se ejecuta una validación de autorización en el creador de un objeto o del usuario que hace una llamada.
• Analitycal privileges
  Los privilegios analíticos se asocian con modelos de información SAP HANA y vistas de cálculos. Permiten una mayor precisión en el control de acceso a nivel de fila, controlando qué dato puede verse por cada usuario que accede a la misma vista. Los privilegios analíticos se crean normalmente como objetos en tiempo de diseño y desplegados con la vista asociada.

[wp-svg-icons icon=”pencil-2″ wrap=”i”] Para crear privilegios como objetos en tiempo de ejecución, usa la siguiente sentencia SQL:

CREATE STRUCTURED PRIVILEGE <privilege_name> FOR <action> on <view_name> <filter_condition>

La condición de filtro puede ser fijada tanto con una cláusula WHERE o generada dinámicamente con la cláusula de la columna CONDITION_PROVIDER como IN (SELECT column FROM table a WHERE SESSION_USER = user_name)

Dato que las vistas se pueden apilar,  la resolución de problemas de autorización puede ser un reto, las vistas del sistema como EFFECTIVE_STRUCTURED_PRIVILEGES y el procedimiento GET_INSUGICIENT_PRIVILEGE_ERROR_DETAILS puede ayudar a la resolución de errores de “privilegios insuficientes”. Este procedimiento también se puede acceder desde la card Insufficient Privilege Details de la app Database Overview en el cockpit de SAP HANA. Para análisis más complejos, usa la app Authorization Dependency Viewer.

Al usar Role Assignment, puedes asignar roles a usuarios o a roles. Al usar Privilege Assignement, puedes asignar y configurar privilegios, incluyendo, por ejemplo, la opción WITH ADMIN, que da el privilegio a otros. El proceso recomendado es mapear roles a tareas específicas combinadas para ejecutar una función en particular (rol de negocio). Como los privilegios analíticos, los roles se crean normalmente como objetos en tiempo de diseño y desplegados juntos con los objetos de la base de datos asociados usando HDI. Como best practice, respeta el principio del menor privilegio y crea funciones con el menor conjunto posible de privilegios para el menor grupo posible de usuarios.

La base de datos SAP HANA Cloud incluye usuarios predefinidos así como roles predefinidos, como se muestra en la imagen anterior. La mayoría de estos usuarios están integrados (sin schemas), y algunos son gestionados por SAP. Ejemplos de roles integrados incluyen PUBLIC, para accesos filtrados de sólo lectura para las vistas del sistema, y MONITORING, para accesos de sólo lectura para vistas del sistema y datos agrupados por el servidor de estadísticas (_SYS_STATISTICS).

Data Masking

El enmascarado de datos es un tipo de objeto de privilegio. Cuando creas una tabla o una vista y añades una cláusula WITH MASK, puedes controlar el acceso a los datos usando una expresión de enmascarado, quizás un enmascarado básico para ocultar el rango inicial de números de una tarjeta de crédito. Procedimientos más complejos pueden usar validaciones de privilegios estructurados. El enamascarado de datos no cambia los datos pero en su lugar controla la visibilidad de los datos: Sólo los usuarios con el objeto de privilegio UNMASKED pueden ver los datos. Los otros verán los datos codificados u ocultos de alguna manera. Sin embargo, estos usuarios no tendrán errores al acceder a los datos.

La siguiente sentencia SQL ilustra el uso de la cláusula WITH MASK:

CREATE VIEW <view_name> (<column_name_list>) AS <subquery> WITH MASK (<column_name> USING '<mask_expression>');

Data Anonymization

La anonimización de datos proporciona un enfoque diferente al enmascarado de datos que está especialmente orientado a la ciencia de los datos, ya que esta capacidad permite el análisis de datos protegiendo la privacidad de los mismos. Por lo tanto, puedes usar los datos para estadísticas o propósitos de machine learning sin ser capaz de ver o hacer deducciones de los datos. La anonimización de datos puede aplicarse a las vistas SQL usando la cláusula WITH ANONYMIZATION y aprovechar los algoritmos como k-anonymity, l-diversity, o algoritmos diferenciales de privacidad. Específico para SAP HANA Cloud es que puedes usar también las vistas de anonimización de datos en datos de recursos remotos.

Las siguientes sentencias muestran el uso de la cláusula WITH ANONMIZATION:

CREATE VIEW EMPLOYEES_ANON AS SELECT ID, SITE, GENDER, AGE, SALARY FROM EMPLYEES WITH ANONYMIZATION (ALGORITHM 'DIFFERENTIAL_PRIVACY' PARAMETERS '' COLUMN ID PARAMETERS '{"is_sequence": true}' COLUMN SALARY PARAMETERS '{"is_sensitive": true, "epsilon": 0.5, "sensitivity": 10000}'

Auditing

La auditoría no cubre la protección al acceso de datos pero te permite rastrear y grabar la actividad en la base de datos. También está disponible una app para auditar, llamada app Auditing. La card muestra la auditoría habilitada, con la base de datos usada como objetivo de la auditoría y con nueve políticas de rastreo de actividades auditadas. Como con el encriptado de datos, la activación/desactivación se ha desactivado de la card, por lo que el encriptado de datos está siempre activo. Ni puedes configurar el objeto de auditoría: Sólo la base de datos está disponible. Un sistema de log Linux no es una opción para la nube, lo que tiene sentido ya que no puedes acceder al sistema operativo subyacente ni a los archivos del sistema.

Se nos avisa de la existencia de una política corta fuegos, que se refiere a una política que no está dirigida. Esta política graba cualquiera de las acciones o a todos los usuarios y normalmente es menos efectiva que una política dirigida. (Cuanto más grande es el pajar, más difícil es encontrar la aguja.) Las políticas corta fuegos pueden también impactar en la ejecución. Cuando abres la app Auditing, como se muestra en la siguiente imagen, inmediatamente verás el responsable: Todas las acciones que se auditan para el usuario SYSTEM ¿Demasiado? Probablemente, pero esta política de auditoría es configurable, y puedes adaptarla o incluso deshabilitarla completamente. El usuario SYSTEM es auditado por transparencia. Ya que sólo SAP tiene acceso a la cuenta de usuario SYSTEM, deberías al menos estar informado de las actividades del usuario SYSTEM, que es lo que hace exactamente esta política. Auditar todas las acciones del usuario SYSTEM implica una política de retención que borra las entradas mayores a 90 días. En la pestaña Policy Audit Trail, puedes ver la ruta de esta auditoría con todas las entradas de log disponibles.

Las otras políticas de auditoría predefinidas no son configurables y el log de registro en archivo de texto separados por comas (CSV). Las acciones auditadas incluyen logs de OK/KOs; cambios de configuración; licencias; y cambios hechos a los proveedores de autentificación, certificados, y claves de encriptado.

La política de auditoría predefinida cubre las best practices pero no incluirá la semántica de negocio de tu aplicación. En otras palabras, SAP HANA Cloud no tiene conocimiento del significado de los objetos de la base de datos en uso por tu aplicación y cómo tablas, procedimientos, o vistas se mapean a los objetos de negocio (clientes, proveedores, pedidos, facturas). Algunos objetos pueden referenciar a datos muy sensibles mientras que otros simplemente realizan tareas triviales. Para estas acciones, tendrás que añadir tus propias políticas de auditoría. Para crear una política de aditoría selecciona Create Audit Policy y haz click hacia los siguientes pasos del wizard. Cuando hayas guardado la política, puedes pedir también la sentencia SQL correspondiente para propósitos de documentación y automatización.

Certificate Store y Certificate Collections

Volvamos a la app Database Overview con las vistas Security y User Management, donde verás dos enlaces a las apps Certificate Store y Certificate Collections en la card Security Related Links.

Con la app Certificate Store, puedes importar ceritificados como arvhicos en formato base 64 Privacy-Enhanced Mail (PEM) o usando copiar/pegar. El formato PEM es texto plano mientras que otros formatos son binarios.

Con la app Certificate Collections, puedes crear el equivalente de base de datos de un entorno de seguridad personal basado en archivos (PSE), un conjunto de certificados para un propósito específico. La siguiente imagen muestra la app Certificate Collection. Haciendo click en el botón Add Collection, puedes crear nuevos juntos, y con Add Certificate, puedes añadir certificados desde el almacén de certificados. Haciendo click en Edit Purpose, puedes ajustar un propósito seleccionando una de las opciones JWT, SAML, Remote Source, o None (Other).

JWT y SAML pueden usarse para la autentificación de usuario. Los certificados remotos se usan para SAP HANA SDA. Por ejemplo, puedes importar el certificado de Google GTS-CA-101, que se necesita para disponer de un certificado remoto para Google BigQuery.

Recomendaciones y Best Practices

Para ejecutar SAP HANA Cloud de forma segura, como mínimo, asegúrate de incluir los siguientes ítems en tu concepto de seguridad:

• Crear una lista de control de acceso para que puedes restringir el acceso al endpoint de instancia sólo a las direcciones IP conocidas o rango de direcciones.
• Desactivar DBADMIN después de crear usuarios con menos privilegios para tareas administrativas.
• Gestionar políticas de auditoría para actividades relevantes de aplicación, incluyendo al menos una política de auditoria para cambios hechos con el usuario DBADMIN (activar o cambiar la contraseña).
• Crear grupos de usuarios con políticas de contraseña apropiadas.
• Crear roles con privilegios apropiados y luego dar los roles a los usuarios para evitar dar privilegios directamente a los usuarios.
• Reemplazar la autentificación básica con proveedores de identidades basados en certificados como SAML o JWT.