Projeto: Controle de Acesso de Veículos
Instituição: Instituto Federal de Pernambuco — Campus Belo Jardim
Disciplina: Projeto Integrador — Práticas Reais de Software e Segurança
Equipe: José Ernandes Gonçalves Costa; Raíssa Beatriz Marinho dos Santos
Cliente inicial: Eurico Lopes — Setor de Transporte
Versão: 2.1
Status: Controles técnicos do MVP implementados; validações institucionais, infraestrutura e operação de produção pendentes
Data de referência: 30 de setembro de 2026
Documentos relacionados: MVP e Fluxo Digital v0.1; Arquitetura de Software — arc42 v0.1; Modelo de Dados v0.3; Regras de Negócio v0.1; Requisitos e Backlog v0.3

Baseline de segurança — atualizada em 29/09/2026: a modelagem STRIDE e o guia seguro foram publicados como documentos complementares. Consulte Modelagem de Ameaças e Guia de Boas Práticas de Desenvolvimento Seguro. A fonte versionada foi integrada pelo PR #32. JWT, contas individuais, bloqueio de login, rate limiting, autorização preliminar e identificação do ator nos fluxos geral e institucional estão implementados. O fluxo de eventos preserva a leitura para os quatro perfis e restringe criação, alteração e cancelamento ao Administrador, conforme a política aplicada no servidor. Ele valida estado, período, placa e cota dentro da transação e serializa o consumo concorrente. A auditoria registra identificadores sem copiar nome do evento, responsável, área, observação ou placa. O resumo operacional diário é autorizado para os quatro perfis do MVP e retorna somente totais agregados, limites UTC e o fuso aplicado; não inclui nomes, documentos, placas, motoristas, itinerários ou observações. O servidor possui access token curto, sessão renovável por refresh token opaco em cookie HttpOnly, rotação, revogação, proteção CSRF, logout e atualização progressiva de hashes compatíveis obsoletos. O Nginx local aplica CSP, bloqueio de frames, proteção contra MIME sniffing, política de referência e permissões mínimas, verificados pela CI. O frontend integra restauração, renovação transparente, logout e coordenação entre abas sem persistir ou compartilhar tokens. Após 15 minutos sem atividade humana, a interface encerra o acesso local; o servidor também impõe limite absoluto de 12 horas. Requisições automáticas, renovação e sincronização entre abas não prolongam a atividade. O ciclo de contas usa credencial temporária aleatória, expirável e de uso único, troca obrigatória antes das operações e redefinição administrativa auditada com revogação de sessões. O Administrador não escolhe nem conhece a senha permanente do titular. Dois Administradores funcionais e a entrega direta da credencial temporária ao titular foram definidos para o MVP. O key ring usado pelos cookies e tokens antifalsificação agora persiste em armazenamento compartilhável, usa um nome de aplicação estável e mantém os XML criptografados com certificado X.509 externo; testes automatizados e um ensaio de substituição do contêiner confirmam a continuidade. HTTPS, provisionamento desse armazenamento e dos segredos na OCI, matriz final, backup protegido de produção e implantação institucional permanecem pendentes. A proposta de continuidade está em Retenção, Backup e Continuidade.

Este documento define diretrizes preliminares de segurança e privacidade para o sistema de Controle de Acesso de Veículos do IFPE Campus Belo Jardim.

O objetivo é orientar a futura implementação do sistema para que os registros de veículos, condutores, motoristas, usuários, viagens institucionais e alterações sejam tratados de forma controlada, rastreável e proporcional à finalidade do processo.

O documento não substitui normas institucionais, políticas formais de segurança, orientações jurídicas ou decisões administrativas. As medidas classificadas como propostas, preliminares ou pendentes deverão ser validadas antes da implementação definitiva.

Este documento considera a proteção de dados e operações relacionadas ao MVP:

• Autenticação de usuários internos.
• Perfis e permissões.
• Registros de entrada e saída de veículos.
• Veículos institucionais.
• Motoristas e condutores relacionados a veículos.
• Placas.
• Objetivos de acesso.
• Quilometragem e itinerário de veículos institucionais.
• Consultas operacionais e históricas.
• Correções controladas.
• Auditoria.
• Backup e recuperação.
• Retenção de dados.
• Contingência.
• Exportação autorizada.
• Registros técnicos e operacionais relevantes.

Os itens abaixo só deverão receber controles específicos caso entrem no MVP ou sejam aprovados posteriormente:

• RG ou CPF.
• Registro de recusa de acesso.
• Veículos que permanecem no campus.
• Mototáxis.
• Eventos com veículos.
• Ocorrências.
• Veículos de discentes residentes.
• Exportação de relatórios.
• Integrações com sistemas institucionais.

• Reconhecimento facial.
• Reconhecimento automático de placas.
• Integração com câmeras.
• Integração com sensores.
• Automação da catraca ou cancela.
• Gestão geral de crachás.
• Controle geral de pedestres.
• Controle geral de visitantes sem veículo.
• Controle completo de servidores ou terceirizados sem relação com veículo.
• Vigilância completa do campus.

O sistema será utilizado para substituir ou apoiar o controle manual de veículos atualmente registrado em formulários físicos.

O processo atual possui riscos relacionados a:

• Consulta demorada de documentos físicos.
• Dificuldade para localizar registros históricos.
• Dificuldade para identificar motoristas associados a veículos institucionais.
• Possibilidade de preenchimento incompleto ou ilegível.
• Necessidade de refazer formulários quando ocorre erro.
• Ausência de histórico digital de alterações.
• Dependência de listas e planilhas que podem estar desatualizadas.
• Troca de turno entre porteiro e vigilante.
• Possível exposição indevida de dados pessoais em formulários e consultas.
• Ausência de controles digitais consolidados de acesso, auditoria e permissões.

A solução digital deve reduzir esses riscos sem coletar dados desnecessários ou transformar hipóteses em regras institucionais definitivas.

Os dados devem ser utilizados somente para finalidades relacionadas ao controle de acesso, movimentação, consulta, conferência, segurança operacional e responsabilização administrativa de veículos.

Classificação: Proposta.

O sistema deve coletar somente os dados necessários para cada fluxo aprovado no MVP.

Campos sem finalidade identificada não devem ser incluídos apenas porque existem em formulários físicos ou planilhas antigas.

Classificação: Proposta.

Cada usuário deve possuir apenas as permissões necessárias para executar suas atividades.

Classificação: Proposta.

Operações relevantes devem poder ser relacionadas ao usuário responsável, à data, ao horário e ao registro afetado.

Classificação: Proposta.

Registros operacionais e históricos não devem ser alterados ou removidos silenciosamente.

Correções devem preservar histórico conforme permissão e justificativa.

Classificação: Proposta.

A implementação deve iniciar com configurações restritivas, acesso autenticado, perfis mínimos, validação de dados e registro de operações relevantes.

Classificação: Proposta.

A necessidade de cada campo deve ser analisada antes de sua inclusão no banco, na interface, em consultas ou em relatórios.

Classificação: Proposta.

A indisponibilidade da rede, do sistema ou do dispositivo não deve levar à perda de registros ou à ausência completa de rastreabilidade.

Classificação: Pendente.

Cada operação relevante deve ser realizada por um usuário autenticado individualmente.

Não deve haver compartilhamento de credenciais entre porteiros, vigilantes, Setor de Transporte ou administradores.

Classificação: Implementada no backend; uso individual ainda depende de validação operacional.

As senhas nunca devem ser armazenadas em texto puro.

O sistema deve armazenar somente um hash de senha produzido por mecanismo adequado de derivação de senha.

A implementação atual utiliza o PasswordHasher<TUser> do ASP.NET Core Identity e persiste somente o hash.

