1. Problema y contexto
Un servicio acepta una solicitud para leer o escribir un recurso. El servicio en sí tiene permisos amplios, mientras que el llamador solo debería recibir una autoridad restringida. Si el servicio utiliza una ruta o un ID de recurso controlado por el llamador y luego actúa con sus propios privilegios, un atacante puede hacer que realice una acción que el llamador no podría realizar directamente. AWS llama a esto un problema de diputado confundido (confused deputy problem).
La seguridad basada en capacidades aborda esto haciendo que la autoridad sea explícita en una referencia o token que tanto identifica el recurso como porta el derecho a usarlo. La capacidad debe ser inalterable (unforgeable), con alcance delimitado (scoped) y transferida únicamente al código que la necesita. La pregunta es una discusión general sobre modelos de seguridad; no se limita a un único proveedor de nube o lenguaje de programación.
2. Qué evalúa el entrevistador
- Razonamiento sobre autoridad: ¿Puede distinguir entre autenticación, autorización y posesión de una autoridad delegada?
- Modelado de amenazas: ¿Puede mostrar al diputado, la entrada confundida, la acción privilegiada y el límite controlado por el atacante?
- Privilegio mínimo: ¿Atenúa una capacidad a una sola operación, objeto, inquilino (tenant) o ventana de tiempo?
- Criterio sobre el ciclo de vida: ¿Puede explicar la revocación, la expiración, la auditabilidad y la filtración sin afirmar que las capacidades lo resuelven todo?
- Claridad en los compromisos (trade-offs): ¿Puede comparar las capacidades con la identidad ambiental y las verificaciones de políticas bajo restricciones operativas realistas?
Una respuesta débil dice “usa un token”. Una respuesta sólida explica qué autoriza el token, cómo está restringido y qué sucede cuando se filtra o debe ser revocado.
3. Preguntas para aclarar primero
¿El diputado es código local, un servicio o un rol de nube?
El patrón es el mismo, pero el límite cambia. Una biblioteca puede heredar accidentalmente un descriptor de archivo; un servicio puede usar su identidad de carga de trabajo (workload identity); un rol de nube puede ser engañado para actuar sobre un recurso de otra cuenta. Nombre al principal que posee la autoridad amplia.
¿Qué recurso y operación se están delegando?
Aclare si la autoridad es de lectura, escritura, adición, eliminación, invocación o una operación compuesta. Una capacidad para un solo objeto y un solo método es más fácil de auditar y revocar que un nombre de recurso con comodines.
¿Cuáles son los requisitos de revocación y filtración?
Pregunte si se requiere revocación inmediata, uso fuera de línea, aislamiento multiinquilino (multi-tenant) o auditoría sin repudio. Estas restricciones determinan si se debe usar una referencia en memoria, un token firmado, un arrendamiento (lease), un intermediario (broker) o una verificación de políticas centralizada.
4. Estructura de respuesta de 30 segundos
“Un diputado confundido aparece cuando un llamador con menos privilegios proporciona un nombre de recurso a un servicio con más privilegios, y el servicio utiliza su propia autoridad sin vincular la solicitud al alcance previsto por el llamador. La seguridad por capacidades hace explícita la autoridad: pase una referencia o token inalterable que nombre un recurso y una operación permitida, y exija que el diputado use únicamente esa referencia. Yo atenuaría las capacidades al delegarlas, las vincularía a un inquilino y a una audiencia, las haría expirar o revocaría según el riesgo, y registraría su emisión y uso. Las capacidades reducen la autoridad ambiental y el riesgo de diputado confundido, pero la filtración, la repetición (replay), la recuperación y la auditoría siguen siendo problemas de diseño.”
5. Explicación paso a paso
Paso 1: Separar la identidad de la autoridad
La autenticación responde quién está llamando. La autorización responde qué puede hacer esa identidad según una política. Una capacidad es una referencia concreta que porta autoridad: la posesión más la integridad inalterable de la referencia otorga una acción específica. El modelo puede coexistir con la identidad, pero no depende de una verificación global de identidad ambiental en cada llamada interna.
Paso 2: Dibujar el flujo del diputado confundido
Supongamos que un servicio de informes puede leer cualquier archivo bajo su identidad de carga de trabajo. Un usuario envía file=/reports/other-tenant.csv. Si el servicio valida únicamente que la solicitud está autenticada, se convierte en un diputado: el usuario proporciona un nombre y el servicio gasta su privilegio más amplio. La vinculación faltante es “a este llamador se le otorgó explícitamente autoridad sobre este objeto”.
Paso 3: Reemplazar nombres por autoridad delimitada
En su lugar, un propietario autorizado crea una capacidad para un informe y una operación específicos, como acceso de solo lectura para el inquilino A hasta una fecha límite. El llamador pasa esa capacidad al servicio. El servicio desreferencia la capacidad o la presenta a un intermediario; no transforma una ruta arbitraria en autoridad. La investigación en capacidades de objetos describe este patrón como la codificación de derechos de acceso en objetos individuales y la restricción de sus interacciones.
Paso 4: Atenuar al delegar
Cuando un componente delega, debe producir una capacidad más débil: menos métodos, un solo objeto secundario, un tiempo de vida más corto, una restricción de inquilino o un límite de tasa (rate limit). Nunca amplíe una capacidad porque un componente posterior resulte conveniente. Un contenedor que solo expone readMetadata() es más seguro que pasar un descriptor del sistema de archivos con derechos de escritura y eliminación.
Paso 5: Manejar tokens y repetición (replay)
Si la capacidad cruza el límite de un proceso, utilice una referencia protegida, como un token firmado y delimitado por audiencia, o un identificador emitido por un intermediario. Incluya recurso, acción, inquilino, emisor, audiencia, expiración y un ID único donde la repetición sea un factor crítico. Verifique la integridad y el contexto antes de su uso. El cifrado puede ocultar el contenido, pero por sí solo no impone el alcance ni detiene la repetición.
Paso 6: Planificar la revocación y la recuperación
Las capacidades puras en memoria son fáciles de pasar pero difíciles de revocar globalmente. Los arrendamientos, las expiraciones cortas, la indirección a través de un almacén de revocación o la rotación de claves equilibran el control inmediato frente a la disponibilidad y la latencia. Si se filtra un token, revoque el identificador o la vinculación, rote la clave relevante si es necesario e inspeccione los registros de uso; simplemente eliminar el registro de un usuario puede no invalidar una capacidad ya emitida.
Paso 7: Preservar los límites de auditoría y políticas
Registre quién emitió una capacidad, qué alcance tenía, qué diputado la utilizó y el resultado. Mantenga el contexto de identidad para la rendición de cuentas, incluso cuando la capacidad sea la primitiva de autorización. Para acciones de alto riesgo, combine las verificaciones de capacidades con verificaciones de políticas, como el estado del inquilino, la retención legal o la autenticación reforzada (step-up authentication).
6. Respuesta de muestra de alta calidad
“El diputado confundido es un desajuste de privilegios. Un llamador proporciona un nombre de recurso, pero un servicio con derechos más amplios realiza la operación. El servicio se confunde porque el nombre se trata como autoridad. AWS documenta este patrón para el acceso entre cuentas y entre servicios.
Yo pasaría una capacidad explícita en su lugar: una referencia inalterable o un token protegido delimitado a un solo inquilino, objeto, operación, audiencia y expiración. El diputado solo puede usar esa capacidad, y la delegación crea un elemento secundario atenuado. Para un token remoto, verificaría la integridad, el contexto y las restricciones de repetición, y luego registraría la emisión y el uso.
La revocación es el compromiso. Podría usar arrendamientos de corta duración o un identificador revocable para acciones sensibles, aceptando el costo de una búsqueda. Las capacidades reducen la autoridad ambiental y hacen que el flujo de datos sea más fácil de inspeccionar, pero no eliminan los requisitos de filtración, recuperación, auditoría o políticas. Probaría intentos entre inquilinos, repetición de tokens, nombres confusos y condiciones de carrera en la revocación.”
7. Errores comunes
- “La autenticación es suficiente” → Permite que la identidad amplia de un servicio decida el alcance → Vincule la operación a una autoridad explícita y restringida.
- “Un token firmado es automáticamente una capacidad” → Ignora la audiencia, la operación, la expiración y la repetición → Trate la integridad como una propiedad e imponga el alcance por separado.
- “Usar la ruta del llamador tras verificar el inicio de sesión” → Recrea el flujo del diputado confundido → Pase una capacidad o un identificador de intermediario en lugar de un nombre arbitrario.
- “Las capacidades eliminan las políticas de autorización” → Pasa por alto el estado del inquilino y las reglas contextuales → Combine las verificaciones de capacidad con verificaciones de políticas de alto riesgo.
- “La revocación es gratuita” → Ignora las copias distribuidas y el uso fuera de línea → Elija arrendamientos, indirección o expiración según el requisito de revocación.
- “Ocultar todo el contexto de identidad” → Hace imposible la investigación de incidentes → Preserve el emisor, el sujeto, el alcance y los eventos de uso para la auditoría.
8. Preguntas de seguimiento
¿En qué se diferencia una capacidad de una búsqueda en una ACL?
Una búsqueda en una ACL comienza con una identidad y un nombre de recurso, y luego consulta la política en el momento del uso. Una capacidad transporta una referencia de autoridad delegada a través del flujo de datos. Las ACL centralizan la política y la revocación; las capacidades hacen que la autoridad sea explícita y pueden reducir la autoridad ambiental, pero necesitan controles de ciclo de vida y de filtración.
¿Se puede copiar una capacidad?
Una referencia dentro del proceso a menudo puede ser copiada por código que ya la posee. El límite de seguridad radica en quién puede recibirla y si está atenuada. Un token remoto se puede repetir a menos que esté vinculado a un canal, un nonce, una audiencia o un arrendamiento corto. La posibilidad de copia es un riesgo que se debe modelar, no una razón para asumir que el token es inofensivo.
¿Cómo aseguraría una URL basada en capacidad?
Trátela como una credencial de portador (bearer credential): use HTTPS, alcance restringido, expiración corta, entropía no predecible, vinculación de audiencia, límites de tasa y redacción en registros y encabezados Referer. Para acciones sensibles o reutilizables, prefiera un intercambio de un solo uso por un identificador revocable.
¿Dónde sigue apareciendo el diputado confundido en los sistemas en la nube?
Aparece cuando un rol de servicio, un ejecutor de compilación (build runner) o un proxy de almacenamiento acepta un identificador de recurso controlado por el usuario y utiliza su propio rol amplio. Vincule la solicitud a una política de recursos, al inquilino y a la acción prevista; la guía de acceso entre cuentas de AWS es un ejemplo concreto de este límite.