Capítulo 1. La intersección entre seguridad y fiabilidad
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Sobre contraseñas y ejercicios de fuerza
En el 27 de septiembre de 2012, un inocente anuncio en Google provocó una serie de fallos en cascada en un servicio interno. Al final, para recuperarse de estos fallos se necesitó un taladro eléctrico.
Google tiene un gestor 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 es la contraseña del sistema WiFi para invitados de la gran flota de autobuses que conectan los campus de Google en la bahía de San Francisco.
Aquel día de septiembre, el equipo de transporte corporativo envió por correo electrónico a miles de empleados un anuncio de que había cambiado la contraseña del WiFi. El pico de tráfico resultante fue mucho mayor de lo que podía soportar el sistema de gestión de contraseñas, que se había desarrollado años antes para un reducido grupo de administradores de sistemas.
La carga hizo que la réplica primaria del gestor de contraseñas dejara de responder, por lo que el equilibrador de carga desvió el tráfico a la réplica secundaria, que enseguida falló del mismo modo. En ese momento, el sistema llamó al ingeniero de guardia. El ingeniero no tenía experiencia en responder a fallos del servicio: el gestor de contraseñas recibía asistencia en el mejor de los casos, y nunca había sufrido una interrupción en sus cinco años de existencia. El ingeniero intentó reiniciar el servicio, pero no sabía que para ello se necesitaba una tarjeta inteligente de módulo de seguridad de hardware (HSM).
Estas tarjetas inteligentes estaban guardadas en varias cajas fuertes de distintas oficinas de Google de todo el mundo, pero no en Nueva York, donde se encontraba el ingeniero de guardia. Cuando el servicio no se reinició, el ingeniero se puso en contacto con un colega en Australia para recuperar una tarjeta inteligente. Para su gran consternación, el ingeniero de Australia no pudo abrir la caja fuerte porque la combinación estaba almacenada en el gestor de contraseñas ahora desconectado. Afortunadamente, otro colega de California había memorizado la combinación de la caja fuerte in situ y pudo recuperar una tarjeta inteligente. Sin embargo, incluso después de que el ingeniero de California insertara la tarjeta en un lector, el servicio seguía sin reiniciarse con el críptico error: "La contraseña no pudo cargar ninguna de las tarjetas que protegen esta llave".
Llegados a este punto, los ingenieros de Australia decidieron que estaba justificada una aproximación de fuerza bruta al problema de su caja fuerte y aplicaron un taladro eléctrico a la tarea. Una hora más tarde, la caja fuerte estaba abierta, pero incluso las tarjetas recién recuperadas daban el mismo mensaje de error.
El equipo tardó una hora más en darse cuenta de que la luz verde del lector de tarjetas inteligentes no indicaba, en realidad, que la tarjeta se hubiera introducido correctamente. Cuando los ingenieros dieron la vuelta a la tarjeta, el servicio se reinició y la interrupción terminó.
Tanto la fiabilidad como la seguridad son componentes cruciales de un sistema verdaderamente fiable, pero construir sistemas que sean fiables y seguros a la vez es difícil. Aunque los requisitos de fiabilidad y seguridad comparten muchas propiedades comunes, también requieren consideraciones de diseño diferentes. Es fácil pasar por alto la sutil interacción entre fiabilidad y seguridad, que puede provocar resultados inesperados. El fallo del gestor de contraseñas se desencadenó por un problema de fiabilidad -unas estrategias deficientes de equilibrio de la carga y descarga- y su recuperación se complicó posteriormente por las múltiples medidas diseñadas para aumentar la seguridad del sistema.
Fiabilidad frente a seguridad: Consideraciones sobre el diseño
Al diseñar la fiabilidad y la seguridad, debes tener en cuenta distintos riesgos. Los principales riesgos de fiabilidad son de naturaleza no maliciosa: por ejemplo, una mala actualización del software o un fallo físico del dispositivo. Los riesgos de seguridad, sin embargo, proceden de adversarios que intentan activamente explotar las vulnerabilidades del sistema. Cuando diseñas para la fiabilidad, asumes que algunas cosas irán mal en algún momento. Cuando diseñas para la seguridad, debes suponer que un adversario puede intentar que las cosas vayan mal en cualquier momento.
Como resultado, los distintos sistemas están diseñados para responder a los fallos de formas bastante diferentes. En ausencia de un adversario, los sistemas suelen fallar a prueba de fallos (o abrirse): por ejemplo, una cerradura electrónica está diseñada para permanecer abierta en caso de fallo eléctrico, para permitir una salida segura por la puerta. El comportamiento a prueba de fallos/abierto puede dar lugar a vulnerabilidades de seguridad evidentes. Para defenderte de un adversario que pudiera aprovecharse de un fallo de alimentación, podrías diseñar la puerta para que fuera a prueba de fallos y permaneciera cerrada cuando no recibiera alimentación.
Confidencialidad, Integridad, Disponibilidad
Tanto la seguridad como la fiabilidad se ocupan de la confidencialidad, integridad y disponibilidad de los sistemas, pero ven estas propiedades a través de lentes diferentes. La diferencia clave entre ambos puntos de vista es la presencia o ausencia de un adversario malicioso. Un sistema fiable no debe violar la confidencialidad accidentalmente, como podría hacerlo un sistema de chat con fallos que entrega mal, confunde o pierde mensajes. Además, un sistema seguro debe impedir que un adversario activo acceda a los datos confidenciales, los manipule o los destruya. Veamos algunos ejemplos que demuestran cómo un problema de fiabilidad puede conducir a un problema de seguridad.
Nota
La confidencialidad, la integridad y la disponibilidad se han considerado tradicionalmente atributos fundamentales de los sistemas seguros y se conocen como la tríada CIA. Aunque muchos otros modelos amplían el conjunto de atributos de seguridad más allá de estos tres, la tríada CIA ha seguido siendo popular a lo largo del tiempo. A pesar de las siglas, este concepto no está relacionado en modo alguno con la Agencia Central de Inteligencia.
Confidencialidad
En el sector de la aviación, tener un micrófono de pulsar para hablar atascado en la posición de transmisión es un problema de confidencialidad notable. En varios casos bien documentados, un micrófono atascado ha retransmitido conversaciones privadas entre pilotos en la cabina, lo que representa una violación de la confidencialidad. En este caso, no se trata de un adversario malintencionado: un fallo de fiabilidad del hardware hace que el dispositivo transmita cuando el piloto no tiene intención de hacerlo.
Integridad
Del mismo modo, el compromiso de la integridad de los datos no tiene por qué implicar a un adversario activo. En 2015, los Ingenieros de Fiabilidad de Sitios (SRE) de Google observaron que fallaban las comprobaciones de integridad criptográfica de extremo a extremo de algunos bloques de datos. Como algunas de las máquinas que procesaban los datos mostraban posteriormente indicios de errores de memoria no corregibles, los SRE decidieron escribir un software que calculara exhaustivamente la comprobación de integridad para cada versión de los datos con un cambio de un solo bit (un 0 cambiado por un 1, o viceversa). De ese modo, podían ver si uno de los resultados coincidía con el valor de la comprobación de integridad original. De hecho, todos los errores resultaron ser cambios de un solo bit, y los SRE recuperaron todos los datos. Curiosamente, este fue un caso en el que una técnica de seguridad acudió al rescate durante un incidente de fiabilidad. (Los sistemas de almacenamiento de Google también utilizan comprobaciones de integridad de extremo a extremo no criptográficas, pero otros problemas impidieron que los SRE detectaran los cambios de bits).
Disponibilidad
Por último, por supuesto, la disponibilidad es una preocupación tanto de fiabilidad como de seguridad. Un adversario podría explotar el punto débil de un sistema para detenerlo o impedir su funcionamiento a los usuarios autorizados. O podría controlar un gran número de dispositivos repartidos por todo el mundo para realizar un ataque clásico de denegación de servicio distribuido (DDoS), ordenando a los numerosos dispositivos que inunden de tráfico a una víctima.
Los ataques de denegación de servicio (DoS) son un caso interesante porque están a caballo entre la fiabilidad y la seguridad. Desde el punto de vista de la víctima, un ataque malicioso puede ser indistinguible de un fallo de diseño o de un pico legítimo de tráfico. Por ejemplo, una actualización de software de 2018 hizo que algunos dispositivos Google Home y Chromecast generaran grandes picos sincronizados en el tráfico de red cuando los dispositivos ajustaban sus relojes, lo que provocó una carga inesperada en el servicio de hora central de Google. Del mismo modo, una noticia de última hora u otro acontecimiento que provoque que millones de personas realicen consultas casi idénticas puede parecerse mucho a un ataque DDoS tradicional a nivel de aplicación. Como se muestra en la Figura 1-1, cuando un terremoto de magnitud 4,5 sacudió la zona de la bahía de San Francisco en plena noche de octubre de 2019, la infraestructura de Google que daba servicio a la zona recibió una avalancha de consultas.
Figura 1-1. Tráfico web, medido en solicitudes HTTP por segundo, que llegó a la infraestructura de Google que daba servicio a los usuarios de la zona de la bahía de San Francisco cuando un terremoto de magnitud 4,5 sacudió la región el 14 de octubre de 2019.
Fiabilidad y seguridad: Puntos en común
La fiabilidad y la seguridad -a diferencia de muchas otras características de los sistemas- son propiedades emergentes del diseño de un sistema. Ambas son difíciles de añadir a posteriori, por lo que lo ideal es que las tengas en cuenta desde las primeras fases del diseño. También requieren atención y pruebas continuas durante todo el ciclo de vida del sistema, porque es fácil que los cambios del sistema las afecten inadvertidamente. En un sistema complejo, las propiedades de fiabilidad y seguridad suelen venir determinadas por la interacción de muchos componentes, y una actualización de un componente que parezca inocua puede acabar afectando a la fiabilidad o seguridad de todo el sistema de un modo que puede no ser evidente hasta que provoque un incidente. Examinemos estos y otros aspectos comunes con más detalle.
Invisibilidad
La fiabilidad y la seguridad son casi siempre invisibles cuando todo va bien. Pero uno de los objetivos de los equipos de fiabilidad y seguridad es ganarse y mantener la confianza de clientes y socios. Una buena comunicación -no sólo en momentos de problemas, sino también cuando las cosas van bien- es una base sólida para esta confianza. Es importante que la información sea -en la medida de lo posible- honesta y concreta, y sin tópicos ni jerga.
Por desgracia, la inherente invisibilidad de la fiabilidad y la seguridad en ausencia de emergencias hace que a menudo se consideren costes que puedes reducir o aplazar sin consecuencias inmediatas. Sin embargo, los costes de los fallos de fiabilidad y seguridad pueden ser graves. Según informes de los medios de comunicación, las violaciones de datos pueden haber provocado una reducción de 350 millones de dólares en el precio que Verizon pagó para adquirir el negocio de Internet de Yahoo! en 2017. Ese mismo año, un fallo eléctrico provocó el cierre de sistemas informáticos clave en Delta Airlines y provocó casi 700 cancelaciones de vuelos y miles de retrasos, reduciendo el rendimiento de los vuelos de Delta durante el día en aproximadamente un 60%.
Evaluación
Como no es práctico conseguir una fiabilidad o seguridad perfectas, puedes utilizar enfoques basados en el riesgo para estimar los costes de los sucesos negativos, así como los costes iniciales y de oportunidad de prevenir estos sucesos. Sin embargo, debes medir la probabilidad de sucesos negativos de forma diferente para la fiabilidad y la seguridad. Puedes razonar sobre la fiabilidad de una composición de sistemas y planificar el trabajo de ingeniería según los presupuestos de error deseados,1 al menos en parte porque puedes suponer la independencia de los fallos entre los componentes individuales. La seguridad de dicha composición es más difícil de evaluar. Analizar el diseño y la implementación de un sistema puede ofrecer cierto nivel de seguridad. Las pruebas de adversarios -ataques simulados realizados normalmente desde la perspectiva de un adversario definido- también pueden utilizarse para evaluar la resistencia de un sistema a determinados tipos de ataques, la eficacia de los mecanismos de detección de ataques y las posibles consecuencias de los ataques.
Simplicidad
Mantener el diseño del sistema lo más simple posible es una de las mejores formas de mejorar tu capacidad para evaluar tanto la fiabilidad como la seguridad de un sistema. Un diseño más sencillo reduce la superficie de ataque, disminuye el potencial de interacciones imprevistas del sistema y facilita a los humanos la comprensión y el razonamiento sobre el sistema. La comprensibilidad es especialmente valiosa durante las emergencias, cuando puede ayudar a los intervinientes a mitigar los síntomas rápidamente y reducir el tiempo medio de reparación (MTTR). El Capítulo 6 profundiza en este tema y analiza estrategias como minimizar las superficies de ataque y aislar la responsabilidad de las invariantes de seguridad en subsistemas pequeños y sencillos sobre los que se pueda razonar de forma independiente.
Evolución
Por sencillo y elegante que sea el diseño inicial, los sistemas rara vez permanecen inalterados con el paso del tiempo. Los requisitos de nuevas funciones, los cambios de escala y la evolución de la infraestructura subyacente tienden a introducir complejidad. En cuanto a la seguridad, la necesidad de seguir el ritmo de los ataques en evolución y de los nuevos adversarios también puede aumentar la complejidad del sistema. Además, la presión para satisfacer las demandas del mercado puede llevar a los desarrolladores y mantenedores de sistemas a recortar gastos y acumular deuda técnica. El Capítulo 7 aborda algunos de estos retos.
La complejidad suele acumularse inadvertidamente, pero esto puede llevar a situaciones límite en las que un cambio pequeño y aparentemente inocuo tiene consecuencias importantes para la fiabilidad o seguridad de un sistema. Un fallo que se introdujo en 2006 y se descubrió casi dos años después en la versión Debian GNU/Linux de la biblioteca OpenSSL proporciona un ejemplo notorio de un fallo importante causado por un pequeño cambio. Un desarrollador de código abierto se dio cuenta de que Valgrind, una herramienta estándar para depurar problemas de memoria, informaba de advertencias sobre la memoria utilizada antes de la inicialización. Para eliminar las advertencias, el desarrollador eliminó dos líneas de código. Por desgracia, esto provocó que el generador de números pseudoaleatorios de OpenSSL sólo se sembrara con un ID de proceso, que en Debian en ese momento era por defecto un número entre 1 y 32.768. La fuerza bruta podía así romper fácilmente la criptografía. Así, la fuerza bruta podía romper fácilmente las claves criptográficas.
Google no ha sido inmune a fallos provocados por cambios aparentemente inocuos. Por ejemplo, en octubre de 2018, YouTube estuvo fuera de servicio en todo el mundo durante más de una hora debido a un pequeño cambio en una biblioteca de registro genérico. Un cambio destinado a mejorar la granularidad del registro de eventos parecía inocente tanto para su autor como para el revisor de código designado, y superó todas las pruebas. Sin embargo, los desarrolladores no se dieron cuenta plenamente del impacto del cambio a escala de YouTube: bajo carga de producción, el cambio provocó rápidamente que los servidores de YouTube se quedaran sin memoria y se bloquearan. Cuando los fallos desplazaron el tráfico de usuarios hacia otros servidores aún en buen estado, se produjeron fallos en cascada que paralizaron todo el servicio.
Resiliencia
Por supuesto, un problema de utilización de memoria no debería haber causado una interrupción global del servicio. Los sistemas deben diseñarse para ser resistentes en circunstancias adversas o inesperadas. Desde el punto de vista de la fiabilidad, tales circunstancias suelen estar causadas por una carga inesperadamente elevada o por fallos de componentes. La carga es una función del volumen y el coste medio de las peticiones al sistema, por lo que puedes lograr la resiliencia eliminando parte de la carga entrante (procesando menos) o reduciendo el coste de procesamiento de cada petición (procesando más barato). Para hacer frente a los fallos de los componentes, el diseño del sistema debe incorporar redundancia y distintos dominios de fallo, de modo que puedas limitar el impacto de los fallos redirigiendo las peticiones. En el Capítulo 8 se tratan estos temas con más detalle, y en el Capítulo 10 se profundiza en las mitigaciones de la DoS en particular.
Por muy resistentes que sean los componentes individuales de un sistema, una vez que se vuelve lo suficientemente complejo, no puedes demostrar fácilmente que todo el sistema es inmune al compromiso. Puedes abordar este problema en parte utilizando la defensa en profundidad y los dominios de fallo diferenciados. La defensa en profundidad es la aplicación de mecanismos de defensa múltiples, a veces redundantes. Los dominios de fallo distintos limitan el "radio de explosión" de un fallo y, por tanto, también aumentan la fiabilidad. Un buen diseño del sistema limita la capacidad de un adversario de explotar un host comprometido o unas credenciales robadas para desplazarse lateralmente o escalar privilegios y afectar a otras partes del sistema.
Puedes implementar distintos dominios de fallo compartimentando los permisos o restringiendo el alcance de las credenciales. Por ejemplo, la infraestructura interna de Google admite credenciales que están explícitamente delimitadas a una región geográfica. Este tipo de características pueden limitar la capacidad de un atacante que compromete un servidor en una región para desplazarse lateralmente a servidores en otras regiones.
Emplear capas de encriptación independientes para los datos sensibles es otro mecanismo habitual de defensa en profundidad. Por ejemplo, aunque los discos proporcionen cifrado a nivel de dispositivo, a menudo es buena idea cifrar también los datos en la capa de aplicación. De este modo, incluso una implementación defectuosa de un algoritmo de cifrado en un controlador de unidad no será suficiente para comprometer la confidencialidad de los datos protegidos si un atacante consigue acceso físico a un dispositivo de almacenamiento.
Aunque los ejemplos citados hasta ahora giran en torno a los atacantes externos, también debes tener en cuenta las amenazas potenciales de los internos malintencionados. Aunque un insider puede conocer mejor los posibles vectores de abuso que un atacante externo que roba las credenciales de un empleado por primera vez, ambos casos no suelen diferir mucho en la práctica. El principio del mínimo privilegio puede mitigar las amenazas internas. Dicta que un usuario debe tener el conjunto mínimo de privilegios necesarios para realizar su trabajo en un momento dado. Por ejemplo, mecanismos como sudo de Unix admiten políticas detalladas que especifican qué usuarios pueden ejecutar qué comandos y con qué rol.
En Google, también utilizamos la autorización multipartita para garantizar que las operaciones sensibles sean revisadas y aprobadas por conjuntos específicos de empleados. Este mecanismo multipartito protege contra los intrusos malintencionados y reduce el riesgo de error humano inocente, una causa común de fallos de fiabilidad. El privilegio mínimo y la autorización multipartita no son ideas nuevas: se han empleado en muchos escenarios no informáticos, desde los silos de misiles nucleares hasta las cámaras acorazadas de los bancos. En el Capítulo 5 se tratan estos conceptos en profundidad.
Del diseño a la producción
Las consideraciones de seguridad y fiabilidad deben tenerse en cuenta al trasladar incluso un diseño sólido a un sistema de producción totalmente implementado. Empezando por el desarrollo del código, existen oportunidades para detectar posibles problemas de seguridad y fiabilidad mediante revisiones del código, e incluso para evitar clases enteras de problemas utilizando marcos y bibliotecas comunes. En el Capítulo 12 se analizan algunas de estas técnicas.
Antes de implantar un sistema, puedes utilizar las pruebas para asegurarte de que funciona correctamente tanto en situaciones normales como en los casos extremos que suelen afectar a la fiabilidad y la seguridad. Tanto si utilizas pruebas de carga para comprender el comportamiento de un sistema bajo una avalancha de consultas, como fuzzing para explorar el comportamiento en entradas potencialmente inesperadas, o pruebas especializadas para asegurarte de que las bibliotecas criptográficas no están filtrando información, las pruebas desempeñan un papel fundamental a la hora de obtener garantías de que el sistema que has construido realmente coincide con tus intenciones de diseño. El Capítulo 13 trata estos enfoques en profundidad.
Por último, algunos enfoques de la implementación real del código (véase el Capítulo 14) pueden limitar los riesgos de seguridad y fiabilidad. Por ejemplo, los canarios y los despliegues lentos pueden evitar que rompas el sistema para todos los usuarios simultáneamente. Del mismo modo, un sistema de implementación que sólo acepte código que haya sido revisado adecuadamente puede ayudar a mitigar el riesgo de que alguien con información privilegiada pase un binario malicioso a producción.
Investigación de sistemas y registro
Hasta ahora nos hemos centrado en los principios de diseño y los enfoques de implementación para evitar fallos tanto de fiabilidad como de seguridad. Por desgracia, suele ser poco práctico o demasiado caro conseguir una fiabilidad o seguridad perfectas. Debes asumir que los mecanismos preventivos fallarán, y elaborar un plan para detectar los fallos y recuperarte de ellos.
Como tratamos en el Capítulo 15, un buen registro es la base de la detección y la preparación ante fallos. En general, cuanto más completos y detallados sean tus registros, mejor, pero esta directriz tiene algunas advertencias. A escala suficiente, el volumen de registros supone un coste significativo, y analizar los registros con eficacia puede resultar difícil. El ejemplo de YouTube de este capítulo ilustra que los registros también pueden introducir problemas de fiabilidad. Los registros de seguridad plantean un reto adicional: normalmente, los registros no deben contener información sensible, como credenciales de autenticación o información personal identificable (IPI), para que los propios registros no se conviertan en objetivos atractivos para los adversarios.
Respuesta a la crisis
Durante una emergencia, los equipos deben trabajar juntos con rapidez y sin problemas, porque los problemas pueden tener consecuencias inmediatas. En el peor de los casos, un incidente puede destruir una empresa en cuestión de minutos. Por ejemplo, en 2014 un atacante dejó fuera de juego el servicio de alojamiento de código Code Spaces en cuestión de horas, al apoderarse de las herramientas administrativas del servicio y borrar todos sus datos , incluidas todas las copias de seguridad. Una colaboración bien preparada y una buena gestión de incidentes son fundamentales para responder a tiempo en estas situaciones.
Organizar la respuesta a una crisis es todo un reto, así que es mejor tener un plan preparado antes de que se produzca una emergencia. Cuando descubres un incidente, el reloj puede llevar ya algún tiempo corriendo. En cualquier caso, los intervinientes actúan bajo estrés y presión de tiempo, y (al menos al principio) con un conocimiento limitado de la situación. Si una organización es grande y el incidente requiere capacidades de respuesta 24 horas al día, 7 días a la semana, o colaboración a través de zonas horarias, la necesidad de mantener el estado entre los equipos y de ceder la gestión del incidente en los límites de los turnos de trabajo complica aún más las operaciones. Los incidentes de seguridad también suelen entrañar tensión entre el impulso de implicar a todas las partes esenciales y la necesidad -a menudo impulsada por requisitos legales o normativos- de restringir el intercambio de información en función de la necesidad de conocimiento. Además, el incidente de seguridad inicial puede ser sólo la punta del iceberg. La investigación podría extenderse más allá de los límites de la empresa o implicar a las fuerzas de seguridad.
Durante una crisis, es esencial tener una cadena de mando clara y un conjunto sólido de listas de comprobación, manuales y protocolos. Como se expone en los Capítulos 16 y 17, Google ha codificado la respuesta a las crisis en un programa denominado Gestión de Incidentes en Google (IMAG), que establece una forma estándar y coherente de gestionar todo tipo de incidentes, desde interrupciones del sistema a catástrofes naturales, y de organizar una respuesta eficaz. IMAG sigue el modelo del Sistema de Mando de Incidentes (SCI) del gobierno de EEUU, un enfoque estandarizado para el mando, control y coordinación de la respuesta de emergencia entre el personal de respuesta de múltiples organismos gubernamentales.
Cuando no se enfrentan a la presión de un incidente en curso, los equipos de respuesta suelen negociar largos intervalos con poca actividad. Durante estos periodos, los equipos necesitan mantener afiladas las habilidades y la motivación de los individuos y mejorar los procesos y la infraestructura para prepararse para la siguiente emergencia. El programa de Pruebas de Recuperación de Desastres (DiRT) de Google simula regularmente diversos fallos del sistema interno y obliga a los equipos a enfrentarse a este tipo de escenarios. Los frecuentes ejercicios ofensivos de seguridad ponen a prueba nuestras defensas y ayudan a identificar nuevas vulnerabilidades. Google emplea IMAG incluso para pequeños incidentes, lo que nos impulsa aún más a ejercitar regularmente las herramientas y procesos de emergencia.
Recuperación
Recuperarse de un fallo de seguridad suele requerir parchear los sistemas para corregir una vulnerabilidad. Intuitivamente, quieres que ese proceso se produzca lo más rápidamente posible, utilizando mecanismos que se ejerciten con regularidad y que, por tanto, sean decentemente fiables. Sin embargo, la capacidad de introducir cambios rápidamente es un arma de doble filo: aunque esta capacidad puede ayudar a cerrar vulnerabilidades rápidamente, también puede introducir errores o problemas de rendimiento que causen mucho daño. La presión para introducir parches rápidamente es mayor si la vulnerabilidad es ampliamente conocida o grave. La decisión de aplicar los parches lentamente -y, por tanto, tener más garantías de que no se produzcan efectos secundarios involuntarios, pero el riesgo de que se explote la vulnerabilidad- o de hacerlo rápidamente se reduce, en última instancia, a una evaluación del riesgo y a una decisión empresarial. Por ejemplo, puede ser aceptable perder algo de rendimiento o aumentar el uso de recursos para solucionar una vulnerabilidad grave.
Elecciones como ésta subrayan la necesidad de mecanismos de recuperación fiables que nos permitan desplegar rápidamente los cambios y actualizaciones necesarios sin comprometer la fiabilidad, y que también detecten los problemas potenciales antes de que causen una interrupción generalizada. Por ejemplo, un sistema robusto de recuperación de flotas debe tener una representación fiable del estado actual y deseado de cada máquina, y también debe proporcionar paradas para garantizar que ese estado nunca se revierta a una versión obsoleta o insegura. El Capítulo 9 cubre éste y muchos otros enfoques, y el Capítulo 18 trata de cómo recuperar realmente los sistemas una vez que se ha producido un suceso.
Conclusión
La seguridad y la fiabilidad tienen mucho en común: ambas son propiedades inherentes a todos los sistemas de información que resulta tentador sacrificar al principio en nombre de la velocidad, pero que es costoso arreglar después. Este libro pretende ayudarte a afrontar los inevitables retos relacionados con la seguridad y la fiabilidad desde el principio, a medida que tus sistemas evolucionan y crecen. Junto a los esfuerzos de ingeniería, cada organización tiene que comprender las funciones y responsabilidades (véase el Capítulo 20) que contribuyen a crear una cultura de seguridad y fiabilidad(Capítulo 21) para que persistan las prácticas sostenibles. Al compartir nuestras experiencias y lecciones aprendidas, esperamos que puedas evitar pagar un precio mayor más adelante, adoptando algunos de los principios aquí descritos en una fase suficientemente temprana del ciclo de vida del sistema.
Hemos escrito este libro pensando en un público amplio, con el objetivo de que lo encuentres relevante independientemente de la fase o el alcance de tu proyecto. Mientras lo leas, ten en cuenta el perfil de riesgo de tu proyecto: gestionar una bolsa de valores o una plataforma de comunicación para disidentes tiene un perfil de riesgo drásticamente diferente al de gestionar un sitio web para un santuario de animales. El próximo capítulo trata en detalle las clases de adversarios y sus posibles motivaciones.
1 Para más información sobre los presupuestos de error, consulta el capítulo 3 del libro SRE.
Get Construir sistemas seguros y fiables now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
