Carlos Rodríguez Morales

¿Será Blockchain una ayuda para la ciberseguridad? Ya hemos hablado de qué es Blockchain y cómo funciona y por qué es importante la inmutabilidad. Potencialmente ayuda a mejorar la ciberseguridad, ya que, como sabemos, la plataforma puede prevenir actividades fraudulentas a través de los mecanismos de consenso que hemos comentado y, obviamente, detectar la manipulación de datos en función de sus características subyacentes de resistencia operativa, cifrado de datos, transparencia e inmutabilidad. Blockchain resuelve el problema de "falta de confianza" entre las contrapartes en un nivel muy básico. Debido a su naturaleza distribuida, las cadenas de bloques no proporcionan una entrada 'hackeable' o un punto central de falla y, por lo tanto, brindan más seguridad en comparación con varias estructuras transaccionales actuales basadas en bases de datos. Se puede confirmar la identidad digital y las actividades en las que participamos online utilizando Blockchain, proporcionando un mayor grado de privacidad para los usuarios de Internet. Obviamente, se reduce la posibilidad de robo de identidad. Actualmente encontramos ciertos problemas: Concentración de datos Direccionamiento basado en host Incapaz de utilizar los beneficios de proximidad de una red La descentralización como solución Blockchain trae consigo multitud de beneficios, los hemos distribuido de la siguiente manera: Descentralización Gracias a la red P2P, no hay necesidad de verificación por parte de terceros,ya que cualquier usuario puede ver las transacciones de la red. Rastreo Todas las transacciones en Blockchain están firmadas digitalmente y con marca de tiempo, por lo que los usuarios de la red pueden rastrear fácilmente el historial de transacciones y rastrear cuentas en cualquier momento histórico. Confidencialidad La confidencialidad de los miembros de la red es alta debido a la criptografía de clave pública que autentica a los usuarios y cifra sus transacciones. Seguridad contra fraudes Técnicamente las cadenas de bloques se consideran "no hackeables", ya que los atacantes pueden impactar una red solo al obtener el control del 51 por ciento de los nodos de la red. Integridad Los bloques cifrados contienen datos inmutables que son resistentes a la modificación no autorizada. Contratos inteligentes La tecnología Blockchain puede aumentar significativamente los estándares de seguridad para contratos inteligentes, ya que minimiza los riesgos de ciberataques y errores. Disponibilidad No es necesario almacenar sus datos confidenciales en un solo lugar, ya que Blockchain permite tener múltiples copias de los datos que siempre están disponibles para los usuarios de la red. Verificación de la validez de las descargas / Actualizaciones de software La cadena de bloques tiene el potencial de asignar hashes únicos a las descargas y actualizaciones. Esto permite a los usuarios comparar el hash en su posible descarga con el hash del desarrollador para reducir significativamente las posibilidades de infectar sus sistemas con malware fraudulento. Claves privadas biométricas/Identidades digitales para reemplazar contraseñas La cadena de bloques no requiere contraseñas porque se basa en datos biométricos o en claves privadas y en la autenticación de varios pasos para garantizar que un usuario sea quien dice ser. Estos sistemas no solo son protectores de nuestra información más efectivos que el nombre de usuario y contraseña, sino que también son más fáciles. DNS más seguro DNS, el sistema de nombres de dominio solo está parcialmente descentralizado, lo que significa que se puede explotar la conexión entre su dirección IP y el sitio para bloquear el sitio. Algunas tácticas comunes incluyen el envenenamiento de la memoria caché del DNS, que hace que los usuarios sean redirigidos a sitios web fraudulentos; ataque por amplificación de DNS, que explota las vulnerabilidades de los sistemas de DNS para amplificar los efectos de un ataque DDoS; y los ataques DDoS en un sistema de nombres de dominio, que sobrecargan un servidor y pueden provocar un cierre completo de un sitio si "tienen éxito". El Blockchain, completamente descentralizado por naturaleza, ha sido empujado como un host para el sistema DNS. Los beneficios de esta propuesta incluyen una seguridad más fuerte y descentralizada que representaría un descanso necesario de un sistema parcialmente centralizado que contiene puntos de acceso únicos de vulnerabilidad. Descentralizar el almacenamiento de datos Almacenar datos en una base de datos centralizada con un único punto de acceso vulnerable es imprudente hoy en día. El Blockchain está descentralizado por naturaleza, lo que significa que no hay un solo punto de penetración para los atacantes. Conclusión Como podemos ver, la tecnología Blockchain se puede utilizar por muchísimas razones en una gran cantidad de industrias. Ayuda a prevenir los ciberataques, las filtraciones de datos, el robo de identidad y garantiza que sus datos sean privados y seguros. Esto es solo el comienzo para Blockchain, a medida que se desarrolle nueva tecnología y los desarrolladores creen nuevas versiones, solo se volverá más inteligente y mejor. Blockchain puede monitorear y predecir ataques con inteligencia artificial y brindar una respuesta proactiva a los ciberataques. 2019 será el año en el que la ciberseguridad y la IA irán de la mano, y en eso Blockchain tienen mucho que decir. Como resumen, Blockchain es un gran avance en la ciberseguridad, ya que puede garantizar el más alto nivel de confidencialidad, disponibilidad y seguridad de los datos. Sin embargo, la complejidad de la tecnología puede causar dificultades con el desarrollo y el uso en el mundo real. Sea lo que sea, pinta emocionante… Más sobre Blockchain y Ciberseguridad: CYBER SECURITY Blockchain y ciberseguridad: una breve aproximación (I) 5 de septiembre de 2019 CYBER SECURITY Blockchain y ciberseguridad: la inmutabilidad (II) 19 de septiembre de 2019

