Brama dostępu SSH dla wielu serwerów

Zarządzanie wieloma serwerami, ponad 90 obecnie z 3 programistami przez Ansible. Wszystko działa świetnie, jednak w tej chwili istnieje ogromny problem bezpieczeństwa. Każdy program używa własnego lokalnego klucza ssh, aby uzyskać dostęp bezpośrednio do serwerów. Każdy devop korzysta z laptopa, a każdy laptop może zostać zagrożony, otwierając w ten sposób całą sieć serwerów prod.

Szukam rozwiązania do centralnego zarządzania dostępem, a tym samym blokowania dostępu do dowolnego klucza. Nie różni się tym, jak klucze są dodawane do bitbucket lub github.

Z góry mojej głowy zakładałbym, że rozwiązaniem byłby tunel z jednej maszyny, bramy, do pożądanego serwera prod ... podczas przechodzenia przez bramę żądanie odebrałoby nowy klucz i wykorzystało by uzyskać dostęp do prod serwer. W rezultacie możemy szybko i skutecznie zabić dostęp dla dowolnego dewelopera w ciągu kilku sekund, po prostu odmawiając dostępu do bramy.

Czy to dobra logika? Czy ktoś widział już rozwiązanie tego problemu?

To zbyt skomplikowane (sprawdzanie, czy klucz ma dostęp do określonego serwera prod). Użyj serwera bramy jako hosta skoku, który akceptuje każdy prawidłowy klucz (ale może łatwo usunąć dostęp do określonego klucza, który z kolei usuwa dostęp do wszystkich serwerów), a następnie dodać tylko dozwolone klucze do każdego odpowiedniego serwera. Następnie upewnij się, że możesz dotrzeć do portu SSH każdego serwera tylko za pośrednictwem hosta skoku.

To jest standardowe podejście.

Inżynierowie nie powinni uruchamiać programu ansible bezpośrednio ze swojego laptopa, chyba że jest to środowisko programistyczne / testowe.

Zamiast tego miej centralny serwer, który ściąga elementy Runbook z git. Pozwala to na dodatkowe sterowanie (cztery oczy, przegląd kodu).

Połącz to z bastionem lub hostem skokowym, aby dodatkowo ograniczyć dostęp.

Netflix zaimplementował twoją konfigurację i wydał darmowe oprogramowanie, aby pomóc w tej sytuacji.

Zobacz ten film https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access lub tę prezentację na https://speakerdeck.com/rlewis/how-netflix-gives- wszyscy-inżynierowie-ssh-dostęp-do-instancji-działających w produkcji z rdzeniem:

Przeanalizujemy naszą architekturę bastionu SSH, która u podstaw używa SSO do uwierzytelnienia inżynierów, a następnie wydaje poświadczenia użytkownika z krótkotrwałymi certyfikatami do uwierzytelnienia SSH bastionu do instancji. Te krótkotrwałe dane uwierzytelniające zmniejszają ryzyko ich utraty. Omówimy, w jaki sposób to podejście pozwala nam kontrolować i automatycznie ostrzegać po fakcie, zamiast spowalniać inżynierów przed udzieleniem dostępu.

Ich oprogramowanie jest dostępne tutaj: https://github.com/Netflix/bless

Niektóre interesujące dania na wynos, nawet jeśli nie wdrożysz ich całego rozwiązania:

• używają certyfikatów SSH zamiast tylko kluczy; możesz umieścić znacznie więcej metadanych w certyfikacie, co pozwala na wprowadzenie wielu ograniczeń na wymagania, a także pozwala na prostsze audyty
• przy użyciu bardzo krótkoterminowych (np. 5 minut) ważności certyfikatów (sesje SSH pozostają otwarte nawet po wygaśnięciu certyfikatu)
• używanie 2FA również utrudnia tworzenie skryptów i zmusza programistów do szukania innych rozwiązań
• konkretny podmoduł poza infrastrukturą i odpowiednio zabezpieczony mechanizmami bezpieczeństwa oferowanymi przez chmurę, w której działa, obsługuje dynamiczne generowanie certyfikatów, aby każdy programista mógł uzyskać dostęp do dowolnego hosta

OneSdentity (ex-Balabit) SPS jest dokładnie tym, czego potrzebujesz w tym scenariuszu. Za pomocą tego urządzenia możesz zarządzać tożsamością użytkownika na praktycznie dowolnym komputerze, śledzić zachowanie użytkownika, monitorować i ostrzegać oraz indeksować wszystko, co użytkownicy robią w celu późniejszego przeglądu.

Moją sugestią jest zabronienie dostępu SSH z komputerów użytkowników.

Zamiast tego powinieneś

1. Organizuj podręczniki w Git.
2. Zmień „Serwer dostępu” w serwer Jenkins.
3. Grant potrzebował tylko dostępu Jenkinsa do użytkowników.
4. Wykonuj gry Ansible na Jenkins nad zadaniami kompilacji przez HTTP.
5. Jako dodatkowy środek bezpieczeństwa wyłącz interfejs Jenkins CLI, jeśli to konieczne.

Przykładowy model wykonania,

1. Wtyczka Jenkins Ansible: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

LUB

2. Klasyczna powłoka - niewykonalny typ pracy. Dodaj ręcznie kroki kompilacji, w tym git checkout.

Jeśli masz ograniczone zasoby serwera, ten sam serwer Jenkins może również obsługiwać Git (scm-manager), chociaż istnieje dodatkowe ryzyko bezpieczeństwa, jeśli jeden z programistów zostanie zainfekowany. Można to złagodzić, odłączając serwer Jenkins od Internetu i rozwiązując lokalne zależności Ansible.