Segurança de APIs: práticas modernas com DevSecOps

Fundamentos de segurança em APIs - Apresentação

Apresentando a instrutora e sua experiência

Olá! Meu nome é Bruna La Torraca, sou instrutora e irei ministrar o curso de segurança em APIs.

Audiodescrição: Bruna é uma mulher de pele clara, com cabelos castanhos longos e lisos. Ela usa óculos e está vestindo uma blusa marrom e um casaco verde. Ao fundo, há uma parede azulada com alguns itens de escritório em uma estante.

Trabalho na área de segurança, com foco específico em desenvolvimento seguro, desde 2017. Atualmente, sou analista de segurança de produto em uma multinacional.

Descrevendo o curso de segurança em APIs

Os meus hobbies relacionados ao trabalho incluem fazer trilha, ler, escrever e desenhar. Em relação ao curso, ele será composto por 12 aulas. Algumas delas incluirão laboratórios, e abordaremos desde os conceitos do que é uma API, seus diferentes estilos arquiteturais, a importância do uso de APIs atualmente, até os fundamentos de segurança em APIs. Discutiremos os riscos mais comuns seguindo o OWASP API Security Top 10 e teremos também uma aula no final focada em alguns aspectos de segurança importantes ao desenvolver uma API em GraphQL.

Fundamentos de segurança em APIs - O que são APIs?

Discutindo o conceito de API

Vamos discutir sobre API, ou Application Programming Interface (Interface de Programação de Aplicações), que é a origem da sigla API. Ela atua como uma ponte de comunicação entre dois sistemas, permitindo que programas, aplicativos e serviços diferentes interajam de maneira padronizada. Essa padronização é fundamental. Um exemplo simples é quando utilizamos um aplicativo no celular para consultar o clima. Esse aplicativo pode usar uma API para buscar dados atualizados sobre a previsão do tempo em outro sistema. Quando visualizamos o resultado, como sol, chuva ou temperatura, não percebemos toda a comunicação que ocorre nos bastidores entre o aplicativo e o serviço. Essa comunicação é realizada via API.

A importância das APIs reside no fato de que, sem elas, cada sistema seria fechado e isolado. As APIs tornam os sistemas mais abertos, conectáveis e escaláveis. Elas são essenciais no desenvolvimento moderno, pois permitem a reutilização de funcionalidades. Isso significa que um sistema pode utilizar funções de outro sistema sem precisar recriar tudo do zero. Podemos reutilizar uma API se vários sistemas utilizam o mesmo tipo de informação ou precisam do mesmo tipo de dado, acessando uma única API. Não é necessário criar uma API para cada sistema.

Integrando sistemas através de APIs

A integração entre diferentes sistemas é outro ponto importante. Por exemplo, um aplicativo de entrega utiliza APIs para conectar restaurantes, sistemas de pagamento e obter a geolocalização do usuário. A pessoa desenvolvedora não precisa necessariamente criar cada uma dessas APIs para que o aplicativo funcione. Ela se conecta a outros sistemas que já fornecem esses serviços. Isso também permite uma inovação mais rápida, pois as empresas conseguem lançar produtos e recursos mais rapidamente, sem precisar recriar tudo do zero. Elas conectam sistemas e aplicativos de maneiras diferentes para usar esses dados, permitindo inovação e lançando produtos mais rapidamente no mercado.

Além disso, as APIs oferecem controle e segurança, permitindo limitar o que os sistemas externos acessam e como acessam. Vamos agora falar sobre a exposição de APIs. Nem todas as APIs são usadas da mesma forma por todos. Existem diferentes tipos de exposição de APIs: privadas, parceiras ou públicas. Vamos abordar cada uma delas.

Explorando os tipos de exposição de APIs

Começando pelas APIs privadas, como o nome sugere, elas são internas e restritas à empresa.

As APIs internas são mais controladas e seguras, apresentando menor risco de ataques externos, pois, quando estamos fora do sistema ou da empresa, não temos visibilidade dessa API. Um exemplo seria um sistema interno de RH.

Temos também as APIs parceiras, que possuem acesso mais restrito para parceiros confiáveis, geralmente mediante um contrato ou algum tipo de assinatura. Oferecemos nosso serviço de API e informações mediante um parceiro com contrato, especificando as formas de uso e quem irá utilizá-las. Geralmente, há uma autenticação nessa API para identificar o usuário. Algumas dessas APIs geram cobrança por uso, permitindo esse tipo de cobrança. Um exemplo seria uma empresa de pagamentos acessada por lojas parceiras. Essas lojas vendem produtos, mas não desenvolvem um sistema de pagamento; elas se conectam ao sistema de pagamento. Nesse caso, criamos uma conta na empresa de pagamentos que fornece a API, identificamos-nos, enviamos os dados de pagamento, e a empresa realiza os pagamentos. Este é um exemplo claro de uso de APIs parceiras, que não são acessíveis a todos.

