Cuando ocurrió la caída global de Facebook (ahora conocido como "Meta") en octubre, vimos cómo a los ingenieros de la compañía les tomó mucho tiempo la recuperación del servicio debido a las exigentes normas de seguridad en su hardware, complicando los trabajos que era necesario hacer.
El problema es que hay un dilema entre la fiabilidad y la seguridad, y ninguna gran empresa se salva de esta disyuntiva. Revisemos por un caso de falla que afectó a Google el 27 de septiembre de 2012, y que requirió de un taladro para su solución. La anécdota es relatada en detalle en el libro "Building Secure and reliable systems".
Google tiene un administrador de contraseñas interno que permite a los empleados almacenar y compartir secretos para servicios de terceros que no admiten mejores mecanismos de autenticación.
Uno de esos secretos era la contraseña del sistema WiFi para invitados en los autobuses de Google en San Francisco. Ese día de septiembre, el equipo de transporte corporativo envió por correo electrónico un anuncio a miles de empleados diciendo que la contraseña de WiFi había cambiado.
El aumento resultante en el tráfico fue mucho mayor de lo que podía manejar el sistema de administración de contraseñas, que se había desarrollado años antes para solo un grupo de administradores de sistemas. La carga hizo que la réplica principal del administrador de contraseñas dejara de responder, por lo que el balanceador de carga desvió el tráfico a la réplica secundaria, que
rápidamente falló de la misma manera.
En este punto, el sistema llamó al ingeniero de turno. El sistema no había tenido interrupciones en sus cinco años de existencia, por lo que ingeniero no tenía experiencia en responder a esta falla. El ingeniero intentó reiniciar el servicio, pero no sabía que un reinicio requería una tarjeta inteligente de un módulo de seguridad de hardware.
Estas tarjetas inteligentes se almacenaron en varias cajas fuertes, en diferentes ciudades del mundo, pero no en Nueva York, donde se encontraba el ingeniero de turno. Cuando el servicio no pudo reiniciarse, el ingeniero se comunicó con un colega en Australia para recuperar una tarjeta inteligente. Para su gran consternación, en Australia no pudieron abrir la caja fuerte, porque la combinación estaba almacenada, precisamente, en el administrador de contraseñas.
Afortunadamente, un ingeniero en California había memorizado la combinación de la caja fuerte de su oficina y pudo recuperar una tarjeta inteligente. Sin embargo, incluso después de que el ingeniero en California insertara la tarjeta en un lector, el servicio aún no pudo reiniciarse, mostrando un mensaje de error críptico: "La contraseña no pudo cargar ninguna de las tarjetas que protegen esta clave". En este punto, los ingenieros en Australia decidieron que se necesitaba de fuerza bruta para resolver el problema de seguridad y usaron un taladro eléctrico para abrir la caja. Una hora más tarde, la caja fuerte estaba abierta, pero las tarjetas recién recuperadas mostraban el mismo
mensaje de error.
El equipo tardó otra hora en darse cuenta de que la luz verde del lector de tarjetas inteligentes no indicaba - como se presumía - que la tarjeta se había insertado correctamente. Cuando los ingenieros dieron vuelta la tarjeta, el servicio se reinició y terminó la interrupción.
¿Qué podemos aprender de esta historia?
Como hemos visto, fiabilidad y seguridad son dos caras de una misma moneda. La fiabilidad se preocupa de los riesgos que no son maliciosos, tales como la falla de hardware, un bug en una nueva versión de software, de los procesos de cambio.
La seguridad parte de la base que hay un adversario, un tercero, que quiere hacer algún mal en el sistema o servicio. Con esto se dan ciertas paradojas, como el hecho de que para mejorar la fiabilidad
de un servicio se cree un sitio de contingencia, pero esta decisión aumenta los riesgos de seguridad ya que habrá más sistemas o servidores involucrados, aumentando las chances de un ataque.
La fiabilidad y seguridad deben ser consideraciones iniciales del diseño del servicio. No incluirlos, puede implicar costos significativos al implementar en un sistema ya productivo.
