Consultant administrateur Linux à distance - Meilleures pratiques [fermé]

Nous engageons un consultant en Inde en tant qu'administrateur Linux. Nous ne le connaissons pas bien et il a besoin d'un accès root à tous nos serveurs pour faire son travail (y compris un audit de sécurité).

Quelle est la meilleure pratique pour permettre à un consultant à distance d'effectuer de tels travaux de manière à ce que nous soyons protégés contre toute activité maligne?

Merci d'avance.

Non . De plus, vous courez autant de risques d' ineptie que de méchanceté de ce que j'ai vu de la manière typique dont les entreprises gèrent cela.

Je voudrais dire qu'il y a probablement d' excellents administrateurs système en Inde, mais la façon dont de nombreuses entreprises font les choses est terrible.

Si vous passez par un atelier de carrosserie, vous verrez probablement une coupe assez importante pour eux, et beaucoup d'entre eux ont peu de chances d'avoir correctement vérifié leurs employés. J'en ai parlé à trois, dont un pour qui je travaillais et aucun d'entre eux n'a fait d'interview technique.

Donc, si vous devez embaucher quelqu'un à distance, pour l'amour de Dieu, interviewez-le vous - même et assurez-vous qu'il connaît son travail. L'administration du système est beaucoup trop importante pour être confiée à quelqu'un à l'aveugle

Maintenant que j'en ai géré la partie "ineptie",

L'administration est une phrase assez large. Et quelqu'un avec un accès root peut tout faire . Maintenant, personnellement, je pense que créer un compte pour l'administrateur et lui donner la possibilité de s'élever via sudo est une meilleure idée (que votre système de gestion de configuration devrait gérer si vous avez plusieurs serveurs). Cela dit, même cela repose sur une certaine confiance. Il y a tellement d'histoires sur les dégâts considérables qu'un administrateur système mécontent peut faire. Changer tous vos mots de passe? Bien sûr, vous pourriez éventuellement entrer, mais ce n'est pas anodin, et cela coûterait probablement plus que ce que vous économisez.

Alors, considérez un local. Si ce n'est pas le cas, pensez à quelqu'un que vous avez vérifié vous - même et que vous avez directement embauché .

Comme cela a été mentionné, ne faites pas cela.

La seule façon de vous protéger est de faire quelque chose comme ceci:

1. Insistez pour que le consultant utilise un système de gestion de configuration de votre choix.
2. Le consultant rédigera des manifestes de gestion de configuration pour les actions que vous devez effectuer.
3. Le consultant testera les manifestes sur un système de test.
4. Lorsqu'il est prêt, le consultant valide la configuration dans un référentiel de code.
5. Tous les changements sont examinés par un membre de votre personnel ou un autre consultant qui n'a absolument aucun rapport avec le premier et n'a aucun moyen de les contacter.
6. Une fois les modifications approuvées, elles sont appliquées au serveur par vous ou un membre de votre personnel. Le consultant d'origine ne doit avoir accès à aucun de vos systèmes.

Comme il doit être clair, il s'agit d'un processus très maladroit et inefficace, mais si vous insistez pour accepter le travail d'une personne non fiable, c'est une façon de gérer les choses.

Cependant, comme je l'ai recommandé, il vaut mieux embaucher une personne connue et de confiance.

Quelle est la meilleure pratique pour permettre à un consultant à distance d'effectuer de tels travaux de manière à ce que nous soyons protégés contre toute activité maligne?

D'un point de vue juridique: due diligence préalable et sanctions sévères en cas de rupture de contrat.

Vous commencez par les bonnes pratiques d'embauche habituelles qui s'appliquent également lors de l'embauche de personnel sur site (et / ou de prestataires de services) qui incluent la vérification des faits du curriculum vitae fourni, demander des relevés de notes et des numéros de certification, vérifier et appeler leurs références, interviewer, peut-être même une vérification des antécédents ou un contrôle de sécurité, etc., etc.

