Controle de acesso e RBAC na API

1) Por que controlar o acesso à API

A permissão é uma resposta à pergunta "será que este ator pode executar essa ação neste recurso agora? ». Os erros resultam em fugas BOLA/IDOR, aumento de direitos e violação dos reguladores. O objectivo é construir um modelo em vários níveis, um perímetro de serviço regras de negócios, com políticas e verificações explícitas a nível de objeto.

2) Modelos de autorização: quando escolher

RBAC (Role-Based Access Control) - funções → resolução. Simples, estável, mas propensa a explodir papéis.
ABAC é uma solução para atributos de sujeito/objeto/contexto (país, nível KYC, dono do recurso, risco).
ReBAC (Relationship-Based) é um gráfico de relacionamento (proprietário, membro da equipe, «gerente de projetos»); resolve hierarquias complexas.
Scopes (OAuth) - Contrato entre o cliente e o servidor de recursos sobre «área de acesso» (por exemplo, 'payments: write').
Prática: RBAC para matriz básica, ABAC para contextos e limitações para hierarquias complexas (pastas, organizações, limites e podaccaunts).

3) Taxonomia de recursos e ações

Hierarquia: 'org project' wallet direction '. Herança de cima para baixo com possíveis «limitadores».
Ações: CRUD + domain-específicas («approve», «refund», «massle»).
Propriedades de recursos: proprietário, região, status, marcas de risco (AML/KYC), limites.
Multiplicidade: Todas as soluções contêm 'tenant _ id'; a proibição de solicitações cruzadas por omissão (deny-by-default).

4) Arquitetura: onde a decisão é tomada

PEP (Policy Enforcement Point) - Local de verificação: gateway/API, sidecar mash, serviço próprio.
O PDP (Policy Decision Point) é um motor de políticas centralizado (serviço OPA, motor Cedar) ou uma biblioteca integrada.
PIP - Fontes de atributos: diretório de usuários/papéis, perfil de tenente, CUS/risco, cartão de posse de recursos.
IP - Gerenciamento de versões de políticas, publicação, auditoria.

Recomendação: PDP centralizado + armazenamento local de soluções PEP; verificações complexas de objeto no serviço com invariantes de domínio.

5) Tokens, marcas e identidade

OIDC/OAuth2: 'sub' (ID do sujeito), 'aud' (serviço de destino), 'scope '/' roles', 'tenant', 'kyc _ level', 'risk _ tier'.
JWT: RS/ES-assinatura, curta 'exp', translado por refresh. Não coloque PII; use 'jti' para retirar/faixa de auditoria.
mTLS/HMAC: serviço-a-serviço e parceiros; as marcas são puxadas do diretório por 'cliente _ id'.
Device/Context: IP/ASN, geo, hora do dia - entrada na solução ABAC (por exemplo, proibição de write fora do horário de trabalho).

6) Autorizações de nível de objeto (BOLA-first)

Cada operação deve responder a «o sujeito é dono/tem direito a este 'resource _ id'?».

Verificação de propriedade: 'resource. owner_id == subject. id ou pertencimento a 'org' com o papel.
Filtrar amostras: Sempre insira 'WHERE resource. tenant_id =:tenant AND...` (row-level security).
Para operações de referência (ID no caminho/corpo) - Normalize e valide até a lógica do negócio.

7) Projetar RBAC: papéis, permissões, conjuntos

Permissões - direitos atômicos: 'wallet. read`, `wallet. write`, `payment. refund`.
Os papéis são conjuntos de permissões nomeados como 'admin', 'suporte. read`, `cashier`, `fraud. analyst`.
Scopes é um contrato externo para clientes (mapping scope→permissions).

• papéis básicos + «suplementos» (permision packs),
• restrições ABAC (país/região/tenante),
• «Aumentos temporários» (hora de validade).

8) ABAS/limitações contextuais

Geo/jurisdição: proibição de write de países proibidos (sanções/regulação).
Hora/risco: 'risk _ score <threshold' para grandes operações.
CUS/limites: 'kyc _ level> = 2' para conclusões> X; controle de «esfriamento» entre transações.
Dispositivos de confiança: exija mTLS para parceiros em rotas perigosas.

9) ReBAC e conde de direitos

Útil para complexas estruturas de negócios (grupos, equipes, marcas, filiais).

Relações: 'member', 'admin', 'owner', 'viewer'.
As permissões derivadas de 'viewer' do recurso são herdadas do projeto 'member' que pertence a 'org'.
Armazém de gráficos: BD com matriz de relacionamento, serviço especializado (no espírito Zanzibar-abordagem). Confira as respostas 'check (subject, relation, object)'.

