Proteger el acceso de Quick desde redes corporativas con AWS PrivateLink

Cuando los datos empresariales están detrás de un firewall corporativo o en un centro de datos local privado, no existe una ruta de red directa desde AWS, aunque los agentes de IA y los paneles de Amazon Quick pueden consultar prácticamente cualquier fuente de datos. Los administradores deben asegurarse de que sus datos empresariales confidenciales no queden expuestos a la internet pública y, al mismo tiempo, sean accesibles para obtener información y realizar acciones impulsadas por IA.

Para muchas empresas, enrutar el tráfico por la internet pública introduce un riesgo inaceptable. Los marcos regulatorios como HIPAA, FedRAMP y PCI-DSS a menudo exigen que los datos confidenciales permanezcan dentro de límites de red controlados. Incluso donde el cumplimiento no es el principal factor, exponer las rutas internas de datos aumenta la superficie de ataque, complica las pistas de auditoría e introduce una latencia variable que puede degradar la experiencia del usuario.

Este tutorial muestra cómo conectar fuentes de datos locales a Amazon Quick de forma privada, sin que el tráfico atraviese la internet pública. Se asume que ya tiene AWS Direct Connect o una VPN de AWS Site-to-Site que vincula su entorno local con su nube privada virtual (VPC). A partir de esa base, configuramos VPC endpoints potenciados por AWS PrivateLink para que Quick pueda alcanzar sus recursos privados a través de la columna vertebral de AWS, y luego añadimos grupos de seguridad y políticas de VPC endpoint para una defensa en profundidad.

Al finalizar, tendrá una arquitectura de red que mantiene el tráfico entre Quick y sus fuentes de datos locales fuera de la internet pública, reduciendo la superficie de ataque, proporcionando una conectividad de baja latencia consistente y ofreciéndole una pista de auditoría clara para el cumplimiento normativo.

Amazon Quick y el establecimiento de conectividad de red privada

Amazon Quick es un espacio de trabajo impulsado por IA que reúne búsqueda, análisis, investigación y automatización en una única experiencia conversacional. Comprender qué componentes acceden a su red privada, y de qué manera, determina la arquitectura en las secciones que siguen.

El acceso a datos en Amazon Quick se divide en dos rutas. El tráfico orientado al usuario cubre a cualquier persona que abra la consola de Quick, interactúe con un panel, realice una llamada de API o use Quick Desktop. Todo esto se enruta a través de VPC endpoints (consulte VPC endpoints para el acceso de usuarios y API), manteniendo las sesiones de usuario fuera de la internet pública.

El tráfico de obtención de datos es cuando Quick mismo accede a su red para extraer datos. Esto lo manejan las VPC connections (consulte VPC connections para el acceso a fuentes de datos), y es donde se encuentran la mayoría de las decisiones de arquitectura. Las características e integraciones que inician conexiones de obtención de datos son:

• Amazon Quick Sight consulta bases de datos locales (PostgreSQL, MySQL, SQL Server, Oracle y otras) directamente a través de ENI ubicadas en su VPC. Es el mayor consumidor de VPC connections.
• Amazon Quick Flows y Amazon Quick Automate son funciones de automatización independientes. Flows maneja tareas repetibles. Automate maneja orquestaciones complejas de varios sistemas con intervención humana. Ambos invocan conectores de acción, incluidos servidores MCP alojados de forma privada en su VPC. Cualquier flujo de trabajo que llame a una API interna se enruta por esta vía.
• Quick Agents son la base de todas las interacciones conversacionales y pueden invocar conectores de acción directamente. Cuando un agente personalizado llama a un servidor MCP alojado de forma privada o a una API interna, el tráfico fluye a través de la VPC connection.
• Amazon Quick Index construye una capa de búsqueda unificada a través de fuentes conectadas como Confluence, SharePoint y Amazon Simple Storage Service (Amazon S3). Para los datos dentro de su VPC o locales, las VPC connections de bases de conocimiento actualmente solo son compatibles con Amazon Redshift. Fuentes como Confluence, SharePoint, Box, Google Drive, OneDrive y Amazon S3 no pueden usar una VPC connection de Quick en este momento (consulte Fuentes de datos VPC compatibles). Aún puede restringir el acceso al bucket de Amazon S3 a un VPC endpoint mediante una política de bucket, que es un mecanismo independiente.
• Amazon Quick Research accede a fuentes empresariales detrás del firewall junto con datos de la internet pública para sus informes con citas respaldadas, usando la VPC connection al alcanzar fuentes privadas.
• Apps in Quick crea aplicaciones web interactivas sobre datos estructurados y conectores de acción, heredando la misma conectividad VPC que Quick Sight y Flows.
• Quick Spaces organiza el contenido de las funciones anteriores, pero no inicia sus propias conexiones de datos.

