Defensa a profundidad: cómo ejecutar cargas de trabajo en Azure, parte 1

By Gerry Le Canu

En los últimos años, ha habido un cambio dramático en aceptación de plataformas de nube pública para ejecutar aplicaciones y cargas de trabajo. El miedo en torno a utilizar nubes de múltiples usuarios para ejecutar todas las cargas de trabajo ha disminuido, no solo entre startups y negocios pequeños que buscan rentabilidad en la economía de la nube, sino de manera generalizada.

Es difícil señalar un solo catalizador para este cambio. A pesar de que los ahorros son una motivación importante, otros factores también han tenido importancia, incluyendo el éxito de los cambios de la industria provocados por la agilidad de la nube (Netflix, Uber y Airbnb) y la necesidad de mayor integración con otras empresas, ya sea como socio en su cadena de valor o como proveedor de un servicio que consume (como puede ser una nube o una solución SaaS).

Para las empresas, el cambio a nube pública siempre ha sido dependiente de confiar en que su información está a salvo en el centro de datos de alguien más. No solo desde una perspectiva de seguridad, sino también en privado y de acuerdo con la lista cada vez mayor de regulaciones para proteger la información.

Microsoft se ha esforzado tremendamente para asegurar su confianza en la plataforma Azure, y ha logrado obtener más certificaciones que ningún otro proveedor de nube. Puede ver la gran lista de esas certificaciones aquí.

Pero saber que puede confiar sus datos a Microsoft Azure es solo el primer paso en el proceso de ejecutar cargas de trabajo seguras ahí. Que Microsoft haya logrado una certificación, ya sea HIPAA/HITRUST, PCI o ISO, no le concede automáticamente a usted la misma certificación.

Aún le corresponde a usted y a su organización asegurarse de que sus procesos y uso de servicios Azure se alineen con sus necesidades de protección de datos y certificaciones. De manera similar, la seguridad de sus aplicaciones y datos no solo recae en los hombros del proveedor de nube, por lo que necesita tomar medidas de seguridad para nuevas aplicaciones, aplicaciones existentes que migran y, especialmente, cargas de trabajo híbridas que utilizan infraestructura de nube pública y privada.

Es por ello que Rackspace recomienda un enfoque de defensa a profundidad. De manera similar a una cebolla, hay muchas capas de seguridad en la nube. Conforme remueve esas capas y se adentra en la solución, la responsabilidad de aquellas capas se muda del proveedor de nube (en este caso, Microsoft) a usted.

Aquí revisaremos qué son esas capas y, conforme las removemos, le mostraremos en qué momento la responsabilidad pasa de manos de Microsoft a las suyas, y cómo puede utilizar los servicios que Azure ofrece para proteger sus cargas de trabajo. Asimismo, veremos las diferencias entre protección tradicional de perímetro, en la que usted busca evitar acceso no autorizado, y luego analizaremos una estrategia en la que asume que habrá una filtración y utiliza detección de Microsoft y Rackspace como parte de nuestros servicios de seguridad administradadiseñados específicamente para su ambiente. De manera tradicional esto se ha manejado a través de aplicaciones de red avanzadas como firewalls, balanceadores de carga y, recientemente, firewalls de aplicaciones de red, que se añaden sobre medidas de seguridad física para asegurarse de que solo personal autorizado pueda ingresar a los dispositivos físicos que residen en el centro de datos.

Seguridad física

Para seguridad física en Azure, la responsabilidad reside solo en Microsoft y comienza en sus centros de datos con el uso de medidas y tecnología de seguridad tradicionales.

Las medidas de seguridad incluyen el uso de enrejado perimetral fuera de los centros de datos, monitoreo de seguridad y control de acceso con requisitos multifactor tales como un gafete y lectores biométricos. Eso asegura que solo personal autorizado con una necesidad legítima pueda acceder al lugar.

La tecnología también suplementa a la seguridad física conforme pasa del centro de datos físico hacia la red física y hosts que ejecutan los tejidos de cómputo, red y almacenamiento en la nube.

Microsoft tiene un Security Operations Center que monitorea y protege ante amenazas con distintas herramientas, e incluso aprovecha el poder de Azure a través de inteligencia artificial como parte de su proceso continuo de pruebas de monitoreo y penetración. Una de las herramientas más grandes es un sistema de defensa de denegación de servicio (DDoS) que protege a la plataforma Azure de ataques lanzados de manera externa así como de ataques de otros usuarios de Azure.

Debe señalarse que las actividades en esta sección, incluyendo prevención de DDoS y actividades SOC, se enfocan en Microsoft Cloud en general y no están diseñadas para el uso específico de cada cliente Azure.

