Zdalny konsultant administratora systemu Linux - najlepsze praktyki [zamknięte]

Zatrudniamy konsultanta w Indiach jako naszego administratora systemu Linux. Nie znamy go dobrze, a on wymaga dostępu root do wszystkich naszych serwerów, aby wykonać swoją pracę (w tym audyt bezpieczeństwa).

Jaka jest najlepsza praktyka umożliwiająca zdalnemu konsultantowi wykonanie takiej pracy, abyśmy byli chronieni przed złośliwymi działaniami?

Z góry dziękuję.

Nie rób tego . Ponadto grozi ci tyle samo nieudolności, co złośliwość z tego, co widziałem w typowym sposobie, w jaki firmy sobie z tym radzą.

Chciałbym powiedzieć, że prawdopodobnie w Indiach są świetni administratorzy systemów, ale sposób, w jaki wiele firm robi rzeczy, jest straszny.

Jeśli przechodzisz przez salon fryzjerski, prawdopodobnie zauważysz, że trafia do nich dość duża ciężarze, a wiele z nich prawdopodobnie nie przeprowadziło prawidłowej weryfikacji swoich pracowników. Rozmawiałem z trzema, z których jeden pracowałem i żaden z nich nie przeprowadził żadnych wywiadów technicznych.

Tak więc, jeśli musisz zatrudnić kogoś zdalnie, na miłość boską, przesłuchaj go osobiście i upewnij się, że zna swoją pracę. Administracja systemem jest zdecydowanie zbyt ważna, aby przekazać ją komuś na ślepo

Teraz, kiedy poradziłem sobie z częścią „nieudolności”,

Administracja jest dość szerokim wyrażeniem. A ktoś z dostępem do roota może zrobić wszystko . Teraz osobiście uważam, że utworzenie konta dla administratora i umożliwienie mu awansowania przez sudo jest lepszym pomysłem (z czym powinien sobie radzić system zarządzania konfiguracją, jeśli masz wiele serwerów). To powiedziawszy, nawet to opiera się na pewnym zaufaniu. Jest tak wiele historii o zwykłych szkodach, jakie może wyrządzić niezadowolony administrator. Zmienić wszystkie hasła? Pewnie , że w końcu możesz się dostać, ale nie jest to trywialne i prawdopodobnie kosztowałoby więcej niż oszczędzasz.

Więc rozważ lokalny. Jeśli nie, rozważ osobę, którą sam zweryfikowałeś i którą bezpośrednio zatrudniłeś .

Jak już wspomniano, nie rób tego.

Jedynym sposobem, w jaki możesz się zabezpieczyć, jest zrobienie czegoś takiego:

1. Nalegaj, aby konsultant używał wybranego przez ciebie systemu zarządzania konfiguracją.
2. Konsultant napisze manifesty zarządzania konfiguracją dla działań, które należy wykonać.
3. Konsultant przetestuje manifesty w systemie testowym.
4. Gdy będzie gotowy, konsultant prześle konfigurację do repozytorium kodów.
5. Wszystkie zmiany są sprawdzane przez członka personelu lub innego konsultanta, który absolutnie nie ma związku z pierwszym i nie ma możliwości skontaktowania się z nimi.
6. Po wylogowaniu zmiany są one stosowane na serwerze przez Ciebie lub członka personelu. Pierwotny konsultant nie powinien mieć dostępu do żadnego z twoich systemów.

Jak powinno być jasne, jest to bardzo niezdarny i nieefektywny proces, ale jeśli nalegasz na przyjęcie pracy od niezaufanej osoby, jest to jeden ze sposobów radzenia sobie z różnymi sprawami.

Jednak, jak zalecałem, znacznie lepiej jest zatrudnić znaną, zaufaną osobę.

Jaka jest najlepsza praktyka umożliwiająca zdalnemu konsultantowi wykonanie takiej pracy, abyśmy byli chronieni przed złośliwymi działaniami?

Z prawnego punktu widzenia: należyta staranność i surowe kary za naruszenie umowy.

Zaczynasz od zwykłych dobrych praktyk zatrudniania, które obowiązują również przy zatrudnianiu pracowników lokalnych (i / lub dostawców usług), które obejmują sprawdzanie faktów w dostarczonym CV, proszenie o transkrypcje edukacji i numery certyfikatów, sprawdzanie i dzwonienie do ich referencji, wywiad, a może nawet kontrola w tle lub kontrola bezpieczeństwa itp. itp.

