Ley General de Protección de Datos Personales (LGPDP o LGPD) aplicada a las bases de datos SQL Server

Es el acrónimo de Ley General de Protección de Datos, cuyo objetivo es aumentar la privacidad de los datos personales y evitar casos como grandes filtraciones de información y escándalos que involucran precisamente el mal uso de la información personal que venimos siguiendo en los últimos años.

La creación de esta ley coloca a Brasil en la lista de más de 100 países que, hoy, pueden considerarse adecuados para proteger la privacidad y el uso de datos en el escenario global.

El tema movilizó al Congreso principalmente tras la filtración de datos de usuarios de Facebook, una de las mayores redes sociales, recopilados por la empresa Cambrigde Analytica y utilizados en las últimas elecciones en Estados Unidos.

¿Qué son los datos personales?
Según la ley, datos personales son “informaciones relativas a una persona física identificada o identificable” y datos personales sensibles son “datos personales sobre origen racial o étnico, convicciones religiosas, opiniones políticas, afiliación a un sindicato u organización de carácter religioso, filosófico o político, datos relativos a la salud o a la vida sexual, datos genéticos o biométricos, cuando estén vinculados a una persona física”.

Sin embargo, este concepto sigue siendo muy amplio. Los datos personales pueden ser cualquier información que identifique a una persona, como nombre y apellido, nombre de la madre, CPF, DNI, correo electrónico, entre otros. Además, también se consideran datos personales si la información, cruzada con otros datos, permite identificar a una persona. Es decir, el ID de cuenta de una red social, como por ejemplo Facebook, también puede considerarse dato personal.

¿Cuál es el objetivo de la LGDP?
El principal objetivo de la LGPD es garantizar la privacidad de los datos personales (especialmente los sensibles) y obligar a las empresas a utilizar más controles para proteger esta información contra intrusiones, accesos indebidos y filtraciones de datos personales sensibles.

Además, la ley crea reglas claras sobre los procesos de recopilación (el usuario debe aceptar esto), almacenamiento (en ubicaciones seguras y cifradas) y compartir esta información (solo con la autorización del usuario). Este consentimiento deberá prestarse por escrito o por otro medio que demuestre la voluntad del titular y podrá ser revocado en cualquier momento.

Entre sus principios, cobra especial relevancia la transparencia en el uso de los datos personales y la respectiva responsabilidad, la adecuación, es decir, la compatibilidad del uso de los datos personales con los fines señalados, la protección del usuario en toda la arquitectura empresarial (privacidad por diseño), la finalidad, según la cual los datos sólo deben usarse para los fines específicos para los cuales fueron recopilados y previamente informados a sus titulares, y también el principio de necesidad, que significa limitar el uso de los datos al mínimo necesario para lograr el fin. pretendido, de lo que surge la indispensable supresión inmediata de los datos, una vez conseguida esta finalidad.

Delegado de Protección de Datos
Con la LGDP, las organizaciones deben establecer un Comité de Seguridad de la Información para analizar los procedimientos internos y cómo se almacenan, recopilan, protegen y comparten los datos. Dentro de este organismo se sugiere que exista un profesional exclusivo para la protección de datos (Delegado de Protección de Datos), siendo así el responsable de cumplir con esta nueva ley, atender las quejas de los interesados ​​y atender cualquier problema relacionado con la protección de datos.

Controlador, Operador y Responsable
La ley creó los llamados Agentes de Tratamiento de Datos Personales –en la forma de Responsable y Operador–, que pueden ser una persona natural o jurídica, de derecho público o privado. El primero (responsable) es responsable de tomar decisiones respecto del tratamiento de datos personales, mientras que el segundo (operador) es responsable de realizar el tratamiento por cuenta del primero.

También se definió la figura del Responsable, quien también como persona natural o jurídica, de derecho público o privado, actuará como canal de comunicación entre el Responsable y titulares de datos personales y la Autoridad Nacional de Protección de Datos (ANPD).

