Plantilla de Revisión de Control de Acceso

Resumen

Las revisiones de acceso son la verificación de higiene periódica que mantiene honesta una política de control de acceso: cada trimestre (o cada mes, para acceso privilegiado) alguien recorre el registro de accesos y pregunta de cada entrada “¿sigue justificado?”. Esta plantilla estructura esa revisión — quién revisa qué, qué evidencia registrar, cómo los hallazgos se convierten en remediación y cómo la atestación se vuelve prueba de auditoría. Da soporte a los requisitos de revisión de SOC 2, ISO 27001 y PCI-DSS documentando quién tiene acceso, por qué lo tiene y si sigue siendo necesario.

La revisión verifica los controles definidos en tu política de control de acceso — la política dice qué debería existir; la revisión prueba que existe. Para la recolección de datos, la Plantilla de Auditoría de Acceso de Usuarios cubre la extracción del snapshot de acceso que esta revisión consume. Los dos documentos responden preguntas distintas: la auditoría pregunta “¿qué acceso existe ahora mismo?” — un inventario puntual con certificación del estado actual. Esta revisión pregunta “¿sigue justificado ese acceso, y qué hacemos con lo que encontramos?” — el ciclo recurrente de decisiones, hallazgos, remediación y atestación al que las auditorías alimentan.

Cuándo Usarla

• Durante revisiones de acceso trimestrales o anuales.
• Antes de una auditoría externa o certificación.
• Después de un cambio de rol, terminación o reorganización.
• Al incorporar o retirar un sistema sensible.
• Cuando se detecta una cuenta con privilegios excesivos.

Prerrequisitos

• Una lista autoritativa de sistemas, roles y usuarios.
• Acceso a logs del proveedor de identidad o APIs de gestión de roles.
• Una política definida de privilegio mínimo y ciclo de vida de roles.
• Un revisor que sea manager o dueño del sistema, no el usuario revisado.

Solución

Plantilla

1. Alcance de la Revisión

Campo	Descripción	Ejemplo
Sistema o aplicación	Recurso bajo revisión	Base de datos de producción
Período de revisión	Fechas de inicio y fin	Q2 2026
Revisor	Persona responsable	Manager de ingeniería
Fecha de revisión	Cuándo se realiza la atestación	2026-06-27
Tamaño de muestra	Número de usuarios revisados	42

2. Registro de Acceso de Usuarios

Usuario	Rol	Permisos	Justificación de negocio	¿Aún requerido?	Notas del revisor
alice@example.com	db-admin	Lectura, escritura, esquema	Mantenimiento de BD	Sí	Válido
bob@example.com	solo-lectura	Lectura	Reportes	No	Desactivar cuenta
deploy-bot	servicio	Desplegar en producción	Pipeline CI/CD	Sí	Gestionado por rol IAM

3. Checklist de Cuentas de Servicio

Cuenta	Propósito	Último uso	Clave rotada	Acción requerida
backup-sa	Backups nocturnos	2026-06-26	Sí	Ninguna
integration-sa	Sincronización con tercero	Nunca	No	Revisar o eliminar
monitoring-sa	Ingesta de métricas	2026-06-27	Sí	Ninguna

4. Hallazgos y Acciones

ID hallazgo	Descripción	Severidad	Dueño	Fecha límite	Estado
AC-01	Dos usuarios con admin nunca lo usan	Media	Equipo IAM	2026-07-04	Abierto
AC-02	Cuenta huérfana de ex-contratista	Alta	Seguridad	2026-06-30	Abierto
AC-03	MFA ausente en tres cuentas privilegiadas	Alta	Equipo identidad	2026-07-02	Abierto

5. Atestación

Campo	Valor
Nombre del revisor	Alice Rivera
Rol	Manager de ingeniería
Fecha	2026-06-27
Resultado	Aprobado con condiciones
Condiciones	Eliminar dos cuentas huérfanas y exigir MFA en 5 días
Próxima revisión	2026-09-27

Explicación

