Caso transversal · PagoSeguro
Un escenario que evolucionará contigo
PagoSeguro utiliza un rol operador con acceso a todos los comercios y permite continuar una orden cuando el servicio de autorización no responde, para evitar interrupciones operativas.
01 · Concepto
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 · Concepto
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 · Concepto
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.
Aplicación
Buenas prácticas para comenzar
- 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.
Práctica guiada
Rediseña una decisión insegura
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 comercio 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.
Exigir ownership y, para pagos críticos, maker-checker o step-up.
Denegar temporalmente acciones sensibles si la autorización no puede comprobarse.
Complementar con límites, registros inmutables y alertas de comportamiento anómalo.
Comprobación no calificada
Comprueba lo aprendido
Intenta responder antes de desplegar la explicación. No se 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.
Cuaderno local
Tus notas de la sesión
Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.
Cierre de sesión
Ahora deberías poder
- Detectar violaciones de mínimo privilegio.
- Diseñar defensa en profundidad.
- Definir comportamientos de fallo seguros y proporcionales.
Para aplicar y profundizar
Recurso y referencias
Plantilla reutilizableChecklist de diseño seguroAppSec en la actualidad