Gobierno que blinda
su operación SAP

01Introducción

RoleShield es la capa de gobierno de accesos para SAP de HardSoft. Se conecta al sistema del cliente en modo solo lectura y responde una pregunta de negocio: qué usuarios acumulan funciones incompatibles — crear un pedido y aprobarlo, dar de alta un proveedor y pagarle, mantener un maestro y contabilizar contra él. Son las combinaciones que permiten que una sola persona cierre un circuito completo sin intervención de terceros.

De cada caso informa tres cosas: quién lo tiene, por qué asignación se originó y qué corrección lo resuelve con el menor impacto operativo — porque casi siempre hay más de una forma de remediarlo y no todas cuestan lo mismo. Nada de lo que muestra es una estimación: todo sale de tablas que su equipo puede volver a consultar en SAP.

Las tres promesas

02Conceptos SAP

Para leer RoleShield no hace falta ser consultor Basis, pero sí manejar seis palabras. Estas son, en el orden en que un auditor las recorre:

La cadena de autorización

Todo acceso en SAP se explica recorriendo esta cadena, del usuario hacia abajo. RoleShield la recorre igual, y cuelga de cada eslabón el verbo que corrige en ese nivel:

El Dashboard agrupa los hallazgos por estas tres capas en «Origen del riesgo».

Las tablas que se leen

03El portal

El portal se organiza por preguntas, no por módulos. La rejilla de la esquina superior izquierda cambia de grupo; los menús de la cinta cambian de pantalla dentro del grupo:

La cinta superior sella siempre tres datos: el cliente auditado, los datos vigentes (la fecha de la última extracción — antes de discutir un número, mire esa fecha) y el ? de la esquina, que abre la ayuda de la pantalla donde usted esté. La barra inferior declara la conexión y el mandante; si los datos son sintéticos, una marca de DEMOSTRACIÓN lo dice en el sitio más visible.

Atajos de teclado

04Uso por pantalla

Empezar aquí

La única pantalla que no depende de la auditoría: se lee antes de la primera corrida y sigue valiendo después. Ocho pestañas cuentan la historia completa una vez — qué hace, qué analiza, cómo mide el riesgo, y con la misma honestidad, qué no hace.

Dashboard

La pantalla que se abre a diario. Postura de control resume lo que exige decisión hoy (conflictos en personas activas) y lo que duerme contenido. Los tres anillos parten el universo completo — roles, hallazgos y cuentas — en rebanadas que siempre suman el total, para que cada cifra cuadre con «Fuentes de datos». Origen del riesgo agrupa los conflictos por la capa donde se corrigen, con el verbo de cada una.

El semáforo LED manda en todo el portal: rojo exige decisión, ámbar pide revisión, verde está bajo control, gris aún no aplica. El resto del panel usa la escala de azules — oscuro es más severo — y reserva el naranja para la acción.

Situación · Evolución del riesgo

La tendencia entre auditorías: barras grises (conflictos totales) y naranjas (de riesgo alto), y bajo cada tramo, su gestión — qué se decidió entre una auditoría y la siguiente. Si la curva bajó sin decisiones registradas, la pantalla lo dice en naranja: eso no es una mejora demostrada, es un cambio en los datos.

Qué encontramos · Segregación de funciones

Una fila por combinación incompatible — no por persona—: a cuánta gente alcanza cada regla, qué roles la producen y el patrón, que nombra qué hacer: diseño de rol (partirlo), sistémico (política o alta masiva), caso aislado (quitar un rol). Debajo, el corte que ordena el trabajo: Amenaza latente — cuentas dormidas cuyo conflicto sigue vivo; bloquear la cuenta cierra todos sus conflictos de un golpe sin tocar a nadie que trabaje — y Deuda de diseño, los roles que sobreviven al bloqueo porque el conflicto nace dentro.

Al abrir una combinación y pulsar una persona, la ficha de evidencia muestra las dos funciones enfrentadas y las transacciones exactas que producen el conflicto (en naranja). El fin no es quitarle a la persona sus funciones: es separar esas dos.

Las otras tres pantallas del grupo siguen la misma carcasa: Accesos críticos (super-usuarios, cuentas genéricas, inactivos con acceso, roles sin uso — con el corte «exigen decisión / deuda de limpieza»), Autorizaciones críticas (EWA) (las comprobaciones del anexo EWA de SAP, medidas por autorización y no por nombre) y Cuentas dormidas (más de 90 días sin entrar, ordenadas por consecuencia, con exportación a Excel y envío directo a revisión).

