No desenvolvimento seguro e manutenção de sistemas de informação no âmbito do Ministério da Saúde/DATASUS, a segurança cibernética é um pilar que deve ser dado como fundamental para a proteção de dados sensíveis e a garantia da continuidade dos serviços essenciais da saúde pública. Os processos de HARDENING e a aplicação de linhas de base de segurança ou BASELINES são sugeridos como estratégias críticas dentro deste contexto, visando minimizar vulnerabilidades e reforçar as defesas contra ameaças cibernéticas. Sendo assim, este documento, referente à SPRINT 12 - Configuração de Sistemas do Guia de Desenvolvimento Seguro do Ministério da Saúde/DATASUS, propõe a incorporação das abordagens e conceitos já tratados de Segurança no Design alinhando-se às Melhores Práticas de Codificação Segura recomendadas pelo OWASP, com ênfase na Configuração do Sistema.
Definir procedimentos para a configuração segura de sistemas. Implementar práticas de hardening para reduzir superfícies de ataque. Garantir a conformidade com regulamentações como LGPD e GDPR. Proporcionar um guia de ferramentas e frameworks para o processo de configuração de sistemas. Orientar as equipes de desenvolvimento na adoção de medidas de segurança desde a concepção até a execução e manutenção das aplicações.
Hardening refere-se ao conjunto de ações realizadas para reforçar a segurança de sistemas e aplicações, reduzindo sua superfície de ataque e eliminando vulnerabilidades. No âmbito do Ministério da Saúde/DATASUS, o processo de hardening abrange desde a atualização e aplicação de patches de segurança em servidores, frameworks e componentes do sistema, até a desativação de listagem de diretórios e restrição de privilégios de contas de serviço e processos. A prática de hardening visa assegurar que apenas funcionalidades essenciais sejam mantidas ativas, enquanto funcionalidades e acessos desnecessários são eliminados, mitigando o risco de exploração por agentes mal-intencionados.
As linhas de base de segurança representam um conjunto de padrões ou configurações mínimas de segurança que devem ser aplicadas a todos os sistemas e aplicações para garantir um nível aceitável de proteção. Essas linhas de base funcionam como um guia para a configuração segura de sistemas, orientando o Ministério da Saúde/DATASUS na aplicação de práticas de segurança consistentes e auditáveis. A definição de linhas de base envolve a especificação de versões aprovadas de softwares, a aplicação sistemática de atualizações, a configuração adequada de arquivos como "robots.txt" para prevenir a indexação de arquivos sensíveis e a gestão rigorosa de mudanças, garantindo que as alterações no sistema sejam controladas e documentadas.
A Segurança no Design enfatiza a importância de considerar a segurança desde as fases iniciais de desenvolvimento de um projeto, integrando práticas de modelagem de ameaças, inspeção de código e testes de invasão para identificar e mitigar proativamente vulnerabilidades. Por outro lado, há também a Segurança por Default que assegura que configurações e funcionalidades padrão sejam estabelecidas com o máximo de restrição, adotando o menor privilégio e desabilitando serviços não essenciais por padrão, reduzindo assim a superfície de ataque disponível para exploração em sistemas desenvolvidos pelo Ministério da Saúde/DATASUS.
A Configuração Incorreta de Segurança nos Sistemas apresenta um risco exponencial quando uma configuração pré-definida de segurança é adotada na aplicação, incluindo frameworks, servidor de aplicação, servidor web, banco de dados e plataforma. Isso ocorre porque tal abordagem facilita a previsibilidade para possíveis invasores, que podem explorar padrões conhecidos, aumentando a probabilidade de vulnerabilidades. Diante disso, é altamente recomendado que todas as configurações sejam cuidadosamente definidas, aplicadas e mantidas, evitando assim a insegurança inerente às configurações padrão. A atualização regular do software é uma medida crucial para mitigar possíveis brechas de segurança e manter a robustez do ambiente.
O processo de Configuração do Sistema será aplicado nas seguintes etapas do ciclo de desenvolvimento seguro de software SDLC (Software Development Life Cycle):
|
LEVANTAMENTO DE REQUISITOS |
|
|
Quando deve acontecer No início do ciclo de vida do desenvolvimento de software, antes de iniciar a fase de design. |
Porque deve ser feito Para identificar e documentar os requisitos de segurança necessários para proteger a aplicação e os 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. Por exemplo: Analistas de Requisitos, Arquitetos de Segurança e Arquitetos de Software. |
Quem define os Atores responsáveis pela Validação do Levantamento de Requisitos Coordenação de Segurança da Informação Realiza a chamada de equipes para validação das partes da aplicação. Por exemplo: Analistas de Segurança, Arquitetos de Software, Analistas de Qualidade e Equipe de Infraestrutura. |
|
Quais os documentos necessários para a etapa de Levantamento de Requisitos?
|
|
|
O que precisamos definir na Etapa de LEVANTAMENTO DE REQUISITOS?
|
|
|
O que precisamos entregar para a próxima etapa (SECURITY BY DESIGN)? Relatório dos Requisitos do Projeto, contendo:
Responsáveis pela entrega: Coordenação de Desenvolvimento, Analistas de Requisitos, Arquitetos de Segurança e Arquitetos de Software. |
|
|
Práticas recomendadas
|
|
|
Ferramentas recomendadas
|
|
|
Testes e Avaliações Iniciais
|
|
|
Referências
|
|
|
SECURITY BY DESIGN |
|
|
Quando deve acontecer Durante a fase de design e arquitetura do ciclo de vida do desenvolvimento de software. |
Porque deve ser feito Para incorporar medidas de segurança desde a concepção do sistema, reduzindo riscos e custos futuros de mitigação. Integrar medidas de Hardening e segurança diretamente no design do sistema para evitar vulnerabilidades e garantir conformidade. |
|
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. Por exemplo: Equipe de Arquitetura de Software e Segurança da Informação, com participação dos Desenvolvedores e DevOps. |
Quem define os Atores responsáveis pela Validação do Design Coordenação de Segurança da Informação - Realiza a chamada de equipes para validação das partes da aplicação. Por exemplo: Analistas de Qualidade e Analistas de Segurança. |
|
Os documentos necessários para a etapa de SECURITY BY DESIGN e suas definições?
|
|
|
O que precisamos definir na etapa de SECURITY BY DESIGN?
|
|
|
O que precisamos entregar para a próxima etapa (EXECUÇÃO SEGURA)? Relatório ou Plano de Design de Sistema Atualizado, contendo:
Responsáveis pela entrega: Coordenação de Desenvolvimento, Arquitetos de Software, Analistas de Segurança da Informação, com participação dos Desenvolvedores e DevOps. |
|
|
Práticas recomendadas
|
|
|
Ferramentas recomendadas
|
|
|
Testes e Avaliações Iniciais
|
|
|
Referências:
|
|
|
EXECUÇÃO SEGURA |
|
|
Quando acontece Durante a fase de aplicação e uso modelos, ferramentas e bibliotecas no desenvolvimento contínuo do ciclo de vida do desenvolvimento de software. |
Porque deve ser feito Para garantir que a execução do sistema esteja em conformidade com os requisitos de segurança definidos, minimizando vulnerabilidades e riscos. |
|
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. Por exemplo: Equipe de Desenvolvimento, Equipe de Segurança da Informação e DevOps, com orientação de Arquitetos de Segurança. |
Quem define os Atores responsáveis pela Validação do Design Coordenação de Segurança da Informação – Define e realiza a chamada de equipes para validação das partes da aplicação. Por exemplo: Analista de Qualidade de Segurança e Analistas de Segurança, em colaboração com Gestores de Projeto. |
|
Os documentos necessários para a etapa de EXECUÇÃO SEGURA e suas definições?
|
|
|
O que precisamos definir na etapa de EXECUÇÃO SEGURA?
|
|
|
O que precisamos entregar para a próxima etapa (TESTE DE SEGURANÇA)? Relatório ou Plano de Design de Sistema Atualizado, contendo:
Responsáveis pela entrega: Coordenação de Desenvolvimento, Arquitetos de Software e Engenheiros de Segurança e Desenvolvedores. |
|
|
Práticas recomendadas
|
|
|
Ferramentas recomendadas
|
|
|
Testes e Avaliações Iniciais
|
|
|
Referências:
|
|
|
TESTE DE SEGURANÇA |
|
|
Quando acontece Após a fase de Execução Segura e antes da implantação em produção, e regularmente durante o ciclo de vida da aplicação. |
Porque deve ser feito Para identificar e corrigir vulnerabilidades de segurança antes da implantação, garantindo a proteção dos dados e a conformidade com regulamentos. |
|
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. Por exemplo: Equipe de Segurança da Informação, Analistas de Segurança, em colaboração com Desenvolvedores e DevOps. |
Quem define os Atores responsáveis pela Validação da Etapa de Execução Segura Coordenação de Segurança da Informação – Define e realiza a chamada de equipes para validação das partes da aplicação. Por exemplo: Analista de Qualidade de Segurança e Analistas de Segurança, em colaboração com Gestores de Projeto. |
|
Os documentos necessários para a etapa de TESTE DE SEGURANÇA e suas definições?
|
|
|
O que precisamos definir na etapa de TESTE DE SEGURANÇA?
|
|
|
O que precisamos entregar para a próxima etapa (GERENCIAMENTO)? Relatório dos Testes de Segurança, contendo:
Responsáveis pela entrega: Coordenação de Desenvolvimento, Arquitetos de Software e Engenheiros de Segurança e Desenvolvedores. |
|
|
Práticas recomendadas
|
|
|
Ferramentas recomendadas
|
|
|
Testes e Avaliações Iniciais
|
|
|
Referências:
|
|
|
GERENCIAMENTO |
|
|
Quando acontece Durante e após a fase de execução e testes do projeto, e continuamente durante todo o ciclo de vida da aplicação. |
Porque deve ser feito Para garantir a detecção precoce de incidentes de segurança, monitorar a integridade do sistema e garantir a conformidade contínua com as regulamentações. |
|
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. Por exemplo: Equipe de Segurança da Informação, em colaboração com DevOps, Analistas de Segurança e Gestores de Projeto. |
Quem define os Atores responsáveis pela Validação do Design Coordenação de Segurança da Informação – Define e realiza a chamada de equipes para validação das partes da aplicação. Por exemplo: Analista de Qualidade de Segurança e Analistas de Segurança, em colaboração com Gestores de Projeto. |
|
Os documentos necessários para a etapa de GERENCIAMENTO e suas definições?
|
|
|
O que precisamos definir na etapa de GERENCIAMENTO?
|
|
|
O que precisamos entregar para a próxima etapa (MONITORAMENTO)? Relatório ou Planos de Gerenciamento de Segurança, contendo:
Responsáveis pela entrega: Coordenação de Desenvolvimento, Arquitetos de Software e Engenheiros de Segurança e Desenvolvedores. |
|
|
Práticas recomendadas
|
|
|
Ferramentas recomendadas
|
|
|
Testes e Avaliações Iniciais
|
|
|
Referências:
|
|
|
MONITORAMENTO |
|
|
Quando acontece Durante e após a fase de execução e aplicação dos recursos determinados nos detalhamentos, e continuamente durante todo o ciclo de vida da aplicação. |
Porque deve ser feito Para garantir a detecção precoce de incidentes de segurança, monitorar a integridade do sistema e garantir a conformidade contínua com as regulamentaçõ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. Por exemplo: Equipe de Desenvolvimento, Equipe de Segurança da Informação e DevOps, com orientação de Arquitetos de Segurança. |
Quem define os Atores responsáveis pela Validação da Etapa de Monitoramento Coordenação de Segurança da Informação – Define e realiza a chamada de equipes para validação das partes da aplicação. Por exemplo: Analista de Qualidade de Segurança e Analistas de Segurança, em colaboração com Gestores de Projeto. |
|
Os documentos necessários para a etapa de MONITORAMENTO e suas definições?
|
|
|
O que precisamos definir na etapa de MONITORAMENTO?
|
|
|
O que precisamos entregar nesta etapa? Relatórios de monitoramento de segurança atualizado, contendo:
Responsáveis pela entrega: Coordenação de Desenvolvimento, Arquitetos de Software e Engenheiros de Segurança e Desenvolvedores. |
|
|
Práticas recomendadas
|
|
|
Ferramentas recomendadas
|
|
|
Testes e Avaliações Iniciais
|
|
|
Referências:
|
|
|
PROTEÇÃO DE DADOS PESSOAIS |
|
|
Quando acontece Durante a fase de planejamento, design e execução da aplicação, e durante todo o ciclo de vida da aplicação. |
Porque deve ser feito Para garantir a proteção de dados pessoais desde o planejamento do sistema, assegurando conformidade com regulamentações como LGPD e GDPR e prevenindo vazamentos de dados. |
|
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. Por exemplo: Equipe de Segurança da Informação, com participação de Desenvolvedores, DevOps, Gestores de Projetos e o Data Protection Officer (DPO). |
Quem define os Atores responsáveis pela Validação do Design Coordenação de Segurança da Informação – Define e realiza a chamada de equipes para validação das partes da aplicação. Por exemplo: Analista de Qualidade de Segurança e Analistas de Segurança, Gestores de Projetos e o Data Protection Officer (DPO). |
|
Os documentos necessários para a etapa de PROTEÇÃO DE DADOS PESSOAIS e suas definições?
|
|
|
O que precisamos definir na etapa de PROTEÇÃO DE DADOS PESSOAIS?
|
|
|
O que precisamos entregar para o projeto?
Responsáveis pela entrega: Coordenação de Desenvolvimento, Arquitetos de Software e DPO. |
|
|
Práticas recomendadas
|
|
|
Ferramentas recomendadas
|
|
|
Testes e Avaliações Iniciais
|
|
|
Referências:
|
|
A configuração segura de sistemas deve ser tratada como um evento decisivo e uma prática contínua e fundamental para a proteção de dados e manutenção da integridade das aplicações. Este documento serve como guia inicial, mas deve ser constantemente revisado e atualizado conforme novas ameaças e melhores práticas emergem. A colaboração entre desenvolvedores, arquitetos e analistas de segurança é crucial para o sucesso no desenvolvimento de um projeto e de um ambiente seguro.