Mega, la nueva generación de servicios cloud. Casualidad o visión

Mucho se ha escrito sobre MEGA, el nuevo servicio de Kim Dotcom y sucesor de Megaupload, desde que lo lanzara el pasado 20 de enero, justo al cumplirse un año de su detención. El objetivo de esta entrada es reflexionar sobre las características de dicho servicio pero desde una perspectiva ligeramente distinta, o al menos, eso es lo que se pretende.


En primer lugar, me gustaría llamar la atención sobre el aspecto de la fragmentación y dispersión de los contenidos puesto que creo que no ha sido tratado con la suficiente relevancia. Una de las características del servicio es que, del mismo modo que hace Google, fragmenta la información que el usuario sube a la nube y la dispersa por múltiples localizaciones, además de manera reiterativa, de forma que actúa como mecanismo de contingencia. De esta forma, Mega lo que custodia son los índices que apuntan a dichos fragmentos, de manera que cuando el usuario quiere acceder a esa pieza de información sabe dónde tiene que ir a buscar los fragmentos que lo componen para recomponerla y, además, como tiene varias copias de cada fragmento, puede acceder a la unidad que más rápido responda a la petición. En definitiva, un mecanismo que asegura que en el caso de que un centro de procesamiento se caiga, el servicio podría seguir funcionando o que si alguien accede a una de esas unidades de almacenamiento no va a poder recuperar ninguna pieza de información completa solo fragmentos "sin sentido".

Como digo, me parece un mecanismo tremendamente resiliente y que, aunque ha sido pensado para evitar que un país pueda "desenchufar" el servicio de manera unilateral (como le ocurrió a Megaupload), tiene derivadas para la seguridad del sistema que lo hacen increíblemente seguro (evidentemente la pieza clave, son los índices y quién puede acceder a ellos). Pero, lo que me gustaría destacar es su importancia en lo relativo al cumplimiento de la legislación en materia de protección de datos. Actualmente, la legislación nos obliga a saber en qué país se encuentran nuestros datos, pero… si utilizamos este sistema, ¿en qué país o países se encuentran? ¿en todos en los que Mega tiene almacenamiento? ¿en algunos? Y lo que me parece más importante, ¿realmente podemos considerar que lo que tiene Mega son datos de carácter personal? Me refiero a que si subo mi nombre (Antonio Ramos) a Mega y lo que hace el servicio (perdonad la simplificación de este ejemplo) es fragmentar esta pieza de información y almacenar la cadena ’Anto’ en Singapur y EE.UU., ’nioR’ en España y Nueva Zelanda y ’amos’ en Alaska y en Noruega… ¿realmente está ese dato en todas esas ubicaciones? ¿sólo dónde estén los índices? Creo que es una cuestión realmente relevante, porque este tipo de almacenamiento podría llegar a simplificar el cumplimiento tremendamente.

Además, si a esto le unimos, el segundo aspecto, el cifrado de la información controlada por el usuario (y observar que digo cifrado, por favor ), al margen de las mejoras que dicho mecanismo puede tener técnicamente y suponiendo que hace realmente lo que dice, es decir, que Mega no tiene acceso a la información porque está cifrada con una clave que tiene el usuario que sube la información, ¿realmente podemos considerar esa información como un dato de carácter personal? Aquí he de decir que comparto la postura de PCI-DSS en relación a este tema: Si el proveedor custodia información cifrada de la cual no tiene la clave de descifrado, no se considera que es un dato de titular de tarjeta y, por tanto, queda fuera del alcance del estándar. Por tanto, ¿no podríamos considerar que la información cifrada, siempre que no haya acceso a la clave de descifrado, no se considera dato de carácter personal y por tanto no hace falta cumplir las medidas en dichos casos?

Al igual que en el caso previo, una medida que se ha pensado para exonerar a Mega de responsabilidad sobre los contenidos, tiene una implicación de gran relevancia: La responsabilidad sobre los contenidos es únicamente de quien siempre es, de su propietario. Es decir, estamos acostumbrados a que existan dudas sobre quién debe hacer qué en los servicios en la nube y el reparto de tareas es siempre algo dudoso. Pero además de esto, incide sobre otro aspecto que a mi juicio es aún más importante. En estos días, son muchos los que hablan insistentemente sobre la necesidad de confiar en los proveedores de servicios en la nube, pero yo defiendo otra postura, directamente no confiar en el proveedor. ¿A qué me refiero? Me refiero a que cuando queremos garantizar el suministro eléctrico de nuestro CPD, contratamos dos acometidas de distintos proveedores. Esto mismo hacemos cuando queremos garantizar las comunicaciones. Y es lo mismo que hacemos con las copias de respaldo… y si lo hacemos en tantas ocasiones, ¿por qué no lo hacemos en la nube? ¿por qué ponemos todo en el mismo proveedor y pretendemos que sea infalible? ¿Desde cuándo tener un solo cliente / proveedor no es un going concern en un informe de auditoría? Evidentemente, debemos esperar una calidad de servicio razonable y tener mecanismos de penalización en caso de que no sea así y, aún más, debemos tener mecanismos que garanticen la interoperabilidad de los servicios, pero, no debemos perseguir quimeras: No podemos pretender que nuestro proveedor sea infalible.

En definitiva, pienso que Mega ha puesto el dedo en la llaga y no sé si lo han hecho por casualidad o porque son unos visionarios, pero, en mi opinión, han acertado de pleno.

Fuente: Inteco

Comentarios

Entradas populares de este blog

Descienden las detecciones de malware en Android y crecen en iOS

Explotan el día cero de la VPN de Fortinet para robar credenciales

Microsoft dice que la interrupción masiva de Azure fue causada por un ataque DDoS