Chaves Secretas API Keys
Como criptografar e distribuir entre os desenvolvedores?
Como disponibilizar as API Keys seguramente?
A maioria nunca fez e/ou não sabe como fazer. Confesso que normalmente desenvolvedores com “maior senioridade” geralmente encarregam-se desta parte durante o setup do projeto. No entanto, cedo ou tarde, alguém terá que disponibilizar as API-Keys de tal maneira, que os desenvolvedores tenham acesso as mesmas.
Na verdade, isso é algo que deveria ser pensado logo no início do projeto. Neste post, irei te mostrar uma maneira que conheci recentemente, que é comumente usada nas empresas europeias com muita frequência em projetos privados. No final desse post você vai encontrar;
Um vídeo explicando tudo na prática.
Todo o código fonte, caso precise.
Disclaimer
Esse conceito é muito comum em projetos privados. Não recomendo faze-lo em um projeto opensource ou diponível abertamente ao público no github. No entando, em projetos privados, a abordagem que apresentarei, traz uma série de benefícios, como veremos no final do post.
O Desafio
A grande maioria dos aplicativos móveis hoje em dia, usam ou irão usar algum tipo de chave, token ou credenciais para utilizar alguma API, serviço de terceiro ou para gerar o próprio build(binário) da aplicação.
O problema com essas credenciais é que elas tem que existir no aplicativo, porém não devem existir no repositório, pois um possível vazamento das mesmas, daria ao detentor toda a liberdade para fazer o que quiser com a aplicação incluindo modifica-la, realizar requisições indesejadas, causar danos a usuários ou a empresa etc.
Maneira convencional - Trade-Off entre agilidade e segurança
Necessidade: Os desenvolvedores precisam das credenciais(usuários, passwords, tokens de acesso etc.) localmente para poder desenvolver de maneira autonoma, resolver bugs expeditivamente, testar features em ambientes diferentes, dar manutenção etc.
Pessoas Chaves: Geralmente são poucas as pessoas que conhecem essas credencias. Elas são depositadas usualmente no agente de build e acessada apenas pelo arquiteto, desenvolvedor senior ou pessoa responsável pela geração dos binários que são distribuidos para testes ou playstores.
Maneira Convencional - Vantagens & Desvantagens
Desvantagem:
Essa abordagem restringe/freia muito o desenvolvimento, manutenção e gera uma gargalo desnecessário.
Certas funções, ambientes de desenvolvimento ou bugs não conseguem ser testados ou resolvidos na mesma velocidade ou com melhor eficiência, já que algumas funções dependem dessas credenciais.
As credenciais precisam ser guardadas seguramente em algum lugar e os detentores precisam saber, quais credencias estão associadas ao projeto em questão.
Vantagem:
Por outro lado, a probabilidade de vazamento de credenciais é menor, dado que apenas algumas pessoas tem acesso às mesmas.
Outra vantagem é que por serem pessoas mais experientes, espera-se que errem menos ao gerar releases do software.
Alternativa (Você vai curtir)
Me deparei com essa solução recentemente e confesso que gostei muito, pois ela acelera bastante o desenvolvimento. Mas deixa detalhar primeiro os componenes envolvidos nessa abordagem com o gráfico a seguir:
A estratégia consiste no seguinte:
loca.properties do projeto são ignoradas no git.
As credenciais necessárias são depositadas dentro dessa local.properties
Dois scripts são criados no projeto (encrypt_secrets.sh e decrypt_secrets.sh)
Uma arquivo local.properties.encrypted é gerado e comitado no projeto
A password usada nesses scripts é salva no cofre da empresa (ex: MacPass)
Como alternativa, colocamos a password no .bashrc para facilitar ainda mais
(vale ressaltar que nossos Laptops são todos criptografados em caso de furto)
Como funciona na prática?
O desenvolvedor baixa o projeto para sua máquina local
Acessa o MacPass da empresa, pega a senha, roda o script de decrypt_secrets.sh
O script descriptografa as credenciais e as disponibiliza em local.properties
A partir de agora o desenvolvedor tem tudo que precisa para desenvolver
Chegando novas credenciais, elas são definidas em local.properties
O desenvolvedor roda o script encrypt_secrets.sh com a senha da empresa
Disponibiliza o arquivo local.properties.encrypted para projeto através do git
Todos desenvolvedores ganham acesso imediatamente às novas credenciais
Vantagens & Desvantagens
Desvantagem:
Grandes poderes, grandes responsabilidades. Exige uma maturidade e responsabilidade maior do time, pois todo mundo “pode” tudo.
Mais propenso a vazamento de credenciais, uma vez que mais pessoas tem acesso as mesmas.
Vantagem:
Todas as chaves são guardadas de maneira segura nos seus respectivos projetos. (não se perdem tão fácilmente)
Baixando o projeto, todo desenvolvedor tem tudo que precisa para executar o projeto imediatamente.
Maior flexibilidade do desenvolvedor para manter e testar a aplicação localmente.
Resolução de bugs e testes mais rápidos e com maior eficiência.
Remove dependências e gargalos de gerentes ou proprietários de agentes de build.
Abordagem comummente usada em projetos privados e o agente de build pode acessar as credenciais em memória na hora de gerar os builds.
Conclusão
As vantagens da segunda abordagem são bem mais significativas em relação a primeira solução (maneira convencional), de maneira que optaria por ela sempre que possível. A priori, achei a segunda abordagem um pouco “perigosa”, no entanto, ao me familiarizar com os prós e contras, logo conclui que ela é realmente bem melhor e aumenta muito nossa produtividade como time, além de termos muito mais liberdade e autonomia para atender aos nossos clientes e dar manutenção aos projetos.
Com relação ao quesito “perigosa”, que se refere principalmente a um vazamento de credenciais, todos nós assinamos termos de confiabilidade, justamente para previnir esse tipo de coisa. O que não impede que algum funcionário vaze alguma informação sigilosa.
Na primeira abordagem também temos essa possibilidade de vazamento, embora estajamos menos espostos. (Já que o grupo de pessoas que conhecem as credenciais é menor) Dito isso, eu tendo, a partir de agora, a usar sempre a segunda abordagem, pois ela nos oferece mais vantagens.
Precisa compartilhar credenciais?
Veja na prática como se faz!
Agora que você já sabe porque isso é tão importante, veja como criar o código e scripts necessários para proteger e compartilhar as credenciais um projeto real kotlin multiplatform mobile:
Quer mais conteúdo assim?
Me siga, se você gosta desse tipo de conteúdo técnico didático e feito com muito carinho. ❤️
Você me encontra no 🐦twitter, 🦑 Github ou no 📺 Youtube onde tenho um curso gratuito “Do zero ao certificado Android”, outro chamado “Resoluções a problemas comuns Android” e Android Jetpack Compose disponíveis 0800 para você.
Para não perder nenhum conteúdo, inscreva-se nesse techblog clicando aqui: