Introdução
Com o compromisso de manter a integridade dos dados sensíveis e a privacidade dos cidadãos ao manipular vários tipos e níveis de informações públicas, o Ministério da Saúde apresenta o Guia de Desenvolvimento Seguro para seus projetos e aplicações e nesta quarta entrega, serão tratados os requisitos para a Codificação de Dados de Saída. Este guia é resultado de uma abordagem abrangente, como os padrões definidos pela Open Web Application Security Project (OWASP), a metodologia Security by Design, a privacidade orientada por meio de Privacy by Design, a cultura de desenvolvimento seguro com DevSecOps e a conformidade com a Lei Geral de Proteção de Dados (LGPD).
Nosso objetivo principal é garantir a confiabilidade, confidencialidade e disponibilidade dos sistemas que envolvem informações cruciais relacionadas à saúde pública. Ao alinhar as melhores práticas de codificação segura apresentadas pelo OWASP, promovemos a resistência contra diversas vulnerabilidades comuns, como Cross-Site Scripting (XSS), Injeção de SQL, entre outras, assegurando o máximo possível de imunidade contra ataques maliciosos.
A abordagem Security by Design incorporada em nosso guia coloca a segurança no centro de cada etapa do ciclo de desenvolvimento, tornando-a inerente ao projeto desde o seu início. Combinado com a premissa de Privacy by Design, o guia também visa garantir a proteção dos dados pessoais dos cidadãos desde a concepção até o pleno uso dentro dos ambientes desenvolvidos, respeitando os princípios de minimização de dados, finalidade, e consentimento explícito, conforme preconizado pela LGPD.
Para atingir esses objetivos, incentivamos fortemente a adoção do modelo DevSecOps, onde a segurança é integrada ao processo de desenvolvimento de software desde a fase de concepção até a implantação. Isso permite que nossas equipes de desenvolvimento, operações e segurança colaborem de maneira proativa, identificando e corrigindo vulnerabilidades de forma contínua e consistente. Sendo assim, este guia nos mostrará as práticas recomendadas, referente à Codificação de Dados de Saída.
Objetivos do Documento
O objetivo principal em tratar a codificação de dados de saída é garantir a segurança e a integridade dos dados apresentados ou transmitidos pela aplicação, evitando vulnerabilidades e protegendo contra ataques maliciosos.
Definir diretrizes práticas e aplicáveis para a codificação de dados de saída em aplicações seguras. Apresentar ferramentas e frameworks homologados que facilitem a aplicação das diretrizes estabelecidas. Garantir a conformidade com normas, legislações e boas práticas do mercado, alinhando-se aos princípios de proteção de dados pessoais e segurança da informação. Orientar equipes de desenvolvimento e segurança no uso eficiente de linguagens e frameworks (Angular, React, Vue, Java, Node e Python) para prevenir vulnerabilidades.
Práticas Recomendadas
Neste documento o DATASUS apresenta e difunde a adoção de um conjunto importante de práticas recomendadas pelo OWASP para Codificação de Dados de Saída, que pode ser aplicado em todas as etapas do ciclo de desenvolvimento seguro. Estas práticas ressaltam a importância de efetuar a codificação dos dados em ambientes confiáveis, utilizando-se de rotinas padronizadas e certificadas por meio de testes para cada tipo de codificação de saída.
Além disso, é extremamente relevante codificar os dados baseados em contexto, visando a prevenção de falhas em casos específicos, e a necessidade de codificar todos os caracteres, a menos que sejam considerados seguros para o interpretador de destino. O tratamento (limpeza) de dados provenientes de fontes não confiáveis é também enfatizado, especialmente quando usados para construir consultas SQL, XML e LDAP, bem como o tratamento dos dados provenientes de fontes não confiáveis que geram comandos para o sistema operacional. O DATASUS, ao seguir estas práticas, irá mitigar efetivamente as vulnerabilidades de segurança, protegendo o software contra possíveis ameaças e ataques maliciosos.
A inclusão destas diretrizes no processo de desenvolvimento seguro no ambiente do Ministério da Saúde reforça a importância da programação segura e garante um ambiente confiável.
Descrição da Implantação do Processo de Codificação de Dados de Saída
Identificar os contextos onde os dados de saída serão usados.
Mapear requisitos legais e normativos que afetam a manipulação de dados.
Incorporar bibliotecas de codificação seguras desde o design inicial do projeto.
Planejar validações específicas para os diferentes contextos.
Garantir a utilização de métodos específicos para codificação baseados no contexto, como, por exemplo, tratando a codificação para HTML em frameworks front-end como Angular e React.
Realizar testes automatizados e manuais para verificar a correta codificação de dados de saída.
Utilizar ferramentas como OWASP ZAP, Burp Suite, e verificadores estáticos de código.
Monitorar e atualizar bibliotecas seguras de codificação regularmente para evitar dependências vulneráveis.
Integrar logs de monitoramento que estejam devidamente codificados para evitar vazamentos de informações sensíveis.
ETAPAS DO DESENVOLVIMENTO SEGURO
|
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 a prevenção de vulnerabilidades de injeção, e manipulação insegura de dados. Aplicar técnicas que garantam a conformidade com normas e frameworks de segurança. Além de traças todas as táticas de segurança desde o início do projeto. |
|
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 Especificação de Requisitos Funcionais e Não Funcionais. Análise de Impacto de Proteção de Dados (DPIA) para conformidade com normas e frameworks. Matriz de Riscos de Segurança. |
|
|
O que é necessário definir nessa etapa
Contextos de saída (HTML, XML, JSON, logs). Formatos e padrões de dados sensíveis. Regras de codificação e sanitização para cada contexto.
|
|
|
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: Documentação Técnica Detalhada de Requisitos de Codificação, com modelos de aplicação. Lista de ferramentas e bibliotecas recomendadas para a implantação dos processos de Codificação de Dados de Saída. Matriz de Responsabilidades.
|
|
|
Quem é responsável pela entrega
Coordenação de Desenvolvimento -Engenheiros de Software e Arquitetos de Segurança
|
|
|
Práticas recomendadas para o Levantamento de Requisitos
Aplicar padrões de frameworks como OWASP ASVS e NIST SSDF. Realizar sessões colaborativas entre DPO, desenvolvedores e analistas de segurança. Criar cenários de uso específicos para dados de saída.
|
|
|
Ferramentas recomendadas
IDEs – IntelliJ IDEA, PyCharm, Visual Studio Code. Ferramentas para Análise Estática – SonarQube, Checkmarx. Ferramentas para Rastreamento de Requisitos – Jira, Confluence.
|
|
|
Testes e Avaliações Iniciais
Testes de segurança nos fluxos de saída usando OWASP ZAP ou Burp Suite. Testes unitários para codificação e revisão de saída. Análise estática e dinâmica de segurança (SAST/DAST).
|
|
|
Referências técnicas
ISO/IEC 27034 – Segurança da Informação para Processos de Desenvolvimento de Aplicações. OWASP Secure Coding Practices. SAFECode – Fundamental Practices.
|
|
|
SECURITY BY DESIGN |
|
|
Quando deve acontecer
Após o levantamento de requisitos, durante a fase de projeto e arquitetura do sistema, antes da codificação. |
Por que deve ser feito
Para tratar e garantir a aplicação de práticas de segurança no design da aplicação desde o início. Fazer com que a prevenção de vulnerabilidades seja parte inerente das ações do projeto. |
|
Quem define os Atores e Ações da Etapa de Design Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução. Arquiteto de Software e Arquiteto de Segurança, Engenheiro de Software e DPO |
Quem define os Atores responsáveis pela Validação dos processos da Etapa de Design Coordenação de Desenvolvimento e Coordenação de Segurança Equipe de Desenvolvimento e Arquitetos de Segurança. |
|
Quais os documentos necessários para a etapa de Security by Design
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações de requisitos de segurança, definidos na etapa anterior (Levantamento de Requisitos). Especificação de Requisitos Funcionais e Não Funcionais. Documentação de Fluxo de Dados (DFD) para saída de dados. Plano de Controle de Segurança e Matriz de Responsabilidades.
|
|
|
O que precisamos definir na Etapa de Security by Design
Bibliotecas e frameworks a serem utilizados para codificação de saída. Diretrizes específicas para cada contexto de saída - HTML, JSON, XML, logs.
|
|
|
O que precisamos entregar para a próxima etapa (Execução Segura)
Relatório ou Plano de Design de Sistema Atualizado - Incluindo especificações detalhadas de controles definidos e aplicados. Com as seguintes referências: Guia de Estrutura de Codificação de Dados de Saída com exemplos práticos. Prova de conceito de soluções aplicadas ao design. Lista de bibliotecas seguras a serem usadas.
|
|
|
Quem é responsável pela entrega Coordenação de Desenvolvimento – Arquiteto de Soluções e Engenheiros de Software. |
|
|
Práticas recomendadas para o Security by Design Usar modelos arquiteturais seguros como o OWASP Secure Coding Practices. Incorporar padrões de codificação para cada linguagem. Definir contratos claros entre módulos que processam dados. |
|
|
Ferramentas recomendadas IDEs – IntelliJ IDEA, PyCharm, Visual Studio Code (Angular, React, Node.js). Ferramentas de modelagem – Lucidchart, Draw.io para DFDs. Análise estática – SonarQube, Checkmarx. |
|
|
Testes e Avaliações Iniciais Revisões de design (Design Review) focadas em fluxos de dados. Prototipação de soluções com validação contra vulnerabilidades comuns usando OWASP ZAP ou Burp Suite. |
|
|
Referências técnicas ISO/IEC 27034 – Segurança da Informação 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
Para tratar a prevenção de vulnerabilidades como e garantir a aplicação de padrões de codificação definidos nas fases anteriores. |
|
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. Equipes de Desenvolvimento, Infraestrutura e 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 Qualidade, Arquiteto de Software e Arquiteto de 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. Guia de Codificação Segura – entregue na Etapa de Design. Especificação de Contextos de Saída - HTML, JSON, XML, logs. Plano de Testes Unitários e Integrados para codificação de saída.
|
|
|
O que precisamos definir na Etapa de Execução Segura Parâmetros específicos de codificação e revisão para cada linguagem utilizada. Validação e escape de dados em todas as saídas geradas pela aplicação. |
|
|
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: Código desenvolvido com estrutura segura para cada contexto de saída. Resultados dos testes unitários e integrados, incluindo logs de validação 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 Aplicar validação e escape de dados na camada mais próxima de saída. Evitar confiar exclusivamente no cliente para sanitização com o foco nos frameworks front-end como Angular e React. |
|
|
Ferramentas recomendadas Ferramentas de análise estática – SonarQube, Checkmarx. Bibliotecas de codificação de saída – OWASP Java Encoder, html.escape, xss. IDEs – IntelliJ IDEA, PyCharm, Visual Studio Code. |
|
|
Testes e Avaliações Iniciais Testes unitários automatizados para verificar a sanitização de dados de saída. Testes dinâmicos de segurança (DAST) usando ferramentas como OWASP ZAP e Burp Suite. |
|
|
Referências técnicas ISO/IEC 27034 – Segurança da Informação para Processos de Desenvolvimento de Aplicações. OWASP Secure Coding Practices. SAFECode – Fundamental Practices. |
|
|
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 buscar e identificar possíveis vulnerabilidades na codificação de dados de saída. Realizar a verificação quanto à aderência aos padrões e normas de segurança definidos. |
|
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. Desenvolvimento e Equipe 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 de Contextos de Saída – definidas na Etapa de Design. Plano de Testes de Segurança. Relatório de Riscos – com especificações e detalhamento das superfícies críticas para os testes. |
|
|
O que precisamos definir na Etapa de Teste de Segurança Fluxos críticos de saída que requerem validação rigorosa (ex.: respostas em HTML, APIs JSON). - Tipos de testes a serem realizados (estáticos, dinâmicos, manuais e automatizados). |
|
|
O que precisamos entregar para a próxima etapa (Gerenciamento) Relatório dos Testes de Segurança, contendo: Relatórios detalhados dos testes de segurança, com vulnerabilidades identificadas, análise de impacto e recomendações de correção. - Lista de ações prioritárias para remediação. |
|
|
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 Realizar análise estática (SAST) e dinâmica (DAST) de segurança. Simular ataques reais (Penetration Testing) focados em fluxos de saída. Validar dados em diferentes contextos (HTML, XML, JSON). |
|
|
Ferramentas recomendadas Análise Estática: SonarQube, Checkmarx. Análise Dinâmica: OWASP ZAP, Burp Suite. Testes com Técnicas de Fuzzing: Ferramentas como AFL ou Peach Fuzzer para entradas inesperadas em saídas críticas. |
|
|
Testes e Avaliações Iniciais Testes de Penetração – Realizar testes de penetração buscando vulnerabilidades, e riscos que possam ser corrigidos ou mitigados. 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 de Penetração focados em XSS e injeções. Testes de desempenho para garantir que a codificação não impacte a eficiência. Testes de logs para garantir anonimização de dados sensíveis. |
|
|
Referências técnicas ISO/IEC 27034 – Segurança da Informação para Processos de Desenvolvimento de Aplicações. OWASP Testing Guide SAFECode – Fundamental Practices. |
|
|
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
Para garantir continuidade do uso de práticas seguras relacionadas à codificação de dados de saída. Tratar a prevenção da introdução de novas vulnerabilidades durante procedimentos de atualizações ou manutenção. |
|
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 e Segurança. |
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.
|
|
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. Relatório de Testes de Segurança (resultados da etapa anterior). Registro de Mudanças (Change Management). Matriz de Riscos e Controle de Conformidade. |
|
|
O que precisamos definir na Etapa de Gerenciamento
Planos de atualização e correção para bibliotecas e frameworks usados na codificação de saída. Políticas de gerenciamento de mudanças e controles para validação de segurança em alterações. |
|
|
O que precisamos entregar para a próxima etapa (Monitoramento)
Relatório ou Planos de Gerenciamento de Segurança, contendo: Planos de monitoramento contínuo para detecção e prevenção de vulnerabilidades em tempo real. Relatórios de conformidade e controle de segurança atualizados para auditorias.
|
|
|
Quem é responsável pela entrega
Coordenação de Desenvolvimento – Equipe de Desenvolvimento e Segurança e DPO |
|
|
Práticas recomendadas para os Testes de Segurança
Utilizar práticas de DevSecOps para integrar segurança ao pipeline de desenvolvimento. Realizar revisões periódicas das bibliotecas e dependências de codificação de saída
|
|
|
Ferramentas recomendadas
Gerenciamento de dependências – Snyk, Dependabot. Automação de pipelines – Jenkins, GitLab CI/CD. Controle de mudanças – Jira, ServiceNow. Análise contínua – SonarQube, OWASP Dependency-Check.
|
|
|
Testes e Avaliações Iniciais
Testes regressivos de segurança após cada mudança de código. - Reanálise periódica de riscos com ferramentas de análise dinâmica (DAST).
|
|
|
Referências técnicas
ISO/IEC 27001 – Sistema de Gestão de Segurança da Informação. NIST SSDF – Secure Software Development Framework. OWASP SAMM – Maturity Model. SAFECode – Fundamental Practices.
|
|
|
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 corrigir vulnerabilidades relacionadas à codificação de dados de saída em tempo real. - Garantir a conformidade contínua com padrões de segurança e legislações, como LGPD e 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 Desenvolvimento, Segurança, Operações, Qualidade e Auditores Internos (ou externos). |
|
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 de Segurança. Relatórios de Auditoria Interna. Logs de execução detalhados, incluindo registros de codificação de saída e alertas de segurança. |
|
|
O que precisamos definir na Etapa de Teste de Segurança
Métricas de monitoramento, como tempo médio para detecção de vulnerabilidades (MTTD). Políticas de retenção e anonimização de logs para proteção de dados sensíveis.
|
|
|
O que precisamos entregar
Relatório de Incidentes de Segurança, incluindo: Relatórios de monitoramento com análise de tendências e padrões. Alertas configurados para possíveis falhas na codificação de saída.
|
|
|
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
Utilizar monitoramento contínuo com ferramentas integradas ao pipeline (DevSecOps). Realizar auditorias regulares para verificar a integridade dos dados de saída. Configurar alertas baseados em regras específicas (SIEM).
|
|
|
Ferramentas recomendadas para o projeto
Monitoramento contínuo – Splunk, ELK Stack (Elasticsearch, Logstash, Kibana). Detecção de vulnerabilidades – Snyk, Dependabot. SIEM (Security Information and Event Management) – QRadar, Azure Sentinel.
|
|
|
Testes e Avaliações Iniciais
Simulação de Falhas - Simular eventos de falha. 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. Ataques Simulados – A equipe deverá simular ataques para validar a detecção de falhas (Testes de Penetração). Monitoramento Contínuo de Logs – Análise contínua de logs para verificar a sanitização e codificação correta.
|
|
|
Referências técnicas
ISO/IEC 27001 – Sistema de Gestão de Segurança da Informação. NIST SSDF – Secure Software Development Framework. OWASP SAMM – Maturity Model. SAFECode – Fundamental Practices.
|
|
|
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. Minimizar riscos de exposição de dados por XSS ou injeções. |
|
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) Instrumentos Normativos de Proteção de Dados Pessoais – em conformidade com a LGPD e o GDPR, abrangendo políticas, diretrizes e procedimentos para o ciclo de vida dos dados. Plano de Resposta a Incidentes de Segurança envolvendo Dados Pessoais – contemplando procedimentos de detecção, contenção, erradicação, recuperação e notificação, em alinhamento com as obrigações de comunicação à Autoridade Nacional de Proteção de Dados (ANPD) e aos titulares, conforme previsto na LGPD e GDPR. Avaliação de Impacto à Proteção de Dados Pessoais (AIPD/DPIA) – Tratando a identificação, análise e avaliação dos riscos potenciais ao tratamento de dados pessoais, com a finalidade de aplicar medidas de mitigação e demonstrar conformidade com os artigos 38 da LGPD e 35 do GDPR. Inventário e Classificação de Dados Pessoais – Documento de mapeamento e classificação de dados pessoais, incluindo a identificação de bases legais e medidas de segurança, em alinhamento com a LGPD e GDPR. |
|
|
O que precisamos definir nesta tapa
Contextos em que dados pessoais serão exibidos ou processados. Políticas de Anonimização e Pseudonimização de dados em saídas da aplicação. Regras personalizadas para revisão, sanitização e escape de dados antes de exibi-los em logs ou interfaces. Exemplos de Procedimentos de Sanitização Remover tags HTML de um texto para evitar ataques de Cross-Site Scripting (XSS). Remover caracteres especiais que podem ser usados em injeções SQL. Converter caracteres de controle para suas representações de escape. Validar se os dados estão dentro de um formato esperado (ex: um número de telefone tem o formato correto). Exemplos de Procedimentos de Escape de Dados Em HTML, o caractere < é escapado para <, o > para >, o & para & e as aspas " para ". Assim, se você quiser exibir o texto <script> na tela, você deve usar <script>. Em SQL, as aspas simples ' são escapadas para ' ' (duas aspas simples) para evitar injeções SQL.
|
|
|
Artefatos a serem gerados nessa etapa
Relatórios e Evidências de Conformidade – Conjunto de artefatos documentais que evidenciam a conformidade com leis e normas regulatórias de proteção de dados pessoais, LGPD e GDPR, incluindo, mas não se limitando a, inventários, DPIAs/AIPDs, políticas, registros e relatórios de incidentes. Reporte do Uso de Ferramentas de Monitoramento – Uso de ferramentas SIEM com regras de correlação e alertas configuradas para detecção proativa de potenciais exposições de dados pessoais, incluindo monitoramento de logs, anomalias e vulnerabilidades. Logs de Segurança Anonimizados ou Pseudonimizados – armazenados em ambiente controlado com acesso restrito, em observância aos princípios da LGPD e GDPR. |
|
|
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 técnicas de anonimização ou pseudonimização de dados pessoais em registros de auditoria e relatórios, utilizando métodos como generalização, supressão, randomização ou substituição por tokens não reversíveis, garantindo a desvinculação irreversível ou a dissociação controlada dos dados em relação aos seus titulares, em conformidade com os princípios da minimização de dados e da finalidade previstos na LGPD e GDPR. Realizar tratamento de erros que previna a divulgação de informações sensíveis a usuários finais, com registro detalhado em logs anonimizados para análise interna, em conformidade com a LGPD/GDPR. Adotar práticas de codificação segura, seguindo as diretrizes do OWASP, para mitigar vulnerabilidades como XSS e SQL Injection, garantindo a proteção dos dados em conformidade com a LGPD/GDPR. |
|
|
Ferramentas recomendadas
Monitoramento de Dados – Splunk, ELK Stack. Ferramentas de Análise Estática e Dinâmica – SonarQube, Checkmarx. Testes de Conformidade – TrustArc, OneTrust. Gestão de Logs – Fluentd, Logstash.
|
|
|
Testes e Avaliações Iniciais
Avaliação da Segurança do Repositório de Dados Pessoais – Conduzir uma auditoria técnica abrangente da infraestrutura de armazenamento de dados pessoais, incluindo a análise de configurações de segurança física e lógica, controles de acesso (RBAC, ABAC), criptografia em repouso e em trânsito, políticas de backup e recuperação, gestão de vulnerabilidades e conformidade com padrões de segurança reconhecidos (ex: ISO 27001, NIST Cybersecurity Framework). O objetivo é verificar a adoção de medidas de segurança adequadas para proteger a confidencialidade, integridade e disponibilidade das informações confidenciais. Testes de Penetração e Simulação de Ameaças – Executar testes de penetração (Pentest) e simulações de ataques direcionados a cenários de interceptação de dados em trânsito (ex: ataques Man-in-the-Middle) e tentativas de acesso não autorizados (ex: exploração de vulnerabilidades de autenticação e autorização). O objetivo é avaliar a eficácia dos controles de segurança implementados, identificar vulnerabilidades exploráveis e validar a capacidade de detecção e resposta a incidentes. Auditoria de Conformidade – Validar conformidade com LGPD, GDPR e normas ISO (ex: ISO 27001, ISO 27701), avaliando políticas, procedimentos e controles de segurança da informação e proteção de dados. Análise de Vulnerabilidades com Ênfase em Exposição de Dados Pessoais – Realizar testes de vulnerabilidade, incluindo testes de penetração (Pentest), análise de código estática e dinâmica, e testes de fuzzing, com o objetivo específico de identificar vulnerabilidades que possam resultar em vazamento ou acesso não autorizado a dados pessoais, como injeções (SQL, XSS, etc.), falhas de autenticação e autorização, e exposição de dados sensíveis em APIs ou interfaces web. Validar das Técnicas de Anonimização/Pseudonimização – Avaliar a eficácia das técnicas de anonimização/pseudonimização aplicadas em logs, assegurando a impossibilidade ou a dificuldade controlada de reidentificação dos titulares. Testes de Conformidade com LGPD/GDPR em Saídas da Aplicação – Utilizar simuladores de auditoria para testar a conformidade das saídas da aplicação com os requisitos da LGPD/GDPR relacionados à transparência, minimização, finalidade, segurança e direitos dos titulares.
|
|
|
Referências técnicas
ISO/IEC 27001 – Sistema de Gestão de Segurança da Informação. ISO/IEC 29100 – Estrutura para proteção da privacidade. OWASP Privacy Risks SAFECode – Fundamental Practices.
|
|
Considerações Finais
Este documento teve como foco principal a codificação de dados de saída, 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 27034: Segurança da Informação para Processos de Desenvolvimento de Aplicações.
OWASP: https://owasp.org
NIST Secure Software Development Framework (SSDF): https://csrc.nist.gov/publications
OWASP Java Encoder Project: https://owasp.org/projects/
LGPD e GDPR: Regulamentações sobre proteção de dados pessoais.
SAFECode Fundamental Practices: https://www.safecode.org