Caso: revisa permisos de un servicio Windows

NightlyReport genera un resumen diario de inventario. Revisas una propuesta para reducir permisos antes de que la acepte el responsable del servicio. Todos los nombres y registros son ficticios. Lee el expediente y redacta una decisión; no necesitas modificar ningún equipo.

Un límite de permisos es un punto donde una acción sobre un recurso concreto requiere autoridad. Administrar el servicio, leer su archivo de configuración y escribir su salida cruzan límites distintos. Que las tres actividades estén relacionadas con NightlyReport no hace intercambiables sus permisos.

P1: las funciones aprobadas

El responsable de la aplicación aprueba cuatro funciones. Soporte puede consultar el estado. Operaciones puede iniciar y detener el servicio durante una ventana acordada. Los administradores de versiones mantienen la configuración del servicio y su archivo de configuración. La identidad dedicada ReportWriter lee los registros de entrada y la configuración, y crea informes en el área de salida. No necesita modificar su configuración.

Son requisitos de esta aplicación, no valores universales de Windows. Su responsable confirma que NightlyReport no guarda ajustes en el archivo de configuración ni necesita ejecutarse con identidad de administrador. Si cambiasen esos hechos, habría que revisar la propuesta.

E1-E4: la instantánea de permisos

El equipo aporta decisiones efectivas para las identidades ordinarias indicadas. Los registros ya consideran la pertenencia a grupos y la herencia de archivos aplicables. Supón nuevas comprobaciones de acceso, sin identificadores de objeto previamente abiertos, suplantación de identidad ni privilegios especiales u otra política que alteren los resultados. No deduzcas permisos de otros objetos a partir de este expediente reducido.

El acceso de mantenimiento aprobado de los administradores de versiones se verifica por separado y debe conservarse. El expediente no aporta registros de acciones ni una revisión completa de otros servicios.

Windows denomina SERVICE_QUERY_STATUS al derecho de consultar el estado y SERVICE_CHANGE_CONFIG al de cambiar la configuración del servicio. El acceso al contenido de un archivo depende de sus controles de seguridad. El token del proceso aporta identidad y contexto de ejecución; el permiso de gestión de un operador no transfiere su identidad al servicio en ejecución.

Toma la primera decisión

Predice¿Qué dos registros muestran autoridad innecesaria y qué afirmación evitarías?

E1 supera la función de Soporte limitada a consultar el estado en P1. E3 permite que la identidad de ejecución cambie un archivo que, según P1, solo lee. Son dos desviaciones demostradas respecto a la política. Ningún registro prueba que alguien utilizara el permiso, modificara un informe o comprometiera el equipo. Describe la posibilidad de cambios no aprobados como impacto y deja pendiente su utilización real.

Observa la diferencia con E4. Crear la salida es trabajo útil exigido por P1. Retirar toda escritura a ReportWriter mezclaría un permiso innecesario sobre la configuración con otro necesario sobre la salida. Una propuesta más acotada resulta más fácil de justificar y verificar.

Propón un cambio con responsable

El responsable de la plataforma Windows debe revisar la retirada del permiso de Soporte para cambiar la configuración, conservando las consultas de estado. El responsable de la aplicación y el administrador de versiones deben revisar la retirada de escritura a ReportWriter sobre el archivo de configuración, manteniendo su lectura y generación de informes. Registra ambos cambios por separado aunque compartan ventana de mantenimiento.

Antes de aprobarlos, pregunta qué entradas de política conceden esos permisos efectivos, si un grupo compartido o una regla heredada afecta a otras aplicaciones, y si la identidad registrada coincide con la desplegada. La evidencia de acceso efectivo identifica la desviación, pero no determina por sí sola la modificación mínima. Una denegación amplia sin revisar puede impedir el mantenimiento requerido.

Define la aceptación antes de comprobarla

Las evidencias de aceptación relacionan resultados observados con requisitos acordados. Solicita una nueva instantánea de permisos y resultados de tareas ordinarias con las identidades indicadas. Soporte debe consultar el estado con éxito y recibir una denegación al solicitar cambiar la configuración del servicio. ReportWriter debe leer su configuración, recibir una denegación ante una solicitud ordinaria de escritura en ese archivo y producir el informe esperado. Operaciones y los administradores deben conservar sus tareas aprobadas.

Son resultados esperados para la validación controlada del responsable, no instrucciones para interactuar con un servicio real. Registra identidad, objeto, acción solicitada, condiciones, hora y resultado. Una captura con el estado «en ejecución» no cubre esos requisitos. Tampoco un informe generado por un administrador demuestra las capacidades de ReportWriter.

Una revisión modelo y sus límites

«P1 limita Soporte a consultar el estado y la identidad de ejecución a leer la configuración. E1 y E3 muestran permisos excesivos que permiten posibles cambios no aprobados. Los responsables de plataforma y aplicación deben aprobar correcciones acotadas y aportar evidencias de denegación y de tareas conservadas. Los hallazgos siguen abiertos hasta cubrir ambos límites. Este expediente no demuestra ninguna acción no autorizada».

Si falla un cambio controlado y se restaura la instantánea anterior, registra la recuperación del servicio separadamente de los permisos pendientes. Recuperar disponibilidad no satisface los criterios de aceptación originales. Conserva las observaciones, revisa la propuesta y asigna la siguiente revisión. La conclusión se limita a NightlyReport y las identidades indicadas; no ofrece garantías sobre todos los servicios Windows.