Há mais de 20 anos, Jeff Bezos declarou que todas as equipes da Amazon precisariam "expor seus dados e suas funcionalidades por meio de interfaces de serviço" — sem exceções. O memorando, atualmente conhecido como o "mandato das APIs", afirmava, essencialmente, que as interfaces de programação de aplicativos (APIs) não eram opcionais, o que ajudou a desencadear uma corrida entre os desenvolvedores em todos os lugares para conectar tudo por meio de APIs. A questão é que, para muitas organizações, a segurança das APIs acabou ficando defasada em relação ao ritmo acelerado da implementação das APIs.
O tráfego relacionado a APIs agora compreende a maioria (cerca de 57%) de todo o tráfego dinâmico da internet, de acordo com o recente Relatório de Gerenciamento e Segurança de APIs 2024. Porém, as empresas costumam ter dificuldades para superar desafios como:
Superfícies de ataque invisíveis e desprotegidas: a TI e a segurança não podem defender o que não conseguem ver, e as organizações têm "APIs sombra" — APIs que suas equipes de TI ou de segurança não estão gerenciando —, o que acarreta a exposição de dados, o movimento lateral e outros riscos cibernéticos.
Autorizações excessivamente permissivas: em mãos erradas, o acesso de "gravação" às APIs, originalmente destinadas a ser somente leitura, deixa os sistemas vulneráveis aos ataques e a uma possível perda de dados. Ainda assim, quase 60% das organizações permitem um acesso de "gravação" a pelo menos metade de suas APIs.
As organizações podem tranquilamente ignorar e classificar erroneamente as causas de erros relacionados a APIs: nem todos os erros de APIs são causados por ataques e nem todos os ataques às APIs podem ser mitigados da mesma forma. Uma vulnerabilidade ou erro não detectados ou mal diagnosticados pode resultar em uma experiência negativa do usuário final ou, pior ainda, em um ataque cibernético.
Estima-se que existam, atualmente, cerca de 200 milhões de APIs públicas e privadas em uso, e esse número está aumentando. Para capitalizar com segurança o poder dessas APIs — e também das APIs futuras —, as organizações precisam de uma abordagem de gerenciamento projetada especificamente para APIs que incorpore a lista a seguir de três coisas que devem e não devem ser feitas.
Digamos que o Hospital da Acme ofereça iniciativas digitais que seus pacientes e profissionais adoram: tudo, desde telessaúde móvel integrada até um processamento de prontuários assistido por IA. Certo dia, um dos desenvolvedores da Acme permitiu o acesso de "gravação" à API de um sistema de faturamento sem a documentação adequada. Alguns meses depois, o fornecedor foi invadido e em seguida, por meio de um movimento lateral, os invasores conseguiram explorar a API pública da Acme para violar os prontuários de pacientes do hospital.
A Acme poderia ter detectado e mitigado essa situação mais cedo se tivesse uma maneira de fazê-lo automaticamente:
Descubra todos os endpoints de APIs públicas (incluindo APIs não autenticadas) e o tráfego relacionado a eles
Detecte esquemas de API (os metadados que definem as especificações de uma chamada/resposta de API válidas)
Detecte variações de ataque nas APIs
Entram em cena as soluções de segurança de API que utilizam modelos de aprendizado de máquina e não requerem comunicações manuais "pontuais" entre a TI, a segurança e os desenvolvedores.
Por exemplo, uma descoberta de APIs e uma detecção de esquemas de API alimentados por aprendizado de máquina podem fornecer a organizações como a Acme um inventário mais completo de suas APIs: Quais são essas APIs? Quais dados e sistemas elas acessam? Quando e onde estão sendo acessadas? A quem foi concedida uma permissão "somente leitura" ou de "gravação"?
Esse tipo de dados é crucial para evitar a proliferação de APIs sombra. Durante o processo de desenvolvimento de novas funcionalidades para o cliente (que costumam ser expostas primeiro como APIs voltadas para a internet), as "boas práticas" de documentação e segurança de APIs são geralmente deixadas por conta de cada desenvolvedor. Muitas vezes, não há tempo nem recursos suficientes para incluir as equipes de segurança.
Eis por que os desafios de segurança aparecem: as organizações não podem proteger o que não conseguem ver. Na verdade, os modelos de aprendizado de máquina da Cloudflare revelaram 31% endpoints de API a mais do que as organizações relataram espontaneamente, sugerindo que quase um terço das APIs são essencialmente APIs sombra.
As APIs ocultas, muitas vezes introduzidas de forma benigna durante as frequentes alterações de código, não são inerentemente maliciosas. Porém, se levarmos em conta que 86% dos desenvolvedores não consideram a segurança do aplicativo uma prioridade máxima, as APIs ocultas são uma ameaça importante. Se forem exploradas, poderão acarretar a exposição de dados, vulnerabilidades não corrigidas, violações de conformidade de dados e outros riscos. O aprendizado de máquina ajuda a tirar essas APIs ocultas da escuridão.
Aplicativos web e APIs são fundamentalmente diferentes. Um aplicativo de transporte de passageiros é "visível" para seus usuários, mas a API que dá acesso aos dados do Google Maps para o aplicativo é "invisível". Devido a essas (e outras) diferenças, as organizações precisam de uma segurança projetada especialmente para APIs para proteger as APIs — não basta uma segurança de aplicativos web.
Por exemplo, um firewall de aplicativos web (WAF) tradicional filtra e monitora o tráfego HTTP entre um aplicativo web e a internet com base em uma lista de bloqueios. O WAF procura sinais conhecidos de um ataque e, em seguida, toma providências para impedir esses ataques. Todos os demais tráfegos são permitidos — um modelo de segurança "negativo", que pode ser eficaz para a segurança de aplicativos web sempre que for mais fácil identificar e bloquear o tráfego web mal-intencionado.
No entanto, proteger as APIs contra abusos — a segurança de APIs — requer uma segurança "positiva". Em vez de se limitar a procurar as solicitações "sabidamente ruins", procure as "sabidamente boas" e deixe que apenas estas sejam recebidas: todo o resto deve ser bloqueado. (Saiba mais sobre o que define essas solicitações — ou seja, chamadas de API — clicando aqui).
Por quê?
Considere o exemplo de um provedor de telecomunicações australiano que sofreu uma violação que expôs os dados de quase 10 milhões de clientes: o invasor tinha acessado um determinado banco de dados de clientes por meio de uma API não autenticada. Embora os detalhes completos do ataque sejam desconhecidos do público, vale observar que um modelo de segurança de APIs "positivo" teria permitido apenas o tráfego de APIs que estivesse em conformidade com as especificações de APIs da empresa.
Em outras palavras, adote uma segurança "positiva" de APIs e permita apenas o tráfego de usuários autenticados, provenientes de redes corporativas autenticadas e executando ações autorizadas. As organizações também podem combinar modelos de segurança, como, por exemplo, sobrepondo a segurança "negativa" de um WAF e a segurança "positiva" de um gateway de API.
A conclusão é que as APIs requerem uma abordagem abrangente para se defender contra uma ampla gama de ameaças às APIs, entre elas as 6 principais ameaças às APIs a seguir:
Fonte: Relatório de Gerenciamento e Segurança de APIs 2024
Conforme identificado no gráfico acima, as anomalias de HTTP representaram a maioria (60,7%) das ameaças a APIs que foram mitigadas. As anomalias de HTTP (como a ausência de agentes de usuário — o software que recupera o conteúdo da internet para os usuários finais — e outras) são sinais comuns de solicitações mal-intencionadas.
Ao aplicar a segurança "positiva" (conforme descrevemos anteriormente), as organizações podem identificar as anomalias de HTTP e outras ameaças de modo a permitir aos seus servidores de API apenas o tráfego "limpo" para cada API.
As equipes de TI e segurança compartilham com os desenvolvedores de aplicativos a responsabilidade de proteger a gigantesca superfície de ataque decorrente da existência de milhares de ativos com suporte de APIs. Ainda assim, as prioridades dessas equipes costumam ser conflitantes:
73% dos desenvolvedores dizem que o trabalho ou as ferramentas cujo uso é requerido por sua equipe de Segurança “interferem em sua produtividade e inovação”.
87% dos diretores de Informática acreditam que os engenheiros e desenvolvedores de software “abrem mão das políticas e controles de segurança para lançar novos produtos e serviços no mercado mais depressa”.
Apenas metade dos diretores de Informática acreditam que os desenvolvedores estão "muito familiarizados" com os riscos de segurança das ferramentas de desenvolvimento e fluxos de trabalho.
Como resultado, as organizações poderão decidir abrir mão de aprimorar sua segurança para inovar mais rapidamente, deixando suas APIs vulneráveis. De acordo com o relatório, quase 60% das organizações permitem o acesso de "gravação" a pelo menos metade de suas APIs, mas quem, em última instância, é responsável por garantir que o acesso de "gravação" não seja concedido ao usuário errado?
Para uma empresa que está sempre expondo novos serviços por meio de APIs, uma nuvem de conectividade pode funcionar como um tecido conjuntivo entre a implantação do aplicativo e a defesa profunda de APIs.
Uma nuvem de conectividade é uma plataforma unificada de serviços nativos de nuvem que simplifica a conectividade “any-to-any” segura em ambientes de TI. Isso, por sua vez, ajuda as organizações a recuperar o controle e a visibilidade de seus domínios digitais em rápido crescimento — incluindo seu tráfego de APIs.
Com uma nuvem de conectividade, as organizações podem dar conta das tarefas a seguir (e outras) usando um único plano de controle:
Automatizar a descoberta e a visibilidade de APIs para fornecer a todas as partes interessadas um inventário claro de seu patrimônio de APIs
Modernizar os processos de autenticação e autorização de APIs desde o início
Gerenciar os endpoints de APIs para monitorar métricas como latência, erros e taxas de erros, além do tamanho da resposta para domínios orientados por APIs.
Proteger-se contra ameaças à camada 7 das APIs, como ataques de DDoS, tentativas de login por força bruta e outros abusos de APIs
A tecnologia de APIs não é nova, mas, ainda assim, a abordagem holística da segurança de APIs é novidade para muitas equipes de segurança e desenvolvimento de aplicativos. No entanto, todo progresso começa em algum lugar, e a segurança de APIs pode ser resolvida em fases:
Visibilidade (Fase 1): comece identificando todas as APIs usadas na sua organização. Use ferramentas de descoberta de APIs, leia a documentação técnica e os contratos, converse com seus desenvolvedores e monitore seu tráfego na internet.
Proteção geral contra ataques da web (Fase 2): os aplicativos web e as APIs costumam trabalham juntos (por exemplo, um site de comércio eletrônico que usa uma API para processar pagamentos). Use e integre as ferramentas projetadas especificamente para proteger aplicativos web (e, até certo ponto, as APIs por trás deles) contra ataques de DoS e DDoS, preenchimento de credenciais, vulnerabilidades de dia zero e outras ameaças.
Segurança avançada de APIs consolidada (Fase 3): o portfólio de Proteção de Aplicativos Web e APIs (WAAP) da Cloudflare, alimentado por uma nuvem de conectividade, fornece uma segurança e desempenho holísticos em torno de APIs voltadas para o público sem inibir a produtividade. Com a descoberta de APIs, o gerenciamento e análise de APIs integrados e as defesas em camadas, a Cloudflare capacita as equipes de TI e segurança a obter visibilidade e controle sobre suas APIs.
Este artigo é parte de uma série sobre as tendências e os assuntos mais recentes que influenciam os tomadores de decisões de tecnologia hoje em dia.
Receba o Relatório de Gerenciamento e Segurança de APIs 2024 para explorar as vulnerabilidades de APIs mais comuns, as previsões do setor e recomendações mais detalhadas para a proteção de APIs.
Após ler este artigo, você entenderá:
3 desafios comuns relacionados a APIs
O que fazer e o que não fazer em um gerenciamento projetado especificamente para APIs
Como aumentar a maturidade da segurança de APIs ao longo do tempo