Bezpieczeństwo informacji w chmurze – zgodność z ISO 27001 i NIS2

Migracja do chmury przestała być decyzją technologiczną — stała się decyzją compliance. Jeśli Twoja firma jest podmiotem kluczowym lub ważnym w rozumieniu znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa, dostawca chmury obliczeniowej jest osobną kategorią podmiotu tego systemu (art. 2 pkt 4e KSC, t.j. Dz. U. z 2026 r. poz. 20, z późn. zm. — po wdrożeniu NIS2 usługi chmurowe trafiły do załącznika sektorów objętych regulacją), a korzystanie z jego usług rodzi po Twojej stronie obowiązki z zakresu zarządzania ryzykiem łańcucha dostaw. Jeśli certyfikujesz się w ISO 27001, od edycji 2022 norma ma dedykowaną kontrolę chmurową A.5.23. A jeśli przetwarzasz dane osobowe — RODO nie zna słowa „chmura”: zna administratora, procesora, umowę powierzenia i transfer danych.

Ten przewodnik porządkuje bezpieczeństwo informacji w chmurze z trzech perspektyw naraz: normatywnej (ISO/IEC 27001 + ISO/IEC 27017), regulacyjnej (KSC/NIS2, RODO, a w finansach DORA) i praktycznej — z modelem współdzielonej odpowiedzialności, przygotowaniem do audytu, specyfiką pentestów środowisk chmurowych oraz porównaniem największych dostawców (AWS, Azure, Google Cloud, OVHcloud) pod kątem certyfikatów i lokalizacji danych.

Wymagania ISO 27017 (bezpieczeństwo chmury) i ISO 27001 – co się nakłada?

ISO/IEC 27001:2022 jest podstawą: klauzule 4–10 budują system zarządzania, a Załącznik A obejmuje 93 kontrole — w tym chmurowe, które w wersji 2022 wreszcie doczekały się własnej pozycji: A.5.23 „Bezpieczeństwo informacji przy korzystaniu z usług chmurowych” (obowiązki stron, ocena ryzyka, wymagania wobec dostawcy, monitorowanie, strategia wyjścia), uzupełnianej przez A.5.19–A.5.22 (relacje z dostawcami, ICT supply chain, umowy, monitoring usług) oraz kontrole techniczne A.8.x. Pełną mapę zabezpieczeń znajdziesz w naszym omówieniu Załącznik A ISO 27001.

ISO/IEC 27017 to rozszerzenie wytycznych (oparte na ISO/IEC 27002) dedykowane usługom chmurowym: doprecyzowuje kontrole o aspekty wirtualizacji, współdzielonej odpowiedzialności, separacji klientów, lokalizacji danych i roli agenta/administracji chmurowej. Nie jest normą certyfikowalną samodzielnie — funkcjonuje jako rozszerzenie zakresu certyfikatu ISO 27001 (akredytowane jednostki certyfikują „ISO 27001 z rozszerzeniem 27017″). Obok niej warto znać: ISO/IEC 27018 (ochrona danych osobowych w chmurze publicznej — kodeks praktyk dla procesorów), ISO/IEC 27701 (rozszerzenie systemu o zarządzanie prywatnością) oraz ISO/IEC 27799 (zdrowie). W praktyce przetargowej coraz częściej pada pytanie o nie wszystkie — a odpowiedź „mamy ISO 27001″ przestaje wystarczać.

Co się nakłada? Upraszczając: ISO 27001 mówi że masz zarządzać ryzykiem chmury i mieć to udokumentowane; ISO 27017 podpowiada jak — konkretnymi wytycznymi dla każdej strony relacji (dostawca/klient). Prawo dokłada własną warstwę: art. 28 RODO (umowa powierzenia — dostawca chmury to klasyczny procesor), rozdział V RODO (transfery poza EOG), art. 8 ust. 1 pkt 2 KSC (środki bezpieczeństwa obejmujące nabywanie, rozwój i eksploatację systemów — w tym usług chmurowych) oraz — dla podmiotów krytycznych — art. 6zzo–6zzq ustawy o zarządzaniu kryzysowym (dostawcy krytyczni: rejestr, ocena ryzyka min. raz w roku, plany awaryjne, możliwość zastąpienia dostawcy).

