Sensedia Webinar | Segurança de APIs: itens essenciais, pilares e seus princípios

Olá pessoal, bom, dando continuidade à iniciativa da SimSídia em compartilhar informação de forma gnóstica para a comunidade técnica, comunidade de negócio, bom, para todas as comunidades, a gente vai começar um vídeo falando especificamente sobre segurança, mas não se preocupe, não é a segurança da NASA, é uma segurança que é possível, segurança de itens essenciais. A ideia não é abordar a forma absurda que é necessário para alguns casos, mas sim para algumas pessoas repassar se está atendendo itens essenciais ou se nem está atendendo, então vamos correr atrás. E a SimSídia está aí para ajudá-los, vamos passar várias informações, então vamos lá.

Ah, antes de eu entrar na apresentação e na agenda, meu nome é Fabrício, eu sou Solution Architect aqui na Sensedia, trabalho no time de consultoria, no time de soluções para desenhos de novos projetos, focado em desacoplamento, modernização e muito recentemente, bom, desde o ano passado para cá, a parte de Open Insurance, Open Banking, Open Education, que daqui a pouco está aí. Bom, vamos lá, meus contatos estão aí, mas o importante é conteúdo, vamos lá.

Falando em conteúdo, a agenda que a gente pretende passar são alguns cases, e aí bem ressaltando, não tão bons os cases desastrosos, vamos entrar um pouco nos principais riscos de segurança em APIs e dividir esses riscos no que a gente chama de pilares de segurança no processo de integração. Especificando a parte de:

• Canal
• Autenticação
• Autorização
• Conteúdo
• A parte perfeita, e todo mundo tem que enxergar nisso, é a automatização e a garantia disso tudo que vocês definem de segurança, que é o DevSecOps.

Bom, isso aqui é muito real e eu estou na área já há um pouquinho de tempo, uns 20 anos talvez, sim, eu desenvolvi códigos para resolver o bug do Minério, e não só lá atrás, 98, 97, 98, mas também agora, a gente vê muito essa analogia de implementação. Você ter todo o seu front bonito, com todo o cuidado para mostrar para o teu parceiro, para o teu cliente, mas no fim, o seu front não aguenta toda a carga ou ele não está preparado, porque a partir do momento que você se expõe na internet, você está exposto para qualquer pessoa, para qualquer script, para qualquer robozinho, tanto de pessoas mais leigas, quanto de pessoas bem expert em conseguir, de forma intencional, entrar na sua infraestrutura.

Alguns exemplos aqui, cases não tão bons e bem reais, do qual o problema foi a integração, o primeiro que eu trago para vocês, e aí até um ponto de, nossa, isso aqui é bem arriscado, é um risco muito grande. Imagina você com um marca-passo, você com algum parente que tem um marca-passo, e esse marca-passo tem uma maneira de entrar dentro desse equipamento para poder fazer pequenas configurações ou até upgrades, só que isso de forma remota. E sim, foi encontrado uma brecha de segurança na API, que você consegue conectar, uma segurança muito fraca ou fácil de identificação, e teve que rolar o recall. Imagina o recall de um marca-passo de pessoas que já estavam utilizando. Calma, não precisou abrir, retirar para poder fazer o recall, foi um recall de software, ainda bem, e todo um refactor da solução com mais segurança de hardware. Um outro exemploque eu trago para vocês é uma invasão até então tranquila, porque, pô, eu vou descobrir quais foram os... Porque eu vou descobrir onde a pessoa correu, porque naturalmente isso aqui até o hacker foi mais de engenharia social. Esse aplicativo de fitness muito comum, ele dá metas e publica suas metas na rede social dele. Mas ele é usado por algumas pessoas que é bem sensível, no caso aqui para o exército americano. Então o hacker, através de engenharia social e com as APIs, conseguiu obter informações privilegiadas para até identificar um militar de relevância na hierarquia dos Estados Unidos para saber onde ele está, real time até, ou o perfil de comportamento dele fora do exército. Isso aqui é muito perigoso e foi também uma exposição de dados interna que acabou externalizando.

