Categoría: FLOSS

Articulo, noticias y todo lo relacionado con el tema SoL, OpenSource, Free Culture

Commodity Cloud: Estrategia Multi-Cloud para evitar el vendor lock-in

cristian Deja un comentario

Las nubes públicas también tienen downtime

Si trabajás en IT, seguramente recordás alguno de esos días en que uno de los grandes proveedores de nube pública decidió tomarse un descanso. Estas interrupciones parecen volverse cada vez más frecuentes; ya no nos sorprenden. La mayoría de nosotros hemos sido afectados de alguna forma: aplicaciones caídas en todo el mundo, equipos en pánico, temas en tendencia en redes sociales, y ese incómodo mensaje en el dashboard de la nube: «servicio degradado». Mientras todos preguntan cuándo van a volver los servicios, nos preguntamos: ¿por qué dependemos tanto de un solo proveedor?

La respuesta siempre fue «porque es más fácil», «porque todos usan ese proveedor», o la clásica «porque lo decidió alguien que ya no trabaja más en la empresa». Pero hoy, entre muchos SREs e ingenieros DevOps, crece una filosofía de tratar a los proveedores de nube como lo que se denomina «commodity compute»: proveedores de infraestructura básica e intercambiable.

Esto no significa que todas las nubes sean iguales, pero la idea es que deberías poder mover tus aplicaciones de una a otra sin necesidad de refactorizar la mitad del código o la infraestructura. Tiene sentido, ¿no? Pero requiere estrategia, disciplina y las herramientas adecuadas para lograrlo.

Commodity Compute — qué significa ?

Imaginá que tu infraestructura en la nube es como la electricidad: no te importa si viene de plantas solares, eólicas o hidroeléctricas — solo querés que llegue de forma consistente y poder cambiar de proveedor si uno falla o te cobra de más. Eso es el commodity compute.

En términos técnicos, significa construir tus sistemas de modo que no dependan de servicios propietarios específicos de AWS, GCP o Azure. En lugar de usar AWS Lambda, DynamoDB o S3 directamente en tu código, construís capas de abstracción que puedan funcionar con cualquier proveedor. Si mañana Google Cloud ofrece mejor relación precio-rendimiento, o Azure tiene datacenters más cerca de tus usuarios, deberías poder migrar sin reescribir toda tu aplicación.

Esto es especialmente relevante cuando recordamos que:

  • Las nubes han experimentado múltiples cortes, cada vez más frecuentes.
  • Los precios de los proveedores varían entre sí y entre regiones.
  • Existen costos ocultos o difíciles de estimar, como los cargos por transferencia de datos.
  • Ciertas regulaciones exigen que determinados datos permanezcan en ciertas regiones o países.
  • El vendor lock-in (quedar atado a un proveedor) elimina tu poder de negociación.

Vendor lock-in

Es como firmar una hipoteca sin leer la letra chica. Los proveedores de nube saben cómo venderte conveniencia: configuraciones rápidas, servicios integrados y ejemplos de código que «simplemente funcionan». Pero esa conveniencia tiene un precio oculto: una dependencia de servicios propietarios que no existen fuera de ese ecosistema. Después descubrís que:

  • Tu código está atado a servicios propietarios. Si usaste AWS Lambda con API Gateway y DynamoDB, migrar a otra nube significa reescribir una parte enorme de tu aplicación. Ese «ahorro de tiempo» inicial se convierte en deuda técnica extremadamente cara.
  • Perdés tu poder de negociación. El proveedor puede ofrecerte descuentos por compromiso o volumen, pero no tenés la opción de irte a la competencia sin una inversión significativa. Cuando cambiar de proveedor implica reescribir tu app, estás negociando desde una posición de debilidad. El proveedor fija precios unilateralmente y tu única alternativa es aceptarlos o embarcarte en meses de migración costosa.
  • La resiliencia puede ser más frágil de lo que pensás. Sí, AWS tiene múltiples zonas de disponibilidad. Pero cuando toda la región us-east-1 tiene problemas (como ya ha ocurrido), tu «99.9% de disponibilidad» se evapora. Esto no significa que estar en más de una nube garantice mágicamente el uptime, pero hay buenas prácticas que apuntan en esa dirección.

Filosofía multi-cloud: soberanía, no caos

Acá es donde entra la estrategia multi-cloud. No se trata de duplicar todo en n nubes distintas — eso sería increíblemente caro y complejo — sino de diseñar sistemas que puedan ejecutarse en distintos proveedores sin cambios mayores.

La clave está en usar tecnologías y herramientas cloud-agnostic; es decir, herramientas que funcionan igual sin importar si estás en AWS, GCP o Azure. Esto se logra principalmente a través de:

1. Kubernetes

Kubernetes se ha convertido en el gran unificador; es el estándar de oro de la infraestructura en la nube: todos los grandes proveedores lo soportan (EKS en AWS, GKE en Google, AKS en Azure), y una vez que tu aplicación corre en Kubernetes, puede — en teoría — correr en cualquier lugar.

¿Por qué es tan poderoso? Porque abstrae las diferencias entre nubes. Tu aplicación se comunica con la API de Kubernetes, no directamente con AWS o Google. Los contenedores son portables por diseño.

Ojo: también existen características específicas de cada proveedor de Kubernetes, como Auto EKS o AKS Virtual Nodes, que añaden fricción al paradigma multi-cloud. Pero no entres en pánico: existe un ecosistema masivo de herramientas open source construidas para Kubernetes que funcionan perfectamente en cualquier nube.

2. Infrastructure as Code (IaC)

Escribir infraestructura como código no es nuevo, pero hacerlo de forma agnóstica requiere disciplina. Terraform y su fork open source, OpenTofu, son los estándares de facto: permiten definir la infraestructura (servidores, redes, bases de datos) en archivos de configuración que funcionan en múltiples proveedores.

