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

Construyendo el sistema inmunológico digital de tu organización

cristian Deja un comentario

En un mundo donde las brechas de seguridad son noticia casi todos los días y los ataques son cada vez más sofisticados y coordinados, depender de soluciones aisladas o estrategias meramente reactivas es como intentar salvar al Titanic con un pequeño balde.

A nivel global, se estima según firmas de cybersecurity ventures que el impacto del cibercrimen crecerá de 9,22 billones USD en 2024 a 13,82 billones en 2028. ^{1,2,3}

Pero no hace falta mirar tan lejos: en Uruguay, los incidentes de ciberseguridad crecieron un 65% en 2024, y en el primer semestre de 2025 se registraron 17.015 casos. ^{4,5,6} Hubo filtraciones masivas en organismos públicos y privados, con grupos locales e internacionales que actúan cada vez con más recursos.

Pero lo más alarmante es la falta de preparación: más de 150 mil organizaciones nunca evaluaron su nivel de seguridad, y el 85% no tiene políticas documentadas. ^7 Mientras tanto en 2024, los intentos de fraude afectaron a casi un millón de usuarios. La ciberseguridad moderna ya no se trata de apagar incendios, sino de tener un sistema integrado donde cada parte cumpla su rol como en una orquesta bien afinada.

Los escudos que separaron a las empresas hackeadas de las que no.

Contenido del artículo

La experiencia muestra que una estrategia meramente reactiva (SOC, etc) no es suficiente en el mundo actual. Usualmente cuando cuando un incidente es identificado el daño y el impacto al negocio ya está hecho. Por este motivo se deben abordar estrategias que permitan un monitoreo más proactivo de los riesgos a los que se exponen las organizaciones. De esta forma establecer un enfoque que reduzca estos en los ambientes de producción, tanto a nivel de infraestructura (patch management) como de las aplicaciones que se ejecutan en dichos ambientes.


Esto nos lleva al concepto de Postura de Seguridad (Security Posture) de una organización, donde se unifican los distintos indicadores de riesgo con el objetivo de tener una visión holística del riesgo organizacional. Así se construye un ciclo de mejora continua, donde los riesgos se evalúan en base al impacto real en el negocio, la probabilidad de explotación y la criticidad de los activos. Ya no se trata de recibir miles de alertas sin contexto: se trata de tener información útil para actuar rápido y con foco.

Para la construcción de los indicadores asociados a la Postura de Seguridad, suele implementarse un esquema de Cybersecurity Exposure Management (CEM) que esta basado en tres pilares fundamentales y que deben trabajar de forma coordinada son: Company Security Posture, Application Security Posture e Infrastructure Security Posture. Cada uno cumple un rol distinto, pero su verdadero poder aparece cuando todos funcionan en coordinación, alimentando al CEM con información crítica.

Company security posture: el director de orquesta

La postura de seguridad corporativa traduce métricas técnicas en información comprensible para la alta dirección, de modo que las decisiones sobre inversiones en seguridad no dependan del conocimiento técnico de los directivos, sino de tener buena información.

Este componente consolida la información de todas tus herramientas y actividades para lograr una visión única del estado de la seguridad de la organización. Son tus dashboards, tu consola de comandos desde la que podemos ver la situación de seguridad y disparar acciones automatizadas o manuales.

Application security posture

Las aplicaciones son el corazón de cualquier organización moderna. Desde el sistema de sueldos hasta la app que usan tus clientes, todo pasa por software.

El Application Security Posture Management (ASPM) se encarga de mantener esas aplicaciones seguras a lo largo de todo su ciclo de vida. Monitorea vulnerabilidades en el código, las APIs, las dependencias y las configuraciones.

Si lo de Log4Shell en 2021 nos pareció grave, 2024 nos dio una lección más dura: el backdoor identificado en la librería XZ^{15} que afecto a miles de aplicaciones que la incluían como parte de su código, incluso aplicaciones de seguridad (ej: ssh) fueron afectadas por este problema. Una sola vulnerabilidad en la cadena de suministro puede tener consecuencias enormes. ASPM existe justamente para prevenir estos escenarios y/o acelerar su resolución.

Infrastructure security posture