Estas dos rutas de tráfico requieren dos mecanismos distintos de conectividad privada que funcionan juntos:

• VPC endpoints (AWS PrivateLink): Gestiona el tráfico orientado al usuario, como el acceso al sitio web de Quick, las llamadas a la API y el acceso administrativo. Esto mantiene el tráfico de usuarios fuera de la internet pública.
• Conexiones de VPC: Gestiona el tráfico de las fuentes de datos. Amazon Quick accede a su VPC (y, por extensión, a su red local) para obtener datos de bases de datos, fuentes de base de conocimiento de Amazon Redshift y API internas. Estas se configuran dentro de la consola de Quick.

Configuración de la conectividad privada

Esta sección recorre, en orden, los cuatro componentes básicos: endpoints de VPC para el acceso de usuarios y API, conexiones de VPC para el acceso a fuentes de datos, endpoints de VPC para servicios de datos de AWS y acceso de salida a los dominios externos requeridos.

Requisitos previos

Antes de configurar la conectividad privada para Quick, asegúrese de que se cumplan los siguientes requisitos:

• Una cuenta de AWS activa con una suscripción a Amazon Quick Enterprise (las conexiones VPC requieren la edición Enterprise).
• Una VPC existente en la Región de AWS donde Quick está desplegado.
• Una Región de AWS compatible. Los VPC endpoints del sitio web de Quick no están disponibles en las Regiones de AWS China ni en las Regiones AWS GovCloud (US).
• Una conexión AWS Direct Connect o una Site-to-Site VPN establecida entre su red local y su VPC. Esta es la ruta privada que transporta el tráfico desde su centro de datos hacia AWS.
• Permisos de AWS Identity and Access Management (IAM) para crear y administrar VPC endpoints, security groups y la administración de Quick. Para crear conexiones VPC, la identidad de IAM del administrador también necesita quicksight:CreateVPCConnection, quicksight:DescribeVPCConnection, quicksight:ListVPCConnections, quicksight:UpdateVPCConnection, quicksight:DeleteVPCConnection, ec2:DescribeSubnets, ec2:DescribeVpcs, ec2:DescribeSecurityGroups, iam:ListRoles, y iam:PassRole con el ámbito limitado al rol de ejecución de la conexión VPC.
• Acceso a la gestión de DNS de su organización (zonas alojadas privadas de Route 53 o reenviadores DNS locales), ya que la resolución DNS privada enruta el tráfico a través de VPC endpoints en lugar de direcciones públicas.

VPC endpoints para el acceso de usuarios y API (AWS PrivateLink)

Los VPC endpoints basados en PrivateLink gestionan todo el tráfico orientado al usuario hacia Amazon Quick, incluidos el sitio web, las llamadas a la API y el contenido incrustado. Evitan que los usuarios necesiten atravesar la internet pública para acceder a la consola de Amazon Quick.

Figura 1: Acceso privado a Amazon Quick desde un centro de datos corporativo a través de un VPC endpoint

Como se muestra en la Figura 1: (1) un cliente en la red corporativa envía una solicitud a Quick; (2) la solicitud viaja por AWS Direct Connect, a través de la puerta de enlace de Direct Connect, hacia su VPC; (3) el VPC endpoint de Quick evalúa la política del endpoint y permite o deniega la solicitud; (4) las solicitudes permitidas llegan a Amazon Quick a través de la red de AWS.

Planificación de la arquitectura de sus VPC endpoints

Al planificar la arquitectura de sus endpoints, comience por identificar la Región de AWS donde está desplegada su cuenta de Quick, ya que los VPC endpoints deben estar en la misma Región. Elija subnets en varias Availability Zones para la colocación de los ENI de los endpoints, y asegúrese de que esas subnets tengan rutas hacia su red local a través de Direct Connect o VPN.

Diseñe security groups que restrinjan el tráfico en los ENI de los endpoints solo a los puertos y rangos de origen necesarios. Si desea que todo el tráfico se enrute de forma privada (incluidas las llamadas que Amazon Quick realiza a Amazon S3, Amazon Redshift y Amazon Athena), planifique también VPC endpoints para esos servicios (consulte Configuración de VPC endpoints para fuentes de datos).

Creación de VPC endpoints para Quick

Quick requiere dos VPC endpoints de interfaz para un acceso completamente privado:

• Endpoint de acceso al sitio web – Nombre del servicio com.amazonaws.<region>.quicksight-website. Esto gestiona la mayor parte del tráfico de usuarios hacia la consola de Quick. Los nombres DNS privados para el sitio web de Quick difieren de la URL pública, por lo que debe crear un registro A para <region>.quicksight.aws.amazon.com apuntando al VPC endpoint.
• Endpoint de acceso a la API – Nombre del servicio com.amazonaws.<region>.quicksight. Esto gestiona las llamadas programáticas a la API. Cuando el DNS privado está habilitado, las llamadas API existentes a quicksight.<region>.amazonaws.com se enrutan automáticamente a través del VPC endpoint sin necesidad de configuración DNS adicional. Para el cumplimiento de FIPS, use com.amazonaws.<region>.quicksight-fips.

Nota: No todas las API de Quick están disponibles a través del VPC endpoint de la API. Las siguientes 13 API no son compatibles: las API de conectores de acciones (CreateActionConnector, DeleteActionConnector, DescribeActionConnector, DescribeActionConnectorPermissions, ListActionConnectors, SearchActionConnectors, UpdateActionConnector, UpdateActionConnectorPermissions) y las API de flujos (GetFlowMetadata, GetFlowPermissions, ListFlows, SearchFlows, UpdateFlowPermissions). La automatización que gestiona conectores de acciones o flujos de manera programática necesita una ruta hacia el endpoint de la API pública. Consulte Quick y los VPC endpoints de interfaz.

Si los administradores inician sesión en Amazon Quick como usuarios de IAM a través de la VPC, cree también los endpoints de la consola de AWS Management Console:

• com.amazonaws.<region>.console.
• com.amazonaws.<region>.signin.

Para crear el endpoint del sitio web en la consola de Amazon Virtual Private Cloud (Amazon VPC):

1. Abra la consola de Amazon VPC. En el panel de navegación, en PrivateLink and Lattice, elija Endpoints, luego elija Create endpoint.
2. Escriba una etiqueta Name (por ejemplo, my-quicksight-vpc-endpoint) y, en Type, elija AWS services.
3. En Services, busque com.amazonaws.<region>.quicksight y seleccione com.amazonaws.<region>.quicksight-website (Figura 2).

Figura 2: Nombrando el endpoint y seleccionando el servicio de endpoint Quick website

1. En Network settings, seleccione su VPC. En Additional settings, mantenga seleccionada la opción Enable private DNS name .
2. Seleccione subredes en al menos dos Availability Zones y luego seleccione el grupo de seguridad para las ENIs del endpoint (Figura 3).

Figura 3: Selección de la VPC, el DNS privado, las subredes y el grupo de seguridad para el endpoint

1. Elija una Policy (consulte la siguiente sección Configuración de políticas de endpoints de VPC), añada etiquetas y elija Create endpoint (Figura 4).

Figura 4: Elección de la política del endpoint y creación del endpoint

1. Repita estos pasos para el endpoint de la API, com.amazonaws.<region>.quicksight.

Configuración de la resolución DNS

Para el endpoint del sitio web, cree un registro A para <region>.quicksight.aws.amazon.com y apúntelo al nombre DNS del endpoint de la VPC. De esta manera, cuando los usuarios de su red corporativa resuelvan la URL de Quick, el tráfico se enruta a través del endpoint privado en lugar de la internet pública. Para el endpoint de la API, habilitar el DNS privado en el endpoint de la VPC es suficiente, ya que las llamadas a la API se resuelven automáticamente en las direcciones IP privadas del endpoint.

Una zona alojada privada de Route 53 solo responde a consultas desde dentro de las VPC asociadas con ella. Como sus usuarios se conectan desde la red corporativa, configure sus servidores DNS locales para reenviar las consultas de <region>.quicksight.aws.amazon.com a un endpoint de entrada de Route 53 Resolver en la VPC (o aloje un registro equivalente en su DNS local). Finalmente, valide la resolución DNS desde su red corporativa para confirmar que las solicitudes se resuelven en direcciones IP privadas dentro de su VPC en lugar de direcciones públicas.

Para crear el registro en Route 53:

1. En la consola de Route 53, elija Hosted zones, luego Create hosted zone.
2. Para Domain name, ingrese <region>.quicksight.aws.amazon.com (por ejemplo, us-east-1.quicksight.aws.amazon.com). Limitar la zona a su Región evita sobrescribir otros nombres de host de Quick. Elija Private hosted zone, asocie su VPC y elija Create hosted zone (Figura 5).

Figura 5: Creación de una zona alojada privada en Amazon Route 53

1. En la nueva zona alojada, elija Create record (Figura 6).

Figura 6: Creación de un registro en la nueva zona alojada privada

1. Deje Record name en blanco, elija el tipo de registro A, active Alias, elija Alias to VPC endpoint, seleccione su región y el nombre DNS del endpoint del sitio web, y elija Crear registros (Figura 7).

