Audyt bezpieczeństwa w chmurze: lista kontrolna dla AWS, Azure i Google Cloud na start

Od czego zacząć audyt bezpieczeństwa w chmurze

Zdefiniowanie celu i zakresu audytu

Audyt bezpieczeństwa w chmurze ma sens dopiero wtedy, gdy jest zawężony do konkretnego celu. Dla startu najlepiej skupić się na prostej odpowiedzi: co w tej chwili jest najbardziej narażone na przejęcie lub wyciek. W praktyce oznacza to przejrzenie kont nadrzędnych, dostępu administratorów, publicznie dostępnych usług oraz głównych baz danych i bucketów z danymi.

Na początku trzeba zdecydować, które środowiska obejmuje audyt:

• tylko produkcja – gdy zależy na szybkim ograniczeniu ryzyka biznesowego,
• produkcja + test – gdy dane testowe mogą być prawdziwe lub łatwo powiązane z realnymi,
• wszystkie środowiska – gdy konfiguracja „przecieka” między środowiskami (np. kopiowanie szablonów).

Drugie pytanie: z jakiej perspektywy patrzeć na audyt. Można to ułożyć w kilka obszarów:

• bezpieczeństwo konta – root/owner, dostęp do konsoli, MFA, polityki haseł,
• infrastruktura – sieć, serwery, kontenery, usługi PaaS,
• dane – bazy, storage, backupy, szyfrowanie danych w chmurze,
• tożsamość – IAM, role, grupy, service accounts, integracja z IdP,
• zgodność – minimalne wymagania z RODO, ISO, branżowych regulacji.

Na pierwszy audyt warto wybrać 2–3 perspektywy, zamiast próbować „ogarnąć wszystko”. Dobry zestaw na start: konto + tożsamość + dane publicznie dostępne. To właśnie tu dochodzi do najszybszych i najdroższych w skutkach incydentów, zwłaszcza przy niewielkich, rosnących środowiskach.

Kolejny krok to spisanie krytycznych systemów i danych. Minimum:

• lista aplikacji, które działają w chmurze (frontend, backend, API, batch),
• lista baz danych i storage, gdzie przechowywane są dane klientów lub dane wrażliwe,
• komponenty wystawione do internetu (API, portale, panele admina),
• integracje z systemami zewnętrznymi (płatności, CRM, narzędzia marketingowe, SaaS).

Dobrą praktyką jest spisanie tego w najprostszej tabeli (arkusz, dokument) i oznaczenie priorytetu: Wysoki / Średni / Niski. Zakres audytu na start powinien obowiązkowo obejmować wszystkie elementy z priorytetem „Wysoki”.

Na koniec warto ustalić prosty harmonogram audytu. Nie musi być skomplikowany:

• tydzień 1: konta, IAM, MFA, polityki haseł,
• tydzień 2: sieć i dostęp publiczny,
• tydzień 3: szyfrowanie danych, backupy, rotacja kluczy,
• tydzień 4: logowanie i monitoring w chmurze, alerty.

Na tej podstawie można później ustalić cykliczny przegląd – np. co kwartał szybki audyt „light”, a raz do roku pełniejszy przegląd.

Różnice między audytem „na start” a audytem dojrzałego środowiska

Audyt bezpieczeństwa w chmurze w młodym środowisku ma zupełnie inny charakter niż w dużej, wieloletniej organizacji. Na początku najczęściej brakuje procesów, automatyzacji i narzędzi klasy enterprise, ale za to architektura jest prostsza, a liczba komponentów ograniczona. To duża przewaga – wiele ryzyk da się ograniczyć dosłownie w kilka dni.

Na etapie „na start” nie ma sensu inwestować czasu w:

• budowę dużego SIEM klasy enterprise z pełną korelacją logów z on-prem i chmur,
• skomplikowane modele zarządzania tożsamością wielopoziomową (np. kilkunastopoziomowe role),
• rozbudowane automatyzacje typu SOAR, setki reguł detekcji i orkiestrację reakcji,
• zaawansowane modele segmentacji mikroserwisów, jeśli środowisko dopiero powstaje.

Obowiązkowe elementy już od pierwszego dnia to:

• bezpieczeństwo konta root/owner – silne hasło, MFA, brak codziennej pracy na tym koncie,
• MFA dla wszystkich osób z dostępem do portali zarządzania (AWS Console, Azure Portal, Google Cloud Console),
• podstawowe logowanie i monitoring – włączenie logów audytowych, logów API, logów zmian konfiguracji,
• kontrola publicznego dostępu – brak baz danych, bucketów, storage z niekontrolowanym dostępem z internetu,
• szyfrowanie danych w spoczynku – przynajmniej z użyciem zarządzanych przez dostawcę kluczy.

W miarę rozwoju środowiska, zakres audytu powinien być rozbudowywany krok po kroku:

