Llaves de acceso y aprobaciones
Firme con una llave de acceso las reparaciones de IA que aprueba, para que cada servidor compruebe la aprobación por sí mismo y ni siquiera el servidor principal pueda aprobar nada por su cuenta.
Cuando la guardia de IA quiere ejecutar una reparación que necesita su aprobación, usted la aprueba con una llave de acceso: su dispositivo firma la operación exacta (con su huella, su rostro o un PIN). El ayudante root del servidor comprueba esa firma con las claves en las que confía, y comprueba además la firma propia del servidor principal en cada operación. Así, ni siquiera un servidor principal comprometido puede aprobar, cambiar ni agregar una operación.
Mientras un servidor no confíe en las claves, la IA solo ejecuta diagnósticos allí: ninguna reparación.
Requisitos
- El panel en HTTPS (o abierto en
localhost). Los navegadores solo permiten llaves de acceso en páginas seguras. Consulte HTTPS. - Una versión actual de Chrome, Edge, Safari o Firefox, y un dispositivo con lector de huellas, reconocimiento facial, un PIN o una llave de seguridad (por ejemplo una YubiKey).
- Siempre la misma dirección. Una llave de acceso pertenece al nombre de host con el que abrió el panel al crearla, por ejemplo
monitor.example.com. Apruebe en esa misma dirección.
Agregar una llave de acceso
Abra Configuración → Llaves de acceso y haga clic en ＋ Agregar llave de acceso.
Dele un nombre, por ejemplo "MacBook Touch ID", "iPhone" o "YubiKey", y haga clic en Crear llave de acceso. El navegador le pide su huella, su rostro o su PIN.
Los servidores confían en la primera llave de acceso del panel cuando root confirma su huella en cada servidor, o cuando se instala un agente con el comando del panel. Consulte Servidores.
Cualquier llave de acceso posterior muestra Esperando una firma hasta que un administrador que ya tiene una llave de acceso de confianza hace clic en Confirmar con mi llave de acceso. Solo entonces la aceptan los servidores.
Cada administrador puede registrar varias llaves de acceso, por ejemplo una en la laptop y otra en el celular. Registre una segunda, para poder seguir aprobando si pierde un dispositivo.
| Estado | Significado | Botones |
|---|---|---|
| De confianza | Los servidores aceptan las aprobaciones firmadas con ella | Revocar |
| Esperando una firma | Creada, pero todavía no firmada por una llave de acceso de confianza | Confirmar con mi llave de acceso, Eliminar |
| Revocada | Ya no se acepta | — |
Revocar hace que los servidores dejen de aceptar las aprobaciones firmadas con esa llave de acceso, en cuanto reciben el registro firmado.
Servidores
Un servidor solo confía en las claves después de un paso en el propio servidor: el servidor principal no puede hacer que un servidor confíe en nada.
-
Los servidores instalados con el comando de instalación del panel confían en ellas automáticamente: el comando contiene las huellas de la clave de firma del servidor principal y de las llaves de acceso de confianza (
--master-key …y--approvers …). -
Servidor principal + agente: el instalador confía en las claves de su propio servidor principal.
-
Servidores ya instalados: ejecute en cada uno
sudo 3rmonitor approvers trustMuestra la huella de la clave de firma del servidor principal y la de cada llave de acceso. Compárelas con Configuración → Llaves de acceso → Huellas para comparar y escriba
yes. Configuración → Llaves de acceso también muestra el mismo comando con las huellas, para ejecutarlo sin preguntas.
A partir de entonces, cada cambio (una llave de acceso nueva, una revocada) es un registro numerado y firmado que los servidores comprueban por sí mismos. El servidor principal no puede inventar uno. Los servidores aplican un registro nuevo, y las claves de confianza de approvers trust, en segundos.
La lista Servidores de Configuración → Llaves de acceso muestra cada servidor:
| Se muestra | Significado |
|---|---|
| Al día: "N claves de confianza (registro N)" | Las reparaciones que usted aprueba pueden ejecutarse allí |
| Requiere acción: "Todavía no confía…" | Ejecute sudo 3rmonitor approvers trust en ese servidor |
| Requiere acción: "N claves de confianza; obteniendo el registro más reciente…" | El servidor se pone al día en segundos. Mientras un servidor se pone al día, la página se actualiza sola. |
| No disponible | El agente es anterior a la 1.1.0, o su ayudante no está en ejecución. Consulte Solución de problemas. |
| Problema | El registro no se puede aplicar; se muestra el motivo |
En un servidor:
sudo 3rmonitor approvers list # las claves en las que confía este servidor
sudo 3rmonitor approvers trust # confía en la clave del servidor principal y en las llaves de acceso de los administradores
sudo 3rmonitor approvers reset # deja de confiar en todas las claves (las reparaciones se detienen hasta que vuelva a confiar)Si se pierden todas las llaves de acceso
En cada servidor, ejecute sudo 3rmonitor approvers reset.
En Configuración → Llaves de acceso, registre una llave de acceso nueva. Vuelve a ser la primera.
En cada servidor, ejecute sudo 3rmonitor approvers trust y compare las huellas.
Trasladar el servidor principal
La clave de firma del servidor principal es el archivo signing.key en /var/lib/3rmonitor. Una copia de seguridad del directorio de datos la incluye, así que los servidores siguen confiando en un servidor principal restaurado a partir de ella. Si configura un servidor principal nuevo sin la copia de seguridad, los servidores no confían en su clave: siga los pasos anteriores en cada servidor. Haga lo mismo si el panel pasa a otro nombre de host, porque las llaves de acceso pertenecen al nombre de host.