Seguridad de bases de datos de SQL Server para SAP en Azure

  • Artículo

Este artículo forma parte de la serie de artículos "Ampliación e innovación de la seguridad de SAP: Procedimientos recomendados".

En este artículo se proporcionan consideraciones de seguridad y recomendaciones para SAP en Azure que se ejecuta en una base de datos de SQL Server.

Datos seguros en reposo

El cifrado transparente de datos (TDE) de SQL Server cifra los datos y los archivos de registro de las bases de datos de usuario y las bases de datos de sistema de SQL Server. Una vez cifrado, las copias de los archivos de datos y registro o los archivos de copia de seguridad no se pueden restaurar y usar sin los certificados asociados. Este proceso se denomina protección de datos en reposo. Es una tecnología transparente para el sistema SAP, por lo que es compatible con la nota de SAP 1380493: SQL Server TDE. Para obtener información sobre el procedimiento TDE, consulte cifrado SQL Server.

Todas las páginas de datos que se leen o escriben en el disco deben cifrarse o descifrarse, por lo que TDE tiene una penalización de CPU. Cuando se aplica TDE a una base de datos de usuario, el uso de CPU aumenta entre el 3 % y el 8 %. Las aplicaciones que usan en gran medida TempDB de SQL Server o realizan exámenes grandes en tablas grandes se ven más afectadas. Cuando al menos una base de datos de usuario de la instancia de SQL Server se cifra con TDE, las bases de datos del sistema, como TempDB, también se cifran. SAP Business Warehouse (SAP BW) es un ejemplo de este tipo de aplicación.

Nota

Si se pierden las claves de cifrado o los certificados, se pierden los datos de la base de datos cifrada. Es importante establecer procesos y pasos extensos para proteger las copias de seguridad de certificados.

Una implementación de TDE correcta necesita pruebas correctas y exhaustivas y procesos bien diseñados para controlar certificados y copias de seguridad de certificados.

Características de SQL Server no admitidas

SQL Server también ofrece otras características para la protección de datos. Estos métodos permiten el cifrado parcial o el enmascaramiento en la granularidad de columnas de base de datos:

En función de las restricciones de estos tres métodos y los cambios que requieren en muchas áreas de los componentes de SAP NetWeaver, SAP no admite estas funcionalidades.

No se admite la replicación en tiempo real entre una base de datos habilitada para TDE en SQL Server y SAP HANA. Para más información, consulte la nota de SAP OSS 2812637: la replicación en tiempo real no es compatible con la base de datos MSSQL Server habilitada para TDE.

Cifrado de copia de seguridad

El cifrado de copia de seguridad es cuando se cifra el archivo de copia de seguridad mientras se realiza la copia de seguridad. Cifra todas las páginas de datos del archivo de copia de seguridad y crea un certificado o requisito de clave asimétrica para restaurar el archivo de copia de seguridad, lo que impide una restauración no autorizada.

Si la base de datos no está cifrada con TDE antes de que se realice la copia de seguridad cifrada, todavía no se cifra después de la restauración. Solo los archivos de copia de seguridad se cifran. El archivo de base de datos y su contenido no se modifican.

Puede usar el cifrado de copia de seguridad con TDE, pero no es beneficioso porque los datos ya están cifrados en los archivos de base de datos y en los archivos de copia de seguridad. Cuando se usa el cifrado de copia de seguridad y el TDE juntos, la base de datos cifrada con el certificado TDE o las páginas de datos cifrados con claves se vuelven a cifrar con el certificado o la clave de copia de seguridad. Este método prolonga el proceso de copia de seguridad y agrega una carga adicional de CPU al sistema mientras se ejecuta el proceso de copia de seguridad.

Protección de SQL Server y sistema SAP

La protección de nivel de sistema operativo y servidor es esencial para un sistema en ejecución seguro.

Siga las siguientes recomendaciones para proteger SQL Server y su sistema SAP. Para más información, consulte la nota de SAP OSS 2417205.

SQL Server se basa en la implementación en Windows del protocolo Seguridad de la capa de transporte (TLS) y del protocolo Capa de sockets seguros (SSL) a través de SCHANNEL Security Support Provider (SSP).

Puede deshabilitar el protocolo SSL porque TLS se usa ampliamente y se admite. La mayoría de los SQL Server y la compatibilidad con productos de SAP usan el protocolo TLS 1.2.

Puede controlar la mayor parte de la configuración de seguridad del SCHANNEL SSP a través de los cambios del Registro en la rama SCHANNEL correspondiente. Con esta configuración, puede controlar:

  • Qué protocolos, como SSL y TLS, están habilitados para la parte de cliente y servidor del cuadro de diálogo.
  • Los cifrados, por ejemplo, RC2, RC4, Triple DES y AES, que están habilitados y el orden en que están habilitados.
  • Algoritmos hash, por ejemplo, MD5 y SHA.
  • Los algoritmos de intercambio de claves, por ejemplo, Diffie-Hellman y ECDH.

