Políticas de segurança

Política de Desenvolvimento Seguro de Software

  1. 1. APRESENTAÇÃO E OBJETIVOS
  2. 2. ARMAZENAMENTO DE DADOS
    1. 2.1 Procedimentos e Meios para Armazenamento de Dados
    2. 2.2 Permissões para Acesso a Informações em Bancos de Dados
    3. 2.3 Gerenciamento e Distribuição de Senhas para Acesso a Dados
  3. 3. GERENCIAMENTO E DISTRIBUIÇÃO DE SENHAS PARA ACESSO A DADOS
    1. 3.1 Autorização e Autenticação de Usuários
    2. 3.2 Autenticação em Sistemas Web
  4. 4. COMUNICAÇÃO SEGURA
  5. 5. ATAQUES À SISTEMAS E SUAS DEFESAS
  6. 6. AUDITORIA, RASTREAMENTO E LOGS
    1. 6.1 Exemplos de eventos que podem ser registrados:
    2. 6.2 Exemplos de informações que podem ser armazenadas, relativas a cada evento:
  7. 7. PREVENÇÃO, REAÇÃO E MITIGAÇÃO DE FALHAS DE SEGURANÇA
    1. 7.1 Backups
    2. 7.2 Testes
    3. 7.3 Ocorrências
  8. 8. AMBIENTE DE DESENVOLVIMENTO
    1. 8.1 Acesso ao Código-Fonte
    2. 8.2 Separação de Ambientes
  9. 9. PROTEÇÃO DE DADOS
    1. 9.1 Criptografia e Hash
    2. 9.2 Senhas
  10. 10. CICLO DE VIDA DE ​SOFTWARE
    1. 10.1 Projeto
    2. 10.2 Codificação
    3. 10.3 Manutenção
    4. 10.4 Pessoal

1 - APRESENTAÇÃO E OBJETIVOS

Este documento é o guia para desenvolvimento seguro de software no âmbito da Epimed Solutions. Seu objetivo é servir como guia de boas práticas a serem adotadas por analistas, desenvolvedores de software, tornando o processo de concepção dos sistemas construídos mais confiável, auditável, estável e protegido contra ameaças. As orientações aqui contidas são direcionadas a todos os envolvidos no processo de desenvolvimento de software no âmbito da Epimed Solutions.

A Epimed Solutions se preocupa em proteger a confidencialidade dos Dados Pessoais e/ou Dados Sensíveis de Pacientes ou clientes que sejam de qualquer modo obtidos através de seus softwares, em conformidade com a nova legislação brasileira nº 13.709, de 14 de agosto de 2018 (“Lei Geral de Proteção de Dados” ou “LGPD”). Por este motivo, a Epimed Solutions estabeleceu a Política de Privacidade e Proteção de Dados Pessoais, da qual este documento pertence na qualidade de anexo. Todas as orientações contidas neste documento deverão ser interpretadas de acordo com as diretrizes da Política de Privacidade e Proteção de Dados Pessoais, que sempre prevalecerão quando em eventual conflito com as diretrizes deste documento.

2 - ARMAZENAMENTO DE DADOS

Esta seção apresenta definições e diretrizes que tratam do armazenamento de informações sigilosas ou não e de sua disponibilização. Descreve procedimentos para o armazenamento seguro das informações em bancos de dados. Detalha o gerenciamento de permissões de acesso e distribuição de senhas a serem adotadas para operacionalização dessas estruturas.

 

2.1 Procedimentos e Meios para Armazenamento de Dados

  • Não se deve utilizar meio de armazenamento que não possua acesso para leitura e escrita restrito por senha. 
  • Deve-se preferencialmente armazenar dados criptografados.

 

2.2 Permissões para Acesso a Informações em Banco de Dados

  • Não se deve disponibilizar às aplicações acesso à algum banco de dados utilizando login de usuário com permissões de root.
  • Não se deve disponibilizar às aplicações acesso à algum banco de dados utilizando login de usuário com permissões para execução de comandos em Data Definition Language (DDL).
  • Não se deve disponibilizar às aplicações acesso à algum banco de dados utilizando login de usuário com permissões além das estritamente necessárias ao seu funcionamento.

 

