Modelo de seguridad

Esta página existe para que cuando tu cliente enterprise te audite, tengas algo que pegar en la respuesta sin tener que escribir desde cero. Está organizada por las preguntas que efectivamente nos hacen.

Aislamiento

¿Comparten una base de datos con otros tenants? No. Cada workspace tiene su propia instancia dedicada con su propio schema en Postgres. No hay tabla compartida cross-workspace excepto el plano de control (billing, audit del propio Prysm:ID), que no contiene PII de tus usuarios finales.

¿Hay un network path entre instancias? Las instancias no se hablan entre ellas. Una instancia no puede consultar otra, ni siquiera por error de configuración: viven en redes separadas.

¿Qué pasa si vulneran el plano de control? El plano de control puede orquestar workspaces (crear, suspender, leer config) pero no puede leer credenciales de tus usuarios finales. Las contraseñas viven hasheadas (bcrypt) en la instancia del workspace, jamás salen de ahí.

Encryption

At rest: Postgres con encryption AES-256 a nivel de volumen. Snapshots y backups también encriptados.

In transit: TLS 1.3 obligatorio en todos los endpoints públicos (auth.*.prysmid.com, api.prysmid.com, app.prysmid.com). El plano de control habla con tu instancia por TLS interna también; no hay tráfico plain en ningún hop.

Application-level: cualquier credencial de service account que el plano de control necesite guardar para operar tu instancia está encriptada con Fernet antes de persistirse.

Keys y firma de tokens

Cada instancia tiene su propio key store. Los id_token y access_token se firman con RS256 por default. Las keys públicas se exponen vía JWKS en https://auth.<slug>.prysmid.com/oauth/v2/keys.

Rotation: las keys de firma rotan automáticamente. La key vieja queda activa para validación durante un período de gracia. Tu cliente debe seguir el JWKS dinámicamente, no cachear una key fija (la mayoría de las librerías OIDC lo hacen bien por default).

Audit

Quién hace qué en tu instancia: el audit log nativo registra cada evento (signup, login, logout, password change, IdP linking, role grant, app registration). Lo accedés vía la admin API de tu instancia, o vía dashboard en app.prysmid.com → audit.

Quién toca el plano de control: tenemos un audit log separado para acciones administrativas en app.prysmid.com (qué miembro del workspace cambió qué). Visible desde el dashboard.

Retention: 90 días en plan Pro, 1 año en Enterprise. Plan Free, 30 días.

Portabilidad — el “exit plan”

Si querés irte de Prysm:ID hoy, lo hacés:

1. Export. Andá a Settings → Export del workspace. Descargás un dump completo de tu instancia (usuarios, IdPs, projects, apps, roles, branding) en formato estándar.

2. Levantar tu propia infraestructura. El motor de auth subyacente es open source y self-hosteable. Cualquier server con Postgres sirve. La operación realista son días, no meses.

3. Importar el dump. Usuarios, IdPs, apps, branding, todo se restaura.

4. Apuntar tu DNS. auth.acme.prysmid.com lo apuntás vos (CNAME al server tuyo) o cambiás el issuer en tu app. Tus tokens emitidos antes siguen válidos hasta expirar.

5. Cancelás Prysm:ID. Borrás el workspace desde el dashboard. La instancia se elimina; los backups se purgan a 90 días.

Consejo

El export es una operación real, no un pitch. Probala en un workspace de prueba antes de necesitarla — escribinos a soporte si querés un walkthrough.

Compliance

Estándar	Estado
SOC 2 Type II	En proceso (target: Q3 2026).
LGPD	Cumplido (procesador, contrato disponible). Workspaces dedicados ayudan a la postura.
Habeas Data (Argentina, Colombia)	Cumplido.
GDPR	Cumplido (procesador). DPA disponible bajo Enterprise.
HIPAA	No (fuera de scope hoy).
PCI-DSS	No procesamos tarjetas — Stripe lo hace.

Reportá vulnerabilidades

security@prysmid.com o key PGP en https://prysmid.com/.well-known/security.txt. Acuse de recibo en 24h. Bug bounty pendiente, manejamos disclosure responsable case-by-case mientras tanto.