Manual de segurança da informação e boas práticas para aplicações
Parte I
1. INTRODUÇÃO
Com o mundo cada vez mais digital, a preocupação das empresas em relação à segurança da informação é visível e extremamente necessária. É possível perceber que a relevância deste setor está em constante crescimento, principalmente em empresas que detém grande quantidade de dados sensíveis.
Mas o que exatamente faz a área de segurança?
No setor de TI, a segurança envolve mais que apenas eliminar vulnerabilidades e proteger contra-ataques de invasores. É responsável por preservar os recursos mais valiosos: dados e operações da companhia. E manter informações confidenciais é mais complexo do que parece.
Quando a segurança é bem executada, afeta de maneira positiva os resultados da empresa, visto que gera credibilidade e confiança para os clientes, mas se feita de forma inadequada, pode pôr em risco o negócio.
Para auxiliar a sua empresa a manter um alto nível de segurança para as aplicações, este artigo traz requisitos para a aquisição e/ou desenvolvimento de novos sistemas, ou atualização de sistemas já existentes.
Os requisitos deste artigo foram baseados nas melhores práticas de segurança, de acordo com a norma ISO 27002 e a metodologia OWASP (The Open Web Application Security Project).
2. REQUISITOS FUNCIONAIS DE SEGURANÇA
As funcionalidades relacionadas neste item são necessárias quando a aplicação exigir controle de acesso.
2.1 CONTROLE DE ACESSO
Recomendamos a utilização de Microsoft Active Directory (domínio CORP) para a função de autenticação/autorização de contas de acesso ao aplicativo.
Exceções devem ser discutidas pela área da Segurança da Informação.
2.1.1 CONTROLE DE SESSÃO E TEMPO DE INATIVIDADE
É importante que exista um controle de sessão do usuário e, após um tempo de inatividade, o usuário seja automaticamente desconectado do sistema. Este tempo deve ser, preferencialmente, configurável pelos administradores do sistema.
O controle de sessão dos usuários deve ser realizado através da utilização de valores enviados pelo campo apropriado no corpo da requisição http, gerados de forma randômica e que sejam inviáveis de obtenção através de ataques de força bruta. Tokens de sessão não devem ser enviados através de url e devem ser configurados com os atributos HttpOnly e Secure flag.
Deve ser garantido que páginas e links com informações classificadas como CONFIDENCIAL, RESTRITA ou INTERNA, que não façam consulta a banco de dados (ex: páginas e arquivos estáticos), não sejam acessíveis através de links diretos publicados acidentalmente na internet (ex: link direto de um documento .PDF ou um arquivo .XLS publicado no Twitter acidentalmente).
2.1.2 BLOQUEIO DE MÚLTIPLOS ACESSOS
O sistema deve proibir autenticação simultânea para o mesmo identificador de usuário. Este controle deve ser implementado através de controle de sessão.
2.1.3 PROTOCOLO DE COMUNICAÇÃO SEGURA
Recomendamos que as aplicações web da sua empresa adotem proteção por criptografia TLS para proteger o processo de autenticação, a sessão do usuário e a transmissão de qualquer informação CONFIDENCIAL ou RESTRITA. Os valores de sessão do usuário devem ser sempre protegidos através de criptografia TLS para evitar o roubo de sessão através de captura de tráfego de rede (sniffing).
A aplicação e o servidor web devem aceitar apenas estabelecer comunicação utilizando TLS versão 1.1 ou versão superior. O protocolo SSL (todas as versões) deve ser completamente desabilitado. Da mesma forma, cifras TLS com tamanhos de chave inferiores a 128 bits são consideradas fracas e devem ser rejeitadas, sugerimos aplicar chaves com 256 bits. Este item pode ser garantido através de configuração de segurança do servidor web.
As aplicações da sua empresa devem utilizar certificados SSL válidos emitidos por autoridades certificadoras reconhecidas pelos principais navegadores web, sendo que as aplicações corporativas devem utilizar o certificado SSL público já configurado no Netscaler, e servidores web internos devem utilizar um certificado SSL emitido pela CA (autoridade certificadora) interna de sua companhia.
Aplicações que permitem acesso a informações classificadas como CONFIDENCIAL devem ter o servidor configurado para apenas permitir acesso através de TLS, evitando a prática comum de redirecionar o usuário de http para https, o que deixa a comunicação vulnerável a ataques de interceptação que buscam impedir o uso de SSL (ataque conhecido como SSLStrip).
Quando possível, deve-se implementar o padrão conhecido como HTTP Strict Transport Security, o qual força os navegadores a acessar o servidor da aplicação apenas através de https e apenas quando o certificado apresentado pelo servidor é válido.
2.1.4 ACESSOS SEM AUTENTICAÇÃO
Mensagens e telas de sistemas que sejam acessíveis sem autenticação (ex: mensagens de erro de login ou páginas institucionais) não devem fornecer dados internos da sua empresa (ex: telefones, links e e- mails de contato com pessoas, setores ou o próprio Helpdesk, além de jargões e outros dados que possam ser utilizados por potenciais invasores na busca por brechas de segurança, como, por exemplo, qual servidor web está sendo utilizado).
Páginas necessariamente sem autenticação (ex: páginas de exibição de conteúdo de cartões virtuais, etc.) devem conter métodos que evitem o cacheamento ou indexação automática nos principais buscadores da Web (ex: “Metatag” e uso do arquivo “robots.txt” para o Google, Bing, etc).
2.1.5 HASHING DE SENHAS
No desenvolvimento ou aquisição de aplicações disponibilizadas a usuários externos, a sua empresa pode decidir não utilizar o Microsoft Active Directory (estas exceções devem ser discutidas com a área da Segurança da Informação). Nestes casos, deve-se armazenar as senhas dos usuários apenas através de função criptográfica de resumo (hashing), com intuito de impedir a reversão destas senhas para texto claro.
Nos cenários descritos acima, deve-se utilizar algoritmo de hashing que foi elaborado especificamente para este propósito, sendo um dos seguintes: bcrypt, PBKDF2 ou scrypt. Estes algoritmos são propositalmente de computação lenta para mitigar ataques de força bruta e já incluem internamente mecanismo de salting.
Algoritmos amplamente adotados como o MD5 ou SHA-1 são atualmente considerados fracos para esta finalidade e não devem ser utilizados. E, especialmente, algoritmos que permitem reverter criptografia não devem ser empregados para proteção de senhas.
2.2 ACESSO AO SISTEMA GERENCIADOR DE BANCO DE DADOS
Em hipótese nenhuma, a aplicação deve acessar o servidor de banco de dados utilizando usuário com privilégios administrativos (ex. SA, System, Sys, etc).
Os usuários de acesso ao banco de dados não devem possuir permissão para criar stored procedures e tampouco permissão para acessar as tabelas de sistema do banco de dados (ex: master..sysobjects, master..sysdatabases, master..syslogins e master..syscolumns no Microsoft SQL Server). As operações de gravação no banco de dados devem ser realizadas através de stored procedures customizadas e os usuários de acesso ao banco não devem possuir permissão para escrever diretamente nas tabelas. Além disto, o usuário de acesso ao banco de dados não deve ter permissão para executar stored procedures padrões do SGBD (ex. master..xp_cmdshell no Microsoft SQL Server).
Recomendamos que a sua empresa evite adquirir ou desenvolver novas aplicações utilizando o antigo modelo cliente/servidor, pois este facilita o acesso não autorizado ao SGBD. Caso seja necessário para o negócio utilizar uma solução com um cliente customizado (ex. cliente desenvolvido em C++), deve-se utilizar uma camada intermediária (ex. web services) para acesso a servidores de banco de dados remotos.
2.3 PROTEÇÃO CONTRA ATAQUES DE FORÇA BRUTA E OUTROS ATAQUES AUTOMATIZADOS
Para evitar ataques automatizados em formulários e outros tipos de páginas, as aplicações devem adotar uma proteção utilizando captcha. A solução adotada deve ser avaliada e aprovada pela área de Segurança de Informação da empresa, pois muitas implementações conhecidas de captcha podem ser derrotadas por programas de reconhecimento de imagens disponibilizados na Internet.
Para o processo de autenticação, deve avaliar se a proteção contra-ataques de força bruta será o bloqueio temporário de conta e/ou uso de captcha. Caso opte-se pelo uso de captcha para diminuir o risco relacionado a ataques de negação de serviço através de bloqueio de contas, a aplicação deve passar a desafiar o usuário, através de captcha, quando ocorrer um erro de autenticação. Já nesta primeira falha, a aplicação deve obrigar o usuário a passar pelo teste de captcha, antes de retornar a mensagem de erro. Após a primeira falha, o usuário só deve conseguir concluir o processo de autenticação após responder o teste de captcha, mesmo quando o usuário e senha estiverem corretos.
A aplicação deve possuir um contador de erros de autenticação, indicando o número de tentativas erradas após a última autenticação válida e, caso o contador seja maior que zero, deve sempre realizar a verificação por captcha, não havendo diferença para quando o usuário fornecer credenciais de acesso válidas. Qualquer erro de autenticação deve resultar na verificação do usuário através de captcha, antes de retornar a mensagem genérica de erro de autenticação, inclusive quando o usuário for inexistente no sistema.
Em formulários e outras páginas que podem ser exploradas por ataques automatizados, incluindo páginas de cadastro de usuário, páginas de recuperação de senha e páginas de envio de e-mail, as aplicações devem sempre testar o usuário através de captcha antes de completar o processo. É importante ressaltar que páginas permitindo a identificação de usuários válidos no sistema, como páginas de cadastro de usuário, devem testar se o cliente é humano, por captcha, antes de retornar a informação de usuário já cadastrado ou de cadastro efetuado com sucesso.
2.4 USO DE COMPONENTES EXTERNOS
O uso de Widgets e componentes hospedados externamente (ex: “.jar”, “.js”, ”.rss”, “.css”, “.xml”, buscadores, redes sociais: “like”, “comment”, “share this”, etc.) deve ser evitado e, sempre quando o uso for necessário, deve-se avaliar o componente para verificar se este não inclui código malicioso ou vulnerável, ou se a simples chamada do componente em questão pode facilitar ou acarretar violação da política, normas, padrões ou procedimentos de Segurança da Informação do seu negócio.
É essencial que, nestes casos, o ambiente de hospedagem externo seja avaliado quanto aos requisitos de segurança da sua empresa para evitar que vulnerabilidades externas afetem a integridade dos dados e sistemas corporativos.
2.5 MENSAGEM DE ERRO DE AUTENTICAÇÃO
As mensagens de erro de autenticação não devem fornecer informação quando o usuário não existe, a senha é incorreta ou o usuário está bloqueado. Deve-se apresentar uma mensagem genérica de autenticação que não permita a enumeração de usuários válidos no sistema.
2.6 TRATAMENTO DE MENSAGENS DE ERRO
A aplicação deve tratar mensagens de erro, evitando que o usuário receba mensagens de erro com informações do banco de dados, da aplicação ou do servidor. As mensagens de erro de sistema devem ser genéricas para o usuário, impedindo a identificação do tipo exato de erro ocorrido.
Além do tratamento de mensagens de erro pela própria aplicação, o servidor web da aplicação deve ser configurado para não exibir mensagens de erro para usuários comuns, mostrando no lugar uma página customizada. Para facilitar o trabalho da equipe de TI, pode-se configurar uma verificação de endereço de origem (endereçamento IP) para que a mensagem de erro original seja exibida para usuários provenientes da rede da empresa.
2.7 ENVIO DE MENSAGENS ELETRÔNICAS POR SISTEMAS (E-MAILS)
Mensagens eletrônicas (e-mails) enviadas por sistemas devem sempre utilizar a infraestrutura de e-mails corporativos, devendo obrigatoriamente ocorrer de forma autenticada por login e senha e através de túnel criptografado (SMTPS — SMTP over SSL/TLS). O certificado SSL do servidor SMTPS deve sempre ser validado.
2.8 CRIPTOGRAFIA EM BANCO DE DADOS
Informações classificadas como CONFIDENCIAL devem ser armazenadas no banco de dados utilizando criptografia forte. Utilize AES com chaves de tamanho de 256 bits ou superior. Caso outra opção de algoritmo de criptografia seja considerada, consulte a área de Segurança da Informação para verificar se a solução de criptografia é aceitável.
2.9 WEB SERVICES
A comunicação entre aplicações e web services deverá sempre utilizar criptografia SSL/TLS e o certificado SSL do servidor deverá sempre ser validado. Caso o servidor não apresente um certificado SSL válido para o endereço acessado emitido por autoridade certificadora válida (externa ou interna), a aplicação deverá rejeitar a comunicação com o web service. Quando possível, o cliente deve validar também se o certificado SSL foi emitido por autoridade certificadora previamente estabelecida (externa ou interna).
Deve-se proteger o uso de web services que realizam operações sensíveis ou que permitam acesso a informações classificadas como RESTRITAS ou CONFIDENCIAIS através das abordagens a seguir (a abordagem “a” é obrigatória e a abordagem “b” é recomendável):
a) Verificar se o cliente/usuário possui permissão para acessar o web service através de controle de sessão ou de autorização, onde o web service verifica se um token de sessão ou de autorização (randômico e com tamanho mínimo de 128 bits) válido, associado ao cliente ou usuário, foi enviado no corpo da requisição.
b) Restringir acesso aos web services por meio do uso de autenticação mútua através de certificado SSL, onde o certificado SSL do cliente é validado pelo servidor. Com exceção de web services com finalidade específica de autenticação de usuário, web services não devem controlar acesso através do recebimento de senha no corpo da requisição.
Vale ressaltar que para aplicações corporativas, a autenticação entre serviços deve utilizar o ADFS (Active Directory Federation Services) ou algum serviço de SSO de sua empresa.
2.10 TRILHAS DE AUDITORIA
Os sistemas da sua empresa precisam possuir trilhas de auditoria e pentest para registrar os seguintes tipos de evento: autenticação, logout, falhas de autenticação, execução de atividades críticas do sistema, eventos de negação de acesso, inclusão de usuários, alteração de dados de usuários, remoção e bloqueio de usuários.
Os eventos registrados devem acompanhar informações detalhadas sobre o usuário que efetuou a ação, incluindo: ID do usuário, perfil, data, hora e endereço IP.
Os campos de informações de auditoria devem ser escritos no momento da ocorrência do evento e não devem utilizar relacionamento com outras fontes de informação (ex. outras tabelas do banco de dados).
Informações sensíveis não devem ser armazenadas nas trilhas de auditoria, tais como senhas de acesso, tokens de sessão, números de CPF, entre outras possíveis informações sigilosas ou classificadas como CONFIDENCIAL ou RESTRITA.
Tecnologias, tais como web services e serviços LDAP/SSO, podem ser utilizadas para a centralização de trilhas de auditoria de vários sistemas.
2.11 AMBIENTES DE ACEITAÇÃO, HOMOLOGAÇÃO E PRODUÇÃO
As aplicações devem ser homologadas em servidores distintos dos servidores de ambiente em produção, porém, com as mesmas configurações de segurança adotadas nos servidores de produção.
Os servidores usados pela aplicação nos ambientes de aceitação, homologação e produção, devem ser mantidos com o sistema operacional, serviços de rede e softwares atualizados, com todas as correções de segurança instaladas. Nunca se deve utilizar senhas padrões ou senhas fracas na administração de plataformas web.
Informações classificadas como CONFIDENCIAL não devem ser armazenadas em ambientes de homologação ou de aceitação, mesmo sob proteção de criptografia. Utilize dados fictícios ou utilize rotinas para alterar dados reais sensíveis em ambientes de homologação ou de aceitação.
Aplicações disponibilizadas na Internet e hospedadas no ambiente de sua empresa devem utilizar o servidor localizado na DMZ, acessível a partir da Internet apenas através de proxy reverso (Netscaler).
2.12 HOSPEDAGEM EXTERNA E USO DE COMPUTAÇÃO EM NUVEM (CLOUD COMPUTING)
Caso a aplicação seja hospedada em ambiente externo, este deve ser avaliado quanto aos requisitos e segurança da sua empresa para evitar que vulnerabilidades externas afetem a integridade, confidencialidade e disponibilidade dos dados e sistemas corporativos e/ou a imagem da empresa.
Deve-se, inclusive, sempre que possível, garantir cláusulas específicas de Segurança da Informação na contratação deste tipo de serviço. Informações classificadas como CONFIDENCIAIS não devem ser armazenadas em provedores externos ou em nuvens não privadas (públicas). Informações classificadas como RESTRITAS só podem ser armazenadas em provedores externos ou em nuvens não privadas sob proteção de criptografia forte (veja o item 2.8 Criptografia em Banco de Dados).
Deve-se garantir que aplicações em ambientes compartilhados com outras organizações não possuam vulnerabilidades de controle de acesso ou de infraestrutura que permitam acesso às informações ou aos ambientes da sua empresa por usuários não autorizados. As tabelas de banco de dados do ambiente devem ser totalmente distintas das tabelas utilizadas por outras organizações. Constitui fragilidade de segurança a separação dos dados apenas através de um campo de identificação (ID). No desenvolvimento de aplicações em nuvem do tipo PaaS (Platform as a Service), é importante explorar os recursos que permitem obter forte segregação dos dados e ambiente entre as organizações/usuários hospedados.
Para aplicações utilizadas por usuários corporativos, deve-se considerar a implementação de single-sign-on (SSO) através de padrões como o SAML ou OAuth. Para integração com a base de usuários corporativa no AD, consulte a área de Segurança da Informação para obter orientação relacionada a arquitetura de segurança a ser adotada.
Evite a utilização de domínios compartilhados ou públicos para aplicações corporativas. Utilize domínios customizados, sob controle da sua empresa. Veja o item 3.15 Proteção contra Vulnerabilidades em Domínios Compartilhados.
Deve-se proteger APIs e web services controlando o acesso a estas interfaces (veja o item 2.9. Web Services) e protegendo-as contra vulnerabilidades de software (veja o item 3 Proteção Contra Vulnerabilidades de Software). Muitas APIs web são criadas para serem usadas apenas por outros serviços em nuvem e não deveriam ser utilizadas por usuários. No entanto, apesar de serem interfaces consideradas como “back end”, estas podem estar expostas na Internet. Sendo assim, deve-se implementar controles para restringir o acesso a estas APIs (ou web services), tais como o uso de autenticação mútua por SSL e uso de token de autorização.
Aplicações hospedadas externamente ou em nuvem devem seguir todas as orientações de segurança deste artigo, incluindo a realização de teste de intrusão conforme o item 5 Certificação de Segurança (será abordado na parte IV deste artigo).
Eu sou Rafael Borges, especialista em segurança da informação na Mobicare e Akross. Com vasto conhecimento em Tecnologia da Informação e Infraestrutura, gosto de trabalhar com diferentes soluções tecnológicas.
A Mobicare e a Akross combinam os Melhores Talentos, Tecnologias de Ponta, Práticas Agile e DevOps com Capacidades Operacionais avançadas para ajudar Operadoras Telecom e grandes empresas a gerarem novas receitas e a melhorarem a experiência dos seus próprios clientes.
Se você gosta de inovar, trabalhar com tecnologia de ponta e está sempre buscando conhecimento, somos um match perfeito!
