Seguridad práctica en la nube, 2ª edición

Capítulo 1. Principios y conceptos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Sí, ésta es una guía práctica, pero necesitamos cubrir algunos principios y conceptos de seguridad relevantes para la nube a un alto nivel antes de sumergirnos en las partes prácticas. Si eres un profesional de la seguridad experimentado, pero nuevo en la nube, quizá quieras hojear hasta "El modelo de responsabilidad compartida en la nube".

La razón por la que cubro estos principios y conceptos en primer lugar es porque se utilizan implícitamente en el resto del libro cuando hablo del diseño y la aplicación de controles de seguridad para detener a los atacantes. Las lagunas conceptuales y los malentendidos en seguridad pueden causar muchos problemas. Por ejemplo:

• Si no estás familiarizado con el mínimo privilegio, puede que entiendas bien la autorización para los servicios en la nube, pero aun así concedas demasiado acceso a personas o automatizaciones en tu cuenta en la nube o en una base de datos en la nube con información sensible.

• Si no estás familiarizado con la defensa en profundidad, tener varias capas de autenticación, control de acceso a la red o encriptación puede no parecer útil.

• Si no sabes un poco de modelado de amenazas -las motivaciones probables de los atacantes y los límites de confianza del sistema que estás diseñando-, puedes estar dedicando tiempo y esfuerzo a proteger las cosas equivocadas.

• Si no entiendes los modelos de prestación de servicios en la nube y el modelo de responsabilidad compartida, puedes dedicar tiempo a preocuparte por riesgos que son responsabilidad de tu proveedor de servicios en la nube y pasar por alto riesgos que son responsabilidad tuya abordar.

• Si no sabes un poco de gestión de riesgos, puedes dedicar demasiado tiempo y esfuerzo a los riesgos bajos, en lugar de gestionar los riesgos más altos.

Cubriré esta información básica rápidamente para que podamos pasar a los controles de seguridad en la nube.

Mínimo privilegio

El principio del menor privilegio establece simplemente que las personas o las herramientas automatizadas deben poder acceder sólo a lo que necesitan para hacer su trabajo, y no más. Es fácil olvidar la parte de automatización de esto; por ejemplo, un componente que accede a una base de datos no debe utilizar credenciales que permitan el acceso de escritura a la base de datos si no se necesita el acceso de escritura.

Una aplicación práctica del mínimo privilegio suele significar que tus políticas de acceso son de denegación por defecto. Es decir, a los usuarios no se les concede ningún privilegio (o muy pocos) por defecto, y tienen que pasar por el proceso de solicitud y aprobación de cualquier privilegio que necesiten.

Para los entornos en nube, algunos de tus administradores necesitarán tener acceso a la consola en nube, una página web que te permite crear, modificar y destruir activos en nube, como máquinas virtuales. Con muchos proveedores, cualquiera que tenga acceso a su consola de nube tendrá privilegios divinos por defecto para todo lo que gestione ese proveedor de nube. Esto puede incluir la capacidad de leer, modificar o destruir datos de cualquier parte del entorno de la nube, independientemente de los controles que existan en los sistemas operativos de los sistemas aprovisionados. Por esta razón, tienes que controlar estrictamente el acceso y los privilegios en la consola de la nube, de forma muy parecida a como controlas estrictamente el acceso al centro de datos físico en los entornos locales, y registrar lo que hacen estos usuarios.

Defensa en profundidad

Muchos de los controles de este libro, si se aplicaran perfectamente, anularían la necesidad de otros controles. La defensa en profundidad es un reconocimiento de que casi cualquier control de seguridad puede fallar, ya sea porque un atacante es lo suficientemente decidido y hábil o por un problema con la forma en que se implementa ese control de seguridad. Con la defensa en profundidad, creas múltiples capas de controles de seguridad superpuestos, de modo que si uno falla, el que está detrás aún puede atrapar a los atacantes.

Sin duda, puedes llegar a extremos absurdos con la defensa en profundidad, por eso es importante comprender las amenazas a las que probablemente te enfrentes. Sin embargo, como norma general, deberías poder señalar cualquier control de seguridad que tengas y decir: "¿Y si esto falla?". Si la respuesta es inaceptable, probablemente tengas una defensa en profundidad insuficiente. También puedes tener una defensa en profundidad insuficiente si un único fallo puede hacer que varios de tus controles de seguridad sean ineficaces, como un problema de inventario que hace que varias herramientas pasen por alto un problema.

