Explicação de como expandir a segurança da API do modelo de defesa em profundidade para o modelo de confiança zero   “A pandemia colocou imensa urgência nas empresas para que todos os tipos de projetos de transformação digital fossem executados o mais rápido possível, e esse é quase certamente um fator determinante por trás desse aumento nos ataques”, disse.   —   , Diretor de Tecnologia da   . Peter Klimek Imperva  As APIs DYKT são usadas há mais de 20 anos. Desde então, as APIs evoluíram drasticamente — de um conjunto limitado de empresas que usam APIs para atender a necessidades específicas para, recentemente, uma coleção infinita de casos de uso em ambientes DevOps de todos os tamanhos. As APIs podem ser encontradas em desenvolvimentos de aplicativos — desenvolvimento ágil, conectando clientes e parceiros com serviços e impulsionando iniciativas de transformação digital.  Mas em relação à segurança cibernética, de acordo com a pesquisa da   ,   . No entanto, com uma adoção mais ampla, as APIs expõem dados mais confidenciais hoje do que nunca, tornando-as um alvo valioso para ataques. ProgrammableWeb uma média de 220 novas APIs foram adicionadas todos os meses desde 2019  Este post é uma introdução sobre como mapear os requisitos de API Security, desde Defense-in-Depth até Zero Trust Model.  Histórico - O estado da segurança da API  Antes de entrar em como proteger a API, vamos examinar o cenário atual de ameaças da API Security. De acordo com o  relatório State of API Security da Salt Security:  Ataques de API aumentaram 681% nos últimos 12 meses  95% dos entrevistados tiveram um incidente de segurança de API no último ano  34% dos entrevistados não possuem nenhuma estratégia de segurança de API  62% dos entrevistados reconheceram a desaceleração do lançamento de um novo aplicativo devido a preocupações com a segurança da API  Resumindo, podemos dizer que a maioria das empresas não está preparada para um ataque baseado em API. Além disso, a confiança na segurança existente e nas ferramentas de gerenciamento de API, por exemplo, firewalls de aplicativos da Web (WAFs) e gateways de API, poderia ter evitado efetivamente incidentes de segurança e fornecido uma falsa sensação de segurança.  E quanto a Shift-Esquerda?  O relatório destaca que as táticas shift-left não estão ajudando, pelo menos na segurança da API. Mais de 50% dos entrevistados disseram que as equipes de desenvolvedores, DevOps ou DevSecOps são responsáveis pela segurança da API. As empresas que gastam mais em esforços de pré-implantação incluem:  práticas recomendadas de codificação segura,  escaneamento de código e  teste manual  No entanto,   - provando que essas práticas de segurança DevOps, embora importantes, não são suficientes. 85% reconheceram que suas ferramentas de segurança são ineficazes na prevenção de ataques de API  Então, qual proteção uma organização deve criar ou adotar para se defender contra ataques de API? Para responder a essa pergunta, primeiro precisamos entender os ataques comuns contra a API.  O atual cenário de ameaças  No relatório recente sobre   , as fontes de ameaças de segurança de API são: segurança de API do Google Cloud  APIs mal configuradas (40%),  APIs, dados e componentes desatualizados (35%),  Spam, abuso, bots (34%).  “APIs mal configuradas” ou “configurações incorretas de segurança”, como uma categoria, são a fonte de ameaça mais identificada.  De acordo com outro estudo do   ,   que saltou 271%. Os hackers usam ataques RCE ou RFI para roubar informações da empresa, comprometer servidores e desfigurar sites ou até mesmo assumir o controle dos sites. Imperva Research Labs o ataque mais significativo é o Remote Code Execution (RCE) ou Remote File Inclusion (RFI),  Outras vulnerabilidades de API são, de acordo com  o top 10 da OWASP API Security:  API DDOS fan-out,  ataques de API de dia zero,  credenciais roubadas,  violações de perímetro,  movimentação lateral de brechas,  vazamento de dados na saída, ou  sequestro de recursos  Cibersegurança: a API é o novo endpoint  Conforme mencionado acima, a primeira razão para o aumento do risco de segurança das APIs   - muitas APIs em um ambiente. Por exemplo, um aplicativo Kubernetes tem centenas de pods e microsserviços. Cada um deles está gerenciando meia dúzia ou mais APIs. (Esse é um cenário típico em um ambiente DevOps). é a explosão da adoção  Agora, acrescente que essas cargas de trabalho de microsserviços (e, portanto, as chamadas de API) são temporárias, executadas em nuvens, escritas em vários idiomas e usam protocolos diferentes. Ou, resumindo, as APIs criam um ambiente complexo e desafiador para a equipe de segurança supervisionar a operação da API.  Em segundo lugar, as APIs nunca foram feitas para serem expostas ao mundo exterior. No entanto, foi isso que enfrentamos com as vulnerabilidades encontradas nas pilhas de protocolos de rede. Esses desenvolvedores nunca imaginariam que suas obras seriam adotadas na escala atual. Como resultado, as APIs têm vulnerabilidades e riscos inatos incorporados a elas.  Em terceiro lugar, os ataques e violações têm se tornado cada vez mais sofisticados, especialmente aqueles executados na fase de pós-autenticação e autorização. Eles também são mais profundos na carga útil de dados da API.  Portanto, há uma necessidade de olhar para a segurança além da autenticação e autorização, também da aplicação e da camada de carga de dados da API. Uma maneira de fazer isso é  pensar na API Security como análoga à nossa tradicional segurança de endpoint.  DiD (defesa em profundidade), de novo!  Problemas de segurança também acontecem em nossa vida diária fora dos computadores. Desde os primórdios da história da humanidade, vários países vêm explorando e praticando múltiplos mecanismos de defesa e fortificações. Essas experiências e ideias também se aplicam à segurança de terminais, redes e APIs.  Digamos que o Endpoint Software seja análogo ao castelo:  A autenticação de identidade é igual à prova de identificação dos comandantes, e  Honeypots (ou iscas em guerra) atraem atacantes para longe de alvos de alto perfil.  Dentre essas estratégias de guerra, uma das formas mais eficazes é a Defesa em Profundidade (DiD).  A abordagem DiD pode ser dividida em duas áreas:  Defesa de limite (assinaturas antimalware)  Detecção/ Prevenção de Intrusão (IDS/ IPS/ EDR)  Explicarei a segurança da API com essas áreas DiD uma a uma.  1# Defesa de Limite  A defesa de limite é o tipo mais básico de defesa. Quase todas as empresas investem em defesas de fronteiras. Na segurança de endpoint, usamos assinaturas e listas de negação de IP para  nos defender contra métodos de ataque conhecidos.  Como linha de frente de proteção, essa camada visa impedir 90% de todos os ataques, não direcionados e iniciados por indivíduos não qualificados que não possuem conhecimento técnico sólido ou mentalidade de hacker. Nesse cenário,  a defesa de limite pode resistir bem a esses ataques indiscriminados.  Em API Security, o WAF está fazendo um excelente trabalho nessa área. Ele oferece recursos padrão para defesa de limite:  · Listas de permissão e negação de IP,  · Motor de regras WAF,  · Limitação de taxa, e  · injeção de falhas/fuzzing.  Quando combinado, pode bloquear quase todos os ataques de commodities.  2# Detecção de Intrusão (++)  A visibilidade da segurança é um elemento crítico da prevenção de ataques. Depois que um hacker violou o perímetro, precisamos de uma maneira adequada de identificar qual arquivo/processo/tráfego provavelmente está relacionado ao ataque mal-intencionado. No Endpoint Software, temos   para inspecionar todas as solicitações que passam pelo portão frontal. IDS/IPS baseado em host  Alguns outros métodos de detecção, como  detecção de APT e aprendizado de máquina, podem ser mais intuitivos para avaliar contra ataques direcionados.  Outras formas típicas de implementar a análise do comportamento são:  · Honeypots,  · EDR (Endpoint Detection and Response), e  · Inteligência de ameaças (arquivo e processo).  Entre todos esses métodos, os honeypots são um dos mais antigos (desde o início das guerras). Ao atrair alguns alvos de alto valor para armadilhas/chamarizes, eles podem analisar o comportamento do inimigo e até mesmo ajudar a localizá-los. Hoje em dia, adotamos essas táticas e as transformamos em técnicas de engano.  No mundo moderno, as soluções de segurança de API fornecem combinações das técnicas mencionadas; por exemplo, os artefatos coletados em honeypots podem ser enviados para o feed de inteligência de ameaças para WAF ou consumo de aplicativos da Web e proteção de API (WAAP). Nesta camada, temos técnicas semelhantes para aumentar a visibilidade e a velocidade para parar um ataque:  · Honeypots de rede  · NDR (detecção e resposta de rede) e  · Inteligência de ameaças (carga útil e rede).  Usar bots para executar ataques de "enchimento de credenciais" é outra tática de ataque comum. Ele tenta roubar ativos de alto valor. A estratégia é encontrar uma maneira de obter informações de login, como e-mails/senhas vazados, e depois tentar acessar as localizações da rede em lotes (movimento lateral). De longe, a defesa mais eficiente para combater o preenchimento de credenciais vem da fonte: identifique o bot de usuários reais para interceptar todas as solicitações feitas pelo bot.  Assim, algumas ferramentas AppSec também fornecem recursos anti-bots, um tipo específico de detecção de comportamento como parte da segurança da API.  Quando a segurança da API atende a zero confiança  Não estou dizendo que o DiD é inútil. Soluções de segurança de API e aplicativos, como proteção WAF para organizações contra ataques de commodities. No entanto, conforme mencionado, a API cria um ambiente complexo e a configuração incorreta piora o problema.  Com um perímetro não esclarecido, pode ser necessário mais do que uma abordagem DiD. O Zero Trust essencialmente coloca obstáculos em todos os lugares para os invasores, impossibilitando que eles se movam lateralmente dentro do ambiente.  A confiança zero é uma estrutura e estratégia de segurança abrangentes. Requer etapas de verificação rígidas e unificadas para todos os terminais, BYODs (Bring Your Own Devices), servidores, APIs, microsserviços, armazenamento de dados e serviços internos.  A ideia principal do Zero Trust é   , incluindo APIs. Seja uma solicitação externa de acesso interno, um telefone celular ou um PC, uma chamada API ou solicitação HTTP, um funcionário comum ou um CEO, ninguém é confiável. transformar o ponto de aplicação centralizado em vários micro pontos de verificação em todos os caminhos de seus aplicativos  Para atingir efetivamente tal objetivo sem parar ou desacelerar seus aplicativos,   seriam as etapas determinantes críticas. a orquestração e a automação  Por que a orquestração e a automação são cruciais para a segurança da API Zero Trust?  ZTA, NIST SP800–207 | imagem do autor  Para explicar a necessidade dos dois, vamos dar uma olhada mais de perto em um pilar da Zero Trust Architecture —   . Esse método de defesa é semelhante a mostrar seu passaporte no posto de controle do aeroporto e suas carteiras de identidade para comprar álcool. confiança de acesso do usuário/dispositivo  Sem a identidade e autoridade correspondentes, é impossível entrar no sistema relacionado. É aqui que um API Gateway entra em ação, pois fornece alguns recursos importantes de autenticação:  Rotação automática de chaves  Integração com vários sistemas de autenticação, como OKTA e Auth 2.0  Suporta criptografia TLS e mTLS de tráfego  Existem dois componentes principais da confiança do usuário e do dispositivo:  Gerenciamento de identidade e acesso  API Gateway com segurança integrada    , como aeroportos e ferrovias de alta velocidade. Você também deve entender todas as rotas de e para todos os centros de transporte e implementar salvaguardas. Imagine adicionar equipamentos de identificação em todos os centros de transporte  Em uma grande empresa, haverá centenas de sistemas, dezenas de milhares de APIs e microsserviços e centenas de milhares de clientes. A menos que tenhamos recursos e tempo ilimitados, a equipe de DevOps, Segurança ou Aplicativo não pode definir e adicionar manualmente centenas de milhares de verificações de microidentificação em aplicativos modernos.  Todos os outros pilares da Zero Trust   também requerem a mesma lógica para adoção. A necessidade é de uma solução que: Architecture, Application, Workload e Data  Utiliza arquitetura moderna,  Trabalha em ambientes heterogêneos,  Mitiga esses riscos (não apenas as commodities) e  Faz tudo isso de maneira automatizada em ambientes multinuvem  (opcional) de código aberto, de forma a permitir agilidade tecnológica e criatividade.  Como é a segurança da API Idea Zero Trust?  Para adotar os ambientes complexos e heterogêneos na API, a solução Zero Trust API Security   , por exemplo: deve poder ser implantada em vários formatos e, assim, suportar diferentes configurações  Contêiner Docker,  Um proxy reverso autônomo,  Agente para web/servidor de aplicativos ou  Incorporado no Kubernetes Ingress Controller.  Com o suporte da nuvem e da arquitetura moderna de aplicativos, a automação e a escalabilidade seriam atendidas.  Mas, para manter a orquestração, o “agente” (ou ponto de microaplicação) deve poder ser implantado   , garantindo latência mínima e controle máximo. sobre um aplicativo existente sem alterar a arquitetura existente  Depois de considerar os fatores de forma de implantação e arquitetura, também é essencial que o nível de segurança não seja degradado. Para ser genuinamente adotado Zero Trust,   sem transmitir para outras nuvens ou engines, como um sandbox de nuvem para análise. o processamento de segurança deve ser feito localmente  Se as partes externas não estiverem sob nosso controle, será difícil verificar a confiança no acesso aos dados/rede. Existem alguns outros benefícios de fazer isso localmente, como:  Os dados confidenciais não saem do ambiente protegido.  Você não precisa compartilhar certificados e chaves privadas com terceiros.  Nenhuma dependência de tempo de atividade de terceiros para processamento de tráfego.    Idealmente, precisamos de uma solução que possa ser inserida no ambiente do aplicativo enquanto um orquestrador pode gerenciar esses agentes e cuidar das seguintes operações: A última parte é considerar a orquestração.  registro/cancelamento de agentes  atualização de política  atualização de configuração  atualização de software  registro e  Sincronização de dados.  Resumindo, o Zero Trusted API Security deve estar em várias formas para infundir em ambientes de aplicativos modernos. Enquanto isso, a melhor solução deve ser capaz de fornecer orquestração e todas as funções de segurança que as soluções tradicionais podem fornecer.  Então, como você sabe, a confiança zero não é perfeita. As soluções de confiança zero não podem se defender totalmente contra ataques de dia zero ou de engenharia social, embora possam reduzir significativamente a superfície e o impacto do ataque.  Para saber mais sobre a Zero Trust Architecture:   . Introdução à Zero Trust Security Architecture — um conceito, não um produto  Palavras Finais  As APIs se tornaram o sistema nervoso central dos aplicativos modernos, trazendo informações e dados críticos de uma parte do aplicativo para outra ou de um aplicativo para outro. Como resultado, a segurança da API deve ser a prioridade ao proteger os aplicativos. Isso é particularmente verdadeiro para APIs públicas, com usuários em todo o mundo acessando componentes de software e dados confidenciais.  A adoção do Zero Trust Framework muda o foco de uma única proteção para diferentes pilares (Usuários, Dispositivos, Redes, Aplicativos e Dados). Isso pode ajudá-lo a garantir que cada parte do acesso à API, seja dentro ou fora do perímetro, esteja sob a abordagem de privilégios mínimos e monitorada continuamente.  Obrigado por ler. Que a InfoSec esteja com você🖖.

This story contains new, firsthand information uncovered by the writer.

Interested in Infosec & Biohacking. Security Architect by profession. Love reading and running.

Como usar o Zero Trust Framework para segurança de API?

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps