Check Point Nube Segura Blueprint

©2018 Check Point Software Technologies Ltd. All rights reserved | P. 1
Check Point Nube Segura Blueprint | White Paper
Visión
El cómputo en la nube ha sido ampliamente adoptado a nivel mundial y se espera que crezca aún
más en los próximos años. Sin lugar a dudas, la agilidad empresarial es el principal beneficio y el
factor clave detrás de la adopción de la nube, porque los recursos de TI se pueden adquirir y
desplegar más rápidamente. Una vez desplegados, estos recursos se pueden aumentar o disminuir
según sea necesario para satisfacer la demanda.
De acuerdo con el reporte “2017 State of the Cloud Report” de RighScale (mostrado en la imagen
abajo), el 95% de los encuestados del informe indicaron que están utilizando la nube. La adopción
se nota en todas las plataformas en la nube, tanto públicas como privadas y, lo que, es más, las
organizaciones utilizan múltiples proveedores mientras construyen sus entornos de nube híbrida.
Al mismo tiempo, Gartner afirma que la seguridad continúa siendo el mayor inhibidor de la
adopción de la nube. Esto no es una sorpresa considerando el hecho de que los servicios en la nube
son entornos compartidos, siempre conectados y dinámicos por naturaleza, lo que los convierte en
un desafío cuando se trata de seguridad.
Mover los recursos y los datos informáticos a un entorno de nube pública significa que las
responsabilidades de seguridad se comparten entre usted y su proveedor de la nube. Si bien el
proveedor brinda protección de la infraestructura, usted desea y necesita la capacidad de controlar
sus propios datos, mantenerlos privados y proteger todos sus activos en la nube, a la vez que
mantiene el cumplimiento de los mandatos regulatorios. Check Point CloudGuard protege
CHECK POINT NUBE
SEGURA BLUEPRINT
Arquitectura de seguridad ágil para la nube

aplicaciones y datos en nubes privadas y públicas con seguridad avanzada de prevención de
amenazas a la vez que permite una conectividad confiable a entornos de nube públicos e híbridos.
El enfoque de este documento es el diseño de arquitectura y seguridad de esta. Se entiende como
un modelo que le permite lograr los mejores controles de seguridad y visibilidad alineados con la
agilidad, elasticidad y naturaleza automatizada de la infraestructura en la nube.
Para instrucciones operativas detalladas, existen documentos separados por plataforma para
proporcionar una guía práctica sobre cómo crear y desplegar la solución.
Guía de Arquitectura de Seguridad en la Nube
Como se mencionó anteriormente, las organizaciones buscan utilizar mejor sus recursos de TI,
alinearlo con lo último y mejor que la nube tiene para ofrecer:
• Agilidad: disminuya el intervalo de tiempo hasta el mercado
• Elasticidad: expanda y reduzca los recursos según demanda
• Eficiencia: solo pague por lo que usa
Al diseñar su entorno basado en la nube, es fundamental que la arquitectura se alinee con los casos
de uso comercial de usted y de sus clientes, todo mientras mantiene un enfoque sin compromisos
hacia la seguridad.
Este documento destaca los principios necesarios y las mejores prácticas a seguir para construir sus
entornos basados en la nube de forma segura.
Los Cinco Principios Primordiales
1. Seguridad Perimetral con Prevención Avanzada contra Amenazas
En años recientes, ha habido un claro aumento tanto en la frecuencia de ataque como en la
sofisticación del software malicioso que se está utilizando. Esto está sucediendo en
correlación con incidentes en la nube relacionados con el análisis de vulnerabilidad, ataques
de aplicaciones web y los ataques de fuerza bruta. Muchas organizaciones deducen
erróneamente que sus proveedores de servicios en la nube (CSP) son responsables de
proteger sus datos en la nube. Este no es el caso.
Si bien la seguridad es una prioridad importante para los CSP (proveedores de servicios en la
nube), normalmente operan con un paradigma conocido como Modelo de Responsabilidad
Compartida. Esto significa que los CSP asumen total propiedad (y responsabilidad) de
cualquier cosa "de" la nube y dejan todo lo que está "en" la nube como responsabilidad
exclusiva y única del cliente. Los CSP también proporcionan algunas herramientas de
seguridad básicas que son gratuitas para los clientes, pero con las amenazas más recientes y
filtraciones de datos, resulta obvio que se requiere adicionalmente de una prevención de