Confianza cero

Hoy en día, muchos productos y servicios afirman ser de confianza cero, o apoyar los principios de confianza cero. El nombre es confuso, porque confianza cero no significa falta total de confianza en nada, y la confusión es mayor porque se utiliza con muchos fines de marketing diferentes. Existen muchas definiciones e ideas diferentes sobre lo que se entiende por confianza cero.

Probablemente estemos atascados con el término en este punto, pero "confianza cero" en realidad debería llamarse de otra manera, como "confianza implícita cero" o "confianza asumida cero sin una buena razón".¹ El principio básico es que la confianza de un usuario o de otro sistema debe ganarse, en lugar de otorgarse simplemente porque el usuario puede localizarte en la red, o tiene un dispositivo propiedad de la empresa, o algún otro criterio que no esté biencontrolado.

La implementación de la confianza cero será muy diferente según se trate de confiar en dispositivos, conexiones de red u otra cosa. Una implementación comúnmente utilizada de la confianza cero es exigir cifrado y autenticación para todas las conexiones, incluso las que se originan y terminan en redes supuestamente de confianza. Esto siempre ha sido una buena idea, pero es aún más importante en los entornos de nube, donde el perímetro está diseñado de forma menos estricta y la conectividad a Internet es fácil.

Otra aplicación común de los principios de confianza cero consiste en limitar el acceso de los usuarios a la red sólo a las aplicaciones que necesitan, desafiando la confianza implícita de que todos los usuarios deberían poder conectarse a todas las aplicaciones, aunque no puedan iniciar sesión. Si piensas que esto se parece mucho al privilegio mínimo y a la defensa en profundidad, tienes razón. Existe un solapamiento considerable entre los principios de confianza cero y algunos de los otros principios de este capítulo.

Un tercer ejemplo de confianza cero es el uso de la autenticación multifactor de los usuarios, con la reautenticación requerida periódicamente o cuando se solicitan transacciones de mayor riesgo. En este caso, estamos desafiando la confianza implícita de que quien tiene la contraseña de una cuenta, o controla una sesión concreta de una aplicación, es el usuario previsto.

Cuando sigas los principios de confianza cero, sólo debes confiar en una interacción si tienes pruebas sólidas de que la confianza está garantizada, como por ejemplo mediante una prueba de autenticación sólida, o autorización, o configuración correcta. Esas pruebas deben proceder de algo que controles directamente (como tu propio sistema de autenticación o de gestión de dispositivos), o de algún tercero que hayas evaluado explícitamente como competente para tomar decisiones de confianza por ti. Al igual que otros principios de este capítulo, puede ser perjudicial para la experiencia del usuario si se lleva al extremo.

Actores de la amenaza, diagramas y límites de confianza

Hay diferentes maneras de pensar en tus riesgos, pero yo suelo favorecer un enfoque orientado a los activos. Esto significa que te concentras primero en lo que necesitas proteger, y por eso profundizo primero en los activos de datos, en el Capítulo 2.

También es una buena idea tener en cuenta quién tiene más probabilidades de causarte problemas. En la jerga de la ciberseguridad, éstos son tus "actores de amenaza" potenciales. Por ejemplo, puede que no necesites protegerte contra un actor estatal bien financiado, pero puede que tengas un negocio en el que un ciberdelincuente pueda ganar dinero robando tus datos, o en el que un "hacktivista" quiera desfigurar tu sitio web por motivos políticos o sociales. Ten en cuenta a estas personas cuando diseñes todas tus defensas.

Aunque hay mucha información y debates disponibles sobre el tema de los actores de amenazas, motivaciones y métodos,² en este libro consideraremos cuatro tipos principales de actores de amenazas de los que puedes tener que preocuparte:

• Crimen organizado o delincuentes independientes, interesados principalmente en ganar dinero

• Hacktivistas, interesados principalmente en desacreditarte divulgando datos robados, cometiendo actos de vandalismo o perturbando tu negocio.

• Atacantes internos, normalmente interesados en desacreditarte o ganar dinero

• Agentes estatales, que pueden estar interesados en robar secretos o perturbar tu negocio para promover la misión o causa política de un gobierno extranjero.

Tomando prestada una técnica del mundo del diseño de la experiencia del usuario, quizá quieras imaginar a un miembro de cada grupo aplicable, darle un nombre, apuntar un poco sobre esa "persona" en una tarjeta, y mantener las tarjetas a la vista cuando diseñes tus defensas.

Lo segundo que tienes que hacer es averiguar qué tiene que hablar con qué en tu aplicación, y la forma más fácil de hacerlo es hacer un dibujo y averiguar dónde es probable que estén tus puntos débiles. Hay libros enteros sobre cómo hacerlo,³ pero no necesitas ser un experto para dibujar algo lo suficientemente útil que te ayude a tomar decisiones. Sin embargo, si estás en un entorno de alto riesgo, probablemente deberías crear diagramas formales con una herramienta adecuada, en lugar de dibujar figuras de palo.

Aunque existen muchas arquitecturas de aplicación diferentes, para la aplicación de ejemplo utilizada aquí como ilustración, mostraré un diseño sencillo de tres niveles. Esto es lo que recomiendo para un diagrama de componentes de aplicación muy sencillo:

1. Dibuja una figura de palo y etiquétala como "usuario". Dibuja otra figura de palo y etiquétala como "administrador"(Figura 1-1). Puede que más adelante descubras que tienes varios tipos de usuarios y administradores, u otras funciones, pero éste es un buen comienzo.

   

   Figura 1-1. Funciones de usuario y administrador

2. Dibuja un recuadro para el primer componente con el que habla el usuario (por ejemplo, los servidores web), traza una línea desde el usuario hasta ese primer componente, y etiqueta la línea con la forma en que el usuario habla con ese componente(Figura 1-2). Ten en cuenta que, en este punto, el componente puede ser una función sin servidor, un contenedor, una máquina virtual o cualquier otra cosa. Esto permitirá que cualquiera hable con él, así que probablemente será lo primero que se ataque. Realmente no queremos que los demás componentes confíen en éste más de lo necesario.

   

   Figura 1-2. Primer componente

3. Dibuja otros recuadros detrás del primero para todos los demás componentes con los que tenga que hablar el primer sistema, y traza líneas que vayan a ellos(Figura 1-3). Cuando llegues a un sistema que realmente almacene datos, dibuja un pequeño símbolo (yo utilizo un cilindro) junto a él y anota qué datos hay allí. Sigue así hasta que no se te ocurran más cajas que dibujar para tu aplicación.

   

   Figura 1-3. Componentes adicionales

4. Dibuja ahora cómo accede el administrador (y cualquier otro rol que hayas definido) a la aplicación. Ten en cuenta que el administrador puede tener varias formas distintas de hablar con esta aplicación; por ejemplo, a través del portal o las API del proveedor de la nube, o a través del sistema operativo, o de forma similar a como accede un usuario(Figura 1-4).

   

   Figura 1-4. Acceso de administrador

5. Dibuja algunos límites de confianza como líneas de puntos alrededor de las casillas(Figura 1-5). Un límite de confianza significa que cualquier cosa dentro de ese límite puede tener al menos cierta confianza en los motivos de cualquier otra cosa dentro de ese límite, pero requiere verificación antes de confiar en cualquier cosa fuera del límite. La idea es que si un atacante entra en una parte del límite de confianza, es razonable suponer que acabará teniendo el control total de todo lo que haya en ella, por lo que atravesar cada límite de confianza debería suponer cierto esfuerzo. Observa que he dibujado varios servidores web dentro del mismo límite de confianza; eso significa que está bien que estos servidores web confíen unos en otros, y que si alguien tiene acceso a uno, efectivamente tiene acceso a todos. O, dicho de otro modo, si alguien compromete uno de estos servidores web, no se producirá más daño si se comprometen todos.

   En este contexto, los principios de confianza cero nos llevan a reducir estos límites de confianza al tamaño más pequeño razonable: por ejemplo, un único componente, que aquí podría ser un servidor individual o un clúster de servidores con los mismos datos y finalidad.

   

   Figura 1-5. Límites de confianza de los componentes

