Visando altos padrões de segurança no processo de desenvolvimento de aplicações e sistemas para o Ministério da Saúde, ressaltamos a sensibilidade do processo de Autenticação e o Gerenciamento de Credenciais.
Tais eventos figuram como parte sensível de um projeto, pois eles garantem verificação e identidade dos usuários bem como o controle de acesso a recursos e funcionalidades da aplicação, evitando também o comprometimento das credenciais usadas para os acessos. Esse processo figura em duas etapas do desenvolvimento seguro a saber o Levantamento de Requisitos e o Security By Design, para o embasamento correto na descrição dos processos foram utilizados os padrões OWASP, Security by Design, Privacy by Design e DevSecOps.
Objetivos do Documento
O objetivo deste documento é fornecer diretrizes claras e atualizadas para a utilização segura de autenticação e gerenciamento de credenciais nos projetos em desenvolvimento, a serem desenvolvidos e aqueles que estão sendo mantidos em nosso ambiente. Garantir a conformidade com padrões como ISO/IEC 27001, GDPR, e LGPD, e mitigar vulnerabilidades críticas descritas no OWASP Top Ten. Capacitar equipes de desenvolvimento, segurança e operações a integrar controles robustos de autenticação no ciclo de vida do software (SSDLC).
Toda a tratativa dos pontos citados será com o claro objetivo de manter o ambiente do Ministério da Saúde e nossos produtos em compliance com a legislação vigente e oferecer segurança aos nossos usuários internos e externos, essa documentação expressa nossa determinação em solidificar as bases da Engenharia de Software Segura, bem como difundir e estabelecer a cultura cooperação entre as equipes de desenvolvimento, operações e segurança.
Descrição da Implantação da Autenticação e Gerenciamento de Credenciais
Definir os métodos de autenticação mais adequados para o projeto em desenvolvimento, como o uso de autenticação multifator ou autenticação baseada em dispositivos.
Mapear as necessidades de gerenciamento de credenciais, incluindo meios de armazenamento seguro, renovação e rotação periódica.
Documentar requisitos regulatórios com base em leis e normas aplicáveis ao projeto, como no caso da LGPD.
Analisar o código e sua execução quanto aos métodos e fluxos de armazenamento de senhas utilizando algoritmos de hashing seguros, como bcrypt ou argon2.
Não utilizar senhas hardcoded no código, priorizar o uso de ferramentas como HashiCorp Vault ou AWS Secrets Manager.
Estabelecer parâmetros de validade temporal de tokens JWT para prevenir ataques de reutilização (replay attacks).
Configurar alertas para tentativas de autenticação suspeitas ou repetidas.
Configurar detecção de comportamento anômalo com aprendizado de máquina (opcional).
Identificar, analisar e documentar os cenários de Falso Positivo, para referências em tratativas apresentadas pelos alertas que indiquem ser um procedimento do sistema ou realizado pelas equipes de infraestrutura ou demais.
Durante a fase inicial do projeto, ao iniciar o ciclo de vida do desenvolvimento.
Por que deve ser feito
Para garantir que os requisitos de autenticação e gerenciamento de credenciais estejam claramente definidos, alinhados às melhores práticas e em conformidade com regulamentações 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.
Analistas de Negócio, Especialistas em Segurança, DPOs e Desenvolvedores.
Quem define os Atores responsáveis pela Validação dos Requisitos Levantados e Definidos
Coordenação de Desenvolvimento e Coordenação de Segurança
Especialistas em Segurança da Informação, Arquitetos de Soluções e DPOs.
Quais os documentos necessários para a etapa de Levantamento de Requisitos
Políticas de segurança da informação da organização.
Documento contendo Requisitos Funcionais e Não Funcionais.
Mapeamento de dados sensíveis a serem utilizados na autenticação.
Políticas organizacionais de segurança e gerenciamento de credenciais.
O que é necessário definir nessa etapa
Método(s) de autenticação – senha, MFA ou OAuth.
Regras para gestão de credenciais – rotação, expiração.
Políticas para proteção de dados pessoais utilizados na autenticação, como, por exemplo, o uso de criptografia.
Requisitos de logs (parâmetros de captura, armazenamento , dentre outros que julgados como necessários) e auditoria de eventos de autenticação.
O que precisamos entregar para a próxima etapa (Security by Design)
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações de requisitos de segurança, contendo:
Documentação com especificações detalhadas dos requisitos de autenticação e gerenciamento de credenciais.
Lista de potenciais ameaças ligadas ao processo.
Desenho do Modelo lógico de autenticação e gerenciamento de credenciais.
Tabela de permissões e fluxos de autenticação.
Quem é responsável pela entrega
Coordenação de Desenvolvimento -Equipe de Engenharia de Software e Arquitetos de Segurança, com aprovação final pelos DPOs e validação técnica por Especialistas em Segurança.
Práticas recomendadas para o Levantamento de Requisitos
Usar o método Threat Modeling para mapear riscos potenciais.
Aplicar os princípios de Privacidade por Design e Menor Privilégio.
Documentar cenários de uso e abuso relacionados à autenticação.
Ferramentas recomendadas
Rastreabilidade dos requisitos – JIRA ou Azure DevOps.
Diagramas para fluxos de autenticação – Lucidchart ou Visio.
Modelagem de ameaças – OWASP Threat Dragon.
Documentação centralizada dos requisitos – Confluence.
Testes e Avaliações Iniciais
Simulação de cenários de ataque – Simular, por exemplo, ataques de força bruta e bypass de autenticação.
Revisão inicial dos fluxos de autenticação – para buscar e identificar falhas de lógica.
Testes automatizados – Configurar testes automáticos sobre entradas, como no caso de senhas. Podem ser usadas ferramentas como OWASP ZAP ou Burp Suite.
Referências técnicas
ISO/IEC 27001 e 27034 – Diretrizes para segurança de autenticação.
OWASP ASVS e Top Ten – Práticas contra falhas críticas em autenticação.
NIST SP 800-63 – Diretrizes para autenticação digital.
SAFECode – Fundamentos para o desenvolvimento seguro.
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 incorporar segurança desde o início, minimizando falhas de autenticação, protegendo credenciais e assegurando conformidade com 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.
Arquitetos de Software: Desenham a arquitetura técnica da autenticação. - Especialistas em Segurança: Validam o design contra ameaças conhecidas. - DPOs
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
Equipes de Segurança da Informação: Validam a robustez do design contra ameaças. - Auditores Internos e DPOs
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).
Manual com descrições detalhadas das especificações de design.
Modelagem de Ameaças, (Threat Modeling) deviRegistro de riscos e de ferramentas, processos ou métodos para correção e mitigação.
O que precisamos definir na Etapa de Security by Design
Uso de mecanismos de autenticação como MFA, OAuth e OpenID Connect.
Aplicação de métodos de proteção para credenciais, como hashing de senhas e armazenamento seguro.
Desenvolvimento e padrões e métodos de recuperação de acesso e renovação de credenciais.
Modelo de Gestão de logs e processos de auditorias necessários para rastreabilidade.
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:
Desenho da arquitetura definida para autenticação e gerenciamento de credenciais.
Catálogo de controles a serem configurados no código.
Planos para correção e mitigação de riscos aprovados.
Planos de teste inicial para validação dos fluxos projetados.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Arquitetos de Software e Especialistas em Segurança, com validação por DPOs e Auditores Internos.
Práticas recomendadas para o Security by Design
Aplicar o princípio Privacidade por Design e o princípio do Menor Privilégio.
Utilizar Modelagem de Ameaças para mapear e mitigar riscos potenciais.
Incorporar medidas de segurança proativa, como autenticação multifator e tokens com prazo de expiração.
Validação Contínua – O design deve ser revisado à medida que novos riscos são descobertos.
Segurança Inata – Soluções devem ser seguras por padrão, exigindo o mínimo de configuração para atingir conformidade.
Rastreabilidade – Todos os componentes do design devem ser documentados para garantir clareza e conformidade.
Ferramentas recomendadas
Modelagem de ameaças – OWASP Threat Dragon.
Desenho de fluxos de autenticação – Lucidchart/Visio.
Gerenciamento de identidade e acesso – Keycloak.
Frameworks de autenticação segura – Spring Security e FastAPI Security.
Testes e Avaliações Iniciais
Testes de validação dos fluxos de autenticação.
Testes de segurança para cenários de ataques como, por exemplo, replay attacksm e força bruta.
Revisão e análise da eficácia dos controles propostos com ferramentas como OWASP ZAP e Burp Suite.
Referências técnicas
ISO/IEC 27001 e 27034 – Diretrizes para design de segurança.
OWASP ASVS e Top Ten – Mitigação de falhas críticas em autenticação.
NIST SP 800-63 – Diretrizes para autenticação digital.
SAFECode – Boas práticas para desenvolvimento seguro.
Durante a etapa de codificação e execução do sistema, após as definições de design, antes de realizar os testes de segurança.
Por que deve ser feito
Para assegurar que os requisitos de segurança definidos sejam aplicados e codificados corretamente, concedendo ao projeto a devida proteçã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.
Equipes de Desenvolvimento, Infraestrutura e Segurança.
Quem define os Atores responsáveis pela Validação dos processos da Etapa de Execução
Coordenação de Desenvolvimento e Coordenação de Segurança
Equipe de Desenvolvimento, de Infraestrutura e de Segurança conforme a necessidade do projeto.
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.
Requisitos funcionais e não funcionais aprovados.
Manual de políticas de segurança organizacional.
Diagrama técnico do fluxo de autenticação e fluxos de credenciais.
Plano de testes inicial para validar segurança do código.
O que precisamos definir na Etapa de Execução Segura
Configurações de autenticação segura como hashing de senhas com bcrypt, tokens JWT com expiração.
Ferramentas e mecanismos de proteção contra ataques, como CSRF e replay attacks.
Políticas de gerenciamento de credenciais, como o tempo de expiração e rotação.
Centralização de dados de logging para facilitar a auditoria de eventos de autenticação.
O que precisamos entregar para a próxima etapa (Teste de Segurança)
Relatório de Execução Segura do Projeto (Etapa III) – Apresentando os controles utilizados, com listagem das práticas aplicadas no código e ferramentas utilizadas. Contendo:
Código a descrição das ferramentas de segurança, com as configurações para autenticação e gerenciamento de credenciais.
Informações detalhadas dos logs de eventos relacionados à autenticação.
Scripts de teste automatizados para validação.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Engenheiros de Software, Equipes de Segurança da Informação, DPOs e Arquitetos de Segurança.
Práticas recomendadas para a Execução Segura
Armazenar senhas e tokens utilizando hashing seguro com bcrypt ou argon2.
Proteger endpoints de autenticação com TLS, nas suas versões mais recentes.
Impedir por padrão o uso de senhas hardcoded usando ferramentas como HashiCorp Vault.
Utilizar MFA (Autenticação Multifator) para autenticação segura, nos casos de acessos sensíveis.
Configurar cookies de sessão com atributos HttpOnly, Secure e SameSite.
Configurar o uso de protocolos padrão, como OAuth 2.0 e OpenID Connect.
Configurar logs detalhados visando os eventos de auditoria, para rastrear eventos de autenticação.
Ferramentas recomendadas
Framework robusto para autenticação e autorização – Spring Security.
Extensão para segurança em APIs – FastAPI Security.
Gerenciamento de identidade e acesso – Keycloak.
Gerenciamento de segredos e credenciais – HashiCorp Vault.
Identificação de vulnerabilidades em dependências – OWASP Dependency-Check.
Gestão e Proteção de Credenciais – AWS Secrets Manager ou HashiCorp Vault.
Monitoramento, Auditoria e Tratamento de Logs – Splunk ou ELK Stack.
Testes e Avaliações Iniciais
Testes de autenticação – através de simulação de eventos de força bruta e replay attacks.
Simulações de ataques em APIs – Utilizar ferramentas como OWASP ZAP, Burp Suite para testes de manipulação de credenciais.
Testes Unitários – Realizados com a finalidade de validar os desenhos de fluxos de autenticação.
Revisão Estática do Código – Utilizar ferramentas como SonarQube ou Checkmarx para as revisões.
Referências técnicas
ISO/IEC 27001 e 27034 – Diretrizes para desenvolvimento seguro.
OWASP ASVS – Padrões de segurança para autenticação.
SAFECode – Boas práticas de execução segura.
NIST SP 800-63 – Diretrizes de autenticação digital.
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 busca, identificação e correção de possíveis falhas e vulnerabilidades nos mecanismos de autenticação e gerenciamento de credenciais, prevenindo acessos não autorizados e garantindo conformidade regulatória.
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.
Engenheiros de Software, Analistas de Segurança e DPOs.
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
Auditores Internos e Equipe de Segurança da Informação, Desenvolvimento e DPOs.
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.
Plano de Testes de Segurança definido e referenciado para as equipes envolvidas.
Casos de teste específicos para autenticação e gerenciamento de credenciais.
Relatórios de análise estática e dinâmica.
O que precisamos definir na Etapa de Teste de Segurança
Casos de Teste – Referências para cobertura de fluxos de autenticação como login/logout e recuperação de senhas.
Parâmetros para Testes e Simulações - Simular ataques comuns como os de força bruta, CSRF e replay attacks.
Modelos e Planos de Mitigação – Desenho de estratégias de correção e mitigação para vulnerabilidades encontradas nos testes.
O que precisamos entregar para a próxima etapa (Gerenciamento)
Relatório dos Testes de Segurança, contendo:
Relatório detalhado de vulnerabilidades encontradas e corrigidas.
Resultados dos testes automatizados e manuais.
Logs e evidências de conformidade com requisitos regulatórios.
Quem é responsável pela entrega
Coordenação de Desenvolvimento – Equipes de Segurança da Informação, Engenheiros de Software e DPOs.
Práticas recomendadas para os Testes de Segurança
Definir a Estrutura dos Testes – Utilizar ferramentas como o OWASP Testing Guide.
Priorizar de Estruturas – Identificar estruturas críticas como endpoints expostos e fluxos de autenticação.
Revisar e Validar Controles – Definir um cronograma de validação para os controles aplicados, simulando cenários reais de ataque, para esses casos as equipes poderiam realizar testes de força bruta em ambientes isolados para verificar proteção contra senhas fracas ou repetidas.
Ferramentas recomendadas
Testes Dinâmicos de APIs e Fluxos de Autenticação – OWASP ZAP.
Testes de Vulnerabilidades – Burp Suite (para testes de interceptação de requisições).
Análise Estática – SonarQube (para detectar falhas no código).
Testes de Validação de APIs – Postman/Newman (incluir análise de autenticação e autorização).
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.
Verificação de segurança em tokens – Testes utilizando JWT assinados com chaves fracas.
Auditoria de Logs – Análise de logs de autenticação para comportamento anômalo.
Referências técnicas
ISO/IEC 27001 e 27034 – Diretrizes para garantir segurança durante os testes.
OWASP ASVS e Top Ten – Identificação e mitigação de vulnerabilidades críticas.
NIST SP 800-63 – Diretrizes de autenticação digital.
SAFECode – Práticas de teste durante o ciclo de desenvolvimento.
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 a segurança contínua da autenticação e das credenciais, proteger contra acessos indevidos, e manter conformidade com regulamentações como LGPD e GDPR.
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.
Equipe de Desenvolvimento, Segurança da Informação, Segurança de Infraestrutura e DPOs.
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
Auditores Internos, Equipes de Segurança da Informação e Infraestrutura.
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 autenticação e gerenciamento de credenciais.
Documentação de logs de auditoria e eventos de autenticação.
Plano de rotação de credenciais e tokens.
Descrição do Inventário de permissões e acessos.
O que precisamos definir na Etapa de Gerenciamento
Políticas de renovação e rotação de credenciais.
Valores e Limites para reutilização de senhas.
Regras para expiração de tokens e sessões.
Métodos e Mecanismos para revogação de credenciais comprometidas.
O que precisamos entregar para a próxima etapa (Monitoramento)
Relatório ou Planos de Gerenciamento de Segurança, contendo:
Logs centralizados e auditáveis de autenticação e uso de credenciais.
Inventário atualizado de permissões e credenciais.
Relatórios de auditoria e conformidade.
Quem é responsável pela entrega
Coordenação de Desenvolvimento – Gestores de Segurança, Administradores de Sistemas e DPOs.
Práticas recomendadas para os Testes de Segurança
Definir e aplicar rotação periódica de credenciais e tokens.
Definir política de força e expiração de senhas.
Definir e configurar alertas para uso suspeito de credenciais.
Definir regras de segregação de ambientes (produção, desenvolvimento, teste).
Ferramentas recomendadas
Gerenciamento Seguro de Senhas e Credenciais – HashiCorp Vault.
Plataforma para Gestão de Identidade e Acesso – Keycloak.
Monitoramento e Análise de Logs – Splunk ou ELK Stack.
Gerenciamento Automatizado de Credenciais – AWS Secrets Manager.
Testes e Avaliações Iniciais
Testes e Simulações – Realizar simulações de acessos indevidos para validar políticas de revogação.
Testes de Conformidade – Verificações manuais e automatizadas de conformidade com políticas definidas.
Testes de Comportamento e Padrões – Análise de comportamento em logs para detectar padrões suspeitos.
Referências técnicas
ISO/IEC 27001 e 27002 – Diretrizes de gerenciamento contínuo de segurança.
OWASP ASVS – Boas práticas para gerenciamento de autenticação.
NIST SP 800-63 – Requisitos para autenticação digital.
SAFECode – Práticas fundamentais para desenvolvimento e gerenciamento seguro.
Após o sistema estar em produção, com monitoramento contínuo e revisões periódicas para garantir a integridade e a segurança dos processos de autenticação e gerenciamento de credenciais.
Por que deve ser feito
Para realizar buscas, identificação e prover respostas rápidas contra atividades suspeitas, prevenir acessos não autorizados e garantir conformidade com regulamentações como LGPD e GDPR.
Quem define os Atores e Ações da Etapa de Monitoramento
Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução.
Equipes de Desenvolvimento, 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 Monitoramento
Relatório dos Requisitos do Projeto (Etapa I) – Com as especificações de requisitos de segurança, definidos na etapa anterior (Levantamento de Requisitos).
Relatório ou Plano de Design de Sistema Atualizado (Etapa II)- Incluindo especificações detalhadas de controles definidos e aplicados.
Relatório de Execução Segura do Projeto (Etapa III) – Apresentando os controles utilizados, com listagem das práticas aplicadas no código e ferramentas utilizadas.
Relatório dos Testes de Segurança (Etapa IV) – Apresentando informações sobre vulnerabilidades e registros das atividades.
Relatório ou Planos de Gerenciamento de Segurança(Etapa V) – Com padrões e planos de gerenciamento, planos de atualização e revisão, relatórios de testes e logs de referência.
Política de monitoramento de segurança.
Configuração de ferramentas de observabilidade.
Logs de auditoria e relatórios de atividades.
Inventário de credenciais e permissões.
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
Eventos para Monitoramento – Definir eventos e sua criticidade para serem monitorados, como tentativas de login falhadas e mudanças em permissões.
Alertas automáticos para atividades suspeitas.
Frequência de análises manuais e auditorias.
O que precisamos entregar
Relatório de Incidentes de Segurança, incluindo:
Configurações de monitoramento ativo, alertas e notificações, incluindo alertas e relatórios para eventos de atividades anômalas.
Logs centralizados e estruturados.
Relatórios de monitoramento contínuo.
Planos de resposta a incidentes.
Quem é responsável pela entrega
Coordenação de Desenvolvimento e de Infraestrutura – Gestores de Segurança e Administradores de Sistemas e DPOs.
Práticas recomendadas para a Etapa de Testes de Segurança
Configurar Alertas Automatizados – Nos casos de eventos críticos, como falhas de autenticação TLS.
Centralizar Informações de Registros – Logs de segurança devem ser centralizados em ferramentas robustas, como o Elastic Stackn e Splunk.
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.
Configurar monitoramento em tempo real de eventos críticos.
Estabelecer limites de alertas para evitar alertas falsos positivos.
Integrar logs e métricas em plataformas de análise centralizadas como o SIEM utilizado pela organização.
Realizar auditorias regulares de nas listas e inventários de acessos e permissões.
Ferramentas recomendadas para o projeto
Monitoramento e Análise de logs – Splunk ou ELK Stack.
Visualização e Alertas de Métricas – Prometheus e Grafana.
Gestão de Logs de Autenticação e Sessões – Keycloak.
Rastreamento de Acessos e Eventos – HashiCorp Vault.
Testes e Avaliações Iniciais
Simulação de Falhas – Simular eventos de falha do projeto, como tentativas de login maliciosas através de força bruta e para validação de alertas e detecção de eventos críticos.
Auditoria de Logs – Auditar logs de eventos e revisão de logs para identificar falhas ou inconsistências.
Testes de Integridade – Validar a integridade de logs e registros monitorados contra alterações indevidas.
Testes de Automação – Testar as automações desenvolvidas e aplicadas para resposta a eventos críticos, atestando sua eficácia.
Referências técnicas
ISO/IEC 27001 e 27034 – Diretrizes de segurança no monitoramento de sistemas.
OWASP ASVS – Padrões para monitoramento de autenticação.
NIST SP 800-92 – Diretrizes para gerenciamento e análise de logs.
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ítica de Gestão de Credenciais – Define regras para criação, armazenamento, renovação e exclusão de credenciais.
Relatório de Impacto à Proteção de Dados (DPIA) – Avaliação de riscos relacionados ao tratamento de credenciais e autenticação.
Matriz de Controles de Acesso – Detalha permissões baseadas em papéis (RBAC) ou atributos (ABAC).
Política de Retenção e Exclusão de Dados – Regras para gerenciamento do ciclo de vida de dados pessoais usados na autenticação.
Plano de Resposta a Incidentes – Planos direcionados a respostas diante de violação de dados pessoais.
O que precisamos definir nesta tapa
Mecanismos de Autenticação Segura – Definir e aplicar métodos de autenticação multifator (MFA), políticas de força de senhas e renovação periódica.
Armazenamento Seguro de Credenciais – Hashing de senhas como bcrypt e Argon2, além da proteção de tokens como, por exemplo, HMAC-SHA256.
Proteção contra Ataques – Utilizar medidas contra brute force, phishing e reutilização de credenciais.
Fluxo de Recuperação de Credenciais – Processo seguro para redefinir senhas ou recuperar contas.
Artefatos a serem gerados nessa etapa
Sistema de Autenticação Seguro – Apresentar controles detalhados de força de senha, proteção de credenciais e MFA.
Logs de Autenticação – Registros de tentativas de login, falhas e sucessos, protegidos contra adulteração.
Relatório de Conformidade – Evidências de que a autenticação e gerenciamento de credenciais estão alinhados às regulamentações e normas técnicas.
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
Hashing Seguro – Definir e aplicar algoritmos modernos como bcrypt e Argon2.
Autenticação Multifator (MFA) – Aplicar camadas extras de proteção além de senhas.
Política de Renovação – Padronizar a renovação periódica de credenciais e tokens.
Monitoramento de Tentativas de Login – Realizar o bloqueio de IPs nos casos de diversas tentativas falhas.
Minimização de Dados – Armazenar apenas o necessário e evitar retenção de dados sensíveis em texto claro.
Ferramentas recomendadas
Gestão de Identidade – Keycloak (com suporte a MFA e RBAC).
Configuração de Autenticação e Autorização Seguras – Spring Security.
Gestão Segura de Autenticação – Flask-Login.
Armazenamento de Credenciais – HashiCorp Vault.
Testes de Vulnerabilidades de Autenticação e Proteção de Credenciais – OWASP ZAP e Burp Suite.
Testes e Avaliações Iniciais
Teste de Força de Senhas – Garantir que senhas seguem políticas de complexidade.
Simulação de Ataques de Brute Force – Validar a proteção configurada contra ataques de força bruta.
Validação de Hashing de Credenciais – Analisar o armazenamento das senhas com hashing seguro.
Teste de MFA – Validar que a autenticação multifator está configurada corretamente.
Referências técnicas
ISO/IEC 27001 – Diretrizes para proteção de informações pessoais e credenciais.
OWASP ASVS – Requisitos para autenticação segura e gerenciamento de credenciais.
NIST SP 800-63B – Padrões de autenticação digital e força de senhas.
LGPD e GDPR
Considerações Finais
A autenticação e o gerenciamento de credenciais figuram como parte extremamente sensível na proteção de aplicações contra acessos não autorizados e vazamentos de dados, além do desenvolvimento de projetos seguros, tendo em vista sua função de controlar a entrada e os níveis de acesso concedidos, o que pode acarretar em danos ao ambiente ou mesmo na apropriação indevida de informações sensíveis da organização e dos usuários. Considerando esses fatos é imperativo que todos os envolvidos no desenvolvimento mantenham o estado de alerta, dada a relevância desse processo e seu nível de criticidade para todas as aplicações desenvolvidas para o Ministério da Saúde.