A criptografia é uma prática essencial no desenvolvimento seguro de projetos e crucial para garantir a segurança dos dados em trânsito e em repouso, protegendo informações contra acessos não autorizados, vazamentos e outras ameaças. Este capítulo apresenta um conjunto abrangente de boas práticas, ferramentas e referências técnicas para inserir a criptografia de forma eficaz no ciclo de desenvolvimento seguro de software (SSDLC), atendendo a normas internacionais e regulamentações como LGPD e GDPR. A criptografia é o processo de transformar informações em um formato ilegível para proteger a confidencialidade dos dados. O objetivo do uso de práticas de criptografia é controlar e manter a integridade e confidencialidade dos dados à medida que eles são transmitidos ou armazenados em diferentes partes do sistema.
Objetivos do Documento
Para atender aos mais elevados padrões de segurança, busca-se a compatibilidade com padrões já reconhecidos, como o FIPS 140-2 e equivalente ao NIST. Isso garante que os algoritmos e uso de criptografia atendam a requisitos rigorosos de segurança, fortalecendo a postura do Ministério da Saúde na proteção de dados confidenciais. Além disso, este documento destaca a necessidade de estabelecer uma cultura de colaboração entre as equipes de desenvolvimento, operações e segurança, visando a efetiva implementação de práticas de criptografia eficazes e robustas. Estando o Ministério da Saúde/DATASUS determinado a manter seu ambiente e produtos em conformidade legislações vigentes, bem como a garantir a segurança de seus usuários internos e externos. Isso reflete o compromisso do Ministério da Saúde/DATASUS em solidificar as bases de uma abordagem segura de Engenharia de Software, protegendo as informações críticas em sua esfera governamental.
Princípios e Práticas e Ferramentas Relacionadas
Tratando da criptografia em projetos de software seguro, temos princípios, métodos e práticas que devem ser considerados e avaliados para seu uso no projeto para que a segurança seja a base e eficácia seja uma constante. Com base na OWASP em seu Guia do desenvolvedor, no item 2.4 (Os princípios da criptografia) temos princípios e práticas relacionados que devem ser foco da atenção dos desenvolvedores e demais envolvidos em projetos de software seguro.
Quanto aos princípios temos os seguintes:
Confidencialidade
Para os fins desta seção, confidencialidade é definida como "nenhuma divulgação não autorizada de informações". A criptografia aborda isso por meio da criptografia de dados em repouso ou dados em trânsito, protegendo as informações contra aqueles que não possuem a chave de descriptografia. Hashes criptográficos (hashes seguros, de sentido único) são usados para evitar a divulgação de senhas.
Autenticação
Autenticação é o processo de verificar a alegação de que um sujeito é quem ele diz ser, por meio de alguma evidência corroborativa fornecida. A criptografia é central para a autenticação:
Proteger a evidência corroborativa fornecida (por exemplo, hash de senhas para armazenamento posterior).
Protocolos de autenticação frequentemente utilizam criptografia para autenticar entidades diretamente ou para trocar credenciais de maneira segura.
Verificar a identidade de uma ou ambas as partes na troca de mensagens, como a verificação de identidade dentro do Transport Layer Security (TLS).
O OpenID Connect é amplamente utilizado como uma camada de identidade sobre o protocolo OAuth 2.0, consulte o OAuth 2.0 Protocol Cheat Sheet.
Integridade
Integridade garante que, mesmo usuários autorizados, não tenham realizado alterações acidentais ou maliciosas nas informações. A criptografia pode ser utilizada para prevenir adulterações por meio de Códigos de Autenticação de Mensagem (MACs) ou assinaturas digitais.
Quanto à referência "autenticidade da mensagem", devemos entender como a garantia da integridade da informação, muitas vezes utilizando criptografia simétrica e chaves compartilhadas, mas não autentica a parte remetente.
Quando tratamos do termo "criptoautenticação" compreendemos que nesse ponto devemos tratar da garantia da integridade das informações e, caso a criptografia assimétrica seja utilizada, nesse caso criando a possibilidade de autenticar o remetente.
Não Repúdio
O não repúdio do remetente garante que a pessoa que envia uma mensagem não possa negar posteriormente que a enviou. O não repúdio do receptor garante que a pessoa que recebe a mensagem não possa negar que a recebeu. A criptografia pode ser usada para garantir o não repúdio fornecendo mensagens ou respostas inalteráveis.
O não repúdio é útil para transações financeiras, comércio eletrônico e trocas contratuais. Pode ser alcançado por meio da assinatura digital de um registro transacional único, feito pelo remetente ou receptor.
Atestação
Atestação é o ato de "testemunhar" ou certificar algo para um uso ou propósito específico. Atestação é geralmente discutida no contexto de um Módulo de Plataforma Confiável (TPM), Gestão de Direitos Digitais (DRM) e Inicialização Segura UEFI.
Por exemplo, a Gestão de Direitos Digitais se interessa por atestar que seu dispositivo ou sistema não foi comprometido com algum "backdoor" que permita copiar ilegalmente conteúdo protegido por DRM.
A criptografia pode ser usada para fornecer uma cadeia de evidências que tudo está conforme o esperado, provando para um desafiador que tudo está de acordo com as expectativas. A atestação remota pode ser utilizada para provar que você está realmente executando o software que diz estar executando. Atestação normalmente é realizada fornecendo uma cadeia de assinaturas digitais, começando com um carregador de inicialização (bootloader) assinado digitalmente.
Quanto ás práticas, podemos relacionar as seguintes:
Implantação em Sistemas Confiáveis
Garantir que os sistemas confiáveis estejam devidamente monitorados e atualizados para mitigar vulnerabilidades emergentes.
Abordagem aprofundada: Utilize verificações regulares de integridade no sistema, com o fim de evitar comprometimentos por malware ou acessos não autorizados.
Proteção da Senha Mestra
Utilize cofres digitais como HashiCorp Vault, AWS KMS ou Azure Key Vault para proteger a senha mestra, garantindo que ela nunca seja armazenada em texto plano ou em código.
Abordagem aprofundada: Adicione método de rotação periódica da senha mestra e garanta que acessos sejam registrados para auditorias.
Falhar com Segurança
Além registrar falhas, utilize um circuit breaker ou processos automáticos de fallback para evitar interrupções completas do serviço enquanto o ambiente é protegido.
Abordagem aprofundada: Aplique configurações de alertas em tempo real para notificações de falhas criptográficas e defina playbooks de resposta rápida.
Geradores de Números Aleatórios
Garanta através de estruturas testadas que geradores de números aleatórios estejam configurados para atender aos padrões como NIST SP 800-90A ou equivalentes.
Abordagem aprofundada: Desenvolva um processo de auditoria periódica para avaliar os geradores de números aleatórios, o objetivo deve ser de avaliar a força da aleatoriedade, especialmente quando usados para IDs ou valores críticos.
Compatibilidade com Padrões Criptográficos
Padrões e políticas a serem seguidos pela aplicação devem ser documentados de forma evidente, e incluir a conformidade com FIPS 140-3 (sucessor do FIPS 140-2).
Abordagem aprofundada: Apliquei processos de automação para verificações de compatibilidade durante o ciclo de desenvolvimento usando ferramentas de validação como o Cryptographic Module Validation Program (CMVP).
Política de Gerenciamento de Chaves
Parametrize e determinar regras para o gerenciamento de chaves, incluindo geração, distribuição, rotação, expiração e destruição.
Abordagem aprofundada: Integre práticas de segregação de funções (SoD) para evitar que uma única pessoa ou sistema controle completamente as chaves criptográficas.
¶Temos práticas que devem por recomendação ser adicionadas ao conjunto de ferramentas para proteção do projeto e dos dados tratados por ele. São as seguintes:
Princípio do Menor Privilégio
Desenvolva e utilize controles de acesso rígidos para limitar o acesso aos módulos e processos criptográficos. Somente e apenas componentes ou usuários que necessitam acessar as chaves devem ter permissão.
Rotação e Expiração de Chaves Criptográficas
Desenvolva e aplique políticas de rotação automática para chaves sensíveis com base em períodos predefinidos (ex.: 90 dias) e expiração forçada para evitar uso prolongado de chaves comprometidas.
Revisão e Atualização Regular de Algoritmos
Estabeleça uma política de revisão periódica dos algoritmos criptográficos em uso e substituir aqueles considerados obsoletos ou inseguros, como MD5 ou SHA-1.
Testes de Penetração Focados em Criptografia
Inclua cenários específicos em testes de segurança, como ataques de padding oracle, força bruta e downgrade, para validar a resiliência dos sistemas criptográficos.
Logs Seguros de Operações Criptográficas
Garanta que todas as operações criptográficas sejam registradas em logs protegidos, com anonimização de dados sensíveis e criptografia em repouso para os registros.
Integração Contínua e Scanners Automatizados
Tenha em sua grade de ferramentas elementos como SonarQube, OWASP Dependency-Check, ou Snyk para detectar dependências vulneráveis em bibliotecas de criptografia durante a integração contínua.
Criptografia End-to-End (E2EE)
Conforme a necessidade do projeto utilize criptografia ponta-a-ponta para evitar que dados sensíveis sejam expostos em pontos intermediários do sistema.
Criação de Backups Criptografados
Realize revisões para garantir que todos os backups que envolvam dados sensíveis sejam criptografados e armazenados em locais seguros com chaves de acesso separadas.
Auditorias Externas e Internas
Periodicamente realize processo de auditoria com especialistas externos para garantir que as práticas, metodologias e ferramentas definidas para o projeto atendam aos padrões mais recentes.
Agora restam apenas os componentes da estrutura de criptografia que devem estar presentes e também precisam de análise quanto e aplicação e uso, como os que seguem:
Vetores de Inicialização
Um vetor de inicialização (IV) criptográfico é uma entrada de tamanho fixo para a operação de criptografia/descriptografia de uma cifra de bloco. O IV é recomendado (e em muitos casos, exigido) para ser aleatório ou, no mínimo, pseudo-aleatório.
Preenchimento (Padding)
Exceto quando operam em modo de fluxo, as cifras de bloco geralmente operam em blocos de tamanho fixo. Essas cifras de bloco também precisam operar com mensagens de qualquer tamanho, não apenas aquelas que são múltiplos inteiros do tamanho do bloco da cifra, e assim a mensagem pode ser preenchida (padded) para se ajustar ao próximo bloco de tamanho fixo.
Cifras Assimétricas
Cifras assimétricas criptografam e descriptografam com duas chaves diferentes. Uma chave geralmente é designada como chave privada e a outra como chave pública. Normalmente, a chave pública é amplamente compartilhada e a chave privada é mantida em segurança.
As cifras assimétricas são várias ordens de magnitude mais lentas do que as cifras simétricas. Por essa razão, elas são usadas frequentemente em sistemas criptográficos híbridos, que combinam cifras simétricas e assimétricas. Em tais sistemas híbridos, uma chave de sessão simétrica aleatória é gerada, que é usada apenas durante a comunicação criptografada. Essa chave de sessão é então criptografada usando uma cifra assimétrica e a chave privada do destinatário. Os dados em texto claro são criptografados com a chave de sessão. Em seguida, o pacote inteiro (chave de sessão criptografada e mensagem criptografada) é enviado junto. TLS e S/MIME são sistemas criptográficos comuns que utilizam criptografia híbrida.
Assinatura Digital
Assinaturas digitais são cadeias de dados criptografadas usadas para garantir a integridade dos dados e provar a autenticidade de uma mensagem digital, associando uma mensagem de entrada com uma entidade de origem. Um algoritmo de geração de assinatura digital é um algoritmo com criptografia forte utilizado para gerar a assinatura digital.
Protocolos de Acordo de Chave
Protocolos de acordo de chave são protocolos pelos quais N partes (geralmente duas) podem concordar com uma chave comum sem realmente trocar a chave. Quando projetados e configurados corretamente, os protocolos de acordo de chave impedem que adversários descubram a chave ou forcem sua própria escolha de chave nas partes participantes.
Criptografia em Nível de Aplicação
Criptografia em nível de aplicação refere-se à criptografia que é considerada parte da própria aplicação; não implica nada sobre onde no código da aplicação a criptografia é realmente feita.
Derivação de Chave
Uma função de derivação de chave (KDF) é um algoritmo determinístico utilizado para derivar uma chave de um determinado tamanho a partir de algum valor secreto. Se duas partes usam o mesmo valor secreto compartilhado e a mesma KDF, elas devem sempre derivar exatamente a mesma chave.
Embalagem de Chave
A embalagem de chave é uma construção usada com cifras simétricas para proteger o material de chave criptográfica, criptografando-o de uma maneira especial. Algoritmos de embalagem de chave têm a intenção de proteger chaves enquanto estão armazenadas de maneira não confiável ou enquanto são transmitidas por redes de comunicação inseguras.
Protocolos de Troca de Chave
Protocolos de troca de chave são protocolos usados para trocar chaves criptográficas secretas entre um remetente e um receptor de maneira que atenda a certos requisitos de segurança. Protocolos de troca de chave tentam resolver o problema de compartilhar de maneira segura uma chave secreta comum entre duas partes por um canal de comunicação inseguro, de modo que nenhuma outra parte possa obter uma cópia da chave secreta.
O algoritmo de troca de chave mais familiar é o Diffie-Hellman. Existem também algoritmos de troca de chave autenticados por senha. A troca de chave RSA usando PKI ou redes de confiança ou servidores de chave confiáveis também são comumente usadas.
Protocolos de Transporte de Chave
Protocolos de transporte de chave são aqueles onde uma parte gera a chave e a envia de maneira segura para o(s) destinatário(s).
Protocolos de Acordo de Chave
Protocolos de acordo de chave são protocolos pelos quais N partes (geralmente duas) podem concordar com uma chave comum com todas as partes contribuindo para o valor da chave. Esses protocolos impedem que adversários descubram a chave ou forcem sua própria escolha de chave nas partes participantes.
Descrição da Implantação do Processo de Proteção de Dados
Identificar dados sensíveis e confidenciais – Determinar quais dados a serem protegidos, incluindo dados pessoais, credenciais e informações críticas do sistema.
Definir padrões de conformidade – Usar como fundamentos a LGPD, GDPR, ISO/IEC 27001 e NIST para identificar os requisitos de proteção de dados por meio de criptografia.
Especificar requisitos de algoritmos seguros: – Aplicar algoritmos como AES-256 (criptografia simétrica) e RSA (criptografia assimétrica).
Incorporar criptografia desde o início – Definir arquitetura que garanta segurança ao sistema e integrar mecanismos de criptografia para dados em trânsito e repouso.
Desenvolver sistemas com chaveamento seguro – Utilizar bibliotecas e metodologias recomendadas para gerenciar chaves, como HashiCorp Vault.
Modelagem de ameaças: – Realizar busca por vetores de ataque relacionados à criptografia, como ataques de força bruta ou de downgrade.
Revisar configurações de criptografia – Testar força e segurança dos algoritmos utilizados no projeto.
Testar vulnerabilidades – Realizar testes para identificar ataques de downgrade, configurações inseguras ou uso de algoritmos obsoletos como MD5 e DES.
Auditar fluxos de dados criptografados – Assegurar que não há dados sensíveis sendo transmitidos sem criptografia.
Rotação periódica de chaves – Definir e aplicar políticas de rotação de chaves de criptografia regularmente.
Monitoramento de falhas – Parametrizar e configurar alertas para identificar falhas na aplicação de criptografia ou uso de chaves inválidas.
Atualização de bibliotecas – Revisar versões de bibliotecas de criptografia para a manutenção do processo de atualização prevenindo assim vulnerabilidades conhecidas.
Durante a fase inicial do projeto, ao iniciar o ciclo de vida do desenvolvimento.
Por que deve ser feito
Para identificar e definir as tratativas ligadas aos dados sensíveis e confidenciais que precisam de proteção por criptografia. Garantir que o projeto esteja em conformidade com normas, regulamentações e boas práticas e trabalhar intensamente na redução de riscos de vazamento de informações mantendo a integridade e confidencialidade dos 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.
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
Políticas internas de segurança da informação.
Normas regulatórias aplicáveis ao projeto (LGPD, GDPR, ISO/IEC 27001).
Desenho com especificações de fluxos de dados sensíveis.
Modelagem preliminar de ameaças.
O que é necessário definir nessa etapa
Quais dados precisam de proteção criptográfica - Dados pessoais, credenciais, transações financeiras.
Em que partes do projeto e como será aplicada a criptografia - Em trânsito, em repouso, ou ambos.
Quais serão os algoritmos e padrões recomendados - TLS 1.3, AES-256 ou RSA.
Definir os requisitos de gerenciamento de chaves - Rotação, armazenamento seguro, expiração.
Elencar os critérios de conformidade normatiza ou regulatória - Anonimização, Pseudonimização, criptografia robusta.
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:
Documento com os requisitos de criptografia, com algoritmos especificados, fluxos de dados protegidos e controles de segurança.
Listagem pontos sensíveis demandam a configuração de criptográfica.
Proposta inicial de estrutura de segurança relacionada à criptografia.
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 o Levantamento de Requisitos
Aplicar o princípio de minimização de dados, protegendo apenas o necessário, reduzindo superfícies vulneráveis.
Utilizar padrões e referências reconhecidos (ISO/IEC, OWASP, NIST) para parametrizar algoritmos e métodos de criptografia.
Manter como padrão criptografia end-to-end nos casos de dados críticos.
Revisar requisitos com base nos riscos identificados na modelagem de ameaças.
Ferramentas recomendadas
Casos de Modelagem de Ameaças - Microsoft Threat Modeling Tool, OWASP Threat Dragon.
Casos de Gestão de Requisitos - Jira, Confluence.
Casos de Análise de Fluxos de Dados - Data Flow Diagramming (DFD) com Lucidchart, Draw.io.
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 garantir que a proteção dos dados e as práticas de criptografia sejam agregadas ao design da aplicação desde o início. Minimizar custos e riscos associados à aplicação equivocada de controles criptográficos. Além de alinha o desenho do projeto com regulamentações como LGPD, GDPR e normas ISO.
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.
Equipe de Infraestrutura e Equipe de Banco de Dados (Modelo colegiado).
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).
Políticas internas de segurança da informação e privacidade.
Modelagem de ameaças focada em criptografia.
O que precisamos definir na Etapa de Security by Design
Arquitetura criptográfica – Proteção de dados em trânsito e repouso.
Algoritmos e padrões – Utilizar AES-256 para criptografia simétrica e RSA para assinaturas digitais.
Fluxos de dados - Pontos de entrada e saída dos dados protegidos com criptografia.
Gerenciamento de chaves – Uso de rotação periódica, armazenamento seguro com HashiCorp Vault.
Políticas de fallback – tratamento de cenários de falha de criptografia, como no caso de TLS downgrade attack.
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:
Modelo arquitetural detalhado com integrações criptográficas.
Listagem dos fluxos de dados protegidos e os algoritmos associados.
Guia de referência técnica para desenvolvedores sobre a aplicação detalhando os mecanismos de criptografia definidos.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Engenheiro de Software, Arquiteto de Soluções e o DPO da organização.
Práticas recomendadas para o Security by Design
Definir e configurar Defesa em Profundidade - realizando a combinação de técnicas e ferramentas de criptografia em trânsito, repouso e end-to-end.
Priorizar algoritmos modernos e robustos - Utilizar TLS 1.3, AES-256 e SHA-256, evitando algoritmos desatualizados como MD5 e DES.
Revisar e validar definições do design – para tratamento de cenários de ataque conhecidos como MITM e força bruta em chaves.
Uso de ferramentas de modelagem de ameaças – Busca e identificação de vulnerabilidades no design definido.
Ferramentas recomendadas
Criptografia no Desenvolvimento: Crypto (Node.js), Cryptography (Python), BouncyCastle (Java).
Gestão de Chaves: HashiCorp Vault, AWS KMS, Azure Key Vault.
Validação do Design: OWASP ZAP (testes de TLS), SSL Labs (verificação de segurança em conexões).
Modelagem de Ameaças: OWASP Threat Dragon, Microsoft Threat Modeling Tool.
Testes e Avaliações Iniciais
Teste de segurança das conexões TLS configuradas no design.
Revisar os algoritmos criptográficos em relação aos requisitos de conformidade.
Revisar o design definido em busca de registros de ataques de downgrade e exposição de chaves.
Simular eventos de fluxo de dados simulados visando verificar a criptografia nos pontos críticos.
Referências técnicas
ISO/IEC 27001 e 27002
ISO/IEC 27034
OWASP Cryptographic Storage Cheat Sheet
NIST SP 800-57 - Diretrizes para gerenciamento de chaves criptográficas.
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
Avaliar se as práticas de criptografia definidas no design sejam configuradas corretamente. Para a proteção dos dados sensíveis em trânsito e repouso, visando assegurar que os requisitos regulatórios (LGPD, GDPR) e normas técnicas sejam devidamente atendidos na execução da aplicação.
Quem define os Atores e Ações da Etapa de Execução Segura
Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução.
Equipe de Desenvolvimento, de Infraestrutura e Equipe de Banco de Dados (Modelo colegiado).
Quem define os Atores responsáveis pela Validação dos processos da Etapa de Execução
Coordenação de Desenvolvimento e Coordenação de Segurança
Equipe de Desenvolvimento (Código, integrações e arquitetura), Equipe de Infraestrutura (Sistema Operacional) e Equipe de Banco de Dados (Dados armazenados).
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 técnico de integração de bibliotecas criptográficas.
O que precisamos definir na Etapa de Execução Segura
Configuração de algoritmos robustos – Podendo ser utilizado o AES-256 (para dados em repouso) e TLS 1.3 (para dados em trânsito).
Bibliotecas confiáveis – Bibliotecas capazes de realizar os processos de criptografia como Crypto, Cryptography e BouncyCastle.
Gerenciamento de chaves - Para garantir segurança e rotação de chaves utilizando ferramentas como HashiCorp Vault e AWS KMS.
Definir Pontos Críticos de Criptografia – como a autenticação, transações financeiras e armazenamento de credenciais.
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 configurado com criptografia ativa, acoplada ao código conforme os padrões definidos.
Relatórios e definições de Logs com o detalhamento das configurações criptográficas aplicadas.
Documentação com detalhamento do uso de bibliotecas, configuração de TLS e gerenciamento de chaves.
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
Utilizar prioritariamente algoritmos criptográficos atuais com criptografia de alto nível.
Ao configurar conexões prefira o protocolo TLS 1.3 ou superior e utilize sempre certificados válidos.
Dados sensíveis (armazenados) em repouso devem ser criptografados com AES-256.
O gerenciamento de chaves deve ser realizado fora do código-fonte, e protegidas por soluções especializadas como HashiCorp Vault.
Defina e configure revisões de integridade para detectar adulterações em dados criptografados.
Ferramentas recomendadas
Criptografia no Código: Crypto (Node.js), Cryptography (Python), BouncyCastle (Java).
Gerenciamento de Chaves: HashiCorp Vault, AWS KMS, Azure Key Vault.
Configuração de TLS: OpenSSL, Certbot (Let’s Encrypt).
Validação de Configurações: SSL Labs (testes de TLS), OWASP ZAP (análise de conexões).
Testes e Avaliações Iniciais
Testar e revisar conexões HTTP quanto ao uso obrigatório do HTTPS com TLS devidamente configurado.
Avaliar o funcionamento da criptografia em pontos críticos, como login e autenticação, garanta que dados sensíveis não sejam transmitidos sem proteção.
Verificar se o armazenamento de chaves criptográficas está sendo realizado em sistemas seguros e se por definição não são expostas no código ou logs.
Revise o código analisando as bibliotecas utilizadas, todas devem ser confiáveis e recomendadas por entidades reconhecidas.
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 validar se os controles, ferramentas e demais estruturas de criptografia definidos e configurados protegem os dados de forma eficaz. Buscar possíveis vulnerabilidades como o uso de algoritmos fracos ou configurações inadequadas de criptografia. Além de analisar a conformidade com padrões e normas vigentes e aplicáveis ao projeto.
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.
O que precisamos definir na Etapa de Teste de Segurança
Criação de cenários de testes críticos – Testar todos os componentes relacionados à criptografia do projeto, o que inclui verificações de TLS, armazenamento seguro de dados e gerenciamento de chaves.
Definir critérios para identificar vulnerabilidades – Buscas por algoritmos obsoletos ou falhas na configuração.
Metodologias de Validação – Definir as metodologias que as equipes usarão para analisar se o projeto está em conformidade com padrões como NIST e OWASP.
O que precisamos entregar para a próxima etapa (Gerenciamento)
Relatório dos Testes de Segurança, contendo:
Informações sobre possíveis vulnerabilidades identificadas e ações corretivas aplicadas.
Logs detalhados de testes realizados, incluindo evidências de conformidade com regulamentos.
Documentação atualizada de configurações e controles criptográficos configurados.
Detalhamento de vulnerabilidades identificadas e ações corretivas aplicadas.
Logs detalhados de testes realizados, incluindo evidências de conformidade com regulamentos.
Documentação atualizada de configurações e controles criptográficos utilizados.
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
Uso de ferramentas automatizadas para identificar vulnerabilidades criptográficas conhecidas.
Aplicação de testes manuais para validar fluxos críticos e configurações TLS.
Revisar se os dados sensíveis estão sendo armazenados ou transmitidos com criptografia por padrão.
Avaliar a segurança das chaves de criptografia, incluindo seu armazenamento, rotação e exclusão segura.
Definir ciclos de análise de conformidade com regulamentações.
Ferramentas recomendadas
Testes de TLS e Configurações - SSL Labs, OWASP ZAP, Burp Suite.
Análise de Código Estático - SonarQube, Snyk.
Gerenciamento de Vulnerabilidades - Nessus, Qualys.
Testes de Criptografia no Código - CryptoLint, Crylogger.
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. Ligar o processo de testes ao deploy, incluindo os testes na esteira de desenvolvimento e produção aumenta a segurança e confere agilidade ao processo como um todo permitindo que novas versões do projeto sejam liberadas já com os testes realizados por padrão.
Realizar Testes de Conexões de Rede - avaliar e validar o uso de HTTPS com TLS 1.3 ou superior.
Testar de Força – Avaliar os algoritmos configurados, visando garantir o uso de padrões como AES-256 e SHA-256.
Testar Segurança das Chaves - Validar a segurança do armazenamento de chaves, garantindo que estejam protegidas contra acessos não autorizados.
Ataques Simulados - Simular cenários de ataque, como Força Bruta e MITM (Man-In-The-Middle).
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 que os sistemas criptográficos possuam gestão eficaz ao longo de sua vida útil. Com o objetivo de manter a conformidade com normas e padrões aplicáveis. Permitindo assim a prevenção de falhas de segurança relacionadas ao uso inadequado de criptografia e ao gerenciamento de chaves.
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 (atualização de sistemas, patchs e CVEs atualizadas, além das aplicações legadas existentes no ambiente) e Banco Dados (versionamento, patchs e CVEs atualizadas).
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 Banco Dados.
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.
Políticas de gerenciamento de chaves e criptografia.
Diretrizes de conformidade regulatória (LGPD, GDPR, ISO/IEC 27001).
Relatórios de testes de segurança realizados.
Plano de ciclo de vida de chaves criptográficas.
O que precisamos definir na Etapa de Gerenciamento
Estratégias de Gerenciamento de Chaves - Geração, rotação, expiração, destruição segura.
Políticas de retenção de dados criptografados – Alinhar parâmetros aos requisitos regulatórios internos e externos.
Desenvolver Processos de Atualização - Monitoramento de Algoritmos e Padrões Criptográficos (NIST, ENISA), Análise de Impacto sobre sistemas, aplicações e integrações, Definição de Prazos e Ciclos de Vida dos Algoritmos, Planejamento para Substituição Gradual (Backward Compatibility), Testes de Integração e Validação, Automatização e Orquestração de Atualizações, Documentação e Resiliência Criptográfica (Crypto Agility).
Regras de acesso aos sistemas de gerenciamento – definir quem, como e por quanto tempo terá acesso aos sistemas de gerenciamento de chaves, dependendo da necessidade de intervenção no ambiente ou no projeto de forma geral.
Garantias de Integridade – Desenvolver e definir os métodos para garantidores da integridade dos dados protegidos por criptografia.
O que precisamos entregar para a próxima etapa (Monitoramento)
Relatório ou Planos de Gerenciamento de Segurança, contendo:
Padrões e planos de gerenciamento de chaves e criptografia documentadas e configuradas, planos de atualização e revisão de componentes e ferramentas de criptografia.
Relatórios de conformidade com políticas de gerenciamento.
Logs e métricas de uso de criptografia e chaves, prontos para monitoramento contínuo.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Gestores das Equipes de Infraestrutura, Engenheiros de Software (configuração técnica); Arquitetos de Segurança (supervisão); DPO (validação regulatória).
Práticas recomendadas para os Testes de Segurança
Desenvolver e aplicar políticas claras de ciclo de vida de chaves, incluindo rotação periódica e destruição segura.
Garantir por meio de padronização e revisão, que algoritmos criptográficos obsoletos sejam identificados e substituídos em tempo hábil.
Centralizar o gerenciamento de chaves utilizando ferramentas seguras.
Utilizar o princípio do menor privilégio para restringir o acesso às chaves de criptografia.
Auditar continuamente a conformidade do projeto e seus componentes com as políticas e regulamentações definidas.
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 responder a eventos anômalos relacionados à criptografia, como falhas de chaves, tentativas de quebra ou configurações inadequadas. - Assegurar a conformidade contínua com LGPD, GDPR e normas ISO. - Proteger dados sensíveis em tempo real contra violações.
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, 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
Desenvolvimento, Equipes de Qualidade 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ó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.
O que precisamos definir na Etapa de Teste de Segurança
Padrões de Monitoramento – Definir os eventos e níveis de criticidade para o monitoramento como acessos não autorizados, falhas de descriptografia, anomalias de chaves.
Definir KPIs – Definir os indicadores-chave de desempenho (KPIs) para medir a segurança da criptografia usada no projeto.
Definir Regras de Resposta Automática – Parâmetros de resposta para eventos ou incidentes de segurança relacionados à criptografia.
Tratamento de Logs - Requisitos de geração, retenção e exclusão de logs de monitoramento. Esse processo é tratado com melhor direcionamento se a organização já possuir uma Política de Gerenciamento de Chaves Criptográficas atualizada.
Gerenciamento de Certificados - Tratar a administração da CA (entidade certificadora) em parceria com a equipe de Infraestrutura, focando no tratamento e gestão de certificados.
Relatórios de Incidentes de Segurança - Tratamento das informações de Incidentes de segurança, desde os incidentes reais até os falsos positivos para melhor treinamento das ferramentas de monitoramento (SIEM), trabalhar em parceria com as equipe de Segurança (SOC) da organização.
Registros de Atividades Suspeitas – Como devem ser registrados, comunicados e documentos os eventos ou comportamentos suspeitos relacionados ao projeto, trabalhar em parceria com as equipe de Segurança (SOC) da organização.
O que precisamos entregar
Relatório de Incidentes de Segurança, incluindo:
Configurações de monitoramento ativo, incluindo alertas e relatórios para eventos de segurança criptográfica.
Documentação atualizada das métricas monitoradas e processos de resposta.
Logs detalhados e centralizados para auditorias e investigações futuras.
Referências para atualizações na política de gerenciamento de chaves.
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 os Testes de Segurança
Configurar alertas automatizados - Nos casos de eventos críticos, como falhas de autenticação TLS ou tentativas de descriptografia não autorizadas.
Centralize Informações de Registros - Logs de segurança devem ser centralizados em ferramentas robustas, como o Elastic Stackn e Splunk.
Proteger de Logs Sensíveis - Utilize criptografia para proteger logs sensíveis, garantindo integridade e confidencialidade.
Realize Auditorias – A organização deverá regularmente validar a eficácia do monitoramento e a conformidade com regulamentações.
Implantar Respostas Automatizadas a Incidentes – Tratar incidentes de forma automatizada com ferramentas profissionais dará suporte a processo de mitigação de ameaças e correções de falhas com agilidade, garantindo mais segurança ao ambiente e usuários.
Ferramentas recomendadas
Monitoramento de Eventos Criptográficos - Splunk, Elastic Stack, Datadog.
Durante todo o ciclo de desenvolvimento, devendo ter as atividades enfatizadas nas etapas de design, codificação, operação e gerenciamento contínuo. Revisões, atualizações e auditorias devem ser periódicas.
Por que deve ser feito
Para que a confidencialidade, integridade, disponibilidade e a proteção de dados pessoais sejam garantidas. Dar subsídios para atender às regulamentações como LGPD e GDPR que exigem a aplicação de criptografia para proteção de dados sensíveis. Além de fornecer recursos e referências para reduzir riscos de vazamento e acesso não autorizado a dados pessoais.
Quem define os Atores e Ações na Etapa de Proteção de Dados Pessoais
Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução.
Engenheiros de Software, Arquitetos de Segurança e Soluções e DPO.
Quem define os Atores responsáveis pela Validação dos processos da Etapa de Proteção de Dados Pessoais
Coordenação de Desenvolvimento e Coordenação de Segurança
Equipes de Qualidade, de Segurança, DOP e Auditores Internos (ou externos).
Quais os documentos necessários para a etapa de Proteção de Dados Pessoais
Relatório dos Requisitos do Projeto (Etapa I)
Relatório ou Plano de Design de Sistema Atualizado (Etapa II)
Relatório de Execução Segura do Projeto (Etapa III)
Relatório dos Testes de Segurança (Etapa IV)
Relatório ou Planos de Gerenciamento de Segurança(Etapa V)
Relatório de Incidentes de Segurança (Etapa VI)
Políticas de privacidade e proteção de dados (baseadas em LGPD e GDPR).
Plano de resposta a incidentes relacionados à violação de dados pessoais.
O que precisamos definir nesta tapa
Definir os dados pessoais que serão processados e repositórios para armazenamento dos dados.
Métodos de proteção, como criptografia em trânsito e repouso, e Anonimização/Pseudonimização.
Planos e estratégias de gerenciamento de chaves para dados pessoais criptografados.
Requisitos para logs protegidos especificando as informações sobre acessos e operações em dados pessoais.
Artefatos a serem gerados nessa etapa
Referência e especificação dos dados pessoais a serem criptografados em todas as fases de seu ciclo de vida.
Mecanismos utilizados para Anonimização ou Pseudonimização conforme análise das equipes de arquitetura de desenvolvimento e segurança.
Documentação de conformidade regulatória dos métodos de criptografia utilizados no projeto.
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 criptografia forte (AES-256, RSA-2048) para proteger dados pessoais em repouso e em trânsito.
Aplique técnicas de Anonimização e Pseudonimização em dados sensíveis por padrão.
Defina como itens a serem protegidos logs que contenham informações sobre dados pessoais, garantindo sua integridade e confidencialidade.
Fortaleça os padrões de controle de acesso aos dados, seguindo o princípio do menor privilégio.
Audite regularmente para identificar possíveis vulnerabilidades em processos de proteção de dados pessoais.
Ferramentas recomendadas
Criptografia de Dados - Crypto (Node.js), Cryptography (Python), BouncyCastle (Java).
Testes de Criptografia - Realize testes de criptografia para validar a funcionalidade da proteção de dados em trânsito e em repouso.
Auditoria no Repositório – revise as estruturas e configurações do ambiente de armazenamento de dados pessoais, o objetivo é garantir que informações confidenciais estão protegidas adequadamente.
Ataques Simulados - Simular ataques como a interceptação de dados em trânsito e acesso não autorizados, para testar as ferramentas e configurações de defesa.
Auditoria de Conformidade - Validar a conformidade das práticas utilizadas no projeto com LGPD, GDPR e normas ISO.
Referências técnicas
ISO/IEC 27001 e 27002
ISO/IEC 29134
OWASP Cryptographic Storage Cheat Sheet
NIST SP 800-122 - Guia para proteção de informações pessoalmente identificáveis (PII).
LGPD e GDPR: Regulamentações para proteção de dados pessoais.
Considerações Finais
A definição e configuração de ferramentas de criptografia são essenciais para garantir a segurança dos dados em sistemas modernos. Este capítulo forneceu uma abordagem detalhada para integrar práticas de criptografia em todas as fases do ciclo de desenvolvimento seguro de software, enfatizamos a conformidade regulatória, escolha de algoritmos robustos e a aplicação de ferramentas modernas e reconhecidas. Adotar boas práticas, junto com o treinamento contínuo das equipes e auditorias regulares, é fundamental para prevenir ameaças e proteger informações sensíveis.
A colaboração entre equipes de desenvolvimento, operações e segurança estabelece bases sólidas para aplicações resilientes, comprometidas com a proteção dos dados. Esses processos são dinâmicos, evoluindo na mesma linha temporal da tecnologia, o que demanda das equipes envolvidas no desenvolvimento do projeto aprendizado e melhorias contínuas para que o Ministério da Saúde esteja devidamente preparado para enfrentar desafios e garantir a integridade e confidencialidade dos dados críticos em constante evolução.
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.
NIST SP 800-57 - Diretrizes para gerenciamento de chaves criptográficas.