amenazas avanzada y es responsabilidad del cliente defender sus datos. Por lo tanto, es
obligatorio para las organizaciones rodear sus entornos con las mejores protecciones
existentes en su clase contra los ataques de hoy en día. Esto es aplicable tanto en el
perímetro del entorno como en sus principales cruces de tráfico dentro y fuera del entorno.
2. Segmentación
La segmentación de red se realiza generalmente con la finalidad de reducir los ataques en la
superficie de la red y limitar la capacidad de una amenaza maliciosa de propagarse
libremente por la red. Los ciberataques recientes dependen en gran medida de propagarse
lateralmente dentro de una red y de infectar otras máquinas dentro de esa misma red. Este
comportamiento reitera la necesidad de segmentar la red por aplicación o servicio y colocar
las mejores protecciones en su clase entre estos segmentos de red.
El refuerzo de la seguridad se realiza en dos capas. La primera capa está en el nivel de
acceso donde la política del firewall se usa para permitir que cierto tráfico fluya
normalmente con la finalidad de permitir el funcionamiento normal de la aplicación, pero
también bloquea el tráfico no deseado entre estos segmentos. La segunda capa de
prevención de amenazas es cuando el firewall inspecciona el tráfico que está permitido por
el nivel de acceso, pero lo inspecciona minuciosamente para identificar el comportamiento
malicioso dentro de estos flujos. Esto permite que las aplicaciones se comuniquen entre sí
de forma segura.
Dando un paso más allá, la capacidad de la nube de la Red Definida de Software (SDN), nos
permite también poner estos puntos de inspección de protección avanzada entre hosts
individuales (incluso dentro del mismo segmento de red) y también lograr lo que se conoce
comúnmente como "Micro - segmentación".
Otro aspecto de la segmentación cubierto por blueprint es reforzar metodológicamente las
restricciones de tráfico y la segmentación, para evitar errores humanos y la pérdida de
datos debido a configuraciones incorrectas que pueden exponer los activos al público. Este
método se practica, por ejemplo, bloqueando sistemáticamente el movimiento lateral a
través de una sección de la red mientras se permite el movimiento en una sección
controlada alternativa donde se monitorea atentamente y donde se aplican los controles de
seguridad.
3. Agilidad
La capacidad para operar el negocio a gran velocidad y ser verdaderamente ágil se logra
gracias a la naturaleza bajo demanda que la nube ofrece. Resulta prácticamente imposible
adoptar prácticas comerciales eficientes y modernas, si toma semanas proveer a los
servidores y servicios, o si su operación de seguridad se convierte en un obstáculo
significativo para el negocio debido a que cada solicitud o proceso de aprobación es tedioso
y resulta en una pérdida de tiempo.

