Avalados por :
Cómo mejorar la construcción de roles de seguridad en SAP S/4HANA: Evita el cambio manual, busca el estándar.
- Creado 01/03/2024
- Modificado 01/03/2024
- 21 Vistas
0
Cargando...
Cómo puedes aprovechar la nueva funcionalidad para mejorar la construcción de roles de seguridad en SAP S/4HANA.
Evita el CAMBIADO. MANUAL por Excepción. MANTENIDO está bien. Busca el ESTÁNDAR.
Durante el tiempo que he estado construyendo roles de seguridad de aplicaciones a través de la transacción PFCG, este ha sido el mantra que he seguido al mantener las autorizaciones. La transacción PFCG (Mantenimiento de roles) está integrada con la transacción SU24 (Propuestas de autorizaciones). Esta integración importa y elimina automáticamente propuestas de autorizaciones del rol basándose en los elementos del menú del rol.
Con el cambio a SAP S/4HANA y SAP Fiori, la gestión de autorizaciones se vuelve más importante que nunca. Las autorizaciones afectan directamente la Experiencia del Usuario de tus usuarios. Si te equivocas, corres el riesgo de degradar activamente la adopción de UX y reducir los beneficios que tus usuarios y tu organización pueden obtener de estas innovaciones. Por ejemplo, agregar manualmente un código de transacción a un rol lo hará no disponible para los usuarios en el Launchpad de Fiori.
En su mayor parte, la transacción SU24 es un acelerador de construcción y se considera una mejor práctica para la construcción de roles ya que:
Volviendo al mantra –
Evita el CAMBIADO. MANUAL por Excepción. MANTENIDO está bien. Busca el ESTÁNDAR.
¿Por qué evitar el CAMBIADO?
Evitamos el CAMBIO porque es una ruptura deliberada de los mapeos y se desvía de la consistencia. Un objeto de estado CAMBIADO se trata como un objeto MANUAL. La transacción PFCG no puede eliminar automáticamente una autorización CAMBIADA de un rol cuando se elimina la transacción ya que no hay relación entre los datos. Por lo tanto, los objetos CAMBIADOS pueden aumentar la expansión de acceso y dificultar la evaluación adecuada del impacto o la eliminación del acceso.
¿Por qué MANUAL por Excepción?
Aceptamos MANUAL por excepciones. Algunas autorizaciones son necesarias pero no están mapeadas a elementos de aplicaciones que pueden agregarse a un menú de roles (por ejemplo, S_RFCACL para RFC de confianza). Algunas pueden ser decisiones de diseño claras para complementar un rol existente y proporcionar autorización adicional (por ejemplo, códigos de aprobación de compras). Estas excepciones están claramente documentadas y es menos probable que cambien.
¿Por qué buscar el ESTÁNDAR?
Buscamos el ESTÁNDAR ya que significa que teníamos un 100% de alineación con las propuestas de autorización. Suponiendo que los datos de SU24 son precisos, es poco probable que el equipo de administradores de seguridad necesite mantener valores en PFCG.
¿Por qué está bien MANTENIDO?
Aceptamos y nos conformamos con MANTENIDO como un equilibrio entre mapear lo que podemos en SU24 y evitar el estado CAMBIADO.
Sería genial si no tuviéramos que conformarnos con lo mantenido? Las variantes hacen esto posible.
El estado MANTENIDO ocurre porque solo mantenemos parcialmente la propuesta de autorización dentro de SU24. Esto es necesario cuando un código de transacción pertenece a mú
Evita el CAMBIADO. MANUAL por Excepción. MANTENIDO está bien. Busca el ESTÁNDAR.
Durante el tiempo que he estado construyendo roles de seguridad de aplicaciones a través de la transacción PFCG, este ha sido el mantra que he seguido al mantener las autorizaciones. La transacción PFCG (Mantenimiento de roles) está integrada con la transacción SU24 (Propuestas de autorizaciones). Esta integración importa y elimina automáticamente propuestas de autorizaciones del rol basándose en los elementos del menú del rol.
Con el cambio a SAP S/4HANA y SAP Fiori, la gestión de autorizaciones se vuelve más importante que nunca. Las autorizaciones afectan directamente la Experiencia del Usuario de tus usuarios. Si te equivocas, corres el riesgo de degradar activamente la adopción de UX y reducir los beneficios que tus usuarios y tu organización pueden obtener de estas innovaciones. Por ejemplo, agregar manualmente un código de transacción a un rol lo hará no disponible para los usuarios en el Launchpad de Fiori.
Una visión general de la integración de PFCG y SU24
En su mayor parte, la transacción SU24 es un acelerador de construcción y se considera una mejor práctica para la construcción de roles ya que:
- Reduce la expansión de acceso : cuando se eliminan transacciones del menú del rol, también se eliminan las propuestas de autorizaciones asociadas (si otro elemento del menú no las requiere). Este beneficio solo funciona para elementos de estado de autorización estándar y mantenidos.
- Reduce errores de autorizaciones : el rol recibirá automáticamente las autorizaciones requeridas para cada aplicación siempre que los mapeos estén completamente mantenidos en la transacción SU24 y la aplicación se haya añadido al menú del rol
- Reduce el esfuerzo y el tiempo de construcción : los administradores de seguridad pueden aprovechar los mapeos existentes como parte de la construcción del rol y requiere menos tiempo para mapear los valores para cada rol.
- Simplifica y mejora el Análisis de Impacto: hace que sea más fácil para los expertos en autorizaciones de roles identificar fácilmente por qué una autorización forma parte de un rol de seguridad. Esto ayuda con la evaluación del impacto de la segregación de funciones, la limpieza de roles y la priorización de las pruebas de regresión.
Volviendo al mantra –
Evita el CAMBIADO. MANUAL por Excepción. MANTENIDO está bien. Busca el ESTÁNDAR.
¿Por qué evitar el CAMBIADO?
Evitamos el CAMBIO porque es una ruptura deliberada de los mapeos y se desvía de la consistencia. Un objeto de estado CAMBIADO se trata como un objeto MANUAL. La transacción PFCG no puede eliminar automáticamente una autorización CAMBIADA de un rol cuando se elimina la transacción ya que no hay relación entre los datos. Por lo tanto, los objetos CAMBIADOS pueden aumentar la expansión de acceso y dificultar la evaluación adecuada del impacto o la eliminación del acceso.
¿Por qué MANUAL por Excepción?
Aceptamos MANUAL por excepciones. Algunas autorizaciones son necesarias pero no están mapeadas a elementos de aplicaciones que pueden agregarse a un menú de roles (por ejemplo, S_RFCACL para RFC de confianza). Algunas pueden ser decisiones de diseño claras para complementar un rol existente y proporcionar autorización adicional (por ejemplo, códigos de aprobación de compras). Estas excepciones están claramente documentadas y es menos probable que cambien.
¿Por qué buscar el ESTÁNDAR?
Buscamos el ESTÁNDAR ya que significa que teníamos un 100% de alineación con las propuestas de autorización. Suponiendo que los datos de SU24 son precisos, es poco probable que el equipo de administradores de seguridad necesite mantener valores en PFCG.
¿Por qué está bien MANTENIDO?
Aceptamos y nos conformamos con MANTENIDO como un equilibrio entre mapear lo que podemos en SU24 y evitar el estado CAMBIADO.
Sería genial si no tuviéramos que conformarnos con lo mantenido? Las variantes hacen esto posible.
Escenario común para el estado MANTENIDO
El estado MANTENIDO ocurre porque solo mantenemos parcialmente la propuesta de autorización dentro de SU24. Esto es necesario cuando un código de transacción pertenece a mú
Pedro Pascal
Se unió el 07/03/2018
Facebook
Twitter
Pinterest
Telegram
Linkedin
Whatsapp
Sin respuestas
No hay respuestas para mostrar
Se el primero en responder
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
Hola ¿Puedo ayudarte?