Redes de Confianza Cero

Capítulo 1. Fundamentos de la Confianza Cero

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

En una época en la que la vigilancia de la red es omnipresente, nos resulta difícil saber en quién confiar. ¿Podemos confiar en que nuestro tráfico de Internet estará a salvo de escuchas? Desde luego que no. ¿Qué pasa con ese proveedor al que alquilaste la fibra? ¿O ese técnico contratado que estuvo ayer en tu centro de datos trabajando en el cableado?

Denunciantes como Edward Snowden y Mark Klein han revelado la tenacidad de las redes de espionaje respaldadas por el gobierno. El mundo quedó conmocionado al revelarse que habían conseguido entrar en los centros de datos de grandes organizaciones. Pero, ¿por qué? ¿No es exactamente lo que tú harías en su lugar? ¿Especialmente si supieras que el tráfico allí no estaría cifrado?

La suposición de que los sistemas y el tráfico dentro de un centro de datos son de confianza es errónea. Las redes modernas y los patrones de uso ya no se hacen eco de los que hacían que la defensa del perímetro tuviera sentido hace muchos años. Como resultado, moverse libremente dentro de una infraestructura "segura" es a menudo trivial una vez que un solo host o enlace ha sido comprometido.

La confianza cero pretende resolver los problemas inherentes a depositar nuestra confianza en la red. En su lugar, es posible asegurar la comunicación y el acceso a la red de forma tan eficaz que la seguridad física de la capa de transporte pueda despreciarse razonablemente. Huelga decir que se trata de un objetivo elevado. La buena noticia es que hoy en día tenemos una criptografía bastante buena y, con los sistemas de automatización adecuados, esta visión es realmente alcanzable.

¿Qué es una Red de Confianza Cero?

Una red de confianza cero se basa en cinco afirmaciones fundamentales:

• Siempre se supone que la red es hostil.
• En la red existen amenazas externas e internas en todo momento.
• La localidad de la red no es suficiente para decidir la confianza en una red.
• Cada dispositivo, usuario y flujo de red está autenticado y autorizado.
• Las políticas deben ser dinámicas y calcularse a partir de tantas fuentes de datos como sea posible.

La arquitectura de seguridad de red tradicional divide las distintas redes (o partes de una misma red) en zonas, contenidas por uno o varios cortafuegos. A cada zona se le concede cierto nivel de confianza, que determina los recursos de red a los que puede acceder. Este modelo proporciona una defensa en profundidad muy sólida. Por ejemplo, los recursos considerados más arriesgados, como los servidores web que dan a la Internet pública, se colocan en una zona de exclusión (a menudo denominada "DMZ"), donde el tráfico puede ser estrictamente monitorizado y controlado. Este enfoque da lugar a una arquitectura similar a algunas que hayas visto antes, como la que se muestra en la Figura 1-1.

Figura 1-1. Arquitectura tradicional de seguridad de la red

El modelo de confianza cero de da la vuelta a este diagrama. Colocar tapones en la red es un sólido paso adelante con respecto a los diseños de antaño, pero tiene carencias significativas en el panorama moderno de los ciberataques. Las desventajas son muchas:

• Falta de inspección del tráfico intrazona
• Falta de flexibilidad en la colocación del host (tanto física como lógica)
• Puntos únicos de fallo

Cabe señalar que, si se eliminan los requisitos de localización de la red, también desaparece la necesidad de las VPN. Una VPN (o red privada virtual) permite que un usuario se autentique para recibir una dirección IP en una red remota. A continuación, el tráfico se tuneliza desde el dispositivo hasta la red remota, donde se desencapsula y enruta. Es la mayor puerta trasera que nadie sospechaba.

Si, por el contrario, declaramos que la ubicación de la red no tiene valor, la VPN queda obsoleta de repente, junto con otras construcciones de red modernas. Por supuesto, este mandato exige llevar la aplicación de la ley lo más lejos posible del perímetro de la red, pero al mismo tiempo libera al núcleo de tal responsabilidad. Además, los cortafuegos de estado existen en todos los principales sistemas operativos, y los avances en conmutación y encaminamiento han abierto la oportunidad de instalar capacidades avanzadas en el perímetro. Todos estos avances se unen para llegar a una conclusión: es el momento adecuado para un cambio de paradigma.

Aprovechando la aplicación de políticas distribuidas y aplicando los principios de confianza cero, podemos producir un diseño similar al que se muestra en la Figura 1-2.

Figura 1-2. Arquitectura de confianza cero

Presentación del Plano de Control de Confianza Cero

El sistema de soporte de se conoce comoplano decontrol , mientras que casi todo lo demás se denominaplano de datos , que el plano de control coordina y configura. Las solicitudes de acceso a recursos protegidos se realizan primero a través del plano de control, donde tanto el dispositivo como el usuario deben autenticarse y autorizarse. En esta capa pueden aplicarse políticas detalladas, quizás basadas en el papel que se desempeña en la organización, la hora del día o el tipo de dispositivo. El acceso a recursos más seguros puede exigir además una autenticación más fuerte.