Classificação: Implementada.

A política técnica exige senha permanente individual de 12 a 128 caracteres e impede reutilizar a credencial atual. Ajustes operacionais ainda dependem de validação institucional.

Os controles atuais exigem:

• Senha individual.
• Tamanho mínimo adequado.
• Proibição de senhas comuns ou fracas, quando suportado.
• Alteração de senha por mecanismo autenticado.
• Armazenamento exclusivo de hash.
• Proteção contra tentativa excessiva de login.

Classificação: Controle técnico implementado; política institucional final pendente.

A implementação bloqueia a conta por 15 minutos após cinco tentativas consecutivas com senha inválida. Login bem-sucedido e transição para bloqueio geram auditoria na mesma transação da conta. Os detalhes registram apenas o resultado e, quando aplicável, o fim do bloqueio; senha, token e e-mail não são duplicados na auditoria.

Administradores podem pesquisar, desativar e reativar contas. A API impede auto-desativação, serializa mudanças concorrentes para preservar ao menos um Administrador ativo e audita somente a transição do estado. Conta ou perfil inativo rejeita inclusive um JWT emitido anteriormente na requisição seguinte.

Criação administrativa e bootstrap também geram auditoria na mesma transação de pessoa e conta. A criação HTTP exige Administrador autenticado; o bootstrap usa ator nulo e origem explícita de sistema, sem atribuição falsa e sem copiar nome, e-mail, senha ou hash.

Na criação HTTP, o Administrador informa nome, e-mail e perfil, mas não escolhe a senha permanente. O servidor gera uma credencial temporária com fonte criptograficamente segura, validade padrão de 30 minutos e uso único. O texto claro é devolvido somente uma vez com resposta não armazenável; o banco mantém apenas o hash e os estados mínimos. O primeiro login consome a credencial atomicamente e restringe a conta à troca da senha ou ao logout.

Somente o Administrador pode redefinir a credencial temporária de outra conta ativa, com motivo categorizado. A operação invalida a credencial anterior, incrementa a versão, revoga sessões e grava auditoria transacional sem senha, hash ou token. Porteiro, Vigilante e Setor de Transporte não recebem essa permissão.

A decisão institucional registrada na Issue #220 definiu dois Administradores funcionais como responsáveis pela redefinição e a entrega direta da credencial temporária ao titular. Ainda precisa ser definido ou observado:

• Como o procedimento de entrega direta funciona no ambiente real e se a validade padrão de 30 minutos precisa de ajuste.
• Como encerrar uma sessão específica sem revogar todas as sessões da conta.
• Se tentativas inválidas adicionais podem ser registradas com segurança sem permitir enumeração de contas.
• Se haverá autenticação institucional integrada no futuro.

Classificação: Ciclo técnico de sessão, credencial temporária, troca obrigatória e redefinição administrativa implementados e integrados; responsáveis e entrega direta definidos para o MVP; autenticação institucional e observação operacional permanecem na Issue #162.

Esta matriz não representa permissões institucionais definitivas. Ela deverá ser validada com os responsáveis pelo processo.

A autorização deve ser concedida conforme a necessidade operacional do usuário.

Exemplos:

• O porteiro não deve possuir acesso administrativo sem necessidade.
• O Setor de Transporte pode corrigir somente os campos descritivos aprovados, sempre com justificativa e auditoria; entrada, saída, encerramento excepcional, identidade, placa, horários, situação e autoria original permanecem fora dessa permissão.
• RG ou CPF, se aprovados, não devem ficar visíveis para todos os perfis.
• A exportação de dados deve ser limitada a usuários autorizados.
• Usuários inativos não devem realizar operações.

Classificação: Proposta.

O nome do condutor ou motorista é necessário para identificar pessoas relacionadas a acessos e viagens institucionais.

A visualização deve ser limitada aos usuários que necessitam da informação para operação, consulta, conferência ou responsabilização administrativa.

Classificação: Confirmado em documento.