Si las aplicaciones son el corazón, la infraestructura es el esqueleto que sostiene todo. La mayor parte de la vida de una aplicación transcurre en un ambiente productivo ofreciendo los servicios para la que fue creada, y la seguridad de la organización queda definida por la íntima interacción entre la infraestructura y las aplicaciones. Por eso, verlos como elementos independientes o inconexos no es el mejor enfoque.

Gestionar la seguridad de servidores, redes y software de base, tanto en la nube como on-premise, en conjunto con las vulnerabilidades de las aplicaciones nos permite una mejor gestión de los riesgos, reduciendo la probabilidad de incidentes de seguridad.

En la era del «todo en la nube», donde una empresa puede tener recursos distribuidos entre AWS, Azure, Google Cloud y su propio datacenter, mantener una infraestructura bien protegida es indispensable.

El caso Snowflake lo deja claro: el grupo UNC5537 accedió usando credenciales robadas que llevaban años circulando en la dark web. Sin autenticación multifactor, lograron comprometer millones de registros. Todo por una brecha básica que podría haberse evitado.

Cybersecurity exposure management: la visión consolidada

A partir de los resultados de los elementos antes mencionados, se integra toda esa información en el Cybersecurity Exposure Management (CEM) lo que habilita una gestión integral de nuestra Postura de Seguridad. El CEM es el motor que nos permite identificar, evaluar y priorizar riesgos en toda la organización.

Opera en cinco pasos claves: alcance, descubrimiento, priorización, validación y movilización. Escanea y evalúa riesgos continuamente, pero lo verdaderamente importante es que prioriza en función del contexto del negocio, no solo de la gravedad técnica. Una vulnerabilidad crítica en un sistema de desarrollo interno no pesa igual que una en la plataforma que procesa miles de transacciones por hora.


Los beneficios, de apagar incendios a prevenirlos

Contenido del artículo

La diferencia entre una empresa que sufre brechas constantemente y una que mantiene su seguridad bajo control no es el presupuesto: es el enfoque. Este ecosistema integrado transforma la seguridad de reactiva a proactiva, y los beneficios son inmediatos y medibles.

Anticiparse en lugar de remediar

Imaginate este escenario: tu equipo de desarrollo lanza una nueva funcionalidad al e-commerce un viernes por la tarde. El lunes descubres que la actualización incluía una librería con una vulnerabilidad crítica que ya está siendo explotada en la web. Ahora tenés que hacer rollback en producción, con clientes comprando en tiempo real, perdiendo ventas y credibilidad.

Con un ecosistema integrado, esto no sucede. El Application Security Posture Management escanea automáticamente las dependencias antes del despliegue. Si detecta algo sospechoso, bloquea el paso a producción y alerta al equipo: Crisis evitada antes de que ocurra.

Ejemplo práctico: El caso de Equifax en 2017 ilustra perfectamente por qué el enfoque proactivo salva empresas. La brecha expuso información de 147 millones de personas debido a una vulnerabilidad conocida en un componente open-source (Apache Struts) que no fue parcheada a tiempo. El resultado: la compañía perdió $4 mil millones en valor de mercado y gastó más de $1.4 mil millones en costos post-brecha. Una estrategia ASPM efectiva habría identificado automáticamente esa dependencia vulnerable en producción y priorizado su remediación antes de que los atacantes la explotaran. $ 1.4 mil millones es la diferencia entre ser proactivo o reactivo.

Priorización inteligente basada en la realidad operativa

No todas las vulnerabilidades son iguales, aunque tengan el mismo puntaje CVSS. Una vulnerabilidad crítica en tu sistema de desarrollo interno no tiene el mismo impacto que la misma vulnerabilidad en tu plataforma de pagos que procesa 10,000 transacciones diarias y esta expuesta a internet.

El problema tradicional: tu escáner te arroja 2,347 vulnerabilidades. ¿Por dónde empezar? La mayoría de las empresas se ahogan en alertas y terminan ignorándolas todas o priorizando mal.

El enfoque integrado hace algo diferente, cruza datos técnicos con contexto empresarial real. Evalúa:

  • ¿Está este sistema expuesto a internet o es interno?
  • ¿Procesa datos sensibles de clientes o información pública?
  • ¿Qué impacto tendría en el negocio si se compromete?
  • ¿Existen exploits activos circulando?
  • ¿Qué tan crítico es para nuestras operaciones diarias?

Un ejemplo, Caso de Kenna.VM/Cisco: Una empresa Fortune 500 del sector healthcare enfrentaba desafíos de gestión de vulnerabilidades: «demasiadas vulnerabilidades sin forma efectiva de priorizarlas» y «alto volumen de datos de seguridad sin contexto para toma de decisiones». Después de implementar Kenna.VM (ahora Cisco Vulnerability Management), la empresa pudo priorizar vulnerabilidades basándose en riesgo real, permitiendo a sus equipos de remediación enfocarse en lo que verdaderamente importaba. ^8

Minimizar riesgos sin pisar el freno

El miedo de muchas organizaciones es este: «más seguridad = menos velocidad». Pero está ampliamente demostrado que es todo lo contrario: seguridad integrada significa despliegues más seguros y más rápidos.

Cómo funciona en la práctica:

  1. Pre-producción: Antes de que el código llegue a producción, ya pasó por múltiples validaciones automáticas. No es un cuello de botella: son verificaciones en segundos que se ejecutan en paralelo al proceso de CI/CD.
  2. Visibilidad continua en producción: Una vez desplegado, el monitoreo continuo detecta cambios de configuración riesgosos o nuevos vectores de ataque que emergen. Si aparece una nueva vulnerabilidad en una librería que usas, lo sabes inmediatamente y recibes un plan de remediación priorizado.
  3. Respuesta coordinada: Cuando se detecta algo crítico, no hay reuniones interminables para decidir qué hacer. Los playbooks automatizados ya están definidos: el sistema aísla el componente afectado, notifica a los equipos relevantes con información contextual y sugiere el fix específico.

Por ejemplo, según Radixweb, una empresa que adoptó DevSecOps pasó de ~4 despliegues al mes a ~10+ al mes y redujo los incidentes de seguridad en producción en ~82 %. ^9 Otros estudios muestran que organizaciones con pipelines automatizados logran ~12 despliegues por semana y tasas de fallos de cambio ~5 %. ^{10}

Equipos enfocados en lo importante

Quizás el beneficio más subestimado es liberar a tu equipo de seguridad del infierno de las tareas manuales repetitivas. En lugar de revisar manualmente miles de alertas falsas, pueden enfocarse en:

  • Modelar amenazas específicas para tu industria
  • Diseñar arquitecturas seguras para nuevos proyectos
  • Educar a equipos de desarrollo en prácticas seguras
  • Planificar estratégicamente cómo defender contra amenazas emergentes

Un ejemplo práctico: Antes de implementar un ecosistema de seguridad integrado, el equipo dedicaba gran parte de su tiempo —casi dos tercios de la jornada— a tareas manuales de triado de alertas, validación de falsos positivos y coordinación entre herramientas aisladas.

Con la automatización y la consolidación de fuentes de datos en una sola plataforma, el volumen de trabajo repetitivo se redujo drásticamente. Hoy, apenas un 15 % del tiempo del equipo se destina al triado inicial; el resto se aprovecha en actividades de mayor valor: entrenar a desarrolladores, mejorar la documentación de seguridad, ejecutar pruebas proactivas y diseñar estrategias defensivas más efectivas.

El resultado es doble: una postura de seguridad más madura y resiliente, y un equipo menos saturado y más motivado, que trabaja con foco en la prevención en lugar de apagar incendios. Diversos estudios y casos de implementación respaldan este tipo de mejora. Por ejemplo, Shield53 reportó una reducción del tiempo de triado de alertas a menos de 4 horas por turno tras automatizar procesos (Dropzone AI, 2024). ThreatQuotient documentó un 93 % de ganancia en eficiencia en la gestión de alertas, gracias a la automatización y el contexto compartido (ThreatQuotient ROI Whitepaper, 2023). A nivel académico, investigaciones como “Improved Detection and Response via Optimized Alerts” (Capitol Technology University, MDPI 2022) destacan que los analistas de seguridad invierten entre 40 % y 60 % de su tiempo en tareas de triado manual, lo que evidencia el impacto de la automatización para liberar capacidad y mejorar la moral del equipo.

