Estimados amigos de Inseguros !!!
En el Tema 3 de los Controles CIS llega el control 3.3, y es de los que parecen “administrativos”, pero en la práctica determinan si una empresa está razonablemente protegida o si vive en el caos: mantener una lista de control de acceso al dato (ACL). Es decir, saber y poder demostrar quién puede leer, modificar, crear o borrar datos, y además revisarlo periódicamente.
El ejemplo clásico es el File Server con Active Directory y la estructura de carpetas por departamentos. Se monta una jerarquía con contabilidad, gerencia, operarios, zonas de intercambio… y poco a poco aparecen “casos especiales”: intercambio contabilidad–pagos, niveles por rol, carpetas “ultra sensibles”, excepciones puntuales, accesos por proyectos. Y ahí es donde se suele pervertir el modelo: no el día que se crea, sino meses después, cuando se integra una aplicación, se da un permiso rápido “para que funcione”, o se heredan permisos sin control.
Para intentar sobrevivir a esa complejidad, entran los grupos y los permisos basados en pertenencia. En M365 también ocurre con Teams y recursos compartidos: se crean grupos puntuales, se mete gente interna/externa, se colabora… y el problema aparece cuando nadie revisa qué quedó abierto, quién sigue dentro y qué permisos ya no tienen sentido.
Por eso el 3.3 insiste en el mantenimiento. La lista de control de acceso al dato no es una foto fija. Hay que revisarla, porque se heredan permisos de aplicaciones, aparecen cuentas de servicio que acceden a datasets, y se crean rutas indirectas de acceso que acaban rompiendo el modelo inicial. En entornos Microsoft es habitual apoyarse en herramientas que ayuden a visualizar permisos (por ejemplo para shares) y poder “pintar” la realidad, porque un File Server con muchos niveles y herencia puede volverse inabarcable a ojo.
Aquí entra otra idea muy práctica: permisos temporales y Just-In-Time. Si se asume que habrá sobre-permisos por operativa, al menos que sean acotados en el tiempo: pertenencia temporal a grupos, acceso durante X días y luego vuelta atrás. Esto reduce muchísimo el “permiso zombie” que se queda años y acaba siendo el camino perfecto para un atacante.
El control 3.3 además no se limita a carpetas. El dato vive en todas partes: bases de datos, APIs, correo, SaaS, integraciones, RPA, automatizaciones… y ahí aparecen problemas típicos. En bases de datos muchas veces no se accede “directo”, se accede a través de un frontend, y por debajo la aplicación usa un usuario genérico con acceso amplio al dataset. En APIs pasa algo parecido: se entrega un usuario a un cliente y, si el control es débil, aparecen fallos clásicos tipo “cambiar el ID y ver datos de otros” (lo que en seguridad web se conoce como IDOR).
Cuando la organización madura, el control de acceso empieza a combinarse con sensibilidad del dato y contexto. Ya no es solo “Joaquín tiene permiso”, sino “Joaquín tiene permiso en sede, con dispositivo corporativo, y no desde un portátil fuera”. Esto conecta de forma natural con modelos de Zero Trust, con gobierno de identidad y con políticas modernas de acceso condicional.
En resumen: el CIS 3.3 obliga a tomarse en serio el acceso al dato con tres ideas: definir ACL, mantenerla, y revisarla con dueños de dato (data owners), porque la tecnología sola no entiende la casuística de negocio. Cuando esto se hace bien, bajan los accesos excesivos, se reduce el radio de impacto de una intrusión y la auditoría deja de ser una pelea.
Para profundizar en controles CIS aplicados a empresa, auditoría y gobierno del dato, en la academia hay formación orientada a profesionales que trabajan en entornos reales, no en teoría: https://www.seguridadsi.com
Gracias por leerme !!!