Una vez que el plano de control ha decidido que se permitirá la solicitud, configura dinámicamente el plano de datos para que acepte el tráfico de ese cliente (y sólo de ese cliente). Además, puede coordinar los detalles de un túnel encriptado entre el solicitante y el recurso. Esto puede incluir credenciales temporales de un solo uso, claves y números de puerto efímeros.

Aunque se pueden hacer algunas concesiones en cuanto a la solidez de estas medidas, la idea básica es que una fuente autorizada, o un tercero de confianza, tenga la capacidad de autentificar, autorizar y coordinar el acceso en tiempo real, basándose en una serie de datos.

Evolución del modelo de perímetro

La arquitectura tradicional de descrita en este libro suele denominarse modelo perimetral, por el enfoque de muro de castillo utilizado en seguridad física. Este enfoque protege los elementos sensibles construyendo líneas de defensa que un intruso debe penetrar antes de obtener acceso. Por desgracia, este enfoque es fundamentalmente erróneo en el contexto de las redes informáticas y ya no es suficiente. Para comprender plenamente el fallo, es útil recordar cómo se llegó al modelo actual.

Gestión del espacio global de direcciones IP

El viaje de que condujo al modelo perimetral comenzó con la asignación de direcciones. Las redes se conectaban a un ritmo cada vez mayor durante los primeros tiempos de Internet. Si no se conectaba a Internet (recuerda que Internet no era omnipresente en aquella época), se conectaba a otra unidad de negocio, a otra empresa o quizá a una red de investigación. Por supuesto, las direcciones IP deben ser únicas en cualquier red IP, y si los operadores de la red tuvieran la mala suerte de tener rangos solapados, tendrían mucho trabajo para cambiarlos todos. Si resulta que la red a la que te conectas es Internet, entonces tus direcciones deben ser únicas a nivel mundial. Así que está claro que aquí hace falta algo de coordinación.

La Autoridad de Asignación de Números de Internet (IANA), creada formalmente en 1998, es el organismo que hoy se encarga de esa coordinación. Antes de la creación de la IANA, esta responsabilidad corría a cargo de Jon Postel, que creó el mapa de Internet que se muestra en la Figura 1-3. Él era la fuente autorizada para los registros de propiedad de direcciones IP, y si querías garantizar que tus direcciones IP eran únicas en todo el mundo, debías registrarte con él. En aquella época, se animaba a todo el mundo a registrarse para obtener un espacio de direcciones IP, aunque la red que se registrara no fuera a estar conectada a Internet. Se partía de la base de que, aunque una red no estuviera conectada ahora, probablemente estaría conectada a otra red en algún momento en .

Figura 1-3. Mapa de los inicios de Internet creado por Jon Postel, fechado en febrero de 1982.

Nacimiento del espacio de direcciones IP privadas

A medida que crecía la adopción del IP a través de finales de los 80 y principios de los 90, el uso frívolo del espacio de direcciones se convirtió en una seria preocupación. Empezaron a surgir numerosos casos de redes realmente aisladas con grandes necesidades de espacio de direcciones IP. Las redes que conectaban los cajeros automáticos y las pantallas de llegadas y salidas de los grandes aeropuertos se citaron como ejemplos principales. Estas redes se consideraban verdaderamente aisladas por varias razones. Algunos dispositivos podían estar aislados para cumplir requisitos de seguridad o privacidad (por ejemplo, las redes destinadas a los cajeros automáticos). Algunos podían estar aislados porque el alcance de su función era tan limitado que tener un acceso más amplio a la red se consideraba muy poco probable (por ejemplo, las pantallas de llegadas y salidas de los aeropuertos). El RFC 1597, Address Allocation for Private Internets, se introdujo para resolver este problema de desperdicio de espacio de direcciones públicas.

En marzo de 1994, el RFC 1597 anunció que se habían reservado tres rangos de red IP con la IANA para uso general en redes privadas: 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. Esto tuvo el efecto de ralentizar el agotamiento de las direcciones al garantizar que el espacio de direcciones de las grandes redes privadas nunca creciera más allá de esas asignaciones. También permitió a los operadores de red utilizar direcciones no únicas globalmente donde y cuando lo consideraran oportuno. Tuvo otro efecto interesante, que perdura hoy en día: las redes que utilizaban direcciones privadas eran más seguras, porque eran fundamentalmente incapaces de unirse a otras redes, en particular a Internet.

En aquella época, muy pocas organizaciones (relativamente hablando) tenían conexión o presencia en Internet, por lo que las redes internas solían estar numeradas con los rangos reservados. Además, las medidas de seguridad eran de débiles a inexistentes porque estas redes solían estar confinadas por los muros de una sola organización.

Las redes privadas se conectan a las redes públicas

El número de cosas interesantes en Internet creció con bastante rapidez, y pronto la mayoría de las organizaciones quisieron tener al menos algún tipo de presencia. El correo electrónico fue uno de los primeros ejemplos de ello. La gente quería poder enviar y recibir correo electrónico, pero eso significaba que necesitaban un servidor de correo de acceso público, lo que por supuesto significaba que necesitaban conectarse a Internet de alguna manera.

