Por qué la nube híbrida no debería ser igual a la seguridad híbrida

Las telas de redes de nube híbrida resuelven muchos desafíos en las redes empresariales de hoy en día. Permiten la creación de una única arquitectura de red, que se abstrae por encima de los entornos de data center subyacentes. También permiten tolerancia a fallas, resiliencia, servicios “elásticos” en todos los centros de datos y una topología de red que no depende de ningún proveedor de red subyacente. Una empresa puede administrar múltiples entornos de red física, pero ¿pueden crear una estructura de red única en todos ellos?

Por ejemplo, una empresa puede mantener centros de datos duales (uno primario y otro para recuperación ante desastres), además de múltiples implementaciones de nube pública en AWS, Azure y/o GCP. Cada uno de estos entornos de hosting implementa sus propias arquitecturas de red físicas subyacentes con sus propias tecnologías específicas, a menudo con diferentes proveedores de routing y switching.

Pero con el advenimiento de Redes definidas por software (SDN) en toda la industria de redes, la mayoría de los proveedores de redes de hoy en día pueden crear su propia “nube”. En terminología de redes, una nube es esencialmente una red virtual, una donde la topología de red se abstrae por encima de la topología física, a menudo llamada “red superpuesta”. Y una red superpuesta es esencialmente una colección de túneles, todos administrados por un controlador SDN central. Esta nube puede crear una estructura de red única y unificada en todos los entornos de hospedaje administrado.

Un protocolo de tunelización, como VXLAN, se utiliza para crear la topología de red superpuesta, de modo que la ruta del tráfico se determina por la forma en que se implementan estos túneles en lugar de cómo se implementa la topología física subyacente. Todos los proveedores de redes utilizan términos diferentes para describir su enfoque basado en SDN para permitir esto, pero al final del día, básicamente todos están haciendo lo mismo: usar túneles para crear una red superpuesta que es automatizada y administrada por un controlador central.

Si bien muchos de estos proveedores tienen la capacidad de extender las redes superpuestos desde centros de datos locales hasta proveedores de nube pública, la realidad es que muchas empresas solo implementan redes superpuestos localmente en sus centros de datos locales.

En lugar de extender su solución SDN local a la nube pública (por ejemplo, extender su topología de red tunelizada a AWS o Azure), muchas empresas crean entornos administrados localmente en sus instancias de nube pública y administran estas redes de manera diferente a la forma en que administran sus redes de centros de datos locales. A menudo optan por utilizar los enfoques de red que ya se utilizan en cada proveedor de nube pública, como VPC en AWS y VNet en Azure, y luego administrar las soluciones SDN en sus centros de datos locales de manera diferente.

El resultado es una implementación de red en la nube híbrida que se administra en un enfoque de “silla giratoria”. El administrador de red girará su silla de un lado a otro entre las herramientas utilizadas para administrar su centro de datos on-prem y otras herramientas utilizadas para administrar sus redes de nube pública. El término nube híbrida a menudo implica una arquitectura única y unificada, que a menudo no es precisa cuando se trata de operaciones.

Protección de su entorno híbrido

Este enfoque fragmentado de la administración de redes es especialmente cierto para la seguridad en una nube híbrida. Así como las herramientas de red administradas localmente se utilizan en cada entorno en centros de datos locales y nubes públicas, lo mismo ocurre con las soluciones de seguridad. La mayoría de los proveedores de redes SDN tienen sus propias herramientas de seguridad básicas e integradas que se pueden utilizar para permitir cierto nivel de aplicación de políticas en su entorno administrado localmente. Y todos los principales proveedores de nube pública tienen sus propias soluciones de seguridad, lo que también permite niveles básicos de aplicación de políticas.

Pero, desafortunadamente, estas herramientas de seguridad están en silos en la arquitectura general. Cada solución de seguridad no funciona bien en el sandbox con otras, y correlacionar una brecha de seguridad entre todas ellas es una tarea engorrosa que introduce grandes retrasos en la resolución.