6. Hasta cierto punto, confiamos más en todo nuestro sistema que en el resto del mundo, así que traza una línea de puntos alrededor de todas las casillas, incluido el admin, pero no el usuario(Figura 1-6). Ten en cuenta que si tienes varios administradores, como un administrador del servidor web y un administrador de la base de datos, podrían estar en límites de confianza diferentes. El hecho de que haya límites de confianza dentro de límites de confianza muestra los distintos niveles de confianza. Por ejemplo, los servidores aquí pueden estar dispuestos a aceptar conexiones de red de servidores de otros límites de confianza dentro de la aplicación, pero aún así verificar sus identidades. Por otro lado, pueden no estar dispuestos a aceptar conexiones de sistemas situados fuera de todo el límite de confianza de la aplicación.

   

   Figura 1-6. Límite de confianza de toda la aplicación

Utilizaremos este diagrama de una aplicación de ejemplo a lo largo del libro cuando hablemos del modelo de responsabilidad compartida, el inventario de activos, los controles y el monitoreo. En este momento, no se muestran controles específicos de la nube en el diagrama, pero eso cambiará a medida que avancemos en los capítulos. Fíjate en cualquier lugar donde una línea cruce un límite de confianza. ¡Estos son los lugares en los que tenemos que centrarnos en asegurar primero!

Modelos de prestación de servicios en la nube

Existe una ley no escrita según la cual ningún libro sobre computación en nube está completo sin una visión general de la Infraestructura como Servicio (IaaS), la Plataforma como Servicio (PaaS) y el Software como Servicio (SaaS). En lugar de dar la visión general estándar, me gustaría decir rápidamente que los servicios IaaS suelen permitirte crear ordenadores virtuales, almacenamiento y redes; los servicios PaaS suelen ser servicios de nivel superior, como bases de datos, que te permiten crear aplicaciones; y los servicios SaaS son aplicaciones utilizadas por los usuarios finales. Puedes encontrar muchas definiciones ampliadas y subdivisiones de estas categorías, pero éstas son las definiciones básicas.

Estos modelos de servicio sólo son útiles para una comprensión general de los conceptos; en concreto, la línea entre IaaS y PaaS es cada vez más difusa. ¿Un servicio de red de distribución de contenidos que almacena información en caché en Internet para mantenerla cerca de los usuarios es un PaaS o un IaaS? En realidad, no importa. Lo importante es que entiendas lo que proporciona (¡y lo que no!) el servicio, no si encaja o no en una categoría concreta.

El modelo de responsabilidad compartida en la nube

La pregunta de seguridad más básica que debes responder es: "¿De qué aspectos de la seguridad soy responsable?". Esto suele responderse implícitamente en un entorno local. La organización de desarrollo es responsable de los errores de código, y la organización de operaciones (TI) es responsable de todo lo demás. Muchas organizaciones aplican ahora un modelo DevOps en el que esas responsabilidades se comparten, y los límites de los equipos entre desarrollo y operaciones son difusos o inexistentes. Independientemente de cómo esté organizada, casi toda la responsabilidad de la seguridad está dentro de la empresa.

Quizá uno de los cambios más chocantes al pasar de un entorno local a un entorno en la nube sea un modelo de responsabilidad compartida más complicado en materia de seguridad. En un entorno local, puede que tuvieras algún tipo de documento interno de entendimiento o contrato con TI o algún otro departamento que gestionara los servidores por ti. Sin embargo, en muchos casos los usuarios empresariales de TI estaban acostumbrados a entregar los requisitos o el código a un proveedor interno y que todo lo demás se hiciera por ellos, sobre todo en el ámbito de la seguridad.

Aunque lleves tiempo operando en un entorno de nube, puede que no te hayas parado a pensar dónde acaba la responsabilidad del proveedor de la nube y dónde empieza la tuya. Esta línea de demarcación es diferente en función de los tipos de servicios en nube que adquieras. Casi todos los proveedores de servicios en la nube abordan esto de alguna manera en su documentación y materiales de formación, pero la mejor forma de explicarlo es utilizar la analogía de comer pizza.

Con Pizza como servicio,⁴ digamos que tienes hambre de pizza. ¡Hay un montón de opciones! Podrías hacer una pizza en casa, aunque necesitarías tener bastantes ingredientes y te llevaría un rato. Podrías ir corriendo al supermercado y comprar una para llevar y hornear; eso sólo requiere que tengas un horno y un lugar donde comerla. Podrías llamar a tu pizzería favorita. O podrías ir a sentarte a un restaurante y pedir una pizza. Si dibujamos un diagrama de los distintos componentes y quién es responsable de ellos, obtendremos algo como la Figura 1-7.

