NUEVOYa está disponible la primera herramienta de auditoría de visibilidad en IA para Web3.Ejecutar auditoría gratuita →
Seguridad Policy · Effective April 13, 2026

How Crawlux protects your data.

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.

Read security detailsGDPR · Encrypted at rest · No raw site data stored

Hechos clave de seguridad

5Defense layers
15minIncident detection target
72hUser notification SLA
90dDisclosure window
MFARequired for admin access
Section 01
// Defense in depth

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.

01Infrastructure

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.

03Application

Autenticación, rate limiting 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.

05Operational

Logs de acceso, audit trails y admin con MFA requerido

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.

Section 02
// What is encrypted

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 typeIn transitAt restKey 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
API keys (when launched)TLS 1.3AES-256 · envelopeCustomer-isolated keys
Webhook signing secretsTLS 1.3AES-256 · envelopeCustomer-isolated keys
Payment dataTLS 1.3 to StripeStripe-side onlyStripe PCI infrastructure
Database backupsTLS 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.

Section 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 requerido para acceso admin

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 data del cliente loggeado

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.

Section 04
// Incident response

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.

Phase 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.

Phase 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.

Phase 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.

Phase 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.

Phase 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.

Phase 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.

Section 05
// Vulnerability disclosure

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.

SeverityInitial responseRemediation target
Critical (RCE, auth bypass, data exposure)24 hours7 days from confirmation
High (privilege escalation, sensitive disclosure)3 business days30 days from confirmation
Medium (information disclosure, lower-impact issues)5 business days60 days from confirmation
Low (minor issues, defense-in-depth)10 business days90 days from confirmation
Yes

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.

Section 06
// Compliance posture

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.

Now

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.

Is my audit data encrypted?

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.

How do you handle security incidents?

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.

Do you have a vulnerability disclosure program?

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.

Who has access to my data internally?

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.

Where is my data stored geographically?

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.

What certifications do you hold?

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.

Report a vulnerability
// Contact

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.

For privacy-related security questions, see the privacy policy. For acceptable use questions, see the acceptable use policy. For service status during incidents, see the status page.

RUN YOUR FIRST AUDIT FREE

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 · Full PDF report