Remote Linux Admin Consultant - Best Practice [geschlossen]

Wir beauftragen einen Berater in Indien als Linux-Administrator. Wir kennen ihn nicht gut und er benötigt Root-Zugriff auf alle unsere Server, um seine Arbeit zu erledigen (einschließlich eines Sicherheits-Audits).

Was ist die beste Vorgehensweise, um einem Remote-Berater solche Arbeiten zu ermöglichen, damit wir vor bösartigen Aktivitäten geschützt sind?

Danke im Voraus.

Nicht . Außerdem besteht für Sie die gleiche Gefahr der Unfähigkeit wie für Böswilligkeit .

Ich möchte sagen, dass es in Indien wahrscheinlich großartige Systemadministratoren gibt, aber die Art und Weise, wie viele Unternehmen Dinge tun, ist schrecklich.

Wenn Sie durch einen Karosseriebau gehen, werden Sie wahrscheinlich auch einen ziemlich großen Einschnitt sehen, und es ist unwahrscheinlich, dass viele von ihnen ihre Mitarbeiter ordnungsgemäß überprüft haben. Ich habe mit drei gesprochen, von denen einer für mich gearbeitet hat und keiner von ihnen hat technische Interviews geführt.

Wenn Sie also jemanden aus der Ferne einstellen müssen, um Himmels willen, interviewen Sie ihn selbst und stellen Sie sicher, dass er seine Arbeit kennt. Die Systemadministration ist viel zu wichtig, um sie blind übergeben zu können

Nun, da ich den Teil der "Unfähigkeit" behandelt habe,

Administration ist ein ziemlich weit gefasster Satz. Und jemand mit Root-Zugriff kann alles tun . Nun persönlich denke ich , ein Konto für den Administrator erstellen und ihm die Möglichkeit gibt , sich durch sudo zu erheben ist eine bessere Idee (die Config - Management - System sollte umgehen , wenn Sie viele Server haben). Das heißt, auch das setzt ein gewisses Maß an Vertrauen voraus. Es gibt so viele Geschichten über den Schaden, den ein verärgerter Sysadmin anrichten kann. Alle Passwörter ändern? Sicher, Sie könnten irgendwann einsteigen, aber es ist nicht trivial, und es würde wahrscheinlich mehr kosten, als Sie sparen.

Betrachten Sie also einen Einheimischen. Wenn nicht, ziehen Sie jemanden in Betracht, den Sie selbst überprüft und direkt eingestellt haben .

Tun Sie dies nicht, wie bereits erwähnt.

Die einzige Möglichkeit, sich zu schützen, besteht darin, Folgendes zu tun:

1. Bestehen Sie darauf, dass der Berater ein Konfigurationsmanagementsystem Ihrer Wahl verwendet.
2. Der Berater erstellt Konfigurationsmanagement-Manifeste für die Aktionen, die Sie ausführen müssen.
3. Der Berater testet die Manifeste auf einem Testsystem.
4. Wenn der Berater bereit ist, schreibt er die Konfiguration in ein Code-Repository.
5. Alle Änderungen werden entweder von einem Mitarbeiter oder einem anderen Berater überprüft , der absolut keine Beziehung zum ersten Mitarbeiter hat und keine Möglichkeit hat, mit diesen in Kontakt zu treten.
6. Sobald die Änderungen abgemeldet sind, werden sie von Ihnen oder einem Mitglied Ihres Personals auf den Server angewendet. Der ursprüngliche Berater sollte keinen Zugriff auf eines Ihrer Systeme haben.

Es sollte klar sein, dass dies ein sehr umständlicher und ineffizienter Prozess ist. Wenn Sie jedoch darauf bestehen, dass Sie Arbeiten von einer nicht vertrauenswürdigen Person annehmen, ist dies eine Möglichkeit, mit Dingen umzugehen.

Wie ich jedoch empfohlen habe, ist es viel besser, eine bekannte, vertrauenswürdige Person einzustellen.

Was ist die beste Vorgehensweise, um einem Remote-Berater solche Arbeiten zu ermöglichen, damit wir vor bösartigen Aktivitäten geschützt sind?

Aus rechtlicher Sicht: Due Diligence im Vorfeld und strafrechtliche Verfolgung von Vertragsverletzungen.

Sie beginnen mit den üblichen guten Einstellungspraktiken, die auch bei der Einstellung von Mitarbeitern vor Ort (und / oder Dienstleistern) Anwendung finden. Dazu gehören die Überprüfung des bereitgestellten Lebenslaufs, die Anforderung von Zeugnissen und Zertifizierungsnummern, die Überprüfung und der Anruf ihrer Referenzen, Befragung, möglicherweise sogar eine Hintergrundüberprüfung oder Sicherheitsüberprüfung usw. usw.