¿Y qué cambia para los usuarios con esta nueva ley?
Para los usuarios de servicios, ya sea en línea o fuera de línea, el mayor cambio es el acceso a la información sobre sus datos. Cuando la ley ya esté vigente, los ciudadanos podrán conocer cómo las empresas, públicas o privadas, tratan los datos personales:

• cómo se recopilaron los datos
• por qué recopilan tus datos
• cómo se almacenan los datos recopilados
• ¿Cuánto tiempo conservan tus datos?
• con quien comparten

¿Qué cambia para las empresas con esta nueva ley?
Con la nueva Ley General de Protección de Datos de Brasil, todas las pequeñas, medianas y grandes empresas deberán invertir en ciberseguridad e implementar sistemas de cumplimiento eficaces para prevenir, detectar y remediar las violaciones de datos personales, en particular porque la ley establece que la adopción de una política de buenas prácticas se considerará un criterio atenuante para las sanciones.
También se les garantiza el derecho de revocación, portabilidad y rectificación de datos.

Además, las empresas deberán facilitarles la información de los usuarios de forma clara y sencilla, donde muchas ya adoptan esta práctica en sus sitios web, pero a partir de la LGDP será obligatoria y dejará de ser una opción.

Excepciones a la LGDP
Las únicas excepciones a la aplicación de la LGDP son los tratamientos de datos personales realizados por una persona natural con fines exclusivamente privados y no económicos, además de los realizados exclusivamente para (i) fines periodísticos, artísticos o académicos (en este caso no se requiere consentimiento), (ii) seguridad pública, defensa nacional, seguridad del Estado o actividades de investigación y represión por delitos penales o (iii) datos en tránsito, es decir, aquellos que no están destinados a Agentes de Tratamiento en Brasil.

Información de menores
Cuando se trata de un servicio o producto dirigido a niños, el lenguaje debe ser adecuado al grupo de edad, siendo aún más claro y comprensible, pero también dirigido a los padres o tutores – incluso porque se requiere en el artículo 20, inciso 2, el consentimiento de al menos uno de los padres o tutor legal para el tratamiento de datos de niños y adolescentes.

Publicidad dirigida
Con la LGDP, será necesario auditar los modelos de negocio digitales basados ​​en publicidad dirigida. Por ejemplo, si una persona compra una pulsera inteligente que mide el ritmo cardíaco, la finalidad es obtener información sobre su salud. Si la empresa de pulseras decide compartir los datos con una marca de seguros, el propósito del consentimiento entra en conflicto con el interés comercial.

Según la normativa actual, el seguro médico podría ofrecer un plan más caro a un cliente porque sabe que tiene problemas cardíacos, por ejemplo, y con la LGDP esto ya no puede ocurrir sin el consentimiento explícito del usuario.

Subcontratistas (empresas o personas subcontratadas)
La LGPD también se aplica a estos profesionales, como proveedores y socios de tecnología. También están sujetos a obligaciones y pueden realizar pagos de compensación, por ejemplo.

¿Qué pasa si mi empresa no se adapta? ¿Lo que sucede?
La LGDP prevé sanciones para quienes no cumplan con las buenas prácticas. Incluyen amonestaciones, multas y, en el peor de los casos, la prohibición total o parcial de actividades relacionadas con el tratamiento de datos. Las multas pueden oscilar entre el 2% de los ingresos del año anterior de la empresa y hasta 50 millones de reales, incluidas multas diarias.

¿Qué pasa si, aún con todas las protecciones, se producen fugas de datos en la empresa?
La LGPD exige que las empresas recopilen únicamente los datos necesarios para los servicios que prestan. En los casos de filtración de datos, el responsable debe informar al organismo competente y a los interesados ​​(titulares de los datos filtrados), lo que ya es una práctica recomendada en esta situación (incluso antes de la ley), aunque las empresas muchas veces intentan omitir la filtración, agravando aún más la situación.

