Segmentação de privilégios

1) Por que precisa de segmentação

A segmentação de privilégios é a chave para reduzir os erros «blast radius» e os abusos privilegiados. Ela permite limitar exatamente quem e onde pode realizar quais ações com quais dados, ao mesmo tempo que mantém a velocidade das operações e a conformidade com os reguladores.

• menos incidentes por «mais direitos»;
• aceleração das investigações: acessíveis transparentes e explicáveis;
• conformidade com SoD/complacência comprovada pela auditoria;
• experiências seguras e lançamentos rápidos sem risco para o núcleo de prod.

2) Princípios

Zero Trust: cada ação é testada contextualmente; não há «zonas de confiança».
Least Privilege: direitos mínimos concedidos por um período mínimo (o ideal é JIT).
Context over Role: Os direitos não dependem apenas do papel, mas também de atributos (tenante, região, ambiente, risco).
Segregation of Duties (SoD): Compartilhamos iniciação, aprovação, execução e auditoria.
Policy-as-Code: Políticas em código com versionagem, testes e revezamento.

3) Modelo de maturidade de acesso

1. RBAC (roles): início - papéis fixos (Apoio, Risk, Payments, Trading, Ops, SRE, Compliance).
2. ABAC (atributes): Adicionamos atributos: tenente, região, jurisdição, produto, canal, ambiente (prod/estágio/dave), tempo, classe de risco, sinais KRI.
3. PBAC (policy-based): políticas centralizadas de «quem/o/o/o/o/porquê» + condições (por exemplo, «em venda - apenas por JIT e tíquete»).

4) Domínios de segmentação (eixo após eixo)

4. 1 Tenante/cliente

O acesso e as operações são limitados por uma marca/operadora/afiliada específica.
Ações cruzadas-tenentes são proibidas, exceto agregações estritamente definidas sem PII.

4. 2 Região/jurisdição

Os políticos consideram as regras locais de licenciamento e KYC/AML.
As operações de dados do jogador são limitadas pela geografia de armazenamento e processamento.

4. 3 Ambiente (dave/estágio/prod)

O Prod está isolado: credenciais individuais, redes, Basion/PAM, «read-only padrão».
Acesso ao prod apenas JIT, com tíquetes e janelas de alteração.

4. 4 Classe de dados

PII/finanças/telemetria de jogo/tecnologia - diferentes níveis de acesso e disfarce.
Exportar PII - somente através de workflow com criptografia e TTL aprovados.

4. 5 Criticidade de operações

Classes P1/P2/P3: publicação de coeficientes, notas manuais, conclusões, mudança de routing PSP - exigem controle dual.
As operações de baixo risco podem ser feitas de forma automática.

5) Níveis de privilégio (tiers)

Viewer: apenas leitura de unidades e dados mascarados.
Operator: execute os procedimentos dos ranbooks sem alterar as configurações.
Contributor: altera configurações em domínios não críticos.
Approver: aprovação de pedidos e operações high-risk (não combinado com execução - SoD).
Admin (JIT): aumento de curto prazo para tarefas raras sob controle dual e gravação de sessão.

6) Papéis SoD e incompatíveis

• Iniciar conclusões ≠ aprovar ≠ realizar finalmente.
• Criar campanha de bónus ≠ ativar na venda ≠ alterar limites.
• Desenvolver o Fichch ≠ apertar o lançamento ≠ alugar para fora.
• Pedir carregamento de PII ≠ aprovar ≠ decifrar.

Cada casal tem uma política de exclusão e exclusão formalizada com data de revisão.

7) Acesso JIT e PAM

Elevation a pedido: especifica o alvo/tíquete/prazo; após o vencimento, uma crítica automática.
Controle dual: P1/P2 - dois approwers de funções diferentes.
Sessão de controle: gravação de sessões críticas, alertas de anomalias, proibição de copipaço no uso do PII.
Break-glass: acesso de emergência com limites rígidos e pós-áudio obrigatório.

8) Contas de serviço e APIs

Guindastes mínimos; Divisão por tarefas/microsserviços; tokens/certificados de curta duração.
Rotação de segredos, proibição de segredos shared; a proibição de «god-scope».
Limites para rate/cotas, chaves idempotency, assinatura de webhooks (HMAC).

