Najlepsze praktyki bezpieczeństwa

Zamierzam wprowadzić Ansible do mojego centrum danych i szukam najlepszych praktyk bezpieczeństwa w tym, gdzie zlokalizować maszynę sterującą i jak zarządzać kluczami SSH.

Pytanie 1: maszyna sterująca

Oczywiście potrzebujemy maszyny sterującej. Na maszynie sterującej zapisane są publiczne klucze SSH. Jeśli osoba atakująca ma dostęp do komputera sterującego, potencjalnie ma dostęp do całego centrum danych (lub serwerów zarządzanych przez Ansible). Czy lepiej jest mieć dedykowaną maszynę sterującą w centrum danych lub maszynę zdalnie sterowaną (jak mój laptop zdalnie podłączony do centrum danych)?

Jeśli najlepszą praktyką jest korzystanie z mojego laptopa (który oczywiście może zostać skradziony, ale mogę bezpiecznie zapisać moje klucze publiczne online w chmurze lub offline na przenośnym urządzeniu szyfrowanym), co zrobić, jeśli będę musiał korzystać z niektórych interfejsów sieciowych z Ansible, jak Ansible Tower, Semaphore, Rundeck lub Foreman, który należy zainstalować na scentralizowanym komputerze w centrum danych? Jak go zabezpieczyć i uniknąć, by stał się „pojedynczym punktem ataku”?

Pytanie 2: klucze SSH

Załóżmy, że muszę użyć Ansible do wykonania niektórych zadań, które wymagają wykonania przez root'a (np. Instalowanie pakietów oprogramowania lub coś takiego). Myślę, że najlepszą praktyką nie jest używanie użytkownika root na kontrolowanych serwerach, ale dodanie normalnego użytkownika dla Ansible z uprawnieniami sudo. Ale jeśli Ansible musi wykonać prawie każde zadanie, musi mieć dostęp do wszystkich poleceń za pośrednictwem sudo. Więc jaki jest najlepszy wybór:

