Incremento de Segurança na Administração de Documentos Contábeis – FB02 – F_BKPF_BLA

Dada a criticidade das informações que mantém, a camada de autorizações relacionada aos componentes FI/CO, estes que, transacionam informações estratégicas e sensíveis, é amplamente discutida. O estabelecimento de controles, tal qual, SOD, visa assegurar a lisura nos processos e a integridade das informações demonstradas.

O ponto de partida para esta publicação foi a seguinte impressão: “A verificação de autorizações na FB02 não provém um nível de granularidade que habilite a restrição a modificações para determinados tipos de documentos.”

Cenário.:

  • Usuários de contabilidade são aptos a modificação de documentos X1 – Lançamento imobilizado, entretanto, não é tolerável qualquer modificação para documenos Z2 – Pgto.Tributos.

Contexto.:

O rigor e a integridade das informações transacionadas no sistema SAP, dentre outros aspectos, são asseguradas pelo robusto conceito de autorizações. Este que,  abrange diversos componentes e permite a configuração de restrições complexas, sejam standard, híbridas ou totalmente personalizadas.

Através de um trace de autorizações(STAUTHTRACE), observamos que a rotina de modificações executada na FB02 verifica alguns objetos F_BKPF*, que por sua vez compõem a classe de objetos FI – Contabilidade Financeira.

Em uma análise superficial, observamos verificações relacionadas a: Empresa, Tipo de Conta, Área de Contabilidade de Custos, dentre outros objetos Etc.

Solução.:

A solução viável para nosso cenário foi mapeada e publicada pela SAP há bastante tempo, mesmo assim, achei por bem consolidar as informações.

Através das notas supracitadas, a SAP nos expôs a possibilidade da restrição de modificações por Grupos de Autorizações, semelhante ao funcionamento do Grupo de Autorização Programa(P_GROUP) carregado pelo objeto S_PROGRAM e o Grupo de Autorizações de Tabela(DICBERCLS) carregado pelo objeto S_TABU_DIS.

Os objetos de autorização citados como exemplo, têm como propósito viabilizar a composição de regras granulares, permitindo a distinção de regras de atividade em função do agrupamento dos objetos sujeitos às ações, Sejam eles: programas, tabelas ou em nosso caso, tipos de documentos.

Exemplo:

A role 01 – Assistente de Contabilidade deve habilitar a modificação em lançamentos tipo “A1”, bem como, assegurar que lançamentos tipo “C1” estejam restritos somente a visualização.

Ajuste.:

Para tal configuração, a SAP provém o objeto F_BKPF_BLA que se comporta como opcional, tendo sua etapa de verificação relevante quando o Tipo do Documento está categorizado em um Grupo de Autorizações.

  1. Através da transação OBA7 obtemos a visão acerca dos Tipos de Documentos, ao expandir a visão de um tipo específico, temos contato com suas propriedades.
  2. O campo “Grupo de Autorizações” é um CHAR que recebe 4 caracteres, “YDOC”, por exemplo. Definição SAP: “O Grupo de Autorizações possibilita uma proteção de autorização ampliada para determinados objetos. Os grupos de autorização podem ser definidos livremente. Os grupos de autorização surgem em objetos de autorização, geralmente em combinação com uma atividade.”
  3. A categorização do Tipo de Documento em um Grupo de Autorizações específico, o torna suscetível a restrições.
  4. Superada a etapa de atribuição do Tipo de Documento ao grupo, cabe uma checagem nos indicadores de verificação através da SU24 para o objeto F_BKPF_BLA.
    1. A transação FB02 carrega devidamente o objeto F_BKPF_BLA?
    2. O objeto F_BKPF_BLA sofreu alguma manutenção que alterasse seus valores propostos?
  5. Atribuição, verificação e proposta OK? Definimos através da PFCG a configuração de acordo com a necessidade.
    1. Recomendações:
      1. Evitemos a inserção manual e modificação de objetos em desacordo a lista de utilizações, preservemos a relação transacional SU24 x PFCG o máximo possível.
      2. Verifiquemos a ocorrência de autorizações sobrepostas, eventualmente alguma autorização para o F_BKPF_BLA pode ter sido definida com “*”, seja na role em si, ou em outra role que esteja atribuída ao usuário. A condição pode ser verificada através da análise do buffer do usuário na transação SU56 ou exame das roles a ele atribuídas através da tabela AGR_1251.

Referências.:

Tópicos relacionados:

Resumo.:

Em suma, a proposta de solução para o cenário apresentado utiliza um conceito bem difundido dentro das práticas de SAP Security, grupos. Sejam de usuários, programas, tabelas, documentos ou qualquer elemento, nos possibilitam a trazer maior granularidade para nossas restrições. Conforme dito anteriormente, outras rotinas aceitam ajustes dessa natureza, podemos superficialmente buscar por objetos relacionados através do report RSUSR040.

Em breve detalharei outros contextos e estratégias relacionadas a autorizações SAP. Espero poder contribuir, a intenção é sempre: Aprender, compartilhar e fortalecer a comunidade.