La multimodalidad en los entornos de TI implica complejidad. El concepto de que los sistemas de información de una organización operan en un espacio y en equipos de propiedad de la organización, ha sido reemplazado por sistemas que residen en:
- Un centro de datos propietario, “in house”
- Un sitio comercial de colocación/ubicación (colo)
- Un centro de datos externalizado (outsourced)
- Un proveedor gestionador de servicios
- Un sitio remoto, operado por el proveedor, que presta un servicio sobre la Internet
- La nube, un término comúnmente usado para una serie de centros de datos en los cuales un cliente ejecuta sus aplicaciones o adquiere servicios comerciales
Oh, por cierto, todas las alternativas al mismo tiempo.
Esta complejidad es difícil de manejar incluso en los mejores tiempos. Tener una huelga desastrosa en cualquiera de esos lugares decididamente no es el mejor de los casos. (Otros más sabios que yo pueden decidir si un desastre físico es el peor de los casos o si ese “honor” pertenece el ser víctima de un ciberataque destructivo.) Creo que hablo por todos nosotros en decir que los desastres son bastante malos y deben ser evitados.
Diversidad geográfica
La multimodalidad es, en parte, una respuesta a la amenaza de desastres. Su misma estructura asegura que un simple desastre no acabe con todo, solo la parte de los sistemas de una organización que tiene la mala suerte de estar ubicada donde golpeó un desastre. ¿O estoy siendo demasiado liberal con la palabra “asegura”?
Uno de los factores que debería influir en las decisiones sobre sacar un sistema de un centro de datos propietario, es donde será ubicado, cómo está asegurado y cómo funciona, más allá de lo que éste puede hacer. Si la intención es reducir el riesgo, moviendo los sistemas a un colo que está en la calle del frente de la sede central de la organización a un proveedor de outsourcing vecino, no se logrará mucho. Como siempre, un mal diseño puede socavar el mejor de los controles y las funciones de seguridad. La palabra “asegura” debería sustituirse por “posibilita”; Los arquitectos de sistemas deben proporcionar el aseguramiento de que un entorno multimodal contiene la diversidad geográfica suficiente para cumplir con todos sus objetivos de recuperación ante un desastre.
Centros de datos propietarios
Incluso en una arquitectura multimodal, existe la necesidad de contar con un centro de datos propietario.1 Este es el punto central para comunicar todos los sistemas en cualquier parte. También este centro cuenta con equipos para la conducción de la administración del edificio y sistemas de control de acceso, así como también con equipamiento de Internet de las Cosas (IoT),2 alrededor del edificio. La planificación para la recuperación de un desastre en un centro de datos “in-house” es ahora realmente más difícil que antes. Antiguamente (oh, casi una década atrás), la mayoría de las aplicaciones e infraestructuras estaban en el propio centro de datos de la organización.
Ahora, el simple hecho de encontrar otro lugar para ejecutar estos sistemas es insuficiente y tal vez incluso inútil. En el traspaso a un múltimodalismo, si estos sistemas pudieran haber sido transferidos fuera del centro de datos, ellos ya se habrían transferido. ¿Cuál sería el objetivo de un centro de término remoto de telecomunicaciones (hub) si está destruido el demarc de un edificio (punto de demarcación donde la responsabilidad del proveedor termina y comienza la del cliente)? Aunque se pudiese establecer un enlace remoto, ¿cómo sería entregada la información a los desktops? ¿Cómo sonarían los teléfonos?
Sitios de colocación y proveedores de servicios externos
El uso de un sitio de colocación (colo) a menudo tiene que ver más con cuestiones mecánicas, eléctricas y de plomería (MEP) que de TI. Para muchas organizaciones, las economías en la potencia y enfriamiento de un centro de datos no tienen sentido si esas cargas se pueden transferir a una tercera parte. Para otros, migrar de un centro de datos de la organización a un colo es simplemente una fase de transición hacia “Todo es un Servicio” (XaaS).3 Sea lo que sea, la decisión de mover los servidores, el almacenamiento y las telecomunicaciones a un colo significa moverlos no a uno sino a dos sitios: uno primario y uno de respaldo. Una organización podría contar con una instalación de recuperación de desastres que puede servir o no para los sistemas transferidos. Antes de la dependencia total de los sistemas ubicados en un colo, deben estar en orden la ejecución de pruebas. Lo mismo se puede decir del outsourcing4 de una o más aplicaciones y de su infraestructura asociada. En la elección de un proveedor externo, es obligación del cliente asegurarse que esa empresa de hosting tiene al menos un segundo centro de datos, así como también un plan bien probado y mantenido para usarlo si llegase el momento. Todavía está vigente la premisa básica de los centros de datos.
Gestión de servicios y de software como un servicio
Un caso especial del outsourcing son los servicios gestionados: en esencia, es contratar a alguien (un proveedor de servicios administrados [MSP]) para hacer un trabajo que una organización no quiere o no puede hacer por sí misma. Estos trabajos incluyen ciertas funciones de TI, en particular el hosting del correo electrónico, la gestión del desempeño, la supervisión de la seguridad, el almacenamiento, la recuperación, los respaldos, y el monitoreo de la red.5 Por supuesto, muchas de estas actividades se pueden hacer en cualquier MSP que se decida, pero algunas de estas funciones requieren de un trabajo manual. Por lo tanto, los compradores deben considerar cómo estos servicios serán proporcionados si hay un desastre en los sistemas y, más importante aún, si los trabajadores (de estos MSP) estarán disponibles.
Cuando un cliente utiliza Internet para el acceso, es mayor la necesidad de una debida diligencia (de la recuperación) en el caso del Software como Servicio (SaaS).6 Una organización obtiene el uso de un software típicamente sobre la base de una licencia, pero sin poseer ese software, ni los servidores, ni el almacenamiento en el cual éste corre. Que ese equipo esté en algún lugar y, la preparación para una recuperación de desastres, tendría también que estar en algún lugar. Dónde está ese “algún otro lugar” es relevante, así como la frecuencia con que se replica el software y los datos de los clientes de un sitio a otro. Estas no son consideraciones novedosas, pero muchos contratos de SaaS son hechos por las áreas de negocio, no por TI, y la recuperación ante desastres puede pasarse por alto.
La nube
Una verdadera nube es una excelente solución a los problemas de recuperación de desastres. Tengan en cuenta la connotación de “verdadera”. Hay proveedores que afirman ofrecer servicios en la nube, pero una pequeña investigación mostrará que ellos son solo servicios de hosting en unos pocos sitios. No ofrecen la infraestructura subyacente y la mecánica de una verdadera nube, en que el mismo software (generalmente virtualizado) se ejecuta simultáneamente en dos o más sitios, con datos replicados, a intervalos frecuentes, entre ellos. La intención y en muchos casos la realidad, es que esas operaciones se pueden cambiar de un sitio a otro, con poco o ningún impacto en los clientes. Esto se puede hacer por razones de rendimiento, equilibrio de carga o de recuperación. Con tención a esto último, antes de comprometerse con un proveedor de nube, es fundamental verificar los reclamos sobre la infraestructura del vendedor y validar que estas fallas se solucionan automáticamente.
En esta era de la tecnología multimodal, muchos de los problemas de recuperación de desastres son resueltos, algunos simplemente se transfieren y otros empeoran. La recuperación ante desastres es manejable, pero sólo con los ojos bien abiertos.
Notas finales
1 This assumes that an organization has a building where its people work, which is only partially true today. Many people work remotely some or all of the time. The future may lead companies and government agencies to divorce work from real estate and the residual data center may actually disappear.
2 Addressed in Ross, Steven J.; “The End of the Beginning?” ISACA Journal, vol.3, 2017, www.isaca.org/resources/isaca-journal/issues.
3 McLellan, C.; “XaaS: Why ‘Everything’ Is Now a Service,” ZDNet, 1 November 2017, www.zdnet.com/article/xaas-why-everything-is-now-a-service/. Pronounced zăss, it means “Anything as a Service.”
4 In using a colo, an organization owns the equipment and rents the floor space and MEP. If a system is outsourced, the organization owns the application(s), but not the equipment on which it runs, nor the floor space, nor the MEP. These are subtle differences, to be sure, but crucial in planning for disaster recovery.
5 Olavsrud, T.; “How to Get the Most From a Managed IT Services Provider,” CIO, 30 June 2017
6 Hufford, J.; “Cloud Vs SaaS: What’s the Difference?” nChannel, 13 July 2016, https://www.nchannel.com/blog/cloud-vs-saas/. All such services based on software in a cloud are SaaS, but SaaS need not be in the cloud. The services can be accessed directly without passing through a cloud provider. This is a source of confusion and some controversy, into which I do not intend to enter here.
Steven J. Ross, CISA, CISSP, MBCP
Es director ejecutivo de Risk Masters International LLC. Ross ha estado escribiendo una de las columnas más populares de la revista desde 1998. Se lo puede contactar en stross@riskmastersintl.com.