Visando divulgar e estabelecer um modelo de boas práticas para a aplicação do Controle de Acesso, este documento apresentará os conceitos do papel desempenhado pelo Controle de Acesso no processo de desenvolvimento de aplicações e sistemas para o Ministério da Saúde, ressaltamos a sensibilidade do processo haja vista figurar no processo de avaliação dos acessos, desta forma prevenindo ou não acessos não autorizados.
Objetivos do Documento
O objetivo deste documento é definir as metodologias para a aplicação de ferramentas de controle acesso nas aplicações durante as etapas de desenvolvimento. Além disso, descrever orientações sobre a aplicação dos controles de acesso de forma segura e eficaz e recomendar as melhores práticas para um modelo de gestão dos controles de acesso de usuários e possíveis grupos criados na aplicação. Um destaque para as equipes de desenvolvimento é a adoção do Modelo Zero Trust, que estabelece como princípio que ‘nenhum usuário ou dispositivo deve ser automaticamente confiável, seja dentro ou fora da rede’, este modelo deverá ser a base nas tomadas de decisão a respeito do controle de acesso no projeto em desenvolvimento em conjunto com as demais normas, padrões e boas práticas.
Sempre com o foco em oferecer ao Ministério da Saúde e seus usuários aplicações seguras e que atendam aos requisitos da Lei Geral de Proteção de Dados (LGPD). Com o claro objetivo de manter o nosso ambiente e nossos produtos em conformidade 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.
PÚBLICO-ALVO
Este documento é direcionado aos profissionais de desenvolvimento de software no âmbito do Ministério da Saúde e do DATASUS e tem o objetivo de fornecer orientações e boas práticas para garantir a segurança e a privacidade dos dados sensíveis durante o desenvolvimento de sistemas de saúde. Ele servirá como referência centralizada na Wiki do Ministério da Saúde e do DATASUS, promovendo uma cultura de segurança e disponibilizando informações relevantes para todos os envolvidos no Ciclo de Vida de Desenvolvimento de Software.
Descrição da Implantação do Processo de Controle de Acesso
Etapas que trabalharão a percepção constante das alterações, dos comportamentos e necessidades do projeto para que seja mantido seguro e em conformidade com leis, normas e diretrizes aplicáveis ao projeto.
Instruir quanto à proteção do(s) repositório(s) de armazenamento de dados pessoais em conformidade com o princípio de privacidade por design.
Além de apresentar ferramentas como as de Data Loss Prevention (DLP) e melhores práticas para a execução das etapas dentro do projeto
Durante a fase inicial do projeto, ao iniciar o ciclo de vida do desenvolvimento.
Por que deve ser feito
Para garantir que as necessidades de autenticação, autorização e controle de acesso sejam identificadas, documentadas e alinhadas com as melhores práticas de segurança.
Quem define os Atores e Ações da Etapa de Levantamento de Requisitos
Coordenação de Desenvolvimento – convocar e definir equipes e responsabilidades para cada fase da etapa em execução.
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
Documento de requisitos funcionais e não funcionais, apresentando casos de uso para melhor compreensão das necessidades do projeto.
Catálogo ou listagem de usuários, com o detalhamento dos perfis e permissões.
Políticas de controle de acesso.
O que é necessário definir nessa etapa
Documentação de Controle de Acesso: Contendo a listagem e descrição dos usuários, grupos e suas permissões.
Mecanismos de autenticação – Como o uso de MFA entre outros, conforme a necessidade do projeto.
Escopos de acesso – Realizar análise de usuários por funções adotando modelos como RBAC ou ABAC.
Integração de Providers de Identidade – Os Identity Providers (IdPs) que trabalharão as funções de armazenamento e gestão de identidades digitais, como o SAML, OAuth e o OpenID Connect, além de definir a(s) ferramenta(s), a equipe deverá definir o modo de trabalho da(s) ferramenta(s).
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 segurança.
Modelo lógico de controle de acesso.
Lista de pontos de auditoria.
Protótipo inicial para validação.
Quem é responsável pela entrega
Coordenação de Desenvolvimento -Equipes de Engenharia de Software, Especialistas de Segurança e o Arquiteto de Soluções de Segurança da Informação.
Práticas recomendadas para o Levantamento de Requisitos
Alinhar o controle de acesso aos princípios de menor privilégio e separação de responsabilidades, seguindo os princípios do Modelo Zero Trust.
Documentar cenários de uso e abuso para identificação e monitoramento dos riscos identificados.
Utilizar métodos como Threat Modeling para as tratavas de ameaças ao projeto como STRIDE, DREAD e OWASP Threat Modeling.
Ferramentas recomendadas
Rastreamento de Requisitos – JIRA ou Azure DevOps.
Mapeamento de Fluxos de Acesso – Lucidchart ou Microsoft Visio.
Ferramentas de Documentação – Confluence.
Testes iniciais de API para autenticação e autorização – Postman, Insommia, REST-Assured e SoapUI.
Testes e Avaliações Iniciais
Peer Review – Verificação inicial de requisitos.
Testes de Penetração – Simulações de cenários de ataque para os protótipos.
Análise Estática – Analisar as definições iniciais do modelo de controle de acesso.
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 os controles de acesso sejam devidamente incorporados desde o início, reduzindo vulnerabilidades e custos de correção posteriores.
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).
Relatórios das informações obtidas a partir da Modelagem de ameaças (Threat Modeling).
Diagramas de arquitetura detalhados com os fluxos de autenticação.
O que precisamos definir na Etapa de Security by Design
Estrutura de autenticação – Ferramentas e modelos, como OAuth e OpenID Connect.
Política de Controle de Acesso – baseada em papéis ou atributos (RBAC - ABAC).
Mecanismos de auditoria e logs para acessos.
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:
Design final da arquitetura com controle de acesso a ser utilizado no código do projeto.
Lista com detalhamento das ameaças identificadas e tratadas, bem como os requisitos de segurança documentados.
Protótipos ou wireframes de autenticação/autorização, que apresentem, por exemplo, telas de Login e Autenticações, Fluxos de Autorização, Controle de Acesso baseado em Funções, Gestão dos Perfis dos Usuários e o Tratamento de Erros e Exceções.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Arquitetos de Software, Engenheiros de Software e Equipe de Segurança e DPOs.
Práticas recomendadas para o Security by Design
Aplicar os princípios de segurança por padrão e privacidade por design. - Garantir segmentação de ambientes (e.g., desenvolvimento, produção). - Realizar Threat Modeling usando ferramentas como OWASP Threat Dragon.
Ferramentas recomendadas
Modelagem de Ameaças – OWASP Threat Dragon.
Criação de Diagramas – para o desenho dos protótipos de controle de acesso Lucidchart, Visio, Figma, Miro, Mockflow e Balsamiq
Frameworks – Spring Security (Java) ou Flask-Security (Python).
Testes e Avaliações Iniciais
Revisões Técnicas – para validar o modelo de controle de acesso desenhado.
Simulação de Ambientes e Eventos – simular eventos de acessos não autorizados e cenários de abuso.
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 garantir que o controle de acesso seja configurado de forma segura e robusta, prevenindo vulnerabilidades como escalonamento de privilégios e bypass de autenticaçã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.
Plano de desenvolvimento seguro do projeto.
Requisitos de segurança codificados, como a(s) ferramenta(s) de autenticação multifator e proteção dos (endpoints) pontos de entrada da aplicação (APIs, interfaces web, etc.).
Políticas de Acesso revisadas e devidamente atualizadas.
O que precisamos definir na Etapa de Execução Segura
Definir Regras e Níveis de Permissionamento – estabelecendo assim os mecanismos de controle de acesso no código.
Ferramentas e Métodos de Proteção – definir os meios de proteções contra ataques como Broken Access Control e Cross-Site Request Forgery (CSRF).
Tipos de Ferramentas de Criptografia – para tokens de sessão e 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-fonte com os parâmetros de segurança aplicados, com logs para referência, configurados para auditoria.
Documentação de controle de acesso configurado.
Detalhamento de Scripts e testes automatizados de segurança.
Quem é responsável pela entrega
Coordenação de Desenvolvimento Equipe de Desenvolvedores e Analistas de Segurança.
Práticas recomendadas para a Execução Segura
Aplicar na codificação e nas configurações os princípios Fail Secure e Least Privilege.
Modelar o código aplicando ferramentas para análise estática (SAST) e dinâmica (DAST).
Documentar necessidades de acessos especiais ou exceções para revisão contínua.
Ferramentas recomendadas
Análise estática de código – SonarQube.
Verificação de Vulnerabilidades em Tempo Real – Checkmarx.
Testes Iniciais de Autenticação/Autorização em APIs – Postman/Newman, Spring Security (Java) ou FastAPI Security (Python) para tratamento e controle de acesso.
Testes e Avaliações Iniciais
Revisão de código – Busca e identificação de vulnerabilidades.
Testes Unitários e de Integração – para análise da execução do fluxo e das ferramentas de controle de acesso.
Validação de Endpoints Críticos – procedimento que visa tratar possíveis meios ou superfícies exploráveis para acessos não autorizados.
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 no controle de acesso, analisar as ferramentas e métodos que garantam que os mecanismos de autenticação e autorização estejam em conformidade com as políticas de segurança e regulamentos.
Quem define os Atores e Ações da Etapa de Testes
Coordenação de Desenvolvimento e de Segurança – 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.
Plano de Testes de Segurança.
Relatórios de análise estática e dinâmica (SAST e DAST).
Solicitação ou Roteiro com cenários e scripts de testes automatizados.
Políticas de controle de acesso definidas e aplicadas ao código do projeto.
O que precisamos definir na Etapa de Teste de Segurança
Casos de Teste Aplicáveis – realizar testes que alcancem itens como a autenticação (login/logout) e autorização (controle de permissões).
Testes para Vulnerabilidades – definir listagem de vulnerabilidades conhecidas, como Broken Access Control e SQL Injection, para realizar testes no código.
Planos de Correção e Mitigação de Falhas – Definir as estratégias possíveis para correção e mitigação de falhas detectadas.
O que precisamos entregar para a próxima etapa (Gerenciamento)
Relatório dos Testes de Segurança, contendo:
Detalhamento das vulnerabilidades detectadas, em paralelo com procedimentos de correção ou mitigação.
Resultados dos testes automatizados e manuais.
Logs e evidências de para análise de conformidade com requisitos regulatórios.
Quem é responsável pela entrega
Coordenação de Desenvolvimento – Equipe de Segurança da Informação, com suporte de Desenvolvedores e validação final pelo DPO e Arquitetos de Segurança.
Práticas recomendadas para os Testes de Segurança
Testes com Metodologia Referenciada – Desenvolver os testes com base em metodologias como OWASP Testing Guide para estruturação dos testes.
Documentar Vulnerabilidades – Gerar documentação detalhada das vulnerabilidades, superfícies exploráveis e demais informações pertinentes e sensíveis das vulnerabilidades encontradas e corrigidas.
Realizar Testes Avançados – desenvolver os testes utilizando cenários críticos, como APIs expostas e autenticação.
Automação de Testes – Integrados testes ao pipeline de CI/CD para detectar problemas de segurança no controle de acesso logo após alterações de código.
Relatórios e Logs – Desenvolver estrutura clara e rastreável para os relatórios, baseados nos requisitos de conformidade.
Ferramentas recomendadas
Testes dinâmicos – para identificar falhas em tempo de execução, utilizar o OWASP ZAP.
Testes de Interceptar e Manipular – Nos casos de requisições HTTP, utilizar o Burp Suite.
Teste de Código – para análise e busca de vulnerabilidades no código, utilizar o SonarQube.
Testes de API – para testes que incluem incluindo autenticação e autorização, utilizar o Postman e Newman.
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. Incluir simulação de cenários críticos de ataques, como tentativas de bypass de autenticação.
Revisão de Permissionamento – Realizar validação de permissões em endpoints e funcionalidades.
Revisão de Logs – analisar registro de logs em busca de comportamentos anômalos.
Referências técnicas
ISO/IEC 27034
OWASP ASVS e OWASP Top Tem
NIST SSDF – Estrutura para integrar testes de segurança ao 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 que as ferramentas e métodos definidos para o controle de acesso sejam gerenciados, atualizados e auditados continuamente, o que minimiza riscos e garante a conformidade regulatória.
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.
Gestores de Segurança, Administradores de Sistemas 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
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ítica de controle de acesso.
Inventário de permissões e acessos.
Procedimentos para gerenciamento de credenciais e senhas.
O que precisamos definir na Etapa de Gerenciamento
Políticas de Revisão de Credenciais – Desenvolver e aplicar políticas para revisão de acessos e permissões.
Gestão de Credenciais – Desenvolver e aplicar ferramentas e metodologias para gerenciar credenciais, como parâmetros de expiração e rotação.
Cronograma de Auditoria – Realizar auditoria regular em paralelo com procedimento de correção de acessos inadequados.
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 credenciais.
Inventário atualizado de permissões e usuários.
Relatórios de conformidade e auditorias.
Logs estruturados para análise de comportamento e detecção de anomalias.
Quem é responsável pela entrega
Coordenação de Desenvolvimento - Gestores de Segurança com suporte de Administradores de Sistemas e validação final pelos DPOs.
Práticas recomendadas para os Testes de Segurança
Política de Rotação de Credenciais – Garantir que chaves e senhas sejam alteradas periodicamente, reduzindo o risco por uso ou permanência de credenciais comprometidas.
Ciclo de Revisão – Estruturar ciclos de revisão de permissões, por exemplo, revisar trimestralmente, analisando possíveis alterações de níveis de permissionamento ou mesmo exclusão de usuários.
Automação – Automatizar a rotação de credenciais usando ferramentas especializadas.
Rastreabilidade de Acessos – Desenvolver e aplicar ferramentas e métodos que garantam a rastreabilidade total dos acessos, utilizando Loggin Detalhado (SUCESSOS E FALHAS), Níveis de Logs Adequados (DEBUG, INFO, WARN, ERROR, FATAL), Formatos Consistentes (JSON, CSV) e a Centralização de Logs com sistemas de gerenciamento (ELK STACK, GRAYLOG) com logs centralizados e revisados.
Integração com Ferramentas de Segurança – Integrar os eventos e cronogramas de testes com as ferramentas de segurança da organização como as ferramentas de SIEM e SOAR, visando tratativas e respostas em tempo real.
Ferramentas recomendadas
Gerenciamento de identidades e permissões – utilizar, por exemplo, o Keycloak.
Gerenciamento de credenciais e senhas – utilizar, por exemplo, HashiCorp Vault.
Análise de Comportamento e Monitoramento de logs – ELK Stack ou Splunk.
Testes e Avaliações Iniciais
Testes de autenticação – incluir teste de força bruta, injeção de credenciais.
Testes de autorização – incluir teste de (elevação de privilégios, bypass de controles de acesso).
Testes de acesso a recursos – incluir teste de com diferentes níveis de permissão.
Simulações de cenários Críticos – simular acessos indevidos e uso de credenciais comprometidas.
Referências técnicas
ISO/IEC 27001 e 27002
ISO/IEC 29147 e 30111
NIST SSDF – Para integrar práticas de gerenciamento ao ciclo de vida.
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
Para realizar buscas, oferecer respostas e correção para tentativas de acesso não autorizado. Revisar e tratar escalonamento de privilégios, além de outras possíveis violações de controle de acesso, garantindo a conformidade com regulamentos 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.
Analistas de Segurança, Arquitetos de Software e DPO.
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
Auditores Internos e Especialistas em Segurança e Gestores de Segurança
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 e resposta a incidentes.
Guia de Referencias e Configurações de ferramentas de Observabilidade.
Plano de resposta a incidentes.
O que precisamos definir na Etapa de Teste de Segurança
Padrões de Monitoramento – Eleger os eventos para monitoramento e os níveis de monitoramento. Tratando, por exemplo, eventos como tentativas de login falhadas, alterações em permissões.
Alertas e Comunicação – Definir os tipos e níveis de alertas, além de como serão tratadas as notificações em tempo real para acessos suspeitos. Bem como o plano de comunicação das informações.
Integração com Ferramentas de Segurança – Definir se haverá Integração com sistemas de gerenciamento de incidentes, o SIEM da organização, por exemplo, e em qual nível será aplicada essa integração. Além de definir como serão tratadas as informações e alertas gerados pelas ferramentas em consequência de sua integração.
O que precisamos entregar para o projeto
Relatório de Incidentes de Segurança, incluindo:
Logs centralizados e auditáveis.
Relatórios de segurança contínuos.
Alertas acionáveis para equipes de resposta a incidentes.
Quem é responsável pela entrega
Coordenação de Desenvolvimento e de Infraestrutura – Gestores de Segurança, com suporte de Administradores de Sistemas e validação final pelos DPOs e Arquitetos de Segurança.
Práticas recomendadas para a Etapa de Testes de Segurança
Configurar alertas automatizados e baseados em comportamento anômalo.
Estruturar e configurar log centralizado e correlação de eventos usando ferramentas SIEM.
Realizar testes regulares de resposta a incidentes (simulações).
Auditar regularmente a eficácia do monitoramento e revisar o a aderência às regulamentações.
Centralização de Logs: Garantir que a coleta de logs de diferentes fontes (aplicações, servidores, firewalls, etc.) seja direcionada para local único, facilitando a análise, a correlação e o monitoramento. Para tal o uso de ferramentas como o ELk Stack ou Graylog é possibilitam esse tipo de processo, em paralelo com as devidas parametrizações.
Definição e Configuração de Alertas Proativos: O objetivo é permitir a detecção precoce de atividades suspeitas ou anômalas, possibilitando respostas rápidas contra incidentes de segurança ou violação de políticas. Para tal é necessário Definir as Regras de Alertas, Configurar Faixas de Limitação para os Alertas, Definir Canais de Comunicação, Definir Alertas Prioritários e montar a Integração com SIEM.
Definição e Configuração para Processos de Análise de Comportamento: Implantar processos de aprendizado de máquina ou regras heurísticas para detectar padrões anômalos, identificar padrões e desvios no comportamento dos usuários, auxiliando na detecção de ameaças internas e ataques sofisticados.
Implantar Sistemas de Respostas Automatizadas a Incidentes – automatizar o processo de mitigação de ameaças e correções de falhas confere agilidade e oferece mais segurança ao ambiente e usuários.
Ferramentas recomendadas
Análise e Correlação de Eventos – Splunk.
Monitoramento e visualização de log – ELK Stack.
Gestão de Métricas e alertas em tempo real – Prometheus e Grafana.
Gestão de Logs de autenticação e autorização – Keycloak.
Ferramentas de Análise de Comportamento do Usuário (UBA) – Exabeam, Securonix.
Plataformas de Observabilidade – Datadog, New Relic.
Testes e Avaliações Iniciais
Testes de Autorização - Testes de Elevação de Privilégios (Privilege Escalation), Testes de Bypass de Autorização (Authorization Bypass), Testes de Acesso a Recursos Restritos e Testes de Compartilhamento Não Autorizado de Recursos.
Testes de Gestão de Sessão – Testes de Fixação de Sessão (Session Fixation), Testes de Roubo de Sessão (Session Hijacking), Testes de Timeouts de Sessão e Testes de Revogação de Sessão.
Testes de Validação de Entrada - Testes de Injeção (SQL Injection, XSS, Command Injection) e Testes de Fuzzing.
Testes de APIs – Testes de Autenticação e Autorização em APIs, Testes de Injeção em APIs e Testes de Rate Limiting.
Auditoria de Logs - Auditar logs de eventos.
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 27002 – Requisitos e práticas para monitoramento de segurança.
OWASP Logging Guide
NIST SSDF – Integração de práticas de monitoramento ao ciclo de desenvolvimento.
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
Com o fim de conferir proteção aos dados pessoais contra acessos não autorizados, assegurando a garantia de conformidade com LGPD, GDPR e outras regulamentações aplicáveis, e prevenir vazamentos e violações de privacidade.
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.
DPOs, Especialistas em Segurança e Desenvolvedores.
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
Equipe de Conformidade, Auditores Internos e Arquitetos de Segurança.
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).
Inventário de dados (Data Mapping).
Relatórios de impacto à privacidade (PIA - Privacy Impact Assessment).
Contratos e termos relacionados ao processamento de dados.
Plano de resposta a incidentes relacionados à violação de dados pessoais.
O que precisamos definir nesta tapa
Quais dados pessoais são processados e em que contexto.
Mecanismos e métodos para limitação de acesso aos dados, como o uso do RBAC e/ou ABAC.
Modelos e Estratégias de anonimização e criptografia.
Períodos de retenção de dados e políticas de exclusão, conforme as dependências do projeto.
Artefatos a serem gerados nessa etapa
Manual de Configuração de controle de acesso com granularidade apropriada.
Relatório de Logs Auditáveis nos acessos a dados pessoais.
Documentação de conformidade com LGPD/GDPR.
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
Criptografia – Definir e Configurar criptografia de dados em repouso e em trânsito.
Segregação de Dados – Garantir a aplicação da segregação de dados sensíveis conforme a necessidade de cada ambiente.
Privacidade por Design – Utilizar o princípio de privacidade por design por padrão.
Mapeamento de Dados: Identificar onde dados pessoais são processados e armazenados para garantir que controles de acesso sejam aplicados consistentemente.
Criptografia e Anonimização: Garantir que dados pessoais estejam protegidos mesmo em caso de violação.
Logs e Auditorias: Manter registros detalhados de acessos e ações em dados pessoais, permitindo rastreabilidade completa.
Ferramentas recomendadas
Controle de acesso federado com suporte a GDPR – Keycloak
Gerenciamento de segredos e senhas – HashiCorp Vault.
Gerenciamento de políticas de acesso a dados sensíveis – Apache Ranger.
Para conformidade em aplicações Python – Django GDPR.
Testes e Avaliações Iniciais
Testes de Coleta de Dados – Testes de Consentimento, Testes de Legalidade, Testes de Transparência e Testes de Minimização de Dados.
Testes de Armazenamento de Dados – Testes de Segurança da Infraestrutura, Testes de Integridade, Testes de Criptografia e Testes de Controle de Acesso.
Testes de Processamento de Dados – Testes de Anonimização e Pseudonimização, Testes de Finalidade e Testes de Qualidade dos Dados.
Testes de Compartilhamento de Dados – Testes de Compartilhamento com Terceiros e Testes de Transferência Internacional de Dados.
Testes de Descarte de Dados
Testes de Direitos dos Titulares – Testes de Acesso aos Dados, Testes de Retificação de Dados, Testes de Exclusão de Dados, Testes de Portabilidade de Dados e Testes de Oposição ao Tratamento.
Simulação de vazamentos para avaliar a eficácia de medidas de mitigação.
Referências técnicas
ISO/IEC 27001 e 27701 – Diretrizes de proteção de dados e privacidade.
NIST SP 800-122 – Guia de proteção de informações pessoais identificáveis (PII).
LGPD e GDPR
Considerações Finais
Este documento teve como objetivo apresentar as melhores práticas para a aplicação dos processos de autenticação e gerenciamento de credenciais, tendo como referência o Guia de Melhores Práticas de Codificação Segura OWASP. Além disso, foi proposto o alinhamento com a abordagem do DevSecOps, visando assegurar a integridade, confidencialidade e disponibilidade dos dados sensíveis no contexto da saúde.
Oferecemos aqui um ponto de partida robusto, conciso e prático para integrar controle de acesso nas fases do SSDLC, tendo assim asseguradas a conformidade e proteção contra ameaças.