10 Dicas Basicas de Arquitetura de Código : 3 - Cuidado com o que você armazena no seu código
Tags: architecture, security, git, dotnet
Published: 2023-07-05 14:33:21

![Bertuzzi no PC](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wttrskymaeyv4461r1j9.png)

Fala galera,

tudo beleza?

Dando continuidade a serie de artigos sobre arquitetura (se não viu a parte 2 [clique aqui](https://dev.to/tbertuzzi/10-dicas-basicas-de-arquitetura-de-codigo-2-code-smells-54nf)), 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. 


![Bertuzzi detetive](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zr1vv5fx0eqygcr4w5si.png)

**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.


![Bertuzzi Check](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v17sw52y8h06i7p3sc3e.png)

**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](https://www.youtube.com/watch?v=l5m6QeEWIZc)) , 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](https://dev.to/tbertuzzi/desenvolvimento-seguro-s-sdlc-1n4f)

Espero ter ajudado!

Aquele abraço!