Czy istnieje bezpieczny sposób przechowywania haseł używanych dla ssh przez skrypt?

Więc najpierw wiem, że powinienem użyć uwierzytelniania klucza w SSH. Nie musisz mi tego wyjaśniać.

Problem polega na tym, że mam (dużą) grupę serwerów i muszę mieć skrypt umożliwiający połączenie każdego z nich.

Używam uwierzytelniania klucza, gdy tylko mogę, jednak nie jest to możliwe na każdym serwerze (nie mam nad tym kontroli). Więc SSH z loginem lub czasem telnet.

Tak więc dla niektórych po prostu zapisałem hasła w db, a mój skrypt zabrał je w razie potrzeby. Problem polega na tym, że nie wydaje się to tak naprawdę bezpieczne. Czy istnieje sposób, aby uczynić to trochę bezpieczniejszym?

Jak jakiś konkretny sposób przechowywania?

Jeśli skrypt może połączyć się z dowolnym z tych serwerów, każdy z dostępem do skryptu (lub uprzywilejowanym dostępem do komputera, na którym działa skrypt) może połączyć się z dowolnym z tych serwerów.

Jeśli skrypt musi działać autonomicznie, wszystkie zakłady są wyłączone. Odpowiedź brzmi: nie, nie ma absolutnie bezpiecznego sposobu przechowywania haseł w takim środowisku . Nie ma absolutnie bezpiecznego i praktycznego sposobu robienia czegokolwiek.

Zamiast próbować uniknąć tego, co nieuniknione, powinieneś skupić się na głębokiej obronie .

Oczywiście, po pierwsze, należy odpowiednio chronić hasła . Zazwyczaj oznacza to trzymanie ich w pliku osobnym od skryptu i konfigurowanie restrykcyjnych uprawnień systemu plików . To wszystko, co możesz zrobić na tym froncie, z perspektywy bezpieczeństwa.

Inne środki z pewnością mogą przyczynić się do zaciemnienia procesu. Szyfrowanie haseł sprawi, że atakujący będzie musiał poszukać klucza deszyfrującego. Korzystanie z pewnego rodzaju pamięci chronionej przez system operacyjny ogólnie chroni przed dostępem innych użytkowników do Twojego klucza (więc nie daje przewagi nad uprawnieniami systemu plików, poza tym, że jest trudny do zaatakowania i użycia). Środki te opóźnią atak, ale z pewnością nie zapobiegną atakowi przeciwko zdecydowanemu atakującemu.

Teraz przez chwilę traktujmy hasła jako publiczne . Co możesz zrobić, aby zmniejszyć szkody?

Starym i przetestowanym rozwiązaniem jest ograniczenie możliwości tych poświadczeń. W systemie UNIX dobrym sposobem na to jest skonfigurowanie osobnego użytkownika dla twojego skryptu i ograniczenie możliwości tego użytkownika , zarówno na serwerze dostępowym, jak i dostępnym. Możesz ograniczyć możliwości użytkownika na poziomie SSH , na poziomie powłoki lub ewentualnie za pomocą mechanizmu obowiązkowej kontroli dostępu, takiego jak SELinux .

Można również rozważyć przeniesienie logiki skryptu na serwery . W ten sposób otrzymujesz mniejszy interfejs, który łatwiej kontrolować, a zwłaszcza ...

Monitorować . Zawsze monitoruj dostęp do serwerów. Najlepiej, aby uwierzytelnianie dziennika i komendy były wykonywane tylko w dzienniku dołączającym . Nie zapomnij na przykład monitorować zmian w pliku skryptu auditd.

Oczywiście wiele z tych mechanizmów nie jest użytecznych, jeśli nie masz kontroli nad serwerami, jak sugeruje twoje pytanie. W takim przypadku radzę skontaktować się z osobami administrującymi serwerami i poinformować ich o skrypcie i potencjalnych pułapkach bezpieczeństwa.

Krótka odpowiedź brzmi: nie.

Długa odpowiedź brzmi: nie, nie ma całkowicie bezpiecznego sposobu. (Obejmuje to zmienne środowiskowe, do których inni mogą uzyskać dostęp na serwerze.) Najbliższe, co możesz uzyskać, to przechowywać je w jakimś zaszyfrowanym formacie - keepass, plik zaszyfrowany GPG lub coś innego wzdłuż tych linii. Ale w pewnym momencie musisz odszyfrować hasło, aby skrypt mógł go użyć, a wtedy będziesz podatny na ataki.

Innymi słowy, musisz dokładnie przyjrzeć się dogłębnym zabezpieczeniom, zarówno na serwerze, z którego uruchamiany jest skrypt, w sieci, jak i na serwerach docelowych.

Możesz zaszyfrować hasła w bazie danych za pomocą drugiego hasła i przechowywać to hasło na osobnym (trzecim) komputerze i mieć system, w którym skrypt, który musi wylogować się z bazy danych, najpierw łączy się z tym trzecim komputerem, aby uzyskać hasło deszyfrowania , odszyfrowuje hasło w bazie danych za pomocą hasła otrzymanego z 3. komputera i działa.

Oczywiście to tak naprawdę nie dodaje żadnych dodatkowych zabezpieczeń, osoba atakująca z wystarczającymi uprawnieniami może również poprosić o hasło z 3. komputera.

Ale chodzi o to, że strona trzecia może kontrolować trzecią maszynę, np. Szefa lub oficera bezpieczeństwa, lub osoba trzecia kontrolująca serwery, których nie kontrolujesz.

W ten sposób możesz im powiedzieć, że jeśli kiedykolwiek napotkają problem, jeśli rzucisz pracę i nie ufają facetowi, który cię zastępuje, lub po prostu chcą, aby twoje skrypty przestały uzyskiwać dostęp do swoich maszyn, mogą wyciągnąć wtyczkę na 3. miejscu maszynę, a twoje skrypty nie będą już miały dostępu do haseł.