<\/p>\n
Neste artigo s\u00e3o descritas as formas de autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o de REST apis distribu\u00eddas, os motivos que aumentam a complexidade de desenvolvimento dessas futures em web services escalonados e as solu\u00e7\u00f5es baseadas nas melhores pr\u00e1ticas em rela\u00e7\u00e3o \u00e0 essas arquiteturas.<\/p>\n
Tamb\u00e9m \u00e9 abordado a import\u00e2ncia da cria\u00e7\u00e3o de sistemas seguros, evid\u00eancias que demonstram como esse problema impacta desde pequenas startups at\u00e9 grandes empresas, a gravidade da ci\u00eancia do n\u00edvel de criticidade e risco em rela\u00e7\u00e3o aos softwares desenvolvidos e a import\u00e2ncia de expor apenas recursos que sejam realmente necess\u00e1rios.<\/p>\n
Ser\u00e3o mencionados tamb\u00e9m os perigos relacionados aos ataques de Man-in-the-middle, nega\u00e7\u00e3o de servi\u00e7o, SQL inject, JSON inject e os m\u00e9todos utilizados para combat\u00ea-los.<\/p>\n
Informa\u00e7\u00f5es sigilosas s\u00e3o expostas diariamente e esse problema n\u00e3o atinge apenas jovens startups que n\u00e3o tem o devido investimento na \u00e1rea, com frequ\u00eancia surgem not\u00edcias de grandes empresas que s\u00e3o hackeadas e acabam vazando dados indesejados. Somente neste ano, o Yahoo! afirmou que quinhentos milh\u00f5es de contas foram hackeadas. No Dropbox foram mais de sessenta milh\u00f5es e a Anatel teve seu banco de dados invadido. Inclusive grandes organiza\u00e7\u00f5es como NASA e ESA n\u00e3o ficam fora dessa lista.<\/p>\n
Softwares com suas arquiteturas baseados em micro servi\u00e7os, orquestra\u00e7\u00e3o e coreografias s\u00e3o termos cada vez mais citados na comunidade de desenvolvimento web. E todas as abordagens tem uma caracter\u00edstica em comum: REST APIs. Elas est\u00e3o por toda a parte.<\/p>\n
Com o crescimento exponencial de estrat\u00e9gias digitais em mobilidade, cloud computing, m\u00eddias sociais e dispositivos inteligentes da Internet das Coisas, empresas de todos os tamanhos e setores est\u00e3o desenvolvendo e expondo seus Web Services. Mas como sempre no mundo da computa\u00e7\u00e3o, nem tudo s\u00e3o flores: junto com v\u00e1rias vantagens relacionadas \u00e0 utiliza\u00e7\u00e3o de APIs distribu\u00eddas, tamb\u00e9m existem grandes problemas a serem resolvidos, e uma das maiores dificuldades \u00e9 a seguran\u00e7a desses sistemas.<\/p><\/div>\n
J\u00e1 \u00e9 sabido que n\u00e3o existe uma forma de manter dados totalmente seguros na internet. A seguran\u00e7a total \u00e9 uma utopia, mas \u00e9 poss\u00edvel de se dizer que existe um n\u00edvel de seguran\u00e7a adequado para determinado software ou para dados espec\u00edficos.<\/p>\n
Antes de desenvolver ou arquitetar a seguran\u00e7a de uma API, \u00e9 fundamental determinar o n\u00edvel de criticidade existente nos dados que ser\u00e3o manuseados pela mesma, e quem ser\u00e3o os clientes que ir\u00e3o consumi-la. Se a API for disponibilizada apenas em uma rede bem configurada e consumidas apenas por sistemas desenvolvidos internamente, o risco ser\u00e1 muito menor que se estiver dispon\u00edvel na internet e sendo consumida por centenas de sistemas desenvolvidos por outras empresas ou pela comunidade. Outro fator importante \u00e9 ter o conhecimento dos dados trafegados pelo sistema e da criticidade de perda ou altera\u00e7\u00e3o deles.<\/p>\n
A defini\u00e7\u00e3o da forma de autentica\u00e7\u00e3o e de valida\u00e7\u00f5es de acesso que ser\u00e1 desenvolvido para cada API deve depender do n\u00edvel de criticidade dos dados manuseados e do risco relacionado \u00e0 perda ou modifica\u00e7\u00e3o dos mesmos.<\/p>\n
Primeira e principal preocupa\u00e7\u00e3o relacionada \u00e0 exposi\u00e7\u00e3o de APIs. Sempre! Voc\u00ea \u00e9 realmente quem diz ser? Voc\u00ea tem acesso a esse recurso? Estas s\u00e3o perguntas fundamentais. Evitar ataques de for\u00e7a bruta e roubo de credenciais s\u00e3o amea\u00e7as relacionadas \u00e0 autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o de APIs.<\/p>\n
Existem v\u00e1rias alternativas que diminuem a for\u00e7a dessas amea\u00e7as, desde uma simples implementa\u00e7\u00e3o do HTTP Basic, at\u00e9 o OAuth, que est\u00e1 se firmando como principal forma de delimita\u00e7\u00e3o de acesso \u00e0 recursos em APIs. As maiores empresas do mundo da tecnologia aderiram a esse padr\u00e3o, tais como Google e Facebook.<\/p>\n
O descuido nesse quesito pode colocar uma boa implementa\u00e7\u00e3o em risco, principalmente se suas APIs n\u00e3o forem disponibilizadas apenas em uma rede interna. Existem v\u00e1rios ataques em que um usu\u00e1rio consegue capturar as requisi\u00e7\u00f5es e respostas feitas ao seu Web Service. E n\u00e3o tem nada de dif\u00edcil nisso, a verdade \u00e9 que qualquer roteador em que uma requisi\u00e7\u00e3o passa tem acesso \u00e0s informa\u00e7\u00f5es trafegadas. Por isso \u00e9 muito importante que seu servidor tenha um certificado HTTPS para que os dados trafegados n\u00e3o sejam leg\u00edveis para interceptadores mal intencionados.<\/p>\n
Sabemos que \u00e9 indispens\u00e1vel o uso do HTTPS na constru\u00e7\u00e3o de APIs. Destaca-se que em algumas situa\u00e7\u00f5es, at\u00e9 mesmo o uso de uma criptografia adicional \u00e9 recomend\u00e1vel.<\/p>\n
Um exemplo de ataque que utiliza os meios citados \u00e9 o Man-in-the-middle, ou ataque do homem do meio. Consiste na intercepta\u00e7\u00e3o de dados trocados entre duas partes, por exemplo o navegador de um usu\u00e1rio navegando em um site e a sua API. O interceptador tem a capacidade de registrar as informa\u00e7\u00f5es em uma base local, ou at\u00e9 mesmo modific\u00e1 las.<\/p>\n
Mais um t\u00f3pico onde o risco de ataque \u00e9 muito maior no caso de sua API ser disponibilizada para todos na internet, ao inv\u00e9s de estar dispon\u00edvel apenas em uma rede interna. \u00c9 sabido que existe a necessidade, mas \u00e9 importante salientar a diferen\u00e7a da criticidade das duas situa\u00e7\u00f5es. Isso demonstra muito bem a import\u00e2ncia de um assunto j\u00e1 citado neste artigo: O levantamento do n\u00edvel de criticidade e risco relacionado ao seu sistema.<\/p>\n
DDoS, tamb\u00e9m citados como Ataques distribu\u00eddos de nega\u00e7\u00e3o de servi\u00e7os \u00e9 um dos riscos mais comuns nas abordagens citadas neste artigo. A quest\u00e3o \u00e9: Como \u00e9 poss\u00edvel construir softwares e definir a infra-estrutura ideal para resistir a esse tipo de ataque? Infelizmente n\u00e3o \u00e9 poss\u00edvel se proteger de maneira completa em rela\u00e7\u00e3o a esse risco, caso um grupo gigante de invasores desiste rodar scripts ao redor do mundo para atacar um software, n\u00e3o existe infra-estrutura no mundo capaz de resistir. Mas existem recursos que amenizam esse problema: monitorar o tr\u00e1fego dos Web Services, gerando alertas capazes de identificar comportamentos maliciosos \u00e9 imprescind\u00edvel. Em determinadas situa\u00e7\u00f5es tamb\u00e9m \u00e9 importante limitar o uso das APIs por meio de controles de rate limiting.<\/p><\/div>\n
<\/p>\n
\u00c9 extremamente importante ter um gerenciamento de logs muito bem definido e implementado. Todas as requisi\u00e7\u00f5es e respostas de um REST Web API devem ser registrados por completo. O que aconteceria se em um Web Service respons\u00e1vel por fazer a venda de produtos de uma loja virtual, uma venda for contabilizada para um usu\u00e1rio e ele alegar que n\u00e3o foi feito compra alguma? Nesses momentos ser\u00e1 extremamente importante ter logs das requisi\u00e7\u00f5es registradas.<\/p>\n
Vale a aten\u00e7\u00e3o referente ao tamanho de arquivos de logs, que tendem a crescer muito. Importante que os registros sejam f\u00e1ceis de registrar e consultar, para que seja poss\u00edvel ter uma resposta \u00e1gil no caso de algum incidente.<\/p>\n
Novamente um risco que \u00e9 mais recorrente em APIs disponibilizadas na internet. Alguns ataques de inje\u00e7\u00e3o de SQL ou JSON podem causar problemas graves. Para evitar esses problemas \u00e9 muito importante que sua API exponha apenas recursos realmente necess\u00e1rios para seus clientes. A tecnologia utilizada para desenvolver a aplica\u00e7\u00e3o, o servidor utilizado e a forma de persist\u00eancia s\u00e3o os principais pontos a serem ocultos, ou at\u00e9 mesmo omitidos.<\/p>\n
Existem v\u00e1rias abordagens que modificam os cabe\u00e7alhos das requisi\u00e7\u00f5es HTTP omitindo as tecnologias utilizadas, dificultando muito a a\u00e7\u00e3o de invasores. Tamb\u00e9m \u00e9 imprescind\u00edvel fazer o uso de filtros de dados de entrada, para evitar SQL e JSON injections e filtrar exce\u00e7\u00f5es para n\u00e3o correr o risco de exposi\u00e7\u00e3o de tecnologias ou bugs.<\/p>\n
Um software pode ser chamado de escalon\u00e1vel quando funciona bem em variados cen\u00e1rios. Ou seja, seu sistema deve estar preparado tanto para rodar no provedor de hospedagem da sua cidade, com 5 acessos ao mesmo tempo, quanto distribu\u00eddo em centenas de servidores espalhados pelo mundo, capaz de ter milhares ou milh\u00f5es de acessos simult\u00e2neos.<\/p>\n
Arquiteturas de sistemas devem ser moldadas desde o \u00ednicio levando em considera\u00e7\u00e3o a necessidade de escalonamento e distribui\u00e7\u00e3o, mesmo tendo como proje\u00e7\u00e3o inicial poucos acessos. Ao menos que a ambi\u00e7\u00e3o relacionada ao software seja muito pequena, a forma de escalonamento e distribui\u00e7\u00e3o de um software deve ser pensada antes mesmo do seu desenvolvimento, porque se o n\u00famero de acessos aumentar, ser\u00e1 prefer\u00edvel ter constru\u00eddo uma aplica\u00e7\u00e3o escal\u00e1vel do que ter que ficar aumentando a mem\u00f3ria ou capacidade de processamento do servidor a cada usu\u00e1rio novo acessando o sistema.<\/p>\n
\u00c9 no cen\u00e1rio de APIs distribu\u00eddas em v\u00e1rios servidores que a complexidade na manuten\u00e7\u00e3o da forma adequada da seguran\u00e7a da informa\u00e7\u00e3o aparece. A partir do momento que um mesmo REST web service \u00e9 distribu\u00eddo em mais de um servidor, as informa\u00e7\u00f5es de um usu\u00e1rio autenticado n\u00e3o s\u00e3o armazenados em uma sess\u00e3o, por exemplo, pelo contr\u00e1rio, a autentica\u00e7\u00e3o deve acontecer em cada requisi\u00e7\u00e3o. Existem v\u00e1rios padr\u00f5es que resolvem esse problema, como HTTP Basic, Autentica\u00e7\u00e3o\/Autoriza\u00e7\u00e3o baseada em certificados, Token-Based Authorization e OAuth.<\/p>\n
Este documento apresentou os problemas recorrentes na autentica\u00e7\u00e3o e manuten\u00e7\u00e3o de um n\u00edvel adequado de seguran\u00e7a em REST Web APIs. Fica clara a diferen\u00e7a do n\u00edvel de criticidade e risco entre Web Services que s\u00e3o disponibilizados apenas em redes de empresas internas e APIs que s\u00e3o disponibilizadas para todos os usu\u00e1rios na internet. Em redes locais, requisitos que s\u00e3o extremamente cr\u00edticos em APIs p\u00fablicas, como disponibilidade e integridade, por exemplo, n\u00e3o necessitam de uma aten\u00e7\u00e3o t\u00e3o grande.<\/p>\n
\u00c9 sabido que se h\u00e1 a necessidade de disponibiliza\u00e7\u00e3o de servi\u00e7os na internet, \u00e9 extremamente aconselh\u00e1vel o uso de REST, e pode-se concluir que esses sistemas devem ser arquitetados visando a escalabilidade e, principalmente, conhecendo o n\u00edvel de criticidade e risco relacionado ao mesmo, pois s\u00f3 assim ser\u00e1 poss\u00edvel encontrar a solu\u00e7\u00e3o ideal para o n\u00edvel de seguran\u00e7a ideal.<\/p>\n
BACILI, Kleber. Os fundamentos da seguran\u00e7a de APIs. Dispon\u00edvel em: <http:\/\/awshub.com.br\/resources\/os-fundamentos-da-seguranca-de-apis\/<\/a>>. Acesso em: 18 out. 2016.<\/p>\n