Estratégia de Open API

Em nossa 6ª edição das Security Lives tivemos como tema central a Estratégia de Open API, visando aumentar a adoção do uso pelo ecossistema com segurança. Para nossa conversa, contamos com a presença de: 

• André Antunes – Cybersecurity Audit Manager no Banco Carrefour  

• Dárcio Takara – Especialista em cybersecurity na Sec4You 

• Alfredo dos Santos – Head of product Marketing na Digibee 

O que é OPEN API?

Para entender o conceito “API aberta – OpenAPI” é preciso saber de antemão o que é API (Interface de Programas de Aplicação) de uma forma resumida, API é um meio pelo qual dois sistemas possam conversar entre si.  

Por exemplo, toda vez que você acessa um site, o seu navegador só mostra as informações porque está em contato com a API da página que você entrou e, caso esse site tenha a opção de login, você terá a possibilidade de se cadastrar utilizando sua rede social. Tudo isso só é possível porque uma API interliga esses sistemas.  

André Antunes, cita Jeff Bezos, CEO da Amazon, como um dos maiores responsáveis da visão que temos hoje sobre economia das APIs. Jeff publicou um mandato em 2002 falando sobre a abertura das suas APIs para seus funcionários. 

“Jeff foi um visionário naquela época. Ele basicamente disse que todas as interações dos times da Amazon deveriam ocorrer através de interfaces de serviços onde só seria possível a comunicação entre as áreas através das APIs, como troca de informações e processos, sem a necessidade de links, e acessos diretos a memória, sem a inclusão dos sistemas legados”, conta André. 

Entretanto, esse sistema de Interfaces que foi utilizado, ainda em 2002, pela Amazon não era compelido como OPEN API. Isto porque o sistema de APIs que ele implementou servia somente para seus próprios desenvolvedores e times de funcionários, isto não é uma OpenAPI, neste caso é uma API fechada para utilização interna. 

Porém, Jeff deixou claro que em pouco tempo as interfaces seriam abertas para o público externo, ou seja, outras empresas poderiam utilizar as APIs da Amazon para melhorar e aplicar as interfaces nos seus produtos. Isto sim é uma API aberta (Open API). 

Desta forma, podemos então conceituar OpenAPI como uma interface disponível para desenvolvedores externos, visando uma padronização documental “O OpenAPI traz uma padronização muito forte, porque uma das dificuldades que encontramos nestas APIs é a padronização de consumo delas”, diz Antunes. 

André continua, “Hoje o OpenAPI já se encontra na versão 3.0, ele vem trazer uma facilidade para essa documentação e padronização. Você vê também um aspecto muito forte ligado a metodologia ágil aonde você consegue definir um design da sua API sem necessariamente começar pela codificação dela”. 

As lições aprendidas

André Antunes conta que todo o processo desenvolvido pela Amazon foi de extrema relevância para o mercado de APIs, isto porque outras empresas começaram a enxergar a necessidade de fazer o mesmo para se manter no mercado. 

Este processo gerou diversas lições para a Amazon, que alterou toda sua cultura interna para se adaptar as APIs, e mostrou que as áreas começaram a se enxergar como provedoras de toda aquela novidade. André cita algumas das lições: 

Suporte: as interfaces que foram desenvolvidas de forma descentralizada tiveram a necessidade de contar com suporte que era considerado muito diferente do padrão que as outras aplicações legadas utilizavam. 

Segurança: este aspecto passou a ser um dos mais importantes. Uma vez que cada time poderia provocar ataques nas outras unidades causando problemas nos processos desenvolvidos. Desta forma, a empresa teve que estabelecer níveis de serviço, cotas e limitações de rede entre esses serviços. 

Monitoração/ QA: este processo garantia que as APIs fossem interconectáveis e que elas falassem sobre soluções que entregariam os resultados esperados. 

Discovery: um aspecto fundamental de governança foi a necessidade de incluir o discovery nos processos. A quantidade de novos serviços que surgiu foi tão grande que as intercessões entre eles tinham dificuldades de se relacionarem. Desta forma, o discovery servia para verificar se as APIs estavam disponíveis, quais eram elas e como encontrá-las. 

Teste: antes das APIs irem ao ar, era necessário realizar testes na  Sandbox e realizar debugging para verificar se seria possível disponibilizá-las entre as áreas de serviço. 

As transformações

Tal processo deu origem a uma abordagem nova. André cita três transformações nos sistemas de APIs: 

Monolíticas: foi a primeira abordagem vista. Nestas transformações quando a empresa realmente precisa das aplicações para fazer qualquer alteração, é necessária uma gestão de configuração muito forte. 

