[UFMS Digital] Projeto Integrador de Tecnologia da Informação III - Módulo 3 - Unidade 1

[Música] Olá, seja bem-vindo ao nosso terceiro módulo da disciplina de projeto integrador de tecnologia da informação 3. Eu sou o professor Woodson Silvo Borges e nesse módulo nós abordaremos boas práticas no desenvolvimento de serviços web. Bom, nos módulos anteriores, nós abordamos técnicas de verificação, validação e teste e nesse módulo nós daremos continuidade a à apresentação, aplicação de técnicas focado na melhoria da qualidade dos nossos serviços, dos nossos artefatos e tudo que construímos ao longo do processo de desenvolvimento.

Bom, especificamente nessa videoaula, nessa unidade, você verá um pouco mais sobre desenvolvimento seguro. Segurança no desenvolvimento software é um tópico extremamente importante, principalmente no dia, nos dias de hoje, onde vemos ali notícias quase que frequentes, né, na nos meios de comunicação sobre ali invasões, roubos de dados ou até mesmo questões relacionadas à segurança que comprometem a informação dos clientes e naturalmente comprometem também a credibilidade das empresas. E isso cabe a você como desenvolvedor e também como equipe, né, agir para mitigar esses problemas, esses riscos que eventualmente venham a surgir.

Bom, então o contexto que traremos, que discutiremos nessa videoaula é de fato sobre como podemos tornar um desenvolvimento de software seguro, né? Não, note que você nesse momento não está lidando somente com ferramentas. de segurança para sistemas, né?

O foco aqui é evoluir, trazer toda esse todo esse processo de segurança, né, que seja aplicado durante todas as etapas de desenvolvimento. Então, a ideia é que você pense em segurança desde quando você começa a trabalhar naquele sistema, né? Você individualmente, você no time, você como empresa deve sempre incluir elementos, né, critérios de segurança no desenvolvimento.

Por quê? Nós sabemos que construir software seguro, né, e é um termo, uma expressão bastante importante, exige conhecimento básico, né, ali em princípios de segurança. Então, o que nós abordaremos nessa videoaula e esperamos que você aplique dentro do projeto que você está desenvolvendo para o seu curso, né, é que você leve em consideração princípios de segurança também no desenvolvimento.

O objetivo principal aqui é em manter a confidencialidade, integridade e disponibilidade dos recursos de informação para permitir que as operações que o seu sistema vem oferecer sejam eh bem-sucedidas, né? Você consiga manter todas todos esses critérios em relação às informações que o seu sistema acaba lhe dando, né? Como você bem imagina, confidencialidade significa ter acesso somente aqueles que têm permissão para acesso a determinada informação, né?

Então, informações pessoais devem ser mantidas ali acessadas somente pel aquele pel aquelas pessoas, pel aqueles agentes que têm tem permissão para acesso. Integral integridade significa ali você manter integridade dos dados, ou seja, não fazer modificações, eh, alterações que tornem aqueles dados ali não seguros, né? e disponibilidade no sentido que você deve manter essa informação disponível, mas garantindo que essa entrega vai ser feita somente para aqueles com os devidos as devidas permissões.

Bom, se o objetivo é esse, como que a gente pode alcançar dentro de um processo de desenvolvimento de software? é o a ideia, né, o propósito é simplesmente implementar controles de segurança. Então, nessa nessa videoaula, nessa aula aqui, basicamente eu vou orientá-lo a como você consegue implementar controles de segurança para permitir e garantir, né, confidencialidade, integridade e disponibilidade desses recursos de informação para os clientes da sua aplicação.

Bom, princípios de segurança podem ser aplicados em diversas camadas, tá? Então, notem, como eu havia comentado até anteriormente, né, que a gente pode aplicar princípios de segurança em diversas camadas. aplicação de mecanismos de segurança no sistema, no software, na aplicação, é uma das camadas, por assim dizer, né, que a gente pode aplicar, mas a gente pode trazer princípios de segurança para diferentes etapas e camadas de desenvolvimento também.

E eu vou trazer isso para você em breve. Contém também controles técnicos, né, para mitigar ocorrências. Então acontece que eh garantir a segurança 100% é muito difícil.