¿Cuándo entra en vigor esta ley?
Desde la fecha de publicación de la ley (14 de agosto de 2018), las empresas tienen 24 meses para adaptarse a la ley, que será en agosto de 2020.

Las empresas tardarán 24 meses en adaptarse y los principales retos que ya se plantean son:

• nombramiento de una persona a cargo
• realizar una auditoría de datos
• creación de mapas de datos
• revisión de políticas de seguridad
• revisión del contrato
• preparación de un informe de impacto en la privacidad

Un resumen de la LGPD

cortafuegos

Un recurso muy importante para prevenir ataques y accesos no autorizados, el Firewall está disponible en entornos On-Premises (Firewall de Windows y Firewall de terceros) y en entornos de Nube y sirve para evitar el acceso no autorizado a su base de datos.

La idea del Firewall es bloquear el acceso desde IPs que no están en la lista de IPs permitidas, es decir, que los atacantes no puedan obtener ningún tipo de acceso, independientemente de la técnica utilizada, lo que en la práctica es una seguridad muy efectiva contra varios tipos de ataques.

Aunque no es una actividad específicamente del DBA (es más infraestructural), el DBA debe tener conocimiento sobre cómo funciona un Firewall, cómo configurarlo y analizar los logs. Especialmente en entornos Cloud, son comunes los escenarios en los que el DBA acaba “heredando” esta responsabilidad de gestionar las reglas del Firewall de la base de datos.

Cuidado con los ataques de fuerza bruta

Debido a que almacenan prácticamente todos los datos de los clientes y de la empresa en su conjunto, las bases de datos son potencialmente uno de los objetivos más populares para los atacantes que intentan robar información o simplemente obtener acceso privilegiado a esta base de datos para cualquier otro propósito.

Hablando específicamente de SQL Server, existen algunas formas de identificar la ocurrencia de este tipo de ataque y protegerse para que no sea posible intentar iniciar sesión en el banco usando contraseñas incorrectas una y otra vez sin una penalización por hacerlo. Una de estas formas es habilitar el registro de SQL Server para registrar todos los intentos fallidos de inicio de sesión debido a una contraseña incorrecta. ¡Esté atento al registro SQL y busque siempre escenarios en los que haya muchos errores de inicio de sesión!

Para obtener más información sobre los ataques de fuerza bruta en SQL Server y prevenir este tipo de ataque, asegúrese de consultar mi artículo. SQL Server: cómo evitar ataques de fuerza bruta a su base de datos.

Cuidado de permisos

Otro punto muy importante es el relativo a los permisos sobre la base de datos. Usted, como DBA, siempre debe cumplir con la regla del menor acceso posible para todos los usuarios. Olvídese de sysadmin y db_owner, refuerce siempre la seguridad de su entorno otorgando el permiso específico que un usuario necesita para realizar su tarea (y revise los permisos periódicamente). Si un sistema necesita acceso de lectura a 10 tablas y acceso de escritura a 5, este es el acceso que debe otorgar, especialmente para los usuarios de integración.

Un escenario que facilita mucho la fuga de información son las aplicaciones que comparten el mismo servidor de base de datos y todas tienen acceso total a los datos. En caso de cualquier brecha de seguridad en una de estas aplicaciones, el atacante tendrá acceso a todos los datos de todas las aplicaciones en ese servidor de base de datos, aumentando exponencialmente el daño causado por esta invasión.

Algunos artículos que pueden ayudarte a aumentar la seguridad de tu entorno:

• Comprobar los permisos de un usuario en SQL Server
• SQL Server: comprensión de los riesgos de la propiedad CONFIABLE habilitada en una base de datos
• SQL Server: cómo utilizar la auditoría para asignar los permisos reales necesarios a un usuario
• SQL Server – Cómo deshabilitar el inicio de sesión “sa” minimizando los impactos
• SQL Server: cómo ocultar bases de datos a usuarios no autorizados