Figura 1-7. Pizza como servicio

El mundo tradicional on-premise es como hacer una pizza en casa. Tienes que comprar un montón de componentes diferentes y montarlos tú mismo, pero consigues una flexibilidad total. ¿Anchoas y canela en corteza de trigo? Si puedes soportarlo, puedes hacerlo.

Sin embargo, cuando utilizas la Infraestructura como Servicio, la capa base ya está hecha por ti. Puedes hornearla al gusto y añadir una ensalada y bebidas, y tú eres responsable de esas cosas. Cuando pasas a Plataforma como Servicio, ya se toman más decisiones por ti, incluida la forma en que se hornea tu pizza. (Como se ha mencionado en la sección anterior, a veces puede ser difícil clasificar un servicio como IaaS o PaaS, y en muchos casos crecen juntos. La clasificación exacta no es importante; lo importante es que entiendas qué proporciona el servicio y cuáles son tus responsabilidades).

Cuando llegas al Software como Servicio (comparado con cenar fuera en la Figura 1-7), parece que todo está hecho para ti. Pero no es así. Sigues teniendo la responsabilidad de comer con seguridad, y el restaurante no es responsable si te atragantas con la comida. En el mundo del SaaS, esto se reduce en gran medida a gestionar adecuadamente el control de acceso.

Si dibujamos el diagrama pero centrándonos en la tecnología en lugar de en la pizza, se parece más a la Figura 1-8.

Figura 1-8. Modelo de responsabilidad compartida en la nube

Por desgracia, la realidad de la computación en nube es un poco más complicada que comer pizza, por lo que hay algunas zonas grises. En la parte inferior del diagrama, las cosas son concretas (a menudo literalmente). El proveedor de la nube tiene toda la responsabilidad de la seguridad de la infraestructura física, que a menudo implica controles que van más allá de lo que muchas empresas pueden hacer razonablemente en sus instalaciones, como el acceso biométrico con medidas contra el acceso no autorizado, guardias de seguridad, barreras de losa a losa y controles similares para mantener al personal no autorizado fuera de las instalaciones físicas.

Asimismo, si el proveedor ofrece entornos virtualizados, los controles de seguridad de la infraestructura virtualizada que mantienen tu entorno virtual separado de otros entornos virtuales son responsabilidad del proveedor. Cuando las vulnerabilidades Spectre y Meltdown salieron a la luz a principios de 2018, uno de los efectos potenciales era que los usuarios de una máquina virtual podían leer la memoria de otra máquina virtual en el mismo ordenador físico. Para los clientes de IaaS, solucionar esa parte de la vulnerabilidad era responsabilidad del proveedor de la nube -Amazon, Microsoft, Google e IBM tuvieron que actualizar sus hipervisores, por ejemplo-, pero solucionar las vulnerabilidades del sistema operativo era responsabilidad del cliente.

La seguridad de la red se muestra como una responsabilidad compartida en la sección IaaS de la Figura 1-8. ¿Por qué? Es difícil mostrarlo en un diagrama, pero hay varias capas de red, y la responsabilidad de cada una recae en una parte diferente. El proveedor de la nube tiene su propia red que es su responsabilidad, pero normalmente hay una red virtual por encima (por ejemplo, algunos proveedores de nube ofrecen una nube privada virtual), y es responsabilidad del cliente dividirla en zonas de seguridad razonables y establecer las normas adecuadas para el acceso entre ellas. Muchas implementaciones también utilizan redes superpuestas, cortafuegos y cifrado de transporte que son responsabilidad del cliente. Esto se tratará en profundidad en el Capítulo 6.

La seguridad del sistema operativo suele ser sencilla: es tu responsabilidad si utilizas IaaS, y es responsabilidad del proveedor si adquieres servicios de plataforma o software. En general, si compras esos servicios, no tienes acceso al sistema operativo subyacente. (Como regla general, si tienes la capacidad de romperlo, normalmente tienes la responsabilidad de asegurarlo).