As APIs públicas, como o nome sugere, são abertas e de acesso livre para todos os desenvolvedores externos. Qualquer pessoa interessada pode usá-las e integrá-las. Elas geralmente possuem documentações disponíveis na internet, permitindo que vejamos como chamá-las e como funcionam. O potencial de inovação é grande, pois são mais fáceis de acessar e integrar, com menos contratos e burocracias. Exemplos incluem o Google Maps, o Twitter e serviços de clima-tempo, muitos dos quais são abertos. Por serem públicas e abertas, exigem maior segurança em termos de autenticação. No entanto, quanto mais exposta for a API, maior é o risco, tornando fundamental a segurança de controle de acesso. Não apenas o acesso, mas também como a API trata as informações recebidas e enviadas deve ser considerado. O sistema que recebe essas APIs também deve ser cauteloso, e esse será o foco principal do nosso curso.

Concluindo a introdução sobre APIs

Resumindo, para concluir este primeiro contato com APIs, definimos que elas são interfaces que permitem a comunicação entre diferentes sistemas de forma padronizada. Elas servem para integração, reutilização de funcionalidades e inovação, permitindo o controle de quem acessa e como acessa. Por isso, possuem diferentes níveis de exposição: privadas, parceiras ou públicas. Esperamos vê-los no próximo vídeo.

Fundamentos de segurança em APIs - Tipos de APIs

Introduzindo a importância das APIs e estilos arquiteturais

No vídeo anterior, entendemos que, no desenvolvimento de sistemas modernos, as APIs desempenham um papel fundamental ao permitir a comunicação entre diferentes aplicações, sistemas e plataformas. No entanto, nem toda API é criada da mesma forma. Existem diferentes estilos arquiteturais que definem como essa API se comunica, como ela é estruturada e padronizada, e como é executada. Os estilos mais comuns utilizados são o SOAP, o REST, o GraphQL e o gRPC. Cada estilo tem suas vantagens, limitações e casos de uso ideais. Compreender essas diferenças é essencial para escolher a abordagem mais adequada para cada tipo de projeto, seja ele um sistema corporativo, uma aplicação web moderna ou uma estrutura de microsserviços.

Para entender melhor o assunto, vamos falar individualmente de cada um desses tipos de arquitetura, citando prós e contras para cada uma. Vamos começar pelo SOAP, Simple Object Access Protocol. Ele é um protocolo formal e padronizado que troca mensagens, geralmente em XML. Ele utiliza métodos HTTP, mas pode usar outros protocolos para enviar essas mensagens estruturadas. Os prós do SOAP incluem seu padrão robusto. Quando falamos em padrão robusto, referimo-nos a técnicas e práticas que tornam esses documentos XML mais resistentes a erros, confiáveis e seguros. A robustez desse padrão não se limita apenas a ser bem formatado e sintaticamente correto, mas também à capacidade do próprio sistema de lidar com imprevistos, falhas e possíveis ataques. Isso também se deve aos contratos rígidos via WSDL. Por contrato rígido, entendemos que esse WSDL é um arquivo em XML que funciona como um contrato formal entre o serviço e seus consumidores. Esse contrato descreve de forma detalhada e padronizada onde o serviço está localizado, a URL, quais operações estão disponíveis, as funções e métodos, quais dados devem ser enviados e recebidos, e os formatos desses dados, tipos e estruturas. Essa rigidez é útil em sistemas que exigem maior padronização, validação e controles rigorosos. O contra é que ele acaba sendo muito complexo, com alta complexidade de implementação, mais pesado e verboso, transmitindo muito XML. Por isso, é pouco usado em aplicativos modernos ou móveis devido à sua alta complexidade e maior acoplamento entre os sistemas, sendo mais comum em sistemas corporativos. O SOAP é utilizado em integrações corporativas, como em bancos, seguradoras e governo, quando há exigência de maior segurança formal, auditoria e transações confiáveis.

Explorando o estilo REST

O próximo estilo que vamos abordar é o REST, Representational State Transfer. Ele é um estilo mais popular de APIs modernas, baseado em HTTP e recursos. O REST foi concebido na ideia de recursos acessados por URL, seguindo o modelo CRUD mais HTTP, que é o famoso GET, POST, PUT, DELETE. Essa abordagem é simples e poderosa, mas tem certas limitações quando precisamos fazer consultas mais complexas ou dinâmicas. Os prós do REST incluem sua simplicidade e leveza, sendo bem suportado por navegadores e ferramentas, e utilizando URLs legíveis de recursos. O contra é que ele tem pouca flexibilidade com consultas complexas, caindo no overfetching e no underfetching. O overfetching ocorre quando o REST retorna mais dados do que o necessário, pois os endpoints retornam um objeto fixo. Por exemplo, se pedimos o nome do usuário, o endpoint pode enviar nome, e-mail, endereço, lista de pedidos, etc., mesmo que só precisemos do nome. Já o underfetching é o contrário, quando ele envia dados de menos. Às vezes, precisamos de dados relacionados, como um usuário e seus pedidos, e no REST isso exige várias chamadas diferentes, tornando as consultas complexas. As consultas complexas exigem URLs com muitos parâmetros, tornando a construção confusa e, às vezes, inviável. Há também uma flexibilidade limitada, pois o cliente tem pouco controle sobre a resposta. O servidor decide o que será retornado, e o cliente não pode especificar exatamente quais campos deseja. Isso pode causar maior consumo de banda e lógica extra no front-end para filtragem e exibição. O REST é uma excelente escolha na maioria dos casos, especialmente quando buscamos simplicidade, padronização e compatibilidade. No geral, é encontrado em web services públicos, APIs de aplicativos móveis, web, integrações simples e de larga escala. O REST é indicado em operações que precisam da necessidade básica do CRUD, que é criar, ler, atualizar e deletar, e quando precisamos de compatibilidade com navegadores. Ele é uma boa escolha quando desejamos uma arquitetura padronizada e fácil de manter, pois o REST tem convenções claras e previsíveis de funcionamento. Isso facilita o desenvolvimento em equipe, a documentação, os testes automatizados e a integração de novas pessoas desenvolvedoras na equipe que lidará com essa API.