9) Segmentação ao nível da infraestrutura

Redes: isolamento de segmentos (per-domain/per-tenant), exclusão de egress padrão, mTLS.
Kubernetes/Cloud: Neymspace/projetos per-ambiente e domínio, Gatekeeper/OPA para banir modelos perigosos.
BD/Cash: corretor de acesso (DB proxy/IAM), read-only padrão, proibição de DDL fora da janela.
Armazéns: diferentes chaves/baquetes per-classe de dados com políticas TTL e WORM para auditoria.

10) Políticas como código (PaC)

Políticas em repositórios (Rego/YAML), revezamento PR, testes automáticos (unit/e2e), auditoria diff.
Contexto dinâmico: hora do dia, localização, nível de KRI, risco-mapeamento da operação.
Explicabilidade da solução allow/deny e referência à política na auditoria.

11) Revistas e auditorias

Abrangência: quem/onde/quando/porquê, antes/pós-valores, ID do tíquete.
Inadequado: coleta centralizada, WORM/imutável, assinatura de registros.
Conectividade: Cadeia do console de adin API BD e provedores externos.
Auditoria SLA: velocidade de resposta a pedidos de controle/regulador.

12) Dashboards e métricas (KPI/KRI)

Acesso KPI: JIT vs direitos permanentes, média de privilégio,% de SoD cobertos, tempo de processamento de pedidos, cobertura de ressalvas.
KRI abuso: picos de operações sensíveis, descarga em massa, localização/relógio atípico, sequências de «zayavka→deystviye→otkat».
Exec-dashboard: faixa de status de alto risco, eventos break-glass, tendências.

13) Exemplos de políticas (esboços)

Prod-операции: `allow if role in {Operator, Admin} AND env=prod AND jit=true AND ticket!=null AND sod_ok AND time in ChangeWindow`.
Экспорт PII: `allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2`.
PSP-роутинг: `allow if action=UpdateRouting AND dual_control AND risk_assessment_passed AND rollback_plan_attached`.

14) Mapa de trânsito de implementação (8-12 semanas)

Ned. 1-2: inventário de operações/papéis/dados, matriz de SoD, classificação de dados e domínios de segmentação.
Ned. 3-4: Base RBAC, catálogo de papéis, JIT para consoles de prod, PaC inicial (OPA/Gatekeeper).
Ned. 5-6: ABAC: atributos tenante/região/ambiente/classe de dados; separação de neimspace/projetos.
Ned. 7-8: PAM (JIT-elevation, gravação de sessões, break-glass), proibição de DDL e corretor de BD, política de exportação de PII.
Ned. 9-10: PBAC para operações de alto risco (conclusões, bónus, PSP), controle dual, alertas KRI.
Ned. 11-12: Ressalvas trimestrais, 100% de alta-risk operações de PaC, relatórios e treinamento.

15) Artefactos

Role Catalog: papéis, privilégios mínimos, proprietários.
SoD Matrix: funções/operações incompatíveis, exceções, processo override.
Policy Pack: um conjunto de políticas PaC com testes e exemplos deny/allow.
Access Request Forma: alvo, data limite, objeto (tenante/região/ambiente), risco-avaliação, apruveres.
O Sensive Ops Register é uma lista de ações P1/P2, janelas, critérios dual controle.
Auditório Playbook: Coletar e fornecer registros, SLA resposta, rol.

16) Antipattern

Permissões e aulas gerais.
Acessibilidade cruzada por conveniência.
Não há isolamento prod/estágio/dave.
Políticas em papel sem enforce em código/consoles.
Exportar PII por acordo manual sem criptografia e TTL.
Nenhuma ressalva e direitos «dependentes».

17) Resultado

Segmentar privilégios não é apenas «papéis certos». Isto é isolamento multidimensional (tenante, região, ambiente, dados, criticidade) + contexto dinâmico (ABAC/PBAC) + processos (SoD, JIT, ressalvas) + forçação técnica (PaC, PAM, rede/BD). Este padrão reduz drasticamente o risco de erros e abusos, acelera mudanças seguras e torna a plataforma resistente às exigências de escala e reguladores.