10) Soluções em dinheiro e desempenho

A chave do PDP no nível PEP (por exemplo, na entrada) é "sub 'tenant' resource 'action' policy _ version '.
TTL curto (segundos a minutos) + deficiência por evento: alteração de papéis/relacionamentos/tenante.
Verificações batch (bulk athz) para listas: reduzem charjás PDP.
Mede latency soluções; em degradação - graceful-degradation apenas para read (nunca para write/dinheiro).

11) Exemplos de políticas

11. 1 marca JWT → PEP bruto (pseudo-gateway)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 Restrição de jurisdição (política deny-list)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 Política de ReBAC (pseudo)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) Gerenciamento de políticas e versões

Versionagem de políticas ('policy _ version') e canário para alterações perigosas.
«Raios secos» (dry-run/shadow decisions) é um logem 'allow/deny' sem impacto.
Catálogo de políticas e migrações: quem, quando e porquê mudou; Comparar com incidentes.
Testes de cenários negativos (maletas proibidas) são obrigatórios em CI.

13) Observação e auditoria

Logs de soluções: 'trace _ id', 'subject', 'tenant', 'action', 'resource', 'result',' policy _ version ', motivo da falha.
Métricas: 'autz _ decision _ latency', 'autz _ denied _ total\action a.', proporção de tentativas de BOLA, dinheiro-hit-rate.
Dashboards: alta rejeição de acções/tenentes, tendências após o lançamento de políticas.

14) Segurança e sustentabilidade

Deny-by-default: falta de autorização explícita = proibição.
Fail-closed: se PDP não estiver disponível, write crítico → a proibição (ou a degradação para o «conjunto mínimo» de papéis estritamente testados).
Verificações de guard locais dentro de serviços para invariantes críticos (por exemplo, 'tenant '/' owner').
Minimizar as marcas no JWT; atributos sensíveis de substituir através do PIP através de um canal seguro.

15) Especificidades do iGaming/Finanças

Os papéis são 'cashier', 'kyc. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
Restrições: transações de pagamento dependem de 'kyc _ level', limites de pagamento responsável, status AML/sanções.
Os registros de bloqueio são 'org/brand/device/payment _ montar' - filtros ABAC em write.
Os registros de auditoria são imutáveis para as ações KYC/AML/conclusões; armazenamento de acordo com o prazo regulatório.
API associado: mTLS + «scopes» contratados sobre rotas, filtros geo/ASN no perímetro.

16) Testes e verificação

Matriz Negativa: Lista as malas «proibidas» explícitas e fixe os testes.
Permissões de Fuzz: trocar 'tenant _ id', 'owner _ id', contornar filtros de paginação/triagem.
Teste Load PDP: Verifique a latência e o comportamento do disco no p95/p99.
Lançamento de políticas dry-run + canary + serviço automático com o deny/allow esperado.
Os incidentes são uma réplica de pedidos no estande com uma versão precisa das políticas.

17) Antipattern

Basear-se apenas em 'scope' sem verificação de objeto (BOLA).
Misturar lógica de negócios e verificação de direitos em cada handler sem um modelo centralizado.
Hardcoder papéis na UI e confiar em soluções de clientes.
Não há filtros 'tenant '/' owner' nas solicitações de BD (leaky reads).
Não há deficiência de solução em dinheiro quando você muda de papel/relacionamento.
JWT longa vida sem reversão/rotatividade.

18) Folha de cheque pró-prontidão

• São definidos recursos/ações, hierarquias e multiplicidade.
• Matriz RBAC básica + limitadores ABAC para ReBAC.
• PDP/PEP foram projetados; Há um dinheiro local de soluções e deficiência.
• As políticas são versionizadas, testes de cenários negativos em CI.
• Verificações BOLA em cada write/read para um 'resource _ id' específico.
• JWT com marcas mínimas, curta 'exp'; auditoria/levantamento por 'jti'.
• Métricas/logs de soluções, dashboards, alertas por deny/latency.
• Fail-closed para write crítico; o modo fallback está documentado.
• Documentação para clientes: 'scopes', códigos de erro (401/403/404/409), exemplos.

19) TL; DR

Construa a permissão de BOLA-first: central PDP + dinheiro de soluções, RBAC como base, ABAC para contexto, ReBAC para relacionamentos. Todas as solicitações estão no contexto de «tenant» e «resource _ id» específico; deny-by-default, JWT curtos, filtros de objeto no banco de dados. Versionize e teste políticas, mede latency/deny, e os incidentes reproduzam uma réplica. Para iGaming, papéis individuais (KYC/AML/caixa), limitadores ABAC rígidos e auditoria imutável.