ROI medible

  • Las organizaciones que integran automatización de seguridad en sus pipelines y operaciones (detección → análisis → contención → prevención) reportan mejoras medibles: reducción del tiempo de respuesta a incidentes (algunos estudios indican reducciones de hasta ~90 % en MTTR). ^{11}
  • También se observa una disminución de ruido y falsos positivos — por ejemplo, una entidad financiera redujo su volumen de alertas un ~85 % tras adoptar IA-alertas. ^{12} En términos de costo evitado, el promedio global de una brecha ronda los USD 4.88 millones. ^{13}
  • Y en cuanto a eficiencia operativa, las guías de automatización indican mejoras del “500 % en capacidad de procesamiento de eventos” y “reducciones de 40-60 % en personal de seguridad” como resultado de la automatización y orquestación. ^{14}

Por tanto: integrar los silos de seguridad y automatizar no es solo una cuestión de organización elegante — es un imperativo para defender organizaciones modernas que operan a la velocidad del negocio digital.

En resumen

Contenido del artículo

Hoy, la pregunta ya no es si te van a atacar, sino cuándo. Por eso, adoptar un ecosistema de seguridad integrado no es un lujo, es construir el sistema inmunológico digital de tu organización. Para esto no podemos únicamente reaccionar después de haber sido atacados, si no que vamos a prevenir que esto ocurra, y el camino mas adecuado implica reducir las vulnerabilidades y riesgos de los sistemas sensibles para evitar que los atacantes encuentren fisuras por donde comprometer nuestra organización. Porque en 2026 y los próximos años, proteger los datos y la reputación de tu empresa no es una opción, es una necesidad.

Publicado en https://www.linkedin.com/pulse/construyendo-el-sistema-inmunol%C3%B3gico-digital-de-tu-organizaci%C3%B3n-tapaf/?trackingId=k0I9tiBsRYOuo%2BTdP1%2B0uQ%3D%3D

El eterno retorno de los pozos salteños

cristian Deja un comentario

Una crónica sobre el arte de tapar huecos que se destapan solos

En Salto, hay tradiciones que trascienden el mate en las termas en verano, el asado en la costa y las discusiones futboleras. Una de ellas, quizás la más democrática y persistente, es la reaparición puntual de los pozos en nuestras calles cada vez que se larga la primera lluvia de consideración. No importa el color político de turno ni las promesas de campaña: los baches salteños son una constante que desafía gobiernos, presupuestos y hasta las leyes de la física.

Lo curioso del asunto no es que tengamos calles en mal estado —eso, lamentablemente, es moneda corriente en buena parte del país— sino la admirable regularidad con que las reparaciones realizadas por la Intendencia desaparecen apenas el cielo se pone generoso. Uno podría pensar que el material utilizado para tapar los pozos tiene alguna propiedad especial, una suerte de alergia al agua de lluvia que lo hace evaporarse o, en el mejor de los casos, disolverse como azúcar en el mate.

El ciclo es tan predecible que ya forma parte del paisaje urbano: aparece un pozo, los vecinos reclaman, llega la cuadrilla municipal con pala y asfalto en mano, se tapa el hueco con solemnidad de quien construye para la posteridad y, a los pocos días o semanas —según la suerte climática— el bache reaparece, generalmente más grande y profundo que su versión original. Es el eterno retorno de Nietzsche aplicado al mantenimiento vial.

Un problema sin color partidario

Lo más llamativo del fenómeno es su imparcialidad política. Administraciones de todos los signos han protagonizado este mismo ritual: unos tapan, llueve, se destapa, otros tapan, llueve, se destapa. Es una danza que se repite con la precisión de un reloj suizo, solo que en lugar de marcar las horas, marca la ineficiencia acumulada década tras década.

Hay quienes, con cierta nostalgia, recuerdan épocas en que las calles salteñas eran el orgullo de la región. Aquellos tiempos en que el asfalto se colocaba pensando en que duraría, en que la obra pública era sinónimo de calidad y no de parche urgente. Pero eso, para muchos salteños menores de cuarenta, suena más a leyenda urbana que a realidad vivida.

