LGPD
O Neemias foi projetado com proteção de dados desde a arquitetura. Abaixo, o alinhamento com os princípios da LGPD.
Classificação de Dados Pessoais
| Campo | Tipo de dado | Classificação LGPD | Finalidade | Retenção |
|---|---|---|---|---|
displayName | Nome completo | Dado pessoal | Identificação do aluno | Enquanto o aluno estiver ativo |
photoRef | Foto | Dado pessoal sensível (biométrico) | Identificação visual | Enquanto o aluno estiver ativo |
guardianName / guardianNameAlt | Nome do responsável | Dado pessoal | Contato de emergência | Enquanto o aluno estiver ativo |
birthDate | Data de nascimento | Dado pessoal | Cálculo de idade para alocação em turma | Enquanto o aluno estiver ativo |
phones[].number | Telefone | Dado pessoal | Contato de emergência | Enquanto o aluno estiver ativo |
address.* (7 campos) | Endereço residencial | Dado pessoal | Cadastro e emergência | Enquanto o aluno estiver ativo |
allergies | Alergias | Dado pessoal sensível (saúde) | Segurança da criança | Enquanto o aluno estiver ativo |
specialNeeds | Necessidades especiais | Dado pessoal sensível (saúde) | Acomodação pastoral | Enquanto o aluno estiver ativo |
imageConsent | Consentimento LGPD | Dado pessoal sensível | Autorização de uso de imagem | Permanente (auditoria) |
Campos não-PII: studentId, classId, status, nucleus*, familyMembershipStatus, timestamps.
Autorização de Uso de Imagem e Voz
Desde junho/2026, o app oferece suporte nativo ao Termo de Autorização de Uso de Imagem, Voz e Dados de Menor, em conformidade com:
- LGPD (Lei 13.709/2018): base legal de consentimento do responsável (Art. 7º, I c/c Art. 14, §1º)
- ECA Digital (Lei 15.211/2025): compromissos de proteção em plataformas digitais
Fluxo de cadastro
- Admin/Cadastro abre o formulário de adição de aluno
- Seção "Autorização de Uso de Imagem (LGPD)" exibe:
- Checkbox de autorização
- Campos de CPF e RG do responsável
- Nome e CPF de duas testemunhas
- Upload do termo assinado (PDF ou foto)
- Ao salvar, um registro
imageConsenté criado na tabelaimageConsentsno IndexedDB com statusACTIVE - O ID do consentimento é vinculado ao registro do aluno (
student.imageConsentId)
Revogação
O responsável pode revogar a autorização a qualquer momento via pedido escrito ao contato LGPD indicado na política da instituição. A revogação não prejudica tratamentos já realizados regularmente (Art. 8º, §5º, LGPD).
Renovação
O termo é válido enquanto o menor participar das atividades. Um novo consentimento pode ser registrado a qualquer momento (cria novo registro na tabela, versão anterior arquivada).
Consentimento server-side (issue #756)
O Worker — fonte da verdade e o único plano do Modo Fácil v1 (online-only) — passou a persistir o aceite na tabela image_consents do D1 (migrations/0010_image_consents.sql), não apenas no IndexedDB:
- O que foi consentido:
term_version(ex.:2026-09-v1), finalidade nomeada (purpose) e o texto do termo congelado no ato (term_text). - Quem consentiu:
granted_by_name,granted_by_user_id(quando houver conta) erelationship(vínculo com o menor). - Como foi verificado (Art. 14, §5º — "todos os esforços razoáveis"):
verification_method(RECEPTION_GUARDIAN_PHOTO,VERIFIED_GUARDIAN_PRESENT,PHONE_OTP,IN_PERSON_DOCUMENT,ADULT_SELF) +verified_by_user_id(quem conferiu). - Titulares:
subject_type=STUDENT(criança — foto de rosto/biometria para identificação na chegada e saída) ouUSER(adulto responsável — a foto dele, exibida na conferência da entrega). - Imutabilidade: o aceite nunca é editado nem apagado. A revogação apenas preenche
revoked_at/revoked_by_user_id/revocation_reasonuma única vez (409 na segunda tentativa); reconsentir insere uma nova linha e a consulta devolve o estado atual + histórico completo. - Gate da matrícula: um aluno com fotos (
photo_refs) só persiste junto com o aceite validado — a linha de consentimento entra no mesmo batch atômico do evento/projeção do aluno (sem aceite → 400, nada é gravado). O vínculostudents.image_consent_idcontinua preenchido, preservando os consumidores atuais do app.
Endpoints: POST /api/v1/image-consents (registrar), GET /api/v1/image-consents?subjectType=&subjectId= (estado + histórico) e POST /api/v1/image-consents/:consentId/revoke (revogar, ADMIN). As fotos em si vivem no R2 sob faces/students/{id}/* e faces/users/{id}/* (issue #755); o D1 guarda apenas as keys em photo_refs, de modo que a eliminação (Art. 18) apaga N objetos + limpa a referência sem varrer o bucket.
Autorização temporária de retirada — N3 (issue #758)
A retirada da criança é controlada pela lista fechada de autorizados (ADR-0036) em níveis de confiança (ADR-0042): N1 = responsável legal criado na matrícula (issue #757); N2 = adulto novo verificado por OTP no telefone (IAL1 do NIST SP 800-63); N3 = autorização temporária do dia/evento, dada por um responsável N1/N2 presente na recepção. O que o N3 trata no D1 (pickup_authorizations, migrations/0012_pickup_authorizations.sql):
- Base verificável estrutural (Art. 14, §5º):
authorized_by_pickup_idprecisa ser uma entrada ACTIVE da lista da mesma criança no momento da criação — sem responsável verificado presente não existe N3. O registro guardaauthorized_by(quem autorizou),created_by(o voluntário/ator) erelationship. - Minimização (Art. 6º, III): o adulto autorizado não ganha conta (
users) e o telefone é opcional (quando informado, serve ao casamento por sufixo no check-out). Só o nome, o vínculo e a janela de vigência são armazenados. - Vigência limitada:
valid_from→valid_until; o padrão é o fim do dia UTC (espelha o token diário do check-out, ADR-0026) e a janela explícita é limitada a 7 dias — depois disso a concessão fica inerte na leitura e no gate de retirada, sem precisar de job. - Sem OTP, por quê: a verificação do consentidor é presencial contra dado já verificado (a foto do responsável de arquivo é conferida na tela, issue #731) — o análogo do "text-plus" do COPPA e da fotografia-no-ato do Texas §744.2803.
- Revogação e auditoria: a concessão pode ser revogada com justificativa (obrigatória) e cada criação/revogação gera evento imutável
AUTHORIZED_PICKUP. A eliminação LGPD por linha da concessão entra junto do job de retenção (as linhas são do dia e mínimas). - Transparência: a recepção vê nome + vínculo (nunca o telefone); a lista durável e as concessões vigentes são consultadas separadamente e o app (#723) exibe apenas o que está dentro da janela.
Medidas de Proteção
Minimização de Dados
Apenas campos essenciais são armazenados. O sistema não coleta dados desnecessários ou excessivos. Soft-delete preserva o histórico de auditoria sem expor dados ativos.
Criptografia em Repouso
Dados sensíveis no IndexedDB são criptografados com AES-GCM. A chave de criptografia é derivada do hash da senha do usuário via PBKDF2. Campos como changePayload e justification são armazenados apenas como ciphertext.
Controle de Acesso
- RBAC com 4 papéis base + papéis customizados
- Apenas
ADMINacessa todos os dados de alunos CHAMADORvê apenas nome e status para marcação de presença- Auditoria: toda mutação registrada via tabela de eventos
Responsabilidades (Controlador vs Operador)
| Papel | Quem é | Responsabilidades LGPD |
|---|---|---|
| Controlador | Igreja / Escola (instituição usuária do software) | Definir finalidades, obter consentimento, responder a requisições de titulares, notificar ANPD em caso de incidente |
| Operador | Mantenedores do software Neemias | Garantir a segurança técnica do software, processar dados conforme instruções do controlador, manter registro de operações |
A instituição usuária (igreja/escola) é a controladora dos dados nos termos do Art. 5º, VI da LGPD. O software é a ferramenta — a responsabilidade pelo cumprimento da LGPD é da instituição que opera o sistema.
Fluxo de Resposta a Incidentes
| Etapa | Descrição | Prazo |
|---|---|---|
| 1. Detecção | Identificação de vazamento, acesso não autorizado ou perda de dados | Imediato |
| 2. Contenção | Isolamento do sistema afetado, revogação de tokens/senhas comprometidos | 24h |
| 3. Investigação | Análise de logs (local: IndexedDB, servidor: Cloudflare D1) para determinar escopo | 48h |
| 4. Notificação ANPD | Comunicação à Autoridade Nacional de Proteção de Dados | 72h (Art. 48, LGPD) |
| 5. Notificação titulares | Comunicação aos responsáveis dos alunos afetados | 72h |
| 6. Remediação | Correção da vulnerabilidade, melhoria de controles | 7 dias |
Contato para reportar incidentes: conforme SECURITY_CONTACT_EMAIL configurado na instância.
Workflow de Requisição de Titular (Art. 18 LGPD)
| Direito | Como exercer | Funcionalidade no app |
|---|---|---|
| Acesso | Responsável solicita à instituição | Exportar dados do aluno (CSV/JSON) + registro de consentimento |
| Correção | Responsável solicita correção de dado incorreto | Edição de campos na interface de admin |
| Exclusão | Responsável solicita remoção (direito ao esquecimento) | Soft-delete do aluno + revogação de consentimento |
| Portabilidade | Responsável solicita exportação dos dados | Export CSV/JSON de todos os dados do aluno |
| Oposição | Responsável contesta tratamento de dado específico | Revogação de consentimento de imagem |
| Revogação de consentimento | Responsável cancela autorização anterior | Revogação do registro imageConsent |
A instituição deve responder à requisição em até 15 dias (Art. 19, LGPD).
Equivalência LGPD → GDPR
| LGPD | GDPR | Diferenças |
|---|---|---|
| Art. 5º — Dado pessoal | Art. 4(1) — Personal data | Equivalentes |
| Art. 7º — Bases legais | Art. 6 — Lawfulness of processing | Equivalentes (LGPD tem uma base a mais: proteção ao crédito) |
| Art. 11 — Dados sensíveis | Art. 9 — Special categories | Equivalentes |
| Art. 18 — Direitos do titular | Art. 15-22 — Data subject rights | Muito similares; LGPD inclui direito de oposição explícito |
| Art. 41 — Encarregado (DPO) | Art. 37 — Data Protection Officer | Equivalentes |
| Art. 48 — Notificação de incidentes | Art. 33 — Breach notification | Prazos: 72h (LGPD e GDPR) |
| — | Art. 27 — Representative | GDPR exige representante na UE se controlador estiver fora |
Checklist de Due Diligence para Implantação
Infraestrutura
- Tráfego: HTTPS obrigatório (Cloudflare)
- Armazenamento: IndexedDB (client-side) + D1 (Cloudflare, servidores nos EUA)
- Backups: D1 backups automáticos diários
- Logs: Sem rastreamento de terceiros. Sem cookies de tracking.
- Fornecedores terceiros: Nenhum dado de aluno é compartilhado com terceiros para fins comerciais
Fonte: packages/schemas/src/entities.ts (PII comments), .specs/project/STATE.md, app/src/db/types.ts (ImageConsent), docs/operations/storage-retention.md