DEV Community: Thiago Bertuzzi 👨🏻‍💻

MVP Conf 2025 - OWASP API Security Top 10

Thiago Bertuzzi 👨🏻‍💻 — Wed, 29 Oct 2025 12:38:53 +0000

Fala galera,

Tudo beleza?

Sexta-feira dia 24/10/2025 tive o prazer de ter participado do MVPConf 2025, onde tive a oportunidade de palestrar sobre o tema OWASP API Security Top 10: Recomendações importantes para tornar suas APIs mais seguras.

Durante o evento, abordei como as APIs REST se tornaram peças centrais em projetos de software — sejam mobile, web ou integrações de sistemas — e que, justamente por lidarem com dados e operações críticas, estão sujeitas a uma variedade de ataques, que vão desde falhas de autorização até consumo desenfreado de recursos.

Confira aqui a apresentação

Apresentei os 10 principais vetores de risco definidos pela OWASP para APIs, com destaque para vulnerabilidades como:
- Broken Object Level Authorization (BOLA) – acesso indevido a objetos.
- Broken Authentication – falhas em autenticação e tokens.
- Unrestricted Resource Consumption – consumo ilimitado de recursos (DoS).
- Unrestricted Access to Sensitive Business Flows – exposição de fluxos de negócio sensíveis.
- Além de outros riscos como SSRF, más configurações de segurança e versionamento inadequado.
Trouxe recomendações práticas e aplicáveis no dia a dia das equipes de desenvolvimento:
- Usar IDs aleatórios ou UUIDs para evitar inferência de recursos.
- Implementar Rate Limiting e políticas de uso para prevenir abusos.
- Praticar governança de versões de API, desativando endpoints obsoletos.
- Garantir que parceiros e APIs externas também sigam boas práticas.
Reforcei a importância de integrar segurança desde o design até o monitoramento, e não tratá-la como um “passo final” do ciclo de desenvolvimento.

Durante a sessão, tivemos uma excelente interação com o público — com perguntas sobre arquiteturas .NET, APIs em nuvem, microserviços e cenários reais de ataque — o que demonstrou o quanto o tema é atual e necessário.

Como profissional que atua com desenvolvimento, arquitetura e segurança, acredito que essa palestra reforça o compromisso de elevar o nível de maturidade da comunidade técnica.

Projetos bem-sucedidos não entregam apenas funcionalidades — entregam segurança, confiabilidade e confiança. Em um mundo onde dados são o ativo mais valioso, falhar na segurança das APIs pode comprometer todo o negócio.

O MVPConf foi o palco ideal para reforçar essa mensagem ao lado de tantos profissionais incríveis, MVPs e líderes de tecnologia que também acreditam em compartilhar conhecimento.

No encerramento da palestra, destaquei a importância de fortalecer a cultura de API Security (falando dos cursos da APISec University) dentro das equipes, lembrando que a proteção das APIs é um investimento essencial para a confiança e continuidade dos sistemas modernos.

Agradeço ao time do MVPConf pela organização impecável, aos colegas palestrantes pelo alto nível técnico e, principalmente, ao público que participou e compartilhou suas experiências.

Esse tipo de troca é o que nos faz crescer como comunidade!

Obrigado a todas as 36 pessoas que apareceram na minha palestra!

Aquele abraço!

10 Dicas Basicas de Arquitetura de Código : 5 - Cuidado com integrações

Thiago Bertuzzi 👨🏻‍💻 — Wed, 09 Oct 2024 12:57:30 +0000

Fala galera,

tudo beleza?

Dando continuidade a serie de artigos sobre arquitetura (se não viu a parte 4 clique aqui), é uma pratica comum precisar integrar seu sistema com softwares, API's, frameworks de terceiros.

Porem é preciso tomar cuidado para não sujar sua arquitetura, ou ter uma dependencia tão grande de um sistema terceiro que pode acabar afetando seu próprio negocio. Dito isso, vamos dar uma olhada de como nos blidarmos e boas praticas que devemos seguir quando integramos nossos sistemas!

1 Planejamento da Arquitetura de Integração

Antes de iniciar a nossa implementação, é essencial definir como a integração com APIs e serviços externos se encaixa na arquitetura geral do software.

Algumas questões críticas que devem ser respondidas no planejamento incluem:

Qual o impacto da dependência de APIs externas na disponibilidade e desempenho do sistema?
Quais dados serão compartilhados ou consumidos?
Quais são os requisitos de segurança para a integração?
Como será a atualização e manutenção dessas integrações ao longo do tempo?

Duas abordagens comuns para integrar APIs são:

Chamadas diretas: O sistema se comunica diretamente com a API externa via HTTP/HTTPS. Ideal para integrações pontuais ou quando a latência da comunicação não é crítica.

Camada de integração intermediária: A utilização de um middleware ou um barramento de serviços que centraliza a comunicação com APIs. Essa abordagem aumenta a flexibilidade e a resiliência ao desacoplar as integrações.

2 Resiliência e Tolerância a Falhas

Eu sempre digo eu me preocupo mais quando uma API não é minha, por não ter o controle do que acontece com ela. Um dos maiores desafios ao integrar APIs de terceiros é a garantia de disponibilidade e estabilidade ( e tem algumas que da vontade de matar quem fez) . Mesmo que seu software esteja funcionando corretamente, você está à mercê de falhas externas quando depende de APIs de terceiros. Portanto, garantir que seu sistema seja resiliente a essas falhas é fundamental.

Existem algumas formas de garantir e isso se chama Resiliência , ter um sistema resiliente garante que vc se proteja e escape dessas falhas :

Timeouts e Retry: Sempre defina tempos de espera (timeouts) razoáveis para chamadas a APIs externas e implemente uma política de retentativa (retry). Dessa forma, se uma requisição falhar temporariamente, seu sistema pode tentar novamente de maneira controlada.

Circuit Breaker: O padrão circuit breaker protege o sistema de um serviço ou API que está consistentemente falhando. Se o serviço estiver fora do ar ou inoperante por um período, o circuit breaker interrompe as tentativas de comunicação até que o serviço seja restaurado.

Fallbacks: Em algumas situações, pode ser necessário um plano de contingência. Se uma API estiver indisponível, é possível fornecer uma resposta parcial ou usar dados em cache até que a API volte a funcionar.

Rate Limiting e Controle de Fluxo: Algumas APIs têm limites de uso (rate limits) impostos pelo provedor. Se seu sistema atingir esse limite, pode sofrer penalidades ou bloqueios temporários. Implementar mecanismos de controle de fluxo ajuda a evitar que esse limite seja atingido de forma inadvertida.

3 Segurança nas Integrações

Eu tenho uma seria continua que estou sempre falando de segurança e realmente isso é uma preocupação dobrada quando se integra com serviços de terceiros.

Existem algumas medidas que podemos tomar, afinal novamente eu digo : é um ambiente externo que na maioria das vezes não temos controle.

Autenticação e Autorização: Use sempre padrões robustos de autenticação e autorização, como OAuth 2.0 ou OpenID Connect. Esses padrões garantem que apenas usuários e sistemas autorizados possam acessar a API ou o serviço.

Transmissão Segura de Dados (HTTPS): Toda a comunicação com APIs externas deve ser feita por meio de conexões seguras (HTTPS). Certifique-se de que o certificado TLS está atualizado e configurado corretamente para evitar ataques como man-in-the-middle.

Validação de Dados: Nunca confie cegamente nos dados recebidos de APIs de terceiros (Zero Trust hoje e sempre). Sempre valide os dados de entrada, verificando se estão no formato esperado e se não contêm valores maliciosos ou inconsistentes.

Escopo de Permissões: Limite as permissões das chaves de API ou tokens de acesso ao mínimo necessário. Um princípio de menor privilégio deve ser aplicado em todas as integrações para minimizar o impacto em caso de comprometimento.

Rotação de Chaves e Tokens: Assegure-se de que as chaves e tokens de API sejam rotacionados regularmente e que haja um processo de revogação em caso de suspeita de comprometimento.

4 Monitoramento e Observabilidade

Monitoramento, Log e saber o que acontece em integrações com APIs e serviços de terceiros é crucial para garantir sua continuidade e identificar problemas rapidamente. A observabilidade permite que sua equipe antecipe falhas, responda rapidamente a incidentes e mantenha um desempenho estável.

Logs detalhados de integração: Registre todas as interações com serviços externos, incluindo chamadas bem-sucedidas, falhas, tempos de resposta e dados relevantes das transações. Isso facilita o diagnóstico de problemas e a auditoria de eventos.

Alertas e notificação de falhas: Configure alertas em caso de falhas nas integrações. Um aumento nas falhas de requisição ou latência elevada pode ser um sinal de problemas com o serviço externo ou de sobrecarga na rede.

Métricas de desempenho: Monitore métricas como tempo de resposta, taxas de erro e volume de tráfego. A análise dessas métricas permite identificar gargalos e ajustar a arquitetura para melhorar a eficiência.

5 Versionamento e Atualizações

Sei que ja cansaram de ler mas novamente, NÃO TEMOS CONTROLE DO AMBIENTE DE TERCEICOS hahaha. Serviços e APIs de terceiros evoluem com o tempo. Versões antigas podem ser descontinuadas, novos recursos podem ser lançados, e mudanças podem impactar diretamente a forma como seu software se integra com eles. Por isso, é essencial estar preparado para lidar com essas atualizações.

Versionamento de API: Prefira trabalhar com APIs que versionam seus endpoints (mesmo sabendo que na maioria dos casos, não tem). Isso garante que novas atualizações não quebrem funcionalidades existentes em seu sistema. Adapte sua integração para lidar com diferentes versões de API, se necessário.

Testes regressivos: Sempre que uma nova versão de API ou serviço de terceiro for lançada, execute testes de regressão para garantir que sua aplicação continuará funcionando corretamente.