riscos sempre vão vão acontecer, né? Sempre vai existir ali um risco tal que o seu dado ou dado da sua aplicação seja basado, seja acessado indevidamente. Eh, existem agentes que são treinados justamente para invadir esses temas, né, para roubar essas informações e de certa forma lucrar ter algum benefício próprio em relação a esses dados roubados, né?

E nós como desenvolvedores devemos trabalhar para mitigar, né, essas essas ocorrências, ou seja, diminuir as chances que esses acessos indevidos acontecem, né, essas esses riscos vem acontecer, assim como se acontecer, o que que nós podemos fazer para mitigar os impactos dessas ocorrências? Essa é a ideia e principalmente, né, trabalhar ali sobre como podemos atuar para pelo menos vulnerabilidades comuns não ocorram dentro do nosso processo. Bom, existem um conjunto de vulnerabilidades, né, que são bastante comuns de serem eh serem exploradas, né, o que a gente sempre tem que ficar atento e evitar.

O foco do desenvolvimento seguro é justamente proteger o negócio, né, o o core do negócio, o coração do negócio da sua aplicação, contra riscos que a gente chama de inaceitáveis. Inaceitáveis é todo aquele risco que nós sabemos que existe e a gente de certa forma acaba negligenciando, né? traremos ali algum alguns exemplos aqui, discutiremos um pouquinho mais adiante, mas riscos inaceitáveis são aqueles riscos conhecidos, mas que deliberadamente ou até por outros motivos, você como desenvolvedor ou os seus colegas como desenvolvedores e as empresas e outros agentes de desenvolvimento acabam ignorando e isso traz um risco inerente para os seus clientes.

Bom, então como que nós podemos definir o que que é um risco, né? Como foi mencionado, de riscos inaceitáveis. O risco a gente pode definir como um agente de ameaça, alguém que tem a intenção de ter acesso a essa informação, né?

Que interage com o sistema, por exemplo, o sistema que está sendo desenvolvido, que você está dando manutenção, que você está trabalhando ou que você eventualmente até usa, né? no qual pode haver uma vulnerabilidade latente, ou seja, tem uma vulnerabilidade naquele sistema que eventualmente nem é do seu próprio conhecimento e que pode ser explorada e causar um impacto no seu negócio, né? Um impacto aqui pode ser em diversas dimensões, seja um impacto financeiro, um um impacto relacionado à própria credibilidade da do time.

E essa é uma definição de riscos, né? Observe aqui que nós temos alguns temas importantes, como o agente, que é justamente aquele que ameaça a segurança do do seu sistema. O seu sistema é a aplicação que está sendo desenvolvida ou mantida, né?

é o que gera ali um valor pro seu negócio. Vulnerabilidade latente é uma brecha, né, que a sua aplicação possui, que uma esse agente pode pode de fato explorar, né, para para ter acesso às informações, assim como foi mencionado por esses por essas marcações e o impacto é de fato o evento ali que ocorre a partir do do acesso indevido a essa informação. Bom, como que seria um exemplo, tá?

Um exemplo bem simples aqui. Um ladrão, né, um agente, né, um ladrão de carros, passa por um estacionamento de carros verificando nos carros presentes. Então, carros presentes é justamente o sistema procurando por portas destrancadas, né?

Portas destrancadas seria a vulnerabilidade. E quando encontra, abre a porta, né? né?

Então, abrir a porta é a exploração e leva para si o que está dentro do carro, né? Então, o levar o que está dentro do carro a um impacto. Basicamente essa é uma ideia bastante genérica que pode ser produzida para diversos outros ambientes, assim como a gente pode adaptar facilmente esse cenário para dentro de uma aplicação de software, correto?

Bom, então como que nós podemos começar a trabalhar dentro do desenvolvimento seguro, né? como evitar esses riscos, principalmente os riscos inac inacitáveis, né? Nós temos elementos adicionais que precisam ser integrados no desenvolvimento software.

Então, além, né, de considerar aqueles aspectos de verificação e validação da perspectiva da qualidade de atender aos desejos do usuário, nós também devemos considerar os aspectos de segurança, né, que por muitas vezes é um desejo dos nossos clientes também. Então, para atender esses princípios de desenvolvimento seguro, é importante que a gente considere elementos adicionais durante o processo de desenvolvimento, ou seja, sempre integrar, né, assim como nós temos discutido bastante nessa nessa disciplina, a ideia aqui é ser uma disciplina integradora tal que a gente adiciona esses elementos que vão permitir a construção de software seguro e alinhados às necessidades dos clientes, né? Em geral são requisitos, né, de segurança e casos de abuso, né, no sentido que que são relacionadas a segurança da informação.