Este blueprint está diseñado de manera que cultiva agilidad mientras que garantiza que la
velocidad no se transforme en una pérdida de control o en un mayor riesgo operativo. Esto
se hace creando una delegación del alcance de propiedad entre los diferentes grupos de
interés en la organización. De esta forma, DevOps (desarrollo y operaciones), propietarios
de las aplicaciones y otros grupos disfrutan de un mejor nivel de autoridad sobre sus
recursos y entornos. Por lo tanto, son libres de crearlos y administrarlos. La mayor
autoridad viene acompañada de una mayor responsabilidad de tener control de acceso
dentro y entre sus propias cargas de trabajo, dejando la prevención de amenazas y las
consideraciones de prevención avanzada de seguridad a la Red y a los equipos de Seguridad.
4. Automatización, Eficiencia y Elasticidad
La automatización de la Nube es un término amplio que se refiero a los procesos y
herramientas que utiliza una organización para reducir los esfuerzos manuales asociados
con brindar y manejar cargas de trabajo de computo en la nube. Claramente, esto es
también muy relevante para las operaciones de seguridad donde la forma tradicional de
proteger manualmente cargas de trabajo y recursos ya no es relevante en entornos de
nube.
En un mundo en el que la agilidad de la empresa se ve frenada debido a las operaciones de
seguridad, esta última está sujeta a ser evadida (mediante el uso de métodos alternos) o
alternativamente al abrir la protección de una manera que no obstaculice los negocios.
Cuando se trata de operaciones de seguridad en la nube, la automatización es fundamental
para reducir el riesgo potencial y eliminar el factor humano de algunos procesos
organizacionales. Blueprint inherentemente apoya y promueve la automatización de
procesos y pasos desde cero, desde la fase de aprovisionamiento del entorno que se realiza
utilizando una plantilla pre configurada, hasta la operación de política diaria que se realiza
mediante políticas dinámicas y adaptativas, donde ninguna intervención humana es
requerida.
5. Sin Límites
Como se indicó anteriormente, se está convirtiendo en una práctica cada vez más común
para los clientes empresariales, lanzar y ejecutar sus cargas de trabajo con múltiples
proveedores de servicios en la nube, principalmente para respaldar mejor sus
requerimientos comerciales. El uso de múltiples proveedores de computo en la nube en un
entorno único y heterogéneo también se conoce comúnmente como una estrategia multi -
nubes. Esta es ciertamente, una estrategia prometedora. El uso de múltiples proveedores
de la nube con diferentes ubicaciones geográficas con una plétora de tecnologías nuevas y
emergentes tiene sus desafíos de seguridad, tales como:
a. Ejecutar una política de seguridad consistente a lo largo de todos los entornos.
b. Gestionar fácilmente la postura de seguridad desde un punto unificado y
centralizado. Conectar de forma segura varias nubes y ubicaciones.
c. Permitir que las aplicaciones se comuniquen de forma fácil y segura
independientemente de su ubicación.

d. Tener visibilidad de los flujos de tráfico en y entre las diferentes ubicaciones.
Este Blueprint responde a todos los retos antes mencionados y respalda la urgencia del negocio
de seguir esta estrategia.
Blueprint Check Point Nube Segura
La arquitectura del blueprint descrita a continuación se diseñó para cumplir con las pautas
anteriores y garantizar que las empresas migren de forma segura a la nube. El concepto
arquitectónico se basa en un modelo "hub & radio" donde el entorno se configura como un sistema
de conexiones acomodado como una rueda de cables en la que todos los radios (spokes) están
conectados a un hub central y todo el tráfico hacia y desde los radios atraviesa a través de un
concentrador (hub). Blueprint propone el uso de dos hubs en el mismo entorno para permitir la
separación del tráfico.
HUB
Spoke
Spoke
Spoke
HUB
Spoke
Spoke
Spoke
Spoke
Spoke Spoke
Los radios (spokes)
Un radio (spoke) es un entorno de red aislado que contiene una colección de una o más subredes
de la red desde la que las cargas de trabajo típicas pueden ser instaladas y ejecutadas. Un caso
común de uso es un radio que contiene varios servidores virtuales que comprenden tanto una
parte o un conjunto completo de aplicaciones (web, aplicación y base de datos). Otro caso de uso
es cuando un radio actúa como una extensión de una red local existente en sitio, tales como un
conjunto de servidores QA para fines de prueba o un conjunto de servidores de procesamiento de
datos que utilizan el aprovisionamiento bajo demanda de la nube para un menor costo y agilidad
mejorada.

