Spanish

warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/taxonomy.pages.inc on line 33.

Cifrado e identidad, no todo es anonimato

Submitted by gwolf on Tue, 02/09/2016 - 13:49
Wolf G.  2016.  Cifrado e identidad, no todo es anonimato. Seminario de ética hacker, seguridad y vigilancia.
( categories: )

Fortalecimiento del llavero de confianza en un proyecto geográficamente distribuido

Submitted by gwolf on Thu, 11/19/2015 - 11:34
Wolf G.  2015.  Fortalecimiento del llavero de confianza en un proyecto geográficamente distribuido. III Congreso de Seguridad de la Información ESIMECU-IPN; Congreso de Seguridad en Cómputo UNAM.

Los contenedores: Aislamiento, sí, pero... ¿distribución?

Submitted by gwolf on Mon, 10/05/2015 - 10:40
Wolf G.  2015.  Los contenedores: Aislamiento, sí, pero... ¿distribución? Software Gurú.

Discutir acerca de mecanismos de virtualización implica cubrir una gran cantidad de tecnologías distintas. Y no me refiero con esto a diferentes proveedores que ofrecen productos con funcionalidad similar, sino que a herramientas de muy distinta naturaleza, que a veces incluso no parecen tener nada que ver entre sí.

La primera acepción que vendrá a la mente de muchos, es la virtualización asistida por hardware, donde una computadora con ciertas capacidades de hardware (disponibles en la arquitectura x86 desde hace ya diez años, y hoy presentes incluso en los CPUs de más baja gama) ejecuta un hipervisor, software específico que se ubica por debajo del sistema operativo y permite que la computadora sea compartida entre distintos sistemas operativos (o distintas instancias del mismo), aparentando ante cada uno de ellos ser una computadora independiente. Como apéndice de esta categoría entrarían los paravirtualizadores, que corren versiones de dichos sistemas operativos que saben que se ejecutarán dentro de una máquina virtual, con lo cual delegan algunos procesos al sistema anfitrión, muchas veces aumentando la estabilidad o reduciendo la penalización de velocidad.

Por otro lado, la emulación de hardware completamente distinto del sistema primario puede también considerarse virtualización. Podemos encontrarla como parte de los kits de desarrollo para dispositivos móviles, en que el código generado se compila para procesadores típicamente de arquitectura ARM, mientras que el desarrollo se efectúa sobre computadoras x86. La emulación incluso cubre a las máquinas virtuales empleadas nativamente, como la JVM (Java) o CIL (.NET): El bytecode compilado para estas arquitecturas no corre nativamente en ningún procesador, son arquitecturas diseñadas para ser siempre emuladas

Una modalidad más de virtualización es el uso de contenedores. Esta modalidad puede comprenderse mejor si se contrasta con las anteriores dónde está el engaño — O (más bonito) dónde está la magia. En vez de proveer una computadora virtual a los sistemas operativos huéspedes, los contenedores buscan proveer un sistema operativo virtual a conjuntos de programas.

¿Qué significa esto? Que a cambio de reducir la flexibilidad, esta modalidad de virtualización provee un mucho mejor rendimiento (las aplicaciones virtualizadas tienen exactamente la misma velocidad que en el hardware nativo) y menor impacto en el resto del sistema (cuando los procesos que forman parte del contenedor no tienen trabajo por realizar, su consumo de recursos es verdaderamente cero, a diferencia de un sistema virtualizado, que debe seguir pendiente a posibles eventos).

La reducción de flexibilidad referida consiste en que, dado que el núcleo del sistema operativo en ejecución es uno solo, todos los procesos que sean ejecutados empleando esta técnica deben estar compilados para la misma arquitectura y sistema operativo —esto significa que por ejemplo, en un sistema anfitrión x86 con Linux, todos los contenedores deberán ser también x86 con Linux. Esta tecnología hereda directamente de la llamada al sistema chroot(), en 1982. Claro está, a esta simple llamada se tuvieron que agregar numerosas funciones implementando una separación más limpia y completa entre los distintos espacios de nombres. Poco a poco se desarrollaron mecanismos para limitar el uso total de memoria o de CPU de cada contenedor, y aislar la vista de la red que cada uno de ellos puede tener. El primer sistema en implementar lo que hoy conocemos con contenedores fue FreeBSD, en el año 2000; dado que están construidos alrededor de la llamada chroot(), resulta natural que casi todos los sistemas operativos en implementar contenedores sean tipo Unix; en el mundo Windows, hoy en día se tiene la promesa de que la versión 10 incluirá esta característica.

En Linux hay distintas implementaciones disponibles, y que han logrado madurar cada cual a su ritmo. Durante muchos años, la más fuerte fue VServer, pero requería de cambios demasiado invasivos, que nunca fueron aceptados por Linus Torvalds para la rama principal del kernel. Posteriormente se popularizó OpenVZ, la versión libre de Virtuozzo, pero sufrió del mismo problema. Sin embargo, a partir de la incorporación de los grupos de contexto (cgroups) al kernel de Linux 2007, el proyecto Linux Containers (lxc) logró una implementación suficientemente eficaz y sencilla, y es hoy en día la más popular y consolidada.

Distribución basada en contenedores

A principios de 2013, se anunció la liberación de un innovador programa que ha cambiado en gran medida las reglas del juego para el despliegue de aplicaciones: Docker. Su principal contribución es que cambia el enfoque: presenta a cada contenedor ya no como una máquina virtual, como una instalación completa de una computadora, sino que como el entorno completo de ejecución de una aplicación. Esto tiene aspectos muy positivos, pero también tiene otros francamente dignos de cuidado. Pero antes de abordarlos, permítanme explicar un poco.

Originalmente, instalar o aprovisionar un contenedor implicaba como paso necesario la instalación del software de sistema tal como si se tratara de una computadora real. La delgada capa de virtualización de los contenedores permitían tomar a un conjunto de máquinas virtuales como si fuera una granja de servidores — Y el trabajo del administrador de sistemas es, a fin de cuentas, gestionar a cada una de las máquinas virtuales cual si fuera un servidor completo — Que si bien es mucho menos complejo que si se tratara de una sola instalación con todo el software bajo el mismo espacio, implica una innegable complejidad. El principal cambio que introduce Docker es que permite generar un contenedor por aplicación, y gestionarlo directamente como si fuera una unidad — ya no una colección de paquetes relacionados.

Bibliotecas, versiones, infiernos y apps

Demos un brinco conceptual a un tema, aparentemente, sin relación. Prometo pronto explicar a qué viene esto.

El desarrollo de los sistemas operativos que empleamos hoy en día cruzó hace unos treinta años por un punto crucial en lo concerniente a su flexibilidad: La introducción de formatos estándar de bibliotecas compartidas, que pueden ser utilizadas entre diversas aplicaciones. Gracias a ellas, el tamaño de cada uno de los programas se redujo fuertemente (puesto que éstos no tenían que incluir expresamente todas las definiciones que emplean), se estandarizaron interfaces (puesto que diversos programas aprovecharían las mismas bibliotecas ampliamente conocidas), y –muy importante– dado que redujo fuertemente la duplicación de código, mejoró significativamente la seguridad de los sistemas operativos: Ante un error o vulnerabilidad, basta con actualizar una copia del código vulnerable para que todos los programas afectados reciban la corrección.

