Administración y controles

Documento: LK-MAN-ES-03 · Versión: 0.1
Última actualización: 2026-07-18 · Estado: draft / requires product review and legal review where applicable
Audiencia: administradores, owners y responsables de seguridad

Este manual describe controles operativos; no certifica cumplimiento legal ni reemplaza la evaluación jurídica de cada organización.

Índice

1. Modelo de organización y roles
2. Miembros e invitaciones
3. Claves API e integraciones
4. Política de alertas
5. Plan y facturación
6. Cuenta, MFA y privacidad
7. Controles de seguridad y datos
8. Matriz de responsabilidades
9. Checklist periódico

<a id="modelo-de-organizacion-y-roles"></a>

1. Modelo de organización y roles

Figura 1. Miembros, accesos y configuración de una organización sintética. Captura: 2026-07-18.

El aislamiento por organización evita que una solicitud autorizada en un tenant acceda a otro. Los permisos se evalúan junto con la organización activa y el recurso solicitado.

1.1 Capacidades por rol

El rol entrega un máximo, no una obligación. Asigne Member por defecto y eleve privilegios solo cuando la función lo requiera.

<a id="miembros-e-invitaciones"></a>

2. Miembros e invitaciones

1. Abra Organization.
2. Revise miembros activos e invitaciones pendientes.
3. Invite usando la dirección corporativa correcta y el rol mínimo necesario.
4. Verifique aceptación y retire invitaciones vencidas o erróneas.
5. Al cambiar funciones o terminar una relación, reduzca o revoque el acceso sin demora.

Controles recomendados:

• mantenga al menos dos owners cuando la gobernanza interna lo permita;
• no otorgue Owner para tareas operativas normales;
• revise periódicamente cuentas inactivas y dominios de correo externos;
• conserve la trazabilidad de altas, cambios de rol y bajas en el registro de auditoría;
• trate el correo, nombre y membresía como datos personales necesarios para administrar el servicio.

<a id="claves-api-e-integraciones"></a>

3. Claves API e integraciones

El acceso API está incluido por defecto en Business. Admin y Owner pueden administrar claves de la organización.

3.1 Creación segura

1. Defina una finalidad y responsable técnico.
2. Elija los scopes mínimos necesarios.
3. Configure expiración cuando esté disponible.
4. Copie el secreto una sola vez a un gestor de secretos.
5. Pruebe en un entorno controlado y registre la integración.

No incluya claves en repositorios, tickets, capturas, logs ni reportes. La plataforma no debe devolver el secreto original después de crearlo; rote inmediatamente ante sospecha de exposición.

3.2 Webhooks y proveedores

Los webhooks están disponibles desde Pro, sujetos al límite del plan. Use HTTPS, valide autenticidad, restrinja destinos y evite enviar más información que la necesaria. Documente cualquier proveedor externo, su finalidad, región, retención y relación contractual antes de usarlo en producción.

No almacene payloads completos solo para depuración. Prefiera identificadores de evento, estado, idempotency key y errores sanitizados.

<a id="politica-de-alertas"></a>

4. Política de alertas

Figura 2. Canales, reglas y controles de entrega. Captura: 2026-07-18.

La configuración puede incluir canales, destinatarios, umbrales de expiración, deduplicación, escalamiento, webhooks y quiet hours según el plan.

Pruebe cada canal después de configurarlo y cada vez que cambien credenciales, destinos o reglas. No envíe evidencia sensible a listas de distribución amplias.

<a id="plan-y-facturacion"></a>

5. Plan y facturación

Figura 3. Vista de plan Business y consumo de límites. Captura: 2026-07-18.

Solo Owner administra billing. La pantalla reúne plan actual, capacidades, consumo de límites y, cuando están habilitados, suscripción, datos tributarios, métodos de pago, facturas y transferencias.

• Confirme la organización activa antes de cualquier cambio.
• Use datos de facturación autorizados y minimizados.
• No copie datos de tarjetas ni secretos del proveedor en comentarios o soporte.
• Conserve facturas y registros conforme a obligaciones financieras aplicables.
• Los overrides de una organización pueden modificar capacidades o límites; Billing es la fuente operativa de verdad.

Los detalles exactos por plan están en el manual 04.

<a id="cuenta-mfa-y-privacidad"></a>

6. Cuenta, MFA y privacidad

Figura 4. Perfil de una identidad sintética reservada para documentación. Captura: 2026-07-18.

Cada persona administra su perfil. Las funciones pueden incluir:

• nombre e imagen; imágenes admitidas JPEG, PNG o WebP y sujetas a validación de tamaño;
• cambio de contraseña y MFA;
• idioma, zona horaria y formatos;
• consentimientos opcionales para finalidades no esenciales;
• exportación de datos personales, corrección y cierre de cuenta.

Los consentimientos opcionales deben mantenerse separados de autenticación, seguridad, facturación y demás tratamientos necesarios para prestar el servicio. Un cierre de cuenta no implica borrar registros de auditoría, seguridad o facturación que deban retenerse; se pueden bloquear, anonimizar o conservar con justificación.

<a id="controles-de-seguridad-y-datos"></a>

7. Controles de seguridad y datos

7.1 Clasificación de roles de datos

7.2 Controles aplicados

• autenticación, RBAC y autorización por recurso;
• aislamiento multi-tenant mediante org_id o tenant_id;
• DTOs y respuestas que no exponen hashes, tokens ni secretos internos;
• secretos de integraciones y credenciales almacenados de forma protegida;
• logs sanitizados, sin cuerpos, headers, evidencia ni datos personales completos;
• validación de tipo/tamaño y autorización de descarga para archivos y evidencias;
• paginación de listados cuando corresponde;
• retención, exportación y eliminación diferenciadas por clase de dato;
• auditoría de acciones administrativas relevantes;
• controles de plan y límites en el backend, no solo en la interfaz.

7.3 Nunca debe incluirse en una exportación personal

password_hash, secretos TOTP, hashes de códigos de respaldo, tokens de reset, hashes de claves API, secretos de webhooks, access/refresh tokens ni secretos de proveedores.

7.4 Responsabilidad del cliente

El cliente define finalidad, licitud, alcance y usuarios autorizados para la información que carga o configura. Debe minimizar identidades y evidencias, fijar retención, atender solicitudes de titulares cuando corresponda y no usar la plataforma para monitoreo no autorizado.

<a id="matriz-de-responsabilidades"></a>

8. Matriz de responsabilidades

R: ejecuta; A: rinde cuentas; C: consultado. La matriz debe adaptarse al modelo contractual y operativo real.

<a id="checklist-periodico"></a>

9. Checklist periódico

• Revisar owners, admins, miembros e invitaciones.
• Revocar cuentas, claves y webhooks sin responsable.
• Probar canales de alerta y escalamiento.
• Revisar auditoría de cambios administrativos.
• Comparar consumo con límites del plan.
• Revisar datos tributarios, destinatarios de facturas y métodos de pago.
• Confirmar retención y eliminación de evidencia.
• Revisar páginas de estado públicas y reportes programados.
• Confirmar que integraciones y proveedores sigan aprobados.
• Documentar excepciones y fecha de próxima revisión.

Control de cambios: v0.1 — creación inicial, 2026-07-18.