CallwiseDocs

Modelo de seguridad

Las reglas que Postgres hace cumplir, sea lo que sea que envíen la aplicación o un cliente de API.

La aplicación oculta lo que usted no puede usar, pero ocultarlo no es la protección. Cada regla de abajo la hace cumplir la base de datos con seguridad a nivel de fila, permisos de columna, triggers o funciones de comprobación, y cada una tiene una prueba que intenta romperla (pnpm test:rls; consulte Pruebas).

Las tablas del producto empiezan con cw_ y cada fila pertenece a un espacio de trabajo. El acceso lo decide una sola función, cw_can_access(workspace, module, level), que usa cada política.

Las reglas

#ReglaCómo lo hace cumplir Postgres
1Solo la facturación puede cambiar el plan, el estado, el período o la asignación de la bolsa de un espacio de trabajo.Los usuarios con sesión iniciada pueden leer cw_subscriptions, pero no tienen permiso de escritura sobre ella.
2Nadie desbloquea un módulo sin pagar. Los módulos nuevos empiezan en locked; activar un módulo bloqueado falla.Los usuarios no pueden escribir access_state; los propietarios solo pueden actualizar enabled, y un trigger lo rechaza en los módulos bloqueados.
3Publicar un guion exige publish en Recepcionista.Las versiones solo las crea cw_publish_agent(), que comprueba el nivel. Se rechazan las escrituras directas a las versiones o al puntero publicado.
4Los registros de llamadas no se pueden reescribir desde la aplicación. Solo cambian la marca de revisión y el indicador, y quien revisa es siempre usted.Permiso de columna solo en los campos de revisión; un trigger fija a quien revisa y la hora a partir del usuario con sesión iniciada.
5Los usuarios no pueden crear llamadas ni líneas de transcripción.No hay permiso de inserción. Solo el servicio de voz, a través del webhook firmado, las escribe.
6Un módulo en none, o apagado, no devuelve filas.cw_can_access en cada política de lectura.
7Un espacio de trabajo nunca ve los datos de otro.cw_can_access comprueba primero la pertenencia.
8Las personas no pueden subir su propio nivel de acceso.Solo los propietarios y los administradores editan el acceso; los administradores no pueden tocar las filas del propietario.
9Las entradas de auditoría solo se escriben como usted mismo.La política de inserción exige actor_type = 'user' y su propio id de usuario; no hay actualizaciones ni eliminaciones.
10Un espacio de trabajo de solo lectura no se puede modificar.cw_can_access limita cada nivel a view en los módulos de solo lectura.
11Borrar a quien llama, y enrutar un número de teléfono, exigen publish.cw_erase_caller() comprueba el nivel; la política de actualización de los números de teléfono exige publish.
12Las notas pertenecen a su autor.Las inserciones deben usar su propio id de usuario; usted solo puede editar o borrar sus propias notas.

Otras protecciones

  • Rol de servicio. La clave que omite estas reglas se usa en un solo archivo del servidor (apps/web/lib/callwise/service-role.ts), para la facturación y el webhook de voz.
  • Webhook de voz. Firmado con HMAC, con la marca de tiempo comprobada dentro de 5 minutos, idempotente por id de evento.
  • Grabaciones. Bucket privado; un archivo solo se puede leer con view en Recepcionista dentro de su espacio de trabajo; no hay cargas desde la aplicación.
  • Webhooks salientes. Las URL de destino pasan un control del lado del servidor antes de que se envíe nada.
  • El modo de demostración no puede ejecutarse en producción sin un ALLOW_DEMO_IN_PROD=true explícito, y nunca hace una solicitud al exterior.

Lo que aún no está cubierto

No se ha hecho una auditoría de seguridad externa ni una prueba de penetración, y Callwise no tiene ninguna certificación de cumplimiento. Consulte Datos y privacidad.

On this page