Seguridad en la frontera de confianza
Identifica quién controla cada entrada y qué acciones puede hacer cada identidad.
AL TERMINAR, PODRÁS
- Distinguir autenticación de autorización
- Hacer cumplir la propiedad de los recursos en cada operación relevante
- Reconocer ejecución insegura y exposición de secretos
Descripción del diagrama: Petición → Validar; Validar → ¿Quién?; ¿Quién? → ¿Puede?; ¿Puede? → Trabajos del dueño
Pregunta quién controla la entrada
Una frontera de confianza separa datos o comportamiento controlados por partes distintas.
Un cuerpo HTTP, un archivo subido, una URL o un registro importado desde otro lugar pueden cruzar esa frontera. La validación comprueba si la entrada tiene una forma y un significado aceptables, pero no demuestra que quien llama tenga permiso para hacer la acción. Trata el tipo de trabajo como una elección entre manejadores conocidos, no como código Python arbitrario para evaluar.
Ejecutar código que envía el usuario es un producto distinto, que requiere aislamiento fuerte, controles de recursos y un modelo de amenazas propio.
Identidad no es permiso
La autenticación (authentication) establece una identidad; la autorización (authorization) decide qué acciones puede hacer esa identidad sobre qué recursos.
Un inicio de sesión válido no debe permitir que un usuario lea o cancele el trabajo de otro adivinando su ID. Incluye la comprobación de propiedad o permiso en cada operación relevante del servidor, incluidas las lecturas de estado, las cancelaciones y los reintentos. Prefiere reglas que nieguen por defecto y prueba explícitamente el acceso entre usuarios.
Ocultar un botón en la interfaz ayuda a la usabilidad, pero no da ninguna garantía de seguridad, porque un cliente puede enviar peticiones directamente.
Reduce el radio de impacto
Dale al servicio y a sus workers solo los permisos que necesitan.
Mantén los secretos fuera del control de versiones, de los logs y del código que se envía al navegador. Limita el tamaño de las peticiones, el tiempo de ejecución de los trabajos y el uso de recursos para que el trabajo mal formado o abusivo no consuma todo el sistema. Ten cuidado con los trabajos que descargan URLs proporcionadas por el usuario: pueden convertirse en un camino hacia servicios internos si no se restringen los destinos (SSRF).
Registra los eventos relevantes para la seguridad sin recolectar datos sensibles innecesarios. Un modelo de amenazas útil nombra los activos, los puntos de entrada, los abusos plausibles y los controles concretos.
ERROR FRECUENTE
Comprobar que un trabajo existe sin comprobar que quien llama puede acceder a él crea una falla de autorización a nivel de objeto.
INTÉNTALO TÚ
Modela dos usuarios y tres trabajos. Escribe una tabla de autorización para leer, cancelar y reintentar, y prueba a un usuario válido intentando acceder al trabajo de otra persona.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Crea el modelo de amenazas de Relay y aplica comprobaciones de propiedad en el servidor. Usa un registro fijo de manejadores en lugar de ejecutar código fuente enviado.