Separe a propriedade do acesso do dia a dia
Decida quem detém cada conta de hospedagem, domínio, DNS e terceiros, quem paga suas cobranças e quem controla a recuperação. Essas funções podem pertencer a pessoas diferentes. O mantenedor que envia uma versão não deve se tornar a única pessoa capaz de recuperar o projeto do cliente.
Liste o identificador da conta, o responsável de negócio, o responsável pelo contato de recuperação e os administradores autorizados. Registre onde o material de recuperação é guardado sem colocar o próprio material nesta planilha. Confirme que a continuidade do negócio não depende do e-mail pessoal ou do dispositivo de um contratado que está saindo.
Preencha uma matriz de responsabilidades em conjunto
O exemplo abaixo é uma proposta para discussão, não uma declaração das obrigações contratuais da PrivateHostLab. O cliente detém as decisões de negócio, a agência assume o trabalho técnico que aceita, e as obrigações do provedor vêm do contrato de serviço real. Substitua as funções por pessoas nomeadas ou por um contato documentado do provedor.
Para cada linha, adicione um limite de aprovação e o método de contato acordado. Um substituto deve aceitar a função e ter o acesso necessário. Um substituto em branco ou uma rota de escalonamento desconhecida do provedor é uma ação em aberto, não uma cobertura presumida.
Role horizontalmente para ver todas as colunas da tabela.
| Responsabilidade | Primário proposto | Substituto a nomear | Escalar quando |
|---|---|---|---|
| Orçamento de hospedagem e renovação | Responsável pelo orçamento do cliente | Deputado autorizado pelo cliente | Uma decisão de pagamento ou renovação está sem responsável |
| Controle de domínio e DNS | Proprietário do cliente; alteração de agência somente por acordo | Operador de domínio autorizado | O acesso falha ou os registros encaminham os usuários incorretamente |
| Manutenção de SO e aplicativos | Mantenedor da agência no escopo acordado | Substituição qualificada da agência | Uma atualização falha ou um componente não suportado precisa de uma decisão |
| Verificações de backup e recuperação | Operador de dados nomeado da agência ou do cliente | Operador de recuperação treinado | Uma cópia está faltando ou uma verificação de restauração falha |
| Problemas de infraestrutura | Provedor dentro de seu limite de serviço verificado | Rota declarada no acordo real | As evidências apontam para fora do controle do aplicativo |
| Atualizações de incidentes do cliente | Contato do projeto acordado | Substituição aprovada pelo cliente | Um fluxo de trabalho crítico é interrompido ou a próxima atualização está vencida |
Dê aos operadores o acesso que a tarefa deles exige
Use identidades individuais onde o sistema relevante as suportar. Mantenha distintas, quando possível, as permissões de publicação, implantação, cobrança e recuperação de conta. A OWASP recomenda conceder o mínimo de privilégios necessários e revisar permissões quanto a acessos acumulados. Traduza esse princípio em uma tarefa nomeada e uma data de revisão para cada conta de projeto. Folha de Referência de Autorização da OWASP.
Acorde quem pode adicionar ou remover chaves SSH e quem verifica o resultado. Antes de alterar a configuração do SSH, preserve uma sessão de funcionamento conhecida e uma rota de recuperação confirmada; valide a configuração antes de aplicá-la, depois comprove uma nova conexão autorizada antes de encerrar a sessão antiga. O Ubuntu aconselha explicitamente verificar a configuração antes de reiniciar o OpenSSH para evitar perder o acesso. Documentação do servidor Ubuntu OpenSSH.
O documento de transferência deve conter impressões digitais de chaves ou referências de registro de acesso, nunca chaves privadas, senhas ou frases de recuperação de carteira.
Defina o escalonamento pelo impacto no negócio
Separe uma solicitação de conteúdo de rotina, uma mudança de manutenção planejada e um incidente que afeta um fluxo de trabalho crítico do cliente. Escreva os horários de cobertura, o fuso horário, o primeiro contato, o substituto e o próximo ponto de verificação de comunicação. Não transforme um canal de mensagens conveniente em uma garantia implícita de tempo de resposta.
Os alertas devem levar a uma ação que alguém possa tomar. A orientação de monitoramento do Google distingue sintomas visíveis de possíveis causas e pergunta se uma página é urgente e acionável. Para este projeto, “não é possível enviar consultas” é uma descrição de incidente mais clara do que “o servidor parece incomum”. Orientação de monitoramento do Google SRE.
Uma nota de escalonamento útil registra o fluxo de trabalho afetado, o horário da primeira observação, o último sucesso conhecido, a mudança recente e as ações já tomadas. Remova dados pessoais e segredos dos logs de suporte.
Atribua a decisão de recuperação, além da tarefa de backup
Concorde em qual ponto no tempo os dados devem ser recuperados e quanto tempo a recuperação pode levar antes que o negócio seja materialmente afetado. Estas são questões de planejamento diferentes refletidas pelos ponto de recuperação e tempo de recuperação objetivos da NIST.
Nomeie a pessoa que mantém as cópias, a pessoa que as testa e o aprovador para uma restauração em produção. Ensaiem em um destino separado. Registre o ponto de dados restaurado, as verificações funcionais, o tempo decorrido e as lacunas; um ensaio bem-sucedido é evidência para esse exercício, não uma garantia sobre cada incidente futuro.
Faça a transferência de um registro de projeto utilizável
Imagine um cliente mudando seu mantenedor diário após uma campanha. A agência que está saindo fornece a versão atual, o inventário de dependências, os passos de implantação, o procedimento de recuperação de banco de dados e uploads, os detalhes do agendador, o mapa de DNS e o registro de contas de terceiros. O cliente confirma quais contas e trabalhos em andamento passam para a substituta.
O operador receptor deve realizar um exercício controlado com os documentos: localizar a versão aprovada, restaurar dados de amostra em isolamento, encontrar o próximo trabalho agendado e identificar o responsável pela renovação. Registre o que não pôde ser concluído e resolva isso antes de confiar nesse operador para um incidente.
- Confirme o acesso autorizado do substituto antes de remover o acesso da pessoa que está saindo.
- Rotacione credenciais que foram compartilhadas ou revogue identidades individuais quando esse for o controle apropriado.
- Remova chaves obsoletas, tokens de implantação e concessões de acesso em todo o inventário do projeto.
- Confirme a destinação das cópias restantes e do trabalho em andamento conforme os termos de transferência acordados.
Aceite a planilha e depois a mantenha
Marque cada verificação de transferência como aceita, bloqueada ou que requer acompanhamento, com o revisor e o local da evidência. Um contato de recuperação não resolvido deve permanecer visível em vez de desaparecer em uma mensagem geral de “transferência concluída”.
Revise a planilha sempre que o cliente, a agência, o escopo do provedor ou o aplicativo mudar. Vincule-a ao orçamento de hospedagem aprovado e registro de migração. Esta planilha prepara um acordo operacional; ela não substitui os termos reais do vendedor nem cria compromissos de suporte do provedor. Compare-a com o escopo de serviço publicado e resolva detalhes ausentes explicitamente.
Fontes e revisão
As referências técnicas foram verificadas em setembro de 12, 2026. Os exemplos são exercícios de planejamento; a documentação de software referenciada não estabelece capacidades de serviço PrivateHostLab.