INTRODUCCIÓN
Traducción literal, no automática, realizada por Privacy Driver del catálogo de medidas de seguridad publicado por la Autoridad Danesa de Protección de Datos (DATATILSYNET):
En este catálogo se proponen una serie de medidas técnicas y organizativas que pueden ser necesarias para garantizar una seguridad adecuada a los riesgos que suponga el tratamiento (art. 5.1.f, 24, 25 y 32 RGPD). El análisis de si las medidas son necesarias y adecuadas lo lleva a cabo la organización basándose en una gestión de riesgos, y dependiendo de igual forma de qué otras medidas se hayan adoptado, por lo que este catálogo no supone una lista exhaustiva de medidas.
Los ejemplos utilizados se basan en gran medida en la experiencia de la DATATILSYNET en la supervisión de empresas públicas y privadas, las brechas de seguridad de datos personales notificadas, las directrices del CEPD y las normas ISO 27001 y 27002.
¿QUÉ ES UNA MEDIDA DE SEGURIDAD?
Son las que previenen y/o modifican un riesgo. Pueden ser preventivas, de detección, correctivas o una combinación de estas. El RGPD sólo diferencia entre:
- Medidas técnicas: soluciones informáticas para la gestión de usuarios, cifrado/eliminación automática, control de acceso automático, registro de usos de datos personales, puertas y cerraduras físicas, etc.
- Medidas organizativas: políticas de seguridad, procedimientos para el control de los derechos de acceso, o para retirarlos, distribución de tareas según competencias, formación en el uso correcto de las TI, valoración y evaluación de la eficacia de las medidas técnicas y organizativas.
Pero lo importante no es en qué categoría se puede encuadrar una medida, sino que se hayan adoptado suficientes para garantizar un nivel de seguridad adecuado al tratamiento.
Para que un firewall/cortafuegos sea efectivo, se necesita además de su instalación, configurarse, administrarse y mantenerse actualizado adecuadamente. Por lo tanto, una medida denominada «cortafuegos» constará en realidad de muchas medidas, a menudo una mezcla de algo técnico y algo organizativo. Cada una de estas medidas podría describirse como medidas independientes, pero para evitar confusión se denominan «medidas» en este catálogo.
¿CÓMO SE PRESENTA CADA MEDIDA DE SEGURIDAD EN EL CATÁLOGO?
De cada medida de seguridad se indica:
- ¿Qué riesgos se abordan?
- Qué riesgos se pueden tratar con la medida.
- ¿Qué medidas se pueden considerar?
- Medidas que se pueden valorar para tratar los riesgos.
- ¿Cuándo es necesaria la medida?
- Cuando es preciso adoptar la medida.
MEDIDAS DE SEGURIDAD
- DERECHOS DE ACCESO EN BASE A LAS NECESIDADES DE LAS FUNCIONES DESEMPEÑADAS
1.1. ¿Qué riesgos se abordan?
Si un empleado tiene acceso a un sistema de TI con más derechos de los necesarios para sus funciones, puede representar un riesgo innecesario sobre los datos. Limitar los derechos de acceso (por ejemplo, acceso de lectura sin acceso de escritura) puede evitar errores y usos indebidos. Es por tanto una medida preventiva que puede reducir las consecuencias si el derecho de un usuario se utiliza incorrectamente o se abusa de él.
No suele ocurrir lo mismo con el acceso de un ciudadano/cliente a una solución de autoservicio, ya que las opciones (leer, cambiar, añadir, eliminar datos) generalmente se eligen en función de lo que el usuario de la solución de autoservicio debe poder hacer el mismo, y la responsabilidad del uso incorrecto recae en el propio usuario. Sin embargo, puede haber excepciones a esto, donde no sea apropiado darle al cliente la oportunidad de modificar/eliminar ciertos datos, incluso si se trata de datos personales del propio cliente.
1.2 ¿Qué medidas se pueden considerar?
Los derechos de acceso de los empleados se adaptan a una necesidad relacionada con sus funciones y están limitados, por ejemplo, a las posibilidades de leer, añadir, buscar, cambiar, extraer o eliminar datos.
Si se utiliza una ARP/RPA (Automatización robótica de procesos /Robotic Process Automation) o similar y para ello se conceden derechos de acceso a los usuarios del ARP, su acceso también se restringirá lo más posible. El ahorro económico en licencias de usuario de ARP pueden ser tentadores para otorgarle a un robot tantos derechos de acceso como sea posible, pero un usuario de ARP que tiene muchos derechos puede representar un riesgo mayor si, por ejemplo, un ciberdelincuente tiene la oportunidad de obtener los derechos de acceso de este robot. Al minimizar los derechos de acceso de los usuarios del ARP, también se limita el daño potencial que el usuario puede causar en caso de un error en el código/automatización.
Las opciones para restringir los derechos de acceso suelen depender del diseño de los sistemas informáticos, por lo que hay que tener en cuenta estos aspectos a la hora de diseñar, comprar o actualizar los sistemas informáticos existentes.
Ciertos derechos de acceso pueden dar la oportunidad de causar daños irreparables, por ejemplo, la eliminación, y por lo tanto se conceden al menor número posible de personas y sólo a personas con la cualificación adecuada. Por lo tanto, esta medida debe considerarse en el contexto de la correlación entre competencias de usuario, derechos de acceso y tareas.
1.3. ¿Cuándo es necesaria la medida?
El artículo 5.1.f RGPD trata sobre la integridad y confidencialidad de los datos personales. Cuanto menos pueda hacer el usuario con los datos a los que tiene acceso, menores serán las posibles consecuencias si algunos de estos usuarios realizan acciones no intencionadas o maliciosas o usos injustificados de los datos. Esto también tiene un efecto protector frente a las ciberamenazas, ya que un hacker a menudo opera a través de derechos de acceso a cuentas de usuario comprometidas y, por lo tanto, menos derechos limitan sus opciones. Por lo tanto, los derechos de acceso deben limitarse lo más posible.
Conforme al art.25 RGPD, al desarrollar, adquirir o actualizar un sistema de TI, se debe considerar la protección de datos desde el diseño y por defecto. La opción de limitar/diferenciar los derechos de acceso a los datos requiere que la opción esté integrada en los sistemas de TI que controlan el acceso.
- CONCIENCIACIÓN Y FORMACIÓN
2.1.¿Qué riesgos se abordan?
Concienciación se utiliza como término colectivo para todas las iniciativas orientadas a aumentar la concienciación, sensibilización y el conocimiento de los empleados sobre seguridad. Puede versar sobre lo que los empleados no pueden hacer o sobre lo que deberían hacer. Por lo tanto, normalmente se trata de motivar a los empleados a adoptar un comportamiento con menos riesgo o a cambiar de comportamiento al tratar datos. Es por tanto una medida preventiva que puede reducir la probabilidad de muchos escenarios diferentes que pueden afectar la confidencialidad, integridad o disponibilidad de los datos.
Pueden ser medidas que capaciten a los empleados para detectar mensajes de phishing, en los que un ciberdelincuente intenta robar la información de inicio de sesión del empleado por correo electrónico o SMS. Si los empleados no proporcionan dicha información, no hacen clic en enlaces sospechosos o no abren archivos adjuntos, se puede evitar comprometer el acceso de los usuarios o la red de la organización. La concienciación también puede ser información para los empleados de que todas las acciones en los sistemas de TI se registran para evitar abusos.
Si los empleados aprenden qué hacer para bloquear rápidamente una tarjeta de acceso perdida/robada, la concienciación también puede suponer una medida de detección, deteniendo potencialmente un incidente (tarjeta de acceso perdida/robada) antes de que el incidente afecte el tratamiento de datos personales por parte de la organización (la tarjeta se usa indebidamente para acceder a datos/artículos).
2.2. ¿Qué medidas se pueden considerar?
A continuación se muestra una lista de medidas entre las que elegir, dependiendo de lo que sea importante o relevante en cada organización en particular y en relación con el tratamiento de datos personales.
Varias de las medidas también pueden tener soporte técnico, de modo que los usuarios no puedan evitar hacer lo correcto. Las iniciativas que se basan únicamente en procedimientos que deben recordarse y cumplirse implican inherentemente un riesgo de incumplimiento. A menudo, este riesgo se puede minimizar en gran medida mediante soporte técnico.
- Garantizar el conocimiento de qué acciones se registran, el objetivo del registro y posibles sanciones por abuso de, por ejemplo, derechos de acceso. Esto puede incluir el registro de las acciones del usuario en los sistemas informáticos, pero también el registro del acceso físico a las instalaciones, la videovigilancia, etc.
- Informar a los administradores de usuarios y usuarios sobre lo que pueden hacer con sus respectivos derechos de acceso, por ejemplo:
- Que los usuarios no puedan utilizar los datos para fines distintos a los relacionados con sus funciones.
- Los responsables de otorgar derechos deben centrarse en el acceso limitado (no sólo en la capacidad de los usuarios para resolver tareas), y
- Los administradores de usuarios no deben actuar por sí solos y deben documentar todas las autorizaciones emitidas por los responsables de otorgar derechos.
- Formación sobre la elección de contraseñas, incluido evitar las que también se utilicen de forma privada, ya que pueden estar comprometidos o no ser lo suficientemente seguras.
- Reforzar la información de que las contraseñas, tokens, tarjetas de acceso y otros factores que otorgan acceso son estrictamente intransferibles, confidenciales y personales, y que el usuario es responsable de todas las acciones realizadas durante su inicio de sesión, posiblemente con referencia al registro y las sanciones. Esto puede respaldarse con información sobre procedimientos fijos de muestreo y auditoría.
- Instrucciones sobre cómo deben reaccionar los usuarios en caso de sospecha/conocimiento de que una persona no autorizada ha obtenido acceso/conocimiento de los factores que otorgan el acceso.
- Instrucciones sobre cómo deben reaccionar los usuarios en caso de sospecha/conocimiento de que personas no autorizadas han obtenido medios de acceso como llaves, llaveros, tarjetas de acceso, etc. Incluso si solo hay acceso electrónico a datos personales, esta instrucción puede ser relevante si:
- El medio de acceso proporciona acceso físico a equipos de TI que contienen datos personales, o
- El nivel de seguridad en el acceso electrónico es diferente, dependiendo de dónde se encuentre físicamente (por ejemplo, dentro o fuera del edificio de oficinas de la organización).
- Conocimiento específico sobre cómo se pueden utilizar los datos personales para realizar pruebas en relación con el desarrollo de sistemas informáticos.
- Formación sobre las consecuencias de infringir las normas/legislación sobre confidencialidad y cualquier acuerdo de confidencialidad firmado.
- Conocimiento general de cómo los datos personales pueden y deben tratarse de acuerdo con el RGPD y otra legislación relevante, por ejemplo, siguiendo pautas internas que se hayan elaborado para garantizar la implementación de un sistema de cumplimiento de la normativa. Esto puede referirse al almacenamiento, uso, divulgación, eliminación, transmisión y otros tratamientos. Hay que tener en cuenta que algunos datos personales «básicos» pueden ser confidenciales, por ejemplo, direcciones protegidas.
- Formación específica en el uso de sistemas informáticos específicos, por ejemplo, registro en diario, publicación, registro en diario con publicación automatizada, anonimización, eliminación de metadatos, obligaciones legales, etc. combinado con herramientas que facilitan la realización de las acciones antes mencionadas sin cometer errores.
- Formación dirigida a administradores de usuarios o responsables de seguridad de TI para detectar intentos de abuso interno.
- Formación dirigida a los empleados con acceso a las cuentas bancarias y los sistemas financieros de la organización con respecto al «fraude del director ejecutivo» (también conocido como «fraude del director»), donde los empleados son engañados por alguien que se hace pasar por director. Esto puede posiblemente combinarse con otras reglas comerciales que respalden la aprobación adecuada de pagos y transferencias de moneda.
2.3. ¿Cuándo es necesaria la medida?
Dado que la concienciación puede reducir muchos riesgos muy diferentes, no se puede especificar cuándo es necesaria. La concientización es una medida organizativa (incluida la relacionada con la persona/conductual). Por lo general, constituye un complemento a las amenazas que no pueden gestionarse adecuadamente mediante medidas técnicas (incluidas las físicas). Por lo tanto, la necesidad de concienciación depende de cuánto se puede conseguir de otras formas.
3.1.¿Qué riesgos se abordan?
Un mayor número de accesos de usuarios proporciona una mayor «superficie de ataque» para los actores maliciosos, por tanto, los accesos inactivos suponen un riesgo innecesario. Esta es por lo tanto una medida preventiva que puede reducir la probabilidad que se haga un mal uso del acceso de un usuario (innecesario).
La inactividad es a menudo una señal de que el acceso es innecesario, y los accesos inactivos pueden ser más fácilmente utilizados indebidamente durante un período de tiempo más largo sin que el usuario legítimo lo descubra, porque él mismo no utiliza el acceso.
3.2. ¿Qué medidas se pueden considerar?
Supresión automática de accesos que no se han utilizado durante un periodo de tiempo (por ejemplo 45 días). Cuando la función está integrada en el sistema informático, se selecciona. Alternativamente, se establece un procedimiento manual. Para garantizar una administración uniforme, en la medida de lo posible se gestiona de forma centralizada desde un sistema de gestión de usuarios, en lugar de localmente en los sistemas temáticos individuales.
3.3. ¿Cuándo es necesaria la medida?
Los accesos innecesarios deben suprimirse lo antes posible para minimizar la mencionada «superficie de ataque». Además, un usuario puede optar por utilizar deliberadamente un acceso a intervalos regulares para evitar el cierre automático.
La gestión de riesgos según el artículo 32 RGPD mostrará qué medidas son las que se deben adoptar. Las medidas por sí solas no garantizan que no se produzca el abuso, y el valor de las medidas depende en gran medida de qué más se haga para garantizar la supresión rápida del acceso innecesario.
Conforme al art. 25 RGPD, al desarrollar, adquirir o actualizar un sistema de TI, se debe considerar la protección de datos desde el diseño y por defecto, por tanto la supresión automática requiere que esté integrada en el sistema informático que controla el acceso.
4.1. ¿Qué riesgos se abordan?
La copia de seguridad se puede utilizar para restablecer el acceso a datos que se han vuelto inaccesibles o se han destruido, es por lo tanto una medida correctiva que puede reducir las consecuencias de la destrucción, pérdida o alteración accidental o ilícita de datos. De esta forma la copia de seguridad:
- Convierte la falta de disponibilidad en una pérdida temporal y no permanente.
- Se puede utilizar para corregir la integridad de los datos, si los datos, por ejemplo, están comprometidos por un virus o un ciberdelincuentes.
- Debe asegurar la posibilidad de poder restaurar sistemas completos y, por tanto restaurar sistemas operativos, bases de datos, certificados, claves de cifrado, licencias, configuraciones del sistema (incluidas las configuraciones del firewall), cuya restauración manual es compleja y requiere mucho tiempo.
- Su efecto depende en gran medida del factor tiempo, ¿cuánto tiempo pasa desde la falta de disponibilidad o pérdida de integridad hasta que se pueden restaurar los datos? Si, por ejemplo, solo tiene que pasar un tiempo muy corto sin que los datos estén disponibles antes de que las consecuencias sean máximas, es posible que la copia de seguridad no pueda resolver esto (por sí sola) y que se deban utilizar sistemas de TI duplicados.
- No puede restaurar un sistema de TI tal como estaba exactamente cuando ocurrió un incidente, sino como apareció en algún momento antes del incidente. Por lo tanto, siempre existe un riesgo de pérdida de datos; sin embargo, este riesgo es menor cuando se utilizan datos/ sistemas duplicados.
- Generalmente no incluyen los últimos cambios en los datos, por lo que aún habrá un problema (menor) con la integridad de los datos después de que se utilice una copia de seguridad para restaurarlos y puede incluir datos que hayan sido eliminados del sistema informático y que, por tanto, deberán borrarse nuevamente una vez utilizada la copia de seguridad.
- No debe confundirse con una «copia de datos”, es mucho más y, por lo tanto, también puede proteger contra distintas amenazas. Algunas amenazas (por ejemplo, ransomware) están diseñadas para afectar tanto a los datos del sistema de TI como a la copia de los mismos datos y, por lo tanto, una copia de los datos suele ser sólo una falsa sensación de seguridad.
4.2. ¿Qué medidas se pueden considerar?
Los procedimientos de asignación de acceso garantizan que la misma persona no tenga acceso tanto a los datos de producción como a la copia de estos datos. Cuando esto no se puede evitar, los accesos se comparten, requiriendo diferentes cuentas de usuario para acceder a ellos.
Cuanto más tiempo transcurra entre las copias de seguridad, mayor será la pérdida de datos. El tiempo que transcurre entre cada copia de datos se determina sobre la base de la gestión de riesgos, es decir, una evaluación de cuánto tiempo hace que se debe haber realizado la última copia antes de que las consecuencias puedan ser demasiado graves para los interesados. En una estrategia de copia de seguridad, se especifican los intervalos y el tipo (copias completas/incrementales).
Si la copia de seguridad está automatizada, una alerta garantiza que se detecte si la copia falla.
El hardware y software se deben poder recuperar desde la copia y con rapidez. Esto se aplica, por ejemplo, a servidores físicos, sistemas operativos, software de bases de datos, licencias, claves de cifrado, etc. Alternativamente, garantiza que estos elementos también se encuentren en una copia.
La ubicación física de la copia se determina en base a la gestión de riesgos, es decir, en base a una evaluación de qué amenazas pueden afectar la ubicación física donde se encuentran los datos originales. Si, por ejemplo, existe la posibilidad de que los sistemas informáticos queden destruidos por una inundación, entonces la copia se debe ubicar en un lugar que no pueda verse afectado por las inundaciones.
En lo referente a la ubicación lógica (ubicación de red), la copia de seguridad se debe almacenar en un lugar donde hay un acceso más limitado, ya que solo unos pocos (administradores de TI) necesitan acceso. Las redes que almacenan datos de producción y datos de respaldo no están conectadas a la red, por ejemplo, porque el respaldo lo realiza un proveedor de respaldo. Cuando esto no se puede evitar, las redes se segmentan entre sí mediante cortafuegos, que limitan el acceso a lo absolutamente necesario, por lo que la copia de seguridad está mejor protegida contra ataques de piratas informáticos que pueden afectar a otras partes de la red.
Se debe probar a intervalos regulares si la copia de seguridad se realiza en los intervalos esperados (frecuencia), si la copia de seguridad está disponible, si la copia de seguridad contiene todos los datos necesarias (extensión), si la copia de seguridad es veraz (integridad). Este último puede ser, por ejemplo, un tipo de prueba de integridad (suma de comprobación u otra).
Se deben hacer también pruebas de restauración, si los datos realmente se pueden recuperar y utilizar en un sistema de TI. Esta es una prueba de si la recuperación se puede realizar con guías/procedimientos existentes, (2) que todo lo que tiene copias (hardware, software, datos) puede funcionar en conjunto y (3) que la recuperación puede ocurrir con bastante rapidez en relación con el hecho de que la consecuencia generalmente aumenta con el tiempo (Objetivo de tiempo de recuperación).
Se debe establecer procedimientos para garantizar que los datos que no sean necesarios se eliminen después de utilizar una copia de seguridad, de modo que los datos no se almacenen por más tiempo del necesario.
Se garantiza que el uso de copias de seguridad (y, por tanto, la difusión de datos) no aumente el riesgo para los interesados. Esto se debe a que la transmisión y el almacenamiento de los datos en la copia de seguridad están protegidos contra accesos no autorizados y que el tratamiento de los datos en la copia de seguridad se realiza bajo el control del responsable del tratamiento. Esto se hace a través de acuerdos de tratamiento de datos y cifrando los datos antes de su transferencia y almacenamiento.
4.3. ¿Cuándo es necesaria la medida?
La gestión de riesgos según el artículo 32 RGPD mostrará qué medidas son las que se deben adoptar, ya que los riesgos dependen en gran medida de las consecuencias para los derechos de los interesados, derechos que se ven afectados si sus datos personales dejan de estar disponibles para el responsable.
Si, por ejemplo, se trata de registros de pacientes en un hospital, la falta de disponibilidad puede influir en la posibilidad de que el paciente pueda recibir el tratamiento óptimo; en el peor de los casos, puede tener consecuencias fatales. Si, por el contrario, se trata de un registro de cliente de una tienda online que vende vestidos, presumiblemente las consecuencias para los registrados serán menores o nulas en caso de falta de disponibilidad.
- GESTIÓN DE DERECHOS CENTRALIZADA
5.1. ¿Qué riesgos se abordan?
La gestión descentralizada (o «autónoma») de derechos puede significar que quien la realiza no la tenga como tarea principal. Puede aumentar la posibilidad de errores por falta de experiencia, conocimiento o falta de enfoque en la seguridad al gestionar los derechos.
Si se producen cambios en un entorno de TI sin que se continúe y se pruebe la gestión de derechos, esto puede, entre otras cosas, hacer desaparecer la restricción de acceso correspondiente, de modo que se produzca inmediatamente un acceso no autorizado. La gestión descentralizada de derechos puede implicar una mayor probabilidad de que se pasen por alto condiciones específicas de importancia para dicha gestión cuando se realicen cambios en los entornos de TI, porque sólo una o unas pocas personas son conscientes de las condiciones en cuestión.
Si, por el contrario, la gestión de derechos la lleva a cabo una unidad central que la tiene como tarea principal, es más fácil garantizar el conocimiento necesario y centrarse en la seguridad. Esto evita errores. Por lo tanto, se trata de una medida preventiva que puede reducir la probabilidad de que se establezca o mantenga un acceso innecesario de usuarios.
La gestión centralizada de derechos normalmente también facilitará el control y, por tanto, la implementación de una revisión periódica de estos derechos de acceso.
5.2. ¿Qué medidas se pueden considerar?
Se garantiza una visión general de todos los accesos de los usuarios y una gestión uniforme de los mismos. La tarea se reúne organizativamente con personas que reciben la formación necesaria para realizar esta tarea en particular.
Mediante directrices y/o medidas técnicas se prohíbe/impide la administración descentralizada de usuarios. Por ejemplo, decidiendo que sólo los empleados de la unidad central de administración de usuarios puedan gestionar los derechos de acceso. Una medida técnica puede, por ejemplo, ser un obstáculo técnico para que los empleados puedan crear carpetas con restricciones de acceso en unidades de red o plataformas de intercambio de archivos basadas en web como SharePoint.
La centralización puede incluir una centralización técnica mediante el uso de inicio de sesión único o un servicio de directorio como Active Directory en Windows. Si es posible, debería haber un enlace a sistemas autorizados, por ejemplo, un sistema de recursos humanos que siempre muestre quién está empleado actualmente y en qué puesto/departamento. Si es posible, debería haber un vínculo con una asignación centralizada de derechos a través de, por ejemplo, un sistema IdM.
Cuando la gestión centralizada de derechos no es posible o apropiada, se establecen procedimientos fijos de ejecución, de modo que se sigan principios uniformes.
5.3. ¿Cuándo es necesaria la medida?
La gestión de riesgos según el artículo 32 RGPD mostrará qué medidas son las que se deben adoptar, ya que los riesgos y las oportunidades dependen en gran medida de la organización específica y de los tipos de sistemas informáticos que se utilizan.
Conforme al art. 25 RGPD, al desarrollar, adquirir o actualizar un sistema de TI, se debe considerar la protección de datos desde el diseño y por defecto. Si los sistemas de TI se seleccionan/ diseñan para ser parte de una gestión central de derechos y posiblemente de inicio de sesión único, se puede evitar una gestión descentralizada con los riesgos antes mencionados.
6.1. ¿Qué riesgos se abordan?
Los derechos de acceso deben limitarse al máximo. Cuando un empleado tiene acceso a la información de muchas personas, puede aumentar la tentación de abusar del acceso para fines privados o no relacionados con sus funciones. Al limitar el acceso a los datos para que correspondan a las necesidades relacionadas con sus funciones, se pueden reducir las posibilidades de abuso. Este es por tanto una medida preventiva que puede reducir la probabilidad de uso indebido del acceso de los usuarios, y las consecuencias si se produjese un mal uso.
Lo mismo suele ocurrir con el acceso de un ciudadano/cliente a una solución de autoservicio de una autoridad o de una empresa privada, ya que el acceso a menudo debe limitarse a los propios datos personales del usuario.
6.2. ¿Qué medidas se pueden considerar?
El derecho de acceso a los empleados se otorga según las necesidades relacionadas con sus funciones y puede limitarse, por ejemplo, a la actualidad o antigüedad de los datos, el tipo de datos (por ejemplo, si son datos de clientes, datos de recursos humanos, datos de denunciantes), tipo de caso ( por ejemplo, «casos familiares»), etc.
Los derechos de acceso de los ciudadanos/clientes se adaptan a lo que el individuo tiene derecho a acceder (normalmente sólo sus propios datos personales y posiblemente los de sus familiares cercanos).
Las opciones suelen depender del diseño de los sistemas informáticos, por lo que estos aspectos se tienen en cuenta a la hora de diseñar o comprar sistemas informáticos.
Si se utiliza una ARP/RPA (Automatización robótica de procesos /Robotic Process Automation) o similar y para ello se conceden derechos de acceso a los usuarios del ARP, su acceso también se restringirá lo más posible. El ahorro económico en licencias de usuario de ARP pueden ser tentadores para otorgarle a un robot tantos derechos de acceso como sea posible, pero un usuario de ARP que tiene muchos derechos puede representar un riesgo mayor si, por ejemplo, un ciberdelincuente tiene la oportunidad de obtener los derechos de acceso de este robot. Al minimizar los derechos de acceso de los usuarios del ARP, también se limita el daño potencial que el usuario del puede causar en caso de un error en el código/automatización.
Ver también la medida de seudonimización y anonimización, que también restringe el acceso, pero eliminando o separando datos.
6.3. ¿Cuándo es necesaria la medida?
El artículo 5.1.f RGPD trata sobre la integridad y confidencialidad de los datos personales. Cuanto menos pueda hacer el usuario con los datos a los que tiene acceso, menores serán las posibles consecuencias si algunos de estos usuarios realizan acciones no intencionadas o maliciosas o usos injustificados de los datos. Esto también tiene un efecto protector frente a las ciberamenazas, ya que un hacker a menudo opera a través de derechos de acceso a cuentas de usuario comprometidas y, por lo tanto, menos derechos limitan sus opciones. Por lo tanto, los derechos de acceso deben limitarse lo más posible.
Conforme al art.25 RGPD, al desarrollar, adquirir o actualizar un sistema de TI, se debe considerar la protección de datos desde el diseño y por defecto. La opción de limitar/diferenciar los derechos de acceso a los datos requiere que la opción esté integrada en los sistemas de TI que controlan el acceso. La configuración predeterminada también puede minimizar los derechos como punto de partida, pero también puede tratarse, por ejemplo, de la eliminación automática de datos según su antigüedad, lo que contribuye a minimizar el acceso a los datos.
7.1. ¿Qué riesgos se abordan?
Los administradores de derechos de usuarios tienen la opción de dar a otros, incluso a ellos, acceso a los sistemas de TI, tiene la posibilidad técnica de crear acceso sin seguir los procedimientos o autorizaciones establecidos, por ejemplo para facilitar procedimientos o, en el peor de los casos, para crear una base para abuso. Un control a esto son los requisitos de documentación para la autorización necesaria. Por lo tanto, se trata de una medida preventiva que puede reducir la probabilidad que un usuario administrador cometa errores o abuse de sus derechos de acceso.
7.2. ¿Qué medidas se pueden considerar?
Los procedimientos y/o la tecnología deben estar configurados de manera que los administradores de usuarios se vean obligados a documentar que no han actuado por su cuenta en relación con la emisión de derechos de acceso.
Establecer como requisito (por escrito) que las autorizaciones (aprobaciones de derechos de acceso por parte de los responsables de autorización) sean documentadas por el administrador de usuarios. Esto protege contra la presión de un administrador de usuarios para que emita derechos de acceso sin una autorización documentada; este tipo de presión podría, por ejemplo, provenir de un gerente que está más centrado en optimizar los flujos de trabajo que en la seguridad. El usuario administrador debe conservar la documentación para poder demostrar que se han seguido los procedimientos correctos en la asignación de derechos de acceso.
En la medida de lo posible, se debe crear un obstáculo técnico para que el usuario administrador pueda cambiar la autorización una vez presentada y documentada. Esto protege contra trampas por parte del administrador de usuarios.
Se debe complementar con comprobaciones de si la documentación coincide con los derechos de acceso establecidos. Posiblemente pueda ocurrir como parte de la medida de control periódico de la puntualidad de los derechos de acceso.
7.3. ¿Cuándo es necesaria la medida?
El artículo 5.1.f RGPD establece, entre otras cosas, que los datos personales deben procesarse de manera que se garantice la protección contra el tratamiento no autorizado o ilícito. Cuando las autorizaciones no están documentadas, puede reducirse el sentido de responsabilidad tanto del usuario administrador como del responsable de autorizaciones. Por lo tanto, se puede dar mayor prioridad a hacer que el devenir diario funcione que a realizar correctamente la gestión de derechos.
La gestión de riesgos según el artículo 32 RGPD mostrará qué medidas son las que se deben adoptar, pero considerando el aspecto humano, la documentación de las autorizaciones muy a menudo será relevante.
8.1. ¿Qué riesgos se abordan?
La autenticación multifactor, inicio de sesión multifactor o en inglés MFA (Multi-Factor Authentication), tiene como objetivo reforzar el control sobre quién accede a un sistema informático, de modo que se minimice la probabilidad de acceso no autorizado.
La autenticación implica que una persona verifique su identidad, por ejemplo, proporcionando una contraseña que sólo ella debe conocer. La contraseña es, por tanto, el factor de autenticación en el proceso de inicio de sesión. La MFA requiere que el usuario indique dos o más factores independientes de diferentes categorías para obtener acceso. Dos factores se consideran independientes si no es posible derivar uno de ellos a partir del conocimiento del otro. Las distintas categorías se describen a continuación, y el panorama de riesgo se ve afectado por las categorías seleccionadas para el proceso de inicio de sesión.
También se puede considerar como una medida de detección, los intentos de obtener acceso no autorizado a través del inicio de sesión de un usuario autorizado requerirán múltiples pasos (debido a los múltiples factores en el proceso de inicio de sesión) y pueden brindar una mayor oportunidad de detectar intentos de abuso en progreso (en el primer factor) y antes de que termine en un acceso no autorizado exitoso.
8.2. ¿Qué medidas se pueden considerar?
Los factores deben poder autenticar quién es el usuario, es decir, garantizar que sea el usuario correcto quien inicie sesión. El nombre de usuario, el número de cliente, etc. no pueden considerarse un factor si alguien que no sea el usuario conoce o tiene acceso a esta información. Además, es información de la misma naturaleza y se ingresa de la misma manera que la contraseña, por lo que están expuestas a las mismas amenazas (por ejemplo, escuchas mediante malware o vigilancia física). Por lo tanto, tener que introducir tanto el nombre de usuario como la contraseña no reduce significativamente los riesgos, incluso si ambos fueran conocidos sólo por el propio usuario. Los factores se deben seleccionar de diferentes categorías:
- Algo que el usuario sabe: normalmente, una contraseña personalizada. Debe ser algo que sólo el usuario sepa y que sólo pueda memorizar. Por lo tanto, también suele ser algo que el usuario ha elegido por sí mismo. El factor no debe haber sido accesible en ningún momento ni volverse accesible para otras personas, por lo que debe almacenarse cifrado. El usuario debe poder sustituir este factor si sospecha que otros han tenido conocimiento de él.
- Algo que el usuario tiene: por ejemplo, una tarjeta personalizada con códigos únicos de un solo uso. El factor también puede generarse mediante un software único integrado en el hardware, por ejemplo, códigos únicos de una llave física o un llavero. Debe ser algo que el usuario pueda tener en su posesión física y que pueda guardar completamente para sí mismo. No debe ser algo que deba compartirse con otros. El usuario debe poder reemplazar este factor si sospecha que otros tienen la capacidad de usar una copia.
- Algo que es una característica física del usuario: datos biométricos típicos, como huellas dactilares, escáner de iris, reconocimiento facial, reconocimiento de voz, etc. En comparación con las otras dos categorías, esta tiene un punto débil, es decir, que el usuario rara vez puede conservar el factor ellos mismos o reemplazarlo.
La ventaja de la autenticación multifactor es que puede minimizar riesgos específicos. En primer lugar, se identifican todas las amenazas a las que puede estar expuesto un inicio de sesión específico y luego se seleccionan los factores en función de una evaluación de si afectan (reducen) suficientemente los riesgos específicos. Ejemplo: 1. un empleado debe utilizar contraseñas ingresadas a través de un PC/smartphone. Esto lo puede hacer el empleado en lugares públicos. Una amenaza principal es que la contraseña puede ser interceptada por software malicioso o piratas informáticos que hayan comprometido el PC o el smartphone utilizado. La contraseña también está sujeta a interceptación «mirando por encima del hombro» o mediante cámaras de vigilancia en un lugar público.
Si el segundo factor es un código de un solo uso procedente de un visor de códigos electrónico, éste también puede interceptarse del mismo modo y, por tanto, está expuesto a las mismas amenazas que la contraseña. Sin embargo, si el código que se muestra en el visor de códigos sólo se puede utilizar una vez y en un período de tiempo muy corto (y es probable que el usuario lo utilice inmediatamente), entonces este factor no está expuesto en el mismo grado.
El visor de códigos puede ser robado (amenaza de robo físico), pero la contraseña no queda expuesta de la misma manera si solo la conoce el usuario. Por lo tanto, el usuario no debe escribir el código en un trozo de papel que pueda ser robado junto con el visor de códigos. Es decir, se añade una medida organizativa en forma de directrices para los usuarios sobre cómo gestionar la contraseña y denunciar rápidamente el robo para bloquear el visor de códigos y, posiblemente, el inicio de sesión. También se puede considerar como dos factores si primero se debe forzar una barrera física en un edificio cerrado con una tarjeta de acceso electrónica personalizada («algo que tienes»), combinada con un inicio de sesión en el sistema de TI con una contraseña («algo que sabes «). En este ejemplo, sin embargo, es un poco difícil evaluar los riesgos porque los dos factores están muy separados y pueden gestionarse de manera muy diferente.
El factor único está protegido contra el uso indebido, lo que lo hace más difícil de eludir. Por ejemplo, las funciones de inicio de sesión que utilizan el factor «contraseña» están protegidas contra ataques de fuerza bruta y ataques de diccionario que intentan adivinar/probar el factor. Se puede establecer una protección adicional a través de medidas organizativas en forma de instrucciones a los empleados, por ejemplo, requisitos para elegir y gestionar contraseñas.
La protección contra ataques en los que se engaña al usuario para que entregue los factores que otorgan acceso se denomina MFA resistente al phishing.
Los factores se protegen aún más al abstenerse de transmitirlos por correo electrónico y SMS, porque aquí están expuestos a ser interceptados. En cambio, los factores se pueden generar localmente en un dispositivo.
Finalmente, se garantiza que no haya desvíos para iniciar sesión, lo que realmente socava la solución de autenticación multifactor. Podría ser, por ejemplo, una solución de ayuda para los usuarios que han olvidado su contraseña, lo que en la práctica permite iniciar sesión con un solo factor.
8.3. ¿Cuándo es necesaria la medida?
La gestión de riesgos según el artículo 32 RGPD mostrará qué medidas son las que se deben adoptar, ya que los riesgos y las oportunidades dependen en gran medida de las circunstancias específicas.
Sin embargo, se debe tener en cuenta el artículo 5.1.f RGPD, que establece que los datos personales deben tratarse de manera que se garantice la protección contra el tratamiento no autorizado o ilícito. Al acceder a datos personales especialmente sensibles a través de Internet, puede resultar imposible protegerlos adecuadamente mediante un inicio de sesión con un solo factor. Para el acceso a través de Internet a sistemas informáticos en los que se tratan datos personales sensibles, se debe implementar una autenticación multifactor o algo que aumente correspondientemente el nivel de seguridad.
Además, en el caso de funciones de inicio de sesión a las que no se puede acceder desde Internet, puede considerarse necesaria la autenticación multifactor, por ejemplo, porque se trata de un acceso de administrador, que debe estar particularmente bien protegido contra amenazas que se encuentran (o pueden mover) en las redes internas de la organización.
9.1. ¿Qué riesgos se abordan?
Las tareas realizadas con un derecho de acceso pueden descalificar a la persona para tareas que pueden realizarse con otro derecho de acceso. Por eso en los sistemas administrativos se realiza la separación de funciones, donde se garantiza que un solo empleado no pueda corregir y aprobar una factura de compras propias.
Del mismo modo, una misma persona no debe poder ordenar y autorizar su propio acceso a un sistema informático. Esto se evita estableciendo una separación funcional en tareas y/o derechos de acceso. Se trata, por tanto, de una medida preventiva que puede reducir la probabilidad de que se produzcan diversos tipos de abuso del derecho de acceso.
La separación de funciones existe con una medida que apoya el control mutuo entre las diferentes funciones laborales y así previene el abuso.
9.2. ¿Qué medidas se pueden considerar?
Se establecen procedimientos (si es técnicamente posible) mediante los cuales se garantiza la separación funcional entre usuarios (quienes utilizan el acceso), responsables de la autorización (quienes aprueban el acceso) y administradores de usuarios (quienes crean/eliminan el acceso). También puede haber un cuarto vínculo si, por ejemplo, un empleado de operaciones de TI en la práctica crea/elimina el acceso en nombre del administrador de usuarios.
La separación de funciones se lleva a cabo mediante una clara separación de las tareas laborales y los derechos de acceso, de modo que las tareas/accesos de las personas mencionadas no se superpongan en la medida de lo posible. Por ejemplo, un administrador de usuarios no debe aprobar su propio acceso a un sistema informático y, si esto no puede evitarse técnicamente, debe existir un procedimiento de aprobación que garantice una documentación válida para la aprobación del responsable de autorizaciones. Con procedimientos manuales basados en formularios, puede ser necesario diseñar el formulario de autorización de manera que no pueda manipularse después de que el responsable de autorizaciones haya aprobado el acceso. Se deben establecer normas u obstáculos técnicos para que un responsable de autorizaciones no apruebe cambios en su propio acceso.
Si la opción está incluida en el sistema de TI, los derechos de acceso del administrador del usuario se limitan a permitir únicamente la gestión de derechos en el sistema de TI. Por lo tanto, el usuario administrador no puede él mismo acceder a los datos en el sistema de TI donde controla el acceso de otros.
Al asignar un nuevo acceso en relación con un nuevo empleo o reasignación en la organización, se establecen procedimientos o descripciones que garanticen que no pueda surgir una situación en la que un empleado obtenga acceso a través de la separación de funciones deseada. Posiblemente esté asegurado mediante el formulario utilizado al otorgar derechos de acceso.
Se garantiza que el acceso, que únicamente tiene una finalidad operativa de TI, solo se concede al personal de operaciones de TI con la formación adecuada y, si es posible, también por un tiempo limitado.
La separación de funciones no sólo es relevante entre humanos, sino también entre robots. Si se utiliza una ARP/RPA (Automatización robótica de procesos /Robotic Process Automation) o similar y se otorgan derechos de acceso a los usuarios de robots en ese sentido, puede parecer que la falta de separación de funciones no implica los mismos riesgos que si los mismos derechos se combinaran con una persona. Los ahorros económicos en licencias de usuario de robots pueden resultar tentadores para otorgarle a un robot tantos derechos de acceso como sea posible, pero esto puede representar un riesgo mayor si, por ejemplo, un ciberdelincuente o un desarrollador de software tiene la oportunidad de abusar de los derechos de este robot.
9.3. ¿Cuándo es necesaria la medida?
El artículo 5.1.f RGPD trata sobre la integridad y confidencialidad de los datos personales, y esto normalmente no está suficientemente protegido sin un cierto grado de separación funcional. Sin embargo, la gestión de riesgos del responsable del tratamiento de acuerdo con el artículo 32 RGPD puede indicar que la separación funcional no es necesaria en relación con el tratamiento específico de datos personales.
La posibilidad de implementar esta medida también puede verse limitada por el tamaño de la organización, por lo que no se puede esperar una separación funcional, por ejemplo, en una empresa de dos personas.
10.1. ¿Qué riesgos se abordan?
Un mayor acceso proporciona una mayor «superficie de ataque» para los actores maliciosos. Los accesos que ya no son necesarios suponen, por tanto, un riesgo innecesario y, por tanto, deben suprimirse. Se puede utilizar el conocimiento previo de cuándo un acceso ya no es necesario para garantizar un cierre rápido del acceso. Por lo tanto es una medida preventiva que puede reducir la probabilidad de que un acceso sea utilizado indebidamente por alguien que no sea el usuario previsto (autorizado).
10.2. ¿Qué medidas se pueden considerar?
Si existe la opción, ya se fijará una fecha de caducidad en el derecho de acceso cuando se establezca el mismo. Posiblemente se pueda gestionar de forma centralizada a través de datos de un sistema de recursos humanos con información actualizada sobre las fechas de baja. La fecha de vencimiento puede ser relevante, por ejemplo, a la hora de contratar consultores externos vinculados a un proyecto con una duración clara. Alternativamente, se puede hacer manualmente con recordatorios en una función de calendario.
La medida de fecha de vencimiento también pueden ayudar con la acumulación de tareas relacionadas y las bajas, que puede ocurrir con el cambio de mes o simplemente una acumulación aleatoria de tareas, lo que significa que no hay tiempo para suprimir todos los accesos exactamente cuando termina un empleo.
En organizaciones más grandes, la medida de gestión de derechos centralizada puede evitar la acumulación de tareas e implicar una solución más sistemática de la tarea.
10.3. ¿Cuándo es necesaria la medida?
Se trata de una evaluación de riesgos según el artículo 32 RGPD que mostrará qué medidas son necesarias. Si, por ejemplo, la organización tiene pocos empleados, o si las contrataciones o renuncias son raras, los procedimientos escritos pueden ser suficientes y esta medida no contribuirá significativamente a la seguridad.
Conforme al art.25 RGPD, al desarrollar, adquirir o actualizar un sistema de TI, se debe considerar la protección de datos desde el diseño y por defecto. El cierre automático del acceso requiere que la funcionalidad esté integrada en los sistemas de TI que controlan el acceso.
- REGISTRO DEL USO DE DATOS PERSONALES POR PARTE DE LOS USUARIOS
11.1. ¿Qué riesgos se abordan?
Uno de los objetivos del registro es permitir la investigación de eventos pasados en los sistemas de TI. Por ejemplo, el registro puede mostrar qué acciones han realizado los usuarios en el sistema, pero también qué ha hecho el sistema. En algunos casos, los registros también se pueden utilizar para detectar incidentes en curso y así limitar posiblemente los daños detectando y deteniendo acciones no autorizadas. Si los usuarios son conscientes de que el uso que hacen de los datos personales en los sistemas se registra y analiza, puede ayudar a contrarrestar el uso indebido deliberado, como el espionaje. Ver también las medidas de registros de muestreo del uso de datos personales por parte de los usuarios y formación, dependiendo de las circunstancias, esto es, medida:
- Preventiva que puede reducir la probabilidad de abuso de los derechos de acceso y,
- De detección y correctiva si el registro se utiliza en relación con la detección y parada de un incidente en curso.
11.2. ¿Qué medidas se pueden considerar?
Los sistemas de TI se desarrollan y configuran para registrar todos los usos de los datos personales por parte de los usuarios, es decir la lectura, la edición, la búsqueda, la modificación, la extracción y la eliminación, independientemente de cómo el usuario realice el uso de los datos personales.
Los sistemas de TI están desarrollados para poder almacenar datos de registro durante un período de tiempo específico, por ejemplo, los últimos X meses. Permitir la eliminación automática de registros es importante para el principio de minimización de datos del artículo 5.1.c RGPD.
El tiempo de conservación del registro se establece de acuerdo con su objetivo, por lo que si se va a utilizar un registro para rastrear abusos, puede ser apropiado establecer el tiempo de conservación de acuerdo con la frecuencia con la que se verifican los derechos de acceso. Encontrar errores en estos derechos puede generar la necesidad de revisar los registros durante al menos el período transcurrido desde la verificación anterior, ya que este será el período durante el cual existieron los derechos incorrectos y podrían usarse indebidamente. Sin embargo, la necesidad de investigar ataques cibernéticos puede requerir un tiempo de retención más prolongado, y lo mismo se aplica a los registros que se almacenan en relación con la investigación de un incidente específico o una sospecha de uso indebido.
Los registros se almacenan en un lugar donde están protegidos en términos de confidencialidad, integridad y disponibilidad. Por ejemplo, se puede establecer un servidor de registros que recopile copias de registros de varios sistemas de TI. Los procedimientos garantizan que las personas con acceso privilegiado a estos sistemas de TI no tengan acceso a la copia del servidor de registros. El servidor de registros también está específicamente protegido contra ciberataques que puedan afectar a los sistemas informáticos.
Se garantiza que al responsable del tratamiento le sea posible obtener registros de los encargados del tratamiento sin mayores dificultades ni gastos.
Se debe garantizar una guía accesible sobre cómo interpretar los registros y probar la correcta interpretación utilizando la guía. Esto se puede hacer, por ejemplo, mediante una prueba a ciegas en la que una persona realiza/documenta acciones y otra persona utiliza la guía para interpretar el registro, y luego se comparan las percepciones de las dos personas sobre lo sucedido.
El registro se prueba eficazmente. Si hay varios métodos para ver datos, se prueba que se registren independientemente del método que se utilice.
Se comprueba si se siguen registrando como se esperaba y si los datos de registro se almacenan durante el tiempo suficiente y se pueden interpretar con la guía actual o un sistema de TI asociado. Se trata, por tanto, de una prueba de una medida establecida, conforme al art. 32.1.d RGPD. La verificación se lleva a cabo durante los cambios de sistema como parte de la gestión de cambios, pero también posiblemente entre ellos si transcurre un largo tiempo entre cambios de sistema.
Si es posible, el registro se configura de manera que permita seleccionar muestras del uso de los datos por parte de los usuarios con el fin de verificar el uso con fines laborales. De esta manera, el registro respaldará las comprobaciones aleatorias, de modo que las comprobaciones aleatorias puedan centrarse en usos que puedan violar las directrices internas o equivaler a espionaje.
Para el acceso físico directo a registros con datos personales, el registro en el sistema de acceso físico también debe estar cubierto por las medidas anteriores.
Para que los registros tengan un efecto preventivo y, por tanto, sean una medida preventiva, requiere que se haya informado a los usuarios de que el uso indebido puede detectarse (a través de registros) y sancionarse. También supone que todas las acciones pueden atribuirse a una sola persona física, por lo que también se deben considerar las medidas de evitar el uso innecesario de cuentas multiusuario y concienciación . El registro se activa a más tardar cuando se pone en marcha el sistema TI.
11.3. ¿Cuándo es necesaria la medida?
Es principalmente una gestión de riesgos de conformidad con el art. 32 RGPD la que debe mostrar qué medidas son necesarias, ya que los riesgos dependen en gran medida de qué tratamiento de datos personales se realiza en los diferentes sistemas de TI, así como qué efecto preventivo se puede esperar de los usuarios saben que sus acciones se registran y pueden investigarse retrospectivamente.
En general, se puede decir que el uso de sistemas informáticos que contienen datos de muchas personas tiene más riesgos porque hay mayor posibilidad de mal uso, y cuanta más gente tenga acceso, mayor será la probabilidad de que alguien pueda hacer un mal uso del acceso, por ejemplo, con fines privados o que no estén específicamente relacionados con el trabajo. Sin embargo, la evaluación de riesgos debe considerar los riesgos para la confidencialidad, la integridad y la disponibilidad, por lo que otros aspectos también pueden requerir el registro.
Conforme al art. 25 RGPD al desarrollar, adquirir o modificar sistemas informáticos, la protección de datos debe incorporarse desde el diseño y por defecto. Para poder registrar los usos de datos personales, la funcionalidad debe estar integrada en el sistema de TI. Esto incluye la capacidad de almacenar el registro en una ubicación segura donde esté más protegido contra el acceso o la manipulación por parte de usuarios o piratas informáticos. La configuración por defecto debe ser que el registro esté habilitado de forma predeterminada.
Registrar el uso de datos personales confidenciales y sensibles ha sido un requisito para las autoridades públicas durante muchos años. Para las autoridades estatales, el registro es un requisito técnico mínimo.
En general, se recomienda considerar el registro de manera más amplia, de modo que esté asegurado en relación con lo anterior.
12.1. ¿Qué riesgos se abordan?
Esta medida tiene el mismo objetivo que la medida “Registro de los usos de datos personales por parte de los usuarios”, pero los requisitos para el contenido del registro pueden ser diferentes, porque la atención debe centrarse en poder detectar el abuso de los derechos de acceso del administrador del usuario.
El seguimiento de las acciones de un administrador de usuarios puede tener un enfoque y una frecuencia diferentes al seguimiento de las acciones de otros usuarios. En cuanto a los controles mediante muestras aleatorias, consulte la descripción de las medidas en la medida “Muestras en el registro de uso de datos personales por parte de los usuarios”.
12.2. ¿Qué medidas se pueden considerar?
Ver descripción de la medida “Registro de usos de datos personales por parte de los usuarios”.
12.3. ¿Cuándo es necesaria la medida?
Igual que la medida “Registro de usos de datos personales por parte de los usuarios”. Dado que el administrador de usuarios normalmente puede dar a otros y posiblemente Si el usuario tiene acceso a varios sistemas informáticos, existen buenas razones para garantizar el control de sus acciones.
Conforme al artículo 25 RGPD, al desarrollar, adquirir o cambiar sistemas de TI, la protección de datos debe tenerse en cuenta desde el diseño y por defecto. Para poder registrar las acciones del administrador de usuarios, la funcionalidad debe estar integrada en el sistema informático utilizado para la administración de usuarios, incluida, en particular, la funcionalidad de que el registro debe poder almacenarse en un lugar seguro al que el administrador de usuarios no pueda acceder o manipularlo a través de sus derechos de acceso privilegiado.
13.1. ¿Qué riesgos se abordan?
Los derechos de acceso con un alcance mayor del necesario pueden plantear un riesgo innecesario de pérdida de confidencialidad, integridad y disponibilidad debido a un mal uso. Al limitar la cantidad de personas que pueden otorgar derechos de acceso, se reduce la probabilidad de error y abuso. Se trata, por tanto, de una medida preventiva que puede reducir la probabilidad de una asignación incorrecta o desigual de los derechos de acceso.
La medida también puede reducir el riesgo asociado con los ciberataques externos, porque es menos probable que el compromiso del inicio de sesión de un usuario aleatorio brinde inmediatamente la oportunidad de controlar los derechos de acceso a uno o más sistemas de TI. Por lo tanto, la medida también es pertinente en relación con la reducción de las consecuencias del uso indebido de los derechos de acceso de los usuarios autorizados.
13.2. ¿Qué medidas se pueden considerar?
Designar la menor cantidad posible de responsables de autorizaciones. Limitar la función organizativa responsable de la administración de usuarios al menor número de personas posible. Esto puede resultar difícil si los administradores de usuarios están dispersos por toda la organización, por lo que la implementación simultánea de la medida “Gestión de derechos centralizada” reforzará el efecto preventivo general.
13.3. ¿Cuándo es necesaria la medida?
El artículo 5.1.f RGPD, trata de la integridad y confidencialidad de los datos personales. Cuanto menos pueda hacer el usuario individual con los datos a los que tiene acceso, menores serán las posibles consecuencias si comprometen la integridad y confidencialidad de los datos mediante acciones inadvertidas o maliciosas. Esto también tiene un efecto protector frente a las ciberamenazas, ya que un hacker a menudo opera a través de derechos de acceso a cuentas de usuario comprometidas y, por lo tanto, menos derechos limitan sus opciones. Por lo tanto, los derechos de acceso deben limitarse tanto como sea posible y se debe limitar quién puede otorgar nuevos derechos de acceso.
La gestión del riesgo por parte del responsable del tratamiento de acuerdo con el artículo 32 RGPD puede mostrar qué medidas son necesarias. Si se trata, por ejemplo, de una empresa de dos personas, puede ser necesario que ambas puedan controlar los derechos de acceso, sin riesgo de abuso, etc. aumentando así significativamente.
14.1. ¿Qué riesgos se abordan?
Un ataque típico de un ciberdelincuente suele implicar que adquiera más derechos de acceso, ya que esto proporciona más opciones en los sistemas de TI que los derechos de acceso de un usuario normal. Si el ciberdelincuente puede utilizar una cuenta de usuario con derechos de acceso privilegiados, esto suele ser más problemático. Minimizar el uso de derechos de acceso privilegiados hace que esto sea más difícil de lograr. Esta es una medida preventiva que puede minimizar las consecuencias si un atacante logra apoderarse de una cuenta de usuario.
14.2. ¿Qué medidas se pueden considerar?
El desafío es que alguien siempre necesita tener derechos de acceso privilegiados. Entonces, además de limitar quién tiene estos derechos, también puede darle al mismo usuario dos cuentas de usuario, una regular con derechos regulares y otra con más derechos. Al utilizar la cuenta de usuario privilegiada únicamente cuando sea absolutamente necesario, se limita su exposición, pero no si el empleado utilizará esta cuenta la mayor parte del tiempo. La división en dos cuentas también puede tener el efecto positivo de hacer que el usuario sea más consciente de cuándo está trabajando con derechos de acceso que pueden causar más daños (si se cometen errores). Es posible que la división no necesariamente tenga sentido en organizaciones pequeñas o si el empleado solo realiza tareas que requieren acceso privilegiado.
El acceso de administrador de usuarios se considera acceso privilegiado, ya que se puede abusar de él más que de las cuentas de usuario normales. Otros tipos de acceso privilegiado se utilizan para operaciones de TI, como el acceso directo a una base de datos, conocido como «acceso SQL». Esto puede permitir la manipulación directa de la base de datos, es decir, eludir las restricciones de acceso y las características de seguridad que normalmente se encuentran en las aplicaciones que se encuentran entre el usuario y la base de datos. Este tipo de acceso implica más riesgos y sólo se utiliza bajo las siguientes condiciones:
- Se concede sólo cuando es absolutamente necesario (por tiempo limitado).
- Solo se otorga a personas con tareas operativas de TI y las competencias adecuadas.
- Solo se otorga después de algún tipo de autorización de seguridad y posiblemente sujeto a no contar con antecedentes penales.
- El uso se registra y el registro se almacena en un lugar al que no pueden acceder quienes utilizan el acceso.
14.3. ¿Cuándo es necesaria la medida?
Se trata principalmente de una gestión de riesgos según el artículo 32 RGPD, que debe mostrar qué medidas son necesarias, ya que los riesgos dependen en gran medida del daño que el usuario pueda causar con derechos de acceso privilegiados. Al mismo tiempo, esto también tiene un efecto protector frente a las ciberamenazas, ya que un hacker a menudo opera a través de derechos de acceso a cuentas de usuario comprometidas y, por lo tanto, menos derechos le dan al hacker menos oportunidades.
15.1. ¿Qué riesgos se abordan?
La gestión de derechos es un proceso que normalmente involucra a varias personas y pueden ocurrir errores. También puede haber una falta de enfoque en cerrar el acceso/derechos de acceso innecesarios. Una comprobación de los derechos de acceso puede detectar errores que, de otro modo, podrían existir durante años. Se trata, por tanto, de una medida correctiva que puede reducir la probabilidad de abuso de derechos de acceso innecesarios.
15.2. ¿Qué medidas se pueden considerar?
Un control puede incluir una o más de las siguientes investigaciones:
- Si los derechos de acceso establecidos están amparados por una autorización documentada y en vigor.
- Si el acceso debería haberse cerrado previamente debido a una autorización de tiempo limitado, caducada, renuncia, excedencia u otros motivos.
- Si las autorizaciones están vigentes, es decir, si todas las aprobaciones de derechos de acceso son necesarias y se basan en una necesidad relacionada con el trabajo.
- Si hay cuentas de usuario que ya no son utilizadas por el usuario autorizado («cuentas fantasma») y que, por lo tanto, deberían cerrarse.
Las posibilidades y lo más sencillo dependen de los sistemas informáticos utilizados. Los derechos de acceso se mantienen contra una fuente creíble y actualizada. Normalmente existe un sistema de recursos humanos que muestra quién está empleado actualmente y qué puesto ocupa. Si la organización utiliza derechos de acceso basados ??en roles, el registro en el sistema de recursos humanos puede indicar con mucha precisión quién debería tener acceso a qué y qué accesos deberían ser cerrado.
«Controladores» con diferentes roles (director diario, responsable de seguridad informática, propietario del sistema, etc.) tienen diferentes intereses, y se debe ser consciente de ello cuando se asigna y explica la tarea de control al responsable del tratamiento. Si el administrador tiene que comprobar los derechos de acceso de sus propios empleados, este administrador puede centrarse más en si se han establecido los derechos necesarios que en si algunos usuarios tienen demasiados derechos.
El objetivo de una verificación también puede ser ahorrar dinero en licencias de usuario, lo que puede eliminar derechos de acceso innecesarios, pero todavía no se centra en si los derechos son necesarios para cumplir un necesidad laboral.
La frecuencia de los controles mencionados anteriormente se ajusta según los problemas que revele el control. Si la verificación muestra que rara vez hay errores, puede ser suficiente realizar menos comprobaciones en el futuro. Si, por el contrario, la verificación muestra muchos errores, es posible que sea necesario aumentar la frecuencia o el alcance. Muchos errores también pueden indicar que otras medidas/procesos no están funcionando de manera óptima. En ese caso, puede ser más relevante intentar arreglar la gestión diaria de los derechos de acceso en lugar de aumentar la frecuencia de los controles.
15.3. ¿Cuándo es necesaria la medida?
La Autoridad Danesa de Protección de Datos ha declarado que, en su opinión, el requisito de seguridad adecuada en el RGPD, Artículo 32, subsección 1 normalmente implicará que el responsable del tratamiento compruebe continuamente si los derechos de acceso a los sistemas informáticos se limitan a los datos personales que son necesarios y necesarias para las necesidades laborales del usuario en cuestión.
Esto se debe a que, no importa cuán estrictamente se gestionen los derechos de acceso, las cosas pueden salir mal en muchos lugares de un proceso de este tipo, que a menudo involucra a muchas personas. Por tanto, es muy probable que se produzcan errores que sólo podrán detectarse mediante controles periódicos.
16.1. ¿Qué riesgos se abordan?
Los datos anonimizados no están sujetos al RGPD. La anonimización es un proceso que garantiza que los datos no puedan vincularse a una persona física.
Los datos personales seudonimizados son datos que solo pueden atribuirse a una persona física mediante el uso de información adicional, y el acceso a esta información adicional está muy restringido. La seudonimización se puede utilizar, por ejemplo, si algunos usuarios necesitan utilizar un conjunto de datos sin necesidad de identificar a las personas titulares de los mismos. La información adicional que permite identificar a las personas en el conjunto de datos se puede encontrar, por ejemplo, en otro sistema informático al que los mismos usuarios no tienen acceso.
Un usuario que sólo tiene acceso a datos anónimos no tiene acceso a datos personales. Un usuario que sólo tenga acceso a datos seudonimizados no podrá vincularlos a una persona física (con sus derechos de acceso). Se trata, por tanto, de una medida preventiva que puede reducir las consecuencias del mal uso de cuentas de usuario, ya sea que el uso indebido lo lleve a cabo el usuario autorizado o un pirata informático que se apodere de los derechos de acceso del usuario.
16.2. ¿Qué medidas se pueden considerar?
Las posibilidades de implementar la anonimización o la seudonimización dependen de los sistemas de TI y de las tareas realizadas en la organización. La verdadera anonimización y la seudonimización son procesos difíciles que requieren una comprensión de cómo se pueden identificar los individuos en un conjunto de datos.
16.3. ¿Cuándo es necesaria la medida?
Se trata principalmente de una gestión de riesgos según el artículo 32 RGPD, que debe mostrar qué medidas son necesarias y el mismo artículo también menciona la seudonimización como una medida potencialmente relevante. Hay que tener en cuenta que tanto la seudonimización como la anonimización son medidas necesarias en relación con el principio de minimización de datos del artículo 5.1.c.
Conforme al artículo 25 RGPD al desarrollar, adquirir o modificar sistemas informáticos, se debe tener en cuenta la protección de datos desde el diseño y por defecto. La posibilidad de seudonimización o anonimización requiere que esto se haya tenido en cuenta en el diseño del sistema informático y que funcione con las tareas laborales de los empleados. La configuración predeterminada puede ser, entre otras cosas, que la seudonimización se realice automáticamente, controlada por ejemplo por la antigüedad de la información, o la terminación de las relaciones con los clientes.
Acerca de lo que se necesita para garantizar una verdadera anonimización en un conjunto de datos: WP216 del grupo del Artículo 29, «Opinión 05/2014 sobre técnicas de anonimización»
17.1. ¿Qué riesgos se abordan?
En organizaciones grandes con muchos sistemas de TI, evaluar qué derechos de acceso son apropiados puede ser una tarea compleja. Esto aumenta la probabilidad de errores al establecer derechos. La asignación de acceso basada en roles facilita que el administrador de autorizaciones evalúe y apruebe las solicitudes de acceso porque no requiere una comprensión de las necesidades de acceso de cada sistema de TI, solo conocimiento de los roles/tareas de los usuarios. Esto facilita la tarea a todas las partes implicadas, minimizando así la probabilidad de errores. Se trata, por tanto, de una medida preventiva que puede reducir la probabilidad de que Se producen errores al asignar derechos.
17.2. ¿Qué medidas se pueden considerar?
Los derechos de acceso se agrupan según los roles/tareas de los usuarios para que cubran las necesidades laborales más típicas en relación con la función de cada persona trabajadora, recursos humanos, contabilidad, atención al cliente, etc. Esto también puede facilitar la tarea de definir los derechos de acceso a todos los sistemas de TI.
17.3. ¿Cuándo es necesaria la medida?
La necesidad depende de la complejidad de su entorno de TI. Por lo tanto, es una gestión de riesgos según el artículo 32 RGPD la que mostrará qué medidas son necesarias.
Conforme al artículo 25 RGPD, al desarrollar, adquirir o actualizar sistemas informáticos, la protección de datos debe incorporarse desde el diseño y por defecto. La posibilidad de simplificar la cesión de derechos puede depender del diseño de los sistemas informáticos.
18.1. ¿Qué riesgos se abordan?
El tratamiento incorrecto de los datos puede dar lugar a brechas de seguridad involuntarias, como la publicación o divulgación de datos personales que deberían haberse omitido. El riesgo se puede prevenir garantizando que cada usuario tenga los conocimientos necesarios para utilizar su autorización y tratar los datos correctamente. Esta es una medida preventiva que minimiza la probabilidad de errores en el tratamiento de datos.
Muchas brechas de seguridad se producen por usuarios que utilizan TI a diario y, que piensan que tienen los conocimientos suficientes, pero aun así cometen errores. En algunos casos, esto se debe a que el enfoque del usuario no está en la seguridad, o porque el tratamiento seguro de datos requiere un conocimiento especializado de TI, una comprensión diferente a la requerida para realizar las tareas del usuario. En algunos casos, las brechas de seguridad son causadas directamente por una falta de conocimiento de la diferencia entre el ámbito físico y el electrónico, por ejemplo, si el usuario cree que los datos se han eliminado de un documento si no son visibles en la pantalla de su PC.
18.2. ¿Qué medidas se pueden considerar?
Al conceder un nuevo acceso, se debe aprobar un procedimiento para garantizar que el usuario al que se concede tenga las competencias necesarias para tratar los datos de forma segura evitando brechas de seguridad en la medida de lo posible, se trata de no dar a través de derechos de acceso un margen de maniobra que esté fuera de sus competencias.
Estos son algunos ejemplos en los que el acceso de los usuarios se considera junto con las competencias adecuadas:
- El acceso no se concede hasta que el empleado tenga las competencias necesarias, si ya está concedido, se le imparte la formación adecuada.
- Los derechos de acceso para publicar datos en un sitio web solo se otorgan a los empleados para quienes esta tarea es un área principal de trabajo, y solo después de recibir capacitación sobre cómo encontrar y filtrar datos personales que pueden almacenarse en los metadatos en un documento. También pueden ser necesarias las herramientas y competencias que les permitan eliminar datos (no solo ocultarlos) y entender cuándo los datos se anonimizan.
- El tratamiento electrónico de las solicitudes de acceso solo lo llevan a cabo empleados a quienes se les han proporcionado herramientas y competencias que les permiten eliminar datos de manera efectiva (no solo ocultarlos) y después de recibir capacitación sobre los requisitos legales pertinentes sobre el alcance del acceso.
- Los datos personales solo los envían fuera de la organización empleados que han recibido formación sobre los requisitos para una transmisión (segura). Si es posible, también se les han proporcionado herramientas que facilitan el envío de datos de forma segura.
- La redacción de documentos que se publican automáticamente al mismo tiempo la realiza un reducido número de empleados para quienes esta tarea es su principal área de trabajo. Si existe una publicación automática de documentos en el sistema de registro, el empleado también recibe formación sobre su funcionamiento.
- Algunos derechos de acceso pueden implicar un riesgo mayor que otros. Un empleado con acceso de lectura a los datos puede comprometer la confidencialidad de los datos al transmitirlos a personas no autorizadas. La capacidad de eliminar datos conlleva un riesgo adicional, el riesgo de que los datos sean inaccesibles si, por ejemplo, el empleado elimina accidentalmente los datos que no se den suprimir. La capacidad de eliminar datos también puede estar vinculada a requisitos legales, como las normas de la administración pública, que pueden prohibir la eliminación en determinados contextos. Dichos derechos de acceso están reservados para empleados que hayan recibido formación sobre riesgos relevantes y/o requisitos legales y para quienes esta tarea sea su principal área de trabajo.
18.3. ¿Cuándo es necesaria la medida?
Es principalmente una gestión de riesgos según el artículo 32 RGPD la que mostrará qué medidas son necesarias, ya que los riesgos específicos dependen en gran medida de si hay funciones/tareas en la organización en las que la falta de competencias realmente pueda representar un riesgo.
Ver la medida “Concienciación y Formación” para seleccionar información adicional relevante que se proporcionará en el momento de contratar un nuevo empleado o al cambiar los derechos de acceso.
- MUESTRAS EN EL REGISTRO DE USO DE DATOS PERSONALES POR PARTE DE LOS USUARIOS
19.1. ¿Qué riesgos se abordan?
Si los usuarios son conscientes de que se está supervisando el uso de los sistemas, esto puede desalentar el uso indebido. Si se utiliza correctamente, es por tanto una medida preventiva y posiblemente también de detección que puede reducir la probabilidad de abuso de los derechos de acceso. Por supuesto, esto supone que todas las acciones pueden atribuirse a una única persona física, por lo que la medida “Evitar el uso innecesario de cuentas multiusuario” también es relevante.
Esta medida puede ser especialmente pertinente en situaciones en las que los derechos de acceso no pueden limitarse mucho y en las que los usuarios necesariamente deben tener un amplio acceso a una gran cantidad de datos personales como parte de su trabajo y en las que, por tanto, puede existir un riesgo particular de que alguien se sienta tentado a utilizar su acceso sin que sea específicamente relacionado con sus funciones.
19.2. ¿Qué medidas se pueden considerar?
El muestreo de registros se realiza según un procedimiento fijo, sin que el muestreo sea predecible para los usuarios. El efecto preventivo requiere que los usuarios estén familiarizados con esta medida de control, ver más en la medida “Concienciación y formación”.
Puede ser una ventaja si la muestra se refiere a un uso relativamente reciente, de modo que se pueda esperar razonablemente que el usuario pueda explicarlo.
El tamaño de la muestra dependerá de cada caso, por ejemplo, si es posible filtrar automáticamente una gran cantidad de avisos en los datos como relacionados con las funciones de su puesto (debido a una relación conocida con el cliente, área de trabajo, relación médico/paciente, etc.), entonces la muestra de las entradas restantes puede ser más limitada o específica que si tuviera que abarcar todos los puestos.
Se deben establecer alertas (por ejemplo, basadas en datos de registro) que se activen automáticamente ante una actividad sospechosa, esto puede complementar o reemplazar un muestreo más aleatorio.
El muestreo aleatorio continuo también funcionan como una verificación para ver si el registro siempre se realiza como se esperaba y si los datos del registro se almacenan durante el tiempo suficiente y se pueden interpretar con la guía actual. Por lo tanto, también es una prueba de una medida establecida y, conforme al artículo 32.1.d) RGPD. Ver la medida “Registro del uso de datos personales por parte de los usuarios” .
19.3. ¿Cuándo es necesaria la medida?
Es principalmente una gestión de riesgos según el artículo 32 RGPD la que mostrará cómo deben organizarse los controles aleatorios, incluido el alcance y la frecuencia. Esto se debe a que el riesgo depende de qué tratamiento de datos personales se realiza en los diferentes sistemas informáticos, así como de quién y cuántas personas tienen acceso.
En el caso de un acceso amplio, es decir, cuando los usuarios tienen acceso a una gran cantidad de datos personales sensibles y/o acceso a datos de muchas personas, a menudo serán necesarias comprobaciones aleatorias cada seis meses.
20.1. ¿Qué riesgos se abordan?
Las restricciones de acceso físico pueden complementar las restricciones de acceso electrónicas, pero en algunos casos la primera es el único obstáculo al acceso no autorizado a datos personales. Se trata de un símil con el inicio de sesión electrónico en sistemas informáticos o soportes de datos. Es una restricción controlada de acceso y por lo tanto una medida preventiva que pueda minimizar las consecuencias si el acceso del usuario se utiliza incorrectamente.
Los requisitos para obtener acceso electrónico a un sistema de TI pueden ser menores dentro de un entorno físico (por ejemplo, un edificio de oficinas) que en el exterior. Por lo tanto, el inicio de sesión puede resultar más complicado cuando un usuario utiliza el acceso remoto que cuando el mismo usuario inicia sesión desde su puesto de trabajo en la oficina. Alternativamente, el acceso remoto puede ser más limitado.
Además, pueden existir accesos electrónicos que, por motivos de seguridad, sólo sean posibles dentro de un determinado marco físico. Por lo tanto, los derechos de acceso físico pueden ser una parte importante de la protección de los datos personales, tanto los automatizados como los que están en papel.
20.2. ¿Qué medidas se pueden considerar?
Nos referimos básicamente a la protección de la confidencialidad de los datos, la integridad o la disponibilidad puede requerir medidas diferentes, como respaldo en caso de robo de equipos de TI a través de un acceso físico comprometido.
El personal de recepción puede impedir el acceso a personas no autorizadas y los recepcionistas reciben instrucciones sobre cómo reaccionar ante personas que normalmente no tienen acceso (comerciales informáticos, etc.), en qué medida se debe identificar a las personas, si debe ser acompañado hasta el interior, etc. Se registra el acceso de invitados a través del mostrador de recepción.
Si es previsible que el personal de recepción no conozca a todos los empleados, será más seguro utilizar medios de acceso personalizados, como tarjetas de acceso electrónicas combinadas con un código personal, que deben asignarse, registrarse y bloquearse según los mismos principios que el resto de gestión de derechos utilizados para los identificadores de usuario y las contraseñas para iniciar sesión en los sistemas informáticos.
Si la organización dispone de instalaciones con acceso físico a un entorno informático (cajas de conexiones y salas de servidores), este acceso implica a menudo la posibilidad de eludir la restricción de acceso electrónico y, por tanto, la gestión electrónica de derechos. Dichos locales deben tener una restricción física especial y considerar puertas antirrobo, cierrapuertas automáticos con alarmas en caso de fallo de cierre, sistemas de llaves de seguridad (a prueba de manipulaciones, protegidos contra copia), alarmas, sensores de movimiento, detectores sísmicos, etc.
El acceso a los documentos físicos en las oficinas, por ejemplo, puede restringirse mediante armarios de seguridad (cajas fuertes) ubicadas a una parte fija del edificio. La clave/código del armario se gestiona según los mismos principios que el control de acceso electrónico. Las cajas fuertes estarán disponibles en diferentes «clases» que definen su resistencia al robo, es decir, qué lo difícil que es entrar abrirla, y esto debe adaptarse al tiempo que puede pasar antes de que se pueda esperar que una alarma o un guardia detecte el acceso no autorizado.
Las impresoras se colocan donde solo los empleados tienen acceso y, además, se pueden usar herramientas que solo imprimen cuando el usuario correcto está en la impresora (también conocido como «Impresión Sígueme»).
La gestión del acceso físico se coordina con otras posibles medidas para evitar la elusión de las restricciones de acceso físico, como guardias, puertas reforzadas, alarmas contra intrusos, sensores de movimiento, alarmas de fallo de cerraduras de puertas, cerraduras personales, etc.
20.3. ¿Cuándo es necesaria la medida?
Según el artículo 32 RGPD, se trata principalmente de una gestión de riesgos la que debe indicar qué medidas son necesarias, ya que los riesgos dependen en gran medida de las circunstancias específicas.
Es una interacción entre medidas lo que crea un nivel adecuado de seguridad. Medidas como el cifrado de los soportes de datos pueden reducir la necesidad de seguridad física en la oficina y en el hogar. Por otro lado, cifrar servidores puede resultar complicado y aumentar el riesgo de indisponibilidad y pérdida de datos, razón por la cual se prioriza la seguridad física sobre el cifrado del servidor.
Conforme al artículo 25 RGPD al desarrollar, adquirir o actualizar sistemas informáticos, la protección de datos debe incorporarse desde el diseño y por defecto. Por lo tanto, los sistemas informáticos para, por ejemplo, las tarjetas de acceso también deben seleccionarse en función de si pueden minimizar el acceso a los datos personales, por ejemplo, que el sistema informático pueda diferenciar entre el acceso a la sala de servidores, a la de conexiones de red, a la oficina, zona de atención al cliente, sala de impresoras, archivo de ficheros, recepción de mercancías, etc.
21.1. ¿Qué riesgos se abordan?
Cuando hay cambios en las funciones de una persona trabajadora, se producen modificaciones que afectan directa o indirectamente al acceso a los datos personales. Cuando ya no es necesario el acceso a los sistemas informáticos, hay que eliminarlos, pero esto se puede olvidar dando acceso al usuario durante más tiempo del necesario. Un mayor acceso proporciona una mayor «superficie de ataque» para los actores maliciosos. Los accesos que ya no son necesarios suponen, por tanto, un riesgo innecesario. Especialmente cuando se libera a los empleados, puede existir riesgo de uso indebido del acceso si no se cierran inmediatamente. Es por tanto una medida preventiva que puede reducir la probabilidad de que existan derechos de acceso innecesarios al sistema informático que se utilicen de forma indebida.
Una cuenta que ya no es utilizada por el usuario legítimo también se denomina «cuenta fantasma». Incluso si se impide al usuario legítimo utilizar la cuenta, por ejemplo bloqueándola, es posible que el acceso se siga utilizando indebidamente. Al eliminar dichas cuentas de usuario, se reduce la superficie de ataque, ya que se evita que los ciberdelincuentes abusen de una «cuenta fantasma» para obtener derechos de acceso. El abuso de «cuentas fantasma» también puede ocurrir durante un período de tiempo más largo sin ser detectado, que en el caso del abuso de las cuentas que todavía utiliza el usuario legítimo.
21.2. ¿Qué medidas se pueden considerar?
Los procedimientos o técnicas se establecen de tal manera que la organización se ve obligada a reaccionar cuando hay cambios en las funciones o en los puestos de trabajo, como cambio de tareas laborales, licencias, renuncias, despidos, enfermedades de larga duración y muerte. Los cambios en las condiciones laborales deben generar una notificación, por ejemplo, a través de un sistema de recursos humanos. Alternativamente, se puede establecer un procedimiento fijo, de modo que se cancelen los derechos de acceso innecesarios. El proceso debe garantizar el mismo alto enfoque en la terminación de los derechos existentes que en la creación de otros nuevos.
Se garantiza que el empleado adecuado reciba información sobre el cambio para evitar situaciones en las que el acceso permanezca abierto después de la renuncia del empleado.
Algunos cambios en las condiciones de empleo exigen que se fije con antelación un momento en el que se debe “izar” una bandera y se debe iniciar un proceso especial; esto se aplica, por ejemplo, si una autorización de seguridad expira automáticamente después de x años con la consiguiente falta de aprobación para acceder a determinados datos especialmente clasificados.
Las bajas por maternidad, por enfermedad, etc. son situaciones en las que probablemente haya que eliminar el acceso, pero como es temporal, el cierre se produce de forma diferente que en el caso de las bajas definitivas. Por ejemplo, el acceso de los empleados a la intranet se puede mantener porque aquí se comparte información sobre actividades e información sobre el desarrollo del trabajo. De esta manera, el empleado ausente aún puede sentirse parte del lugar de trabajo. Al mismo tiempo, se cierra o desactiva temporalmente el acceso de los empleados a los sistemas en cuestión.
Con la rotación interna, las tareas se pueden cambiar gradualmente. En esta situación se asegura un procedimiento o automatización que provoca el cierre de los accesos cuando ya no son necesarios.
Finalmente, se establece un procedimiento especial para los sistemas periféricos/externos que no pueden cerrarse a través de una unidad centralizada de administración de usuarios.
Se debe considerar lo siguiente cuando sea necesario eliminar o cambiar los derechos de acceso:
- El empleado debe cerrar el acceso a sistemas externos, que de otro modo sería más difícil para otros.
- Los empleados con derechos administrativos deben transferirlos ellos mismos a otro empleado.
- Eliminación de datos en dispositivos antes de la entrega y restablecimiento o provisión de un código para que pueda reutilizarse.
- Limpiar cuentas de correo electrónico, unidades de red y especialmente en lugares donde solo este empleado tenía acceso, o limpiar datos privados para que el contenido de la cuenta pueda estar disponible para otros después de la baja.
- Cerrar el acceso a sistemas informáticos, buzones de funciones y sistemas informáticos externos.
- Inclusión de DNI, llaveros, llaves de puertas/buzones/bastidores/…, tokens de acceso, PC, smartphone, memorias USB, discos duros, documentos físicos, etc.
- Cambiar códigos que se comparten entre múltiples usuarios (cuentas multiusuario).
- Bloqueo de acceso mediante llaveros, tarjetas de acceso, acceso físico/paneles de alarma, cabinas/cajas fuertes.
- Reemplazo / recodificación de cerraduras (si la llave no está protegida contra copia).
- Bloquear el acceso remoto a los sistemas informáticos.
- Bloquear el acceso con certificados y posiblemente con los propios certificados.
- Cancelación de línea telefónica y de internet corporativos, si se le permite quedarse con el teléfono, se presta especial atención al hecho de que no contenga datos de la empresa y que se detenga la sincronización de datos (normalmente citas del calendario y correos electrónicos).
- Eliminación de datos de empleados que ya no sean necesarios, por ejemplo, fotografía utilizada para el documento de identidad o información de la guía telefónica en la intranet.
- Las listas de contactos internas se actualizan y los agentes externos son informados de esos cambios (clientes, empresa de seguridad, comerciales, etc. ), especialmente si el empleado puede seguir utilizando el número de teléfono después de su baja.
- Revisión de la organización de emergencias, titularidad del sistema, etc. si el empleado estuviera cubierto por ésta.
- Investigar si se produce una dependencia inapropiada de las personas cuando se eliminan o modifican los derechos de acceso.
21.3. ¿Cuándo es necesaria la medida?
Del artículo 5.1.f RGPD se desprende que al tratar datos personales se debe garantizar una seguridad suficiente, incluida la protección contra el tratamiento no autorizado e ilícito, eliminar el acceso reduce este riesgo, lo que puede ser particularmente importante en situaciones en las que un empleado es despedido. En situaciones muy especiales, una gestión de riesgos podrá demostrar que la medida no es necesaria si, por ejemplo, el acceso es únicamente a datos personales disponibles públicamente y el uso indebido en forma de cambio/eliminación de esta información no puede dañar a los interesados.
- EVITAR LA REUTILIZACIÓN DE AUTORIZACIONES SIN CONSIDERARLO ACTIVAMENTE
22.1. ¿Qué riesgos se abordan?
La renovación de las autorizaciones puede ser relevante, por ejemplo, para el empleo temporal repetido del mismo trabajador temporal o consultor externo. La autorización es otorgada por el responsable de la autorización de conformidad con un empleo. Si la autorización se reutiliza en la siguiente cita, sin que el responsable de la autorización analice de nuevo qué derechos de acceso son necesarios, se pueden generar derechos innecesarios que pueden usarse indebidamente. Se trata por tanto de una medida preventiva que puede reducir la probabilidad de acceso incorrecto.
22.2. ¿Qué medidas se pueden considerar?
Se establecen procedimientos para garantizar que, cuando se renueven las autorizaciones, se realice una nueva evaluación de la necesidad. Esto garantiza que a los usuarios no se les asignen derechos innecesarios. La protección puede realizarse a través de procedimientos, sistemas informáticos o formularios utilizados en relación con la administración de usuarios.
22.3. ¿Cuándo es necesaria la medida?
El artículo 5.1.f RGPD trata sobre la integridad y confidencialidad de los datos personales. Cuantas menos personas tengan acceso, más se reduce la probabilidad de que algunos de estos usuarios puedan suponer un riesgo mediante acciones accidentales o maliciosas. Cuanto menos acceso tenga el usuario individual, menores serán las posibles consecuencias si algunos de estos usuarios dañan los datos mediante acciones accidentales o maliciosas. Al mismo tiempo, esto también tiene un efecto protector frente a las ciberamenazas, ya que un hacker a menudo opera a través de derechos de acceso a cuentas de usuario comprometidas y, por lo tanto, menos derechos le dan al hacker menos opciones. Por lo tanto, los derechos de acceso deben limitarse lo más posible.
23.1. ¿Qué riesgos se abordan?
Puede ser más fácil crear nuevos usuarios copiando los derechos de acceso de un o existente, sin embargo, esto conllevará los siguientes riesgos:
- Si hay errores en los derechos de acceso que se copian, se copiará a otro usuario.
- Es posible que el administrador de autorizaciones no sea consciente de lo que se está copiando y, por tanto, no considere activamente si es necesario copiarlo todo.
- Los derechos de acceso para el usuario existente pueden cambiar entre el momento de la aprobación del administrador de autorización y el momento de la copia de los derechos de acceso y, por lo tanto, pueden surgir dudas sobre lo que se aprobó. Por lo tanto, pueden surgir dudas sobre si el administrador de usuarios ha procesado correctamente la tarea o qué derechos de acceso ha autorizado realmente el administrador de autorizaciones para ser copiados.
- Dado que la persona responsable de la autorización no indica específicamente qué derechos de acceso se deben conceder, no está claro de qué se puede responsabilizar posteriormente a la persona responsable de la autorización si se conceden más derechos de acceso de los necesarios y se hacen un uso indebido.
Estos riesgos se pueden minimizar gestionando rigurosamente el proceso de autorización y considerando activamente los derechos de acceso. Se trata de una medida preventiva que puede minimizar la probabilidad de derechos de acceso incorrectos.
23.2. ¿Qué medidas se pueden considerar?
Se debe emplear un procedimiento de asignación mediante el cual los derechos de acceso del usuario se «construyan desde cero» y no se acepte la copia de los mismos. Alternativamente, se puede realizar una copia controlada, teniendo en cuenta los riesgos antes mencionados, por ejemplo, considerando cada derecho individual en un formulario para cada usuario, que puede ser firmado por el responsable de la autorización. El uso de un formulario también garantiza la documentación y el proceso promueve la responsabilidad por parte de la persona responsable de la autorización.
23.3. ¿Cuándo es necesaria la medida?
El artículo 5.1.f RGPD trata sobre la integridad y confidencialidad de los datos personales. Cuantas menos personas tengan acceso a los datos personales, más se reduce el riesgo que algunos de estos usuarios pueden suponer mediante acciones accidentales o maliciosas. Cuanto menos acceso tenga el usuario individual, menores serán las posibles consecuencias si algunos de estos usuarios dañan los datos mediante acciones accidentales o maliciosas. Al mismo tiempo, esto también tiene un efecto protector frente a las ciberamenazas, ya que un hacker a menudo opera a través de derechos de acceso a cuentas de usuario comprometidas y, por lo tanto, menos derechos le dan al hacker menos oportunidades. Por lo tanto, los derechos de acceso deben limitarse lo más posible.
24.1. ¿Qué riesgos se abordan?
Las cuentas multiusuario se caracterizan por un acceso que pueden utilizar varios usuarios y, por tanto, corresponden en realidad a un inicio de sesión impersonal o anónimo. Por lo tanto, las acciones realizadas no pueden atribuirse a una sola persona física, lo que limita la posibilidad de comprobar si un uso o acceso específico a la información está justificado. Puede tratarse, por ejemplo, de cuentas de usuario de prueba, que son utilizadas sucesivamente por diferentes desarrolladores, sin que quede claro quién ha iniciado sesión y cuándo. En el sector sanitario, puede tratarse del acceso a equipos en salas de exploración, donde varios grupos de especialistas están con un paciente al mismo tiempo.
Las cuentas multiusuario pueden ser una tentación de abuso. Además, las medidas de registro tendrán poco o ningún efecto preventivo contra el abuso si los usuarios saben que pueden esconderse detrás de un inicio de sesión anónimo.
Por lo tanto, evitar o limitar el uso de cuentas multiusuario es una medida preventiva que puede reducir la probabilidad de abuso de los derechos de acceso. El beneficio no se limita al mal uso deliberado, cuando varias personas comparten un inicio de sesión, efectivamente comparten la responsabilidad del tratamiento de datos personales que se lleva a cabo a través de este inicio de sesión, y cuando varias personas comparten la responsabilidad, el individuo a menudo siente menos o ninguna responsabilidad, este es un efecto psicológico. Finalmente, el acceso anónimo puede aumentar la probabilidad de que los factores de acceso (por ejemplo, contraseña) no se manejen adecuadamente, por varias razones:
- Las contraseñas se pueden compartir entre personas que no necesariamente han sido autorizadas. El usuario individual no siente una gran responsabilidad de proteger la contraseña, porque ya está compartida.
- Las contraseñas no se pueden cambiar cuando las personas abandonan el grupo de usuarios y, por lo tanto, ya no deberían tener acceso.
- Las contraseñas que el usuario no ha elegido por sí mismo suelen ser más difíciles de recordar y, por ello, se anotan.
24.2. ¿Qué medidas se pueden considerar?
Los sistemas y procedimientos informáticos están configurados de forma que se impida en la medida de lo posible el acceso anónimo, esto significa que los factores de acceso (por ejemplo, contraseñas) son personales y sólo los conoce el usuario individual. Cualquier cuenta de servicio cuyo inicio de sesión esté codificado en software está protegida contra el uso indebido.
Si los ID de usuario se reutilizan (se pasan a otra persona), se registra cuando esto sucede, de esta forma, la organización sabe siempre quién ha podido utilizar este ID de usuario en cada momento. Este suele ser el caso de las cuentas de usuario utilizadas para pruebas o empleo temporal (consultores externos, trabajadores temporales, estudiantes).
Si no es posible evitar que varias personas compartan los factores de concesión de acceso, se deben establecer procedimientos que pueden garantizar que un cambio en el grupo de usuarios también dé lugar a un cambio en el factor de concesión de acceso. Esto significa que sólo el grupo de usuarios actual puede iniciar sesión.
Un buen complemento es la formación para los usuarios sobre cómo gestionar y proteger los factores de acceso, de modo que el usuario sea consciente de que sigue siendo responsable de las acciones realizadas durante el inicio de sesión.
24.3. ¿Cuándo es necesaria la medida?
En general, del artículo 5.1.f RGPD se desprende que los datos personales deben tratarse de una manera que garantice la protección contra el tratamiento no autorizado o ilícito. Una gestión de riesgos según el artículo 32 RGPD mostrará qué medidas son necesarias, ya que los riesgos y las oportunidades dependen en gran medida de las circunstancias específicas. Como se ve en lo anterior, el uso de inicios de sesión anónimos puede aumentar la probabilidad de uso indebido deliberado, falta de sentido de responsabilidad y otras cosas que resulten en un tratamiento de datos no autorizado/ilícito.
- GESTIÓN DE CAMBIOS
25.1. ¿Qué riesgos se abordan?
En caso de cambios en los entornos de TI, el software, la organización, los procesos y procedimientos de negocio, etc., pueden producirse errores. Los errores también pueden ocurrir en lugares de un entorno de TI que no se ven directamente afectados por un cambio determinado, porque los cambios desencadenan errores derivados en los sistemas asociados, o como resultado de procedimientos que no se adaptan a los cambios planificados en un entorno de TI.
Una buena gestión del cambio implica que se gestionen de acuerdo con principios establecidos. Lo que realmente implica la gestión del cambio puede variar de una situación a otra, la clave es contar con procedimientos fijos para tratar y evaluar las consecuencias de los cambios planificados antes de implementarlos. Se intenta anticipar los errores para evitarlos, pero también para tener un plan para afrontar las consecuencias si se producen errores en relación con el cambio. Por tanto, se trata de una medida con muchas facetas. La forma en que afecta los riesgos depende de qué parte de la gestión del cambio se esté hablando.
Pueden producirse errores, por ejemplo, si no se garantiza que las medidas existentes se mantengan al sustituir el servidor, si se mantiene una restricción de acceso a una carpeta de una unidad de red que se traslada a otro servidor.
Otros errores pueden surgir a través de la integración entre sistemas de TI y procesos automatizados. Al iniciar transferencias de datos entre sistemas de TI, se debe garantizar, por ejemplo, que se incluyan marcas sobre nombres modificados, para que la información sobre nombres protegidos no se exponga accidentalmente en otro sistema de TI.
Algunos ejemplos en los que una mejor gestión del cambio podría haber marcado la diferencia:
- En relación con un traslado, la escuela envía una carta a los padres, el envío se realiza automáticamente, incluso si el niño vive con uno de los padres en una dirección protegida, pero la dirección no se omite, por lo que se transmite inadvertidamente información sobre una dirección protegida. Esto se debe a que, al desarrollar un nuevo sistema informático, no se ha tenido suficientemente en cuenta qué datos personales se tratan en el sistema informático y cómo se puede utilizar esta información en el nuevo. El envío de cartas se ha automatizado sin tener en cuenta circunstancias individuales en torno a la protección de algunos de los datos personales tratados.
- Los padres separados con custodia compartida tienen la oportunidad de iniciar sesión en una solución para que ambos puedan acceder a las cartas sobre el hijo común. No se tiene en cuenta que el otro progenitor no puede acceder a la información sobre la dirección protegida, que figura en las cartas.
- Uno de los progenitores tiene una orden de restricción contra las visitas del otro y el domicilio del niño está protegido. No obstante, se envía un SMS a ambos padres con información sobre dónde y cuándo el niño común tiene cita en una clínica dental. El error se debe a un fallo al actualizar los datos entre los sistemas de TI.
- Un formulario para cambiar de escuela le permite ingresar un número de seguridad social, después de lo cual el sistema de TI envía automáticamente un recibo a ambos padres con una dirección. El sistema no tiene en cuenta la protección de la dirección, razón por la cual uno de los padres puede obtener injustificadamente la dirección protegida del otro padre ingresando el número de seguridad social del otro padre en el formulario.
- Una escuela envía un SMS a los padres biológicos de un niño sobre un evento escolar, incluso si a los padres biológicos no se les permite saber el paradero del niño. Esto les da a los padres información sobre a qué escuela asiste el niño. Parte del problema es la lentitud en la actualización entre los sistemas de TI y la falta de consideración de las frecuencias de actualización. Falta una visión general de qué sistemas reciben qué datos y a qué velocidad.
- Un padre sin patria potestad recibe un SMS con la dirección de la escuela del niño, incluso si la ubicación del niño está protegida. Se debió a un error en la configuración de un sistema informático, ya que se realizó una integración entre sistemas informáticos sin las pruebas necesarias.
- Se pasa lista en clase utilizando un nombre protegido, porque los datos no provienen de uno de los sistemas escolares donde el nombre se reemplaza por un alias, sino que se obtienen directamente de CPD.
- Una mala codificación en el sistema informático provoca que no se incluya la indicación de protección de dirección cuando los expedientes se envían de una autoridad a otra. Esto conlleva el riesgo de que la autoridad receptora proporcione por error información sobre una dirección protegida, por ejemplo al entregar documentos del caso.
25.2. ¿Qué medidas se pueden considerar?
Se revela qué actividades de tratamiento se ven afectadas por uno o más cambios planificados en el entorno de TI. También se descubre si el cambio puede afectar partes del entorno o procesos y aplicaciones asociadas de los sistemas de TI afectados, que no son directamente objeto del cambio en sí. De esta manera se puede determinar qué partes deben comprobarse en relación con los cambios.
Se garantiza que todos los escenarios de error probables se descubran antes de implementar el cambio, del mismo modo que los escenarios de error relevantes se prueban en la medida necesaria. Todos los errores encontrados se evalúan en función de los posibles riesgos para los derechos y libertades de los interesados y se evalúa, en particular por el DPO (si ha sido designado), si significan que el cambio debe posponerse hasta que se corrija el error.
Comprobar si las medidas existentes se mantienen en caso de un cambio en el sistema. Entre otras cosas lo siguiente:
- Llevar a cabo pruebas que garanticen que todas las medidas de control en un entorno de TI, que se han establecido durante toda la vida del entorno de TI permanecen o se reemplazan por algo equivalente después de un cambio.
- Comprobar si se está realizando un registro en el sistema informático que se va a modificar. Dicho registro debe probarse inmediatamente después del cambio, de modo que se garantice que se siga realizando como se esperaba y que los datos se almacenen durante el tiempo suficiente y puedan interpretarse con las directrices actuales o un sistema de TI asociado. Si esto no se implementa, un cambio en el sistema puede socavar medidas como “Registro de los usos de datos personales por parte de los usuarios y Registro de acciones del administrador de usuarios”.
- Comprobar si el sistema informático a modificar incluye zonas de acceso restringido. Si es así, se implementan medidas para garantizar que la gestión de derechos actual continúe, se interrumpa o se adapte en la medida necesaria, y las restricciones de acceso se prueban inmediatamente después de la implementación de los cambios.
- La gestión de derechos puede tener lugar dentro de un grupo reducido de empleados que, por ejemplo, han optado por restringir el acceso a una carpeta en una unidad de servidor. Es importante descubrir y tener en cuenta dicha gestión descentralizada de derechos antes de iniciar el cambio al sistema informático.
- Si se utiliza una ARP/RPA (Automatización robótica de procesos /Robotic Process Automation) o similar, se comprueba que los derechos de acceso del usuario del robot siguen vigentes o si es necesario restringirlos.
- Si el cambio se refiere al acceso directo a bases de datos, almacenes de archivos y similares fuera de las aplicaciones habituales con gestión de derechos, se debe garantizar que la gestión de derechos aplicable no se vea afectada por el cambio. Esto puede pasarse por alto, especialmente cuando se pasa de la prueba a la producción. Normalmente, como máximo, el administrador y posiblemente la cuenta de servicio podrían acceder a una base de datos directamente.
- En el caso de la integración entre sistemas de TI, y especialmente cuando se intercambian datos activamente, se descubre lo siguiente:
- Si la frecuencia de actualización es suficiente.
- Si se transfieren suficientes datos.
- Si los cambios pueden tener un impacto en los requisitos legales aplicables para el tratamiento, como por ejemplo si los datos se utilizan para fines no autorizados, se almacenan durante más tiempo del necesario, etc.
- Se presta atención a si los cambios en la integración pueden dar lugar a cambios no deseados en los derechos de acceso, con el riesgo de que, por ejemplo, se pueda acceder a más datos de los que deberían o que los datos necesarios para gestionar el tratamiento de otros datos hayan desaparecido. Esto podría ser, por ejemplo, una situación en la que se experimenta un error en una conexión de comunicación con una fuente de datos, razón por la cual se cambia rápidamente a una fuente de datos alternativa. Sin embargo, la fuente alternativa tiene datos desactualizados, lo que significa que se utilizan datos desactualizados en los procesos automatizado
25.3. ¿Cuándo es necesaria la medida?
Del artículo 32.1.b RGPD se desprende que las medidas pertinentes para garantizar un nivel de seguridad adecuado a los riesgos evaluados pueden incluir la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia de los sistemas y servicios de tratamiento.
La gestión de cambios siempre es relevante para un entorno de TI, software, organización, procesos de negocio, etc., incluso si el desarrollo no se lleva a cabo internamente. En el caso de TI subcontratada, los requisitos para la gestión de cambios pueden incluirse en los contratos de TI y los acuerdos de tratamiento de datos. La gestión del cambio también puede ser relevante para cambios en los procedimientos y la organización.
A continuación se muestran algunos ejemplos de escenarios en los que la gestión del cambio debe estar bajo control:
- Si la organización, posiblemente en colaboración con un encargado del tratamiento, realiza cambios en los sistemas de TI, procedimientos de trabajo, etc., entonces el artículo 32.1.b RGPD es relevante, como cualquier cambio en los sistemas de TI, procedimientos de trabajo, etc. .puede introducir errores que afecten la confidencialidad, integridad, disponibilidad o resiliencia.
- Cambiar un sistema de TI puede introducir errores si hace que los procedimientos de trabajo ya no se ajusten al sistema de TI. Por el contrario, los cambios en los procedimientos deben realizarse comprendiendo cómo funciona el sistema de TI, para que no introduzca errores.
- Los cambios en la organización también pueden introducir errores si a los nuevos empleados se les asigna un trabajo para el cual no han sido capacitados adecuadamente o que está lejos del área de enfoque normal del empleado. sistema, que no es intuitivo, en el que el empleado no está capacitado o que no está protegido contra errores del usuario.
Lo anterior muestra que el desarrollo/cambio tanto de los sistemas, procedimientos y organización de TI debe realizarse con un enfoque en la seguridad del tratamiento, y que el sistema, los procedimientos y la organización de TI deben encajar. El artículo 25 RGPD tiene como objetivo garantizar que la protección de datos esté pensada desde el diseño, y no solo en el diseño de los sistemas informáticos, sino también en el de la organización y en los procesos/procedimientos de trabajo de la organización.