Tratar erros e logs é um evento que se destaca como item crítico no desenvolvimento seguro de software, pois fornece informações detalhadas para a depuração, monitoramento de aplicações e análise de incidentes de segurança. Este capítulo fornece diretrizes baseadas nas melhores práticas, normas internacionais (ISO/IEC, OWASP, NIST), e legislações como a LGPD e GDPR. O foco gira em torno de garantir o tratamento de erros e logs esteja em conformidade com padrões de segurança e privacidade. O modo como essa parte do desenvolvimento foi abordado nesse capítulo foi pensando em equilibrar a necessidade de capturar informações úteis para a manutenção e melhoria do software com a responsabilidade de proteger informações sensíveis e evitar vazamentos de dados..
Objetivos do Documento
O objetivo deste documento é de fornecer definições de diretrizes de segurança para o tratamento de erros e geração de logs, minimizando os riscos de exposição de informações sensíveis. Também visa proporcionar recomendações práticas para implementação segura de mecanismos de logs e tratamento de erros nos frameworks e linguagens homologados: Angular, React, Vue, Java, Node.js e Python. Além disso, visamos assegurar conformidade com normas e regulamentos, como LGPD, GDPR e ISO/IEC 27001. E por fim, promover a rastreabilidade e monitoramento seguro, garantindo a coleta de dados relevantes para auditoria e detecção de incidentes sem comprometer a integridade dos sistemas.
Boas Práticas para Tratamento de Erros e Logs
Boas Práticas no Tratamento de Erros
Revisar mensagens de erro: Evite expor detalhes do sistema, como caminhos de diretório, configurações de banco de dados ou informações de stack traces.
Definir erros genéricos para o usuário final: Forneça mensagens claras e úteis, mas sem expor detalhes internos.
Mensagem exibida ao usuário: "Ocorreu um erro. Por favor, tente novamente mais tarde."
Mensagem registrada no log: "Erro SQL ao acessar tabela 'usuarios': [detalhes]".
Boas Práticas no Tratamento de Logs
Logue apenas o necessário: Capture apenas as informações críticas para auditoria e resolução de problemas, evitando excesso de logs que dificulte a análise.
Criptografe logs sensíveis: Utilize criptografia para proteger logs com informações sensíveis.
Classifique os logs por severidade: Categorize os logs em níveis, como DEBUG, INFO, WARN, ERROR, CRITICAL.
Configure a rotação de logs: Limite o crescimento de arquivos de log para evitar consumo excessivo de recursos.
Descrição da Implantação do Processo de Tratamento de Erros e Logs
Tratamento de Erros
Atendendo as etapas de Engenharia de Software e as melhores práticas de Desenvolvimento Seguro e a aplicação da cultura DEVSECOPS, visamos entregar produtos confiáveis e resilientes.
¶Etapas do SSDLC com Foco em Tratamento de Erros e Logs
Identificar os requisitos legais e normativos para o tratamento de dados pessoais e logs, conforme LGPD e GDPR.
Determinar quais informações sobre os erros deverão ser registradas, como deverão ser registradas e as garantias de que não serão incluídos dados pessoais ou confidenciais.
Especificar a retenção segura de logs com períodos definidos e mecanismos de exclusão automática.
Definir e especificar quem tratará e como tratará as informações geradas, bem como o modo que será realizado o retorno do tratamento das informações para todas as equipes envolvidas no processo.
Planejar um sistema de centralização de logs, bem como a segregação quando for necessário para ampliar a segurança, aumentando a capacidade de gestão e restrição de acesso às informações de log.
Definir mecanismos de anonimização para logs que possam conter dados sensíveis.
Definir e implantar tratamento de erros que evitem vazamento de detalhes internos para usuários finais.
Validar a conformidade dos logs com requisitos de segurança, garantindo que informações confidenciais ou pessoais não sejam registradas acidentalmente.
Realizar testes de segurança em mensagens de erro para evitar a exposição de vulnerabilidades internas.
Aplicar testes automatizados para verificar se mensagens de erro foram revisadas e tratadas adequadamente.
¶4.5. Gerenciamento, Monitoramento e Proteção de Dados Pessoais
Monitorar continuamente os logs para detecção de eventos anômalos ou incidentes de segurança.
Configurar alertas para erros críticos e acessos não autorizados.
Garantir a proteção dos logs em trânsito e em repouso, utilizando criptografia robusta, como AES-256.
5.1. Identificação de Erros - utilizar códigos de erro devidamente elencados e mensagens com descrições direcionadas para identificar e categorizar os erros.
5.2. Captura de Erros - aplicar blocos de try-catch para capturar exceções e erros inesperados.
5.3. Registro de Erros - utilizar sistemas de registro para armazenar informações detalhadas sobre os erros, incluindo stack trace, timestamp e contexto.
5.4. Notificação de Erros - aplicar mecanismos de notificação (por exemplo, e-mails, SMS e outros meios de alertas) para informar a equipe de desenvolvimento sobre erros críticos.
Logs de Aplicação
Níveis de Log - definir níveis de log diversificados, respeitando os princípios da observabilidade (debug, info, warning, error) para registro de informações relevantes em diferentes contextos.
O parâmetro “info” deve ser mantido como padrão, por conta das métricas e referências. Devem ser somadas as referências de saúde da aplicação, com os devidos ajustes, direcionados para linguagens e frameworks, somando a isso o que venha a ser acoplado ao projeto da aplicação e que ofereça ou não informações úteis.
6.2. Formato de Log – criar padrões para o formato de log facilitando análise posterior. Devendo incluir informações como data, hora, contexto e ação executada.
6.3. Gerenciamento de Logs - usar ferramentas de gerenciamento de logs para armazenamento, realizar busca e análise das informações.
Em conjunto com as equipes devem ser definidos parâmetros do que deve ser retido ou capturado para futuras tratativas. Tal comportamento é necessário para que as informações que são geradas (normalmente em grande quantidade) sejam devidamente tratadas.
Nos casos relacionados à segurança da aplicação os parâmetros devem ser ajustados. Nesses casos o julgamento deve levar em conta o que será ganho ou perdido como informação, caso um item seja retirado da lista de captura.
Essa análise deve partir da Equipe de Segurança, para que haja uma negociação sobre os itens a serem usados ou não como referência para as capturas, sempre com base nas informações repassadas pela Equipe de Desenvolvimento. Respeitando os nivelamentos de recursos computacionais e financeiros do Ministério da Saúde.
Como referência as equipes deveriam usar métricas das aplicações, não restringindo as tratativas apenas aos logs, o que facilitaria realizar buscas direcionadas. Como ferramenta pode se utilizar o Open Telemetri.
“Debug” deveria ser evitado, são exceções direcionadas para os processos marcados como necessários.
Durante a fase inicial do Ciclo de Vida do Desenvolvimento Seguro de Software (SSDLC), antes de iniciar o design.
Por que deve ser feito
Identificar requisitos de segurança e conformidade para o tratamento de erros e logs. - Garantir que a aplicação atenda às normas ISO, LGPD e GDPR, reduzindo o risco de vazamento de dados.
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.
Equipe de Engenharia de Software e Segurança da Informação, DPO e Arquitetos 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
Arquitetos de Soluções e Segurança, com a validação final pelo DPO e equipe de Compliance. - Equipe de Qualidade e Segurança.
Quais os documentos necessários para a etapa de Levantamento de Requisitos
Política de Segurança da Informação (ISO/IEC 27001).
Requisitos de negócios do sistema.
Documentos de conformidade (LGPD, GDPR).
Diretrizes de desenvolvimento seguro (NIST, OWASP).
O que é necessário definir nessa etapa
Escopo de captura de logs (o que registrar e onde armazenar).
Categorias de severidade (DEBUG, INFO, ERROR, CRITICAL).
Requisitos de proteção de dados pessoais em logs.
Requisitos de retenção e exclusão de logs.
Requisitos de controle de acesso aos logs.
O que precisamos entregar para a próxima etapa (Security by Design)
Relatório dos Requisitos do Projeto contendo: as especificações de requisitos de logs (com definições completas).
Checklist de conformidade para o tratamento de erros e logs.
Estrutura preliminar para a arquitetura de logging e tratamento de erros.
Proposta contendo as possíveis ferramentas para uso na aplicação.
Quem é responsável pela entrega
Coordenação de Desenvolvimento -Líderes técnicos das equipes de Desenvolvimento e Segurança.
Práticas recomendadas para o Levantamento de Requisitos
Utilizar modelos de requisitos baseados em normas (NIST e ISO/IEC 27034).
Identificar os pontos de falha críticos e suas mensagens de erro associadas.
Priorizar requisitos críticos alinhados às categorias de riscos de logs (OWASP Logging Cheat Sheet).
Ferramentas recomendadas
Ferramentas de Requisitos - Jira, Confluence.
Monitoramento de Conformidade - SonarQube, Snyk.
Gestão de Logs - Elastic Stack (Elasticsearch, Logstash, Kibana), Graylog.
Monitoramento e Alerta - Splunk, Datadog.
Testes e Avaliações Iniciais
Teste de capacidade de anonimização de logs e se os parâmetros estão alinhados com as normas.
Validar tratativa de erros sensíveis quanto a não exposição em ambientes de desenvolvimento.
Auditar os parâmetros quanto à compliance com ferramentas como OWASP ZAP.
Durante a etapa de design e arquitetura do sistema, antes da implantação do código, após o levantamento de requisitos.
Por que deve ser feito
Visando garantir que os mecanismos de logs e tratamento de erros sejam projetados com segurança desde o início. Minimizar riscos de exposição de dados sensíveis ou vazamento de informações internas. Garantir conformidade com normas de segurança e privacidade, como LGPD e GDPR.
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.
Arquitetos de Soluções e Segurança da Informação, DPO e Engenheiros de Software.
Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança
Líderes Técnicos das Equipes de Sustentação, Analistas de Segurança e Engenheiros de Software.
Quais os documentos necessários para a etapa de Security by Design
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações requisitos de logs (baseado no levantamento de requisitos).
Políticas de segurança da informação (ISO/IEC 27001 e 27002).
Diretrizes de desenvolvimento seguro (OWASP, NIST, SAFECode).
Normas de conformidade (LGPD, GDPR).
O que precisamos definir na Etapa de Security by Design
Estrutura do sistema de logs – o que deverá incluir locais de armazenamento (centralizado ou distribuído).
Níveis de severidade - DEBUG, INFO, WARN, ERROR, CRITICAL.
Formato padrão dos logs - JSON, texto estruturado, etc.
Requisitos de segurança para logs - como criptografia em trânsito e repouso (AES-256).
Políticas de retenção e exclusão automática de logs
Mecanismos de tratamento de erros seguros - evitando exposição de stack traces e detalhes internos.
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 e o modelo arquitetural de segurança para logs e tratamento de erros.
Guia Técnico – que oriente a implantação das ferramentas e padrões e demais componentes do projeto.
Checklist de segurança - baseado em OWASP e NIST para validação durante o desenvolvimento.
Identificação de pontos de monitoramento crítico para logs.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Arquitetos de Soluções e Segurança, Engenheiros de Software, DPO e Compliance.
Práticas recomendadas para o Security by Design
Definir formatos padrão para logs - alinhados com ferramentas de análise e monitoramento como no caso do JSON.
Usar princípios de Least Privilege para acesso a logs.
Projetar logs – o projeto deve prever que sejam legíveis para humanos e possam ser analisados, interpretados e decodificados por máquinas (automação).
Evitar a inclusão de dados pessoais ou confidenciais nos logs. Quando inevitável, garantir anonimização ou pseudonimização.
Definir separação de logs por categorias – como logs de segurança, de aplicação e de auditoria.
Ferramentas recomendadas
Para Design e Planejamento: Confluence (documentação), Lucidchart (diagramas). - Para Logs Centralizados: Elastic Stack (Elasticsearch, Logstash, Kibana), Graylog. - Para Análise de Conformidade: SonarQube, Snyk. - Para Monitoramento de Logs: Splunk, Datadog, Grafana Loki.
Testes e Avaliações Iniciais
Simular geração de logs em cenários críticos - como falhas de autenticação, erros em banco de dados.
Verificação de Armazenamento de Logs – avaliando se os logs estão sendo armazenados de maneira segura e acessados apenas por usuários autorizados.
Princípio do Menor Privilégio aplicado a erros - Validar se as mensagens de erro tratadas exibem informações genéricas para o usuário final e detalhes técnicos apenas em logs seguros.
Durante a etapa de codificação e execução do sistema, após o Security by Design e antes dos Testes de Segurança.
Por que deve ser feito
Visa garantir que os logs e o tratamento de erros sejam executados seguindo práticas de segurança definidas no design. Evitar a exposição de dados sensíveis e mitigar riscos associados à logs inadequados ou erros não tratados. Preparar o ambiente de execução para monitoramento seguro e auditoria contínua.
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.
Engenheiros de Software, Arquitetos de Segurança e DPO.
Quem define os Atores responsáveis pela Validação
Coordenação de Desenvolvimento e Coordenação de Segurança
Equipe de Qualidade, Analistas de Segurança, Líderes Técnicos e Arquitetos de Soluções.
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.
Documento de Especificação Técnica de Logs e Erros (produzido na etapa de design).
Políticas internas de segurança da informação.
Diretrizes OWASP Logging Cheat Sheet e NIST.
Normas de conformidade (LGPD, GDPR).
O que precisamos definir na Etapa de Execução Segura
Regras para sanitização e formatação de logs, incluindo tratamento de dados pessoais.
Mecanismos de anonimização/pseudonimização de dados em logs.
Tipos de execução de criptografia para logs sensíveis (em trânsito e repouso).
Estrutura de mensagens de erro (mensagens claras, mas que não exponham detalhes internos). - Mecanismos de rotação, arquivamento e exclusão de logs.
O que precisamos entregar para a próxima etapa (Teste de Segurança)
Relatório de Execução Segura do Projeto – Apresentando os logs definidos e integrados com sistemas de monitoramento e análise.
Tratamento de erros definido com validações iniciais.
Scripts ou módulos para testar o fluxo de geração, armazenamento e análise de logs.
Checklist de conformidade para auditorias iniciais.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Engenheiros de Software e Equipe de Segurança.
Práticas recomendadas para a Execução Segura
Utilize logs estruturados (JSON) para facilitar a análise automatizada.
Aplique padrões de nomenclatura consistentes para mensagens de erro e logs.
Impeça registro de dados sensíveis ou confidenciais em logs, salvo se anonimizados.
Defina e aplique controles de acesso robustos aos logs, usando Least Privilege. - Garanta a compatibilidade com ferramentas de análise e monitoramento (ex.: Elastic Stack, Splunk).
Ferramentas recomendadas
Para Logs e Monitoramento: Elastic Stack (Logstash, Elasticsearch, Kibana), Graylog. - Para Tratamento de Erros: Sentry (para monitoramento de exceções), Winston (Node.js), Loguru (Python). - Para Gerenciamento de Conformidade: SonarQube, Snyk. - Para Criptografia de Logs: OpenSSL (bibliotecas integradas).
Testes e Avaliações Iniciais
Analisar os logs definidos e utilizados quanto à segurança, criptografia e alinhamento com a padronização de formato.
Testar cenários de erros para garantir mensagens seguras e informativas para os usuários.
Simular ataques comuns - como injection em campos de logs, para avaliar a robustez da revisão e limpeza de entradas.
Durante a fase de testes no ciclo de desenvolvimento, após a codificação e execução segura, e antes da etapa de gerenciamento e monitoramento.
Por que deve ser feito
Visando identificar vulnerabilidades relacionadas ao tratamento de erros e logs antes do lançamento da aplicação. Garantir que logs não exponham dados sensíveis ou detalhes internos do sistema. E por fim, validar a conformidade com normas (ISO/IEC, LGPD, GDPR) e alinhamento com as melhores práticas de segurança.
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.
Equipe de Segurança, Engenheiros de Software, Arquitetos de Segurança e 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
Arquitetos de Soluções e 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)
Relatório ou Plano de Design de Sistema Atualizado (Etapa II)
Relatórios de Execução Segura do Projeto (Etapa III)
Documento de Especificação Técnica de Logs e Erros (do design).
Relatório de Execução Segura (com logs utilizados e integrados).
Políticas internas de segurança da informação.
Normas de conformidade (LGPD, GDPR).
OWASP Testing Guide (orientações específicas para segurança de logs e erros).
O que precisamos definir na Etapa de Teste de Segurança
Possíveis Cenários de Teste - que incluam simulação de erros críticos e validação de mensagens seguras para usuários.
Geração de logs em situações extremas - como ataques de negação de serviço (DoS).
Critérios Definidos – para aceitação para segurança de logs e erros.
Estratégias de Correção e Mitigação - para correção e mitigação de vulnerabilidades detectadas.
O que precisamos entregar para a próxima etapa (Gerenciamento)
Relatório dos Testes de Segurança, contendo: Dados consolidados de vulnerabilidades encontradas e ações corretivas aplicadas.
Logs testados e auditados com validação de conformidade.
Documentação das práticas aplicadas para monitoramento contínuo.
Checklist de preparação para a etapa de gerenciamento.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Equipes de Segurança, Arquitetos de Segurança e DPO.
Práticas recomendadas para os Testes de Segurança
Realizar testes automatizados para verificar vulnerabilidades nos logs, como dados sensíveis registrados.
Garantir que as mensagens de erro não revelem detalhes internos, como caminhos do sistema, credenciais.
Testar a capacidade de alternar e excluir logs conforme políticas de retenção.
Validar o uso de criptografia para logs em trânsito e repouso.
Revisar as permissões de acesso para logs, garantindo que sigam o princípio do menor privilégio.
Ferramentas recomendadas
Para Testes de Segurança de Logs e Erros - OWASP ZAP, Burp Suite, SonarQube.
Para Testes de Conformidade e Análise de Dependências - Snyk, Dependency-Check.
Para Monitoramento de Vulnerabilidades - Splunk, Datadog, Elastic Stack.
Testes e Avaliações Iniciais
Ataques simulados - como SQL Injection e XSS, para validar que mensagens de erro e logs não exponham detalhes internos.
Teste de Criptografia - Anlisar a criptografia de logs em trânsito e repouso.
Teste de Cenários – como os casos de alto volume de logs (testes de estresse) para garantir que o sistema seja escalável e seguro.
Simulações - simular tentativas de acessos não autorizados aos logs para validar os controles de acesso.
Durante a fase de operação e manutenção contínua do ciclo de vida de desenvolvimento, após a conclusão da etapa de Teste de Segurança e antes do Monitoramento contínuo.
Por que deve ser feito
Para garantir que os logs e o tratamento de erros sejam gerenciados de forma centralizada e segura. Assegurar conformidade com normas como LGPD e GDPR, especialmente para retenção e exclusão de dados sensíveis. Além de facilitar processos de auditoria, análise forense e a resposta a incidentes de segurança.
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.
Equipe de Operações e de Segurança, DPO, Arquitetos de Segurança e Soluções.
Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança
Auditores internos e externos e Líderes Técnicos
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)
Políticas de Retenção e Exclusão de Logs (definidas em conformidade com LGPD/GDPR).
Documentos de Testes de Segurança e Relatórios de Auditoria.
Diretrizes internas de gerenciamento de vulnerabilidades (ISO/IEC 30111).
Manual de Procedimentos de Tratamento de Incidentes.
O que precisamos definir na Etapa de Teste de Segurança
Políticas de retenção e exclusão de logs
Controles de acesso e permissões para gerenciar logs.
Processos para análise e arquivamento de logs para auditoria.
Automação de processos, como rotação e exclusão de logs antigos.
Requisitos de backup e recuperação de logs críticos.
O que precisamos entregar para a próxima etapa (Monitoramento)
Relatório ou Planos de Gerenciamento de Segurança, contendo: Logs organizados e configurados em sistemas de gerenciamento centralizados.
Políticas documentadas de retenção, exclusão e backup de logs.
Checklist de conformidade e evidências de auditoria.
Ambiente preparado para instalação e uso de ferramentas de monitoramento contínuo.
Quem é responsável pela entrega
Coordenação de Desenvolvimento – Equipe de Infraestrutura, Segurança e DPO.
Práticas recomendadas para os Testes de Segurança
Centralizar logs em ferramentas seguras e escaláveis (ex.: Elastic Stack, Splunk).
Utilizar criptografia para proteger logs em trânsito e repouso.
Utilizar automação para retenção, exclusão e arquivamento de logs.
Realizar auditorias periódicas para garantir que os logs estão sendo gerenciados de acordo com as políticas definidas.
Garantir que somente usuários autorizados tenham acesso a logs sensíveis.
Ferramentas recomendadas
Para Centralização de Logs - Elastic Stack (Elasticsearch, Logstash, Kibana), Graylog, Splunk.
Para Gerenciamento de Conformidade - Snyk, SonarQube.
Para Automação de Processos - Ansible, Jenkins (CI/CD para automação de tarefas de log).
Para Backup e Recuperação - AWS Backup, Azure Backup.
Testes e Avaliações Iniciais
Validar a política de retenção e exclusão automática de logs em um ambiente controlado.
Realizar testes de recuperação para logs arquivados.
Simular cenários de acesso não autorizado para garantir que as permissões e controles de acesso estão configurados corretamente.
Auditar logs gerados em cenários de testes para verificar a conformidade com padrões estabelecidos.
Durante toda a fase de operação e produção, após o gerenciamento e conforme o ciclo de vida do sistema, com monitoramento contínuo e avaliações periódicas.
Por que deve ser feito
Detectar eventos anômalos ou suspeitos relacionados ao tratamento de erros e logs. Garantir a integridade, disponibilidade e confidencialidade de logs sensíveis. Além de prover apoio para auditorias de conformidade e resposta rápida aos incidentes de segurança.
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.
Equipe de Operações e de Segurança, Arquitetos de Segurança e Soluções e 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
Líderes Técnicos 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)
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íticas de Monitoramento e Auditoria (com base nas normas ISO/IEC 27001 e 27002).
Relatórios de gerenciamento e auditoria de logs.
Matriz de Alertas e Indicadores de Segurança.
Diretrizes regulatórias relacionadas a eventos envolvendo dados pessoais (LGPD e GDPR).
O que precisamos definir na Etapa de Teste de Segurança
Eventos críticos a serem monitorados - como acessos não autorizados, falhas de autenticação, tentativas de ataque.
Níveis de criticidade e categorização de eventos.
Padrões de resposta automática para eventos específicos - como bloqueios temporários.
Requisitos para arquivamento seguro de logs monitorados.
Frequência e critérios de geração de relatórios de monitoramento.
O que precisamos entregar
Relatório contendo a consolidação dos eventos monitorados, destacando anomalias e ações tomadas.
Logs processados e categorizados para análise detalhada.
Documentação dos processos de monitoramento contínuo e resposta a eventos.
Checklist de conformidade e preparação para auditorias regulatórias.
Quem é responsável pela entrega
Coordenação de Desenvolvimento e de Infraestrutura – Equipes de Infraestrutura e Operações, Equipes de Segurança, DPO, Engenheiros e Arquitetos de Software.
Práticas recomendadas para os Testes de Segurança
Configurar alertas automatizados para eventos críticos, como falhas recorrentes ou tentativas de acesso não autorizado.
Implantar sistemas de coleta centralizada de logs para facilitar análise e resposta a incidentes.
Definir métodos que garantam que os logs monitorados sejam protegidos contra alterações ou manipulações indevidas e exclusão não autorizada.
Realizar revisões periódicas das métricas de monitoramento realizando os devidos ajustes conforme novas ameaças ou alterações regulatórias.
Adotar políticas de arquivamento seguro para logs antigos, protegendo sua integridade e acessibilidade.
Ferramentas recomendadas
Monitoramento em Tempo Real - Splunk, Datadog, Elastic Stack (Logstash, Elasticsearch, Kibana).
Gerenciamento de Alertas e Incidentes - Grafana Loki, PagerDuty, AWS CloudWatch.
Auditorias de Conformidade - SonarQube, Snyk, OWASP ZAP.
Proteção de Dados Sensíveis em Logs - HashiCorp Vault, OpenSSL (para criptografia).
Testes e Avaliações Iniciais
Realizar simulações de eventos críticos - como tentativas de invasão e erros de execução, visando validar o funcionamento dos alertas.
Realizar Auditoria de Logs - para garantir que informações sensíveis estão protegidas (anonimizadas ou criptografadas).
Realizar Testes de Integridades dos Logs – com a finalidade de verificar a integridades dos logs armazenados, analisando se houve alterações indevidas ou exclusão sem permissão.
Realizar auditorias regulares para validar conformidade com LGPD e GDPR.
Referências técnicas
ISO/IEC 27001 e 27002 - Diretrizes para monitoramento e auditoria contínuos.
ISO/IEC 29147 e 30111 - Processos para detecção e tratamento de vulnerabilidades.
OWASP Logging Cheat Sheet - Práticas para monitoramento seguro de logs.
A ser executado em todas as fases do ciclo de vida da aplicação, direcionado especialmente às etapas de desenvolvimento, testes, e operação contínua. Devendo ser aplicado antes de o código ser posto em produção e durante auditorias regulares.
Por que deve ser feito
Para que a confidencialidade, integridade e disponibilidade de dados pessoais processados sejam garantidas, e os dados devidamente armazenados ou registrados em logs. Buscando também atender às regulamentações de proteção de dados, como LGPD e GDPR. Visando também a redução de riscos de vazamento de dados e garantir que logs e erros não exponham informações sensíveis.
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 em conjunto com Arquitetos de Segurança e Engenheiros de Software.
Quem define os Atores responsáveis pela Validação
Coordenação de Desenvolvimento e Coordenação de Segurança
Revisores e Auditores Internos, Líderes Técnicos e o DPO da organização.
Quais os documentos necessários para a etapa de Proteção de Dados Pessoais
Políticas internas de privacidade e segurança da informação.
Data Mapping - Documentação de mapeamento de dados pessoais.
Relatórios de impacto à proteção de dados.
Manual de tratamento de vulnerabilidades e logs.
O que precisamos definir nesta tapa
Minimização de Dados - Definir os dados pessoais que poderão podem ser registrados em logs e as circunstâncias aplicáveis.
Políticas de Anonimização e Pseudonimização – quais as políticas a serem utilizadas quanto aos dados pessoais em logs.
Requisitos de criptografia para dados pessoais em logs (em trânsito e repouso).
Definir Parâmetros de Acesso e Controle – criar os parâmetros para os perfis de acesso e controle de permissões para logs sensíveis.
Estratégias de Retenção - para retenção e exclusão de logs que contenham dados pessoais.
Artefatos a serem gerados nessa etapa
Logs com configurações parametrizadas para anonimizar ou pseudonimizar dados pessoais.
Mecanismos de criptografia definidos e aplicados para tratamento de logs sensíveis.
Documentação de políticas de retenção, exclusão e auditoria de logs.
Quem é responsável pela entrega
Coordenação de Desenvolvimento e Segurança – DPO da Organização, Engenheiros de Software e Arquitetos de Segurança.
Práticas recomendadas
Registrar apenas o necessário e com propósitos especificados, impondo a minimização e registros de dados pessoais nos logs.
Substituir identificadores pessoais por códigos genéricos, o que aplica métodos de anonimização ou pseudonimização de dados em logs.
Criptografar dados em trânsito e em repouso, visando garantir que todos os dados pessoais sejam protegidos.
Tratar controles de acesso com base em privilégios mínimos para aumentar os níveis de proteção de logs sensíveis.
Monitorar e auditar regularmente o uso e acesso a logs que contenham dados pessoais.
Ferramentas recomendadas
Processos de Casos de Anonimização e Pseudonimização - Faker.js (Node.js), Python Faker.
Processos de Criptografia de Logs - OpenSSL, HashiCorp Vault, bibliotecas nativas de criptografia (Crypto para Node.js, Cryptography para Python).
Processos de Monitoramento e Auditoria - Splunk, Elastic Stack (Kibana), AWS CloudTrail (em ambientes na nuvem).
Processos de Análise de Conformidade - Snyk, SonarQube, OWASP ZAP.
Testes e Avaliações Iniciais
Realizar revisão dos dados registrados em logs quanto à aderência as políticas de minimização e anonimização.
Testar a eficácia de controles de acesso e criptografia aplicados aos logs.
Realizar simulações de ataques, envolvendo interceptação de logs em trânsito, visando avaliar a resiliência das medidas de segurança.
Realizar auditorias de conformidade para verificar que dados pessoais em logs estão protegidos.
Referências técnicas
ISO/IEC 27001 e 27034
ISO/IEC 29134
LGPD e GDPR
OWASP Logging Cheat Sheet
NIST Secure Software Development Framework
Considerações Finais
Esse capítulo apresentou um resumo direcionado das melhores práticas aplicadas ao tratamento de erros e logs que figura como peça fundamental no ciclo de desenvolvimento seguro de software. Se tratados corretamente, fomentam a garantia de estabilidade do projeto, facilitando a depuração e processos de análises de incidentes. Somado a isso, temos o suporte à conformidade com normas e regulamentos, como LGPD e GDPR, que demandam planejamento adequado e meticuloso para evitar violações de privacidade. Aplicar boas práticas, em paralelo ao uso de ferramentas modernas, proporcionam um ambiente seguro e eficiente para o desenvolvimento e operação de projetos.
Referências
ISO/IEC 27001 - Sistema de Gestão de Segurança da Informação (SGSI).
ISO/IEC 27034 - Segurança no Desenvolvimento de Aplicações.
OWASP Logging Cheat Sheet - Boas práticas de logging para aplicações seguras.
LGPD e GDPR - Regulamentações de proteção de dados pessoais.
ISO/IEC 29134 - Orientações para avaliação de impacto à proteção de dados.
NIST Secure Software Development Framework - Diretrizes para desenvolvimento seguro.