Um outro exemplo, e esse aqui exige um nível de complexidade maior, porém possível, que é o desenvolvimento de um hardware. Um hardware para você invadir um carro. Isso aqui é bem interessante, até recomendo a leitura do case. A pessoa aperta o botão para trancar o carro e não funciona. Aí ele aperta de novo e tranca. O que essa pessoa fazia? De forma remota ele capturava a chave de criptografia para poder travar o carro. Ele conseguia interceptar isso, ele traficava de forma aberta, absurdo. Então ele conseguia pegar via radiofrequência essa chave e a segunda ela não era usada, era uma chave válida. A segunda vez não anulava a primeira e ele conseguiu, o dono do veículo conseguiu atrancar. Só que aí essa pessoa que tinha uma chave válida que ainda poderia ser utilizada, ele chegava do lado e destravava o carro. Ligava o carro. Tem que tomar cuidado. Se você for trafegar dados sensíveis para esse nível de complexidade, trafega esses dados sensíveis de forma segura.

E um exemplo também que não é um hackeamento do veículo, mas sim de softwares utilizados pelo veículo. No caso aqui o hacker, por meio de uma competição, isso é muito normal ultimamente, as empresas fazendo competições de hacker e premiar a pessoa que consegue invadir. No caso aqui esse hacker conseguiu, através de uma brecha de segurança de um browser, que estava instalado dentro do veículo, ele conseguiu entrar no root do sistema admin do veículo. Então remotamente ele conseguiu acessar via API uma brecha de segurança de um software que não era o principal, era um browser, e conseguiu invadir toda a parte de gestão do veículo. Tome cuidado. Se você usa softwares de terceiros que não é seu, sei lá, tente isolar esse software terceiro, não ter tanto acesso à tua solução e principalmente, mantenha ele atualizado. Sempre fique esperto. Ou não deixa a camada que tem o log com tanto acesso à tua solução. Faça essa proteção.

E API está aí para expor, a integração está aí para isso. Bom, você está exposto na internet. A partir do momento que você está exposto na internet, você está exposto para qualquer um. Tanto para os seus consumidores, parceiros, que é o seu principal objetivo, mas também para pessoas maliciosas que estão doidas para explorar essas vulnerabilidades. Então, proteja.

E onde normalmente ocorrem essas vulnerabilidades? O lado esquerdo aqui é o consumidor, denominado nessa apresentação como app, que pode ser um web browser, pode ser um ser humano, pode ser um appliance, um hardware. E do lado direito, o seu software, a sua solução. Onde pode acontecer invasão? É no túnel de comunicação. Pode ter espionagem de dados, então talvez você tenha que colocar aqui um protocolo de criptografia no túnel, ou uma criptografia do conteúdo. Pode ter uma manipulação de dados, que é o man in the middle, que foi o que aconteceu nos cases que eu acabei de mostrar para vocês. O uso não autorizado, ou seja, o acesso indevido. Você dá acesso para o seu parceiro, para o seu cliente de uma operação GET e ele

consegue descobrir qual é uma operação POST para alteração de dados e ele consegue acessar. Então, controle os seus acessos. E garante a proteção de repetições insistentes. Então, tenta proteger a parte de repetições insistentes porque ele pode derrubar a

tua API que está exposta na internet e, consequentemente, o teu back-end que é o software. Tudo isso você tem que proteger porque você está exposto. Todos os cases que eu mostrei para vocês anteriormente caiu em alguma dessas falhas aqui.

E como você resolve? Não existe uma bala de prata. Não existe. O que nós recomendamos é dividir para conquistar. E é o que eu vou trazer aqui para vocês. Como a gente divide?

• Redesenvolvendo toda a tua solução?
• Dominando a tua solução e redesenvolvendo toda ela em pequenos modos? Talvez. Se for possível, talvez seja interessante. Mas não é isso a proposta dessa apresentação. É basicamente dominar o seu legado de uma forma sustentável com uma solução de mercado ou uma solução desenvolvida para vocês. Não precisa de comprar uma ferramenta específica para isso, mas você tem que saber o que tem que proteger e quais são os itens que tem que proteger. Como eu disse, dividir para conquistar.

E como você divide isso? Divide em cima do que a gente chama de pilares de segurança. Nós temos:

• O pilar do canal de comunicação,
• O pilar de autenticação do seu consumidor,
• O pilar de autorização de quem foi autenticado. Então ele tem que saber e você tem que limitar o acesso disso.
• E o pilar de conteúdo que está trafegando nesse canal.

Porque, acredite, é muito comum você proteger absurdamente o seu canal de autenticação e autorização e o conteúdo está protegido sobre esses três pilares, só que ele fica aberto internamente. Sim, internamente é um ponto de risco também. Infelizmente você tem que pensar também no dado aberto dentro da tua infraestrutura, com o teu time de desenvolvimento vendo aquele dado aberto e sensível e esse é um problema bem grande.