Figura 7: Creación de un registro A con alias que apunta al endpoint de VPC del sitio web de Quick

Configuración de las políticas de endpoints de VPC

Las políticas de endpoints de VPC restringen qué cuentas u organizaciones pueden usar el endpoint. Para Quick, las políticas pueden limitarse por ID de cuenta de AWS o por ID de organización. Para cambiar una política, abra el endpoint en la consola de Amazon VPC, elija la pestaña Policy y elija Edit Policy (Figura 8).

Limitación importante: Para el endpoint del sitio web de Quick, los campos Principal, Action, y Resource deben estar todos configurados en *. Las condiciones solo pueden especificarse contra los atributos aws:PrincipalAccount o aws:OrgId . Las políticas más restrictivas a nivel de acciones solo se admiten en el endpoint de API.

Ejemplo de política de endpoint del sitio web:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalAccount": ["012345678901"]
                }
            }
        }
    ]
}

Figura 8: Apertura de la política del endpoint desde la página de detalles del endpoint de VPC

Ejemplo de política de endpoint de API (restringida a acciones específicas):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "quicksight:DescribeUser",
                "quicksight:ListUsers"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalAccount": ["012345678901"]
                }
            }
        }
    ]
}

Figura 9: Edición de una política de endpoint de VPC personalizada

Conexiones de VPC para el acceso a fuentes de datos

Mientras que los endpoints de VPC gestionan el tráfico orientado al usuario, las conexiones de VPC gestionan la ruta del lado del servidor, lo que significa que Amazon Quick accede a su VPC para llegar a bases de datos, fuentes de la base de conocimiento de Amazon Redshift y API internas.

Cómo funcionan las conexiones de VPC

Amazon Quick Enterprise edition está completamente integrado con Amazon VPC. Cuando crea una conexión de VPC en Amazon Quick, está agregando interfaces de red elásticas (ENI) en las subredes de su VPC. Estas ENI permiten que Quick intercambie tráfico de red con los recursos dentro de su VPC y, por extensión, con todo lo alcanzable desde esa VPC, incluidos los sistemas locales conectados mediante Direct Connect o VPN.

Todos los controles de seguridad estándar de VPC se aplican a este tráfico. Las tablas de rutas, las ACL de red, las subredes y los grupos de seguridad rigen el tráfico hacia y desde Quick de la misma manera que rigen el tráfico entre cualquier otra instancia de su VPC. Esto significa que puede conectarse a:

• Bases de datos privadas no expuestas a internet público.
• Fuentes de datos locales alcanzables mediante Direct Connect o VPN.
• API internas accesibles por dirección IP dentro de su red.

Cree un grupo de seguridad dedicado (por ejemplo, QuickSight-VPC) para las ENI de la conexión de VPC. En el grupo de seguridad de cada fuente de datos, permita el tráfico entrante en el puerto de la base de datos desde ese ID de grupo de seguridad.

Nota para las conexiones de VPC creadas antes del 27 de abril de 2023: El grupo de seguridad asociado a la interfaz de red Quick no tiene estado. Debe añadir una regla de entrada que permita explícitamente el tráfico de retorno desde el grupo de seguridad de su fuente de datos en todos los puertos (0–65535), porque los paquetes de retorno usan puertos de destino asignados aleatoriamente. Las conexiones creadas después de esa fecha usan el comportamiento estándar con estado. Vea Grupos de seguridad: reglas de entrada y de salida.

Creación del rol de ejecución

Amazon Quick no crea por usted el rol de ejecución de la conexión de VPC. Antes de añadir la conexión, cree un rol de IAM dedicado (recomendado) o actualice un rol existente que ya confíe en Quick, como aws-quicksight-service-role-v0 usado en las capturas de pantalla de esta publicación. El rol necesita:

• Una política de permisos que otorgue las acciones de Amazon Elastic Compute Cloud (Amazon EC2) que Quick usa para gestionar sus ENI (Figura 10).
• Una política de confianza que permita quicksight.amazonaws.com asumir el rol. Solo los roles con esta política de confianza aparecen en la lista Execution role de la consola de Quick.

Política de permisos:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateNetworkInterface",
                "ec2:DeleteNetworkInterface",
                "ec2:ModifyNetworkInterfaceAttribute",
                "ec2:DescribeSubnets",
                "ec2:DescribeSecurityGroups"
            ],
            "Resource": "*"
        }
    ]
}

Figura 10: Adición de los permisos de Amazon EC2 requeridos por el rol de ejecución de la conexión de VPC

Política de confianza:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": { "Service": "quicksight.amazonaws.com" },
            "Action": "sts:AssumeRole"
        }
    ]
}