Ensuite, appliquez la carotte : payez la juste valeur, offrez un travail attrayant, des collègues incroyables, de bonnes conditions de travail et des avantages, etc. ( si vous payez des arachides, vous obtenez des singes. )

Et le bâton : enfreignez les termes de votre contrat de travail / service et nous vous rendrons malades nos avocats et vous laisserons en faillite!

Malheureusement, les deux éléments ci-dessus deviennent de plus en plus difficiles lors du franchissement des frontières et des fuseaux horaires.

Une fois que vous avez décidé d'embaucher quelqu'un:

• des directives et des politiques claires, les gens doivent être conscients de ce qu'ils doivent et ne peuvent pas faire.
• le principe de l'accès minimal s'applique, il est difficile pour les gens (accidentellement ou volontairement) de faire des choses qu'ils ne devraient pas. Pour l'administrateur système typique, cela signifie souvent toujours un accès complet, mais un auditeur de sécurité, par exemple, ne devrait pas avoir besoin d'un accès administrateur complet, mais peut simplement demander aux administrateurs existants d'exécuter un script en son nom qui recueille les détails dont il a besoin pour faire son rapport. Un tel script peut facilement être vérifié au préalable.
• faites confiance, mais vérifiez. Demandez simplement au personnel existant de vérifier le travail d'un nouveau menuisier et, comme toujours, de collecter les informations d'audit.
• etc.

Cette question détaille ce que je demande habituellement à mes clients pour établir un accès à distance pour moi, ce qui pourrait également être un point de départ pour vous.

Il y a une méthode systémique de protection qui vous vient à l'esprit, que je n'ai pas vue mentionnée.

Hébergez vos instances Linux en tant que VM sur un hyperviseur de virtualisation (VMware, Xenserver, Hyper-V, etc.).

NE donnez PAS à l'administrateur distant l'accès administratif à l'hyperviseur. L'administrateur distant obtiendrait uniquement un accès root aux machines virtuelles elles-mêmes.

Mettre en œuvre un système de sauvegarde basé sur un hyperviseur (Unitrends, Veeam, vSphere Data Protection, etc.)

CONSERVEZ au moins un instantané par jour de chaque machine virtuelle Linux, en remontant aussi loin que vous le jugez nécessaire.

NE donnez PAS à l'administrateur distant un accès en écriture aux référentiels de sauvegarde.

Si vous faites ces choses, vous aurez des instantanés de sauvegarde de chaque instance Linux sur laquelle l'administrateur distant n'a aucun contrôle. Si l'administrateur distant fait quelque chose de hinky, que ce soit intentionnellement ou accidentellement, vous pouvez toujours monter une sauvegarde avant que le hinkeness ne se produise pour évaluer ce qui s'est passé et éventuellement revenir à un état propre.

Cela ne sera pas une preuve contre une attaque de canal latéral d'hyperviseur, qui pourrait potentiellement être montée à partir d'une machine virtuelle à laquelle l'attaquant a un accès root.

Si vos sauvegardes ne remontent pas assez loin dans le temps, cela ne vous protégera pas.

Vous devez faire entièrement confiance à la personne qui contrôle votre hyperviseur et l'infrastructure de sauvegarde.

Si vous faites cela dans le cloud (AWS, Azure, etc.), les détails de l'implémentation seront différents, mais le concept général serait le même.

Essentiellement, répartissez les responsabilités entre les parties qui ne sont pas des partenaires commerciaux entre elles, en plus d'embaucher uniquement des personnes en qui vous avez confiance.

Donnez-lui son propre compte utilisateur. Découvrez ensuite à quoi il a besoin d'accéder et accordez cet accès, mais rien d'autre. Par exemple, s'il a besoin de reconfigurer un serveur Web Apache, utilisez une ACL pour lui donner un accès en écriture aux fichiers de configuration Apache et configurez-le sudopour qu'il redémarre le service Apache mais n'exécute aucune autre commande en tant que root. Comme toujours, conservez des sauvegardes de tout ce à quoi vous lui donnez accès (dans ce cas, vos fichiers de configuration Apache).