Guias, né, o material ali que guia o desenvolvedor pode ser elaborado para ajudar na identificação e abordagem de requisitos e cenários de ataque. Então, o cenário de desenvolvimento seguro tem se tornado cada vez tão importante que estão sim surgindo guias, materiais que apoiam os times no desenvolvimento de software com foco na segurança da informação. Na web, controles no cliente oferecem pouco nenhum benefício de segurança.

Então, se você, como desenvolvedor, pensa em adicionar algum mecanismo de segurança somente lá na interface do seu usuário, saiba, né, que esse tipo de controle só do lado do cliente não é seguro, não garante a segurança da informação. É necessário que a gente adote controles de segurança nas diversas camadas que foram mencionadas, né? Então, por exemplo, você tem que proteger o seu serviço que roda em um servidor remoto, você tem que proteger a infraestrutura onde a sua aplicação tá hospedada, você tem que proteger ali diversas camadas para que de fato você obtenha ali uma segurança da informação na sua aplicação.

Eh, falhas de segurança de software podem ser introduzidas em qualquer fase do ciclo de desenvolvimento. Isso aqui é importante destacar, né? no sentido que essas falhas no desenvolvimento não é só um erro de código, não só é uma linha, não é só uma configuração, mas também faz parte de todo um processo, né?

como, por exemplo, não identificação das necessidades no início. Então, quando você foi lá e conversou com os seus clientes, eh, naturalmente pode ser que esse tópico não tenha sido devidamente discutido e isso não foi mapeado como um dos requisitos da sua aplicação. Então, naquele momento de mapeamento de requisitos, já pode haver um um problema, né?

já pode ter uma falha de segurança, arquiteturas, né? Hoje em dia você tem ali diversos estilos arquiteturais que podem ser adotados, né? Eh, modelos arquiteturais.

Então, que ao adotá-lo cegamente, né, ou simplesmente copiar, seguir ali informações genéricas, você pode acabar trazendo eh alguma arquitetura, algum elemento ali que torna a sua aplicação insegura por meio da do projeto arquitetural da sua aplicação. práticas de codificação ruins, por exemplo, copiar e colar muito código, reuso indevido, né, sem uma análise devida também pode introduzir facilmente muito problema. E hoje em dia, eu trago até um exemplo que já está sendo relatado, por exemplo, com o uso de ferramentas de IA para o apoio a desenvolvedores, está havendo ali um aumento de duplicidade de código muito grande.

E essa duplicidade, a partir de o reuso, né, de códigos ou trechos das próprias ferramentas, isso acaba introduzindo muitos problemas, inclusive podendo implicar ali em problemas de segurança. Então você tem que ficar atento na codificação também, implantação de modo apropriado, né? Depois que você termina de fazer o seu sistema, quando você vai implantar, colocar isso numa infraestrutura física ou até mesmo em nuvem, é importante que você configure esse ambiente de forma adequada, porque um intruso poderia simplesmente adentrar, né, no nesse ambiente e pegar, coletar os dados sem mesmo passar pela sua aplicação.

E além disso, um um último risco, né, envolvido aqui, tá na inserção durante manutenções. Então, um software evolui ao longo do tempo, ele sofre manutenções, manutenções evolutivas, cognitivas. Logo, é importante também ficarmos atentos ali a a o que que a gente tá fazendo, o que que a gente tá inserindo no sistema para que a gente não insira nenhuma prchaça.

Bom, então como eu havia comentado, a segurança pode ser trabalhado em diversas camadas, né, dentro de um processo de desenvolvimento. A segurança deve ser trabalhado nessas diversas camadas que não estão limitadas a mas eu vou trazer algumas aqui para você como exemplo. infraestrutura, como acabei de comentar, um ambiente em onde você vai implantar o seu sistema, o seu time vai implantar seu sistema, é importante ser protegido, protegido não fisicamente, mas até mesmo virtualmente, né?

Existem algumas ações que podemos tomar e eu vou trazer alguns exemplos nos próximos slides. A aplicação, o sistema, existem mecanismos que podem ser implementados ali para garantir a segurança na aplicação. Loguditoria, né?

É importante você ter ali o registro de informações porque eventualmente se o seu seu sistema for invadido, tiver alguma ação indevida, você consegue ali de certa forma recuperar ou refazer os caminhos que o invasor acabou acabou usando, né? Existem muitas ferramentas que nos auxiliam no na implantação, né, implementação de de desenvolvimento secou. Bom, nós também podemos atuar ali sobre ambientes.

Ambientes eh muitas vezes são utilizados para isolar, né, eh, ambientes de trabalho, por exemplo, desenvolvimento, produção. No ambiente de desenvolvimento, nós tipicamente utilizamos ele de forma mais flexível, acessível a todosos desenvolvedores, enquanto ambiente de produção ambiente mais restrito de acesso, né? Pouquíssimas pessoas podem ter acesso, tem mecanismos mais ou mais elaborados, né, de proteção, inclusive pelos times.

Nós podemos atuar também na camada de equipe, porque os desenvolvedores, você como desenvolvedor também é responsável pela segurança do sistema. Logo, você pode ter ali uma credencial de acesso que permite acesso a determinados dados e você é responsável também por manter essa credencial segura. API, né, aplicações tipicamente são compostas por serviços web eh disponíveis por meio de APIs.

Então, proteger essas APIs e, por fim, também erros e exceções, né? A toda aplicação pode apresentar problemas, né, durante a execução. E é importante lidar com esses erros e tratar de exceções ali de forma adequada.

Não, a gente não pode expor uma quantidade de erros ali e para para pessoas externas, uma vez que eles podem ter informações da estrutura interna da aplicação. Logo, nós devemos ter bastante cuidado. Bom, aqui eu trago uma tabela disponibilizada pelo OASP.

OSP é uma organização voltada a segurança no desenvolvimento de software, onde ele faz um comparativo, né, das principais segur riscos de segurança, né, de 2017 e 2021, junto com a sua evolução, né, como que mudou. Eh, só ressaltando que para 2025 está prevista uma nova versão, né, então deveremos ter uma atualização nesses top 10 riscos. Contudo, é importante refletirmos aqui porque muitos desses riscos se mantém.

Então, por exemplo, em 2017, o principal risco era injection ou injeção, né? Eh, você possivelmente já ouviu falar ali sobre SQL Injection, que é um tipo de injeção, né, aonde pessoas mal intencionadas poderiam colocar ali código SQL dentro de uma entrada do seu sistema e se o seu sistema não lida adequadamente com esse código que não deveria ser um código, né, se não faz o escape, né, descaracteriza os comandos SQL, isola a entrada de fato, ele poderia executar instruções ções, né, de consulta dos seus dados a partir da sua própria aplicação. Isso é, isso foi muito comum em 2017, enquanto em 2021 injeção, né, assim como SL injection, já não era o principal problema, porque nós temos muita muitas ferramentas atuais que nos permitem ali lidar adequadamente com isso.

Diversos frameworks modernos lidam com isso automaticamente, diminuindo os riscos, né? Por outro lado, nós temos ali que Broken Access Control foi ali o top um de 2021, o risco principal de 2021, aonde usuários maliciosos, né, buscavam quebrar, né, o controle de acesso da sua aplicação de autenticação. Então, por muitas vezes desenvolvedores desatentos, usando ali de uma estratégia, né, de autenticação bem fraca, acabam introduzindo ali um risco de segurança deliberado na na aplicação.

E isso deve ficar ali bem atento ali quanto esses riscos que podem ocorrer. Seguido aqui por falhas de criptografia importante, né, para que se eventualmente os dados sejam vazados. eh os dados não sejam lidos facilmente pelo pelos invasores.

Eh, aqui o design, que é segurança de insegurança por por projeto, né, por design. Ou seja, quando você projeta a aplicação, devemos considerar questão de segurança também, né, de projeto. E observe aqui que um novo risco, né, mapeado.

Então, o a segurança deve ser considerada desde os primórdios de desenvolvimento, desde as etapas iniciais, você deve considerar questões de segurança seguido de eh erros de configuração, né, de segurança. Então não basta simplesmente você pegar uma uma ferramenta e utilizar no seu sistema, pois eventualmente será necessário que você adapte as configurações de segurança para sua aplicação. Eh, vulnerabilidades e componentes desatualizados.

É muito comum, né, que empresas desenvolvam sistemas ali por um longo período e acabam utilizando ali de componentes, né, bibliotecas, outros sistemas antigos, né, desatuados. que tem vulnerabilidades. Se você ou seu time ou sua empresa tem o costume de manter essas essas esses componentes desatualizados, a aquelas pessoas mal intencionadas mal intencionadas podem eventualmente utilizar dessas brechas componentes para roubar as informações da sua aplicação.

eh falhas relacionadas à autenticação, né, identificação, software deita integridade de dados também é uma falha que que foi mapeada, eh, log e monitoramento de segurança, né, pois e eventualmente problemas podem acontecer e é muito comum que times não adotem mecanismos de monitoramento e segurança. Então, depois que uma falha ocorre, em geral é bem difícil inclusive encontrar quem fez aquele aquela aquela ação, né? Então tem que temos que ficar atento.

E por fim, aqui é até um problema de segurança relacionado a novas tecnologias. Então quando as quando novas tecnologias surgem, é comum também que falhas de segurança relacionadas também surjam, né? Atualmente nós temos aqui diversos frameworks, né, como React, Angular, eh, e entre outros frameworks que permitem a construção de aplicações web também utilizando do Service Service H request for, que é um tipo ali de requisição do lado do servidor.

Então, esse tipo de de vulnerabilidade também acabou aparecendo mais recentemente. Bom, então a partir desses riscos de segurança, como que a gente pode começar a trabalhar para trazer ali mecanismos, políticas ou até mesmo ferramentas que ajudem a lidar, né, com os riscos de segurança envolvida envolvidas nessas diversas camadas que foram apresentadas, como, por exemplo, infraestrutura, né? Existem algumas recomendações, eu vou trazer algumas para você aqui discutir tal que pode ser adotado eventualmente dentro do próprio projeto que você está desenvolvendo, caso seja aplicável, né?

Por exemplo, primeiro, uso de criptografia nos dados. Como eu disse para você anteriormente, riscos são inerentes, né, de qualquer atividade. Dentro do desenvolvimento software, eh, os dados serem roubados é um risco que estamos sujeitos, né?

Mas eventualmente alguns alguns dados podem ser expostos, né, e outros dados, principalmente aqueles pessoais, eh, e críticos ali, não podem ser expostos. O uso de criptografia pode ajudar bastante nesses cenários, porque eventualmente essas pessoas com maliciosas, né, com acesso a esses dados, podem ter os dados, mas podem não conseguir, né, fazer a leitura de de criptografar, né, esses dados que tiveram acesso. Então, uso de criptografia pode ajudar criptografia na infraestrutura, né?

Por exemplo, vários bancos de dados disponíveis permitem e oferecem ferramentas de criptografia para que os dados sejam armazenados já com alguma criptografia pré-configurada. E é uma das opções, proteção de ambientes internos é importante, então é comum que a gente crie ambientes, por exemplo, de desenvolvimento. Se um agente mancioso tem acesso a um ambiente de desenvolvimento, já que os desenvolvedores tendem a ser negligentes, né, quanto à proteção desse tipo de ambiente, ele pode analisar o seu ambiente de desenvolvimento e a partir disso estabelecer, né, gerar eh alguma alguma estratégia de invasão no seu ambiente de produção.

Então, proteger ambientes de desenvolvimento com as informações, uso, por exemplo, de VPNs, né, que é muito comum em diversos times que t seus membros trabalhando remotamente, pode ser uma forma de de proteção decente, né, dos dados e do sistema e do processo como um todo. Não usar componentes com vulnerabilidades conhecidas, CVS. Poxa, normalmente para infraestrutura é comum o uso de servidores de aplicação.

Quando nós vamos utilizar o um servidor, opte pelo uso daqueles pel aquelas aplicações, né, pel aqueles servidores de aplicação que não possuem vulnerabilidades conhecidas. Existe uma lista ali que podemos consultar e fazer essa análise, né? Se você usa algum componente, algum servidor, por exemplo, muito antigo, desatuado, pessoas maliciosas facilmente podem ter acesso à sua aplicação a partir de problemas que estão presentes nesse tipo de de aplicação, né?

Então, basicamente, ficando de olho ali nas vulnerabilidades conhecidas dos componentes, é importante. Existiria um conjunto de diversos outros eh métodos e recomendações, né? podemos adotar, mas a ideia aqui abordarmos um pouco sobre diferentes camadas, como por exemplo na camada de aplicação.

