Acceso centralizado a puntos finales privados de VPC

Un punto de enlace de VPC le permite conectar su VPC de forma privada a los servicios de AWS compatibles sin necesidad de una puerta de enlace a Internet o un dispositivo NAT, una conexión VPN o una conexión. AWS Direct Connect Por lo tanto, su VPC no se expone al Internet público. Las instancias de su VPC no requieren direcciones IP públicas para comunicarse con los puntos de enlace del servicio de AWS con este punto de enlace de la interfaz. El tráfico entre su VPC y otros servicios no sale de la red troncal de AWS. Los puntos de conexión de la VPC son dispositivos virtuales. Son componentes de VPC escalados horizontalmente, redundantes y de alta disponibilidad. Actualmente, se pueden aprovisionar dos tipos de puntos de enlace: puntos de enlace de interfaz (con tecnología de AWS PrivateLink) y puntos de enlace de puerta de enlace. Los puntos de enlace de enlace se pueden utilizar para acceder a los servicios de Amazon S3 y Amazon DynamoDB de forma privada. El uso de puntos de enlace de gateway no supone ningún cargo adicional. Se aplicará la tarifa estándar por la transferencia de datos y el uso de recursos.

Puntos de conexión de VPC de tipo interfaz

Un punto final de interfaz consta de una o más interfaces de red elásticas con una dirección IP privada que sirve como punto de entrada para el tráfico destinado a un servicio compatible. AWS Al aprovisionar un punto final de interfaz, se incurre en un coste por cada hora de funcionamiento del punto final, además de los gastos de procesamiento de datos. De forma predeterminada, se crea un punto final de interfaz en cada VPC desde la que se quiere acceder al AWS servicio. Esto puede resultar prohibitivo y difícil de gestionar en la configuración de la zona de aterrizaje, donde un cliente quiere interactuar con un servicio de AWS específico en varias VPC. Para evitarlo, puede alojar los puntos finales de la interfaz en una VPC centralizada. Todos los VPC radiales utilizarán estos puntos finales centralizados a través de Transit Gateway.

Al crear un punto final de VPC para un AWS servicio, puede habilitar el DNS privado. Cuando está habilitada, la configuración crea una zona alojada privada (PHZ) de Route 53 administrada por AWS que permite la resolución del punto final del AWS servicio público a la IP privada del punto final de la interfaz. El PHZ administrado solo funciona dentro de la VPC con el punto final de la interfaz. En nuestra configuración, cuando queremos que las VPC habladas puedan resolver el DNS de los puntos finales de la VPC alojado en una VPC centralizada, el PHZ administrado no funcionará. Para solucionar este problema, deshabilite la opción que crea automáticamente el DNS privado cuando se crea un punto final de interfaz. A continuación, cree manualmente un PHZ de Route 53 y añada un registro de alias con el nombre completo del punto de enlace del servicio de AWS que apunte al punto de enlace de la interfaz.

1. Inicie sesión en la consola y vaya al servicio de Route 53.

2. Seleccione la zona alojada privada y vaya a Crear registro.

3. Rellene el campo Nombre del registro, seleccione el tipo de registro como A y active el alias.

4. En la sección Enrutar el tráfico a, seleccione el servicio al que se debe enviar el tráfico y seleccione la región en la lista desplegable.

5. Seleccione la política de enrutamiento adecuada y asegúrese de activar la opción para evaluar el estado del destino.

Esta zona alojada privada se asocia a otras VPC de la zona de destino. Esta configuración permite a las VPC radiales resolver los nombres de los puntos de conexión de servicio completo en los puntos de conexión de la VPC centralizada.

nota

Para acceder a la zona alojada privada compartida, los hosts de las VPC radiales deben utilizar la IP de resolución de Route 53 de su VPC. También se puede acceder a los puntos finales de la interfaz desde las redes locales a través de VPN y Direct Connect. Utilice reglas de reenvío condicional para enviar todo el tráfico de DNS de los nombres de los terminales de servicio completo a los puntos de enlace entrantes de Route 53 Resolver, que resolverá las solicitudes de DNS según la zona alojada privada.

En la siguiente figura, Transit Gateway permite el flujo de tráfico desde las VPC radiales hasta los puntos finales de la interfaz centralizada. Cree puntos de enlace de VPC y la zona alojada privada para ellos en la cuenta de servicios de red y compártalos con las VPC de radio de las cuentas de radio. Para obtener más información sobre cómo compartir información de puntos de conexión con otras VPC, consulte la entrada del blog Integrating AWS Transit Gateway with AWS PrivateLink and Amazon Route 53 Resolver.

nota

Un enfoque de punto final de VPC distribuido, es decir, un punto final por VPC, le permite aplicar políticas de privilegios mínimos en los puntos de enlace de VPC. Con un enfoque centralizado, aplicará y gestionará políticas para el acceso a VPC de todos los radios en un único punto final. Con el aumento del número de VPC, la complejidad de mantener los privilegios mínimos con un único documento de política podría aumentar. Un único documento de política también da como resultado un radio de explosión mayor. También está restringido el tamaño del documento de política (20.480 caracteres).