Configuración de una conexión VPC

Para crear una conexión de VPC en la consola de Quick:

1. Inicie sesión en Amazon Quick como administrador. Elija el icono de su perfil en la parte superior derecha y, a continuación, elija Gestionar cuenta (Figura 11). Si no ve esta opción, no es administrador de Quick.

Figura 11: Apertura de Administrar cuenta desde el menú Perfil rápido

1. En el panel de navegación, en Seguridad, elija Administrar conexiones de VPC (Figura 12), luego elige Agregar conexión de VPC.

Figura 12: Administrar conexiones VPC en Seguridad en la página Administrar cuenta

1. Proporcione lo siguiente (Figura 13):
   1. Una descripción Nombre de la conexión VPC.
   2. El ID de VPC de la VPC de destino. Esto no se puede cambiar más tarde.
   3. El Rol de ejecución que creaste en el paso anterior.
   4. Al menos dos subredes en diferentes Zonas de Disponibilidad.
   5. Al menos uno grupo de seguridad ID.
   6. (Opcional) Si el nombre de host de su base de datos debe resolverse mediante DNS privado, introduzca las direcciones IP de sus endpoints de entrada de Route 53 Resolver en Endpoints del resolvedor DNS.
2. Elegir AÑADIR.

Figura 13: Adición de una conexión VPC en la consola de Quick

El estado de la conexión muestra UNAVAILABLE hasta que Quick termina de aprovisionar los ENI, y luego cambia a AVAILABLE. Un estado de PARTIALLY AVAILABLE significa que uno de los ENI no está disponible, pero la conexión aún puede usarse.

Configuración de los endpoints VPC de origen de datos

Los endpoints VPC (PrivateLink, usado aquí para las API de servicios de AWS) y las conexiones VPC (ENI de Quick colocados en su VPC; vea Conexiones VPC para acceso a orígenes de datos) son mecanismos diferentes. Quick accede a otros servicios de AWS (Amazon S3, Amazon Redshift, Amazon Athena, AWS Secrets Manager) al recuperar datos para paneles y análisis. Si desea que todo el tráfico permanezca privado, incluidas las llamadas que Amazon Quick realiza a estos servicios de AWS, cree endpoints VPC de interfaz o de puerta de enlace para cada uno:

* Athena no es compatible como fuente de datos de conexión VPC. El endpoint de Athena mantiene el tráfico de la API de Athena solo en AWS PrivateLink.

Cree estos endpoints en la misma VPC donde se encuentran las ENI de Amazon Quick. Asegúrese de que las tablas de rutas y los grupos de seguridad permitan el tráfico entre las subredes de Amazon Quick y las subredes de los endpoints.

Habilitación del acceso a los dominios externos requeridos

Si bien el tráfico de datos entre Quick y sus fuentes locales permanece en la red privada, los navegadores de los usuarios aún necesitan acceder a un conjunto de dominios para el inicio de sesión, los recursos estáticos, las métricas del lado del cliente y las integraciones. Incluso con los endpoints de VPC configurados, los dominios sin compatibilidad con endpoints de VPC necesitan conectividad saliente, generalmente a través de su proxy corporativo o firewall. Si su cuenta usa IAM Identity Center, el inicio de sesión desde el navegador también requiere los endpoints públicos de inicio de sesión de AWS e IAM Identity Center (consulte Protección del acceso de los usuarios y la federación de identidades).

Dominios externos requeridos

Fuente: Dominios a los que accede Quick.

Guía de configuración:

• Para los dominios con compatibilidad de VPC endpoint (el sitio web y la API de Quick, signin.aws.amazon.comy Amazon S3), cree los VPC endpoints correspondientes y los registros DNS.
• Para los dominios sin compatibilidad de VPC endpoint, permítalos a través de su salida a internet corporativa (proxy de salida o firewall). Si el tráfico de los usuarios sale a través de su VPC, use una NAT gateway en una subred pública.
• Si su postura de seguridad requiere filtrado a nivel de URL, use un proxy de salida o reglas de filtrado de dominios de AWS Network Firewall para permitir únicamente los dominios enumerados anteriormente.
• Pruebe desde una estación de trabajo corporativa (o una instancia en la misma ruta de salida): nslookup y curl contra cada dominio, confirme la resolución DNS y el enrutamiento.

Aplicación de restricciones de VPC endpoint

Una vez que sus endpoints estén configurados y probados, puede exigir que todo acceso a su cuenta de Quick pase por el endpoint de la VPC, bloqueando por completo el acceso general a internet. Como resultado, los usuarios solo podrán acceder a Quick desde su red corporativa a través de la ruta privada que ha establecido.