• dodanie centralnego zarządzania organizacją (AWS Organizations, Azure Management Groups, GCP Organization),
• wprowadzenie polityk organizacyjnych (SCP, Azure Policy, Organization Policy Service),
• standaryzacja pipeline’ów CI/CD z kontrolą bezpieczeństwa (skanowanie IaC, obrazów kontenerów),
• wdrożenie dedykowanego systemu logowania i monitoringu (CloudWatch/CloudTrail + SIEM, Azure Monitor/Log Analytics, Cloud Logging + narzędzie zewnętrzne).

Różnica kluczowa: audyty w dojrzałym środowisku muszą być procesem, w którym zmiany w konfiguracji chmury są powiązane z zarządzaniem ryzykiem, zmianami w aplikacjach, compliance. Audyt „na start” to przede wszystkim wyłapanie najbardziej rażących luk i stworzenie fundamentu, na którym można bezpiecznie rozwijać architekturę.

Podstawy bezpieczeństwa konta i tożsamości (IAM, konta root/owner)

Blokowanie najgroźniejszych wektorów – konta root/owner

Konto root w AWS, Account Owner w Azure i Organization Admin/Owner w Google Cloud to główne bramy do całej organizacji. Ich przejęcie oznacza pełną kontrolę nad zasobami, rozliczeniami i konfiguracją bezpieczeństwa. Dlatego audyt bezpieczeństwa w chmurze powinien zacząć się właśnie tutaj.

Pierwsza mikro-checklista dla kont nadrzędnych:

• sprawdzenie, czy MFA jest włączone na koncie root/owner,
• weryfikacja, czy adres email dla konta jest dedykowany (nie prywatny, nie ogólny),
• zmiana hasła na silne, długie (menedżer haseł, min. 16+ znaków),
• sprawdzenie ostatniego użycia konta root/owner (logi audytowe),
• skonfigurowanie powiadomień o logowaniu na konta uprzywilejowane (np. przez CloudWatch Events / Event Grid / Cloud Logging).

W AWS konto root powinno być wykorzystywane tylko do kilku operacji, których nie da się wykonać z konta admina (np. niektóre zmiany rozliczeniowe). AWS CloudTrail pozwala sprawdzić, czy ktoś logował się na konto root i do czego je wykorzystywał. Jeśli root pojawia się w logach regularnie, to sygnał alarmowy.

W Azure dostęp właścicielski do subskrypcji (Owner) i rola Global Administrator w Entra ID (dawniej Azure AD) muszą być ograniczone do absolutnego minimum – najlepiej do 2–3 osób z jasno opisaną odpowiedzialnością. W Google Cloud podobnie traktuje się rolę Organization Admin – powinna być przydzielona wąskiej grupie, a codzienna praca odbywać się na mniej uprzywilejowanych rolach.

Dobrą praktyką jest formalna dokumentacja dostępu uprzywilejowanego:

• kto ma dostęp do root/owner/Organization Admin,
• w jakich sytuacjach wolno używać tych kont,
• jak wygląda procedura awaryjna (np. utrata telefonu z MFA),
• jak zgłaszany i akceptowany jest tymczasowy dostęp uprzywilejowany.

Nawet mała firma może wdrożyć prostą politykę: dostęp do kont nadrzędnych jest rotowany i audytowany (np. raz na kwartał przegląd listy uprawnień i logów logowania). Jedno zadbane konto root jest warte więcej niż dziesięć półkonfigurowanych skanerów bezpieczeństwa.

Zasady IAM w praktyce (AWS IAM, Azure AD/Entra ID, Google IAM)

Kolejny krok to konfiguracja IAM w chmurze. Tutaj wiele organizacji popełnia ten sam błąd: na początku „na szybko” nadaje się szerokie uprawnienia (np. AdministratorAccess w AWS, Owner w Azure, Editor w GCP), a potem nikt tego nie zawęża. Audyt „na start” powinien dążyć do przybliżenia się do zasady najmniejszych uprawnień.

Praktyczne podejście:

• zebrać listę wszystkich użytkowników i ról w IAM / Entra ID / Google IAM,
• przejrzeć, kto ma role typu Admin, Owner, Editor, Contributor,
• wyszukać polityki zawierające "*" w sekcjach akcji lub zasobów (np. "Action": "*" w AWS IAM),
• sprawdzić, które konta są nieużywane (brak logowań od wielu miesięcy).

W AWS warto zacząć od podziału na:

• grupy i role dla ludzi – przypisane do użytkowników IAM lub przez federację (SSO),
• role dla maszyn – EC2 instance profiles, role dla kontenerów, Lambda execution roles,
• role dla integracji zewnętrznych – np. narzędzia backupowe, monitoring, SaaS.

W Azure podobny podział można oprzeć na:

• użytkownikach Entra ID,
• managed identities dla aplikacji i usług (system-assigned i user-assigned),
• grupach bezpieczeństwa i ról przypisanych do subskrypcji, resource group, zasobów.

