Mínimo privilegio, aplicado en el diff.
CC6.1 es uno de los Criterios de Servicios de Confianza que una pull request normal puede debilitar silenciosamente, porque se refiere al acceso lógico, y el acceso lógico suele residir en el código y la configuración. El criterio exige que el acceso a tus sistemas y datos se limite a los usuarios y procesos autorizados para tenerlo. En la práctica, esto significa mínimo privilegio: un rol puede acceder solo a lo que necesita para su función, y nada más.
The shapes the same control failure takes.
CC6.1 rara vez se rompe con una línea que diga 'conceder admin a todos'. Se rompe con cambios ordinarios y aparentemente razonables. Estas son las formas que se repiten.
Una política de acceso se amplía
Un rol de IAM, grupo de seguridad o concesión adquiere acciones más amplias o un comodín, por lo que un componente ahora puede hacer más de lo que su función requiere.
Se elimina una comprobación de autorización
Una ruta pierde su comprobación de rol o propiedad, o un middleware de autorización deja de aplicarse a un nuevo endpoint, por lo que una solicitud que debería rechazarse ahora tiene éxito.
Una concesión de datos se amplía
Un rol de base de datos obtiene acceso a tablas o filas que antes no tenía, se relaja la seguridad a nivel de fila o una cuenta de servicio se apunta a una base de datos a la que no tenía razón para acceder.
Un valor por defecto cambia a permitir
El acceso pasa de denegar por defecto a permitir por defecto: un nuevo recurso se envía legible por todos, o una comprobación de permisos devuelve verdadero por defecto en un caso desconocido.
Se abre una vía de escalada de privilegios
Un actor con menos privilegios obtiene una forma de actuar como uno con más: una bandera interna que omite la comprobación de rol, o un token generado con un alcance mayor al que tiene el solicitante.
Una refactorización que elimina una comprobación de autorización.
Se está ordenando una ruta. La comprobación de rol en medio parece redundante junto al middleware de autenticación, así que se elimina. El endpoint sigue requiriendo un usuario conectado, pero ya no requiere el correcto: ahora cualquier usuario autenticado puede eliminar cualquier proyecto.
- router.delete("/projects/:id", requireRole("admin"),- loadProject, deleteProject)+ router.delete("/projects/:id", loadProject, deleteProject)Esto elimina la comprobación de rol de un endpoint destructivo. El middleware de autenticación confirma que el solicitante ha iniciado sesión, pero CC6.1 se refiere a si está autorizado para esta acción, y eliminar cualquier proyecto no es algo que cualquier usuario deba poder hacer. Restaura la comprobación de autorización (una comprobación de rol o propiedad sobre el proyecto) antes del controlador.
CC6.1 se muestreo, no solo se declara.
En un examen SOC 2, CC6.1 no se cumple con un documento de política que afirme que se aplica el mínimo privilegio. El auditor muestrea el acceso real: quién y qué puede acceder a un sistema dado, si esas concesiones coinciden con los roles documentados y si algo es más amplio que su propósito. Un rol comodín, un endpoint al que le falta su comprobación de autorización o una cuenta de servicio con acceso permanente que nunca usa son exactamente el tipo de excepciones que se convierten en hallazgos, y suelen entrar en el sistema en una sola pull request meses antes. Detectar el cambio en el diff ayuda a mantener esas excepciones de acceso fuera del muestreo.
Una revisión, no una atestación.
heygrc marca los cambios que afectan a CC6.1 y cita el criterio para que la corrección se realice en la pull request. No ejecuta tu auditoría ni emite una opinión. Detecta el cambio de acceso temprano para que el examen tenga menos excepciones que explicar.