Planteamiento y contexto
Una plataforma B2B cuenta con muchos servicios de negocio, y cada uno reimplementa la lógica de “¿puede este usuario acceder a este recurso?”. Construye un servicio de políticas de autorización multi-inquilino compartido que admita roles, relaciones entre recursos y condiciones de atributos. Las actualizaciones de políticas necesitan versiones, y una falla breve del servicio central no debe generar acceso entre inquilinos.
El foco es la ruta de decisión de autorización y su límite de consistencia. No dibujes únicamente una base de datos de políticas; explica el contexto de la solicitud, la publicación de políticas, la invalidación de caché y el efecto de una denegación o un tiempo de espera agotado (timeout) en los clientes que llaman.
Qué está evaluando el entrevistador
Desean que separes un Punto de Decisión de Políticas (PDP) del Punto de Aplicación de Políticas (PEP) en el servicio de negocio, y que diseñes el aislamiento de inquilinos, la propagación de versiones y una auditoría explicable. OPA documenta la desacoplación de las decisiones de políticas de su aplicación; el artículo de Zanzibar muestra las compensaciones entre el ordenamiento causal y la baja latencia a escala de autorización global.
Preguntas para clarificar primero
Pregunta sobre el volumen de solicitudes, el objetivo de latencia, la complejidad de las políticas, la cantidad de inquilinos, la profundidad de las relaciones y los requisitos de consistencia. Clarifica quiénes son los autores de las políticas, el flujo de trabajo de aprobación, el plazo límite de revocación, la evaluación offline, los campos sensibles en los registros de decisiones y si los clientes que llaman pueden fallar de forma segura cerrando el acceso (fail closed).
Una estructura de respuesta en 30 segundos
Definiría el modelo de autorización y la invariante de “sin acceso entre inquilinos”, luego dibujaría el PEP, el PDP, el almacenamiento de políticas, la distribución y la auditoría. Las políticas están versionadas por inquilino; los PDP almacenan en caché las versiones aprobadas localmente o en la misma zona. Las solicitudes llevan sujeto, acción, recurso y el contexto requerido. Las revocaciones de alto riesgo requieren confirmación de versión; si el PDP no está disponible, las acciones sensibles se deniegan. Mide la latencia p99, el retraso de propagación, las denegaciones falsas y la integridad de la auditoría.
Análisis paso a paso
Paso 1: Definir los objetos de autorización y la entrada de políticas
Utiliza una estructura de solicitud consistente: sujeto, acción, recurso y contexto, con espacios de nombres de inquilino y recurso sin ambigüedades. RBAC gestiona las concesiones de roles, ABAC gestiona atributos como departamento, dispositivo o tiempo, y la autorización basada en relaciones gestiona casos como “este usuario es un colaborador del documento”. El lenguaje de políticas debe expresar permitir, denegar, precedencia y condiciones sin que cada servicio tenga que componer sus propias reglas.
Paso 2: Separar PEP, PDP y la gestión de políticas
El PEP permanece en una puerta de enlace de API (API gateway) o en un servicio de negocio, recopila la identidad de confianza y aplica permitir o denegar. El PDP evalúa y devuelve una decisión, la versión de la política y un motivo opcional. El plano de gestión edita, valida, aprueba, publica y revierte políticas. OPA desacopla las decisiones de la aplicación y admite despliegues locales o en red; elige según la latencia y la disponibilidad.
Paso 3: Diseñar el almacenamiento de inquilinos y la publicación versionada
Las políticas, las relaciones de recursos y los atributos llevan tenant_id, el cual se verifica en cada lectura. La publicación crea una versión inmutable y un resumen criptográfico (digest), la evalúa en un entorno aislado (sandbox) y luego la distribuye en lotes a los PDP. Registra el autor, el aprobador, la hora y el alcance. Las revocaciones o las políticas de seguridad pueden tener prioridad y requerir que las versiones antiguas expiren dentro de una ventana de tiempo delimitada.
Paso 4: Manejar la consistencia, el almacenamiento en caché y la revocación
Las claves de caché incluyen inquilino, sujeto, acción, recurso y policy_version; usar solo el ID de usuario no es seguro. Almacena en caché las autorizaciones de bajo riesgo con un TTL medido, pero usa un TTL corto o verificaciones forzadas de versión para revocaciones, cambios administrativos y recursos sensibles. Los PDP devuelven la versión utilizada; un servicio de negocio puede rechazar una versión más antigua. Los despliegues multirregionales propagan marcas de agua de versión en lugar de asumir una invalidación simultánea.
Paso 5: Diseñar modos de falla y valores predeterminados seguros
Define el comportamiento para el agotamiento de tiempo del PDP, la distribución retrasada de políticas, fuentes de atributos no disponibles y una canalización de auditoría congestionada. Las escrituras sensibles, los cambios de permisos y las exportaciones fallan de forma cerrada (fail closed); las lecturas de bajo riesgo pueden usar una caché aprobada y delimitada en el tiempo. Un cliente que llama nunca debe convertir un error de red en un permiso (allow). Limita el tamaño de las políticas, la recursión de relaciones y las QPS por inquilino para que la evaluación de políticas no se convierta en un vector de denegación de servicio.
Paso 6: Auditoría, explicabilidad y observabilidad
Registra decision_id, inquilino, resumen del sujeto, acción, resumen del recurso, resultado, versión de la política y latencia; redacta u ofusca mediante hash las entradas sensibles. El registro debe responder “a quién se le permitió qué, cuándo y bajo qué versión” sin convertirse en una nueva superficie de fuga de datos. Monitorea p50/p95/p99, aciertos de caché, propagación de versiones, tasa de denegaciones, tiempos de espera agotados y reintentos; genera alertas ante denegaciones o reversiones inusuales.
Respuesta de muestra de alta calidad
Dividiría el sistema en PEPs en los servicios de negocio, clústeres de PDP en la misma zona y un plano de gestión independiente. Las solicitudes llevan sujeto, acción, recurso y contexto de confianza. El PDP evalúa políticas de RBAC, de relaciones y de atributos aisladas por inquilino y devuelve permitir o denegar, un decisionid y policyversion. Las ediciones de políticas se validan y prueban, se convierten en versiones inmutables, se distribuyen por inquilino y región, y admiten reversión.
Las claves de caché incluyen inquilino, sujeto, acción, recurso y versión. Las lecturas ordinarias pueden usar una autorización con TTL corto, mientras que las revocaciones, cambios de permisos y exportaciones de datos requieren confirmación de versión; un cliente rechaza un resultado de PDP más antiguo que su marca de agua requerida. El tiempo de espera agotado del PDP o la falta de atributos fallan de forma cerrada para acciones sensibles.
Cada decisión registra inquilino, resumen del sujeto, acción, resumen del recurso, resultado, versión y latencia con entradas redactadas. Las métricas principales son la latencia p99, la tasa de aciertos, el retraso de propagación, las denegaciones por versión obsoleta, los errores y la integridad de la auditoría. Esto centraliza la gestión de políticas mientras mantiene la aplicación en el límite del servicio.
Errores comunes y mejoras
- Dibujar un solo “microservicio de autorización”: añade las rutas de PEP, PDP, gestión y distribución.
- Mencionar solo RBAC: explica cómo los atributos y las relaciones intervienen en una decisión.
- Almacenar en caché solo por usuario: incluye inquilino, recurso, acción y versión de la política.
- Permitir en caso de tiempo de espera agotado: las operaciones sensibles fallan de forma cerrada y el uso de la caché de bajo riesgo es explícito.
- Registrar la solicitud completa: redacta la entrada mientras se mantiene un decision_id y una versión rastreables.
Preguntas de seguimiento y respuestas
¿Con qué rapidez debe surtir efecto una revocación?
Clasifica las revocaciones por riesgo. Para acciones de administrador, exportación y datos sensibles, exige una versión de política reciente o una ventana de propagación delimitada y corta; las lecturas de menor riesgo pueden usar un TTL medido. Establece el objetivo y monitoréalo.
¿Debe el PDP ejecutarse localmente o como un servicio compartido?
Usa un PDP local o en la misma zona por motivos de latencia y aislamiento de fallas, con un plano de gestión compartido para la distribución de políticas. Un PDP de red central puede simplificar las actualizaciones pero añade una dependencia a cada solicitud; elige según la carga de trabajo y prueba el modo de falla.
¿Cómo evitas que un inquilino lea la política de otro inquilino?
Coloca la identidad del inquilino en la solicitud autenticada, aplícala en el almacenamiento y en las claves de caché, y prueba las consultas entre inquilinos como una condición de validación de lanzamiento (release gate). Nunca confíes en un identificador de inquilino suministrado únicamente por la carga útil (payload) del cliente.
¿Cómo depuras una denegación inesperada?
Devuelve un decision_id y la versión de la política, luego inspecciona las entradas redactadas, las reglas coincidentes, la frescura de los atributos y el estado de propagación. No expongas detalles internos sensibles de la política a los usuarios finales; proporciona a los operadores una vista de explicación controlada.