E como você mantém esses pilares? Em cima de uma boa política de DevSecOps. Bem definida a parte de desenvolvimento, acompanhando sempre a parte de segurança e mantendo isso em cima do operacional. Usa uma ferramenta para isso? A Cincidia tem essa ferramenta, eu vou mostrar mais no final, mas a ideia é a gente entrar mais no detalhe do pilar.

O que você tem que se preocupar? Eu vou fazer isso, então eu tenho que proteger tudo. Absurdamente fazer aquela tecnologia absurda da NASA, porque eu quero fazer a segurança. Não é necessário. Primeiro, você vai aumentar a complexidade do seu consumidor, você vai ter que provisionar uma infraestrutura muito grande, você vai ter um custo computacional. Então saiba dosar em quais são os locais que vocês necessitam dessa proteção.

Então, que nem aqui na casinha dos três porquinhos. Às vezes você quer dar muita comodidade para o seu consumidor, mas consequentemente você expõe um pouco a segurança. Ou você quer muita segurança, mas você tem pouca comodidade. Então, o que seria comodidade? É o consumo da tua API para fazer a integração. Muita comodidade, o acesso às vezes é público. Pouca comodidade, mas porém muita segurança, mas pouca comodidade porque você tem que criptografar o dado com uma chave absurda de segurança.

Então, qual é o objetivo dessa apresentação? É vocês pelo menos seguirem os itens essenciais e depois eleger quais são os itens que necessitam de uma segurança mais específica e aí sim talvez entrar em conceitos mais complexos de proteção de dados. Então, vamos falar um pouco. Esse é o escopo, são os itens essenciais.

O primeiro pilar que eu queria abordar, que eu vou abordar, e passando o item essencial, é a parte de canal. E pasmem, muita gente não faz o básico, que é colocar um certificado SSL na exposição da API. Só isso já resolve muito a tua exposição de dados. Muita gente expõe a API para integrações em um HTTP normal, sem ter um certificado. O que o certificado, quando você colocano teu canal, ele vai fazer? Ele vai literalmente criptografar o canal. Até o presente momento, estou falando mais uma vez, estou falando 19 de 8 de 2022. Até o presente momento, quebrar essa chave do canal é muito caro, muito oneroso. Daqui a pouco os computadores quânticos estão chegando aí, de uma forma mais barata, talvez fique mais fácil quebrar essa chave, mas no momento ninguém tem acesso a esse tipo de tecnologia, então é uma solução muito rápida para vocês colocarem. Então garanta que o teu canal está protegido com o certificado. Não use certificado auto-assinado também, tenta ter uma certificadora homologada, uma CA. Tem certificados registrados publicamente que você paga muito barato. E eu estou falando de barato de, sei lá, 10 dólares por ano. Eu tenho que criar certificados, eu não tenho essa grana, estou falando de um conceito corporativo, isso é muito barato. Entre em contato com uma CA, uma empresa certificadora que gere esse certificado e compre esse certificado e coloque no teu túnel. E detalhe, essa solução não envolve, não altera a característica do teu software, do teu back-end. Isso é uma capability de infraestrutura e não prejudica o teu consumidor, porque ele até prefere que seja HTTPS no teu túnel. Então isso é muito fácil de habilitar, é o que eu recomendo do canal. Isso é essencial, tem gente que não faz.

O outro ponto, seguindo na parte dos pilares, é a autenticação. É você identificar o seu consumidor. O item essencial que eu recomendo e é altamente usado no mercado é usar os padrões de OAuth. Muita gente usa os padrões de OAuth. Aliás, não é tão utilizado, porque às vezes a pessoa vê uma complexidade de utilizar de OAuth, de ter uma inteligência de OAuth na exposição dos dados. Mas hoje você tem várias soluções open source, por exemplo, Keycloak. O Keycloak, o Jansen, da Glue, ou até mesmo soluções de cloud, caso você contrate uma cloud para colocar o teu back-end, Azure, AWS, GCP da Google, você tem essa solução. É drag and drop, literalmente. Você vai lá e arrasta e habilita a parte de autenticação. Mas tomem muito cuidado. Às vezes, colocar autenticação com a estratégia errada também pode ser um problema. Então talvez o Client Credential é uma autenticação muito simples, que a gente chama de Basic Authentication, que é você ter uma chave fixa. Mas eu recomendo que vocês usem uma estratégia de Access Token, no mínimo, com um tempo de expiração curto, não longo. Eu já peguei projetos que o tempo de expiração chegava a uma semana. Então, pelo amor de Deus, não faça isso. Então tenha um Access Token que expire em uma hora ou até menos. Eu já peguei casos também que expirava em um minuto ou por finalização. Mas use uma estratégia de OAuth para autenticar o seu cliente.