Kluczowe kontrole bezpieczeństwa w modelu IaaS/PaaS/SaaS

Niezbędne minimum kontroli — niezależnie od modelu:

• Tożsamość i dostęp: SSO z IdP organizacji, MFA obowiązkowe (A.5.17, A.8.5), role i najmniejsze przywileje (RBAC/IAM), proces joiner-mover-leaver spięty z HR, dostęp awaryjny (break-glass) pod kontrolą, zakaz kont współdzielonych.
• Dane: szyfrowanie w transmisji (TLS 1.2+) i w spoczynku (A.8.24), zarządzanie kluczami (klucze dostawcy vs własne — KMS/BYOK; przy danych wrażliwych rozważ HYOK), klasyfikacja i maskowanie (A.8.11), DLP na wyjściach (A.8.12), retencja i usuwanie — także po rozwiązaniu umowy (A.5.23 strategia wyjścia).
• Konfiguracja: baseline’y wg CIS Benchmarks, skanowanie posture (CSPM), zakaz publicznych bucketów/baz „domyślnie”, infrastruktura jako kod z przeglądem zmian (A.8.9, A.8.32).
• Monitorowanie i detekcja: logi audytowe z warstwy kontrolnej (odpowiedniki CloudTrail/Activity Log/Audit Logs) z retencją min. 12 miesięcy, alerty na operacje krytyczne (zmiany IAM, wyłączenie logów, masowy eksport), integracja z SIEM (A.8.15–A.8.16).
• Ciągłość działania: kopie międzyregionalne, testy odtworzenia (A.8.13–A.8.14), plany RTO/RPO spójne z analizą ryzyka (A.5.29–A.5.30).
• Łańcuch dostaw: marketplace i obrazy stron trzecich z weryfikacją, rejestr usług chmurowych w inwentarzu aktywów (A.5.9), ocena dostawcy przed migracją i okresowo (A.5.19–A.5.22; KSC/NIS2 supply chain; DORA art. 28–30 dla finansów).
• Shadow IT: polityka używania usług chmurowych (A.5.23) + wykrywanie nieautoryzowanych integracji — większość „incydentów chmurowych” zaczyna się od konta SaaS założonego bez wiedzy IT.

Rozkład akcentów między modelami: w IaaS Twoja jest cała warstwa systemu operacyjnego i wyżej (patche OS, hardening, sieci wirtualne); w PaaS — aplikacja, dane i konfiguracja dostępu; w SaaS — dane, konta, konfiguracja funkcji bezpieczeństwa i… polityka, bo reszta jest poza Twoją kontrolą operacyjną (dlatego w SaaS kluczowa jest weryfikacja certyfikatów i umowy, nie skany podatności).

Shared responsibility model – kto za co odpowiada w chmurze?

Shared responsibility (model współdzielonej odpowiedzialności) to fundament ochrony danych w chmurze: dostawca odpowiada za bezpieczeństwo chmury (infrastruktura: centra danych, sprzęt, hipernadzorca, usługi podstawowe), klient — za bezpieczeństwo w chmurze (dane, tożsamości, konfiguracja, aplikacje). Granica przesuwa się wraz z modelem usługi — i to właśnie niedopowiedzenia na tej granicy są źródłem większości głośnych wycieków („publiczny bucket” to nie wina AWS-a).

Obowiązki dostawcy vs obowiązki klienta – tabela podziału

Trzy wnioski praktyczne: (1) dane i tożsamości są Twoje w każdym modelu — „chmura jest bezpieczna” nie zwalnia z MFA i klasyfikacji danych; (2) zgodność prawna nie migruje: administratorem danych pozostajesz Ty, dostawca jest procesorem (art. 28 RODO), a odpowiedzialność za dobór środków należy do Ciebie (art. 24, art. 32 RODO); (3) w KSC/NIS2 i ustawie o zarządzaniu kryzysowym dostawca chmury ma własne obowiązki jako podmiot systemu, ale Twoje obowiązki obejmują zarządzanie ryzykiem tego dostawcy (umowy, oceny, plany awaryjne, możliwość zastąpienia — art. 6zzp u.z.k.; w finansach dodatkowo rejestr informacji i wymogi wobec dostawców ICT — art. 28 i nast. DORA).