Este Blueprint se creó como un documento de diseño de alto nivel que es aplicable a todos los
entornos líderes de la nube, como AWS, Azure, Google, Oracle Cloud, Alibaba Cloud entre otros.
Los hubs
En el siguiente diagrama, utilizamos dos hubs dentro del entorno. Esto permite la flexibilidad y
separación sistemática de los tipos de comunicación a través del entorno. Un hub está designado
para el tráfico entrante de Internet y el otro hub está designado para el tráfico lateral entre radios,
el tráfico entrante o saliente de la red corporativa y el tráfico saliente hacia Internet u otros
entornos de la nube.
Flujo de tráfico dentro del entorno
Al configurar el routing y las conexiones entre hubs y radios, logramos alcanzar una situación en la
que los hubs son la única forma de entrada/salida del entorno, así como la única forma de
atravesar dentro y entre radios en el entorno ya que los radios no están conectados directamente
entre ellos, en realidad únicamente son accesibles a través de uno de los hubs. Esto permite tanto
la segmentación del perímetro como la del ambiente.

Perímetro de Seguridad
La aplicación del perímetro se realiza en los hubs (norte y sur).
Las protecciones de seguridad recomendadas para activarse en el perímetro son Antivirus, Anti-Bot
e IPS.
Segmentación
La segmentación se logra colocando nuestros recursos en diferentes radios y aplicando controles
de seguridad en el tráfico que entra o sale de un radio. Existen tres tipos principales de radios
dentro del blueprint:
 Únicamente con orientación a Internet (por ejemplo, RADIO-1 en el dibujo anterior): - Estos
radios están conectados a los hubs en dirección norte y solo se puede acceder a ellos a través
del tráfico entrante de Internet. Comúnmente, estos radios albergarán servidores de primer
nivel con orientación a Internet y que necesiten ser accedidos desde Internet. La conectividad
de estos radios a recursos corporativos u a otros radios del entorno se bloquea
sistemáticamente y no puede ser habilitada mediante una configuración simple (Esto se hace
para evitar errores humanos y errores que exponen recursos no deseados al público).
 Únicamente con orientación Privada (por ejemplo, RADIO-2 en el diagrama superior) – Estos
tipos de radios están únicamente conectados al hub con orientación al sur y por lo tanto
sistemáticamente no son accesibles desde Internet, sino más bien son accesibles a través de
VPN y/o conectividad directa de la red corporativa o de otros radios en el entorno (debido a la
política de seguridad en los firewalls orientados al sur). Un ejemplo práctico de un radio de este
tipo es un radio alojando servidores de bases de datos (DB). No queremos que estos sean
directamente accesibles desde Internet, pero queremos que sean capaces de tener
conectividad segura.
 Combinados (por ejemplo, RADIO-3 superior) – Estos tipos de radios son adecuados para
servidores que son accesibles desde Internet, pero que también requieren acceso de backend a
otros radios o a la red corporativa. Un ejemplo de uso en este caso es un servidor que está
expuesto a internet en una entrada y necesita acceso a un servidor de aplicación o un servidor
de base de datos en la otra.
Agilidad
Para habilitar y apoyar la agilidad empresarial, los radios pueden crearse y pertenecer por
completo a las diferentes líneas de negocio (LOB por sus siglas en inglés). De hecho, cualquiera
dentro de la organización puede ser propietario de un radio siempre que esto se alinee con la
política de la organización. Una vez creado, servidores, contenedores y cualquier otra carga de
trabajo dentro del radio el dueño del radio los controla y les de mantenimiento. Esto le da libertad
para operar dentro del radio, ya sea creando, desarrollando o ejecutando un servicio o aplicación.
Esto permite la característica de agilidad más deseada de la nube que no haya sobrecarga de
entradas ni dependencia para nada que ocurra dentro de cada radio.