¿Por qué la inmutabilidad del blockchain es importante en la ciberseguridad? La inmutabilidad, la capacidad para que un libro mayor de blockchain permanezca como un historial permanente, indeleble e inalterable de transacciones, es una característica definitiva que blockchain destaca como un beneficio clave. La inmutabilidad tiene el potencial de transformar el proceso de auditoría en un procedimiento rápido, eficiente y rentable, y brindar más confianza e integridad a los datos que las empresas usan y comparten todos los días. Profundicemos en esta afirmación un poco más. Es extremadamente difícil cambiar las transacciones en un blockchain, porque cada bloque está vinculado al bloque anterior al incluir el hash del bloque anterior. Este hash incluye el hash de raíz de Merkle (mas adelante explicamos en que consiste) de todas las transacciones en el bloque anterior. Si una sola transacción fuera a cambiar no solo cambiaría el hash raíz de Merkle, sino también el hash contenido en el bloque modificado. Además, cada bloque subsiguiente debería actualizarse para reflejar este cambio. En la práctica, el árbol de Merkle lo que busca es poder relacionar una serie de datos separados en un único hash (raíz) para reducir el tiempo y recursos empleados en verificar la integridad de una cantidad de información. Esta estructura relaciona todas las transacciones y las agrupa entre pares para obtener un Root Hash o "dirección maestra", la cuál está basada en todos los hashes del árbol. Verificar todas las transacciones de una red sería algo extremadamente lento e ineficiente, por eso se implementó este sistema: si un hash es cambiado, cambiarían todos los demás hasta llegar a la raíz (Root hash). En un Árbol de Merkle los hashes se agrupan en pares en una relación 2n, donde "n", es la cantidad de pares, y no existe un número máximo determinado, pueden ser 2, 4, 8, 16… los límites los establece el tamaño del bloque. De esta forma, validar 10.000 transacciones en la red cuestan lo mismo que validar una única transacción. Cualquier intento de manipulación de una transacción de un bloque validado provocaría un cambio en los hashes propagados, hasta llegar al Root hash. El Root hash no se puede modificar, ya que depende de otras ramificaciones. Si se detecta un intento de cambio, este se invalida automáticamente, lo mismo sucedería si se intentan añadir transacciones. Más sobre blockchain y ciberseguridad: CYBER SECURITY Blockchain y ciberseguridad: una breve aproximación (I) 5 de septiembre de 2019 CYBER SECURITY Blockchain y ciberseguridad (III): la descentralización como solución 10 de octubre de 2019