Comunicação com fornecedores: Mantenha uma comunicação clara e constante com os fornecedores das APIs. Inscreva-se para receber notificações de atualizações, depreciações e novos recursos.

6 Desacoplamento e Flexibilidade

Bom acho que essa altura dos artigos não preciso dizer o quão bom e correto é baixo ou desacoplamento né? Uma integração com serviços externos não deve criar uma dependência rígida que prejudique a escalabilidade ou a manutenção do software. O desacoplamento das integrações ajuda a manter a flexibilidade e evita que o sistema fique preso a um fornecedor específico.

Abstração de integrações: Crie camadas de abstração para as integrações com APIs e serviços de terceiros. Em vez de codificar diretamente as chamadas à API em todo o código, centralize essas interações em uma classe ou módulo específico, o que facilita futuras modificações ou trocas de serviço.

Design baseado em interfaces: Utilize interfaces para definir contratos entre o seu sistema e o serviço externo. Dessa forma, você pode substituir facilmente a implementação do serviço, sem precisar reescrever a lógica do seu sistema.

7 Documentação e Comunicação

Por fim o que a maioria dos desenvolvedores odeia, mas que todo arquiteto deveria saber e entender que se precisa : Documentação. A documentação clara e acessível das integrações com APIs e serviços externos é fundamental para a manutenção do software e para o trabalho de equipes de desenvolvimento, especialmente em ambientes ágeis.

Descreva fluxos de integração: Documente como as integrações funcionam, incluindo os endpoints de API utilizados, parâmetros, formatos de dados e possíveis cenários de falha.

Mantenha exemplos atualizados: Forneça exemplos práticos de requisições e respostas das APIs, com base em diferentes cenários. Isso ajuda os desenvolvedores a compreender rapidamente o funcionamento da integração.

Acompanhe mudanças: Atualize a documentação sempre que houver modificações na forma de integração, seja por atualizações na API ou mudanças na arquitetura interna do sistema.

Ufa em, parece muito mas é tranquilo se seguir as boas praticas!

A integração com APIs e serviços de terceiros pode oferecer enormes benefícios em termos de funcionalidades e eficiência. No entanto, é importante adotar boas práticas de arquitetura para garantir que essas integrações sejam seguras, resilientes e fáceis de manter ao longo do tempo.

Seguindo esse artigo com essas recomendações, os desenvolvedores podem evitar armadilhas comuns, reduzir a complexidade do código e garantir que o sistema permaneça flexível e escalável.

Espero ter ajudado!

Aquele abraço!

Código seguro com OWASP e SSDLC - 3 OWASP API Security Top 10

Thiago Bertuzzi 👨🏻‍💻 — Tue, 08 Oct 2024 13:11:31 +0000

Fala galera,

Tudo beleza?

Dando continuidade ao conteudo de Código Seguro com OWASP e SSDLC, hoje vamos falar do OWASP API Security Top 10.

Lembrando que nessa série ja abordamos o : Owasp TOP 10 e o ASVS.

Quando eu falei do Owasp TOP 10 eu especifiquei um panorama geral de todas as aplicações, porem um pouco mais focado o OWASP API Security Top 10 é uma lista que destaca as principais vulnerabilidades de segurança encontradas em APIs (Application Programming Interfaces).

Essa lista serve como um guia para desenvolvedores, arquitetos e equipes de segurança garantirem que suas APIs estejam protegidas contra as ameaças mais comuns.

Então vamos dar uma olhada em cada vulnerabilidade, junto com um exemplo prático em .NET para ilustrar como essas vulnerabilidades podem ocorrer e como mitigá-las.

1 Broken Object Level Authorization

Essa falha ocorre quando uma API não implementa de forma adequada a autorização de nível de objeto, permitindo que um usuário acesse dados ou objetos de outros usuários sem a devida permissão.

Imagine que temos um controlador que permite que usuários acessem suas próprias contas. Se não validarmos corretamente o ID do usuário, um atacante pode acessar informações de outras contas.

[HttpGet("{id}")]
public IActionResult GetAccount(int id)
{
    var account = _accountService.GetAccountById(id);
    if (account == null)
    {
        return NotFound();
    }
    return Ok(account);
}

Neste exemplo, um usuário mal-intencionado poderia acessar qualquer conta, alterando o parâmetro id. A solução seria garantir que o ID pertence ao usuário autenticado.

[HttpGet("{id}")]
public IActionResult GetAccount(int id)
{
    var account = _accountService.GetAccountByIdAndUserId(id, User.Identity.GetUserId());
    if (account == null)
    {
        return NotFound();
    }
    return Ok(account);
}

2 Broken Authentication

Autorização e Autenticação parecem a mesma coisa mas não são. A autenticação quebrada pode permitir que atacantes comprometam tokens de autenticação ou senhas, assumindo a identidade de outros usuários. Isso pode acontecer devido a tokens JWT fracos, gerenciamento de sessão inadequado, ou falhas na política de senhas.

Uma API que aceita senhas fracas pode ser comprometida facilmente. Suponha que estamos usando uma autenticação baseada em token:

public IActionResult Login(string username, string password)
{
    var user = _userService.Authenticate(username, password);
    if (user != null)
    {
        return Ok(new { Token = _tokenService.GenerateToken(user) });
    }
    return Unauthorized();
}

Implemente uma política de senhas fortes e valide corretamente os tokens de autenticação, além de utilizar por exempplo PasswordHasher para armazenar as senhas com segurança:

public IActionResult Login(string username, string password)
{
    var user = _userService.Authenticate(username, password);
    if (user != null)
    {
        var hashedPassword = _passwordHasher.HashPassword(user, password);
        if (_passwordHasher.VerifyHashedPassword(user, hashedPassword, password))
        {
            return Ok(new { Token = _tokenService.GenerateToken(user) });
        }
    }
    return Unauthorized();
}

3 Excessive Data Exposure

Lembra do as vezes menos é mais? APIs às vezes retornam mais dados do que o necessário, o que pode expor informações sensíveis que não deveriam ser acessíveis ao cliente.

Uma API que retorna todos os dados de um usuário sem filtrar as informações sensíveis:

public IActionResult GetUser(int id)
{
    var user = _userService.GetUserById(id);
    return Ok(user);  // Retornando todos os dados, incluindo dados sensíveis
}

Retorne apenas os dados necessários e utilize DTOs (Data Transfer Objects) para filtrar a informação sensível:

public IActionResult GetUser(int id)
{
    var user = _userService.GetUserById(id);
    var userDto = new UserDto { Name = user.Name, Email = user.Email }; // Expondo apenas os dados necessários
    return Ok(userDto);
}

4 Lack of Resources & Rate Limiting

Se sua API não for o ultraman zero beyond, ela precisa ter limites! (Ok essa referencia é só para quem gosta de Tokusatsu). APIs que não limitam adequadamente a quantidade de requisições podem sofrer ataques de negação de serviço (o famoso DoS), esgotando recursos e causando indisponibilidade.

Usar RateLimiting com AspNetCoreRateLimit para limitar o número de requisições por cliente.

services.AddInMemoryRateLimiting();
services.Configure<IpRateLimitOptions>(options =>
{
    options.GeneralRules = new List<RateLimitRule>
    {
        new RateLimitRule
        {
            Endpoint = "*",
            Limit = 1000,
            Period = "1h"
        }
    };
});

5 Broken Function Level Authorization

Notem como autorização é importante, por isso no top 10 existem niveis diferentes pra cada tipo. Essa vulnerabilidade ocorre quando funções diferentes na API não possuem restrições de autorização adequadas, permitindo que usuários acessem funcionalidades para as quais não possuem permissão.

Uma API que permite que qualquer usuário acesse funções administrativas.

[HttpPost]
public IActionResult DeleteUser(int id)
{
    _userService.DeleteUser(id);
    return Ok();
}

Implemente checagens de autorização no nível de função, garantindo que apenas administradores possam realizar certas operações.

[Authorize(Roles = "Admin")]
[HttpPost]
public IActionResult DeleteUser(int id)
{
    _userService.DeleteUser(id);
    return Ok();
}

6 Mass Assignment

Atribuição massiva ocorre quando os dados recebidos da requisição permitem que um atacante defina campos sensíveis que deveriam ser restritos, como privilégios de administrador. Isso tambem ocorre quando é possivel acessar regras de negócio que não deveriam ser expostas.

Uma API que permite que o cliente forneça dados arbitrários para atualizar um usuário.

[HttpPost]
public IActionResult UpdateUser([FromBody] User user)
{
    _userService.UpdateUser(user);
    return Ok();
}

Utilize DTOs para garantir que apenas os campos permitidos sejam atualizados.

public class UpdateUserDto
{
    public string Name { get; set; }
    public string Email { get; set; }
}

[HttpPost]
public IActionResult UpdateUser([FromBody] UpdateUserDto userDto)
{
    _userService.UpdateUser(userDto);
    return Ok();
}

7 Security Misconfiguration

A configuração incorreta de componentes de segurança, como falhas no CORS, permissões de arquivos inadequadas, ou erros nos cabeçalhos de segurança, pode expor a API a ataques.

Um erro frequente é permitir CORS para qualquer origem sem restrição.

services.AddCors(options =>
{
    options.AddDefaultPolicy(builder =>
    {
        builder.AllowAnyOrigin()
               .AllowAnyMethod()
               .AllowAnyHeader();
    });
});

Restrinja as origens permitidas e implemente corretamente os cabeçalhos de segurança.

services.AddCors(options =>
{
    options.AddDefaultPolicy(builder =>
    {
        builder.WithOrigins("https://siteConfiavel.com")
               .AllowAnyMethod()
               .AllowAnyHeader();
    });
});

8 Injection

Falhas de injeção, como SQL Injection ou NoSQL Injection (sim elas existem tambem), ocorrem quando a entrada de dados não é validada corretamente, permitindo a execução de comandos maliciosos.

