Bezpieczeństwo Chmury

Przegląd bezpieczeństwa chmury bada konfigurację kont: tożsamości i uprawnienia, reguły sieciowe, szyfrowanie, sekrety, kopie zapasowe oraz logowanie zdarzeń w AWS, Azure lub GCP. Kontenery, klastry Kubernetes, proces wdrożeniowy i osobne środowiska usług biurowych uzgadnia się osobno, bo każde z nich niesie własny model uprawnień. Kod aplikacji i logika biznesowa zwykle zostają poza tą usługą i wymagają innej pracy.

Wycena idzie za tym, ile jest do policzenia: konta i subskrypcje, uruchomione usługi, klastry oraz osobne procesy wdrożeniowe. Środowisko rozpięte na dwóch platformach kosztuje więcej niż jedna platforma tej samej wielkości, bo każda ma własny model uprawnień i własne nazwy kontroli. Udział inżyniera dostawcy przy naprawie oraz powtórne sprawdzenie po zmianach wycenia się zwykle jako odrębne pozycje.

Przeniesienie danych do chmury nie przenosi obowiązków na dostawcę. W typowym układzie klient pozostaje administratorem, a dostawca działa jako podmiot przetwarzający, ale role zależą od usługi i celu przetwarzania - dla własnych celów dostawca bywa administratorem tej części. Podział ustala się dla każdej usługi osobno i zapisuje w umowie powierzenia, a podmioty objęte NIS2 dokładają do tego nadzór nad dostawcą.

Naprawę porządkuje się według ekspozycji, nie według liczby pozycji: najpierw to, co jest osiągalne z internetu i co daje prawa administracyjne. Każda pozycja potrzebuje wskazanego właściciela, bo znalezisko bez osoby odpowiedzialnej wraca w kolejnym przeglądzie. Poprawki wprowadzone ręcznie w konsoli trzeba przenieść do kodu infrastruktury, inaczej najbliższe wdrożenie je cofnie.

Odczyt konfiguracji nie zmienia stanu środowiska, więc sam przegląd pracuje na dostępie tylko do odczytu. Ryzyko pojawia się przy naprawie: zawężenie roli albo zamknięcie ścieżki sieciowej potrafi zatrzymać integrację, której nikt nie opisał. Dlatego zmiany w rolach i regułach ruchu wprowadza się etapami, najpierw poza produkcją, i obserwuje logi odrzuconych żądań, zanim stara reguła zostanie wyłączona.

Przegląd konfiguracji chmury odpowiada na pytanie, jak środowisko jest ustawione, a nie czy da się do niego włamać. Audytor pracuje od strony konta i widzi polityki, role oraz ustawienia usług, których napastnik nie widzi, a test penetracyjny idzie od zewnątrz i dowodzi skutku. Drugie nieporozumienie dotyczy certyfikatów platformy: potwierdzają warstwę dostawcy, nie Twoją konfigurację.

Umowa powinna nazwać konta i usługi objęte nadzorem oraz zestaw reguł, według których oceniana jest konfiguracja. Potrzebuje też ścieżki powiadomienia o wykrytym odchyleniu, rozdziału na to, kto może zmieniać cokolwiek w Twoich kontach, a kto tylko zgłasza, oraz zasad odbierania dostępów po zakończeniu współpracy. Dopisz punkt o tym, że raporty i dane z nadzoru pozostają czytelne bez narzędzi dostawcy.

Przegląd konfiguracji pracuje na metadanych - nazwach zasobów, politykach, regułach sieciowych i wpisach z logów - a nie na zawartości baz i magazynów. Dostęp do odczytu przechowywanych obiektów jest osobną decyzją i przy tej pracy rzadko bywa potrzebny. Ustal przed startem, gdzie leżą zebrane wyniki, jak długo dostawca je trzyma i czy konta założone na potrzeby przeglądu są później usuwane.

Odpowiedzialność za wyciek z zasobu, który skonfigurowała Twoja organizacja, zostaje przy Twojej organizacji, choć sprzęt należy do kogoś innego. Platforma bierze na siebie warstwę fizyczną i wirtualizację, co dostawcy opisują w modelu współdzielonej odpowiedzialności. Audytora wiąże umowa, która zwykle obiecuje staranność przy wykonaniu przeglądu, a nie gwarancję, że środowisko jest bezpieczne.

Oferta napisana pod konkretne środowisko nazywa Twoje usługi i sposób pracy: konta, platformy, obecność kontenerów i to, jak zmiany trafiają na produkcję. Ogólna mówi o dobrych praktykach i zgodności, nie dotykając niczego, co u Ciebie działa. Poproś o próbkę raportu bez danych klienta i sprawdź, czy kroki naprawcze da się wykonać wprost na Twojej platformie.