Na nossa aplicação ou na aplicação que você está desenvolvendo, busque utilizar, por exemplo, bibliotecas sempre atualizadas, né? Por atualizadas, não necessariamente é a última ah disponível, pois eventualmente podem ser também bibliotecas que estão ali no estado do beta, ainda não totalmente estáveis, né? Mas são aquelas que estão estáveis suficientes e tem um suporte ainda ativo, né, versões LTS, entre outras.

Busque sempre ali atualizar as bibliotecas quando possível. É um, é uma recomendação importante para aplicações. Eh, o uso de autenticação em múltiplos fatores ajuda na proteção, né?

Então, para que não vaze ali uma senha a partir de uma lista conhecida, importante incentivar e disponibilizar esse meio de autenticação para os seus usuários. Por exemplo, nas principais aplicações que eu pessoalmente uso, eu sempre habilito autenticações, autenticação em dois fatores ou múltiplos fatores. Cuidado no armazenamento e compartilhamento de senhas, tá?

Isso aqui é uma dica muito muito básica, mas que ocorre, né? Então, não guarde senhas, não compartilhe senhas em arquivos que estejam eventualmente em pucks, né, em em compartilhamentos ali públicos, tal, que outros podem ter acesso. Existem diversos trabalhos na literatura e na indústria, por exemplo, de pessoas que salvam senhas em arquivos e acabam salvando isso em dados públicos, mandam para um repositório público no KitHub.

E isso facilita o trabalho de pessoas, né, com que têm intenção de ter acesso ao indevido. Então, cuidado, armazenamento comportamento também é importante. Criação de políticas de senhas, né?

Eh, incentivar ali senhas seguras, né, para não permitir senhas de aniversário, senhas 1 2 3 4 5 e essas senhas presentes em todas listas, né, que são vazadas. Então, defina uma política de senha segura, né? Sua senha deve conter X caracteres, né?

Sendo eles, tá, o numeral, caracter especial e tudo mais. Criação dessas políticas de senha é importante e diversas aplicações têm adotado esse tipo de estratégia, né? Proteção contra requisições exaustivas.

Então, proteja sua aplicação para que ela não permita que usuários lancem ali ataques de requisições exaustivas, tá? No sentido de sair fazendo requisições deliberadamente para toda a sua aplicação ou diversas vezes, né? Isso pode causar indisponibilidade ou até mesmo ele pode ter um acesso indevido.

Existem mecanismos ali que identificam esse comportamento e começam a adicionar, por exemplo, timeouts, né? tal que a pessoa pode fazer outras requisições em tanto tempo. Ou seja, existem mecanismos para lidar com esse tipo de ação e fazer gestão efetiva da sessão de usuário, tá?

que é outra questão importante. Muitas vezes você pode permitir os usuários fazerem login na sua aplicação, mas é importante fazer o gestão dessa sessão, ou seja, fazer um com que a sessão do usuário tenha um tempo definido, por exemplo, um dia, uma hora, uma semana, definir esse tempo máximo. Assim que o usuário sair dessa aplicação, encerre a sessão também do lado do servidor, não somente do lado do cliente.

Essas ações ali ajudam a aumentar a segurança da aplicação. Em relação a log e auditoria, monitoramento e respostas a incidentes é importante, né? O monitoramento contínuo da aplicação é importante no sentido de você verificar ali os acessos na sua aplicação e responder a incidentes de forma rápida.

É crítico manter registros de acesso de usuário, né, dos usuários, permite você ter um controle sobre como foi feito o acesso aos dados, à alterações e mantendo ali uma rastreabilidade, né, dessas operações. Então, log e a auditoria são elementos extremamente críticos, principalmente para lidar ali com o pós-acontecimento de alguns riscos. Mais uma vez, tá?

proteção 100% contra acessos indevido. Nenhuma, nenhuma empresa, nenhuma equipe consegue lidar, mas a gente busca sempre ter uma cobertura ali de ter esses riscos o maior possível. Se acontecer, logo e auditoria são ações extremamente importantes, né, para lidar com o pós ocorrido, pois eventualmente você pode ter que prestar informações ali para agentes federais, né, relacionados à segurança da informação.