Automatización
Como se indicó anteriormente, otro aspecto importante de blueprint es incorporar TI a las
operaciones en la nube. Blueprint simplifica el proceso de llevar TI a la nube y ayuda a utilizar las
mejores funciones de la nube, como la automatización y la organización. El objetivo final es
permitir que las TI funcionen y sean un facilitador comercial en lugar de ser un obstáculo comercial.
Al usar plantillas de implementación preconfiguradas del firewall virtual, TI es capaz de
implementar de manera segura un entorno completo con el "clic de un botón" y con muy poca o
ninguna configuración práctica.
Esto es cierto para el aprovisionamiento del entorno, así como para ejecutar las operaciones diarias
y apoyar un entorno elástico listo para usar. Tome un entorno similar al del diagrama anterior
como ejemplo. El propietario de una aplicación dentro entorno agrega un nuevo radio. El servidor
de administración de Check Point (SMS) automáticamente identifica este nuevo radio y
automáticamente forma las conexiones seguras requeridas hacia y desde el. Esto permite una
visibilidad completa y control del tráfico hacia y desde la radio recién creada, y asegura que cumple
con los estándares y políticas identificados por TI.
El mismo nivel de dinámica se logra con la postura de seguridad de la organización donde una
política puede ser pre aprobada previamente y luego se asigna dinámicamente a cargas de trabajo
(con base en etiquetas de recursos, por ejemplo). Los cambios son instantáneos, lo que permite a
los propietarios del negocio avanzar a su propio ritmo y al mismo tiempo que se aseguran de que
las políticas y los estándares de la compañía se cumplan.
Sin Límites
Este diseño también soporta intrínsecamente el escalado fuera de los límites normales de una sola
plataforma en la nube y también maneja la conectividad entre plataformas en la nube,
manteniendo los mismos principios de arquitectura y manteniendo la misma postura de seguridad
en todos los entornos.
Un ejemplo para una arquitectura de múltiples nubes múltiple es una compañía de juegos en línea
que despliega sus servicios a través AWS y Azure. La lógica detrás de esto es un enfoque de "lo
mejor de su clase" en el que cada plataforma se elige en función de la experiencia del equipo y la
superioridad tecnológica.
Por ejemplo, la interfaz web y los niveles de las aplicaciones se alojan con AWS a través de
múltiples zonas de disponibilidad para la redundancia y la Identidad y Autenticación es provista por
el servicio integrado AD de Azure mientras que la DB y los niveles de almacenamiento se alojan en
el centro de datos local.

Este entorno debe ser seguro y permitir la flexibilidad y agilidad desde el primer momento. El
siguiente diagrama ilustra este caso de uso:
Como se muestra en el diagrama, implementar gateways vSEC a través de diferentes plataformas
nos permite tanto controlar el tráfico específicamente en cada ubicación, pero también ejecutar
nuestra política de seguridad a través y entre ubicaciones.
Consideraciones Adicionales
Gestión Unificada
La seguridad operativa en un entorno de múltiples nubes puede ser un desafío ya que implica
administrar y controlar recursos en una variedad de ubicaciones que usan diferentes herramientas
de administración. Tratar de mantener una política unificada en tales condiciones es obviamente
tedioso e ineficiente, a pesar de la resolución de problemas de conectividad o eventos de seguridad
en el entorno.
El servidor de administración (SMS) R80.10 es una solución integrada de administración de
seguridad que incluye política, registro, monitoreo, correlación de eventos e informes, todo en un
solo sistema utilizando una política de seguridad unificada que permite a los administradores
identificar fácilmente los riesgos de seguridad en todo el entorno y mantener la política de
seguridad.

Una política unificada permite a las organizaciones traducir sus definiciones de seguridad en un
conjunto simple de reglas, que luego optimiza la política de administración y ejecución dentro de la
organización.
La ubicación del servidor de administración es completamente flexible y puede ubicarse en
cualquier lugar del entorno. También es posible configurar el servidor de gestión en modo de alta
disponibilidad en todas las plataformas (por ejemplo, administración principal ubicada en sitio con
un servidor de respaldo ubicado en un área designada para recuperación de desastres).
Redundancia y Resiliencia
Como regla general, blueprint se creó con una capacidad incorporada de resiliencia para eventos
de fallas locales. Esto se encuentra implementado en varias capas del entorno.
1. Redundancia a nivel de Centro de Datos – El entorno está construido dentro de múltiples zonas
(2 o más) donde cada una representa un centro de datos separados (por ejemplo, una red
separada de electricidad, aires acondicionado y por lo general, incluso en un edificio separado).
2. Redundancia a nivel de software– Las gateways se implementan con redundancia N+1* a lo
largo de todo el entorno. Esto se traduce en dos soluciones separadas con base en la ubicación
y rol de las puertas de entrada.
* N+1 redundancia es una forma de resiliencia que asegura la disponibilidad del sistema en el caso de una falla de componentes. Los
componentes (N) tienen al menos un componente independiente de backup (+1).
a. En el Hub hacia el Norte, donde las conexiones basadas en http/https están entrando
desde el Internet, las gateways son implementadas de forma elástica donde el número

