Consultor de administração remota do Linux - Práticas recomendadas [fechado]

Estamos contratando um consultor na Índia como nosso administrador de 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 esse trabalho, a fim de estarmos protegidos contra atividades malignas?

Desde já, obrigado.

Não . Além disso, você corre o mesmo risco de ineptidão e malícia do que vi da maneira típica pelas quais as empresas lidam com isso.

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

Se você estiver passando por uma oficina, provavelmente também verá um corte bastante grande, e é improvável que muitos deles tenham avaliado adequadamente seus funcionários. Conversei com três, um dos quais trabalhei e nenhum deles fez nenhuma entrevista técnica.

Então, se você deve contratar alguém remotamente, pelo amor de deus, entrevistá-lo a si mesmo e certifique-se que ele conhece o seu trabalho. A administração do sistema é muito importante para ser entregue cegamente a alguém

Agora que eu lidei com a parte "inaptidão",

Administração é uma frase bastante ampla. E alguém com acesso root pode fazer qualquer coisa . Agora, pessoalmente , 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 (com a qual seu sistema de gerenciamento de configurações deve lidar se você tiver muitos servidores). Dito isto, mesmo isso depende de uma certa quantidade de confiança. Há tantas histórias por aí sobre o estrago que um administrador de sistemas descontente pode causar. Alterar todas as suas senhas? Claro que você pode entrar eventualmente, mas não é trivial e provavelmente custaria mais do que você está economizando.

Então, considere um local. Caso contrário, considere alguém que você se autodestinou e contratou diretamente .

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

A única maneira de conseguir 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 escreverá manifestos de gerenciamento de configuração para as ações necessárias.
3. O consultor testará os manifestos em um sistema de teste.
4. Quando estiver pronto, o consultor confirmará a configuração em um repositório de códigos.
5. Todas as alterações são revisadas por um membro da sua equipe ou por outro consultor que não tem absolutamente nenhuma relação com o primeiro e não tem como entrar em contato com eles.
6. Depois que as alterações são assinadas, elas são aplicadas ao servidor por você ou por um membro da 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.

Porém, como eu recomendei, é muito melhor contratar um indivíduo conhecido e confiável.

Qual é a melhor prática para habilitar um consultor remoto para esse trabalho, a fim de estarmos protegidos contra atividades malignas?

Do ponto de vista jurídico: diligência prévia e penalidades estritas por quebra de contrato.

Você começa com as boas práticas habituais de contratação que também se aplicam ao contratar funcionários locais (e / ou prestadores de serviços), que incluem a verificação de fatos no currículo fornecido, solicitam transcrições educacionais e números de certificação, conferem e ligam para suas referências, entrevistas, talvez até verificação de antecedentes ou triagem de segurança etc. etc.

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

E o segredo : violar os termos do seu contrato de trabalho / serviço e nós faremos nossos advogados ficarem doentes e deixar você em falência!

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

Depois de decidir contratar alguém:

• diretrizes e políticas claras, as pessoas devem estar cientes do que devem ou não fazer.
• o princípio do acesso mínimo se aplica, 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 ainda significa acesso total, mas um auditor de segurança, por exemplo, não deve precisar de acesso total ao administrador, mas pode simplesmente solicitar aos administradores existentes que executem um script em seu nome que colete os detalhes necessários para fazer seu relatório. Esse script pode ser facilmente verificado com antecedência.
• Confie mas verifique. Basta fazer com que a equipe existente verifique o trabalho de um novo marceneiro e, como sempre, colete informações de auditoria.
• etc etc.

Esta pergunta detalha o que geralmente peço aos meus clientes para estabelecer acesso remoto para mim, o que também pode ser um ponto de partida para você.

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

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

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

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 o tempo que achar necessário.

NÃO dê ao administrador remoto acesso de gravação aos repositórios de backup.

Se você fizer essas coisas, terá instantâneos de backup de cada instância do Linux sobre os quais o administrador remoto não tem controle. Se o administrador remoto fizer algo excêntrico, intencional ou acidentalmente, você sempre poderá montar um backup antes da ocorrência do hinkness para avaliar o que aconteceu e possivelmente recuperar para um estado limpo.

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

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

Você precisa confiar totalmente em quem está no controle do seu hipervisor e da 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 as responsabilidades entre as partes que não são parceiros de negócios, além de contratar apenas pessoas em que você confia.

Dê a ele sua própria conta de usuário. Em seguida, descubra exatamente ao que ele precisa acessar e conceda apenas esse acesso, mas nada mais. Por exemplo, se ele precisar reconfigurar um servidor da web Apache, use uma ACL para fornecer acesso de gravação aos arquivos de configuração do Apache e configure sudopara permitir que ele reinicie o serviço Apache, mas não execute nenhum outro comando como root. Como sempre, mantenha backups de tudo o que você está dando acesso a ele (neste caso, seus arquivos de configuração do Apache).