¿Qué es la regla de respaldo 3-2-1 para SCADA?
Los equipos de SCADA pierden datos por discos fallados, archivos de proyecto corrompidos y ransomware, y un solo respaldo que vive en el mismo servidor rara vez sobrevive a cualquiera de ellos. La regla de respaldo 3-2-1 es una disciplina simple y memorable que corrige esto: mantenga tres copias de sus datos, en dos tipos distintos de medio, con al menos una copia guardada fuera de sitio. Aplicada a los archivos de proyecto del SCADA, las bases de datos del historiador y las imágenes completas de servidor, convierte un respaldo único frágil en una defensa por capas. Esta guía recorre cada número, por qué la copia fuera de sitio es la que lo salva durante un evento de ransomware, y cómo la regla se mapea a sus objetivos de tiempo y punto de recuperación.
Regla de respaldo 3-2-1 en una línea: La regla de respaldo 3-2-1 dice que debe mantener tres copias de sus datos importantes, almacenadas en dos tipos distintos de medio, con al menos una copia guardada fuera de sitio. Para SCADA, eso significa el sistema en vivo más dos respaldos de los archivos de proyecto, el historiador y las imágenes de servidor, con un respaldo guardado en una ubicación separada para que un incendio, una inundación o un ataque de ransomware en la sala de control no pueda destruir todas las copias a la vez.
Los tres números y contra qué protege cada uno
El primer número, tres copias, cuenta los datos de trabajo más dos respaldos. El sistema SCADA en vivo en el servidor es la copia uno. Un respaldo en un disco local o en un dispositivo de respaldo es la copia dos. Una tercera copia guardada en otra parte es la copia tres. La razón de tres en lugar de dos es directa: si el primario falla y usted echa mano de su único respaldo y resulta estar corrompido o incompleto, no le queda nada. Una tercera copia independiente significa que un solo respaldo malo no lo deja con las manos vacías.
El segundo número, dos tipos de medio, significa que las copias no deben vivir todas en la misma clase de almacenamiento. Si tanto sus datos en vivo como su respaldo están en discos giratorios del mismo rack, una falla de controladora, un pico de energía o un error de firmware puede tumbar ambos juntos. Repartir las copias entre medios distintos - disco local más un dispositivo de respaldo, o disco más almacenamiento de objetos en la nube, o disco más cinta - elimina ese modo de falla compartido. El punto es que ningún defecto de hardware o falla de medio único deba poder alcanzar cada copia que usted tiene.
El tercer número, una fuera de sitio, es la copia que sobrevive a un desastre a nivel de sitio. Un incendio en la sala de control, una inundación, un rayo o un robo pueden destruir cada dispositivo físicamente presente. Si una copia completa vive en otro edificio, otra instalación o una región de nube lejana, la pérdida del sitio no significa la pérdida de la configuración y la historia del SCADA. Esta copia fuera de sitio es lo que convierte un evento de pérdida total en una restauración molesta en lugar de un hueco permanente.
Aplicar la regla a archivos de proyecto, historiador e imágenes de servidor del SCADA
Para un entorno SCADA, los datos que vale la pena proteger caen en tres cubetas amplias, y la regla 3-2-1 aplica a cada una. La primera es los datos de ingeniería: los archivos de proyecto del SCADA, las pantallas de HMI, las bases de datos de tags, las configuraciones de alarmas y los programas de PLC o RTU. Estos son la receta para reconstruir el sistema, y cambian cada vez que un ingeniero compromete trabajo, así que deben capturarse en un horario lo bastante apretado como para que un día de esfuerzo de ingeniería nunca esté en riesgo. La segunda cubeta es la base de datos del historiador, que guarda la historia acumulada de proceso y medición de la que dependen los reguladores, la contabilidad de producción y el diagnóstico.
La tercera cubeta es las imágenes completas de servidor: capturas completas del sistema operativo, los controladores, el software SCADA instalado y la configuración del servidor SCADA, el servidor de historiador y las estaciones de ingeniería. Estas imágenes le dejan reconstruir una máquina entera en lugar de reinstalar todo a mano bajo presión. Cuando usted aplica 3-2-1, cada cubeta recibe sus tres copias repartidas entre dos medios con una fuera de sitio, aunque la frecuencia difiere - el historiador y los archivos de proyecto pueden capturarse cada noche, mientras que una imagen de servidor de referencia se refresca solo cuando la construcción cambia.
El detalle crucial para OT es que al menos una de esas copias fuera de sitio debe estar con brecha de aire o fuera de línea en lugar de ser un recurso compartido de red en vivo. Un respaldo que siempre está montado y alcanzable por la red puede ser cifrado por el mismo ransomware que golpeó al servidor SCADA, porque el malware simplemente sigue la conexión. Una copia con brecha de aire - una que está físicamente desconectada, en medios removibles rotados fuera del edificio, o en almacenamiento inmutable en el que el atacante no puede escribir - es la copia que está garantizada de seguir limpia cuando todo lo alcanzable ha sido cifrado.
Cómo el 3-2-1 se mapea a RTO, RPO y SCADA en la nube
La regla 3-2-1 es una estrategia de almacenamiento, pero solo se gana su lugar cuando se ata a objetivos de recuperación. Su objetivo de punto de recuperación, la máxima pérdida de datos que puede tolerar medida en tiempo, fija con qué frecuencia debe refrescarse cada copia: si no puede perder más de una hora de datos del historiador, la captura horaria de esa copia es lo que la regla exige. Su objetivo de tiempo de recuperación, cuánto puede estar caído antes de restaurar, moldea a qué copia echa mano primero - una copia rápida en disco local para una reversión veloz, y la copia más lenta fuera de sitio o con brecha de aire solo cuando las copias locales se fueron o quedaron comprometidas.
Restaurar desde un respaldo que nunca ha probado es una apuesta, así que la regla funciona mejor cuando se empareja con ensayos periódicos de restauración que prueban que cada copia de verdad reconstruye un sistema funcional dentro del tiempo objetivo. Un respaldo que existe pero no restaura no es una copia en absoluto. Ensayar la copia fuera de sitio en particular importa, porque es la que apoyará durante los peores eventos, y el día de un corte por ransomware es el momento equivocado para descubrir que el archivo estaba incompleto.
El SCADA en la nube cambia la aritmética en una dirección útil. Una plataforma como Merobix transmite de forma continua los datos de campo a un historiador administrado en la nube, que de forma natural provee una copia geográficamente separada de la historia de medición que se mantiene y replica por usted en lugar de depender de que un técnico se acuerde de rotar un disco. Eso no reemplaza toda la regla - usted aún mantiene los archivos de proyecto de ingeniería y las imágenes de servidor respaldados bajo 3-2-1 - pero satisface gran parte de los requisitos de fuera de sitio y de segundo medio para el historiador de forma automática, así que la historia de las plataformas de pozos remotas y los sitios de medición ya no queda atrapada en una sola caja en una caseta.
Preguntas frecuentes
¿Un respaldo en la nube cuenta como la copia fuera de sitio en el 3-2-1?
Sí, una copia en la nube en una región separada de su sitio satisface el requisito de fuera de sitio, porque un incendio o una inundación en la sala de control no puede alcanzarla. Solo asegúrese de que también esté en un medio distinto de su respaldo local e, idealmente, de que al menos una copia en la nube sea inmutable o versionada para que el ransomware no pueda sobrescribirla. Un recurso compartido en la nube que permanece continuamente escribible por la red está fuera de sitio pero no es automáticamente a prueba de ransomware.
¿Por qué es necesaria una tercera copia si ya tengo un respaldo?
Porque los respaldos fallan en silencio. Un respaldo puede estar corrompido, incompleto, o capturado en un momento en que el historiador estaba a mitad de una escritura, y muchas veces no lo descubre hasta que intenta restaurar. Con un solo respaldo, una copia mala lo deja sin nada después de que el primario falla. Una tercera copia independiente significa que un solo respaldo malo o no disponible no acaba con su recuperación.
¿Cómo protege el 3-2-1 al SCADA contra el ransomware específicamente?
El ransomware moderno deliberadamente rastrea y cifra cualquier respaldo alcanzable antes de dispararse, así que un respaldo en un recurso compartido de red en vivo ofrece poca protección. La copia fuera de sitio y con brecha de aire en el 3-2-1 es la respuesta: una copia que está físicamente desconectada o guardada en almacenamiento inmutable no puede ser alcanzada ni cifrada, así que permanece limpia. Esa copia limpia es lo que le deja reconstruir el sistema SCADA sin pagar, y es por lo que la copia fuera de línea es la parte más importante de la regla para OT.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.