> 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!