É evidente que a segurança de aplicações e APIs se tornou mais especializada. As APIs não são mais apenas pontos de entrada baseados em identificador uniforme de recursos (URI) em uma aplicação. Elas cresceram e se tornaram uma entidade separada com suas próprias necessidades de segurança.
A maioria dessas necessidades está relacionada à natureza das interações da API. Ou seja, as APIs precisam ser autorizadas por transação. Nas aplicações, que geralmente implementam a autorização por sessão, isso é bem diferente.
A taxa de interação também é maior para APIs, assim como várias outras características que trazem desafios específicos para a proteção das APIs.
Aplicação | API | |
---|---|---|
Fluência no formato de mensagem | HTML, JSON, XML | ProtoBuf, JSON, GraphQL, binário, XML, formatos de dados |
Interações | Mudança estática e infrequente | Mudança dinâmica e frequente |
Dados | Estruturados, transacionais | Não são estruturados, contínuos e transacionais |
Usuário | Pessoa | Software, pessoa |
Agente do usuário | Navegadores, aplicações | Software, dispositivo, scripts, aplicações, navegadores |
Autenticação | Com base em sessão | Com base em transações (mais do tipo ZT) |
Fluência de protocolo | HTTP/S, QUIC | gRPC, WebSockets, HTTP/S, QUIC |
Uma comparação de aplicações e APIs ilustra as diferenças que causaram a divergência nas necessidades de segurança.
Dito isso, existem riscos de segurança comuns a aplicações e APIs que devem ser levados em consideração ao implementar soluções de segurança. Por exemplo, o Top 10 de segurança de APIs de 2023, atualizado recentemente, mostra de forma clara um subconjunto de riscos também inerente às aplicações:
Além desses riscos, ainda há um número substancial de ataques direcionados à disponibilidade. Ou seja, ataques DDoS que são comuns a aplicações e APIs, já que geralmente compartilham as mesmas dependências de TCP e HTTP, ambos sujeitos a diversos ataques voltados a interromper o acesso e a disponibilidade.
Uma forma de enfrentar os desafios de proteger aplicações, APIs e a infraestrutura que os suporta é implantar várias soluções. Defesa contra bots e fraudes, proteção contra DDoS, segurança de aplicações e segurança de APIs. Embora isso enfrente, sem dúvidas, os desafios de segurança, traz desafios operacionais e torna várias tarefas relacionadas à segurança, como gerenciamento de mudanças de políticas e reação a ameaças que afetam aplicações e APIs, mas complexas. A complexidade não é apenas inimiga da segurança, mas também da velocidade.
A velocidade de resposta a ameaças emergentes é um dos principais fatores que estimulam a adoção da Segurança como Serviço, segundo a nossa pesquisa anual. Cada solução que requer um patch, atualização ou implantação de uma nova política para mitigar uma ameaça emergente aumenta o tempo e a possibilidade de haver uma configuração incorreta ou erro. Assim, o tempo para mitigar a ameaça aumenta com a complexidade, principalmente se uma organização opera em vários ambientes (TI híbrida) e usa soluções de segurança por ambiente. Não estou fazendo as contas para determinar se isso é um crescimento linear ou exponencial porque, honestamente, qualquer coisa que aumente o tempo de resposta a uma ameaça iminente não é algo positivo.
É por isso que a melhor opção é combinar soluções, compartilhando o gerenciamento operacional e de segurança para funções voltadas a enfrentar ameaças. Assim, pode haver políticas de segurança específicas para lidar com esses protocolos e cargas exclusivas de aplicações e APIs.
Isso leva a uma estratégia integrada de segurança de aplicações e APIs, na qual funções comuns são compartilhadas com maior granularidade e especificidade aplicadas mais perto da aplicação ou API. Afinal, os bots são bots, e seu impacto na qualidade dos dados, no custo de entrega e no perfil de risco de aplicações e APIs é uma preocupação compartilhada. DDoS é DDoS. Operar o dobro de serviços para resolver o mesmo problema é ineficiente em todos os aspectos da métrica.
Uma estratégia integrada de segurança de aplicações e APIs faz sentido em termos operacional, financeiro e de arquitetura.