En las redes privadas establecidas, solía ocurrir que este servidor de correo fuera el único servidor con conexión a Internet. Tendría una interfaz de red orientada a Internet y otra a la red interna. De este modo, los sistemas y las personas de la red privada interna podían enviar y recibir correo electrónico por Internet a través de su servidor de correo conectado.

Rápidamente nos dimos cuenta de que estos servidores habían abierto una ruta física de Internet a su red, que de otro modo sería segura y privada. Si uno de ellos quedaba comprometido, un atacante podría abrirse camino hasta la red privada, ya que los hosts de ésta podían comunicarse con él. Esta constatación provocó un escrutinio estricto de estos hosts y sus conexiones de red. Los operadores de red colocaron cortafuegos a ambos lados de ellos para restringir la comunicación y frustrar a los posibles atacantes que intentaran acceder a los sistemas internos desde Internet, como se muestra en la Figura 1-4. Con este paso nació el modelo perimetral. La red interna se convirtió en la red "segura", y la bolsa estrechamente controlada en la que se encontraban los hosts externos pasó a ser laDMZ, o zona desmilitarizada,de .

Figura 1-4. Tanto los recursos de Internet como los privados pueden acceder a los hosts de la DMZ; sin embargo, los recursos privados no pueden llegar más allá de la DMZ, por lo que no obtienen acceso directo a Internet

Nacimiento de NAT

El número de recursos de Internet a los que se deseaba acceder desde las redes internas crecía rápidamente, y enseguida resultó más fácil conceder acceso general a Internet a los recursos internos que mantener hosts intermediarios para cada aplicación deseada. NAT, otraducción de direcciones de red , resolvió este problema de forma muy satisfactoria.

ElRFC 1631, El Traductor de Direcciones de Red IP, define un estándar para un dispositivo de red capaz de realizar la traducción de direcciones IP en los límites de la organización. Al mantener una tabla que mapea IPs y puertos públicos a privados, permitía a los dispositivos de redes privadas acceder a recursos arbitrarios de Internet. Este mapeo ligero es independiente de la aplicación, lo que significa que los operadores de red ya no necesitan dar soporte a la conectividad a Internet para aplicaciones concretas; sólo necesitan dar soporte a la conectividad a Internet en general.

Estos dispositivos NAT tenían una propiedad interesante: como el mapeo de IP era de muchos a uno, no era posible que las conexiones entrantes de Internet accedieran a IP privadas internas sin configurar específicamente el NAT para gestionar este caso especial. De este modo, los dispositivos mostraban las mismas propiedades que un cortafuegos con estado. Los cortafuegos reales empezaron a integrar las funciones NAT casi instantáneamente, y ambas se convirtieron en una única función, en gran medida indistinguible. La compatibilidad con la red y los estrictos controles de seguridad hicieron que, con el tiempo, pudieras encontrar uno de estos dispositivos prácticamente en todos los límites de la organización, como se muestra en la Figura 1-5.

Figura 1-5. Diseño típico (y simplificado) de cortafuegos perimetral

El modelo de perímetro contemporáneo

Con un cortafuegos/dispositivo NAT entre la red interna e Internet, se forman claramente las zonas de seguridad. Está la zona "segura" interna, la DMZ (zona desmilitarizada), y la zona no fiable (también conocida como Internet). Si en algún momento del futuro, esta organización necesitara interconectarse con otra, se colocaría un dispositivo en ese límite de forma similar. Es probable que la organización vecina se convierta en una nueva zona de seguridad, con normas particulares sobre qué tipo de tráfico puede pasar de una a otra, al igual que la DMZ o la zona segura.

Echando la vista atrás, se puede ver la progresión. Pasamos de redes offline/privadas con sólo uno o dos hosts con acceso a Internet a redes altamente interconectadas con dispositivos de seguridad en todo el perímetro. No es difícil de entender: los operadores de red no pueden permitirse sacrificar la perfecta seguridad de su red offline porque tenían que abrir puertas para diversos fines empresariales. Los estrictos controles de seguridad en cada puerta minimizaron el riesgo de .

Evolución del panorama de amenazas

Incluso en , antes de que existiera la Internet pública, era muy conveniente comunicarse con un sistema informático remoto. Esto se hacía habitualmente a través del sistema telefónico público. Los usuarios y los sistemas informáticos podían marcar y, mediante la codificación de datos en tonos audibles, obtener conectividad con la máquina remota. Estas interfaces de acceso telefónico eran el vector de ataque más común de la época, ya que obtener acceso físico era mucho más difícil.

Una vez que las organizaciones tuvieron hosts conectados a Internet, los ataques pasaron de producirse a través de la red telefónica a lanzarse a través de Internet. Esto provocó un cambio en la dinámica de la mayoría de los ataques. Las llamadas entrantes a interfaces de acceso telefónico ocupaban una línea telefónica, y eran un hecho notable si se comparaban con una conexión TCP procedente de Internet. Era mucho más fácil tener una presencia encubierta en una red IP que en un sistema al que había que marcar. Los intentos de explotación y fuerza bruta podían llevarse a cabo durante largos periodos de tiempo sin levantar demasiadas sospechas... aunque de este cambio surgió una capacidad adicional y más impactante: el código malicioso podía entonces escuchar el tráfico de Internet.

A finales de los 90, los primeros caballos de Troya (software) del mundo habían empezado a hacer sus rondas. Normalmente, se engañaba a un usuario para que instalara el malware, que abría un puerto y esperaba conexiones entrantes. El atacante podía entonces conectarse al puerto abierto y controlar remotamente la máquina objetivo.

No pasó mucho tiempo antes de que la gente se diera cuenta de que sería una buena idea proteger esos hosts orientados a Internet. Los cortafuegos de hardware eran la mejor forma de hacerlo (la mayoría de los sistemas operativos no tenían entonces el concepto de cortafuegos basado en host). Hacían cumplir las políticas, garantizando que sólo se permitiera la entrada de tráfico "seguro" de la lista blanca desde Internet. Si un administrador instalaba inadvertidamente algo que dejaba al descubierto un puerto abierto (como un troyano), el cortafuegos bloqueaba físicamente las conexiones a ese puerto hasta que se configurara explícitamente para permitirlas. Del mismo modo, se podía controlar el tráfico a los servidores orientados a Internet desde el interior de la red, garantizando que los usuarios internos pudieran hablar con ellos, pero no viceversa. Esto ayudó a evitar la entrada en la red interna de un host DMZ potencialmente comprometido.

Los hosts DMZ eran, por supuesto, un objetivo principal (debido a su conectividad), aunque estos controles tan estrictos sobre el tráfico entrante y saliente dificultaban el acceso a una red interna a través de una DMZ. Un atacante tendría primero que comprometer el servidor con firewall, y luego abusar de la aplicación de forma que pudiera utilizarse para una comunicación encubierta (al fin y al cabo, necesitan sacar datos de esa red). Las interfaces de acceso telefónico seguían siendo la fruta más fácil de conseguir si se quería acceder a una red interna.

Aquí es donde las cosas tomaron un giro interesante. Se introdujo NAT para conceder acceso a Internet a los clientes de las redes internas. Debido en parte a la mecánica de NAT y en parte a verdaderos problemas de seguridad, seguía existiendo un estricto control del tráfico entrante, aunque los recursos internos que deseaban consumir recursos externos podían hacerlo libremente. Hay que hacer una distinción importante al considerar una red con acceso NAT a Internet frente a una red sin él: la primera tiene una política de red saliente relajada (si es que tiene alguna).

Esto transformó significativamente el modelo de seguridad de la red. Los servidores de las redes internas "fiables" podían comunicarse directamente con servidores de Internet no fiables, y el servidor no fiable estaba de repente en posición de abusar del cliente que intentara hablar con él. Peor aún, un código malicioso podía enviar mensajes a hosts de Internet desde la red interna. Hoy conocemos esto como llamando a casa.

Llamar a casa es un componente crítico de la mayoría de los ataques modernos. Permite que se exfiltren datos de redes que, de otro modo, estarían protegidas; pero lo más importante es que, como TCP es bidireccional, también permite que se inyecten datos.

Un ataque típico implica varios pasos, como se muestra en la Figura 1-6. En primer lugar, el atacante compromete un único ordenador de la red interna explotando el navegador del usuario cuando visita una página concreta, enviándole un correo electrónico con un archivo adjunto que explota algún software local, por ejemplo. El exploit lleva una carga útil muy pequeña, sólo el código suficiente para establecer una conexión con un host remoto de Internet y ejecutar el código que recibe en la respuesta. Esta carga útil se conoce a veces comomarcador .

El dialer descarga e instala el malware real, que la mayoría de las veces intentará establecer una conexión adicional con un host remoto de Internet controlado por el atacante. El atacante utilizará esta conexión para enviar comandos al malware, exfiltrar datos sensibles o incluso obtener una sesión interactiva. Este "paciente cero" de puede actuar como trampolín, dando al atacante un host en la red interna desde el que lanzar ataques adicionales.

Figura 1-6. El cliente inicia todas las conexiones relacionadas con el ataque, atravesando fácilmente los cortafuegos perimetrales con una seguridad de salida relajada

Seguridad de salida

La seguridad de la red saliente es una medida de mitigación muy eficaz contra los ataques basados en dialers, ya que el teléfono de origen puede detectarse y/o bloquearse. A menudo, sin embargo, el phone home se disfraza de tráfico web normal, posiblemente incluso hacia redes aparentemente benignas o "normales". Una seguridad de salida lo suficientemente estricta como para detener estos ataques a menudo paralizará la usabilidad de la web para los usuarios. Esta es una perspectiva más realista para los sistemas de back-office.

La capacidad de lanzar ataques desde hosts dentro de una red interna es muy poderosa. Es casi seguro que estos hosts tienen permiso para hablar con otros hosts de la misma zona de seguridad (movimiento lateral) e incluso podrían tener acceso para hablar con hosts de zonas más seguras que la suya. En este sentido, comprometiendo primero una zona de baja seguridad de la red interna, un atacante puede moverse por la red, consiguiendo finalmente acceder a las zonas de alta seguridad.

