Confianza
Acceso de solo lectura, de forma verificable.
HardenAxis existe para gestionar de forma responsable un acceso sensible a tu entorno AWS. Esta página describe exactamente cómo funciona ese acceso, qué datos tocamos y cuáles no, y contra qué diseñamos — sin barniz de marketing.
Cómo funciona el acceso
Cada conexión empieza con una plantilla de CloudFormation que crea un rol IAM cross-account dedicado en tu cuenta. Nunca pedimos AdministratorAccess, ReadOnlyAccess ni SecurityAudit como atajo — el rol está acotado únicamente a los permisos que cada capacidad necesita.
- Un ExternalId único por instalación, de modo que un ARN de rol robado nunca es suficiente por sí solo para asumirlo
- Sesiones STS de corta duración — nunca se almacenan credenciales de larga duración
- Puedes revocar el acceso en cualquier momento eliminando el stack de CloudFormation en tu cuenta
- Sin secretsmanager:GetSecretValue, ssm:GetParameter, kms:Decrypt ni s3:GetObject en el conjunto de permisos del MVP
Aislamiento por tenant
Cada job de escaneo queda vinculado a un tenant_id, un aws_connection_id y un scan_id, con aislamiento lógico estricto aplicado en profundidad, no solo en el límite de la API. Los workers de escaneo son efímeros y se ejecutan por job — ningún workspace se reutiliza entre clientes.
Qué gestionamos — y qué no
Sí tocamos
- Identificadores de cuenta y región
- ARNs y nombres de recursos, según sea necesario para la evidencia
- Configuración y políticas necesarias para evaluar un control
- Hallazgos normalizados
- Hashes y digests
Nunca tocamos, por defecto
- Valores de secretos
- Contenido de objetos S3
- Datos de bases de datos
- Payloads de aplicaciones
- Logs de negocio
- Credenciales temporales
Las respuestas en bruto de la API de AWS se procesan en memoria y se descartan una vez normalizadas — no conservamos copia más allá de lo que un modo de evidencia explícito requiera.
Contra qué diseñamos
Adaptado de nuestro threat model interno — el mismo documento que usa nuestro equipo de ingeniería, no una versión de marketing aparte.
Compromiso de la plataforma que lleve a asumir un rol
Defensa en profundidad frente a cualquier vía que permita a un atacante asumir el rol cross-account de un cliente.
Confused deputy vía ExternalId
ExternalId único por instalación, validado en cada llamada de assume-role.
Fallo de aislamiento multi-tenant
Acotamiento estricto por tenant_id aplicado en cada capa, no solo en la API.
Exfiltración vía logs o informes
Secretos, tokens, ExternalIds y payloads sensibles en bruto nunca se registran en logs.
Abuso de escaneos para generar coste
Límites de tasa y cuotas de jobs de escaneo por tenant.
Compromiso de la cadena de suministro
Dependencias e imágenes de contenedor fijadas por versión o digest, con SBOM generado en cada build.
Privilegio excesivo en el conector
Conjuntos de permisos de mínimo privilegio, revisados al añadir nuevas capacidades — nunca un rol de atajo amplio.
Manipulación de hallazgos o del scoring
Scoring explicable y trazable hasta la evidencia real de AWS que lo sustenta.
Acceso administrativo interno no auditado
Toda acción interna privilegiada es atribuible y queda registrada.
Sobre certificaciones
HardenAxis no cuenta hoy con certificación SOC 2 ni ISO 27001, y no vamos a insinuar lo contrario. Compliance Evidence Export (dentro de Hardening Advisor, hoy una capacidad "próximamente") está diseñado para dar soporte a tus propias auditorías — no es una afirmación de que HardenAxis esté certificado.
¿Preguntas sobre un control concreto?
Si estás evaluando HardenAxis para una revisión de seguridad, con gusto repasamos el rol IAM, el conjunto exacto de permisos o nuestro threat model con más detalle.