Fernando Carmona, CEO
Como título de este artículo de opinión me estoy copiando de una de las frases que más usamos los comerciales cuando queremos motivar a alguien a que se sume a la última tendencia del momento, bien sea algo viejo como que hay que migrar todo a JAVA, que implemente Block Chain por todos lados o lo que sea la tendencia actual. La frase es: la decisión no es si debe o no implementar lo que le estoy vendiendo, sino cuando. Con tanto hackeo en todo Latinoamérica, muchos que llegan a las portadas de los diarios y otros que se mantienen con bajo perfil, para evitar el impacto reputacional, lo que mucha gente se pregunta no es si lo van a hackear o no, sino cuando.
En los últimos 20 años los bancos han pasado de infraestructuras sencillas, completamente OnPrem, a unas de las más complejas de todas las industrias, incluyendo aquellos que crecieron con una telaraña de diferentes elementos siguiendo tendencias y proveedores que desarticularon su infraestructura.
Actualmente un banco moderno tiene en promedio 60 aplicaciones para poder funcionar, debe soportar un sinnúmero de tecnologías de todo tipo, una miríada de normas y regulaciones y ejecutar todo en ambientes híbridos, Cloud y OnPrem, administrando decenas de proveedores y luchando contra la constante obsolescencia de lo que tiene. El resultado es que un banco moderno afronta una complejidad que ha crecido de manera exponencial y, como me lo ha dicho más de un honesto director de tecnología, a veces no saben ni cómo es que la entidad funciona. Hay demasiados puntos potencialmente vulnerables.
¿Qué hacer ante esta difícil situación?, ante un entorno tan complejo, con muchas fuerzas que le seguirán presionando para que lo haga aún más complejo, existen recomendaciones conocidas, que en este artículo queremos repasar y que se resumen en cinco puntos: aplique pensamiento escéptico, simplifique la infraestructura tecnológica, certifíquese (pero no crea en las certificaciones), corra en modalidad clúster con DRP y haga zafarranchos, entendiéndose zafarrancho como una prueba controlada, pero real, de los ambientes de contingencia. A continuación, el detalle de cada uno de los puntos.
1. Aplique pensamiento escéptico.
Comienzo por un punto que siempre expongo y que suelo discutir con mis colegas de informática. La informática es una profesión joven, muy joven, donde el Método Científico suele brillar por su ausencia y lo que prima es la demostración anecdótica. Por tanto, el Pensamiento Escéptico, sobre todo cuando llegan nuevas modas, sean tecnológicas o administrativas, es pocas veces utilizado y los resultados suelen ser el aumento innecesario de la complejidad, con el costo y riesgo que eso implica. Hay que decirlo claro: en general los líderes de tecnología de las entidades gustan mucho de las modas y gastan demasiado recurso en seguirlas, en sacrificio de optimizar y mejorar lo existente. Cada moda que llega a la mesa por supuesto hay que explorarla, pero no volverla el santo grial de la institución. Todo sistema nuevo implica hardware, software, bases de datos con información sensible, proveedores y costos. Toda dispersión que vaya en contra de tener soluciones integradas y simples, sin que se use el pensamiento escéptico para abordarlas, es un leño más en la hoguera que da calor a los hackers.
2. Simplifique su arquitectura tecnológica.
Encadenado con lo anterior, tenemos un resultado donde los bancos se volvieron el campo de juego, y pruebas de todo lo que hay por ahí. No solo basta con ser cuidadoso en agregar más servidores, servicios y sistemas a su infraestructura, sino que la misión de simplificarla debe ser objetivo de todos los días. Hay muchos proyectos que se inician y que nunca terminan, hay muchos sistemas que brindan poco beneficio y se puede vivir sin ellos, hay muchos sistemas que para poder funcionar integradamente se componen de demasiados elementos dispersos. Oriéntese a hardware y software integrado, donde la solución depende de la menor cantidad de proveedores posibles (no olvide los proveedores de los proveedores). En la actualidad es más conveniente mantener OnPrem las aplicaciones de Misión Crítica, o máximo explorar un entorno híbrido, y solo dejar en Cloud las que no lo son, y los ambientes de prueba. Es más fácil cuidar la casa si esta no tiene 628 puertas y ventanas.
3. Certifíquese, pero no crea en las certificaciones.
PCI, ISO27001 y toda la lista de certificaciones que estamos obligados a cumplir son exactamente las mismas que todos los proveedores de Cloud, y muchas instituciones se ufanaban de tener y mostraban con orgullo, justo antes de que los hackearan. No es que no sirvan, por supuesto que son muy útiles y hay que obtenerlas no solo por cumplir y tener el sello, sino que hay que hacerlas con ahínco, como por ejemplo la encripción de datos sensibles para hacerle la vida más difícil a los hackers si le llegan a robar la información. Pero no hay que creer en ellas porque, aunque ayudan, al final no son una barrera fuerte, no son garantía de nada. Además, recuerde siempre que las certificaciones son negocio para otros y eso automáticamente las baja de su pedestal de infalibilidad.
4. Implemente Activo – Activo más DRP.
En las aplicaciones que son de Misión Crítica implemente modelos de ejecución en esquema Clúster, con sites lo más aislados posible. Lo usual en la industria sigue siendo el Activo-Pasivo, que es válido siempre y cuando sean verdaderamente aislados (aunque no guste a los amantes del single sign on), y se prueben en zafarranchos. Más ideal aún es que el servicio corra en esquema Activo-Activo, con distribución de carga en caliente. Más ideal aún es que complemente todo con un DRP, idealmente OnPrem en alguno de sus bunkers de confianza, con replicación de datos en línea e, insisto, probados en zafarranchos programados. Por último, como la criptografía es clave en toda la seguridad moderna, no solo para validar datos sino para protegerlos, prefiera infraestructuras donde viene integrada.
5. Haga zafarranchos.
Finalmente, como todos estamos de acuerdo en que ningún plan de contingencia sirve si no se ejecuta, hay que hacer zafarranchos. El problema con los zafarranchos es que como lo urgente no da tiempo para lo importante, se les trata como cenicienta; siempre se pueden hacer “después”. Note que un clúster activo-activo evita tener que hacer zafarranchos porque el esquema en sí es implica un espejo de contingencia; en A-A lo que debe hacerse es el zafarrancho del DRP. Los zafarranchos se darán mayor tranquilidad en el caso en que le secuestran un site, porque con el otro, o los otros, puede seguir operando sin demasiado black out en la reactivación del servicio.
De los cinco puntos anteriores el factor común es la simplicidad. En CLAI PAYMENTS® Technologies, la lucha por mantener soluciones simples, pero que a su vez sean completas, integradas e independientes de terceros, es la base de nuestra estrategia, a partir de esta filosofía hemos creado soluciones que vienen generando éxito en la facilidad para integrar y agilizar las plataformas de nuestros clientes, así como hacer que los datos sensibles estén protegidos bajo el cifrado más robusto de la industria, a la fecha inexpugnable. Desde nuestra visión y experiencia hemos recomendado este camino a muchos de nuestros clientes que, si bien no están exentos de un ataque, sus datos, sus servidores, y los datos sensibles de sus clientes están resguardados en cuanto a misión crítica se refiere.