01
Mínimo privilegio y denegación predeterminada
Usuarios, servicios, agentes y pipelines deben ejecutar únicamente las acciones necesarias sobre recursos determinados. Los permisos amplios facilitan la operación inicial, pero aumentan el radio de impacto de errores y credenciales comprometidas.
Denegar por defecto obliga a autorizar explícitamente. Este criterio resulta especialmente importante en APIs, operaciones administrativas y sistemas multi-tenant.
02
Defensa en profundidad
La protección combina controles en identidad, red, aplicación, datos, infraestructura y monitoreo. Un WAF no corrige una autorización defectuosa y una red privada no convierte una cuenta compartida en una identidad segura.
Las capas deben ser independientes en lo posible, para que el fallo de una no elimine todas las barreras restantes.
03
Simplicidad, trazabilidad y fallo seguro
Los controles complejos y excepciones implícitas son difíciles de revisar. Las decisiones sensibles deben ser simples, centralizadas y auditables.
Si un servicio de autorización, secreto o dependencia crítica no está disponible, el comportamiento debe definirse deliberadamente. En operaciones sensibles, continuar sin verificar suele ser más peligroso que detenerse.
Criterios para aplicarlo
- Usar denegación predeterminada en autorización.
- Separar identidades humanas y técnicas.
- Evitar bypass basados únicamente en red o correo.
- Diseñar y probar escenarios de fallo de dependencias críticas.
04 · Práctica guiada · opcional
Practica lo aprendido
Evalúa el rol global y el comportamiento ante la caída del servicio de autorización. Identifica los principios vulnerados y diseña una alternativa.
- 01Separa las acciones de consulta, creación, aprobación y anulación.
- 02Limita cada acción por grupo y propiedad del recurso.
- 03Define el comportamiento fail-safe para operaciones sensibles.
- 04Agrega controles independientes y trazabilidad.
Ver solución orientativa
Sustituir el rol global por capacidades específicas y alcance tenant.
Validar pertenencia de cada reserva y exigir otra persona aprobadora para reservas de más de 20 asistentes en este ejercicio.
Denegar temporalmente acciones sensibles si la autorización no puede comprobarse.
Complementar con límites, registros inmutables y alertas de comportamiento anómalo.
05
Comprueba lo aprendido
Responde antes de abrir la explicación. Esta comprobación es opcional y no guarda una puntuación.
01¿Una red privada permite omitir autorización en la aplicación?
No. La red es una capa adicional, no una prueba suficiente de identidad, intención ni permiso sobre el recurso.
02¿Fail-closed significa detener siempre toda la aplicación?
No. El comportamiento puede ser proporcional: bloquear operaciones sensibles y mantener funciones de bajo riesgo claramente definidas.
03¿Por qué separar identidades humanas y técnicas?
Porque tienen ciclos, permisos, mecanismos de autenticación y necesidades de auditoría diferentes.
Cómo demostrar el objetivo
Compara tu práctica con estos resultados. Si solo diseñaste una prueba, registra su resultado como esperado, no como observado.
- La propuesta limita capacidades por acción, grupo y recurso.
- Explicas qué operaciones sensibles se rechazan ante autorización indisponible y cuáles pueden continuar justificadamente.
Qué debes recordar
- Cada identidad debe recibir solo los permisos necesarios.
- Ningún control aislado debe sostener toda la defensa.
- Ante un error de seguridad, el sistema debe fallar de forma segura.
Tu cuaderno · notas personales
Cuaderno local
Tus notas del contenido
Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.
Material de apoyo · descarga, glosario y referencias
Consulta las condiciones de reutilización de los recursos descargables. Procedencia y condiciones de uso.