W Google Cloud punkt centralny to service accounts, które bardzo często mają zbyt szerokie role (np. Editor na poziomie projektu). Dobrym ruchem na starcie jest przejrzenie wszystkich service accounts i ograniczenie ich uprawnień do tego, co faktycznie wykorzystują – np. zamiast Editor użyć konkretnych ról typu Storage Object Viewer, Pub/Sub Publisher.

Do przeglądu dostępu zewnętrznego przydaje się prosta lista:

• które integracje SaaS korzystają z dostępu do chmury (backup, monitoring, CI/CD, billing),
• jakie uprawnienia mają nadające się im role (czy faktycznie potrzebują Admina),
• jak wygląda proces rezygnacji z integracji – czy ktoś usuwa role i klucze, gdy narzędzie przestaje być używane,
• czy istnieją jeszcze konta konsultantów, którzy już nie współpracują z firmą.

Dobrym nawykiem jest oddzielenie ról dla ludzi i maszyn. Człowiek loguje się przez SSO i MFA, a maszyna (aplikacja, pipeline) korzysta z managed identity lub service account. Jeśli w IAM widać wiele użytkowników z kluczami dostępowymi typu „admin-api” bez kontekstu, to powinna zapalić się czerwona lampka.

Podstawowe polityki haseł i MFA

Bezpieczeństwo kont w chmurze zaczyna się od kontroli haseł i MFA. W każdej z trzech głównych chmur wygląda to trochę inaczej, ale cel jest ten sam: wymusić, żeby atakujący nie mógł łatwo zgadnąć albo wyłudzić danych logowania i wejść do konsoli.

Najprostsza konfiguracja na start obejmuje:

• zdefiniowanie polityki haseł (długość, złożoność, rotacja),
• włączenie MFA dla wszystkich kont z dostępem do konsoli administracyjnej,
• zasady blokady konta po wielu nieudanych próbach logowania,
• powiadomienia o nietypowych logowaniach (np. z nowych lokalizacji).

W AWS, jeśli używani są użytkownicy IAM, polityki haseł definiuje się na poziomie konta. Przy integracji z zewnętrznym IdP (SSO) polityka jest przeniesiona do IdP. Coraz częściej firmy odchodzą od lokalnych użytkowników IAM na rzecz federacji – to kierunek, który warto wpisać do planu rozwoju bezpieczeństwa.

W Azure Entra ID daje dużo opcji polityk haseł, również adaptacyjnych (risk-based). Na start wystarczy jednak:

• minimalna długość hasła (np. 12+ znaków),
• blokada prostych haseł,
• MFA dla wszystkich użytkowników z dostępem do Azure Portal i krytycznych aplikacji SaaS.

W Google Cloud tożsamość jest powiązana z kontem Google, które często jest zarządzane przez Google Workspace. Tutaj również polityki haseł i MFA ustawia się centralnie. Kluczowe jest odseparowanie kont prywatnych od służbowych i wymuszenie MFA dla wszystkich członków organizacji GCP.

Na koniec warto wprowadzić szybką politykę blokad kont – określić, po ilu błędnych próbach logowania konto jest blokowane i jak wygląda proces jego odblokowania. Nawet prosta procedura (zgłoszenie do admina, weryfikacja, odblokowanie) zmniejsza ryzyko ataków typu brute force i ułatwia reagowanie na incydenty.

Organizacja środowiska: konta, subskrypcje, projekty i separacja

Model kont i subskrypcji – porządek przed szczegółami technicznymi

Bez sensownego podziału środowiska audyt szybko zamienia się w chaos. Ten sam błąd wraca jak bumerang: jedno konto AWS, jedna subskrypcja Azure, jeden projekt GCP – i wszystko wrzucone do środka. Dla małego POC-u to jeszcze działa, dla produkcji już nie.

Na start przydaje się prosty model warstwowy:

• pion – środowiska (prod, test, dev, sandbox),
• poziom – domeny biznesowe / systemy (np. e-commerce, BI, integracje),
• technicznie – odzwierciedlenie w kontach / subskrypcjach / projektach.

W AWS często stosuje się mapowanie: jedno konto = jedno środowisko danego systemu. Przykład: ecommerce-prod, ecommerce-test, shared-services. W Azure podobną rolę pełnią subskrypcje, w GCP – projekty. Jeśli dzisiaj wszystko siedzi w jednym miejscu, audyt powinien jasno wskazać plan migracji do bardziej rozdzielonego modelu.

Krótka lista kontrolna stanu obecnego:

• ile jest kont AWS / subskrypcji Azure / projektów GCP i jak są nazwane,
• czy istnieje rozróżnienie na prod / test / dev,
• czy są zasoby „wspólne” (np. logging, monitoring, CI/CD) i gdzie mieszkają,
• czy ktoś czuwa nad centralną strukturą, czy każdy zespół tworzy, co chce.