La economía del despilfarro

Acá es donde la ironía se vuelve amarga como mate sin azúcar. Porque mientras las autoridades se quejan —con razón— de presupuestos ajustados y recursos escasos, persisten en aplicar una metodología de reparación que garantiza el desperdicio: tapar mal para tener que volver a tapar pronto. Es como pretender calmar el hambre comiendo pochoclo: por un rato calma, pero al final te queda más hambre que antes.

Los números, aunque nadie se anima a mostrarlos públicamente, deben ser elocuentes. ¿Cuánto se gasta anualmente en tapar los mismos pozos una y otra vez? ¿Cuántas cuadrillas se movilizan para reparar lo que hace seis meses ya habían «reparado»? ¿Cuánto combustible, cuántas horas de trabajo, cuánto material se tiran a la basura cada vez que una lluvia borra el trabajo de semanas?

La pregunta que cualquier vecino con dos dedos de frente se hace es simple: ¿no sería más barato, más eficiente y más digno hacer las cosas bien de entrada? Invertir en un bacheo de calidad, con materiales apropiados, con técnica adecuada, con control de obra que no sea una formalidad burocrática. Reparar la base del asfalto cuando corresponde, en lugar de esperar a que el deterioro sea tan grave que requiera obra mayor.

El costo oculto de la mediocridad

Pero hay algo más en juego que el simple desperdicio de recursos públicos. Está el desgaste de los vehículos —amortiguadores, cubiertas, alineación— que los salteños asumen como un impuesto no escrito por vivir acá. Está el riesgo de accidentes, especialmente para motos y bicicletas que encuentran en cada pozo una trampa potencial. Está la imagen de una ciudad que no se cuida, que no se respeta, que parece haber naturalizado la mediocridad como estándar aceptable.

Y está, también, el mensaje implícito que se envía: que acá las cosas se hacen así, mal y rápido, porque para qué esforzarse en hacer algo duradero. Que el «mientras aguante» es filosofía de gestión. Que el vecino que reclama está pidiendo demasiado si espera que un arreglo dure más que una tormenta.

¿Será tan difícil?

Uno se pregunta si realmente es tan complejo hacer un bacheo que resista. Otras ciudades del país lo logran. Pueblos más chicos que Salto tienen calles en mejor estado. ¿Será cuestión de presupuesto? ¿De capacitación técnica? ¿De voluntad política? Probablemente sea un poco de todo, pero sobre todo parece ser cuestión de no darse cuenta —o no querer darse cuenta— de que la «solución» aplicada hace décadas es, en realidad, el problema.

Hay algo profundamente frustrante en ver cómo, año tras año, gobierno tras gobierno, se repite la misma película. Como si no hubiera memoria institucional, como si cada nueva administración estuviera condenada a cometer los mismos errores, a gastar mal los mismos recursos, a decepcionar a los mismos vecinos.

Una propuesta modesta

Quizás sea hora de que alguien en la Intendencia se tome un cafecito y haga las cuentas. Que compare lo que se gasta tapando mal los mismos pozos cinco veces contra lo que costaría taparlos bien una sola vez. Que consulte con quienes saben de pavimentación cómo se hace un trabajo que dure. Que visite otras ciudades para ver qué están haciendo diferente.

No hace falta inventar la pólvora. La tecnología existe, los materiales están disponibles, las técnicas están probadas. Lo que falta es decisión. Decisión de romper con el círculo vicioso del parche y el pozo, del tapar y destapar, del gastar mal para tener que volver a gastar.

Los salteños no pedimos calles de Fórmula 1. Pedimos calles normales, transitables, que no se conviertan en campo minado cada vez que llueve. Pedimos que los impuestos que pagamos se inviertan con un mínimo de criterio y previsión. Pedimos, en definitiva, que las autoridades se tomen el trabajo en serio.

Mientras tanto, seguiremos esquivando pozos, llevando el auto al mecánico, y preguntándonos cuándo, algún día, alguien en el gobierno municipal tendrá esa revelación tan simple como necesaria: que hacer las cosas bien, desde el principio, no es un lujo, es sentido común.