Middleware, en este contexto, es un nombre genérico para software como bases de datos, servidores de aplicaciones o sistemas de colas. Están en el medio, entre el sistema operativo y la aplicación, y no los utilizan directamente los usuarios finales, sino que se emplean para desarrollar soluciones para ellos. Si utilizas un PaaS, la seguridad del middleware suele ser una responsabilidad compartida; el proveedor puede mantener actualizado el software (o facilitarte las actualizaciones), pero tú sigues siendo responsable de los ajustes relevantes para la seguridad, comoel cifrado.

La capa de aplicación es la que utiliza realmente el usuario final. Si utilizas SaaS, las vulnerabilidades en esta capa (como el cross-site scripting o la inyección SQL) son responsabilidad del proveedor, pero si estás leyendo este libro probablemente no estés utilizando el SaaS de otro. Aunque todas las demás capas tengan una seguridad a prueba de balas, una vulnerabilidad en la capa de seguridad de la aplicación puede exponer fácilmente toda tu información.

Por último, la seguridad del acceso a los datos es casi siempre tu responsabilidad como cliente. Si indicas incorrectamente a tu proveedor de la nube que permita el acceso a datos concretos, como conceder permisos incorrectos de almacenamiento de objetos, permisos de middleware o permisos de SaaS, en realidad no hay mucho que el proveedor pueda hacer, aparte de intentar detectar el problema y avisarte.

La causa raíz de muchos incidentes de seguridad es la suposición de que el proveedor de la nube está gestionando algo, cuando resulta que nadie lo estaba gestionando. Muchos ejemplos del mundo real de incidentes de seguridad derivados de una mala comprensión del modelo de responsabilidad compartida proceden de cubos abiertos de Amazon Simple Storage Service (Amazon S3). Claro que el almacenamiento en S3 es seguro y está encriptado, pero nada de eso ayuda si no estableces correctamente los controles de acceso. Este malentendido ha causado la pérdida de:

• Datos de 198 millones de votantes estadounidenses

• Seguimiento automático de los registros de la empresa

• Registros inalámbricos de clientes

• Más de 3 millones de registros de encuestas demográficas

• Más de 50.000 informes de crédito de ciudadanos indios

• Más de 100.000 notas e información personal de estudiantes

• Miles de horas de grabaciones de audio y vídeo que contienenconversaciones privadas

Hay muchos más ejemplos. Aunque se han producido avances considerables, el modelo de responsabilidad compartida sigue siendo a menudo malinterpretado. Muchos responsables de TI siguen creyendo que los proveedores de nubes públicas son responsables de la seguridad no sólo de los servicios en la nube que ofrecen, sino también de las aplicaciones y los datos de los clientes en la nube. Si lees el acuerdo con tu proveedor de la nube, descubrirás que esto no es cierto.

Gestión de riesgos

La gestión de riesgos es un tema profundo, sobre el que se han escrito libros enteros. Si realmente te interesa profundizar, te recomiendo que leas El fracaso de la gestión de riesgos: Why It's Broken and How to Fix It, de Douglas W. Hubbard (Wiley, 2020), y la Publicación Especial 800-30 Rev 1 del NIST. En pocas palabras, los humanos somos realmente malos evaluando el riesgo y averiguando qué hacer al respecto. Esta sección pretende darte sólo lo esencial para gestionar el riesgo de incidentes de seguridad y violaciones de datos.

A riesgo de afirmar lo obvio, un riesgo es algo malo que podría ocurrir. En la mayoría de los sistemas de gestión de riesgos, el nivel de riesgo se basa en una combinación de lo probable que es que ocurra lo malo (probabilidad) y lo malo que será el resultado si ocurre (impacto). Por ejemplo, algo que es muy probable que ocurra (como que alguien adivine que tu contraseña es "1234") y que será muy malo si ocurre (como que pierdas todos los archivos de tus clientes y tengas que pagar grandes multas) sería un riesgo alto. Algo que es muy improbable que ocurra (como que un asteroide acabe con dos centros de datos regionales diferentes a la vez) pero que sería muy malo si ocurriera (quebrar el negocio) podría ser sólo un riesgo bajo, dependiendo del sistema que utilices para decidir el nivel de riesgo.⁵

En este libro, hablaré de riesgos desconocidos (de los que no tenemos suficiente información para saber cuáles son sus probabilidades e impactos) y de riesgos conocidos (de los que al menos sabemos a qué nos enfrentamos). Una vez que tengas una idea de los riesgos conocidos, puedes hacer una de estas cuatro cosas con ellos:

1. Evita el riesgo. En seguridad de la información, esto suele significar que apagas elsistema: no más riesgo, pero tampoco ninguno de los beneficios que obtuviste al poner en marcha el sistema en primer lugar.

2. Mitiga el riesgo. Sigue ahí, pero haces cosas adicionales para reducir la probabilidad de que ocurra lo malo o el impacto si ocurre. Por ejemplo, puedes optar por almacenar datos menos sensibles para que, si se produce una violación, el impacto no sea tan grave.

3. Transfiere el riesgo. Pagas a otro para que gestione las cosas, de modo que el riesgo sea su problema. Esto se hace mucho con la nube, donde transfieres muchos de los riesgos de gestionar los niveles inferiores del sistema al proveedor de la nube.

4. Acepta el riesgo. Tras analizar el nivel de riesgo global y los beneficios de continuar con la actividad, puedes decidir anotar que el riesgo existe, conseguir que todas las partes interesadas estén de acuerdo en que es un riesgo y seguir adelante.

Cualquiera de estas acciones puede ser razonable. Sin embargo, lo que no es aceptable es no tener ni idea de cuáles son tus riesgos, o tener una idea de cuáles son los riesgos y aceptarlos sin sopesar las consecuencias u obtener la aprobación de tus partes interesadas. Como mínimo, debes tener una lista en algún lugar de una hoja de cálculo o documento que detalle los riesgos que conoces, las acciones emprendidas y las aprobaciones necesarias.

Conclusión

Aunque a menudo no hay respuestas perfectas en el mundo real, comprender algunos conceptos básicos te ayudará a tomar mejores decisiones a la hora de proteger tus entornos en la nube.

El mínimo privilegio consiste básicamente en reconocer que dar acceso privilegiado a algo o a alguien es un riesgo, y no quieres correr más riesgos de los necesarios. Es un arte, por supuesto, porque a veces hay que elegir entre riesgo y productividad, pero el principio general es bueno: sólo hay que conceder el mínimo privilegio necesario. Esto a menudo se pasa por alto en la automatización, pero podría decirse que es aún más importante porque muchos ataques del mundo real se basan en engañar a un sistema o automatización para que realice acciones inesperadas.

La defensa en profundidad consiste en reconocer que no somos perfectos y que los sistemas que diseñamos no serán perfectos. También es un guiño a las leyes básicas de la probabilidad: si tienes dos cosas independientes que tienen que fallar ambas para que ocurra algo malo, es mucho menos probable que ocurra. Si tienes que lanzar una moneda al aire y sale cruz dos veces seguidas, tus probabilidades de que eso ocurra son sólo del 25%, en comparación con el 50% de probabilidades de que salga cruz al lanzar una moneda. Aspiramos a tener controles de seguridad mucho más eficaces que el lanzamiento de una moneda, pero el principio es el mismo. Si tienes dos controles superpuestos e independientes con una eficacia del 95%, ¡la combinación de ambos tendrá una eficacia del 99,75%! Sin embargo, este enfoque tiene rendimientos decrecientes, por lo que cinco o seis capas en la misma área probablemente no sean un buen uso de los recursos.

El modelado de amenazas es el proceso de comprender quién es probable que ataque tu sistema y por qué, y de comprender los componentes de tu sistema y cómo funcionan juntos. Con esas dos piezas de información, puedes mirar tu sistema a través de los ojos de los posibles atacantes, e intentar detectar las áreas en las que los atacantes podrían hacer algo indeseable. Luego, para cada una de esas áreas, puedes poner obstáculos (o, más formalmente, "controles" y "mitigaciones") para frustrar a los atacantes. En general, los lugares más eficaces para poner mitigaciones son los límites de confianza, que son los lugares donde una parte de tu sistema necesita confiar en otra.

