AWS Verified Access ahora admite el acceso seguro a recursos a través de protocolos que no son HTTP(S) (en versión preliminar) | Servicios web de Amazon

AWS Verified Access proporciona acceso seguro a sus aplicaciones y recursos corporativos sin una red privada virtual (VPN). lanzamos Acceso verificado en vista previa en re:Invent hace 2 años como una forma de proporcionar acceso seguro y sin VPN a aplicaciones corporativas, lo que permite a las organizaciones administrar el acceso a la red en función de la identidad y la seguridad del dispositivo en lugar de direcciones IP, lo que aumenta el control y la seguridad sobre el acceso a las aplicaciones.

Hoy, Acceso verificado está lanzando una vista previa de sus capacidades de acceso seguro sin VPN a aplicaciones y recursos que no son HTTP(S), lo que permite un acceso de confianza cero a recursos corporativos a través de protocolos como Secure Shell (SSH) y Remote Desktop Protocol (RDP).

Las organizaciones requieren cada vez más acceso remoto seguro a recursos internos como bases de datos, escritorios remotos e instancias de Amazon Elastic Compute Cloud (Amazon EC2). Las soluciones VPN tradicionales, aunque efectivas para el acceso a la red, a menudo otorgan amplios privilegios y no admiten controles de acceso granulares, lo que puede exponer la infraestructura con datos confidenciales. Aunque algunas organizaciones utilizan hosts bastión para mediar en el acceso, este enfoque puede crear complejidad e inconsistencias en las políticas entre aplicaciones HTTP(S) y no HTTP(S). Con el aumento de las arquitecturas de confianza cero, estas brechas resaltan la necesidad de una solución de acceso seguro que extienda políticas de acceso consistentes a todas las aplicaciones y recursos.

Acceso verificado aborda estas necesidades proporcionando controles de acceso de confianza cero para sus aplicaciones y recursos corporativos. Al admitir protocolos como SSH, RDP o Java Database Connectivity (JDBC) o Open Database Connectivity (ODBC), Acceso verificado simplifica sus operaciones de seguridad. Ahora puede establecer políticas de acceso uniformes y contextuales en todas sus aplicaciones y recursos corporativos. Acceso verificado evalúa cada solicitud de acceso en tiempo real, asegurándose de que el acceso se otorgue solo a los usuarios que cumplan con requisitos específicos de identidad y seguridad del dispositivo. Además, elimina la necesidad de VPN independientes o hosts bastión, lo que agiliza las operaciones y reduce el riesgo de acceso con privilegios excesivos.

Una de mis capacidades favoritas es incorporar un grupo de recursos especificando su enrutamiento entre dominios sin clase (CIDR) IP y sus puertos, en lugar de incorporar un recurso a la vez. Acceso verificado crea automáticamente registros DNS para cada recurso activo dentro del rango CIDR especificado. Esto elimina la necesidad de una configuración DNS manual y, por lo tanto, los usuarios pueden conectarse a nuevos recursos al instante.

Uso de acceso verificado para acceso que no sea HTTPS
Configurando Acceso verificado para el acceso no HTTPS no es muy diferente de lo que existe hoy. Puede leer la publicación del blog que escribí para el lanzamiento de la versión preliminar hace 2 años o el tutorial Comenzar con Verified Access para saber cómo comenzar.

Acceso verificado propone dos nuevos tipos de objetivos de punto final: un objetivo para un único recurso y un objetivo para múltiples recursos.

Con el interfaz de red, equilibrador de carga o destino de punto final RDS puede proporcionar acceso a un recurso individual, como una instancia de Amazon Relational Database Service (Amazon RDS) o una aplicación TCP arbitraria liderada por un Network Load Balancer o una interfaz de red elástica. Este tipo de punto final de destino se define mediante una combinación de un tipo de destino (como un equilibrador de carga o una interfaz de red) y un rango de puertos TCP. Acceso verificado proporcionará un nombre DNS para cada punto final en el momento de su creación. A Acceso verificado Se asigna un nombre DNS para cada destino. Este es el nombre que utilizarán los usuarios finales para acceder de forma segura al recurso.

Con destino del punto final CIDR de redlos recursos se definen mediante un CIDR de IP y un rango de puertos. A través de este tipo de destino de punto final, puede proporcionar fácilmente acceso seguro a recursos efímeros, como instancias EC2, a través de protocolos como SSH y RDP. Esto se hace sin tener que realizar ninguna acción, como crear o eliminar destinos de punto final cada vez que se agrega o elimina un recurso. Siempre que a estos recursos se les asigne una dirección IP del CIDR definido, Acceso verificado proporciona un registro DNS público único para cada IP activa detectada en el CIDR definido.

Aquí hay un diagrama de la configuración de esta demostración.

Parte 1: Como administrador de acceso verificado

como un Acceso verificado administrador, creo la instancia de acceso verificado, el proveedor de confianza, el grupo de acceso, el punto final y las políticas de acceso, permitiendo el acceso del usuario final al servidor SSH.

Para esta demostración, configuro un Acceso verificado destino del punto final CIDR de la red. selecciono tcp como Protocolo y CIDR de red como Tipo de punto final. Me aseguro de que CIDR El rango está dentro de uno de los VPC dónde están mis recursos objetivo. selecciono el TCP Rangos de puertos y el Subredes dentro del VPC.

Este es un buen momento para estirar las piernas y volver a llenar tu taza de café, se necesitan unos minutos para crear el punto final.

Una vez, el estado es ✅ Activolanzo una instancia EC2 en una nube privada virtual de Amazon (Amazon VPC). Habilito SSH y configuro el grupo de seguridad de la instancia para acceder solo a las solicitudes provenientes de la VPC. Unos minutos más tarde, puedo ver que se detectó la IP de la instancia y se le asignó un nombre DNS para conectarme desde el Acceso verificado aplicación cliente.

