Dobry audyt infrastruktury odpowiada na cztery pytania: co uruchamiamy, kto może uzyskać do tego dostęp lub to zmienić, jakie dowody potwierdzają działanie zabezpieczeń i co naprawić najpierw? Traktuj PaaS, IaaS, sieci, zapory i systemy operacyjne jako jeden połączony system. Zacznij od pisemnej zgody, uzgodnionego zakresu, wskazanych właścicieli, terminu i kontaktu awaryjnego. W miarę możliwości używaj dostępu tylko do odczytu; nie skanuj ani nie testuj systemów bez upoważnienia.
Przed testami zmapuj środowisko: konta i subskrypcje chmurowe, regiony, projekty, środowiska produkcyjne i testowe, publiczne punkty końcowe, obciążenia, magazyny danych, tożsamości i dostawców zewnętrznych. Zaznacz przepływy danych i granice zaufania. Dla każdego zasobu zapisz właściciela, cel biznesowy, wrażliwość danych, ekspozycję, zależności i znaczenie dla odtworzenia. Porównaj inwentarz z rozliczeniami, DNS, eksportami konsoli chmurowej, zarządzaniem urządzeniami i Infrastructure as Code, aby znaleźć zapomniane zasoby oraz ręczne zmiany.
Najpierw ustal podział wspólnej odpowiedzialności. W IaaS dostawca zwykle obsługuje fizyczną infrastrukturę i usługę bazową, a zespół odpowiada za systemy gościa, konfigurację obciążeń, tożsamości, reguły sieciowe i dane. W PaaS dostawca zarządza większą częścią środowiska wykonawczego, ale zespół nadal odpowiada za kod, dostęp, dane, sekrety i ustawienia usługi. Sprawdź warunki dla każdej usługi: określenie „zarządzana” nie oznacza, że dostawca realizuje wszystkie zabezpieczenia.
W IaaS sprawdź granice kont i projektów, role administratorów, MFA, tożsamości obciążeń, konta usługowe, przechowywanie kluczy i sekretów, publiczne IP, ekspozycję magazynu, kopie zapasowe, szyfrowanie, poprawki i odchylenia konfiguracji. Preferuj krótkotrwałe, ograniczone poświadczenia i prywatne ścieżki administracyjne. W PaaS sprawdź izolację tenantów, uwierzytelnianie i autoryzację, prywatną łączność, dozwolone źródła, uprawnienia wdrożeniowe, zmienne środowiskowe, referencje sekretów, retencję i dzienniki audytowe. Upewnij się, że logi diagnostyczne są włączone, przechowywane, chronione i przydatne podczas incydentu.
W sieci komputerowej zweryfikuj rzeczywiste ścieżki między użytkownikami, wejściem z Internetu, load balancerami, warstwami aplikacji, bazami danych, interfejsami administracyjnymi i celami ruchu wychodzącego. Sprawdź podsieci i trasy, segmentację, DNS, VPN lub dostęp prywatny, zdalną administrację, ograniczenia ruchu wychodzącego i odporność. Porównaj diagram z logami przepływu i eksportami konfiguracji. Zbadaj nieoczekiwane ścieżki, płaskie sieci, bezpośrednio wystawione bazy, nieużywane interfejsy i ruch omijający kontrolę. Dozwolony skaner pomoże znaleźć osiągalne usługi; uzgodnij czas i tempo, a wyniki zweryfikuj — skan nie jest pełnym audytem sieci.
Oceniaj razem reguły cloud security groups, sieciowych ACL, zapór hostów i dedykowanych urządzeń. Dla każdej reguły ustal właściciela, cel, źródło, miejsce docelowe, protokół, port, kierunek, środowisko oraz termin przeglądu lub wygaśnięcia. Szukaj nieograniczonych źródeł internetowych, szerokich zakresów portów, reguł any-to-any, duplikatów, przestarzałego dostępu tymczasowego i publicznych portów administracyjnych. Sprawdź domyślną odmowę i logowanie. Zmiany testuj bezpiecznie; usuń regułę dopiero po potwierdzeniu zależności i przygotowaniu wycofania.
Dla każdego zarządzanego systemu operacyjnego sprawdź wspieraną wersję i poprawki, bezpieczną konfigurację bazową, konta lokalne i katalogowe, grupy uprzywilejowane, MFA dla administracji, ekspozycję SSH lub pulpitu zdalnego, uwierzytelnianie, zaporę hosta, ochronę urządzeń, szyfrowanie dysku, Secure Boot, jeśli jest dostępny, synchronizację czasu, usługi i zadania startowe. Zweryfikuj centralne przesyłanie logów, alerty, kopie i odtwarzanie oraz zarządzanie konfiguracją. Porównaj ustawienia z aktualnymi zaleceniami dostawcy lub właściwym CIS Benchmark i udokumentuj uzasadnione wyjątki. W PaaS sprawdzaj tylko dostępne kontrole hosta, skupiając własny przegląd na aplikacji i konfiguracji usługi.
Zachowuj odtwarzalne dowody: zasób i konto, czas, narzędzie lub widok konsoli, zrzut konfiguracji, stan oczekiwany i zaobserwowany, audytor i ograniczenia. Chroń eksporty i zrzuty ekranu, bo mogą zawierać identyfikatory, topologię lub sekrety; maskuj wrażliwe wartości i ogranicz dostęp. Klasyfikuj ustalenia według wpływu, prawdopodobieństwa, dotkniętych zasobów, ekspozycji, możliwości wykorzystania i zabezpieczeń kompensujących. Oddziel potwierdzone słabości od obserwacji wymagających dalszych dowodów; wskaż właściciela biznesowego i technicznego.
Zamień ustalenia w śledzony plan napraw z priorytetem, właścicielem, terminem, wpisem zmiany, planem wycofania i walidacją. Najpierw usuń publiczny dostęp administracyjny i nadmierne uprawnienia, potem luki segmentacji, podatne lub niewspierane systemy, braki w logowaniu i słabe kopie. Po zmianie ponownie sprawdź kontrolę i zachowaj dowody przed i po. Ryzyko rezydualne zgłoś osobie uprawnionej do jego akceptacji. Audyt kończy się, gdy właściciele rozumieją ryzyko, a zweryfikowane działania je ograniczyły.
Używaj uznanych wytycznych jako punktu wyjścia, nie zamiennika kontekstu: NIST SP 800-115 opisuje planowanie i prowadzenie technicznych ocen bezpieczeństwa; CIS Benchmarks zawierają zalecenia konfiguracji dla chmury, urządzeń sieciowych i systemów operacyjnych. Wybierz benchmark dla właściwego dostawcy i wersji, dostosuj go udokumentowanymi decyzjami ryzyka i stosuj wyłącznie metody dozwolone w zasadach audytu. Źródła: https://csrc.nist.gov/pubs/sp/800/115/final oraz https://www.cisecurity.org/cis-benchmarks-overview
Daj kolejnemu produktowi kogoś, kto zostanie.
Chcesz zacząć? Napisz do mnie — mogę rozpocząć od razu i zostać na dłużej. Długoterminowa współpraca, nie przekazanie projektu po dwóch tygodniach. Omówmy projekt, wymagania i najlepszy sposób realizacji.