En lugar de usar CloudFormation (AWS) o Azure Resource Manager, Terraform y OpenTofu ofrecen una sintaxis y flujo de trabajo comunes. Una advertencia: cambiar de proveedor no es trivial — los recursos de AWS no son intercambiables con los de Azure — pero al menos usás el mismo lenguaje de IaC. No tenés que aprender CloudFormation, ARM Templates ni Google Deployment Manager.

Lo más importante: podés gestionar infraestructura en múltiples nubes desde un único stack, habilitando verdaderas arquitecturas multi-cloud.

3. CI/CD neutral

Este es un error común: usar AWS CodePipeline o Azure DevOps parece conveniente al principio, pero te ata. En cambio, plataformas como Jenkins, GitLab CI o GitHub Actions con runners self-hosted te dan flexibilidad total.

ArgoCD y Flux son particularmente interesantes para despliegues en Kubernetes: implementan GitOps (donde tu repositorio Git es la «única fuente de verdad»), y funcionan de manera idéntica en cualquier cluster de Kubernetes, independientemente de en qué nube esté.

Mejores prácticas para lograr independencia

1. Usá herramientas open source y estándares abiertos

En lugar de CloudWatch (AWS), usá Prometheus para métricas y Grafana para visualización. En lugar de AWS Secrets Manager, usá HashiCorp Vault. En lugar de servicios propietarios de service mesh, podés optar por Istio o Linkerd.

Estas herramientas funcionan exactamente igual en cualquier cluster de Kubernetes, en cualquier nube. Sí, requieren más configuración inicial, pero te dan libertad y portabilidad.

2. Abstraé los servicios de almacenamiento

Los buckets de almacenamiento (S3, Cloud Storage, Blob Storage) son similares pero tienen APIs diferentes. Usá bibliotecas que abstraigan esas diferencias — como s3fs, que puede trabajar con múltiples backends compatibles con S3 — o implementá tu propia capa de abstracción.

Para bases de datos, optá por soluciones que puedas ejecutar en cualquier lugar: PostgreSQL, MySQL, MariaDB o Valkey. Si bien las versiones gestionadas de los proveedores son convenientes, correr las versiones open source en Kubernetes te da portabilidad total.

3. Implementá observabilidad cloud-agnostic

La observabilidad (logs, métricas, trazas) es crítica, pero evitá las soluciones propietarias. OpenTelemetry es el estándar emergente que permite recolectar telemetría de forma unificada, independiente del proveedor.

Tu stack de observabilidad podría verse así:

  • OpenTelemetry para recolectar métricas y trazas.
  • Fluentd o Loki para logs.
  • Prometheus para almacenar métricas.
  • Grafana para visualización.
  • Jaeger o Tempo para trazabilidad distribuida.

Este setup funciona en cualquier nube, e incluso on-premises si fuera necesario.

4. Diseñá SLIs y SLOs neutros

En SRE, definís Service Level Indicators (SLIs) y Objectives (SLOs) para medir la confiabilidad. Estos deben ser independientes del proveedor: «99.9% de solicitudes exitosas» o «latencia p95 menor a 200ms» son métricas universales.

Al medir desde fuera del proveedor de nube (usando tus propias herramientas de monitoreo), podés comparar objetivamente el rendimiento entre proveedores. Esto no solo te da los datos para decidir dónde correr cada workload, sino también evidencia concreta si necesitás negociar precios o cambiar de proveedor.

5. Automatizá, automatizá, automatizá

El multi-cloud solo es viable si está altamente automatizado. Desplegar manualmente en tres nubes distintas sería una pesadilla; por eso necesitás:

  • IaC para toda la infraestructura.
  • GitOps para deployments (ArgoCD, Flux).
  • Automatización de backups cloud-agnostic (por ejemplo, Velero para Kubernetes).
  • Planes de Migración, DRP (Plan de Recuperación ante Desastres) y BCP (Plan de Continuidad de Negocio) regularmente testeados.
  • Policy as Code con herramientas como OPA (Open Policy Agent) o Kyverno.

El objetivo SRE aquí es reducir el «toil» (trabajo manual repetitivo). Si cambiar de nube requiere semanas de esfuerzo manual, no es verdaderamente portable.

Kubernetes Federation: cómo dominar entornos multi-cluster

Cuando operás en múltiples nubes, probablemente tenés varios clusters de Kubernetes. Gestionarlos uno por uno sería un caos. Acá entran las herramientas de orquestación y federación multi-cluster:

  • Crossplane te permite gestionar infraestructura cloud usando la API de Kubernetes, bajo licencia Apache 2.0. Básicamente, definís recursos de AWS, GCP o Azure como objetos de Kubernetes, y Crossplane los provisiona. Es IaC «a la manera de Kubernetes», completamente open source.
  • Karmada es un sistema de orquestación multi-cloud que permite desplegar aplicaciones en múltiples clusters simultáneamente, con políticas de distribución y failover automático. También bajo licencia Apache 2.0.
  • Open Cluster Management es un plano de control centralizado para gestionar clusters de Kubernetes existentes y crear nuevos. Usa el modelo hub-spoke para controlar los clusters y aprovecha herramientas como Argo CD y Open Policy Agent para orquestar políticas, deployments, recuperación ante desastres y más. Es extensible con add-ons y su licencia es Apache 2.0.

La clave es tener un plano de control unificado sin depender de soluciones propietarias como Google Anthos o Azure Arc — que, irónicamente, crean lock-in mientras prometen libertad multi-cloud.

Seguridad y Compliance en multi-cloud

