Seguridad

Controles de Seguridad

Los proyectos generados por el Nx Plugin for AWS incluyen una serie de controles de seguridad listos para usar. Esta página proporciona una descripción general de esos controles y enlaces a las guías relevantes para más detalles.

Escaneo de Infraestructura

Los proyectos de infraestructura están configurados con Checkov como parte del target build, por lo que la configuración de infraestructura insegura falla la compilación:

Los proyectos CDK sintetizan plantillas de CloudFormation que son escaneadas por Checkov. Consulte Pruebas de Seguridad para más detalles.
Los proyectos Terraform ejecutan Checkov directamente contra su código Terraform. Consulte Proyectos Terraform.

Donde la infraestructura proporcionada suprime una regla de Checkov, la supresión está limitada al recurso específico y anotada con una justificación. El helper compartido suppressRules requiere una razón para cada supresión, y recomendamos seguir la misma práctica en su propio código. Consulte Supresión de Verificaciones de Checkov.

Escaneo de Imágenes de Contenedor

Los proyectos que construyen imágenes de contenedor (por ejemplo, agentes, servidores MCP e imágenes de migración de bases de datos) incluyen un target trivy que escanea imágenes en busca de vulnerabilidades HIGH y CRITICAL, saliendo con código distinto de cero al encontrar hallazgos. Consulte Empaquetado Docker para más detalles, incluyendo cómo suprimir hallazgos con un archivo .trivyignore.

Escaneo de Credenciales

Los workspaces incluyen hooks de pre-commit de git-secrets que escanean archivos preparados en busca de patrones de credenciales de AWS, previniendo commits accidentales de claves de acceso y otros valores sensibles. Consulte la sección Git Secrets de la guía del workspace.

Autenticación

Las APIs, agentes y servidores MCP usan autenticación AWS IAM (SigV4) por defecto:

Las APIs tRPC, FastAPI y Smithy usan autenticación IAM por defecto, con Cognito y autorizadores personalizados disponibles como opciones. El stub del autorizador personalizado proporcionado deniega solicitudes por defecto.
Los Agentes y servidores MCP desplegados en Amazon Bedrock AgentCore Runtime usan autenticación IAM (SigV4) por defecto, con autenticación Cognito basada en JWT como opción.
El generador de autenticación de sitios web proporciona un user pool de Amazon Cognito con autenticación multifactor (MFA) requerida, una política de contraseñas fuerte y protección contra eliminación habilitada.

Cifrado

La infraestructura proporcionada cifra datos en tránsito y en reposo:

Los sitios web se sirven a través de CloudFront con HTTP redirigido a HTTPS, y una política de encabezados de respuesta que incluye HTTP Strict Transport Security (HSTS), una Content Security Policy y otros encabezados de seguridad. Un WAF con reglas administradas de AWS está asociado con la distribución.
Los buckets S3 bloquean todo acceso público, aplican acceso solo SSL mediante políticas de bucket, están cifrados (KMS con rotación de claves para contenido de sitios web) y entregan logs de acceso del servidor a grupos de logs de CloudWatch cifrados con claves KMS administradas por el cliente, donde pueden consultarse con Logs Insights y generar alarmas.
Los logs de acceso de API se escriben en grupos de logs de CloudWatch cifrados con claves KMS administradas por el cliente con rotación habilitada.
Las bases de datos Aurora habilitan cifrado de almacenamiento con una clave KMS administrada por el cliente, generan credenciales en AWS Secrets Manager (nunca codificadas) y soportan rotación automática de credenciales.

Mínimo Privilegio

Los constructs de CDK y módulos de Terraform proporcionados siguen el principio de mínimo privilegio:

Los constructs exponen métodos grant* (por ejemplo grantInvokeAccess en APIs y agentes, grantConnect en bases de datos) para que los consumidores otorguen solo el acceso que necesitan.
Las políticas IAM en la infraestructura proporcionada están limitadas a recursos y acciones específicas. Donde se requiere un recurso comodín por el servicio de AWS (por ejemplo ecr:GetAuthorizationToken), está limitado a esas acciones y restringido con condiciones donde sea soportado.

Licencias de Dependencias

El generador de licencias configura la gestión automatizada de encabezados de licencia y la verificación de licencias de dependencias contra una lista de licencias aprobadas, ayudándole a detectar dependencias transitivas problemáticas antes de que se publiquen.

Responsabilidad

La seguridad y el cumplimiento son una responsabilidad compartida. AWS describe esto a través del Modelo de Responsabilidad Compartida, que distingue entre la seguridad de la nube (responsabilidad de AWS) y la seguridad en la nube (su responsabilidad como cliente).

El Nx Plugin for AWS le ayuda a abordar partes de su lado de ese modelo. Sus generadores proporcionan fundamentos seguros y codifican las mejores prácticas de AWS dentro del alcance del código que producen — los controles descritos anteriormente. Esto reduce el esfuerzo requerido para construir de manera segura, pero no transfiere la propiedad de la seguridad al plugin.

Usted es propietario del código que se genera en su workspace y sigue siendo responsable de su seguridad. Una vez proporcionado, el código generado es suyo para modificar, extender y operar, y debe tratarse igual que cualquier otro código que usted escriba.

En particular:

El alcance del plugin está limitado a sus generadores. El plugin no tiene conocimiento de la lógica de negocio de su aplicación, clasificación de datos, modelo de amenazas u obligaciones regulatorias, y no puede tomar decisiones que dependan de ellos.
La autenticación está configurada, pero la autorización no. Las APIs están protegidas con autenticación por defecto (por ejemplo IAM/SigV4), pero el plugin no puede determinar qué principales autenticados deben tener permiso para realizar qué operaciones en qué recursos. La autorización granular depende de su lógica de negocio y debe ser diseñada, implementada y probada por usted.
El código generado es un punto de partida, no un producto terminado. A medida que agrega funcionalidad, introduce consideraciones de seguridad que el plugin no puede anticipar — validación de entrada, manejo de datos, gestión de secretos, elección de dependencias e integraciones con otros sistemas.

En consecuencia, debe revisar el código generado y las aplicaciones que construye sobre él de acuerdo con las políticas de seguridad, estándares y procesos de revisión de su propia organización, y someterlos al mismo modelado de amenazas, pruebas de seguridad y puertas de aprobación que aplica a cualquier carga de trabajo de producción. Los controles proporcionados por el plugin están destinados a complementar esos procesos, no a reemplazarlos.