Audyt bezpieczeństwa chmury – jak przygotować się na weryfikację?

ISO 27001 cloud (certyfikacja z zakresem obejmującym usługi chmurowe, ewentualnie z rozszerzeniem ISO 27017) przebiega jak standardowy audyt SZBI — z tą różnicą, że audytor zapyta o dowody specyficzne dla chmury. Jeśli migrujesz lub już jesteś w chmurze i czeka Cię audyt (certyfikacyjny, kliencki albo nadzorczy KSC), przygotuj poniższy komplet. O samym przebiegu audytu piszemy w przewodniku Audyt ISO 27001 – jak przygotować się na wizytę audytora.

Dokumentacja wymagana przez audytora: umowy, polityki, logi, raporty

1. Umowy i powierzenia: DPA (umowa powierzenia z art. 28 ust. 3 RODO) z każdym dostawcą chmurowym i SaaS; warunki główne (terms of service — tak, audytor potrafi zapytać, czy je przeczytaliście); klauzule transferowe (SCC/IDTA) i oceny transferów (rozdział V RODO, Transfer Impact Assessment) — przy regionach spoza EOG; dla podmiotów krytycznych: minimalne wymagania bezpieczeństwa wobec dostawców krytycznych (art. 6zzp u.z.k.).
2. Analiza ryzyka i DPIA: ryzyka usługi chmurowej w rejestrze (6.1.2), z uwzględnieniem A.5.23; przy danych osobowych na dużą skalę lub nowych technologiach — DPIA (art. 35 RODO).
3. Polityki i standardy: polityka korzystania z usług chmurowych (dozwolone usługi, klasy danych, regiony), baseline konfiguracji (CIS), standard IAM/MFA, polityka kluczy i szyfrowania, strategia wyjścia (exit plan: format eksportu, terminy usunięcia danych po rozwiązaniu umowy, alternatywny dostawca).
4. Rejestry: inwentarz aktywów i usług chmurowych (A.5.9) z właścicielami i klasami danych; rejestr dostawców z ocenami (A.5.19–A.5.20); rejestr kont i ról IAM z przeglądami uprawnień.
5. Dowody operacyjne: logi warstwy kontrolnej (retencja!), raporty z przeglądów konfiguracji (CSPM), wyniki skanów podatności obrazów/kontenerów, raporty z testów odtworzenia backupów, zapisy incydentów dotyczących chmury, potwierdzenia szkoleń.
6. Raporty dostawcy: aktualne certyfikaty (ISO 27001/27017/27018, zakres i ważność), raport SOC 2 Type II z sekcją CUEC (Complementary User Entity Responsibilities — obowiązki klienta wynikające z raportu; audytorzy uwielbiają pytać, czy wdrożyliście CUEC-y — większość firm ich nawet nie czyta), raporty pentestów dostawcy (jeśli udostępnia pod NDA), komunikaty o dostępności (status pages/SLA).

Testy penetracyjne środowiska chmurowego – specyfika i ograniczenia

Pentesty chmury rządzą się własnymi prawami (pełny przewodnik procesowy: Testy penetracyjne w ramach ISO 27001):

