Blog Tecnológico

Blog everyWAN

Tecnología, ciberseguridad y tendencias IT que importan

Análisis Profundo
Ciberseguridad
Tendencias IT
Filtrar por:
Bahías de disco de un servidor con bandejas medio extraídas y huecos vacíos
8 min lectura

Tu redundancia supone que el repuesto llega mañana

Un disco se muere un martes y no pasa nada: para eso pagaste la réplica. Pero lo que compraste no es inmunidad, es una ventana de tiempo para reponer antes del siguiente fallo, y esa ventana se calculó dando por hecho que el repuesto llega mañana. Western Digital dijo en su llamada de resultados que estaba «prácticamente vendido para el año natural 2026» y Seagate que su capacidad nearline estaba «completamente asignada» para el mismo periodo, con acuerdos de nube que ya alcanzan 2027 y 2028. Hacemos la aritmética con las tasas de fallo publicadas por Backblaze: con el repuesto en 48 horas, la probabilidad de un segundo fallo antes de la reparación es del 0,18 %; con el repuesto en 20 semanas, del 11,5 %. El mismo diseño, los mismos discos, 66 veces más riesgo por una variable que no sale en ningún diagrama. Dónde duele más (el nodo, no el disco), el recorte de retención que no firma nadie, y las seis preguntas que hacemos ahora antes de dar por bueno un diseño.

Pasillo entre armarios de servidores en penumbra, con centenares de indicadores luminosos encendidos a la vez
7 min lectura

Tormenta de reintentos: la segunda caída la provocas tú

El 12 de junio de 2025 Google Cloud se cayó a lo grande. A los 40 minutos la mitigación estaba desplegada y las regiones empezaron a recuperarse, las pequeñas primero; us-central1 no quedó resuelta del todo hasta 2 h 40 min después de empezar el incidente. Lo que alargó esa región no fue el bug: fueron los reintentos. El informe público lo dice con todas las letras —«Service Control no tenía implementado el backoff exponencial aleatorizado apropiado para evitar esto»— y describe un efecto manada sobre la tabla de Spanner de la que dependía todo. Aquí contamos dónde vive ese mismo mecanismo en una empresa normal (el cron que tarda más que su intervalo, el backup que se solapa, los sesenta equipos que arrancan a la vez cuando vuelve la luz, la monitorización que aprieta justo cuando duele), por qué tres reintentos en tres capas son 64 intentos contra tu base de datos, los cuatro números que hay que tener escritos y cuándo NO tocar nada.

Sala de reuniones vacía con mesa larga, sillas y una pizarra de cristal borrada al fondo
5 min lectura

Los chats de Teams no están en tu copia de seguridad

Microsoft 365 Backup protege tres cargas de trabajo: OneDrive, SharePoint y Exchange Online. El chat de Teams no es ninguna de las tres. Y en la página de limitaciones de una de las herramientas de terceros más extendidas, los chats individuales y de grupo aparecen en la lista de lo que no se respalda. Dónde vive de verdad un mensaje de Teams según la documentación de Microsoft, por qué una política de retención conserva pero no restaura, los 21 días que tarda un mensaje borrado en entrar en la carpeta SubstrateHolds y las seis preguntas que le hacemos a la copia de Microsoft 365 de una empresa antes de tocar nada.

Vista aérea de un corredor de centros de datos: naves industriales bajas y anchas repartidas a lo largo de una autopista
13 min lectura

Tu nube aguanta perder una zona. AWS acaba de perder una región

El 15 de septiembre AWS escribió en su panel de estado que no puede restaurar los recursos y datos alojados «exclusivamente» en la región de Baréin ni en la zona mec1-az2 de Emiratos. Esa palabra separa a quien perdió datos de quien no. El perímetro de esa redundancia estaba publicado desde el principio: S3 está diseñado para aguantar la pérdida de UNA zona, y las zonas están a menos de 100 km unas de otras. Lo que dice la documentación, lo que dice el contrato y las cuatro preguntas que escribimos en una hoja antes de tocar nada.

