Claves útiles - Seguridad y privacidad de datos

Esta guía explica el tema Seguridad y privacidad de datos con contexto práctico. Están relacionadas pero no son intercambiables: seguridad y privacidad de datos responden a preguntas distintas, una sobre el acceso no autorizado y otra sobre qué datos personales se recogen y para qué.

La seguridad y la privacidad están relacionadas, pero no son lo mismo. La seguridad protege los sistemas y los datos contra el acceso no autorizado, el mal uso, las interrupciones y las pérdidas. La privacidad determina si se deben recopilar datos personales, cómo se deben utilizar, quién debe recibirlos y qué opciones tienen las personas.

Un sistema puede ser seguro y aun así violar la privacidad. Una empresa podría cifrar un perfil de comportamiento enorme, restringir el acceso de los empleados y almacenarlo de forma segura. Si la empresa recopiló el perfil sin un propósito válido o lo utilizó para publicidad inesperada, el problema de privacidad persiste.

La diferencia simple

La seguridad pregunta: ¿puede acceder la persona equivocada?

La privacidad pregunta: ¿deberían existir estos datos, debería ocurrir este uso y la persona los entendió o controló?

Ambos importan. La privacidad sin seguridad es frágil porque los datos personales pueden filtrarse. La seguridad sin privacidad puede convertirse en una vigilancia bien protegida.

Ejemplos

Un administrador de contraseñas necesita una seguridad sólida: cifrado, controles de acceso, recuperación segura, registros de auditoría y resistencia al phishing. También necesita privacidad: no debe analizar los sitios web que guardas para publicidad ni vender datos de uso.

Un producto de análisis web necesita seguridad: paneles de control protegidos, transmisión segura de datos, acceso basado en roles, copias de seguridad y respuesta a incidentes. También necesita privacidad: minimización de datos, ausencia de identificadores innecesarios, retención breve, propósitos claros y elección cuidadosa de proveedores.

El portal de un hospital puede ser seguro si sólo el personal autorizado accede a los registros. Aún puede violar la privacidad si los empleados acceden a los registros sin un propósito de tratamiento o si los datos se reutilizan para marketing sin una base legal.

Donde la seguridad respalda la privacidad

Los controles de seguridad son parte del cumplimiento de la privacidad. GDPR El artículo 32 exige una seguridad adecuada del procesamiento, incluidas medidas como seudonimización, cifrado, confidencialidad, integridad, disponibilidad y resiliencia cuando corresponda (GDPR Artículo 32).

Los controles de seguridad comunes que protegen la privacidad incluyen:

• Cifrado en tránsito y en reposo.
• Autenticación fuerte y MFA.
• Acceso con privilegios mínimos.
• Registros de auditoría.
• Gestión de vulnerabilidades.
• Controles seguros de eliminación y retención.
• Respuesta a incidentes.
• Revisión de seguridad de proveedores.

Estos controles reducen la posibilidad de que los datos personales queden expuestos o se utilicen indebidamente.

Donde la privacidad va más allá

La privacidad agrega preguntas que la seguridad no responde:

• ¿Son necesarios los datos?
• ¿El propósito es específico y legítimo?
• ¿Se requiere y es válido el consentimiento?
• ¿Puede la persona acceder, rectificar, suprimir u oponerse?
• ¿Se comparten los datos con terceros?
• ¿Se transfiere internacionalmente?
• ¿Cuánto tiempo se conserva?
• ¿Podría usarse contra la persona más adelante?

La minimización de datos es el puente. Si nunca recopila un atributo confidencial, no necesita protegerlo, eliminarlo, exportarlo ni explicarlo más adelante.

Por qué Analytics es un buen caso de prueba

La analítica tradicional recopila más de lo que los equipos necesitan: cookies, identificadores, detalles del dispositivo, URL completas, datos de campaña y, a veces, ID de usuario. Una implementación segura puede proteger bien esos datos. Una implementación que prioriza la privacidad pregunta si los datos son necesarios.

Para muchos sitios web, el análisis agregado puede responder las preguntas comerciales: cuántas visitas, qué páginas, qué referentes, qué campañas, qué objetivos. Esto se puede hacer sin seguimiento entre sitios ni perfiles publicitarios persistentes. La privacidad mejora el diseño al reducir el modelo de datos antes de que la seguridad tenga que protegerlo.

Un marco práctico

Al evaluar una herramienta, haga preguntas de seguridad y privacidad por separado.

Preguntas de seguridad:

• ¿Es compatible con SSO o MFA?
• ¿Están cifrados los datos?
• ¿Las funciones y permisos son granulares?
• ¿Hay registros disponibles?
• ¿Cuál es el proceso de respuesta a incidentes?
• ¿Se revisan los subprocesadores?

Preguntas sobre privacidad:

• ¿Qué datos personales se recogen?
• ¿Por qué es necesario cada campo?
• ¿Utiliza cookies o identificadores de dispositivo?
• ¿Se comparten datos con fines publicitarios o de elaboración de perfiles?
• ¿Dónde se procesan los datos?
• ¿Cuánto tiempo se conserva?
• ¿Pueden los usuarios ejercer derechos?

Los productos más fuertes tienen ambos. Recopilan menos datos, explican claramente el propósito, protegen lo que queda y hacen posible su eliminación o exportación. La seguridad evita que los datos sean robados. En primer lugar, la privacidad evita que las organizaciones se conviertan en recolectores descuidados.

Dónde los equipos suelen confundirlos

Una respuesta de seguridad común a un problema de privacidad es "la base de datos está cifrada". El cifrado es importante, pero no justifica la recopilación de datos. Otra respuesta común es "sólo los administradores pueden verlo". El control de acceso es bueno, pero no responde si los administradores deberían tener esa visibilidad en primer lugar.