Blockchain va a cambiar las reglas de la informática de la misma manera que lo hizo el software de código abierto hace años, igual que hizo Linux en el desarrollo de aplicaciones modernas. La duda que se genera es cuánto tiempo va a tardar la tecnología Blockchain en convertirse en un estándar para compartir información entre redes abiertas y privadas. Todo apunta a que esto será así y no tardaremos mucho en llegar a ello. En términos simples, Blockchain no reemplazará la base de datos relacional corporativa, el modelo que todos conocemos, pero creará un nuevo paradigma para los datos transaccionales dentro (y fuera de) las empresas globales, esto si es disruptivo en sí mismo. Conceptualmente, esto es TCP / IP aplicado al mundo de los negocios y las transacciones. En los años 70' y 80', no se podía imaginar que TCP / IP fuera tan robusto y escalable como lo era, ahora sabemos que TCP / IP nos permite toda esta funcionalidad moderna que damos por sentado en la web, y Blockchain tiene el mismo potencial. Por la parte que nos toca, la ciberseguridad aumentará en eficacia debido a la tecnología Blockchain. Técnicamente previene el fraude y debería detectar la manipulación de los datos, los encripta y los hace transparentes y auditables. ¡Genial! Obviamente, todo esto funciona no solo para cifrar los datos y las transacciones que se proporcionan, sino que todo está descentralizado. Los que quieran intentar centralizar o entrar en la cadena de bloques alertarán a todo el sistema, sobre el papel, es una maravilla, ¿no? Un Blockchain es una compilación de registros que se conocen como bloques, estos bloques de registros están protegidos criptográficamente. Los bloques se vinculan entre sí y contienen información de otros bloques, datos de transacciones y timestamps. Cuando se completa un bloque, crea un código seguro único que lo vincula al siguiente bloque. Como una red peer 2 peer, combinada con un servidor timestamp distribuido, los ledgers de cadena de bloques se pueden administrar de forma autónoma para intercambiar información entre partes dispares. No hay necesidad de un administrador, en realidad los usuarios de Blockchain son los administradores. Además, las redes de Blockchain se pueden usar para "contratos inteligentes" o scripts que se ejecutan automáticamente cuando se cumplen ciertas condiciones. Por ejemplo, los usuarios de Ethereum deben cumplir con las condiciones predeterminadas que prueban que alguien posee la criptomoneda y tener la autoridad para enviar el dinero que dicen poseer. Tambien, los usuarios de múltiples Blockchain pueden crear contratos que requieren más de un conjunto de entradas para activar una transacción. Más sobre Blockchain y ciberseguridad: CYBER SECURITY Blockchain y ciberseguridad: la inmutabilidad (II) 19 de septiembre de 2019 CYBER SECURITY Blockchain y ciberseguridad (III): la descentralización como solución 10 de octubre de 2019

