Como dar acesso à sua equipe sem repartir senhas
Publicado em 2026-09-12 por frfrand
Por qué la contraseña compartida siempre termina filtrada, cómo se reparte el acceso por persona y por proyecto, y qué tiene que pasar el día que alguien se va del equipo.
Começa sempre igual e sempre com boa intenção. Precisa entregar algo, entra alguém novo, e a forma rápida é repassar a senha que já existe.
O problema não é essa decisão. É que não tem volta.
Seis meses depois, essa senha vive em três chats diferentes, é conhecida por pessoas que já não trabalham no projeto, e mudá-la implica coordenar com sete pessoas ao mesmo tempo. Então não se muda.
Por que a credencial compartilhada é um problema estrutural
Não é uma questão de cuidado. São quatro propriedades que ela tem por design.
Não pode ser revogada parcialmente. Se quiser tirar o acesso de uma pessoa, tem que mudar a credencial para todos. Como isso incomoda todo mundo, é adiado indefinidamente.
Não identifica. O log diz que "o usuário admin reiniciou o serviço". Não serve para entender o que aconteceu, e também não para pedir ajuda: não se sabe a quem perguntar.
Não pode ser graduada. Uma senha dá tudo ou nada. Não existe "pode ver os logs, mas não reiniciar", que costuma ser exatamente o que é preciso.
Se copia sem deixar rastro. Uma credencial que passou por um chat está no histórico desse chat, no backup dele, e em qualquer máquina onde alguém a tenha colado em um arquivo temporário.
O modelo que funciona: uma identidade por pessoa
A alternativa não é complicada de descrever:
- Cada pessoa entra com a própria conta.
- Cada pessoa tem sua própria chave SSH, e o servidor guarda as chaves públicas de todas.
- As permissões são concedidas à pessoa, não a uma credencial que circula.
A mudança importante não está em como o acesso é concedido, mas em como ele é revogado. Remover uma pessoa passa de ser "coordenar uma mudança de senha com toda a equipe" para "excluir uma linha".
Sobre as chaves SSH vale esclarecer um ponto que confunde muita gente: não há nenhum problema em o servidor ter as chaves públicas de dez pessoas em ~/.ssh/authorized_keys. A chave pública não permite deduzir a privada. Remover alguém é apagar sua linha desse arquivo, e isso não afeta ninguém mais.
Três perguntas antes de conceder um acesso
Vale a pena fazer essas perguntas uma vez, no início. Elas evitam muita limpeza depois.
Quem é essa pessoa? Sua própria conta, sempre. Mesmo que seja por duas semanas. Mesmo que seja o fundador.
O que ela precisa tocar? Quase nunca é "tudo". Um freelancer que trabalha para um cliente precisa ver esse cliente. Um designer precisa enviar arquivos, não reiniciar serviços.
Por quanto tempo? Um contratado não é um membro permanente. Se o acesso tem data de término, defini-la desde o primeiro dia é gratuito; lembrar disso dentro de três meses, não.
A regra padrão: conceder o menor escopo possível que permita realizar o trabalho. Ampliar depois é um clique; perceber que era demais, não.
Como resolvemos isso na ArduMaker
A estrutura da plataforma é montada em torno disso.
As Empresas separam clientes. Cada cliente vive em sua própria Empresa, com seus VPS, seus domínios, sua faturação e sua equipe. Alguém que pertence a uma Empresa não vê as outras. Não é uma questão de permissões bem configuradas: não há um lugar onde elas se toquem.
Os cargos separam responsabilidades. Um Membro trabalha; apenas um Admin mexe em meios de pagamento e faturação. O desenvolvedor que implanta não precisa, nem vê, o cartão do cliente.
As chaves SSH são por pessoa. Cada usuário do VPS tem a sua, são carregadas a partir do painel e são removidas uma a uma.
Tudo fica registrado. Cada comando executado em um VPS a partir da plataforma registra quem o lançou e quando.
O dia em que alguém sai
Esta é a prova real do modelo. Se a lista levar mais de cinco minutos, algo estava mal montado antes.
- Remover a associação. Uma ação, em um único lugar.
- Dar baixa na chave SSH. Trivial se as chaves eram por pessoa.
- Rotacionar o que essa pessoa sabia de cor. Idealmente, pouco: tokens de API que tenha usado e credenciais de serviços externos.
- Ver o registro. O que tocou nas últimas semanas. Não por desconfiança: porque se deixou algo pela metade, é melhor saber agora.
A ideia curta
Repartir acesso é fácil. O difícil, e o que define se sua equipe tem um problema de segurança ou não, é poder removê-lo rápido e sem quebrar o trabalho de ninguém mais.
Se hoje você tivesse que tirar uma pessoa da sua produção, quanto demoraria? Essa resposta diz mais sobre sua infraestrutura do que qualquer checklist.