Sam fakt przejścia z „jednego worka” na kilka logicznych kont zwykle rozwiązuje połowę problemów z uprawnieniami, limitami, porządkiem w tagach i rozliczeniach.

Separacja obowiązkowa: produkcja vs. reszta

Najważniejsza linia podziału to oddzielenie środowisk produkcyjnych od eksperymentów. Jeśli produkcję da się przypadkiem „dotknąć” z konta developera bawiącego się w sandboxie – to z punktu widzenia bezpieczeństwa sygnał ostrzegawczy.

Prosty model do wdrożenia na początku:

• osobne konto/subskrypcja/projekt dla prod,
• oddzielne dla test/UAT,
• oddzielne dla dev/sandbox.

W AWS klasyczny wzorzec to użycie AWS Organizations z kilkoma OU (Organizational Units):

• OU Prod – konta produkcyjne,
• OU NonProd – test, dev, sandbox,
• OU Shared – narzędzia wspólne, np. centralny logging, skanery bezpieczeństwa.

W Azure podobny efekt daje Management Groups z hierarchią typu Prod, NonProd, Platform. W GCP tą rolę pełnią foldery pod organizacją. W audycie warto sprawdzić, czy taka struktura istnieje i czy faktycznie odzwierciedla rzeczywistość, a nie tylko ładnie wygląda w portalu.

Minimalne kroki bezpieczeństwa dla prod:

• osobne role i grupy dostępu niż dla non-prod,
• silniejsze polityki (np. wymóg MFA, PIM/Just-In-Time do uprawnień admina),
• blokady na poziomie organizacji/management groups (np. zabronione typy zasobów),
• bardziej rygorystyczne polityki sieciowe (brak bezpośredniego dostępu z Internetu do admin interfejsów).

Konto „landing zone” i wspólne usługi

Nawet mała organizacja powinna mieć jedno miejsce, z którego zarządza rzeczami wspólnymi. To tzw. landing zone albo konto/platforma usług wspólnych. Dobrze zaplanowana landing zone bardzo ułatwia audyt – większość ustawień bezpieczeństwa jest w jednym miejscu.

W AWS wspólne konto (np. shared-services albo security) może trzymać:

• centralne logi (CloudTrail, Config, VPC Flow Logs, ALB/NLB logs),
• systemy monitoringu i SIEM,
• narzędzia do backupu, skanowania podatności, skanów compliance.

W Azure rolę landing zone często pełni specjalny zestaw subskrypcji podpiętych pod Management Group Platform. W GCP – projekty typu security-logging, platform-monitoring w osobnym folderze. Z punktu widzenia audytu kluczowe są dwie rzeczy:

• czy logi z innych kont/subskrypcji/projektów rzeczywiście trafiają do centralnego miejsca,
• kto ma dostęp do tej „centrali” i jak są chronione dane (np. szyfrowanie, IAM, retention).

Jeśli dzisiaj każde konto ma swoje osobne logi, a dostęp do nich mają przypadkowe osoby, w raporcie z audytu musi się pojawić rekomendacja ujednolicenia tego modelu.

Tagowanie, nazewnictwo i mapowanie do biznesu

Sprawny audyt wymaga, żeby dało się szybko odpowiedzieć na kilka prostych pytań: do jakiego systemu należy ten serwer, kto za niego płaci, czy jest produkcyjny. Bez standardu nazewnictwa i tagowania kończy się to klikiem po każdym zasobie z osobna.

Podstawowy pakiet na start:

• konwencja nazw (np. <system>-<środowisko>-<typ>-<id>),
• zestaw obowiązkowych tagów/etykiet (AWS tags, Azure tags, GCP labels),
• mechanizm wymuszania (polityki organizacyjne).

Przykładowy minimalny zestaw tagów:

• Environment (prod/test/dev),
• Owner (zespół lub system owner),
• System (nazwa aplikacji),
• CostCenter lub BilingCode.

W AWS AWS Organizations + Service Control Policies (SCP) oraz tag policies pozwalają wymuszać obecność określonych tagów. W Azure podobny efekt osiąga się przez Azure Policy, a w GCP – Organizational Policies i automaty tagujące (np. Cloud Functions / Cloud Run z cronem).

Podczas audytu dobrze sprawdzić:

• jaki procent zasobów ma wymagane tagi,
• czy da się łatwo wylistować wszystkie zasoby dla konkretnego systemu lub właściciela,
• czy tagi są używane do polityk (np. backup, szyfrowanie, monitorowanie).

Granice między zespołami i odpowiedzialność

Drugi wymiar separacji to zespoły. W większych organizacjach każdy ma trochę inne potrzeby i poziom dojrzałości. Jedni potrafią sensownie zarządzać uprawnieniami, inni klikają wszystko na roli Owner.

