Introdução
A validação de dados de entrada é um dos pilares fundamentais no desenvolvimento seguro de software. Sua aplicação previne a exploração de vulnerabilidades críticas, como injeções (SQL, XSS), ataques de força bruta e manipulações não autorizadas de informações. Este capítulo, fundamentado em normas reconhecidas internacionalmente, como ISO/IEC 27001, OWASP e NIST SSDF, aborda as melhores práticas e ferramentas para implementar validações seguras em aplicações utilizando linguagens e frameworks homologados.
Objetivos do Documento
Fornecer diretrizes para implementar validações de dados de entrada seguras e eficazes no ciclo de vida do desenvolvimento de software.
Prevenir ataques que exploram entradas não validadas ou mal sanitizadas.
Garantir conformidade com normas legais e regulamentares, como LGPD e GDPR.
Alinhar práticas de validação com os princípios de Security by Design
Implantação do Processo de Validação dos Dados de Entrada
Identificar e mapear os tipos de dados que a aplicação processará (ex.: texto, números, e-mails).
Definir padrões de validação com base nos contextos de uso (ex.: tamanho, formato, faixa de valores permitidos).
Estabelecer requisitos legais para proteção de dados sensíveis (ex.: LGPD e GDPR).
Incorporar validações no design arquitetural, adotando o princípio do fail-safe defaults (dados inválidos devem ser descartados).
Planejar filtros e validações para proteger pontos críticos de entrada, como APIs e formulários web.
Implementar bibliotecas ou funções específicas para validação e sanitização de entradas.
Configurar restrições baseadas em listas de permissões (whitelists), rejeitando entradas fora do padrão esperado.
Realizar testes de penetração simulando entradas maliciosas.
Aplicar ferramentas de análise dinâmica e estática para identificar vulnerabilidades em validações.
Monitorar atualizações de bibliotecas usadas na validação para evitar vulnerabilidades conhecidas.
Documentar processos de validação implementados para rastreabilidade e auditoria.
Configurar alertas para entradas inesperadas ou maliciosas durante a execução da aplicação.
Analisar logs regularmente para detectar padrões suspeitos em entradas processadas.
Implementar políticas de anonimização e pseudonimização para dados sensíveis validados.
Garantir que dados de entrada rejeitados sejam descartados sem armazenamento.
| Categoria | Ferramentas/Frameworks | Descrição |
| Validação de Dados | - Java: javax.validation, Hibernate Validator. - Python: Cerberus, Pydantic. | Ferramentas para validação segura com suporte a formatos específicos (e-mails, URLs, etc.). |
| Análise de Segurança | - SonarQube. - OWASP Dependency-Check. | Identifica vulnerabilidades relacionadas a entradas inseguras ou mal validadas. |
| Teste Dinâmico (DAST) | - OWASP ZAP. - Burp Suite. | Ferramentas para simulação de ataques e validação de fluxos de entrada. |
| Monitoramento | - Splunk, ELK Stack. | Coleta e análise de logs para identificar entradas suspeitas. |
| Conformidade | - TrustArc, OneTrust. | Valida conformidade com LGPD e GDPR em processos de entrada de dados sensíveis. |
|
LEVANTAMENTO DE REQUISITOS |
||
|
Quando deve acontecer
Durante a fase inicial do projeto, ao iniciar o ciclo de vida do desenvolvimento. |
Por que deve ser feito
Para desenvolver um projeto com capacidade de prevenção de vulnerabilidades relacionadas a entradas maliciosas. Para garantir que os dados processados obedeçam padrões definidos para integridade, segurança e conformidade com normas legais aplicáveis. Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança Equipe de Qualidade e de Segurança da Informação, Arquitetos de Segurança, Auditores Internos e em alguns casos Auditores Externos. |
|
|
Quem define os Atores e Ações da Etapa de Levantamento de Requisitos
Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução. Engenheiros de Software, Arquitetos de Segurança e Soluções e o DPO da organização. |
||
|
Quais os documentos necessários para a etapa de Levantamento de Requisitos
Documento de Requisitos Funcionais e Não Funcionais. Análise de Impacto de Proteção de Dados (DPIA) para identificar riscos relacionados à entrada de dados sensíveis. Matriz de Riscos e Controles (Risk Assessment Matrix).
|
||
|
O que é necessário definir nessa etapa
Formatos de Entrada – Definir formatos para cada tipo de entrada como números, e-mails e JSON (JavaScript Object Notation). Limites – Para tamanho e intervalos de valores permitidos. Regras de Validação – Regras específicas para validação de dados sensíveis como CPF e números de cartão.
|
||
|
O que precisamos entregar para a próxima etapa (Security by Design)
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações de requisitos de segurança, contendo: Detalhamento de especificações para requisitos de validação. Cenários e Casos de Teste – Apresentar cenários e meios de validação definidos para validação de entradas. Catálogo de Ferramentas – Lista de bibliotecas e frameworks recomendados para utilização segura.
|
||
|
Quem é responsável pela entrega
Coordenação de Desenvolvimento – Engenheiros de Software, Arquitetos de Software, Equipe de Segurança e DPO |
||
|
Práticas recomendadas para o Levantamento de Requisitos
Definir Padrões – Pode-se fazer uso de whitelists para definir padrões aceitos de entrada. Tratamento de Validação - Aplicar validação na borda (camadas de entrada) e novamente no back-end para defesa em profundidade. Zero Trust - Considerar todas as entradas como não confiáveis por padrão.
|
||
|
Ferramentas recomendadas
Análise de Requisitos – Jira, Confluence. Validação de Requisitos Legais – TrustArc, OneTrust. Análise de Segurança – OWASP ZAP (para simulação de entradas maliciosas).
|
||
|
Testes e Avaliações Iniciais
Simulação de entradas inválidas ou maliciosas para verificar resistência. Revisões manuais e automatizadas dos requisitos para alinhamento com as normas ISO/IEC e OWASP.
|
||
|
Referências técnicas
ISO/IEC 27034 – Segurança para Processos de Desenvolvimento de Aplicações. OWASP ASVS – Application Security Verification Standard. SAFECode – Fundamental Practices.
|
||
|
LEVANTAMENTO DE REQUISITOS |
|
|
Quando deve acontecer
Durante a fase inicial do projeto, ao iniciar o ciclo de vida do desenvolvimento. |
Por que deve ser feito
Para desenvolver um projeto com capacidade de prevenção de vulnerabilidades relacionadas a entradas maliciosas. Para garantir que os dados processados obedeçam padrões definidos para integridade, segurança e conformidade com normas legais aplicáveis. |
|
Quem define os Atores e Ações da Etapa de Levantamento de Requisitos
Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução. Engenheiros de Software, Arquitetos de Segurança e Soluções e o DPO da organização. |
Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança Equipe de Qualidade e de Segurança da Informação, Arquitetos de Segurança, Auditores Internos e em alguns casos Auditores Externos. |
|
Quais os documentos necessários para a etapa de Levantamento de Requisitos
Documento de Requisitos Funcionais e Não Funcionais. Análise de Impacto de Proteção de Dados (DPIA) para identificar riscos relacionados à entrada de dados sensíveis. Matriz de Riscos e Controles (Risk Assessment Matrix).
|
|
|
O que é necessário definir nessa etapa
Formatos de Entrada – Definir formatos para cada tipo de entrada como números, e-mails e JSON (JavaScript Object Notation). Limites – Para tamanho e intervalos de valores permitidos. Regras de Validação – Regras específicas para validação de dados sensíveis como CPF e números de cartão.
|
|
|
O que precisamos entregar para a próxima etapa (Security by Design)
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações de requisitos de segurança, contendo: Detalhamento de especificações para requisitos de validação. Cenários e Casos de Teste – Apresentar cenários e meios de validação definidos para validação de entradas. Catálogo de Ferramentas – Lista de bibliotecas e frameworks recomendados para utilização segura.
|
|
|
Quem é responsável pela entrega
Coordenação de Desenvolvimento – Engenheiros de Software, Arquitetos de Software, Equipe de Segurança e DPO |
|
|
Práticas recomendadas para o Levantamento de Requisitos
Definir Padrões – Pode-se fazer uso de whitelists para definir padrões aceitos de entrada. Tratamento de Validação - Aplicar validação na borda (camadas de entrada) e novamente no back-end para defesa em profundidade. Zero Trust - Considerar todas as entradas como não confiáveis por padrão.
|
|
|
Ferramentas recomendadas
Análise de Requisitos – Jira, Confluence. Validação de Requisitos Legais – TrustArc, OneTrust. Análise de Segurança – OWASP ZAP (para simulação de entradas maliciosas).
|
|
|
Testes e Avaliações Iniciais
Simulação de entradas inválidas ou maliciosas para verificar resistência. Revisões manuais e automatizadas dos requisitos para alinhamento com as normas ISO/IEC e OWASP.
|
|
|
Referências técnicas
ISO/IEC 27034 – Segurança para Processos de Desenvolvimento de Aplicações. OWASP ASVS – Application Security Verification Standard. SAFECode – Fundamental Practices.
|
|
|
EXECUÇÃO SEGURA |
|
|
Quando deve acontecer
Durante a etapa de codificação e execução do sistema, após as definições de design, antes de realizar os testes de segurança. |
Por que deve ser feito
Prevenir ataques baseados em entradas maliciosas (ex.: SQL Injection, XSS). - Assegurar que os dados sejam validados antes de serem processados ou armazenados. - Reduzir custos associados à correção de falhas em fases avançadas. |
|
Quem define os Atores e Ações da Etapa de Execução Segura Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução. Equipe de Desenvolvimento, de Infraestrutura e Equipe de Segurança. |
Quem define os Atores responsáveis pela Validação dos processos da Etapa de Execução Coordenação de Desenvolvimento e Coordenação de Segurança Equipe de Desenvolvimento (Código, integrações e arquitetura), Equipe de Infraestrutura (Sistema Operacional) e Segurança. |
|
Quais os documentos necessários para a etapa de Execução Segura
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações de requisitos de segurança, definidos na etapa anterior (Levantamento de Requisitos). Relatório ou Plano de Design de Sistema Atualizado (Etapa II) – Incluindo especificações detalhadas de controles definidos e aplicados. Especificação Técnica dos Requisitos de Validação. Listagem de Cenários de Teste – Tratando entradas válidas, inválidas e maliciosas. Manual de Melhores Práticas – Para aplicação do framework utilizado como nos casos do OWASP para Angular e Java.
|
|
|
O que precisamos definir na Etapa de Execução Segura
Bibliotecas e funções específicas para validação e revisão. Pontos críticos de validação na aplicação como as APIs, formulários, carregamento de arquivos. Quais as políticas de mensagens de erro seguras e de logs auditáveis.
|
|
|
O que precisamos entregar para a próxima etapa (Teste de Segurança)
Relatório de Execução Segura do Projeto (Etapa III) – Apresentando os controles utilizados, com listagem das práticas aplicadas no código e ferramentas utilizadas. Contendo: Estrutura do Código Desenvolvido – Definições e configurações fortes para validações robustas para entradas. Tratamento de Logs de execução – Detalhamento dos dados validados e erros documentados. Relatório de Conformidade – Para referência nos testes de segurança.
|
|
|
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Engenheiros de Software, Arquitetos de Segurança e DPO da organização. |
|
|
Práticas recomendadas para a Execução Segura
Defesa em Profundidade – Aplicar validações tanto no front-end quanto no back-end. Utilizar Whitelists – Tratar validações com base em listas de permissões. Uso de Bibliotecas Seguras – Utilizar bibliotecas nativas de cada linguagem para validação e sanitização.
|
|
|
Ferramentas recomendadas
Validação de Dados – Hibernate Validator, Pydantic e express-validator. Análise de Código – SonarQube eCheckmarx. Gestão de Logs – ELK Stack (Elasticsearch, Logstash, Kibana).
|
|
|
Testes e Avaliações Iniciais
Testes unitários para validação de entradas. Simulações de entradas maliciosas para verificar a eficácia das validações como fuzzing. Testes manuais para validação de cenários não automatizáveis.
|
|
|
Referências técnicas
ISO/IEC 27034 – Segurança para Processos de Desenvolvimento de Aplicações. OWASP Secure Coding Practices. SAFECode – Fundamental Practices for Secure Software Development.
|
|
|
TESTES DE SEGURANÇA |
|
|
Quando deve acontecer
Durante a fase de revisão do código, estruturas e testes do projeto, após a execução segura e antes da entrada em produção. Deve ser definido um cronograma de execução em ciclos regulares o ciclo de vida do sistema. |
Por que deve ser feito
Para oferecer a garantia de que as validações de dados de entrada estejam protegendo contra ataques como SQL Injection, XSS e Log Injection. Além de permitir processos de identificação de vulnerabilidades que possam ter sido introduzidas durante o desenvolvimento. |
|
Quem define os Atores e Ações da Etapa de Testes Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução. Equipes de Desenvolvimento, Segurança e de Testes (interna ou contratada). |
Quem define os Atores responsáveis pela Validação dos processos da Etapa de Testes Coordenação de Desenvolvimento e Coordenação de Segurança Equipe de Desenvolvimento, de Segurança e Auditores Internos (ou externos). |
|
Quais os documentos necessários para a etapa de Teste de Segurança
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações de requisitos de segurança, definidos na etapa anterior (Levantamento de Requisitos). Relatório ou Plano de Design de Sistema Atualizado (Etapa II) - Incluindo especificações detalhadas de controles definidos e aplicados. Relatório de Execução Segura do Projeto (Etapa III) – Apresentando os controles utilizados, com listagem das práticas aplicadas no código e ferramentas utilizadas. Relatórios de testes automatizados e manuais realizados durante o processo de execução segura. Especificações Técnicas para Requisitos de Validação. Plano de Testes de Segurança – com definições de cenários e casos de teste. Logs e relatórios gerados na etapa de Execução Segura para referência durante os testes.
|
|
|
O que precisamos definir na Etapa de Teste de Segurança
Cenários de entrada válidos, inválidos e maliciosos. Ferramentas e métodos para simular ataques e entradas inesperadas. Limites de tolerância para entradas erradas e rejeitadas.
|
|
|
O que precisamos entregar para a próxima etapa (Gerenciamento)
Relatório dos Testes de Segurança, contendo: Informações sobre possíveis vulnerabilidades identificadas e procedimentos de correção ou mitigação utilizados. Logs detalhados de testes realizados, incluindo evidências de conformidade com regulamentos. Relatórios de vulnerabilidades identificadas, categorizadas por criticidade. Planos de correções e mitigação de falhas. Evidências de conformidade com normas e regulamentações aplicáveis como a LGPD.
|
|
|
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Equipes de Testes de Segurança (Pentester), Engenheiros de Software e Arquitetos de Segurança. Nos casos nos quais as equipes identifiquem a necessidade, a presença do DPO será solicitada. |
|
|
Práticas recomendadas para os Testes de Segurança
Executar testes manuais e automatizados para tratar diferentes cenários de entrada. Utiliza técnicas de fuzzing para simulação de entradas inesperadas e verificar comportamentos. Analisar e validar mensagens de erro e logs gerados durante os testes.
|
|
|
Ferramentas recomendadas
Testes Dinâmicos (DAST): – OWASP ZAP, Burp Suite. Testes Estáticos (SAST) – SonarQube, Checkmarx. Testes com Técnicas de Fuzzing – Peach Fuzzer, Zest Proxy. Gestão de Vulnerabilidades: – Nessus, Qualys.
|
|
|
Testes e Avaliações Iniciais
Testes de Penetração – Realizar testes de penetração buscando vulnerabilidades, e riscos que possam ser corrigidos ou mitigados. Testar entradas críticas, como APIs e formulários. Para que o processo de testes tenha melhor aproveitamento, os pedidos de testes devem estar atrelados às atualizações de aplicações e ambientes, mantendo o processo em paralelo com o desenvolvimento. Testes unitários automatizados para validar entradas válidas e inválidas. Testes de desempenho para avaliar a resposta a grandes volumes de entradas.
|
|
|
Referências técnicas
ISO/IEC 27034 – Segurança para Processos de Desenvolvimento de Aplicações. OWASP Testing Guide NIST SSDF – Secure Software Development Framework.
|
|
|
GERENCIAMENTO |
|
|
Quando deve acontecer
Durante a fase de operação e manutenção contínua do ciclo de vida do software, após a etapa de Testes de Segurança e antes do Monitoramento contínuo. |
Por que deve ser feito
Garantir que as práticas de validação de dados permaneçam eficazes ao longo do tempo. - Prevenir a introdução de vulnerabilidades durante alterações ou melhorias no sistema. - Manter conformidade com normas e regulamentações (LGPD, GDPR). |
|
Quem define os Atores e Ações da Etapa de Gerenciamento Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução. Equipes de Desenvolvimento, Infraestrutura, Segurança da Informação e DPO. |
Quem define os Atores responsáveis pela Validação dos processos da Etapa de Gerenciamento Coordenação de Desenvolvimento e Coordenação de Segurança Equipes de Desenvolvimento, Infraestrutura e Segurança da Informação.
|
|
Quais os documentos necessários para a etapa de Gerenciamento
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações de requisitos de segurança, definidos na etapa anterior (Levantamento de Requisitos). Relatório ou Plano de Design de Sistema Atualizado (Etapa II) - Incluindo especificações detalhadas de controles definidos e aplicados. Relatório de Execução Segura do Projeto (Etapa III) – Apresentando os controles utilizados, com listagem das práticas aplicadas no código e ferramentas utilizadas. Relatório dos Testes de Segurança (Etapa IV) – Apresentando informações sobre vulnerabilidades e registros das atividades. Plano de Gerenciamento de Mudanças (Change Management Plan). Relatório de Vulnerabilidades Identificadas e Tratadas. Dados dos logs de alterações e atualizações no sistema.
|
|
|
O que precisamos definir na Etapa de Gerenciamento
Metodologias para gestão de mudanças nos pontos de validação de entradas, como, por exemplo, novas APIs ou modificações em formulários. Políticas de Revisão de requisitos de entrada para os casos de mudanças significativas no código ou arquitetura.
|
|
|
O que precisamos entregar para a próxima etapa (Monitoramento)
Relatório ou Planos de Gerenciamento de Segurança, contendo: Relatórios de mudanças realizadas e os impactos sobre a segurança. Informações detalhadas dos logs centralizados e anonimizados de dados validados e descartados. Planos de correção e mitigação para vulnerabilidades descobertas durante o gerenciamento.
|
|
|
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Gestores das Equipes de Infraestrutura, Engenheiros de Software (configuração técnica); Arquitetos de Segurança (supervisão); DPO (validação regulatória). |
|
|
Práticas recomendadas para os Testes de Segurança
Estabelecer um processo formal de gestão de mudanças para validações de entrada. Documentar todas as alterações que envolvam validações, incluindo bibliotecas ou frameworks. Realizar revisões periódicas das práticas de validação.
|
|
|
Ferramentas recomendadas
Gestão de Mudanças – Jira, ServiceNow. Monitoramento de Alterações – GitLab CI/CD, Jenkins. Gestão de Logs – ELK Stack (Elasticsearch, Logstash, Kibana), Fluentd.
|
|
|
Testes e Avaliações Iniciais
Testes regressivos automatizados para validar entradas após cada mudança. Simulações de ataques (Penetration Testing) para avaliar o impacto das mudanças. Análise de logs em busca de inconsistências nos eventos de validação.
|
|
|
Referências técnicas
ISO/IEC 27034 – Segurança para Processos de Desenvolvimento de Aplicações. NIST SSDF – Secure Software Development Framework. OWASP SAMM – Software Assurance Maturity Model.
|
|
| MONITORAMENTO DE SEGURANÇA | |
|
Quando deve acontecer
Durante a fase de operação e manutenção contínua do ciclo de vida do projeto, e enquanto a aplicação estiver em uso. |
Por que deve ser feito
Detectar e prevenir falhas relacionadas à validação de entradas. - Identificar padrões de ataques baseados em entradas maliciosas (ex.: força bruta, injeções). - Garantir conformidade contínua com normas e regulamentações (LGPD, GDPR). |
|
Quem define os Atores e Ações da Etapa de Monitoramento Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução. Equipes de Desenvolvimento, Operações, SOC (Monitoramento) e Testes. |
Quem define os Atores responsáveis pela Validação dos processos da Etapa de Monitoramento Coordenação de Desenvolvimento e Coordenação de Segurança Equipes de Segurança, Desenvolvimento e DPO. |
|
Quais os documentos necessários para a etapa de Monitoramento
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações de requisitos de segurança, definidos na etapa anterior (Levantamento de Requisitos). Relatório ou Plano de Design de Sistema Atualizado (Etapa II) - Incluindo especificações detalhadas de controles definidos e aplicados. Relatório de Execução Segura do Projeto (Etapa III) – Apresentando os controles utilizados, com listagem das práticas aplicadas no código e ferramentas utilizadas. Relatório dos Testes de Segurança (Etapa IV) – Apresentando informações sobre vulnerabilidades e registros das atividades. Relatório ou Planos de Gerenciamento de Segurança (Etapa V) – Com padrões e planos de gerenciamento, planos de atualização e revisão, relatórios de testes e logs de referência. Plano de Monitoramento Contínuo. Logs de Validação e Auditoria. Matriz de Riscos e Planos de Resposta a Incidentes.
|
|
|
O que precisamos definir na Etapa de Teste de Segurança
Parâmetros de monitoramento, como volume de entradas inválidas e taxa de rejeição por validação. Políticas de alerta para entradas maliciosas, não conformidades e Falsos Positivos. Política de Retenção e anonimização de logs de entrada sensíveis.
|
|
|
O que precisamos entregar
Relatório de Incidentes de Segurança, incluindo: Cronograma de auditoria de monitoramento. Configuração de Alertas para detecção e resposta a entradas suspeitas. Logs centralizados e seguros para análise forense e melhoria contínua.
|
|
|
Quem é responsável pela entrega
Coordenação de Desenvolvimento e de Infraestrutura – Equipes de Operações (configuração); Arquitetos de Segurança (validação); DPO (garantia de conformidade). |
|
|
Práticas recomendadas para a Etapa de Testes de Segurança
Configurar alertas automatizados - Nos casos de eventos críticos, como falhas de autenticação TLS. Centralize Informações de Registros - Logs de segurança devem ser centralizados em ferramentas robustas, como o Elastic Stackn e Splunk. Realize Auditorias – A organização deverá regularmente validar a eficácia do monitoramento e a conformidade com regulamentações. Implantar Respostas Automatizadas a Incidentes – Tratar incidentes de forma automatizada com ferramentas profissionais dará suporte a processo de mitigação de ameaças e correções de falhas com agilidade, garantindo mais segurança ao ambiente e usuários. Utilizar dashboards para monitoramento em tempo real. Automatizar análises de logs para identificar anomalias e padrões suspeitos. Realizar auditorias regulares para revisar a eficácia do monitoramento.
|
|
|
Ferramentas recomendadas para o projeto
Monitoramento Contínuo – Splunk, ELK Stack (Elasticsearch, Logstash, Kibana), Fluentd. SIEM (Security Information and Event Management) – QRadar, Azure Sentinel. Análise de Logs – Graylog, Loggly.
|
|
|
Testes e Avaliações Iniciais
Simulação de Falhas - Simular eventos de falha e de ataques com fuzzing para avaliar a capacidade de identificação de entradas inesperadas. Testes de penetração para verificar a resposta do monitoramento a entradas maliciosas. Auditoria de Logs - Auditar logs de eventos. Testes de Integridade - Validar a integridade de logs e registros monitorados contra alterações indevidas. Testes de Automação – Testar as automações desenvolvidas e aplicadas para resposta a eventos críticos, atestando sua eficácia.
|
|
|
Referências técnicas
ISO/IEC 27034 – Segurança para Processos de Desenvolvimento de Aplicações. OWASP Logging Guide SAFECode – Fundamental Practices for Secure Software Development.
|
|
|
PROTEÇÃO DE DADOS PESSOAIS |
|
|
Quando deve acontecer
Durante todo o ciclo de desenvolvimento, devendo ter as atividades enfatizadas nas etapas de design, codificação, operação e gerenciamento contínuo. Revisões, atualizações e auditorias devem ser periódicas. |
Por que deve ser feito
Para que a confidencialidade, integridade, disponibilidade e a proteção de dados pessoais sejam garantidas. Dar subsídios para atender às regulamentações como LGPD e GDPR que exigem a aplicação de criptografia para proteção de dados sensíveis. Além de fornecer recursos e referências para reduzir riscos de vazamento e acesso não autorizado a dados pessoais. |
|
Quem define os Atores e Ações na Etapa de Proteção de Dados Pessoais Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução. Engenheiros de Software, Arquitetos de Segurança e Soluções e DPO. |
Quem define os Atores responsáveis pela Validação dos processos da Etapa de Proteção de Dados Pessoais Coordenação de Desenvolvimento e Coordenação de Segurança Equipes de Qualidade, de Segurança, DOP e Auditores Internos (ou externos). |
|
Quais os documentos necessários para a etapa de Proteção de Dados Pessoais
Relatório dos Requisitos do Projeto (Etapa I) Relatório ou Plano de Design de Sistema Atualizado (Etapa II) Relatório de Execução Segura do Projeto (Etapa III) Relatório dos Testes de Segurança (Etapa IV) Relatório ou Planos de Gerenciamento de Segurança (Etapa V) Relatório de Incidentes de Segurança (Etapa VI) Políticas de privacidade e proteção de dados (baseadas em LGPD e GDPR). Plano de resposta a incidentes relacionados à violação de dados pessoais. Relatório de Classificação de Dados Pessoais (identificação de dados sensíveis). DPIA (Data Protection Impact Assessment) para identificar riscos e medidas mitigadoras. Diretrizes de Validação de Dados para proteção legal. |
|
|
O que precisamos definir nesta tapa
Padrões para validação de dados pessoais, como formatos esperados como CPF e e-mails. Políticas para anonimização e pseudonimização de dados. Mecanismos para prevenir armazenamento de dados pessoais sem validação.
|
|
|
Artefatos a serem gerados nessa etapa
Código seguro com validações robustas para entradas de dados pessoais. Logs anonimizados de entradas validadas e rejeitadas. Relatórios de conformidade com normas de proteção de dados para auditorias internas e externas.
|
|
|
Quem é responsável pela entrega
Coordenação de Desenvolvimento e Segurança – Engenheiros e Arquitetos de Software; Arquitetos de Segurança e DPO. |
|
|
Práticas recomendadas
Utilizar métodos de validação de borda (front-end) e no back-end para proteção em camadas. Tratar listas de permissões (whitelists) para entradas de dados pessoais. Garantir anonimização nos logs que armazenam informações validadas.
|
|
|
Ferramentas recomendadas
Validação de Dados – Hibernate Validator, Pydantic. Análise de Conformidade – TrustArc, OneTrust. Anonimização de Dados – Python Faker, ARX Data Anonymization Tool.
|
|
|
Testes e Avaliações Iniciais
Auditoria no Repositório – revise as estruturas e configurações do ambiente de armazenamento de dados pessoais, o objetivo é garantir que informações confidenciais estão protegidas adequadamente. Ataques Simulados - Simular ataques como a interceptação de dados em trânsito e acesso não autorizados, para testar as ferramentas e configurações de defesa. Auditoria de Conformidade - Validar a conformidade das práticas definidas para o proejto, com LGPD, GDPR e normas ISO. Testes de penetração focados em dados pessoais, tratando, por exemplo, de exploração de entradas não validadas. Análise dinâmica e estática de vulnerabilidades. Revisão programada do status de conformidade legal com simuladores de auditoria.
|
|
|
Referências técnicas
ISO/IEC 27034 – Segurança para Processos de Desenvolvimento de Aplicações. LGPD e GDPR – Regulamentações de Proteção de Dados. OWASP Top 10 – A10 - Falhas em Proteção de Dados.
|
|
Este documento teve como foco principal a validação dos dados de entrada, tendo como referência o Guia de Melhores Práticas de Codificação Segura OWASP. Além disso, ele propôs o alinhamento com a abordagem do DevSecOps, visando assegurar a integridade, confidencialidade e disponibilidade dos dados sensíveis no contexto da saúde. Com essa iniciativa, o Ministério da Saúde e o DATASUS fortalecem a segurança e protegem os dados sensíveis de maneira efetiva. A revisão regular das práticas e a atualização de acordo com as melhores práticas e tendências de segurança são fundamentais para garantir a proteção contínua dos dados. A segurança é uma responsabilidade compartilhada por toda a equipe, que deve estar comprometida em seguir essas práticas para garantir a integridade, confidencialidade e disponibilidade dos dados.
Referências
ISO/IEC 27001: Sistema de Gestão de Segurança da Informação.
OWASP Secure Coding Practices: https://owasp.org/.
NIST SSDF: Secure Software Development Framework.
SAFECode: Fundamental Practices for Secure Software Development.
LGPD e GDPR: Regulamentações de proteção de dados pessoais.