Następnie zastosuj marchewkę : zapłać godziwą wartość, zaoferuj atrakcyjną pracę, niesamowitych współpracowników, dobre warunki pracy i świadczenia itp. ( Jeśli płacisz orzeszki ziemne, dostajesz małpy ).

I kij : złam warunki umowy o pracę / umowę o świadczenie usług, a my obarczymy cię prawnikami i doprowadzimy do bankructwa!

Niestety oba powyższe stają się coraz trudniejsze przy przekraczaniu granic i stref czasowych.

Gdy zdecydujesz się kogoś zatrudnić:

• jasne wytyczne i polityki, ludzie powinni być świadomi tego, co powinni robić, a czego nie.
• obowiązuje zasada minimalnego dostępu, utrudniająca ludziom (przypadkowo lub celowo) robienie rzeczy, których nie powinni. Dla typowego administratora systemu często oznacza to nadal pełny dostęp, ale na przykład audytor bezpieczeństwa nie powinien potrzebować pełnego dostępu administratora, ale może po prostu poprosić istniejących administratorów o uruchomienie skryptu w jego imieniu, który zbiera dane potrzebne do złożenia raportu. Taki skrypt można łatwo sprawdzić wcześniej.
• ufaj ale sprawdzaj. Wystarczy, że istniejący personel sprawdzi pracę nowego stolarza i jak zawsze zbierze informacje z audytu.
• itd itd.

To pytanie zawiera szczegółowe informacje na temat tego, co zwykle proszę moich klientów, aby ustanowić dla mnie zdalny dostęp, co może być również punktem wyjścia dla Ciebie.

Jest jedna systemowa metoda ochrony siebie, która przychodzi mi na myśl, o której nie wspomniałem.

Hostuj instancje systemu Linux jako maszyny wirtualne na hiperwizorze wirtualizacji (VMware, Xenserver, Hyper-V itp.).

NIE udzielaj administratorowi zdalnego dostępu administracyjnego do hiperwizora. Zdalny administrator uzyskałby dostęp root tylko do samych maszyn wirtualnych.

Wdróż system tworzenia kopii zapasowych oparty na hiperwizorze (Unitrends, Veeam, vSphere Data Protection itp.)

Zrób co najmniej jedną migawkę na dzień dla każdej maszyny wirtualnej z systemem Linux, cofając się w czasie, który uważasz za konieczny.

NIE udzielaj zdalnemu administratorowi dostępu do zapisu do repozytoriów kopii zapasowych.

Jeśli to zrobisz, będziesz mieć zapasowe migawki każdej instancji Linuksa, nad którą zdalny administrator nie ma kontroli. Jeśli zdalny administrator zrobi coś podejrzanego, czy to celowo, czy przypadkowo, zawsze możesz zamontować kopię zapasową sprzed zdarzenia hinkness, aby ocenić, co się stało, i ewentualnie przywrócić do stanu czystego.

Nie będzie to dowód na atak bocznego kanału hiperwizora, który mógłby zostać zamontowany z poziomu maszyny wirtualnej, do której atakujący ma dostęp root.

Jeśli kopie zapasowe nie cofną się wystarczająco wcześnie, nie ochroni cię to.

Musisz dokładnie zaufać każdemu, kto kontroluje Twój hypervisor i infrastrukturę tworzenia kopii zapasowych.

Jeśli robisz to w chmurze (AWS, Azure itp.), Szczegóły implementacji będą się różnić, ale ogólna koncepcja będzie taka sama.

Zasadniczo podziel obowiązki między strony, które nie są partnerami biznesowymi, oprócz zatrudniania tylko osób, którym ufasz.

Daj mu własne konto użytkownika. Następnie dowiedz się dokładnie, do czego potrzebuje dostępu, i zapewnij tylko ten dostęp, ale nic więcej. Na przykład, jeśli musi zmienić konfigurację serwera WWW Apache, skorzystaj z ACL, aby dać mu dostęp do zapisu do plików konfiguracyjnych Apache i skonfiguruj sudogo tak, aby mógł zrestartować usługę Apache, ale nie będzie wykonywać żadnych innych poleceń jako root. Jak zawsze przechowuj kopie zapasowe wszystkiego, do czego dajesz mu dostęp (w tym przypadku plików konfiguracyjnych Apache).