Acceso justo a tiempo con Monopam
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 8 → 9
ActualizaciónNuevo módulo sobre el diseño de aprobaciones: dónde se configura la aprobación, cómo funcionan la ventana y el número de aprobadores, y las aprobaciones para proveedores, usuarios externos y ejecuciones de scripts. El módulo incluye ahora diagramas y, al final, una lista de qué comprobar primero.
2 lecciones actualizadasduración
Actualización de contenido. Se notificó a los estudiantes inscritos.
La duración cambió de 20 a 21 minutos.
"Póngale una aprobación" puede significar tres ajustes distintos en Monopam. Están en lugares diferentes y se comportan de forma diferente, así que el primer paso del diseño es nombrar cuál hace falta.
| Quiere aprobación antes de que | Configure | Ventana que obtiene el solicitante |
| --- | --- | --- |
| Alguien se conecte a un recurso | `Approvement` en la pestaña `Advanced` de los ajustes del recurso, con sus aprobadores | Una solicitud de conexión simple obtiene 8 horas fijas desde ahora, y esa duración no se puede cambiar en el recurso. LaUna ventana distinta se pide con la opción `Scheduled` de la ventana de conexión, visibleque solo aparece cuando el recurso exige aprobación, permite pedir en. La solicitud es entonces del tipo `Scheduled Connection` y su lugar una ventana elegidadetalle muestra el `Requested Access Period` |
| Alguien revele un campo protegido del vault | Aprobación en `Required` en el flujo de la Vault Access Policy | La duración que pidió la solicitud |
| Se ejecute un comando de shell concreto | Una regla de comandos privilegiados con el comportamiento `Requires Approval` | Una ejecución de exactamente esa línea de comando, dentro de 60 minutos |
::diagram pam-approval-places
Un contratista que necesita dos horas aprobadas en un servidor es, por tanto, un recurso con `Approvement` activado más una solicitud `Scheduled` para esas dos horas. Cuando la ventana se cierra, el acceso termina solo. Nadie tiene que acordarse de quitarlo.
### Qué le hace a la ventana una aprobación tardía
Una aprobación de política tiene un tipo de duración. Decide qué pasa cuando el aprobador es más lento de lo que esperaba el solicitante.
| Tipo | Regla | Solicitud de 14:00 a 16:00, aprobada a las 15:15 |
| --- | --- | --- |
| `OnRequest` | La ventana se desplaza al momento de la aprobación y conserva su duración | 15:15 a 17:15 |
| `OnSchedule` | La ventana se queda exactamente donde la puso el solicitante | 15:15 a 16:00. El retraso se pierde |
Use `OnSchedule` cuando importa la hora en sí, como una ventana de cambio acordada con el negocio. Use `OnRequest` cuando la persona simplemente necesita cierto tiempo de trabajo.
### Cuántos aprobadores
Un elemento Approval nombra aprobadores y dice cuántos hacen falta.
| Ajuste | Significado |
| --- | --- |
| `RequireAll` | Deben aprobar todos los aprobadores nombrados |
| `MinimumApprovalCount` | Bastan N cualesquiera de los nombrados |
| `RequireBySelf` | El solicitante se añade como aprobador y el número necesario sube en uno |
Seis personas nombradas con `MinimumApprovalCount` en 3 significa tres cualesquiera de las seis. Añada `RequireBySelf` y la solicitud necesita cuatro aprobaciones: la confirmación del propio solicitante y otras tres. `RequireBySelf` sirve como paso deliberado de "confirmo que pido esto", no como forma de reducir el número de aprobadores independientes.
Una solicitud sin aprobador no desaparece. Muestra la insignia `No approver` y un superadministrador puede decidirla. Aun así, trate esa insignia como un error de configuración que corregir.
### ¿Deny o aprobación para un comando?
Ambos comportamientos detienen una línea de comando antes de que llegue al shell. Elija preguntándose si el comando es legítimo alguna vez.
- Nunca legítimo desde una sesión intermediada: `Deny`.
- Legítimo pero raro y de gran impacto, como reiniciar un host de base de datos de producción: `Requires Approval`. Una segunda persona es testigo de cada ejecución.
- Rutinario: ninguno. Cada aprobación cuesta la atención de un aprobador, y quien recibe cincuenta peticiones al día deja de leerlas.
### Qué reduce de verdad el privilegio permanente
La grabación y la rotación son valiosas, pero con ellas el acceso sigue existiendo todo el tiempo. El privilegio deja de ser "permanente" solo cuando falta por defecto: una concesión que termina sola al cerrarse su ventana, o un paso de aprobación que se interpone cada vez entre una persona y un secreto. Cuando alguien pregunte qué controles reducen el privilegio permanente, esos son los dos tipos que hay que nombrar.
> Consejo: cuando un solicitante se queje de que la ventana aprobada fue más corta de lo pedido, mire antes que nada el tipo de duración. Con `OnSchedule`, una aprobación tardía consume parte de la ventana por diseño.
Con terceros es donde el acceso justo a tiempo demuestra su valor. Sigamos a una contratista, Deniz, de un proveedor de mantenimiento, durante toda la vida de su acceso.
::diagram pam-vendor-access
### 1. La invitación es en sí una solicitud
Un superadministrador usa `Invite External User`. Eso no crea una cuenta. Crea una solicitud de aprobación.
- Los aprobadores son los superadministradores **distintos del solicitante**. Solo cuando hay un único superadministrador esa persona aprueba su propia solicitud.
- Puede haber una invitación abierta por dirección de correo. Una segunda para la misma dirección se rechaza mientras la primera está pendiente.
- Tras la aprobación, Deniz recibe un correo de inscripción y pasa a ser una usuaria externa con fecha de caducidad.
Una invitación aprobada no se puede retirar desde `Requests`, porque el correo ya salió. Si la aprobación fue un error, termine el acceso donde vive la cuenta: `Deactivate` en la página `Users`, o deje que caduque.
### 2. Caducidad y `Extend Access`
Cuando termina el periodo de acceso, la cuenta se deshabilita. `Extend Access` da una nueva fecha de fin y vuelve a habilitar una cuenta deshabilitada **por caducidad**. No vuelve a habilitar una cuenta que un administrador deshabilitó a propósito y que no había caducado. Una fecha nueva nunca anula una decisión deliberada.
### 3. Las barreras del proveedor
La cuenta de Deniz pertenece a una organización proveedora, y el proveedor lleva ajustes que se aplican a todos sus usuarios.
| Ajuste del proveedor | Efecto | Atención |
| --- | --- | --- |
| `Require approval for every connection (JIT)` | Toda conexión de los usuarios del proveedor necesita aprobación, en cualquier recurso | En un recurso sin flujo de aprobación propio, la solicitud se envía a todos los superadministradores. Asegúrese de que lo esperan |
| `Allowed Sites` | Los usuarios del proveedor solo pueden conectarse a recursos de los sitios seleccionados | Un recurso sin sitio cuenta como **fuera**. El usuario ve "This resource's site is not allowed for your vendor organization." incluso con una política válida |
La solución del segundo caso es asignar el recurso al sitio correcto, no relajar el proveedor. Una política decide a qué puede llegar un usuario. `Allowed Sites` es una comprobación aparte que se hace al crear la sesión y de nuevo al conectar.
### 4. Scripts en muchos servidores
La Script Library tiene dos puertas opcionales. La **aprobación de publicación** significa que una versión nueva de un script necesita un aprobador antes de poder ejecutarse. La **aprobación de ejecución** significa que una solicitud de ejecución necesita un aprobador. Una solicitud puede apuntar a muchos recursos y se aprueba una vez para todo el lote, no una vez por servidor. Por eso los aprobadores deben leer la lista de destinos con tanto cuidado como el script.
### 5. Cuando el acceso termina antes de lo aprobado
Si un usuario informa de que una concesión aprobada dejó de funcionar antes de su hora de fin, hay dos causas habituales.
| Comprobación | Significado |
| --- | --- |
| El estado de la solicitud es `Cancelled` | Alguien revocó la concesión |
| La concesión es para consultas de base de datos y la solicitud no está cancelada | Una concesión así puede llevar un límite de uso. Compare el recuento usado con el límite: cuando se agotan las ejecuciones permitidas, la concesión termina aunque el reloj no |
### Qué comprobar primero cuando un usuario de proveedor no puede conectarse
1. ¿Está activa la cuenta? Una cuenta caducada queda desactivada y `Extend Access` la recupera. Una cuenta desactivada a propósito sigue desactivada.
2. ¿Está el recurso en uno de los `Allowed Sites` del proveedor? Un recurso sin sitio cuenta como fuera.
3. ¿Hay una solicitud en espera? Con `Require approval for every connection (JIT)` cada conexión necesita aprobación, y en un recurso sin flujo de aprobación propio la solicitud espera a los superadministradores.