Dando un paso atrás por un momento en , puede verse que este patrón socava muy eficazmente el modelo de seguridad perimetral. El fallo crítico que permite la progresión de los ataques es sutil, pero claro: las políticas de seguridad se definen por zonas de red, se aplican sólo en los límites de la zona, sin utilizar nada más que los detalles de origen y destino .

Deficiencias del perímetro

Incluso aunque el modelo de seguridad perimetral sigue siendo el más prevalente con diferencia, es cada vez más evidente que la forma en que confiamos en él es defectuosa. Todos los días se producen ataques complejos (y con éxito) contra redes con una seguridad perimetral perfectamente buena. Un atacante introduce una herramienta de acceso remoto (o RAT) en tu red a través de una miríada de métodos, obtiene acceso remoto y comienza a moverse lateralmente. Los cortafuegos perimetrales se han convertido en el equivalente funcional de construir un muro alrededor de una ciudad para mantener alejados a los espías.

El problema surge cuando se integran zonas de seguridad en la propia red. Imagina el siguiente escenario: diriges una pequeña empresa de comercio electrónico. Tienes algunos empleados, algunos sistemas internos (nóminas, inventario, etc.) y algunos servidores para alimentar tu sitio web. Es natural empezar a clasificar el tipo de acceso que pueden necesitar estos grupos: los empleados necesitan acceso a los sistemas internos, los servidores web necesitan acceso a los servidores de bases de datos, los servidores de bases de datos no necesitan acceso a Internet pero los empleados sí, etc. La seguridad de red tradicional codificaría estos grupos como zonas y luego definiría qué zona puede acceder a qué, como se muestra en la Figura 1-7. Por supuesto, tienes que aplicar realmente estas políticas; y como se definen zona por zona, tiene sentido aplicarlas siempre que una zona pueda dirigir tráfico a otra.

Como puedes imaginar, siempre hay excepciones a estas reglas generalizadas... de hecho, se conocen coloquialmente comoexcepciones del cortafuegos . Estas excepciones suelen tener un alcance lo más restringido posible. Por ejemplo, tu desarrollador web podría querer acceso SSH a los servidores web de producción, o tu representante de RRHH podría necesitar acceso a la base de datos del software de RRHH para realizar auditorías. En estos casos, un enfoque aceptable es configurar una excepción de cortafuegos que permita el tráfico desde la dirección IP de esa persona al servidor o servidores concretos en cuestión.

Ahora imaginemos que tu archienemigo ha contratado a un equipo de hackers. Quieren echar un vistazo a tus cifras de inventario y ventas. Los hackers envían correos electrónicos a todas las direcciones de correo electrónico de los empleados que encuentran en Internet, haciéndose pasar por un código de descuento para un restaurante cercano a la oficina. Efectivamente, uno de ellos hace clic en el enlace, lo que permite a los atacantes instalar malware. El malware llama a casa y proporciona a los atacantes una sesión en la máquina del empleado ahora comprometido. Por suerte, sólo se trata de un interno, y el nivel de acceso que obtienen es limitado.

Figura 1-7. Red corporativa interactuando con la red de producción

Empiezan a buscar en la red y descubren que la empresa utiliza software de intercambio de archivos en su red. De todos los ordenadores de los empleados de la red, ninguno tiene la última versión y son vulnerables a un ataque que se hizo público recientemente. Uno a uno, los hackers empiezan a buscar un ordenador con acceso elevado (por supuesto, este proceso puede ser más selectivo si el atacante tiene conocimientos avanzados). Finalmente dan con la máquina de tu desarrollador web. Un keylogger que instalan allí recupera las credenciales para iniciar sesión en el servidor web. Se conectan mediante SSH al servidor utilizando las credenciales que han obtenido; y utilizando los derechos sudo del desarrollador web, leen la contraseña de la base de datos del disco y se conectan a la base de datos. Vuelcan el contenido de la base de datos, lo descargan y borran todos los archivos de registro. Si tienes suerte, puede que descubras que se ha producido esta brecha. Han cumplido su misión, como se muestra en la Figura 1-8.

Espera, ¿qué? Como puedes ver, muchos fallos a muchos niveles condujeron a esta brecha, y aunque puedas pensar que se trata de un caso especialmente artificioso, los ataques exitosos como éste son asombrosamente comunes. Sin embargo, la parte más sorprendente pasa desapercibida con demasiada frecuencia: ¿qué ocurrió con toda esa seguridad de la red? Los cortafuegos estaban meticulosamente colocados, las políticas y las excepciones estaban estrechamente delimitadas y muy limitadas, todo se había hecho bien desde el punto de vista de la seguridad de la red. Entonces, ¿qué ocurre?

Figura 1-8. Movimiento del atacante hacia la red de la empresa, y posterior producción en la red

Ejemplo de progresión de ataque