• pozwól Ansible użyć użytkownika root (z jego kluczem publicznym zapisanym w ~/.ssh/authorized_keys
• utwórz nieuprzywilejowanego użytkownika dedykowanego dla Ansible z dostępem sudo
• pozwól użytkownikowi Ansible uruchomić wszystkie polecenia poprzez sudo, podając hasło (które jest unikalne, musi być znane każdemu sysadminowi, który używa Ansible do sterowania tymi serwerami)
• pozwól użytkownikowi Ansible na uruchamianie wszystkich poleceń poprzez sudo bez podawania hasła
• jakieś inne wskazówki?

Host bastionu (centrum sterowania ansible) należy do oddzielnej podsieci. Nie powinien być bezpośrednio dostępny z zewnątrz, nie powinien być bezpośrednio dostępny z zarządzanych serwerów!

Twój laptop jest najmniej bezpiecznym urządzeniem ze wszystkich. Jedna głupia poczta, jedna głupia luka we Flashu, jedna głupia Wi-Fi gościa i robi się poważna.

W przypadku serwerów nie zezwalaj wcale na dostęp do konta root za pośrednictwem ssh. Wiele audytów na to szydzi.

W przypadku ansible pozwól każdemu administratorowi używać własnego konta osobistego na każdym serwerze docelowym i pozwól mu sudo z hasłami. W ten sposób żadne hasło nie jest dzielone między dwie osoby. Możesz sprawdzić, kto zrobił co na każdym serwerze. To od Ciebie zależy, czy konta osobiste zezwalają na logowanie za pomocą hasła, tylko klucza ssh lub wymagają obu.

Aby wyjaśnić ansible, nie wymaga użycia jednej docelowej nazwy logowania . Każdy administrator może i powinien mieć osobistą docelową nazwę logowania.

Uwaga dodatkowa: Staraj się nigdy nie tworzyć konta o nazwie jakieś słowo (np. „Ansible” lub „admin” lub „klaster” lub „zarządzanie” lub „operator”), jeśli ma ono hasło. Jedyną dobrą nazwą konta, które ma hasło, jest imię człowieka, na przykład „jkowalski”. Tylko człowiek może być odpowiedzialny za działania wykonane za pośrednictwem konta i odpowiedzialny za niewłaściwe zabezpieczenie hasła, „ansible” nie może.

> Pytanie 1: maszyna sterująca

W Userify (pełne ujawnienie: faktycznie oferujemy oprogramowanie do zarządzania kluczami ssh), radzimy sobie z tym przez cały czas, ponieważ prowadzimy również największy magazyn kluczy SSH. Zasadniczo zalecamy lokalną instalację zamiast korzystania z chmury, ponieważ masz większą kontrolę, zmniejszasz powierzchnię, możesz naprawdę zablokować ją tylko znanym zaufanym sieciom.

Ważną rzeczą do zapamiętania jest to, że w prawidłowo zbudowanym systemie takim jak ten naprawdę nie powinno być żadnych istotnych tajemnic, które mogłyby zostać ujawnione atakującemu. Jeśli ktoś wjedzie wózkiem widłowym do twojego centrum danych i odejdzie z twoim serwerem, nie dostanie dużo, z wyjątkiem niektórych mocno zaszyfrowanych haseł, prawdopodobnie niektórych mocno zaszyfrowanych plików i niektórych kluczy publicznych bez odpowiadających im kluczy prywatnych. Innymi słowy, nie tak bardzo.

Jak zauważyłeś, wektory rzeczywistego zagrożenia mają miejsce wtedy, gdy atakujący przejmie kontrolę nad tym komputerem i użyje go do wdrożenia własnych kont użytkowników i (publicznych) kluczy. Jest to ryzyko dla praktycznie każdej platformy chmurowej (np. Linode). Powinieneś najbardziej skoncentrować się na zapobieganiu dostępowi do płaszczyzny kontroli, co oznacza zminimalizowanie powierzchni ataku (odsłonięcie tylko kilku portów i zablokowanie tych portów tak bardzo, jak to możliwe), a najlepiej użycie oprogramowania zabezpieczonego przed eskalacją uprawnień i różnymi atakami ( Wstrzykiwanie SQL, XSS, CSRF itp.) Włącz dostęp 2FA / MFA do płaszczyzny sterowania i skup się na zablokowaniu tej płaszczyzny, na ile to możliwe.

Czy lepiej jest mieć dedykowaną maszynę sterującą w centrum danych lub maszynę zdalnie sterowaną (jak mój laptop zdalnie podłączony do centrum danych)?

To zdecydowanie lepiej mieć dedykowanego urządzenia sterującego w bezpiecznym centrum danych, ponieważ można go wyizolować i zablokować ją w dół, aby zapobiec / zminimalizować ryzyko kradzieży lub nieuprawnionym dostępem.

Jeśli najlepszą praktyką jest korzystanie z mojego laptopa (który oczywiście może zostać skradziony, ale mogę bezpiecznie zapisać moje klucze publiczne online w chmurze lub offline na przenośnym urządzeniu szyfrowanym), co zrobić , jeśli będę musiał korzystać z niektórych interfejsów sieciowych z Ansible, jak Ansible Tower, Semaphore, Rundeck lub Foreman, który należy zainstalować na scentralizowanym komputerze w centrum danych?

Nie musisz uruchamiać ŻADNEGO interfejsu internetowego ani dodatkowej płaszczyzny kontroli, aby zarządzać kluczami (nawet Userify), dopóki nie staniesz się wystarczająco duży, aby zacząć mieć problemy z zarządzaniem z powodu większej liczby użytkowników i różnych poziomów autoryzacji na serwerach lub potrzebujesz dodatkowych trzymanie za rękę dla użytkowników, którzy mogą nie mieć wiedzy lub dostępu do Ansible w celu aktualizacji kluczy. Userify na początku było niewiele więcej niż skryptami powłoki (dziś prawdopodobnie byłyby Ansible!) I nie ma w tym nic złego, dopóki nie zaczniesz potrzebować dodatkowej kontroli zarządzania i łatwych sposobów zarządzania / obracania ich przez ludzi własne klucze. (Oczywiście, proszę spojrzeć na Userify, jeśli dojdziesz do tego punktu!)

Jak go zabezpieczyć i uniknąć, by stał się „pojedynczym punktem ataku”?

Cóż, oczywiście sprawdź wszystkie zasoby w sieci do blokowania rzeczy, ale co najważniejsze, zacznij od bezpiecznego fundamentu:

1. Od samego początku twórz swoje rozwiązania z myślą o bezpieczeństwie. Wybierz technologię (tj. Bazę danych lub języki), które tradycyjnie miały mniej problemów, a następnie koduj z myślą o bezpieczeństwie. Wyczyść wszystkie przychodzące dane, nawet od zaufanych użytkowników. Paranoja jest cnotą.

2. W końcu wszystko się psuje. Zminimalizuj szkody, kiedy to nastąpi: jak już wskazałeś, spróbuj zminimalizować obsługę tajnego materiału.

3. Uprość to. Nie rób najnowszych egzotycznych rzeczy, chyba że masz pewność, że w sposób wymierny i możliwy do zwiększenia Twoje bezpieczeństwo. Na przykład wybraliśmy X25519 / NaCl (libsodium) zamiast AES dla naszej warstwy szyfrowania (szyfrujemy wszystko, w spoczynku i w ruchu), ponieważ został pierwotnie zaprojektowany i napisany przez kogoś, komu ufaliśmy (DJB i in.) I został sprawdzony przez świat uznani badacze, tacy jak Schneier i zespół ds. bezpieczeństwa Google. Używaj rzeczy, które mają tendencję do prostoty, jeśli są nowsze, ponieważ prostota utrudnia ukrywanie głębokich błędów.

4. Spełniaj standardy bezpieczeństwa. Nawet jeśli nie wpadasz w reżim bezpieczeństwa, taki jak PCI lub zasada bezpieczeństwa HIPAA, zapoznaj się z tymi standardami i dowiedz się, jak je spełnić lub przynajmniej bardzo silne kontrole kompensacyjne. Pomoże to zapewnić, że naprawdę spełniasz „najlepsze praktyki”.

5. Wprowadź zewnętrzne / niezależne testy penetracyjne i uruchom nagrody za błędy, aby upewnić się, że postępujesz zgodnie z tymi najlepszymi praktykami na bieżąco. Wszystko wygląda świetnie, dopóki nie zaczną na nim wpadać inteligentni i silnie zmotywowani ludzie ... kiedy to się skończy, będziesz mieć dużo zaufania do swojego rozwiązania.

Pytanie 2: klucze SSH Jaki jest najlepszy wybór: pozwól Ansible użyć użytkownika root (z jego kluczem publicznym zapisanym w ~/.ssh/authorized_keys/ pozwól użytkownikowi Ansible na uruchomienie wszystkich poleceń przez sudo z określeniem hasła (które jest unikalne, musi być znane każdemu sysadminowi który używa Ansible do kontrolowania tych serwerów)

Staraj się unikać używania haseł na serwerach, nawet w sudo. To dotyczy tajemnic i ostatecznie podważy twoje bezpieczeństwo (nie możesz tak naprawdę bardzo łatwo zmieniać hasła sudo między maszynami, musisz je gdzieś przechowywać, hasło oznacza, że ​​tak naprawdę nie możesz zrobić automatyzacji między serwerami, która jest dokładnie o co w tym wszystkim chodzi. Ponadto, jeśli pozostawisz SSH na wartościach domyślnych, hasła te mogą zostać brutalnie wymuszone, co sprawia, że ​​klucze są nieco bezsensowne.

Utwórz nieuprzywilejowanego użytkownika dedykowanego dla Ansible z dostępem sudo / pozwól użytkownikowi Ansible na uruchamianie wszystkich poleceń przez sudo bez podawania hasła

Dokładnie. Nieuprzywilejowany użytkownik, który możesz poddać inspekcji z powrotem do ansible, z rolami sudo. Idealnie, stwórz standardowego użytkownika dedykowanego do komunikacji serwer-serwer / ansible z dostępem sudo (bez hasła).

... Uwaga: jeśli korzystasz z Userify, sugerowałbym, aby utworzyć użytkownika Userify dla ansible (możesz to również podzielić według projektu lub nawet grupy serwerów, jeśli masz wiele automatycznych urządzeń sterujących), wygeneruj klucz SSH na serwerze sterującym i podaj jego klucz publiczny na stronie profilu Userify. (To pole tekstowe zasadniczo się zmienia /home/ansible/.ssh/authorized_keys). Konto systemowe ansible powinno być oddzielone od innych kont systemowych serwer-serwer, takich jak konto zdalnej kopii zapasowej, tajne zarządzanie itp. Następnie zaproś swoich ludzi, a także będą mogli tworzyć własne klucze i zarządzać nimi, a wszystko pozostanie oddzielone. Ale podobnie jak w przypadku blokowania serwera sterującego Ansible, spróbuj zablokować serwer Userify (lub dowolne rozwiązanie, które wdrażasz) w ten sam sposób.

jakieś inne wskazówki?

Myślę, że zdecydowanie robisz to we właściwy sposób i zadajesz właściwe pytania. Jeśli chcesz porozmawiać na ten temat, napisz do mnie (imię i nazwisko pierwszego użytkownika w userify), a chętnie porozmawiam bez względu na to, w jakim kierunku ostatecznie podążasz. Powodzenia!

Odpowiedź 1: maszyna sterująca

Trochę z obu, możesz użyć swojego laptopa, aby połączyć się z serwerami VIA hosta bastionu. coś jak:

Host private1
  IdentityFile ~/.ssh/rsa_private_key
  ProxyCommand ssh user@bastion -W %h:%p

Host bastion
  IdentityFile ~/.ssh/bastion_rsa_key

Więcej na temat gospodarzy bastionu

Gdzie masz klucz do serwera bastionu, a następnie oddzielny klucz dla hosta za nim. (osobiście użyłbym gpg-agent / ssh-agent)

Odpowiedź 2: Uwierzytelnianie

Nie jestem pewien, w jaki sposób najlepsze praktyki „ansible” różnią się od innych najlepszych praktyk połączenia ssh, ale nie, chcesz uruchamiać ansible jak ty, a nie konto usługi, a nie konto root.

Połączenie następujących uwierzytelnień:

• Klucze SSH dla użytkownika (przechowywane centralnie)
• Uwierzytelnianie Kerberos
• Uwierzytelnianie wieloskładnikowe ( Yubikeys , Duo, GoogleAuth itp.)
• Fail2ban / blokada konta
• scentralizowane rejestrowanie i ostrzeganie
• scentralizowane uwierzytelnianie (FreeIPA, LDAP, IdM, MS AD)
• podpisuj klucze ssh wewnętrznym ok

Inne przemyślenia:

• Zawsze przechowuj sekrety / prywatne informacje w ansible-vault.
• Ansible nie wymaga uruchamiania SUDO / Root, chyba że to, co robisz, wymaga sudo / root.
• Ansible może podnieść uprawnienia na wiele różnych sposobów

Na koniec nie wspomniałeś o Windowsie. Mogę tylko założyć, że tego nie używasz. Jednak w tym przypadku bastion.hostname.fqdnużyłbym opcji delegowania, aby twój laptop używał hosta bastionu (delegate_to :) i kerberos / winrm https z biletami kerberos.

Na wypadek, gdybyś go przeoczył, najlepsza praktyka dotycząca komputerów, nigdy nie rób niczego jako root, zawsze używaj nazwanych kont