Há pelo menos três respostas boas e algumas não tão boas.
A estratégia, principalmente quando se trata de tecnologia, muitas vezes é colocada sobre os ombros dos executivos. Quando se trata de estratégias relacionadas à segurança, geralmente é o CISO ou, se não houver tal função, o CIO.
Mas algumas organizações delegam a responsabilidade de conduzir estratégias de segurança de API a outras funções. Desenvolvedores, SREs e até mesmo profissionais de rede podem ser donos da estratégia para proteger APIs hoje.
Talvez seja porque não há uma pesquisa real sobre quais podem ser os resultados dessas decisões. Afinal, há bons motivos para os desenvolvedores implementarem uma estratégia de segurança de API, assim como há bons motivos para atribuir essa responsabilidade a todos que podem ter contato com uma API de alguma forma, seja durante o desenvolvimento, teste ou produção.
Em nossa pesquisa recente sobre segurança de API, perguntamos a cada um dos nossos entrevistados — todos os tomadores de decisões de segurança de API — quais funções em sua organização eram responsáveis por conduzir a estratégia de segurança de API. Encontramos uma mistura de respostas, desde desenvolvedores a profissionais de rede e abordagens interorganizacionais.
Mas também perguntamos alguns detalhes essenciais sobre os tipos de serviços de segurança que as organizações usam para proteger APIs. Esses são serviços como proteção DDoS, controle de acesso, mTLS e SSL. Usamos a implantação desses serviços como uma representação tangível da execução estratégica porque eles são alguns dos controles necessários para aplicar políticas derivadas de uma estratégia de segurança. Em seguida, analisamos quais desses serviços foram implantados com base em quem conduz a estratégia de segurança da API.
Francamente, ficamos surpresos com os resultados.
Acontece que o conjunto mais abrangente de serviços foi implantado quando a estratégia de segurança de API é uma responsabilidade interorganizacional, seguida de perto pela organização de segurança mais geral e pela liderança do CIO/CISO.
Talvez o mais preocupante seja que, quando os SREs conduzem a estratégia de segurança, a segurança da API não é incorporada até a fase de teste do ciclo de vida da API. Quando outras escolhas para a estratégia de segurança de API são feitas, a incorporação da segurança de API começa em grande parte nas fases de design ou desenvolvimento. Mesmo quando as equipes de rede conduzem a estratégia de segurança da API, elas nos dizem que o desenvolvimento é a fase na qual a segurança da API deve ser incorporada.
Agora, a boa notícia é que a maioria das organizações atribui a responsabilidade de definir a estratégia de segurança da API a um desses três. Apenas 8% delegam isso aos desenvolvedores, menos ainda (3%) esperam que profissionais de rede cuidem disso e apenas 1% atribuem essa tarefa aos SREs.
Isso está intimamente alinhado ao domínio ao qual a segurança da API é atribuída. Porque essa decisão é amplamente influenciada por quem conduz a estratégia. Quando a estratégia de segurança de API é conduzida pela liderança do CIO/CISO ou considerada interorganizacional, a segurança de API acaba sendo distribuída em quatro domínios típicos: Gerenciamento de API, segurança de aplicativos, rede e segurança, mas separados da segurança de aplicativos. Dado que os serviços que defendem e protegem APIs podem abranger vários domínios, isso faz sentido.
Portanto, se sua organização atribui a estratégia de segurança de API à liderança do CIO/CISO, Segurança, ou considera isso uma responsabilidade interorganizacional, parabéns! Sua abordagem estratégica está levando a controles de segurança abrangentes por meio de serviços de segurança que defendem e protegem APIs de uma ampla variedade de ataques.
Você pode se aprofundar ainda mais na vida secreta das APIs lendo o comunicado de imprensa de hoje e adquirindo nosso último relatório . Aqui você encontrará estatísticas mais assustadoras, mas também aprenderá mais sobre as maneiras como as APIs são realmente usadas dentro da empresa, bem como os recursos de segurança que as organizações consideram importantes para manter as APIs seguras.