1. Empleados víctimas de phishing por correo electrónico
2. Máquina corporativa comprometida, cáscara paleada
3. Movimiento lateral a través de la red corporativa
4. Puesto de trabajo privilegiado localizado
5. Escalada de privilegios local en estación de trabajo-keylogger instalado
6. Contraseña de desarrollador robada
7. Comprometido el host de la aplicación de producción desde una estación de trabajo privilegiada
8. Contraseña de desarrollador utilizada para elevar privilegios en el host de la aplicación prod
9. Robo de credenciales de base de datos de una aplicación
10. Exfiltración del contenido de la base de datos a través de una aplicación comprometida

Cuando se examina detenidamente, resulta abrumadoramente obvio que este modelo de seguridad de red no es suficiente. Eludir la seguridad del perímetro es trivial con programas maliciosos que llaman a casa, y los cortafuegos entre zonas no tienen en cuenta más que el origen y el destino a la hora de tomar decisiones de aplicación. Aunque los perímetros pueden seguir aportando cierto valor a la seguridad de la red, su papel como mecanismo principal por el que se define la postura de seguridad de una red debe reconsiderarse .

El primer paso, por supuesto, es buscar las soluciones existentes. Seguro que el modelo perimetral es el enfoque aceptado para asegurar una red, pero eso no significa que no hayamos aprendido cosas mejores en otros lugares. ¿Cuál es el peor escenario posible para la seguridad de la red? Resulta que en realidad hay un nivel de absoluto en esta pregunta, y el quid de la cuestión reside en la confianza de .

Dónde reside la confianza

Cuando considera opciones más allá del modelo perimetral, hay que tener una comprensión firme de lo que es de confianza y lo que no lo es. El nivel de confianza define un límite inferior en la robustez de los protocolos de seguridad necesarios. Desgraciadamente, es raro que la robustez supere lo necesario, por lo que conviene confiar lo menos posible. Una vez que la confianza se incorpora a un sistema, puede ser muy difícil eliminarla.

Una red de confianza cero es tal como suena. Es una red en la que no se confía en absoluto. Por suerte para nosotros, interactuamos con una red así con mucha frecuencia: Internet.

Internet nos ha enseñado algunas valiosas lecciones de seguridad. Sin duda, un operador asegurará un servidor orientado a Internet de forma muy distinta a como asegura su homólogo accesible localmente. ¿Por qué? Y si los dolores asociados a tal rigor se curasen (o incluso sólo disminuyesen), ¿seguiría mereciendo la pena el sacrificio de seguridad?

El modelo de confianza cero dicta que todos los hosts sean tratados como si estuvieran orientados a Internet. Las redes en las que residen deben considerarse comprometidas y hostiles. Sólo con esta consideración puedes empezar a construir una comunicación segura. Dado que la mayoría de los operadores han construido o mantenido sistemas orientados a Internet en el pasado, tenemos al menos alguna idea de cómo asegurar la IP de forma que sea difícil interceptarla o manipularla (y, por supuesto, cómo asegurar esos hosts). La automatización nos permite extender este nivel de seguridad a todos los sistemas de nuestra infraestructura.

La automatización como facilitadora

Las redes de confianza cero de no requieren nuevos protocolos o bibliotecas. Sin embargo, utilizan tecnologías existentes de formas novedosas. Los sistemas de automatización son los que permiten construir y hacer funcionar una red de confianza cero.

Las interacciones entre el plano de control de y el plano de datos de son los puntos más críticos que requieren automatización. Si la aplicación de las políticas no puede actualizarse dinámicamente, la confianza cero será inalcanzable; por eso es fundamental que este proceso sea automático y rápido.

Hay muchas formas de realizar esta automatización. Los sistemas creados a propósito son los más ideales, aunque otros más mundanos, como la gestión de la configuración tradicional, también pueden encajar aquí. La adopción generalizada de la gestión de la configuración representa un paso importante para una red de confianza cero, ya que estos sistemas suelen mantener inventarios de dispositivos y son capaces de automatizar la configuración de la aplicación de la red en el plano de datos.

Debido a que los sistemas modernos de gestión de la configuración pueden tanto mantener un inventario de dispositivos como automatizar la configuración del plano de datos, están bien posicionados para ser un primer paso hacia una red madura de confianza cero.

Perímetro frente a confianza cero

Los modelos de perímetro y de confianza cero son fundamentalmente diferentes entre sí. El modelo perimetral intenta construir un muro entre los recursos de confianza y los que no lo son (es decir, la red local e Internet). Por otro lado, el modelo de confianza cero básicamente tira la toalla y acepta la realidad de que los "malos" están en todas partes. En lugar de construir muros para proteger a los cuerpos blandos que hay dentro, convierte a toda la población en una milicia.

Los enfoques actuales de las redes perimetrales asignan cierto nivel de confianza a las redes protegidas. Esta noción viola el modelo de confianza cero y conduce a algunos malos comportamientos. Los operadores tienden a bajar un poco la guardia cuando la red es "de confianza" ( son humanos). Rara vez los hosts que comparten una zona de confianza están protegidos de sí mismos. Compartir una zona de confianza, después de todo, parece implicar que son igualmente de confianza. Con el tiempo, hemos aprendido que esta suposición es falsa, y que no sólo es necesario proteger a tus servidores del exterior, sino también protegerlos unos de otros.