Claro, surge complejidad del manejo de los cientos de bibliotecas compartidas que se instalan en un sistema típico, de la cual se deriva la expresión “DLL hell” (el infierno de los DLLs). Sin embargo, este es un problema en el que se ha invertido una gran cantidad de trabajo, y la situación hoy en día es radicalmente diferente a la de hace veinte años, cuando se acuñó dicho término.

Ahora bien, ante la popularización de las apps en dispositivos móviles y el abaratamiento del almacenamiento, se impuso el concepto inverso: El empaquetamiento de todas las dependencias dentro de un mismo binario. Para evitar que el usuario final tenga que descargar todas las dependencias que empleó cada desarrollador, y asegurar que cada paquete funcionará independientemente de los demás que tenga instalado el sistema, se ha optado por –de facto– reconvertir las bibliotecas dinámicas en objetos ligados estáticamente. Claro, esto obliga a que ante la actualización de una biblioteca compartida, cada una de las aplicaciones que la usa sea actualizada también — Pero en una era de conexión permanente a Internet, esta idea ha resultado del favor del mercado.

Distribución y servidores virtuales

Uniendo, pues, los dos temas expuestos: La principal contribución de Docker es que convierte el engorroso despliegue de servidores virtuales en un sencillo despliegue de aplicaciones — Y, claro está, de aplicaciones empaquetadas a la moda, con el mínimo de dependencias.

Desde una perspectiva meramente de DevOps, esto suena muy bien. Sin embargo, también involucra grandes riesgos, como lo ilustran entre otros muchos los textos que han escrito al respecto dos de los desarrolladores de Debian GNU/Linux: Joey Hess [1] y Erich Schubert [2].

En primer lugar, un uso irresponsable de Docker (aunque sea el recomendado por sus desarrolladores) nos puede llevar a confiar en software cuyo origen no necesariamente es el que esperamos, sin saber en qué consisten los cambios y cómo éstos nos afectarán. Los paquetes que dicen ser oficiales de determinadas distribuciones han demostrado haber sido alterados, lo cual debe poner a pensar mal a cualquier administrador de sistemas.

En segundo lugar, y esto me parece más complicado y peligroso aún, el modelo que impulsa Docker nos invita a olvidarnos de la seguridad que debe mantenerse como parte de la gestión de cada sistema instalado. Un contenedor no puede ser creado una única vez y visto, a partir de ese momento, como una app, como un objeto estático e independiente. Y no, cada sistema debe integrar las correcciones a las vulnerabilidades (o simples bugs) que constantemente van apareciendo y siendo corregidas, y un administrador de sistemas siempre debe estar familiarizado con la tecnología que tiene instalada. Resulta inexcusable poner al mismo nivel a un sistema operativo completo y a aplicaciones como Wordpress, pero eso es precisamente lo que ocurre [3].

Obviamente, la tecnología no es mala, y la adopción que ha tenido habla de sus virtudes técnicas. Sin embargo, el uso y crecimiento que ha tenido dejando de lado las buenas prácticas de administración de sistemas, y el impacto que esto puede tener en nuestro campo, merecen ser consideradas

Referencias

[1] “What does docker.io run -it debian sh run?”, https://joeyh.name/blog/entry/docker_run_debian/
[2] “The sad state of sysadmin in the age of containers”, http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin...
[3] Repositorios oficiales de Docker: https://registry.hub.docker.com/search?q=library&f=official

( categories: )

Los detalles de implementación en la era de las abstracciones

Submitted by gwolf on Fri, 09/04/2015 - 11:58
Wolf G.  2015.   Los detalles de implementación en la era de las abstracciones . Software Gurú. :48-49.

– Me llamo Gunnar, y soy programador.

– ¡Hola, Gunnar!

– Tengo que contarles hoy respecto a mi abuso de las abstracciones y de la automatización. Por aprovechar lasfacilidades de un /framework/ completo y poderoso, me he ido olvidando de las interacciones reales. Me engolosiné con un ORM que me presenta los datos como objetos, y me olvido de la realidad de su representación entidad-referencial. Mis métodos son todos cortitos y asumo que el ciclo de atención a solicitudes es corto, olvidando que dejo referencias en memoria. Hago llamadas a procedimientos remotos en proveedores SaaS y no considero que pueden fallar.

– Pero ahora estas consciente de ello. ¡Has dado el Primer Paso! ¡Ese es el camino para ser un Programador, para ser!

– Sí, pero… ¿Por dónde comienzo? Hay tantas abstracciones, tanto por reaprender. A todos lados a donde volteo a buscar, me encuentro con más abstracciones. ¡Me siento perdido! ¿Dónde quedó la simple realidad del cómputo que teníamos antes?

Sí, no hay ni cómo esconderlo: Tiene ya varias décadas que me apasionó comprender lo que pasa dentro de una computadora, cómo opera su aparente magia. Y cuando aprendí, cuando muchos de nosotros aprendimos, incluso un niño de diez años podía comprender cómo operaban ciertos procesos, si bien tal vez no a nivel electrónico, sí a partir de una visión muy cercana. Piensen, por ejemplo, en qué tan a profundidad podía un niño de los 1980s conocer a una magnífica /Commodore 64/, e incluso cuánto puede haber aprendido con una PC. Recuerdo largas horas de leer documentación, modificar binarios a mano con un editor hexadecimal para cambiar las cadenas que presentaban al usuario, buscando comprender todo lo que veía — Simplemente, porque era posible hacerlo.