La revisión separa la identificación del acceso de la aprobación. Al listar cada cuenta, su rol, justificacion y necesidad, los revisores pueden detectar acumulacion de privilegios, cuentas huérfanas y MFA faltante. El paso de atestación crea una trazabilidad de auditoría que demuestra cumplimiento.

El detalle de diseño que importa es quién revisa. El trabajo del revisor es detectar lo que el sistema no puede: si el acceso sigue teniendo sentido para el trabajo real de la persona. Por eso la plantilla insiste en que el revisor sea un manager o dueño de sistema y nunca el titular de la cuenta — la auto-revisión certifica lo que ya existe. Y por eso cada fila del registro exige un campo de justificación: “sí” es gratis, pero escribir “Alice necesita acceso a esquema porque es dueña del pipeline de migración” es el acto de pensamiento para el que existe la revisión.

La atestación es el entregable. Todo lo demás — el snapshot, el registro, los hallazgos — existe para sostener la declaración firmada “revisé este acceso en esta fecha, y esto es lo que encontré y decidí”. Los auditores se anclan en ella: la atestación es lo que convierte un ejercicio de spreadsheet en evidencia. Por eso las condiciones van dentro de la atestación (“eliminar dos cuentas huérfanas y exigir MFA en 5 días”) y no en un email posterior — una condición sin registro es un hallazgo que nadie verificará que se resolvió.

Por Qué Fallan las Revisiones

Las revisiones mueren de dos formas. La primera es el aprobado en masa: el revisor aprueba 500 filas en una sesión, lo que significa que nadie las leyó — una revisión donde el 100% del acceso se aprueba sin comentarios es evidencia de que el proceso no opera, no de que el acceso esté limpio. Se arregla reduciendo el alcance (frecuencia por niveles, muestreo) y exigiendo un motivo escrito por fila.

La segunda muerte son los hallazgos sin remediación: la revisión ocurre, los hallazgos se registran y nadie es dueño de resolverlos, así que la siguiente revisión encuentra las mismas cuentas huérfanas. Se arregla tratando cada hallazgo como un ticket con dueño y fecha límite — la atestación no está completa hasta que los hallazgos tienen camino de remediación.

Hay también un fallo más sutil: revisar los datos equivocados. Si el snapshot de acceso viene de un spreadsheet actualizado “cuando alguien se acuerda”, la revisión certifica una fantasía. La automatización — exports del IdP, APIs de IAM, los scripts de esta plantilla — es lo que convierte la revisión de ritual trimestral en control real.

Frecuencia de Revisión por Nivel de Riesgo

No todo merece la misma cadencia. Nivela la revisión por lo que cuesta un error:

Nivel de acceso	Ejemplos	Frecuencia	Revisor
Privilegiado	Admins, deploy a prod, break-glass, admin de BD	Mensual	CISO o responsable de seguridad
Cuentas de servicio	Bots CI/CD, integraciones, API keys	Trimestral	Responsable técnico
Usuarios estándar	Empleados con acceso por rol	Trimestral (o muestra 10-15%)	Manager directo
Externo	Contratistas, vendors, partners	Mensual + caducidad forzada	Manager sponsor
Dormido	Cuentas sin uso 30+ días	Mensual, auto-desactivación	Automatizado + check IT

Los niveles resuelven los dos modos de fallo: revisar todo muy raramente (las revisiones anuales pierden un año de privilege creep en cuentas admin) y revisar todo muy seguido (la fatiga convierte las revisiones en aprobado automático). Un calendario de revisiones con responsables por nivel mantiene la cadencia honesta — el calendario pertenece a compliance, no a la memoria de cada equipo.

Variantes

La misma plantilla se adapta a alcances más estrechos — conserva la estructura y reduce el registro:

• Revisión de acceso privilegiado: Se enfoca solo en administradores, cuentas root y credenciales de emergencia. Mayor frecuencia y SLAs de hallazgos más estrictos.
• Revisión a nivel aplicación: Revisa roles y permisos dentro de una sola aplicación en lugar de infraestructura. Útil cuando un sistema tiene su propio modelo de permisos (Salesforce, una org de GitHub, un cluster de Kubernetes).
• Revisión de IAM en la nube: Apunta a roles, políticas y grupos de AWS, Azure o GCP. Los scripts de automatización de abajo están pensados para esta variante.
• Revisión de contratistas: Revisa acceso con duración limitada y fechas de vencimiento — toda cuenta de contratista debería tener una caducidad al momento de aprovisionarse, y esta revisión verifica que la caducidad existe y se ejecuta.