Capa de acceso a la nube

Conforme entramos a la siguiente capa, pasamos de protecciones físicas y de plataforma a espacio de control compartido en el que el tráfico pasa de internet hacia su red privada. Esta es la “capa de acceso a la nube” y es identificada por las direcciones IP públicas que se exponen al internet público y que permiten que el tráfico sea dirigido en porciones específicas a servicios y recursos privados en Azure. El enrutamiento está en manos de Network Address Translation (NAT), que dirige el tráfico hacia direcciones IP y puertos privados en una red virtual.

A pesar de que no puede llevar sus direcciones IP públicas a Azure, son opcionales y no son necesarias para cada máquina virtual (VM, por sus siglas en inglés), sino que solo se utilizan cuando se exponen recursos en una DMZ o al usar servicios de Azure de cara al público como Azure SQL Databases y Azure Storage. También son configurables y pueden asociarse con VM, balanceadores de carga externos, gateways VPN y gateways de aplicaciones (balanceadores de carga de capa 7).

En esta capa es importante no dejar que cada VM que cree tenga una IP pública, sino que es mejor que solo su contenido de cara a internet esté expuesto a través de una IP pública. Únicamente deje que los recursos que sirven a sus aplicaciones y contenido de cara a su público tengan IP pública y utilice puertas de enlace administrativas como VPN Gateways o ExpressRoute para su conectividad interna a Azure.

Aislamiento de red virtual

Cuando el tráfico alcanza a su red virtual, gran parte de la administración queda en sus manos. La plataforma Azure brinda aislamiento de red virtual que funge como un límite entre usted y otros usuarios Azure, así como sus múltiples redes virtuales en Azure.

Una red virtual o vNet es una red privada para aislamiento de sus recursos de nube en Azure con control total de espacio privado de IP, DNS, seguridad y enrutamiento. Puede elegir su plan de IP, ya sea bloqueo de iP privada Class A, B o C para su red.

Puede subdividir aun más ese bloqueo al clasificarlo en subredes, agrupando recursos en múltiples capas de subredes, o mantenerlo relativamente simple con un DMZ en la parte frontal y una subred en la parte trasera.

Por defecto, todos los recursos dentro de una red virtual son enrutables nativamente unos con otros por lo que se conoce como System Routes. Este es el caso incluso de subred a subred lo que significa que nadie tiene que perder tiempo en configurar tablas de rutas en la red virtual.

Eso solo aplica a la red virtual, a menos que estén habilitados vNet o ExpressRoute, lo que implicaría que enrutar entre vNet posiblemente ocurre porque no hay traslape de red.

La función de las rutas de sistema es muy simple de configurar, pero también es fácil que elementos perversos se muevan lateralmente dentro de su ambiente si es que buscan obtener acceso. Como mínimo, las subredes dentro de una vNet deben usarse para crear una topología multicapa con una subred frontal de cara al público o un DMZ con servicios back-end agrupados lógicamente basado en sus funciones o capa dentro de la aplicación.

Grupos de seguridad de red

Con Azure, como casi en todas las plataformas de nube, la función de control de tráfico cambia de firewalls tradicionales y aplicativos de seguridad de red a una nueva creación llamada grupos de seguridad de red (NSG). Los NSG son un grupo de reglas o listas de control de acceso (ACL) que permiten o rechazan tráfico de red en una red virtual. Las reglas NSG o ACL se agrupan en un NSG y se aplican a recursos dentro de Azure para permitir o negar el tráfico.

La práctica recomendada es aplicar NSG a una subred dentro de su red virtual, que se aplicaría a todas las máquinas virtuales dentro de esa subred. También es posible aplicar más restricciones a una VM específica al aplicar NSG adicionales a la tarjeta de interfaz de red asignada a la VM.

A unir las piezas

Mudarse a una plataforma de nube no es una labor sencilla y hay muchos elementos a considerar en el recorrido. Hacerlo solo es una labor plagada de problemas y dificultades.

Para maximizar el valor de la nube y concentrarse en los lugares en que puede añadir más valor a sus usuarios finales, necesitará de un guía que le ayude a lo largo de su recorrido. En Rackspace, no solo obtiene la orientación necesaria para aprovechar Azure al máximo, sino que tendrá a un socio que se encarga de la infraestructura por usted, lo que le permitirá enfocarse en sus aplicaciones.

En la parte dos de esta serie discutiremos cómo mitigar los efectos de una filtración utilizando protección externa a amenazas, seguridad de red, enrutamiento definido por usuarios y a los expertos de un socio de seguridad capaz.

LEAVE A REPLY

Please enter your comment!
Please enter your name here