Antes de hablar de los algoritmos de cifrados recomendados, por ejemplo, para SQL y Oracle, y los que están en desuso, vamos a explicar los algoritmos de cifrado a utilizar, incidiendo en los tipos de algoritmos simétricos y asimétricos, ya que por ejemplo Oracle soporta los dos tipos. Como veremos mas adelante, el simétrico usa la misma clave para encriptar y desencriptar y ambas están disponibles. El asimétrico, en cambio, usa dos claves, una publica para encriptar y una privada para desencriptar, tanto al hacer login en la BBDD como en la comunicación entre la misma BBDD servidor y cliente. Como hemos dicho, es necesario seleccionar el algoritmo de cifrado adecuado para el caso de uso, como el cifrado, la firma y la validación, utilizando el esquema adecuado. Cifrado simétrico: se utiliza para garantizar la confidencialidad. Los socios de comunicación deben mantener la misma clave para cifrar o descifrar un mensaje. Ejemplos: 3DES y AES. Cifrado asimétrico (o clave pública): se utiliza para garantizar la confidencialidad. En el caso de la transmisión de mensajes, un remitente utiliza la clave pública del destinatario para cifrar el mensaje, mientras que el destinatario utiliza la clave privada correspondiente para el descifrado. El remitente puede acceder a la clave pública del destinatario a través de un directorio de claves de confianza. Ejemplos: RSA y ECIES. MAC (Código de autenticación de mensajes): se utiliza para garantizar la autenticidad y la integridad de los mensajes. Los compañeros de comunicación deben mantener la misma clave. Ejemplos: HMAC y CMAC. Firmas: Para firmar un mensaje, generalmente se asigna una función hash criptográfica para obtener un resumen breve del mismo. El resumen se transforma con la clave privada del firmante para obtener una firma. Cualquier titular de la clave pública del firmante puede verificar si una firma autentica un mensaje bajo la clave privada correspondiente, pero los titulares de la clave pública no pueden generar firmas por sí mismos. Como tal, la firma autentica de forma única el mensaje como originado por el firmante, lo que permite servicios de no repudio. Ejemplos: RSA, y ECDSA. Además, uno debe considerar el tamaño de clave relevante de acuerdo con el modelo de amenaza exacto. Tanto Oracle como SQL recomiendan el uso de AES 128, AES 192 y AES 256, y en desuso, aunque disponibles estarían DES (Data Encryption Estándar), 3DES, 3DES 3KEY, DESX, RC2, RC4, RC4 128… Llegados a este punto, tenemos que hablar de dónde ubicar las claves y cómo protegerlas y administrarlas. Esto daría para otro articulo completo, por lo que vamos a resumir los métodos típicos de administración de claves de cifrado mas utilizados: Cifrado de disco completo Cifrado del sistema de archivos Cifrado de base de datos: Las soluciones para el cifrado de base de datos difieren en la ubicación de las claves de cifrado: HSM Vault CSP KMS Dentro de la base de datos Cifrado a nivel de aplicación: Los desarrolladores de aplicaciones implementan varias metodologías de seguridad, como los HSM; las claves de cifrado rara vez se almacenan dentro de la propia aplicación. Conclusión Los estándares regulatorios actuales, tanto dentro como fuera de la UE, abogan por la encriptación de los datos como método para proteger los mismos y evitar sanciones regulatorias. En este sentido, la recomendación es migrar aplicaciones y BBDD a entornos seguros, tanto de programación como de BBDD (Oracle, Microsoft SQL, etc.), actualizados a las ultimas versiones y con las configuraciones de seguridad correspondientes. Como ya hemos visto, hay muchas maneras de hacerlo con las capas de seguridad apropiadas. Es cierto que en ocasiones el desarrollo ha primado la funcionalidad sobre la seguridad, y este tópico es uno de los que hay que combatir, aunque, por ejemplo, si hablamos de antiguas aplicaciones en 32 bits (que aun corren muchas por ahí), cuantas más capas de seguridad, menos funcionalidad tenían, pero como decía, están o deben estar en desuso, ya que la propia tecnología y el cumplimiento normativo las está dejando fuera. Para visualizarlo mejor, imaginemos un entorno donde nuestra aplicación de gestión corriera en un lenguaje de programación descatalogada por el fabricante y nuestra base de datos se pudiera abrir con un editor de texto cualquiera. Por mucho que cifráramos discos duros y todos nuestros datos, deberíamos dejar fuera la BBDD de dicha encriptación, poniendo en peligro la seguridad de los datos y, por consiguiente, el cumplimiento normativo, exponiendo nuestra organización a duras sanciones, perdida de reputación, etc. Los usuarios de aplicaciones y Bases de Datos obsoletas tienen que estar atento, seguramente no cumplan la norma y sus datos y los de sus clientes pueden estar en peligro. Encriptar, por favor. También te puede interesar: » Las Bases de Datos y el RGPD...¡Vamos a Cifrar! (1/3) » Las Bases de Datos y el RGPD...¡Vamos a Cifrar! (2/3)