En entornos multi-cloud, la seguridad requiere consistencia. No podés tener políticas distintas para cada nube, porque los errores de configuración están entre las principales causas de incidentes de seguridad según el OWASP Top 10 2025.

Para prevenirlo, debemos usar Policy as Code para definir reglas una vez y aplicarlas en todos lados. Algunas herramientas disponibles:

  • OPA Gatekeeper o Kyverno para políticas de Kubernetes.
  • Falco para detección de amenazas en runtime.
  • Trivy o Grype para escaneo de vulnerabilidades en contenedores.

Para Identity and Access Management (IAM), deberías implementar OIDC (OpenID Connect) con proveedores como Keycloak que podés correr en cualquier lugar, en lugar de depender completamente del IAM nativo de cada nube.

Estrategias de Migración y Recuperación ante Desastres

Una de las ventajas menos obvias del multi-cloud es la resiliencia ante desastres. Si diseñaste tu arquitectura correctamente, podés lograr:

  • Failover automático: ante una interrupción o degradación en una región de AWS, el tráfico se redirige automáticamente a GCP. Esto se logra mediante DNS con health checks, balanceadores de carga globales y replicación de datos entre proveedores.
  • Migraciones graduales: no necesitás migrar todo de una vez. Podés mover workloads específicos a distintas nubes según tus necesidades: cargas pesadas donde sean más baratas, APIs de baja latencia cerca de los usuarios, y datos sensibles en nubes con compliance certificado que cumpla las leyes locales.
  • Testing continuo: una parte central de la filosofía SRE es testear regularmente tus runbooks de DR. Simulá que AWS desapareció y validá que podés levantar todo en GCP en minutos, no en días.

Trade-offs: porque no todo es color de rosa

Seamos honestos: el multi-cloud no es gratis ni trivial. Hay que reconocer varios desafíos clave:

  • Complejidad operativa: gestionar múltiples nubes es significativamente más complejo que quedarse en una. Requiere expertise en distintos proveedores, monitorear más piezas en movimiento y mantener una huella de infraestructura más grande.
  • Costos iniciales: la implementación requiere una inversión real: tiempo de ingeniería, tooling especializado y automatización pesada. Es una apuesta a mediano-largo plazo, no una victoria rápida.
  • Networking: mover datos entre nubes es caro — muy caro. Los proveedores cobran altos egress fees, y también hay que considerar la latencia. Necesitás una arquitectura inteligente para minimizar transferencias entre nubes y reducir la latencia donde el rendimiento del servicio es crítico.
  • No siempre es necesario: una startup en etapa temprana probablemente no necesite multi-cloud. El enfoque «commodity» tiene más sentido para organizaciones que tienen:
  • Workloads críticos con tolerancia cero al downtime.
  • Requerimientos regulatorios complejos.
  • Escala suficiente para que el vendor lock-in sea un riesgo material.
  • El presupuesto para invertir en portabilidad.

El futuro es portable

Tratar a los proveedores de nube como commodity compute es más que una decisión técnica; es una postura estratégica sobre control, resiliencia y costos. En un mundo donde la dependencia de un único proveedor puede costarte millones en una negociación contractual desfavorable — o donde una sola interrupción puede paralizar todo tu negocio — la portabilidad es una póliza de seguro valiosa.

Los estándares abiertos y el ecosistema CNCF son maduros hoy. La parte difícil no son las herramientas. Es operarlas en producción, a escala empresarial, en múltiples nubes, sin que el toil consuma vivo a tu equipo.

No necesitás estar en tres nubes simultáneamente desde el día uno, pero sí necesitás diseñar como si pudieras estarlo mañana. Usá abstracciones, evitá servicios específicos del proveedor — especialmente cuando existen alternativas open source viables — automatizá todo y mantené tus opciones abiertas.

Porque al final del día, cuando AWS, GCP o Azure caigan (y va a pasar), vas a querer un Plan B — y será mucho más fácil de ejecutar si lo diseñaste desde el principio.

El camino hacia la independencia en la nube es largo, pero cada paso que das para reducir el vendor lock-in es un paso hacia mayor control, mejor resiliencia y una arquitectura más sostenible a largo plazo.

Recursos recomendados y referencias

SoftwareSitio oficial
Kuberneteshttps://kubernetes.io
OpenTofuhttps://opentofu.org
Prometheushttps://prometheus.io
Grafanahttps://grafana.com
OpenTelemetryhttps://opentelemetry.io
Crossplanehttps://www.crossplane.io
Karmadahttps://karmada.io
Pluralhttps://www.plural.sh
Istiohttps://istio.io
Linkerdhttps://linkerd.io
Vault (HashiCorp)https://developer.hashicorp.com/vault
OPA Gatekeeperhttps://open-policy-agent.github.io/gatekeeper/website
Kyvernohttps://kyverno.io
Falcohttps://falco.org
Trivyhttps://trivy.dev

Esta es una traducción al español mi articulo original: https://www.linkedin.com/pulse/commodity-cloud-multi-cloud-strategy-avoid-vendor-lock-in-netlabs-vttuf

DNSCrypt o cómo asegurar nuestras consultas DNS

cristian Deja un comentario

Cuando usas HTTPS o SSL para navegar, consultar correo o usando algun otro programa estas haciendo que tu tráfico sea encriptado (generalmente)

Pero qué pasa con las consultas DNS ? Aun cuando el tráfico sea encriptado,  incluso haciendo uso de una VPN tus consultas a los DNS va en plano.

Esto deja la puerta abierta no solo a ataques de spoofing o MitM (man-in-the-middle) sino que implica que tu proveedor de DNS pueda guardar un registro de tus consultas  y ayudar a espiarnos a gobiernos e instituciones.