Centralización de los puntos finales de VPC de la interfaz

Acceso a puntos finales entre regiones

Cuando desee configurar varias VPC en diferentes regiones que compartan un punto final de VPC común, utilice una PHZ, tal y como se ha descrito anteriormente. Las dos VPC de cada región se asociarán a la PHZ con el alias del punto final. Para enrutar el tráfico entre las VPC en una arquitectura multirregional, las pasarelas de tránsito de cada región deben estar conectadas entre sí. Para obtener más información, consulte este blog: Uso de zonas alojadas privadas de Route 53 para arquitecturas multirregionales entre cuentas.

Las VPC de diferentes regiones se pueden enrutar entre sí mediante Transit Gateways o VPC Peering. Utilice la siguiente documentación para interconectar las pasarelas de tránsito: Adjuntos de interconexión de las pasarelas de tránsito.

En este ejemplo, la instancia de Amazon EC2 de la us-west-1 región de VPC utilizará el PHZ para obtener la dirección IP privada del punto final de la región y enrutará el tráfico a la VPC de la us-west-2 región a través del emparejamiento de Transit Gateway o el emparejamiento de us-west-2 VPC. Con esta arquitectura, el tráfico permanece dentro de la red de AWS, lo que permite que la instancia EC2 acceda us-west-1 al servicio us-west-2 de VPC de forma segura sin tener que pasar por Internet.

Terminales de VPC multirregionales

nota

Se aplican cargos por transferencia de datos entre regiones al acceder a los puntos finales en todas las regiones.

Haciendo referencia a la figura anterior, se crea un servicio de punto final en una VPC de la us-west-2 región. Este servicio de punto final proporciona acceso a un servicio de AWS en esa región. Para que las instancias de otra región (por ejemplous-east-1) puedan acceder al punto final de la us-west-2 región, debe crear un registro de direcciones en la PHZ con un alias para el punto final de la VPC deseado.

En primer lugar, asegúrese de que las VPC de cada región estén asociadas a la PHZ que creó.

Al implementar un punto final en varias zonas de disponibilidad, la dirección IP del punto final devuelto por el DNS procederá de cualquiera de las subredes de la zona de disponibilidad que esté asignada.

Al invocar el punto final, utilice el nombre de dominio completo (FQDN) que se encuentra en la PHZ.

Acceso verificado de AWS

Acceso verificado de AWS ofrece un acceso seguro a las aplicaciones de una red privada sin una VPN. Evalúa las solicitudes en tiempo real, como la identidad, el dispositivo y la ubicación. Este servicio permite el acceso a las aplicaciones en función de la política y conecta a los usuarios mediante la mejora de la seguridad de la organización. El acceso verificado proporciona acceso a aplicaciones privadas al actuar como un proxy inverso que reconoce la identidad. La identidad del usuario y el estado del dispositivo, si corresponde, se analizan antes de enrutar el tráfico a la aplicación.

El siguiente diagrama brinda información general de alto nivel sobre Acceso verificado. Los usuarios envían solicitudes para acceder a una aplicación. Acceso verificado evalúa la solicitud en función de la política de acceso del grupo y de cualquier política de punto de conexión específica de la aplicación. Si se permite el acceso, la solicitud se envía a la aplicación a través del punto de conexión.

Descripción general del acceso verificado

Los componentes principales de una Acceso verificado de AWS arquitectura son:

• Instancias de Acceso verificado: una instancia evalúa las solicitudes de aplicación y concede el acceso solo cuando se cumplen los requisitos de seguridad.

• Puntos de conexión de Acceso verificado: cada punto de conexión representa una aplicación. Un punto final puede ser un NLB, un ALB o una interfaz de red.

• Grupo de Acceso verificado: conjunto de puntos de conexión de Acceso verificado. Se recomienda agrupar los puntos de conexión de las aplicaciones con requisitos de seguridad similares a fin de simplificar la administración de las políticas.

• Políticas de acceso: conjunto de reglas definidas por el usuario que determinan si se debe permitir o denegar el acceso a una aplicación.

• Proveedores de confianza: el acceso verificado es un servicio que facilita la administración de las identidades de los usuarios y los estados de seguridad de los dispositivos. Es compatible con proveedores de confianza AWS tanto como de terceros, por lo que es necesario adjuntar al menos un proveedor de confianza a cada instancia de Verified Access. Cada una de estas instancias puede incluir un único proveedor de confianza de identidad, así como varios proveedores de confianza de dispositivos.

• Datos de confianza: los datos de seguridad que tu proveedor de confianza envía a Verified Access, como la dirección de correo electrónico de un usuario o el grupo al que pertenece, se evalúan en función de tus políticas de acceso cada vez que se recibe una solicitud de solicitud.

Puedes encontrar más información en las publicaciones del blog de Verified Access.