Materias seguridad de la información: ¿Necesita un plan de recuperación de desastres…?

Son esos tres puntos (los del título) los que me salvan de la acusación de ser un lunático. (Oh, bueno, de acusaciones basadas en este tema). Lo que sigue a los tres puntos es “la recuperación ante desastres se muda a la nube”. Incluso para ser más específico, estoy hablando de la utilización de la Recuperación ante Desastres como un Servicio (DRaaS), que es la relación comercial en la cual una empresa recibe y almacena datos replicados, copias de seguridad y proporciona servidores para hacer las pruebas de recuperación ante desastres con un mayor número de ellos (equipos) para enfrentar un desastre real. Siendo más específico, un proveedor de DRaaS lleva a cabo la recuperación cuando se le solicite, según los acuerdos de nivel de servicio especificados (SLAs). Por lo tanto, un negocio puede, comprar (arrendar realmente) una capacidad de recuperación en incrementos que van desde una hora, cuatro horas, un día o para cualquiera de los niveles de servicio que un proveedor esté dispuesto ofrecer.

Las ventajas del DRaaS

DRaaS ofrece una serie de ventajas sobre el uso de los hot-sites comerciales o de los centros internos de recuperación de datos. Alivia a las organizaciones de tener una repentina necesidad de contar con un cuadro de personal técnico más grande en un momento de crisis. Simplifica la recuperación ante desastres, de pruebas que implican un viaje anual de los técnicos a un sitio de recuperación en un fin de semana de trabajo, y convierte este ejercicio en una llamada telefónica seguida por la espera de resultados. Debe mencionarse que esa llamada telefónica activa una acción del lado del proveedor DRaaS y por tanto, después de eso, posiblemente una factura. En ciertos momentos, cuando muchas organizaciones están externalizando trabajos técnicos a otras regiones del mundo el DRaaS es un multiplicador de la fuerza disponible; los trabajadores en el extranjero podrían no ser capaces de acceder al ambiente de recuperación, y mucho menos recuperar los sistemas desde sus ubicaciones. Por último, en una época en que más procesos de producción son llevados a la nube, también tiene sentido mover la recuperación para allá. Pero eso plantea la cuestión aludida en el título de este artículo: Si un vendedor está haciendo el trabajo de recuperación, con un SLA establecido por contrato (piensa en los objetivos de punto de recuperación (OPR) y objetivos de tiempo de recuperación (RPO), ¿es necesario para una organización tener, de todas maneras, un plan de recuperación ante desastres (DRP)? Veo tres respuestas posibles, y cada vez que pienso que me he decidido por una de ellas, las otras dos vienen detrás rugiendo para debilitar mi confianza.

No, usted no necesita un plan

¿Por qué comprar un perro y luego usted mismo (ponerse a) ladrar?

Involucrarse en una relación con un vendedor DRaaS significa asignar a esa empresa la responsabilidad de recuperar los sistemas de quien compra el servicio. Implícitamente, el vendedor afirma que él sabe cómo llevar a cabo su obligaciones contractuales y que ellas pueden ser probadas (o refutadas) mediante las pruebas. Tal vez la organización que adquiere un apoyo de un DRaaS haya detallado los procedimientos de cómo se van a recuperar los sistemas X, Y y Z desde el punto A al punto B. Esos planes se convierten en irrelevantes cuando es derribado el mismo paradigma de la recuperabilidad de los sistemas. Yo soy apenas el primero que nota que la nube lo cambia todo.

Por otra parte, la organización compradora no tiene nada que decir sobre lo que podrían ser los procedimientos de recuperación del sistema. Esos son los secretos comerciales del vendedor. Se puede sentir como un desperdicio espantoso el hecho de perder el conocimiento acumulado de décadas de planificación de recuperación ante desastres, y que ello puede causar la pérdida de uno o dos puestos de trabajo.

Pero dicen que todo esto es acerca de tecnología disruptiva. Ese conocimiento (DRP) está acumulado dentro de sus cabezas con menos pelos, pero grises. ¿Cuál es el punto de transmitir ese conocimiento, excepto como un artefacto histórico? Una vez perdimos una gran cantidad de conocimientos en COBOL y conseguimos continuar bastante bien sin él.¹

Oh, sí, todavía existe la necesidad de tener un plan que contenga la información de contacto para el proveedor de DRaaS, un proceso de mantenimiento de la correspondencia entre la producción y los sistemas de recuperación, los procedimientos para la validación de la recuperaron de los sistemas y de los datos. Pero eso es apenas una parte de lo que entendemos por un DRP.

Sí, usted necesita un plan, pero no tanto

Sí, usted necesita un plan, pero no tanto. Otra observación no tan original—tengo un millón de ellas—es que usted puede externalizar la responsabilidad, pero no la responsabilidad final de rendir cuenta (accoutability). Por lo tanto, la organización de apoyo del DRaaS debe documentar ampliamente cómo ejecutará las actividades que están bajo su responsabilidad. Estas incluirán todos y los mismos pasos preliminares que debiera contener un DRP de origen interno, incluyendo la determinación que se ha producido un desastre relativo a las TI; cómo declararlo cara-a-cara al proveedor del DRaaS; la supervisión de los procesos de recuperación y comunicación con las partes interesadas de la organización, mientras esté en marcha la acción de recuperación.

Quizás la parte más importante de un DRP basado en un DRaaS, es documentar un entendimiento de cómo la organización llevará a cabo sus negocios mientras sus sistemas están siendo ejecutados de forma remota. Inevitablemente, y como de costumbre, habrán diferencias entre las empresas en el período apoyado por el DRaaS. Los procedimientos de operación deben ser pensados, documentados y revisados antes de que se éstos se necesiten, para así evitar el doloroso hecho de tener que hurgar en ellos precisamente en el peor momento posible.

Finalmente, el DRP requiere de una sección sobre cómo restaurar las operaciones normales una vez terminado el desastre. Si eso significa un retorno a un centro de datos de la organización, esto será complicado. Los proveedores DRaaS son una fuente de orientación sobre cómo transferirles procesos a ellos, pero no son tan buenos en contarles a sus clientes como ir en la dirección inversa. Si una organización usa la nube para sus servicios de software o infraestructura (SaaS/IaaS), ello es aún más complicado, ya que ese proveedor ahora es también responsable de su propia recuperación, dejando atrás temas del comprador mientras soluciona problemas propios.

Sí, usted necesita un plan en el mismo nivell

Todo lo anterior asume que el mismo vendedor del DRaaS no fallará, con varios significados a esa última palabra. Aplica a un proveedor que es incapaz de proporcionar un servicio adecuado; no se recupera dentro de los SLAs establecidos; o, en el peor de los casos, simplemente falla y se va fuera del negocio. La organización que compra el DRaaS debe tener en cuenta estas eventualidades al momento de su adquisición. Considérelo como un acuerdo prenupcial que hace una organización consigo misma, porque el vendedor DRaaS ciertamente no participará. Tal vez se puede incluir en el contrato una especie de “testamento vital”, pero de nuevo, el vendedor tiene pocos incentivos para participar en esto. Esto deja a la organización adquirente con la extraña responsabilidad de planear una recuperación desde un entorno de producción que enfrenta un potencial desastre para un centro de datos que no existe.

Con la recuperación prevista hacerla con un DRaaS, el comprador del servicio debería aceptar sus potenciales futuras fallas y planificarlas. Esto no sólo es contrario a la intuición, es muy difícil de financiar y es imposible de probar. Podría disuadir la decisión de usar un DRaaS, pero una vez que se ha tomado esa decisión, el pensamiento del tipo “Qué pasa si” debe comenzar a operar.

¿A dónde voy con todo esto? Como dije al principio, tengo una mente contradictoria en esta materia. Hay una cierta calidad de golpear a un topo² en el tema. Si me aprietan contra la pared, yo diría que las organizaciones necesitan tener sus propios planes de lo que ellos harían mientras el vendedor DRaaS está desarrollando lo que hará. No le digo a un mecánico cómo arreglar mi auto pero planearía que es lo que haría mientras el auto esté en el garaje. Es una analogía inexacta, pero es la mejor que tengo para esta columna.

Notas Finales

¹ Excepto en el período previo al año 2000.
² Whack-a-mole “golpear a un topo”. Había un juego arcade Americano en la década del 70. Para aquellos que no recuerdan la América en la década del 70, había un juego en que topos surgían de un agujero y, cuando eran golpeados, aparecería otro topo en algún otro lugar. En la práctica este término es utilizado cuando al tratar de deshacerse varias veces de algo, sólo hacemos que aparezcan más de lo mismo, como eliminar las cuentas de correo de los spammers o cerrar las ventanas pop-up en un explorador web. http://onlineslangdictionary.com/meaning-definition-of/whack-a-mole