Um outro ponto também muito importante, e eu faço isso até por diversão. Muitas vezes, aqui na Sensedia, a gente desenvolve a parte de backend e implementa a segurança de autenticação. E dá para o consumidor. Então, normalmente, quando tem o consumidor, uma página web, eu até penso, qual é a página web que vocês estão implementando o acesso às minhas APIs? Ah, essa aqui. Eu entro, dou um F12, eu inspeciono a página HTML e eu acho, infelizmente, o Client ID e o Client Secret. Não, esse dado tem que ser protegido, porque com essas duas informações eu consigo gerar o Access Token. Se você expor essas duas informações, qualquer pessoa vai conseguir gerar o Access Token e passar por você. Porque o Client ID é por consumidor. Aliás, isso é tanto ajuda na unicidade do seu consumidor, também na rastreabilidade do consumo. Então, use da forma correta. Access Token, normalmente, eu uso para integrações internas. A estratégia de Grant Code eu uso muito para integrações externas com parceiro, porque eu garanto que, por mais que exponha o Client ID e o Client Secret, o Code só é gerado e enviado para um servidor de callback, não fica exposto. Use da forma correta, tem as RFCs, a 6749 e a 6750. Dá uma estudada ou veja um provedor. A Syncedr tem essa solução. Nós desenvolvemos,então a gente pode ser um provedor de autenticação para você. Fora a parte de autenticação, temos também a parte de autorização. Não adianta eu identificar o meu parceiro, o meu cliente, e eu não definir como ele vai acessar as minhas operações. Qual que é a estratégia mais simples que a gente pode utilizar? É fazer perfis de acesso. Basicamente, é ter uma API com 10 operações:

1. Operações de alteração de dados,
2. Operações de inserção de dados,
3. Operações de consulta de dados.

E com a mesma API eu consigo fazer vários perfis de acesso para vários consumidores. Então, hoje, o melhor dos mundos é você tentar fazer a tua autorização por perfil de acesso. É o que a gente chama aqui na Sensedia de planos, plano de acesso. A gente tem vários clientes que contratam a plataforma justamente para fazer o gerenciamento do acesso. Porque a API pode ter vários perfis de acesso. E não faz sentido eu clonar a API para justamente brindar o acesso dela. Não. Especializa isso em uma camada de plano. Isso define a autorização. Tá ok?

Falando aqui um pouco da plataforma, bem rapidamente, isso aqui é o cadastro de apps, dos meus consumidores, com os acessos. Então ele pode acessar a SAPR com plano X, SAPR com outro plano. E eu defino dessa forma a forma que ele vai acessar a minha API, por plano. Autenticação? Não. Canal, né? HTTPS. Autenticação? O off. Autorização? Uma regra de plano.

E agora o que falta nos meus pilares é a parte de conteúdo. O conteúdo... Toma cuidado. Não vamos partir para uma criptografia, a não ser que seja necessário. Que é o primeiro ponto que eu queria mostrar para vocês. Pô, eu vou seguir a criptografia. Perfeito. Mas qual estratégia? Você vai usar uma criptografia simétrica ou uma criptografia assimétrica? Qual que é a diferença dos dois?

Criptografia simétrica: A mesma chave eu consigo criptografar e decriptografar. Então, se eu trafego um dado criptografado e a chave que eu criptografei é exposta, quem pegar esse payload por alguma forma, com certeza ele não vai conseguir pegar no túnel, mas ele pode conseguir pegar isso nas pontas e ele tem essa chave, ele consegue abrir o dado. Então você tem que entender qual que é a melhor forma de você manejar essa chave. É uma estratégia interessante de utilizar. Ela dá uma segurança, porém, tome muito cuidado com a exposição da chave. Tem alguns clientes que chegam a gerar chaves diariamente ou até de hora em hora. Para se de alguma forma alguém expôs a chave, ele só vai conseguir usar isso num período curto. Ou garanta que você esteja protegendo a tua chave simétrica.