W praktyce dobrze działa model:

• chmura zarządzana centralnie (Cloud Center of Excellence / platform team) – definiuje zasady, landing zone, polityki organizacyjne,
• zespoły produktowe mają wydzielone konta/subskrypcje/projekty w ramach centralnych reguł.

Podczas audytu warto jasno zmapować:

• które konta/subskrypcje/projekty należą do jakich zespołów,
• kto jest technicznym i biznesowym właścicielem (imiona, zespoły, nie „IT ogólnie”),
• jakie są domyślne uprawnienia dla zespołu (np. Contributor na swojej subskrypcji, brak Ownera).

Szczególnie istotne są przypadki, gdy konsultant lub vendor dostaje „na szybko” Ownera do całej subskrypcji lub konta. W audycie trzeba takie sytuacje wyłapać i zaproponować model oparty na własnych kontach vendorów z ograniczonym dostępem oraz jasną datą wygaśnięcia.

Kontrola nad tworzeniem nowych kont i subskrypcji

Gdy każdy może tworzyć nowe konta/subskrypcje/projekty, struktura organizacyjna zaczyna się rozjeżdżać. Dodatkowy problem – nowe środowiska często powstają poza standardami bezpieczeństwa (bez logowania, bez backupu, bez polityk sieciowych).

Bezpieczny model zakłada:

• centralny proces tworzenia kont/subskrypcji/projektów (formularz, ticket, automation),
• szablony (landing zones) z gotową konfiguracją bezpieczeństwa,
• automatyczne podłączanie logów, monitoringu, polic do nowego środowiska.

W AWS dobrze sprawdzają się narzędzia typu AWS Control Tower lub własne automaty (CloudFormation/Terraform) tworzące nowe konta w ramach Organizations. W Azure – Azure Blueprints (obecnie zastępowane przez kombinację ARM/Bicep + Policy + Management Groups). W GCP – szablony Terraform + Cloud Identity / Google Workspace do zarządzania projektami.

Podczas audytu trzeba ustalić, czy nowe środowiska powstają według takiego standardu. Jeśli nie, pierwszym krokiem naprawczym powinno być zamknięcie „wolnej amerykanki” i wprowadzenie prostego, ale kontrolowanego procesu.

Bezpieczeństwo sieci w chmurze: VPC/VNet i dostęp z zewnątrz

Model sieciowy: segmentacja zamiast jednej wielkiej sieci

Sieć w chmurze bywa traktowana jak wielka płaska podsieć z kilkoma security groupami na deser. To zaproszenie do problemów – wystarczy jedno przejęte konto aplikacyjne, żeby można było przeskakiwać między systemami.

Podstawą jest segmentacja sieciowa:

• podział na VPC/VNet/projekty sieciowe według środowisk i systemów,
• podział w ramach sieci na strefy: publiczną, prywatną, admin, integracyjną,
• ograniczenie ruchu między segmentami do absolutnie potrzebnych portów i kierunków.

W AWS naturalną jednostką jest VPC z zestawem subnetów. W typowym wzorcu:

• subnety publiczne – tylko load balancery i bastiony,
• subnety prywatne – aplikacje, bazy danych, kolejki,
• subnety dedykowane dla admin narzędzi – np. jump hosty, narzędzia skanujące.

W Azure podobną rolę pełni Virtual Network + subnets z dołożonymi NSG i ewentualnie Azure Firewall / NVA. W GCP – VPC networks, subnety i firewall rules. W audycie trzeba sprawdzić, czy w ogóle istnieje koncepcja segmentów, czy wszystko jest „wszędzie do wszystkiego”.

Dostęp z Internetu: publiczne IP, load balancery, bastiony

Najłatwiej zaatakować to, co wystaje do sieci publicznej. Pierwszym krokiem audytu jest lista wszystkich zasobów z publicznym adresem IP lub publicznym endpointem.

Przydaje się prosta checklista:

• wszystkie publiczne IP (EC2/VM, load balancery, NAT-y, bramy VPN),
• publiczne endpointy PaaS (bazy danych, storage, funkcje serverless),
• otwarte porty administracyjne (SSH, RDP, bazy danych, panele aplikacji).

Następnie dla każdego punktu z listy:

• czy musi być publiczny – jeśli nie, wyłączyć lub przenieść za load balancer/VPN,
• jeśli musi – czy jest za reverse proxy/WAF,
• czy dostęp jest ograniczony adresowo (whitelist), czy otwarty na cały świat.

W AWS dobry wzorzec to ekspozycja usług wyłącznie przez ALB/NLB, a ruch administacyjny przez AWS SSM Session Manager zamiast klasycznych bastionów z publicznym IP. W Azure podobnie – Azure Bastion, prywatne endpointy, Application Gateway + WAF zamiast bezpośrednich publicznych VM-ek. W GCP – IAP (Identity-Aware Proxy), Cloud Armor, prywatne adresy dla backendów.