Nave de un centro de distribución: estanterías metálicas con palés embalados y pasillo de preparación de pedidos
8 min lectura

Desconectarte lleva 101 minutos; reconectarte, nueve días

Boston Scientific hizo público su incidente un miércoles. Ese mismo día, 101 minutos después del primer aviso, la plataforma por la que sus clientes le pasan los pedidos le cortó todas las conexiones globales. Tardó nueve días en devolvérselas. La cronología completa está en una página de estado pública y enseña tres cosas que no están en casi ningún plan de continuidad: quién decide desconectarte, con qué canal degradado aguantas mientras, y por qué tu sistema de estado deja de decir la verdad.

Sala llena de puestos de trabajo vacíos con los monitores apagados
9 min lectura

El fallo de RDS figura como «mitigado». La mitigación es apagar y encender la máquina

El 11 de septiembre Microsoft abrió una incidencia por los Servicios de Escritorio remoto que dejan de responder tras la actualización de septiembre. Ocho horas después la marcó como «Mitigated». Fuimos a leer la mitigación: parar la máquina virtual y volver a arrancarla. La lista de plataformas afectadas de esa misma ficha tampoco son los tres Windows Server de los titulares, son seis. Y el paquete que quieres desinstalar es el que tapa un 9,8 sin autenticar en el mismo servicio.

Reloj de pared de esfera oscura en una pared gris de oficina
8 min lectura

Cyber Resilience Act: 24 horas para avisar, y el reloj no arranca con el CVE

Hoy empieza a aplicarse el artículo 14 del Cyber Resilience Act: 24 horas para el primer aviso de una vulnerabilidad explotada. Dos detalles que casi nadie está contando: es el único artículo que el reglamento estira hacia atrás, hasta lo que ya vendiste, y el plazo no cuenta desde que se publica el CVE, sino desde que tú «tienes conocimiento». Eso convierte una obligación legal en un problema de instrumentación: de telemetría, de buzón vigilado y de quién declara la hora.

Pasillo estrecho de un centro de datos, con un rack abierto de paneles de parcheo de fibra en primer plano y latiguillos aguamarina y amarillos recogidos en las guías de cable
10 min lectura

La redundancia no sobrevive al procedimiento

El 1 de septiembre, una actualización de capacidad programada desconectó de forma secuencial el 100% de los caminos de fibra de una parte de la zona us-central1-b de Google Cloud, en trece minutos. El informe describe justo antes una arquitectura correcta: caminos físicamente separados, alimentación diversa, tolerancia a fallos dobles y triples. Un estudio de Berkeley de 2003 ya explicaba por qué no sirvió: el error de operador no es más frecuente que el de hardware, es que se enmascara peor.

Plan de continuidad sin ensayar: un servidor sacado a medias del rack con los cables de alimentación desenchufados
9 min lectura

El plan de continuidad que nadie ha ensayado es un documento, no un plan

El informe anual de caídas de Uptime Institute de mayo de 2026 dice que la primera causa de las caídas con error humano detrás sigue siendo no seguir procedimientos ya establecidos. Establecidos: el documento existía. Y el 87% de quienes sufrieron una caída con impacto cree que se podía evitar con mejor gestión, procesos o configuración, siete puntos más que en 2024. Qué falta entonces, cómo es un simulacro que sirve, y cuándo NO deberías hacer uno.

Priority Cleanup de Microsoft Purview: borrar por encima de la retención en Microsoft 365
9 min lectura

Borrar por encima de la retención: tres firmas en Exchange, una en SharePoint

Priority Cleanup de Microsoft Purview borra contenido de Microsoft 365 saltándose políticas de retención, etiquetas y holds de eDiscovery, y la documentación dice que lo borrado no lo recupera ni el usuario, ni el administrador, ni Microsoft. En buzones exige siempre tres aprobaciones; en SharePoint y OneDrive, una, y ninguna del responsable de retención. Qué lo detiene, qué apagar antes y qué le pide esto a tu copia.

