Gestión de usuarios
Añada, edite y elimine usuarios de su organización. Gestione roles, asignaciones de equipo y monitorice el progreso individual.
Lista de usuarios
La página Usuarios muestra a todos los miembros de la organización en una tabla ordenable y buscable. Cada fila muestra el nombre del usuario, su correo, equipo, rol y último inicio de sesión. Los usuarios deshabilitados se marcan en línea con una pequeña píldora DISABLED — no hay una columna de estado aparte. Un botón Exportar CSV en la parte superior de la página descarga la lista completa de usuarios con los totales de progreso.
| Columna | Descripción |
|---|---|
| Nombre | Campo único de nombre para mostrar (no separado en nombre / apellido). |
| Correo | Dirección de correo de inicio de sesión — usada para acceder con código mágico. |
| Equipo | Equipo al que pertenece el usuario (en blanco si está sin asignar). |
| Rol | org_admin o learner. |
| Último inicio de sesión | Fecha y hora del inicio de sesión más reciente del usuario. En blanco para usuarios que aún no han iniciado sesión. |
Añadir usuarios
Hay dos formas de añadir usuarios a su organización:
Manual
Haga clic en + Añadir usuario e introduzca el nombre, correo, rol (learner o org_admin) y opcionalmente un equipo. No se envía ningún correo de invitación. Comparta usted mismo la URL de inicio de sesión con el usuario; solicitará un código mágico en la página de inicio de sesión e iniciará sesión con el código de seis dígitos que le enviamos por correo.
Aprovisionamiento SCIM
Configure SCIM para sincronizar automáticamente los usuarios desde su proveedor de identidad (Okta, Azure AD). Los usuarios se crean y desactivan automáticamente según cambia su directorio.
Límites de puestos
Su organización tiene un número máximo de puestos en función de su plan. Añadir un usuario más allá de ese tope falla con el error Seat limit reached (N). Contact support to increase. — la propia página Usuarios no expone hoy un contador de puestos en vivo; use la página Informes o la API pública GET /api/public/v1/org para leer maxSeats frente al recuento actual de usuarios.
Editar usuarios
Haga clic en una fila de usuario para abrir la página de detalle del usuario; el botón Editar abre un modal que permite a los administradores de la organización cambiar las siguientes cuatro propiedades. Cada campo es obligatorio y la edición actúa como un reemplazo completo — para mantener un campo sin cambios, deje el valor actual.
| Campo | Editable |
|---|---|
| Nombre | Sí — campo único de nombre para mostrar. |
| Correo | Sí — cambiarlo no reenvía ningún correo. |
| Rol | Sí — learner ↔ org_admin. |
| Equipo | Sí — elija un equipo o déjelo sin asignar. |
| Contraseña | No — no hay campo de contraseña. Los usuarios inician sesión con un código mágico o SSO; nada que los administradores deban establecer o restablecer. |
Eliminar usuarios
La acción Eliminar en la página de detalle del usuario elimina el propio registro del usuario. Una vez eliminado, la persona ya no puede iniciar sesión. Eliminar un usuario libera un puesto frente a su tope de maxSeats.
Los datos históricos del usuario — resultados de desafíos de práctica, progreso en escenarios de aprendizaje, finalizaciones de asignaciones, certificados obtenidos — no se borran de la base de datos, porque esas tablas no se eliminan en cascada con el registro del usuario. En la práctica, sin embargo, esos datos dejan de ser visibles: todos los informes, clasificaciones, verificaciones de certificado y páginas de detalle de usuario hacen join con el registro del usuario para mostrarlos, así que una vez desaparece la fila del usuario, las filas quedan como huérfanas que la interfaz no expone.
Volver a añadir el mismo correo tras una eliminación crea un usuario nuevo con un nuevo id interno. Las antiguas filas huérfanas no se vuelven a vincular — no hay una ruta de "restaurar" en la interfaz de administración.
Si quiere mantener visible el historial de formación del usuario por retención de evidencias, auditorías de cumplimiento o escenarios de recontratación, no use Eliminar. O bien desaprovisione al usuario aguas arriba mediante SCIM (que lo marca como inactivo pero mantiene la fila del usuario en su sitio) o simplemente deje la cuenta en paz — no podrá iniciar sesión si su buzón ya no recibe el código mágico.
Roles
SecureCodingHub admite dos roles a nivel de organización:
| Rol | Puede hacer |
|---|---|
| Administrador de organización | Gestionar usuarios, equipos, asignaciones, ver el panel, configurar SSO/SCIM/SCORM |
| Estudiante | Completar desafíos, ver el propio progreso, gestionar preferencias |
Gestión de puestos
Su organización tiene un límite de maxSeats determinado por su plan de suscripción. Hoy no hay un contador de puestos en vivo en la cabecera de la página Usuarios; si necesita monitorizar el uso, léalo desde la API pública (GET /api/public/v1/org devuelve maxSeats) y compárelo con el recuento actual de usuarios. Póngase en contacto con su responsable de cuenta para subir el tope si necesita puestos adicionales.
Interfaz de la lista de usuarios
Así es la página de gestión de usuarios:
Modal de añadir usuario
Hacer clic en + Añadir usuario abre el siguiente formulario. El selector de rol usa dos tarjetas en paralelo en lugar de un desplegable:
Por qué importa una gestión de usuarios cuidadosa
La mayoría de las organizaciones no se dan cuenta de la proliferación de puestos hasta que aparece en la factura de renovación. Un puñado de contratistas terminan un proyecto y se quedan en el directorio. Un equipo se reorganiza y la antigua pertenencia al equipo nunca se limpia. Dos ingenieros dejan la empresa pero el ticket de off-boarding olvidó la plataforma de formación. En un año, el veinte por ciento de los puestos por los que paga su equipo financiero pertenecen a personas que no inician sesión, y las cuentas que quedan no reflejan quién está realmente en el equipo hoy.
La proliferación de puestos es también un problema de seguridad. Cada cuenta inactiva es una credencial que un atacante puede atacar mediante reutilización de contraseñas, phishing o secuestro de sesión. El mismo SSO que da acceso a su plataforma de revisión de código puede dar acceso aquí, y una cuenta que nadie vigila es la más fácil de comprometer sin hacer ruido. Tratar la lista de usuarios como un artefacto vivo, no como un backlog, cierra esa brecha antes de que se convierta en un incidente.
Auditar trimestralmente el mapeo usuario-equipo
Una revisión trimestral sencilla mantiene la plantilla en orden. Exporte la lista de usuarios, filtre por último inicio de sesión hace más de noventa días y pregunte al responsable de línea si cada persona debe permanecer. Coteje la columna Equipo con su sistema de RR. HH. o el organigrama — cualquiera cuya pertenencia al equipo ya no coincida con su rol real es candidato a reasignación. Preste especial atención a los usuarios sin equipo asignado, ya que normalmente se escapan de las asignaciones a nivel de equipo y sesgan las tasas de finalización a la baja sin que nadie se dé cuenta.
Si usa Aprovisionamiento SCIM, la mayor parte de este trabajo ocurre automáticamente. La pertenencia a grupos en Okta o Azure AD fluye al mapeo de equipos, y desaprovisionar a un usuario en el proveedor de identidad lo desactiva en SecureCodingHub en el siguiente ciclo de sincronización. La auditoría se convierte entonces en una comprobación de cordura, en lugar de una reconciliación manual.
Por qué el desaprovisionamiento importa para las evidencias de cumplimiento
PCI DSS 8.1.3 y el control A.9.2.6 de ISO 27001 exigen ambos que el acceso de usuarios dados de baja se revoque con prontitud. Los auditores buscan evidencia — un evento con marca de tiempo que muestre cuándo la cuenta dejó de poder iniciar sesión, idealmente vinculado a la fecha de off-boarding en RR. HH. El botón Eliminar satisface la revocación de acceso, pero también elimina el registro del usuario, lo que significa que su formación completada deja de ser visible en los informes — las filas siguen existiendo como huérfanas pero ninguna interfaz las expone. Si su auditoría necesita que ese historial siga apareciendo como evidencia, desaprovisione mediante SCIM (que marca la cuenta como inactiva manteniendo el registro del usuario en su sitio) en lugar de usar Eliminar. El registro de auditoría registra ambas acciones.
Para los equipos que ejecutan formación en codificación segura como parte de su paquete de evidencias PCI DSS 6.2.2, la lista de usuarios sirve también como prueba de quién estaba dentro del alcance durante el periodo de auditoría. Capture una instantánea en el momento de la auditoría — bien desde el botón Exportar CSV, bien a través de la API pública — y consérvela junto al resto de su paquete de evidencias.