Criptografia simétrica é uma estratégia mais sofisticada, do qual você tem uma chave pública e uma chave privada. A chave pública criptografa e a chave privada decripto. Essa chave privada está guardada no meu cofre, ninguém tem acesso a ela. E a minha chave pública qualquer um pode ter acesso. Porque através dela o máximo que ele vai conseguir fazer é criptografar. Qual que é o senão de usar essa estratégia? Custo computacional. É uma estratégia que exige uma complexidade um pouco grande. Essa inteligência de criptografia com a chave privada, dependendo da infraestrutura que você tem, pode ter um custo operacional grande. Então normalmente aqui na Sensedia, nos nossos projetos, ou do que a gente vê de mercado, a estratégia simétrica é muito aceita, porém usado em determinadas operações. Não é usado para tudo. E a estratégia de criptografia simétrica é mais utilizada, porém com o cuidado de não expor a chave, porque a mesma chave que criptografa é a chave que decriptografa. Então é preciso tomar cuidado.

Uma estratégia pouco utilizada, e eu acho bem interessante que seja utilizada, e é fácil, é você usar umaestratégia de único request ID. Ele protege o teu conteúdo, do famoso man in the middle. O que seria o man in the middle? Seria você trafegar a sua informação, o teu back-end receber a informação, né? Representado pela camada de software, aqui no meu desenho. Ele recebe a informação, só que de alguma forma, que não vem ao caso, esse payload foi interceptado. Provavelmente na origem, porque o túnel é protegido para HTTPS, como eu falei lá no começo. Ele foi interceptado antes da sua transmissão, mas foi transmitido. O hacker, enfim, a pessoa má intencionada que pegou esse pacote, ele resubmete, porém, alterando algumas informações. Usando a estratégia de unique request ID, né? Que tem também que tomar muito cuidado com esse ID. Ele é uma maneira de você garantir a unicidade do seu request. Então, você faz o request com a tua unique request ID, a tua camada de software ou teu gateway, ou teu firewall, ele valida que aquela chave, aquele ID, é daquela transação. E quando alguém tentar fazer a mesma transação, ou a transação similar, com o ID já utilizado, ele não vai permitir, porque já foi utilizado. É de um tiro só. Então, isso é uma solução muito simples, que pode resolver vários pepinos, e o custo operacional de processamento aqui é bem simples.

Ah, Fabrício, como eu trafego a parte de ID? O ID pode ser fornecido pela camada de back-end para o app, de forma segura. Pode até usar uma estratégia de criptografia para transacionar esse ID. Mas, ou o app, a camada de consumidor, ele sabe como gerar esse ID. E o software, ele sabe identificar se aquele ID foi gerado pelo app, para garantir a unicidade. Então, tudo isso em segurança e a comodidade que você quer ter. Existem soluções de mercado, existem frameworks para isso. É bem rápido você implementar essa parte.

Bom, passei pela parte de consumo de dado, a parte de exposição de dados, toda a parte de túnel, da comunicação, que eu pus no nome de canal, a parte de autenticação, a parte de autorização plano, a parte do dado em si, criptografia, unicidade de requests. Tudo bem, eu tenho várias estratégias, cada estratégia com a sua responsabilidade, mas e aí? Como que eu gerencio tudo isso? A melhor estratégia é você ter um pipeline, que faz toda a garantia de desenvolvimento da forma adequada do qual você definiu, que você é dono do pipeline, usando a estratégia de DevSecOps. Muitos falam DevSecOps. Por quê? Porque os sistemas evoluem. Então, você teve um sistema mais simples, ele evoluiu para uma natureza on-demand, via infraestrutura, que é o tal do monolito. Ele evoluiu para a parte de containerização, ele evoluiu para a parte de CI-CD automatizado com pipeline, ele evoluiu para a parte de advanced deploy com customizações, e agora a gente está no microserviço e vai evoluir ainda mais. Então, o seu legado evolui, então você tem que estar preparado que, conforme todo o seu desenvolvimento evolua, ele siga os seus padrões de segurança.

Muita gente usa o conceito de DevOps, mas o DevOps só garante a parte de desenvolvimento e a parte operacional do que foi instalado. Por isso que eu trouxe o DevSecOps. É você colocar no seu pipeline de desenvolvimento e operacional a camada de segurança também. Isso é muito importante.

E como você implementa a sua parte de DevSecOps? Bom, no Dev, para melhorar a comodidade, lembra dos três porquinhos? Das casinhas dos três porquinhos? Para melhorar a comodidade do seu consumidor na camada de Dev, é altamente recomendado você gerar uma documentação rica, ter SDKs, o que seria SDK? Seriam pequenas partes de software de várias linguagens. Eu tenho consumidores que é Java, C Sharp, JavaScript, Python, Node. Tudo bem, crie SDKs, exemplos de códigos que implementam uma obrigatoriedade da tua definição de segurança. É a melhor estratégia, porque aí a pessoa