Las distintas combinaciones de estas partes, como el protocolo, el cifrado y el algoritmo hash y de intercambio de claves, se representan en conjuntos de cifrado. Al deshabilitar una de estas partes, por ejemplo, el protocolo SSL 2.0, todos los conjuntos de cifrado que contienen esta parte no se pueden usar para el sistema.

Nota

Al combinar varios cambios, es posible que el cliente, por ejemplo, el sistema SAP y el servidor, por ejemplo, SQL Server, no puedan usar un conjunto de cifrado para comunicarse y es posible que el sistema SAP no se inicie.

También puede controlar la prioridad y la disponibilidad de los conjuntos de cifrado en el sistema en el editor de directivas de grupo local.

  1. Vaya a Directiva de equipo local > Configuración del equipo > Plantillas administrativas > Configuración de SSL de red >.
  2. Defina un orden personalizado del conjunto de cifrado SSL.

Captura de pantalla que muestra la configuración SSL.

Este orden de lista define la prioridad que el sistema usa conjuntos de cifrado. Si quita un conjunto de cifrado de la lista, ya no se puede usar en el sistema. La configuración de directiva de grupo tiene prioridad sobre la configuración del registro SCHANNEL. Normalmente, el departamento de seguridad controla esta configuración en función de las directivas de grupo. Pero el grupo de administración de bases de datos SAP Basis o SQL Server se encarga de los problemas de conexión resultantes.

Considere la posibilidad de usar la herramienta SAP, SCoTT, para analizar problemas con protocolos deshabilitados o conjuntos de cifrado. La herramienta puede analizar problemas de conexión entre el sistema SAP, como ABAP y Java, y SQL Server que se ejecuta en Linux o Windows. Para más información, consulte la nota de SAP 2846170.

Authentication

Estas son algunas consideraciones para la autenticación con SAP en Azure.

  • SAP NetWeaver en SQL Server tiene requisitos específicos para las cuentas de inicio de SAP y SQL Server, la autenticación en la instancia de SQL Server, la base de datos de SAP y el acceso de DBA. Para más información, consulte la nota de SAP 1645041: inicios de sesión de SQL Server y su uso en entornos de SAP.

  • El sistema SAP ABAP NetWeaver no requiere inicios de sesión de SQL Server porque todas las conexiones usan autenticación de Windows. Por ejemplo, para el usuario SAPService<SID> o <SID>administrator, puede deshabilitar la característica de autenticación de SQL Server.

  • El sistema SAP JAVA NetWeaver requiere la característica de autenticación de SQL Server porque usa un inicio de sesión de SQL Server, como SAP<SID>DB, para la conexión.

  • Para SAP en SQL Server, puede deshabilitar la cuenta de administrador del sistema de SQL Server porque los sistemas SAP de SQL Server no usan la cuenta. Asegúrese de que otro usuario con derechos de administrador del sistema pueda acceder al servidor antes de deshabilitar la cuenta de administrador del sistema original.

  • Un sistema de alta disponibilidad que usa SQL Server AlwaysOn tiene requisitos específicos para inicios de sesión, usuarios y trabajos. Todos los servidores conectados al sistema deben tener exactamente los mismos inicios de sesión y usuarios, por lo que el sistema SAP puede conectarse incluso si se produce una conmutación por error a otro nodo. Todos los trabajos de SQL Server relacionados con SAP deben tener el mismo propietario en todos los nodos AlwaysOn. Para obtener más información, consulte Sincronizar inicios de sesión, trabajos y objetos de SAP.

  • La inyección de código SQL es cuando el código malintencionado se combina en instrucciones SQL que se ejecutan en SQL Server. Cuando un informe se ejecuta en el sistema SAP, genera instrucciones SQL genéricas a partir del código ABAP del informe. Las instrucciones se envían y transforman mediante el nivel de base de datos de SAP para SQL Server.

    Esta capa de base de datos se integra en el proceso de trabajo de SAP y no es accesible desde el exterior. Después de la transformación en instrucciones específicas de SQL Server, se envían a la base de datos y se ejecutan. El resultado se devuelve al informe de llamada. Estas instrucciones solo se pueden manipular entre la capa de base de datos del sistema SAP y la instancia de SQL Server, que se denomina ataque de tipo "Man in the middle".

    En el sistema SAP, use conexiones cifradas entre el proceso de trabajo y la base de datos SQL Server para evitar estos ataques. La transacción DBACockpit tiene una ventana de comandos SQL rudimentaria para ejecutar instrucciones SQL básicas. Para obtener más información, consulte Nota de SAP 1027512: MSSQL: cabina DBA para la versión 7.00 y posteriores.

Auditoría

Pasos siguientes