Resumen
Utilice esta lista siempre que se proponga una política de identidad, acceso o endpoints como un diff versionado. Aplíquela antes de abrir el cambio, durante la revisión, antes del merge y después del despliegue. Ajuste la profundidad de la revisión y la supervisión al riesgo del cambio, pero no omita la responsabilidad, la aprobación independiente, la validación ni las evidencias.
Antes de abrir el cambio
- Limite el cambio a un propósito claro. Separe las correcciones no relacionadas en diffs distintos para que puedan evaluarse de forma independiente.
- Mantenga el diff lo bastante pequeño como para revisarlo en detalle, incluida la salida de política generada y las dependencias afectadas.
- Explique por qué se necesita el cambio, qué resultado se espera y qué usuarios, dispositivos, cargas de trabajo, recursos, entornos y responsables de política están dentro del alcance.
- Asigne un responsable y una clasificación de riesgo, y vincule un registro de cambio o issue. Registre plazos, dependencias y restricciones operativas.
- Compare la propuesta con la política declarada y efectiva actual, no con lo que recuerda el autor ni con una exportación obsoleta.
- Para el acceso temporal o las excepciones, codifique un vencimiento automático con fecha, hora y zona horaria exactas. Asigne un responsable a toda revisión posterior necesaria.
Durante la revisión
- Cambio efectivo. Revise el cambio resultante de permisos o postura, no solo las líneas editadas. Confirme qué pasa a estar permitido, denegado, exigido, exento o heredado.
- Alcance y mínimo privilegio. Confirme que el cambio no sea ni más amplio ni más limitado de lo previsto y que no cree privilegios innecesarios, combinaciones de permisos peligrosas ni conflictos de separación de funciones.
- Radio de impacto. Cuantifique las identidades, grupos, dispositivos, aplicaciones, cargas de trabajo, recursos y entornos afectados. Investigue cualquier diferencia respecto de la población esperada.
- Dependencias y conflictos. Compruebe grupos anidados, roles heredados, precedencia, perfiles de endpoint superpuestos y cambios recientes o pendientes que puedan ampliar o deshacer silenciosamente la propuesta.
- Duración. Confirme si el cambio debe ser permanente. Verifique que las concesiones y excepciones temporales venzan automáticamente en lugar de depender solo de un recordatorio.
- Recuperación. Defina una vía de recuperación probada y adecuada al riesgo: revertir, corregir hacia delante, pausar la aplicación, aislar el objetivo o utilizar un procedimiento de emergencia aprobado. Especifique las señales y la autoridad necesarias para activarla.
- Acceso de emergencia. Si el cambio afecta al acceso break-glass, confirme que sea intencionado, verifique que siga disponible una vía de recuperación independiente y pruébela mediante el procedimiento aprobado de la organización.
- Mapeo de cumplimiento. Si el cambio implementa o afecta a un control supervisado, vincule el requisito correspondiente e identifique las evidencias que deben conservarse.
- Revisión independiente. Exija la aprobación de una persona distinta del autor y del responsable de la política o del sistema cuando el cambio afecte a su ámbito de control.
Validación automática
- Valide la sintaxis, el esquema, las referencias, los tipos y los campos obligatorios de la política. Trate como errores las advertencias que puedan modificar la aplicación.
- Ejecute pruebas para permisos previstos y denegaciones esperadas, incluidos límites, precedencia, herencia, vencimiento y comportamiento fail-closed.
- Haga fallar la comprobación si no se descubre ninguna prueba de política o si la salida generada difiere del artefacto revisado.
- Genere el cambio efectivo de política o permisos en un formato que el revisor pueda inspeccionar. Señale incorporaciones, eliminaciones, excepciones y variaciones del número de objetivos que no se esperaban.
- Ejecute las comprobaciones obligatorias contra la revisión exacta pendiente de aprobación y repítalas cuando cambien el diff, las dependencias o la baseline de destino.
Antes del merge y el despliegue
- Valide el cambio, cuando sea posible, en un entorno de staging representativo, una simulación, una cuenta de prueba o un grupo canary. Incluya escenarios de éxito previsto y de denegación esperada.
- Defina anillos de despliegue, criterios de éxito y cancelación, señales de supervisión y la persona autorizada para pausar el despliegue o iniciar la recuperación.
- Utilice reglas del repositorio que exijan revisión del Pull Request, comprobaciones de estado correctas y, cuando corresponda, aprobación del responsable de la política. Impida los push directos y las omisiones no revisadas en la rama protegida.
- Vincule la aprobación al diff exacto. Invalide o repita la aprobación si un commit posterior, un cambio de dependencia o la resolución de un conflicto modifica lo que se va a fusionar.
- Confirme que el artefacto desplegable se deriva de la revisión examinada y que el registro de producción puede identificar esa revisión.
- Notifique al help desk, los equipos afectados, seguridad y los responsables del servicio en el momento definido por el plan. Si el merge despliega automáticamente, complete la comunicación necesaria antes del merge.
Después del despliegue
- Registre la revisión y el artefacto desplegados, el entorno, la persona o identidad de automatización, las horas de inicio y finalización, la población objetivo y el resultado.
- Verifique el estado efectivo en objetivos representativos. Compruebe que el acceso previsto funciona, las denegaciones esperadas siguen vigentes y los controles no relacionados no han cambiado.
- Supervise las señales definidas de éxito, fallo y recuperación durante un periodo adecuado al riesgo y la frecuencia de uso. No aplique la misma ventana fija a todas las políticas.
- En un despliegue por etapas, compare los resultados canary con los criterios de aceptación y cancelación antes de ampliar al siguiente anillo.
- Confirme que la conciliación continua esté activa cuando sea compatible. De lo contrario, asigne un responsable y una frecuencia de verificación para detectar desviaciones respecto del estado aprobado.
- Adjunte al registro de cambio las evidencias de validación, aprobación, despliegue, estado observado, excepciones y recuperación antes de cerrarlo.
Ejemplo práctico
Cambio propuesto: añadir contractor-jane a finance-readonly hasta 2026-10-31T23:59:59-04:00.
Antes de abrirlo, el autor limita el cambio a una identidad y un grupo, registra el motivo de negocio y el responsable, vincula la contratación y codifica el vencimiento en la política. Durante la revisión, el revisor examina los permisos efectivos heredados mediante finance-readonly, confirma que el rol no puede escribir ni exportar datos restringidos, verifica el número de objetivos y comprueba cambios superpuestos.
Las comprobaciones automáticas validan la política y prueban tanto el acceso permitido a informes como las operaciones de escritura denegadas. Antes del merge, una identidad de prueba representativa confirma el comportamiento esperado; las comprobaciones y la aprobación del responsable de la política están vinculadas a la revisión más reciente, y el help desk recibe el aviso del despliegue.
Después del despliegue, el registro identifica la revisión aprobada y el objetivo. El responsable verifica el acceso efectivo de Jane y las operaciones denegadas, supervisa las señales definidas y confirma que la conciliación eliminará o señalará la concesión si permanece activa después del vencimiento codificado.
Fallos habituales
- Cambio sin alcance preciso. Se modifica un rol o grupo amplio cuando bastaría una identidad, un recurso, una acción o una clase de dispositivo específicos.
- Vencimiento ausente. El acceso temporal se vuelve permanente porque su retirada depende de un recordatorio o ticket posterior.
- Diff engañoso. Las líneas editadas parecen seguras, pero la herencia, la precedencia o la salida generada producen un cambio efectivo más amplio.
- Denegación no probada. El caso correcto funciona, pero nadie verifica que las acciones prohibidas continúen bloqueadas.
- Aprobación obsoleta. Un commit posterior o la resolución de un conflicto modifica el diff después de su aprobación.
- Recuperación insegura. Una reversión ciega restaura acceso excesivo o elimina una protección más reciente.
- Evidencia incompleta. El repositorio muestra la aprobación, pero no puede demostrar qué revisión llegó a producción ni si el estado efectivo convergió.
Cómo utilizar este recurso
Convierta las comprobaciones aplicables en una plantilla de Pull Request y aplique controles objetivos mediante reglas del repositorio e integración continua. Defina niveles de riesgo para mantener ágiles los cambios rutinarios y exigir una revisión, pruebas, despliegue y evidencias más rigurosos en cambios de alto impacto sobre identidad, endpoints, acceso privilegiado y acceso de emergencia.
Recursos relacionados
- Consulte la guía GitOps para cumplimiento de endpoints para conocer el modelo completo de revisión, aplicación y conciliación.
- Consulte Revisar cambios de políticas de acceso como código para profundizar en la revisión de cambios efectivos de permisos.