Por exemplo uma API vulnerável a SQL Injection:

public IActionResult GetUser(string username)
{
    var query = $"SELECT * FROM Users WHERE Username = '{username}'";
    var user = _dbContext.Users.FromSqlRaw(query).FirstOrDefault();
    return Ok(user);
}

Use consultas parametrizadas para evitar injeção de SQL.

public IActionResult GetUser(string username)
{
    var user = _dbContext.Users
                         .FromSqlRaw("SELECT * FROM Users WHERE Username = @username", new SqlParameter("@username", username))
                         .FirstOrDefault();
    return Ok(user);
}

9 Improper Assets Management

Muitas vezes precisamos atualizar APIs ou por erro, melhoria ou necessidades especificas por cliente. APIs podem expor versões antigas ou descontinuadas, o que pode ser um vetor de ataque se essas versões contiverem vulnerabilidades conhecidas.

Suponha que há duas versões de uma API, mas a versão antiga ainda está acessível e vulnerável.

[Route("api/v1/[controller]")]
public class UserControllerV1 : ControllerBase
{
    // Código antigo, ainda acessível
}

Desative e remova versões antigas e implemente políticas de versionamento claras.

[Route("api/v2/[controller]")]
public class UserControllerV2 : ControllerBase
{
    // Nova versão da API com melhorias de segurança
}

10 Insufficient Logging & Monitoring

