Tus datos, y el dinero de tu evento, protegidos por diseño
No es una promesa de marketing — es la arquitectura real de Aluna: roles granulares, autenticación sin contraseña opcional, aislamiento entre organizaciones a nivel de cada consulta, y tu propia cuenta de Stripe cobrando directo.
🔑 RBAC granular
Roles separados por función (admin, member, finanzas, marketing, analyst...) con permisos individuales por módulo — un miembro de marketing no puede ver Finanzas solo porque tiene una cuenta.
🛡️ Passkeys y MFA
Inicia sesión con huella o Face ID (WebAuthn) sin contraseña, o con un código de tu app de autenticación favorita (1Password, Google Authenticator, Microsoft Authenticator) — tu elección.
🏢 Aislamiento multi-organización real
Cada endpoint que recibe un id de recurso valida que pertenece a la organización de la sesión actual antes de tocarlo — no es solo un filtro visual, es una verificación en cada llamada al servidor.
💳 Tu propia cuenta de Stripe
Stripe Connect en modalidad de cargos directos (no destination charges) — el dinero de tus boletos y patrocinios va directo a tu cuenta, nunca a una cuenta de Aluna.
📎 Archivos con control de acceso
Cada adjunto se sirve por un endpoint propio que valida explícitamente que quien lo pide tiene derecho a verlo — nunca una URL de archivo abierta al público por accidente.
🚦 Rate-limit fail-closed
En las rutas públicas sin sesión (como comprar un boleto), si el contador de abuso no se puede leer, la acción se rechaza — nunca se permite "por si acaso" cuando el sistema de protección falla.
Sobre seguridad
¿El dinero de mis boletos pasa por una cuenta de Aluna?
No — usamos Stripe Connect en modalidad de cargos directos (no destination charges): el dinero va directo a tu propia cuenta de Stripe, nunca a una cuenta de Aluna.
¿Puedo usar una llave de seguridad física o Face ID en vez de contraseña?
Sí, Aluna soporta passkeys (WebAuthn) además de MFA por código (TOTP) — puedes iniciar sesión con huella o Face ID, sin escribir contraseña.
¿Un miembro de mi equipo puede ver datos de otra organización?
No — el aislamiento entre organizaciones es real a nivel de cada consulta: todo endpoint que recibe un id de recurso valida que pertenece a la organización de la sesión actual antes de tocarlo.