azure - microsoft - Comportamiento siempre cifrado en SQL Server 2016

porta azure (2)

Estaba haciendo una demostración en SQL Server 2016 para el tema Siempre encriptado. Tengo algunas dudas. A continuación se muestran los pasos seguidos:

En el servidor de base de datos (alojado en la máquina virtual de Microsoft Azure):

En la tabla MyTable , se creó la Clave de cifrado de columna (CEK) y la Clave de cifrado maestro (CMK)
Select * from MyTable , muestra datos encriptados (tanto desde la aplicación como desde el servidor de bases de datos)
Exportado el certificado del servidor de base de datos
Importé el certificado en el Servidor de aplicaciones (mi máquina local)
Column Encryption Setting=Enabled agregada Column Encryption Setting=Enabled para la cadena de conexión de mi aplicación.
Está funcionando bien, ahora muestra los datos de texto sin formato como se esperaba.

Duda:

En Servidor de base de datos (en VM de MS Azure), si un inicio de sesión de SysAdmin (Autenticación de SQL) se conecta a SSMS con el parámetro adicional Column Encryption Setting=Enabled , muestra datos de texto sin formato (esperando datos encriptados). Según entiendo, nadie más que los usuarios de la aplicación deberían ver los datos de texto sin formato ). ¿Alguien puede aclarar?

Una consideración adicional y muy importante:

El objetivo principal de Always Encrypted es proteger sus datos del malware que se ejecuta en la máquina que aloja SQL Server y de usuarios malintencionados de alto privilegio en la máquina que aloja SQL Server (DBA, administradores de sistema). Si estos son los vectores de ataque que desea abordar en su aplicación, nunca debe aprovisionar las claves para Siempre Encriptado en un equipo que aloja una instancia de SQL Server que contiene una base de datos con columnas que desea proteger. Si ejecuta una herramienta de aprovisionamiento de claves, por ejemplo, SSMS o PowerShell, en una máquina que aloja su instancia, y la máquina está en peligro, un atacante puede robar sus claves, por ejemplo, raspando la memoria SSMS. Y, por supuesto, si genera un certificado y lo coloca en el almacén de certificados en la máquina del servidor, es aún más fácil para un atacante obtenerlo.

Consulte https://msdn.microsoft.com/en-us/library/mt708953.aspx#SecurityForKeyManagement para obtener más detalles y pautas útiles.

En el paso 3, menciona que exporta el certificado desde el Servidor de base de datos, para garantizar la máxima seguridad, nunca almacene su certificado en el Servidor de base de datos. El servidor no necesita tener acceso al certificado.

Si un inicio de sesión de SysAdmin (Autenticación de SQL) se conecta a SSMS con el parámetro adicional Configuración de cifrado de columna = Activado, muestra datos de texto sin formato (esperando datos encriptados). Según entiendo, nadie más que los usuarios de la aplicación deberían ver los datos de texto sin formato). ¿Alguien puede aclarar?

Si SysAdmin se está conectando a SSMS desde una máquina cliente que tiene el certificado y si SysAdmin tiene permiso para acceder al certificado, entonces verá los datos de texto sin formato.

A grandes rasgos, Always Encrypted ofrece la siguiente garantía de seguridad. Los datos en texto plano solo serán visibles para las entidades que tengan acceso a ColumnMasterKey (Certificate)

Para elaborar, considere la siguiente situación.

Considere dos máquinas:

MachineA : máquina en la que se está ejecutando SQL Server
MachineT : Máquina del cliente.

Considera dos usuarios

UserA (esto puede ser técnicamente un grupo de usuarios, pero consideraré un escenario con usuario único para simplificar): Quién es un Administrador en MachineA , administrando el servidor SQL y es SysAdmin en el servidor SQL. Sin embargo, userA no tiene ningún tipo de acceso a MachineT y UserA no debería poder descifrar ningún dato cifrado almacenado en SQL Server en la Máquina A (En el contexto de esta respuesta, los datos están encriptados usando la función Always Encrypted de Servidor SQL).
UserT (esto puede ser técnicamente un grupo de usuarios, pero consideraré un escenario con un solo usuario para simplificar): Es un usuario confiable, tiene acceso a MachineT , tiene acceso a todos los datos en la base de datos db que está alojado en SQL Server en MachineA . Además, dado que userT es de confianza, él / ella debería ser capaz de descifrar los datos encriptados.

Considere la posibilidad de que el SQL Server que se ejecuta en MachineA tenga una base de datos db y una tabla t .

Nuestro objetivo es asegurar una columna que pertenezca a la tabla t , digamos ssnCol , de modo que solo el usuario T pueda ver el ssnCol en texto sin formato.

El objetivo descrito anteriormente se puede lograr utilizando los siguientes pasos.

UserT inicia sesión en MachineT .
UserT abre SSMS en MachineT .
UserT se conecta a SQL Server en MachineA
UserT encripta ssnCol en la tabla t usando los pasos mencionados en la sección Encrypt columns (configure Always Encrypted) de este artículo
Después de este paso, la columna ssnCol se cifrará.

Cuando userT encripta ssnCol de la manera descrita anteriormente, se generan dos claves

CMK : la clave maestra de columna de CMK aka es la clave que se utiliza para cifrar CEK / s. Esta clave se almacena en el almacén de certificados de Windows de MachineT .
CEK : la clave de cifrado de columna CEK aka es la clave que se utiliza para cifrar ssnCol , esta clave se almacena en forma cifrada en SQL Server en MachineA y no se conserva en ningún lugar en texto sin formato.

Por lo tanto, para descifrar ssnCol , se requiere CEK, sin embargo, para descifrar CEK, se requiere CMK.

Como CMK está en el almacén de certificados de Windows de machineT , solo el usuario T puede acceder al CMK, descifrar el CEK y descifrar ssnCol .

userA es un administrador en machineA y también un SysAdmin en SQL Server, pero, como no tiene acceso al CMK, userA no puede acceder a ssnCol en texto plano. Puede verificar esto mediante, usando SSMS desde MachineA , iniciando sesión como userA y consultando ssnCol

Si tiene preguntas adicionales, por favor colóquelas en la sección de comentarios y yo las puedo responder.