Não são só os Portugueses, mas também temos esta mania: dizer muito mais mal das coisas do que bem. Basta um incidente de segurança para quebrar a confiança numa marca ou num produto. E é isso que te vamos ajudar a evitar.
Em primeiro lugar tens que ter a noção de que não há pós mágicos nesta área. O que fazes é um best effort que, na grande maioria dos casos, resulta. Não há nada 100% seguro.
Seja numa app, um website, ou qualquer conteúdo para a Internet que transmita ou receba dados, há várias coisas que podemos fazer para melhorar e também otimizar a user experience. Não basta teres um bom produto que vá colmatar uma necessidade, tens que saber que o produto está bem concebido para não passar de um sucesso a um fracasso em menos de nada.
Caso andes à procura de informação sobre por onde começar e o que precisas de saber para criar tecnologia, o nosso artigo “O que precisas de saber para programar a próxima app” é ideal para ti.
SSL, obviamente. Mas um SSL como deve ser.
Estamos em 2018 e por isso falar de SSL já se tornou demasiado banal. Mas o que muitos programadores desconhecem é que ter um SSL não chega. Os “headers” que o protocolo HTTP envia são muitas vezes maus e permitem ataques como Man in the Middle e outros (ainda) mais sofisticados. Uma boa forma de verificar se o servidor onde tens alojado o teu produto se encontra seguro é usares o SecurityHeaders, um site que analisa a resposta técnica do teu SSL.
Como exemplo prático, o uso de Content-Security-Policy evita ataques XSS, logo, este valor deve estar sempre bem configurado no teu servidor tal como descrito aqui.
Code review, pela tua segurança
Minimizar riscos, criar valor ao teu código, confirmar se o design e a infraestrutura estão corretas e respeitam os standarts ou até detectar bugs é a função do chamado code review ou auditoria de código fonte.
Este processo, recomendado para equipas pequenas, consiste em ter empresas a auditar o teu código, para prevenir que qualquer erro que tenhas cometido, enquanto programador, e que este seja detectado antes de publicares o teu produto online. Afinal, somos todos humanos.
Se o teu budget é reduzido e não consegues pagar o pricing que estas empresas pedem, uma outra hipótese é mostrares o código a um amigo teu, com o mesmo conhecimento que tu ou equiparado, para que ele consiga fazer o mesmo processo de “passar a pente fino” o teu trabalho.
Leis de Proteção de Dados
Uma Startup pode ir à falência se for considerada culpada por não relatar um incidente de segurança à luz do novo Regulamento Geral de Protecção de Dados - sim, literalmente à falência. Se a base do teu produto são cidadãos Europeus, ou tiveres pelo menos um cidadão Europeu como cliente, tens que cumprir o GDPR (ou RGPD em Português).
O Governo Português publicou uma checklist com "orientações técnicas para a Administração Pública em matéria de arquitetura de segurança das redes e sistemas de informação relativos a dados pessoais". Esta checklist é também a tabela pelo qual se vai reger o RGPD, pelo que deves verificar a tabela e garantir que tanto no frontoffice como no backoffice são, no mínimo, cumpridas estas normas.
Há que ter em conta que estas leis são criadas por burocratas e que, por exemplo, quando é apenas uma “recomendação” as passwords não estejam em plain text, sabemos que tu podes (e deves) fazer melhor que isso e encripta-las na tua base de dados.
Validar o envio e recepção de dados
Os ataques XSS existem e são cada vez mais comuns em web apps e websites. E nem sempre a firewall ou uma conta CloudFlare Pro te vai proteger disso. O segredo é a boa programação.
Para evitares o recebimento de dados incorretos pelo browser ou app, deves sempre declarar o tipo de dado que estás à espera de receber. Além disso, o tipo de dados, número máximo de caracteres ou os padrões, evitam que sejam recebidos dados que contenham código que pode despoletar um ataque informático. Podes ler mais sobre isto aqui.
Existem bibliotecas e frameworks que já contém muito boas práticas para evitares sofrer com XSS e outras vulnerabilidades. Duas delas são o Angular e o React. Se tiveres curiosidade em saber mais, lê o nosso artigo "A batalha épica: Angular vs React - quem ganhará?".
Código limpo
Uma das grandes vantagens de um programador é escolher o nome de funções ou variáveis e até nomes de ficheiros. E embora se possa fazer alguma coisa pertida e humorística com estes três elementos, devemos ter em conta que em code review podemos literalmente fritar os neurônios de quem nos audita.
Algumas das boas práticas são: usar “is”, “has” ou “should” no código, comentá-lo quando necessário, usar nomes de ficheiros facilmente explicáveis, funções não numéricas e relacionadas com uma palavra ou código que está no ficheiro, etc. Eis um exemplo prático de um mau código e depois um bom código, citado pelo Donavon West, responsável do departamento de engenharia da American Express:
mau código:const done = current >= goal;
bom código:const isComplete = current >= goal;
Servidores
A primeira coisa que tens que procurar ao escolheres um serviço externo para alojar os teus dados ou a tua app é o contacto (físico) da empresa, seguido dos dados legais e a reputação da empresa online. Tudo isto consegues fazê-lo com uma ou duas pesquisas no Google (mas se fores uma pessoa que liga muito à segurança, usas o DuckDuckGo). Por fim, verifica se o datacenter respeita algumas certificações ISO, nomeadamente certificações de qualidade ISO 9001, ISO 14001 e ISO 27001.
Backups
Se encontraste a empresa certa, preocupa-te agora com o backup dos teus dados: quando é feito, quem o faz, em que local é guardado? Se conseguiste responder a estas perguntas de forma satisfatória, tens uma boa aposta num servidor. E lembra-te: o backup, se for feito por ti, deve estar encriptado, pois os incidentes de segurança também podem acontecer no teu computador.
DDoS e Firewall
DDoS ou Denial of Service é o ataque mais básico que hoje em dia se pode fazer. Literalmente, qualquer jovem que procure ferramentas dessas no Google as vai saber usar em dez minutos. Há vários tipos de DDoS, mas há também técnicas que podem prevenir (quase) todos. A mais importante técnica será uma firewall física, mas nem todos os serviços de alojamento têm.
Ao contrário dos servidores “normais”, as Cloud Hosting Platforms como a DigitalOcean ou a Vultr, com protecções até 10Gbps. Existem também falhas ao nível aplicacional, e podes por isso usar o mod_security no Apache. Em última análise, caso não tenhas experiência nesta área, podes usar a CloudFlare, que por 20USD/mês te protege tanto a nível de DDoS como a nível de vulnerabilidades aplicacionais para os CMS mais populares.
Em termos de firewall no servidor, em sistemas Linux, o mais comum é usar a APF (Advanced Policy Firewall) em conjugação com o BFD (Brute Force Detection). Em sistemas com cPanel, a aposta, por ter uma interface gráfica, vai para a CSF (ConfigServer Security & Firewall).
Honestidade
Sim, honestidade é uma dica de segurança. Existem muitos sites de serviços e produtos, alguns expostos no Have I been Pwned, que ao sofrerem um incidente de segurança, se recusam a comunicar com os seus clientes de forma proativa e a informar o que aconteceu.
E a honestidade é uma dica de segurança porque na sequência do RGPD que abordámos há pouco vai ser obrigatório a partir do próximo mês comunicares com os teus utilizadores caso exista um incidente de segurança.
Anteriormente era algo apenas recomendado. Da mesma forma que és honesto em relação a uma quebra de segurança, deves também ser honesto em relação ao eventual tracking que possa existir na tua app e que os utilizadores podem não saber que existe ao utilizar o teu produto.
Como dissemos inicialmente, não há magia na segurança nem um fix everything automático. Mas se fizeres um esforço com estas boas práticas (algumas delas legais, com consequências monetárias se não forem acauteladas) estás certamente no bom caminho.
