Bloco Segurança

Linguagem de intenção de negócio

O bloco Seguranca usa linguagem de intenção de negócio, não linguagem técnica. O arquiteto descreve quem pode acessar o quê e quais dados precisam de proteção — sem precisar saber o nome de nenhuma técnica de segurança.

A IA traduz essas intenções em implementações concretas: se você diz "login deve ser protegido contra tentativas automáticas", a IA implementa rate limiting. Se você diz "dados pessoais devem seguir LGPD", a IA aplica as práticas adequadas. O arquiteto decide a política; o agente decide o mecanismo.

Seguranca {
  acesso: usuários precisam criar conta com email e senha
  - Login deve ser protegido contra tentativas automáticas de senha
  - Cadastro deve ser protegido contra criação em massa de contas
  - Senhas devem ser armazenadas com hash seguro — nunca em texto puro
  - Sessões expiram após 24 horas de inatividade
}

Campo acesso

O campo acesso descreve como os usuários se autenticam no sistema. É um campo de texto livre — descreva com as palavras do negócio:

Exemplos de campo acesso

// Sistema com login simples
acesso: usuários criados pelo admin — sem cadastro público

// Sistema com diferentes perfis
acesso: clientes se cadastram livremente; médicos são cadastrados pelo admin

// Sistema com SSO
acesso: login via conta Google — sem cadastro de senha própria

// Sistema B2B
acesso: acesso por tenant — cada empresa tem seus usuários gerenciados pelo admin da empresa

Instruções livres de proteção

Use instruções livres com hífen para descrever o que precisa ser protegido. A IA interpreta cada instrução e decide a implementação técnica mais adequada:

Seguranca {
  acesso: contas com apelido e senha — sem email no cadastro público
  - Login deve ser protegido contra tentativas automáticas de senha
  - Cadastro deve ser protegido contra criação em massa de contas
  - Upload de arquivos deve validar tipo e tamanho antes de aceitar
  - Dados de pagamento nunca devem ser armazenados no banco próprio
  - Logs não devem conter senhas, tokens ou dados de cartão
  /// O sistema processa dados de saúde — aplicar LGPD com ênfase em
  /// dados sensíveis conforme Art. 11 da Lei 13.709/2018
}

Sub-bloco Middleware

O sub-bloco Middleware dentro de Seguranca declara interceptadores de pipeline — componentes que verificam todas as requisições antes de chegar nos handlers:

Seguranca {
  acesso: usuários autenticados via JWT

  Middleware IpValidation {
    aplicacao: endpoints-autenticados
    - Rejeitar se IP atual difere do IP registrado no JWT
    - Retornar 401 com mensagem de sessão inválida
    /// Proteção contra roubo de token — IP muda quando o token é usado em outro dispositivo
  }

  Middleware RequestLogger {
    aplicacao: todos-os-endpoints
    - Registrar método, rota, status e tempo de resposta
    - Não registrar body de requisições com dados sensíveis
  }
}

Valor de `aplicacao`	Escopo
`todos-os-endpoints`	Aplica em todas as rotas da API
`endpoints-autenticados`	Aplica apenas em rotas que exigem autenticação
Texto livre	O arquiteto descreve o escopo com suas próprias palavras

Segurança por módulo

O bloco Seguranca pode aparecer em módulos diferentes para especificar políticas específicas de cada domínio. O compilador consolida todas as declarações de Seguranca no arquivo de saída:

modulo-financeiro.spell

Seguranca {
  /// Módulo financeiro — regras mais rígidas de acesso
  - Transações acima de R$ 10.000 exigem segundo fator de autenticação
  - Relatórios financeiros acessíveis apenas por perfis financeiro e admin
  - Toda operação financeira gera evento de auditoria imutável
  - Exportações de dados financeiros ficam disponíveis por no máximo 1 hora
}