NUEVOYa está disponible la primera herramienta de auditoría de visibilidad en IA para Web3 del mundo.Haz una auditoría gratis →
Política de seguridad · Vigente desde el 13 de abril de 2026

Cómo Crawlux protege tus datos.

Arquitectura de seguridad defense-in-depth cubriendo encriptación, control de acceso, respuesta a incidentes y divulgación de vulnerabilidades. Construida en AWS con hosting primario en región UE para alineación con GDPR.

Ver detalles de seguridadGDPR · Cifrado en reposo · No se almacenan datos brutos del sitio

Hechos clave de seguridad

5Capas de defensa
15minObjetivo de detección de incidentes
72hSLA de notificación al usuario
90dVentana de divulgación
MFAObligatorio para acceso de administrador
Sección 01
// Defensa en profundidad

Cinco capas de seguridad

Crawlux aplica defensa en capas a través de infraestructura, red, aplicación, datos y controles operacionales. Un atacante necesitaría comprometer múltiples capas independientes para acceder a la data de usuarios, con cada capa elevando el costo del ataque.

01Infraestructura

Hosteado en AWS con región UE primaria

Producción corre en AWS eu-west-1 con réplicas de backup en eu-central-1. Seguridad de hardware, control de acceso físico e integridad de cadena de suministro heredados de los controles SOC 2 Type II de AWS.

02Network

Aislamiento VPC con protección WAF y DDoS

Las VPCs de producción aisladas del internet público excepto a través de endpoints ALB. El WAF de CloudFlare filtra patrones de ataque conocidos. AWS Shield Standard mitiga DDoS en el borde de red.

03Aplicación

Autenticación, limitación de tasa y protección CSRF

Todas las rutas autenticadas requieren tokens de sesión válidos. Rate limits aplicados por IP y por cuenta. Tokens CSRF para operaciones que cambian estado. Validación de input en cada frontera de API.

04Data

Encriptación AES-256 en reposo, TLS 1.3 en tránsito

Base de datos, object storage y backup storage todos encriptados con AES-256 usando claves manejadas por AWS KMS. Tráfico de API protegido con TLS 1.3 mínimo. Las API keys y secretos de webhooks usan envelope encryption.

05Operativa

Registros de acceso, pistas de auditoría y administración con MFA obligatorio

El acceso a la base de datos de producción requiere MFA. Todo el acceso loggeado con usuario, acción y timestamp. Las auditorías mensuales de acceso identifican y remueven permisos sin usar. El acceso a data del cliente requiere justificación loggeada.

Sección 02
// Qué se cifra

Cobertura de encriptación

La encriptación aplica a cada categoría de data que Crawlux maneja. La tabla abajo mapea cada tipo de data al mecanismo de encriptación y enfoque de manejo de claves.

Data typeEn tránsitoEn reposoKey management
Audit JSON outputTLS 1.3AES-256AWS KMS
PDF reportsTLS 1.3AES-256AWS KMS · S3 SSE-KMS
User account dataTLS 1.3AES-256AWS RDS encryption
Claves de API (cuando se lancen)TLS 1.3AES-256 · envelopeClaves aisladas por cliente
Secretos de firma de webhooksTLS 1.3AES-256 · envelopeClaves aisladas por cliente
Datos de pagoTLS 1.3 to StripeStripe-side onlyStripe PCI infrastructure
Respaldos de base de datosTLS 1.3AES-256Cross-region replicated
Server logsTLS 1.3AES-256CloudWatch encryption

Encriptación de claves aislada por cliente

Las API keys y secretos de firma de webhooks usan envelope encryption donde los secretos de cada cliente están encriptados con una clave KMS por-cliente. Una brecha de la capa de storage de un cliente no expone los secretos de otros clientes.

Sección 03
// Access control

Quién tiene acceso a tus datos

El acceso a sistemas de producción y data del cliente está restringido a miembros del equipo de ingeniería con necesidad de negocio documentada. El principio de menor privilegio aplica a través de cada sistema. Todo el acceso está loggeado.

01

MFA obligatorio para el acceso de administrador

El acceso a la base de datos de producción, consola de infraestructura y dashboard admin requieren autenticación multi-factor. Claves de seguridad por hardware preferidas. MFA basado en SMS no permitido.

02

Menor privilegio por defecto

Los nuevos miembros del equipo empiezan con cero acceso a producción. Privilegios otorgados por necesidad documentada con aprobación del manager. Acceso por tiempo limitado para tareas específicas cuando es posible.

03

Todo acceso loggeado

Cada query de base de datos, lectura de objeto S3 y acción admin está loggeada con usuario, timestamp y operación. Logs retenidos por 1 año mínimo. Los patrones anómalos se marcan para revisión.

