{"id":3741,"date":"2017-06-12T11:35:29","date_gmt":"2017-06-12T18:35:29","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=3741"},"modified":"2017-06-12T11:35:29","modified_gmt":"2017-06-12T18:35:29","slug":"putting-zipper-back-hospital-gown","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/putting-zipper-back-hospital-gown\/","title":{"rendered":"C\u00f3mo poner una cremallera en la espalda de la bata de hospital"},"content":{"rendered":"

La semana pasada, la empresa de seguridad Appthority public\u00f3 un informe titulado<\/span> HospitalGown: La exposici\u00f3n del backend que pone en riesgo los datos de la empresa<\/span><\/a>que destac\u00f3 <\/span>vulnerabilidades reci\u00e9n descubiertas <\/span><\/a>entre aplicaciones m\u00f3viles y bases de datos backend inseguras que contienen datos de la empresa. La vulnerabilidad no est\u00e1 causada por el c\u00f3digo de la aplicaci\u00f3n, sino por el hecho de que los desarrolladores de la aplicaci\u00f3n no protegen adecuadamente los servidores backend con cortafuegos y autenticaci\u00f3n.<\/span><\/p>\n

Appthority cit\u00f3 una serie de exposiciones en m\u00faltiples plataformas backend, con una primera iteraci\u00f3n del informe mencionando Couchbase. Sin embargo, despu\u00e9s de una revisi\u00f3n posterior, los investigadores se dieron cuenta de la inclusi\u00f3n inadvertida y ofrecieron la siguiente declaraci\u00f3n a Couchbase:<\/span><\/p>\n

Aunque nuestro equipo de investigaci\u00f3n analiz\u00f3 los servidores Couchbase encontrados en la naturaleza, descubrimos que todos requer\u00edan autenticaci\u00f3n... Couchbase aparec\u00eda en la lista de forma inexacta cuando en realidad se refer\u00eda a un proveedor de alojamiento CouchDB.<\/span><\/i><\/p>\n

Se trata de la misma autentificaci\u00f3n sobre la que mi colega Wayne Carter escribi\u00f3 en un blog anterior titulado<\/span> Seguridad de los datos descentralizados con Couchbase Mobile<\/span><\/a><\/p>\n

La seguridad es una previsi\u00f3n para Couchbase - algo que hemos incorporado desde el principio en lugar de a\u00f1adirlo a posteriori. Construirlo de esta manera tambi\u00e9n ayuda a aliviar la carga del desarrollador.<\/span><\/p>\n

En cuanto a la autenticaci\u00f3n, es compatible con la autenticaci\u00f3n conectable, incluida la compatibilidad inmediata con los proveedores de inicio de sesi\u00f3n p\u00fablicos m\u00e1s conocidos, como Facebook, y los proveedores est\u00e1ndar de OpenID Connect (OIDC). Adem\u00e1s, los desarrolladores pueden escribir su propio proveedor personalizado. Los desarrolladores tambi\u00e9n pueden restringir el acceso al sistema a los usuarios autenticados correctamente u, opcionalmente, permitir usuarios an\u00f3nimos.<\/span><\/p>\n

Pero espera, hay m\u00e1s.<\/span><\/p>\n

Como Wayne escribi\u00f3 anteriormente, existe la expectativa de que las aplicaciones funcionen siempre, con y sin conexi\u00f3n a Internet. Cumplir esta expectativa requiere el acceso y almacenamiento de datos descentralizados directamente en un dispositivo. La gesti\u00f3n de datos descentralizados introduce una serie de riesgos de seguridad que es fundamental gestionar, que es lo que descubrieron los investigadores de Appthority. Adem\u00e1s de la autenticaci\u00f3n del usuario, existen otras cuatro preocupaciones clave en materia de seguridad cuando se trabaja con el almacenamiento y el transporte de datos:<\/span><\/p>\n