Log de Riscos Aceitos — Plataforma OLP

Findings de scanner que NÃO serão remediados tecnicamente por decisão de produto/jurídico/negócio. Cada item exige reavaliação periódica.

Não confunda com SILENT_DATA_LOSS_AUDIT.md (bugs silenciosos) nem RLS_POLICIES.md §Pendências (remediação programada).

---

RA-001 — Vínculo cross-escola de responsável via portal

Campo	Valor
Finding origem	inscricoes_portal_responsavel_scope (supabase_lov, level: error)
Tabela	aluno_responsaveis (INSERT via portal_responsavel_auto_vincular)
Aceito em	2026-05-08
Reavaliação	Após retorno do alinhamento jurídico LGPD (em andamento)
Owner	Produto + Jurídico

Risco descrito pelo scanner

Sem WITH CHECK validando escola_id do aluno contra o JWT do responsável, um responsável autenticado pode se vincular a aluno de qualquer escola se conhecer matrícula + data de nascimento.

Por que é aceito hoje (decisão de produto)

É feature real, não bug. Um responsável pode legitimamente ter filhos em escolas diferentes, e o portal hoje opera com identidade global de responsável (vide architecture/identidade-global-responsavel). A informação necessária (matrícula + DN) é considerada conhecimento privilegiado do responsável real.

Mitigações em vigor (não remover sem substituir)

• Rate limit em portal-responsavel-auto-vincular (escola + IP, via portal_check_guards).
• OTP exigido para login portal.
• Lockouts incrementais em portal_login_tentativas.
• Leitura subsequente do responsável passa por get_alunos_responsavel() / responsavel_vinculado_aluno() — escopo é por responsavel_id, não por escola_id. A feature não vaza dados de outros alunos da mesma escola.
• Mural por escola usa get_mural_publicacoes_responsavel_global() que já valida vínculo aluno_responsaveis antes de retornar.

Gatilhos para reabrir

• Decisão jurídica de exigir prova adicional de parentesco (ex.: documento, autorização da escola).
• Incidente de enumeração massiva detectado em portal_login_tentativas ou portal_rate_metrics.
• Mudança de modelo: cada escola passar a gerenciar a lista de responsáveis (vínculo deixaria de ser auto-serviço).

Backlog técnico (quando reabrir)

• Adicionar WITH CHECK em aluno_responsaveis exigindo que aluno_id pertença a alguma escola onde o responsável já tenha vínculo prévio aprovado, OU
• Criar fluxo de aprovação assíncrono (responsável solicita, gestor escola confirma).
• Reduzir teto diário de novos vínculos por responsavel_id (ex.: 5/dia) como guard de enumeração.

---

Convenções

• Toda entrada precisa: ID RA-NNN, finding origem, data de aceite, owner, reavaliação.
• Marcar finding correspondente como ignore no scanner com reason referenciando o ID desta tabela.
• Atualizar memory mem://security/<feature>-accepted-risk para o agente não tentar "corrigir" automaticamente.