Comprender los modelos de prestación de servicios en la nube puede ayudarte a centrarte en las partes del sistema general de las que eres responsable, para que no pierdas el tiempo intentando hacer el trabajo de tu proveedor de servicios en la nube, y para que no asumas que tu proveedor de servicios en la nube se está ocupando de algo que realmente es responsabilidad tuya. Aunque existen términos estandarizados para los distintos modelos de prestación de servicios en la nube, como IaaS, PaaS y SaaS, algunos servicios no encajan perfectamente en esos grupos. Sin embargo, son conceptualmente útiles, y lo más importante es entender dónde acaba la responsabilidad de tu proveedor y dónde empieza la tuya en el modelo de responsabilidad compartida en la nube. En un mundo local, la seguridad de todo el sistema será a menudo responsabilidad de una sola organización dentro de una empresa, mientras que en las Implementaciones en la nube, ¡casi siempre se divide entre al menos dos empresas diferentes!

Por último, aunque los humanos somos bastante buenos evaluando el riesgo en situaciones del tipo "¿me va a comer este depredador?", no somos naturalmente muy buenos en situaciones más abstractas. La gestión del riesgo es una disciplina que nos permite evaluar mejor el riesgo y averiguar qué hacer al respecto. La forma más sencilla de gestión del riesgo consiste en estimar la probabilidad de que ocurra algo malo y el impacto de lo malo que será si ocurre, y luego tomar decisiones basadas en la combinación de probabilidad e impacto. La gestión del riesgo puede reducir nuestro riesgo global permitiéndonos centrarnos primero en los riesgos mayores.

Ahora que tenemos estos conceptos y principios en nuestro kit de herramientas, pongámoslos en práctica para proteger los datos y otros activos de nuestros entornos en la nube.

Ejercicios

1. ¿Cuáles de estos son buenos ejemplos del principio del menor privilegio en acción? Selecciona todos los que corresponda.

   1. Tener diferentes niveles de acceso dentro de una aplicación, de forma que los usuarios sólo puedan acceder a las funciones que necesitan para su trabajo.

   2. Exigir tanto una contraseña como un segundo factor para iniciar sesión

   3. Dar a una herramienta de inventario acceso de sólo lectura en lugar de acceso de lectura/escritura

   4. Uso de una herramienta como sudo para permitir que un usuario sólo ejecute determinados comandos

2. ¿Cuáles de estos son buenos ejemplos del principio de defensa en profundidad? Selecciona todas las que correspondan.

   1. Cifrar datos valiosos, y también impedir que la gente lea los datos cifrados a menos que necesiten verlos

   2. Tener controles de cortafuegos muy estrictos

   3. Asegurarte de que tus límites de confianza están bien definidos

   4. Disponer de autenticación multifactor

3. ¿Cuáles son algunas de las motivaciones habituales de los actores de amenazas? Selecciona todas las que correspondan.

   1. Robar dinero

   2. Robar secretos

   3. Perturbar tu negocio

   4. Avergonzarte

4. ¿Cuál de estos elementos es siempre responsabilidad del proveedor de la nube?

   1. Seguridad de las infraestructuras físicas

   2. Seguridad de la red

   3. Seguridad del sistema operativo

   4. Seguridad de acceso a los datos

5. ¿Cuáles son los factores más importantes para evaluar la gravedad de un riesgo? Selecciona los dos que correspondan.

   1. Las posibilidades, o probabilidad, de que ocurra un acontecimiento

   2. Cómo de grave será el impacto si se produce un suceso

   3. Si puedes o no transferir el riesgo a otra persona

   4. Si las acciones que causan el riesgo son legales o ilegales

¹ Si esperas consejos sobre cómo elegir nombres de marketing pegadizos, ¡probablemente estés leyendo el libro equivocado!

² El Informe de Verizon sobre investigaciones de violaciones de datos es un excelente recurso gratuito para comprender los distintos tipos de ataques con éxito, organizado por sectores y métodos, y el resumen ejecutivo es muy legible.

³ Recomiendo Modelado de amenazas: Designing for Security, de Adam Shostack (Wiley, 2014).

⁴ Concepto original del artículo de LinkedIn de Albert Barron de 2014, "La pizza como servicio".

⁵ Los riesgos también pueden interactuar, o agregarse. Puede haber dos riesgos que tengan cada uno una probabilidad relativamente baja e impactos limitados, pero es probable que ocurran juntos, y los impactos pueden combinarse para ser más graves. Por ejemplo, el impacto de la caída de cualquiera de las líneas eléctricas de un par redundante puede ser insignificante, pero el impacto de la caída de ambas puede ser realmente grave. Esto suele ser difícil de prever; el apagón del aeropuerto de Atlanta en 2017 es un buen ejemplo.