# Políticas de destino y de control

> Agrupa los recursos en políticas de destino y decide con políticas de control qué comandos sudo y qué programas de Windows se permiten, se rechazan o esperan aprobación.

URL: https://docs.ironchip.com/pam/administracion/politicas/

Las políticas de PAM son piezas que nombra un [acceso](https://docs.ironchip.com/pam/administracion/accesos/): 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](https://docs.ironchip.com/identidad/conceptos/politicas/) del acceso, y la aprobación se define en [políticas de aprobación](https://docs.ironchip.com/pam/administracion/aprobadores/).

## 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**.

   [Imagen: Página Target policies con cada política, sus máquinas y los accesos que la nombran]

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](https://docs.ironchip.com/pam/administracion/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**.

   [Imagen: Página Control policies con cada política, sus reglas y los accesos que la nombran]

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**.

   [Imagen: Ventana Add control policy con reglas de sudo permitidas, rechazadas y que piden aprobación]

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](https://docs.ironchip.com/pam/administracion/aprobadores/#comandos-que-esperan-aprobaci%C3%B3n) 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](https://docs.ironchip.com/pam/administracion/cuentas/) 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](https://docs.ironchip.com/pam/administracion/accesos/): dónde se nombran estas políticas.
- [Aprobación](https://docs.ironchip.com/pam/conceptos/aprobacion/): cómo funciona la aprobación de accesos y de comandos.