Uma das dúvidas mais comuns na implementação de APIs REST é sobre como garantir a segurança dos serviços. Como muitas coisas em software, há várias opções, e vamos dar uma visão geral sobre as possibilidades, com uma boa dose de opinião.
O esforço na implementação de segurança e seu custo deve avaliar algumas questões principais. Claro que o ideal seria termos somente sistemas absolutamente seguros, porém isto pode trazer custos pesados e a decisão vai sempre levar em conta o que é “bom o suficiente”.
Parte das ações relativas a segurança depende de infraestrutura e parte depende de desenvolvimento. Sem dúvidas uma API privada pode ser muito mais blindada pela infraestrutura e talvez as preocupações dos desenvolvedores fiquem bem suaves. Já numa API pública o grau de exposição é bem maior e o leque de atacantes é desconhecido, exigindo do desenvolvimento uma série de verificações para garantir acessos legítimos e autorizados.
Ninguém quer permitir acessos indevidos às suas APIs, mas é claro que vazamentos de dados sobre os times e escalações do jogador no Cartola são menos preocupantes do que vazamentos num ERP ou CRM. Quanto mais interessantes os dados para uma pessoal mal-intencionada, mais críticos devem ser os bloqueios no acesso.
Uma observação importante é que é fundamental acompanhar as APIs de produtos eventualmente construídos fora da empresa. Um amigo de uma importante empresa de tecnologia de SP me contou que seu RH uma vez contratou um sistema de folha de pagamento que disponibilizava abertamente uma URL que listava TODOS os salários da empresa. Esta é uma falha catastrófica mesmo que os dados não saiam de dentro da empresa, e mostra a importância do processo de segurança permear tanto os desenvolvimentos internos como os terceirizados.
Hoje em dia o desenvolvimento de componentes com APIs é cada vez mais frequente e um sistema normalmente se integra com um ou mais sistemas da mesma empresa. Se suas APIs abrem possibilidades de interação em outros sistemas da empresa, os cuidados devem ser redobrados.
O controle da segurança muitas vezes se utiliza de mais de um mecanismo e a abordagem pode ser bem sofisticada. Falaremos aqui de exemplos bastante encontrados.
Em APIs internas, às vezes o controle da segurança fica totalmente implementado pela infraestrutura. Restrições de acesso por IP implementados em roteadores, firewalls e balanceadores de carga. Restrição também de protocolos de comunicação permitidos e portas, logging detalhado dos acessos realizados.
Isto também é possível em ambientes de nuvem como a Amazon Web Services, através de grupos de segurança, firewalls internos nas instâncias, controle no Elastic Load Balancer, VPCs, entre outras formas.
O HTTPS é um protocolo para comunicações seguras que vem sendo amplamente utilizado na internet há muitos anos. Ele provê autenticação entre usuários finais e servidores, e também na comunicação entre servidores.
Ele já protege contra ataques man-in-the-middle e provê criptografia bilateral entre cliente e servidor, protegendo contra Eavesdropping e Tampering. Servidores que se comuniquem via HTTPS possuem chance muito menor de brechas de segurança. Sendo usado em conjunto com a restrição de acesso na rede, já é uma solução bem segura para APIs privadas na maioria dos casos.
A autenticação HTTP basic é uma forma bem simples de um cliente informar suas credenciais de acesso ao fazer uma requisição HTTP. Ela é a técnica mais simples de exigir controle de acesso a recursos web, pois não requer cookies, identificadores de sessão ou páginas de login. São usados somente cabeçalhos HTTP estáticos, que não exigem handshake antes do início da comunicação.
Na autenticação HTTP Basic, o usuário e senha do cliente são enviados ao servidor codificados em Base64. Esta forma de autenticação provê algum controle de acesso, mas é vulnerável a interceptações na rede, que permitiriam que o atacante obtivesse o usuário e senha e passasse a fazer requisições usando os dados obtidos. Porém, o uso de HTTPS para proteger o canal resolve este problema.
Em linhas gerais a comunicação funciona conforme abaixo.
A autenticação HTTP Digest é outra forma de controle de acesso a recursos web, e é mais segura que a HTTP Basic. Ela aplica um hash criptográfico MD5 na senha antes de enviá-la pela rede, com uso de valores nonce para prevenir contra replay attacks.
Os cálculos MD5 usados na autenticação digest buscam ser unidirecionais, ou seja, deve ser difícil obter o valor de entrada somente a partir da saída. Porém, se a senha for muito simples não deve ser tão custoso o processo de quebra por força-bruta.
Em linhas gerais a comunicação funciona conforme abaixo.
A autenticação/autorização através de certificados também do lado do cliente é um refinamento adicional de segurança sobre a comunicação HTTPS, que já pode ser feita com certificados só do lado do servidor. Esta forma de autenticação/autorização é bastante segura, porém o trabalho e custo de lidar com certificados dos 2 lados é razoável, sendo adequada só em cenários muito sensíveis de segurança.
Esta é uma forma simples e segura de controlar autenticação/autorização de serviços entre servidores, embora não seja um padrão. Há alguns anos implementei algumas APIs usando esta forma. As etapas no geral são:
O OAuth é um padrão aberto para autorização. Ele provê um método para clientes acessarem recursos no servidor por parte do dono do recurso (como um outro cliente ou um usuário final). Ele também provê meios de usuários finais autorizarem acesso de terceiros a seus recursos em um servidor sem informar suas credenciais, normalmente através de redirects e confirmações por parte dos usuários.
O OAuth é comumente usado quando temos um aplicativo que precisa manipular APIs com dados de usuários finais e estes precisam autorizar o acesso. Exemplos típicos são aplicativos que conectam-se a conta do usuário em redes sociais.
Embora possa ser usado para autorizações entre servidores, isto não é muito comum. Embora seja seguro, o OAuth não tem adesão tão grande devido à complexidade na implementação. Exemplos abaixo para as versões 1.0 e 2.0
Há diversas formas de controlar a segurança de APIs REST, e neste post apresentamos formas comuns de fazê-lo. É possível criar protocolos customizados de autenticação/autorização, mas é altamente recomendável usar soluções já conhecidas.
Em posts futuros da série, mostraremos implementações prática destes mecanismos de segurança com Java e possivelmente outras linguagens.
Até a próxima!
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.