Dann wenden Sie die Karotte an : Bezahlen Sie fairen Wert, bieten Sie attraktive Arbeit, tolle Kollegen, gute Arbeitsbedingungen und Vorteile usw. ( Wenn Sie Erdnüsse bezahlen, bekommen Sie Affen. )

Und der Knüppel : Verstoßen Sie gegen die Bestimmungen Ihres Arbeits- / Dienstleistungsvertrags und wir werden unsere Anwälte an Ihnen erkranken und Sie bankrott machen!

Leider wird beides beim Überschreiten von Grenzen und Zeitzonen immer schwieriger.

Sobald Sie sich entschieden haben, jemanden einzustellen:

• Klare Richtlinien und Richtlinien. Die Menschen sollten sich bewusst sein, was sie tun sollen und was nicht.
• Es gilt der Grundsatz des minimalen Zugangs, der es Menschen (aus Versehen oder absichtlich) erschwert, Dinge zu tun, die sie nicht tun sollten. Für den typischen Systemadministrator bedeutet dies häufig immer noch vollständigen Zugriff, aber ein Sicherheitsprüfer sollte beispielsweise keinen vollständigen Administratorzugriff benötigen, sondern kann einfach die vorhandenen Administratoren auffordern, in seinem Namen ein Skript auszuführen, das die Details sammelt, die er für die Erstellung seines Berichts benötigt. Ein solches Skript kann einfach vorab überprüft werden.
• vertrauen, aber verifizieren. Lassen Sie einfach das vorhandene Personal die Arbeit eines neuen Tischlers überprüfen und wie immer Audit-Informationen sammeln.
• usw. usw.

In dieser Frage wird beschrieben, was meine Kunden normalerweise tun müssen, um einen Remotezugriff für mich einzurichten. Dies könnte auch für Sie ein Ausgangspunkt sein.

Es gibt eine systemische Methode, um sich selbst zu schützen, die ich nicht erwähnt habe.

Hosten Sie Ihre Linux-Instanzen als VMs auf einem Virtualisierungshypervisor (VMware, Xenserver, Hyper-V usw.).

Geben Sie dem Remote-Administrator keinen Administratorzugriff auf den Hypervisor. Der Remote-Administrator würde nur Root-Zugriff auf die VMs selbst erhalten.

Implementieren Sie ein hypervisorbasiertes Sicherungssystem (Unitrends, Veeam, vSphere Data Protection usw.)

Bewahren Sie mindestens einen Snapshot pro Tag für jede Linux-VM auf und gehen Sie dabei so weit zurück, wie Sie es für erforderlich halten.

Gewähren Sie dem Remote-Administrator KEINEN Schreibzugriff auf die Backup-Repositorys.

Wenn Sie dies tun, erhalten Sie Backup-Snapshots von jeder Linux-Instanz, über die der Remote-Administrator keine Kontrolle hat. Wenn der Remote-Administrator absichtlich oder versehentlich Probleme hat, können Sie jederzeit ein Backup von vor dem Auftreten des Problems erstellen, um die Vorgänge zu bewerten und möglicherweise einen sauberen Zustand wiederherzustellen.

Dies ist kein Beweis für einen Hypervisor-Seitenkanalangriff, der möglicherweise von einer VM aus gemountet werden kann, auf die der Angreifer root-Zugriff hat.

Wenn Ihre Backups nicht rechtzeitig genug sind, werden Sie dadurch nicht geschützt.

Sie müssen absolut darauf vertrauen, wer die Kontrolle über Ihren Hypervisor und die Backup-Infrastruktur hat.

Wenn Sie dies in der Cloud tun (AWS, Azure usw.), unterscheiden sich die Implementierungsdetails, aber das allgemeine Konzept ist dasselbe.

Teilen Sie die Verantwortlichkeiten im Wesentlichen auf Parteien auf, die keine Geschäftspartner sind, und stellen Sie nur Personen ein, denen Sie vertrauen.

Gib ihm sein eigenes Benutzerkonto. Finden Sie dann genau heraus, worauf er Zugriff haben muss, und gewähren Sie nur diesen Zugriff, aber sonst nichts. Wenn er beispielsweise einen Apache-Webserver neu konfigurieren muss, verwenden Sie eine ACL, um ihm Schreibzugriff auf die Apache-Konfigurationsdateien zu gewähren, und konfigurieren sudoSie ihn so, dass er den Apache-Dienst neu startet, aber keine anderen Befehle als Root ausführt. Wie immer sollten Sie Backups von allem aufbewahren, auf das Sie ihm Zugriff gewähren (in diesem Fall von Ihren Apache-Konfigurationsdateien).