SOA: esta abordagem está relacionada a arquitetura de software (SOA). Ela serve para conectar recursos com o objetivo de obter ou apresentar dados sob demanda. Nesta etapa é incluído o webservice de uma forma genérica para facilitar o uso e consumo dentro da aplicação. 

Microsserviços: a partir desta etapa, existe um desacoplamento dos microsserviços que tem funcionalidades distintas, mas que muitas vezes se alimentam de informações entre eles sem um acesso único a uma base de dados. Desta forma, temos tecnologias de fila e outras mudanças interessantes. 

Quais os perigos que sua API corre?

Quando desenvolvedores abrem suas APIs para que outras empresas possam utilizar os dados e informações pertinentes, eles têm ciência do perigo que o sistema corre. Isto porque se a interface não tiver o melhor sistema de segurança, é possível que informações que não deveriam ser acessadas sejam expostas provocando um grande problema. 

“Hoje os desenvolvedores devem ter conhecimento que outras pessoas tentarão explorar a vulnerabilidade das APIs. Infelizmente, por mais que a padronização das interfaces seja positiva, ela pode facilitar a invasão que acontece nas APIs.”, diz André. 

É necessário ponderar a forma como as informações são disponibilizadas, separá-las por níveis, as que são relevantes das que são informações confidenciais. Para isso, os desenvolvedores devem se atentar a quantidade de logs que são inclusos na interface para que evite e consiga ordenar as informações comuns das informações privadas. 

André frisa a necessidade de que os desenvolvedores devem pensar além das autenticações simples impostas para o usuário, como login e senha, e pensar em modelos como Open ID, OFF 2 e mais. É interessante estudar a proposta de CIAM (Customer Identity & Access Management), que atua voltado para a identificação do cliente e usuário. 

Outro risco frequente que é encontrado nesta integração de serviços e microsserviços pelas APIs é uma requisição frequente no uso de acessos para que a interface rode de uma forma adequada. Para isso, é necessário ter cuidado na hora de permitir o acesso aos dados disponibilizados pelas APIs externas 

O valor de negócio de OPEN API 

Já temos conhecimento que OpenAPI são de acesso público, logo são utilizadas por desenvolvedores fora da organização que as criou. Porém, quando as API são abertas, pode-se compreender que elas não estão seguras. Mas este conceito está errado! 

Exatamente pelo fato de serem públicas, as Open APIs possuem na sua estrutura a segurança dobrada para evitar fraudes, vazamento de dados e outros perigos. É dessa forma porque outras empresas como fintechs, bancos digitais e e-commerce podem ter acesso a dados importantes. 

“A iniciativa de OpenAPI busca criar um ecossistema em torno do seu negócio. Ou seja, se você tem algum dado, alguma informação relevante para esses terceiros, basicamente a estratégia é criar esse ecossistema”, conta Dárcio Takara. 

Essa integração entre desenvolvedores e serviços permite que o OpenAPI seja visto como um ótimo meio para firmar parcerias de negócio, estratégias de longo alcance e valor financeiro, isto é, o ecossistema que a interface produz. 

Segundo Takara, alguns serviços de assinatura, aplicativos, precisaram adaptar estratégias como os serviços de assinaturas de academias. Com os locais fechados, esses aplicativos passaram a mover esforços para encontrar outras formas de se manterem firmes. 

Os principais desafios na hora de aplicar segurança e governança para sua iniciativa de OPEN API

Todas essas ações de estratégia visando o negócio pelo Open API causa um grande aquecimento no mercado financeiro e tecnológico. Entretanto é preciso estar atento a vazamentos de dados que estão cada vez maiores devido as APIs abertas. 

Dárcio Takara conta que quando acontece algum tipo de vazamento de informação por conta das invasões nas interfaces abertas, o risco é muito pior. Isto porque não é somente um dado utilizado dentro da organização, mas sim outras empresas que podem ter acesso a essas informações. 

“Eu costumo dizer que quando utilizamos APIs, dependendo do tipo da falha, o dado que é vazado é muito mais exposto. Isso acontece porque temos uma base de dados com informações que acabam amplificadas e sendo consumidas por parceiros”, Takara diz. 

Existe uma sequência lógica da ameaça no vazamento da informação, por exemplo, em uma instituição financeira: 

O primeiro passo seria a falha na configuração dos mecanismos de segurança dessa API. Dessa forma um roubo massivo das informações ocorre. 

O segundo passo é a divulgação e venda dessas informações, um mercado ilegal, ou seja, no exemplo de uma instituição financeira existe uma monetização das informações dos dados que foram vazados. 

O terceiro passo refere-se a fraude, nesta etapa os clientes já estão reportando a ação. E, questionando os possíveis prejuízos que tiveram. 

