Stonen
Seguridad, acceso y continuidad
Quién ve qué, y qué pasa si algo sale mal
Esta página describe los controles que existen hoy y lo que cada uno significa para la operación de su empresa. También dice lo que todavía no existe — porque una lista de controles sin sus lagunas sirve para vender, no para decidir.
No se ha obtenido ninguna certificación de seguridad, y no se ha realizado ninguna auditoría externa. Lo que sigue es el comportamiento verificado del sistema.
Una empresa nunca ve a otra
Toda lectura y toda escritura en Stonen se limitan a la organización de quien hace la solicitud. Un registro de otra empresa no se filtra de la pantalla: la API lo rechaza, con un error propio.
Para su negocio, esto significa que su cartera de clientes, su inventario, sus precios y sus conversaciones no aparecen para otra empresa que use el mismo producto — ni por un error de tipeo, ni por un enlace compartido por equivocación.
Este aislamiento vale para todos los perfiles, incluido el titular de la cuenta. No hay un perfil que lo vea todo.
Cada persona ve lo que su rol le permite
El acceso se decide por 35 permisos, combinados en cuatro perfiles. La regla que los atraviesa a todos es la que fijó el dueño del producto: lectura amplia, acción comercial restringida.
La tabla completa — cada permiso frente a cada perfil — se genera a partir del mismo código que usa la API en cada solicitud, y no se escribe a mano. Si la tabla estuviera mal, el código estaría mal también.
| Perfil | Qué hace | Qué evita |
|---|---|---|
| PerfilTitular | Qué haceve toda la operación, administra el equipo y la configuración | Qué evitaque la empresa dependa de una persona externa para gestionar su propia cuenta |
| PerfilGerente | Qué hacedistribuye el trabajo, hace seguimiento e interviene; actúa fuera de su propia cartera por excepción, con motivo | Qué evitaque el gerente quede bloqueado — y que toque la cartera ajena sin dejar rastro |
| PerfilVendedor | Qué hacetrabaja su propia cartera; no actúa en la de otro | Qué evitaque la cartera de un vendedor sea accedida por otro |
| PerfilTecnología | Qué hacese ocupa de las integraciones y de la calidad de los datos. Tiene 7 de los 35 permisos: ve el inventario físico, pero no ve cartera, precio, oportunidad ni cliente | Qué evitaque quien opera la parte técnica vea la operación comercial |
Algunas acciones exigen un motivo declarado para ser aceptadas, y el rechazo lo hace el servidor, no la pantalla. Ocultar un botón no es control de acceso.
Lo que se hizo queda registrado
Las decisiones comerciales se graban como eventos, y no como un campo que la siguiente modificación sobrescribe. La recomendación original, la decisión de la persona, el acercamiento, la respuesta del cliente y el desenlace quedan vinculados entre sí.
Para su negocio, esto sirve para responder preguntas como *"¿por qué se le ofreció este material a este cliente?"*, *"¿quién cambió al responsable de esta oportunidad?"* y *"¿qué respondió el cliente, y cuándo?"* — meses después, sin depender de la memoria de nadie.
Es un historial de lo que ocurrió en la operación comercial. No es un registro de auditoría de seguridad en sentido formal: Stonen no mantiene un registro propio de intentos de inicio de sesión, porque la autenticación la hace un sistema de identidad separado.
Las contraseñas no se guardan aquí
Stonen no guarda contraseñas. Quien autentica es un sistema de identidad separado, y el producto recibe solo la confirmación de quién es la persona y de a qué tiene derecho.
La consecuencia práctica: retirarle el acceso a alguien no depende de tocar Stonen, y un problema en Stonen no expone las credenciales de nadie.
Esto también es una dependencia: sin el sistema de identidad disponible, nadie entra. El producto se construyó para negarse a arrancar sin él, en lugar de abrir una puerta alternativa.
Copias de seguridad y recuperación
Existen cuatro capas de copia, con cadencias distintas, porque cada una protege contra una falla diferente: error de aplicación, pérdida de la máquina, pérdida de la cuenta del proveedor y pérdida total.
La restauración fue ensayada, y no solo documentada: en una prueba con registro de fecha, la base de datos volvió a responder en unos 15 segundos.
| Capa | Protege contra | No protege contra |
|---|---|---|
| CapaCopia diaria en el propio servidor | Protege contraerror de aplicación, eliminación accidental | No protege contrapérdida del servidor |
| CapaCopia diaria a otro lugar, cifrada | Protege contrapérdida del servidor | No protege contrapérdida de la cuenta del proveedor |
| CapaCopia dos veces al día fuera del proveedor, cifrada | Protege contrapérdida del servidor y de la cuenta | No protege contradías en que la máquina de origen no se enciende |
| CapaCopia semanal de la máquina completa | Protege contrapérdida total | No protege contrahasta 7 días de atraso |
Lo que todavía no existe: recuperación a un instante exacto (*point-in-time*). El peor caso realista de pérdida es la ventana entre dos copias — unas 24 horas. Cerrar eso es una decisión de costo pendiente, y está registrada como tal.
Lo que todavía no existe
Esta lista está aquí porque decidir con ella es distinto de decidir sin ella.
- No hay monitor externo a la máquina. Existe un vigilante que detecta "la aplicación se cayó" y avisa. No detecta "el servidor entero murió", porque vive en el servidor.
- No hay nivel de servicio contratado (SLA). La medición de disponibilidad empezó en septiembre de 2026; sin historial no hay base para prometer una cifra en un contrato, y prometer sin base sería peor que no prometer.
- No hay certificación ni auditoría externa de seguridad.
- La recuperación a un instante exacto no existe — ver la sección anterior.
- Una sola empresa en producción. El aislamiento entre organizaciones está probado, pero el comportamiento con varias empresas simultáneas todavía no se ha medido a escala real.
Cada uno de estos puntos tiene responsable y costo identificados en el seguimiento interno del producto. Ninguno está olvidado; algunos esperan una decisión de inversión.
Página actualizada el 22 de septiembre de 2026.