Cuidado con las contraseñas de los usuarios

Otro tema sumamente importante para prevenir fugas de datos en su empresa es garantizar la seguridad de las contraseñas de los usuarios de la base de datos. Aunque en teoría esto es obvio, en la práctica vemos un gran abandono respecto de este tema.

Aunque Microsoft recomienda el uso de la autenticación de Windows como una buena práctica, ya que todo el control de contraseñas lo maneja Active Directory (AD) o el sistema operativo (OS), en la práctica los usuarios del sistema casi siempre usan la autenticación de SQL Server.

Durante las consultas en la consultora donde trabajo es muy común ver a usuarios del banco que no han cambiado su contraseña desde hace más de 5 años. Es decir, todos los que han tenido acceso a esta contraseña durante este tiempo, aunque ya hayan abandonado la empresa, AÚN CONOCE LA CONTRASEÑA. He visto casos en los que la empresa pasó más de 10 años sin cambiar la contraseña del usuario principal, utilizada por TODAS las aplicaciones e incluso los usuarios empresariales tenían hojas de cálculo de Excel con ese nombre de usuario y contraseña fijos allí... jajaja

Para solucionar este problema de contraseñas antiguas, recomiendo activar la propiedad Expiración para todos los inicios de sesión, de modo que el propio SQL Server se encargue de asignar una fecha de caducidad a la contraseña de los usuarios y los obligue a cambiar su contraseña periódicamente (por defecto es cada 180 días).

Para evitar que las contraseñas de los usuarios de la aplicación caduquen a mitad del día y afecten al medio ambiente, el DBA debe crear un cronograma y un plan para cambiar estas contraseñas periódicamente.

Además de las contraseñas antiguas, debemos prestar atención a la complejidad de las contraseñas. No 123456 en las contraseñas de los usuarios de la base de datos. Las contraseñas deben ser grandes, complejas y difíciles de descifrar mediante ataques de fuerza bruta. Preferiblemente, utilice generadores de contraseñas, que incluyan letras (mayúsculas y minúsculas), números, símbolos y longitudes superiores a 50 caracteres.

¿Necesita ayuda para identificar posibles contraseñas débiles en su SQL Server? Mira cómo puedo ayudarte en el artículo. SQL Server: cómo identificar contraseñas débiles, vacías o iguales al nombre de usuario.

Cifrado de columnas con Always Encrypted

Característica presente desde SQL Server 2016 en las ediciones Express, Standard, Enterprise y Developer (Express y Standard desde 2016 SP1), la Siempre cifrado le permite cifrar ciertas columnas que contienen datos físicamente confidenciales y datos de clientes. A diferencia del Enmascaramiento Dinámico de Datos, esta solución no es un simple enmascaramiento de datos sino más bien una solución de cifrado aplicada a los datos originales, permaneciendo cifrados en la memoria, archivos físicos (MDF, LDF y NDF) y archivos de respaldo.

Una vez que se aplica Always Encrypted, solo los usuarios que tengan la clave de cifrado podrán ver los datos originales. Esta es la única protección que impide que incluso los usuarios administradores de bases de datos (sysadmin) vean los datos originales.

Debido a todas las características de seguridad, esta solución es ideal para garantizar la privacidad de los datos de sus usuarios, ya que los datos siempre están cifrados y nunca se transmiten de forma insegura (texto sin formato), es decir, incluso si una persona que logra acceder a sus archivos de datos (MDF), registro (LDF) o copia de seguridad (BAK), no podrá acceder a los datos cifrados con esta tecnología, incluso si intenta restaurar los archivos para usarlos en otro entorno.

Esto evita un escenario de fuga de información debido al acceso físico a los archivos de la base de datos. Otro factor importante que se evita son las fugas de datos internas, donde los propios empleados aportan información. Al utilizar Always Encrypted, no podrán acceder a estos datos confidenciales incluso con acceso completo a la base de datos.