de gateways es dinámico con base en la carga que fluye a través de las gateways. Este
tipo de escalamiento, también conocido como como escalamiento horizontal**,
significa que en cualquier momento en el que la carga incrementa gateways adicionales
son añadidas y puestas en funcionamiento en muy pocos minutos (cinco a siete minutos
para la inicialización de gateways. Cuando la carga se reduce, las gateways innecesarias
se eliminan del montón (pool) y el entorno se mantiene eficiente desde un punto de
vista de costo y desempeño.
b. En el Hub hacia el Sur, las gateways son implementadas como un clúster activo-en
espera. El mecanismo de escalado aquí se conoce como escalamiento vertical ***.
Siempre que sea necesario soportar un aumento de la carga a través de este hub, se
agregarán más recursos a las puertas de enlace, respectivamente.
Conmutación por error (Failover)
En caso de fallo en el Hub hacia el norte, las conexiones que existían en ese gateway no se
conservan y nuevas conexiones se reajustan a un gateway saludable en el entorno. Las conexiones
basadas en http / https son por naturaleza sin estado. La experiencia del usuario es una mera
actualización de un navegador en cuestión de segundos.
En el Hub hacia el sur, donde las conexiones son más diversas, complejas y generalmente con
estado, las conexiones se sincronizan constantemente entre los miembros del clúster. Una
conmutación por error del gateway activo hará que un miembro en espera recupere todas las
conexiones activas y se convierta en un miembro activo.
Afinidad de Conexión
La afinidad de conexión en el hub hacia el norte se basa en la dirección IP y el número de puerto
del cliente, de modo que siempre que se inicie una conexión desde Internet, el equilibrador de
carga elige la gateway destinada para enviar la conexión y mantiene el mismo objetivo siempre que
la sesión este activa.
La afinidad en el hub hacia el sur se basa en el miembro activo, de modo que todo el tráfico
siempre se dirige a los miembros activos.
Dimensionamiento Recomendado
El dimensionamiento de la solución se realiza normalmente con base en los requerimientos de
desempeño dentro del entorno y del nivel de seguridad requerido. El dimensionamiento típico
recomendado para un entorno sería el siguiente:
1. En el Hub hacia el norte, un mínimo de 2 gateways (N+1) cada una con 4 núcleos CPU
virtuales y 8 GB de RAM es lo recomendado. Tal como se mencionó anteriormente, el
escalamiento se realiza de manera horizontal, por lo que gateways adicionales se agregan
automáticamente al entorno a medida que crece la carga de trabajo que llega al entorno.

2. En el hub hacia el sur, la recomendación es que el clúster este comprendido por 2 gateways
cada una con 8 núcleos CPU virtuales y 8GB de RAM. El crecimiento es vertical, lo que
significa que más recursos (CPU/RAM) son añadidos a cada gateway.
** Escalamiento horizontal significa que tú escalas al añadir más maquinas a tu conjunto de recursos.
*** Escalamiento vertical significa que tú escalas al añadir mayor poder a una máquina existente (CPU, RAM)
Recuperación de Siniestro
Configurar una arquitectura resiliente para un evento catastrófico es una práctica común para
muchas organizaciones. Teniendo la flexibilidad alcanzada a través de este blueprint, un sitio DR
puede ser fácilmente creado y mantenido como cualquier otro sitio dentro de la arquitectura. Es
más, la infraestructura puede reducirse a no tener redundancia, pero si lo suficiente como para
soportar cargas de trabajo en hora pico
Implementaciones practicas del Blueprint
En AWS
Desde un punto de vista terminológico, los HUB y los radios se construyen mediante nubes
privadas virtuales (Virtual Private Clouds, VPC) en la plataforma AWS. La configuración del plan en
AWS se realiza utilizando plantillas predefinidas de CloudFormation.
En el caso de AWS, las VPC de radio a las que se debe acceder a Internet público están conectadas a
la VPC de Northbound utilizando capacidades de peering de VPC. Como VPC Peering en AWS no es
transitivo, lo que significa que no puede atravesar una tercera VPC utilizando la conexión entre las
dos primeras, utilizamos la interconexión para asegurarnos de que el tráfico que proviene de
Internet solo viaje un salto dentro del entorno (sistemáticamente). Para las conexiones de Internet
que se originan desde las VPC de Spoke, las conexiones se enrutan a través de la VPC de
Southbound. Las VPC de Spoke están conectadas a la VPC en dirección sur a través de túneles IPsec
sobre la VPN basada en ruta con las VGW de AWS en cada Spoke. Esta infraestructura también se
utiliza para la conectividad entre VPC (este-oeste dentro del entorno), acceso a entornos locales y
acceso a Internet.
En este método, las puertas de enlace de seguridad en el VPC hacia el sur propagan las rutas a los
VGW para dirigir el tráfico saliente desde los radios a través de las puertas de enlace hacia el sur
para servicios de inspección, enrutamiento y VPN. La VPC hacia el sur también crea VPN con el
entorno local utilizando una comunidad VPN separada que puede estar basada en el dominio o en
la ruta. En la VPC de Northbound, la plantilla de CloudFormation despliega un grupo de
escalamiento automático y un balanceador de carga interno para servir a las aplicaciones
publicadas en las VPC de spoke. ELB, NLB o ALB pueden implementarse como un balanceador de
carga externo para el medio ambiente.

En la VPC de Southbound, la plantilla de CloudFormation despliega 2 puertas de enlace de
seguridad en AZ separadas para servir a las VPC de Spoke en modo de alta disponibilidad.
En Azure
Desde un punto de vista terminológico, los HUB y los radios se construyen mediante redes virtuales
(vNET) en la plataforma Azure. La configuración del blueprint en Azure se realiza utilizando
plantillas de solución predefinidas.
Para las conexiones a Internet que se originan en los vNET de Spoke, las conexiones se enrutan a
través de vNET en dirección sur. La conexión desde southbound vNET a las instalaciones es a través
de ExpressRoute o VPN a través de Internet (basado en el dominio o basado en rutas). Todas las
demás conexiones se basan en peering entre vNET del entorno.

Peering en Azure podría configurarse como transitivo; sin embargo, desde la perspectiva de
seguridad esa capacidad debe evitarse. Esto se hace usando la configuración de configuración de
peering y forzando el tráfico utilizando UDR a las puertas de enlace IaaS CloudGuard de los hub de
vNET (ya sea hacia el sur o hacia el norte).
Resumen
Los principios de diseño anteriores permiten la máxima flexibilidad operativa donde cada ocupante
(por ejemplo, departamento, cliente, propietario de la aplicación, etc.) desplegado en un entorno de
radio dedicado es libre de crear su propia red y calcular recursos dentro de este entorno manteniendo
control incondicional y seguridad de cualquier cosa viajando hacia y desde estos entornos. Esto se hace
para cumplir con la política de seguridad de la compañía y permitir el mismo nivel de control y
visibilidad de la red de la empresa por parte de los equipos de seguridad; similar a lo que se hace en un
entorno de red heredado.

Check Point Nube Segura Blueprint

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Similar a Check Point Nube Segura Blueprint

Similar a Check Point Nube Segura Blueprint (20)

Último

Último (20)

Check Point Nube Segura Blueprint