Política de Segurança da Informação para o Desenvolvimento MSTECH

Versão 1.0 - publicada em 20/05/2016

1. Apresentação

A Política de Segurança da Informação da MSTECH EDUCAÇÃO E TECNOLOGIA LTDA tem por finalidade estabelecer as diretrizes de segurança da informação para desenvolvimento de sistemas e dos serviços prestados aos seus clientes, reduzindo os riscos e garantindo a integridade, confidencialidade, sigilo e disponibilidade das informações dos sistemas de informação e recursos. Este documento possui caráter oficial e tange como modelo de referência aplicável para toda a empresa.

2. Escopo

A MSTECH, uma empresa de desenvolvimento de sistemas computacionais comprometida com os seus ativos de informação hospedados em sua própria infraestrutura de TI para acesso de seus clientes e usuários, necessita planejar as ações de segurança da informação nos níveis em que ela possa ser manipulada ou acessada, como os recursos computacionais que armazenam e manipulam a informação, passando pelo tratamento dos dados, pelo código produzido pela área de desenvolvimento de software da empresa até aos requisitos que serão exigidos dos usuários destes sistemas.

Para facilitar a compreensão, a disseminação e a busca das informações contidas neste documento pelas áreas e colaboradores diretamente envolvidos decidiu-se por segmentá-lo nos níveis de segurança da informação com abrangência na segurança das aplicações e do banco de dados como o conjunto de ações para garantir o tratamento e armazenamento correto dos dados dentro da aplicação e prevenir vulnerabilidades que permitam o ataque e roubo de informações por pessoas mal-intencionadas.

3. Segurança das aplicações e do banco de dados

A segurança das aplicações corresponde aos sistemas websites desenvolvidos pela MSTECH e hospedados na infraestrutura de TI, estes sistemas devem acessar o banco de dados com usuário configurado somente com permissão de leitura e escrita dos dados, não sendo permitido conceder quaisquer permissões de alterações dos objetos de banco de dados para os usuários utilizados pelos sistemas.

3.1 Validação dos dados

Para evitar possíveis falhas de segurança comuns em aplicações web, os sistemas devem realizar a validação da entrada de dados provenientes do cliente ou a partir do ambiente, antes de qualquer uso dessa informação. Esta deficiência abrange quase todas as principais vulnerabilidades tais como: scripting, cross site, injeção de SQL, injeção intérprete, ataques local e Unicode, arquivos de ataques do sistema e estouros de buffer.

Todos os dados de entrada recebidos pelo sistema devem ser tratados antes mesmo de serem processados, a rotina de validação deve ser realizada sempre no lado do servidor (podendo ser aplicado também no lado cliente mas, mesmo nesse caso, não se exclui a validação do lado servidor) e centralizada na aplicação com base em um conjunto de caracteres permitidos para cada campo.

Além disso, são considerados a identificação de todas as fontes de dados e sua classificação como sendo confiáveis ou não e, quando necessário o uso de caracteres especiais em algum campo, sempre realizar a codificação destes caracteres em UTF-8 para evitar que sejam tratados como código executável. Os dados de uma entidade externa ou cliente nunca devem ser considerados automaticamente como confiáveis sendo tratados em conformidade com as práticas citadas. Todas as requisições e respostas devem utilizar o padrão de codificação UTF-8.

3.2 Autenticação e gerenciamento de credenciais

A autenticação deve validar a identidade digital dos usuários autorizados bem como garantir que suas credenciais sejam transportadas de maneira segura, essa validação das permissões do usuário por parte do sistema deve ser realizada antes da execução de qualquer ação.

Os controles de autenticação e autorização devem executar padronizados e, já na ocorrência de situações excepcionais, como no caso de falhas, executar os procedimentos específicos com o propósito de manter o sistema seguro (por exemplo, negando a entrada do usuário no sistema).

Quando a aplicação gerenciar um repositório de credenciais as senhas devem ser armazenadas na base de dados somente sob a forma de hash reconhecidamente forte pelo mercado e, a tabela/arquivo que armazena as senhas e as próprias chaves devem ser manipuladas apenas pela aplicação. Já as credenciais de autenticação de acesso aos serviços externos à aplicação devem ser armazenadas em um local protegido.

Cada sistema estabelece um padrão de senhas fortes sendo implementadas considerando a especificação dos requisitos de comprimento e complexidade de senha. Os sistemas críticos devem exigir alterações mais frequentes nas credenciais de segurança e o tempo entre as trocas de senhas devem ser controlados administrativamente.

Os mecanismos de recuperação de senhas devem ser implementados de forma segura, atendendo aos requisitos da seção “3.1 Validação dos dados” deste documento.