2.3 Gerenciamento e Distribuição de Senhas para Acesso a Dados

  • Não se deve permitir a elaboração de senhas que não sigam os padrões estabelecidos pela Epimed Solutions. As senhas devem possuir no mínimo 6 (seis) caracteres alfanuméricos, utilizando caracteres especiais (@ # $ %).
  • Não se deve utilizar o armazenamento de senhas em código-fonte.
  • Deve-se armazenar de forma segura os dados de usuários e os sistemas que utilizam cada senha fornecida.
  • Não se devem utilizar as mesmas senhas para ambientes de desenvolvimento, teste, homologação e produção.

3 - GERENCIAMENTO E DISTRIBUIÇÃO DE SENHAS PARA ACESSO A DADOS

Esta seção apresenta definições e diretrizes que tratam do controle de acesso aos dados e a atribuição das permissões necessárias.

 

3.1 Autorização e Autenticação de Usuários

  • Não se deve armazenar senhas em texto plano sem utilizar um algoritmo de hash seguro e salt.
  • Deve-se utilizar controle de usuário e senha nominais para determinar a identidade do usuário.
  • Deve-se utilizar autenticação via AD sempre que possível para autenticar usuários internos.
  • Deve-se dar ciência ao usuário das permissões e níveis de acesso que possui.
  • Deve-se utilizar grupos de ​Active Directory ​ (AD) para determinar as políticas de acesso e ​roles ​ de usuário.

 

3.2 Autenticação em Sistemas Web

  • Sendo o HTTP um protocolo stateless, que utiliza cookies para manter sessões de usuário, faz-se necessário garantir tanto a segurança da troca de credenciais quanto a segurança das demais páginas acessadas pelos usuários dos sistemas web. O protocolo HTTPS visa contribuir para que essa segurança seja garantida. 
  • Dessa forma deve-se utilizar HTTPS em todas as telas dos sistemas.

4 - COMUNICAÇÃO SEGURA

Esta seção apresenta definições e diretrizes que tratam da transmissão segura de dados sensíveis entre sistemas, de modo a salvaguardar a integridade, autenticidade e demais atributos pertinentes ao uso dos dados comunicados.  

  • Deve-se empregar canal de comunicação com controle de duplicação e perda de informações/mensagens. Dessa forma deve-se utilizar HTTPS em todas as telas dos sistemas.
  • Deve-se empregar canal de comunicação que provenha controle de integridade dos dados transmitidos (HTTPS).
  • Deve-se empregar canal de comunicação com controle de autenticação (HTTPS, certificados digitais gerados por autoridades confiáveis, VPNs).
  • Deve-se armazenar de maneira segura os dados a serem transmitidos em ambas as extremidades da comunicação.
  • Deve-se empregar canal de comunicação que provenha confidencialidade dos dados transmitidos (HTTPS e VPNs).

5 - ATAQUES À SISTEMAS E SUAS DEFESAS

Esta seção apresenta diretrizes para reforçar a resiliência de sistema a ataques contra sistemas e aplicações. Recomenda-se que sejam prevenidos os principais ataques conhecidos, de forma a evitar que ataques mal-intencionados possam comprometer a segurança do sistema, expor dados sigilosos e realizar operações não autorizadas, dentre outras vulnerabilidades. 

  • Deve-se prevenir ataques de injeção de SQL (SQL Injection).
  • ​Não se deve criar SQLs concatenando parâmetros textuais de origem não-segura, como parâmetros preenchidos pelo usuário ou mesmo armazenados no banco de dados.
  • Deve-se restringir permissões de acesso ao banco de dados para o usuário da aplicação.
  • Deve-se, sempre que possível, passar parâmetros em comandos SQL (DML ou DDL) utilizando prepared statements. Consultas que não podem ser parametrizadas deverão receber tratamento especial, como escapes ou codificação em hexadecimal.
  • Deve-se prevenir ataques de injeção de HTML e Javascript.
  • Deve-se prevenir ataques do tipo cross-site scripting (XSS).
  • Deve-se prevenir ataques de quebra de autenticação e gerenciamento de sessão (Broken Authentication and Session Management.
  • Deve-se submeter os sistemas a ferramentas de testes de invasão.

6 - AUDITORIA, RASTREAMENTO E LOGS

Esta seção apresenta diretrizes para a manutenção de registros/logs para posterior auditoria, rastreamento e consulta de incidentes ligados à segurança dos sistemas. Cada sistema possui uma criticidade diferente no que se refere a restrição de acesso a dados, não-repúdio e histórico de operações realizadas no banco de dados. Por esse motivo, essa seção não define quais informações devem ser auditadas, mas sim sugere possíveis itens que podem ser auditados, rastreados oulogados. Estes itens, então, devem ser avaliados pelos gestores do produto.

 

6.1 Exemplos de eventos que podem ser registrados:

  • Acessos a determinadas telas ou seções do sistema;
  • Acesso a informações com alguma restrição (​Ex: documentos sigilosos, dados pessoais…);
  • Operações de inclusão, alteração ou exclusão de registros no banco de dados;
  • Alteração de perfil de acesso (para sistemas que possuem acesso com diferentes perfis);
  • Execução de jobs e tarefas automatizadas.

 

6.2 Exemplos de informações que podem ser armazenadas, relativas a cada evento:

  • Data e hora; 
  • Usuário que efetuou a operação;
  • Endereço IP;
  • Identificador da sessão do usuário (quando aplicável Ex: cookie);
  • Tela (página) do sistema de onde a operação foi realizada;
  • Identificador da instância (para sistemas clusterizados );
  • Para operações de inserção, alteração ou exclusão, o tipo da operação, nome da tabela que foi manipulada, ID do registro e, se for o caso, valores anterior e atual de cada campo;
  • Parâmetros informados pelo usuário (​Ex: parâmetros GET ou POST), tomando cuidado de não armazenar dados sensíveis, como senhas;
  • Tempo de resposta do sistema;
  • Para execução de jobs e tarefas automatizadas, armazenar o resultado da operação; falha, sucesso, cancelada, etc.

7 - PREVENÇÃO, REAÇÃO E MITIGAÇÃO DE FALHAS DE SEGURANÇA

Esta seção apresenta diretrizes para a realização de procedimentos que garantam uma reação adequada à ocorrência de falhas de segurança. Detalha-se o emprego de backups, testes e tratamento de ocorrências.

 

7.1 Backups

  • Deve-se definir um procedimento estruturado para a restauração de backups.
  • Deve-se definir e capacitar responsáveis pela recuperação dos backups.
  • Deve-se criar baselines das versões do sistema, facilitando a recuperação ágil para uma versão anterior.
  • Deve-se realizar simulações de restauração de dados continuamente.

 

7.2 Testes

  • Deve-se realizar testes manuais de segurança antes de cada versão do software que modifique sua estrutura (telas de login, serviços não autenticados, novos formulários com interação com o usuário, etc.).
  • Deve-se garantir, através de testes automatizados, que os serviços e dados sigilosos estejam protegidos e disponíveis apenas para os usuários detentores das informações.
  • Deve-se elaborar uma política de testes, automatizados ou não, visando a garantia de não vulnerabilidade aos principais ataques conhecidos em sistemas.
  • Deve-se definir cenários de testes voltados à garantia dos requisitos não funcionais dosoftware, preferencialmente realizado por uma equipe de testes diferente da equipe de desenvolvimento do software, com intuito de se evitar vícios.
  • Deve-se definir cenários de testes, principalmente nos aspectos de segurança, para os casos de atualizações na arquitetura do sistema (servidores de aplicação, banco de dados, versões de browser, versões de sistema operacional, etc.).

 

7.3 Ocorrências

  • Deve-se manter procedimento planejado para imediata indisponibilização do sistema e realização de manutenção corretiva.
  • Deve-se definir uma política de acompanhamento pós-correção de ocorrências de falha de segurança.
  • Deve-se utilizar lições aprendidas nas ocorrências passadas para revisar a política de testes e incrementar segurança dos sistemas.

8 - AMBIENTE DE DESENVOLVIMENTO

Esta seção apresenta diretrizes para a instalação, configuração e gerenciamento de ambientes de desenvolvimento de sistemas.

 

8.1 Acesso ao Código-Fonte

  • Deve-se utilizar um sistema de controle de versão com controle de acesso e recuperação em caso de falhas. (Ex.: Microsoft Team Foundation Server).

 

8.2 Separação de Ambientes

  • Deve-se separar os ambientes de Desenvolvimento/Testes/Homologação do ambiente de Produção.
  • Deve-se utilizar bancos de dados distintos para cada ambiente.
  • Deve-se utilizar servidores de aplicação/web distintos para cada ambiente.
  • Deve-se prover acesso ao ambiente de Desenvolvimento/Testes/Homologação apenas aos integrantes da equipe de desenvolvimento e aos interessados no projeto (stakeholders).
  • Deve-se realizar testes periódicos para assegurar a segurança do ambiente de desenvolvimento/testes/homologação.
  • Não se deve fornecer as senhas de acesso ao ambiente de produção aos desenvolvedores.

9 - PROTEÇÃO DE DADOS

Esta seção apresenta diretrizes para a configuração de proteção a dados sensíveis. São detalhados parâmetros para criptografia, hash e gerenciamento de senhas.

 

9.1 Criptografia e Hash

  • Deve-se utilizar um método criptográfico que siga o princípio de Kerckhoffs. O método de encriptação e seus parâmetros devem ser públicos e estar documentados, somente a chave criptográfica deve ser mantida em sigilo.
  • Não se deve utilizar um cifrador que admita um método conhecido para quebra da chave criptográfica (força bruta), baseada em tentativa e erro.
  • Não se deve utilizar o modo de cifrador de bloco electronic codebook (ECB) ou modos menos seguros. 
  • Não se deve utilizar um tamanho da chave menor que 128 bits (cifrador simétrico) ou 1024 bits (cifrador assimétrico).
  • Não se deve utilizar função de hash sem algum tipo de salt.
  • ​Não se deve utilizar algoritmos considerados obsoletos para criptografia e hash criptográfico. Exemplos: MD5, SHA1, DES/3DES, RC2, RC4, MD4.
  • Não se deve utilizar um tamanho da chave menor que 192 bits (cifrador simétrico) ou 2048 bits (cifrador assimétrico).
  • Não se deve distribuir chaves criptográficas sem a utilização de uma infraestrutura de chave pública e, portanto, sem a utilização de um cifrador assimétrico.
  • Não se deve utilizar um tamanho da chave menor que 256 bits (cifrador simétrico) ou 4096 bits (cifrador assimétrico).

 

9.2 Senhas

  • Tamanho da senha: Não se deve utilizar senhas com menos de 6 caracteres.
  • Variação de símbolos: Deve-se utilizar pelo menos letras maiúsculas e minúsculas, junto a ao menos um tipo de caractere (dígito, símbolo).
  • Aleatoriedade: Não se deve elaborar senhas sem auxílio de software gerador de senhas aleatórias, configurado para atender aos parâmetros aqui estabelecidos.
  • Testes: Não se deve utilizar senha que não tenha sido validada por um software testador de força de senhas.
  • Periodicidade de troca: Não se deve utilizar periodicidade de troca de senhas superior a 6 meses.
  • Mudança e recuperação de senha: Não se deve permitir que se utilize o mesmo canal de validação da senha. Não se deve enviar a senha antiga para o usuário, em claro ou não, sob nenhuma hipótese.
  • Armazenamento (usuário): Não se deve armazenar senha que não esteja criptografada seguindo o nível padrão de criptografia estabelecido neste documento.
  • Número de tentativas: Não se deve permitir uma taxa de tentativas de validação de senha superior a 5 tentativas por minuto. A senha deve ser bloqueada em caso de no máximo 5 erros de validação consecutivos e sua reabilitação deve depender de processo específico.

10 - CICLO DE VIDA DE SOFTWARE

Esta seção apresenta diretrizes para reforço da segurança de software nas diferentes fases de seu ciclo de vida; projeto, codificação e manutenção. Traz ainda, diretrizes para a aplicação com as pessoas envolvidas nestas diferentes fases.

 

10.1 Projeto

  • Deve-se empregar modelo de projeto de software que contemple:
    • Etapa de modelagem de ameaças;
    • Definição clara dos riscos de segurança;
    • Nível de severidade que o comprometimento de dados sensíveis traria ao sistema e à instituição.
  • Não se deve omitir, durante o projeto de desenvolvimento de sistema e sua execução, a definição de responsabilidades pela segurança de dados do sistema e como essa responsabilidade será verificada.
  • Deve-se utilizar cronograma de projeto que contemple pontos de verificação de segurança do sistema desenvolvido ao longo de sua construção.

 

10.2 Codificação

  • Deve-se documentar, inclusive no código da aplicação, as medidas protetivas aplicadas no código-fonte, de modo a indicar precisamente o procedimento utilizado e suas peculiaridades.

 

10.3 Manutenção

  • Não se deve habilitar as atualizações automáticas de software ou componentes utilizados na construção de um sistema, sob pena de introdução indevida de falhas de segurança.
  • Não se deve modificar software de terceiros, salvo quando estritamente necessário. Controles de segurança internos podem ser invalidados. A mudança deve ser feita pelo desenvolvedor original do sistema sempre que possível.

 

10.4 Pessoal

  • Deve-se proporcionar treinamento e capacitação de programadores para aquisição e revisão de princípios de segurança computacional e desenvolvimento de software seguro.