Auditoria RBAC de Marketplace

Visão Geral

Audite a autorização em marketplaces onde clientes, fornecedores, equipe de logística, entregadores, agentes de suporte, administradores e contas de serviço agem em pedidos e recursos compartilhados. Crie uma matriz de políticas explícita, rastreie a aplicação desde a rota até o acesso aos dados e verifique comportamentos permitidos e negados sem tratar controles de UI ocultos como segurança.

Por padrão, esta é uma revisão somente leitura. Ela não concede permissão para escanear um serviço ativo, criar contas de teste, alterar permissões ou acessar dados de outra pessoa.

Quando Usar Esta Habilidade

• Revisar a autorização em um marketplace, plataforma de entrega, loja multiven-dor ou sistema de logística.
• Adicionar ou alterar funções, poderes administrativos, regras de propriedade ou transições de estado de pedido.
• Investigar se um cliente, fornecedor, entregador, hub ou locatário pode acessar recursos de outra parte.
• Preparar testes de autorização negativos antes do lançamento ou após um incidente de controle de acesso.

Não use esta habilidade apenas para design de autenticação, arquitetura genérica multilocatário, enumeração de ID ofensiva ou testes de penetração fora de um ambiente de teste explicitamente autorizado.

Estabelecer o Contrato de Autorização

Registre os atores e recursos reais em vez de assumir nomes de função padrão.

Para cada ator, capture:

• fonte de identidade e autoridade de atribuição de função;
• locatário, organização, loja, hub, região ou escopo de atribuição;
• relacionamentos de recursos como proprietário, vendedor, entregador atribuído, hub de serviço ou caso de suporte;
• operações permitidas e transições de estado;
• acesso de emergência, suporte, delegado e conta de serviço;
• requisitos de log de auditoria e aprovação para ações privilegiadas.

Separe estas dimensões de política:

1. Função — o que este tipo de ator pode fazer em geral.
2. Relacionamento — a qual objeto específico o ator pode acessar.
3. Locatário ou escopo operacional — onde a permissão se aplica.
4. Estado do recurso — se a operação é válida agora.
5. Escopo de campo — quais atributos podem ser visualizados ou alterados.

Uma função correspondente não é suficiente quando as regras de propriedade, atribuição, locatário, estado ou campo falham.

Construir a Matriz de Políticas

Crie uma linha para cada combinação significativa de ator-recurso-operação.

Marque uma decisão não documentada como UNDEFINED; não invente uma permissão apenas porque o código atual a permite.

Fluxo de Trabalho de Auditoria

1. Inventariar Pontos de Entrada

Mapeie rotas HTTP, operações GraphQL, ações de servidor, trabalhos em segundo plano, webhooks, downloads de arquivos, exportações, ferramentas administrativas e consumidores de fila que acessam recursos do marketplace. Inclua operações em massa e métodos HTTP alternativos.

2. Rastrear Identidade e Escopo

Para cada ponto de entrada, rastreie como o principal autenticado se torna um contexto de autorização. Confirme que as reivindicações de função, locatário, loja, hub, atribuição e delegação vêm de uma fonte confiável do lado do servidor e são atuais o suficiente para a operação.

Não aceite campos de ator, locatário, proprietário, fornecedor, hub, entregador, preço, pagamento ou privilégio da solicitação apenas porque eles estão presentes em uma sessão logada.

3. Rastrear Autorização de Objeto

Siga o identificador do recurso da solicitação até o acesso aos dados. Prefira uma consulta com escopo ou mutação atômica que inclua todos os predicados necessários:

ID do recurso
+ escopo de locatário/loja/hub
+ relacionamento proprietário/vendedor/atribuído
+ estado atual permitido
= objeto autorizado ou nenhuma correspondência

Uma sequência separada de "verificar e depois atualizar" pode competir com a reatribuição ou mudanças de estado. Registre onde uma transação, atualização condicional, bloqueio em nível de linha ou controle de consistência equivalente é necessário.

4. Verificar Autorização em Nível de Campo

…