pega aquele código e já começa a usar a tua solução, já consegue trafegar para todas as suas estratégias de desenvolvimento. A tua solução já consegue trafegar para todas as suas estratégias de desenvolvimento que você defina. Outra estratégia muito

importante, que também é uma responsabilidade de dev, é você separar também toda a tua camada de integração. Hoje ainda vemos muito no mercado, não tão os grandes, mas os médios e pequenos, não vai para uma exposição gerenciada por um API Gateway. No mínimo um API Gateway, tá? Existem soluções de mercados open source, que vocês podem ir para essa linha, existe soluções de mercado on demand, que usa o conceito de SaaS, que é por faixa de consumo, e no primeiro momento eu já coloco um Gateway na comunicação do meu consumidor com o meu backend. Então é a primeira coisa que eu acho que vocês têm que habilitar na tua solução.

E um ponto muito importante, o Gateway é responsável pelos requisitos não funcionais. O que seria isso? Toda a parte de autenticação e autorização não é uma responsabilidade do teu software, do teu backend. Ele é uma responsabilidade do teu Gateway. Passa essa responsabilidade do teu Gateway. Porque somente o seu Gateway tem acesso ao teu backend. Então isso é muito importante. Ah, mas eu vou jogar responsabilidade de negócio em cima do meu Gateway. É possível? Eu faço isso? Ok. Porém, só em casos emergenciais ou com previsibilidade de tirar requisitos funcionais do Gateway para jogar para o software, o software é responsável por isso. Ele também aumenta na rastreadibilidade, identificação dos consumidores, a parte de troubleshooting, caso tenha algum erro, monitoramento de consumo.

Temos cases aqui na Sensedia de Black Friday ou algumas empresas que a gente atende da parte de venda de ingresso, pré-venda, com alto grau de acesso sazonalizado e em vez de escalar a parte de software ou até modernizar a infraestrutura ou o software, o tal do monolito, a gente simplesmente coloca regras de rate limit aqui, rapidamente, protegendo o teu software. Então o Gateway tem que ser responsável pelos requisitos não funcionais e é o que eu recomendo altamente, ficar entre o teu consumidor e a tua infraestrutura, o teu software.

Ah, esse aqui é um exemplo de uma visão do Gateway, por acaso da SimSídia, né? Eu consigo rapidamente, na minha camada de request, colocar o que a gente chama de interceptors, né? Que esses interceptors, ele injeta complexidades de segurança. Por exemplo, quero fazer uma proteção de gestão de SQL, XSS, quero fazer uma regra de rate limit, quero colocar nessa camada a minha parte de OAuth, eu quero fazer parte de credential ou até mesmo o meu Gateway possibilitar eu desenvolver pequenos trechos de código, tanto em JavaScript quanto em Java, tá? No caso, é o que a SimSídia utiliza aqui na nossa solução. Tem outros que utilizam outras linguagens, mas isso aqui já atende, JavaScript já atende, sei lá, 95% dos interceptors que eu gero customizado. O Java seria uma complexidade maior, também roda muito bem aqui na parte da plataforma.

Detalhe, o requisito não funcional, ou ilustrado aqui como interceptors, eles não podem onerar a tua transação, tá? Tudo isso aqui tem que durar uma ou duas, toda a transação, né? De request, response, eu tô falando de uma integração síncrona, ele tem que levar mais ou menos um ou dois segundos, tá? O seu backend tem que ficar muito rápido e os interceptors não tem que ser o ofensor da transação. Isso a gente consegue ver tudo no log.

Ainda em dev, é a parte de CI e CD. Isso aqui é um exemplo que eu trouxe, trouxe em GIF pra ficar mais fácil de ilustrar. Use o CI e CD, tá? E use não em produção apenas, use em toda a sua esteira de desenvolvimento, tanto de dev quanto de QA e automatize os processos, tá? Por mais que você altere apenas um backend de vocês, tenha os testes muito bem definidos e atualizados, do qual você altere uma operação e você rode todo o seu stack de testes pra garantir que mesmo com aquelaalteração você não prejudicou todo o seu ambiente. Então isso eu recomendo fortemente. Hoje a automatização de testes e executáveis de forma periódica, e eu estou falando não uma vez por semana, eu estou falando de hora em hora talvez, dependendo do quanto você desenvolve ou de quanta dependência você tem de terceiros.