Quick proporciona controles de restricción por IP y endpoint de VPC que limitan el acceso a la cuenta a una lista predefinida de rangos de IP, ID de VPC o ID de endpoints de VPC. Por ejemplo, puedes crear una regla que permita el acceso únicamente desde el endpoint de VPC utilizado para Direct Connect, lo que significa que cualquier persona que intente llegar a Quick desde la internet pública será rechazada.

Para configurar a través de la consola de Quick (solo los administradores que hayan iniciado sesión con credenciales de IAM pueden acceder a la página de restricciones):

1. Elige el icono de tu perfil y luego Administrar cuenta. Bajo Seguridad, elija Administrar restricciones de IP/VPC.
2. En el Restricción campo, introduzca el ID del endpoint de la VPC (por ejemplo, vpce-001122def) , introduzca un Descripción, y elija Añadir (Figura 14).
3. Elegir Guardar cambios para aplicar la regla.
4. Encender Aplicar restricciones.

Figura 14: Adición de una regla de endpoint de VPC en la página de restricciones de IP y endpoint de VPC

Alternativamente, configure a través de la AWS Command Line Interface (AWS CLI):

aws quicksight update-ip-restriction \
--aws-account-id ACCOUNT_ID \
--region REGION \
--enabled \
--vpc-endpoint-id-restriction-rule-map \
vpce-001122def=CorporateVpcEndpoint

Nota: UpdateIpRestriction reemplaza el mapa de reglas completo. Recupera tus reglas actuales con aws quicksight describe-ip-restriction e incluir cualquier regla existente en la actualización.

Consideraciones clave:

• Las reglas de IP y de endpoint de VPC se aplican al acceso web, integrado y móvil de Quick, lo que significa que no restringen el acceso a la API pública. Para restringir las llamadas a la API desde orígenes específicos, use políticas de IAM con aws:SourceIp o aws:SourceVpce condiciones.
• Asegúrate de que tu propia IP o tu VPC endpoint esté incluido en las reglas antes de activar las restricciones; de lo contrario, te quedarás bloqueado.
• Las reglas pueden tardar hasta 10 minutos en surtir pleno efecto.
• Puede combinar reglas de IP y reglas de VPC endpoint, de modo que se permita el tráfico si cumple cualquiera de los dos tipos de regla. Puede añadir hasta 100 reglas de IP y VPC endpoint combinadas.
• Las reglas de IP y de VPC endpoint se aplican en todas las regiones de AWS de su cuenta, pero solo puede añadirlas o gestionarlas desde la región de AWS donde se creó su cuenta de Quick.
• Si tiene dashboards insertados públicamente, solo serán accesibles a través del VPC endpoint una vez que las restricciones estén habilitadas.

Después de aplicar las restricciones, solo el tráfico que llegue a través del VPC endpoint especificado (o de los rangos de IP permitidos) podrá acceder a su cuenta de Quick. Todo otro acceso se deniega.

Acceso seguro de usuarios y federación de identidades

La conectividad de red privada mantiene el tráfico fuera de la internet pública, pero no responde a la pregunta de quién puede acceder a qué dentro de Quick. Esta sección cubre cómo integrar su proveedor de identidades corporativo, controlar el aprovisionamiento de usuarios y aplicar una segmentación de acceso de grano fino en los componentes de Quick.

Integración con AWS IAM Identity Center

Importante: Para las cuentas de Quick integradas con IAM Identity Center, la autenticación basada en navegador requiere acceso a los endpoints públicos de inicio de sesión de AWS y de IAM Identity Center. Los VPC endpoints no proporcionan esta ruta de inicio de sesión por navegador. No se requieren direcciones IP públicas. Proporcione conectividad de salida a través de una NAT gateway o un proxy. Consulte Considerations for private access en la IAM Identity Center User Guide.

Amazon Quick utiliza AWS IAM Identity Center como punto central para la gestión de identidades de la fuerza laboral. IAM Identity Center se conecta a su proveedor de identidades corporativo (IdP) existente mediante SAML 2.0 para la autenticación y SCIM 2.0 para el aprovisionamiento automático de usuarios y grupos. Esto proporciona:

• Aprovisionamiento y desaprovisionamiento automático de usuarios sincronizado desde su IdP.
• Sincronización de membresías de grupo – cuando se añade o elimina un usuario de un grupo, ese cambio se propaga a Quick.
• Inicio de sesión único (SSO) con las credenciales corporativas existentes.
• Credenciales temporales a través de roles de IAM asumidos – sin contraseñas específicas de Quick de larga duración.

Para una guía paso a paso sobre la configuración de IAM Identity Center con su proveedor de identidades, consulte Getting started with IAM Identity Center.