RG ou CPF aparecem no Formulário nº 02, mas sua necessidade no fluxo digital ainda não foi confirmada.

Antes de incluir esses dados, deve ser validado:

• Se o documento é realmente necessário para o controle veicular.
• Se RG, CPF ou ambos devem ser aceitos.
• Em quais categorias de acesso ele será necessário.
• Quem poderá visualizar o dado.
• Quem poderá exportar esse dado.
• Qual será o prazo de retenção.
• Qual justificativa operacional ou institucional fundamenta a coleta.

Enquanto essas questões não forem aprovadas, RG e CPF não devem ser exigidos como campo obrigatório no MVP.

Classificação: Confirmado em documento e pendente.

A placa é um dado necessário para identificar e consultar veículos, conforme os Formulários nº 01 e nº 02.

A obrigatoriedade da placa em todas as categorias ainda precisa ser confirmada, especialmente para possíveis exceções institucionais.

Classificação: Confirmado em documento e pendente quanto à obrigatoriedade.

O itinerário, a quilometragem e o motorista são dados relacionados aos veículos institucionais.

Esses dados devem ser acessíveis apenas a usuários que necessitem deles para operação, conferência, consulta histórica ou responsabilização administrativa.

O significado detalhado de “itinerário” ainda precisa ser validado.

Classificação: Confirmado em documento e pendente quanto ao significado do itinerário.

Os seguintes dados não devem ser coletados no MVP sem finalidade validada:

• Telefone.
• E-mail.
• Endereço.
• Marca.
• Modelo.
• Cor.
• Documento adicional.
• Foto.
• Imagem de câmera.
• Dados biométricos.
• Localização em tempo real.
• Informações sem relação direta com o controle veicular.

Classificação: Proposta baseada em minimização de dados.

O sistema deve registrar auditoria para operações relevantes, incluindo:

• Criação de registro de entrada.
• Encerramento de registro por saída.
• Criação de uso de veículo institucional.
• Registro de retorno de veículo institucional.
• Alteração de dados relevantes.
• Correção de registro.
• Cancelamento, se essa funcionalidade for aprovada.
• Criação, inativação ou alteração de usuário.
• Alteração de perfil ou permissão.
• Exportação de dados, se aprovada.
• Consulta de dados pessoais restritos, se aprovada.

Classificação: Proposta.

O registro de auditoria deve conter, quando aplicável:

• Usuário responsável.
• Data e horário.
• Entidade ou registro alterado.
• Tipo de ação.
• Valor anterior.
• Novo valor.
• Motivo da correção.
• Identificação técnica da origem, se definida pela arquitetura.

Classificação: Proposta.

Erros não devem exigir a exclusão silenciosa do registro original.

A correção deve:

1. Ser realizada por usuário autorizado.
2. Exigir justificativa.
3. Preservar o valor anterior.
4. Registrar o novo valor.
5. Registrar data, horário e usuário.
6. Permitir conferência posterior pelo Setor de Transporte, quando aplicável.

Classificação: Proposta.

A consulta do histórico de auditoria deve ser restrita a perfis autorizados.

No MVP, a política dedicada audits:read restringe GET /audits a Administrador. A consulta usa período padrão de 30 dias, máximo de 90 dias, páginas de até 100 eventos e filtros que distinguem ator humano de origem de sistema. Ela não faz junções com pessoas, contas ou veículos. A matriz permanece revisável na homologação.

Classificação: Pendente.

O sistema deve evitar ou sinalizar:

• Registro de saída duplicada.
• Encerramento de acesso já encerrado.
• Quilometragem de entrada menor que quilometragem de saída.
• Datas e horários inconsistentes.
• Veículo institucional com múltiplas viagens em aberto, salvo regra validada.
• Alteração de registro sem auditoria.
• Usuário inativo realizando operações.
• Acesso a operações sem permissão.

Classificação: Proposta.

As validações abaixo dependem de confirmação:

• Obrigatoriedade da placa por categoria.
• Obrigatoriedade de RG ou CPF.
• Formato aceito para RG ou CPF.
• Significado do campo “veículo”.
• Tipos oficiais de veículos.
• Formato do objetivo.
• Significado do itinerário.
• Regras oficiais para veículos sem placa.
• Regras oficiais para motociclistas sem capacete.
• Procedimento para registro sem entrada correspondente.
• Procedimento para veículo que permanece no campus.

Classificação: Pendente.

As validações importantes não devem depender apenas da interface.

A camada de aplicação deve validar regras de negócio e autorização antes de persistir os dados.

Classificação: Proposta.

Quando o sistema for implantado em ambiente acessível por rede, a comunicação entre navegador e aplicação deve utilizar conexão protegida.

A tecnologia definitiva dependerá do ambiente de implantação, mas a proposta é utilizar HTTPS com certificado válido.

Classificação: Proposta.

O banco de dados deve possuir controles de acesso restritos ao ambiente necessário para execução da aplicação e administração autorizada.

A estratégia de criptografia de dados sensíveis em repouso dependerá da infraestrutura e da necessidade de armazenamento de RG ou CPF.

Classificação: Proposta.

Senhas, chaves, tokens, strings de conexão e outros segredos não devem ser gravados no código-fonte, commits, Wiki ou arquivos públicos.

A implementação futura deve utilizar mecanismo apropriado de configuração segura para cada ambiente.

Classificação: Proposta.

As dependências utilizadas no projeto devem ser acompanhadas para evitar vulnerabilidades conhecidas.

O projeto deve observar alertas do Dependabot e corrigir vulnerabilidades altas ou críticas antes da implantação.

Classificação: Confirmado em documento da disciplina.

A API aplica janela fixa em memória, sem fila, com limite padrão de 300 requisições por minuto por usuário autenticado ou endereço da conexão. O login possui limite específico de 30 por minuto por endereço. Excesso retorna HTTP 429 em ProblemDetails, com correlação e Retry-After; health checks são isentos.

Os valores são configuráveis e precisam ser calibrados com observabilidade e teste de carga. O controle atual é por instância e não confia em X-Forwarded-For; proxy conhecido e rate limiting distribuído permanecem necessários antes de uma implantação horizontal.

Classificação: Implementado na Issue #69; calibração de produção pendente.

O sistema deve possuir uma estratégia de backup para preservar cadastros, registros de acesso, viagens institucionais, usuários, perfis e auditoria. O ambiente local já comprova dump lógico, manifesto SHA-256, verificação anterior ao PostgreSQL e restauração isolada. A CI exercita o caminho válido e rejeita uma cópia adulterada.

O checksum detecta corrupção enquanto o manifesto permanece íntegro, mas não autentica a origem e não protege a confidencialidade. O PR #313 aprovou como direção Object Storage privado, chave gerenciada no OCI Vault, instance principal, MFA e grupos IAM separados para upload, recuperação, chaves e auditoria.

Backups usarão janela móvel de 35 dias, alerta de ausência ou falha e exercício trimestral. Desenvolvedores e orientadores terão autorização por IAM/Vault; não receberão nem compartilharão arquivos de chave. O provisionamento e a restauração externa permanecem na Issue #311.

Classificação: Ensaio local implementado; arquitetura de produção aprovada e ainda não provisionada.

Em caso de falha de banco de dados, servidor, exclusão indevida ou incidente, a equipe deve possuir procedimento documentado para recuperar os dados a partir de cópia válida.

O RPO-alvo de produção é de até uma hora e o RTO-alvo é de até quatro horas no período com suporte. O dump diário atual entrega apenas RPO técnico de até 24 horas. A Issue #312 implementará e provará WAL/PITR; o primeiro exercício real está previsto para a segunda unidade.

Classificação: Metas aprovadas; capacidade de produção e tempos ainda não comprovados.

O responsável pelo processo definiu cinco anos para acessos, usos, eventos, auditorias e formulários físicos reconciliados. Pessoas, veículos e a identidade mínima das contas permanecem enquanto forem necessários a registros retidos. Logs técnicos usam 90 dias e backups usam 35 dias, porque backup não substitui arquivo histórico.

Cinco anos constituem decisão operacional, não interpretação jurídica. A referência arquivística ou de proteção de dados ainda deve confirmar o enquadramento antes do descarte automático.

Classificação: Direção operacional aprovada; revisão arquivística e expurgo seguro pendentes.

Quando houver política institucional de descarte ou expiração de dados, o processo deve considerar:

• Retenção necessária para finalidade operacional e administrativa.
• Necessidade de preservação de auditoria.
• Necessidade de backup.
• Exclusão lógica ou física conforme regra aprovada.
• Anonimização, quando aplicável.
• Registro da operação de descarte, quando necessário.

Classificação: Pendente.

A exportação de registros deve ocorrer somente quando houver necessidade operacional ou administrativa aprovada.

A exportação deve considerar:

• Perfil autorizado.
• Finalidade da solicitação.
• Dados mínimos necessários.
• Registro do usuário responsável.
• Data e horário.
• Tipo de informação exportada.
• Proteção do arquivo gerado, quando aplicável.

Classificação: Proposta.

RG ou CPF, caso sejam aprovados futuramente, não devem ser incluídos em relatórios ou exportações gerais sem necessidade validada.

Classificação: Proposta.

Relatórios gerenciais avançados não fazem parte obrigatória do MVP.

Consultas básicas por placa, veículo, condutor, motorista e período possuem prioridade maior.

Classificação: Fora do escopo inicial para relatórios avançados.

A aplicação deve registrar erros técnicos relevantes para facilitar diagnóstico e manutenção.

Os logs não devem registrar senhas, hashes de senha, tokens, documentos pessoais completos ou outros dados sensíveis sem necessidade.

Classificação: Logging HTTP mínimo implementado; centralização pendente.

A API já oferece métricas HTTP/runtime e traces ASP.NET Core por OTLP quando explicitamente habilitada. A implantação deve considerar monitoramento de:

• Disponibilidade da aplicação.
• Erros técnicos.
• Uso de recursos.
• Falhas de autenticação.
• Falhas de backup.
• Eventos de segurança relevantes.

Collector, armazenamento, logs centralizados, painéis e alertas ainda não foram definidos. A integração não exporta logs, corpos, credenciais ou SQL; valores de query permanecem redigidos e health checks não geram traces.

Classificação: Instrumentação implementada; plataforma externa pendente.

Alertas técnicos poderão ser configurados futuramente para:

• Indisponibilidade da aplicação.
• Falha de backup.
• Erros recorrentes.
• Tentativas excessivas de autenticação.
• Falhas de banco de dados.
• Espaço insuficiente de armazenamento.

Classificação: Futuro.

O procedimento definitivo para falta de rede ainda precisa ser validado com a portaria e o Setor de Transporte.

A proposta preliminar é:

Falha de rede identificada
    ↓
Porteiro ou vigilante utiliza procedimento temporário aprovado
    ↓
Registro é realizado em meio definido pela instituição
    ↓
Ocorrência é comunicada quando necessário
    ↓
Uma pessoa digita e outra confere posteriormente
    ↓
Reconciliação registra horário observado, autoria, justificativa e auditoria

Os endpoints atuais registram horário e ator do servidor; não devem ser usados para recriar fatos antigos. A Issue #100 deverá criar o fluxo idempotente e auditável depois da validação institucional da Issue #30.

Classificação: Proposta documentada; homologação e implementação da reconciliação pendentes.

O procedimento de contingência deve considerar:

• Registro temporário aprovado.
• Comunicação ao responsável técnico ou Setor de Transporte.
• Registro posterior dos dados.
• Identificação da indisponibilidade.
• Auditoria do lançamento posterior.
• Verificação de dados duplicados após retorno do sistema.

Classificação: Pendente.

A catraca está sem motor, empenada e quebrada.

O MVP não deve depender da automação da catraca para registrar acessos ou operar o controle veicular.

Classificação: Informado.

Ainda precisa ser confirmado:

• Se haverá computador ou tablet disponível na portaria.
• Se haverá dispositivo alternativo.
• Quem será responsável pelo suporte.
• Como o operador deve agir em caso de falha do dispositivo.

Classificação: Pendente.

Exemplos de incidentes que deverão ser considerados futuramente:

• Acesso indevido a conta de usuário.
• Perda ou exposição de dados.
• Alteração não autorizada de registros.
• Indisponibilidade do sistema.
• Falha de backup.
• Uso indevido de exportação.
• Comprometimento de credenciais.
• Vulnerabilidade alta ou crítica identificada em dependência.

Classificação: Proposta.

O procedimento de resposta a incidentes deverá ser definido antes da implantação e pode incluir:

1. Identificar o incidente.
2. Registrar data, horário e responsável pelo registro.
3. Conter o problema quando possível.
4. Preservar evidências necessárias.
5. Comunicar responsáveis técnicos e institucionais.
6. Corrigir ou recuperar o serviço.
7. Avaliar impacto nos registros e dados.
8. Registrar lições aprendidas e ações preventivas.

Classificação: Proposta.

Os responsáveis formais por resposta a incidentes ainda precisam ser definidos.

A equipe do projeto não deve assumir automaticamente responsabilidades institucionais de segurança, infraestrutura ou proteção de dados sem definição formal.

Classificação: Pendente.

A implementação futura deve considerar:

• Validação de dados no servidor.
• Controle de autorização em cada operação protegida.
• Armazenamento de senha somente como hash.
• Proteção de segredos e variáveis de ambiente.
• Tratamento seguro de erros.
• Registro de auditoria.
• Proteção contra alteração indevida de registros.
• Revisão por Pull Request.
• Testes antes de merge.
• Dependabot e análise de vulnerabilidades.
• Uso de branch protegida.
• Pipeline de CI/CD conforme evolução do projeto.

Classificação: Proposta e confirmado em documento da disciplina.

Toda alteração de código relacionada a autenticação, autorização, auditoria, acesso a dados ou exportação deve passar por Pull Request e revisão antes do merge na branch principal.

Classificação: Confirmado em documento da disciplina.

A estratégia de testes futura deve incluir, quando aplicável:

• Testes de autenticação.
• Testes de autorização por perfil.
• Testes de acesso indevido.
• Testes de validação de entrada.
• Testes de correção e auditoria.
• Testes de exposição de dados pessoais.
• Testes de exportação autorizada.
• Testes de contingência.
• Testes de vulnerabilidades em dependências.
• Testes de recuperação de backup, quando a infraestrutura existir.

Classificação: Proposta.

As questões abaixo precisam ser confirmadas antes da implementação definitiva:

• RG ou CPF será necessário no fluxo veicular?
• Qual documento será aceito: RG, CPF ou ambos?
• Em quais situações o documento será obrigatório?
• Quem poderá visualizar documentos pessoais?
• Qual é o prazo de retenção desses dados?
• O campo “veículo” representa tipo, modelo, identificação patrimonial, número de frota ou outra informação?
• A placa será obrigatória em todas as categorias?
• Telefone, e-mail, marca, modelo, cor, patrimônio ou frota possuem finalidade no MVP?

• O vigilante terá as mesmas permissões do porteiro?
• Quem poderá criar usuários?
• Quem poderá inativar usuários?
• Quem poderá redefinir senhas?
• Quem poderá corrigir registros?
• Quem poderá consultar históricos?
• Quem poderá consultar auditoria?
• Quem poderá exportar dados?
• Quais permissões serão atribuídas ao Setor de Segurança?
• Quais permissões serão atribuídas ao SEGAI?