Publicado en https://elpueblodigital.uy/el-eterno-retorno-de-los-pozos-saltenos/

Bloquear anuncios en todos tus dispositivos

cristian Deja un comentario

En el vasto mundo digital de hoy, los anuncios no solo son molestos, sino que también pueden ralentizar tu navegación y comprometer tu privacidad. Afortunadamente, AdGuard DNS ofrece una solución elegante y efectiva para bloquear anuncios en todos tus dispositivos, incluido iOS. Aquí te mostraré cómo hacerlo, paso a paso.

¿Qué es AdGuard DNS?

AdGuard DNS es un servidor DNS público que filtra el tráfico de Internet eliminando anuncios, rastreadores, y amenazas de phishing. Funciona en el nivel de DNS, redirigiendo las solicitudes de dominios conocidos por alojar anuncios o rastreadores a una «dirección nula», lo que efectivamente bloquea el contenido no deseado antes de que llegue a tu dispositivo.

Configuración en dispositivos en general

Para configurar AdGuard DNS en la mayoría de los dispositivos:

  1. Accede a la configuración de tu red Wi-Fi.
  2. Busca la sección de configuración de DNS.
  3. Selecciona la opción para configurar manualmente los servidores DNS.
  4. Ingresa las direcciones DNS de AdGuard: Puedes elegir entre el modo predeterminado para bloqueo de anuncios o el modo «Familia» para bloqueo de anuncios y contenido para adultos. Las direcciones están disponibles en la página oficial de AdGuard DNS.

Configuración específica para iOS

iOS permite una integración más profunda mediante la creación y carga de un perfil de configuración. Esto es particularmente útil, ya que no necesitarás configurar DNS para cada red Wi-Fi individualmente. Sigue estos pasos para crear y cargar tu perfil de AdGuard DNS en iOS:

  1. Visita el generador de perfiles de AdGuard DNS desde tu dispositivo iOS.
  2. Elige tus preferencias de filtrado y crea el perfil. Selecciona entre las opciones predeterminadas o familiares, según tus necesidades.
  3. Descarga el perfil de configuración que se genera automáticamente.
  4. Abre el perfil descargado en tu dispositivo iOS. Se te guiará a través del proceso de instalación; simplemente sigue las instrucciones en pantalla.
  5. Una vez instalado, el perfil configurará automáticamente los servidores DNS de AdGuard en tu dispositivo, aplicando el filtrado de contenido a todas las conexiones.

Ventajas de AdGuard DNS

  • Bloqueo de anuncios y rastreadores en todos los dispositivos sin la necesidad de instalar software adicional.
  • Mejora de la velocidad de navegación al reducir la cantidad de contenido cargado.
  • Incremento de la privacidad al evitar que los rastreadores recolecten tus datos.
  • Protección contra sitios de phishing y contenido para adultos (con el modo «Familia»).

Conclusión

Con AdGuard DNS, tienes una herramienta poderosa y fácil de usar para mejorar tu experiencia en línea en todos tus dispositivos, incluido iOS. La configuración es sencilla y te ofrece un control considerable sobre el contenido que llega a tu dispositivo. Prueba hoy mismo AdGuard DNS y disfruta de una web más limpia, rápida y segura.

Las desprolijidades de mi mutualista

cristian Deja un comentario

con la seguridad de la información.

Si, así como lo leen, en muchos sentidos mi mutualista es muy desprolija, como casi todas las de Uruguay, mejores peores, por mil cosas.

Pero no voy a hablar de la prestaciones que me da, de las cuales no me puedo quejar, sino de la proteccion de datos y la seguridad de información.

Hace mas de un año, luego de que presentaran una app de celular la instalo y como buen curioso la examino, ahi encuentro que no solo pasaba los datos en plano, sino que lo hacia hacia un windows server en EEUU.

TLS para que!

Un nmap después veo que tienen abierto al mundo no solo el puerto del MS SQLserver abierto sino un ftp… con las claves por defecto y dentro… la app con los fuentes y los hashes de las DB ahi nomas..

Me quedo mas tranquilos, sin virus…

Bueno, esto se notifico por mail a ellos y al cert.uy.