A falta de monitoramento adequado permite que ataques passem despercebidos e não sejam identificados a tempo, comprometendo a segurança da API. Alem disso o excesso de informação que não deveria ser retornada (um log interno com id's e etc) pode ser um prato cheio para quem quer saber uma falha, ou vulnerabilidade de sua API.

Um exemplo simples não registrar tentativas de login falhas ou acessos maliciosos.

// Nenhum registro de falha de autenticação
public IActionResult Login(string username, string password)
{
    var user = _userService.Authenticate(username, password);
    if (user == null)
    {
        return Unauthorized();
    }
    return Ok();
}

Implemente logging adequado e use ferramentas de monitoramento.

public IActionResult Login(string username, string password)
{
    var user = _userService.Authenticate(username, password);
    if (user == null)
    {
        _logger.LogWarning($"Falha de autenticação para o usuário: {username}");
        return Unauthorized();
    }
    return Ok();
}

São exemplos bem simples, porem implementar as boas práticas sugeridas no OWASP API Security Top 10 é fundamental para proteger suas APIs contra as vulnerabilidades mais comuns. O uso de boas práticas de segurança, como autenticação forte, autorização robusta, criptografia e monitoramento adequado, é essencial para garantir a segurança das aplicações.

Participei de uma live no canal do Microsoft Reactor com meu amigo e MVP Renato Groffe onde abordamos e detalhamos mais esse top 10 :

Alem disso gravamos 2 Episódios sobre segurança em nosso DevShow Podcast!

Espero ter ajudado!

Aquele abraço!

Código seguro com OWASP e SSDLC - 2 ASVS

Thiago Bertuzzi 👨🏻‍💻 — Thu, 05 Oct 2023 13:02:13 +0000

Fala galera,

Tudo beleza?

Como prometido e Dando continuidade ao conteudo de Código Seguro com OWASP e SSDLC, hoje vamos falar do ASVS.

Mas obviamente para começar:

O que é ASVS?

ASVS é uma sigla que significa "Application Security Verification Standard" (Padrão de Verificação de Segurança de Aplicativos), e o projeto OWASP ASVS é uma iniciativa da OWASP que visa fornecer um conjunto de diretrizes e requisitos de segurança para o desenvolvimento e testes de aplicativos web.

O objetivo principal do ASVS é garantir que os aplicativos web sejam projetados e construídos com segurança desde o início, protegendo-os contra as ameaças cibernéticas mais comuns.

O OWASP ASVS é uma ferramenta do cara... para desenvolvedores, "testadores" e profissionais de segurança . Ele fornece um conjunto abrangente de requisitos de segurança que podem ser usados como um guia para desenvolvimento seguro e teste de aplicativos.

Nota: a versão atual do ASVS utilizada na escrita desse artigo é a 4.0.3 (a 5.0 ja foi anunciada)

E como Funciona?

O OWASP ASVS é organizado em três níveis de segurança, cada um com requisitos específicos. Na maioria dos casos se sua aplicação esta no Nivel 1 eu ja fico feliz por você hahaha, pois é o minimo que se espera de um testes. Porem conforme exista uma maior complexidade do negocio e os tipos de dados envolvidos é necessario subir o nivel:

Nível 1 - Verificação Automatizada

É o nível mais básico. Este nível é focado em verificações automatizadas que podem ser implementadas durante o ciclo de desenvolvimento.

Ele inclui testes como verificação de vulnerabilidades conhecidas e configurações seguras de servidor web. Esses testes podem ser facilmente integrados em pipelines de CI/CD (Integração Contínua/Entrega Contínua) para fornecer feedback imediato aos desenvolvedores.

Nível 2 - Recomendado para aplicações e sistemas que contêm dados pessoais Verificação Funcional, geralmente para a maioria de aplicações comerciais.

O segundo nível envolve verificações manuais para garantir que os requisitos de segurança estejam sendo atendidos. Isso inclui testes de autenticação, autorização, criptografia e proteção contra ameaças comuns, como injeção de SQL e XSS (Cross-Site Scripting). (OWASP Top Ten)

Nível 3 - Verificação de Arquitetura

Recomendado para aplicações críticas e transacionais uma aplicação que requeira um alto nível de confiabilidade.

O nível mais alto do OWASP ASVS envolve revisões mais aprofundadas da arquitetura de segurança do aplicativo. Isso inclui avaliações de design de segurança, análise de risco e considerações de ameaças. Também aborda a conformidade com regulamentações de segurança, como GDPR (Regulamento Geral de Proteção de Dados) e HIPAA (Lei de Portabilidade e Responsabilidade de Seguro de Saúde).

Cada nivel vai complementando o anterior , então dependendo do tipo de aplicação é necesario aplica-los.

A implementação do ASVS prove : Maior segurança, Padrões Claros, Integração com CI/CD e Conformidade Regulatória.

Arquitetura ASVS :

Focando nos primeiros niveis se você deseja que seu aplicativo tenha um padrão de segurança de alto nivel alguns tipos de "arquiteturas" podem ser uteis.

Claro, considerando que você esta aplicando o OWASP Top TEN no seu ciclo de desenvolvimento ja podemos considerar que você esta no caminho certo, porem, para reforçar vamos falar especificamente de algumas arquiteturas que serão abordadas de forma mais detalhada nos proximos artigos :

Authentication Architecture

Utilize patterns de segurança existentes
Aplica frameworks/métodos de autenticação de mercado e testados : não vai inventar o seu próprio sendo que existem varios opensource como Keycloack e gratuitos para começar como o Azure B2C
Prefira uma a varias formas de autenticação : Se possivel utilize apenas uma forma de autenticação, isto alem de diminuir a complexidade diminui os riscos de brechas de segurança
Autenticação segura para componentes de backend e serviços de terceiros : Principalmente em arquiteturas de microserviços é importante lembrar de criar uma autenticação segura entre os mesmos e claro em qualquer arquitetura uma autenticação segura com serviços que você não tem o controle
Logs e monitoramento : Manter um monitoramento constante de quem e de onde é autenticado em sua aplicação. Isso facilita o rastreio para evitar problemas futuros.

Access Control Architecture

Quem pode acessar o que e quais dados : Roles devem ser levadas a serio, é importante sempre tratar os dados que devem ou não ser acessados de acordo com as regras e perfis de acesso
Um Único mecanismo bem testado para autenticação : Diversos mecanismos criam complexidades desnecessárias e abrem brechas de segurança
Verificação de controles acontece só no Cliente ou no Server também? : Caso você esteja implementando tanto a solução de Client como Server prefira realizar a validação em ambos os lados. Isto melhora a segurança e tambem garante uma integridade de dados caso va compartilhar sua api com terceiros.

Input and Output Architecture

Validação do que é Enviado : Validação de dados que são enviados para sua aplicação como formularios, sql injection, dados sem criptografia e dados que não deveriam estar la
Validação do que é retornado : Tão perigoso quanto o envio são os dados retornados. É importante garantir que toda informação retornada seja para o perfil correto ou não possua dados sensiveis.

Cryptographic Architecture

Os dados estão devidamente criptografados? : Tudo que é enviado ou gerado pela sua aplicação com informações sensiveis deve ter algum tipo de criptografia. Isso minimiza problemas e brechas de segurança em trafegos de dados.
O que você armazena do lado do Client? : Cookies, secrets entre outros são informações armazenadas que podem abrir brechas para vazamentos de dados e possiveis invasores. É importante tomar cuidado no que é armazenado.
Os dados do lado do servidor estão protegidos? : Não adianta nada proteger apenas o lado do Client,informações da aplicação publicada devem ser protegidas tambem. Prefira armazenar informações sensiveis em keyvaults do que em arquivos de configuração por exemplo.
Considere um cenario caso se algum invasor consiga roubar uma chave ou algum “secret”

Auditing Architecture

Erros
Logs de informações
Auditoria
Proteção de Logs Sensíveis : Essa parte é muito importante!! Deve-se tomar cuidado com o que se loga de facil acesso.Um log pode revelar informações sensiveis que abrem brechas de segurança e facilitam o acesso de um invasor para roubos de informações.

Nota : gravamos um episódio do devshow só desse tema , vale a pena escutar.

Data Protection And Privacy Architecture

Dados devem ser classificados :

Publico
Interno
Confidencial

Aplique controles próprios para cada tipo de informação garantindo que dados sensiveis não fiquem expostos.

Communications Architecture

Proteja/Criptografe dados que são transmitidos
Não exponha dados compartilhados entre micro serviços, Apis ou containers

Malicious Software Architecture

Repositório GIT : Deve se tomar cuidado com o que você armazena em seus repositórios
Secrets em Commits : Nunca, jamais, nem por brincadeira deve-se commitar secretes e informações sensiveis em repositórios.
Bagunça em Branch : Branchs bagunçadas ou com nomes de desenvolvedores podem gerar dores de cabeça e abrir brechas de segurança. Prefira adotar um padrão como Gitflow por exemplo

Existem algumas ferramentas como Sonarqube/SonarCloud e GitGuardian quem podem lhe ajudar não permitir que informações Sensiveis sejam guardadas em repositórios.

Business Logic Architecture

Autenticação
Controle de Acesso
Gerenciamento de Sessão (expirar e etc)
Regras de negocio com tratamentos e validações

Muitas vezes os problemas de segurança estão na própria regra de negócio da aplicação. Aplique validações consistentes e revisões de logica. Um Código bem feito pode evitar problemas de segurança.

Secure File Upload Architecture

Quais arquivos podem ser enviados? : Garanta que apenas os arquivos permitidos sejam possiveis de ser inseridos em sua aplicação
Validação de Tipos de Arquivo : Um bom começo é permitir apenas extensões validas de acordo com sua regra de negócio
Validação de Arquivos Maliciosos : Tenha um validador de arquivos eficiente para garantir que arquivos maliciosos não consigam prejudicar sua aplicação
Arquivos que podem ser baixados : Garanta quais arquivos podem ou não ser baixados

Configuration Architecture

Build and Deployment : Tenha uma esteira de Devops configurada e segura, garantindo quais informções estão em variaveis de ambiente, arquivos e etc
Monitorar vulnerabilidades
Variáveis de Ambientes para projetos separados
Fontes assinadas

Ufa!!! Creio que para esse artigo ja tem muita coisa hehehe.

Segurança é um assunto extenso e que deve ser levado a sério, então creio que com essas boas praticas sua aplicação deve atingir um nivel excelente de segurança durante o ciclo de desenvolvimento.

Recentemente fizemos uma live no Canal .net sobre o Assunto, quem quiser pode conferir :

Espero ter ajudado!

Aquele abraço!

Código seguro com OWASP e SSDLC - 1 Top Ten

Thiago Bertuzzi 👨🏻‍💻 — Mon, 02 Oct 2023 17:01:27 +0000

Fala galera,

tudo beleza?

Dando continuidade ao conteudo de segurança para código, hoje vamos falar dela a OWASP. Em um artigo anterior eu expliquei como funiona o Desenvolvimento Seguro, S-SDLC na parte da teoria, porem agora vamos começar a entender de vez como podemos melhorar nosso código do ponto de vista de segurança.

Antes de mais nada o que é, quem é onde vive e o que come a OWASP?

A Open Web Application Security Project ou OWASP é uma organização sem fins lucrativos fundada em 2001, cuja missão é melhorar a segurança do software. Seu nome completo reflete sua missão e importancia na segurança de aplicativos web, mas suas atividades vão além disso, abrangendo várias áreas de segurança.

A organização é composta por uma comunidade global de especialistas em segurança, desenvolvedores, engenheiros, e outros profissionais que compartilham seu conhecimento e experiência para criar recursos e ferramentas de segurança acessíveis a todos.

A Owasp em sim possui 3 objetivos : Fornecer Recursos Educacionais, Desenvolver Ferramentas e Padrões e Promover Melhores Práticas. Tudo voltado para que tenhamos uma ideia de onde seguir boas praticas para termos aplicações mais seguras.

Owasp Top Ten

Uma das contribuições mais reconhecidas da OWASP é o "OWASP Top Ten". Esta é uma lista anual das dez principais vulnerabilidades de segurança em aplicativos da web.

O objetivo do OWASP Top Ten é conscientizar sobre as ameaças mais críticas e ajudar as organizações a priorizar seus esforços de segurança. As vulnerabilidades incluídas na lista podem variar ao longo do tempo à medida que as ameaças evoluem, mas geralmente incluem problemas como injeção de SQL, autenticação inadequada, exposição de dados sensíveis e muitos outros.

Traduzindo para nosso querido portugues o Owasp Top Ten aborda os seguintes tópicos :

1. Injeção: Vulnerabilidades que ocorrem quando dados não confiáveis são inseridos em comandos ou consultas não seguras, permitindo que um atacante execute código malicioso.

Por exemplo dados não confiáveis são inseridos diretamente em instruções SQL, permitindo que um atacante execute comandos maliciosos no banco de dados.

string userInput = Request.Query["search"];
string query = $"SELECT * FROM Produtos WHERE Nome = '{userInput}'";

2. Quebra de Autenticação: Falhas na autenticação e gerenciamento de sessões que podem permitir que um invasor assuma a identidade de outro usuário.

if (senhaDigitada == usuario.Senha) {
    // Acesso concedido
}

3. Exposição de Dados Sensíveis: Quando informações confidenciais são acessíveis por pessoas não autorizadas devido a configurações inadequadas ou vulnerabilidades na aplicação.

string cartaoCredito = HttpContext.Request["cartao"];

4. Controle de Acesso Quebrado: Falhas na aplicação de autorização e controle de acesso, permitindo que usuários não autorizados acessem recursos protegidos.

if (!User.IsInRole("Administrador")) {
    // Usuário não autorizado
}

5. Má Configuração de Segurança, Logs e dados: Configurações incorretas que podem abrir brechas de segurança, como servidores web com informações de depuração ativadas.

"Logging": {
    "LogLevel": {
        "Default": "Debug"
    }
}

6. Falha de Segurança em Componentes: Quando componentes de terceiros, como bibliotecas ou frameworks, contêm vulnerabilidades conhecidas que podem ser exploradas.

dotnet add package VulnerableLibrary --version 1.0

7. Cross-Site Scripting (XSS): Vulnerabilidades que permitem que um invasor injete scripts maliciosos em páginas da web vistas por outros usuários.

string userInput = Request.Query["comment"];
Response.Write("Comentário: " + userInput);

8. Deserialização Insegura: Quando dados não confiáveis são desserializados sem verificação adequada, permitindo que um atacante execute código arbitrário.

MemoryStream stream = new MemoryStream(Convert.FromBase64String(serializedData));
BinaryFormatter formatter = new BinaryFormatter();
object obj = formatter.Deserialize(stream);

9. Regras de Negócios Quebrada: Falhas na lógica de negócios que podem ser exploradas por atacantes.

if (usuario.ID == 1) {
    // Acesso total concedido
}

10. Redirecionamento e Encaminhamento Não Confiável: Quando aplicativos permitem que um invasor redirecione ou encaminhe um usuário para sites maliciosos, comprometendo sua segurança.

Response.Redirect(Request.Query["url"]);

Respeitando e implementando essas dicas do TOP TEN sua aplicação tem o minimo de segurança aceitavel para estar no ar.

Claro que isso é apenas um resumo, para entender melhor é necessario revisar toda a documentação do OWASP TOP TEN

Porem é uma introdução pois no proximo artigo iremos falar de OWASP ASVS então nos vemos la!

Espero ter ajudado!

Aquele abraço!

10 Dicas Basicas de Arquitetura de Código : 4 - Overengineering

Thiago Bertuzzi 👨🏻‍💻 — Thu, 20 Jul 2023 18:40:58 +0000

Fala galera,

tudo beleza?

Dando continuidade a serie de artigos sobre arquitetura (se não viu a parte 3 clique aqui), é muito comum encontramos patterns, arquiteturas complexas, soluções mirabolantes e pessoas vendendo cursos de "microservice First" quando estamos procurando a melhor solução para nossos projetos.

Porem pior do que não saber como fazer é fazer em excesso e encher a arquitetura/aplicação de complexidade desnecessaria e isso é conhecido como Overengineering/Superengenharia!

Overengineering ou Superengenharia consiste em criar arquiteturas, sistemas ou soluções que ultrapassam os requisitos necessários, resultando em uma complexidade desnecessária, custos elevados e uma eficiência reduzida. Embora a inovação (e as vezes pró atividade) seja fundamental para avanços tecnológicos, o overengineering pode ter consequências graves que superam seus potenciais benefícios.

1. La se vai o Orçamento, custos elevados:

Um dos problemas mais evidentes do overengineering é o custo adicional que ele nos tras. Ao adicionar recursos e funcionalidades complexas além do necessário, os custos de desenvolvimento, produção e manutenção podem aumentar consideravelmente. Investir recursos financeiros em aspectos que não agregam valor real ao produto final pode ser prejudicial para a saúde financeira de uma empresa ou projeto.

Um bom exemplo é contratar serviços desnecessarios, componentes mirabolantes, diversos serviços de Cloud e etc. Outro cenario são diversas horas desnecessarias em um cronograma que gera custo x hora de profissionais.

2. Vamos usar aquele Framework/Modelo que é legal , complexidade Desnecessária:

À medida que um projeto é sobrecarregado com recursos excessivos, sua complexidade aumenta. Isso torna a compreensão do sistema mais difícil, tanto para os desenvolvedores que precisam mantê-lo quanto para os usuários que o utiliza. A complexidade desnecessária pode resultar em dificuldades de resolução de problemas, tornando a identificação de erros e falhas uma tarefa mais complicada e demorada.

Um exemplo classico, fazer um projeto microservices só porque ta no hype ou porque te disseram que é melhor sem considerar se você precisa de tamanha complexidade.

3. E agora quem fez isso ? Dificuldades de Manutenção:

Sistemas com complexidade desnecesaria podem se tornar verdadeiros problemas para os desenvolvedores que precisam fazer atualizações ou correções. A manutenção se torna uma tarefa dificil e geralmente com grandes chances de erros, especialmente quando há falta de documentação adequada e padrões claros de desenvolvimento. A longo prazo, a falta de facilidade na manutenção pode levar a sistemas obsoletos e incompatíveis com novas tecnologias .

4. Muito daora! Mas quando você me entrega? Atrasos no Tempo de Desenvolvimento:

Enquanto os Arquitetos/Desenvolvedores se esforçam para criar um sistema (com complexidade desnecessaria) sofisticado, pode haver um aumento significativo no tempo de desenvolvimento. O foco em detalhes não essenciais pode atrasar a entrega do projeto , o que pode ser prejudicial em setores onde a rapidez é fundamental para o sucesso e para seus clientes.

5. Precisamos realizar uma integração nova e agora? Dificuldades na Integração:

Com o aumento de complexidade desnecessaria, a integração com outros sistemas pode se tornar um verdadeiro desafio. A falta de interoperabilidade com soluções existentes pode resultar em incompatibilidades e dificuldades na troca de dados entre diferentes sistemas, o que, por sua vez, pode prejudicar a eficiência operacional de toda a organização.

6.Arquitetura complexa, mas o sistema faz o que? Falta de Foco no Usuário:

Você pode ter um sistema com uma complexidade gigante (que na cabeça de muitos é um sistema bom) , porem se ele não atende o que foi pedido el não serve para nada. Ao priorizar a adição de recursos avançados, pode-se negligenciar as necessidades básicas e a usabilidade do produto para os clientes. Isso pode resultar em uma experiência do usuário desfavorável e, em última instância, levar à rejeição do produto pelo cliente ou mercado.

Como dizem no Master Chefe : As vezes menos é mais!

O overengineering pode levar a uma série de problemas que afetam negativamente a viabilidade e a sustentabilidade de um projeto ou organização. É essencial encontrar um equilíbrio entre funcionalidade e simplicidade, garantindo que os recursos adicionados agreguem valor real ao produto final e atendam às necessidades reais dos usuários. Ao evitar esses problemas as empresas podem otimizar seus processos, economizar recursos e oferecer soluções mais eficientes e melhores.

Espero ter ajudado!

Aquele abraço!

GitHub : GitFlow , Organizando a bagunça das suas branchs

Thiago Bertuzzi 👨🏻‍💻 — Mon, 10 Jul 2023 14:34:01 +0000

Fala galera,

tudo beleza?

Organização é algo muito importante para desenvolvimento de aplicações, principalmente nos repositorios de código. Uma falta de organização adequada pode resultar em perda de código, merges erroneos, problemas de segurança, versões incorretas colocadas em produção e etc.

Uma forma que eu gosto muito de organização de branchs é o GitFlow e é dele que vamos falar hoje. Bora?

Calma! A Imagem acima pode ate assustar um pouco, mas eu garanto que é mais simples do que é!

O Gitflow, desenvolvido por Vincent Driessen, oferece uma estrutura clara para colaboração e integração contínua, permitindo um desenvolvimento mais organizado e escalável. Ele pode ser aplicado a qualquer serviço que hospede repositorios Git , porem GitHub oferece recursos e ferramentas que facilitam a implementação e o gerenciamento desse fluxo.

Então utilizando o Github como exemplo vamos entender as etapas do Fluxo :

1. Repositório "master/main" e "develop":

Quando criamos um projeto no GitHub, temos um repositório vazio.

O branch "main" é criada como a versão mais estável e entregável do software. Esta branch contém apenas o código que está em produção e é considerado estável e pronto para ser implantado. Ela não deve ser modificado diretamente. Em vez disso, as alterações são trazidas de outros branches, como a branch "release" e a branch "hotfix" que veremos mais para frente.

Devemos criar uma branch "develop" que seria o ambiente de desenvolvimento contínuo. Esta Branch contém todo o código em desenvolvimento, incluindo novos recursos, correções de bugs e melhorias. É a partir da branch "develop" que novos branches de features, releases são criados. Podemos dizer que a Develop é a branch candidata a ir para produção.

2. Branches de feature:

Essas branches são usados para adicionar novos recursos ao projeto. Elas são criados a partir da branch "develop" e são nomeados de forma descritiva, como "feature/nome-da-feature". As branches de feature são desenvolvidos independentemente e, quando concluídos, são mesclados de volta para o branch "develop".

Por exemplo :

Um desenvolvedor (ou responsavel pelo repositório) cria um branch de feature chamado "feature/adicionar-tarefas" no GitHub a partir do branch "develop", em seguida ele ou a equipe trabalha na branch fazendo várias alterações para implementar o recurso. são feitos diversos commits e pushs das alterações para o branch no GitHub.

Quando o desenvolvimento está concluído, o desenvolvedor abre um pull request (PR) no GitHub para mesclar a branch de feature na branch "develop".
Outros membros da equipe (ou algum responsavel) revisam o código, fazem comentários e, finalmente, o PR é aprovado e mesclado no GitHub.

3. Branches de hotfix:

Essas branches são usados para corrigir bugs críticos encontrados no código em produção. Elas são criadas a partir do branch "main" e, quando concluídas, são mesclados tanto na branch "main" quanto na branch "develop". Isso garante que a correção seja refletida tanto na versão atual em produção quanto na próxima versão em desenvolvimento.

Por exemplo :

Alguem encontra um erro/bug crítico no código em produção, uma branch de hotfix chamado "hotfix/bug-critico" é criada no GitHub a partir da branch "main".
Após a correção do bug é e os commits feitos no GitHub ,um PR é aberto para mesclar a branch de hotfix no branch "main".

O PR é revisado, aprovado e mesclado no GitHub, garantindo que a correção seja refletida tanto na versão atual em produção quanto na próxima versão em desenvolvimento.

4. Branches de release:

Quando o código na branch "develop" está pronto para ser colocado em produção, uma branch de release é criado a partir dele.

A branch de release é usado para realizar atividades finais de teste, correção de bugs e preparação para o lançamento. Qualquer correção de bug necessária é feita diretamente na branch de release. Quando o branch de release está pronto, ela é mesclada tanto no branch "main" quanto no branch "develop", marcando assim uma nova versão do software.

Por exemplo :

Quando o código na branch "develop" está pronto para ser liberado, uma branch de release chamado "release/v1.0" é criada no GitHub a partir da branch "develop".

Após a conclusão da branch de release, um PR é aberto no GitHub para mesclar o branch de release no branch "main".
O PR é revisado, aprovado e mesclado no GitHub, marcando assim uma nova versão do software.

De forma simples estas são as Etapas. É possivel adapta-las para o uso do dia a dia de forma que atenda a necessidade da sua equipe, assim como nomenclaturas utilizadas nos nomes de releases,hotfix e features.

O que eu gosto da utilização desse padrão com o Github é que ele fornece uma interface intuitiva e ferramentas poderosas para facilitar o uso do Gitflow. temos recursos como pull requests, revisões de código, rastreamento de problemas e integração contínua para ajudar as equipes a colaborar e gerenciar o desenvolvimento de software de forma eficiente.

Utilizar o Gitflow com o GitHub, podemos ter um fluxo de trabalho estruturado, facilitando a coordenação e a colaboração entre os membros da equipe. A combinação dessas duas ferramentas permite um controle preciso sobre as diferentes etapas do ciclo de vida do código, promovendo um desenvolvimento mais organizado, estável e confiável.

Espero ter ajudado!

Aquele abraço!

GitHub : Dependabot suas dependencias atualizadas e seguras

Thiago Bertuzzi 👨🏻‍💻 — Fri, 07 Jul 2023 14:44:12 +0000

Fala galera,

tudo beleza?

Não é novidade que meu repositorio favorito é o Github, inclusive sempre digo que o mesmo tem diversas funcionalidades muito bacanas para ajudar a melhorar e proteger seu código.

Quando desenvolvemos um software é comum depender de bibliotecas e pacotes de terceiros, porem manter tudo atualizado é geralmente um problema. Existem pacotes que possuem diversas atualizações importantes de segurança, ja outros ao atualizar quebram nosso build com mudanças de assinatura de método ou funcionalidades.

O Github tem uma ferramenta muito legal para nos ajudar nisso o Dependabot! E é dele que vamos falar hoje!

Dependabot!

O Dependabot é um serviço de integração contínua oferecido pelo GitHub, projetado especificamente para monitorar e atualizar automaticamente as dependências dos repositórios. Ele analisa regularmente o arquivo de manifesto de dependências (como o package.json no JavaScript ou o csproj do .net) e notifica sobre versões desatualizadas, novas e atualizações criticas de correções de segurança.

Legal, mas como funciona?

O Dependabot funciona integrado ao seu repositorio ou a um fluxo devops do GitHub. Quando ativado em um repositório, o Dependabot verifica regularmente as dependências em busca de atualizações disponíveis. O Mais incrivel é que ele cria solicitações de pull (PRs) com as atualizações propostas, permitindo que você revise e teste as mudanças antes de comita-las em seu código.

Mais incrivel ainda do ponto de vista de segurança, o Dependabot analisa as atualizações em busca de vulnerabilidades conhecidas. Se uma atualização resolver uma vulnerabilidade de segurança, o Dependabot criará uma PR específica para essa atualização, destacando a importância da correção. Isso é incrivel! Principalmente para manter o seu projeto protegido contra possíveis ameaças.

Como configurar o DependaBot?

Existem 2 formas de configurar o DependaBot, uma é com um arquivo dependabot.yml adicionado ao seu repositorio (caso queira ver todas as opções do Arquivo clique aqui), ou no proprio repositorio :

No seu repositorio clique em settings :

Em Seguida nas opções de segurança :

Então temos todas as opções do Dependabot :

Caso queira configurações mais especificas pode acessar a documentação oficial clicando aqui.

Um exemplo de como ele se comporta :

O Pull request é bem explicativo e facil de entender antes de dar o merge :

Então recapitulando os beneficios do Dependabot :

Manutenção dependências: Ele automatiza a tarefa de acompanhar e atualizar suas dependências, poupando tempo e esforço. Ele mantém você informado sobre as atualizações disponíveis e cria PRs prontas para serem revisadas e mescladas.

Correção de vulnerabilidades: Isso ajuda a garantir que você esteja ciente das vulnerabilidades conhecidas nas suas dependências. Ao criar PRs específicas para resolver essas vulnerabilidades, ele facilita a aplicação das correções necessárias para manter seu código e sistema seguro.

Ja esta no GitHub: O Dependabot é um serviço nativo do GitHub, o que significa que ele se integra perfeitamente ao ambiente do GitHub. Ele se alinha com os fluxos de trabalho existentes, Actions, repositorio ,notificações e revisões de código, facilitando a adoção e utilização por desenvolvedores.

Caso queira saber mais sobre Desenvolvimento seguro clique aqui

Caso queira saber o que não se deve armazenar no seu código clique aqui

Espero ter ajudado!

Aquele abraço!

10 Dicas Basicas de Arquitetura de Código : 3 - Cuidado com o que você armazena no seu código

Thiago Bertuzzi 👨🏻‍💻 — Wed, 05 Jul 2023 14:33:21 +0000

Fala galera,

tudo beleza?

Dando continuidade a serie de artigos sobre arquitetura (se não viu a parte 2 clique aqui), Algumas dicas basicas de arquitetura se extendem alem de padrões código limpo e etc.

Existem algumas coisas que devemos nos preocupar, como a adoção de medidas de segurança eficientes para proteger informações sensíveis.

Existem muitas informações sensíveis/confidenciais, como senhas, chaves de API, tokens de autenticação entre outras. No entanto, infelizmente, ainda é comum encontrar projetos que armazenam tais segredos diretamente no código e pior nos repositórios Git.

Existem alguns pontos que devemos nos preocupar :

Vulnerabilidade: Ao armazenar segredos no código fonte (e comitando no repositório Git), você está expondo essas informações a qualquer pessoa com acesso ao repositório. Isso inclui colaboradores, hackers ou indivíduos mal-intencionados que possam explorar essas informações para obter acesso não autorizado aos sistemas e dados sensíveis. Imagina se alguem por algum erro ou "cagada" deixa o repositório publico?
Histórico de alterações: Quem ja escutou a frase : "Uma vez que cai na internet ja era". Então,o Git mantém um histórico completo de todas as alterações feitas no código e nos arquivos do repositório. Isso significa que, mesmo que você exclua ou apague secrets e outras coisas posteriormente, eles ainda poderão ser recuperados do histórico de commits. Essa vulnerabilidade pode ser explorada por alguém com acesso ao repositório, o que coloca em risco a segurança dos dados.
Compartilhamento: O desenvolvimento de aplicações na maioria dos casos envolve vários desenvolvedores, testadores e administradores de sistemas. Quando você armazena informações sensiveis você acaba compartilhando com várias pessoas. Isso amplia o risco de exposição acidental ou intencional das informações, especialmente quando os níveis de acesso e controle não são adequadamente definidos.
Mudanças de ambiente: Alem dos riscos citados acima, existe tambem um problema ao implantar um aplicativo em diferentes ambientes (desenvolvimento, teste, produção) ou escalar sua infraestrutura. Obviamente é necessário gerenciar diferentes configurações/secrets para cada ambiente. Ao armazenar essas configurações/secrets no código fonte ou no repositório (imagina um cenario de deploy automatico), a gestão dessas configurações se torna complicada, levando a erros, vazamentos e dificuldades em manter a sincronização adequada entre as diferentes instâncias.

Certo, mas como resolver?

Variáveis de ambiente: Ao invés de armazenar informações sensiveis no código , utilize variáveis de ambiente para acessar essas informações durante a execução da aplicação. Dessa forma, você pode proteger esses dados em um local separado, acessível apenas pelo sistema operacional ou pelo gerenciador de execução.
Ferramentas de gestão de segredos: Há várias ferramentas disponíveis para o gerenciamento seguro de segredos, como o Azure Key Vault (Caso queira conhecer fizemos uma live no Canal dotNet Sobre) , AWS Secrets Manager ou HashiCorp Vault. Essas soluções permitem o armazenamento centralizado de segredos e fornecem mecanismos seguros para acessá-los durante a execução da aplicação.
Arquivos de configuração externos: Mais facil que contratar um serviço é utilizar arquivos de configuração externos, como arquivos JSON, XML, YAML ou INI, para armazenar os segredos. Esses arquivos podem ser criptografados ou protegidos por permissões adequadas, garantindo que apenas usuários autorizados tenham acesso a eles.
Controle de acesso e revisões: Não adianta nada se preocupar se sua equipe não se preocupa.É importante implementar controles de acesso adequados aos repositórios Git e aos sistemas de gerenciamento de segredos. Além disso, é fundamental realizar revisões periódicas para identificar e corrigir possíveis exposições de segredos, garantindo a conformidade com as políticas de segurança estabelecidas.

Em resumo você pode ter a melhor arquitetura do mundo, se não se preocupar com o que armazena no seu código/repositório essa sua aplicação bem escrita pode não vai ficar muito tempo no ar....

Caso queira saber mais sobre Desenvolvimento seguro clique aqui

Espero ter ajudado!

Aquele abraço!

10 Dicas Basicas de Arquitetura de Código : 2 - Code Smells

Thiago Bertuzzi 👨🏻‍💻 — Wed, 07 Jun 2023 12:43:56 +0000

Fala galera,

tudo beleza?

Dando continuidade a serie de artigos sobre arquitetura (se não viu a parte 1 clique aqui), hoje vamos falar sobre quando ta fedendo a ... Bem, Código mal cheirosos no portugues bem claro heheheh

Bora?

Em um bom resumo Code Smells são indicações de possiveis problemas ou deficiências no seu código que podem afetar negativamente a qualidade, perfomance e principalmente manutenção de uma aplicação.

Esses "Smells" de código devem ser levados em consideração pois são sinais de que algo pode estar errado com o projeto.

Code Smells podem ser identificados através de análises e/ou revisões de código. Geralmente são analises feitas por desenvolvedores mais experientes, alem de existirem diversos problemas que podem ocorrer.

Para te ajudar a verificar o seu código (Considerando exemplos comuns) vou demonstrar alguns casos de Code Smells que podem te ajudar a identificar problemas.

Código em duplicidade:

A famosa duplicidade de código ocorre quando há trechos semelhantes ou idênticos em diferentes partes do código. Isso pode levar a problemas de manutenção, pois qualquer alteração deve ser feita em vários lugares.
Um exemplo de duplicação seria quando a mesma lógica é repetida em diferentes métodos ou classes. A solução para esse problema é extrair a lógica duplicada para um método separado e chamá-lo onde for necessário.

// Código com duplicação
public void CalcularTotalPedido(Pedido pedido)
{
    // ...
    decimal total = 0;
    foreach (var item in pedido.Itens)
    {
        total += item.Preco * item.Quantidade;
    }
    // ...
}

public void CalcularTotalVenda(Venda venda)
{
    // ...
    decimal total = 0;
    foreach (var item in venda.Itens)
    {
        total += item.Preco * item.Quantidade;
    }
    // ...
}

// Código refatorado
public decimal CalcularTotal(IEnumerable<Item> itens)
{
    decimal total = 0;
    foreach (var item in itens)
    {
        total += item.Preco * item.Quantidade;
    }
    return total;
}

public void CalcularTotalPedido(Pedido pedido)
{
    // ...
    decimal total = CalcularTotal(pedido.Itens);
    // ...
}

public void CalcularTotalVenda(Venda venda)
{
    // ...
    decimal total = CalcularTotal(venda.Itens);
    // ...
}

Classe com mais responsabilidades do que devia:

Você ja ouviu a palavra da Mono-Classe? Se não nem escute porque ta errado hahaha. Uma classe com muitas responsabilidades tende a ser mais difícil de entender, testar e manter.
É importante seguir o princípio da responsabilidade única (quer entender mais escute nosso episódio DEVSHOW #21 – SOLID (SRP), onde cada classe deve ter apenas uma razão para mudar.
Isso pode ser identificado quando uma classe executa várias operações diferentes ou possui muitos métodos e propriedades. A solução para isso é dividir a classe em classes menores e mais especializadas, seguindo o princípio da segregação de interfaces.

// Classe com muitas responsabilidades
public class ProcessamentoPedido
{
    public void ProcessarPedido(Pedido pedido)
    {
        // Lógica para processar o pedido

        // Enviar email de confirmação
        EnviarEmailConfirmacao(pedido);

        // Atualizar estoque
        AtualizarEstoque(pedido);

        // Gerar relatório
        GerarRelatorio(pedido);

        // ...
    }

    private void EnviarEmailConfirmacao(Pedido pedido)
    {
        // Lógica para enviar o email
    }

    private void AtualizarEstoque(Pedido pedido)
    {
        // Lógica para atualizar o estoque
    }

    private void GerarRelatorio(Pedido pedido)
    {
        // Lógica para gerar o relatório
    }
}

// Classes refatoradas
public class EmailService
{
    public void EnviarEmailConfirmacao(Pedido pedido)
    {
        // Lógica para enviar o email
    }
}

public class EstoqueService
{
    public void AtualizarEstoque(Pedido pedido)
    {
        // Lógica para atualizar o estoque
    }
}

public class RelatorioService
{
    public void GerarRelatorio(Pedido pedido)
    {
        // Lógica para gerar o relatório
    }
}

public class ProcessamentoPedido
{
    private readonly EmailService emailService;
    private readonly EstoqueService estoqueService;
    private readonly RelatorioService relatorioService;

    public ProcessamentoPedido(EmailService emailService, EstoqueService estoqueService, RelatorioService relatorioService)
    {
        this.emailService = emailService;
        this.estoqueService = estoqueService;
        this.relatorioService = relatorioService;
    }

    public void ProcessarPedido(Pedido pedido)
    {
        // Lógica para processar o pedido

        emailService.EnviarEmailConfirmacao(pedido);
        estoqueService.AtualizarEstoque(pedido);
        relatorioService.GerarRelatorio(pedido);

        // ...
    }
}

Métodos muito longos:

Se você não quer escutar a palavra da Mono-Classe cuidado com o Mono-Método! Métodos longos podem dificultar a compreensão e manutenção do código.
É recomendado que as funções sejam curtas e executem apenas uma tarefa específica. Isso pode ser identificado quando um método possui muitas linhas de código ou realiza várias ações diferentes. A solução é extrair partes do método em funções menores e mais especializadas.

// Método muito longo
public void ProcessarPedido(Pedido pedido)
{
    // Lógica 1
    // ...

    // Lógica 2
    // ...

    // Lógica 3
    // ...

    // ...

    // Lógica 10
    // ...
}

// Método refatorado
public void ProcessarPedido(Pedido pedido)
{
    ProcessarLogica1(pedido);
    ProcessarLogica2(pedido);
    ProcessarLogica3(pedido);
    // ...
    ProcessarLogica10(pedido);
}

private void ProcessarLogica1(Pedido pedido)
{
    // Lógica 1
    // ...
}

private void ProcessarLogica2(Pedido pedido)
{
    // Lógica 2
    // ...
}

// ...

Classe ou método com muitos parâmetros:

Não adianta nada refatorar um método gigante e encher o mesmo de 500 parametros. Quando uma classe ou método possui muitos parâmetros, isso pode indicar uma falta de coesão ou uma responsabilidade excessiva.
Isso pode dificultar a compreensão e o uso da classe ou método. A solução é agrupar parâmetros relacionados em objetos ou estruturas de dados e passá-los como um único argumento.

// Classe com muitos parâmetros
public class Pedido
{
    public void AdicionarItem(string descricao, decimal preco, int quantidade, DateTime dataEntrega)
    {
        // Lógica para adicionar item
    }
}

// Classe refatorada
public class ItemPedido
{
    public string Descricao { get; set; }
    public decimal Preco { get; set; }
    public int Quantidade { get; set; }
    public DateTime DataEntrega { get; set; }
}

public class Pedido
{
    public void AdicionarItem(ItemPedido item)
    {
        // Lógica para adicionar item
    }
}

Métodos ou classes com baixa coesão:

Ainda falando de baixa coesão, a mesma ocorre quando há muitas responsabilidades ou tarefas diferentes agrupadas em um único método ou classe. Isso pode tornar o código mais difícil de entender e manter. A solução é dividir o método ou classe em partes menores e mais coesas.

// Classe com baixa coesão
public class Relatorio
{
    public void GerarRelatorioVendas()
    {
        // Lógica para buscar dados de vendas

        // Lógica para calcular total de vendas

        // Lógica para formatar e exibir relatório
    }
}

// Classe refatorada
public class Relatorio
{
    public IEnumerable<Venda> BuscarVendas()
    {
        // Lógica para buscar dados de vendas
    }

    public decimal CalcularTotalVendas(IEnumerable<Venda> vendas)
    {
        // Lógica para calcular total de vendas
    }

    public void ExibirRelatorio(IEnumerable<Venda> vendas)
    {
        // Lógica para formatar e exibir relatório
    }

    public void GerarRelatorioVendas()
    {
        var vendas = BuscarVendas();
        var total = CalcularTotalVendas(vendas);
        ExibirRelatorio(vendas);
    }
}

Dependências desnecessárias:

Muitas vezes declaramos classes, ou refatoramos um código e esquecemos varias dependências que não são mais utilizadas. Isso pode aumentar o acoplamento e tornar o código mais frágil. A solução é remover as dependências não utilizadas ou separá-las em classes ou módulos independentes.

// Classe com dependências desnecessárias
public class PedidoService
{
    private readonly EmailService emailService;
    private readonly EstoqueService estoqueService;

    public PedidoService(EmailService emailService, EstoqueService estoqueService)
    {
        this.emailService = emailService;
        this.estoqueService = estoqueService;
    }

    public void ProcessarPedido(Pedido pedido)
    {
        // Lógica para processar o pedido

        emailService.EnviarEmailConfirmacao(pedido);
        estoqueService.AtualizarEstoque(pedido);
    }
}

// Classe refatorada
public class PedidoService
{
    private readonly EmailService emailService;

    public PedidoService(EmailService emailService)
    {
        this.emailService = emailService;
    }

    public void ProcessarPedido(Pedido pedido)
    {
        // Lógica para processar o pedido

        emailService.EnviarEmailConfirmacao(pedido);
    }
}

Muitas responsabilidades em uma classe base:

A famosa classe "Zelador"! Quando uma classe base contém muitas funcionalidades e responsabilidades, ela pode se tornar complexa e difícil de entender. Isso pode levar a problemas de manutenção e dificultar a extensibilidade do código. A solução é extrair as responsabilidades em classes derivadas ou interfaces mais especializadas.

// Classe base com muitas responsabilidades
public class Animal
{
    public void Mover()
    {
        // Lógica para mover o animal
    }

    public void Comer()
    {
        // Lógica para alimentar o animal
    }

    public void Dormir()
    {
        // Lógica para fazer o animal dormir
    }

    // ...
}

// Classes derivadas ou interfaces especializadas
public interface IMovel
{
    void Mover();
}

public interface IComivel
{
    void Comer();
}

public interface IDormivel
{
    void Dormir();
}

public class Cachorro : IMovel, IComivel, IDormivel
{
    public void Mover()
    {
        // Lógica para mover o cachorro
    }

    public void Comer()
    {
        // Lógica para alimentar o cachorro
    }

    public void Dormir()
    {
        // Lógica para fazer o cachorro dormir
    }

    // ...
}

// ...

Uso excessivo de comentários:

Eu sempre digo que a arquitetura/código bem feito(a) é auto explicativo. Por mais que os comentários sejam úteis para explicar o propósito de um código, o uso excessivo deles pode ser indicativo de código mal escrito ou falta de clareza. Um código limpo e bem estruturado deve ser autoexplicativo na maioria dos casos. A solução é simplificar o código e usar nomes descritivos para classes, métodos e variáveis.

// Classe para calcular o total do pedido
public class CalculadoraPedido
{
    // Método para calcular o total do pedido
    public decimal CalcularTotalPedido(Pedido pedido)
    {
        decimal total = 0;

        // Loop pelos itens do pedido
        foreach (var item in pedido.Itens)
        {
            // Cálculo do subtotal do item
            decimal subtotal = item.Preco * item.Quantidade;

            // Adicionar o subtotal ao total
            total += subtotal;
        }

        // Retornar o total do pedido
        return total;
    }
}

Objetos com muitas propriedades:

Quando você cria um objeto com um grande número de propriedades, isso pode indicar uma falta de coesão e um design pouco eficiente. Uma classe com muitas propriedades pode ser difícil de entender e pode indicar que ela está tentando fazer muitas coisas ao mesmo tempo (muitas vezes mais do que deveria). A solução é revisar a classe e identificar se é possível dividir suas responsabilidades em classes mais especializadas ou agrupar propriedades relacionadas em objetos compostos.

// Classe com muitas propriedades
public class Pessoa
{
    public string Nome { get; set; }
    public int Idade { get; set; }
    public string Endereco { get; set; }
    public string Telefone { get; set; }
    public string Email { get; set; }
    // ...
}

// Classe refatorada
public class Pessoa
{
    public string Nome { get; set; }
    public int Idade { get; set; }
    public Endereco Endereco { get; set; }
    public Contato Contato { get; set; }
    // ...
}

public class Endereco
{
    public string Logradouro { get; set; }
    public string Cidade { get; set; }
    public string Estado { get; set; }
    public string CEP { get; set; }
    // ...
}

public class Contato
{
    public string Telefone { get; set; }
    public string Email { get; set; }
    // ...
}

Falta de tratamento de erros adequado:

Eu sei em, você ja fez ou viu um Catch vazio... Um código que não possui tratamento adequado de erros, como exceções não capturadas ou blocos catch vazios, pode resultar em falhas no sistema e comportamentos inesperados. É importante implementar tratamento de erros apropriado para lidar com exceções e situações inesperadas de forma segura e controlada.

// Falta de tratamento de erros adequado
public decimal Dividir(decimal a, decimal b)
{
    return a / b;
}

// Tratamento de erros adequado
public decimal Dividir(decimal a, decimal b)
{
    try
    {
        return a / b;
    }
    catch (DivideByZeroException ex)
    {
        // Lógica para lidar com a divisão por zero
        throw;
    }
    catch (Exception ex)
    {
        // Lógica para lidar com outras exceções
        throw;
    }
}

Falta de testes automatizados:

É eu sei , se funciona na produção com certeza funciona na homologação. A falta de testes automatizados é um code smell comum em projetos.
A ausência de testes unitários adequados torna mais difícil verificar a corretude do código e introduz riscos de regressão. É recomendado implementar testes automatizados para garantir que o código funcione corretamente e evitar problemas futuros.

// Falta de testes automatizados

// Código a ser testado
public decimal CalcularTotal(List<decimal> valores)
{
    decimal total = 0;
    foreach (var valor in valores)
    {
        total += valor;
    }
    return total;
}

// Implementação de testes automatizados
[TestFixture]
public class CalculadoraTests
{
    [Test]
    public void CalcularTotal_DeveRetornarSomaDosValores()
    {
        // Arrange
        var calculadora = new Calculadora();
        var valores = new List<decimal> { 1.5m, 2.5m, 3.5m };

        // Act
        var resultado = calculadora.CalcularTotal(valores);

        // Assert
        Assert.AreEqual(7.5m, resultado);
    }
}

Ausência de documentação adequada:

Principalmente para quem faz componentes, dlls, frameworks entre outros códigos que serão consumidos por terceiros, um código não possuir documentação adequada, como comentários explicativos ou documentação XML, pode ser difícil para outros desenvolvedores entenderem o propósito e o funcionamento do código. É recomendado fornecer documentação clara e concisa para ajudar na compreensão e no uso correto do código.

// Ausência de documentação adequada
public class Cliente
{
    public string Nome { get; set; }
    public string Email { get; set; }
}

// Documentação adequada
/// <summary>
/// Representa um cliente no sistema.
/// </summary>
public class Cliente
{
    /// <summary>
    /// Obtém ou define o nome do cliente.
    /// </summary>
    public string Nome { get; set; }

    /// <summary>
    /// Obtém ou define o e-mail do cliente.
    /// </summary>
    public string Email { get; set; }
}

Ufa! Acho que por hoje ta bom né? hahaha. É claro que existem muitos outros casos, mas creio que com esses exemplos você ja entendeu os mais comuns e tambem a ideia dos Code Smells conseguindo identifica-los.

Caso queira entender mais sobre SOLID e alguns dos principios citados eu recomendo escutar nossos episódios do DEVSHOW Relacionados ao tema.

Espero ter ajudado!

Aquele abraço!

10 Dicas Basicas de Arquitetura de Código : 1 - Aproveitando os Benefícios da Virtualização

Thiago Bertuzzi 👨🏻‍💻 — Tue, 06 Jun 2023 20:30:35 +0000

Fala galera,

tudo beleza?

Vou começar uma serie de artigos de dicas basicas para desenvolvedores com conceitos simples e uteis de Arquitetura com .net (Mesmo que você consiga aplicar para sua linguagem :) ).

Hoje vamos falar de Métodos Virtuais ! Bora!

Por mais que alguns escrevam artigos dizendo o contrario, a arquitetura de software desempenha um papel fundamental no desenvolvimento de aplicativos eficientes e escaláveis.

Uma das abordagens mais poderosas é a utilização de métodos virtuais. Essa técnica oferece uma série de benefícios que vão desde a extensibilidade até a facilidade de manutenção do código.

O que são métodos virtuais?

Um método virtual é aquele que pode ser sobrescrito em uma classe derivada, permitindo que seu comportamento seja modificado para atender às necessidades específicas dessa classe. Essa flexibilidade é alcançada através do uso da palavra-chave virtual na declaração do método na classe base e da palavra-chave override na declaração do método na classe derivada.

E Quais as vantagens?

- Extensibilidade: Ao utilizar métodos virtuais, é possível estender a funcionalidade de uma classe base através da criação de classes derivadas que substituem o comportamento dos métodos virtuais. Isso permite adicionar novos recursos ou personalizar o comportamento existente sem modificar a classe base, mantendo assim a integridade do código.

- Polimorfismo: O polimorfismo é um dos princípios fundamentais da programação orientada a objetos, e os métodos virtuais são uma ferramenta essencial para sua implementação. Com métodos virtuais, é possível tratar objetos derivados como objetos da classe base, facilitando o uso de herança e permitindo que diferentes implementações de um método sejam invocadas com base no tipo de objeto em tempo de execução.

- Manutenção simplificada: As modificações em um método na classe base refletem-se automaticamente em todas as classes derivadas que o sobrescrevem. Isso simplifica a manutenção do código, uma vez que as alterações são centralizadas e propagadas para todas as partes relevantes do sistema.

Vamos ver um exemplo bem facil para isso :

public class Pessoa
{
    public virtual void MeuCabelo()
    {
        Console.WriteLine("Meu Cabelo Esta grande");
    }
}

public class Bertuzzi : Pessoa
{

}

public class Andre : Pessoa
{
    public override void MeuCabelo()
    {
        Console.WriteLine("Meu Cabelo Esta Sumindo.");
    }
}

public class Ewerton : Pessoa
{
    public override void MeuCabelo()
    {
        Console.WriteLine("Meu Cabelo Sumiu.");
    }
}

class Program
{
    static void Main(string[] args)
    {
        var bertuzzi = new Bertuzzi();
        var andre = new Andre();
        var ewerton = new Ewerton();

        bertuzzi.MeuCabelo(); // Saída: "Meu Cabelo Esta grande."
        andre.MeuCabelo();   // Saída: "Meu Cabelo Esta Sumindo."
        ewerton.MeuCabelo(); // Saída: "Meu Cabelo Sumiu."
    }
}

Neste exemplo, a classe base Pessoal possui um método virtual MeuCabelo() que exibe uma frase genérico. As classes derivadas Andre e Ewerton substituem esse método para exibir suas proprias fases genericas. Ao instanciar os objetos e chamar o método MeuCabelo(), o comportamento apropriado é invocado com base no tipo de objeto em tempo de execução.

Como a classe Bertuzzi não sobrescreve o método, a mesma possui o comportamento do método Virtual.

Simples não? Com essa implementação simples muitos softwares que as vezes precisam de comportamentos especificos podem ser implementados de maneira facil ;).

