Políticas de destino y de control

Las políticas de PAM son piezas que nombra un acceso: las políticas de destino dicen a qué máquinas llega y las políticas de control dicen qué se puede hacer como root una vez dentro. Esta página explica cómo crearlas. Es para quien administra el acceso privilegiado.

Las condiciones con las que se entra (dispositivo, zona segura, factores y aprobación) no están aquí: son las políticas de autenticación del acceso, y la aprobación se define en políticas de aprobación.

Políticas de destino

Una política de destino es un conjunto de máquinas con nombre, como Producción Linux. Un acceso la nombra igual que nombra un grupo de factores, y así dos equipos pueden llegar a las mismas máquinas con condiciones distintas.

Crear una política de destino

1. Ve a PAM > Hosts > Target policies y haz clic en Add target policy.

   

2. Escribe Name y, si quieres, Description (optional), por ejemplo Todos los servidores Linux de producción, en Madrid y en AWS.

3. En Machines, marca las máquinas. Aparecen agrupadas por sitio y una política puede mezclar sitios.

4. Haz clic en Add target policy.

La política no da acceso a nadie hasta que la nombres en un acceso.

Cambiarla o borrarla

• Options > Edit policy cambia el nombre o las máquinas. Los accesos que la nombran llegan a las máquinas nuevas en cuanto guardas, y dejan de llegar a las que quitas.
• Options > Remove policy la borra. Las máquinas se quedan. No se puede borrar mientras algún acceso la nombre: la columna Accesses dice cuáles.

Políticas de control

Una política de control dice qué puede ejecutar como root una persona conectada a través de Ironchip:

• En Linux, cada comando sudo. La máquina pregunta a Ironchip por medio del agente después de que sus propias reglas de sudoers hayan dicho que sí, así que una política solo puede quitar permisos, nunca darlos.
• En Windows, los programas que puede abrir la cuenta con la que entra la persona, que el agente aplica con AppLocker.

Sin agente en la máquina, las políticas de control no se aplican en ella.

La política por defecto

Cada compañía tiene All allowed, la de Ironchip: todo se puede ejecutar y deciden las reglas de la propia máquina. Se ofrece marcada en cada acceso nuevo y no se puede cambiar ni borrar. Para limitar, crea otra.

Crear una política de control

1. Ve a PAM > Hosts > Control policies y haz clic en Add control policy.

   

2. Escribe Name, por ejemplo Operadores web, y si quieres una descripción.

3. En Rules, in order, añade cada regla con Add rule:

   • Kind: Command (sudo) o Windows program.
   • Command: la línea de comando completa tal como se ejecutaría, con la ruta completa del programa: /usr/bin/systemctl restart *. * es cualquier cosa, incluidos espacios y barras; ? es un carácter.
   • Program or path: el nombre del ejecutable, powershell.exe, que vale aunque se copie a otra carpeta, o una ruta con * y las carpetas de Windows: %PROGRAMFILES%\Tools\*.
   • Then: Allow, Refuse o Ask approvers. Con Ask approvers, elige la Approval policy que decide.

4. Ordena las reglas con las flechas: la primera que coincide decide.

5. En Anything else, elige qué pasa con lo que no coincide con ninguna regla. Por defecto, Refuse.

6. Haz clic en Add control policy.

   

Un ejemplo para un equipo que reinicia servicios web y lee sus registros:

#	Kind	Command o programa	Then
1	Command (sudo)	/usr/bin/systemctl restart nginx	Allow
2	Command (sudo)	/usr/bin/journalctl -u nginx*	Allow
3	Command (sudo)	/usr/bin/apt install *	Ask approvers
	Anything else		Refuse

Cómo se decide

• Si un acceso nombra varias políticas, se revisan en el orden en que las marcaste y decide la primera regla que coincide. Si ninguna coincide, se aplica el Anything else más estricto (rechazar antes que pedir aprobación, y pedir aprobación antes que permitir).
• Un comando que espera aprobación aparece en PAM > Approvals y la persona espera en el sudo hasta 5 minutos. Si nadie decide a tiempo, se rechaza.
• Si no hay nadie conectado a la máquina a través de Ironchip, el comando se rechaza. Los comandos que ya se ejecutan como root (uid 0) no se preguntan.
• Si hay dos o más personas conectadas con la misma cuenta, Ironchip no puede saber de quién es el comando y lo rechaza. Usa cuentas distintas para cada equipo.
• En Windows, un rechazo gana a un permiso sea cual sea el orden, y un programa no puede esperar aprobación (Ask approvers no está disponible). Rechazar todo lo demás sigue dejando ejecutar Windows y los programas instalados: detiene lo que la persona trae en sus propias carpetas. Sin nadie conectado, la cuenta mantiene todos los rechazos de todos los accesos que llegan a la máquina, para que las reglas estén puestas antes de que alguien entre; con varias personas conectadas se aplican las reglas más estrictas.
• Un acceso que no nombra ninguna política de control deja la decisión a la máquina.

Al editar una política que nombran accesos, el siguiente comando ya se decide con las reglas nuevas.

Más información

• Accesos: dónde se nombran estas políticas.
• Aprobación: cómo funciona la aprobación de accesos y de comandos.