1. Por Que as Auditorias de Segurança SAP Perdem Conflitos de Função

A verdade incômoda sobre a auditoria de segurança SAP em 2026 é que a maioria das organizações ainda opera com ferramentas e processos projetados para um mundo com 200 usuários e 50 funções (roles). O ambiente SAP empresarial médio hoje tem entre 8.000 e 40.000 usuários ativos, dezenas de milhares de funções e objetos de autorização que se espalham por funções compostas, funções derivadas e agregações de perfis de maneiras que nenhum auditor humano pode rastrear de forma confiável durante um trabalho pontual.

Existem três razões estruturais pelas quais as auditorias perdem conflitos de função, e elas se agravam mutuamente.

A Ilusão SU53

SU53 é a primeira ferramenta que todo administrador BASIS utiliza quando um usuário relata uma falha de autorização. Ela mostra a última verificação de autorização que falhou — o que é útil para solução de problemas, mas ativamente enganoso para auditoria de segurança. SU53 registra apenas a verificação negada mais recente. Não informa o que o usuário pode fazer, apenas o que ele acabou de tentar e não conseguiu. Um usuário com um conflito catastrófico de SoD (Segregação de Funções) — digamos, a capacidade de criar um fornecedor e aprovar uma rodada de pagamentos — nunca aparecerá na SU53 porque essas autorizações não estão falhando. Elas estão funcionando exatamente como configuradas. Esse é o problema.

Explosão de Funções e Opacidade de Funções Compostas

Em um sistema SAP maduro, um único usuário pode ter de 30 a 80 funções atribuídas diretamente ou por meio de herança baseada em posição do HCM ou GRC. Cada função composta contém funções filhas. Cada função filha contém perfis. Cada perfil contém objetos de autorização. Cada objeto de autorização tem valores em nível de campo. Para realmente entender o que um determinado usuário pode fazer, você deve percorrer uma árvore que pode ter vários milhares de nós folha por usuário. Multiplique isso por 10.000 usuários e você terá um problema combinatório que inviabiliza a auditoria baseada em planilhas na primeira hora.

Já vi equipes BASIS gastarem seis semanas extraindo dados manualmente de AGR_USERS, AGR_1251 e USR10 para produzir uma matriz de funções que já estava desatualizada quando a tabela dinâmica do Excel foi finalizada.

Cegueira da Auditoria Pontual

Auditorias externas acontecem uma vez por ano. Auditorias internas, se acontecem, são trimestrais. Entre as auditorias, os usuários acumulam funções temporárias que nunca são removidas, acessos de emergência que se tornam permanentes por inércia e modificações de funções que ignoram completamente o processo de gerenciamento de mudanças. A janela de falha de segurança não é a única semana por ano em que um auditor está no local. A janela de falha de segurança são as outras 51 semanas.

2. Anatomia de uma Falha de Segurança SAP Real Causada por Conflito de SoD

O seguinte estudo de caso é baseado em um projeto real. Nomes de empresas, IDs de sistema e detalhes de identificação pessoal foram alterados ou removidos a pedido do cliente. Os detalhes técnicos são precisos.

O Cenário

O cliente é uma empresa de manufatura por processo com aproximadamente R$ 4,5 bilhões (€800M) em receita anual. Seu ambiente SAP ECC 6.0 (ainda não migrado para S/4HANA) estava em produção há 11 anos. Durante esse período, a equipe BASIS original mudou três vezes. A documentação de funções era parcial. A convenção de nomenclatura de funções havia mudado duas vezes. Havia 14.200 funções ativas no sistema, das quais a equipe atual conseguia descrever com precisão o propósito de menos de 3.000.

O Conflito

Uma usuária do departamento de contas a pagar — vou chamá-la de Usuária A — tinha as seguintes autorizações, acumuladas em seis funções separadamente atribuídas ao longo de quatro anos de adições de funções sem as remoções correspondentes:

• Transação FK01 (Criar Fornecedor) com autorização total para centro de custo e grupo de contas
• Transação F110 (Execução Automática de Pagamento) com autorização para definir parâmetros de pagamento e executar o processo
• Transação FB60 (Lançar Fatura de Fornecedor) com autorização total de lançamento
• Transação FK02 (Modificar Fornecedor) incluindo campos de conta bancária
• Acesso ao programa de meio de pagamento RFFOUS_T com criação irrestrita de variantes

Em linguagem simples: a Usuária A podia criar um fornecedor fictício, lançar faturas contra esse fornecedor, alterar a conta bancária no cadastro do fornecedor para uma conta que ela controlava e executar o processo de pagamento sozinha. Nenhuma segunda análise era necessária em nenhuma etapa. O conjunto de regras de SoD no SAP GRC tinha uma regra para criação de fornecedor versus execução de pagamento, mas ela havia sido definida com status de controle mitigador porque um gerente havia aprovado uma exceção agora expirada quatro anos antes. A sinalização de exceção nunca foi removida.

A Falha de Segurança

Ao longo de 18 meses, a Usuária A desviou R$ 1,8 milhão (€340,000) em pagamentos para uma empresa de fachada. A fraude foi descoberta não pela auditoria interna, não pelo SAP GRC, mas por um fornecedor que ligou para reclamar que sua fatura não havia sido paga, apesar de aparecer como liquidada no sistema. Uma conciliação bancária manual — realizada porque o fornecedor escalou para o CFO — revelou a discrepância.

A falha de segurança ocorreu porque o conflito de SoD existia silenciosamente. O GRC o tinha sinalizado, mas como mitigado, não como um risco ativo que exigia revisão. Ninguém havia validado se a mitigação ainda estava em vigor ou ainda era apropriada. Auditorias pontuais haviam visto a sinalização de controle mitigador e seguiram em frente.

O Que a Detecção por IA Teria Mudado

Um sistema de monitoramento contínuo aumentado por IA, consultando as tabelas de autorização diariamente, teria sinalizado três coisas que o conjunto de regras estáticas perdeu: o timestamp de mitigação expirado, a combinação de alteração de conta bancária de fornecedor mais execução de pagamento no perfil de autorização do mesmo usuário (um SoD de segunda ordem não presente no conjunto de regras padrão) e uma anomalia na frequência de transações da Usuária A na F110 que se desviava três desvios padrão da linha de base de seu grupo de pares.

3. Como a IA Muda a Auditoria de Segurança

A mudança da auditoria manual e baseada em regras para a auditoria aumentada por IA não é apenas uma questão de velocidade. Ela muda o que é detectável em um nível fundamental.

Reconhecimento de Padrões em Mais de 50.000 Permissões

Um modelo de classificação bem treinado pode avaliar o perfil de autorização completo de cada usuário em um sistema — todos os objetos de autorização, todos os valores de campo, todas as hierarquias de funções — e produzir uma pontuação de risco em minutos. Mais importante, ele pode identificar conflitos de SoD emergentes: combinações de autorizações que individualmente parecem inofensivas, mas que juntas criam um caminho de risco que nenhum conjunto de regras estático antecipou.

No caso do cliente de manufatura, a combinação de F_LFA1_BUK (alteração de cadastro de fornecedor por centro de custo) e F_PAYR_BUK (autorização de pagamento) não estava no conjunto de regras padrão do GRC. Um modelo treinado em padrões históricos de fraude em ambientes SAP anonimizados sinalizou-o imediatamente como um vetor de manipulação financeira de alta probabilidade.

Detecção de Anomalias: Comportamento Versus Autorização

A análise de autorização informa o que um usuário pode fazer. A análise de comportamento, impulsionada pela integração SIEM e mineração de logs de auditoria SAP, informa o que eles estão fazendo. A lacuna entre os dois é a sua verdadeira superfície de risco. Modelos de IA podem manter linhas de base comportamentais por usuário e por grupo de funções e alertar quando a atividade se desvia. Um usuário que cria três fornecedores por trimestre e de repente cria 40 em uma semana é uma anomalia. Um usuário que nunca executou a F110 antes de executá-la às 23:47 de uma sexta-feira é uma anomalia. Sistemas baseados em regras exigem que alguém escreva essa regra explicitamente. A detecção de anomalias a encontra sem uma regra predefinida.

Monitoramento Contínuo vs. Auditoria Pontual

A mudança arquitetônica mais significativa que a IA permite é a transição da auditoria como um evento para a auditoria como um estado. Em vez de um projeto de seis semanas produzindo um relatório que está obsoleto antes de ser assinado, o monitoramento contínuo impulsionado por IA produz um painel de risco em tempo real que é atualizado diariamente ou em tempo real. Desvios são sinalizados à medida que ocorrem. A remediação é acionada em horas, não em meses.

4. Comparativo de Ferramentas: SAP GRC vs. Opções Aumentadas por IA

O mercado em 2026 oferece vários níveis de ferramentas para gerenciamento de risco de acesso SAP. Aqui está uma comparação honesta baseada na experiência prática em múltiplos ambientes de clientes.

O SAP GRC Access Control continua sendo a espinha dorsal do processo de governança para a maioria das grandes empresas. Ele lida com workflow, emissão de tickets de remediação, acesso "firefighter" e log de auditoria de maneiras que ferramentas externas não podem replicar totalmente. A crítica não é que ele não funciona, mas que funciona apenas tão bem quanto o conjunto de regras que lhe é dado, e manter esse conjunto de regras em escala empresarial exige administradores de GRC dedicados que são cada vez mais difíceis de contratar.

SecurityBridge é a ferramenta que mais recomendo como complemento ao GRC, não como substituto. Sua força está em detectar o que está acontecendo em vez de o que é permitido. Quando integrado com um SIEM como Splunk ou Microsoft Sentinel, ele cria uma camada de detecção que captura o uso indevido em tempo de execução que a análise de acesso estática perde completamente.

A abordagem de LLM personalizado é onde o desenvolvimento técnico mais interessante está acontecendo agora, e é por isso que a maior parte deste artigo se concentra nela.

5. Construindo um Detector de Conflitos de Função Impulsionado por IA

O que se segue é um passo a passo de um pipeline de detecção de conflitos de função leve, mas capaz de produção. Ele usa Python para extrair dados de autorização do SAP via RFC e, em seguida, passa os perfis extraídos para um LLM para classificação de risco. Implantei variações disso em três clientes nos últimos 12 meses.

Passo 1: Extrair Dados de Autorização via RFC

Instale pyrfc (o conector RFC oficial do SAP para Python) e configure um usuário técnico no SAP com acesso de exibição às tabelas de autorização relevantes. O usuário precisa de S_RFC com o grupo de funções SRFC e acesso de leitura às tabelas AGR_USERS, AGR_1251, USR10, UST04 e USOBT_C.

import pyrfc
import pandas as pd
from datetime import datetime

SAP_CONN = {
    "ashost": "10.0.1.45",
    "sysnr": "00",
    "client": "100",
    "user": "AUDIT_RFC_USR",
    "passwd": "REDACTED",
    "lang": "EN"
}

def extract_user_role_assignments(conn, system_id: str) -> pd.DataFrame:
    """
    Extract all user-to-role assignments from AGR_USERS.
    Returns a DataFrame with columns: USER_ID, AGR_NAME, FROM_DATE, TO_DATE.
    """
    result = conn.call(
        "RFC_READ_TABLE",
        QUERY_TABLE="AGR_USERS",
        DELIMITER="|",
        FIELDS=[
            {"FIELDNAME": "UNAME"},
            {"FIELDNAME": "AGR_NAME"},
            {"FIELDNAME": "FROM_DAT"},
            {"FIELDNAME": "TO_DAT"},
        ]
    )
    rows = []
    for entry in result["DATA"]:
        parts = entry["WA"].split("|")
        rows.append({
            "USER_ID": parts[0].strip(),
            "AGR_NAME": parts[1].strip(),
            "FROM_DATE": parts[2].strip(),
            "TO_DATE": parts[3].strip(),
            "SYSTEM": system_id,
            "EXTRACTED_AT": datetime.utcnow().isoformat()
        })
    return pd.DataFrame(rows)


def extract_role_authorization_objects(conn, role_name: str) -> pd.DataFrame:
    """
    Extract authorization objects and field values for a given role from AGR_1251.
    """
    result = conn.call(
        "RFC_READ_TABLE",
        QUERY_TABLE="AGR_1251",
        DELIMITER="|",
        OPTIONS=[{"TEXT": f"AGR_NAME = '{role_name}'"}],
        FIELDS=[
            {"FIELDNAME": "AGR_NAME"},
            {"FIELDNAME": "OBJECT"},
            {"FIELDNAME": "AUTH"},
            {"FIELDNAME": "FIELD"},
            {"FIELDNAME": "LOW"},
            {"FIELDNAME": "HIGH"},
        ]
    )
    rows = []
    for entry in result["DATA"]:
        parts = entry["WA"].split("|")
        rows.append({
            "AGR_NAME": parts[0].strip(),
            "OBJECT": parts[1].strip(),
            "AUTH": parts[2].strip(),
            "FIELD": parts[3].strip(),
            "VALUE_LOW": parts[4].strip(),
            "VALUE_HIGH": parts[5].strip() if len(parts) > 5 else ""
        })
    return pd.DataFrame(rows)


# Main extraction loop
with pyrfc.Connection(**SAP_CONN) as conn:
    print(f"Connected to SAP. Extracting role assignments...")
    user_roles = extract_user_role_assignments(conn, system_id="PRD")

    # Get unique roles to avoid redundant lookups
    unique_roles = user_roles["AGR_NAME"].unique()
    print(f"Found {len(user_roles)} assignments across {len(unique_roles)} unique roles.")

    auth_objects = pd.concat([
        extract_role_authorization_objects(conn, role)
        for role in unique_roles
    ], ignore_index=True)

    user_roles.to_parquet("/tmp/sap_audit/user_roles.parquet")
    auth_objects.to_parquet("/tmp/sap_audit/auth_objects.parquet")
    print("Extraction complete.")

Passo 2: Construir Perfis de Autorização do Usuário

Junte os dois conjuntos de dados para produzir uma lista plana por usuário de objetos de autorização e seus valores efetivos. Esta é a entrada sobre a qual o LLM irá raciocinar.

def build_user_profiles(user_roles: pd.DataFrame, auth_objects: pd.DataFrame) -> dict:
    """
    Produce a dict keyed by USER_ID where each value is a list of
    (OBJECT, FIELD, VALUE_LOW, VALUE_HIGH) tuples representing the user's
    aggregated authorization profile across all assigned roles.
    """
    merged = user_roles.merge(auth_objects, on="AGR_NAME", how="left")

    profiles = {}
    for user_id, group in merged.groupby("USER_ID"):
        auth_list = group[["OBJECT", "FIELD", "VALUE_LOW", "VALUE_HIGH"]].drop_duplicates()
        profiles[user_id] = auth_list.to_dict(orient="records")

    return profiles


def summarise_profile_for_llm(user_id: str, profile: list) -> str:
    """
    Produce a compact text summary of a user's authorization profile
    suitable for passing to an LLM context window.
    """
    # Group by authorization object
    by_object = {}
    for entry in profile:
        obj = entry["OBJECT"]
        if obj not in by_object:
            by_object[obj] = []
        by_object[obj].append(
            f"  {entry['FIELD']}: {entry['VALUE_LOW']}"
            + (f" to {entry['VALUE_HIGH']}" if entry['VALUE_HIGH'] else "")
        )

    lines = [f"User: {user_id}", "Authorization Objects:"]
    for obj, fields in sorted(by_object.items()):
        lines.append(f"  [{obj}]")
        lines.extend(fields)

    return "\n".join(lines)