Y finalmente, esta característica garantizará que otra aplicación que utilice el mismo servidor no pueda ver los datos originales.

Ejemplo siempre cifrado

Para obtener más información sobre Always Encrypted, asegúrese de consultar mi artículo SQL Server 2016: cómo cifrar sus datos utilizando Always Encrypted.

Enmascaramiento de datos (enmascaramiento de datos dinámico)

Característica presente de SQL Server 2016, la Enmascaramiento de datos dinámicos le permite enmascarar datos de ciertas columnas de la base de datos y evitar que las aplicaciones y los usuarios tengan acceso a datos personales y confidenciales del usuario.

Aunque la mejor opción es enmascarar esto en la aplicación (porque el Dynamic Data Masking no es tan seguro), enmascarar los datos en la base de datos es algo muy rápido de implementar y seguramente dificultará el acceso indebido a datos personales, tanto a través de una aplicación como mediante accesos internos realizados por otros usuarios, rutinas o herramientas.

Al aplicar el enmascaramiento de estos datos, estamos evitando que esta información circule tanto fuera de la empresa (en una aplicación, por ejemplo) como dentro de la empresa (un área de BI creando un informe, por ejemplo), ya que estos usuarios no tendrán permiso UNMASK.

Nota: Este enmascaramiento de datos no cambia los datos originales, simplemente los enmascara en la vista (SELECCIONAR).

Ejemplo de enmascaramiento de datos dinámicos

Para obtener más información sobre el enmascaramiento dinámico de datos, asegúrese de consultar mi artículo. SQL Server 2016: enmascaramiento de datos con enmascaramiento de datos dinámico (DDM).

Seguridad a nivel de fila (RLS)

Otra característica importante de SQL Server que puede ayudarnos a reducir la probabilidad de fugas de información es la Seguridad a nivel de fila (RLS), disponible desde SQL Server 2016, que permite limitar los registros que se devolverán según cada usuario. Esto significa que un gestor, por ejemplo, sólo tiene acceso a los datos de los clientes que compran en esa sucursal.

Este tipo de restricción se describe en la LGPD como principio de necesidad, que supone limitar el uso de los datos al mínimo necesario para lograr la finalidad prevista. Si alguien más obtiene acceso a las credenciales del administrador en este ejemplo, el alcance de los clientes a los que tendrá acceso es mucho menor que si tuviera acceso a toda la base.

EXEC('SELECT * FROM dbo.Pedidos') AS USER = 'dirceu.resende'
EXEC('SELECT * FROM dbo.Pedidos') AS USER = 'fabricio.lima'
EXEC('SELECT * FROM dbo.Pedidos') AS USER = 'tiago.neves'
EXEC('SELECT * FROM dbo.Pedidos') AS USER = 'vithor.silva'

-- Consulta utilizando um login sysadmin (Sem personificar outro usuário)
SELECT * FROM dbo.Pedidos

Resultado:

Precauciones con la inyección SQL

No es nuevo que ataques Inyección SQL preocupan a empresas de todo el mundo. Desde los años 90, los atacantes han utilizado esta técnica para invadir sistemas, cambiar y acceder a datos de clientes, pedidos, etc., utilizando agujeros de programación en los sistemas para forzar comandos maliciosos y obtener acceso directo a la base de datos.

Esta técnica tan antigua y sencilla (tanto en ejecución como en corrección) todavía causa muchos problemas incluso en las grandes empresas hoy en día y con la LGPD esto suele suponer un riesgo para la privacidad de los datos de los usuarios, ya que al utilizar SQL Inyección, un atacante puede tener acceso a los datos personales de todos los clientes de la base, si no están correctamente enmascarados/cifrados.

Si quieres cumplir con las auditorías y evitar que tu empresa sufra fugas de datos e intrusiones en el sistema, este es un punto muy crítico que debe ser revisado urgentemente en todos tus sistemas (especialmente si el sistema ensambla dinámicamente las consultas en una cadena, sin validación de entradas y envía la cadena directamente al banco), ya que los efectos de este tipo de ataques pueden ser devastadores.