Caso queira saber mais sobre o assunto abordado no principio de OCP (Open-Closed Principle). Vou deixar esses dois links que eu recomendo muito :

1 - DEVSHOW #22 – SOLID (OCP)
2 - SOLID: OCP - Open/Closed Principle (Princípio do Aberto/Fechado)

Espero ter ajudado!

Aquele abraço!

ChatGPT e 500 Ferramentas de i.a. : Meus dados estão protegidos?

Thiago Bertuzzi 👨🏻‍💻 — Thu, 01 Jun 2023 16:33:35 +0000

Fala galera,

tudo beleza?

Com a nova onda de centenas de serviços de inteligencia artificial onde o objetivo é destruir o mundo e criar a matrix, diversas empresas estão cada vez mais dependentes dessas tecnologias.
Diversos sistemas de inteligência artificial (IA) e chatbots, como o ChatGPT, para aprimorar ( e acelerar) suas operações e melhorar a experiência do cliente.

Porem... essa "novidade" e enorme adoção de novas tecnologias também traz consigo preocupações significativas em relação à segurança de dados sensíveis, o que curiosamente eu vejo varias pessoas ignorarem enquanto estão deslumbradas com a tecnlogia.

Vamos bater um papo de por que as empresas devem se preocupar com a segurança de dados e dar algumas dicas práticas sobre como protegê-los em um cenário novo e dominado pela IA.