Lo que Funciona

• Revisa acceso privilegiado mensual, acceso estándar trimestral. La cadencia anual deja que el privilege creep se acumule doce meses — la trimestral lo atrapa cuando la remediación aún es barata.
• El revisor es un manager o dueño de sistema, nunca el titular. La auto-revisión certifica lo que ya existe; la independencia es el control.
• Desactiva automáticamente las cuentas dormidas. La inactividad es la señal más barata de que una cuenta sobra — una regla de 30 días de dormancia elimina la mayoría del trabajo de huérfanas antes de que empiece la revisión.
• Exige MFA en toda cuenta privilegiada. Sin excepciones sin caducidad documentada — la mayoría de exenciones “temporales” sobreviven al motivo por el que se otorgaron.
• Retira el acceso el último día, no la semana siguiente. La ventana de offboarding de 24 horas existe porque las credenciales de ex-empleados son la credencial dormida de mayor valor que un atacante puede encontrar.
• Guarda los registros de atestación mínimo un año. La atestación de la revisión anterior es con lo que los auditores comparan — los hallazgos recurrentes entre ciclos son la señal.

Errores Comunes

• Revisar acceso sin comprobar que la cuenta sigue activa — atestar permisos en una cuenta deshabilitada es un falso positivo que desperdicia la fila.
• Permitir la auto-revisión — certifica el status quo; la independencia es lo que convierte una revisión en revisión.
• Conservar acceso amplio tras un cambio de rol — el hallazgo clásico de privilege creep; arregla el proceso de transferencia, no solo la cuenta.
• Omitir cuentas de servicio y API keys — son la categoría menos revisada y más abusada.
• Perder el acceso a la consola cloud al revisar roles de aplicación — la revisión de la app dice “solo lectura”, la consola dice admin.

Hallazgos Comunes y Cómo Remediarlos

La mayoría de revisiones destapan el mismo puñado de problemas. Conocer la remediación estándar de cada uno mantiene la tabla de hallazgos accionable en lugar de una lista de quejas.

Privilege creep. El hallazgo más común: un usuario cambió de equipo dos veces y conservó todos los roles que tuvo. La remediación es higiene de roles, no una revocación puntual — arregla el proceso de transferencia para que el acceso viejo se retire cuando se otorga el nuevo, o registrarás el mismo hallazgo el próximo trimestre.

Cuentas huérfanas. Cuentas cuyo dueño se fue, cuyo proyecto terminó o cuyo propósito nadie puede explicar. Acción por defecto: desactivar inmediatamente, eliminar tras un periodo de gracia (30-90 días cubre el descubrimiento de “espera, eso corría el informe nocturno”). Documenta la eliminación — los auditores preguntan qué pasó con las huérfanas de revisiones anteriores.

Acceso privilegiado permanente. Admins con acceso permanente a producción cuando existe un flujo just-in-time. La remediación es cambio de proceso (pasar a elevación JIT), no revocación — el acceso suele ser legítimo, la parte permanente es el problema.

MFA faltante en cuentas privilegiadas. Normalmente un puñado de cuentas creadas antes del requisito o exentas “temporalmente”. Arregla las cuentas y el proceso de exención — las exenciones vencidas que nunca vencieron son la causa raíz habitual.

Cuentas de servicio sin revisar. La salida de script que nadie poseía. Toda cuenta de servicio necesita un dueño con nombre y una línea de propósito en el registro; las que no tienen ninguno se marcan para revisión o eliminación. Rota las credenciales de cualquier cuenta que sobreviva la revisión — la revisión es el checkpoint natural de rotación.