Después de conversaciones con el experto en seguridad y también con MVP, Alberto Oliveira, me advirtió que para evitar ataques de Inyección SQL en el lado de la aplicación, no basta con validar la entrada de datos y, por lo tanto, se necesitan criterios más precisos a la hora de construir el código, pudiendo incluso contar con un WAF para garantizar la protección más allá del código.

SELECT cpfcnpj, FirstName, [Uid], ID 
FROM dbo.Tabela 
WHERE cpfcnpj = ''; SELECT name, name, name, name FROM sys.tables; --'

Resultado:

Para obtener más información sobre la inyección SQL y cómo identificar posibles lagunas y evitar este tipo de ataque, asegúrese de consultar mi artículo. SQL Server: ¿Cómo evitar la inyección SQL? Deje de usar consultas dinámicas como EXEC (@Query). Ahora..

Descubrimiento y clasificación de datos.

Característica muy interesante que estuvo disponible en SQL Server Management Studio (SSMS) desde la versión 17.5 en adelante, la Descubrimiento y clasificación de datos. (SQL Data Discovery and Classification) te permite generar un informe con posibles datos sensibles identificados mediante un algoritmo SSMS interno, donde defines el nivel de criticidad de esa información y a qué se refiere esa información, de modo que puedas identificar columnas que podrían contener información confidencial o interferir con el cumplimiento de diversos estándares (HIPAA, SOX, PCI y, por supuesto, GDPR).

El asistente utiliza un algoritmo para sugerir columnas que probablemente causen problemas de cumplimiento, pero usted puede agregar las suyas propias, ajustar sus sugerencias y eliminar cualquier columna de la lista. Almacena estas clasicaciones utilizando propiedades extendidas; un informe basado en SSMS utiliza esta misma información para mostrar las columnas que se han identificado. Fuera del informe, estas propiedades no son muy visibles.

En SQL Server 2019, hay un nuevo comando para estos metadatos, ahora disponible en Azure SQL Database, llamado AGREGAR CLASIFICACIÓN DE SENSIBILIDAD. Esto le permite realizar el mismo tipo de asistente que SSMS, pero la información ya no se almacena como una propiedad extendida y cualquier acceso a estos datos se muestra automáticamente en las auditorías en una nueva columna XML llamada data_sensitivity_information. Contiene todo tipo de información a la que se accedió durante el evento auditado.

Cifrado de conexión (TLS)

Otra forma de protegernos ante posibles fugas de información es utilizar cifrado al conectarnos a la base de datos y, para ello, podemos utilizar la función TLS para que los datos transmitidos entre el banco y el cliente no queden disponibles en texto plano.

En particular, las empresas involucradas en el procesamiento de pagos de clientes deben cumplir con el PCI DSS (Estándar de seguridad de datos de la industria de tarjetas de pago). Para cumplir con PCI, la aplicación empresarial debe comenzar a utilizar el protocolo TLS 1.2 (Seguridad de la capa de transporte) antes del 30 de junio de 2018.

Antes de TLS 1.2, existían otras dos versiones 1.1 y 1.0, también conocidas como SSL (Secured Socket Layer), desarrolladas por Netscape. En particular, muchos se referían a TLS 1.1 como SSL V3. La necesidad de pasar al nuevo TLS 1.2 es para abordar las vulnerabilidades planteadas por los protocolos anteriores.

Para mover aplicaciones que utilizan SQL Server al nuevo protocolo, necesitaríamos involucrar a los desarrolladores de aplicaciones junto con los administradores de bases de datos para realizar la transición.

Hay 2 métodos para cifrar conexiones:

• Uso de autocertificación: propenso a ataques MIM (Man-In-Middle) y solo debe usarse en escenarios donde todos los clientes residen en el mismo dominio.
• Certificados CA: son certificados emitidos por la CA y siempre deben ser el método preferido

