Segurança — studyAI

Requisitos e medidas de segurança: auth, rate limiting, proteção de dados e boas práticas.

---

Índice

1. Autenticação
2. Autorização
3. Rate limiting
4. Proteção de dados
5. API e inputs
6. Logs e auditoria
7. Checklist

---

Diagrama: Auth flow

A carregar diagrama…

---

Autenticação

JWT

• Access token: 15 min. Guardado no frontend (memória ou httpOnly cookie).
• Refresh token: 7 dias. Guardado em DB ou Redis. Hash antes de guardar.
• Algoritmo: HS256 ou RS256.
• Claims: sub (user_id), exp, iat, type (access|refresh).

Password

• Hash: bcrypt ou argon2. Salt automático.
• Requisitos: Mínimo 8 chars, 1 maiúscula, 1 número, 1 especial (validar no registo).
• Reset: Token único, expira em 1h. Enviar por email (futuro).

HTTPS

• Obrigatório em produção. Redirect HTTP → HTTPS.
• HSTS header.

---

Autorização

Diagrama: Multi-tenant e isolamento

A carregar diagrama…

Regras: Todas as pesquisas vetoriais exigem project_id. Validação de ownership antes de retrieval/index/delete.

---

Regras

1. Projetos: User só acede aos seus projetos (project.user_id = current_user.id).
2. Ficheiros/Documentos: Pertencem ao projeto; herdam permissão do projeto.
3. User progress: User só vê o seu progresso.

Implementação

• Middleware ou dependency que extrai user_id do JWT.
• Em cada endpoint de projeto: verificar project.user_id == current_user.id.
• 403 se não autorizado.

Exemplo (FastAPI)

async def get_project(project_id: UUID, user: User = Depends(get_current_user)):
    project = await db.get_project(project_id)
    if not project or project.user_id != user.id:
        raise HTTPException(403, "Forbidden")
    return project

---

Rate limiting

Objetivo

• Proteger a API de abuso.
• Controlar custos (chamadas LLM são caras).
• Garantir fair use entre utilizadores.

Estratégia

Implementação

• Redis: Sliding window ou fixed window. Key: ratelimit:{user_id}:{endpoint}.
• Resposta 429: Retry-After header.
• Por plano: Utilizadores premium podem ter limites maiores (futuro).

---

Proteção de dados

Em trânsito

• HTTPS em tudo.
• Tokens nunca em query params (apenas header ou cookie).

Em repouso

• Passwords: Hash, nunca plain text.
• Tokens: Refresh token em hash.
• Ficheiros: Storage com encryption at rest (S3/ R2 default).
• DB: Encryption at rest (PostgreSQL, cloud providers).

PII

• Email: Necessário para auth. Não expor em logs.
• Nome: Opcional. Tratar como PII.
• Conteúdo dos ficheiros: Dados do utilizador. Não usar para treino; não partilhar entre users.

LGPD/GDPR (futuro)

• Política de privacidade.
• Direito ao esquecimento (apagar conta + dados).
• Export de dados.
• Consent para cookies/analytics.

---

API e inputs

Validação

• Pydantic: Validar todos os inputs. Rejeitar malformados.
• Tamanhos: Limitar tamanho de mensagens (ex: 10k chars), ficheiros (ex: 50MB).
• Tipos de ficheiro: Whitelist (PDF, TXT, MD). Rejeitar executáveis, etc.

Prompt injection

• RAG: Chunks do user podem conter texto malicioso. Instruir LLM a ignorar instruções nos chunks.
• Chat: User pode tentar "Ignore previous instructions". Prompt com system message claro: "Responde apenas sobre o material do projeto."
• Avaliação: Não confiar cegamente em output do LLM para decisões críticas.

CORS

• Restringir origens em produção. Ex: https://app.studyai.example.
• Dev: localhost:3000.

---

Logs e auditoria

O que logar

• Auth: Login (sucesso/falha), registo. Sem passwords.
• Ações sensíveis: Criação de projeto, upload, delete.
• Erros: Stack trace em dev; mensagem genérica em prod.
• Rate limit: Quando 429 é devolvido.

O que não logar

• Passwords, tokens.
• Conteúdo completo de mensagens (opcional: só IDs e timestamps).
• PII em plain text.

Formato

• Estruturado (JSON). Campos: timestamp, level, message, user_id, request_id, extra.

---

Multi-tenant / Isolamento

Regras obrigatórias

1. Filtro project_id em todas as pesquisas vetoriais

   • Retrieval: WHERE project_id = :project_id (obrigatório)
   • Nunca fazer similarity search sem filtro de projeto

2. Validação de ownership antes de qualquer operação

   • GET/POST/PUT/DELETE em projects, files, documents: project.user_id == current_user.id
   • Retrieval, index, delete: verificar que resource pertence ao projeto do user

3. Estratégia contra leakage cross-project

   • Nunca devolver chunks de outro projeto
   • Logs: não incluir conteúdo de outros users
   • Testes: criar 2 projetos, user A não deve ver dados de projeto de user B

Testes específicos

• User A cria projeto, faz upload. User B não vê ficheiros de A.
• Query em projeto A não devolve chunks de projeto B.
• DELETE project remove apenas chunks desse projeto.

---

Checklist