Bora?

A I.A. e Meu novo empregado o ChatGPT :

Bem não é novidade para ninguem que mais utilizado que as redes sociais para compartilhar fotos da nossa vida, o ChatGPT tem sido utilizado de forma massiva tanto para estudos, inutilidades e principalmente no mundo corporativo.

Caso você tenha saido da caverna hoje, o ChatGPT é um modelo de linguagem baseado em IA que pode gerar respostas humanas em conversas. Embora seja uma ferramenta poderosa para comunicação e interação com os clientes, é importante reconhecer os desafios associados à segurança de dados que surgem com sua utilização.

Existem muitas empresas realizando integrações com a tecnologia do ChatGPT entre outras ferramentas, enviando documentos, dados de clientes, pesquisas constantes com informações da empresa e etc.

Não podemos nos esquecer que mesmo com essa facilidade a segurança de dados sensíveis é essencial para proteger a confidencialidade, integridade e disponibilidade das informações. Se uma empresa lida com dados confidenciais de clientes, como informações pessoais, dados financeiros ou segredos comerciais, qualquer violação pode levar a consequências graves. Isso inclui danos à reputação, perda de clientes, multas regulatórias e possíveis litígios.

Certo, mas como podemos utilizar o bom da "nova" tecnologia mas continuar seguros?

