25 Enero, 2022 Cómo se aborda la seguridad del dato en proyectos ML La seguridad en proyectos ML suele ser una cuestión que preocupa a las empresas antes de implantar estas soluciones. Explicamos las claves para conseguirla. Cumplir con el RGDP es una cuestión vital para todas las empresas. Pero no solo por mandato normativo. En un mundo conectado y global, lo relacionado con la seguridad del dato se convierte en una prioridad en cualquiera de los ámbitos. Ocurre con más frecuencia en las grandes empresas, más concienciadas con las implicaciones que podría tener un fallo de seguridad. Por ello, no es de extrañar que sea una de las primeras cuestiones que se plantean a la hora de llevar a cabo cualquier proyecto. Y que se volverá más complejo conforme mayor sea el volumen de datos que se necesite. Esto es justo lo que ocurre con los proyectos de Machine Learning. En efecto, los modelos de entrenamiento automático (ML) requieren de grandes cantidades de información. En muchos casos, además, estos datos son bastante sensibles, por lo que han de protegerse tanto en su almacenamiento como a la hora de ser procesados. Google ofrece una infraestructura en la nube de confianza, una seguridad que extiende a los proyectos de ML que se desarrollan en su plataforma (GCP). Pero, una cosa es cómo Google almacena la información, de forma encriptada y asegurando que sólo las personas autorizadas pueden acceder a ella, y otra cómo se asegura el acceso a dichos datos. Es decir, a la hora de abordar la seguridad en proyectos de ML es necesario determinar la lógica que aplicaremos a ese acceso: qué roles se crearán, quiénes serán las personas que podrán acceder... Por otro lado, ha de atenderse a la seguridad del transporte de los datos desde el origen hasta el lugar de almacenamiento. Como se explicaba anteriormente, en GCP todo el transporte está encriptado, pero hasta llegar hasta allí, los datos deberían ser transportados utilizando Transport Layer Security (TLS). Sin embargo, mientras que la seguridad suele ser una cuestión más o menos estándar, en la privacidad influyen multitud de factores: país, tipo de proyecto, problema a solventar… Por todo ello, cada caso necesita un estudio completo en materia de privacidad. Este estudio debe responder cuatro preguntas principales: ¿Qué datos deben recogerse? ¿Cuáles son los usos permitidos? ¿Con quién o quiénes se puede compartir? ¿Qué modelo de control de acceso granular es apropiado? ¿Qué datos deben recogerse para nuestra solución ML? Tendemos a pensar siempre que la calidad está ligada a la cantidad. Por eso en ocasiones erróneamente se intentan recopilar cuantos más datos se puedan. Pero lo más correcto es plantear cuáles se necesitan para la solución que vamos a desarrollar. Recopilar más datos de los que requiere el proyecto de ML implica sobrecostes: Necesidad de mayor almacenamiento Exigencia de anonimización de los datos procedentes de las diferentes fuentes De este modo, es clave detectar y definir qué datos se pueden recoger. Después habrá que decidir cuáles y cómo se van a reunir. Recabar todos los datos y luego decidir no es una buena práctica. Estudia el problema y decide qué información necesitarás para la solución. ¿Qué usos se permiten? El uso al que van destinados los datos tiene que quedar definido desde un primer momento. El motivo es que al facilitar sus datos, los usuarios dan permiso para manejarlos con un determinado fin, por lo que no pueden ser usados para algo diferente a lo que expresaba dicho consentimiento. Utilizar los datos de forma no autorizada para un proyecto de ML acarreará problemas legales. Para aclarar este asunto de los usos permitidos, pongamos como ejemplo una empresa hotelera. Dicha empresa proporciona un conjunto de datos con todas las reservas. El objetivo es buscar métricas para apoyar al equipo de Marketing en sus campañas. En este caso no se podría utilizar el conjunto para analizar ninguna otra cosa más. ¿Con quién podemos compartir los datos? Otro punto importante referente a la privacidad de la información recopilada es a qué aplicaciones y usuarios podemos transmitirlos. Las personas que ofrecen sus datos son las únicas dueñas de los mismos y sólo ellas deben poder acceder. De hecho, siempre tendrán la posibilidad de revocar el acceso de nuestros sistemas a esos datos. Pero, si sólo ellos tienen acceso ¿cómo vamos a analizar esa información? La respuesta es a través de la anonimización. Hacer anónimos los datos es el paso previo a cualquier tiempo de tratamiento o análisis. Sin embargo, para llegar a ese punto es necesario al menos un usuario –o grupo de usuarios– con acceso a los datos para que pueda transformarlos en anónimos. La anonimización de los datos reduce, además, el riesgo de divulgación involuntaria cuando se comparten datos entre países, sectores e incluso departamentos de una misma empresa. Para esta tarea hay una herramienta que detecta y evita que se compartan datos no anonimizados: la API de Prevención de Pérdida de Datos en la Nube (DLP). Esta API detecta datos como números de tarjeta de crédito, números de teléfono, correos electrónicos, etc y posee funciones propias para convertirlos en anónimos. La herramienta permite, incluso, crear detectores propios para nuestro proyecto específico. Asegurar el control de acceso En cuanto a cómo asegurar el control de acceso, Google Cloud Storage permite dos modos: Usando los Permisos IAM. Aunque puede funcionar bien, esta solución está más orientada a gestionar y conceder roles. Si lo que necesitamos es que otras aplicaciones (como por ejemplo BigQuery) accedan a datos, debemos hacerlo mediante “cuentas de servicio”. Utilizando cuentas de servicio. Esta opción está enfocada a que servicios externos puedan acceder a los datos. Puede combinarse con los permisos IAM, ya que estos establecen los roles y se asignan a cada cuenta de servicio. Si un servicio no necesita acceder a los datos, puedes revocar fácilmente las concesiones. No obstante si un servicio va a acceder a los datos durante un corto periodo de tiempo se pueden usar las “cuentas de servicio de corta duración” que son cuentas con caducidad. De esta forma, los datos quedan protegidos en caso de que olvidemos revocar los servicios para dicha cuenta. Otras variables a tener en cuenta La seguridad no sólo se basa en el acceso IAM, también en las variables “env” o cualquier dato extra necesario. Lo más conveniente es que estos se encuentren en el GCP Secret Manager, sobre todo para los datos extra requeridos que la app necesita. Por otro lado, en ocasiones es recomendable utilizar Vault en un clúster HA GKE privado para almacenar nuestros secrets privados. Además, este puede conectarse con nuestro login de GitHub, que tiene factor de doble autenticación, para organizar dichos secrets por equipos.