04

Auditorías mensuales de acceso

Ingeniería revisa los permisos de acceso a producción mensualmente. Los permisos sin usar se remueven. Los roles fuera de la responsabilidad actual se revocan. Los reportes de auditoría se archivan para revisión de compliance.

05

Acceso a datos del cliente registrado

Las solicitudes de soporte que requieren acceso a data del cliente requieren justificación documentada. Cada acceso loggeado con solicitante, destinatario, justificación y timestamp. Los clientes pueden solicitar su log de acceso.

06

Offboarding dentro de 24 horas

Cuando los miembros del equipo se van, todo el acceso a producción es revocado dentro de 24 horas. Las credenciales de cuenta rotadas. Las sesiones activas invalidadas. Las claves de acceso removidas de los pools de rotación.

Sección 04
// Respuesta a incidentes

Respuesta a incidentes de 5 fases

Cuando un incidente de seguridad es detectado, la respuesta sigue un proceso definido de 5 fases con objetivos claros de tiempo en cada fase. La página de status loggea todos los incidentes confirmados públicamente con timestamps.

Fase 01

Detección (objetivo: 15 min)

El monitoreo automatizado alerta sobre patrones anómalos: ubicaciones de login inusuales, picos de autenticaciones fallidas, egreso inesperado de data, picos de tasa de errores. Ingeniero on-call paged dentro de la ventana objetivo.

Fase 02

Contención (objetivo: 1 hora)

Aislar sistemas afectados para prevenir movimiento lateral. Revocar credenciales comprometidas. Bloquear IPs de atacantes a nivel WAF. Preservar evidencia forense en estado read-only. No dañar la investigación en curso.

Fase 03

Evaluación (objetivo: 4 horas)

Determinar alcance: qué sistemas, qué data, qué usuarios. Categorizar severidad. Evaluar obligaciones de notificación regulatoria. Documentar línea de tiempo. Identificar hipótesis de causa raíz para planeación de remediación.

Fase 04

Remediación (típico: 24 horas)

Parchar la vulnerabilidad. Rotar credenciales expuestas. Restaurar sistemas desde backups limpios si es necesario. Verificar la efectividad de la remediación a través de pruebas dirigidas. Actualizar reglas de detección para capturar futuros ataques similares.

Fase 05

Comunicación (objetivo: 72 horas)

Notificar a usuarios afectados vía email dentro de 72 horas de la confirmación. Actualizar página de status con detalles del incidente. Presentar notificaciones regulatorias donde sea requerido (GDPR, UAE PDPL). Publicar revisión post-incidente para aprendizaje.

Fase 06

Revisión post-incidente

Dentro de 2 semanas de la resolución, el equipo de ingeniería conduce un postmortem sin culpa. Los hallazgos documentados en el changelog. Las mejoras de proceso rastreadas hasta su completitud. Los incidentes mayores revisados en el all-hands trimestral.

Sección 05
// Divulgación de vulnerabilidades

Programa de divulgación responsable

Los investigadores de seguridad que encuentran vulnerabilidades pueden divulgarlas a través de nuestro programa de divulgación responsable. Seguimos los principios de divulgación coordinada con objetivos de tiempo de respuesta que escalan con la severidad.

SeveridadRespuesta inicialObjetivo de remediación
Crítica (RCE, bypass de autenticación, exposición de datos)24 horas7 días desde la confirmación
Alta (escalada de privilegios, divulgación de datos sensibles)3 días hábiles30 días desde la confirmación
Media (divulgación de información, problemas de menor impacto)5 días hábiles60 días desde la confirmación
Baja (problemas menores, defensa en profundidad)10 días hábiles90 días desde la confirmación
Sí

Crédito público y reconocimiento

Los investigadores que divulgan son acreditados públicamente en nuestro hall de reconocimiento de seguridad (con permiso). Los hallazgos significativos reciben un agradecimiento personalizado y reconocimiento detallado en el changelog.

No

Sin bug bounty actualmente

Crawlux actualmente no ofrece bug bounties monetarios. Un programa formal de bug bounty está en el roadmap para Q3 2027 una vez que las plataformas API y SDK se hayan estabilizado.

Safe harbor para investigadores

Los investigadores actuando de buena fe dentro del alcance de este programa no están sujetos a acción legal bajo los términos de servicio. Fuera de alcance: ingeniería social del staff, ataques físicos, pruebas de denial-of-service, ataques contra cuentas de clientes.

Sección 06
// Postura de cumplimiento

Certificaciones y roadmap

