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

19

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.

Anderson Tess
la source
66
Si vous ne faites pas confiance à quelqu'un, ne lui donnez pas accès à vos serveurs. Période. Embauchez quelqu'un en qui vous pouvez avoir confiance.
EEAA
6
Je ne peux pas m'empêcher de me demander s'il s'agit d'une action mandatée par des supérieurs et que vous recherchez des munitions / de bons arguments contre elle?
Matt
5
LOL ... Est-ce une bonne idée?
ewwhite
5
Si vous accordez à quelqu'un un accès root à vos serveurs, vous n'avez absolument aucun moyen de vous protéger systématiquement contre les activités malveillantes sur les machines auxquelles l'individu a accès root.
Craig
3
J'espère que vous avez de bonnes sauvegardes hors ligne
CaffeineAddiction

Réponses:

55

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é .

Compagnon Geek
la source
35
J'ai assez de mal à donner un accès privilégié au gars à une porte de moi et encore moins à 12 fuseaux horaires. Mon esprit est stupéfait que quiconque considère même cela comme une option.
EEAA
7
Si vous passez par un atelier de carrosserie, vous ne saurez même pas qui est vraiment en possession de ces informations d'identification racine, vous n'avez aucune garantie que la personne qui travaille sur vos systèmes aujourd'hui est la même personne qui y travaillera demain, vous n'avez aucune garantie que ces gars-là ne vont pas littéralement vous envoyer vos mots de passe de niveau racine en clair (je l'ai vu trop souvent), etc.
Craig
2
Personne ne devrait se connecter à une distribution Linux moderne en tant que root. Le compte root ne devrait même pas avoir de mot de passe. Au lieu de cela, il devrait y avoir des utilisateurs suautorisés à s'élever à la racine. Quand quelqu'un dit qu'il a besoin d'un "accès root", c'est ce qu'il devrait demander. Si cette personne dit avoir besoin du "mot de passe root", elle n'est pas compétente pour faire le travail de toute façon.
Monty Harder
@MontyHarder voulez-vous dire que (certains) utilisateurs devraient avoir le sudodroit de s'élever à la racine? Sinon, pourriez-vous décrire vos meilleures pratiques pour vous suélever à la racine sans avoir et distribuer un mot de passe root?
MadHatter prend en charge Monica le
2
@MontyHarder qui a beaucoup de sens, ce n'est tout simplement pas ce que vous avez dit la première fois; sudoet susont deux choses complètement différentes. Merci de clarifier.
MadHatter prend en charge Monica le
33

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.

EEAA
la source
Pourquoi pas? Je travaille à distance, gérant environ +300 serveurs dédiés, en moins d'une heure je pourrais tout détruire si je veux. Mais bien sûr, je ne ferais pas ça, même si je suis viré. Je suis responsable de la réalisation des sauvegardes, des privilèges les plus élevés (pas seulement moi, nous deux) et nous pouvons être malveillants à tout moment. La raison pour laquelle nous ne le faisons pas - c'est la morale et l'éthique. Nous aimons l'entreprise et les employés et notre travail en général. L'essentiel ici est de faire confiance à quelqu'un et de trouver une personne morale pour ce travail.
fugitif
@fugitive Vous parlez d'une situation différente. Je suppose que la société pour laquelle vous consultez vous fait confiance, sinon elle ne vous aurait pas accordé les autorisations dont vous disposez. Dans le cas de l'OP, il est clair qu'ils ne font pas confiance à ce consultant, c'est pourquoi j'ai recommandé de ne pas donner à cette personne des autorisations sur les systèmes importants.
EEAA
Eh bien, il faut gagner la confiance. :)
fugitif
10

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.

HBruijn
la source
3
"si vous payez des cacahuètes, vous obtenez des singes" ou des éléphants. Bien que j'y pense, je ne sais pas si c'est mieux ou pire que les singes.
un CVn
Juste pour ajouter, la partie «bâton» de votre réponse pourrait être plus difficile à appliquer si l'autre partie se trouve dans un pays différent. Vous devriez d'abord consulter un avocat compétent / expérimenté pour voir quelles possibilités vous avez en cas de problème.
user121391
En outre, l'application de la loi après un incident est probablement plus difficile que de travailler avec une partie de confiance en premier lieu. De la même manière, il y a des gens en qui vous pouvez totalement faire confiance et auxquels vous pourriez ne pas être automatiquement enclins, et des gens en qui vous vous instinctez vers lesquels vous ne devriez probablement pas faire confiance du tout.
Craig
7

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.

Craig
la source
1
Au moment où vous avez fait tout cela, vous êtes déjà l'administrateur système et vous embauchez un laquais à distance ou PFY.
Criggie
3
Pas totalement. Vous administrez uniquement l'hyperviseur et les sauvegardes. Ce qui, certes, n'est pas rien. Mais ce n'est pas nécessairement le même ensemble de compétences ou la même charge administrative. Les chances sont que si vous faites de la virtualisation (nous le sommes), que vous ayez une personne ou des personnes différentes en charge de tout ce qui se passe sur les machines virtuelles individuelles de toute façon.
Craig
1
Bien que l'idée générale soit bonne, elle n'aide que contre l'incompétence / les erreurs (supprimé la base de données de production, etc.), pas contre la malveillance (sauf si vous vérifiez chaque changement chaque jour et comparez le contenu des changements, essentiellement un audit complet quotidien). De plus, les dommages peuvent ne pas être liés à des éléments techniques, par exemple les données client ou les secrets commerciaux détournés ne peuvent pas être contenus de cette manière, car ils sont uniquement réactifs.
user121391
@ user121391: Je ne peux pas vraiment être en désaccord, en particulier avec le problème d'exfiltration des données. Une fois que les données sont prises, elles sont complètement hors de votre contrôle.
Craig
-1

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).

Micheal Johnson
la source
3
Avoir la permission de configurer et de redémarrer un Apache s'exécutant en tant que root donne essentiellement des privilèges root. Il est assez facile d'avoir un binaire arbitraire exécuté par le processus apache, par exemple pour diriger les journaux vers cela. Mieux vaut configurer Apache pour qu'il puisse s'exécuter en tant que non root et toujours se lier à des ports privilégiés. C'est ce que j'ai fait dans cette situation par le passé.
MvG