Mostrador de pedidos de un almacén con el monitor apagado apartado, una libreta con los pedidos apuntados a mano, albaranes en un pincho y un teléfono descolgado
5 min lectura

El backup estaba a salvo. Y llevaba 47 horas dentro de la misma caída

El parte oficial de un proveedor de hosting decía dos cosas el mismo día: «No existe riesgo de pérdida de datos» y «no es posible acceder a los backups ni realizar la migración de los servicios afectados hacia otro nodo». Las dos eran ciertas, y juntas describen el fallo de diseño que casi nadie tiene en su plan: un RPO perfecto con un RTO sin número. Reconstruimos el reloj con el status del proveedor delante y proponemos la cifra que falta en casi todos los planes: a qué hora dejas de esperar.

Cuadro eléctrico general abierto en un cuarto de instalaciones, con filas de magnetotérmicos colgando todos de un mismo interruptor principal
5 min lectura

Cayeron seis servicios de Microsoft 365 a la vez. Para tu plan de continuidad son uno solo

El lunes 31 de agosto el incidente EX1464935 sobre Exchange Online acabó en MO1465074, con OneDrive, SharePoint Online, Teams, Purview y Defender XDR dentro. Seis nombres, una configuración de autenticación compartida por debajo. Repasamos las horas —incluidas las que no cuadran entre BleepingComputer y Computerworld, y lo decimos en vez de elegir una—, por qué nadie ha confirmado lo del certificado caducado, y la dependencia que casi nadie va a mirar: la consola de seguridad y la capa de auditoría estaban dentro de lo que se había caído.

Rincón de oficina con una papelera metálica desbordada de papel y una destructora con el depósito lleno
9 min lectura

Elementos recuperables: 14 días, 30 GB y el día que el buzón deja de poder borrar

La carpeta que te salva cuando alguien vacía la papelera no sale en Outlook, guarda 14 días por defecto y le caben 30 GB. Si pones el buzón bajo retención, el techo sube a 100 GB y a cambio deja de vaciarse: solo entra. Y el día que toca el techo, según la documentación de Microsoft, el usuario no puede borrar, se dejan de guardar versiones y se dejan de escribir las entradas de auditoría. Cómo medir cuánto te queda con dos comandos, cómo abrir el desagüe que viene de fábrica sin conectar, y por qué una carpeta borrada con Mayús+Supr no vuelve ni con retención por juicio.

Servidores de rack idénticos apilados en un carro metálico, pendientes de montar, delante de un rack a medio poblar
5 min lectura

Corosync suma 650 milisegundos por cada nodo: el reloj que tu clúster actualizado sigue arrastrando

El tiempo que tarda un clúster Proxmox en rehacer la membresía tras perder un nodo no es fijo: crece 650 ms por cada nodo que añades, y con los valores de fábrica un clúster de 29 nodos llega a 45,21 segundos, justo donde la propia documentación pide corregirlo antes de que el watchdog de 60 segundos reinicie nodos sanos. Proxmox VE 9.2 lo bajó a 125 ms, pero solo al crear el clúster: los actualizados de la 8 a la 9 siguen con el valor viejo.

Armario de llaves metálico abierto en el pasillo de servicio de una oficina, con dos hileras de llaves colgadas de sus ganchos
7 min lectura

Borraron las copias en los dos centros de datos

El aviso conjunto AA26-222A, publicado el 10 de agosto de 2026 por seis agencias, cuenta que contra una de las víctimas de Gunra los actores borraron los datos de copia y de archivo en el centro de datos principal <em>y</em> en el de recuperación, antes y después de desplegar el cifrador. En otro apartado cuenta cómo se hicieron con el llavero: SSH a un servidor de control de accesos y una clave simétrica que descifraba las contraseñas de las cuentas de servidor de toda la empresa. Nuestra lectura: dos sedes que aceptan la misma credencial son una sola sede con dos direcciones postales. Qué queda fuera del bloqueo de retención y seis comprobaciones para esta semana, dos de ellas hay que ejecutarlas de verdad.