Discutindo o GraphQL

O próximo estilo que vamos abordar é o GraphQL.

O GraphQL é uma linguagem de consulta para APIs criada pelo Facebook, que permite ao cliente definir exatamente os dados necessários, diferentemente do REST. Entre suas vantagens, o GraphQL evita o overfetching e o underfetching, além de possibilitar o agrupamento de múltiplas chamadas em uma única requisição, tornando-se flexível para fontes de dados mais dinâmicas. No entanto, apresenta desafios em termos de segurança e controle de acesso, que são complexos e exigem mais esforço para serem implementados corretamente. Vamos abordar mais sobre o GraphQL em uma aula futura, especialmente sobre esses aspectos de segurança.

Outra dificuldade do GraphQL é a complexidade de cacheamento com HTTP tradicional, além de possuir uma curva de aprendizado maior para iniciantes. Por exemplo, uma pessoa desenvolvedora que ingressa em uma equipe e precisa criar uma API em GraphQL enfrentará essa curva de aprendizado mais acentuada. O GraphQL é indicado para aplicações com interfaces ricas, como dashboards, aplicativos móveis ou SPA (Single-Page Application), onde o cliente precisa de maior controle sobre os dados.

Analisando o gRPC

Após o GraphQL, temos o gRPC, um framework de API de alta performance criado pelo Google, que utiliza o protobuf (protocolo de buffer) em vez de JSON e XML. O protobuf é uma maneira simples e rápida de empacotar informações e transmiti-las, como uma linguagem secreta combinada entre dois computadores. Por exemplo, ao definir que o número 1 representa o nome e o número 2 a idade, utiliza-se esses números e códigos curtos em vez de palavras longas, tornando a mensagem menor, mais leve e rápida de entender.

O gRPC é muito rápido e eficiente, ideal para microserviços, e oferece suporte a streaming bidirecional, permitindo que cliente e servidor troquem dados em tempo real sem esperar a resposta um do outro. Além disso, possui tipagem forte e geração automática de código, o que significa que os dados têm tipos bem definidos e rígidos, evitando erros e proporcionando mais confiança entre cliente e servidor. Antes de usar o gRPC, é necessário definir o que a API espera e retorna, utilizando um arquivo .proto. Após criar esse arquivo, o gRPC gera automaticamente o código necessário para enviar e receber mensagens, chamar funções remotas, e codificar e decodificar dados, funcionando em várias linguagens como Python, Java, Go, C# e Node.

Apesar das vantagens, o gRPC requer ferramentas e configurações específicas para funcionar e não opera diretamente em navegadores, necessitando de um proxy. Existe uma curva de aprendizado para quem migra do REST HTTP tradicional para o gRPC. O gRPC é utilizado quando se precisa de alta performance e eficiência, comunicação entre microserviços externos e transmissão de dados, como vídeos. Aplicações IoT também costumam usar esse protocolo.

Resumindo os estilos arquiteturais

Antes de encerrar, apresentamos um resumo comparativo dos quatro tipos de arquitetura discutidos:

• SOAP: Utiliza formato XML, não é simples de implementar, possui pouca flexibilidade e desempenho mais lento. É ideal para sistemas legados e corporativos que exigem mais rigidez e auditorias.

• REST: Pode usar XML, mas é mais comum com JSON. É simples, possui flexibilidade média, desempenho razoável e é comum em aplicações web e móveis.

• GraphQL: Utiliza JSON, é simples, mas não trivial. Possui curva de aprendizado média, muita flexibilidade no envio e recebimento de dados, bom desempenho e é adequado para interfaces ricas e dinâmicas que requerem consultas complexas.

• gRPC: Utiliza formato protobuf, não é simples de implementar ou aprender, possui flexibilidade limitada dentro do contrato, mas oferece desempenho muito rápido. É usado em streamings de vídeo, jogos online e microserviços de alta performance.

Esse foi o conteúdo de hoje. Nos vemos no próximo vídeo.

Sobre o curso Segurança de APIs: práticas modernas com DevSecOps

O curso Segurança de APIs: práticas modernas com DevSecOps possui 340 minutos de vídeos, em um total de 111 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Introdução à segurança de APIs