Para conocer más sobre cómo configurar TLS en tu SQL Server, te recomiendo leer de este artículo.

Protección avanzada contra amenazas de Azure

Una característica realmente interesante de Azure, que cumple con el requisito de notificar a las partes interesadas y a los huérfanos regulatorios sobre las fugas de datos, es la Protección avanzada contra amenazas de Azure, que además de contar con una serie de defensas ante posibles ataques, permite monitorear a los usuarios y su comportamiento.

Azure ATP (Advanced Threat Protection) es una solución de seguridad basada en la nube que identifica, detecta y ayuda a investigar amenazas avanzadas, identidades comprometidas y acciones internas maliciosas dirigidas a su organización. Azure ATP permite a los analistas de SecOp y profesionales de seguridad que luchan por detectar ataques avanzados en entornos híbridos:

• Supervise a los usuarios, el comportamiento de las entidades y las actividades con análisis basados ​​en el aprendizaje
• Proteja las identidades y credenciales de los usuarios almacenadas en Active Directory
• Identifique e investigue actividades sospechosas de usuarios y ataques avanzados a lo largo de la cadena de ciberataques.
• Proporcione información clara sobre incidentes en un cronograma simple para una clasificación rápida

Interfaz ATP de Azure:

Servicios de datos maestros (MDS)

Mantiene datos personales completos y garantiza que las solicitudes para editar, eliminar o interrumpir el procesamiento de datos se propaguen por todo el sistema utilizando el Servicios de datos maestros con Microsoft SQL Server.

Utilizando el concepto de “disco de oro”, la idea de este servicio es garantizar una base única de clientes y sus datos personales, de manera que todos los sistemas utilicen y mantengan siempre actualizada esta base. En caso de solicitud de rectificación o eliminación de datos a petición del cliente, basta con aplicar este cambio en un solo lugar para que se aplique a todos los sistemas y rutinas de la empresa.

Auditoría de datos

Uno de los pilares de la LGPD es que toda actividad que manipule datos personales debe registrarse y su empresa debe responder a la pregunta de cómo se recopilaron los datos de los usuarios. Bueno, para responder a esta pregunta, podemos usar recursos de Auditoría o Activadores para identificar cambios de datos en las tablas y así rastrear cuándo se registraron/cambiaron/eliminaron los datos de un cliente en particular en la base de datos, así como los cambios realizados, el sistema que registró, el nombre de host, la IP y otra información relacionada con el cambio realizado en los datos de este cliente.

Algunos artículos que pueden ayudarte a utilizar estos recursos:

• SQL Server: cómo crear un historial de cambios de datos para sus tablas (registros de auditoría)
• Auditoría en SQL Server (Server Audit)
• SQL Server: cómo monitorear y auditar los cambios de datos en tablas usando Change Data Capture (CDC)
• SQL Server 2016: cómo “viajar en el tiempo” utilizando la función Tablas temporales

Auditoría de datos en Azure SQL Database

Disponible tanto para Azure SQL Database como para Azure SQL Data Warehouse, auditoría de base de datos es una característica de Azure Portal que le permite definir filtros y métricas para auditar diversa información en sus datos y agruparla en categorías de auditoría (LoginFailed, LoginSucess, DataChanges, etc.).

Más información en este enlace.

Cifrado de archivos con cifrado de datos transparente (TDE)

Otra solución de cifrado, disponible desde SQL Server 2008 en las ediciones Enterprise y Developer, Cifrado de datos transparente (TDE) es una característica que cifra archivos de datos de SQL Server, lo que se conoce como cifrado de datos en reposo.

En un escenario en el que se roban medios físicos (como unidades o cintas de respaldo), un tercero malintencionado puede restaurar o adjuntar la base de datos y explorar los datos. Una solución a esto es cifrar datos confidenciales en la base de datos y proteger las claves utilizadas para cifrar los datos con un certificado. Esto evita que alguien sin las claves utilice los datos.

