# Aprobaciones

> Define quién aprueba los accesos privilegiados, cuántas personas y cuándo, y decide en la consola las solicitudes y los comandos sudo que esperan aprobación.

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

Esta página explica cómo se configura la aprobación de los accesos privilegiados y cómo se deciden las solicitudes y los comandos que esperan a alguien. Es para quien administra el acceso y para quien aprueba.

## Políticas de aprobación

Una política de aprobación dice quién tiene que decir que sí, cuántas personas y cuánto puede durar la ventana. Se añade a un [acceso](https://docs.ironchip.com/pam/administracion/accesos/) como un factor más, junto al dispositivo y la zona segura, y también decide los comandos `sudo` que una [política de control](https://docs.ironchip.com/pam/administracion/politicas/#pol%C3%ADticas-de-control) envía a aprobación.

### Crear una política de aprobación

1. Ve a **Authentication policies > Approval policies** y haz clic en **New policy**.

   [Imagen: Página Approval policies con quién aprueba, cuántas aprobaciones y la ventana más larga de cada política]

2. Escribe **Name**, por ejemplo `Producción`. Es lo que se elige al configurar los factores de un acceso.
3. En **Who approves**, elige el grupo de aprobadores. Con **Administrators (whoever holds the permission)**, aprueban quienes tienen el permiso **PAM approvals and sessions** con Update. Suele ser mejor nombrar a los dueños del sistema que a los administradores de la plataforma.
4. En **Approvers required**, indica cuántas personas distintas tienen que aprobar (de 0 a 10). Con `0` es autoservicio: la ventana se abre al pedirla, y aun así queda registrada, limitada y revocable.
5. En **When they are asked**, elige el momento:
   - **When access is requested**: se aprueba una vez y se abre una ventana.
   - **When the person connects**: no se pregunta a nadie hasta que la persona se conecta, y la conexión queda retenida mientras deciden.
6. En **Longest window (minutes)**, indica la duración máxima de la ventana (`0` la deja sin límite). Si alguien pide más, se acorta a este máximo.
7. Haz clic en **Create**.

Las condiciones se copian en cada solicitud al hacerla: relajar una política no deja pasar una solicitud a medio aprobar, y endurecerla no afecta a las ventanas ya abiertas. Si un acceso tiene varias políticas de aprobación, se aplica la más estricta: más aprobadores, la ventana más corta y la aprobación al conectar antes que al solicitar.

No se puede borrar una política de aprobación mientras algún acceso la use.

## Decidir las solicitudes

**PAM > Approvals** muestra lo que espera una decisión humana. Ves las solicitudes que puedes decidir: las de las políticas cuyo grupo de aprobadores te incluye o, con el permiso **PAM approvals and sessions** con Update, todas.

[Imagen: Página Approvals con las solicitudes de acceso pendientes, el motivo y las aprobaciones que llevan]

| Columna       | Qué muestra                                        |
| ------------- | -------------------------------------------------- |
| **Who**       | Quién pide el acceso y hace cuánto.                |
| **Wants**     | Las máquinas y la integración por la que las pide. |
| **Why**       | El motivo que escribió.                            |
| **Approvals** | Cuántas aprobaciones lleva y cuántas necesita.     |

1. Lee el motivo en **Why**.
2. Abre **Options** y elige **Approve** o **Deny**. Confirma en la ventana que se abre.

Si hacen falta varias aprobaciones, cada una queda registrada y la ventana se abre con la última. La ventana empieza a contar en ese momento y se cierra sola.

Las solicitudes que se aprueban **al conectar** aparecen cuando la persona se conecta, con su conexión retenida. Lo que apruebas es esa conexión concreta: una conexión nueva vuelve a preguntar. Si nadie decide en 5 minutos, la conexión se rechaza.

### Reglas

- Nadie aprueba su propia solicitud ni aprueba dos veces la misma. No se puede configurar de otro modo.
- Aprobar no salta ninguna comprobación: el dispositivo, la zona segura y los factores se comprueban en cada conexión.
- Cada solicitud, aprobación, denegación y retirada queda registrada.

## Comandos que esperan aprobación

Cuando una regla de una política de control dice **Ask approvers**, la persona se queda esperando en el `sudo` y el comando aparece en **PAM > Approvals**, en **Commands waiting on a machine**, con quién lo escribió, con qué cuenta, en qué máquina, la línea completa, la regla que pidió la aprobación y el tiempo que queda.

[Imagen: Apartado Commands waiting on a machine con un sudo apk add retenido por una regla y el tiempo que queda]

- Los aprobadores de la política de aprobación de esa regla ven **Approve** y **Refuse**.
- Quien escribió el comando ve **Waiting for its approvers** y puede retirarlo con **Take back**.
- Si nadie decide en 5 minutos, o si la sesión termina antes, el comando se rechaza.
- Nadie aprueba su propio comando.

La decisión aparece en la [grabación](https://docs.ironchip.com/pam/conceptos/grabacion/) de la sesión, con quién lo autorizó o por qué se rechazó.

## Más información

- [Aprobación](https://docs.ironchip.com/pam/conceptos/aprobacion/): los dos momentos de aprobación.
- [Solicitar acceso](https://docs.ironchip.com/pam/usuarios/solicitar-acceso/): la solicitud vista por quien la hace.