Portal de un edificio antiguo con una única puerta acristalada, el portero automático y los buzones metálicos
5 min lectura

Tu proveedor de identidad no es una aplicación: es infraestructura

El lunes 24 de agosto, a las 03:38, empezó un ataque de denegación de servicio contra la plataforma digital compartida del Estado noruego. Cayeron diez servicios públicos y varios no tenían nada roto: se había atascado la puerta por la que se entra a todos. Digdir escribe en su página de estado que <code>eSignering</code> estaba inaccesible «a causa de las limitaciones en ID-porten», y también que las soluciones estaban «estables con las limitaciones que se han puesto» — parte de la caída la pusieron los propios defensores. Por qué el inicio de sesión único sigue siendo la decisión correcta, qué cambia cuando la puerta pasa a ser infraestructura y las tres preguntas que la reclasifican.

Archivadores metálicos grises de oficina, con un cajón entreabierto y unos papeles asomando
9 min lectura

Ransom Busters: el que te ofrece rescatarte es el que te cifró

El 18 de agosto GuidePoint (GRIT) publicó que un supuesto tercero llamado «Ransom Busters» escribe a las víctimas de ransomware ofreciendo borrar sus datos por entre 20.000 y 60.000 dólares. Al preguntarle, confirmó tener acceso al mismo conjunto de datos robados que el afiliado responsable de la intrusión, y las mismas huellas forenses se repetían en los incidentes que analizó GuidePoint. Lo que de verdad cambia todo es la fecha: el correo llegaba antes de que el incidente fuera público. Qué hacer con él la primera mañana.

Cajón abierto de un fichero de tarjetas de archivo de madera en una sala de oficina, con las fichas de papel apretadas y vistas de canto
5 min lectura

Hay quien lleva desde el lunes sin poder buscar en Microsoft 365. Para el SLA, eso no es una caída

El incidente MO1456424 lleva abierto desde el lunes 17 de agosto: parte de los usuarios de Microsoft 365 no encuentran nada al buscar en SharePoint Online, OneDrive y Outlook. Los ficheros se abren, el correo entra y sale, y por eso el contador de disponibilidad no se mueve. Qué dice el parte de Microsoft palabra por palabra, por qué las definiciones de «caída» de su SLA dejan fuera exactamente esto, y qué comprobación hay que montar para enterarte tú antes que tus usuarios.

Estante metálico de una sala técnica con una fila de cartuchos de cinta en sus cajas y una unidad de cinta montada en rack
9 min lectura

La copia de Microsoft 365 que nunca sale de Microsoft

Microsoft 365 Backup restaura un sitio de SharePoint en menos de veinte minutos, cuesta 0,15 $ por GB protegido al mes y guarda un año de puntos de restauración. Su propia documentación dice también que los datos nunca cruzan la frontera de confianza de Microsoft 365, que el almacenamiento es de solo anexado y no inmutable, y que borrar las copias no está bloqueado. Qué escenario cubre eso, cuál no, y las dos dependencias nuevas que aparecen el día que lo activas.

Una tormenta de verano avanzando sobre el desierto, origen del fallo de refrigeración que apagó 5.000 servidores
5 min lectura

Tus servidores los puede apagar alguien con quien no has firmado nada

El 13 de agosto se apagaron más de 5.000 servidores en un edificio de Phoenix y con ellos cayeron webs, correo y DNS de miles de empresas. La decisión de apagar fue correcta; lo interesante es la cadena por la que bajó la orden, porque el cliente final está al final de ella y no tiene contrato con quien decide. Qué preguntar sobre el edificio donde vive tu hierro y por qué el DNS tumbó a gente que no estaba allí.

Suscríbete a nuestra newsletter

Para recibir historias del mundo IT, novedades de everyWAN y ofertas exclusivas para suscriptores, date de alta a nuestra lista de correo

everyWAN
everyWAN