Lo arreglaron y no seguí, no me corresponde hacerlo ni tenia permisos, pero me puse a las ordenes, me dieron las gracias y nunca mas.

Poco tiempo salió un llamado para el puesto de seguridad de la información, pero como no tengo titulo profesional habilitante no me podia presentar, alguien seguramente se presento, agarro ese trabajo y esperaba que pudieran mejorar la seguridad de en definitiva, mis datos. Parece que no.

En diciembre de 2019 me pongo a mirar unos resultados de análisis clínicos personales (la edad pesa) y me encuentro que los resultados están en una carpeta temporal en la web (a la que le pusieron https!) con un nombre de archivo numérico secuencial, cambiando los números del nombre del archivo pdf puedo acceder a los resultados de cualquier otra persona…. de nuevo, notifico telefónicamente a la institución y por mail al cert.uy estos me informan luego que también se pusieron en contacto con la institución.

Este caso es el resultado de analisis de VIH de un paciente, el nombre y el num soc estaban ahi publicos…

Esto no es contra nadie, sino que se visibilize la importancia de la seguridad en la información. No solo que nadie tiene por qué saber mis temas medicos, sino que alguien maliciosamente puede llegar a tener datos suficientes para otro tipos de delitos.

En este tipo de cosas siempre se criminaliza al que encuentra e informa de estos problemas, pero raramente se hace responsable a quienes en en la omisión no velan por la seguridad de nuestra información, en estos casos se notifico a la institución y solucionaron los problemas, no me corresponde realizar un seguimiento del estado, pero de encontrar cosas así como siempre reportar al cert.uy y a la institución/empresa.

La institución he invertido y esta realizando cosas muy destacables y pioneras a nivel nacional en informática medica, pero este tipo de errores son muy básicas como para dejarlos pasar por alto.

El próximo DDoS que sufra seguramente sea gracias al IoT

cristian Deja un comentario

IoT («Internet of Things» o «Internet de las Cosas») esa sigla que estamos viendo mucho en las noticias de tecnologia y que nos venden como el maravilloso mundo donde todo está conectado y controlado desde el smartphone. Como todo mundo de ensueño, la moda que nos venden es una cosa fabulosa, poder controlar las luces, el aire, el horno, el calefón, la comida de las mascotas, la muñeca ( y los juguetes sexuales) el CCTV, las alarma casi todo desde el smartphone o desde una web es algo realmente tentador.

Qué puede salir mal ?

Y la verdad que la idea esta buenisima, pero como todo en el mundo de la tecnología esto ha avanzado a pasos agigantados dando lugar a que cada vez se desplieguen más este tipo de productos conectados con software cada vez más vulnerable (siendo que esto no es nuevo, sistemas SCADA!!! vulnerable desde…). Esta cantidad de potencia de cómputo y red, sumado al software vulnerable e inseguro son un campo de cultivo para su uso en ataques DDoS  (o minería de Bitcoin) como ya ocurrió hace un tiempo atrás en el ataque a dyn.com desde DVR CCTV ( Botnet MIRAI) infectados, ahora se imagina en un futuro tratando de explicar a un Cliente (o Jefe) que fuimos víctimas de un ataque, provocado por una botnet de Dildos conectados ?

Contamos con el excelente trabajo de OWASP pero siempre dependemos de los fabricantes y su buena voluntad de mantener actualizados sus dispositivos.

Sin lugar a dudas, para los que nos gusta la tecnologia y entendemos un poquito, este momento de querer conectar todo nos divierte y nos preocupa.

http://wwwhatsnew.com/2017/02/17/alemania-pide-a-los-padres-que-destruyan-una-muneca-que-puede-ser-hackeada/

http://www.forbes.com/sites/leemathews/2017/02/13/infected-vending-machines-and-light-bulbs-ddos-a-university

https://www.xataka.com/otros/el-siguiente-gran-mercado-de-la-tecnologia-es-el-de-los-juguetes-sexuales-aunque-casi-nadie-este-hablando-de-ello

https://www.presidencia.gub.uy/comunicacion/comunicacionnoticias/ute-aniversario-104

http://www.petnet.io/

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project