Acceso basado en roles en Quick

Quick admite tres roles base que determinan lo que un usuario puede hacer:

• Admin – Acceso completo de gestión, incluida la configuración de fuentes de datos, conexiones VPC, ajustes de seguridad, gestión de usuarios y compra de capacidad SPICE.
• Author – Puede crear y publicar dashboards, crear agentes, configurar Spaces, gestionar fuentes de datos, crear flujos y crear aplicaciones.
• Lector – Puede ver dashboards publicados, interactuar con agentes, usar los Spaces a los que se le ha otorgado acceso y consumir informes de Quick Research.

Estos roles se asignan a roles de IAM que los usuarios federados asumen al iniciar sesión. Al gestionar la asignación de roles en su IdP, mantiene una única fuente de verdad sobre quién tiene qué nivel de acceso.

Además, Quick admite perfiles de permisos personalizados que pueden anular los permisos predeterminados de los roles a nivel de cuenta, de rol o de usuario. Los permisos a nivel de usuario anulan los de nivel de rol, que a su vez anulan los de nivel de cuenta. Esto brinda a los administradores un control granular más allá de los tres roles básicos.

Segmentación de usuarios con Spaces

Los Spaces de Quick proporcionan una capa adicional de segmentación de acceso más allá de los roles. Cada Space puede configurarse con permisos específicos de usuarios y grupos, lo que significa:

• Un Space del equipo de finanzas que contiene dashboards de ingresos confidenciales y bases de conocimiento financieras solo es accesible para el grupo de finanzas.
• Un Space del equipo de ventas con agentes conectados al CRM y dashboards de canal de ventas está restringido a los usuarios de ventas.
• Los Spaces multifuncionales pueden compartirse entre varios grupos con los permisos adecuados.

El acceso a nivel de Space está controlado por los grupos sincronizados desde su proveedor de identidad, por lo que agregar un nuevo miembro del equipo al grupo adecuado le otorga automáticamente acceso a los Spaces relevantes.

Seguridad a nivel de fila en Quick Sight

Para los dashboards respaldados por datos estructurados, Quick Sight admite seguridad a nivel de fila (RLS) que restringe qué filas de datos puede ver cada usuario o grupo. RLS se configura mediante reglas de conjuntos de datos, que son un conjunto de datos de permisos que asigna usuarios o grupos a los valores de campo a los que pueden acceder.

Por ejemplo, un dashboard de ventas regionales puede configurarse de modo que:

• El grupo de ventas de EMEA solo ve las filas donde region = 'EMEA'.
• El grupo de ventas de NA solo ve las filas donde region = 'NA'.
• El VP de Ventas ve todas las filas.

Las reglas de RLS se evalúan según la identidad del usuario tal como la determina IAM Identity Center, lo que significa que la misma federación de identidades que controla el inicio de sesión también rige el acceso a nivel de datos. Esto se aplica por igual a las vistas tradicionales de dashboards y a las consultas en lenguaje natural potenciadas por IA. Las mismas políticas de seguridad restringen qué datos puede consultar la IA al generar respuestas.

Seguridad a nivel de columna

Además de las restricciones a nivel de fila, Quick Sight admite seguridad a nivel de columna (CLS) para ocultar columnas confidenciales a usuarios o grupos específicos. Por ejemplo, un conjunto de datos con información de empleados podría restringir las columnas de salario y SSN solo al grupo de RR. HH., mientras que otros grupos aún pueden acceder a las columnas no confidenciales del mismo conjunto de datos.

Cómo se vincula la identidad con la conectividad privada

La capa de identidad y la capa de red trabajan juntas:

1. Un usuario en la red corporativa se autentica a través de su IdP → IAM Identity Center → Quick.
2. Su solicitud llega a Quick a través del VPC endpoint (la ruta de red privada; consulte VPC endpoints para acceso de usuarios y API).
3. Quick evalúa su identidad para determinar el rol, el acceso a Spaces y las políticas de RLS/CLS.
4. Cuando Quick obtiene datos de un origen local, utiliza la conexión VPC (ENIs en su VPC; consulte VPC connections para acceso a orígenes de datos) para llegar a la base de datos a través de Direct Connect.
5. La respuesta se devuelve al usuario a través de la misma ruta privada.

Aparte del tráfico de inicio de sesión y de recursos estáticos descrito en Enabling access to required external domains, ningún tráfico atraviesa la Internet pública y, en cada punto, la identidad del usuario determina qué puede ver y hacer.

Validación y pruebas

Antes de aplicar restricciones en producción, valide la conectividad de extremo a extremo para cada patrón de acceso:

Monitoreo

