CapordiaNomear os responsáveis antes de distribuir os acessos
Distinga o responsável pelo dossiê de locação, a pessoa que autoriza o acesso ao projeto e aquela que pode aplicar as mudanças técnicas no alvo. O responsável pelos resultados não precisa necessariamente iniciar processos ou administrar a máquina. Escreva as operações necessárias antes de escolher os direitos: ler um export, depositar entradas, executar uma tarefa ou modificar um ambiente.
Verifique em seguida o escopo dos acessos efetivamente concedidos. Se você não tiver o direito de criar identidades ou configurar permissões, peça que confirmem o procedimento possível antes de convidar outros envolvidos. Não contorne esse limite distribuindo a senha da conta Capordia. O compartilhamento do trabalho e a gestão do dossiê comercial são duas questões diferentes.
Usar uma identidade individual e conhecer seu alcance
Uma identidade individual permite retirar o acesso de uma pessoa sem substituir o de toda a equipe. Em uma organização SSH por chaves, o OpenSSH distingue a chave pública conhecida pelo servidor da chave privada mantida pelo usuário. O documento de coordenação pode conter uma referência ou impressão digital de chave pública; ele nunca deve conter a chave privada ou sua frase de proteção.
Duas chaves diferentes que dão acesso à mesma conta de sistema não criam automaticamente dois perímetros de arquivos diferentes. As permissões dependem da conta e dos mecanismos configurados na máquina. Decida, portanto, se a exigência recai apenas sobre a autenticação individual ou também sobre a separação das ações. Para as automações, preveja uma identidade e um proprietário explícitos, sem reutilizar discretamente a identidade pessoal de um colega.
Verificar o destino antes de apresentar-lhe uma identidade
No primeiro acesso, controle o nome da máquina, a conta esperada e a impressão digital de sua chave de host a partir de uma referência confiável obtida no processo de entrega dos acessos. Essa chave de host identifica o servidor; ela é distinta da sua chave de usuário. Uma mensagem inesperada de mudança de identidade do servidor merece uma análise, não a exclusão automática da referência conhecida.
O OpenSSH armazena chaves de host e sinaliza suas mudanças. Use essa informação com o contexto: reconstrução anunciada da máquina, endereço modificado ou evento não explicado. Peça confirmação da mudança antes de prosseguir se ela não for esperada. O objetivo não é adicionar um ritual a cada conexão, mas evitar tratar um alerta de identidade como um simples incômodo de exibição.
Exemplo fictício: três envolvidos, três necessidades
A equipe fictícia «Dossier des ouvrages» prepara uma semana de trabalho. Idriss executa os processamentos do projeto A, Noémie revisa os exports e Sacha intervém temporariamente para configurar o ambiente. A equipe deseja os direitos da tabela, mas deve verificar se eles são aplicáveis com o sistema realmente entregue. Não se trata nem de contas de clientes existentes nem de funções de gestão de equipe anunciadas pela Capordia.
O princípio decisivo é que Noémie não obtém um acesso de administração para abrir um resultado e que a intervenção de Sacha tem um fim. Uma aprovação humana por si só não configura nenhum direito: o responsável técnico aplica os mecanismos disponíveis, e depois cada um executa os controles previstos. Se a separação desejada não for viável, o projeto deve adaptar sua organização antes de introduzir dados que exijam essa separação.
| Envolvido | Necessidade | Perímetro desejado | Reavaliação |
|---|---|---|---|
| Idriss, operação | Depositar entradas e iniciar o projeto A | Espaço de trabalho A, sem administração geral | Fim de campanha ou mudança de função |
| Noémie, validação | Ler os exports entregues | Resultados retidos, sem modificação das entradas | Fim da validação |
| Sacha, intervenção | Preparar o ambiente autorizado | Mudança definida e aprovada | Assim que a intervenção for recebida |
Preparar uma ficha de acesso e testar os limites
A ficha relaciona uma pessoa ou uma automação, uma identidade técnica, um aprovador, um perímetro, uma justificativa e um prazo. Guarde a referência da chave pública e o procedimento de retirada sem armazenar os segredos. O OpenSSH ssh-keygen permite exibir a impressão digital de uma chave pública: essa referência ajuda a designar a chave correta em uma adição ou remoção, sem copiar sua parte privada.
Teste uma ação autorizada em um arquivo sintético e depois uma ação deliberadamente fora do perímetro, prevista para ser recusada. Para uma função de leitura, a abertura deve funcionar e uma tentativa de modificação controlada deve ser recusada. Não use dados reais para testar uma proibição de exclusão. Verifique também os caminhos comuns e o destino das saídas, pois um direito correto sobre uma pasta não garante todos os caminhos do programa.
Planejar a remoção e verificar uma nova conexão
Acione a remoção ao final da intervenção, na saída de uma pessoa ou após uma suspeita de comprometimento. O responsável identifica todas as autorizações envolvidas, incluindo os outros caminhos de acesso autorizados para essa mesma identidade. Ele aplica a remoção conforme a configuração real. A diretiva RevokedKeys do OpenSSH é um mecanismo possível entre os documentados; ela não deve ser presumida ativa em uma máquina sem verificação.
Em seguida, verifique se uma nova autenticação com a identidade removida é recusada, sem excluir o acesso de recuperação do responsável. Analise separadamente as sessões já abertas, as tarefas em andamento e as identidades de automação: remover uma autorização e interromper uma atividade são decisões diferentes. Se um trabalho precisar continuar, transfira sua responsabilidade conforme um procedimento acordado em vez de deixar uma identidade órfã.
Evitar atalhos que impedem o controle
Uma chave privada compartilhada impede saber quem deve substituí-la e muitas vezes exige uma rotação coletiva. Um acesso amplo "provisório" tende a durar se ninguém tiver definido sua data de revisão. Uma conta de validação usada também para administrar a máquina torna os controles de separação difíceis de interpretar. Corrija esses problemas na ficha de acesso antes que se tornem uma dependência da operação.
Evite também adicionar encaminhamentos de agente, túneis ou exceções de acesso apenas para contornar uma dificuldade não diagnosticada. Peça ao responsável autorizado que descreva a necessidade de conexão e suas restrições. Este guia não propõe uma configuração de servidor universal: os mecanismos dependem das permissões concedidas, do ambiente e das exigências do projeto. Uma documentação geral não equivale à validação do alvo.
Entregar uma organização de acesso que permaneça verificável
Na entrega, reúna a matriz aprovada, as identidades ativas, os testes autorizados e recusados, os prazos e a pessoa capaz de remover um acesso. Verifique se uma pessoa ausente pode ser substituída sem divulgar seu segredo. A continuidade depende de um procedimento e de um responsável de reserva autorizado, não de uma senha compartilhada na pasta do projeto.
Ao passar o bastão, revise os acessos que se tornaram inúteis e as automações que dependem de uma identidade pessoal. Se uma recusa inesperada bloquear o trabalho, monte um dossiê de incidente direcionado com identidade técnica, caminho envolvido e erro expurgado. Não adicione permissões gerais apenas para fazer o sintoma desaparecer. O bom encerramento é um acesso necessário, testado e com um fim conhecido.
Perguntas para decidir
É preciso compartilhar a conta Capordia com todos os envolvidos?
Não. O acompanhamento da locação e os acessos técnicos ao trabalho devem ser organizados separadamente. Defina as identidades de máquina possíveis com as permissões realmente concedidas. Este método não pressupõe nenhum sistema de convites ou de funções de equipe no espaço Capordia.
Uma chave pública concede automaticamente as permissões corretas?
Não. Ela serve para a autenticação quando é autorizada; as ações acessíveis dependem, em seguida, da conta e das permissões do sistema. Verifique uma ação permitida e uma ação que deve ser recusada em arquivos sintéticos.
O que verificar após a saída de um envolvido?
Remova suas autorizações, controle a recusa de uma nova autenticação e analise as sessões, trabalhos e automações ainda vinculados à sua identidade. Mantenha um responsável autorizado para a recuperação e o acompanhamento. Não conclua a remoção com base em uma simples caixa marcada.