Nós temos diversas ferramentas disponíveis, né? Existem ferramentas de teste de segurança. Então, no módulo anterior, onde nós tratamos ali de testes, né, inclusive mencionando testes de segurança, existem ali ferramentas automatizadas que ajudam a lidar com testes de segurança.

Executar processos externos também é importante. O que que é processo externo? Contrate uma empresa externa, contrate um fornecedor externo, um profissional externo para testar de forma da perspectiva da segurança, né, a aplicação, né?

Muitas vezes nós, como desenvolvedores responsáveis também pela segurança, não temos total conhecimento dos processos de segurança. Então, acreditar e também depender de processos e pessoas e agentes externos para a a segurança do no sistema também é importante. E o versionamento, claro, né, básico que de projeto e código permite também ter uma rastrabilidade, né, do dos aspectos de segurança.

Inclusive, diversas plataformas de hospedagem de código já fazem uma varredura de diversos elementos, inclusive elementos de segurança, é o que nos ajuda em relação a APIs, né? Adotar verificações de autorização também dos serviços, né? Não basta simplesmente lá no frontend, lá na na interação com o usuário fazer essas verificações.

Os serviços por trás da sua aplicação também devem fazer sempre essas verificações. Não expor dados em excesso, ou seja, exponha, retorne somente aquele dado que necessário. Seu usuário, você armazenda 15 campos de informações sobre seus usuários.

Se sua aplicação precisa usar só quatro, retorne somente essas quatro informações. Não exponha dados que não sejam extremamente importantes para pra sua aplicação. Tratar adequadamente dados de requisão.

Esse tratar adequadamente está associado, por exemplo, com SK Injection, né? Se você pega um valor que é fornecido dentro de um campo de entrada lá da sua aplicação e armazena diretamente no banco de dados, você tá correndo um risco enorme, né? Faça o tratamento.

Verificação desses dados é importante proteger contra ataques de força bruta, eh, para impedir ali que seja feito um abuso do seu serviço, né, e acabe ficando disponível. Coloque em mecanismos de controle. É importante configurar adequadamente componentes e recursos.

Então, não basta simplesmente você pegar uma ferramenta e usar diretamente. Eh, estude, analise e configure corretamente os componentes que são integrados à sua aplicação, tá? as configurações padrão tipicamente devem ser revisadas, né, e adaptadas pro contexto da sua aplicação.

Não seja cego, seja crítico quanto ao uso desses componentes de terceiro. Bom, e essas recomendações, tá, são só algumas que foram derivadas do OASP, tá? Aqui nessa apresentação está disponível para vocês o link, né, de um conjunto de recomendações muito grande ao que equipes e times de desenvolvimento podem adotar para proteção da sua aplicação, né, não somente da aplicação em si, mas de toda uma camada do processo de desenvolvimento que vai desde a concepção do do sistema até a disponibilização do sistema.

também é importante que sejam adotadas eh mecanismos, políticas de proteção para a sua aplicação. Bom, então, trazendo um pouco mais dessa discussão aqui para uma visão integradora aplicada e direcionada ao que eu espero que você utilize, que você aplique nessa, nessa disciplina, a gente pode começar destacando aqui como a incorporação de práticas de desenvolvimento seguro desde a concepção do projeto. você evidentemente já deve ter iniciado o desenvolvimento da da sua aplicação, mas nunca é tarde para incorporar essas práticas de desenvolvimento.

Então, nesse momento, você deverá adotar práticas de desenvolvimento seguro para a sua aplicação. Mas saiba que essas práticas devem ser consideradas e adotadas desde o início da concepção do projeto. Defina os requisitos de segurança desde o início do projeto.

importante, né? Faça revisões e auditorias no projeto. Então, naquele projeto de inspeção, né, de de código, você pode de fato também incluir as verificações de segurança.

Faça teste de segurança, usa ferramentas, né, automatizadas, tem várias ali disponíveis para diferentes frameorks que você pode utilizar. Bom, na próxima unidade, na unidade dois, veremos um pouco mais ali sobre documentação e questionamento, né, de serviços, visando melhorar a qualidade dos serviços da sua aplicação. As referências dessa aula estão disponíveis, mas são principalmente o livro ali de Neto, né, além das referências do OASP que eu trouxe aqui diretamente para você.

Agradeço a sua atenção e nos vemos ali no próxima unidade.