Tu dato es tuyo.
Queremos que ningún acceso pase sin que lo veas.
Operamos tu ERP. Técnicamente podemos leer tus datos para darte soporte cuando lo pides. Estamos construyendo —y vamos a publicar tres veces por trimestre el avance— un modelo donde cada acceso queda registrado en un log que tú controlas, y requiere aprobación de dos personas distintas de nuestro equipo. Esta página describe ese diseño completo y qué piezas ya están vivas hoy.
Nos inspiramos en el modelo de Stripe (audit log visible al merchant), Notion (workspace audit log Enterprise), Linear (workspace security), Vercel (audit trail por workspace) y 1Password (Secrets Automation con M-of-N) — pero no afirmamos paridad operativa con ellos todavía. Lo que ellos cobran en tier Enterprise, queremos incluirlo desde Pro cuando esté Tier 1 operativo.
Cómo funciona técnicamente
Cuatro capas que protegen tus datos
No nos pedimos confianza ciega. Te damos los mecanismos para verificarla. Cada paso es auditable por ti, sin nuestra cooperación.
Operativo en julio 2026.
El diseño y el código están listos. Estamos completando la integración con AWS Secrets Manager y CloudTrail (mirror externo de cada acceso a llaves) antes de declararlo público activo para clientes Pro y superior. Mientras tanto, los accesos KONTORE quedan registrados en nuestro audit log interno y disponibles a pedido.
Tu BD vive separada
Cada cliente tiene su propio proyecto Supabase aislado físicamente. No compartes servidor con otros clientes. Tu RLS (row-level security) está activado por defecto.
Las llaves de escalación viven en AWS Secrets Manager
La llave que permite a KONTORE staff leer tus datos NO está en variables de entorno del worker ni en la laptop de nadie. Está en AWS Secrets Manager y el worker la fetcha solo durante un request HTTP — vive en memoria milisegundos, no persiste entre llamadas. Cada acceso queda registrado en AWS CloudTrail (mirror externo independiente).
Hace falta firma de 2 humanos
Ningún empleado de KONTORE puede entrar a tus datos solo. Quien lo pide y quien lo aprueba tienen que ser personas distintas. Ambas firmas quedan en el log. Sin la segunda firma, el sistema rechaza con 403.
Tú ves cada acceso en tu panel
Dentro de tu ERP, sección "Seguridad de mis datos", ves cuántas veces KONTORE entró a tu BD en los últimos 90 días. Por cada acceso: fecha, quién pidió, quién aprobó, qué tabla, cuántas filas, link al ticket. Sin nuestra cooperación.
Flujo completo end-to-end
Cliente abre ticket
"Necesito ayuda con la factura X"
KONTORE staff A pide acceso
Con link al ticket + razón
KONTORE staff B aprueba
Persona distinta de A
Worker fetcha llave en AWS Secrets Manager
En memoria solo durante el request
Ejecuta la query exacta
Validada por hash pre-aprobado
Tú ves el acceso en tu panel
+ mirror externo en CloudTrail
Esto no es invento KONTORE
Es el mismo modelo que usan los líderes del SaaS B2B
Cada empresa abajo cobra estas garantías en tier Enterprise. KONTORE las incluye desde Pro.
Stripe
Audit log visible a merchants
Notion
Workspace audit log (Enterprise)
Linear
Workspace security log
Vercel
Audit trail por workspace
1Password
Secrets Automation con M-of-N
Marcas referenciadas solo como ejemplo de patrón industrial. KONTORE no afirma asociación, partnership ni endorsement de ninguna de las marcas mencionadas.
Verificable sin nuestra cooperación
Audita tu propia BD
No te pedimos que confíes. Te damos el panel para que verifiques.
Panel "Seguridad de mis datos"
Dentro de tu ERP, sección Configuración. Tú lo abres cuando quieras, sin pedirnos nada. Muestras cuántas veces KONTORE entró a tu BD en últimos 90 / 30 / 7 días. Por cada acceso: fecha, iniciador, segundo aprobador, razón, tabla, cuántas filas, link al ticket de soporte que lo originó.
El panel también te permite:
- Verificar el hash chain del log (detecta tampering retroactivo aún de nuestra parte)
- Exportar el log a CSV/JSON para tu propio compliance interno
- Desactivar break-glass por completo (Enterprise) — KONTORE no entra ni con tu permiso retroactivo
El proceso detallado
Break-glass: cuando KONTORE entra a tu BD
Lo que pasa, paso a paso, cuando pides soporte que requiere que miremos tu BD.
Tú abres un ticket de soporte.
Email a support@kontore.app, WhatsApp, o desde el ERP. Describes el problema. Nada técnico: "no me cuadran las facturas de mayo" alcanza.
Un técnico nuestro evalúa si puede resolverlo SIN tocar tu BD.
Tu propio ERP tiene paneles de auditoría que el cliente y soporte pueden mirar sin escalación. La mayoría de tickets se resuelven acá.
Si necesita entrar, el técnico abre una "solicitud de break-glass".
Describe en el sistema qué tabla quiere leer, qué query exacta, y por qué (link al ticket tuyo). Eso queda registrado en nuestro audit log antes de cualquier acceso.
Una segunda persona de KONTORE revisa y aprueba.
Si la solicitud no tiene un ticket válido o la query no se justifica, rechaza. La segunda persona tiene que ser distinta de la primera. Sin esa segunda firma, el sistema rechaza con 403.
Solo entonces el worker fetcha la llave de escalación en AWS Secrets Manager.
La llave vive en memoria del worker solo durante el request HTTP (milisegundos). No se cachea entre requests, no se guarda en variables de entorno, no se reusa. CloudTrail registra cada llamada con timestamp + IAM role.
Tú ves el acceso en tu panel + recibes email opcional.
El acceso aparece en tu "Seguridad de mis datos" inmediatamente. Si activaste notificaciones, también recibes email con el detalle. El mismo evento queda registrado en AWS CloudTrail — un sistema externo a KONTORE LABS que ni nosotros podemos modificar.
Preguntas frecuentes
Lo que quieres saber antes de firmar
¿Quién es el segundo aprobador?
Dos operadores diferentes de la empresa — uno pide, el otro aprueba, nunca la misma persona. A medida que el equipo crece, ampliamos el set de aprobadores manteniendo la regla M-of-N (cualquier escalación necesita dos firmas de personas distintas).
¿Qué pasa si yo (cliente) niego el acceso?
En el plan Enterprise, puedes desactivar break-glass por completo desde tu panel "Seguridad de mis datos". Si lo haces, KONTORE no puede entrar a tu BD ni siquiera con las dos firmas internas. El trade-off es que tampoco podemos darte soporte que requiera mirar tu BD — vas a tener que exportar lo que necesites tú mismo.
¿Qué TTL tiene la sesión de acceso?
La llave fetcheada en AWS Secrets Manager vive en memoria del worker únicamente durante ese request HTTP. El access_token entregado al técnico es one-shot — vale para una operación. No hay sesión larga. Si la operación toma más tiempo, hay que re-pedir el acceso (con nuevo ticket o referencia al mismo, y nueva segunda firma).
¿Puedo desactivar break-glass completamente?
Sí, en Enterprise. Toggle directo desde tu panel. Una vez desactivado, KONTORE no puede entrar a tu BD aunque tú lo pidas después — para reactivarlo hay un cool-down de 24h para evitar phishing. Si tienes un incidente productivo que necesita recovery y break-glass está apagado, tenemos que coordinar exportar/importar a un workspace temporal — más lento, pero el modelo lo soporta.
¿Cómo verifico que el log no fue modificado?
Cada entrada del log lleva un hash HMAC encadenado al row anterior (similar a una blockchain liviana). El secreto del HMAC vive en AWS Secrets Manager, no en la BD que contiene el log — por lo que ni un atacante que controle la BD puede falsificar entradas hacia atrás. Tú puedes pedir el HMAC del último row y verificarlo offline con tu propio script. Adicionalmente, cada acceso a la llave queda registrado en AWS CloudTrail (write-once-via-IAM, externo a KONTORE LABS).
¿Esto me protege de una subpoena gubernamental?
No técnicamente. Si una autoridad de jurisdicción aplicable (Delaware US o donde KONTORE tenga presencia legal) emite un subpoena válido, KONTORE LABS LLC tiene que cumplir. Lo que sí: el acceso queda en tu audit log de la misma manera que cualquier otro acceso — tú lo ves. Salvo que la orden incluya un gag order que nos obligue a no informarte, en cuyo caso el límite es legal, no técnico. Esto es universal: ningún SaaS resuelve esto, ni Stripe ni Notion ni nosotros.
¿Por qué confiar en este modelo y no en otro?
No te pedimos que confíes en KONTORE. Te pedimos que confíes en que el log que tú ves matchea con lo que pasó, lo cual es verificable con el hash chain y el mirror externo. Esa verificación no depende de nuestra cooperación. Si en algún momento el log y la realidad divergen, la verificación falla — y nosotros perdemos al cliente, no al revés.
Diseñado con la trazabilidad de los grandes — sin precio Enterprise.
Hoy: BD dedicada + RLS + audit log con hash chain. Roadmap Q3 2026: M-of-N approval, secret-keys efímeras y panel cliente "Mis accesos KONTORE". 14 días gratis, sin tarjeta.