Para sobrevivir a los ataques del futuro hay que diseñar contra fallos

Lecciones que podemos aprender

Tenemos que aprender si vamos a construir infraestructuras que pueden sobrevivir frente a crecientes ataques. A menudo, las infraestructuras de Web están construidas con una base de datos “en bucle” – como parte del flujo de solicitudes/respuestas – incluso para las solicitudes más sencillas. Esto infringe el objetivo de divisibilidad que hemos visto en el DNS – que un conjunto mínimo de sistemas posible puede satisfacer las solicitudes. ¿Entonces, cómo diseñamos sistemas con una mayor capacidad para sobrevivir en el futuro?

Empezamos a estudiar nuestro modelo de negocio y lo que garantiza lo que queremos ofrecer. En la industria hotelera, por ejemplo, es una práctica corriente “reservar” una habitación por un periodo de tiempo corto cuando un huésped potencial realiza una búsqueda. Por lo tanto, si Vd. está mirando precios, es posible que tenga varias docenas de habitaciones reservadas, incluso si no va a alquilar la mayoría de este inventario. El deseo de los propietarios del hotel es que una vez que haya decidido alquilar una habitación, la habitación está disponible al precio ofertado. Por otra parte, en la industria aeronáutica, es una práctica corriente hacer lo contrario: buscar una plaza no la reserva y es posible que cuando vuelva a comprobarlo, esta plaza ya no esté disponible a este precio.

Dos modelos ligeramente diferentes que marcan una gran diferencia en las arquitecturas. En el modelo del hotel, el sistema de inventario tiene que ser una plataforma unificada – en el momento en que alguien mira el precio de una habitación, dicha habitación se reserva durante un periodo de tiempo corto en el inventario; nadie más puede ver esta habitación. Esto requiere una arquitectura de base de datos síncrona bien diseñada (construir múltiples sitios se convierte en un reto interesante); esta arquitectura también es un objetivo fácil para los ataques (incluso un ataque accidental – un tercero que simplemente intenta entender las tarifas disponibles para su propio sitio Web puede accidentalmente reservar un importante número de habitaciones, sobrecargando así la base de datos y negando habitaciones a los demás). Ofrece una buena garantía de negocio – que la tarifa propuesta será la que se le cargará siempre y cuando su transacción se finalice en un periodo de tiempo determinado. Esto lo hace a un alto precio – una arquitectura masiva que no escala bien, que es difícil de replicar y que es propensa a la denegación de servicio.

Por otra parte, el modelo de la aerolínea, con solo un ligero cambio, ofrece la oportunidad para una infraestructura fuerte. Ya que el inventario solo se reduce en el momento de la compra, hay mucho menos escrituras en el sistema de inventario. Lo más importante, ya que siempre existe un periodo de tiempo entre la visualización de la tarifa y la compra, las ligeras discrepancias en el inventario son críticas. Si un usuario está buscando una tarifa al mismo tiempo que otro está comprando la última tarifa disponible, el primer usuario estará decepcionado. Si ve la tarifa disponible porque buscaron medio segundo antes de la compra, estará decepcionado igual que si ve esta tarifa medio segundo después de la compra. Estructurar la arquitectura en este modelo permite la separación del sistema de búsqueda en el inventario desde el sistema de reservas. Un servicio al cliente bueno dicta que queremos que estos dos conjuntos de datos sean tan síncronos como sea posible – pero una ligera latencia es aceptable. Ahora el sistema de inventario es meramente una caché para el sistema de reservas, lo que significa que es más fácilmente escalable y que puede distribuirse ampliamente. Si un adversario escanea el inventario, no tiene ningún impacto sobre el sistema de reservas de back end.