RIP: Muere Paul Baran, uno de los padres de internet. Noticia aquí. Su aportación aquí.
lunes, 28 de marzo de 2011
Cloud Computing: ¿quien es el responsable de nuestros datos?
Ya hemos hablado de la importancia que el Cloud Computing tiene y tendrá en nuestras vidas y en general de sus riesgos, pero me gustaría pormenorizar en aspectos concretos.
Descripción del problema
En el uso de el cloud computing, el usuario gestiona sus datos fuera de su terminal informática y estos se almacenan en servidores de segundas o incluso terceras empresas. Esto evidentemente supone riesgos que ya vimos en el post sobre riesgos del cloud computing.
El usuario tiene derecho a:
1. Disponer de la información relativa a sus datos personales (consultar, modificar o borrar la misma).
2. Conocer en todo momento quien tiene esos datos, donde y con que finalidad.
Este último aspecto puede ser un problema ya que nos encontramos que los datos no los trata la empresa con la que hemos contratado o suscrito un servicio, sino un tercero. ¿Quien es entonces el responsable? ¿En que medida? ¿Pueden estos datos acabar en un país con un nivel de protección menor?
La LOPD y su ámbito de aplicación
El art. 2 de la Ley Orgánica de Protección de Datos (LOPD) y su reglamento aprobado por el Real Decreto 1720/2007 en el art. 3 establecen su ámbito de aplicación y haré algún comentario respecto al cloud computing:
- Cuando el tratamiento sea efectuado en territorio español en el marco de las actividades de un establecimiento del responsable del tratamiento.
¿Que es un establecimiento en el caso del cloud computing? El artículo parece referirse a un centro de procesamiento físico, lo cual puede ser hasta irrelevante en el caso del cloud computing.
- Cuando al responsable del tratamiento no establecido en territorio español, le sea de aplicación la legislación española en aplicación de normas de Derecho Internacional público.
Por interpretación del siguiente apartado se circunscribe al ámbito comunitario sujeto a la Directiva 95/46/CE.
- Cuando el responsable del tratamiento no este establecido en territorio de la Unión Europea y utilice en el tratamiento de datos medios situados en territorio español, salvo que tales medios se utilicen únicamente con fines de tránsito.
El Documento de Trabajo WP56 de 2002 del Grupo de Trabajo sobre el artículo 29 ya dictaminó que el uso de cookies (almacenados en el ordenador del usuario) servía para considerarlo medio utilizado para el tránsito.
- Cuando el establecimiento no se encuentre ubicado en territorio español, pero pero exista un encargado del tratamiento ubicado en España, serán de aplicación al mismo las normas contenidas en el título VIII del presente reglamento.
En este título VIII se establece el cumplimiento obligatorio de determinadas medidas de seguridad.
-Si el responsable del tratamiento no está establecido en el territorio de la Unión Europea, pero utiliza medios situados en territorio español, este responsable del tratamiento debe designar un representante establecido en territorio español.
Lo que de ser efectivo facilita la identificación del responsable.
-Y por establecimiento hay que entender cualquier instalación que permita el ejercicio efectivo y real de una
actividad, con independencia de la forma jurídica adoptada.
actividad, con independencia de la forma jurídica adoptada.
Así, la determinación del responsable esta bastante delimitada legalmente, lo cual no significa que sea fácil o incluso posible de forma efectiva en todos los casos, pero ¿qué sucede cuando los datos son tratados por un tercero?
El art. 12 de la LOPD y los arts. 20 a 22 de su Reglamento regulan la relación entre el responsable y ese tercero.
La cesión de datos esta admitida legalmente en el 12.1: "no se considerará comunicación de datos el acceso de un tercero a los datos cuando dicho acceso sea necesario para la prestación de un servicio al responsable del tratamiento", mediante un contrato en el que se especificará "únicamente tratará los datos conforme a las instrucciones del responsable del tratamiento, que no los aplicará o utilizará con fin distinto al que figure en dicho contrato, ni los comunicará, ni siquiera para su conservación, a otras personas".
El art 20.2 nos dice que será el responsable del tratamiento el que deberá controlar que el tercero que trate estos datos lo hace conforme al reglamento, incluso si este tercero, habilitado por el propio responsable, subcontrata a otra empresa para tal función.
Es decir, seguimos teniendo al responsable identificado y este será enjuiciable en España.
En breve, una referencia al Movimiento Internacional de Datos.
Para saber mas:
WP56 de 2002 del Grupo de Trabajo sobre el artículo 29
sábado, 26 de marzo de 2011
El HTTPS no es infalible: los grandes son atacados, puede que constantemente
Explicamos el otro día que las conexiones HTTPS aportan un extra de seguridad a las conexiones, pero ojo, no son infalibles.
Los grandes de internet: atacados
Hace un par de días, Jacob Appelbaum, creador del interesante proyecto de anonimato online TOR e investigador de seguridad, denunciaba que había descubierto un ataque MAN-IN-THE-MIDDLE que había afectado afectaba a grandes compañias como Google o Yahoo. Mediante un falso certificado, un servidor iraní estaba recibiendo las claves privadas que encriptan las contraseñas, así como el resto de paquetes por lo que podría extraerlas.
El ataque fue solventado sin ser hecho público, mediante actualizaciones en los principales navegadores para que no aceptaran esos certificados.
Luz y taquígrafos
COMODO, empresa dedicada a servicios de seguridad informática (antivirus, firewalls) y proveedor de certificaciones SSL, el certificador suplantado, al parecer desde un servidor iraní, publicó información sobre el ataque sufrido el día 15 de marzo mediante un post en su blog (accesible aquí). 8 días después del ataque.
El HTTPS no es infalible
El hecho de que los navegadores tengan listas de certificados no autorizados es evidencia de que estos ataques se producen continuamente.
Sin embargo el modo de atajarlos es ciertamente preocupante, ya que dependen de una actualización del navegador por parte del usuario, actualización que no es forzada en ningún caso sino meramente recomendable. Es decir, los usuarios pueden quedar expuestos durante mucho tiempo.
Parece que el método de listas de certificados revocados, que en todo caso deberán haber sido incluidas en una actualización del software, como si fuera un error del mismo en lugar de un ataque, no convence a los expertos en seguridad. De hecho, si el cracker esta capturando los paquetes del usuario, en todos los navegadores recibe las claves privadas.Es decir, los ataque dirigidos (al contrario de los aleatorios y en cualquier caso los más peligrosos) no se evitan con estas técnicas.
La proliferación de Certificadores no ayuda, The EFF SSL Observatory ha denunciado la existencia de 650 certificadores sospechosos autorizados por Microsoft y Mozilla.
El principal problema y puede que la solución es que los certificados tienen largas vigencias (1 año o más). Si esta fuera de unos pocos días se minimizarían los riesgos a cambio de una pequeña molestia al usuario (aceptación de certificados). Así que el panorama esta avocado al cambio, o eso espero.
Para saber más:
viernes, 25 de marzo de 2011
OJO: El canon no es ilegal, sino su reglamento
La sentencia que ha llenado los medios de comunicación solamente castiga defectos de forma en la promulgación del reglamento que extendió el canon a dispositivos antes exentos, como los discos duros o los teléfonos móviles.
martes, 22 de marzo de 2011
HTTPS ¿Qué es? ¿Por qué no se usa en todas las conexiones?
Hace unos días mencioné de pasada el HTTPS en el post sobre Riesgos del Cloud Computing. No es un sistema novedoso, y funciona la mayor parte de las veces de forma invisible para el usuario. Pero empecemos por el principio.
¿Qué es HTTP?
Estas siglas significan Hipertext Transfer Protocol o Protocolo de Transferencia de Hipertexto y es uno de los pilares sobre el que descansa la web (World Wide Web) actual.
De forma llana y entendible, el HTTP es un lenguaje para preguntas y respuestas sobre el que se sostiene toda la información que hay en internet. Así cuando yo quiero entrar en una página web mi ordenador hace una pregunta al servidor en el que según el servidor de DNS esta está almacenada y este me responde enviándome la información solicitada si tiene esa información. Así de sencillo y así de vital.
Es un protocolo sin memoria, es decir, el no contiene información del usuario que hace la petición. Y hay día muchas aplicaciones web necesitan reconocer nuestro estado (quienes somos, que hemos hecho en esa web, etc). Para solucionar esto existen los cookies (concepto que me es necesario para un próximo post sobre la nueva regulación de la UE sobre privacidad) en la que el servidor que contiene la web almacena información del ordenador cliente que hace las preguntas o peticiones. Para que os hagáis una idea, cuando accedéis a vuestro email desde vuestro ordenador puede que os reconozca como usuarios (y os pida la contraseña) o incluso que os de acceso inmediatamente. Eso es gracias a una cookie que se envía junto a la petición aportando dichos datos.
¿Qué peligros tiene el HTTP?
Pues principalmente que alguien puede estar escuchando esa pregunta a la que añadimos una cookie con nuestra información, bien sea de forma pasiva (Eavesdropping) o de forma activa (Ataque Man-in-the-middle) ya que nuestro mensaje pasa por muchos puntos. Aunque a priori la información puede estar cifrada, si se captura la clave pública que usa el servidor, es posible modificar el mensaje para que un intermediario se convierta en receptor de una información privada.
Por ejemplo: Imaginen la banca online sin protección (tranquilos que ya no existe):
- Juan quiere comunicar con su Banco y Ladrón quiere obtener información.
- Para iniciar la conversación Juan pide a Banco la Clave Pública que usa con el.
- Ladrón intercepta la respuesta de Banco.
- Ladrón modifica el mensaje usando una Clave Pública distinta y lo envía a Juan falseando identidad.
- Este cree recibir respuesta del banco y responde enviando su Clave Privada (su contraseña) a Ladrón.
- Ladrón recibe Clave Privada de Juan y puede iniciar proceso con el banco.
Cuidado con Firesheep y las redes públicas
No me cansaré de decirlo, si hace unos años usar un sniffer no era muy complicado (yo hice pruebas capturando mis propias conversaciones de Messenger con Wireshark y algún plugin) hoy es simplemente sencillísimo con aplicaciones como Firesheep, una extensión de Firefox con la que podemos obtener todas las contraseñas no seguras usadas en nuestra red o en una red pública.
¿Qués es HTTPS?
Pues una forma de crear una comunicación segura en una red insegura. Para ello esta comunicación esta avalada por una Autoridad de Certificación en la que nosotros confiamos.
¿Qué mejoras de seguridad supone el HTTPS?
Pues principalmente los siguientes:
1º Tenemos un navegador que reconoce a la autoridad de certificación.
La barra de direcciones del navegador suele mostrar un icono distinto cuando estamos en una conexión HTTPS. Y si pulsamos en ella nos da información adicional sobre la autoridad.
2º El Administrador de la Web a la que accedemos obtiene un Certificado de Clave Pública.
Así, en caso de que una Clave Pública no este identificada como Certificada por la Autoridad de Certificación, nuestro navegador desplegará una alerta.
3º SSL y TLS, el lenguaje de preguntas y respuestas va encriptado.
La comunicación comienza con una mediación con la Autoridad de Certificación para establecer como la pregunta y la respuesta va a ser encriptada (ambos extremos debemos conocer el método y las claves).
Para ello, cuando preguntamos (clientHello) nuestro navegador añade información sobre que tipos de encriptación soporta y este nos responde (serverHello) con la encriptación elegida. Después, por medio de la Autoridad de Certificación se nos concede o bien una Clave Simétrica para ambos o bien una Clave Pública compartida para descifrar una nueva Clave privada.
Y debajo de estas técnicas de cifrado esta el HTTP, es decir, la pregunta y la respuesta.
4º En ocasiones se garantizan que todos los nodos por los que ha pasado el paquete de datos son seguros.
¿Por qué no todo internet funciona con HTTPS?
Esta claro que una comunicación segura es mejor que una que no lo es, y aunque va creciendo el número de comunicaciones que usan el HTTPS, la gran mayoría de estas se producen sin ella. Las razones son enumerables:
1º Alto coste de los certificados de seguridad.
Las Autoridades de Certificación no son gratis, por ello es normal que los comercios y la banca online, o las grandes corporaciones de internet las utilicen pero no las pequeñas y medianas webs.
(Edito: En comentarios un lector nos indica que hay una entidad de certificación con un plan gratuito. Grácias por la información).
(Edito: En comentarios un lector nos indica que hay una entidad de certificación con un plan gratuito. Grácias por la información).
2º El HTTPS no produce caché de datos.
Lo que hace que, especialmente cuando accedemos a webs alojadas en servidores lejanos (piensen en datos que tienen que recorrer medio mundo), todo el contenido tenga que ser reenviado, cuando la web normalmente almacena una serie de datos fijos que dan una velocidad aparente a nuestro navegador.
3º La negociación SSL inicial añade retardo.
Si la seguridad no es esencial, solemos preferir la velocidad.
4º No es usable en los Servidores Virtuales.
Esto es algo técnico, pero imaginemos que yo alquilo un espacio de servidor en una gran empresa de servidores y desde el gestiono a nivel software mi propio servidor. Esta es una práctica habitual. No esta bien solucionada la posibilidad de usar HTTPS (si mediante extensiones TLS pero de forma parcial).
¿Que hacer para evitar Firesheep y otros sniffers?
Hay varias extensiones que fuerzan el uso del HTTPS en los servidores que lo admitan. Muchas webs la ofrecen pero no la utilizan por defecto para maximizar la velocidad.
Mas seguro que estos es usar una VPN (Red Privada Virtual) de la que ya hablé el pasado mes (enlace aquí).
Para saber más:
Suscribirse a:
Entradas (Atom)