Passo 3: Classificação de Risco por LLM

Passe o perfil resumido de cada usuário para um LLM com um prompt estruturado, solicitando que ele identifique conflitos de SoD, avalie sua gravidade e explique o risco em termos de negócio. Em produção, utilizo um modelo auto-hospedado (Mistral 7B ou LLaMA 3.1 8B) para manter os dados de autorização fora de infraestruturas de terceiros. Para trabalhos de prova de conceito em um ambiente de sandbox, uma API comercial é mais rápida para começar.

import anthropic
import json

client = anthropic.Anthropic()  # Reads ANTHROPIC_API_KEY from environment

SOD_CLASSIFICATION_PROMPT = """
You are an SAP security expert specialising in Segregation of Duties (SoD) analysis.

Below is the authorization profile for a single SAP user, extracted from the production system.
Analyze it and identify:

1. Any Segregation of Duties conflicts — combinations of authorization objects that, together,
   give this user the ability to perform a complete financial or data manipulation cycle
   without requiring another person's approval.

2. For each conflict found, provide:
   - Conflict name (short)
   - Authorization objects involved
   - Business risk in plain English (one sentence)
   - Severity: CRITICAL / HIGH / MEDIUM / LOW
   - Recommended action

Return your response as valid JSON in this exact structure:
{
  "user_id": "...",
  "conflicts": [
    {
      "name": "...",
      "objects": ["...", "..."],
      "risk": "...",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW",
      "recommendation": "..."
    }
  ],
  "overall_risk": "CRITICAL|HIGH|MEDIUM|LOW|CLEAN",
  "summary": "..."
}

If no conflicts are found, return an empty conflicts array and overall_risk of CLEAN.

USER AUTHORIZATION PROFILE:
{profile_text}
"""

def classify_user_risk(user_id: str, profile_summary: str) -> dict:
    prompt = SOD_CLASSIFICATION_PROMPT.format(profile_text=profile_summary)

    message = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )

    response_text = message.content[0].text
    try:
        return json.loads(response_text)
    except json.JSONDecodeError:
        # Fallback: extract JSON block if model added surrounding text
        import re
        match = re.search(r'\{.*\}', response_text, re.DOTALL)
        if match:
            return json.loads(match.group())
        return {"user_id": user_id, "error": "parse_failed", "raw": response_text}

Passo 4: Gerar o Relatório de Auditoria

Agregue todas as classificações de risco e produza um relatório pronto para executivos. O relatório ABAP abaixo pode ser executado em paralelo para gerar um rastro de auditoria nativo do SAP que satisfaz os requisitos de workflow do GRC.

*&---------------------------------------------------------------------*
*& Report  ZAIS_SOD_CONFLICT_REPORT
*& AI-Augmented SoD Conflict Summary — for use alongside AI pipeline output
*&---------------------------------------------------------------------*
REPORT zais_sod_conflict_report.

TABLES: agr_users, agr_1251, usr02.

TYPES: BEGIN OF ty_conflict,
         uname    TYPE xubname,
         agr_name TYPE agr_agr_name,
         object   TYPE xuobject,
         field    TYPE xufeld,
         low_val  TYPE xuval,
       END OF ty_conflict.

DATA: lt_conflicts TYPE TABLE OF ty_conflict,
      ls_conflict  TYPE ty_conflict,
      lv_count     TYPE i.