• O prazo atual de cinco anos é obrigatório?
• Qual será o prazo de retenção digital?
• O sistema substituirá completamente os formulários físicos?
• Qual será o procedimento de backup?
• Quem será responsável por verificar backups?
• Como será testada a recuperação?
• Como a portaria atuará sem rede?
• Como a portaria atuará se o sistema estiver indisponível?
• Há dispositivo alternativo disponível na portaria?
• Quem será responsável pelo suporte técnico?

• Onde o sistema será implantado?
• Haverá servidor institucional, VM ou nuvem pública?
• Como será garantido o acesso seguro por HTTPS?
• Quem responderá a incidentes de segurança?
• Quem será responsável por monitorar vulnerabilidades e dependências?
• Quais logs deverão ser armazenados?
• Qual será a política de exportação e compartilhamento de dados?

Este documento poderá ser considerado validado quando:

• As informações de segurança forem revisadas pela equipe.
• Os professores validarem as diretrizes técnicas aplicáveis ao projeto.
• O Setor de Transporte confirmar os dados necessários ao processo.
• A portaria confirmar a viabilidade operacional dos controles propostos.
• A necessidade de RG ou CPF for confirmada ou descartada.
• A matriz de perfis e permissões for definida.
• A política de retenção digital for orientada pela instituição.
• O procedimento de contingência for definido.
• A estratégia de backup e recuperação for definida conforme a infraestrutura.
• A stack e o ambiente de implantação forem escolhidos.
• As medidas aprovadas forem transformadas em requisitos, tarefas, testes e controles de implementação.

Documento: Segurança e Privacidade
Versão: 2.0
Status: Controles técnicos do MVP implementados; validações institucionais, infraestrutura e operação de produção pendentes
Núcleo considerado: Formulários nº 01 e nº 02
MVP: Preliminar
Stack tecnológica: React, ASP.NET Core/.NET 10, EF Core e PostgreSQL Infraestrutura: Pendente de confirmação
Implementação: Fundação técnica, autenticação, sessão renovável com encerramento por inatividade humana, credenciais temporárias, troca obrigatória e ciclo administrativo de contas com auditoria transacional, autorização preliminar, controles HTTP e rate limiting implementados; validações institucionais e produção pendentes Issues relacionadas: #11, #258, #260, #261, #268 e #279

• Coletar somente dados necessários ao fluxo veicular.
• Não tornar RG ou CPF obrigatório antes da validação.
• Utilizar autenticação com contas individuais.
• Armazenar senha somente como hash.
• Não permitir que o Administrador escolha a senha permanente de outra pessoa.
• Exibir credencial temporária somente uma vez e exigir sua substituição antes das operações.
• Aplicar autorização por perfil e menor privilégio.
• Manter auditoria de operações relevantes e correções.
• Não permitir alteração silenciosa de registros importantes.
• Restringir exportações e consultas de dados pessoais.
• Não depender de catraca, câmera, sensor ou reconhecimento de placas no MVP.
• Aplicar retenção de cinco anos aos registros operacionais e ao papel reconciliado, 90 dias aos logs e 35 dias aos backups.
• Proteger backups por Object Storage privado, Vault, instance principal, MFA e separação IAM, ainda pendentes de provisionamento.

• Validar necessidade de RG ou CPF.
• Definir matriz final de perfis e permissões.
• Observar a entrega direta da credencial temporária e definir o identificador principal das contas.
• Confirmar o enquadramento arquivístico e implementar descarte seguro.
• Provisionar backup e PITR nas Issues #311 e #312 e exercitar a recuperação na segunda unidade.
• Homologar a contingência operacional e então implementar a reconciliação da Issue #100.
• Confirmar infraestrutura e ambiente de implantação.
• Validar diretrizes com equipe, professores e responsáveis pelo processo.