Por exemplo, talvez você tenha uma operação que para calcular a distância de uma venda de um determinado produto, você usa um back-end dos correios. Você tem que monitorar os seus parceiros, os seus back-ends. E o correio, se é teu back-end, você tem que monitorar ele.

Então, aqui na Sensedia a gente tem alguns casos, por exemplo, a parte de OpenBank, OpenInsurance, do qual alguns back-ends do OpenBank estão no Bacen, do OpenInsurance está na Susep. E aí eu tenho que rodar testes da OpenID de segurança. A gente roda no mínimo uma vez por dia. No mínimo. Para garantir que está tudo ok. Mesmo não alterando o meu código. E se eu alterar o meu código, com certeza é importante eu fazer o teste integrado de toda a minha solução. Usando bem essas stacks de testar, baixar o código, compilar, testar e publicar. E se deu errado, gerar os alertas que deu errado.

Bom, falei de dev, né? Agora a parte de segurança. Eu garanti toda a parte do meu dev, agora na parte de segurança, tenho que garantir que eu estou usando da forma correta no cenário correto. Então, no meu pipeline, e aqui nesse desenho eu tenho uma camada de análise de segurança, é importantíssimo no seu pipeline você validar se aquela exposição de dados está utilizando a estratégia de segurança correta.

Então, o SEC, essa camada de SEC, além da definição, você tem que automatizar a governança para garantir que você está usando todas as estratégias de segurança na exposição correta. Isso é muito importante. Tem que automatizar, não faz sentido você fazer isso de forma manual. Talvez no começo, ok, mas sempre olhe nisso que pode ser automatizado. E rodar essa automatização de forma persistente.

Ah, é muito importante também, e faz parte da camada de SEC, é sempre ficar antenado nos relatórios que são publicados em diversos órgãos que analisam a segurança, as principais invasões, para ver como está ocorrendo essas invasões e analisar o seu backend, a sua infraestrutura, se está protegido dessas invasões. Então, não adianta você garantir o seu desenvolvimento se você não está antenado com o que está acontecendo. É muito importante você ficar antenado.

Um relatório que eu recomendo é o ASP. Esse aqui é de Application Security Risk, que ele só evolui o relatório se muda alguma ordem aqui do top 10, ou entra um novo. Então, 2021 foi o último que saiu. E o de API Security, 2019 foi o último que saiu. Então, olha todos os itens e verifique como você resolve cada item dentro da sua solução de disposição. Importantíssimo. Não só testar, mas também garantir que você está protegido com os últimos riscos identificados pelo mercado.

Fale com seus clientes, fale com seus parceiros, fale e enxergue o mercado e analise. Inclusive, existe até um conceito de MISP, que é um repositório de riscos que você pode ver esses relatórios e analisar. Pô, eu tenho esse problema aqui na minha infraestrutura e vou saber o quanto isso os hackers ou as pessoas maliciosas estão explorando. Então, isso é muito importante. Às vezes nem é explorado, mas coloca no teu débito técnico para você avaliar. Então, isso é muito importante.

E por fim, a parte operacional. Deve desenvolver da forma correta. SEC, garantir que você está com os últimos proteções de mercado, saber como o mercado está sendo invadido e garantir que toda a sua solução está sendo desenvolvida da forma que foi definida de segurança.

E aí você tem a parte operacional. A parte operacional é desenvolva ou disponibilize um portal do desenvolvedor para os seus consumidores. E esse portal do desenvolvedor pode ler toda a documentação. Isso aqui é alguns exemplos de portais de desenvolvedores disponibilizados pela Sensedia, dos nossos clientes. Então, disponibilize o portal do desenvolvedor. Lembra que eu mencionei da parte do SDK, que ajuda o seu time de desenvolvimento na camada de consumidor a desenvolver aquela complexidade mais rápida de segurança, coloque aqui esses SDKs para download. Então, use o seu DevPortal para poder expor essas informações. Disponibilize relatórios, disponibilize logs transacionais para analisar o que está trafegando, o que está acontecendo no payload. Dê poder ao seu consumidor. O melhor é o DevPortal.

