Cuando una organización inicia el proyecto de migración de los sistemas on-prem (en un housing) a un entorno cloud o multi-cloud, tenemos que confrontar una serie de decisiones de diseño de la red.
El mercado ofrece multitud de soluciones para seguridad de redes en estos escenarios, normalmente basadas en tecnologías con poca implantación lo que causa respeto dado lo que nos estamos jugando, nada menos que el perímetro de seguridad del CPD.
En mi opinión, este tipo de proyectos debe abordarse por fases, evitando aumentar el área de exposición de los sistemas mientras estamos en las primeras fases de familiarización con las capacidades de los servicios cloud. Mi opción es centralizar la seguridad para no mezclar las cosas.
Una arquitectura posible es esta:
Visio-Arquitectura-redes-telco-multicloudLas claves de este diseño son:
- Mantenimiento de un mínimo CPD on-prem (en el servicio de housing de la operadora), donde ubicaremos los equipos físicos (AS400, Hana, etc..) así como las DMZ y los equipos de seguridad perimetral de la red de CPD. Este punto actua como punto central de la red, y es fijo, aunque cambiemos de proveedores de cloud. Para mi es una de las bases del diseño, ya que permite seguir funcionando en un esquema híbrido.
- Separación de la red de usuarios de la red de CPD, creando dos redes MPLS completamente separadas, con direccionamiento distinto. Esto permite un único punto de contacto entre las dos redes. Los servicios de acceso a cloud con líneas dedicadas de las operadoras (ExpressRoute y otros) dan visibilidad del servicio cloud directamente a toda la red, lo que complica tremendamente la configuración (hay que aplicar un FW en cada cloud). Posible, hay tecnología, pero esta opción permite simplicidad y controla un coste muy bajo.
- Adquisición de un firewall (Palo Alto, Fortinet), instalado en el housing, con capacidad para virtualizar un mínimo de 4 firewalls con los que protegeremos cada uno de los accesos al CPD de forma separada y con estrategias distintas. Esto da simplicidad a la programación del firewall, así como mucho control en caso de ataques (podemos cortar los accesos de forma separada y fácil). El resultado es un sistema muy fácil de interpretar, hasta para los operadores que tendrán que enfrentar un problema a las 4 de la mañana.
- Permite crear sub-redes en la zona de usuarios (especialmente útil en entornos industriales o retail) a los que podemos dar acceso a proveedores externos que mantienen equipamiento en las sedes, pero que no tendrán visibilidad de la red del CPD. Para ello, en la zona de usuarios crearemos diferentes VPN con direccionamiento separado, y a través de ACLs podremos evitar de forma muy segura el acceso de estos proveedores a la red corporativa.
- Acceso directo a Internet desde la red MPLS de usuarios, tanto para la entrada de proveedores de mantenimiento (conexiones LANtoLAN), como para teletrabajo, como para la navegación a Internet. El default gateway de esta red de usuarios es por tanto la conexión a Internet, dirigiendo hacia el CPD exclusivamente el tráfico a los servidores frontales de las aplicaciones.
- Implantación de un firewall virtual para la protección del CPD de la red de usuarios (lo que llamo FW de perímetro interno), con filtro de acceso por sesión de usuarios (nivel 4), filtrado por grupos de Active Directory. Habilitar exclusivamente las IP y puertos concretos exclusivamente necesarios. Con esto, declaramos la zona de usuarios zona insegura, y la tratamos como tal, ya que es el punto débil, máxime en entornos con uso generalizado de Wi-Fi.
- Aislamiento de Internet de los servicios cloud – para mantener el control del perímetro, y controlar el acceso de usuarios y proveedores a los servicios, mi propuesta es aislar los servicios cloud de Internet, permitiendo el acceso sólo a través del FW central. Esto genera tráfico por la línea (que tiene coste en caso de bajada), pero evita tener que administrar y monitorizar diferentes puntos de frontera
- Segregación de los caudales de Internet para diferentes propósitos – hoy en día, el coste del servicio Internet esta asociado al acceso y caudal agregado, con lo que separar este acceso en diferentes sub-caudales con direccionamiento específico para cada función no representa un coste. Las ventajas de esta estrategia son la protección de los diferentes servicios (aseguramos el caudal para cada función), y por otra parte poder aplicar reglas de seguridad diferentes para cada acceso.
- Caudal Internet de acceso de proveedores al CPD – se define un caudal para las conexiones LANtoLAN de acceso de los mantenedores de los sistemas del CPD. Aquí la propuesta es separar los proveedores que dan servicio a estos sistemas centrales de los equipos de la zona de usuarios/centros (microinformática, equipamiento audiovisual,etc..). Este acceso al CPD suele ser uno de las principales preocupaciones de cualquier responsable de seguridad. Sin entrar en soluciones existentes pero no al alcance de empresas de tamaño medio, lo mejor es establecer conexiones LANtoLAN encriptadas con los proveedores y proteger el acceso con lista de IPs origen de sus redes, filtrando los servidores para cada proveedor.
- Caudal Internet para interoperabilidad – es la via para las comunicaciones B2B. Las empresas intercambiamos constantemente información via ficheros o webservices, con las que nos hacemos pedidos, recibimos facturas, información de productos, etc. En este caso es sencillo el filtrado por IP origen de estas conexiones. Esta zona acostumbra a tener su propia DMZ, con servicios como el FTP o los proxies inversos que re-dirigen las conexiones.
- Caudal internet para eCommerce – este tipo de acceso es completamente diferente al anterior, y esta sometido a mucha más tensión que el resto. Aquí considero que es de aplicación un servicio WAF (son caros si son buenos, mejor limitarlos a esta función), y es donde tenemos el verdadero reto de seguridad.
Espero que este esquema os pueda ser de utilidad en vuestros proyectos.