Avalados por :
Como melhorar a construção de funções de segurança no SAP S/4HANA: Evite a mudança manual, busque o padrão.
- Creado 01/03/2024
- Modificado 01/03/2024
- 2 Vistas
0
Cargando...
Como aproveitar a nova funcionalidade para melhorar a construção de funções de segurança no SAP S/4HANA.
Evite a ALTERAÇÃO MANUAL por Exceção. MANTIDO está correto. Busque o PADRÃO.
Durante o tempo em que tenho construído funções de segurança de aplicativos através da transação PFCG, este tem sido o mantra que tenho seguido ao manter as autorizações. A transação PFCG (Manutenção de funções) está integrada com a transação SU24 (Propostas de autorizações). Essa integração importa e remove automaticamente propostas de autorizações da função com base nos elementos do menu da função.
Com a mudança para o SAP S/4HANA e SAP Fiori, a gestão de autorizações se torna mais importante do que nunca. As autorizações afetam diretamente a Experiência do Usuário de seus usuários. Se você cometer um erro, corre o risco de degradar ativamente a adoção de UX e reduzir os benefícios que seus usuários e sua organização podem obter dessas inovações. Por exemplo, adicionar manualmente um código de transação a uma função o tornará indisponível para os usuários no Launchpad do Fiori.
Em grande parte, a transação SU24 é um acelerador de construção e é considerada uma prática recomendada para a construção de funções, pois:
Voltando ao mantra -
Evite a ALTERAÇÃO MANUAL por Exceção. MANTIDO está correto. Busque o PADRÃO.
Por que evitar a ALTERAÇÃO?
Evitamos a ALTERAÇÃO porque é uma quebra deliberada dos mapeamentos e desvia da consistência. Um objeto de estado ALTERADO é tratado como um objeto MANUAL. A transação PFCG não pode remover automaticamente uma autorização ALTERADA de uma função quando a transação é removida, pois não há relação entre os dados. Portanto, objetos ALTERADOS podem aumentar a expansão de acesso e dificultar a avaliação adequada do impacto ou a remoção do acesso.
Por que MANUAL por Exceção?
Aceitamos MANUAL por exceções. Algumas autorizações são necessárias, mas não estão mapeadas para elementos de aplicativos que podem ser adicionados a um menu de funções (por exemplo, S_RFCACL para RFC de confiança). Algumas podem ser decisões de design claras para complementar uma função existente e fornecer autorização adicional (por exemplo, códigos de aprovação de compras). Essas exceções estão claramente documentadas e é menos provável que mudem.
Por que buscar o PADRÃO?
Buscamos o PADRÃO, pois significa que tínhamos 100% de alinhamento com as propostas de autorização. Supondo que os dados do SU24 sejam precisos, é improvável que a equipe de administradores de segurança precise manter valores no PFCG.
Por que está correto MANTIDO?
Aceitamos e nos conformamos com o MANTIDO como um equilíbrio entre mapear o que podemos no SU24 e evitar o estado ALTERADO.
Seria ótimo se não tivéssemos que nos conformar com o mantido? As variantes tornam isso possível.
O estado MANTIDO ocorre porque mantemos parcialmente a proposta de autorização dentro do SU24. Isso é necessário quando um código de transação pertence a mú
Evite a ALTERAÇÃO MANUAL por Exceção. MANTIDO está correto. Busque o PADRÃO.
Durante o tempo em que tenho construído funções de segurança de aplicativos através da transação PFCG, este tem sido o mantra que tenho seguido ao manter as autorizações. A transação PFCG (Manutenção de funções) está integrada com a transação SU24 (Propostas de autorizações). Essa integração importa e remove automaticamente propostas de autorizações da função com base nos elementos do menu da função.
Com a mudança para o SAP S/4HANA e SAP Fiori, a gestão de autorizações se torna mais importante do que nunca. As autorizações afetam diretamente a Experiência do Usuário de seus usuários. Se você cometer um erro, corre o risco de degradar ativamente a adoção de UX e reduzir os benefícios que seus usuários e sua organização podem obter dessas inovações. Por exemplo, adicionar manualmente um código de transação a uma função o tornará indisponível para os usuários no Launchpad do Fiori.
Uma visão geral da integração de PFCG e SU24
Em grande parte, a transação SU24 é um acelerador de construção e é considerada uma prática recomendada para a construção de funções, pois:
- Reduz a expansão de acesso : ao remover transações do menu da função, também são removidas as propostas de autorizações associadas (se outro elemento do menu não as exigir). Esse benefício funciona apenas para elementos de estado de autorização padrão e mantidos.
- Reduz erros de autorização : a função receberá automaticamente as autorizações necessárias para cada aplicativo, desde que os mapeamentos estejam completamente mantidos na transação SU24 e o aplicativo tenha sido adicionado ao menu da função.
- Reduz o esforço e o tempo de construção : os administradores de segurança podem aproveitar os mapeamentos existentes como parte da construção da função e exigem menos tempo para mapear os valores para cada função.
- Simplifica e melhora a Análise de Impacto: torna mais fácil para os especialistas em autorizações de funções identificar facilmente por que uma autorização faz parte de uma função de segurança. Isso ajuda na avaliação do impacto da segregação de funções, na limpeza de funções e na priorização dos testes de regressão.
Voltando ao mantra -
Evite a ALTERAÇÃO MANUAL por Exceção. MANTIDO está correto. Busque o PADRÃO.
Por que evitar a ALTERAÇÃO?
Evitamos a ALTERAÇÃO porque é uma quebra deliberada dos mapeamentos e desvia da consistência. Um objeto de estado ALTERADO é tratado como um objeto MANUAL. A transação PFCG não pode remover automaticamente uma autorização ALTERADA de uma função quando a transação é removida, pois não há relação entre os dados. Portanto, objetos ALTERADOS podem aumentar a expansão de acesso e dificultar a avaliação adequada do impacto ou a remoção do acesso.
Por que MANUAL por Exceção?
Aceitamos MANUAL por exceções. Algumas autorizações são necessárias, mas não estão mapeadas para elementos de aplicativos que podem ser adicionados a um menu de funções (por exemplo, S_RFCACL para RFC de confiança). Algumas podem ser decisões de design claras para complementar uma função existente e fornecer autorização adicional (por exemplo, códigos de aprovação de compras). Essas exceções estão claramente documentadas e é menos provável que mudem.
Por que buscar o PADRÃO?
Buscamos o PADRÃO, pois significa que tínhamos 100% de alinhamento com as propostas de autorização. Supondo que os dados do SU24 sejam precisos, é improvável que a equipe de administradores de segurança precise manter valores no PFCG.
Por que está correto MANTIDO?
Aceitamos e nos conformamos com o MANTIDO como um equilíbrio entre mapear o que podemos no SU24 e evitar o estado ALTERADO.
Seria ótimo se não tivéssemos que nos conformar com o mantido? As variantes tornam isso possível.
Cenário comum para o estado MANTIDO
O estado MANTIDO ocorre porque mantemos parcialmente a proposta de autorização dentro do SU24. Isso é necessário quando um código de transação pertence 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?