DNSCrypt nos viene a ayudar a proteger nuestras consultas DNS.

update: 02/02/2018

El proyecto original murio, quedaron como alternativas:

dnscrypt-proxy

DNSCurve

o el recomendado por los desarrolladores originales: DNS-over-TLS, tenta es un browser para android y da unas guías de como usarlo.

DNSCrypt

Qué és?  Según wikipedia:

DNSCrypt es una implementación de DNSCurve, que sirve para cifrar el tráfico  DNS entre el ordenador del usuario y los servidores de nombres de OpenDNS. La implementación de DNSCrypt en OpenDNS se puede realizar mediante la  instalación del servicio DNSCrypt.org.

Este programa corre en *nix, OSX, Windows, Android, iOS y algunos routers, tanto el servidor
como el cliente tiene sus fuentes en github (https://github.com/jedisct1/dnscrypt-proxy)
con permisos para usar, copiar modificar y/o distribuir.

La instalación es simple (está en paquetes de ubuntu), está bien documentada y su puesta a punto es sencilla.

Básicamente su funcionamiento es:

El cliente traslada la consulta regular a una consulta autenticada, la reenvía a un servidor DNSCrypt y la respuesta la verifica y la reenvía al cliente si esta es genuina.

Interesanet es ver el protocolo QUIC (Quick UDP Internet Connections https://en.wikipedia.org/wiki/QUIC) interesante ver que esta relacionado con Chrome, SPDY y HTTP-2.

También se puede configurar para usar UDP/ TCP en el puerto 443, este puerto generalmente no está bloqueado por los routers o ISPs como sí puede estarlo el puerto estándar DNS o alguno otros puertos pero puede ser mas lenta la respuesta.

Sin lugar a dudas no es la solucion, que seria su uso en conjunto con DNSSec pero es una
capa mas de protección a agregar a nuestro arsenal digital.

Algunas capturas de wireshark.

Normal DNS
Consulta normal DNS

 

Con DNSCrypt
Con DNSCrypt

 

[ZIMBRA] Protegernos contra ataques DoS postfix AUTH

cristian Deja un comentario

En un cliente tuvimos problemas ataques varios contra el servidor de correo Zimbra, aparte de problemas por weak passwords (decisiones gerenciales) y la costumbre de poner «123456» y «qwaszx12» que se rompen por diccionario fácilmente.

Luego de que tomaran conciencia de esto y mejorar mucho el manejo de claves igualmente seguimos sufriendo ataques constantes.

Usamos entre otras cosas fail2ban junto a zimbra desde hace algún tiempo ( [ZIMBRA] ENFRENTANDO EL SPAM CON FAIL2BAN )

Ultimamente aumentaron los ataques contra postfix y las reglas del fail2ban que usabamos no las filtraban

En el log se los ve así :

Apr 6 06:30:49 mail postfix/smtpd[00000]: connect from unknown[151.237.190.118]
Apr 6 06:30:49 mail postfix/smtpd[00000]: lost connection after AUTH from unknown[151.237.190.118]

Así que creamos las siguientes reglas en el fail2ban

1: Agregar esto al final de /etc/fail2ban/jail.local

[zimbra-auth-dos]
enabled = true
filter = zimbra-auth-dos
action =iptables-allports[name=Zimbra-auth-DoS]
logpath = /var/log/zimbra.log
ban= 600
retry=5

2: Crear el filtro /etc/fail2ban/filter.d/zimbra-auth-dos.conf

[Definition]
failregex = lost connection after AUTH from (.*)\[<HOST>\]
ignoreregex =

3: Reiniciar fail2ban y luego de 5 intentos los bloqueamos por 600s

 

 

[Zimbra] Deshabilitar IM

cristian Deja un comentario

Para un cliente, en el cual corremos Zimbra desde hace muchos años surgió la necesidad de deshabilitar el IM para algunos usuarios, surge por el problema de la distracción de sus tareas al tenerlo habilitado.

Las formas para hacerlo, funciona en versiones 7.x o anteriores es y desde consola:

Para todo el dominio/COS especifico:

zmprov mc default zimbraFeatureIMEnabled FALSE
zmprov mc default zimbraFeatureInstantNotify FALSE
zmprov mc default zimbraPrefIMAutoLogin FALSE

Para un usuario especifico:

zmprov ma [email protected] zimbraFeatureIMEnabled FALSE
zmprov ma [email protected] zimbraFeatureInstantNotify FALSE
zmprov ma [email protected] zimbraPrefIMAutoLogin FALSE
Gracias Zimbra 😉

Android 5.1 a 5.1.1 en dispositivo Stock con root y recovery

cristian Deja un comentario

Hace unos días GOOGLE publico las imágenes de fabrica para nuestros Nexus de Android 5.1.1. Como en mi post anterior puse los pasos para actualizar a la versión 5.1 y a instalarle el custom recovery para luego rootear y aplicar los mods que mas nos gusten, todo esto sin perder nuestros datos claro. El problema de estos pasos es que al notificarnos del OTA el dispositivo y querer realizarlo no podremos por tener el custom.

Para esto debemos recurrir a un equipo u seguir los siguientes pasos.

Bajar la imagen correspondiente de google. https://developers.google.com/android/nexus/images

Ir a la carpeta donde tenemos el adb y el fastboot y descomprimir todo allí, incluido lo que este dentro de image-hammerhead-lmy48b.zip

#adb reboot bootloader (o reiniciamos con bajar volumen al encenderlo)

#fastboot flash bootloader bootloader-hammerhead-hhz12h.img
#fastboot flash boot boot.img
#fastboot flash radio radio-hammerhead-m8974a-2.0.50.2.26.img
#fastboot flash system system.img
#fastboot flash cache cache.img

Colocarle nuevamente el custom recovery

#fastboot flash recovery archivo.img

(tip: colocarle el cwm en lugar del TWRP ya que no lo carga por alguna razón), reiniciar y copiarle el SuperSU, flashear y listo el root.

Captive portal en PFSense

cristian 2 comentarios

Recientemente tuve que armar un firewall para mi trabajo  para acceso inalámbrico de usuarios a la red, que implicaba ciertos requerimientos de seguridad entre ellos limitar el acceso de cierta manera.

Esto lo llevé adelante con un viejo equipo (Celeron 1.3Ghz 512MB Ram, 3 NICs y 40HDD) usando pfsense como Software, un excelente appliance de firewall basado en FreeBSD.

Con él, brindo DHCP leases para la LAN y DHCP para la wifi, ambas interfaces con DNS Forwarder, requisito básico para que el portal cautivo funcione correctamente. Como HW APs estamos usando Ubiquiti Unifi, que necesitan de un controlador (software) instalado en el mismo pfsense (java requerido) que brinda unas funcionalidades muy interesantes.

Lo que no me gustaba era el  portal cautivo, el cual pfsense permite crear uno propio para login (entre varias cosas interesantes que se puede hacer), me encontré con el problema de la visualización en dispositivos móviles (smartphones, tablets,etc) así que adapté una página de login que se adapta al dispositivo.

Como no di con nada «bonito» es que dejo a disposición la siguiente: acá.

 

Gracias Gabriel por las correcciones. 🙂

 

Comunicado de la comunidad sobre Ley de Software Libre y Formatos Abiertos en el Estado

cristian

Las comunidades de Software Libre del Uruguay expresamos nuestra satisfacción ante la perspectiva de contar con una Ley que dispone la utilización de formatos abiertos y promueve la adopción de Software Libre en ámbitos del Estado .

Saludamos con entusiasmo este avance en el camino hacia una sociedad más libre realizado por la Cámara de Representantes, al otorgar media sanción parlamentaria al Proyecto de Ley de Software Libre y Formatos Abiertos en el Estado, y manifestamos nuestro deseo de su pronta aprobación en la Cámara de Senadores. A la vez, ofrecemos nuestra colaboración para responder consultas o establecer un diálogo en torno a dicho proyecto; así como en todo lo relativo a su futura reglamentación.

Particularmente, en el contexto del Estado, el Software Libre y los formatos abiertos son la forma de garantizar libertad, soberanía e independencia tecnológica. Esta ley es condición necesaria para la preservación y el acceso futuro a la información pública, favoreciendo un control genuino en que la autoridad del Estado no esté limitada por los vaivenes del mercado o por las condiciones restrictivas de ciertos licenciamientos. Además, beneficia a todos los ciudadanos, permitiendo el acceso igualitario a la información de la administración pública, sin obligarles a instalar en sus computadoras software que no desean, ni imponer gastos evitables para acceder a la información. Por último, favorece a la transparencia necesaria e imprescindible a otras tareas pendientes, como la Reforma del Estado.

Un Software es libre si puede ser ejecutado con cualquier propósito, estudiado, modificado y compartido, sin restricción alguna. Esto favorece la libertad y el dominio de la tecnología por las personas, tanto a nivel individual como colectivo. Software Libre no se refiere a una tecnología en particular, sino que es una forma de licenciar el software.

El uso de Software Libre en el Estado proporciona independencia de los proveedores al liberarse de la dependencia generada por el software privativo y/o los formatos cerrados, lo cual además le protege de tener que realizar permanentemente costosas actualizaciones. Posibilitando además, el intercambio y la reutilización de todo o parte del código fuente y la colaboración en el desarrollo del mismo, con lo cual su producción se hace más eficiente, optimizando los recursos humanos y materiales del Estado.

Cabe destacar que este proyecto de ley habla de “…Software Libre en el Estado…”. Sin embargo, la paulatina implantación de Software Libre por parte del Estado uruguayo traerá aparejados también, cambios a nivel del sector de las tecnologías de la información que hoy brindan este servicio al Estado. Por lo cual, es normal la incertidumbre manifiesta por alguna parte del sector privado. No obstante, este cambio será beneficioso para el Estado y la industria por varias razones:

  • Buena parte del dinero que actualmente se va del país en el pago de licencias de software privativo, se invertirá en desarrollo y mantenimiento de software a nivel local.

  • Se empleará más mano de obra calificada y sus beneficios quedarán en el país, diversificando así la matriz productiva.

  • Mejorará la distribución de la riqueza, estimulando a las pequeñas y medianas empresas innovadoras, y a los equipos de trabajo estatales.

  • Generará un proceso de apropiación tecnológica, alcanzando una masa crítica de profesionales capaces de estimular un desarrollo tecnológico autosustentable a nivel nacional.

La aplicación de esta ley propiciará un ecosistema que fortalecerá a las pequeñas y medianas empresas innovadoras y competitivas, de fuerte valor agregado, dándoles mejores posibilidades de competir con productos que pueden modificar y adaptar a las necesidades del organismo estatal contratante.

En el ámbito educativo, el proyecto encuentra su justificación en la propia Ley de Educación, cuando sostiene que “el educando debe ser sujeto activo en el proceso educativo para apropiarse en forma crítica, responsable y creativa de los saberes”, o cuando promueve “la comprensión y apropiación social del conocimiento científico y tecnológico para su democratización”. El Software Libre claramente apunta a cumplir con estos planteamientos, al dejar todas las puertas abiertas para profundizar y apropiarse del conocimiento; el software privativo, por el contrario, genera una situación de dependencia de quien usa el software con la empresa que monopoliza su desarrollo.

La educación debe formar ciudadanas y ciudadanos libres, capaces de ejercer sus derechos y de participar, en democracia, en la vida social y económica. Por otro lado, en un sector tan dinámico como el de las tecnologías de la información, el mercado laboral que conocerá un estudiante a lo largo de su vida activa será muy cambiante y diferente al de hoy. Por todo lo expuesto, con Software Libre se puede lograr, como establece la Ley de Educación, “que las personas adquieran aprendizajes que les permitan un desarrollo integral relacionado con aprender a ser, aprender a aprender (…)” y “alcanzar una real igualdad de oportunidades para el acceso, la permanencia y el logro de los aprendizajes”.

Por lo expuesto, entendemos que en la situación actual donde las tecnologías de la información y comunicación son tan importantes para la sociedad, el uso de Software Libre en el Estado es lo único que le garantiza soberanía e independencia tecnológica, eficacia y eficiencia en el cumplimiento de sus cometidos. Exhortamos a Senadoras y Senadores a atender estos principios fundamentales y aprobar la LEY DE SOFTWARE LIBRE Y FORMATOS ABIERTOS EN EL ESTADO.

El Software Libre es Socialmente justo, Técnicamente viable y Económicamente sostenible.

13 de Marzo de 2013

www.cesol.org.uy – linuxpay.org – linuxsalto.org – Mozilla Uruguay – www.softwarelibre.edu.uy(external link) – www.linux.org.uy –www.ubuntu.org.uy – www.datauy.org – www.cei.fing.edu.uy – Comunidad gvSIG Uruguay

Descargar en PDF: Comunicado_de_las_Comunidad_de_Software_Libre

eVoto en Brasil, resultado de seguridad

cristian Deja un comentario
Hace poco la autoridad electoral de Brasil abrió un concurso para evaluar la seguridad de sus urnas electrónicas?
Bien, un investigador logró comprometer el secreto del voto a través de la lectura de frecuencia radioeléctrica
http://idgnow.uol.com.br/seguranca/2009/11/20/perito-quebra-sigilo-eleitoral-e-descobre-voto-de-eleitores-na-urna-eletronica/
«»Fiz meu experimento em 29 minutos e obtive sucesso no escopo que estava proposto: rastrear a interferência e gravar arquivos para comprovar a materialidade do fenômeno», que sintonizam ondas longas e curtas e estações em AM e FM.»
En el artículo hay un link a un video que muestra cómo se puede leer lo que hace un teclado a unos 20 metros de distancia http://vimeo.com/2007855
Es impresionante.  Así que ahora veremos cómo se las ingenian los brasileros para arreglar esto.
En Holanda, el ataque público fue similar.  Un grupo de hackers logró leer las emisiones de las urnas desde una buena distancia y probar que las urnas ponen en riesgo el secreto del voto.
La solución holandesa fue volver al papel y no gastar más pólvora en chimangos (o euros en urnas electrónicas). Veremos qué hace Brasil con todo esto ahora

Con referencia a mi anterior post sobre la posibilidad de voto electrónico en Uruguay me tope con el resultado de la autoridad electoral de Brasil que abrió un concurso para evaluar la seguridad de sus urnas electrónicas?

Bien, un investigador logró comprometer el secreto del voto a través de la lectura de frecuencia radioeléctrica

http://idgnow.uol.com.br/seguranca/2009/11/20/perito-quebra-sigilo-eleitoral-e-descobre-voto-de-eleitores-na-urna-eletronica/

«»Fiz meu experimento em 29 minutos e obtive sucesso no escopo que estava proposto: rastrear a interferência e gravar arquivos para comprovar a materialidade do fenômeno», que sintonizam ondas longas e curtas e estações em AM e FM.»

En el artículo hay un link a un video que muestra cómo se puede leer lo que hace un teclado a unos 20 metros de distancia http://vimeo.com/2007855

Es impresionante.  Así que ahora veremos cómo se las ingenian los brasileros para arreglar esto.

En Holanda, el ataque público fue similar.  Un grupo de hackers logró leer las emisiones de las urnas desde una buena distancia y probar que las urnas ponen en riesgo el secreto del voto.

La solución holandesa fue volver al papel y no gastar más pólvora en chimangos (o euros en urnas electrónicas).

Veremos qué hace Brasil con todo esto ahora, y que pasa con nuestros presidente (Jose Mujica) quien destacaba la necesidad de instrumentar esto en nuestro país.  (que en Brasil pueden participar 130 millones de electores y «en tres horas están los resultados».)

Voto electrónico,no nos dejemos engañar

cristian 2 comentarios

… y el por que debemos rechazar este tipo de propuestas. 

[Update 17/6/24]

El tema de voto electrónico no es la primera vez en ser discutido en nuestro país, en el año 2007, el señor Garcia Pintos lo planteo (http://www.ladiaria.com.uy/files/ladiaria_20070815web.pdf), pero el proyecto por suerte no se concreto.

El día de hoy me dispongo a escuchar la radio, y leer los diarios, como realizo habitualmente cuando me encuentro con la noticia de que el pre-candidato del FA José Mujica, pone este tema nuevamente en opinión pública. (http://www.espectador.com/1v4_contenido.php?id=158649&sts=1)

También lo manifestó Pedro Bordaberry en Marzo de 2014 en una presentación en la cámara de las comunicaciones

Recientemente José Amorín público en twitter y me entero por un comentario de Asti que el FA presentó un proyecto de incluir eVoto en las elecciones nacionales de 2014.
Si bien personalmente considero esta idea muy mala, no es que simplemente porque lo diga yo, sino que lo dictan las experiencias en este tema que se han realizado en todo el mundo, de las cuales voy a hacer referencia, demostrando que nuestros políticos estas mas que mal asesorados.:

– Holanda: El 16 de mayo de 2008, el Gobierno Holandés resolvió que las elecciones en Holanda serán realizadas usando sólo boletas en papel y lápices rojos. La propuesta para trabajar en el desarrollo de una nueva generación de computadoras de votación fue descartada completamente.
Fuente: http:/ /www.wijvertrouwenstemcomputersniet.nl/

– La corte constitucional alemana emitió un fallo ejemplar, prohibiendo el uso de urnas electrónicas por violar el principio de auditabilidad, el principio de que las elecciones son un acto público, que mediado por computadoras perdía este atributo básico de cualquier democracia.
Fuente: http://www.elespectador.com/columna137468-inconstitucionalidad-del-voto-electronico-alemania

– La empresa fabricante de las máquinas de votación que se usan en la mitad de los condados del Estado de Ohio en EEUU admitió que tienen errores de programación que hacen que se pierdan votos. “El problema no puede ser resuelto antes de las elecciones del 4 de noviembre, por lo que los ejecutivos de Premier Election Solutions (antes Diebold) y la Secretaria de Estado Jennifer Brunner están trabajando en una serie de guías para que los condados puedan detectar y evitar estos problemas” informó The Columbus Dispatch.
Fuente: http://www.vialibre.org.ar/2008/09/28/las‐maquinas‐de‐votacion‐no‐se‐arreglan‐antes‐de‐4‐de‐noviembre/

– Un nuevo informe de la Oficina de Responsabilidad Gubernamental sobre el sistema de votación indica que la Comisión de Asistencia en Elecciones no ha notificado a los oficiales electorales de numerosos condados sobre las fallas en las máquinas de emisión de votos. En tanto, un nuevo estudio de las organizaciones Common Cause y Century Foundation encontró que por lo menos 10 estados importantes tienen significativos problemas en sus sistemas de votación que no fueron resueltos desde la última elección.
Estos 10 estados, según Common Cause son: Colorado, Florida, Georgia, Michigan, Missouri, New Mexico,Ohio, Pennsylvania, Virginia y Wisconsin.
Los problemas detectados van desde un amplio margen de errores en las máquinas de votación, hasta fallas en el registro electrónico. “Encontramos muchos problemas donde la gente está siendo eliminada de las bases de votación porque sus nombres están mal registrados: como por ejemplo, que digan Alex en lugar de Alexander o que contengan iniciales de segundo nombre o no” indicó Susan Geenhalgd de Voter Action.
“Estos son problemas que están siendo creados por restricciones del software que son errores y que en muchos casos están quitando a la gente la posibilidad de votar”. Esto se está solucionando con el otorgamiento de boletas provisoras para los votantes con problemas en el registro. Tova Wang, de Common Cause dijo que hay una “alta probabilidad de que con la cantidad de nuevos votantes que tenemos, haya una demanda enorme de estas boletas provisorias” y agregó que excepto en uno de esos 10 estados “los estados involucrados no están haciendo nada para asegurarse que haya de estas boletas provisorias a mano en suficiente cantidad para no quedarse sin ellas” agregó.
Fuente: CNN. Http://www.cnn.com/2008/POLITICS/09/18/voting. problems/index.html?iref=werecommend
Adaptación al español: Fundación Vía libre

– Al parecer, problemas de estática provocaron el misterioso sobrante de votos registrado en las primarias de septiembre en Washington. Los oficiales del Consejo electoral de Washington DC encontraron una explicación a los 1500 votos fantasma registrados en las primarias de Septiembre, en las que 326 personas asistieron a votar en el Centro Reeves. Cuando sus votos fueron sumados, sin embargo, aparecieron 1500 sufragios de la nada,
que según las explicaciones publicadas esta semana en la prensa, se debieron a una descarga de estática. “Una de las posibles causas podría ser una descarga de electricidad estática” dijo Errol Arthur, miembro del Consejo Electoral de Washington DC, lo que provocó reacciones que van desde la risa hasta la preocupación por parte de los votantes y demás miembros del consejo. El problema central es que esos mismos equipos que dibujaron 1500 votos fantasma en las primarias de septiembre serán utilizados en las presidenciales del próximo 4 de noviembre en el mismo condado.
Fuente: http://www.news8.net/news/stories/1008/55813 8.html
Adaptación al español en http://www.vialibre.org.ar/2008/10/03/la‐culpa‐es‐de‐la‐estatica/

– El voto electrónico impide el reconteo en Venezuela
En Venezuela funciona el voto electrónico, por lo que la titular del máximo organismo de justicia, Luisa Morales, consideró que se ha engañado al pueblo al hablar de auditoría manual. http://www.telegrafo.com.ec/noticias/informacion-general/item/el-voto-electronico-impide-el-reconteo-en-venezuela.html

– Destacados profesores investigadores en seguridad informática de Brasil, luego de los cambios realizados en Brasil en favor de estos sistemas alertan del peligro (Original en Portugués. Documento disponible en línea en http://www.votoseguro.com/alertaprofessores/

– En San Antonio del Este, Argentina se aprueba una ordenanza en el mes de Julio de 2008 en el Concejo Deliberante de la Ciudad de San Antonio Oeste / Las Grutas para derogar la Ordenanza 2454 que autorizó el uso de urnas electrónicas en las elecciones municipales del 16 de diciembre de 2007.  http://www.vialibre.org.ar/2008/07/22/san-antonio-oeste-derogo-la-ordenanza-de-voto-electronico/

-En EEUU, se cree que en 2004 George W. Bush gano las elecciones gracias a un “fraude tecnológico de las corporaciones que fabrican las máquinas electrónicas de votación”, que son las mismas que “proveen al Gobierno, a través del Pentágono, con lucrativos materiales y equipos para su guerra en Irak”, según un artículo publicado por una página de Internet de una universidad de EEUU. Un resumen www.ejfi.org/Voting/Voting.htm

– Nicolás Maduro reconoció  en 2013 que gracias al voto electronico identifico a 900.000 venezolanos que votaron en su contra 

– Dilma Rousseff ganó por 3.360.000 votos, hubo 5.200.000 anulados, mira como fallaban las maquinas al votar por el opositor

– En 2015 Bs.As. Argentina, en las elecciones generales allanaron y detuvieron a investigadores que descubrieron fallas en el sistema de la empresa MSA

EFF: Buenos Aires Censuró y Allanó A Quienes Reportaron Falencias del Voto Electrónico
La Nacion: Detectó fallas en el sistema de boleta electrónica y allanaron su casa

-Salta: denuncian irregularidades en el sistema de voto electrónico: «un grupo de votantes de dos escuelas de esa ciudad, pasaron 15 minutos intentando votar a candidatos de la oposición, pero las máquinas no se lo permitían ya que imprimían boletas con los candidatos por el oficialismo.» Nota Perfil.com y de Clarin.com

2024: El voto electrónico fue un desastre en las elecciones de Puerto Rico: tuvieron que volver al papel para estar seguros

Votos que no coinciden. En una rueda de prensa, las autoridades de Puerto Rico explicaron que había errores en centenares de actas, en concreto 91 actas del Partido Nuevo Progresista y en 30 del Partido Popular Democrático. En estas actas había discrepancias entre el número de votos adjudicado y el recuento de votos.

Bien, ahora, el porqué la mayoría de los que trabajamos en informática, y más que nada relacionados al FLOSS estamos en contra del eVoto.

Según palabras de RMS, que me gustaron y me gustaría citarlas:

“Ciertamente, quienes venimos del campo de la política de la tecnología, como los activistas del software libre, sabemos perfectamente que las tecnologías distan mucho de ser neutrales y que existen discusiones sobre quién controla realmente los avances de la ciencia y la técnica. Quizás esa sea la razón por la cual el voto electrónico, que tanto y tan profundamente ha permeado en grandes sectores, no lo ha hecho entre quienes trabajan en Software Libre o se especializan en seguridad de sistemas de información, ámbitos en los que genera desconfianzas profundas.
Será tal vez porque desde esos sectores que trabajan cotidianamente con las nuevas tecnologías se entiende realmente que la idea de neutralidad y transparencia asociada a la tecnología no es más que una falacia y una construcción que se ha impuesto a fuerza de discursos interesados, armados para consolidar estas herramientas. Misteriosamente, o tal vez no, son estos sectores los que están deliberadamente excluidos del debate sobre voto electrónico.”

Una cosa es cierta, el eVoto es cambiar el sistema que usamos actualmente. De poner un hoja dentro de un sobre, a votar con una computadora, la computadora ejecuta un programa, este puede ser reemplazado temporalmente, por uno que realice una cuenta mal de los votos, alterando de esta forma los resultados y la expresión de un pueblo.

La idea de tener los resultados en 3 o menos horas no es verdad, esto es una mentira total, en las elecciones que ganó (ganó?) George W. Bush los resultados demoraron más de una semana. Hoy por hoy, con el sistema tradicional tardamos un par de horas en tener los primeros datos y confiables.

Otra cosa que se argumenta en favor del eVoto es el costo, donde se quiere justifica que el eVoto es mas barato. Esto es mentira, el costo que tiene: equipos, cableado, impresoras, tonner, papel, mantenimiento, servidores, administradores, electricidad y conectividad. Traslados, fletes y repuestos.
Esto puede salir mas barato que los sobres que se usan ? Las cajas metálicas que tenemos y los gastos de personal asociado ?

“El voto electrónico es infalible porque las computadoras no se equivocan”. A la imposibilidad de fiscalización de lo que un programa efectivamente hace, se suma la inmensa posibilidad de errores, fraudes y fallas al que cualquier sistema electrónico esta expuesto.
Tal como lo conocemos, el voto es secreto, universal y obligatorio, esto NO se respeta con el eVoto.
No existe sistema o implementación que garantice esto, que sea simple y fácil de usar (que permita la universalidad tanto en la emisión como en la auditoría) y que a la vez permita garantizar el secreto del voto.

Cuando hablamos de universalidad, nos referimos a que tanto la emisión del voto debe ser posible para cualquier ciudadano, como la posibilidad de auditarlo, lo cual un derecho constitucional de los ciudadanos, cualquiera , sea una ama de casa o un profesional de renombre, cualquiera teniendo la mínima educación tiene el poder auditar una elección, comprenderla, saber cómo funciona y ejercer su derecho de reunirnos alrededor de la urna a elegir a nuestros representantes.
El voto electrónico nos priva de esta capacidad, que quedaría en manos de un muy, muy reducido número de expertos que no conocemos y en los que no podemos delegar un derecho tan esencial e importante

Otro argumento que se usa, es que el sistema de eVoto es mas sencillo. Conociendo nuestro sistema eleccionario sabemos que seria realmente complicado, ni que hablar de cuando vamos a un cajero automático y tenemos que realizar fila cuando hay una persona que no se entiende con el mismo para realizar una operación, me imagino lo que seria para realizar una elección con nuestro sistema de elecciónes.
Estar en contra del eVoto no es estar en contra de las nuevas tecnologías. Es una cuestión de Libertad, de poder decidir, de respeto por nuestra preciada y frágil democracia.

Fuentes:

http://www.vialibre.org.ar/wp-content/uploads/2009/03/evoto.pdf

http://www.vialibre.org.ar/category/activismo/voto-electronico/

http://ipsnoticias.net/