Cuentas compartidas y genéricas. Un login finance-readonly que comparten tres analistas elimina la trazabilidad individual — las acciones no pueden atribuirse y dar de baja a una persona deja la credencial viva. La remediación es volver a cuentas nominativas; donde el uso compartido es realmente necesario (un kiosko, una credencial break-glass), regístralo como excepción con dueño y caducidad en vez de fingir que no existe.

Preparar Evidencia para Auditores

El documento de revisión es la mitad del entregable; la otra mitad es el rastro de evidencia que prueba que ocurrió como el documento dice.

Lo que los auditores realmente piden. El snapshot de acceso usado para la revisión (o prueba de que era fresco), el registro completado con decisiones por fila, los tickets de remediación creados desde hallazgos y la atestación firmada. Los artefactos con timestamp superan las descripciones narrativas — un ticket de remediación cerrado antes de la fecha de revisión es evidencia más fuerte que una frase diciendo “se retiró el acceso”.

Preguntas de auditoría comunes para pre-responder. ¿Cómo se eligió al revisor (independencia respecto a los usuarios revisados)? ¿Qué pasó con los hallazgos de la revisión anterior (¿recurren)? ¿Cómo se documentan las excepciones? Si tu atestación dice “aprobado con condiciones”, las condiciones y su resolución son lo primero que se muestrea.

Retención. Guarda el paquete de evidencia completo de cada revisión — snapshot, registro, hallazgos, atestación — al menos un año o según lo exija tu framework. La revisión anual de la política usa estos artefactos; perderlos significa reconstruir un año de decisiones de acceso de memoria.

Ejecutando la Revisión

Una revisión que empieza con “todos mirad vuestro acceso” produce un spreadsheet que nadie termina. El proceso que funciona corre en cuatro etapas:

1. Prepara los datos. Saca un snapshot de acceso fresco — del IdP, de la API de roles de cada sistema o de los scripts de automatización de abajo. El snapshot es la verdad base de la revisión; una revisión sobre un export viejo certifica un estado que ya no existe. Incluye cuentas de servicio y API keys explícitamente — son la categoría más omitida y la de mayor riesgo.

2. Acota el alcance. No tienes que revisar todo en cada ciclo. Nivela por riesgo: todo acceso privilegiado cada ciclo (mensual), todas las cuentas de servicio trimestralmente, acceso de usuarios estándar trimestral o por muestreo. El muestreo es legítimo — una muestra del 10-15% de usuarios estándar atrapa problemas sistémicos (un equipo cuyas transferencias nunca pierden acceso viejo) sin revisar miles de filas.

3. Revisa y registra decisiones. Cada fila recibe un veredicto: mantener, modificar o retirar — con un motivo. Un “sí” sin justificación es lo que los auditores marcan; el valor está en el revisor escribiendo por qué el acceso sigue siendo necesario. Vigila los hallazgos habituales: privilege creep (el usuario acumuló roles por transferencias), cuentas huérfanas (el dueño se fue o el proyecto terminó), MFA faltante en cuentas privilegiadas y acceso otorgado “temporalmente” que nunca caducó.

4. Remedia y atesta. Cada hallazgo se convierte en un ticket con dueño y fecha — la tabla de hallazgos de arriba existe exactamente para esto. La revisión cierra cuando la atestación se firma con las condiciones registradas. Una atestación sin hallazgos registrados es evidencia de que la revisión fue aprobada por inercia.

Chequeo de cadencia. Una revisión que consistentemente encuentra cero problemas suele significar una de tres cosas: el acceso está genuinamente limpio (raro), el alcance está mal (los sistemas de riesgo no están en el snapshot), o el revisor aprueba sin leer (lo más común). Las rachas de cero hallazgos merecen el mismo escrutinio que los malos hallazgos.

Conectando la Revisión con la Política

La revisión no existe aislada — es la mitad operativa del ciclo de vida del control de acceso. La política de control de acceso define cómo debería ser el acceso (roles, reglas de MFA, SLAs de offboarding); la revisión es la prueba periódica de que la realidad coincide. Cuando el mismo hallazgo aparece en revisiones consecutivas — privilege creep cada trimestre, por ejemplo — eso no es un problema de revisión, es un problema de política: el proceso de transferencia definido en la política no funciona, y el arreglo va upstream en la política, no en otra ronda de revocaciones.