Todas as páginas e todos recursos devem seguir os padrões de autenticação definidos pela MSTECH, exceto os destinados especificamente como sendo públicos. As tentativas de autenticação suspeitas devem ser registradas, incluindo solicitações com metadados relevantes e necessários para investigações de segurança.

Para evitar possíveis ataques de força bruta devem ser disponibilizados nas telas de autenticação recursos de proteção tal como o CAPTCHA.

Por fim, a MSTECH considera que todos os usuários e senhas de seus sistemas são pessoais e intransferíveis, não sendo de sua responsabilidade quaisquer sanções decorrentes de mau uso dessas credenciais.

3.3 Controle de acesso

As configurações de autorização dos controles de acessos especificam as atribuições e responsabilidades para cada tipo/perfil de usuário e quais seriam os objetos da informação, páginas, funcionalidades e recursos a que eles terão acesso e os níveis de permissão.

Os usuários que acessarem os recursos da informação devem ter suas credenciais válidas para realização deste acesso e estarem associados a um conjunto bem definido de funções e privilégios, essas funções e permissões de metadados serão protegidas de adulteração.

3.4 Gerenciamento de sessão

O gerenciamento de sessão é o mecanismo essencial do conjunto de interações entre usuário e o aplicativo na web. As sessões devem ser únicas para cada usuário e não podem ser adivinhadas ou compartilhadas, sendo invalidadas quando já não são mais necessárias e expiradas durante os períodos de inatividade.

Sempre que possível, as aplicações devem utilizar um framework ou sistema conhecido, testado e confiável para realizar o gerenciamento de sessão, evitando a criação de mecanismos próprios e inseguros.

Todas as páginas que requerem autenticação devem possuir acesso fácil e visível à função de logout.

Quando o usuário faz o logout sua sessão deve ser invalidada, tanto no lado cliente excluindo os respectivos cookies e tokens, quanto no lado servidor invalidando os mesmos. Assim, mesmo que o usuário force a recriação dos cookies e tokens destruídos o sistema não os aceita.

Todas as sessões devem ser criadas com um tempo para expiração, de modo que após esse tempo de inatividade devem ser invalidadas automaticamente pelo servidor. Além disso, deve ser configurado um tempo limite após o qual as sessões são invalidadas independente da atividade.

Sempre que um usuário é autenticado ele recebe um novo identificador de sessão e autenticação, mesmo que já exista um com o mesmo nome no lado cliente, neste caso o valor anterior deverá ser invalidado e sobrescrito com o novo valor.

Os identificadores armazenados em cookies devem ser criados com escopo mínimo, especificado com o parâmetro path. Além disso, os cookies de autenticação deverão ser setados com os atributos HttpOnly e Secure.

Para operações sensíveis o sistema deve utilizar mecanismos adicionais ao gerenciamento de sessão, como a criação de tokens ou parâmetros aleatórios associados com a sessão e página atual.

3.5 Criptografia de dados

Os dados confidenciais, tanto os armazenados no banco de dados quanto nos arquivos de configuração, como conexões de banco de dados, deverão ser criptografados. Os acessos às chaves devem ser realizados de uma forma segura. Define-se por dados confidenciais quaisquer tipos de senha e outros dados que o escopo do projeto considere como sensível.

As senhas não devem ser armazenadas no banco de dados em forma de texto, ao invés disso apenas um hash da senha reconhecidamente forte será armazenado.

O gerenciamento e acesso às chaves de criptografia devem seguir uma política específica, que define todo o ciclo de geração, distribuição, revogação e expiração das chaves, assim como a forma de armazenamento e acesso das mesmas.

A geração de números, nomes, textos e identificadores aleatórios devem ser realizadas por um módulo de criptografia confiável, de forma que os valores gerados não sejam previsíveis.

3.6 Tratamento de erros e log

Na ocorrência de algum erro o sistema deve exibir uma página padronizada de erro sendo que esta evitaria a exibição de detalhes técnicos para os usuários.

Os erros e operações relevantes deverão ser armazenados em log com as devidas informações necessárias para uma futura investigação do ocorrido. Além disso, os dados armazenados em log devem conter apenas as informações úteis para o mesmo, sem coletar informações sensíveis a menos que estritamente necessário.

As informações registradas devem ser tratadas de forma segura e protegidas de acordo com a sua classificação de dados. Além disso, estes registros devem ter seu “tempo de vida” limitado e o mais curto possível e as aplicações configuradas periodicamente devendo ser realizado o expurgo dos dados de log.

3.7 Proteção de dados

As aplicações devem buscar atender três requisitos gerais de proteção aos dados:

a) Confidencialidade: os dados são protegidos contra acesso não autorizado ou vazamento. Essa proteção deve ser garantida em qualquer ponto, tanto no armazenamento quanto no transporte;

b) Integridade: a integridade dos dados deve ser garantida através de mecanismos de proteção que impeçam a alteração, criação ou comprometimento por usuários sem a devida autorização;

c) Disponibilidade: os usuários autenticados e devidamente autorizados são capazes de acessar os dados a qualquer instante. A proteção de dados sensíveis armazenados no servidor é aplicável na preservação e no controle de acesso, incluindo dados em cache, arquivos temporários e dados acessíveis somente por usuários específicos do sistema. Tais dados devem ser criptografados mesmo quando armazenados no servidor, de acordo com a seção “3.5 Criptografia de dados” deste documento.

Será restrito o acesso aos usuários apenas às funcionalidades, dados e informações do sistema que são necessárias para execução de suas tarefas, ou seja, deve-se aplicar o princípio do menor privilégio seguindo as práticas da seção “3.3 Controle de acesso” deste documento.

Não devem ser armazenadas senhas, strings de conexão ou outras informações confidenciais em texto claro/legível ou em qualquer forma considerada insegura no lado cliente. Isso é válido também quando há utilização de formatos inseguros como: viewstate, viewbag, Flash ou código compilado à ser executado no lado cliente.

Em produção, deve-se publicar apenas páginas e código fonte compilado, se possível. O código fonte que precisar de armazenamento no servidor deve estar protegido para evitar o acesso de usuários. Em caso de publicação de API´s nenhuma documentação deverá ser publicada em ambientes de homologação e produção.

Deverão ser removidos os comentários dos códigos em produção, assim como documentações, aplicações e funcionalidades extras não necessárias e que possam revelar informações sobre o sistema. Também deverão ser aplicadas técnicas como ofuscação e minificação de código.

As páginas e formulários que contenham informações sensíveis, incluindo páginas de login, deverão ser devidamente configuradas para impedir o autopreenchimento e o cache no lado cliente.

3.8 Segurança nas comunicações

Os servidores devem possuir certificados TLS validados por uma CA (autoridade certificadora) confiável, e o protocolo TLS deve ser utilizado em todas as conexões, externas ou internas, que requeiram autenticação e/ou envolvam dados e funções sensíveis.

Deve-se utilizar em todo o processo de certificação e criptografia apenas os algoritmos, chaves e protocolos mais fortes e o sistema não poderá aceitar uma alternativa de conexão insegura, mesmo na ocorrência de erros no processo.

3.9 Arquivos e recursos

Sempre que houver redirecionamento e encaminhamento de URL o destino deverá ser validado por uma white list ou deverá exibir um aviso de redirecionamento para conteúdo não confiável.

Dados de arquivos provenientes de fontes não confiáveis não devem ser utilizados diretamente em comandos de leitura e escrita de arquivos e nem executados por uma aplicação.

Em qualquer funcionalidade onde um arquivo pode ser recebido pelo sistema, deve-se restringir os tipos de arquivos aceitos apenas ao necessário. Os arquivos devem ser validados quanto ao seu tipo (através da extensão, tipo mime e cabeçalhos) e conteúdo (verificado por um antivírus), a fim de prevenir o carregamento de arquivos que possam ser interpretados ou executados pelo servidor. A validação é realizada por white list, e antes dessa validação os caracteres especiais, de controle e Unicode deverão ser removidos do nome e extensão do arquivo.

Os arquivos obtidos de fontes não confiáveis devem ser armazenados fora do diretório do sistema e com permissões limitadas (nunca com permissão de execução), preferencialmente em um servidor de conteúdo ou banco de dados. Ao armazenar um arquivo, seu nome deve ser alterado para um identificador único e não previsível, recuperável pela aplicação e, no caso de nomes repetidos, não subscrever os arquivos já existentes.

O caminho absoluto de um arquivo não deve ser enviado para o usuário ou para o lado cliente da aplicação. Sempre utilizar um mecanismo de mapeamento de recursos.

3.10 Mobile

Dados sensíveis não devem ser armazenados no dispositivo sem proteção (criptografia ou hash seguros), mesmo em áreas protegidas do sistema. Identificadores armazenados no dispositivo que possam ser acessados por outras aplicações (UDID, IMEI entre outros) não devem ser utilizados como token de autenticação.

A aplicação requisitará a permissão de acesso apenas para os recursos e funcionalidades realmente necessários, evitando assim o vazamento de informações sensíveis.

Evite exportar activities, intents, content providers e equivalentes para outras aplicações no mesmo dispositivo, aqueles que precisarem ser exportados deverão ser validados todos os parâmetros de entrada.

