Aplicación del Cifrado de datos transparente de SQL Server
Hay varios clientes que usan el Cifrado de datos transparente (TDE) de SQL Server al implementar sus bases de datos SQL Server de SAP en Azure. La funcionalidad TDE de SQL Server es totalmente compatible con SAP (consulte la nota de SAP 1380493).
En los casos en que se efectúe una migración heterogénea desde otro DBMS, que se ejecuta en un entorno local, a Windows o SQL Server, que se ejecuta en Azure, se debería crear de antemano una base de datos de destino vacía en SQL Server. Como paso siguiente, aplicaría la funcionalidad TDE de SQL Server, mientras sigue ejecutando el sistema de producción de forma local. El motivo por el que debe realizar el proceso en esta secuencia es que el cifrado de la base de datos vacía puede tardar bastante tiempo. Luego, los procesos de importación SAP importarían los datos a la base de datos cifrada durante la fase de tiempo de inactividad. La sobrecarga de la importación en una base de datos cifrada tiene un impacto menor en el tiempo que el cifrado de la base de datos después de la fase de exportación en la fase de tiempo de inactividad. Hubo experiencias negativas al implementar TDE con una carga de trabajo de SAP ejecutándose sobre la base de datos. Por lo tanto, se recomienda tratar la implementación de TDE como una actividad que debe llevarse a cabo sin ninguna carga de trabajo de SAP en la base de datos.
En casos en los que se mueven bases de datos de SQL Server de SAP desde una ubicación local hasta Azure, se recomienda probar en qué infraestructura se puede aplicar con mayor rapidez el cifrado. Respecto a esto, debe tener en cuenta estos factores:
- No puede definir la cantidad de subprocesos que se usan para aplicar el cifrado de datos a la base de datos. El número de subprocesos depende principalmente del número de volúmenes de disco por los que se distribuyen los datos y los archivos de registro de SQL Server. Esto significa que, cuantos más diferentes sean los volúmenes, más subprocesos se ejecutarán en paralelo para realizar el cifrado. Esta configuración se contradice con una sugerencia sobre la configuración de disco según la cual se crea uno o unos pocos espacios de almacenamiento para los archivos de base de datos de SQL Server en las máquinas virtuales de Azure Virtual Machines. Una configuración con pocos volúmenes daría lugar a pocos subprocesos que ejecutan el cifrado. Un cifrado de un único subproceso lee extensiones de 64 KB, las cifra y, después, escribe un registro en el archivo de registro de transacciones que indica que se ha cifrado la extensión. Como resultado, la carga en el registro de transacciones es moderada.
- En versiones anteriores de SQL Server, la compresión de copia de seguridad ya no implicaba eficacia alguna al cifrar la base de datos de SQL Server. Este comportamiento podría convertirse en un problema si su idea era cifrar la base de datos de SQL Server de forma local y, después, copiar una copia de seguridad en Azure para restaurar la base de datos en Azure. La compresión de copia de seguridad de SQL Server suele generar una razón de compresión de factor 4.
- Con SQL Server 2016, SQL Server introdujo una nueva funcionalidad que también permite comprimir bases de datos cifradas de una forma eficiente.
- Al aplicar el cifrado TDE con una carga de trabajo SAP nula o muy reducida, se debe probar en su configuración específica para determinar si es mejor aplicar TDE a su base de datos SAP localmente o hacerlo en Azure. En Azure sin duda tiene más flexibilidad en términos de exceso de aprovisionamiento de la infraestructura y de reducir la infraestructura una vez aplicado el TDE.
Azure Key Vault
Azure ofrece el servicio de un almacén de claves para almacenar claves de cifrado. Por otro lado, SQL Server ofrece un conector para usar Azure Key Vault como un almacén para los certificados de TDE.