Una de las cosas más importantes cuando trabajamos en un proyecto de Machine Learning es saber cómo asegurar la privacidad y la seguridad de toda la información. Para empezar, debemos hacernos una visión global tanto de la seguridad como de la privacidad - ya que hay maneras distintas de abordarlo - y para finalizar comentaremos cómo solucionarlo con casos de éxito reales.

Seguridad

Por un lado, tenemos el reto de la seguridad de los datos, que sin duda es algo que tenemos que abordar y pensar sobre ello. Aunque Google nos ayuda a mantener la información a buen recaudo gracias a Security Overview, hay que tener en cuenta cómo almacena Google esa información - encriptada, para asegurar que solo tengan acceso a los que les sea permitido, etc. - Nos centraremos en cómo asegurar el acceso a por ejemplo: a personas concretas y darles ese acceso o incluso adjudicarse un rol, etc.

Normalmente, en un proyecto Machine Learning tenemos ya adjudicado un sitio dónde toda esa información ya está almacenada por ejemplo: Google Cloud Storage - y desde el punto de vista de la seguridad es importante asegurar:

1. Que toda la información está en encriptada y guardada
2. El transporte de información

El primer punto, trata de cómo los datos están guardados, por defecto Google Cloud los maneja a la perfección usando un algoritmo asimétrico para encriptar toda la información con las claves que google  o el usuario podrán manejar.

Hablando del transporte de información, toda la información se debería enviar usando TLS - Si no el transporte no será seguro y quedaría expuesto durante el tráfico desde el origen hasta llegar a Google Cloud Storage. Sin embargo, gracias al GCP  el transporte está encriptado.

Privacidad

Por otro lado, contamos con el reto de privacidad, que aparentemente se tiene menos  en consideración pero no por ello es menos importante, al contrario lo es más que la seguridad. ¿Por qué es más importante? Porque normalmente cambia dependiendo del problema o el país y la seguridad es bastante similar en la mayoría de los casos.

En un proyecto de Machine Learning, cuando hablamos de privacidad, nos centramos en:

1. ¿Qué tipo de data deberíamos recolectar?
2. ¿Cuáles son los usos permitidos?
3. ¿Con quién lo compartirías (usuarios, apps, etc)?
4. ¿Qué modelo de acceso granular es el más apropiado?
5. ¿Qué tipo de datos deberíamos recolectar?

Lo más fácil es recolectar lo máximo que sea posible, pero deberías recolectar siempre sólo la información que realmente sea necesaria, si de verdad sabes la que necesitas. De otra manera es recolectar por recolectar, y con este abordaje se convertiría en incertidumbre. Pero si ese es el caso, la raíz del problema es que desde el inicio estarías recolectando datos de una manera innecesaria que además no te servirían para nada. Por lo tanto implicaría un doble coste ya que no solo tendrías que guardarlo sino también asegurar la privacidad mediante anonimización de la información y así emplearla en fuentes diferentes.

La clave está en estudiar el problema y observar qué tipo de información podemos recolectar, después decidir cuál y cómo podríamos guardarla. Existen casos en los que tienes que guardar todos los datos y después de un primer análisis, decidir con cuál te quedas, sin embargo no es una forma óptima de ejecutarlo ya que sin un estudio preliminar no sabrás con certeza cuál será el resultado y para este tipo de problemas la incertidumbre no es un buen abordaje.

¿Cuáles son los usos permitidos?

Los usos permitidos tienen que estar claros desde el inicio del proceso. Por ejemplo, si una compañía hotelera nos proporcionará datos de reserva de su dataset con el propósito de buscar unas métricas que ayudará al equipo de marketing para realizar una campaña, eso es  permissible use. También, una de las cosas más importantes es que el usuario de permiso para poder utilizar sus datos que tengan un fin (por ejemplo investigaciones de mercado,etc) con lo que no podríamos utilizar sus datos para otra cuestión.

El uso de los datos debería de estar claro antes de empezar a trabajar en un proyecto ML porque usar información la cual no tenemos permiso previo, podría llevarnos a problemas legales.

¿Con quién lo compartirías (usuarios, apps, etc)?

Este punto es importante porque la información pertenece a los “end users” que son realmente los dueños de esos datos.  Podrán revocar el acceso de su información a nuestros sistemas. Entonces, si ellos son los que tienen acceso a la información cómo procederemos a analizar sus datos? La respuesta es simple, anonimizando los datos con el único propósito de abordar y analizar la información y para eso necesitamos solamente un usuario - o un grupo de usuarios - haciéndolo de esta manera minimizamos el riesgo cuando compartimos la información entre países, empresas o entre los propios departamentos de una empresa.