Para evitar análises de engenharia reversa, a descompilação e leitura de código fonte e scripts deve ser dificultada através do uso de ofuscadores de código, minificação e, se possível, criptografia.

3.11 Web Services e API´s

Todos os webservices e API´s devem implementar mecanismos de autenticação e autorização de acordo com as respectivas políticas de segurança. Além disso, para webservices o gerenciamento de sessão também deve implementar esses mecanismos.

Todos os parâmetros de entrada deverão ser validados quanto ao seu conteúdo, formato e tamanho.

3.12 Configurações

Sempre que for necessário o uso de componentes, bibliotecas ou plataformas de terceiros, utilizar a última versão estável destes. Na ocorrência de atualização de componentes já em uso, as próximas versões dos sistemas devem utilizar os componentes atualizados, principalmente se a atualização visa corrigir falhas de segurança.

Os sistemas próprios e componentes de terceiros são configurados de maneira segura quando publicados. Configurações e funções desnecessárias serão removidas, assim como eventuais exemplos para desenvolvimento, documentações, credenciais de teste e demais configurações padrão.

A comunicação entre as partes do sistema (aplicação, banco de dados, serviços, entre outros) deve ser realizada através de um canal seguro e encriptado, utilizando credenciais para autenticação com o menor nível de privilégio necessário.

Os sistemas são publicados e configurados de forma que fiquem isolados de demais sistemas no mesmo servidor, ou seja, utilizando credenciais e restrições de permissão com privilégio mínimo. Assim, mesmo na eventual ocorrência de um atacante conseguir acesso completo ao sistema, este não conseguirá comprometer demais sistemas no mesmo servidor, nem tampouco o servidor em si.

Os ambientes de desenvolvimento e testes devem ser isolados, apenas com acesso interno. Qualquer ambiente com acesso externo (como o de homologação) seguem as mesmas diretivas e padrões de segurança dos ambientes de produção.

3.12.1 Configurações para servidor web

Para os websites, criar o arquivo robots.txt com regras que negam o acesso aos arquivos e diretórios sensíveis que não podem ser indexados. Preferencialmente, todos os arquivos e diretórios sensíveis devem estar em um diretório comum, negando o acesso apenas a esse diretório.

Os servidores web também são configurados de forma a oferecer o maior nível de segurança às aplicações. De acordo com as seguintes configurações:

   a)	A listagem de diretórios deve ser desabilitada;

   b)	Os métodos HTTP aceitos devem ser definidos e os demais devem ser explicitamente bloqueados;

   c)	As respostas HTTP devem conter um cabeçalho que especifique um conjunto de caracteres seguro;

   d)	Os cabeçalhos HTTP ou qualquer parte da resposta não devem revelar informações sobre os componentes e sistemas utilizados no servidor;

   e)	Utilizar os cabeçalhos e valores “X-Content-Type-Options: nosniff”, “X-XSS-Protection: 1; mode=block” e “X-Frame-Options: sameorigin”, a menos que estritamente necessário o uso de configurações diferentes.

3.12.2 Configurações para servidor de BD

A conta padrão de administrador do servidor de banco de dados deve ter seu nome e senha alterados, e se possível a conta deve ser desabilitada.

Se houver uma conta de “convidado”, esta deve ter seu acesso negado a todas as bases de dados, a menos que estritamente necessário.

O role “public” não deve ter permissão de acesso às stored procedures.

A configuração padrão de portas utilizadas pelo servidor de banco deve ser alterada, especificando portas não conhecidas previamente.

Se houver um serviço de descobrimento das instâncias do banco de dados, este deve ser desabilitado para que não divulgue informações do servidor na rede.

---

Sobre

A política de segurança da informação para desenvolvimento de sistemas da MSTECH foi construída a partir de diversos documentos de projetos de referência nesta área de estudo, como a The Open Web Application Security Project (OWASP), entre outros.

Trata-se de um conjunto de boas práticas que devem ser praticadas pelos times de desenvolvimento da MSTECH, visando aumentar o nível de segurança das nossas aplicações, garantindo a segurança dos dados de nossas aplicações e dos dados de nossos clientes e usuários. A segurança da informação é um item essencial para a estratégia de uma empresa de desenvolvimento de sistemas e, como tal, deve ser um item de preocupação permanente de todos os funcionários.

Este documento é evolutivo e será constantemente revisto para adequá-lo à novas situações e tecnologias que forem sendo consideradas. Para sua evolução, contamos também com a sua colaboração, encaminhando sugestões aos responsáveis pela avaliação de segurança dos produtos da empresa.