Crawlux corre en infraestructura AWS con extensas certificaciones heredadas de la plataforma. Las certificaciones independientes de Crawlux están en el roadmap con fechas objetivo publicadas abiertamente.

Ahora

Certificaciones heredadas de AWS

La infraestructura corre en AWS que tiene SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018 y PCI DSS nivel 1. Los reportes de attestation están disponibles para clientes enterprise bajo solicitud.

Q4 2026

Crawlux SOC 2 Type II

Auditoría SOC 2 Type II independiente cubriendo Crawlux como entidad (encima del attestation heredado de AWS). Finalización objetivo Q4 2026. Contratación de firma auditora en progreso.

Q2 2027

Crawlux ISO 27001

Certificación ISO 27001 objetivo Q2 2027. Se construye sobre el trabajo SOC 2 y se extiende a documentación formal del sistema de manejo de seguridad de información alineada a estándares ISO.

// Seguridad Preguntas frecuentes

Preguntas comunes

Seis preguntas cubriendo encriptación, respuesta a incidentes, divulgación de vulnerabilidades, acceso interno, ubicación geográfica de data y certificaciones.

¿Mis datos de auditoría están cifrados?

Sí. Toda la data está encriptada en tránsito usando TLS 1.3 y en reposo usando AES-256. El storage de base de datos, storage de backup y object storage todos usan encriptación AES-256 con claves manejadas por el KMS del proveedor cloud. Las API keys y secretos de firma de webhooks están encriptados con envelope encryption usando claves aisladas por cliente.

¿Cómo manejan los incidentes de seguridad?

Los incidentes de seguridad siguen un proceso de respuesta de 5 fases: Detección dentro de 15 minutos vía monitoreo automatizado, Contención dentro de 1 hora para limitar el blast radius, Evaluación dentro de 4 horas para determinar alcance e impacto, Remediación típicamente dentro de 24 horas y Comunicación a usuarios afectados dentro de 72 horas de la confirmación. La página de status loggea todos los incidentes confirmados con timestamps.

¿Tienen un programa de divulgación de vulnerabilidades?

Sí. Los investigadores de seguridad pueden divulgar vulnerabilidades en [email protected]. Seguimos los principios de divulgación responsable con una ventana de divulgación coordinada de 90 días. Las vulnerabilidades críticas reciben una ventana de respuesta de 24 horas. Actualmente no ofrecemos bug bounties pero sí acreditamos públicamente a los investigadores que divulgan en nuestro hall de reconocimiento.

¿Quién tiene acceso interno a mis datos?

El acceso está limitado a miembros del equipo de ingeniería con necesidad de negocio documentada. Todo el acceso está loggeado con usuario, acción y timestamp. El acceso a la base de datos de producción requiere autenticación multi-factor y es auditado mensualmente. La data del cliente nunca es accedida por razones no esenciales. Las solicitudes de soporte que requieren acceso a data son loggeadas con el solicitante, destinatario y justificación.

¿Dónde se almacenan geográficamente mis datos?

La infraestructura primaria está hosteada en AWS en regiones UE (eu-west-1 y eu-central-1) para alineación con GDPR. Las réplicas de backup están en regiones US de AWS (us-east-1) para redundancia. Los resultados de auditoría pueden ser procesados en regiones de proveedores upstream durante el análisis (DataForSEO, motores IA) pero la data procesada regresa a nuestra infraestructura primaria UE dentro de minutos.

¿Qué certificaciones tienen?

La infraestructura de Crawlux corre en AWS que tiene SOC 2 Type II, ISO 27001 e ISO 27017. Crawlux como empresa está actualmente trabajando hacia certificación SOC 2 Type II independiente con finalización objetivo Q4 2026. El roadmap incluye certificación ISO 27001 objetivo Q2 2027. Los contratos enterprise pueden solicitar los reportes de attestation de AWS inmediatamente.

Reportar una vulnerabilidad
// Contacto

Contacto de seguridad

Para divulgación de vulnerabilidades, preguntas de seguridad o reportes de incidentes, el email dedicado de seguridad es enrutado directamente al equipo de seguridad de ingeniería.

Para preguntas de seguridad relacionadas con la privacidad, consulta la política de privacidad. Para preguntas sobre uso aceptable, consulta la política de uso aceptable. Para conocer el estado del servicio durante incidentes, consulta la página de estado.

HAZ TU PRIMERA AUDITORÍA GRATIS

Mira Crawlux en tu propio sitio crypto.

Sin registro, sin tarjeta de crédito. Reporte completo de auditoría afinada para Web3 en 60 segundos.

Primera auditoría gratis · Sin registro · 60 segundos · Informe PDF completo