Bien, ya nos hemos acercado a la norma y tenemos claro que a nivel regulatorio el cifrado de datos es un “must have”. Ahora vamos a dedicar un momento a saber algo más acerca del cifrado a nivel de archivos, de disco, etc., pero vamos a centrarnos en el cifrado de las BBDD, de aquellas que cumplen la norma y cómo hacerlo. Aun se usan en las empresas aplicaciones de terceros que no soportan el cifrado en sus bases de datos, por lo que la primera recomendación lógica es la siguiente: Consulten a su proveedor por el lenguaje de desarrollo y la base de datos usadas por sus aplicaciones. Seguramente las aplicaciones obsoletas no cumplan el regulamiento normativo, y sus datos y los de sus clientes pueden ser susceptibles a ser atacados por terceros y se estén exponiendo a sanciones legales. Antes de hablar de los enfoques de cifrado, vamos a ver los diferentes estados de los datos digitales y los respectivos métodos de encriptación: Datos en reposo: datos que no se mueven activamente de un dispositivo a otro, o de una red a otra, como los datos almacenados en un disco duro, computadora portátil, unidad flash o archivados / almacenados de alguna otra manera. Para proteger los datos en reposo, las empresas pueden simplemente cifrar archivos confidenciales antes de almacenarlos y/o elegir cifrar la propia unidad de almacenamiento. Datos en movimiento / tránsito: datos que se mueven activamente de una ubicación a otra, como a través de Internet o de una red privada. Para proteger los datos en tránsito, las empresas a menudo eligen cifrar datos confidenciales antes de la transmisión y/o usar conexiones encriptadas (es decir, HTTPS, TLS y FTPS) para proteger el contenido de los datos en tránsito. Datos en uso: datos que se almacenan en una memoria no persistente, generalmente en la memoria de acceso aleatorio (RAM) de la computadora, en el caché de la CPU o en los registros, mientras los equipos informáticos los procesan de forma activa. Los datos en uso son particularmente difíciles de cifrar porque se están procesando activamente y el cifrado puede afectar el rendimiento o hacer que el procesamiento sea imposible. Teniendo esto claro podemos ver los enfoques de cifrado, como os decía, cifrado de disco, de sistema de archivos, de aplicación y el que nos ocupa hoy, de bases de datos desde aqui Enfoques de cifrado Cifrado de disco completo: utiliza software o hardware de cifrado de disco para cifrar cada bit de los datos que van en un disco o dispositivo de almacenamiento (como SAN o NAS) para evitar el acceso no autorizado al almacenamiento de datos. Cifrado del sistema de archivos: es una forma de cifrado de disco donde los archivos o directorios individuales están cifrados por el propio sistema de archivos. Esto contrasta con el cifrado completo del disco donde se encripta toda la partición o el disco en el que reside el sistema de archivos. Esta es la forma de manejar el cifrado de tipos de datos no estructurados, como correos electrónicos, documentos, imágenes y archivos de audio y video. Cifrado a nivel de la aplicación: una solución de seguridad de datos que, a nivel de la aplicación, cifra los datos confidenciales, por lo que solo las partes autorizadas pueden leerlos. Esta solución puede admitir diferentes mecanismos, como el cifrado para preservar el formato (FPE), el cifrado para preservar el orden (OPE) y la tokenización. Por ejemplo, con FPE, un número de tarjeta de crédito de 16 dígitos sigue siendo un número de 16 dígitos después del proceso de cifrado. Este esquema es útil cuando terceros procesan información que necesita ser encriptada, pero la aplicación que la usa debe ser ajena al cambio. Y por ultimo, Cifrado de base de datos: el proceso de conversión de datos, dentro de una base de datos, de formato de texto simple a texto cifrado sin sentido mediante un algoritmo adecuado. El cifrado de la base de datos se puede proporcionar a nivel de archivo o columna. Se han desarrollado varias tecnologías, por ejemplo Transparent Data Encryption (TDE) empleado por Microsoft SQL, IBM DB2 y Oracle DB y MongoDB para cifrar archivos de base de datos, y aunque es seguro, el cifrado se hace en reposo, en el lado del servidor y encripta la base de datos completamente, por lo que es menos funcional, ya veremos mas adelante como se puede utilizar conjuntamente con Always Encrypted de MS SQL, ya que permite el cifrado de datos en reposo y en movimiento, se hace en el lado cliente, sin claves de cifrado en el servidor y permite encriptación por columnas. Para los desarrolladores, la recomendación es .NET 4.6. Como os decía, al cifrar los datos en el lado del cliente, Always Encrypted también protege los datos almacenados en columnas cifradas, en reposo y en tránsito, pero a menos que el objetivo sea proteger los datos confidenciales en uso, TDE es la opción recomendada para el cifrado en reposo, y TLS para proteger los datos en tránsito, de hecho, la recomendación es utilizar conjuntamente Always Encrypted, TDE y TLS: TDE como la primera línea de defensa (y para cumplir con los requisitos de cumplimiento comunes) para cifrar toda la base de datos en reposo. TLS para proteger todo el tráfico a la base de datos. Always Encrypted para proteger datos altamente confidenciales de usuarios de alto privilegio y malware en el entorno de base de datos. También te puede interesar: » Las Bases de Datos y el RGPD...¡Vamos a Cifrar! (1/3) » Las Bases de Datos y el RGPD...¡Vamos a Cifrar! (3/3)

