KairosLink
Acceso a equipos
Cómo decidir qué técnico puede tocar qué equipo: los dos modos, las cuatro capacidades, los cinco alcances y cuál regla gana cuando dos se contradicen.
Por defecto, cualquier técnico de tu organización puede trabajar sobre cualquier equipo. Eso alcanza para un MSP chico, pero deja de alcanzar cuando hay un junior que no debería tocar servidores, un proveedor externo que solo atiende a un cliente, o un cliente que exige que su infraestructura la toquen dos personas y no doce.
Este módulo define quién puede hacer qué sobre cada equipo.
Cómo se entra
Configuración, sección Seguridad, Acceso a equipos. Necesitás el permiso de configuración de la organización, que por defecto tienen Owner y Admin.
La tarjeta se le muestra a todo el mundo, pero quien no tiene el permiso recibe un error al entrar.
Las tres piezas
Para que un técnico pueda hacer algo sobre una máquina tienen que alinearse tres cosas:
- El permiso de su rol. Si no tiene el permiso de control remoto, ninguna regla de acceso se lo va a dar. Las reglas recortan, nunca amplían.
- El modo de tu organización. Qué pasa cuando ninguna regla dice nada.
- Las reglas de ese técnico. Lo puntual.
Los dos modos
Permisivo (el que viene por defecto): sin ninguna regla que aplique, el técnico puede. Las reglas de denegar recortan.
Restrictivo: sin ninguna regla que aplique, el técnico no puede. Las reglas de permitir habilitan, una por una.
El modo se cambia con Guardar modo. Todo cambio queda auditado.
Pensalo bien antes de pasar a restrictivo. En ese modo, un técnico sin reglas cargadas se queda sin acceso a nada. Si vas a cambiarlo, cargá primero las reglas de permitir y después cambiá el modo.
Las cuatro capacidades
Cada regla habilita o bloquea una capacidad específica, no el equipo entero:
| Capacidad | Qué habilita |
|---|---|
| Control remoto | Conectarse a la pantalla del equipo con el visor. Disponible en equipos Windows y macOS |
| Ejecución | La consola de comandos y las herramientas en vivo |
| Parches | Escanear e instalar actualizaciones en ese equipo |
| Monitoreo | Ver las métricas y la ficha del equipo |
Están ordenadas de la más invasiva a la más inocua. Un técnico puede tener parches sobre un servidor y no control remoto: son decisiones separadas.
Ojo con una combinación en particular. El equipo aparece en el listado si el técnico tiene al menos una capacidad, pero abrir la ficha exige Monitoreo. Un técnico con Ejecución y sin Monitoreo va a ver el equipo en su lista, hacer clic y recibir un error. Si le das cualquier capacidad sobre un equipo, dale también Monitoreo.
Los cinco alcances
Una regla se aplica sobre uno de estos cinco:
| Alcance | Sobre qué |
|---|---|
| Equipo | Una máquina puntual |
| Grupo de AD | Un grupo de Active Directory |
| Unidad organizativa | Una OU del dominio, incluidas sus OU hijas |
| Cliente | Todos los equipos de un cliente |
| Todos los equipos | Toda tu flota |
Los dos alcances de Active Directory solo aparecen si ya corriste un descubrimiento de AD. Si no hay nada relevado, el formulario te lo dice y te sugiere correrlo.
Lo que no existe como alcance: no se puede definir una regla sobre un grupo de equipos del panel, ni sobre un sitio, ni sobre una etiqueta. Son esos cinco.
Las reglas son por persona
Una regla se aplica a un usuario y a uno solo. No hay reglas por rol, ni por equipo de trabajo, ni por grupo de usuarios.
Si querés que diez técnicos tengan la misma restricción, hacen falta diez reglas. Es el límite más incómodo del módulo, y conviene saberlo antes de diseñar tu esquema.
Se llega desde el listado de técnicos, entrada Ver reglas. Se agregan con Agregar regla y se sacan con Eliminar regla. Las altas y las bajas quedan auditadas.
Cuál regla gana
Esta es la parte que hay que entender bien, porque no funciona como la mayoría espera.
Denegar no gana siempre. Gana la regla más específica, sin importar su efecto.
El orden de especificidad, de más a menos:
- Equipo
- Grupo de AD
- Unidad organizativa
- Cliente
- Todos los equipos
Un permitir sobre un equipo puntual le gana a un denegar sobre todo el cliente. Eso es intencional: te deja escribir "denegar todo el cliente, permitir este equipo" y que haga exactamente lo que se lee.
Denegar gana solo ante empate exacto, o sea cuando las dos reglas tienen el mismo alcance y la misma prioridad.
La prioridad
Cada regla tiene un número de prioridad, de 1 a 9999, que viene en 100. Menor número gana, y solo desempata entre reglas del mismo alcance.
Tres ejemplos
Especificidad manda sobre el efecto. Denegar Ejecución sobre el cliente 5, y permitir Ejecución sobre el equipo 42, que es de ese cliente. Resultado sobre el 42: permitido.
Empate exacto: gana denegar. Permitir Parches sobre el equipo 42, y denegar Parches sobre el equipo 42, las dos en prioridad 100. Resultado: denegado.
La prioridad desempata dentro del mismo alcance. Dos reglas sobre el mismo cliente, una en prioridad 50 y otra en 100. Gana la de 50.
Por qué el grupo de AD está por encima de la OU: un grupo se arma a propósito para juntar máquinas ("Servidores críticos"), mientras que una OU refleja estructura heredada del dominio. El grupo expresa mejor la intención.
Cuando no se puede evaluar una regla de AD
Un equipo puede no tener datos de Active Directory por varias razones: nunca se relevó el dominio, el relevamiento es viejo, el equipo no está en el dominio, o no se pudo emparejar.
En esos casos KairosLink no adivina. Las reglas de grupo de AD y de OU se saltean, porque tratar "no tengo datos" como "no pertenece a ningún grupo" convertiría un permiso en denegación, o al revés.
Consecuencia práctica que conviene tener presente: una regla de AD sobre un equipo que no tiene datos relevados no aplica, y hoy la pantalla no lo indica. Si cargaste una regla de grupo y no ves el efecto que esperabas, verificá que ese equipo tenga descubrimiento de AD reciente.
Qué ve un técnico sin acceso
En el listado de Equipos, la máquina no aparece. No sale tachada ni deshabilitada: no está. Y el refresco automático de esa pantalla respeta el mismo filtro.
Si entra por dirección directa, recibe un error con el motivo, y queda registrado en la auditoría.
Las acciones están bloqueadas en todas partes. No puede conectarse, ni ejecutar comandos, ni parchear, ni tocar el monitoreo de ese equipo desde ninguna pantalla del panel. Eso es lo que garantiza el módulo.
Lo que sí sigue viendo
El filtro de visibilidad se aplica al listado de Equipos, no a las demás grillas. En parches, monitoreo, antivirus, postura de seguridad, DLP, certificados, el mural, los reportes y el selector de equipos de un ticket, ese equipo se sigue leyendo: nombre, cliente, estado y sus contadores.
No puede actuar sobre él desde ahí, pero lo ve.
Dicho corto: el módulo controla la acción, no la visibilidad del nombre. Si tu caso de uso es que un proveedor externo no vea siquiera los nombres de las máquinas de otros clientes, eso queda fuera de lo que este módulo resuelve.
Los botones no desaparecen
El único que refleja el acceso es Conectar, que se muestra deshabilitado con el motivo en el globito. Todos los demás (consola, archivos, servicios, procesos, parchear) se dibujan siempre y fallan al usarse.
El control está; el aviso visual, no.
Los roles
El Owner nunca queda sin acceso. Está exento de las reglas por diseño: no hay forma de dejar afuera al dueño de su propia flota.
El Admin sí es restringible. Si le cargás reglas, se le aplican. Es intencional: permite tener administradores acotados a un conjunto de clientes.
Técnico y Lectura se rigen enteramente por sus permisos de rol más sus reglas.
Dónde se ve quién tiene acceso a qué
Podés ver qué equipos puede tocar una persona, entrando a sus reglas desde el listado de técnicos.
No existe la vista inversa. No hay ninguna pantalla que responda "quién puede tocar este equipo". Si necesitás auditarlo, hay que revisar técnico por técnico.
Lo que sí queda registrado: los cambios de modo, las altas y bajas de reglas, y cada intento denegado.
Lo que hoy no hace
- No hay reglas por rol ni por grupo de usuarios. Una regla, una persona.
- No se puede definir una regla sobre un grupo de equipos del panel, un sitio o una etiqueta.
- El filtro de visibilidad solo se aplica al listado de Equipos. En las demás grillas el equipo se sigue leyendo.
- No hay una pantalla que muestre quién tiene acceso a un equipo dado.
- Los botones no se ocultan según el acceso, salvo Conectar.
- Una regla de AD que no se puede evaluar no avisa en ninguna pantalla.
Preguntas frecuentes
¿Por dónde empiezo si quiero restringir a alguien? Cargale primero las reglas y después, si hace falta, cambiá el modo. Cambiar a restrictivo sin reglas cargadas deja a todos sin acceso.
Puse un denegar sobre el cliente y el técnico igual entra a un equipo. Fijate si hay un permitir sobre ese equipo puntual: lo más específico gana, sin importar el efecto.
¿Denegar no gana siempre? No. Gana solo cuando empata en alcance y en prioridad con un permitir.
Le di acceso a un equipo y al hacer clic le da error. Abrir la ficha exige la capacidad de Monitoreo. Dásela junto con la que ya tenía.
Quiero la misma restricción para diez técnicos. Hoy hacen falta diez reglas. No hay reglas por rol ni por grupo.
Cargué una regla de grupo de AD y no pasa nada. Si el equipo no tiene datos de Active Directory relevados, esa regla se saltea. Corré un descubrimiento de AD.
¿Puedo dejar sin acceso al Owner? No. Está exento por diseño.
¿Puedo acotar a un Admin? Sí. Los Admin sí se restringen con reglas.
¿Cómo sé quién tiene acceso a un servidor puntual? Hoy no hay una pantalla que lo muestre: hay que revisar las reglas de cada técnico.
Le saqué el acceso y lo sigue viendo en Parches. El filtro que oculta el equipo se aplica al listado de Equipos. En las otras grillas lo ve, pero no puede actuar sobre él.
Actualizado el 22 de agosto de 2026