Para detectar y compartir non-anonymized data, deberíamos usar Cloud Data Loss Prevention (DLP) API ya que detecta información del tipo confidencial (tarjetas de crédito, teléfonos móviles, emails,etc) y además tiene una serie de características que te ayuda a hacerlas anónimas. La herramienta tiene una forma propia de crear identificadores de una manera muy específica para que el contenido no se comparta, de esa manera podemos crear nuestros propios detectores, dependiendo del caso.

Una vez la información está anonimizada y pueda ser tratada, esa información se puede compartir con  apps o incluso otros usuarios que tienen permitido trabajar con todo ese data. La manera más eficaz de asegurarlo es controlando el acceso. En GCloud Storage puedes abarcarlo de diferentes maneras:

1. Empleando IAM Permissions: Esta solución funciona muy bien pero está más orientada a la gestión de roles. Si necesitamos servicios para acceder a información, es mejor manejarlo utilizando service accounts.
2. Usando service accounts: Esta solución funciona cuando necesitamos servicios para acceder a dicha información - por ejemplo importar Big Query data desde el storage. Esta solución es perfecta cuando se combina con IAM permissions porque en IAM permission estableces un rol y lo asignas a cada service account. Además si un servicio no necesita acceso a información, puedes de una manera muy sencilla revocar ese acceso.

Además existe una alternativa en la que solo necesitas que se permita el acceso por un periodo corto de tiempo. En este caso, te recomendamos que utilices short-lived service accounts este tipo de servicio tiene una fecha de caducidad - de esta manera aseguras que toda tu información está protegida si se te olvida revocar dichos permisos a ese servicio en concreto.

Usando service accounts: Esta solución funciona cuando necesitamos servicios para acceder a dicha información,por ejemplo importar Big Query data desde el storage. Esta solución es perfecta cuando se combina con IAM permissions porque en IAM permission estableces un rol y lo asignas a cada service account. Además si un servicio no necesita acceso a información, puedes de una manera muy sencilla revocar ese acceso.

Ejemplo de cómo aplicar la seguridad y la privacidad en un caso real

Hemos hablado de cómo abordar seguridad y privacidad. Ahora vamos a emplearlo en un proyecto real para que podáis entenderlo mejor. Para empezar, el proyecto tiene un extra request, es un proyecto para una empresa alemana. Así que necesitamos emplear la información en una GDPR compliant way (la información no debería salir de la Unión Europea). Además esta empresa tampoco quiere usar la información más allá de sus fronteras así que tendremos que almacenar todos esos datos en el data center que tiene Google Cloud en Alemania (europe-west3).

Necesitamos crear un cubo donde almacenar todos esos datos. Este cubo abordará toda la información, y después de haber sido identificada, se almacenará en otro cubo, que este final será dónde podrán acceder los servicios. Los dos cubos serán regionales (necesitamos recuperar datos con mucha frecuencia) estos los podrás localizar en europa-west3.

Como mencionamos anteriormente, nos quedaremos con el cubo de datos. Después tendremos que analizar toda esa información utilizando Data Loss Prevention API y mirar información sensible por si tuviera que ser anonimizado. Dependiendo de la frecuencia de cada cuanto se actualicen los datos en bruto. Y eso tendrás que tenerlo en cuenta cuando utilices DLP API para detectar esa información sensible. Si has utilizado detectores  infoType por defecto,  te pueden salir falsos positivos (como el proyecto que detectaba las licencias de los conductores en Canadá y daban falsos positivos como resultado).

Una vez se encuentre esa información sensible, puedes automatizar el re-identificador de data sensible utilizando las funciones de Cloud - pudimos utilizar Cloud Function porque la compañía nos permitió utilizar el data center que está en Bélgica solo para la transformaciones pero si no fuera posible, puedes abordarlo, empleando un “compute engine” en europe-west y exponiendolo como si tuviera una funcionalidad flask.

Enlazando la función cloud al “bucket”

La Función Cloud se lanza cuando un elemento nuevo se crea en el bucket, dónde la información en bruto se actualiza.

De-Identifying options

Existen maneras diferentes de re-identificar datos. Esta en concreto ha sido encriptada, utilizando una llave porque el cliente necesita recuperar la información después del análisis.

Qué datos se desidentificarán

Después del análisis de datos re-identificado, los campos que se tienen que encriptar son los que están seteados en esa variable. Si necesitáramos más, solo tendríamos que añadir más elementos.

Una vez anonimizados los datos y almacenados en otro bucket, ya podremos trabajar con ellos de forma segura. Esta transformación es imprescindible porque se tendrá que analizar el conjunto de datos completo, por ejemplo, para implementar un estimador personalizado en TensorFlow, y debemos asegurar la protección de los datos originales. A partir de este momento, el bucket original no debe quedar accesible, mientras que el bucket anonimizado es el que debe ser utilizado por los servicios que necesiten hacer uso de dichos datos.