• Zakres = Twoja warstwa współdzielonej odpowiedzialności: aplikacje i API w chmurze, konfiguracja (IAM, polityki dostępu, storage), tożsamości, sieć wirtualna. Nie testujesz infrastruktury współdzielonej ani hipernadzorcory — to robi dostawca (i udostępnia wyniki w formie certyfikatów/SOC 2).
• Zasady dostawców: AWS, Azure i Google Cloud publikują polityki testów penetracyjnych — co do zasady testy własnych zasobów są dozwolone bez odrębnej zgody, o ile mieszczą się w akceptowalnym użyciu; zakazane są m.in. ataki DoS/DDoS, testy obciążające bez uzgodnienia i jakiekolwiek działania wobec zasobów innych klientów. Reguły bywają aktualizowane — przed każdym testem zweryfikuj aktualną politykę dostawcy i odnotuj to w Rules of Engagement.
• Specyfika techniczna: wektory chmurowe różnią się od klasycznych — przejęcie poświadczeń (klucze API w kodzie/repozytoriach!), eskalacja przywilejów przez role IAM, publicznie dostępne buckety, SSRF do metadanych instancji (IMDS), misconfiguracje serverless. Dlatego obok klasycznego pentestu aplikacji stosuje się cloud-specific assessment: przegląd konfiguracji wg CIS Benchmarks, analizę ścieżek ataku w IAM, skan wycieków sekretów (publiczne repozytoria, paste sites).
• Narzędzia i metodyka: skanery postura (CSPM), narzędzia open source do audytu kont chmurowych (klasy Prowler/ScoutSuite/CloudFox — używane legalnie wyłącznie na własnych kontach, na podstawie pisemnego upoważnienia; przypomnijmy ramy prawne: art. 267 i 269a Kodeksu karnego oraz „klauzule etyczne” art. 269b § 1a i art. 269c k.k.), plus klasyczne narzędzia web/API.
• Dowód dla audytora: raport z testów warstwy klienckiej + certyfikaty/SOC 2 dostawcy dla warstwy współdzielonej + oświadczenie o zakresie i ograniczeniach. Taki „dwuwarstwowy” zestaw zamyka zwykle pytanie o A.8.8/A.8.29 w kontekście chmury.

Dostawcy chmury w Polsce i UE – porównanie pod kątem compliance

Dla polskiego klienta kluczowe są trzy kryteria: certyfikacje (co realnie obejmują), regiony i lokalizacja danych (latencja, jurysdykcja, RODO-transfery) oraz instrumenty suwerenności (kontrola kluczy, granice danych, oferty sovereign). Stan na wrzesień 2026 r. — zestawienie orientacyjne, wymagające weryfikacji przed kontraktem (oferty zmieniają się szybciej niż ten artykuł):

Komentarze do cloud compliance:

• Lokalizacja ≠ pełna suwerenność. Region w Warszawie minimalizuje latencję i upraszcza RODO (dane w EOG), ale np. amerykańscy dostawcy podlegają prawu USA (FISA 702/CLOUD Act) — stąd rosnące znaczenie instrumentów typu EU Data Boundary, external/HYOK key management i ofert sovereign. Przy danych szczególnych kategorii (art. 9 RODO) i sektorach regulowanych analiza jurysdykcji to obowiązkowy element DPIA i oceny ryzyka dostawcy.
• Certyfikat dostawcy nie jest Twoim certyfikatem. ISO 27001 AWS-a nie pokrywa Twojej konfiguracji — audytor (i organ nadzoru) oceni Twój zakres odpowiedzialności. Certyfikaty dostawcy „dziedziczysz” tylko w warstwie infrastrukturnej (stąd model SOC 2 + CUEC).
• NIS2/KSC i łańcuch dostaw. Dostawcy chmury są podmiotami ważnymi/kluczowymi KSC (art. 2 pkt 4e; załącznik nr 2 — usługi chmury obliczeniowej), co w praktyce ułatwia due diligence (podlegają nadzorowi i obowiązkom incydentalnym). Po Twojej stronie zostaje ocena ryzyka dostawcy, umowa, plan awaryjny i możliwość wyjścia (A.5.23; art. 6zzo–6zzp u.z.k. dla podmiotów krytycznych; art. 28+ DORA dla finansów). W pracach na poziomie UE pozostaje projekt europejskiego schematu certyfikacji chmury EUCS (na podstawie aktu o cyberbezpieczeństwie, rozporządzenie (UE) 2019/881 — art. 48–49; pierwszy uchwalony schemat to EUCC — rozporządzenie wykonawcze (UE) 2024/482, dotyczący produktów ICT); do czasu jego przyjęcia punktem odniesienia pozostają ISO 27001/27017/27018, SOC 2, C5, CSA STAR i SecNumCloud.
• Kontekst lokalny. Firmy z Olsztyna i regionu warmińsko-mazurskiego — produkcyjne, spożywcze, medyczne, e-commerce — migrują do chmury równie szybko jak warszawskie; przy wdrożeniach ISO 27001 cloud („iso cloud Olsztyn” to rosnąca fraza w zapytaniach ofertowych) decyduje zwykle ekosystem: Microsoft-centric organizacje wybierają Azure Poland Central, dane-analityczne Google Cloud, a podmioty wrażliwe na jurysdykcję — OVHcloud lub konfiguracje hybrydowe. Więcej o zabezpieczaniu danych w chmurze w ujęciu procesowym piszemy w tekście Cloud security w kontekście ISO 27001 oraz w poradniku Jak chronić dane osobowe w chmurze.

Podsumowanie: chmura nagradza uporządkowanych

Bezpieczeństwo informacji w chmurze to nie zakup „bezpiecznego dostawcy”, lecz zarządzanie współdzieloną odpowiedzialnością: Twoje dane, tożsamości i konfiguracja — zawsze po Twojej stronie; infrastruktura — po stronie dostawcy, ale z Twoim obowiązkiem weryfikacji (certyfikaty, SOC 2 + CUEC, raporty testów). Ramy masz gotowe: ISO 27001 z kontrolą A.5.23 i rozszerzeniem ISO 27017, RODO z art. 28 i rozdziałem V, KSC/NIS2 z zarządzaniem ryzykiem łańcucha dostaw, a dla podmiotów krytycznych i finansowych — dodatkowe reżimy u.z.k. i DORA. Zacznij od inwentaryzacji usług chmurowych i klasyfikacji danych, domknij umowy i MFA, przeczytaj CUEC-y z SOC 2, przetestuj warstwę kliencką i napisz exit plan — a audyt chmury przestanie być loterią.

Zleć audyt bezpieczeństwa chmury
Przeprowadzimy audyt Twojego środowiska (AWS / Azure / Google Cloud / OVHcloud): konfiguracja wg CIS Benchmarks, ścieżki ataku w IAM, umowy i transfery RODO, zgodność z ISO 27001 (A.5.23, A.5.19–A.5.22) i wymogami KSC/NIS2. Otrzymasz raport z priorytetami i wycenę testów penetracyjnych warstwy klienckiej.

Skontaktuj się z nami

Name

Email

Phone

Wiadomość

Wyślij wiadomość

Źródła prawne i normatywne

1. Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (t.j. Dz. U. z 2026 r. poz. 20, z późn. zm.) — art. 2 pkt 4e; art. 8 ust. 1 pkt 2; załączniki nr 1 i 2.
2. Rozporządzenie (UE) 2016/679 (RODO) — art. 5; art. 24; art. 28 ust. 3; art. 32; art. 35; art. 44–49 (rozdział V); art. 9.
3. Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (t.j. Dz. U. z 2026 r. poz. 574 i 815) — art. 6zzo–6zzq; art. 6zt ust. 8.
4. Rozporządzenie (UE) 2022/2554 (DORA) — art. 26 ust. 3; art. 28 i nast.
5. Rozporządzenie (UE) 2019/881 (akt o cyberbezpieczeństwie) — art. 48–49; rozporządzenie wykonawcze Komisji (UE) 2024/482 (EUCC).
6. Kodeks karny (t.j. Dz. U. z 2025 r. poz. 383, z późn. zm.) — art. 267; art. 269a; art. 269b § 1a; art. 269c.
7. Normy: ISO/IEC 27001:2022 (A.5.9, A.5.17, A.5.19–A.5.23, A.8.5, A.8.9, A.8.11–A.8.16, A.8.24, A.8.29, A.8.32); ISO/IEC 27017:2015; ISO/IEC 27018:2019; ISO/IEC 27701:2025 (wyd. 2); CIS Benchmarks dla chmur; polityki testów penetracyjnych AWS/Azure/GCP (aktualne wersje u dostawców).

Certyfikacje, regiony i instrumenty suwerennościowe dostawców — stan na wrzesień 2026 r., wymagają weryfikacji przed decyzją kontraktową. Stan prawny na dzień 20 września 2026 r. Artykuł ma charakter informacyjny i nie stanowi porady prawnej.