Además, si las cargas de trabajo se migran en vivo entre entornos, como entre un centro de datos in situ y una instancia de nube pública, la aplicación de políticas generalmente no va a seguir esa carga de trabajo hasta su destino. Esto da como resultado la necesidad de enfoques manuales para transferir de alguna manera la política entre las herramientas de seguridad en cada entorno o depender de una solución SIEM para alimentar la información de todos los entornos, lo que requiere una gran cantidad de trabajo de scripting inicial.

Debido a la complejidad operacional, estos pasos simplemente no se realizan con frecuencia, lo que resulta en brechas significativas en la seguridad y la visibilidad de la carga de trabajo en toda la nube híbrida.

En lugar de confiar en las herramientas de seguridad nativas y en silos en cada entorno de red en una nube híbrida para imponer la seguridad de sus cargas de trabajo, ¿por qué no simplemente imponer la seguridad y la visibilidad directamente en la carga de trabajo, abstraídas de las herramientas de red subyacentes?

De manera similar a cómo las redes superpuestas crean topologías que se abstraen por encima de las dependencias en los routers y switches subyacentes, ¿por qué no aplicar el mismo enfoque a la seguridad? La seguridad también debe abstraerse (virtualizarse) de las dependencias subyacentes de la estructura de red y habilitarse directamente en la carga de trabajo, independientemente de dónde se aloje esa carga de trabajo o a dónde migre en vivo durante su ciclo de vida. De manera similar a la forma en que las redes superpuestas permiten un enfoque consistente para las redes en una nube híbrida, la seguridad debe diseñarse de la misma manera.

Cómo puede ayudar la microsegmentación

En Illumino, aplicamos seguridad (microsegmentación) directamente en cada carga de trabajo en toda una nube híbrida. Dado que la política de microsegmentación debe aplicarse lo más cerca posible de la entidad que está tratando de proteger, implementamos un agente ligero en cada carga de trabajo, virtual o bare-metal:

• Este agente no está conectado a ningún tráfico. Simplemente reside en segundo plano y monitorea el comportamiento de las aplicaciones directamente en la carga de trabajo.
• A continuación, la información se envía de vuelta al Motor de computación de políticas (PCE) para permitir una visibilidad clara del comportamiento entre todas las cargas de trabajo, independientemente de dónde estén alojadas o de qué entornos de red migren en vivo. Esencialmente, virtualizamos la seguridad, abstraída de las dependencias de red subyacentes.
• El PCE central utiliza etiquetas simples para definir lo que debe segmentarse, ya que la definición de políticas contra direcciones IP no escala en arquitecturas donde las cargas de trabajo migran dinámicamente en vivo y las direcciones IP cambian.

Si bien el PCE crea una arquitectura de seguridad virtualizada, también puede “llegar” a la capa de red y configurar listas de acceso a switches de hardware en un data center local, si es necesario. Por lo tanto, mientras que la seguridad se virtualiza y abstrae sobre la red, Illumio puede aplicar tanto la carga de trabajo como seguridad de red a partir de un modelo operacional de políticas centrales.

Si define los recursos básicos y esenciales en cualquier data center o nube híbrida como computación, almacenamiento de información y red, estos tres recursos ahora se virtualizan y abstraen comúnmente por encima de los recursos subyacentes.

El cuarto recurso esencial del data center es la seguridad y, de manera similar, debe estar virtualizado y depender de los recursos subyacentes. La nube híbrida no debe ser igual a la seguridad híbrida. La seguridad debe abarcar toda la estructura de la nube de la red y la seguridad de la carga de trabajo debe aplicarse directamente en la carga de trabajo, como una “estructura” de seguridad unificada en todas las estructuras de red. La virtualización de la seguridad libera a los arquitectos de red subyacentes para que se centren en las prioridades de la red y coloca la seguridad de la carga de trabajo donde pertenece: directamente en la carga de trabajo.

Obtenga más información sobre cómo este enfoque hace que sea más fácil administrar la seguridad en sus entornos de nube híbrida.