|
Considere los siguientes consejos de GDPR, en relación con la eliminación de datos personales: •El artículo 17 de GDPR (derecho a la supresión / al olvido), hace hincapié en la posibilidad de que las personas hagan suprimir sus datos personales y dejen de ser utilizados por un Controlador de Datos. |
Las personas pueden optar por no participar en cualquier momento, de modo que los datos personales se borren y dejen de ser gestionados para el propósito declarado por el Controlador de Datos.
Sin embargo, y dado que los datos personales pueden residir tanto dentro de los casos de procesos como en relación con los registros de la entidad WFUser, nunca se deben borrar los registros per se (por ejemplo, la eliminación de registros puede terminar produciendo problemas de integridad de los datos, en relación con las referencias en otros registros).
Se recomienda encarecidamente ofuscar los datos en su lugar, como se describe a continuación.
Ofuscación de datos
La ofuscación de datos es una forma de enmascarar los datos para que sean codificados y hechos ininteligibles a propósito.
Es una medida útil que resulta en la encriptación de datos sensibles y mitiga el acceso no deseado a ellos.
Con el fin de ofuscar los datos, Bizagi ofrece diversas opciones, entre las cuales hay una opción para los administradores en el Portal de Trabajo, y nuevas funciones en las reglas de API.
Todas ellas deberán ser consideradas de acuerdo a sus procesos y a las solicitudes de los individuos.
Consulte cómo ofuscar los diferentes datos y escenarios como se describe a continuación.
1. Ofuscar los datos personales de los usuarios finales
Existe una opción en el Portal de Trabajo que permite a un administrador autorizado ofuscar manualmente la información de un determinado usuario final.
Observe que esto sólo es aplicable a los usuarios finales que trabajan en procesos (los registrados en la entidad WFUser).
El procedimiento ofusca todas las propiedades de usuario por defecto de Bizagi. Es decir, las propiedades de usuario personalizadas no son ofuscadas.
Para utilizarlo, un administrador debe navegar al menú de Administración de usuarios y buscar al usuario deseado:
A continuación, haciendo clic en el icono "Anonimizar", el administrador procede a confirmar si desea ofuscar los datos personales relacionados con este usuario:
Considere que una vez que confirme, esos datos se volverán ininteligibles sin posibilidad de deshacerlos.
Aunque la imagen del usuario final se establezca como null, tendrá que solicitar un ticket para borrar el archivo de imagen física en su almacenamiento en la nube.
Para obtener más información al respecto, consulte la siguiente sección sobre Ofuscación de archivos y anexos.
2. Ofuscar los datos personales de otras personas
Recuerde que "otros individuos" en este contexto significará cualquier otro Sujeto de Datos que participe en sus procesos, que no trabaje realmente en los procesos de su organización pero que forme parte de los registros introducidos en el sistema (en entidades maestras).
Ejemplos de ello son: los contactos de un contratista o proveedor, los usuarios/clientes generales o los pacientes de atención de la salud, etc.
Para ofuscar los registros que tienen datos sensibles, es necesario establecer la información como null.
También puede diseñar un proceso separado para este propósito.
A través del nuevo proceso necesitará un control de búsqueda para examinar y buscar datos sensibles en las entidades maestras y atributos que haya diseñado para tal fin.
Esto incluye cualquier dato que pueda tener en las entidades de las Personas también.
Al encontrar un registro, y para los casos abiertos, puede confiar en Xpath para que las reglas puedan fijar su valor en null.
Como alternativa y para los casos cerrados, deberá confiar en la función CHelper.setAttrib() para fijar su valor en null (incluyendo cualquier atributo de archivo que almacene los archivos adjuntos del caso).
Esto cubre parcialmente el requisito y también tendrá que considerar si esos datos están vinculados a archivos físicos adicionales y a archivos adjuntos en su sistema de ECM (por ejemplo, imágenes, capturas de pantalla, documentos personales, informes, etc.).
Si desea obtener más información al respecto, consulte la sección siguiente sobre la Ofuscación de archivos y anexos.
Por otra parte, habrá que considerar en ese mismo proceso de Bizagi, que se ofuscan los datos que se almacenan en los registros del sistema Bizagi.
Estos registros contienen información sobre los cambios realizados en los atributos que usted identifica como poseedores de datos sensibles.
Esto se hace para ofuscar los registros mostrados que tienen valores iniciales y valores modificados para datos sensibles.
Para hacer esto, usted puede confiar en las siguientes dos funciones de la clase CHelper de la API de reglas de Bizagi como se describe a continuación.
FUNCIÓN (firma) |
PARÁMETROS DE ENTRADA |
PARÁMETROS DE SALIDA |
OBJETIVO |
|---|---|---|---|
string CHelper.GetEntityLog (string entityName, string attribName, int surrogateKey) |
Es obligatorio enviar: •entityName: Una cadena de caracteres que especifica el nombre de la entidad maestra cuyo registro obtendrá. •attribName: Una cadena que especifica el nombre del atributo de la entidad maestra dada, cuyo registro se obtendrá. •surrogateKey: Un número entero que especifica el ID interno que identifica de manera única un registro de esa entidad maestra dada. |
Devuelve una cadena con un registro en formato JSON que tiene cualquier número de registros, donde cada registro detalla: [{"entityName":"Customer","attribName":"Email","value":"john.doe@agilityCorp.com","date":"06/12/2018 17:03:36"}]
En caso de que no se encuentre un registro (por ejemplo, para un valor de surrogateKey que no tenga coincidencias), entonces se devuelve un archivo JSON vacío. |
Esta función tiene como objetivo ayudarle a consultar el registro de la entidad que necesita antes de ofuscar realmente sus datos.
También puede utilizarla después de "anonimizar" el registro si desea validar que efectivamente ofuscó los datos. |
void CHelper.AnonymizeEntityLog (string entityName, string attribName, int surrogateKey) |
Es obligatorio enviar: •entityName: Una cadena de caracteres que especifica el nombre de la entidad maestra cuyo registro anonimizará. •attribName: Una cadena que especifica el nombre del atributo de la entidad maestra dada, cuyo registro se anonimizará. •surrogateKey: Un número entero que especifica el ID interno que identifica de manera única un registro de esa entidad maestra dada. |
No devuelve la información (nulo). En caso de un error durante su ejecución, se lanza una excepción.
|
Esta función ofusca los datos en el registro de la entidad aplicable. Debe utilizarse con precaución, dado que su uso no puede deshacerse. |
Para las dos funciones anteriores, se sugiere que en su proceso separado, obtenga el .Id para el registro que localice a través de un control de búsqueda.
De esta manera, el .Id de ese registro se usaría como el surrogateKey que se necesita como parámetro de entrada.
Considere que ambas funciones esperan explícitamente el nombre de un atributo. Para su uso con más atributos, sería necesario utilizar las funciones varias veces.
|
Otras excepciones lanzadas por las funciones anteriores se producirán si: •La entidad no es una entidad maestra o no existe (por ejemplo, está mal escrita). •El atributo especificado no pertenece a esa entidad especificada. |
3. Ofuscar los archivos y los anexos
Los archivos y anexos son en su mayoría aplicables a "otras personas", como se ha tratado anteriormente.
Sin embargo, la eliminación de los archivos físicos del almacenamiento en la nube debe hacerse solicitando un ticket de soporte.
Para eliminar los archivos físicos, primero considere si los está almacenando en el almacenamiento en la nube (tratamiento predeterminado) o en un sistema de ECM.
De lo contrario, administre su sistema de ECM para eliminar los archivos y los anexos allí.
Además de lo anterior, recuerde que también es necesario un proceso para establecer la información de los atributos del archivo como null, de modo que los datos personales se dejen sin límites/sin conexión a los registros del sistema.
Conclusión
La eliminación de los datos personales debe estar bien definida dentro de las políticas de seguridad de su organización, incluidas las leyes, normas o reglamentos locales que le sean aplicables.
Es necesario que usted determine el plazo en el que se eliminarán los datos personales que ya han completado su ciclo en el sistema.
Una medida recomendada para ayudar a hacer cumplir lo anterior es diseñar un proceso en Bizagi que lleve a cabo dicha eliminación de los datos personales presentes en los atributos y entidades involucradas de su modelo de datos de procesos, de modo que dicho proceso pueda activarse a petición de una persona determinada, o que pueda ejecutarse periódicamente siempre que sea estrictamente necesario para cumplir con dichas medidas.
Cuando se diseñe el proceso como se ha sugerido anteriormente, se puede confiar en el uso de la función CHelper.AnonymizeEntityLog() de la API de reglas de Bizagi.
Sin embargo, también puede necesitar procedimientos manuales complementarios en Bizagi, tales como aquellos que consideran la eliminación de archivos físicos y archivos adjuntos, otras opciones de administración, y otros procedimientos que se aplican a su negocio específico, procesos y políticas dentro de su organización; como considerar la eliminación de información en material físico si es aplicable.
|
En cuanto al servicio de Automation, considere que los datos pertenecen completamente al cliente. Por lo tanto y ante una eventual terminación del contrato, Bizagi, como proveedor de servicios, junto con sus asociados de negocios de IaaS (Microsoft Azure) implementa procedimientos que imponen la eliminación segura de datos. Esos procedimientos entrañan políticas y controles tales como: •Los medios físicos no salen de los centros de datos en ningún momento y se destruyen in situ siguiendo procedimientos rigurosos que implican un borrado enérgico. •Los datos almacenados se dividen en múltiples discos físicos usando un sistema estructurado de registro. •Se establecen controles lógicos para asegurar que los datos no queden expuestos cuando los sectores de los discos se reescriban posteriormente. •Los datos no se descargan en ningún momento en ordenadores portátiles u otros dispositivos, ni por el personal de Azure ni por el de Bizagi. •Los clientes pueden solicitar una prórroga por un período de 60 días después de la fecha efectiva de terminación, que los datos del cliente se mantienen. •Los procedimientos de desidentificación tienen lugar siempre que el cliente autoriza el uso de una copia de seguridad de su entorno para el soporte técnico, de modo que no haya datos reales en tales escenarios de resolución de problemas. •Las políticas y procedimientos en Bizagi están en vigor para hacer cumplir que el personal autorizado a conectarse a los entornos en la nube, tenga: ningún datos del cliente en las computadoras portátiles, tecnología de disco encriptado (es decir, BitLocker), acceso revocado y datos borrados de manera segura de las computadoras portátiles al momento de la salida, entre otros. |
Last Updated 7/18/2023 9:29:23 AM