El mismo bucle corre en dirección contraria. Los hallazgos de la revisión alimentan la siguiente revisión de la política: brechas repetidas de MFA abogan por un alta más estricta al aprovisionar, cuentas huérfanas recurrentes abogan por triggers automáticos de offboarding, y una lista creciente de excepciones aboga por una sección de excepciones en la propia política en lugar de fingir que no existen. Un programa maduro trata el informe de revisión como la entrada de la actualización anual de la política — el documento que refinas cada año porque los hallazgos te dicen dónde las reglas tocan la realidad.

Y cuando llega la auditoría, el historial de revisiones es la historia que cuentas: tres o cuatro ciclos consecutivos, cada uno con snapshot, decisiones, hallazgos y atestación firmada, demuestran un control que opera en el tiempo — la diferencia entre “tenemos una política” y “la ejecutamos”.

Una nota sobre el scope creep en dirección contraria: la revisión verifica acceso, no lo otorga. Las solicitudes de acceso nuevo pertenecen al proceso de aprovisionamiento, no a los hallazgos de revisión — mezclar ambos convierte la revisión en cuello de botella y la tabla de hallazgos en cola de solicitudes.

Lo mismo aplica a la profundidad de la remediación: la revisión decide si el acceso debe cambiar; cómo se ejecuta el cambio (qué admin lo revoca, qué sistema de tickets lo sigue) vive en tus runbooks de IAM, no en la atestación.

Scripts de Automatización

Revisión automatizada de acceso con AWS IAM Access Analyzer

Usa AWS IAM Access Analyzer para detectar permisos no usados y generar hallazgos para revisión:

#!/bin/bash
set -euo pipefail

# Generar hallazgos de access analyzer
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

# Listar todos los usuarios IAM y su ultima actividad
echo "=== IAM Users Last Activity ==="
aws iam get-account-authorization-details --output json | \
  jq -r '.UserDetailList[] | {
    user: .UserName,
    groups: (.Groups | join(", ")),
    policies: (.AttachedManagedPolicies | map(.PolicyName) | join(", ")),
    last_used: .PasswordLastUsed
  }'

# Verificar access keys no usadas
echo ""
echo "=== Unused Access Keys (>90 days) ==="
for user in $(aws iam list-users --query 'Users[].UserName' --output text); do
  aws iam list-access-keys --user-name "$user" --output json | \
    jq -r '.AccessKeyMetadata[] | select(.Status=="Active") | "\(.UserName) \(.AccessKeyId) \(.CreateDate)"'
done

# Generar reporte de permisos no usados
echo ""
echo "=== IAM Access Analyzer Findings ==="
aws accessanalyzer list-findings --analyzer-arn "$ANALYZER_ARN" --output json | \
  jq -r '.findings[] | select(.status=="ACTIVE") | {
    resource: .resource,
    finding: .findingType,
    principal: .principal
  }'

Script de auditoría de acceso en organización de GitHub

Audita miembros de la organización de GitHub y su acceso a repositorios con la GitHub API:

#!/usr/bin/env python3
"""Auditar acceso de org de GitHub y flaggear miembros inactivos."""
import requests
import sys
from datetime import datetime, timedelta

ORG = "your-org"
TOKEN = sys.argv[1] if len(sys.argv) > 1 else ""
HEADERS = {"Authorization": f"token {TOKEN}", "Accept": "application/vnd.github+json"}

def get_org_members() -> list:
    resp = requests.get(f"https://api.github.com/orgs/{ORG}/members", headers=HEADERS)
    return resp.json()

def get_user_activity(username: str) -> dict:
    resp = requests.get(
        f"https://api.github.com/users/{username}/events",
        headers=HEADERS,
        params={"per_page": 1},
    )
    events = resp.json()
    if events:
        last_event = datetime.strptime(events[0]["created_at"], "%Y-%m-%dT%H:%M:%SZ")
        days_inactive = (datetime.utcnow() - last_event).days
        return {"username": username, "last_active": events[0]["created_at"], "days_inactive": days_inactive}
    return {"username": username, "last_active": "never", "days_inactive": 999}

def audit_members() -> None:
    members = get_org_members()
    print(f"Total org members: {len(members)}\n")
    print(f"{'Username':<25} {'Last Active':<25} {'Days Inactive':<15} {'Status'}")
    print("-" * 80)

    threshold = 90
    for member in members:
        username = member["login"]
        activity = get_user_activity(username)
        status = "REVIEW" if activity["days_inactive"] > threshold else "OK"
        print(f"{username:<25} {activity['last_active']:<25} {activity['days_inactive']:<15} {status}")

if __name__ == "__main__":
    audit_members()

Auditoría RBAC de Kubernetes con kubectl

Audita bindings RBAC de Kubernetes e identifica subjects sobre-privilegiados:

#!/bin/bash
set -euo pipefail

echo "=== ClusterRoleBindings with cluster-admin ==="
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | "\(.metadata.name) -> \(.subjects[].name // "unknown")"'

echo ""
echo "=== RoleBindings per namespace ==="
for ns in $(kubectl get namespaces -o jsonpath='{.items[*].metadata.name}'); do
  echo "--- Namespace: $ns ---"
  kubectl get rolebindings -n "$ns" -o json | \
    jq -r '.items[] | "\(.metadata.name): role=\(.roleRef.name) subjects=\([.subjects[].name] | join(", "))"'
done

echo ""
echo "=== Service accounts with secrets ==="
kubectl get serviceaccounts --all-namespaces -o json | \
  jq -r '.items[] | select(.secrets != null and (.secrets | length > 0)) | "\(.metadata.namespace)/\(.metadata.name)"'

Técnicas Avanzadas

• Para un análisis más profundo, consulta la Plantilla de Análisis de Brechas de Cumplimiento.

1. Implementa acceso just-in-time para operaciones privilegiadas. En vez de conceder acceso admin permanente, usa elevación just-in-time con aprobación y límites de tiempo. Eso encoge la superficie de ataque permanente y cada elevación deja un registro auditable:

# Teleport role: acceso admin temporal con aprobación
kind: role
metadata:
  name: jit-admin
spec:
  allow:
    node_labels: "*"
    max_session_ttl: 4h
    require_session_join: true

2. Usa dashboards de revisión de acceso para visibilidad continua. Construye un dashboard que muestre métricas de acceso en tiempo real, como número de cuentas privilegiadas, cuentas inactivas y cobertura de MFA:

-- Query: cuentas privilegiadas sin MFA
SELECT u.username, u.role, u.last_login
FROM users u
LEFT JOIN mfa_enrollments m ON u.id = m.user_id
WHERE u.role IN ('admin', 'operator') AND m.id IS NULL
ORDER BY u.last_login DESC;

Cuentas de Servicio y Errores de Automatización

1. No revisar cuentas de servicio e identidades de máquina. Las cuentas de servicio suelen acumular permisos con el tiempo y rara vez se revisan. Inclúyelas en cada ciclo de revisión de acceso y verifica su último uso:

# Verificar fecha de último uso para AWS access keys
aws iam list-access-keys --user-name deploy-bot --query 'AccessKeyMetadata[].{Key:AccessKeyId, LastUsed:CreateDate, Status:Status}' --output table

2. Confiar en spreadsheets manuales para revisiones de acceso. Los spreadsheets son propensos a errores y se desactualizan rápidamente. Usa herramientas de gobernanza de identidad o scripts que extraigan datos en vivo de tu proveedor de identidad:

# Exportar datos de acceso en vivo en vez de mantener spreadsheets
aws iam get-account-authorization-details --output json > access-snapshot-$(date +%Y%m%d).json

Lecturas Adicionales

• NIST SP 800-53 AC-6 — Least Privilege — el control que la revisión verifica
• SOC 2 CC6.3 — Acceso Lógico — la evidencia de retirada de acceso que los auditores piden
• AWS IAM Access Analyzer — los hallazgos de acceso sin uso referenciados en los scripts
• Recursos complementarios — scripts de auditoría de AWS/GitHub/Kubernetes descargables