Por Rodrigo De Burgos, Regional Manager Kaseya para Latinoamérica
El 15 de abril de 1912, el buque de vapor del Correo Real Británico: Titanic, chocó con un témpano de hielo en el Atlántico. Murieron más de 1,500 pasajeros y tripulantes (1). Tan conocida como trágica, vale la pena revisar la historia de este barco de pasajeros e ilustrar la seguridad de los datos de TI y la recuperación en desastres.
Cumplimiento y Sentido de Seguridad para Proteger sus Datos
Los diseñadores del Titanic lo equiparon con más botes salvavidas de los que exigía el Consejo de Comercio Británico. Aunque el Titanic tenía suficientes botes salvavidas para albergar sólo a la mitad de la gente a bordo, los dueños de la nave tal vez tenían un falso sentido de seguridad porque habían rebasado los requerimientos del gobierno británico (2). Los profesionales de TI no pueden darse el lujo de confiarse porque hayan cumplido con los requerimientos legales para la protección de datos de TI. Las regulaciones están inevitablemente detrás de la curva tecnológica.
Proteger los Datos Críticos Requiere las Herramientas Adecuadas
Por la urgencia de establecer un nuevo récord para cruzar el Atlántico, el Titanic partió del puerto sin los binoculares para sus vigías. Para cuando un miembro de la tripulación divisó el témpano de hielo en la ruta del Titanic, el timonel tuvo sólo 37 segundos para evadirlo (3). Un par de binoculares podría haber salvado al Titanic – valorado en $7.5 millones de dólares –y las vidas de muchos de sus pasajeros. Proteger y recuperar los datos de misión crítica requiere implementar las herramientas adecuadas.
Hacer un Simulacro de Protección de Datos de TI
El capitán Edward Smith canceló el único simulacro de desalojo programado el día anterior al hundimiento del Titanic. Cuando ocurrió el desastre, docenas de vidas se perdieron debido a que la mitad de los botes salvavidas fueron lanzados antes de que estuvieran llenos a su máxima capacidad. Su sistema de protección y restauración de datos es el bote salvavidas de sus datos de misión crítica. ¿Tiene la confianza de que funcionarán bajo las condiciones que usted puede prever? ¿Ha realizado un simulacro para ver cómo funciona el sistema de recuperación en circunstancias de desastres?
Automatizar el Respaldo de Datos para Eliminar los Errores Humanos
Se enviaron varias advertencias de hielo al Titanic que nunca fueron recibidas. En un primer caso, el operador de radio de otro barco no transmitió el mensaje con un prefijo que el Capitán Smith hubiera requerido para reconocerlo personalmente (4). En una segunda instancia, posiblemente la advertencia se perdió debido a que los operadores del Titanic estaban ocupados enviando telegramas retrasados de los pasajeros. Si el Titanic hubiese tenido un mejor sistema para entregar un mensaje, los oficiales del barco podrían haber conocido con anticipación los peligros. Automatizar las funciones triviales (pero críticas) de respaldo de datos, reduce la probabilidad de cometer costosos errores humanos.
Competencia entre Objetivos y Seguridad de Datos
Durante la fase de diseño del Titanic, J. Bruce Ismay, el Presidente de White Star Line, decidió reducir el número de botes salvavidas a bordo de 48 a 16 porque obstruían la vista de los pasajeros de primera clase. También estuvo determinado a establecer un récord de velocidad para cruzar el Atlántico para ayudar a promover su flota de cruceros de pasajeros ultra lujosos. Incluso después de que el Capitán Smith recibió las advertencias de témpanos de hielo, partió a todo vapor hacia Nueva York. Toda empresa persigue muchos objetivos, algunos de los cuales pueden estar en conflicto con el trabajo vital de proteger los datos críticos. De la misma forma, el deseo de Smith de establecer un récord de velocidad para cruzar el Atlántico, estuvo en conflicto con su deber de garantizar la seguridad de los pasajeros. ¿Un objetivo urgente o un calendario muy agresivo representan un riesgo para la protección de datos de TI y de seguridad de su compañía?
[1] http://www.britannica.com/titanic/article-302522
[2] http://lessons-from-history.com/project-management-blunders