A gente usa muito o conceito no DevPortal de self-service, que ele entra, ele consegue ver as APIs, ele consegue gerar uma credencial, consegue gerar um token e consegue consumir, obviamente, em sandboxes. E depois que está tudo ok, aí você fala, beleza, agora eu vou te promover a usar as minhas backends de produção. Então, isso é muito utilizado ultimamente e é um poder muito bom de organização, não só para o teu parceiro externo, mas também para os seus clientes internos. Isso também é importante.

A parte operacional, como eu mencionei, você ter gráficos real-time ou próximos de real-time, a gente chama de near real-time, os gráficos de comportamento, também a visualização de um status page da tua solução. Quantas requests realmente está tudo ok? Por exemplo, tem um milhão de requests e 5% deu problema. Deu problema de client ou deu problema de server? 5% é aceitável. Então, é legal você expor para o teu parceiro interno ou externo que está ok, está com a saúde boa. Isso é bem bacana e é um feedback bem bacana para as pessoas, para as empresas que utilizam o teu back-end.

Outro ponto é você, de alguma forma, isso aqui é um exemplo da plataforma da Sensedia, do seu parceiro ou do teu time operacional de back-end, ele conseguir, de uma forma muito rápida, identificar todas as transações que estão acontecendo e como eu consigo analisar o que está sendo trafegado. Aqui, eu estou até vendo aqui, não tem nenhum erro, são todas as transações saudáveis. Tem um 422 aqui, mas é muito importante você analisar o seu tráfego no detalhe. Não só analisar, mas também gerar insights. Normalmente, as plataformas de Gator, isso aqui tudo o Gator oferece, ela faz uma análise, lembra que o nosso foco é requisito não funcional, né? Então, isso aqui são análises de requisitos não funcionais para saber se a exposição das suas APIs estão saudáveis.

Então, crie dashboards. Nesse caso aqui, foram dashboards desenvolvidos em JavaScript mesmo, usando os frameworks de front, mas você pode colocar um Grafana, um Kibana, armazenar os logs no Elasticsearch, enfim, tem N ferramentas open source ou ferramentas gerenciadas por cloud que vocês podem usar e tirar esses insights aqui de uma forma bem rápida.

E, continuando na parte de análise de tráfego também, o comportamento de consumo, consome muito mais de noite do que de manhã ou de tarde. Ah, legal, então consome mais de noite, então eu vou tirar o provisionamento de uma infraestrutura e vou deixar mais de noite. Então, entenda o seu consumidor. Isso é muito importante para o operacional.

Bom, compartilhando alguns links aqui para vocês. Isso estará no descritivo do vídeo. A ideia é deixar no descritivo do vídeo, eu vou colocar até mais alguns itens, mas isso aqui é bem bacana como fonte de informação para vocês aprofundarem do que eu estou falando.

Tem um material da Sensedia. Ah, é legal acompanhar o Gartner da parte de segurança, eles dão vários insights, como o ASP também dá. Então, são os dois OASP aqui que eu mostrei. E, principalmente, a LGPD. Então, dá uma olhada muito na legislação, porque vocês podem ser punidos assim, sem saber. Porque você expõe um dado e aí vem todo aquele processo e a LGPD pega bem forte nisso. Então, proteja o seu dado, porque talvez não é só uma exposição. Você pode levar um processo na sua parte.

Bom, estou encerrando aqui. Por ser um vídeo, não dá para interagir com dúvidas, mas, pessoal, é isso. Tudo que eu mostrei aqui para vocês são itens essenciais. Então, utiliza essa apresentação como se fosse um checklist para saber se está realmente tudo ok. E, se não está ok? Tá realmente tudo ok? E se não tá ok, é um título lixo pra vocês poderem, pô, eu vou analisar mais a fundo essa parte de canal. Então, dê uma olhada mais com carinho em cada pilar que a gente explicou. Veja se as estratégias que a gente colocou aqui de DevSecOps é uma realidade pra vocês ou se estão muito longe disso.

Enfim, a Sensedia tá aí, pode apoiar vocês, principalmente com plataforma, a gente tem Gator pra isso. A gente tem também uma camada de Service Mesh pra proteger a comunicação interna dos seus micro serviços. Tem todos esses insights de relatórios, enfim. É isso que eu queria mostrar.

Muito obrigado pela presença de todos. Tá o meu contato aqui, fiquem à vontade em entrar em contato, pode mandar e-mail pra mim. Eu compartilho o material, quase sempre eu tô nos fóruns e nos grupos de trabalho, mais recentemente de Open Insurance e Open Banking, pra auxiliar nessa parte de segurança. Muito obrigado e até o próximo vídeo, pessoal.

‍