Seguridad

Seguridad y sesiones

Cómo GovFrame protege el aislamiento por empresa, verifica el acceso y revoca sesiones ante cambios sensibles.

Descargar Markdown
  1. Antes de empezar
  2. Recorrido recomendado
  3. Límites y controles del estado actual
  4. Resultado esperado

GovFrame es un servicio de gobierno de datos multiempresa. La seguridad funcional parte de una regla simple: los datos, configuraciones, relaciones, auditoría y operaciones de una empresa permanecen separados de los de las demás. La aplicación determina el contexto de empresa antes de autorizar una consulta o una acción; cambiar un identificador en el navegador no concede acceso a otra empresa.

La protección combina identidad, pertenencia, rol, capacidad, alcance y módulo. El servicio la aplica aunque una opción no esté visible. Por ejemplo, un Data Steward solo puede mantener objetos de negocio en los Dominios o Subdominios asignados.

Antes de empezar

  • Rol: el Administrador revisa accesos de su empresa. Las operaciones globales corresponden al Superadministrador o Administrador de plataforma autorizados; los demás perfiles operan dentro de su responsabilidad y alcance.
  • Módulo: la administración de accesos y el módulo de negocio implicado deben estar habilitados. Un módulo desactivado no queda operable por conocer una ruta o modificar parámetros.
  • Precondiciones: confirme una sesión válida, una pertenencia vigente, una empresa en condición de operar normalmente y, cuando corresponda, el Dominio, Subdominio o Repositorio de la acción.

Recorrido recomendado

  1. Confirme el contexto efectivo de empresa. Normalmente, GovFrame lo resuelve a partir del hostname normalizado. Una persona Superadministradora puede seleccionar una empresa disponible para operación normal en una tarea de plataforma; las personas usuarias ordinarias no eligen libremente otra empresa. Una misma identidad puede tener pertenencias diferentes por empresa.

  2. Revise la autorización completa antes de actuar. GovFrame comprueba pertenencia, rol, capacidad, alcance del objeto y módulo. El Administrador tiene alcance global en su empresa; el Ingeniero de datos, alcance técnico de Repositorios; y Data Owner o Data Steward, ámbito taxonómico asignado. El rol global de Superadministrador no elimina estas comprobaciones.

  3. Mantenga el aislamiento en las asociaciones. Todo objeto y relación deben pertenecer a la empresa efectiva. Una asociación entre Atributo, campo técnico, Regla o Contrato documenta trazabilidad, no permisos. Compruebe el contexto taxonómico y las relaciones registradas antes de atribuir una dependencia.

  4. Use los flujos de identidad previstos. GovFrame admite inicio de sesión local, recuperación de acceso y autenticación federada. Las contraseñas locales se conservan como hashes, nunca en texto claro. Para una identidad federada, la comprobación de correo verificado se realiza de forma estricta; una señal ambigua no debe aceptarse como verificación. No comparta contraseñas, tokens, enlaces de recuperación ni datos de autenticación por comentarios, evidencias o registros operativos.

  5. Trate los cambios sensibles como eventos de sesión. Las sesiones se transportan mediante una cookie HTTP-only y se verifican frente al estado vigente de la cuenta. Al cambiar una contraseña propia, el flujo puede renovar únicamente la sesión actual. En cambio, un restablecimiento mediante token, un restablecimiento administrativo, la suspensión, el rechazo de registro o un cambio de rol o alcance revoca las sesiones afectadas. Después de uno de esos cambios, pida a la persona que vuelva a autenticarse en lugar de intentar reutilizar una sesión anterior.

  6. Aplique las mismas precauciones a conectores y archivos. Las credenciales no se devuelven al cliente; secretos y archivos privados permanecen en almacenamiento seguro y la base conserva referencias y metadatos. Los conectores validan destinos y verifican TLS por defecto. Esto no autoriza conexiones de clientes ni garantiza exploraciones programadas: dependen de configuración y alcance técnico.

Ejemplo sintético: una persona ficticia pasa de Data Steward a Usuario para un Dominio. El cambio de rol o alcance invalida las sesiones previas afectadas. Al volver a iniciar sesión, solo podrá participar en las fichas y tareas que su nuevo perfil, alcance y módulos habilitados permitan; no recupera edición porque conserve una URL antigua.

Límites y controles del estado actual

  • La seguridad no se basa en ocultar opciones: el servicio rechaza operaciones sin pertenencia, capacidad, alcance o módulo permitido.
  • La desactivación de un módulo bloquea su operación y puede ocultar sus accesos, pero no elimina automáticamente los datos ya registrados. Reactivar un módulo sigue sujeto a rol, alcance y condición de los datos.
  • Los riesgos, alertas o controles pueden visualizarse como información derivada de reglas de calidad, políticas, workflows, tareas, contratos, clasificaciones o certificaciones. No existe un catálogo independiente de Riesgos o Controles que sustituya estos objetos.
  • Esta guía describe controles funcionales documentados; no publica secretos, identificadores personales, detalles de infraestructura, duración de credenciales ni procedimientos internos de autenticación.

Resultado esperado

Al finalizar la revisión, cada acción queda vinculada a una empresa efectiva y a una autorización comprobable. Las personas acceden solo a los objetos y módulos que les corresponden, y los cambios sensibles obligan a renovar el acceso cuando procede.

Para profundizar en el contexto de los objetos y las responsabilidades, consulte Modelo de objetos y relaciones, Cómo leer el mapa de relaciones, Roles, capacidades y alcance y Módulos y dependencias.

Fuentes de esta documentación

  • CONTEXT.md
  • ARCHITECTURE.md
  • TESTING_GUIDE.md
  • AGENTS.md
  • Modelodeobjetosyrelaciones.md
  • Módulosydependencias.md
  • Roles,capacidadesyalcance.md