breezeauth.com
ES
Iniciar sesiónEmpieza gratis
Usuarios de servicioRestricciones y seguridad

Restricciones y seguridad

Los controles que limitan lo que pueden hacer los usuarios de servicio, hasta cuándo funcionan sus credenciales y desde qué redes pueden conectarse.

En esta página
  1. Resumen de los controles
  2. Dar solo el acceso necesario
  3. Cortar integraciones al instante
  4. Limitar la vida útil de las credenciales
  5. Restringir las redes desde las que se conectan los usuarios de servicio
  6. Supervisar la actividad
  7. Lista de comprobación de seguridad

La credencial de un usuario de servicio funciona sin que nadie escriba una contraseña ni responda a un desafío de autenticación multifactor, así que merece el mismo cuidado que la cuenta de un administrador. BreezeAuth te ofrece varios controles para que el poder y la exposición de cada usuario de servicio sean lo más reducidos posible. Combínalos.

Resumen de los controles

Control Qué limita Dónde se configura
Rol administrativo Qué puede hacer el usuario de servicio El formulario Editar del usuario de servicio
Estado del usuario de servicio Si el usuario de servicio puede funcionar Pestaña Visión general del usuario de servicio › Cambiar estado
Estado de la credencial Qué credenciales funcionan El formulario Editar de la credencial › Activa
Caducidad de la credencial Hasta cuándo funciona una credencial La fecha en Caduca el de la credencial
Zonas de red Desde dónde puede conectarse el usuario de servicio Organización › Ajustes de seguridad › Ajustes de restricción de acceso por red
Restricción por país Desde qué países se puede acceder a la organización Organización › Ajustes de seguridad › Restringir el acceso por país

Algunos límites son fijos y no se pueden cambiar: los usuarios de servicio no pueden iniciar sesión en la consola de administración ni en las aplicaciones, no pueden ser Propietarios y no pueden añadirse a grupos ni asignarse a aplicaciones.

Dar solo el acceso necesario

El rol administrativo decide qué operaciones puede realizar el usuario de servicio a través de la API; todo lo demás se rechaza. Elige el rol más limitado que cubra la integración, por ejemplo Auditor para informes de solo lectura o Aprovisionador SCIM para el aprovisionamiento de usuarios, y evita Administrador salvo que no funcione nada más. Consulta Elegir un rol.

Crea un usuario de servicio por integración. Así, cada uno tiene solo el acceso que necesita, sus acciones son fáciles de distinguir en los Registros de auditoría y desactivar uno no afecta a los demás.

Cortar integraciones al instante

Puedes cortar el acceso en dos niveles, y ambos se aplican en la siguiente petición a la API, también para los tokens de acceso ya emitidos que aún no han caducado:

  • Desactiva una credencial para detener una instalación de una integración, o un secret que puede haberse filtrado. Las demás credenciales del usuario de servicio siguen funcionando. Consulta Desactivar una credencial.
  • Desactiva el usuario de servicio para detener la integración por completo, sean cuales sean sus credenciales. Consulta Desactivar o reactivar un usuario de servicio.

Ambas acciones pueden deshacerse reactivando.

Limitar la vida útil de las credenciales

Siempre que puedas, pon una fecha en Caduca el a las credenciales. Una credencial que caduca por sí sola limita el daño de un secret que se haya filtrado sin que nadie lo note, y convierte la rotación en una rutina. Los propios tokens de acceso son siempre de corta duración y no existen refresh tokens: cuando una credencial se desactiva o caduca, nada derivado de ella sigue funcionando.

Restringir las redes desde las que se conectan los usuarios de servicio

Las integraciones suelen ejecutarse desde un lugar conocido: tu centro de datos, una cuenta en la nube o un servidor con direcciones IP públicas fijas. Puedes hacer que BreezeAuth rechace las peticiones desde cualquier otro lugar, de modo que un secret robado no sirva de nada fuera de esas redes.

Para ello se usan las zonas de red: listas con nombre de rangos de direcciones IP que defines una vez y reutilizas. Cuando la restricción de acceso por red de la organización está activa:

  • un usuario de servicio solo puede obtener tokens de acceso desde una zona de red permitida;
  • cada petición que hace a la API también se comprueba y se rechaza con network_not_authorized si procede de fuera de las zonas permitidas.

Para configurarlo:

  1. Averigua las direcciones IP públicas que usan los servidores de tu integración para salir a internet. Tu proveedor de nube o de alojamiento, o tu equipo de redes, puede indicártelas; los servidores detrás de un NAT gateway suelen compartir su dirección fija.
  2. Crea una zona de red para ellas, por ejemplo “Servidores de integración”.
  3. Restringe el acceso a la organización a esa zona y a las zonas desde las que se conectan tus personas.

Atención: la restricción de red de la organización se aplica a todos los miembros, tanto personas como usuarios de servicio, y no solo a los usuarios de servicio. Antes de guardar, asegúrate de que las zonas seleccionadas incluyen las redes de todos los administradores y de las personas que usan la organización, o perderán el acceso de inmediato, tú incluido.

Si la organización también usa Restringir el acceso por país, esa restricción se aplica a las peticiones a la API de los usuarios de servicio: las peticiones procedentes de un país no permitido se rechazan con access_not_allowed_from_country.

Supervisar la actividad

Los Registros de auditoría registran cuándo se crean, modifican o eliminan usuarios de servicio y credenciales, cada vez que se usa una credencial para obtener un token de acceso y las acciones que realizan los usuarios de servicio. En la pestaña Credenciales de cada usuario de servicio, la columna Último uso indica cuándo se intercambió cada credencial por un token por última vez.

Revísalos con regularidad: una credencial que nunca se usa puede eliminarse, y la actividad a horas poco habituales o desde lugares inesperados merece una revisión más detenida.

Lista de comprobación de seguridad

  • Cada integración tiene su propio usuario de servicio.
  • Cada usuario de servicio tiene el rol más limitado que funciona.
  • Los client secrets se guardan en un gestor de secretos o en variables de entorno protegidas, nunca en el código ni en los dispositivos de los usuarios.
  • Las credenciales tienen fecha en Caduca el y una rutina de rotación.
  • Las credenciales que no se usan se desactivan y después se eliminan.
  • Si las integraciones se ejecutan desde direcciones fijas, la organización restringe el acceso a zonas de red conocidas.
  • Alguien revisa periódicamente los Registros de auditoría y las fechas de Último uso.
  • Todo el mundo sabe cómo desactivar una credencial o un usuario de servicio en caso de emergencia.

Última actualización: 13 de octubre de 2026