Segurança e proteção de dados
Dados de crianças pedem mais do que promessas. Esta página descreve os mecanismos que existem hoje na KidsNoted — verificáveis no produto e na documentação técnica — em vez de garantias absolutas.
Isolamento por instituição
- Cada pedido é resolvido no servidor com o contexto da instituição autenticada antes de qualquer leitura ou escrita.
- O modelo de dados usa chaves compostas por instituição: um registo não pode referenciar dados de outra instituição ao nível da base de dados.
- Testes automáticos de contenção acompanham o código e verificam que consultas e escritas ficam confinadas à instituição.
Cifra e credenciais
- Palavras-passe guardadas como hash scrypt com salt individual — nunca em texto reversível.
- Categorias sensíveis — saúde, fotografias e arquivo anual — cifradas em repouso com AES-256-GCM ao nível da aplicação, com rotação de chaves suportada.
- Sessões assinadas; em produção, os cookies são HttpOnly, SameSite e Secure e o acesso faz-se por HTTPS.
Auditoria de ações sensíveis
- Operações financeiras, de privacidade, de identidade e de aceitação legal ficam num registo de auditoria aplicacional.
- O registo guarda apenas referências pseudónimas (HMAC, com chave separada) de IP e user-agent — não os valores em bruto.
- Cada tipo de evento tem um catálogo fechado de campos: o registo não aceita detalhes fora do contrato definido.
Direitos RGPD com fluxo próprio
- Exportação, retificação, restrição e eliminação de dados passam por fluxos autenticados dentro do produto — não por emails perdidos.
- Nos dados escolares, a instituição é a responsável pelo tratamento; a KidsNoted atua como subcontratante segundo o DPA e instruções documentadas.
- Não existe analytics de terceiros; o processamento externo de documentos é opcional, desligado por omissão e minimizado.
Backups e recuperação
- Política escrita com objetivos de recuperação (RPO, RTO e janela de PITR) e procedimento de restauro documentado passo a passo.
- Os campos cifrados ao nível da aplicação permanecem cifrados nos backups.
- O lançamento comercial só avança depois de um ensaio de restauro registado dentro dos objetivos definidos.
Releases verificadas
- O build de produção não corre migrações nem seeds; as migrações passam por um workflow com aprovação humana obrigatória.
- Cada deployment é ligado por attestation ao commit exato e à base de dados validada; a promoção exige nova aprovação após os smoke tests.
- Os testes de segurança do repositório cobrem isolamento de dados, privacidade e o contrato da base de dados.
Subcontratantes e documentos
A lista de fornecedores, as regiões de tratamento e as condições de transferência constam da Política de Privacidade. O regime de subcontratantes ulteriores, os deveres do artigo 28.º do RGPD e o direito de auditoria constam do acordo de tratamento de dados. Nenhum fornecedor é ativado sem registo e avaliação prévios.
O que esta página não diz
Segurança não é um estado final e não usamos garantias absolutas, porque nenhum sistema as pode demonstrar. Quando um mecanismo ainda depende de validação — como o ensaio de restauro de backups — dizemo-lo aqui e nos documentos técnicos. Questões de segurança ou privacidade seguem pelo contacto publicado na Política de Privacidade.