TecTop
|
|
Hoy, anunciamos la vista previa de AWS Verified Access, un nuevo servicio de conectividad segura que permite a las empresas habilitar el acceso seguro local o remoto para sus aplicaciones corporativas sin necesidad de una VPN.
Tradicionalmente, una VPN garantiza el acceso remoto a las aplicaciones cuando se está de viaje o se trabaja desde casa. Una vez que la fuerza de trabajo remota se autentica en la VPN, tiene acceso a una amplia gama de aplicaciones según las múltiples políticas definidas en sistemas aislados, como la puerta de enlace VPN, los firewalls, el proveedor de identidad, la solución de administración de dispositivos empresariales, etc. Estos las políticas generalmente son administradas por diferentes equipos, lo que puede crear superposiciones, lo que dificulta el diagnóstico de problemas de acceso a la aplicación. Las aplicaciones internas a menudo se basan en protocolos de autenticación más antiguos, como Kerberosque se construyeron con la LAN en mente, en lugar de los protocolos modernos, como OIDC, que se ajustan mejor a los patrones empresariales modernos. Los clientes nos dijeron que las actualizaciones de políticas pueden tardar meses en implementarse.
Verified Access se crea utilizando los principios de seguridad de AWS Zero Trust. Zero Trust es un modelo conceptual y un conjunto asociado de mecanismos que se centran en proporcionar controles de seguridad en torno a los activos digitales que no dependen única o fundamentalmente de los controles de red tradicionales o los perímetros de red.
Verified Access mejora la postura de seguridad de su organización al aprovechar múltiples entradas de seguridad para otorgar acceso a las aplicaciones. Otorga acceso a las aplicaciones solo cuando los usuarios y sus dispositivos cumplen con los requisitos de seguridad especificados. Ejemplos de entradas son la identidad y el rol del usuario o la postura de seguridad del dispositivo, entre otros. Verified Access valida cada solicitud de aplicación, independientemente del usuario o la red, antes de otorgar acceso. La evaluación de cada solicitud de acceso a la aplicación permite que Verified Access adapte la postura de seguridad en función de las condiciones cambiantes. Por ejemplo, si la seguridad del dispositivo indica que la postura de su dispositivo no cumple con los requisitos, el Acceso verificado ya no le permitirá acceder a la aplicación.
En mi opinión, hay tres beneficios principales al adoptar Verified Access:
Está fácil de usar para los administradores de TI. Como administrador de TI, ahora puede configurar fácilmente aplicaciones para acceso remoto seguro. Proporciona un único punto de configuración para administrar y hacer cumplir una política de seguridad multisistema para permitir o denegar el acceso a sus aplicaciones corporativas.
Eso proporciona un ecosistema abierto que le permite conservar su proveedor de identidad existente y el sistema de administración de dispositivos. Enumeré a todos nuestros socios al final de esta publicación.
Está fácil de usar para los usuarios finales. Este es mi preferido. Su fuerza laboral ya no está obligada a usar un cliente VPN. Un simple complemento del navegador es suficiente para otorgar acceso de forma segura cuando el usuario y el dispositivo están identificados y verificados. A partir de hoy, admitimos los navegadores web Chrome y Firefox. Esto es algo sobre lo que puedo compartir mi experiencia personal. Amazon adoptó una estrategia sin VPN hace unos años. Ha sido un alivio para mis colegas y para mí poder acceder a la mayoría de nuestras aplicaciones web internas sin tener que iniciar un cliente VPN y mantenerlo conectado todo el día.
Veámoslo en acción
Implementé un servidor web en una VPC privada y lo expuse a mis usuarios finales a través de un balanceador de carga de aplicaciones privadas (https://demo.seb.go-aws.com). Creé un certificado TLS para el punto final externo de la aplicación (secured.seb.go-aws.com). También configuré AWS Identity Center (sucesor de AWS SSO). En esta demostración, lo usaré como fuente para las identidades de los usuarios. Ahora estoy listo para exponer esta aplicación a mi fuerza laboral remota.
La creación de un punto final de Verified Access es un proceso de cuatro pasos. Para comenzar, navego a la página de VPC de la Consola de administración de AWS. Primero creo el proveedor de confianza. Un proveedor de confianza mantiene y administra la información de identidad de los usuarios y dispositivos. Cuando se realiza una solicitud de solicitud, Verified Access evaluará la información de identidad enviada por el proveedor de confianza antes de permitir o denegar la solicitud de solicitud. Yo selecciono Proveedor de confianza de acceso verificado en el panel de navegación del lado izquierdo.
Sobre el Crear proveedor de confianza de acceso verificado página, ingreso un Nombre y un opcional Descripción. entro en el Nombre de referencia de la política, un identificador que se utilizará cuando se trabaje con reglas de política. Selecciono la fuente de confianza: Proveedor de confianza del usuario. Para esta demostración, selecciono Centro de identidad de IAM como fuente de confianza para las identidades de los usuarios. Verified Access también funciona con otros Conexión de identificación abierta-proveedores compatibles. Finalmente, selecciono Crear proveedor de confianza de acceso verificado.
Puedo repetir la operación cuando tengo varios proveedores de confianza. Por ejemplo, podría tener un proveedor de confianza basado en identidad para verificar la identidad de mis usuarios finales y un proveedor de confianza basado en dispositivos para verificar la postura de seguridad de sus dispositivos.
Luego creo la instancia de identidad verificada. Una instancia de acceso verificado es una entidad regional de AWS que evalúa las solicitudes de aplicaciones y otorga acceso solo cuando se cumplen sus requisitos de seguridad.
Sobre el Crear instancia de acceso verificado página, ingreso un Nombre y un opcional Descripción. Selecciono el proveedor de confianza que acabo de crear. Puedo agregar tipos de proveedores de confianza adicionales una vez que se crea la instancia de Verified Access.
Tercero, creo un grupo de Acceso Verificado.
Un grupo de acceso verificado es una colección de aplicaciones que tienen requisitos de seguridad similares. Cada aplicación dentro de un grupo de Acceso verificado comparte una política a nivel de grupo. Por ejemplo, puede agrupar todas las aplicaciones para usuarios de «finanzas» y usar una política común. Esto simplifica la gestión de su política. Puede usar una sola política para un grupo de aplicaciones con necesidades de acceso similares.
Sobre el Crear grupo de acceso verificado página, ingreso un Nombre solamente. Introduciré una póliza en una etapa posterior.
El cuarto y último paso antes de probar mi configuración es crear el punto final.
Un acceso verificado punto final es un recurso regional que especifica la aplicación a la que Verified Access proporcionará acceso. Aquí es donde se conectan sus usuarios finales. Cada punto final tiene su propio nombre DNS y certificado TLS. Después de haber evaluado las solicitudes entrantes, el punto final reenvía las solicitudes autorizadas a su aplicación interna, ya sea un balanceador de carga interno o una interfaz de red. Verified Access admite balanceadores de carga a nivel de red y de aplicación.
Sobre el Crear punto final de acceso verificado página, ingreso un Nombre y Descripción. hago referencia a la Grupo de acceso verificado que acabo de crear.
En el Detalles de la aplicación sección, bajo Dominio de aplicación, ingreso el nombre DNS que los usuarios finales usarán para acceder a la aplicación. Para esta demostración, utilizo secured.seb.go-aws.com. Por debajo ARN del certificado de dominio, selecciono un certificado TLS que coincida con el nombre DNS. Creé el certificado usando AWS Certificate Manager.
Sobre el Detalles del punto final sección, selecciono VPC como Tipo de archivo adjunto. Selecciono uno o varios Grupos de seguridad para adjuntar a este punto final. yo entro awsnoticiasblog como Prefijo de dominio de punto final. Selecciono el balanceador de carga como Tipo de punto final. selecciono el Protocolo (HTTP), luego entro en el Puerto (80). selecciono el ARN del equilibrador de carga y el privado Subredes donde se implementa mi balanceador de carga.
De nuevo, dejo el Detalle de la pólizasección s vacía. Definiré una política en el grupo en su lugar. Cuando termino, selecciono Crear punto final de acceso verificado. Puede tardar unos minutos en crearse.
Ahora es el momento de tomar un café y estirar las piernas. Cuando vuelvo, veo que el punto final de Verified Access es ✅ Activo. copio el Dominio de punto final y agregarlo como un registro CNAME al nombre DNS de mi aplicación (secured.seb.go-aws.com). Yo uso Amazon Route 53 para esto, pero también puede usar su servidor DNS existente.
Luego, apunto mi navegador favorito a https://secured.seb.go-aws.com. El navegador se redirige a IAM Identity Center (anteriormente AWS SSO). Introduzco el nombre de usuario y la contraseña de mi usuario de prueba. No estoy agregando una captura de pantalla para esto. Después de la redirección, recibo el mensaje de error: No autorizado. Esto es de esperar porque no hay una política definida en el extremo de Acceso verificado. Niega todas las solicitudes por defecto.
Sobre el Grupos de acceso verificado página, selecciono la 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.
Entro en una política que permite que cualquiera se autentique 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 Identity Center. Tenga en cuenta que el nombre después de context es el nombre que ingresé como Nombre de referencia de la 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 otra vez. Obligo a mi navegador a actualizarse y veo que la aplicación interna ahora está disponible para mi usuario autenticado.
Precios y disponibilidad
AWS Verified Access ahora está disponible en versión preliminar en 10 regiones de AWS: EE. UU. Este (Ohio, N. Virginia), EE. UU. Oeste (Norte de California, Oregón), Asia Pacífico (Sídney), Canadá (Central), París) y América del Sur (São Paulo).
Como de costumbre, el precio se basa en su uso. No hay precio por adelantado o fijo. Cobramos por aplicación (punto final de acceso verificado) por hora, con niveles según la cantidad de aplicaciones. Los precios comienzan en la región EE. UU. Este (Norte de Virginia) en $ 0,27 por punto final de Access verificado y por hora. Este precio baja a $0.20 por punto final por hora cuando tiene más de 200 aplicaciones.
Además de esto, hay un cargo de $0.02 por GB por los datos procesados por Verified Access. También incurre en cargos estándar de transferencia de datos de AWS por todos los datos transferidos mediante el acceso verificado.
Este modelo de facturación facilita comenzar de a poco y luego crecer a su propio ritmo.
Ve y configura tu primer punto de acceso de Verified Access hoy.