Básicamente, con "un toque de magia", se cifra todo el contenido de los archivos MDF, archivos LDF, instantáneas, tempdb y copias de seguridad. El cifrado se produce en tiempo real a medida que los datos se escriben desde la memoria al disco, y el descifrado se produce cuando los datos se leen del disco y se mueven a la memoria. El cifrado se realiza a nivel de la base de datos, por lo que puede optar por cifrar tantas bases de datos como desee.

Siempre cifrado	Cifrado de datos transparente (TDE)
Nivel de columna	Nivel de base de datos
Cifrado en el cliente (mediante un controlador)	Cifrado del lado del servidor (motor de base de datos)
El servidor no conoce las claves de cifrado	El servidor conoce las claves de cifrado
Los datos en la memoria están cifrados.	Los datos en la memoria no están protegidos (texto sin formato)
Los datos en la red están encriptados.	Los datos en la red no están protegidos (texto sin formato)
Sólo los usuarios con acceso a la clave pueden ver los datos originales. Ni siquiera el DBA puede ver los datos originales sin la clave.	DBA puede ver los datos originales sin la clave
Las copias de seguridad y los archivos de registro están cifrados	Las copias de seguridad y los archivos de registro están cifrados
Requiere cambios en la aplicación (pueden ser pequeños o grandes, según el algoritmo de cifrado elegido)	No requiere cambios en la aplicación.
Disponible a partir de SQL Server 2016: todas las ediciones hasta Express (Express y Standard a partir de 2016 SP1)	Disponible a partir de SQL Server 2008: solo para empresas y desarrolladores

Para obtener más información sobre el cifrado de datos transparente, asegúrese de consultar mi artículo. SQL Server 2008: cómo cifrar sus datos utilizando el cifrado de datos transparente (TDE).

Copias de seguridad cifradas

Siguiendo hablando de cómo almacenar los datos de los clientes, no podemos dejar de mencionar el Cifrado de respaldo, que, como su nombre indica, aplica un algoritmo de cifrado al archivo de respaldo generado, evitando que personas no autorizadas restauren archivos de respaldo en instancias que no tienen un certificado válido y no tienen acceso a los datos originales.

Copia de seguridad en la nube

Otra solución que puede mejorar la seguridad de su empresa es utilizar la TOUR DE RESPALDO, lo que significa que las copias de seguridad de su base de datos se crean directamente en la nube de Microsoft (Azure).

Esto mejora la seguridad de sus datos al evitar que terceros tengan acceso a los archivos de respaldo de la base de datos, ya que los archivos se guardan en la nube y pueden ni siquiera almacenarse en la red de su empresa, la cual puede ser susceptible a intrusiones a través de ataques a la red, acceso físico, fugas de datos por parte de empleados, etc.

Mientras tanto, Azure cuenta con un equipo de seguridad especializado para abordar este problema, incluyendo la redundancia de datos y el bloqueo de cualquier tipo de intento de ataque, además de permitir la autenticación sin contraseña a través de Azure Active Directory.

Banca en la nube

Un tema que es objeto de constante discusión entre los profesionales de TI es el relacionado con el Cloud Computing, pero la gente comienza a despertar sobre lo eficiente y práctico que es migrar y almacenar bases de datos en la nube, y con SQL Server esto no es diferente.

Azure ofrece una gama de características de seguridad para prevenir cualquier tipo de ataque (incluso fuerza bruta) a tus datos, los cuales estarán protegidos por un equipo de expertos en Seguridad de Microsoft, trabajando en la parte física, redes, firewall y también mitigando posibles intentos de invasión de almacenamiento, sistemas operativos y otros.

Todo ello nos permite cumplir con las buenas prácticas de la LGPD, haciendo que nuestros datos sean más difíciles de filtrar y acceder a personas no autorizadas, que acaban bloqueadas por múltiples niveles de seguridad de Azure.