Compartilhe esta publicação
APIs não autorizadas são risco para dispositivos?
Não é novidade para ninguém que APIs facilitam muito a vida de desenvolvedores. Isso é aceitável e até estimulável. Afinal, desoneram custos e economizam tempo. Entretanto, o que pensar sobre APIs não autorizadas?
Aliás, que tipo de API é esse? Como ter certeza de que é seguro? De onde veio?
São perguntas importantes em tempos de cotidiano completamente pautado em tecnologia da informação. A vida cibernética atual produz facilidades sem as quais a maioria dos humanos certamente já não viveria.
Então, tão importantes quanto essas perguntas são as respostas. Vamos a elas? Antes, uma rápida resposta para o título deste artigo: sim, são riscos.
APIs não autorizadas, APIs zumbis, APIs de sombra…
Este artigo mencionou acima a eficácia das APIs para desenvolvedores. Entretanto, é conveniente lembrar que facilitam muito a vida de usuários, igualmente. Claro, não de forma direta.
Ao fazer a rotina dos desenvolvedores mais tranquila, eles têm mais tempo para melhorar a performance utilitária das ferramentas. Assim, estas - as ferramentas - entregam para o usuário uma assertividade maior e objetivos mais claros.
Ou seja, elas são valiosas, producentes e úteis também para o consumidor final. Contudo, isso não significa que o consumidor pode deixar as APIs invadirem seus dispositivos. Nesse cenário, precisa estar atento a alterações no desempenho de seus aparelhos.
O problema é que essas alterações podem ser tão sutis que nem são detectáveis. Afinal, as características que se mostram benéficas são as mesmas que podem deixar seu sistema vulnerável.
A Prensa já publicou artigo interessante sobre APIs zumbis. Veja aqui. E muitos outros sobre APIs em si: dicas, instruções, perigos etc. Quanto às APIs de sombra, há consenso no universo dos desenvolvedores que são o mesmo que “APIs não autorizadas”, descritas logo abaixo.
APIs não autorizadas: o perigo mora ao lado
Ou melhor, à frente. Melhor ainda: atrás da tela. Dizer que as APIs estão dominando as atividades de desenvolvedores é chover no molhado. A esta altura do campeonato, você já sabe disso; afinal, você tem acompanhado os muitos artigos aqui na Prensa sobre essa ferramenta.
O site Wallarm informou recentemente que quase 90% dos desenvolvedores inserem APIs em seus códigos. Em meio a tantas e tantas inseridas, não é exatamente fácil informar os usuários finais sobre a presença delas.
Não é fácil nem mesmo assertivo, pois o mercado como um todo pode ver esse fato como alertas de perigo. Bem, boa parte é perigo mesmo, justamente por elas não estarem autorizadas a compor um programa determinado.
Esse… diga-se… desleixo incorre em outro problema. Não havendo comunicado sobre a instalação de APIs não autorizadas, elas não são registradas. Assim, deixam de ser documentadas e, portanto, deixam também de ser gerenciadas.
Por que são inseridas
Organizações responsáveis fazem manutenção e gerenciamento de seus sistemas internos com certa constância. Essa preocupação se dá em especial em empresas que operam diretamente com dados de muitos clientes.
Seus bancos de dados precisam de inspeção regular. Assim, situações distintas acabam em oportunidades para que desenvolvedores economizem tempo e sua massa encefálica - mas nem sempre.
Melhorias - ou pretensas melhorias - em sistemas podem ocorrer a partir de rápidas alterações nos códigos dos programas. Sendo rápidas, são aparentemente inconsequentes. Assim, o desenvolvedor - geralmente externo - cria uma API e a implanta remotamente. Nesse cenário, nem sempre se dá ao trabalho de comunicar o proprietário do sistema
Correção de pequenos trechos que poderiam causar algum “bug” sem danos maiores. Assim, o desenvolvedor cria uma APIs simples para desabilitar o trecho. Igualmente, não comunica o proprietário
Oportunismo por parte de desenvolvedores. Ao precisar testar determinada reação, cria APIs que, com toda certeza, não causam dano algum. Bem, nem sempre esse “com toda certeza” é seguro
De qualquer maneira, criar APIs não autorizadas e brincar com sorte depois é mais … diga-se… aventureiro para o espírito de alguns desenvolvedores.
O problema para o usuário final - que pode ser uma empresa - é que os protocolos de segurança talvez não alcancem as APIs não autorizadas. Afinal, é difícil promover segurança para algo que não se conhece.
O que elas podem fazer
APIs não autorizadas não são criadas com fins exclusivos de oferecer perigo. Por outro lado, fica uma pergunta: por que não ofereceriam perigo se são classificadas por “não autorizadas”?
Ou seja, não estando no código sob conhecimento dos proprietários, certamente os fins não são muito bons. Elas podem causar efeitos simples apenas para alimentar o orgulho de hackers. Nesse caso, dos males, o menor.
Hackers criadores de APIs não autorizadas buscam dados confidenciais dos clientes das empresas
A empresa proprietária pode ter descontinuado determinada atividade para clientes - como acesso a histórico - e elas fazem retornar à condição anterior
Fraudes financeiras são geralmente causadas por APIs não autorizadas
Podem atacar determinada plataforma com sufoco de acessos ao mesmo tempo para estrangular atividades, como no caso de matrículas em provas oficiais ou em instituições de ensino
Em ação menos danosa, podem aumentar consideravelmente o tempo de resposta das solicitações de clientes
O que as empresas podem fazer
Como dito acima, é difícil identificar APIs não autorizadas. Isso também é difícil em relação às APIs zumbis. Difícil, mas não impossível, evidentemente, porque nada é impossível em TI.
Por outro lado, há aplicativos específicos que identificam e anulam APIs não autorizadas. Eles funcionam como auxiliares da equipe de segurança digital. Dessa maneira, os responsáveis pela segurança podem proteger mais adequadamente as APIs já instaladas e criar ambiente propício para defesas futuras.
Entretanto, algumas iniciativas são importantes para a estratégia de busca e anulação de APIs não autorizadas. Veja algumas.
Preocupação
Essa é a palavra de ordem quando o alvo são APIs não autorizadas. Assim, a equipe de segurança digital permanece alerta o tempo todo. É a melhor maneira de se precaver.
Muitas empresas destinam parte de sua equipe de TI a cursos específicos de desenvolvimento de APIs. Assim, adquirem conhecimento para criar estratégias de combate e vigilância.
Análise de log
Por falar em vigilância, análise e registro constantes de atividades em tempo real é outra forma de proteção. A partir disso, os desenvolvedores internos inspecionam in loco e em tempo adequado as solicitações feitas à API e avaliam os efeitos do uso dos aplicativos.
Essa operação geralmente se mostra estressante e dispendiosa. Contudo, como se diz, o seguro morreu de velho.
Padronização
Equipes de várias empresas com operações em TI adotam a padronização como estratégia. Ou seja, constroem seus próprios blocos de maneira similar. Não exatamente com os mesmos comandos, já que isso é impossível, visto que há objetivos diversos.
Porém, produzem trechos semelhantes, com comandos similares. Nesse cenário, é possível associar tais trechos a assinaturas estruturais, uma espécie de impressão digital.
Dessa maneira, pensam ser mais fácil identificar APIs não autorizadas. Afinal, é quase certo que desenvolvedores mal intencionados não terão conhecimento do processo de padronização.
Inventário de APIs
A iniciativa de levantar as APIs próprias e gerar históricos de criação para as novas é, também, boa saída. Assim, eventual análise de APIs de propriedade da empresa se torna trabalho menos oneroso em termos de tempo e custo.
Além disso, essa ação pode evitar conflitos diversos, não associados diretamente às APIs, o que seria vantagem adicional. Entretanto, a reunião de dados documentais (objetivo, estrutura, efeitos etc.) acaba se mostrando altamente eficiente no combate às inserções de APIs não autorizadas.
O maior dos problemas
APIs não autorizadas são geralmente produzidas por hackers que têm tempo. E inteligência.
Claro, isso não significa que membros das equipes de desenvolvedores das empresas não sejam inteligentes. Porém, podem não ter foco. Afinal, os colaboradores têm muitas outras funções internas, além da de "babá de APIs".
Já os hackers são focados na produção de APIs e softwares maliciosos. Nesse horizonte, têm vantagens e mais vantagens e são apoiados justamente pela evolução das linguagens. Com isso, muitos criminosos conseguem criar as APIs não autorizadas atuais “móveis”, “ambulantes”.
Isso se torna o maior dos problemas dos especialistas em segurança cibernética das empresas. O conceito de “móvel”, no caso, está mais associado à facilidade de manuseio remoto. As APIs são criadas, inseridas, alteradas, reinseridas em tempo mínimo e à distância máxima.
Com isso, tão logo as equipes de segurança descobrem APIs não autorizadas ou zumbis, os criminosos alteram os códigos rapidamente. Até mesmo a ação da descoberta é monitorada constantemente, o que dificulta ainda mais o trabalho de desenvolvedores sérios.
A vida de desenvolvedores não está fácil.
Este artigo foi escrito por Serg Smigg e publicado originalmente em Prensa.li.