Proteger os dados é parte crítica do processo de desenvolvimento seguro de software, para atender e tratar corretamente está parte sensível do processo é vital envolver medidas técnicas e organizacionais para garantir a confidencialidade, integridade e disponibilidade de dados pessoais e sensíveis. Este capítulo aborda as melhores práticas e diretrizes para que a proteção de dados seja devidamente integrada em cada etapa do ciclo de vida do desenvolvimento de software (SSDLC), assegurando conformidade com regulamentações como LGPD e GDPR e aderência às normas internacionais de segurança.
Objetivos do Documento
Apresentar meios de garantir a conformidade regulatória, atendendo requisitos legais de proteção de dados pessoais, como LGPD e GDPR. Mitigar riscos relacionados protegendo os dados contra acessos não autorizados, vazamentos e incidentes de segurança relacionados. Integrar segurança no ciclo de desenvolvimento, aplicando práticas de proteção de dados desde o levantamento de requisitos até o monitoramento contínuo. Além de promover responsabilidade e transparência, montando parâmetros e meios de garantir que os desenvolvedores e equipes de segurança compreendam e apliquem medidas eficientes e eficazes de proteger os dados tratados nas aplicações.
Práticas Relacionadas
Algumas práticas ou ações relacionadas à Proteção de Dados figuram como de alta prioridade, tendo como objetivo proteger os dados sensíveis e pessoais em todo o ciclo de vida (coleta, armazenamento, processamento e descarte), prevenindo vazamentos e acessos indevidos. Relacionamos aqui 12 dessas práticas:
Aplicar Política de Privilégio Mínimo
Ação: Restringir acessos a dados e funcionalidades para usuários, sistemas e processos ao que seja exclusivamente necessário à sua função.
Objetivo: Reduzir o impacto de contas comprometidas e evita acessos indevidos a dados sensíveis.
Exemplo: Configurar permissões baseadas em funções (RBAC) para acessar bancos de dados.
Ferramentas: IAM (Identity and Access Management), como AWS IAM ou Azure AD.
Proteção Contra Acesso Não Autorizado a Cópias Temporárias ou em Cache
Ação: Aplicar proteções em diretórios temporários ou coibir o armazenamento em cache de informações sensíveis.
Exemplo: Configurar diretórios temporários no sistema com permissões restritas.
Tratar cabeçalhos HTTP, com referências como Cache-Control: no-store.
Objetivo: Dados sensíveis em arquivos temporários ou em cache podem ser acessados por usuários não autorizados ou explorados em ataques.
Criptografar Informações Altamente Sensíveis
Ação: Utilizar algoritmos robustos como AES-256 para dados em repouso e TLS 1.3 para dados em trânsito.
Exemplo: Criptografar campos de banco de dados que armazenam informações financeiras.
Objetivos: Proteger dados para o caso de possíveis vazamentos ou acessos indevidos.
Proteger o Código-Fonte no Servidor
Ação: Impor controle de acesso ao código-fonte por meio de sistemas de versionamento seguros e gerenciamento de permissões.
Exemplo: Configurar repositórios Git privados e autenticação multifatorial (MFA).
Objetivo: Impedir acesso indevido a credenciais, endpoints ou outras informações sensíveis presentes no código.
Não Armazenar Informações Confidenciais em Texto Claro/Legível no Lado Cliente
Ação: Tratar dados apresentados no Front-end, buscando evitar a exposição de informações sensíveis para o cliente.
Exemplo: Utilizar tokens de acesso temporários em vez de credenciais armazenadas no navegador.
Objetivo: Evitar que dados armazenados, ou expostos, no lado cliente sejam acessados ou manipulados por atacantes.
Remover Comentários do Código de Produção
Ação: Excluir comentários que contenham informações como credenciais de acesso, referências de endpoints internos e dados técnicos que podem beneficiar possíveis atacantes.
Ferramenta: ESLint (JavaScript) para verificar código em busca de comentários.
Objetivo: Impedir que comentários com informações sensíveis ou técnicas sejam expostos o que poderia aumentar riscos de exploração.
Remover Aplicações Desnecessárias e Documentação Excedente do Sistema
Ação: Desinstalar softwares, ferramentas de debugging, além de arquivos de documentação não utilizados.
Exemplo: Remover páginas de teste e APIs públicas expostas durante o desenvolvimento.
Objetivo: Evitar que quaisquer componentes desnecessários sejam utilizados como vetores de ataque.
Não Incluir Informações Sensíveis nos Parâmetros de Requisição HTTP GET
Ação: Conter o uso de URLs para transmitir informações sensíveis.
Exemplo: Usar requisições HTTP POST com payload criptografado em vez de incluir tokens em parâmetros GET.
Objetivo: Impedir que parâmetros em URLs sejam armazenados em logs de servidores ou cache de navegadores, o que poderia levar a exposição de dados.
Desativar a Funcionalidade de Autocompletar em Formulários
Ação: Configurar campos de formulário para desativar funções relacionadas ao autocompletar.
Exemplo: Atributo autocomplete="off" em formulários HTML.
Objetivo: Impedir que navegadores armazenem dados sensíveis como senhas ou informações bancárias.
Desativar o Cache no Lado Cliente para Páginas com Informações Sensíveis
Ação: Configurar cabeçalhos HTTP para impedir o cache de páginas sensíveis.
Exemplo: Cache-Control: no-store.
Objetivo: Proteger dados que de alguma forma possam ser recuperados por invasores em sistemas compartilhados.
Suporte à Remoção de Dados Sensíveis Quando Não Forem Mais Necessários
Ação: Utilizar funcionalidades que permitam exclusão segura de dados.
Exemplo: Usar comandos como ‘DELETE’ em bancos de dados e sobrescrever dados antes do descarte.
Objetivo: Bloquear eventos de retenção desnecessária de dados, conforme exigido por regulamentações como LGPD e GDPR.
Aplicar Mecanismos de Controle de Acesso Apropriados para Dados Sensíveis
Ação: Usar autenticação forte e autorização baseada em funções (RBAC) para restringir acessos.
Ferramentas: Keycloak, OAuth 2.0.
Objetivo: Minimizar riscos de exposição de dados sensíveis a usuários não autorizados.
Descrição da Implantação do Processo de Proteção de Dados
Testes automatizados e manuais: Validar a eficácia das medidas de proteção, incluindo a verificação de anonimização, criptografia e controles de acesso.
Testes de conformidade: Assegurar que os dados processados estão alinhados aos requisitos regulatórios.
Testes de vulnerabilidade: Identificar brechas que possam comprometer a segurança dos dados.
Na fase inicial do ciclo de vida do software, antes da criação da arquitetura e da definição de funcionalidades.
Por que deve ser feito
Visando identificar os dados pessoais e sensíveis que a aplicação irá processar, garantindo conformidade com LGPD/GDPR e prevenindo riscos de segurança e privacidade.
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.
Gestor de Projeto, DPO, Engenheiro de Software, Analista de Negócios, Arquiteto de Segurança.
Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança
DPO, Arquiteto de Soluções de Segurança e Analista Sênior de Segurança validam os requisitos levantados com base em regulamentações (LGPD/GDPR) e padrões técnicos (ISO/IEC 27001, OWASP, NIST).
Quais os documentos necessários para a etapa de Levantamento de Requisitos
Política de Segurança - Baseada na ISO/IEC 27001 e ISO/IEC 27002.
Mapeamento de Dados - Identificação de dados pessoais ou sensíveis e fluxos (Data Flow Diagrams – DFD).
Modelo de Ameaças - Ameaças documentadas usando OWASP Threat Dragon ou similar.
Requisitos Funcionais e Não Funcionais - Requisitos relacionados à proteção de dados, como anonimização, criptografia e logs seguros.
O que é necessário definir nessa etapa
Fluxos de Dados: Identificar pontos de coleta, armazenamento, processamento e descarte.
Classificação dos Dados: Determinar categorias de dados (pessoal, sensível, confidencial).
Políticas de Retenção: Definir prazos e critérios para retenção e descarte de dados.
Restrições Legais e Contratuais: Definir o que é necessário para conformidade com LGPD/GDPR.
Controles de Segurança: Requisitos técnicos aplicados aos métodos para uso de criptografia, controle de acesso e auditoria.
O que precisamos entregar para a próxima etapa (Security by Design)
Documentação de Requisitos de Segurança e Privacidade: Requisitos detalhados, incluindo controles específicos para proteção de dados.
Relatório de Classificação de Dados: Dados categorizados e priorizados para proteção.
Lista de Controles de Segurança: Controles necessários para a próxima etapa (Security by Design), como algoritmos de criptografia, padrões de segurança para APIs, entre outros.
Quem é responsável pela entrega
Coordenação de Desenvolvimento -Engenheiro de Software: Detalhamento técnico dos requisitos. - Arquiteto de Segurança: Requisitos de proteção de dados mapeados para controles técnicos. - DPO: Validação dos requisitos de privacidade e conformidade.
Práticas recomendadas para o Levantamento de Requisitos
Privacy by Design: Incorporar privacidade desde o início.
Participação Multidisciplinar: Envolver todas as partes interessadas para garantir requisitos completos e exequíveis.
Análise de Impacto de Dados (DPIA): Identificar riscos associados ao processamento de dados pessoais.
Modelagem de Ameaças: Utilizar frameworks como STRIDE e ferramentas OWASP.
Ferramentas recomendadas
Lucidchart/Diagrams.net: Para criação de Data Flow Diagrams (DFD).
OWASP Threat Dragon: Modelagem de ameaças.
Git/GitHub Projects: Para versionamento e rastreamento de requisitos.
Jira/Confluence: Gestão de tarefas e documentação colaborativa.
Testes e Avaliações Iniciais
Revisão de Conformidade Legal: Validar os requisitos legais com o DPO.
Análise de Ameaças: Avaliar os pontos de vulnerabilidade inicial nos fluxos de dados.
Teste de Prova de Conceito (PoC): Verificar viabilidade técnica dos requisitos levantados, como integração de criptografia e validações de entradas.
Referências técnicas
ISO/IEC 27001: Gestão de segurança da informação.
ISO/IEC 27034: Segurança no desenvolvimento de aplicações.
OWASP Top 10
LGPD/GDPR
SAFECode: Práticas fundamentais de segurança.
¶Exemplo de Mapeamento em Fluxo de Dados para Aplicação de Saúde: Acesso a Medicamentos Fornecidos pelo SUS
Levando em consideração um modelo hipotético de aplicação desenvolvida em Node.js no back-end e Angular no front-end, que gerencia o acesso a medicamentos fornecidos pelo SUS. Essa aplicação é destinada a pacientes e profissionais de saúde, processando dados pessoais e sensíveis, como informações médicas e de prescrição.
AES-256 para dados armazenados; TLS 1.3 para comunicação segura entre cliente e servidor.
Minimização de Dados
Coletar apenas os dados extremamente necessários para cada funcionalidade (e.g., CPF para identificação, CID para prescrição).
Controle de Acesso
Utilizando RBAC (Role-Based Access Control): - Administração: Operadores do sistema. - Profissionais de saúde: Médicos e farmacêuticos. - Usuários: Pacientes.
Retenção e Descarte
Dados de prescrição retidos por 05 anos, com anonimização obrigatória após esse período. Dados de acesso e logs retidos por 01 ano.
Logo após o levantamento de requisitos e antes do desenvolvimento e da execução da aplicação, na fase de planejamento e design da aplicação.
Por que deve ser feito
Para garantir que os princípios de segurança e proteção de dados sejam incorporados desde o início, reduzindo riscos e evitando retrabalho ou falhas de conformidade com LGPD, GDPR e normas ISO.
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.
Engenheiro de Software, Arquiteto de Segurança, Analista de Segurança, DPO.
Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança
Arquiteto de Segurança e Soluções e DPO.
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, definido na etapa anterior (levantamento de requisitos)
Arquitetura de Software - Desenho técnico da solução com controles definidos.
Modelo de Ameaças - Mapas de ameaças documentados, como STRIDE ou LINDDUN.
Plano de Mitigação de Riscos - Listagem de contramedidas e controles necessários para proteção de dados.
O que precisamos definir na Etapa de Security by Design
Controles de Segurança - Requisitos específicos, como criptografia, autenticação, e controle de acesso.
Segurança de Dados - Estruturas para proteger dados em trânsito, em repouso e em uso.
Segurança de APIs - Políticas e padrões para interfaces seguras.
Auditoria e Rastreamento - Definição de logs seguros e rastreamento de atividades.
Resiliência e Recuperação - Estratégias para lidar com falhas e ataques.
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.
Políticas de Segurança - Definições para autenticação, criptografia e acessos mínimos.
Planos de Testes de Segurança - Casos de teste preparados para a próxima etapa de execução segura.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Engenheiro de Software,Arquiteto de Segurança e o DPO da organização.
Práticas recomendadas para o Security by Design
Princípio de Menor Privilégio - Definir permissões mínimas para usuários e sistemas.
Segurança por Design - Incorporar controles desde o início do projeto.
Segregação de Dados – Utilizar práticas e ferramentas de isolamento para dados sensíveis.
Modelo de Ameaças - Utilizar STRIDE para ameaças gerais ou LINDDUN para privacidade.
Teste de Conceito - Validar antecipadamente a viabilidade técnica de controles críticos, como criptografia ou autenticação forte.
Ferramentas recomendadas
OWASP Threat Dragon - Para modelagem de ameaças.
Lucidchart/Diagrams.net - Para diagramas de arquitetura.
SonarQube - Análise de segurança de código.
SecureHeaders - Utilização de cabeçalhos seguros.
Testes e Avaliações Iniciais
Revisão de Design - Avaliação do design técnico com base em normas ISO e boas práticas OWASP.
Teste de Modelagem de Ameaças - Validar se as ameaças identificadas têm contramedidas adequadas.
Validação Técnica: Verificação da viabilidade dos controles (e.g., configuração de TLS ou aplicações de hashing).
Referências técnicas
ISO/IEC 27034 - Segurança no desenvolvimento de aplicações.
Durante o desenvolvimento do código da aplicação, após a etapa de Security by Design e antes dos testes de segurança.
Por que deve ser feito
Para aplicar controles de segurança diretamente no código, garantindo a proteção de dados durante o ciclo de vida da aplicação e a conformidade com regulamentações como LGPD e GDPR.
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.
Engenheiro de Software, Analista Sênior de Segurança, Arquiteto de Segurança.
Quem define os Atores responsáveis pela Validação
Coordenação de Desenvolvimento e Coordenação de Segurança
Engenheiro de Software e Analista de Segurança, DPO 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)
Relatório ou Plano de Design de Sistema Atualizado (Etapa II) contendo as especificações de Requisitos de Segurança
Guia de Codificação Segura - Regras baseadas em OWASP e ISO/IEC 27034.
Matriz de Controles - Relacionando controles a trechos de código ou funcionalidades específicas.
Checklist de Segurança no Código - Para evitar vulnerabilidades como SQL Injection, Cross-Site Scripting (XSS), e gerenciamento inadequado de memória.
O que precisamos definir na Etapa de Execução Segura
Aplicação e Uso dos Controles no Código - Aplicação de criptografia, validação de entradas, e proteção contra vulnerabilidades conhecidas.
Gerenciamento Seguro de Dados - Estratégias para manipulação e descarte de dados sensíveis.
Práticas de Logging Seguro - Configurar logs que não exponham dados sensíveis.
Integridade do Código - Garantir rastreabilidade de alterações e validação de integridade com ferramentas de controle de versão.
O que precisamos entregar para a próxima etapa (Teste de Segurança)
Relatório de Execução Segura do Projeto – Apresentando os controles utilizados, com listagem das práticas aplicadas no código e ferramentas utilizadas.
Código Seguro e Documentado: Incluindo o uso e aplicação de controles de segurança descritos nos requisitos.
Configurações Seguras – Referências e arquivos de configuração sem credenciais expostas ou permissões excessivas.
Relatório de Controles Utilizados - Listagem das práticas aplicadas no código e as ferramentas utilizadas.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Engenheiros de Software eArquitetos de Segurança da organização.
Práticas recomendadas para a Execução Segura
Validação e Sanitização de Entradas - Proteger contra injeções e manipulação de dados maliciosos.
Criptografia de Dados - Aplicar criptografia segura para dados em trânsito e em repouso (TLS 1.3 e AES-256).
Gerenciamento Seguro de Credenciais - Uso de gerenciadores de segredos como AWS Secrets Manager ou HashiCorp Vault.
Logging Seguro - Remover dados sensíveis dos logs e limitar o acesso a logs críticos.
Princípio de Menor Privilégio - Aplicar controle estrito de permissões.
Ferramentas recomendadas
SonarQube - Para análise estática de segurança do código.
Bandit (Python) ou ESLint (JavaScript) - Para detecção de vulnerabilidades específicas de linguagem.
OWASP Dependency-Check - Identificar vulnerabilidades em bibliotecas externas.
HashiCorp Vault - Gerenciamento de segredos e credenciais.
Testes e Avaliações Iniciais
Análise Estática de Código (SAST) – Busca e identificação de vulnerabilidades no código antes da execução.
Teste de Integração – Verificação do funcionamento dos controles de segurança, se estão dentro dos parâmetros estabelecidos.
Avaliação de Conformidade – Validar se o código utilizado atende os requisitos de proteção de dados da LGPD e GDPR.
Referências técnicas
ISO/IEC 27034 - Práticas de segurança no desenvolvimento de aplicações.
Durante e após a execução do código, antes da implantação em produção. Deve ser parte iterativa do ciclo de desenvolvimento (DevSecOps) e reexecutado sempre que houver alterações significativas no código ou infraestrutura.
Por que deve ser feito
Para identificar e corrigir vulnerabilidades de segurança que possam comprometer dados pessoais e sensíveis, garantindo conformidade com normas como LGPD, GDPR, e padrões ISO.
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.
Engenheiro de Software, Analista Sênior de Segurança, Testador de Segurança (Pen Tester).
Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança
Analistas de Segurança, DPOs e Arquitetos de Segurança.
Quais os documentos necessários para a etapa de Teste de Segurança
Relatório dos Requisitos do Projeto (Etapa I)
Relatório ou Plano de Design de Sistema Atualizado (Etapa II)
Relatórios de Execução Segura do Projeto (Etapa III)
Planos de Testes – Que apresentam casos de uso para testes de segurança baseados no OWASP Testing Guide e ASVS.
Relatório de Análise de Riscos – Material de referência para orientar a priorização de vulnerabilidades a serem testadas.
O que precisamos definir na Etapa de Teste de Segurança
Casos de Testes - Baseados em requisitos de segurança e fluxos de proteção de dados.
Critérios de Aceitação - Para determinar se as vulnerabilidades foram mitigadas adequadamente.
Estratégias de Teste: Incluir análise estática, dinâmica, de dependências e pentests.
O que precisamos entregar para a próxima etapa (Gerenciamento)
Relatório dos Testes de Segurança, contendo:
Relatório de Vulnerabilidades - Incluindo classificação (alto, médio, baixo impacto), origem e ações recomendadas.
Validação de Correções - Testes para garantir que as vulnerabilidades corrigidas não reintroduzam novos problemas.
Documentação para Gerenciamento - Descrever vulnerabilidades críticas que devem ser monitoradas continuamente.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Equipes de Testes de Segurança (Pentester), Engenheiros de Software e Arquitetos de Segurança.
Práticas recomendadas para os Testes de Segurança
Testes Automatizados e Manuais - Combinar análises automatizadas (SAST, DAST) com pentests manuais.
Abordagem Iterativa - Repetir os testes após cada correção.
Priorização Baseada em Impacto - Buscar vulnerabilidades críticas, como aquelas listadas no OWASP Top 10 (e.g., Injeção, XSS, exposição de dados sensíveis).
Simulação de Ataques - Aplicar técnicas de fuzzing e análise de ameaças avançadas.
Após os Testes de Segurança e antes do Monitoramento, e de forma contínua durante todo o ciclo de vida da aplicação.
Por que deve ser feito
Visa assegurar a conformidade contínua com regulamentações (LGPD, GDPR), implementar políticas de gestão de dados, gerenciar riscos de segurança, e manter o controle sobre os dados pessoais e sensíveis manipulados pela aplicação.
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.
DPO, Analista de Segurança, Arquiteto de Segurança, Gestor de TI.
Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança
DPO, Arquitetos de Segurança e Analistas de Segurança (SOC).
Quais os documentos necessários para a etapa de Teste de Segurança
Relatório dos Requisitos do Projeto (Etapa I)
Relatório ou Plano de Design de Sistema Atualizado (Etapa II)
Relatório de Execução do Sistema (Etapa III)
Relatório dos Testes de Segurança (Etapa IV)
Plano de Gestão de Dados - Define como os dados são coletados, armazenados, acessados e descartados.
Política de Retenção de Dados - Baseada em regulamentações e boas práticas.
Matriz de Riscos - Avaliação contínua de riscos relacionados aos dados e estratégias de mitigação.
Relatório de Conformidade - Garantia de que a aplicação atende aos requisitos regulatórios e normativos.
O que precisamos definir na Etapa de Teste de Segurança
Estratégias de Gerenciamento de Dados: Como dados pessoais e sensíveis serão manipulados durante o ciclo de vida da aplicação.
Responsabilidades: Definir papéis e responsabilidades de cada ator no processo de proteção de dados.
Critérios de Retenção e Exclusão: Regras claras para retenção e descarte de dados.
Planos de Resposta a Incidentes: Como agir em caso de falhas ou violações de segurança de dados.
O que precisamos entregar para a próxima etapa (Monitoramento)
Relatório ou Planos de Gerenciamento de Segurança, contendo:
Plano de Continuidade e Gestão de Dados - Incluindo estratégias para garantir a continuidade dos serviços e a proteção de dados durante incidentes.
Relatório de Gerenciamento - Documento detalhando os processos, responsabilidades e ferramentas utilizadas no gerenciamento de dados.
Plano de Monitoramento – Contendo diretrizes e indicadores para a próxima etapa (Monitoramento).
Quem é responsável pela entrega
Coordenação de Desenvolvimento – DPO, Arquitetos de Segurança eGestores das Equipes de Infraestrutura.
Práticas recomendadas para os Testes de Segurança
Política de Acesso - Utilizar controles baseados no Princípio do Menor Privilégio.
Classificação de Dados - Categorizar dados pessoais e sensíveis para aplicar os controles adequados.
Planos de Backup e Recuperação - Configurar backups regulares e seguros com testes de recuperação.
Gerenciamento de Riscos Contínuo - Revisar e atualizar a matriz de riscos e as contramedidas.
Treinamento Contínuo - Capacitar a equipe para lidar com dados sensíveis de forma responsável.
Ferramentas recomendadas
Ferramentas de Gestão de Dados - Collibra, Informatica Data Privacy Management.
Gerenciamento de Logs e Eventos - Elastic Stack (ELK), Splunk, Graylog.
Classificação e Descoberta de Dados - Varonis, Netwrix, BigID.
Rastreabilidade e Conformidade - OneTrust para LGPD/GDPR, Open-AudIT para auditoria.
Testes e Avaliações Iniciais
Revisão de Conformidade - Avaliar se os processos de gerenciamento estão alinhados aos requisitos da LGPD, GDPR e ISO.
Teste de Backup e Recuperação - Simular falhas para validar os processos de recuperação.
Auditoria de Acessos - Verificar logs e permissões para identificar usos inadequados ou não autorizados.
Referências técnicas
ISO/IEC 27001
ISO/IEC 29147
LGPD e GDPR
NIST SP 800-122 - Proteção de dados pessoais identificáveis (PII).
Deve ser um evento contínuo durante todo o ciclo de vida da aplicação e sistemas associados, incluindo ambientes de desenvolvimento, teste e produção.
Por que deve ser feito
Visa detectar e responder a ameaças de segurança, violações de dados e acessos não autorizados em tempo hábil, garantindo a conformidade com LGPD, GDPR e padrões ISO.
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.
Analista de Segurança, Gestor de TI, DPO, Administrador de Sistemas.
Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança
DPO, Arquitetos de Segurança (SOC) e Gestores das Equipes de Infraestrutura.
Quais os documentos necessários para a etapa de Teste de Segurança
Relatório dos Requisitos do Projeto (Etapa I)
Relatório ou Plano de Design de Sistema Atualizado (Etapa II)
Relatório ou Plano de Design de Sistema (Etapa III)
Relatório dos Testes de Segurança (Etapa IV)
Relatório ou Planos de Gerenciamento de Segurança (Etapa V)
Política de Monitoramento - Descreve as práticas, escopo e responsabilidades do monitoramento.
Plano de Resposta a Incidentes - Define ações específicas para lidar com alertas críticos.
Logs Estruturados - Para rastrear e auditar eventos relacionados à segurança.
Relatórios de Compliance - Evidências de conformidade com regulamentações e padrões técnicos.
O que precisamos definir na Etapa de Teste de Segurança
Métricas de Monitoramento - Identificar os indicadores-chave de segurança (KPIs), como número de tentativas de acesso não autorizado, uso de dados sensíveis e comportamento anômalo.
Alertas de Segurança: - Configurar thresholds e alertas automáticos para eventos críticos.
Responsabilidades - Definir os responsáveis pela análise, validação e ações sobre eventos detectados.
Ciclo de Logs - Estabelecer retenção segura e anonimização de logs conforme LGPD/GDPR.
O que precisamos entregar para a próxima etapa (Gerenciamento)
Relatórios de Logs e Eventos - Logs analisados e documentados, evidenciando acessos e operações críticas.
Relatório de Análise de Incidentes - Documentação detalhada de eventos de segurança tratados.
Plano Atualizado de Proteção de Dados - Com insights e ajustes a partir do monitoramento.
Quem é responsável pela entrega
Coordenação de Desenvolvimento e de Infraestrutura – Gestores de Equipes de Infraestrutura, Analistas de Segurança (SOC) e DPO.
Práticas recomendadas para os Testes de Segurança
Monitoramento Contínuo - Usar ferramentas automatizadas para capturar e analisar eventos em tempo real.
Cadeia de Custódia de Logs - Proteger logs contra adulteração e acessos não autorizados.
Análise Comportamental - Definir e utilizar ferramentas baseadas em aprendizado de máquina para identificar anomalias.
Testes Periódicos: - Validar a eficácia do monitoramento por meio de exercícios de simulação.
Em cada um das etapas do ciclo de vida do desenvolvimento da aplicação, com maior ênfase na fase inicial (planejamento e levantamento de requisitos) e durante o monitoramento contínuo em produção.
Por que deve ser feito
Visando assegurar que os dados pessoais sejam coletados, armazenados, processados e descartados de forma segura, garantindo a privacidade dos titulares e a conformidade com regulamentações como LGPD e GDPR.
Quem define os Atores e Ações
Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução.
DPO, Analista de Segurança, Arquiteto de Soluções, Engenheiro de Software.
Quem define os Atores responsáveis pela Validação
Coordenação de Desenvolvimento e Coordenação de Segurança
DPO, Arquitetos de Segurança e Gestores de Infraestrutura.
Quais os documentos necessários para a etapa de Proteção de Dados Pessoais
Política de Privacidade - Documento detalhando as práticas de tratamento de dados pessoais.
Registro de Atividades de Tratamento - Identificação de fluxos de dados e bases legais (LGPD/GDPR).
Relatório de Impacto à Proteção de Dados (DPIA) - Avaliação dos riscos ao tratamento de dados e medidas mitigatórias.
Matriz de Riscos de Dados Pessoais - Identificação e priorização de riscos específicos associados ao tratamento.
O que precisamos definir nesta tapa
Classificação dos Dados Pessoais - Categorizar dados coletados (e.g., dados sensíveis, dados de menores).
Bases Legais para o Tratamento - Especificar os fundamentos legais de cada atividade (e.g., consentimento, execução de contrato).
Controles de Acesso - Garantir que apenas usuários autorizados tenham acesso a dados pessoais.
Critérios de Retenção e Exclusão - Determinar prazos de retenção e métodos de exclusão seguros.
Anonimização e Pseudonimização - Aplicar técnicas para reduzir o impacto de uma possível violação.
Artefatos a serem gerados nessa etapa
Plano de Tratamento de Dados Pessoais - Documento detalhado com estratégias para proteger os dados em todas as fases do ciclo de vida.
Registros de Conformidade - Evidências documentais para auditorias e autoridades regulatórias.
Controles Técnicos Definidos e Aplicados - Como criptografia, proteção de APIs e validação de entradas.
Quem é responsável pela entrega
Coordenação de Desenvolvimento e Segurança – Engenheiros de Software, Arquitetos de Segurança e DPO.
Práticas recomendadas
Privacy by Design e by Default - Incorporar a proteção de dados no design inicial e garantir configurações padrão mais restritivas.
Classificação e Minimização de Dados - Coletar e processar apenas os dados estritamente necessários para a finalidade definida.
Criptografia de Dados Sensíveis – Definir a aplicar ferramentas de criptografia forte para dados em repouso e em trânsito.
Auditoria e Logs Seguros - Rastrear acessos e alterações, sem expor dados sensíveis.
Treinamento Contínuo - Capacitar equipes para lidar com dados pessoais e suas responsabilidades.
Ferramentas recomendadas
Gerenciamento de Consentimento - OneTrust, TrustArc.
Descoberta e Classificação de Dados - BigID, Varonis.
Proteção de Dados em APIs - OWASP API Security Project, Postman para testes.
Criptografia e Proteção - PyCryptodome (Python), Crypto (Node.js).
Gerenciamento de Logs e Eventos - Elastic Stack (ELK), Graylog.
Testes e Avaliações Iniciais
Revisão de Conformidade - Validar se os dados pessoais estão sendo tratados em conformidade com LGPD e GDPR.
Teste de Criptografia - Garantir que os dados sensíveis estão devidamente criptografados e que as chaves estão protegidas.
Auditoria de Acessos - Revisar permissões para identificar possíveis acessos indevidos.
Simulação de Violações - Testar a eficácia das proteções e o plano de resposta a incidentes.
Referências técnicas
ISO/IEC 27001
ISO/IEC 27701
LGPD e GDPR
OWASP Data Protection Guide
NIST Privacy Framework
Considerações Finais
Considerando as práticas abordadas pelo OWASP para a Proteção de Dados, é de suma importância que o Ministério da Saúde/DATASUS, trate da importância de integrar esses princípios no desenvolvimento de software. Ao utilizar uma política de privilégio mínimo, criptografar informações sensíveis, e adotar práticas seguras de armazenamento e controle de acesso, os desenvolvedores que atuarão no âmbito do Ministério da Saúde/DATASUS, fortalecerão as defesas contra possíveis violações de segurança. Proteger os dados das aplicações é um fundamento essencial para garantir a segurança e privacidade em aplicações modernas. Este guia fornece uma abordagem abrangente para integrar práticas de proteção de dados em todo o ciclo de desenvolvimento seguro de software. A adoção de ferramentas adequadas, conformidade com regulamentações e o treinamento contínuo das equipes são fundamentais para alcançar a segurança e confiança dos usuários.
Referências
ISO/IEC 27001 - Sistema de Gestão de Segurança da Informação (SGSI).
ISO/IEC 27034 - Segurança da Informação em Processos de Desenvolvimento de Aplicações.
LGPD e GDPR - Regulamentações para proteção de dados pessoais.
OWASP Privacy Risks Project - Diretrizes para identificar e mitigar riscos de privacidade em aplicações.
NIST SP 800-122 - Diretrizes de proteção para informações pessoais identificáveis (PII).
SAFECode - Práticas fundamentais para desenvolvimento seguro de software.