Model współdzielonej odpowiedzialności w chmurze
Model współdzielonej odpowiedzialności określa, które elementy usługi chmurowej zabezpiecza i utrzymuje dostawca, a które pozostają zadaniem klienta. Dostawca odpowiada za bezpieczeństwo własnej infrastruktury i zarządzanych warstw usługi. Klient nadal odpowiada między innymi za dane, konta, uprawnienia, urządzenia końcowe, ustawienia oraz sposób użycia usługi. Granica przesuwa się od IaaS przez PaaS do SaaS, lecz nigdy nie znika — wiążący podział trzeba sprawdzić dla konkretnego produktu, konfiguracji i umowy.
Na czym polega model współdzielonej odpowiedzialności?
Własne centrum danych przypomina pełną odpowiedzialność za cały stos: od budynku, zasilania i sprzętu po system, aplikację, konta i informacje. W chmurze część tych warstw przejmuje dostawca. Zakres zależy przede wszystkim od modelu usługi IaaS, PaaS lub SaaS. W IaaS klient zachowuje kontrolę nad systemem operacyjnym i aplikacją. W PaaS dostawca utrzymuje także system oraz środowisko uruchomieniowe. W SaaS dostawca zarządza niemal całym stosem technicznym gotowej aplikacji, ale klient nadal decyduje o użytkownikach, dostępie, danych i konfiguracji własnego środowiska.
Najczęściej mówi się o bezpieczeństwie chmury, za które odpowiada dostawca, oraz bezpieczeństwie w chmurze, które wymaga działań klienta. To użyteczny skrót, lecz nie wystarcza do zarządzania usługą. Odpowiedzialność dotyczy również dostępności, kopii zapasowych, odtwarzania, kosztów, obsługi incydentów, zgodności, prywatności oraz zakończenia współpracy. Funkcja oferowana przez dostawcę nie oznacza, że została włączona, właściwie skonfigurowana i przetestowana przez klienta.
Model nie jest certyfikatem bezpieczeństwa ani automatycznym przeniesieniem ryzyka na dostawcę. Nie zwalnia organizacji z oceny informacji, obowiązków prawnych lub nadzoru nad zewnętrznym usługodawcą. Jest mapą granic technicznych i operacyjnych, którą należy przełożyć na architekturę, procedury i umowę. Ogólna tabela poniżej ułatwia rozpoczęcie tej pracy, ale dokumentacja konkretnego produktu ma zawsze pierwszeństwo.
On-premises, IaaS, PaaS i SaaS — tabela odpowiedzialności
Im bardziej zarządzana jest usługa, tym więcej technicznych warstw utrzymuje dostawca. Nie wszystkie obowiązki przesuwają się jednak w tym samym tempie. Dane i decyzje dostępowe pozostają po stronie klienta także wtedy, gdy korzysta on z gotowej aplikacji SaaS. Z kolei odpowiedzialność za centrum danych oraz fizyczne hosty przechodzi na dostawcę już w IaaS.
| Warstwa lub obszar | On-premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Dane, ich klasyfikacja i dozwolony sposób użycia | Klient | Klient | Klient | Klient |
| Tożsamości, użytkownicy, role i przyznawanie dostępu | Klient | Wspólnie | Wspólnie | Wspólnie |
| Urządzenia użytkowników i połączenie z usługą | Klient | Klient | Klient | Wspólnie |
| Aplikacja oraz konfiguracja biznesowa | Klient | Klient | Klient | Wspólnie |
| Środowisko uruchomieniowe i middleware | Klient | Klient | Dostawca | Dostawca |
| System operacyjny | Klient | Klient | Dostawca | Dostawca |
| Logiczne mechanizmy sieciowe | Klient | Klient | Wspólnie | Dostawca |
| Wirtualizacja i izolacja hostów | Klient | Dostawca | Dostawca | Dostawca |
| Serwery, sieć fizyczna i centrum danych | Klient | Dostawca | Dostawca | Dostawca |
Tabela jest modelem edukacyjnym, nie zapisem umownym. „Wspólnie” oznacza różne zadania obu stron. Dokładną granicę wyznaczają funkcje produktu, konfiguracja, dokumentacja, SLA i umowa.
Jak rozumieć poszczególne warstwy odpowiedzialności?
Dane, tożsamości i dostęp
Organizacja wie, jakie informacje przetwarza, kto powinien je widzieć i jak długo są potrzebne. Dlatego klient klasyfikuje dane, określa podstawę ich użycia, nadaje uprawnienia oraz reaguje na zmianę roli pracownika. Dostawca zabezpiecza mechanizmy platformy, lecz nie zna samodzielnie zasad biznesowych klienta. Nawet w SaaS trzeba wyznaczyć administratorów, włączyć MFA, ograniczyć role, usuwać nieaktywne konta i okresowo przeglądać dostęp.
Szyfrowanie także bywa obszarem wspólnym. Dostawca może szyfrować nośniki i transmisję, a klient wybierać ustawienia, zarządzać własnymi kluczami lub pilnować, aby sekret nie trafił do kodu. Informacja „dane są szyfrowane” nie odpowiada jeszcze na pytania: w jakich stanach, którym kluczem, kto ma do niego dostęp i jak przebiega odzyskanie po jego utracie.
Aplikacja i konfiguracja
W IaaS klient odpowiada za kod, zależności, konfigurację aplikacji i poprawki. W PaaS dostawca utrzymuje platformę, ale klient nadal zabezpiecza własny kod i sposób połączenia usług. W SaaS dostawca rozwija aplikację, natomiast klient ustawia tenant: zasady udostępniania, retencję, integracje, role administratorów i dozwolone funkcje. Błąd konfiguracji po stronie klienta może ujawnić dane, mimo że sama platforma działa zgodnie z projektem.
System, runtime i sieć
Maszyna wirtualna w IaaS nadal wymaga aktualizacji systemu gościa, ochrony usług, ograniczenia portów i monitoringu. Dostawca aktualizuje hiperwizor, ale zazwyczaj nie loguje się do systemu klienta, aby naprawić jego pakiety. W PaaS zarządzany system i runtime przechodzą na dostawcę; klient konfiguruje jednak dostęp aplikacji do sieci, baz i interfejsów. W SaaS kontrola sieci aplikacji leży zwykle po stronie dostawcy, podczas gdy klient chroni urządzenia i sesje użytkowników.
Dostępność, backup i odtwarzanie
SLA opisuje dostępność usługi dostawcy, lecz nie gwarantuje ciągłości całego procesu klienta. Dostawca może oferować strefy dostępności, replikację lub funkcję kopii. Klient wybiera architekturę, uruchamia funkcję, ustala retencję, chroni kopię przed usunięciem i testuje odtwarzanie według wymaganych RPO oraz RTO. W SaaS warto sprawdzić, czy standardowa retencja chroni przed omyłkowym usunięciem oraz czy możliwy jest niezależny eksport.
Trzy scenariusze współdzielonej odpowiedzialności w praktyce
Niezałatana maszyna wirtualna
Dostawca utrzymuje centrum danych, serwer i hiperwizor. Firma uruchamia na maszynie system oraz aplikację. Krytyczna poprawka systemu gościa nie została wdrożona i dochodzi do włamania. Awaria nie musi oznaczać naruszenia warstwy dostawcy: aktualizacja systemu gościa, konfiguracja zapory i monitoring należały do klienta. Macierz powinna wskazywać, kto śledzi podatności, w jakim czasie łata system i kto zatwierdza wyjątek.
Baza dostępna z publicznej sieci
Dostawca aktualizuje silnik i system zarządzanej bazy. Zespół klienta wybiera jednak reguły dostępu, konta oraz sposób uwierzytelnienia aplikacji. Jeśli błędna konfiguracja wystawi bazę do internetu, platforma może działać prawidłowo, a ryzyko powstaje w zakresie klienta. Wspólna odpowiedzialność oznacza tu bezpieczny mechanizm po stronie dostawcy i poprawny wybór ustawień po stronie klienta.
Plik udostępniony niewłaściwej osobie
Dostawca zabezpiecza aplikację, przechowywanie i transmisję. Użytkownik klienta wybiera odbiorcę, a administrator określa, czy wolno tworzyć publiczne łącza. Gdy pracownik udostępni dokument poza organizację, trzeba sprawdzić ustawienia tenantów, szkolenie, klasyfikację i logi. Odpowiedzialność dostawcy pojawi się natomiast wtedy, gdy zawiedzie kontrola, którą zobowiązał się utrzymywać.
Te przykłady nie służą automatycznemu przypisaniu winy. Incydent może mieć kilka przyczyn, a zakres odpowiedzialności może zmienić usługa zarządzana, wsparcie partnera albo indywidualna umowa. Służą one do zadania wcześniejszego pytania: kto wykona konkretne działanie, zanim wydarzy się problem?
Przykładowa macierz odpowiedzialności operacyjnej
Podział klient–dostawca jest dopiero pierwszym poziomem. Po stronie klienta zadanie może należeć do właściciela biznesowego, zespołu aplikacyjnego, administratorów platformy albo bezpieczeństwa. Poniższa macierz używa skrótów RACI: R wykonuje pracę, A odpowiada za jej wynik, C jest konsultowany, a I informowany. W jednej czynności powinien być jeden jasno wskazany właściciel A. Role dostawcy trzeba przepisać z dokumentacji i umowy, a nie przypisywać mu ich jednostronnie.
| Działanie | Właściciel usługi | Zespół aplikacyjny | Platforma / IT | Bezpieczeństwo | Dostawca |
|---|---|---|---|---|---|
| Klasyfikacja danych i dopuszczenie do chmury | A | R | C | C | I |
| Konfiguracja ról i najmniejszych uprawnień | A | R | R | C | I |
| Aktualizacja systemu gościa w IaaS | A | C | R | C | I |
| Aktualizacja zarządzanego runtime w PaaS | I | C | C | I | R / A* |
| Konfiguracja kopii i test odtworzenia | A | R | R | C | C* |
| Monitoring obciążenia i pierwsza reakcja | A | R | R | C | I / C* |
| Incydent w fizycznej platformie dostawcy | I | I | C | C | R / A* |
| Test eksportu i wykonanie planu wyjścia | A | R | R | C | C* |
* Rola dostawcy obowiązuje wyłącznie w zakresie uzgodnionym dla produktu i umowy. Macierz nie tworzy zobowiązań kontraktowych. W organizacji można dodać role prawne, ochrony danych, zakupów, ciągłości działania i partnera zarządzającego.
Macierz warto prowadzić na poziomie usługi lub obciążenia, nie wyłącznie całej platformy. Ten sam dostawca może oferować maszynę IaaS, bazę PaaS i aplikację SaaS z innymi granicami. Dla czynności krytycznych trzeba dopisać zastępstwo, termin, narzędzie, alert oraz dowód — na przykład raport zgodności konfiguracji, wynik testu odtworzenia albo zgłoszenie zamknięcia konta.
Jak zweryfikować zakres odpowiedzialności w dokumentacji i umowie?
Marketingowy diagram pokazuje zasadę, ale nie opisuje wszystkich wyjątków. Przed uruchomieniem produkcji należy przejść od ogólnego modelu do konkretnego SKU, regionu i konfiguracji. Pomagają dokumentacja usługi, warunki świadczenia, SLA, umowa powierzenia danych, wykaz podwykonawców, polityka wsparcia i procedura zakończenia. Jeżeli rozwiązanie dostarcza partner zarządzający, powstaje trzeci zakres odpowiedzialności, który również trzeba opisać.
| Obszar | Pytanie weryfikacyjne | Dowód lub dokument |
|---|---|---|
| Zakres usługi | Które komponenty, wersje i regiony obejmuje deklarowany podział? | Karta produktu, dokument odpowiedzialności, architektura i lista zasobów. |
| Aktualizacje | Kto łata host, system gościa, runtime, bibliotekę i aplikację oraz w jakim terminie? | Dokumentacja cyklu aktualizacji, polityka podatności i wewnętrzny harmonogram. |
| Tożsamość | Kto tworzy konta uprzywilejowane, przegląda dostęp i reaguje na odejście pracownika? | Model ról, logi, procedura joiner–mover–leaver i raport przeglądu dostępów. |
| Dane i klucze | Gdzie są dane, kopie, logi i metadane oraz kto kontroluje klucze? | Warunki lokalizacji, opis szyfrowania, polityka kluczy i lista podprocesorów. |
| Dostępność | Co mierzy SLA, jakie są wyłączenia i czy rekompensata pokrywa skutek biznesowy? | SLA, architektura strefowa, wymagania RPO/RTO oraz protokół testu awaryjnego. |
| Incydent | Kto wykrywa, zgłasza i zabezpiecza dowody, a jak przebiega wspólna eskalacja? | Plan reagowania, czasy powiadomień, kontakty 24/7 i zasady dostępu do logów. |
| Zakończenie | Jak wyeksportować dane i konfigurację, ile jest na to czasu i kiedy kopie są usuwane? | Plan wyjścia, formaty eksportu, koszty transferu i potwierdzenie usunięcia. |
Nie każda informacja z dokumentacji staje się automatycznie gwarancją umowną. Trzeba ustalić hierarchię dokumentów, sposób informowania o zmianie usługi i obowiązującą wersję warunków. Gdy wymaganie jest krytyczne, powinno mieć mierzalne kryterium odbioru, właściciela oraz ścieżkę eskalacji. W środowisku regulowanym ocenę należy połączyć z właściwymi przepisami i nadzorem; ogólny model nie jest poradą prawną ani potwierdzeniem zgodności.
Jak wdrożyć model współdzielonej odpowiedzialności w organizacji?
Dobrym momentem na przygotowanie macierzy jest ocena przed migracją. Nie należy czekać do pierwszego incydentu. Zadania dotyczące odpowiedzialności można włączyć do checklisty migracji do chmury: przed startem produkcyjnym potwierdzić konta, logi, kopie, poprawki, eskalację i możliwość wyjścia. Po wdrożeniu macierz powinna być częścią dokumentacji operacyjnej oraz regularnych przeglądów dostawcy.
- Każda używana usługa ma wskazany model, właściciela biznesowego i technicznego.
- Ogólne obszary „wspólne” zostały rozbite na jednoznaczne czynności.
- Znane są granice backupu, retencji, odtwarzania i odpowiedzialności za test.
- Procedura incydentowa zawiera kontakty, czasy reakcji i sposób uzyskania logów.
- Uprawnienia uprzywilejowane są ograniczone, monitorowane i okresowo przeglądane.
- Plan wyjścia obejmuje dane, konfigurację, zależności, terminy, koszt i usunięcie kopii.
- Macierz ma datę przeglądu i jest aktualizowana po istotnej zmianie usługi.
Najczęstsze pytania o współdzieloną odpowiedzialność
Co to jest model współdzielonej odpowiedzialności?
To sposób opisania podziału zadań między dostawcę chmury a klienta. Dostawca utrzymuje warstwy objęte usługą, a klient zarządza elementami, które kontroluje — między innymi danymi, tożsamościami, dostępem i konfiguracją. Dokładny zakres zależy od produktu i umowy.
Czy dostawca chmury odpowiada za bezpieczeństwo moich danych?
Dostawca odpowiada za zabezpieczenia własnej infrastruktury i zarządzanych mechanizmów zgodnie z dokumentacją oraz umową. Klient nadal odpowiada za klasyfikację danych, uprawnienia, dozwolony sposób użycia, wiele ustawień szyfrowania i reakcję na działania własnych użytkowników.
Czy w SaaS cała odpowiedzialność przechodzi na dostawcę?
Nie. Dostawca SaaS utrzymuje aplikację i jej zaplecze, lecz klient zarządza użytkownikami, rolami, treścią, integracjami oraz ustawieniami dostępnymi w swoim tenancie. Klient musi też ocenić, czy produkt i umowa odpowiadają jego wymaganiom.
Kto aktualizuje system operacyjny w IaaS?
Dostawca aktualizuje warstwy fizyczne i wirtualizację, ale system gościa maszyny wirtualnej zwykle aktualizuje klient. Wyjątkiem może być dodatkowa usługa zarządzana. Zakres trzeba potwierdzić w dokumentacji produktu i umowie z dostawcą lub partnerem.
Kto odpowiada za backup w chmurze?
To zależy od produktu. Dostawca może utrzymywać odporność platformy albo oferować mechanizm kopii, a klient wybiera zakres, retencję i ochronę oraz testuje odtwarzanie. Replikacja dostawcy nie zawsze jest kopią spełniającą wymagania biznesowe klienta.
Czym różni się odpowiedzialność od zgodności?
Odpowiedzialność wskazuje, kto wykonuje dane zadanie. Zgodność oznacza spełnienie konkretnych wymagań prawnych, regulacyjnych, umownych lub wewnętrznych. Certyfikaty dostawcy mogą wspierać ocenę, ale nie dowodzą automatycznie zgodności konfiguracji i procesu klienta.
Czy jeden diagram odpowiedzialności wystarczy dla całej platformy?
Nie. Jedna platforma może łączyć IaaS, PaaS, SaaS i usługi partnerów. Dla krytycznych obciążeń trzeba sprawdzić zakres konkretnego produktu, regionu, konfiguracji i wsparcia, a następnie zbudować macierz czynności dla zespołów klienta i dostawcy.
Jak często aktualizować macierz odpowiedzialności?
Co najmniej po istotnej zmianie architektury, produktu, konfiguracji, zespołu, partnera, umowy lub wymagań. Dodatkowo warto ustalić cykliczny przegląd i wykorzystywać wnioski z testów, incydentów oraz zmian dokumentacji dostawcy.
Źródła
- NIST SP 800-145 — definicja chmury i modeli IaaS, PaaS oraz SaaS
- NIST SP 500-292 — architektura referencyjna i role w ekosystemie chmurowym
- AWS — Shared Responsibility Model
- Microsoft Learn — Shared responsibility in the cloud
- Google Cloud Architecture Framework — shared responsibility and shared fate
- CISA — Cloud Security Technical Reference Architecture
Źródła dostawców opisują ich własne usługi. Zestawiono je z neutralnymi definicjami NIST; nie jest to rekomendacja konkretnej platformy. Stan i odsyłacze zweryfikowano 28 sierpnia 2026 r.