MFA antes del acceso protegido
Las áreas protegidas requieren un nivel de autenticación AAL2. Una sesión con contraseña solamente no satisface el acceso a la operación protegida.
SEGURIDAD
Seguridad integrada desde el diseño.
La confianza no debería depender únicamente de lo que muestra una pantalla. Diseñamos nuestros productos para aplicar límites sobre quién entra, qué puede hacer, qué información puede ver y qué actividad queda registrada.
DATOSOperación
IDENTIDADAUTORIZACIÓNPOLÍTICASLa seguridad empieza antes de que una persona abra el producto.
Identidad, permisos, acceso a los datos y trazabilidad trabajan juntos. Ninguna capa sustituye a las demás.
Identidad verificada
El acceso protegido parte de una identidad autenticada y, donde corresponde, de un segundo factor antes de entrar a la operación.
Acceso según responsabilidad
Los permisos se definen alrededor del rol y las capacidades necesarias para el trabajo de cada persona.
Protección a nivel de datos
Las reglas de acceso se aplican sobre la información y no dependen únicamente de ocultar elementos en la interfaz.
Trazabilidad
La actividad relevante se conserva para dar contexto sobre lo que ocurrió dentro del sistema.
La seguridad no vive en una sola capa.
Cada solicitud atraviesa distintos límites antes de llegar a la información que necesita.
- 01IDENTIDAD
Quién eres
La sesión y el nivel de autenticación establecen el punto de entrada.
- 02AUTORIZACIÓN
Qué puedes hacer
Roles, capacidades y pertenencia a la organización delimitan las acciones disponibles.
- 03DATOS
Qué puedes ver
Las políticas de acceso filtran la información según la organización, el contexto y la sensibilidad.
- 04TRAZABILIDAD
Qué queda registrado
Actividad y eventos de auditoría conservan evidencia de acciones relevantes sin depender de la memoria del usuario.
Prosper/Legal convierte esos principios en límites concretos.
Nuestro primer producto aplica estas decisiones dentro de una arquitectura multi-tenant diseñada para separar organizaciones, usuarios y responsabilidades.
Aislamiento entre organizaciones
La autorización se evalúa con la identidad del usuario y su membresía. La aplicación no confía en un identificador de usuario enviado por el cliente para decidir acceso.
Visibilidad según sensibilidad
La información sensible puede quedar completamente fuera de una consulta cuando la persona no tiene el acceso correspondiente, en lugar de mostrarse parcialmente o como un conteo oculto.
Historial que conserva contexto
La actividad operativa relevante se registra de forma append-only para preservar la secuencia del trabajo y evitar que la historia dependa de registros editables.
Soporte con límites claros.
Ayudar a diagnosticar un problema no debería significar abrir la operación de un cliente.
- 01
Identidades separadas
Los operadores de Prosper utilizan una identidad separada del acceso normal de una organización. Una identidad de soporte no se convierte en miembro del despacho para poder ayudar.
- 02
Diagnóstico mínimo
Las herramientas de soporte están diseñadas para trabajar con estados, identificadores, fechas, conteos y señales de configuración en lugar de navegar libremente por contenido jurídico.
- 03
Información reducida cuando no es necesaria
Los datos de contacto se limitan o enmascaran en diagnósticos donde el valor completo no es necesario para resolver el problema.
- 04
Sin impersonación como atajo
El flujo de soporte no entrega una sesión del cliente ni utiliza impersonación para entrar a su aplicación.
Control también significa poder reconstruir lo que ocurrió.
Prosper separa la actividad operacional del producto de los eventos de auditoría y del registro de acciones internas. Eso permite conservar contexto sin convertir la auditoría en un repositorio de contenido sensible.
Los registros de actividad conservan la secuencia operativa relevante.
Los eventos de auditoría guardan metadatos estructurados en lugar de copiar contenido sensible cuando no es necesario.
Las acciones internas de operador pueden mantenerse en un registro separado del historial del cliente.