Desde la entrada en vigor del nuevo reglamento europeo de protección dedatos (RGPD), y sobre su famoso articulo 32, concretamente la parte que habla de las medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, mucho se ha dicho y se ha escrito acerca de la obligatoriedad del cifrado de las bases de datos (BBDD), aunque mas allá del debate, es estrictamente recomendable hacerlo ya que la propia RGPD, en su articulo 34, establece la no obligatoriedad de comunicar un incidente de seguridad si los datos están cifrados, que como sabéis, es obligatorio hacerlo en las primeras 72 horas, tanto a la Agencia Española de Protección de Datos (AEPD) como al interesado, recogido en los art. 33 y 34. El responsable y el encargado del tratamiento aplicarán medidas técnicas y organizativas apropiadas para, que en su caso incluya, entre otros: Artículo 33 “La comunicación al interesado a que se refiere el apartado 1 no será necesaria si se cumple alguna de las condiciones siguientes: Artículo 34 En este post quiero hablaros de la propia regulación normativa, ya que el cifrado es un tema complejo, y veremos que hay varios métodos de cifrado y su aplicabilidad a diferentes casos. También, analizaremos los tipos y enfoques de encriptación (parte 2/3), junto con las consideraciones para la gestión clave y el cumplimiento normativo parte 3/3). La normativa El cumplimiento de las normas de privacidad y seguridad es una parte esencial del proceso operativo de una organización. En este caso, la decisión de usar el cifrado es exigida por una o más de las regulaciones a las que está sujetas las empresas. A continuación, revisamos una serie de regulaciones relevantes y cómo se relacionan con el cifrado. RGPD: el Reglamento General de Protección de Datos impone nuevas reglas a las empresas, agencias gubernamentales, organizaciones sin fines de lucro y otras organizaciones, que ofrecen bienes y servicios a personas en la UE, o que recopilan y analizan datos vinculados a los residentes de la UE. Requiere el uso de cifrado de datos, seudonimización y tokenización ,para proteger los datos personales (PII) de los ciudadanos de la UE. El art. 32 antes comentado hace referencia clara y explicita acerca de este tema. PCI-DSS: El Consejo de Estándares de Seguridad de la Industria de Tarjetas de Pago ayuda a los comerciantes e instituciones financieras a comprender e implementar estándares para políticas de seguridad, tecnologías y procesos continuos que protegen sus sistemas de pago contra violaciones y robo de datos de titulares de tarjetas. Los datos del titular de la tarjeta deben ser ilegibles en cualquier lugar donde se almacenen mediante el uso de criptografía sólida (es decir, cifrado de disco) con procesos y procedimientos de administración de claves asociados. Las claves secretas y privadas utilizadas para cifrar / descifrar los datos del titular de la tarjeta deben almacenarse dentro de un dispositivo criptográfico seguro. Se deben usar criptografía fuerte y protocolos de seguridad (es decir, TLS, IPsec y SSH) para proteger los datos confidenciales de los titulares de tarjetas durante la transmisión a través de redes abiertas y públicas. Fuera de la UE, nos encontramos con varios estándares como pueden ser la GLBA, IIROC y FCA. GLBA: La Ley Gramm-Leach-Bliley es una ley federal de los EE. UU. que exige que las instituciones financieras expliquen cómo comparten y protegen la información privada de sus clientes. El cifrado del número de cuenta es uno de los métodos para limitar el intercambio de información del número de cuenta con fines de marketing. IIROC: la Organización Reguladora de la Industria de Inversiones de Canadá es una organización nacional autorregulada que supervisa a todos los operadores de inversión y las actividades comerciales en los mercados de deuda y capital en Canadá. La disposición requiere proteger la información del cliente, que puede incluir el cifrado de dichos datos, protegiendo aún más las claves de cifrado para garantizar la confidencialidad de la información del cliente. FCA: Financial Conduct Authority es un organismo regulador financiero que regula las firmas financieras que prestan servicios a los consumidores y mantiene la integridad de los mercados financieros en el Reino Unido. Exigir el cifrado de los datos del cliente en movimiento, en reposo y respaldado. También te puede interesar: » Las Bases de Datos y el RGPD...¡Vamos a Cifrar! (2/3) » Las Bases de Datos y el RGPD...¡Vamos a Cifrar! (3/3)