También ocurre el error inverso. Un equipo puede minimizar los datos pero dejar contraseñas débiles, cuentas de administrador compartidas o depósitos de almacenamiento públicos. Las promesas de privacidad colapsan rápidamente cuando la seguridad es deficiente.

Utilice ambas disciplinas durante la revisión del producto. La privacidad debe desafiar el propósito, la necesidad, la retención y el intercambio. La seguridad debe desafiar el acceso, los modelos de amenazas, las vulnerabilidades y la respuesta a incidentes. Cuando ambas revisiones coinciden en que se necesitan menos datos y los datos restantes están bien protegidos, el producto es mucho más potente.

Un ejercicio de revisión rápida

Para cualquier característica nueva, escriba dos columnas breves antes de la implementación. En la columna de seguridad, enumere quién puede atacar el sistema, a qué puede acceder y qué controles reducen ese riesgo. En la columna de privacidad, enumere cada campo de datos personales, el propósito que respalda, el período de retención y las personas o proveedores que pueden recibirlos.

Luego elimine un campo de la columna de privacidad antes de agregar más controles a la columna de seguridad. Ese hábito cambia la conversación. En lugar de pedir a los ingenieros que protejan una pila de datos cada vez mayor, el equipo primero demuestra que los datos pertenecen al producto. El resultado suele ser más barato de construir, más fácil de explicar y más seguro cuando algo sale mal.

Lista de verificación de revisión combinada

Para cada nuevo proveedor o característica, ejecute las revisiones de seguridad y privacidad en paralelo:

• Seguridad: controles de acceso, cifrado, registro, respuesta a incidentes, subprocesadores y manejo de vulnerabilidades.
• Privacidad: campos de datos, finalidad, cookies o identificadores, compartir, retención, derechos de usuario y eliminación.

El mejor resultado no suele ser "recoger todo y asegurarlo". Se trata de "recolectar menos, proteger lo que queda y dejar el propósito lo suficientemente claro como para que los clientes y los equipos internos puedan entenderlo".

Preguntas frecuentes

¿Puede un sistema ser seguro y aun así vulnerar la privacidad?

Una empresa puede cifrar un amplio perfil de comportamiento, restringir el acceso del personal y almacenarlo de forma segura. Esa misma empresa puede vulnerar la privacidad si recopiló ese perfil sin un propósito válido o lo usó para publicidad inesperada. Seguridad y privacidad responden preguntas distintas, así que cumplir una no garantiza la otra.

¿Qué exige el artículo 32 del RGPD?

El artículo 32 del RGPD exige una seguridad adecuada del tratamiento, incluidas medidas como la seudonimización, el cifrado, la confidencialidad, la integridad, la disponibilidad y la resiliencia cuando corresponda. Trata los controles de seguridad como parte del cumplimiento de la privacidad, no como un tema aparte.

¿El cifrado justifica recopilar datos personales?

El cifrado protege los datos del acceso no autorizado, pero no responde si esos datos debían recopilarse en primer lugar. Un equipo puede decir "la base de datos está cifrada" y aun así evitar la pregunta más difícil sobre propósito y necesidad.

¿Qué es la minimización de datos?

Minimizar datos significa nunca recopilar un atributo sensible que no se necesita, de modo que después no haya nada que asegurar, borrar, exportar ni explicar. El artículo la llama el puente entre seguridad y privacidad, porque reduce el modelo de datos antes de que la seguridad tenga que protegerlo.

¿Qué funciones de seguridad necesita un gestor de contraseñas?

Un gestor de contraseñas necesita cifrado, controles de acceso, recuperación segura, registros de auditoría y resistencia al phishing. También necesita privacidad, ya que no debería analizar los sitios web guardados con fines publicitarios ni vender datos de uso.

¿Qué privacidad necesita un producto de analítica web?

Un producto de analítica web necesita minimización de datos, sin identificadores innecesarios, retención breve, propósitos claros y una elección cuidadosa de proveedores. Esto se suma a sus necesidades de seguridad, como paneles protegidos, transmisión de datos segura, acceso basado en roles, copias de seguridad y respuesta a incidentes.

¿Por qué la analítica es un buen caso de prueba para la diferencia entre seguridad y privacidad?

La analítica tradicional recopila más de lo que los equipos necesitan, incluidas cookies, identificadores, detalles del dispositivo, URLs completas, datos de campañas y a veces IDs de usuario. Una implementación segura puede proteger bien esos datos, mientras que una implementación centrada en la privacidad pregunta si esos datos son necesarios, y la analítica agregada suele responder las mismas preguntas de negocio sin rastreo entre sitios.

¿Cuándo puede un portal hospitalario ser seguro y aun así vulnerar la privacidad?

Un portal hospitalario puede ser seguro si solo el personal autorizado accede a los registros. Ese mismo portal vulnera la privacidad si los empleados consultan registros sin un propósito de tratamiento o si los datos se reutilizan para marketing sin base legal. Restringir el acceso responde quién puede llegar a los datos, no si ese acceso o esa reutilización son adecuados.

¿Qué ocurre cuando un equipo minimiza los datos pero descuida la seguridad?

Las promesas de privacidad se derrumban rápido cuando la seguridad es débil. Un equipo puede minimizar los datos que recopila y aun así dejar contraseñas débiles, cuentas de administrador compartidas o buckets de almacenamiento públicos, lo que socava el trabajo de minimización.

¿Qué debería cubrir una revisión combinada de seguridad y privacidad?

Del lado de la seguridad, revisar controles de acceso, cifrado, registros, respuesta a incidentes, subencargados y gestión de vulnerabilidades. Del lado de la privacidad, revisar campos de datos, propósito, cookies o identificadores, compartición, retención, derechos de los usuarios y eliminación.