También tengo la opción durante la configuración de delegar mi propio subdominio DNS, como secure.mycompany.comy Acceso verificado asignará nombres DNS para los recursos dentro de ese subdominio.

Crear una política de acceso

En esta etapa, no hay ninguna política definida en el punto final de acceso verificado. Denegará todas las solicitudes de forma predeterminada.

en el Grupos de acceso verificados página, selecciono el Política pestaña. Luego selecciono el Modificar la política de punto final de acceso verificado Botón para crear una política de acceso.

Introduzco una política que permite a cualquier persona que esté autenticada y tenga una dirección de correo electrónico que termine en @amazon.com. Esta es la dirección de correo electrónico que utilicé para el usuario definido en AWS IAM Identity Center. Tenga en cuenta que el nombre después context es el nombre que ingresé como Nombre de referencia de política cuando creé el Proveedor de confianza de acceso verificado. La página de documentación tiene los detalles de la sintaxis de la política, los atributos y los operadores que puedo usar.

permit(principal, action, resource)
when {
    context.awsnewsblog.user.email.address like "*@amazon.com"
};

Después de unos minutos, Verified Access actualiza la política y se convierte en Activo de nuevo.

Distribuir la configuración a los clientes.

La última tarea como Acceso verificado El administrador debe extraer el archivo de configuración JSON de las aplicaciones cliente.

Recupero el archivo de configuración de la aplicación cliente con la interfaz de línea de comandos de AWS (AWS CLI). Como administrador del sistema, distribuiré esta configuración a cada máquina cliente.

aws ec2 export-verified-access-instance-client-configuration \
     --verified-access-instance-id "vai-0dbf2c4c011083069"

{
    "Version": "1.0",
    "VerifiedAccessInstanceId": "vai-0dbf2c4c011083069",
    "Region": "us-east-1",
    "DeviceTrustProviders": [],
    "UserTrustProvider": {
        "Type": "iam-identity-center",
        "Scopes": "verified_access:application:connect",
        "Issuer": "https://identitycenter.amazonaws.com/ssoins-xxxx",
        "PkceEnabled": true
    },
    "OpenVpnConfigurations": [
        {
            "Config": "Y2...bWU=",
            "Routes": [
                {
                    "Cidr": "2600:1f10:4a02:8700::/57"
                }
            ]
        }
    ]
}

Ahora que tengo un recurso al que conectarme y el Acceso verificado infraestructura existente, permítame mostrarle la experiencia del usuario final para acceder a un punto final de red.

Parte 2: Como usuario final

Como usuario final, recibo un enlace para descargar e instalar el Acceso verificado Aplicación Cliente de Conectividad. Admitimos clientes de Windows y macOS en el momento de escribir este artículo.

Instalo el archivo de configuración que recibí de mi administrador. yo uso ClientConfig1.json como el nombre del archivo y copio el archivo a C:\ProgramData\Connectivity Client en Windows o /Library/Application\ Support/Connectivity\ Client en MacOS.

Este es el mismo archivo de configuración para todos los usuarios y el administrador del sistema puede enviar el archivo a todas las máquinas cliente mediante una herramienta de administración de terminales.

Inicio la aplicación Connectivity Client. yo elijo Iniciar sesión para iniciar la secuencia de autenticación.

La autenticación abre mi navegador web en la página de autenticación de mi proveedor de identidad. La pantalla exacta y la secuencia de inicio de sesión varían de un proveedor a otro. Después de autenticarme, el Cliente de conectividad crea el túnel seguro para acceder a mi recurso, una instancia EC2 para esta demostración.

Una vez que el estado es Conectado, Puedo conectarme de forma segura al recurso, usando el nombre DNS proporcionado por Acceso verificado. En una aplicación de terminal, escribo el ssh comando para iniciar la conexión.

Para esta demostración, configuré un dominio DNS delegado secure.mycompany.com para acceso verificado. La dirección DNS que recibí para la instancia EC2 es 10-0-1-199.awsnews.secure.mycompany.com.

$ ssh -i mykey.pem [email protected]

   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
Last login: Sat Nov 17 20:17:46 2024 from 1.2.3.4

$

Disponibilidad y precios
Acceso verificado está disponible como versión preliminar pública en 18 regiones de AWS: EE. UU. Este (Ohio, Norte de Virginia), EE. UU. Oeste (Norte de California, Oregón), Asia Pacífico (Yakarta, Mumbai, Seúl, Singapur, Sídney, Tokio), Canadá (Central ), Europa (Frankfurt, Irlanda, Londres, Milán, Estocolmo), Israel (Tel Aviv) y América del Sur (São Paulo).

Te cobran por cada hora que su punto final de acceso verificado no HTTP(S) permanezca activo y por conexión. Las primeras 100 conexiones por mes en cada terminal de Verified Access son gratuitas. Para obtener más información, consulte Precios de acceso verificado de AWS.

Con Acceso verificado para aplicaciones HTTP(S) y no HTTP(S), puede unificar los controles de acceso a sus aplicaciones y sistemas privados y aplicar políticas de confianza cero de manera uniforme a todas las aplicaciones y recursos SSH, RDP y HTTP(S). Reduce la complejidad de su infraestructura de red y le ayuda a implementar un acceso de confianza cero a sus aplicaciones y recursos. Finalmente, se adapta a su infraestructura en crecimiento, automatiza la configuración de DNS y admite implementaciones a gran escala sin registro de recursos específicos.

Ve, prueba Acceso verificado ¡Hoy y comparte tus comentarios con el equipo!

— seb