Não faltam estatísticas sobre a (in)segurança das APIs . Uma busca rápida na Internet lhe dará praticamente qualquer perspectiva sobre o tópico que você gosta. Basta dizer que (a) os ataques de API estão aumentando e (b) alguns desses ataques são bem-sucedidos.
Também é comum notar que as organizações têm dificuldade em encontrar todas as APIs ocultas em sua organização. Isso não ocorre apenas porque essas APIs estão espalhadas pelo núcleo, pela nuvem e pela borda. Isso ocorre porque, além da conhecida Open API Specification (OAS), não há “padrões” reais nos quais se basear para definir, e muito menos encontrar, APIs.
Isso não significa que precisamos deles. Afinal, tínhamos SOAP, WSDL e UDDI e, bem, enquanto as pessoas ainda os usam e confiam em XML como formato de dados, a maior parte do mundo migrou para REST, JSON, GraphQL e gRPC.
Mesmo que tivéssemos padrões, isso não mudaria o fato de que as APIs são difíceis de proteger.
Isso ocorre porque o termo API é abrangente. Por exemplo, a API OpenTelemetry é simplesmente uma maneira de dizer: “estamos disponibilizando os recursos do OpenTelemetry aos desenvolvedores”. Não é como se você tivesse uma política de segurança que pudesse cobrir “a” Open Telemetry API. Isso seria o ideal e tornaria as coisas muito mais fáceis. Mas não é isso que temos. O que temos são políticas de segurança que abrangem os pontos de extremidade da API OpenTelemetry.
Vamos investigar isso, certo?
Vamos usar a Open AI API para nosso exemplo porque todo mundo está entusiasmado com a IA generativa agora.
A primeira coisa que você perceberá é que, embora haja apenas “uma” API, há muitos endpoints. Quantos? Esse número muda sempre que novos recursos são introduzidos.
Aqui está uma (lista não exaustiva):
A IA generativa multimodal adiciona mídia (áudio e vídeo) à lista de tipos de conteúdo, mas adiciona novos pontos de extremidade para lidar com solicitações de processamento. Recursos adicionais, como o uso de Ferramentas, também podem expandir o número de endpoints. Cada avanço — cada nova capacidade que nos entusiasma — normalmente adiciona outro ponto final à API.
Você também notará o “v1” nesses pontos finais. Isso significa que quando a versão 2 for lançada, será necessário outro conjunto de políticas de segurança para cobrir esses endpoints, e algumas dessas políticas precisarão mudar com base no que foi alterado no endpoint real.
Isso também existe na pilha de TI, onde a automação é realizada por meio de APIs de dispositivos. O número de endpoints depende muito do seu ambiente. Quanto mais dispositivos você tiver sob gerenciamento, mais endpoints você precisará gerenciar e proteger. Ah, e não vamos esquecer que não há dois dispositivos que usem a mesma API. Quer dizer, isso seria loucura, não é? Quase como dois provedores de nuvem concordando em usar a mesma API. É provavelmente por isso que “complexidade” continua sendo o motivo mais citado para não automatizar uma variedade de tarefas operacionais. Muitas ferramentas e APIs dificultam a automação e ainda mais a proteção.
Mas a segurança da API deve abordar todos esses endpoints porque é por eles que os invasores entram. E cada ponto final requer um conjunto diferente de parâmetros que terminam na carga útil como JSON (ou XML ou GraphQL ou objetos ). É necessário haver limites sobre o que cada parâmetro pode conter: É alfanumérico? Personagens? Uma gama de valores? Quanto tempo pode durar? Quais caracteres não são permitidos? Todas essas informações são traduzidas em uma política que impõe a aparência do conteúdo e, ao fazer isso, impede que ataques ocorram.
Construir uma política apenas para a Open AI API levará algum tempo. E é apenas uma API. A maioria das organizações tem uma média de 442,8 APIs de acordo com nossa próxima pesquisa de 2024 , e esse número dispara para organizações muito grandes. Pense em quantos endpoints — e versões de endpoints — isso pode significar, e rapidamente ficará claro por que a segurança de API é tão difícil.
E por que os invasores são bem-sucedidos o suficiente para continuar atacando-os.