" Select all active role assignments
SELECT agr_users~uname, agr_users~agr_name,
       agr_1251~object, agr_1251~field, agr_1251~low
  INTO CORRESPONDING FIELDS OF TABLE lt_conflicts
  FROM agr_users
  INNER JOIN agr_1251 ON agr_users~agr_name = agr_1251~agr_name
  WHERE agr_users~to_dat >= sy-datum
    AND agr_1251~object IN ('F_BKPF_BUK', 'F_LFA1_BUK',
                             'F_PAYR_BUK', 'F_KNA1_BUK',
                             'P_ORGIN', 'S_DEVELOP').

lv_count = lines( lt_conflicts ).
WRITE: / 'Total authorization entries scanned:', lv_count.
WRITE: / 'Report generated:', sy-datum, sy-uzeit.
WRITE: / 'System:', sy-sysid, '/', sy-mandt.
WRITE: / '-------------------------------------------'.
WRITE: / 'Export this output and cross-reference with AI pipeline results.'.
WRITE: / 'File: /tmp/sap_audit/ai_risk_report.json'.

Passo 5: Operacionalizar como um Job Noturno

Agende o pipeline Python como um cron job em um bastion host com acesso RFC ao ambiente SAP. Configure alertas para que qualquer usuário cuja pontuação de risco mude de CLEAN para HIGH ou CRITICAL durante a noite acione uma notificação imediata no Slack ou Teams para a equipe de segurança SAP. Registre todos os resultados em um banco de dados de série temporal para análise de tendências.

# /etc/cron.d/sap-ai-audit
# Run nightly at 02:15 to avoid overlap with batch jobs
15 2 * * * sap-audit-svc /opt/sap-audit/run_pipeline.sh >> /var/log/sap-audit/nightly.log 2>&1

# run_pipeline.sh
#!/bin/bash
set -euo pipefail
cd /opt/sap-audit
source .venv/bin/activate
python extract.py --system PRD --output /tmp/sap_audit/
python classify.py --input /tmp/sap_audit/ --output /tmp/sap_audit/ai_risk_report.json
python alert.py --report /tmp/sap_audit/ai_risk_report.json --threshold HIGH
python archive.py --date $(date +%Y-%m-%d)

6. Métricas Antes / Depois

Em três implementações deste pipeline em clientes em 2025–2026, as seguintes melhorias foram observadas e verificadas pelas respectivas funções de auditoria interna.

A métrica mais significativa operacionalmente é a latência de detecção. A falha de segurança do cliente de manufatura descrita anteriormente persistiu por 18 meses porque nenhum sistema automatizado estava procurando por mudanças de função na lacuna entre as auditorias. Um pipeline noturno teria sinalizado a mitigação expirada na primeira execução após sua data de expiração. Com o custo médio de um projeto GRC de R$ 130.000 a R$ 320.000 (€25,000–€60,000) por ciclo de auditoria, o custo de infraestrutura de um pipeline auto-hospedado (aproximadamente R$ 1.500 a R$ 4.000 por mês em computação) é trivialmente justificado.

7. Implicações de Conformidade: SOX, LGPD e ISO 27001

Uma das perguntas mais comuns que recebo de CISOs é se as descobertas de auditoria geradas por IA satisfazem auditores externos e examinadores regulatórios. A resposta curta, baseada em projetos em empresas com escopo SOX e entidades reguladas pela LGPD no Brasil (e GDPR na UE), é sim — mas apenas se você projetar o rastro de auditoria corretamente desde o início.

SOX Seção 404: Controles Gerais de TI

Auditores SOX que examinam os controles de acesso SAP procuram evidências de três coisas: que os controles de acesso existem, que estão operando efetivamente e que as exceções são identificadas e remediadas em tempo hábil. Um pipeline de IA que executa diariamente, registra cada resultado de classificação com um timestamp e aciona workflows de remediação documentados satisfaz todos os três requisitos — e o faz de forma mais completa do que um relatório anual de GRC. A chave é o registro imutável. Cada execução do pipeline deve produzir um log assinado e com timestamp que não pode ser alterado. Armazene-os em um armazenamento de dados somente de adição (Amazon S3 Object Lock, Azure Immutable Blob Storage ou um esquema de auditoria PostgreSQL de escrita única) e seus auditores PCAOB ou das Big Four terão o que precisam.

