Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta

[Resolvido] Dúvida em questão de ApiKeys salvas em variáveis de ambiente

Boa noite a todos!
Estou com dúvida em relação se armazenar dados sensíveis como login/password de Banco de Dados ou ApiKeys em variáveis de ambiente.
Este método seria a única opção que trás como solução de segurança para criação do programa e/ou já ter o programa em produção?

Pergunto isto pois foi visto sugestão via fórum de criar arquivos .env para armazenar estes dados, utilizando o dotenv no Java para ler estes arquivos e ter acesso as variáveis.
Também verifiquei outra solução para o caso que seria a segregação das informações do arquivo application.properties, criando outros três arquivos como application-local.properties / application-dev.properties / application-prod.properties, onde deixaria os dados sensíveis nestes arquivos, deixando no application.propertiesapenas as informações abaixo, onde o spring.profiles.active seria o perfil responsável, por exemplo, de acessar o banco local ou de produção.

application.properties

spring.application.name=screenmatch
spring.profiles.active=local

application-local.properties

api.omdb.key=ApiKeyOMDBAqui
spring.datasource.url=jdbc:postgresql://localhost:5432/alura_series
spring.datasource.username=postgres
spring.datasource.password=password
spring.datasource.driver-class-name=org.postgresql.Driver
spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect

spring.jpa.hibernate.ddl-auto=update

Na sugestão do application.properties, foi sugerido de manter no .gitignore a seguinte inclusão:

### Spring Boot / Configs sensíveis ###
application-local.properties
application-dev.properties
application-prod.properties
.env

Gostaria de saber se há problemas com cada abordagem e quais seriam as vantagens para cada uma delas.
Desde já, muito obrigado a todos!

1 resposta
solução!

Olá, Leandro

Não, as variáveis de ambiente do sistema operacional não são a "única" opção, mas são o padrão-ouro para ambientes de produção.

Variáveis de Ambiente (Sistema Operacional)

É o método onde você define os valores diretamente no SO (Windows, Linux) ou no painel do seu provedor de nuvem (AWS, Azure, Heroku).

  • Vantagem: É o mais seguro para produção. O segredo (senha, key) nunca toca o código e nem arquivos físicos que podem ser copiados acidentalmente.
  • Desvantagem: Pode ser trabalhoso configurar no ambiente local de desenvolvimento (ter que ficar criando variáveis no Windows/Linux para cada projeto novo).

arquivos .env (com biblioteca dotenv)

Muito popular em Node.js e Python, e tem ganhado espaço no Java.

  • Vantagem: Facilita muito o ambiente local. Você cria um arquivo .env com DB_PASSWORD=123456, coloca no .gitignore e pronto. O código lê isso como se fosse uma variável de ambiente.
  • Desvantagem: Requer uma dependência extra no Java (biblioteca dotenv) e exige disciplina rígida para nunca esquecer de incluir o arquivo no .gitignore.

Spring Profiles (application-local.properties + .gitignore)

Essa é a abordagem que você detalhou e ela é excelente, especialmente por ser nativa do Spring.

  • Como funciona: Você tem configurações específicas para dev, local e prod.
  • A abordagem híbrida (Melhor dos mundos):
  • No application.properties (que vai para o Git), você define referências para variáveis de ambiente, ex: spring.datasource.password=${DB_PASSWORD}.
  • No application-local.properties (que fica no seu computador e no .gitignore), você pode colocar o valor real para testar: spring.datasource.password=senha123.

A solução que você propôs de usar application-local.properties e adicioná-lo ao .gitignore é uma prática muito comum e válida para o desenvolvimento local. Ela mantém seu código limpo e seguro enquanto você programa.

Para quando a aplicação for para o "mundo real" (produção), a tendência é que o arquivo application-prod.properties não tenha as senhas escritas nele, mas sim as referências (${ENV_VAR}), e quem injeta esses valores é o servidor/container onde a aplicação roda.