Qué hacer · Plan de remediación

El ranking por impacto: cada acción dice cuánto elimina y a cuántas personas alcanza. Desde aquí se seleccionan acciones y se envían a aprobación; el sistema las dirige al aprobador que declara la matriz — no lo elige quien solicita. Simulación permite probar un cambio contra el SAP vivo antes de decidir; Roles y Usuarios son las bibliotecas de consulta con el detalle por rol y por persona.

Qué decidimos

Decisiones reúne en un solo registro las correcciones aprobadas y los riesgos aceptados — el documento que se entrega cuando auditoría pregunta qué se hizo con cada hallazgo. Cada alta y cambio queda firmado en la bitácora.

Política SoD es el rulebook: las combinaciones incompatibles y su gravedad. Las reglas HardSoft llevan candado. Deshabilitar una (hasta 12 meses), agregar o quitar una regla propia y restaurar la base se solicitan y rigen cuando lo firman dos personas con su segundo factor: IT, y Seguridad o Auditoría. Los cambios rigen desde la próxima auditoría y nunca modifican SAP.

Aprobaciones muestra la matriz (quién firma qué) y los lotes en curso. Recertificación arma revisiones por departamento, módulo o prefijo: cada responsable certifica, persona por persona, quién conserva su acceso; al cerrar se emite un certificado.

Cada «?» del portal explica su pantalla o su campo. Las ayudas de formularios recorren campo a campo qué se espera escribir:

Datos y entregables

Fuentes de datos muestra la extracción vigente (fecha, mandante, volúmenes) y el histórico de auditorías; «Actualizar desde SAP» (F8) genera una nueva. Entregables produce al momento el reporte de auditoría en Excel, el plan de remediación y el informe PDF. Base de archivo guarda cada auditoría anonimizada y encadenada por hash, y permite re-evaluar el pasado con las reglas de hoy: si se agrega una regla, responde desde cuándo existía el problema.

05El ciclo de remediación

Es la columna vertebral del producto, y su regla de oro: el estado terminal lo pone el motor, no una persona.

1. El plan propone. Cada acción dice cuánto elimina y qué hay que hacer.
2. El lote viaja al aprobador que dicta la matriz, partido por área: cada gerente firma solo lo que controla. Sin matriz declarada, el envío queda bloqueado — es un requisito, no un descuido.
3. El equipo SAP del cliente ejecuta la corrección en PFCG/SU01. RoleShield nunca lo hará.
4. La auditoría siguiente verifica. Si el hallazgo desapareció, la acción pasa sola a Verificado, con la auditoría como actor.

06Aceptar un riesgo

No todo se corrige: a veces el negocio decide convivir con un riesgo — temporalmente y con red. El formulario exige todos los campos:

Aceptar un riesgo alto lo firma otra persona — el aprobador de excepciones —, porque quien convive con el riesgo no debería poder aceptarlo. Una excepción sin fecha de vencimiento no es una excepción: es una renuncia. Y un control sin frecuencia ni evidencia no es un control: es una intención.

07Qué NO hace RoleShield

• No modifica SAP. Nunca. Ni un rol, ni un usuario, ni un valor. Cada pantalla que propone un cambio lo declara.
• No audita lo que la extracción no baja. El universo son los roles Z* del mandante auditado. Los roles estándar de SAP y los perfiles concedidos directamente en SU01 quedan fuera del recertificable — y estos últimos el producto los trata como hallazgo crítico, no como rutina.
• No confunde «sin ingreso» con «sin uso». El último ingreso es de diálogo; una interfaz puede operar por RFC sin registrarlo. Las posibles técnicas van marcadas y no se bloquean sin Basis.
• No adivina. El módulo de un rol sale de su contenido real (sus transacciones), nunca del nombre; si no puede determinarse, se dice «sin módulo» y decide el responsable general. Un cero que no se pudo medir se muestra como «—», no como cero.
• No decide por el negocio. Propone, ordena por impacto, simula y verifica. Aprobar es de los dueños del proceso; ejecutar, del equipo SAP.

08Glosario y referencia rápida