Algumas dicas para proteger dados sensiveis :

Criptografia: Todo cuidado é pouco na hora de trafegar informações, Documentos, Imagens e etc. Utilize técnicas de criptografia para proteger os dados sensíveis durante o armazenamento e a transmissão. Isso garante que mesmo se houver uma violação de segurança, os dados permanecerão inacessíveis para os invasores.
Controles de acesso: Um Chat própio na empresa é interessante. Mas sera que todos podem buscar qualquer coisa e receber os mesmos resultados? Implemente medidas rigorosas de controle de acesso para limitar quem pode acessar os dados sensíveis. Apenas funcionários autorizados devem ter permissão para visualizar, modificar ou manipular essas informações.
Monitoramento e detecção de ameaças: Mais uma tecnologia, mas uma abertura para problemas externos (e internos claro). Implemente sistemas de monitoramento de segurança para identificar possíveis ameaças e atividades suspeitas. Isso inclui a detecção de padrões incomuns de acesso, tentativas de intrusão ou atividades maliciosas.
Treinamento e conscientização dos desenvolvedores: treine e ensine seus desenvolvedores sobre as melhores práticas de desenvolvimento seguro ,de dados e a importância de proteger informações sensíveis.
Treinamento e conscientização dos funcionários: Mesmo com o tópico anterior não adianta implementar sistemas seguros se os funcionarios não fazem sua parte. Eduque seus funcionários sobre as melhores práticas de segurança de dados e a importância de proteger informações sensíveis. Eles devem estar cientes dos riscos envolvidos e saber como evitar ameaças, como phishing e engenharia social.
Avaliações regulares de segurança: Realize avaliações periódicas de segurança para identificar possíveis vulnerabilidades em seus sistemas e processos. Isso ajudará a garantir que todas as medidas de segurança estejam atualizadas e sejam eficazes contra as ameaças mais recentes.

Lembre-se sempre, cada tecnologia que facilita o dia a dia pode abrir portas para problemas ou brechas de segurança. Nós como desenvolvedores, arquitetos e profissionais de TI em geral devemos sempre estar atentos a esses problemas.

Caso queria saber mais sobre Desenvolvimento seguro vou deixar aqui este meu outro artigo : Desenvolvimento Seguro, S-SDLC

Alem disso , sera que O CHATGPT SUBSTITUIRÁ OS DESENVOLVEDORES?

Espero ter ajudado!

Aquele abraço!