Permissions Comparison

Qué es y por qué existe

En IBM Engineering Lifecycle Management, lo que un usuario puede hacer en un proyecto depende de los roles del área de proyecto y de los permisos de cada rol: quién puede crear o eliminar artefactos, modificar un módulo, aprobar una revisión, crear una línea base o entregar un conjunto de cambios. Las áreas de equipo, las líneas de tiempo y las iteraciones pueden volver a cambiar esos permisos en su parte del proyecto.

Las organizaciones suelen empezar todos los proyectos con la misma plantilla de proceso, y después los proyectos se van separando. Un proyecto permite a los autores eliminar artefactos, otro da a un área de equipo sus propios permisos, un tercero tiene un rol que los demás no tienen. El cliente web muestra los permisos de un área de proyecto cada vez, así que encontrar estas diferencias obliga a abrir las mismas pantallas una junto a otra, rol por rol. Permissions Comparison los lee por usted y lista solo lo que difiere.

Problemas que resuelve

• Áreas de proyecto creadas con la misma plantilla cuyos permisos ya no coinciden, sin que nadie sepa dónde.
• Revisiones de accesos que obligan a comprobar a mano cada rol en cada área de proyecto.
• Áreas de equipo o iteraciones que dan a un rol más o menos permisos que el área de proyecto sin que nadie lo note.
• Ninguna prueba para mostrar a un auditor que los roles y permisos documentados son los que están configurados en el servidor.

Por qué importa para normas y auditorías

Las normas de desarrollo regulado o relacionado con la seguridad rara vez nombran una herramienta, pero esperan que solo las personas autorizadas puedan cambiar los registros controlados y que usted pueda mostrar quién puede hacer qué. En un área de proyecto de ELM, ese control son los permisos de los roles. Permissions Comparison sirve para comprobar que es igual en todos los proyectos y que coincide con su proceso documentado.

• FDA 21 CFR Part 11 (registros electrónicos en dispositivos médicos y en la industria farmacéutica): § 11.10(d) pide «limiting system access to authorized individuals» (limitar el acceso al sistema a las personas autorizadas), y § 11.10(g) pide comprobaciones de autoridad, para que solo las personas autorizadas puedan modificar un registro o realizar la operación de que se trate. La comparación muestra, por área de proyecto, qué rol puede realizar qué operación.
• ISO/IEC 27001:2022: los controles del Anexo A 5.15 Access control, 5.18 Access rights, 5.3 Segregation of duties y 8.2 Privileged access rights. Los derechos de acceso deben revisarse con regularidad y las funciones incompatibles deben mantenerse separadas, por ejemplo el rol que redacta un requisito y el rol que lo aprueba. El informe en Excel deja constancia de qué se revisó y cuándo.
• ISO 26262, Automotive SPICE, DO-178C e IEC 62304: las cuatro exigen gestión de la configuración y gestión de cambios de los productos de trabajo, como los requisitos (ISO 26262 Part 8, SUP.8 y SUP.10 en Automotive SPICE, la sección 7 de DO-178C, la cláusula 8 de IEC 62304). En DOORS Next, parte de ese control es qué roles pueden modificar artefactos, crear líneas base y entregar cambios. Un proyecto cuyos roles permiten más de lo que describe el proceso es un hallazgo de auditoría habitual.

Un evaluador revisa una muestra de proyectos y espera el mismo proceso en todos. Compare cada área de proyecto con su proyecto de referencia antes de la evaluación y verá las diferencias antes que él.

Ventajas

• Todas las diferencias en una lista: roles, su orden y cardinalidad, y cada permiso que está permitido en un lado y no en el otro, para el área de proyecto, las áreas de equipo y, si lo desea, las líneas de tiempo y las iteraciones.
• Un origen, muchos destinos: compare un área de proyecto de referencia con hasta 25 más de la misma aplicación.
• Funciona en todas las aplicaciones de ELM: DOORS Next, Workflow Management (EWM), Test Management (ETM) y Global Configuration, desde un ELM Mini Dashboard.
• Informe en Excel con la matriz completa de permisos, listo para una revisión de accesos o un expediente de auditoría.
• Solo lectura: el widget lee y nunca cambia un permiso.

Cómo se usa

1. En Settings, elija si se comparan las áreas de equipo (activado al principio) y las líneas de tiempo e iteraciones (desactivado al principio).
2. En Compare, elija la Application. From es el origen: en un dashboard de DOORS Next empieza con el proyecto abierto, y Change elige otra área de proyecto.
3. En To, haga clic en Add, marque hasta 25 áreas de proyecto (la búsqueda, Select all y Show archived ayudan) y haga clic en Apply.
4. Haga clic en Compare. El bloque de resultado muestra el número de diferencias, por categoría o por destino, y los destinos que no se pudieron leer, con Retry.
5. En Differences, elija un destino si hay varios y después Roles o Permissions. Los permisos se agrupan por rol y nivel, como Author / Team area: Business Recovery. Haga clic en una fila para ver los dos lados.
6. Haga clic en Export to Excel en el bloque de resultado para guardar la comparación completa.

Conviene saber

• Los roles se emparejan por id y después por nombre, así que un rol con el mismo nombre y otro id cuenta como el mismo rol. Se compara el orden de los roles porque un usuario con varios roles recibe el permiso del primer rol que lo permite.
• El widget compara los roles y sus permisos, no quién los tiene. User Audit lista qué usuarios tienen qué roles.
• Un área de equipo, línea de tiempo o iteración en la que solo un lado da a un rol sus propios permisos se indica en una sola fila, no en una larga lista de diferencias de permisos.
• Momentos habituales para usarlo: antes de una auditoría o evaluación, después de cambiar la plantilla de proceso y cuando se crea un proyecto nuevo a partir de una plantilla.
• El widget no hace que un proyecto cumpla la normativa. Le da los datos para comprobar que los permisos coinciden con su proceso documentado, y un informe que puede guardar como prueba.