Como nota al calce: Si alguno de ustedes se siente identificado con este disfrute histórico, no puedo dejar de invitarlos a una de las lecturas que más he disfrutado en los últimos meses: Un libro titulado sencillamente /«10 PRINT CHR$(205.5+RND(1)); : GOTO 10»/, y que pueden descargar gratuitamente de [http://10print.org/]. Este libro aborda muy distintos aspectos que se desprenden de la línea de BASIC que lleva por título; un análisis técnico, social, cultural, incluso artístico de esa era que a tantos nos atrapó convirtió en lo que hoy somos.

Como segunda nota al calce y recomendación literaria: El libro /«Lauren Ipsum: A story about computer science and other improbable things»/, de Carlos Bueno ([http://laurenipsum.org/]). Aprender los fundamentos del cómputo siendo aún niño definió mi vida. Este libro presenta, a través de un cuento inspirado en /Alicia en el país de las maravillas/, conceptos fundamentales de la ciencia de la computación: Problemas clásicos, estructuras de datos, conceptos fundamentales, presentados con el cuento de una niña perdida en el bosque de los árboles rojo-negros, buscando volver a casa.

Pero volviendo a nuestro tema: con el tiempo, el mundo ha ido cambiando. Y yo también. Al volverme un miembro útil a la sociedad, como les habrá pasado a ustedes también, fui eligiendo mi /nicho ecológico/: Desarrollo de aplicaciones Web y administración de sistemas. Primero, exprimiendo los detallitos que me ofrecía cada pedacito del protocolo… Aunque recuerdo muy bien una discusión con un colega: Yo era bastante reacio a emplear /frameworks/ de desarrollo precisamente porque, al automatizar las tareas repetitivas, esconden del programador su funcionamiento real, y dificultan tener verdadero control de lo que hacen, pero él me mostró las ventajas que conllevaban.

Pero bueno, acortando la historia: De desarrollar mis aplicaciones completas con el lenguaje Perl, cabalgando /a pelo/ sobre el API de Apache, me /subí al tren/ de Ruby on Rails. Y disfruté muchísimo de la libertad que me brindó esta experiencia: Una programación más limpia, orientada a objetos. Configuración por convención. Muchas muy buenas prácticas de desarrollo, y un marco de desarrollo con opiniones propias que me marcó cómo estructurar mi desarrollo. Y sí, las aplicaciones resultantes eran comprensiblemente más rápidas de desarrollar, y al tener el comportamiento base resuelto, me topé con muchos menos errores lógicos en las capas más bajas.

Pero la vida sobre un /framework/ también trae sus desencantos. En mi caso, me topé con los primeros al encontrar la cantidad de código que había que reescribir cuando Rails pasó de su versión 1 a 2, de 2 a 3… Como es de esperarse, los cambios que introducen las versiones mayores no son /compatibles hacia atrás/, y buena parte de mi código histórico iba emitiendo advertencias por usos desaconsejados — O rompiéndose por completo. Y entre más sistemas desarrollaba, menos tiempo tenía para mantenerlos a todos al día.

La respuesta de la comunidad Rails a mis cuitas es relativamente simple: Un sistema que ya está en producción no requiere ser actualizado. El programador puede /congelar/ el sistema base y las /gemas/ (bibliotecas) que emplea, y convivir fácilmente en el mismo sistema con otras aplicaciones Rails — Incluso si estas usan otras versiones de prácticamente todo en el sistema.

En ese momento, comenzó una lucha interior, entre mi Dr. Jekyll, un administrador de sistemas que prepara las cosas y, con la cabeza fría, mantiene una visión consistente y coherente del conjunto, y mi Mr. Hyde, un programador que quiere vivir al límite probando las últimas versiones del último grito de la moda, cambiando de arquitectura subyacente, abandonando a /FCGI/ por /Mongrel/, a /Mongrel/ por /Thin/, a /Thin/ por /Passenger/, incorporando a /Rack/… Y claro, encarnando a esa aberración de la que hablaremos en otra ocasión que hoy deambula libremente: el temido /DevOp/, criatura que encarna lo más obscuro tanto de desarrolladores como de administradores.

Y ojo, me centro en este aspecto porque mi Dr. Jekyll es administrador de sistemas. Pueden imaginar lo que diría uno con formación de DBA al ver el caos resultante del ORM: ¿Cómo se grea mi esquema de datos? ¿Dónde están las verificaciones de integridad? ¿Cómo se generan las consultas para cada una de las operaciones que el buen ActiveRecord realiza?

En fin, podemos recordar esa máxima de la ciencia de la computación, que he visto atribuída tanto a David Wheeler como a Butler Lampson: /Todos los problemas en la ciencia de la computación pueden resolverse/ /con un nivel adicional de indirección — A excepción del de tener/ /demasiados niveles de indirección./

Mientras esa pelea ocurría en mi /yo desarrollador/, muchos otros importantes cambios se presentaron en mi vida. Uno de ellos, me convertí en profesor en la Facultad de Ingeniería de la UNAM. Imparto una materia que siempre me emocionó: Sistemas Operativos. He disfrutado muchísimo con la preparación del material y con el dictado de las clases. En esta materia estudiamos las funciones básicas de todo sistema operativo — Comunicación entre procesos, multiplexión de recursos, organización de sistemas de archivos, gestión de memoria, etc.

Conforme estudio y repito mi material, y conforme comento al respecto con mis colegas, vuelvo a uno de los planteamientos de origen que siempre hago a mis alumnos: No espero que de mi clase salgan autores de sistemas operativos; sería un gran orgullo que así fuera, pero no es lo que la materia persigue. Una de las principales razones para estudiar esta materia es que, si no se comprenden los fundamentos de lo que estamos haciendo, nuestros programas van a resultar de muy baja calidad.

Si nos olvidamos que a fin de cuentas todo nuestro código se traduce a instrucciones de muy bajo nivel, si nos olvidamos de cuidar la eficiencia de los /cachés/ y de reducir accesos a disco, si no tenemos en cuenta el costo de cada llamada al sistema, si no consideramos la necesaria sincronización en problemas que enfrentan concurrencia… Vamos a terminar creando código lento y frágil. Vamos a terminar siendo malos desarrolladores.

Entonces bien… El motivo de esta columna no es llamar a que abandonemos las herramientas que facilitan nuestra tarea. Los /frameworks/ no únicamente son cómodos, sino que son necesarios para la realidad del desarrollo de software hoy en día. Pero debemos mantener en mente, siempre, la importancia de /comprender qué pasa/. Si hay un comportamiento dado que parece mágico, ese es el punto donde debemos revisar el código fuente del /framework/ y averiguar cómo está haciéndolo. Porque sólo de esa forma podremos sacar el provecho correcto del sistema — y escribir mejor código, que a fin de cuentas, por eso nos hacemos llamar /profesionales/.

Entonces, vestidos de investigadores privados y lupa en mano, ¡vamos a investigar implementaciones! ¡Disfruten el viaje!

( categories: )

Escritura Colaborativa utilizando Software Libre

Submitted by gwolf on Tue, 03/10/2015 - 18:25
Ruiz E, Bergero F, Wolf G.  2014.  Escritura Colaborativa utilizando Software Libre. IX Conferencia Latinoamericana de Objetos y Tecnologías de Aprendizaje LACLO 2014.

La enseñanza y lo generativo de la computación

Submitted by gwolf on Tue, 01/06/2015 - 18:21
Wolf G.  2014.  La enseñanza y lo generativo de la computación . Software Gurú. :46-47.

Escribo el presente artículo en octubre del 2014. Resuenan aún fuertes los ecos del inicio del ciclo escolar, hace apenas poco más de un mes, y por la radio siguen sonando los anuncios de la SEP presumiendo al Programa de Inclusión y Alfabetización Digital — particularmente, acerca de la entrega de tabletas a todos los alumnos de 5° de primaria,1 en esta primera etapa en los estados de México, Colima, Sonora, Tabasco, Puebla y el Distrito Federal. Según la información que pude encontrar, esto significa la entrega de unas 700,000 tabletas, con un costo aproximado de 1,400 pesos cada una.

No me corresponde hablar acerca del contenido desarrollado y cargado en estos equipos, dado que se aleja por completo de mi campo de conocimiento. Quisiera, sin embargo, aprovechar este espacio para compartir con los lectores de Software Gurú dos interesantes textos al respecto publicados por Luis Felipe Lomelí — y agregar algunas apreciaciones respecto a la potencialidad que estos equipos podrían presentar — y, como están planteados, no presentan

Lomelí presentó dos columnas en el sitio de periodismo digital sinembargo.mx: la primera, el 24 de septiembre, titulada Tabletas SEP: impacto ambiental,2 y la segunda, el 1° de octubre, Tabletas SEP: ¿mejoran la educación?.3 Recomiendo su lectura a los quienes se interesen en profundizar en el tema; la primera comienza a rascar en dirección de un (necesario) estudio riguroso acerca del impacto ambiental que tendrán, una vez que el programa llegue a un despliegue pleno en el país, millones de equipos de cómputo con un tiempo de vida –siendo optimistas– de tres años; la segunda habla acerca de las ventajas y desventajas para el proceso enseñanza-aprendizaje del uso de estos equipos. Fue esta segunda columna la que me llevó directamente a abordar este tema.

La generatividad

No repetiré las reflexiones que Lomelí ya hizo. Más bien, me interesa continuar del texto al que hago referencia, y unirlo con otro tema que al llevo largo rato acercándome: el cambio en la generatividad de las herramientas de cómputo. Este planteamiento tampoco es mío de origen: en 2008, Jonathan Zitrain (profesor de ciencias de la computación y de derecho informático en la universidad de Harvard) publicó el libro titulado The future of the Internet and how to stop it; este libro está disponible para su lectura en línea.4

Zittrain presenta el concepto de la generatividad, y argumenta acerca del por qué la existencia misma tanto de las computadoras personales (en un concepto amplio — su explicación comienza hablando de la Apple II y las demás computadoras de fines de la década de los setenta) como de Internet: la principal razón por la que tanto las computadoras personales como la "red de redes" pudieron crecer y adaptarse desde sus orígenes, limitadas e incompletas como estaban, hasta lo que son hoy en día es que son plataformas abiertas, pensadas para que sean los usuarios quienes desarrollen, dicten y creen sus contenidos.

Las computadoras personales presentaban una interfaz general, y sus usuarios necesariamente aprendían por lo menos los rudimentos de algún lenguaje de programación; Internet, inicialmente creado como un proyecto del Departamento de Defensa de los Estados Unidos, fue desarrollando todos sus protocolos (y definiendo su funcionalidad y desarrollo) a través de documentos públicos, conocidos como RFCs (Request For Comments, Solicitud de comentarios).

Y desde el nivel de la interfaz física mismo: Una tableta ofrece algunas características atractivas. Sin partes móviles, compacto, y actual. Sin embargo, es claramente un dispositivo para consumir medios. Hay programas que permiten escribir, dibujar, y hasta cierto punto crear… Pero una tableta sencillamente ofrece una interfaz muy limitada para la exploración creativa.

El contenido educativo

Como ya lo dije, yo no soy la persona adecuada para hablar acerca de la idoneidad del contenido educativo precargado en las tabletas que repartió la SEP. Sin embargo, y haciendo eco de la columna que publiqué hace dos años aquí mismo,5 conviene preguntarnos qué es lo que buscamos al introducir a la tecnología a las aulas.

La propuesta actual de la SEP emplea tabletas: computadoras de interfaz muy sencilla, fáciles de emplear, y orientadas a administrar el contenido diseñado centralmente, ayudando a facilitar el aprendizaje de otras materias. Y sí, esto brinda lateralmente la oportunidad de emplear las tabletas para el entretenimiento: son, a fin de cuentas, dispositivos Android bastante estándar, esto es, todas las aplicaciones disponibles por Google Play.

Y en este planteamiento radica parte importante de lo que se puede criticar a este proyecto: Los teléfonos inteligentes y las tabletas presentan todos interfaces ricas e interactivas para el consumo de medios, pero están naturalmente limitados para fomentar su creación, y más aún, cosa que deberíamos fomentar en nuestros niños, su apropiación — concepto fundamental al que volveré en breve.

Queda claro que la idea de incorporar a las "nuevas tecnologías" a la enseñanza no es, redundemos, muy nueva que digamos. Para contrastar modelos, ¿cómo se presentaban las computadoras como auxiliar pedagógico hace veinte, treinta o cuarenta años? En la columna presentada en Software Gurú 38 argumento que el acercamiento al cómputo era presentado como una forma de pensar, como una forma de estructurar las ideas para explicarle a la computadora los pasos que debería seguir — y por qué eso debería verse como parte de las habilidades cognitivas básicas que son transmitidas a los niños a lo largo de su proceso formativo. Esto es, en la década de los ochenta la computación era presentada a los niños no sólo como la herramienta que se usaría para la transmisión del conocimiento, sino que como un área de conocimiento por sí misma, misma que podría potenciar nuestro desarrollo en todas las demás áreas.

Apropiación tecnológica

Apropiarse de la tecnología va mucho más allá de ver a una tableta como parte de las herramientas para realizar nuestro trabajo: Apropiarse de ella implica intimar con la tecnología: Perder el miedo para conocer sus secretos, su funcionamiento, la manera en que cada uno de los niños puede modificarla para que haga lo que él o ella quiere, y no sólo lo que está programada para hacer.

Y volvemos a la generatividad. Este concepto va más allá de lo que presenté hace dos años: No sólo es aprender a programar, sino que es poder moldear a la herramienta en particular. No sólo es aprender a programar en juguete, sino reconocer que eso que me enseñan puede tener impacto, repercusión real, sensible con las herramientas que uso a diario. No sólo poder bajar las apps (los jueguitos) que quieran, sino que poder desarrollarlos y modificarlos.

Y sí, este planteamiento puede sonar iluso e imposible. A fin de cuentas, quien escribe estas líneas se asume a sí mismo como ruido estadístico. La generación, como nos describí en la columna de hace dos años, de los hijos de Logo fuimos muy afortunados: No sólo nos tocó conocer al mundo del cómputo cuando éste era suficientemente sencillo como para que fuera posible para un niño comprender buena parte de los procesos que sucedían al interior de la computadora, sino que tuvimos la suerte de que nuestros padres tuvieran la sensibilidad de ofrecernos formación en cómputo cuando definitivamente no formaba parte de lo normal en la sociedad.

Y por excluyente que suene, es la realidad: Tuvimos la suerte de crecer en una familia –por lo menos– de clase media, que fuere como fuere tuvo la posibilidad de brindar acceso a una tecnología excepcional. No podemos perder de vista que el programa que ahora instrumenta la SEP está enfocado no a unos cuantos niños afortunados, sino que –en este momento– 700,000 niños en cinco estados y el Distrito Federal, y se espera que en los próximos años se extienda a todos los niños de quinto de primaria.

OLPC y Sugar

Sin embargo, la masividad del programa no se contrapone con un enfoque más integral. No podemos olvidar que el planteamiento original de proyectos tan ambiciosos como OLPC (One Laptop Per Child, Una Computadora por Niño)6 puso como condición desde su punto de partida que sólo operaría a gran escala.

Recordemos que el proyecto OLPC nació en 2006, hace ya casi una década. Su impacto ha sido enorme: Resultó tan fundamental para proyectos como el de la SEP como la mera idea de dar equipos de cómputo en propiedad a los alumnos en vez de crear aulas digitales en las escuelas.

Pero más allá de su modelo de distribución o el diseño de computadoras aptas para el trato que les darían los niños, el verdadero corazón de OLPC es el entorno de aprendizaje Sugar.7 Partiendo de que nos niños no son oficinistas, es un entorno orientado a actividades de aprendizaje, y con una fuerte carga constructivista: El niño no se enfrenta con las aplicaciones como cajas negras y cerradas definitivamente, entregadas como parte de un artefacto mágico y sellado, sino que se espera que las exploren — no solamente como usuarios, sino que desde su construcción, desde su código. Prácticamente todo puede ser tocado, modificado, y los niños pueden aprenden a moldear la herramienta a sus intereses.

Claro está, sería demasiado triunfalista de mi parte cerrar esta columna implicando que OLPC y Sugar son el non plus ultra, el modelo a seguir para llevar la apropiación del cómputo a las aulas de nuestro país. OLPC tuvo severos problemas desde el primer momento, y su existencia no ha sido simple. Si bien las cifras que brinda su sitio son muy felices, son a fin de cuentas cifras agregadas de muchos años, y no todos los equipos que presumen están en operación hoy en día. Tampoco puede obviarse la importancia de brindar una adecuada y recurrente capacitación a los docentes, a quienes una herramienta generativa resultará un reto mucho más complejo que una simple terminal. Y, claro, la complejidad del aparato burocrático-educativo en nuestro país no es para ser despreciada.

El importante paso que da la SEP es en la dirección correcta. Sólo resta esperar que el seguimiento que, en futuras ediciones, en futuros sexenios se dé a lo que ahora se está ensayando implique una verdadera apropiación.

Nota al pie de página:

1 http://www.primariatic.sep.gob.mx/

2 http://www.sinembargo.mx/opinion/24-09-2014/27542

3 http://www.sinembargo.mx/opinion/01-10-2014/27750

4 http://futureoftheinternet.org/

5 Programación en la Escuela:
¿Para qué?, http://sg.com.mx/revista/38

6 http://one.laptop.org/

7 http://sugarlabs.org/

( categories: )

Criptografía y seguridad: Bibliotecas y prácticas

Submitted by gwolf on Thu, 10/09/2014 - 11:22
Wolf G.  2014.  Criptografía y seguridad: Bibliotecas y prácticas. Software Gurú. :22-23.

El pasado mes de julio tuve nuevamente la oportunidad de participar en el congreso anual que organiza Software Gurú, presentando la conferencia Desarrollo de software y criptografía.1

Me doy cuenta que, si bien su relevancia resulta clara y hay interésen la comunidad de desarrolladores por comprenderlo, el tema de la criptografía es visto por muchos como un tema casi mágico o místico: Hay unos pocos expertos, pero está fuera del alcance para el común de nosotros, los simples desarrolladores que carecemos de un sólido conocimiento matemático de fondo.

Y sí, no puedo negarlo: El uso correcto de la criptografía requiere de darse una pequeña zambullida en un mar de conceptos nuevos. Sin embargo, me da gusto ver que estamos cada vez más conscientes de la importancia de proteger los datos de nuestras aplicaciones, tanto como sea posible, por criptografía fuerte. Aquí aparece la primer tensión que abordo: ¿Cómo responder a las necesidades de seguridad de información sin tener un sólido conocimiento matemático en cuestiones de criptografía?

Afortunadamente, en ese punto es donde aparece el hilo conductor con el tema de la presente edición de Software Gurú: La era de las APIs: Hay varias bibliotecas criptográficas ampliamente disponibles, implementando los diferentes algoritmos y modos de operación. Y no es necesario implementar los protocolos criptográficos, sino únicamente llamar a las funciones indicadas de la biblioteca de nuestra elección.

Y, claro, el hablar de etas principales implementaciones también da pie a abordar del impacto de los no pocos ni triviales problemas que han aquejado a este campo en los últimos meses. Y sí, aunque probablemente muchos asocien en primer término al término API con las interfaces presentadas por el uso de facilidades provistas por los famosos servicios en la nube, toda biblioteca que empleemos para el desarrollo (incluyendo las bibliotecas estándar, parte de la definición de nuestro lenguaje) expone una interfaz de programación de aplicaciones.

Claro está, estamos viviendo en la era de las APIs — Desde hace más de 60 años.

Criptografía: ¿Para qué?

La criptografía nos brinda distintas herramientas para proteger nuestra información — Y si partimos de que la información es el activo más valioso de todos nuestros sistemas, resulta obvio que la criptografía es uno de nuestros mayores aliados.

Si bien la criptografía es casi tan vieja como la escritura misma, apenas fue abordada como una disciplina científica matemática a partir de mediados del siglo XX. Y si bien durante la mayor parte de la historia su principal afán (y, claro, el concepto relacionado directamente en el imaginario popular) fue el de brindar confidencialidad a la información valiosa, esta hoy en día representa sólo una de las propiedades de la información que la criptografía nos permite asegurar.

La segunda propiedad es la integridad: Partiendo de un texto origen arbitrariamente largo, las llamadas funciones digestoras calculan su hash, una cadena de longitud fija con la propiedad fundamental de ser muy dificil encontrar otro texto que genere la misma salida.

Esta definición de integridad posiblemente deje a más de uno insatisfecho. Y sí, por sí sola no sirve para garantizar gran cosa… Pero la tercer propiedad hará clara su utilidad.

Hasta mediados de los 1970, todos los esquemas de criptografía dependían de una llave única: El equivalente a una contraseña que permitía tanto convertir un texto claro en una representación inintelegible como manipular a dicha representación para obtener de vuelta al texto claro.

Entre el breve lapso comprendido 1976 y 1980, el mundo de la criptografía cambió por completo: Nació la criptografía de llave pública, con los principales protocolos que siguen siendo utilizados al día de hoy. Esencialmente, en vez de manejar una sola llave, se descubrieron varias funciones matemáticas que permiten llaves compuestas de dos mitades: Una privada, que cada indivduo debe custodiar celosamente, y una pública, que puede ser ampliamente distribuída. Estas dos llaves actúan como inversas: Lo que se cifra con una sólo puede descifrarse con la otra.

Este hecho, que parecería una mera curiosidad, permitió la creación de mecanismos para proteger las tercera propiedad de la información: La Autenticación. Si un mensaje cifrado por mi llave privada puede ser descifrado por cualquiera que conozca mi llave pública, y existen directorios de llaves públicas, este mensaje sólo puede haber sido generado por mí.

Ya con estos antecedentes, ¿qué es la cadena que aparece en todas las facturas electrónicas y ocasionalmente incluso en los correos electrónicos? Tomando un texto origen, se obtiene su hash, y se firma con la llave privada del emisor. ¡Listo! Una firma electrónica con un tamaño constante, estableciendo una relación no repudiable entre un documento y su emisor.

Partiendo de distintas formas de emplear estas tres propiedades pueden derivarse otros varios patrones de validación de documentos; este es sólo el más común y sencillo de muchos de los patrones de uso de criptografía.

Pero… ¿Se puede confiar en la criptografía?

Al hablar de la integridad, mencioné que debía ser muy dificil encontrar dos textos que produzcan el mismo resultado. A pesar de que el término puede no inspirar mucha confianza, sin embargo, debe leerse no como algo que intuitivamente (y sin ser especialista) me parezca dificil, sino definido desde la teoría de la complejidad computacional: Computacionalmente dificil significa que es sumamente resistente a ser atacada por búsqueda exhaustiva (o lo que es lo mismo, por fuerza bruta): Idealmente, la complejidad crece de forma exponencial con el espacio de búsqueda.

Por ejemplo: un algoritmo de cifrado simétrico ampliamente utilizado como el AES puede operar con llaves de 128 a 256 bits. Esto significa que, con una llave de 128 bits, el espacio de búsqueda es de \(2^{128}\) (del órden de \(10^{38}\)) posibilidades. Si tuviéramos poder de cómputo suficiente para intentar decodificar un billón de llaves por segundo, una búsqueda exhaustiva tomaría sólo 719 millones de veces la edad del universo. En contraste (e ilustrando el crecimiento exponencial), una llave de 64 bits tomaría sólo 213 días.

Los algoritmos que se han desarrollado, es cierto, no son perfectos. Por ejemplo, Alex Biryukov y Dmitry Khovratovich presentaron en 2009 un artículo2 detallando un tipo de análisis permitiendo reducir dramáticamente (a sólo unas decenas de veces la edad del universo según nuestro cálculo) el espacio de búsqueda. La búsqueda de debilidades en algoritmos criptográficos es un campo vibrante de investigación matemática, con muchos talentosos académicos buscando cómo ganarle un bit más, un pasito más. De encontrarse alguna debilidad, aparecerá sin duda publicada en las más importantes revistas académicas del ramo.

Bibliotecas criptográficas

Pero, dado que nuestro campo es el desarrollo de sistemas y no la criptografía desde un punto de partida matemático, recordemos que hay una gran regularidad entre los parámetros que requieren los diferentes algoritmos. Si empleamos una biblioteca de funciones criptográficas, como la muy conocida OpenSSL, y un algoritmo ampliamente utilizado es descubierto como vulnerable, hacer el cambio para emplear otro algoritmo resultará casi trivial.

Por otro lado, me permito citar la máxima de Adi Shamir, uno de los padres de la criptografía moderna:

La criptografía normalmente es evadida, no penetrada.

Decenas de productos han implementado soluciones criptográficas (generalmente basadas en el firmado) en los últimos años, sólo para encontrar que su mecanismo fue roto al muy poco tiempo de salir al mercado.3 /sup> Todos estos ejemplos derivan de un uso incorrecto de la criptografía: Para hacer un jailbreak, el atacante burla la llamada a la función criptográfica, aprovechando un error de programación para secuestrar el flujo antes de que se lleve a cabo la validación.

Y antes de cerrar esta columna: Mencioné a la popular biblioteca OpenSSL. A más de uno de ustedes debe haberle sonado una alarma: ¿En serio está recomendando OpenSSL? ¿Después de Heartbleed?4 Sí, sí lo recomiendo. Vamos paso por paso.

OpenSSL es la biblioteca criptográfica por excelencia, y su principal fuerza es también su principal desgracia: Es una biblioteca con 20 años de historia, y profundamente multiplataforma. Vamos, su herencia multiplataforma ha mantenido el soporte para arquitecturas que desde hace años son consideradas obsoletas, como VMS u OS/2. Además, el estilo del código es de muy dificil comprensión — Los desarrolladores justifican esto puesto que, siendo la criptografía tan demandante de recursos de cómputo, se vieron orillados a tomar decisiones motivados
más por el rendimiento que por la claridad.

Como sea: El fallo conocido como Heartbleed expuso lo inadecuadas que dichas prácticas son hoy en día. Sin embargo, y analizando el fenómeno desde la perspectiva de un promotor del software libre, la respuesta de la comunidad ha sido de lo más interesante: Por un lado, la Linux Foundation (a través de su Core Infrastructure Initiative) está fondeando una auditoría del código de OpenSSL. Y por otro lado, surgieron dos proyectos derivados de OpenSSL, buscando corregir sus defectos de formas más radicales, aunque signifique romper la compatibilidad a nivel API: LibReSSL,5 del equipo de sistema operativo OpenBSD, y BoringSSL,6 de Google. ¿Por qué BoringSSL? En palabras de Shawn Wilden:

Los componentes fundamentales de seguridad (…) debrían ser muy aburridos. No son el lugar para inovar y experimentar, (ni) para el código que demuestra el virtuosismo del autor. (…) Son donde quieres implementaciones simples, directas y aburridas de los algoritmos y protocolos (…) Cuando se habla de seguridad, lo aburrido es bueno.

Que Heartbleed fue un fallo nefasto nadie lo pone en duda. Sin embargo, ante estos fallos siempre es interesante ver la reacción de las comunidades de desarrolladores. Al igual que cuando otros fallos severos, Heartbleed ha llevado a los desarrolladores (al menos dentro de las comunidades de software libre, cuyo código y cuyas discusiones son claramente visibles desde fuera) a iniciar auditorías y replantearse prácticas que seguramente redundarán en el avance global de la calidad del software.

Nota al pie de página:

1 http://gwolf.org/desarrollo_y_criptografia

2 http://eprint.iacr.org/2009/317

3 La excelente presentación Crypto won't save you either, disponible en http://regmedia.co.uk/2014/05/16/0955_peter_gutmann.pdf, presenta más de 20 casos.

4 ¿No supiste acerca de la vulnerabilidad de seguridad más publicitada por lo menos en este lustro? http://heartbleed.com

5 http://www.libressl.org

6 https://www.imperialviolet.org/2014/06/20/boringssl.html

( categories: )

Conforme las nieves del tiempo platean mi sien

Submitted by gwolf on Thu, 06/26/2014 - 10:26
Wolf G.  2014.  Conforme las nieves del tiempo platean mi sien. Software Gurú. :46.

Para este número, nuestra coordinadora editorial nos pidió enfocarnos a una retrospectiva de lo que significa esta década que se cumple. E inevitablemente, cada vez que comienzo a pensar al respecto, el plazo se me duplica, y termino tarareando una de dos melodías. Dos hermosas canciones que relatan, melancólicamente, a muy distinto ritmo y desde muy distintas ópticas, el recuerdo de un amor al paso de un largo intervalo de tiempo: La contradanza cubana ``Veinte años'', de María Teresa Vera, y el tango ``Volver'', de Le Pera y Gardel.

En ``Veinte años'', se recuerda algo que terminó de forma irremisible, volviendo a que el amor que ya ha pasado no se debe recordar. Sin embargo, en ``Volver'', si bien parte de una historia de desamor y distancia, culmina en la esperanza de un reencuentro — Y aunque el olvido, que todo destruye, haya matado mi vieja ilusión, guardo escondida una esperanza humilde que es toda la fortuna de mi corazón.

Ambas canciones son de las más identificables y definitorias de sus respectivos géneros. Tal vez sea por lo importantes que nos resultan (obviamente, muy por debajo de una relación amorosa de esperanza y de desgarre, pero sigamos el argumento) los números cerrados, los plazos que nos hacen recordar lo que hacíamos hace toda una vida… Y, en este caso, me quedo con ``Volver'', por la esperanza de seguir adelante, la expectativa ante el futuro.

Mucha gente insiste en que en nuestra área más que en otras el cambio es la única constante. Yo soy de la opinión contraria: Hay un gran desarrollo tecnológico, pero las cosas se mantienen igual mucho más de lo que cambian. Cambian, sí, los detalles, los sistemas específicos que empleamos, alguna metodología que esté de moda… Pero viendo la imagen en grande, nuestro ámbito de acción profesional no da los grandes saltos que algunos suponen. SG nos va dando una importante memoria histórica de lo que va ocurriendo en este campo, en nuestro país.

Revisando los temas de portada de una década de SG, hay una clara lista de temas recurrentes — Los temas candentes que representan la mayor parte de las dudas, necesidades y nuevos desarrollos. Estos temas seguramente nos seguirán dando de qué hablar en los próximos años. El cómputo en la nube (SG #22, #32, #43), metodologías y procesos, en particular los ágiles (SG #1, #9, #25, #26), móviles y embebidos (SG #5, #17, #24, #42, y de cierto modo #28 y #29). Obviamente, siendo el objeto primario declarado de SG, el análisis de la industria de software en nuestro país es uno de los temas más recurrentes (#21, #27, #33, incluyendo los estudios de salarios, #18, #30, #37). 18 de los 44 números que ha publicado SG, pues, tocan temas que se han abordado por lo menos en tres ocasiones.

Claro está, este agrupamiento temático que hago es simplista, y basado únicamente en el el título destacado visualmente en la portada; hacer un ejercicio con las editoriales, columnas y artículos que han formado parte de nuestra revista a lo largo de todo este tiempo sin duda nos arrojaría un interesante árbol temático del ramo con nuestras principales recurrencias.

Entonces, pues… Festejo un lustro. Festejamos una década. Y festejemos con la esperanza de seguir haciéndolo para los veinte años, y para después de ello. Este es el inicio de una historia. Software Gurú cubre un espacio importante y necesario para el desarrollo de nuestro país; el proyecto ha crecido desde su planteamiento original, y definir a SG es cada vez más difícil; revista, congresos, seminarios, y toda una comunidad de profesionales del desarrollo de sistemas. Una comunidad formada por empresarios, académicos, estudiantes, gente con intereses muy diversos, que aquí hemos ido encontrando nuestro espacio.

Nuestro campo demanda que nos mantengamos actualizados, que trabajemos en equipo, que compartamos conocimiento. El espacio que SG brinda a los desarrolladores de software en nuestro país es
fundamental. Sigamos haciendo historia juntos — No cinco o diez años más. Sigamos impulsando al desarrollo de software a largo plazo, como una vocación de vida.

¡Muchas felicidades!

( categories: )

Desarrollo de software y criptografía

Submitted by gwolf on Mon, 06/23/2014 - 17:42
Wolf G.  2014.  Desarrollo de software y criptografía. Software Gurú Conference & Expo 2014.

Haciendo dinero con Software Libre

Submitted by gwolf on Fri, 05/09/2014 - 21:40
Written in...: 
2014

This is, beyond any doubt, one of the weirdest talks I have given.Almost all of my friends know that, if there is a topic I don't know much about (and, I must say, I don't really care much about learning) is the insertion of Free Software in a commercial world. I often criticize the entrepeneuring culture, and my concept of a happy life involves having a stable, long-term employment.Neverhteless, my friends at OS-UPIITA invited me to talk in their conference cycle, expressly asking me to tackle this topic.And in the end, I liked the topic. Besides, the presentation went very smoothly. And most important, the interaction with the attending public was just great. A huge success! :-D

Resumen: 

Esta es, sin duda, una de las pláticas más raras que he impartido.Casi todos mis amigos saben que si hay un tema que no conozco (y, he de decir, que no me interesa conocer) es el de la inserción del Software Libre en el mundo comercial. Critico a los emprendedores, y mi concepto de vivir feliz es tener un empleo estable a largo plazo.A pesar de eso, mis amigos de OS-UPIITA me invitaron a participar en su ciclo de conferencias, encargándome expresamente que desarrollara este tema.Y a fin de cuentas, el tema me gustó. Además, la presentación fue muy agradable. Y, lo que es más importante, la interacción con el público asistente fue de maravilla. ¡Todo un éxito! :-D

( categories: )

Nubes públicas, privadas y propias

Submitted by gwolf on Tue, 04/22/2014 - 10:14
Wolf G.  2014.  Nubes públicas, privadas y propias. Software Gurú. :28,29.

Hay dos ángulos principales desde los cuales podemos visualizar el uso de la nube: Por un lado, como desarrollador y proveedor de servicios, hablar de la nube nos hace pensar en escalabilidad, paralelización, distribución geográfica en redes de entrega de contenidos (CDNs), y demás aspectos técnicos, estoy seguro que la mayor parte de los textos en este número irán en ese sentido. Sin embargo, la nube es también, y cada vez más, un concepto que manejan los usuarios finales.

Nuestros usuarios, incluso los menos tecnófilos, están empleando los servicios en la nube con cada vez mayor frecuencia. De una forma muy diferente, claro, pero… ¿qué no es acaso lo mismo?

Quisiera entonces que hagamos una pausa para pensar en los tres modos clásicos en que nos referimos a la nube: IaaS, PaaS, SaaS —respectivamente, Infraestructura, Plataforma y Software como un servicio—, pero haciéndolo desde la perspectiva de cómo los usuarios finales interactúan con cada una de dichas modalidades.

SaaS

Esta modalidad resulta natural. El uso de aplicaciones medianamente interactivas desde un navegador web califica perfectamente para ser un ”software como servicio”. Teniendo los datos almacenados en la nube, la computadora local actúa básicamente como un cliente delgado, que no hospeda la lógica de la aplicación como tal.

El mismo término SaaS nació para describir lo que ya era práctica común: El uso masivo de software hecho para presentarse en un navegador Web. Hoy en día, ya asumimos que para poder trabajar cómodamente con una computadora, cualquier usuario requiere conectividad a Internet. El cliente de correo, los marcadores, las referencias para lo que estemos haciendo … Es cierto que todavía podemos trabajar desde lugares sin red, pero cada vez más tenemos que planear dichos periodos de desconexión.

IaaS

Parecería que esta categoría estaría reservada sólo para los administradores de sistemas a gran escala, y si acaso a sus usuarios corporativos, máquinas virtuales, configuración del equipo (virtual) de red entre ellas, almacenamiento común a dichos equipos, redes privadas virtuales, etcétera. Sin embargo, hagamos símiles: cada vez es más frecuente que nuestros usuarios empleen servicios de alojamiento y compartición de archivos. Además, parte de lo que ofrecen en este sentido varios de los proveedores es la instalación local de un programa para sincronizar automáticamente un directorio local con el almacenamiento remoto. ¿No es acaso esto, para todo propósito práctico, Infraestructura como un Servicio?

PaaS

Me costó un poco más de trabajo encontrar cómo el usuario final emplea plataformas. Una plataforma es algo que nos facilita nuestros desarrollos, que nos permite tomar piezas como bloques de construcción listos y construir sobre ellos. ¿Qué puede hacer un usuario final que pueda verse de este modo?

La respuesta se hace obvia cuando, nuevamente, extendemos las fronteras del significado. Viendo la cantidad de sitios Web que emplean mecanismos al estilo de OpenID u OAuth para la autenticación y autorización centralizada, ¿qué es esto sino el despliegue de una Plataforma como un Servicio?

Ahora bien, al hablar de cómputo en la nube, un tema que está siempre presente es el de la seguridad y protección de datos. Analicemos un poco la nube para usuarios finales desde este punto de vista.

Justamente en la columna que publiqué en la edición anterior de SG ya había comenzado a hablar de este tema (Cómo mantener un nivel aceptable de privacidad en nuestra vida en línea). No tiene caso reiterar esta conversación sobre privacidad que se ha vuelto parte de nuestra vida diaria, nuestros usuarios están ya mayormente al tanto de lo que significa depositar su confianza en sitios en red.

Se viene la tormenta: ¿Confiamos en nuestros proveedores?

Hay una gran cantidad de proveedores de servicios en la nube para los usuarios finales. Es más, casi todos ellos son gratuitos… tristemente, no podemos olvidar la máxima: ”En la nueva economía, no compras un producto, sino que Tú eres el producto”. Otorgar los datos de nuestros usuarios a Dropbox, Google, Slideshare o cualquier empresa de servicios puede vulnerar la confidencialidad de su información —lo cual resulta tan peligroso para ellos como individuos como para la organización entera.

Los proveedores que menciono no sólo representan un riesgo por las ya tan sonadas filtraciones que demuestran cómo agencias gubernamentales de todo tipo se han dedicado a la vigilancia invasiva, sino que también por la mera popularidad de dichos servicios: Los grandes proveedores son objetivo de ataques de forma prácticamente ininterrumpida. Y si bien el tiempo de respuesta ante incidentes es típicamente muy corto, la cantidad de documentos sustraídos al presentarse un ataque exitoso puede ser muy grande.

Con eso no quiero decir, obviamente, que el código que corramos en nuestro propio servidor sea más seguro o robusto que el que ejecutan los grandes proveedores. Sin embargo, al menos en el momento que se da a conocer un ataque, no dependemos de las prioridades de terceros para aplicar las medidas correctivas.

El borde plateado de mi propia nube

Dice el proverbio en inglés que ”toda nube tiene un borde plateado”, con lo que se refiere a que incluso los problemas tienen aspectos positivos. Teniendo esto en cuenta, podemos darle a nuestros usuarios las principales ventajas de muchas aplicaciones en la nube sin perder el control sobre nuestra información.

No acostumbro emplear el espacio que me brinda SG para promover productos específicos, pero en esta ocasión creo que vale la pena hacerlo, y es por ello que les platicaré sobre OwnCloud. OwnCloud es una respuesta a la necesidad de mantener el control de los datos de nuestros usuarios. Es una aplicación web muy fácil de instalar y utilizar que implementa una impresionante cantidad de servicios que nos permiten hospedar los datos de nuestros usuarios en casa. Y no es una solución artesanal, además de una aplicación Web limpia e intuitiva como pocas, hay clientes para el escritorio y dispositivos móviles. Es software libre, y la empresa que dirige su desarrollo ofrece también planes comerciales de servicio y desarrollo a medida.

OwnCloud también puede ser visto por nosotros los programadores como una plataforma de despliegue corporativo de aplicaciones: es una aplicación modular, escrita en PHP, con una extensa documentación para los desarrolladores de aplicaciones. Y respecto al núcleo de OwnCloud, su desarrollo se realiza en GitHub, con lo cual es fácil darle seguimiento y participar en su desarrollo. El equipo de desarrollo de OwnCloud ha logrado incorporar la responsividad y usabilidad de HTML5 a un nivel que me tiene francamente sorprendido.

¿Y qué tipo de aplicaciones podemos encontrar? Hay de todo. Probablemente la funcionalidad más socorrida es la de espacio de almacenamiento y sincronización de archivos, al estilo de Dropbox. La instalación por defecto de OwnCloud incluye una serie de aplicaciones básicas de productividad (calendario, contactos, gestor de marcadores, reproductor de medios). Si bien es cierto que todas son ya bastante comunes y que ninguna de ellas es ya un “killer app”, su valor está en que estos servicios, que ya asumimos como un lugar común, los podemos proveer desde nuestro propio equipo. Y en este sentido, cabe mencionar que, dado que implementa los protocolos CardDAV y CalDAV, OwnCloud puede operar como proveedor de datos para las principales aplicaciones de dispositivos móviles.

OwnCloud se va poniendo más interesante si planteamos su uso ya no sólo para un uso ocasional, sino como parte de los servicios centralizados de nuestra organización. Por ejemplo, puede manejar la autenticación de usuarios a través de LDAP, manejo de los archivos de los usuarios en los directorios en la red corporativa, y todo un largo etcétera. Una de las características más interesantes de la versión 6, liberada en diciembre del 2013, es la edición colaborativa de documentos.

Conclusión

A pesar de que esta columna parece en esta ocasión una inserción pagada (¡cosa que definitivamente no es!), espero aprecien por qué les presento esta alternativa en el número dedicado al cómputo en la nube. Nuestros usuarios tienen ya su concepción (y probablemente familiaridad) de cómo aprovechar a la famosa nube. Nosotros podemos, a través de herramientas como la que reseñé, contribuir de forma importante con la seguridad de su información. Aplicaciones que cubren algunos de los aspectos abordados hay muchas, pero —hasta donde tengo conocimiento— el nivel de integración y la variedad en la oferta de OwnCloud la hacen destacar.

( categories: )
Syndicate content