Para una visibilidad continua, habilite VPC Flow Logs en todas las ENI de endpoints y conexiones VPC para capturar metadatos de tráfico. Monitoree las métricas de CloudWatch en los VPC endpoints (ActiveConnections, BytesProcessed, PacketsDropped) y configure alarmas para fallos de conexión o fuentes de tráfico inesperadas. Estos registros también sirven como rastro de auditoría referenciado en su documentación de cumplimiento.

Solución de problemas comunes

Buenas prácticas de seguridad

Ni el aislamiento de red ni los controles de identidad por sí solos son suficientes. Esta arquitectura se basa en ambos: los controles de red impiden rutas de acceso no autorizadas, mientras que los controles de identidad impiden el acceso no autorizado a los datos dentro de sesiones autorizadas. Las prácticas siguientes mantienen ambas capas.

• Políticas de endpoint con privilegios mínimos: Restrinja los endpoints de sitio web por aws:PrincipalAccount o aws:OrgId. En los endpoints de API, limite las políticas solo a las acciones específicas que su automatización requiere en lugar de permitir todas las acciones quicksight:* .
• Security groups en capas: Aplique grupos de seguridad tanto a las ENI de endpoints de VPC (tráfico de usuarios) como a las ENI de conexiones de VPC (tráfico de datos). En las ENI de endpoints, restrinja el HTTPS entrante a los rangos CIDR de su empresa. En las ENI de conexiones de VPC, use un grupo de seguridad dedicado, restrinja el tráfico saliente solo a los puertos y destinos de base de datos que Quick necesita, y haga referencia a ese grupo de seguridad en las reglas de entrada de cada fuente de datos.
• Habilite VPC Flow Logs en todas las ENI de endpoints: Estos registros capturan metadatos de tráfico para la supervisión de seguridad, la detección de anomalías y la auditoría de cumplimiento. También proporcionan la pista de auditoría que los marcos regulatorios exigen para los límites de red controlados.
• Audite las políticas de endpoints periódicamente: Revise las políticas de endpoints trimestralmente. Use reglas de AWS Config para detectar desviaciones respecto a su configuración de referencia.
• Separe las conexiones de VPC según la sensibilidad: Si tiene múltiples entornos de datos (desarrollo, staging, producción), cree conexiones de VPC separadas con grupos de seguridad distintos para evitar el acceso entre entornos.
• Monitoree con CloudWatch: Configure alarmas en las métricas PacketsDropped y ActiveConnections . Los patrones inusuales pueden indicar una configuración incorrecta o un intento de acceso no autorizado.

Ejemplo de requisitos y configuración de AWS

Los siguientes ejemplos muestran cómo la configuración de esta publicación puede abordar requisitos comunes de seguridad de red. Evalúelos frente a sus propios requisitos junto con su equipo de seguridad.

Consideraciones de costo

Consejos de optimización de costos:

• Use gateway endpoints (sin cargo adicional) para S3 en lugar de interface endpoints cuando sea posible.
• Consolide las ENI de los endpoints: cada endpoint solo necesita ENI en las AZ donde residen las subredes de la conexión VPC de Amazon Quick.
• Habilite VPC Flow Logs de forma selectiva en las ENI de los endpoints en lugar de en toda la VPC.
• Considere si todos los dominios externos necesitan acceso al NAT gateway o si un proxy dirigido sería más rentable para sus patrones de tráfico.

Conclusión

Esta arquitectura establece cuatro controles complementarios: los VPC endpoints mantienen privado el tráfico de los usuarios, las conexiones de VPC proporcionan a Quick una ruta privada hacia sus fuentes de datos, la federación de identidades determina quién puede acceder a qué, y las restricciones de VPC endpoint hacen obligatoria la ruta privada. Cada capa es auditable de forma independiente y corresponde a requisitos de cumplimiento específicos (véase Compliance mapping).

Con esto en su lugar, Quick Agents puede consultar sus bases de datos locales, Quick Research puede investigar fuentes empresariales detrás del firewall, los paneles de Quick Sight pueden visualizar datos confidenciales, y Quick Flows puede orquestar sistemas internos, todo sin que sus datos atraviesen internet público. Las capacidades de IA no cambian. La exposición desaparece.

Para la implementación, comience con los VPC endpoints para el acceso de usuarios y de API, y valide el acceso de los usuarios antes de avanzar hacia las conexiones de VPC para el acceso a las fuentes de datos. Habilite las restricciones de VPC endpoint solo después de confirmar que todos los patrones de acceso funcionan a través de la ruta privada. Para la configuración de la federación de identidades y la configuración avanzada de RLS/CLS, consulte la documentación de IAM Identity Center.

Sobre los autores