LGPD Artigo 32: Segurança do Tratamento

Para organizações que processam dados pessoais da UE no SAP (dados de RH no HCM, dados de clientes em módulos CRM ou SD), a LGPD (Lei Geral de Proteção de Dados) exige medidas técnicas apropriadas para garantir a segurança dos dados. O monitoramento contínuo de risco de acesso é uma forte demonstração de conformidade com o Artigo 32. Criticamente, o próprio pipeline de IA deve lidar com dados pessoais (IDs de usuário, atribuições de função) de maneira compatível com a LGPD. Se você usa uma API LLM hospedada em nuvem para classificação, garanta que seu contrato de processamento de dados cubra os dados de autorização SAP. Para a maioria dos ambientes regulamentados, um modelo auto-hospedado é a única opção viável.

ISO 27001:2022 Controles do Anexo A

A ISO 27001:2022 Anexo A inclui controles específicos para gerenciamento de acesso (A.5.15 a A.5.18) e para gerenciamento de identidade (A.5.16). A nova revisão de 2022 adicionou A.8.2 (direitos de acesso privilegiado) e A.8.3 (restrição de acesso à informação) como controles explícitos. Um programa de monitoramento contínuo aumentado por IA se alinha diretamente a esses controles e fornece evidências documentadas de sua eficácia operacional. Para organizações que buscam a certificação ISO 27001 ou mantêm a certificação existente, a saída do pipeline pode ser referenciada na Declaração de Aplicabilidade como evidência da implementação do controle.

Satisfazendo Auditores com Descobertas Geradas por IA

Auditores externos em 2026 estão cada vez mais familiarizados com a análise gerada por IA, mas ainda exigem três coisas para confiar nas descobertas da IA: explicabilidade (o LLM deve ser capaz de articular por que um conflito é um conflito), reprodutibilidade (executar os mesmos dados através do mesmo modelo deve produzir resultados consistentes) e revisão humana (pelo menos uma amostra das descobertas da IA deve ser revisada e aprovada por um humano qualificado antes de entrar no registro de remediação). Estruture seu pipeline para satisfazer todos os três e você não terá problemas com os auditores.

8. O Que Implementar no 1º Trimestre de 2026: Um Roteiro Prático

Se você está lendo isso no início de 2026 e decidindo por onde começar, aqui está o roteiro priorizado que dou a novos clientes. Ele é projetado para entregar uma redução de risco mensurável em 30 dias sem interromper os processos de GRC existentes.

Semana 1: Linha de Base e Ganhos Rápidos

• Execute a transação SUIM para extrair todos os usuários com autorizações base críticas (S_TCODE para FK01/FK02/F110/FB60/ME21N/ME29N). Este é o seu universo inicial de alto risco.
• Audite controles mitigadores expirados no GRC. Filtre o monitor de mitigação do GRC Access Control para controles com datas de expiração nos últimos 12 meses. Sinalize e escale cada mitigação expirada onde o risco subjacente ainda está presente.
• Identifique IDs de "firefighter" com acesso permanente em vez de acesso limitado por tempo. Qualquer ID de "firefighter" que esteve ativo por mais de 72 horas sem um ticket fechado deve ser tratado como uma descoberta crítica.
• Exporte AGR_USERS para CSV e pivote por usuário para encontrar indivíduos com mais de 25 atribuições de função. Esta é uma heurística forte para risco de privilégio acumulado.

Semana 2: Implementar o Pipeline de Extração

• Configure o usuário técnico RFC com as autorizações mínimas exigidas (somente leitura, exibição de tabela, sem acesso de diálogo).
• Implante os scripts de extração Python em um bastion host seguro dentro da zona de rede SAP.
• Execute uma extração completa e valide a completude dos dados em relação às contagens de funções conhecidas na SUIM.