Dárcio cita uma pesquisa realizada pela Gartner que informa que até 2021, 90% das aplicações web terão mais áreas de superfície para ataque na forma de APIs expostas do que na interface do usuário, acima dos 40% em 2019. 

Ou seja, “A tecnologia vem mudando o modo de expor a informação ou adoção de APIs, elas vêm acontecendo onde os mecanismos de controle não acompanha o movimento”, Takara conclui. 

A pesquisa realizada pela Gartner fala que as APIs aumentam as superfícies de ataque por alguns fatores. 

O modo como as APIs estão sendo utilizadas é completamente diferente do conceito do desenvolvimento tradicional que vinha acontecendo. Ou seja, um servidor de aplicação era protegido por HTTP server. 

Hoje, o processo de proteção é diferente, ele é muito mais granular. Existem pontos de acesso que possuem diferentes operações que podem ser executadas. 

Mas as questões não param por aí, existem três pontos para se considerar, de acordo com Takara. A primeira é a invasão a nível de rede, o ataque sobre sua infraestrutura. Entretanto, esse ataque é responsabilidade dos provedores de serviço. 

No segundo cenário, as invasões são feitas através de aplicações web. Neste caso, a responsabilidade é compartilhada entre aplicações feitas dentro da organização, e interfaces de terceiros. Alguns profissionais são capacitados para proteger nestes casos e existem tecnologias que auxiliam também. 

A terceira situação refere-se a ataques diretos as APIs. Aqui, a responsabilidade é total da organização que a desenvolveu, e muitas vezes as interfaces são feitas de modo “caseiro”, isso quer dizer que existem poucos profissionais capacitados para resolver o problema. A tecnologia de segurança que poderia ser uma aliada não funciona muitas vezes por problemas de configuração de gaps. 

Dárcio diz que existem tantas ameaças as APIs, que contar somente um tipo de proteção não é recomendado, a melhor opção é se apoiar em diferentes formatos de segurança, como autenticação de usuário, HTTPs, biometria, criptografia e outros, criando uma cadeia em camadas. 

Low-Code e a tão sonhada economia das APIs 

Alfredo dos Santos explica de uma forma simples que low-code é um ponto que se interliga a outros pontos. Essa abordagem minimiza a codificação por meio de modelos pré-definidos, técnicas de design gráfico e ferramentas de arrastar e soltar para criar um software. 

O low-code interliga APIs, aspectos de segurança, conexões SAP e decisões que levarão a vários caminhos. 

“Essa abordagem de low-code pela Digibee permite que arrastemos estes componentes para criarmos integrações de uma forma mais simples e segura”, diz Alfredo. 

Ele mostra um exemplo criado pela empresa. Se você vai se conectar com o SAP de uma forma segura, você o expõe por meio de uma API, então todo o sistema criado através do low-code permite que a conexão seja feita especificamente para aquela exposição. 

A API pode ser vista como “a porta para dentro”, ou seja, ela é o ponto de intercessão, e para isso existe um alto grau de desenvolvimento. 

Alguns exemplos de desenvolvimento são: ERPMs, CRMs, Mainframe, banco de dados relacionais e não relacionais. Estes desenvolvimentos permitem a codificação da API para que ela tenha acesso ao API Gateway. 

Este processo exige um esforço, e com o contexto de low-code você está “apificando” com ele. A partir disso, é possível desenvolver pipelines internos que irão conectar nos sistemas e se transformarão em APIs. 

Porém, todo esse processo de transformação em APIs, que contém informação e dados, são suficientes? De acordo com Alfredo, não. Para isso são criados os ecossistemas que funcionam “mais do que porta para dentro”. 

Tais empresas que utilizam as interfaces de aplicações podem ter parceiros de negócios, como citado anteriormente. Mas este processo não pode se resumir a parcerias de negócios, isto porque existe atrito com o desenvolvedor. 

“Da porta para fora” significa que dois ou mais sistemas externos exigem esforços para se conectarem e funcionarem normalmente. Este cenário de atrito e dificuldade de utilização das APIs se torna maior quando se considera o nível de maturidade de tecnologia das empresas. Quando isso acontece, a promessa de economia das APIs não se realiza. 

O desenvolvimento deve ser em conjunto com o parceiro de negócio para superar o desafio de criar uma API aberta que tenha conexão com a “porta para fora”. Quando as duas empresas estão com suas APIs interligadas e maduras, é possível enxergá-las “uma de frente para outra”. 

Quando essa integração e ecossistemas estão prontos e funcionando corretamente, as APIs que são utilizadas por parceiros promovem a tão sonhada economia de APIs. 

Este artigo foi escrito por Alfredo Santos e publicado originalmente em Prensa.li.