As empresas permanecem vulneráveis ​​por meio de segredos de API comprometidos

Views: 159
0 0
Read Time:4 Minute, 41 Second

Os profissionais de segurança cibernética estão frustrados com a quantidade de tempo e atenção que devem dedicar à segurança da API e preocupados com o fato de suas defesas ainda precisarem ser aprimoradas, de acordo com Corsha.

Os pesquisadores entrevistaram recentemente mais de 400 profissionais de segurança e engenharia para aprender sobre suas práticas de gerenciamento de segredos de API e os desafios que enfrentam para impedir ataques de API. Entre os principais destaques:

  • 86% dos entrevistados gastam até 15 horas por semana provisionando, gerenciando e lidando com segredos.
  • 53% já sofreram uma violação de dados com acesso não autorizado a suas redes ou aplicativos devido a tokens de API comprometidos.
  • 72% usam uma solução de gerenciamento de segredos, mas 56% ainda estão preocupados com uma possível violação de dados devido às suas práticas atuais de gerenciamento de segredos.

“As equipes de segurança e engenharia são forçadas a desviar sua atenção da engenharia voltada para o futuro para se concentrar no gerenciamento de segredos, mas suas organizações permanecem vulneráveis ​​a invasores por meio de ataques laterais e segredos de API vazados ou comprometidos para obter acesso ilegítimo a dados confidenciais”, disse Jared Elder , CGO da Corsha.

“Os dados são tudo e o risco potencial de violações de dados associadas a segredos de API vazados é claramente alto e crescente. No entanto, com uma explosão de credenciais para provisionar, rotacionar e gerenciar, os mocinhos se encontram constantemente atrás da bola oito”, acrescentou Elder.

Um cenário de ameaças em mudança

O uso de API explodiu nos últimos anos, à medida que as empresas continuam a expandir sua adoção de tecnologias nativas e ecossistemas orientados por API, como microsserviços e arquiteturas sem servidor, infraestruturas de nuvem híbrida, pipelines de CI/CD e uma série de outros aplicativos e serviços que estão enviando e recebendo informações confidenciais por meio de APIs.

De acordo com a pesquisa, 44% dos entrevistados hospedam seus serviços de API em várias nuvens. Para muitas empresas, isso geralmente significa soluções de gerenciamento de segredos desconexas em ambientes diferentes.

Como resultado, os entrevistados gastam muito tempo gerenciando tokens de API. 78% relataram que gerenciam pelo menos 250 tokens, chaves ou certificados de API em suas redes. Infelizmente, suas estratégias de segurança para comunicação baseada em API não conseguem acompanhar o nível de escala e automação que é possível hoje.

Abordagens desatualizadas para um desafio de segurança moderno

Todas as APIs têm uma coisa em comum: elas conectam serviços para facilitar a transferência de dados. Isso os torna um alvo favorito para hackers, pois o número de APIs que dependem de segredos aumenta e os fluxos de trabalho (por exemplo, provisionamento e compartilhamento de segredos, gerenciamento de segredos, monitoramento, controle) se tornam mais difíceis.

De acordo com a pesquisa, os três principais pontos problemáticos do gerenciamento de segredos de API são:

  • Trabalhar com autoridades certificadoras (44%)
  • Rotação de segredos (37%)
  • Segredos de provisionamento (36%)

Os métodos que os entrevistados mais comumente usam para lidar com esses pontos problemáticos geralmente são antiquados, manuais, propensos a erros e complicados.

Embora muitas equipes de segurança atribuam direitos específicos a chaves de API, tokens e certificados, a pesquisa descobriu que mais de 42% não o fazem. Isso significa que eles estão concedendo acesso de tudo ou nada a qualquer usuário com essas credenciais, o que, embora seja o caminho de menor resistência no gerenciamento de acesso, também aumenta o risco de segurança.

Os pesquisadores da Corsha também descobriram que 50% dos entrevistados têm pouca ou nenhuma visibilidade das máquinas, dispositivos ou serviços (ou seja, clientes) que utilizam os tokens, chaves ou certificados de API que suas organizações estão provisionando. A visibilidade limitada pode levar a segredos que são esquecidos, negligenciados ou deixados para trás, tornando-os alvos principais para os malfeitores explorarem sem serem detectados pelas ferramentas de segurança tradicionais e melhores práticas.

Outra bandeira vermelha: embora 54% dos entrevistados alternem seus segredos pelo menos uma vez por mês, 25% admitem que podem levar até um ano para alternar segredos. A natureza estática e de longa duração desses segredos de portador os torna os principais alvos dos adversários, assim como a natureza estática das senhas para contas online.

Práticas recomendadas de segurança de API

O relatório também descreve o que as organizações podem fazer para implementar processos eficazes de gerenciamento de segredos, incluindo:

  • Integrando um bom gerenciador de segredos para obter visibilidade geral de todos os segredos
  • Usando mTLS quando e onde possível
  • Sempre defina uma expiração curta para os segredos quando possível
  • Sempre assine e verifique os tokens
  • Não armazene ou passe segredos em texto simples

“Atualmente, mesmo a implementação de gerenciamento de segredos modernos mais robusta não é suficiente para impedir que as APIs sejam exploradas, o que explica por que mais da metade dos entrevistados destacaram a preocupação contínua de sofrer uma possível violação de dados devido às suas práticas atuais de gerenciamento de segredos”, disse Scott Hopkins, COO da Corsha. 

“A pesada carga de trabalho administrativa e os processos excessivamente manuais para manter uma boa higiene de segurança em relação ao gerenciamento de segredos criam oportunidades significativas de erro ou descuido. As organizações se beneficiariam de uma resposta mais forte, automatizada e altamente escalável para seus problemas de autenticação de API que podem ser facilmente integrados a qualquer ambiente”, concluiu Hopkins.

Também é importante que as equipes de segurança e desenvolvimento reconheçam que o risco está mudando predominantemente de humano para máquina e de máquina para máquina e considerem o que precisa ser feito para explicar essa transformação.

FONTE: HELPNET SECURITY

POSTS RELACIONADOS