Como el modelo de confianza cero asume que la red está totalmente comprometida, también debes asumir que un atacante puede comunicarse utilizando cualquier dirección IP arbitraria. Por tanto, proteger los recursos utilizando direcciones IP o la ubicación física como identificador no es suficiente. Todos los hosts, incluso los que comparten "zonas de confianza", deben proporcionar una identificación adecuada. Sin embargo, los atacantes no se limitan a los ataques activos. Todavía pueden realizar ataques pasivos en los que husmean tu tráfico en busca de información sensible. En este caso, ni siquiera la identificación del host es suficiente: también se requiere un cifrado fuerte.

Existen tres componentes clave en una red de confianza cero: autenticación de usuarios/aplicaciones, autenticación de dispositivos y confianza. El primer componente tiene cierta dualidad debido a que no todas las acciones las realizan los usuarios. Así que en el caso de una acción automatizada (dentro del centro de datos, por ejemplo), nos fijamos en las cualidades de la aplicación del mismo modo que normalmente nos fijaríamos en las cualidades del usuario.

Autenticar y autorizar el dispositivo es tan importante como hacerlo para el usuario/aplicación. Se trata de una función que rara vez se ve en servicios y recursos protegidos por redes perimetrales. A menudo se implementa mediante la tecnología VPN o NAC de , sobre todo en las redes más maduras, pero encontrarla entre puntos finales (en contraposición a los intermediarios de la red) es poco común.

NAC como tecnología perimetral

NAC, o Control de Acceso a la Red, representa un conjunto de tecnologías diseñadas para autenticar fuertemente los dispositivos con el fin de obtener acceso a una red sensible. Estas tecnologías, que incluyen protocolos como 802.1X y la familia Trusted Network Connect (TNC) , se centran en la admisión a una red más que en la admisión a un servicio y, como tales, son independientes del modelo de confianza cero. Un enfoque más coherente con el modelo de confianza cero implicaría comprobaciones similares lo más cerca posible del servicio al que se accede (algo que TNC puede abordar -más sobre esto en el Capítulo 5). Aunque la NAC puede seguir empleándose en una red de confianza cero, no cumple el requisito de autenticación del dispositivo de confianza cero debido a su distancia del punto final remoto.

Por último, se calcula una "puntuación de confianza" , y la solicitud, el dispositivo y la puntuación se unen para formar un agente. A continuación, se aplica la política contra el agente para autorizar la solicitud. La riqueza de la información contenida en el agente permite un control de acceso muy flexible pero de grano fino, que puede adaptarse a condiciones variables incluyendo el componente de puntuación en tus políticas.

Si la solicitud está autorizada, el plano de control indica al plano de datos que acepte la solicitud entrante. Esta acción también puede configurar los detalles del cifrado. La encriptación puede aplicarse a nivel de dispositivo, a nivel de aplicación, o a ambos. Se requiere al menos uno para la confidencialidad.

Con estos componentes de autenticación/autorización, y la ayuda del plano de control en la coordinación de los canales cifrados, podemos afirmar que cada flujo de la red está autenticado y es esperado. Los hosts y los dispositivos de red descartan el tráfico al que no se le han aplicado todos estos componentes, garantizando que nunca puedan filtrarse datos sensibles. Además, al registrar cada uno de los eventos y acciones del plano de control, el tráfico de la red puede auditarse fácilmente flujo a flujo o petición a petición.

Se pueden encontrar redes perimetrales que tienen una capacidad similar, aunque estas capacidades sólo se aplican en el perímetro. Es famoso que las VPN intentan proporcionar estas cualidades para asegurar el acceso a una red interna, pero la seguridad termina en cuanto tu tráfico llega a un concentrador VPN. Es evidente que los operadores saben cómo debe ser una seguridad fuerte en Internet; sólo que no aplican esas medidas fuertes en todo el perímetro.

Si se puede imaginar una red que aplique estas medidas de forma homogénea, un breve experimento mental puede arrojar mucha luz sobre este nuevo paradigma. La identidad puede probarse criptográficamente, lo que significa que ya no importa de qué dirección IP procede una conexión determinada (técnicamente, aún puedes asociarle un riesgo; hablaremos de ello más adelante). Con la automatización de , que elimina las barreras técnicas, la VPN ha quedado básicamente obsoleta. Las redes "privadas" ya no significan nada especial: los hosts que allí se encuentran están tan reforzados como los de Internet. Pensando críticamente sobre NAT y el espacio de direcciones privado, quizá la confianza cero haga más evidente que los argumentos de seguridad a su favor son nulos.

En última instancia, el fallo del modelo perimetral es la falta de protección y aplicación universales. Celdas seguras con cuerpos blandos dentro. Lo que realmente buscamos son cuerpos duros, cuerpos que sepan comprobar identificaciones y hablar de forma que no puedan ser escuchados. Tener cuerpos duros no te impide necesariamente mantener también las células de seguridad. En instalaciones muy sensibles, esto seguiría siendo recomendable. Sin embargo, eleva el listón de seguridad lo suficiente como para que no sea descabellado disminuir o eliminar esas células. Combinado con el hecho de que la mayor parte de la función de confianza cero puede hacerse con transparencia para el usuario final, el modelo casi parece violar el compromiso seguridad/conveniencia: mayor seguridad, mayor conveniencia. Tal vez el problema de la comodidad (o la falta de ella) se haya trasladado a los operadores de .

Aplicado en la nube

Hay muchos retos en la implementación de infraestructuras en la nube, y uno de los mayores es la seguridad. La confianza cero encaja perfectamente en las Implementaciones en la nube por una razón obvia: ¡no puedes confiar en la red de una nube pública! La capacidad de autenticar y asegurar la comunicación sin depender de las direcciones IP o de la seguridad de la red que las conecta significa que los recursos informáticos pueden ser casi comoditizados.

Como la confianza cero defiende que cada paquete esté cifrado, incluso dentro del mismo centro de datos, los operadores no tienen que preocuparse de qué paquetes atraviesan Internet y cuáles no. A menudo se subestima esta ventaja. La carga cognitiva asociada a cuándo, dónde y cómo encriptar el tráfico puede ser bastante grande, sobre todo para los desarrolladores, que pueden no entender del todo el sistema subyacente. Al eliminar los casos especiales, también podemos eliminar el error humano asociado a ellos.

Algunos podrían argumentar que el cifrado intracentro de datos es una exageración, incluso con la reducción de la carga cognitiva. La historia ha demostrado lo contrario. En los grandes proveedores de la nube, como AWS, una única "región" consta de muchos centros de datos, con enlaces de fibra entre ellos. Para el usuario final, esta sutileza suele estar ofuscada. La NSA apuntaba precisamente a enlaces como éstos en 2013, y a enlaces troncales de Internet incluso antes, en salas como la que se muestra en la Figura 1-9.

Figura 1-9. Sala 641A-Instalación de interceptación de la NSA dentro de un centro de datos de AT&T en San Francisco

Además, existen riesgos en la implementación de red del propio proveedor. No es imposible pensar que pueda existir una vulnerabilidad en la que los vecinos puedan ver tu tráfico. Un caso más probable es que los operadores de red inspeccionen el tráfico mientras solucionan problemas. Tal vez el operador sea honesto, pero ¿qué hay de la persona que robó su portátil unas horas más tarde con tus capturas en el disco? La desafortunada realidad es que ya no podemos dar por sentado que nuestro tráfico está protegido del fisgoneo o la modificación mientras se encuentra en el centro de datos de .

Resumen

Este capítulo de ha explorado los conceptos de alto nivel que nos han llevado hacia el modelo de confianza cero. El modelo de confianza cero acaba con el modelo perimetral, que intenta garantizar que los malos actores permanezcan fuera de la red interna de confianza. En su lugar, el sistema de confianza cero reconoce que este enfoque está condenado al fracaso y, como resultado, parte del supuesto de que los actores maliciosos están dentro de la red interna y construye mecanismos de seguridad para protegerse de esta amenaza.

Para entender mejor por qué nos está fallando el modelo perimetral de , repasamos cómo surgió el modelo perimetral. En los inicios de Internet, la red era totalmente enrutable. A medida que el sistema evolucionaba, algunos usuarios identificaron zonas de la red que no tenían una razón creíble para ser enrutables en Internet, y así nació el concepto de red privada. Con el tiempo, esta idea arraigó, y las organizaciones modelaron su seguridad en torno a la protección de la red privada de confianza. Por desgracia, estas redes privadas no están ni de lejos tan aisladas como lo estaban las redes privadas originales. El resultado final es un perímetro muy poroso, que se vulnera con frecuencia en incidentes de seguridad habituales.

Con la comprensión compartida de las redes perimetrales, podemos contrastar ese diseño con el de confianza cero. El modelo de confianza cero gestiona cuidadosamente la confianza en el sistema. Este tipo de redes se apoyan en la automatización para gestionar de forma realista los sistemas de control de seguridad que nos permiten crear un sistema más dinámico y reforzado. Hemos introducido algunos conceptos clave, como la autenticación de usuarios, dispositivos y aplicaciones, y la autorización de la combinación de esos componentes. Trataremos estos conceptos con más detalle a lo largo del resto del libro.

Por último, hablamos de cómo el paso a entornos de nube pública y la omnipresencia de la conectividad a Internet han cambiado fundamentalmente el panorama de las amenazas. Las redes "internas" son ahora cada vez más compartidas y están lo suficientemente abstraídas como para que los usuarios finales no tengan una comprensión tan clara de cuándo sus datos están transitando por enlaces de red de larga distancia más vulnerables. El resultado final de este cambio es que la seguridad de los datos es más importante que nunca a la hora de construir nuevos sistemas.

El próximo capítulo tratará de los conceptos de alto nivel que hay que comprender para construir sistemas que puedan gestionar la confianza de forma segura.