Como dar acesso à loja Magento para um dev sem entregar a chave da casa

Posso passar o meu usuário de admin para o dev?

Não passe. Além do risco óbvio, o próprio Magento atrapalha:

• Um derruba o outro. A opção Admin Account Sharing, em Stores > Settings > Configuration > Advanced > Admin > Security, vem como No. Assim, quando o dev entra com o seu usuário, a sua sessão cai com a mensagem Someone logged into this account from another device or browser. Your current session is terminated.
• O 2FA é seu. A autenticação em dois fatores é configurada por usuário, no primeiro login. Compartilhar o usuário significa compartilhar o código do seu celular.
• Não dá para saber quem fez o quê. O relatório Action Logs é exclusivo do Adobe Commerce e não existe no Magento Open Source. Mesmo onde existe, usuário compartilhado registra tudo no seu nome.
• Revogar vira trocar a sua senha, e você perde o controle de quando o acesso acaba.

Criar usuário admin com permissão restrita no Magento 2

1. Crie o papel. Em System > Permissions > User Roles, clique em Add New Role. Na aba Role Info, dê um nome que diga a tarefa, como "Dev ajuste de frete". Na aba Role Resources, troque Resource Access para Custom e marque só as áreas necessárias. Deixe desmarcado o próprio Permissions: a documentação da Adobe avisa que, com ele liberado, o usuário consegue alterar as próprias permissões.
2. Crie o usuário. Em System > Permissions > All Users, clique em Add New User, use o e-mail do dev e preencha Expiration Date. Segundo a documentação, depois dessa data a conta passa para Inactive.
3. Ligue o usuário ao papel na aba User Role. Sem papel, a conta não entra.

No primeiro login, o dev configura o próprio 2FA, que a documentação da Adobe trata como obrigatório no admin.

Um detalhe que conferi no código do 2.4.8-p4: a data vale mesmo com o cron parado. No login, o módulo de segurança confere a expiração e recusa o usuário vencido com a mensagem genérica de login incorreto; se a sessão já estiver aberta, ela cai na próxima tela do admin. A tarefa agendada security_deactivate_expired_users, que roda de hora em hora, só marca como Inactive as contas vencidas que ninguém tentou usar. Por isso, com o cron parado, a lista de usuários pode mostrar como ativa uma conta que já não entra. Na revisão de acessos, olhe a data de expiração, e não só o status.

Loja com vários sites? A opção Role Scopes em Custom, que limita o papel a websites específicos, é recurso do Adobe Commerce segundo a documentação.

E se o dev pedir para criar o usuário pelo bin/magento?

O comando bin/magento admin:user:create existe e é útil, mas não para esse caso. As opções documentadas são nome, sobrenome, e-mail, usuário e senha; não há opção de papel nem de expiração. E no código de instalação do Magento, que conferi no 2.4.8-p4, o usuário novo criado por ele é ligado ao papel Administrators, ou seja, acesso total ao admin.

A regra que eu uso: admin:user:create serve para o dono recuperar o próprio acesso. Para terceiro, o usuário nasce pelo admin, já com papel restrito e data de expiração. Se precisar mesmo criar pela linha de comando, troque o papel e preencha a expiração logo em seguida.

Tarefa por tarefa: o acesso mínimo que eu liberaria

O acesso certo depende do perfil contratado (backend, frontend ou DevOps, como explico em o que faz um programador Magento) e da tarefa:

Repare na última linha: sistema externo não deveria usar usuário de pessoa. A tela Integrations gera token próprio, deixa escolher os recursos da API e tem a opção Reauthorize para gerar tokens novos quando alguém que teve acesso a eles sai do projeto.

Acesso SSH por chave e usuário de banco só leitura

SSH: o dev manda a chave pública (a privada nunca sai do computador dele) e a hospedagem cria um usuário só para ele, sem root. Revogar é apagar a chave desse usuário. Senha de SSH compartilhada, ainda mais de root, é exatamente o que este roteiro evita.

Banco só leitura: para diagnóstico, um usuário com SELECT resolve. No MariaDB e no MySQL, trocando loja pelo nome do banco:

CREATE USER 'dev_leitura'@'localhost' IDENTIFIED BY 'troque-por-senha-gerada';
GRANT SELECT ON loja.* TO 'dev_leitura'@'localhost';

Testei num MariaDB 11.4 descartável: a consulta funciona e uma tentativa de UPDATE volta com ERROR 1142 (42000) e a mensagem UPDATE command denied to user. O 'localhost' faz o dev conectar só de dentro do servidor, pelo SSH, e não pela internet. Para encerrar, DROP USER 'dev_leitura'@'localhost';.

O limite dessa solução: só leitura continua lendo tudo, inclusive nome, e-mail, endereço e o CPF, quando a loja guarda o documento no campo taxvat. Pela LGPD, acesso já é tratamento de dado pessoal, e quem trata em nome da loja é operador. Para trabalho no staging, o certo é uma cópia do banco sem dado pessoal.

O que nunca mandar por WhatsApp ou e-mail

• app/etc/env.php: guarda a conexão com o banco e a chave de criptografia que a loja usa para proteger senhas e dados sensíveis.
• Chaves de acesso do Marketplace (as do auth.json): funcionam como usuário e senha do repositório repo.magento.com.
• Cópia do banco ou backup completo: tem os dados de todos os clientes.
• Senha do seu usuário admin, da hospedagem ou do painel do gateway.

Segredo que precisa chegar ao dev vai por um cofre de senhas com compartilhamento ou por um link que expira, e é trocado quando o trabalho termina. Gateway no staging usa credencial de sandbox, nunca a de produção. No fim do contrato, a lista é curta: conta do admin em Inactive, chave SSH removida, usuário de banco apagado, integração revogada e segredos compartilhados trocados.