Firewall, security groups i reguły ruchu

Bez względu na chmurę mechanizm jest ten sam: zestaw reguł określających, skąd i dokąd może płynąć ruch. W AWS to Security Groups i Network ACL, w Azure – NSG i ewentualnie Azure Firewall, w GCP – VPC firewall rules i Cloud Firewall.

Przy audycie reguł sieciowych dobrze zadać kilka konkretnych pytań:

• czy są reguły z zakresem 0.0.0.0/0 dla SSH/RDP/baz danych,
• czy są reguły typu „allow all” między subnetami lub VNet/VPC,
• czy istnieją security groups/NSG bez przypisanych instancji (śmieci),
• czy reguły są opisane (opisy, tagi) – żeby było wiadomo, po co istnieją.

Bezpieczny minimalny standard:

• brak bezpośredniego SSH/RDP z Internetu (VPN, bastion, SSM/IAP zamiast tego),
• ruch między segmentami tylko tam, gdzie jest to uzasadnione architekturą,
• oddzielne security groups/NSG dla warstwy web, app, data, admin,
• regularne przeglądy reguł (np. kwartalne) z usuwaniem nieużywanych.

W AWS sporo wniosków można wyciągnąć z VPC Flow Logs – łatwo wychwycić ruch, który w ogóle nie powinien występować. W Azure analogicznie – NSG Flow Logs i analiza w Log Analytics. W GCP – VPC Flow Logs wysyłane do Cloud Logging/BigQuery.

Usługi zarządzane i prywatna łączność (PrivateLink, Private Endpoint, Private Service Connect)

Coraz więcej systemów opiera się na usługach PaaS. Z punktu widzenia audytu kluczowe jest, czy te usługi są dostępne tylko z prywatnej sieci, czy też mają publiczny endpoint z ograniczeniami „na słowo honoru”.

Trzy podstawowe mechanizmy prywatnej łączności:

• AWS – VPC Endpoints (Gateway/Interface) i PrivateLink,
• Azure – Private Endpoint + disable public network access,
• GCP – Private Service Connect (PSC) oraz Private Google Access.

Przy audycie dobrze przejść po listach usług PaaS i zadać kilka prostych pytań:

• czy baza danych (RDS/SQL Database/Cloud SQL) jest osiągalna wyłącznie po prywatnym IP,
• czy storage (S3/Blob Storage/Cloud Storage) jest konsumowany po prywatnym endpointcie,
• czy funkcje serverless i API (Lambda, Azure Functions, Cloud Functions/Run) wystawiają publiczne URL-e, czy są za API Gateway / Front Door / Cloud Endpoints z kontrolą dostępu.

Bezpieczny kierunek to:

• wyłączanie publicznego dostępu tam, gdzie tylko to możliwe,
• udostępnianie usług PaaS przez prywatne endpointy powiązane z konkretnymi subnetami/VNet/VPC,
• centralne policy, które blokują tworzenie zasobów PaaS z publicznym dostępem.

Przykład z praktyki: w jednym z audytów baza Azure SQL miała wyłączone „public network access”, ale ktoś dodał wyjątek „Allow Azure services”. Efekt – otwarta na cały region. Tego typu „przyjazne” ustawienia trzeba podczas przeglądu wychwycić i zamknąć.

Połączenia hybrydowe: VPN, Direct Connect, ExpressRoute, Cloud Interconnect

Gdy chmura łączy się z on-premise, pojawia się kolejny wektor ryzyka: co się stanie, jeśli atakujący dostanie się z jednej strony tunelu na drugą. Audyt musi objąć nie tylko chmurę, ale i sposób, w jaki sieci są spięte.

Elementy do sprawdzenia:

• jakie typy połączeń istnieją (site-to-site VPN, klient VPN, dedykowany link),
• jakie zakresy adresów są routowane w każdą stronę,
• czy tunel prowadzi do centralnego „hubu”, czy bezpośrednio do każdej VPC/VNet,
• czy ruch między chmurą a on-prem jest filtrowany firewallami po obu stronach.

Dobre praktyki:

• model hub-and-spoke – jedno centralne VPC/VNet z bramą VPN/ExpressRoute/Direct Connect,
• filtrowanie ruchu przez centralny firewall (wbudowany lub NVA),
• brak pełnego routingu „any-to-any” – tylko potrzebne podsieci i porty.

W AWS zwykle będzie to Transit Gateway lub centralny VPC z VPN/Direct Connect. W Azure – Virtual WAN albo hub VNet z VPN Gateway/ExpressRoute Gateway. W GCP – Cloud VPN / Interconnect spięty z centralnym VPC. W audycie warto wyrysować schemat tych połączeń i sprawdzić, czy ktoś nie dorobił „dodatkowego tunelu na boku” poza standardową ścieżką.

Kontrola egress: wychodzący ruch do Internetu i między regionami

Ruch wychodzący zwykle jest mniej pilnowany niż przychodzący, a to nim malware wywozi dane lub robi C2. W środowiskach chmurowych często wszystko wychodzi przez Internet bez kontroli, bo „tak działa NAT”.

Podczas audytu wychodzącego ruchu przydaje się prosty plan:

• zidentyfikować wszystkie ścieżki egress: Internet Gateway, NAT Gateway, load balancery, proxy,
• sprawdzić, czy istnieją jakiekolwiek ograniczenia (firewall, proxy, DNS filtering),
• wyłapać instancje/Pods, które mają bezpośrednie publiczne IP i łączą się w świat.

Bezpieczny wzorzec to:

• centralne punkty wyjścia (egress VPC/VNet) z kontrolą URL/portów,
• allow-list domen/zakresów IP dla krytycznych systemów (np. tylko API partnerów, repozytoria),
• monitorowanie zapytań DNS (Route 53 Resolver Query Logs, Azure DNS Logs, Cloud DNS Logs).

Jeżeli budżet pozwala – dochodzi jeszcze inspekcja TLS (w centralnym firewallu lub proxy). Gdy budżet jest ograniczony, lepiej choćby zablokować ruch do „podejrzanych” kategorii i śledzić, dokąd systemy się łączą (flow logs + threat intel).

Segmentacja w Kubernetes (EKS, AKS, GKE) i ruch między podsłużbami

W wielu organizacjach największy chaos panuje w klastrach Kubernetes. Sieć klastra bywa poza radarem zespołu od infrastruktury, a ruch między usługami jest domyślnie otwarty.

Przy audycie klastrów w chmurze warto sprawdzić:

• czy włączone są Network Policies (np. Calico, Cilium, Azure CNI, GKE Network Policy),
• czy ruch między Namespaces jest domyślnie zablokowany (deny all) i otwierany wyjątkiem,
• jak wygląda ekspozycja usług na zewnątrz (LoadBalancer, Ingress, NodePort).

Kilka konkretnych punktów kontrolnych:

• liczba Service type=LoadBalancer w klastrze i ich publiczne IP,
• czy Ingress kontroler jest za WAF i wykorzystuje certyfikaty z zaufanego źródła,
• czy panele administracyjne (Kubernetes dashboard, narzędzia CI/CD) są dostępne z publicznej sieci.

W EKS i GKE dochodzi jeszcze kwestia integracji z VPC: pods mogą mieć własne IP z zakresu VPC. Trzeba sprawdzić, czy reguły security groups/firewall biorą pod uwagę te adresy, czy panuje „allow all” z/do klastra. W AKS często spotyka się konfiguracje, gdzie cały ruch z klastra ma dostęp do wszystkiego w VNet, bo tak wyszło z domyślnych szablonów.

Bezpieczeństwo danych: szyfrowanie, klucze i klasyfikacja

Szyfrowanie w spoczynku: domyślne ustawienia kontra wymagania regulacyjne

Większość usług chmurowych oferuje „szyfrowanie domyślne”. Z perspektywy audytu trzeba jednak ustalić, czy to wystarczy w kontekście wymogów klienta (RODO, PCI, branża finansowa), czy potrzebne są własne klucze KMS/HSM.

Przegląd szyfrowania obejmuje:

• dyski maszyn wirtualnych (EBS/Managed Disks/Persistent Disks),
• storage obiektowy (S3/Blob/Cloud Storage),
• bazy danych zarządzane (RDS, Aurora, Azure SQL, Cloud SQL, BigQuery),
• kolejki, topic-i, systemy logów (SQS, SNS, Event Hub, Pub/Sub, log storage).

Pytania kontrolne:

• czy szyfrowanie jest włączone na wszystkich nowych i starych zasobach,
• czy używane są klucze zarządzane przez dostawcę (SSE-S3, platform-managed) czy własne (KMS/Key Vault/CMEK),
• jak wygląda rotacja kluczy i kto ma do nich uprawnienia.

W AWS trzeba przejrzeć ustawienia KMS i sprawdzić, czy polityki kluczy nie dopuszczają roli *. W Azure – klucze w Key Vault oraz integracje Customer-Managed Key (CMK) w usługach PaaS. W GCP – Cloud KMS i CMEK dla BigQuery/Cloud Storage/Compute Engine. Częsty problem: infrastruktura deklaratywna (Terraform) zakłada „use default key”, co nie spełnia wymagań bardziej konserwatywnych audytorów.

Szyfrowanie w tranzycie i wymuszanie TLS

Drugi filar to szyfrowanie ruchu. Wiele usług oferuje HTTPS jako opcję, ale część klientów nadal mówi HTTP, bo „tak było szybciej zintegrować”.

Kroki audytowe:

• lista endpointów HTTP/HTTPS (load balancery, API Gateway, Function Apps, Cloud Run/Functions),
• sprawdzenie wymuszania HTTPS (redirect + HSTS, polityki „HTTPS only”),
• weryfikacja wersji TLS i zestawu protokołów (TLS 1.0/1.1 do odstrzału).

Do tego dochodzą połączenia do baz danych i innych usług PaaS. W wielu klientach aplikacje nadal łączą się bez TLS, bo „na początku tak było wygodniej”:

• RDS/Cloud SQL/Azure SQL – czy wymuszają szyfrowane połączenia,
• Redis/Cache for Redis/Memorystore – czy ma włączony TLS,
• SMTP, LDAP, inne integracje – czy używają STARTTLS/LDAPS.

Warto przejrzeć konfiguracje driverów po stronie aplikacji. W AWS i GCP często trzeba jawnie dodać parametr „require SSL/TLS”. W Azure można wymusić szyfrowanie na poziomie serwera (flagą), ale aplikacje i tak muszą umieć to obsłużyć.

Zarządzanie kluczami i sekretami (KMS, Key Vault, Secrets Manager, Secret Manager)

Hasła, tokeny i klucze API nie powinny leżeć w plikach konfiguracyjnych ani zmiennych środowiskowych bez ładu i składu. Każdy audyt infrastruktury chmurowej powinien zawierać przegląd mechanizmów zarządzania sekretami.

Główne usługi:

• AWS – Secrets Manager i SSM Parameter Store,
• Azure – Key Vault,
• GCP – Secret Manager.

Podczas audytu warto sprawdzić:

• czy sekrety są trzymane centralnie, czy „gdzie popadnie” (plik YAML w repo, ConfigMap bez szyfrowania),
• kto ma uprawnienia do odczytu poszczególnych sekretów (IAM na zasobach z sekretami),
• czy istnieje proces rotacji (np. przy odejściu pracownika, zmianie vendora, incydencie).

Dodatkowy element to integracja z workloadami:

• czy aplikacje pobierają sekrety w czasie startu z bezpiecznego źródła,
• czy używane są role/managed identities zamiast statycznych kluczy,
• czy logi i APM nie zawierają treści sekretów (maskowanie w logach).

Typowy problem: ktoś wkleja connection string z hasłem w zmienną środowiskową na portalu (Azure Portal/Console). Potem i tak dostaje się do tego pół firmy, bo rola „Contributor” ma wgląd w konfigurację. Tego typu „wygodne” skróty powinny zostać usunięte i zastąpione odniesieniem do sekretu w dedykowanej usłudze.

Klasyfikacja danych i polityki retencji

Sama technologia szyfrowania nie wystarczy, jeśli nie wiadomo, jakie dane gdzie leżą. Przy poważniejszym audycie przydaje się prosta, praktyczna klasyfikacja danych i powiązane z nią zasady przechowywania.

Elementy, które warto przeanalizować:

• czy organizacja ma kategorie danych (np. publiczne, wewnętrzne, poufne, wrażliwe),
• czy te kategorie są w jakikolwiek sposób odwzorowane w chmurze (tagi, nazwy bucketów, policy),
• jak wygląda retencja danych w storage i logach (ile, gdzie, jak długo).

Na poziomie technicznym:

• lifecycle policies dla storage obiektowego (przesuwanie do tańszych klas, kasowanie po czasie),
• retencja logów w CloudWatch/Cloud Logging/Log Analytics,
• retencja backupów baz danych i snapshotów dysków.

Efekt audytu powinien jasno pokazać, gdzie przechowywane są dane krytyczne (np. dane osobowe, dane finansowe) i jakie środki je chronią: szyfrowanie, ograniczenia sieciowe, kontrola dostępu, retencja. W praktyce często wychodzą na jaw stare, zapomniane snapshoty lub eksporty baz w bucketach „tymczasowych”, które nikt nie sprzątnął po projekcie migracji.

Logowanie, monitorowanie i reagowanie na incydenty w środowiskach AWS, Azure i GCP

Centralne logowanie zdarzeń: CloudTrail, Activity Log, Audit Logs

Bez pełnych logów trudno mówić o skutecznym audycie. Pierwszy krok to upewnienie się, że operacje w panelu i API są rejestrowane oraz archiwizowane poza zasięgiem zwykłych administratorów.

Podstawowe źródła logów:

• AWS – CloudTrail (management events, data events),
• Azure – Activity Log + Resource Logs w Log Analytics / Storage,
• GCP – Cloud Audit Logs (Admin, Data Access, System Event).

Checklist dla audytu:

• czy logi są włączone na poziomie organizacji/konta/subskrypcji/projektu,
• czy są wysyłane do centralnego, niekasowalnego miejsca (dedykowane konto/projekt/subskrypcja z ograniczonym dostępem),
• jaki jest czas retencji i czy odpowiada wymaganiom (np. 1–2 lata dla krytycznych zdarzeń),