Consultor de administração remota do Linux - Prática recomendada [fechada]

Question

Estamos contratando um consultor na Índia como nosso administrador Linux. Nós não o conhecemos bem e ele exige acesso root a todos os nossos servidores para fazer seu trabalho (incluindo uma auditoria de segurança).

Qual é a melhor prática para habilitar um consultor remoto para tal trabalho, de tal forma que estamos protegidos contra quaisquer atividades malignas?

Obrigado antecipadamente.

    

Answer 1

Não . Além disso, você está em tanto perigo de inépcia inépcia, malícia do que eu vi da maneira típica como as empresas lidam com isso.

Eu gostaria de dizer que provavelmente existem ótimos administradores de sistemas na Índia, mas a maneira como muitas empresas fazem as coisas é terrível.

Se você está passando por uma loja de corpo, você também está provavelmente vendo um corte muito grande ir para eles, e muitos deles não são susceptíveis de ter devidamente verificados seus funcionários. Eu conversei com três pessoas, uma das quais trabalhei e nenhuma delas fizeram entrevistas técnicas.

Então, se você precisar contratar alguém remotamente, pelo amor de Deus, entreviste-o você mesmo e certifique-se de que ele conhece o trabalho dele. A administração do sistema é importante demais para entregar a alguém cegamente

Agora que lidamos com a parte "ineptidão" disso,

Administração é uma frase bem ampla. E alguém com acesso root pode fazer qualquer coisa . Agora, pessoalmente eu acho que criar uma conta para o administrador, e dar a ele a capacidade de se elevar através do sudo é uma idéia melhor (que seu sistema de gerenciamento de configuração deve manipular se você tiver muitos servidores). Dito isso, até mesmo isso depende de uma certa quantidade de confiança. Há tantas histórias por aí sobre o enorme dano que um administrador de sistemas insatisfeito pode fazer. Mude todas as suas senhas? > Claro que você poderia entrar eventualmente, mas não é trivial, e provavelmente custaria mais do que você está economizando.

Então, considere um local. Se não, considere alguém que você tenha vetado e tenha contratado diretamente .

    

Answer 2

Como foi mencionado, não faça isso.

A única maneira de você se proteger é fazendo algo assim:

1. Insista para que o consultor use um sistema de gerenciamento de configuração de sua escolha.
2. O consultor gravará manifestos de gerenciamento de configuração para as ações que você precisa concluir.
3. O consultor testará os manifestos em um sistema de teste.
4. Quando estiver pronto, o consultor confirmará a configuração para um repositório de código.
5. Todas as alterações são analisadas por um membro de sua equipe ou por outro consultor que não tenha absolutamente nenhuma relação com o primeiro e não tenha como contatá-lo.
6. Depois que as alterações são encerradas, elas são aplicadas ao servidor por você ou por um membro de sua equipe. O consultor original não deve ter acesso a nenhum dos seus sistemas.

Como deve ficar claro, esse é um processo muito desajeitado e ineficiente, mas se você insistir em aceitar o trabalho de um indivíduo não confiável, essa é uma maneira de lidar com as coisas.

Como eu recomendei, porém, é muito melhor contratar alguém conhecido e confiável.

    

Answer 3

What is the best practice for enabling a remote consultant for such work such that we are protected against any malignant activities?

Do ponto de vista legal: due diligence de antemão e penalidades rigorosas por quebra de contrato.

Você começa com as boas práticas de contratação que também se aplicam ao contratar funcionários locais (e / ou prestadores de serviços) que incluem verificar o currículo fornecido, solicitar transcrições de educação e números de certificação, verificar e chamar suas referências, entrevista , talvez até mesmo uma verificação de antecedentes ou triagem de segurança etc. etc.

Em seguida, aplique a cenoura : pague o valor justo, ofereça trabalho atraente, colegas incríveis, boas condições de trabalho e benefícios etc. ( se pagar amendoins, você ganha macacos. )

E o palito : viola os termos do seu contrato de emprego / serviço e prejudicará nossos advogados e deixará você falido!

Infelizmente, ambos os itens acima se tornam cada vez mais difíceis ao cruzar fronteiras e fusos horários.

Uma vez que você decide contratar alguém:

• diretrizes e políticas claras, as pessoas devem estar cientes do que devem ou não fazer.
• aplica-se o princípio do acesso mínimo, dificulta que as pessoas (acidentalmente ou de propósito) façam coisas que não deveriam. Para o administrador de sistema típico, muitas vezes isso significa acesso total, mas um auditor de segurança, por exemplo, não deve precisar de acesso de administrador completo, mas pode simplesmente solicitar aos administradores existentes que executem um script em seu nome que coleta os detalhes necessários para fazer o relatório. Tal script pode ser facilmente verificado de antemão.
• confie, mas verifique. Basta que o pessoal existente verifique o trabalho de um novo marceneiro e, como sempre, colete informações de auditoria.
• etc. etc.

Esta questão detalha o que eu geralmente peço aos meus clientes que façam para estabelecer acesso remoto para mim, o que pode ser um começo ponto para você também.

    

Answer 4

Existe um método sistêmico de proteger a si mesmo que me vem à mente, o que eu não vi mencionado.

Hospede suas instâncias do Linux como VMs em um hipervisor de virtualização (VMware, Xenserver, Hyper-V, etc.).

NÃO conceda acesso administrativo ao administrador remoto ao hipervisor. O administrador remoto só teria acesso root às próprias VMs.

DO Implemente um sistema de backup baseado em hipervisor (Unitrends, Veeam, vSphere Data Protection, etc.)

Mantenha pelo menos um instantâneo por dia de cada VM do Linux, voltando até o tempo que achar necessário.

NÃO conceda acesso de gravação do administrador remoto aos repositórios de backup.

Se você fizer isso, terá instantâneos de backup de cada instância do Linux sobre a qual o administrador remoto não tem controle. Se o administrador remoto fizer algo estranho, seja intencionalmente ou acidentalmente, você sempre poderá montar um backup antes que ocorra o hinkeness para avaliar o que aconteceu e possivelmente recuperar para um estado limpo.

Isso não será uma prova contra um ataque de canal lateral de hipervisor, que poderia ser montado a partir de uma VM à qual o invasor tenha acesso root.

Se os seus backups não forem suficientemente longe no tempo, isso não protegerá você.

Você precisa confiar totalmente em quem quer que esteja no controle de seu hipervisor e na infraestrutura de backup.

Se você estiver fazendo isso na nuvem (AWS, Azure, etc.), os detalhes da implementação serão diferentes, mas o conceito geral será o mesmo.

Em essência, divida responsabilidades entre as partes que não são parceiras de negócios umas com as outras, além de apenas contratar pessoas de sua confiança.

    

Answer 5

Dê a ele sua própria conta de usuário. Em seguida, descobrir exatamente o que ele precisa acessar e conceder apenas esse acesso, mas nada mais. Por exemplo, se ele precisar reconfigurar um servidor da Web Apache, use uma ACL para conceder acesso de gravação aos arquivos de configuração do Apache e configure sudo para permitir que ele reinicie o serviço Apache, mas não execute outros comandos como raiz. Como sempre, mantenha backups de qualquer coisa que você esteja lhe dando acesso (neste caso, seus arquivos de configuração do Apache).