Planteamiento y contexto
Un cliente de SaaS B2B solicita acceso a aplicaciones, membresía de grupos y privilegios temporales de administrador a través de tickets o chat. TI afirma que la gestión manual es lenta y propensa a errores; seguridad se preocupa por aprobaciones excesivamente amplias, aprobadores ausentes y accesos que nunca expiran. Decide si construir un flujo de trabajo, qué solicitudes atender primero y cuáles deberían ser la v1 y las condiciones de lanzamiento (launch gates).
Esto evalúa las compensaciones (trade-offs) del producto, no un diagrama de estados de solicitudes. Separa el autoservicio de bajo riesgo, la aprobación del propietario del recurso y los privilegios de alto riesgo que requieren revisión de seguridad.
Qué evalúa el entrevistador
Una respuesta sólida comienza con las tareas de los usuarios (user jobs) y los niveles de riesgo, asigna responsabilidades a solicitantes, aprobadores, propietarios de recursos y sistemas de aplicación, y luego mide si tiempos de espera más cortos generan más incidentes de seguridad. Las entrevistas de producto evalúan el criterio del cliente, el diseño de producto acotado, las métricas y la ejecución multifuncional; Interview Pilot lista esto como señales centrales de un PM.
La documentación de Access Requests de Okta muestra límites reales respecto a condiciones, tipos de solicitudes, secuencias de aprobación, tareas, temporizadores y canales. El flujo de trabajo de consentimiento de administrador de Microsoft Entra separa solicitar, revisar, aprobar, denegar, bloquear y notificar.
Preguntas para aclarar primero
Pregunta qué se está solicitando y qué tan riesgoso es: una aplicación común, datos sensibles, un grupo, un rol de administrador o una elevación con límite de tiempo; quién tiene la aprobación final; si el gerente y el propietario del recurso deben aprobar; si el acceso tiene fecha de finalización; cómo se reemplaza a un aprobador ausente; si el cliente ya cuenta con gobernanza de identidades; y si los registros de solicitudes deben transferirse a un sistema de auditoría.
Estas respuestas cambian la v1. Una aplicación de bajo riesgo puede usar una sola aprobación; un rol de alto riesgo necesita dos personas o al propietario del recurso. Si ya existe una plataforma de gobernanza, prioriza la integración y la escritura de estados (status write-back) en lugar de reconstruir su catálogo.
Marco de respuesta de 30 segundos
Validaría un punto de dolor frecuente y medible, comenzando con solicitudes de autoservicio para aplicaciones de bajo riesgo y acceso temporal con un fin de negocio claro. La V1 incluye un catálogo de recursos, motivo, etiqueta de riesgo, aprobador, notificaciones, revocación por expiración y registro de auditoría; los roles de administrador conservan la doble aprobación humana. Mide el tiempo de finalización, la antigüedad de la cola, la tasa de denegación, la revocación exitosa por expiración y las concesiones no autorizadas, para luego pilotear con 5–10 empresas.
Análisis paso a paso
Paso 1: Segmentar recursos y riesgo
Comienza con aplicaciones comunes, grupos de negocio, conjuntos de datos sensibles y roles de administrador. Define el aprobador predeterminado, si se requiere un motivo, si se permite el acceso temporal y qué impacto en el negocio debe registrarse. No pongas todas las solicitudes en el mismo camino: el acceso de bajo riesgo optimiza la velocidad; el de alto riesgo optimiza la justificación y la revocación.
Paso 2: Definir roles y límites de aplicación
El solicitante declara el propósito y la duración; un gerente confirma la necesidad de negocio; el propietario del recurso evalúa el riesgo del recurso; seguridad define la política de alto riesgo; un sistema de aplicación otorga o revoca el permiso. Microsoft distingue entre revisores designados, solicitudes visibles y acciones que requieren permisos de RBAC, demostrando que la visibilidad no equivale a autoridad de aprobación.
Paso 3: Diseñar la experiencia de solicitud
La tarjeta del catálogo debe mostrar el propietario, la sensibilidad, la duración esperada y las alternativas. Solicita únicamente campos que modifiquen la decisión, como el propósito, el proyecto, la fecha de finalización y el uso de datos de clientes. Tras el envío, muestra el estado, el siguiente aprobador, la evidencia faltante y el tiempo estimado de atención para que los usuarios no vuelvan a abrir tickets.
Paso 4: Diseñar la aprobación, reasignación y expiración
Modela aprobar, denegar, bloquear, solicitar información, reasignar y expirar como resultados diferentes. Okta modela las secuencias de aprobación como preguntas, tareas, aprobaciones y pasos de flujo de trabajo, y admite delegación y escalamiento. La V1 debe gestionar la salida de un aprobador, solicitudes duplicadas, tiempos de espera agotados (timeouts) y cambios de propietario. El acceso temporal necesita una acción real de revocación, no solo una fecha en la interfaz de usuario.
Paso 5: Asegurar, auditar e integrar
Registra solicitante, recurso, motivo, aprobador, versión de la política, alcance otorgado y resultado de la revocación. Explica las diferentes consecuencias de denegar y bloquear. Envía eventos sensibles al SIEM o plataforma de gobernanza del cliente. Si el SaaS no puede revocar de forma confiable un permiso en los sistemas posteriores (downstream), puede proporcionar un registro de solicitud y aprobación, pero no debe afirmar que el control de acceso está garantizado.
Paso 6: Validar el valor con criterios de Pase/No Pase (Go/No-Go)
Selecciona entre 5 y 10 clientes con un directorio de identidades, volumen constante de solicitudes y disposición a probar. El pase (Go) requiere un comportamiento consistente de otorgamiento y revocación, pruebas de escalamiento superadas, tareas de expiración reintentables, registros de auditoría completos y una latencia de cola justificable. El no pase (No-Go) incluye un propietario desconocido, acceso temporal irrecuperable, una aprobación crítica no asignada o usuarios que eluden el flujo de trabajo mediante canales manuales.
Ejemplo de respuesta sólida
Plantearía esto como una forma de acortar el tiempo de espera de solicitudes de acceso empresarial preservando los niveles de riesgo y la revocabilidad, no como la construcción de un motor de aprobaciones genérico. Comenzaría con clientes que ya cuentan con un directorio de identidades, un alto volumen de solicitudes de aplicaciones de bajo riesgo y fechas claras de finalización para el acceso temporal. Los roles de administrador seguirán requiriendo doble aprobación del propietario del recurso y de seguridad.
La V1 ofrece un catálogo de recursos, etiquetas de propietario y de riesgo, motivo y fecha de finalización, notificaciones, reasignación, revocación por expiración y registros de auditoría. Los solicitantes introducen solo información relevante para la decisión; los aprobadores ven propósito, alcance, acceso existente y versión de la política. Aprobar, denegar, bloquear, solicitar información y expirar son resultados separados en lugar de un único estado "pendiente".
Mide el tiempo de finalización, la acumulación en cola (backlog), la tasa de denegación, el éxito de la revocación por expiración, las omisiones manuales y las concesiones no autorizadas. Realiza un piloto con 5–10 clientes. Si el acceso downstream no se puede revocar de manera confiable o los registros de aprobación y auditoría divergen, pausa la expansión y construye una integración o un registro de solicitud trazable antes de prometer una aplicación efectiva.
Errores comunes y mejoras
- Un solo camino de aprobación para cada permiso → Por qué falla: las solicitudes de bajo riesgo heredan demoras de alto riesgo → Solución: categorizar por recurso y riesgo.
- Construir únicamente un formulario → Por qué falla: no hay propietario, expiración ni resultado de aplicación → Solución: definir la responsabilidad de aprobación, el otorgamiento downstream y los resultados de revocación.
- Tratar la denegación y el bloqueo como lo mismo → Por qué falla: los usuarios no saben si pueden volver a solicitar → Solución: separar resultados, motivos y notificaciones.
- Optimizar solo el tiempo promedio de atención → Por qué falla: la velocidad puede incrementar accesos obsoletos o excesivos → Solución: añadir métricas de revocación, concesiones no autorizadas y omisiones.
- Ignorar a los aprobadores ausentes → Por qué falla: las colas se estancan y los usuarios eluden el proceso → Solución: admitir reasignación, delegación, escalamiento y reintentos por timeout.
Preguntas de seguimiento y respuestas
¿Debería cada solicitud requerir la aprobación de un gerente?
No. Utiliza el riesgo y la propiedad del recurso. Las aplicaciones de bajo riesgo pueden recurrir a la aprobación del propietario del recurso o basada en políticas; los datos sensibles y los roles de administrador necesitan una revisión más estricta. Un gerente puede confirmar la necesidad de negocio, pero no debe ser el único responsable de la decisión de seguridad.
¿Qué pasa si el sistema downstream no puede revocar el acceso temporal?
No prometas acceso con límite de tiempo. Limita la v1 a un registro de solicitud y aprobación, o intégrate con un sistema que pueda aplicar la revocación. Una fecha de expiración visible sin una acción real de cumplimiento genera una falsa sensación de seguridad.
¿En qué se diferencia una denegación de un bloqueo?
Denegar rechaza la solicitud actual y explica el motivo; bloquear también impide solicitudes futuras para ese recurso hasta que la política cambie. La interfaz, las notificaciones y el registro de auditoría deben reflejar esa diferencia.
¿Qué métrica importa más en el lanzamiento?
Combina el tiempo de acceso con métricas de seguridad: revocación exitosa por expiración, concesiones no autorizadas, antigüedad de elementos en cola, solicitudes repetidas y omisiones manuales. Optimiza solo después de confirmar que el camino más rápido sigue cumpliendo con los requisitos de control del cliente.