Dane i operacje: suwerenność w praktyce technicznej

W dyskusji o suwerenności chmurowej coraz wyraźniej widać, że sama lokalizacja infrastruktury czy zapisy kontraktowe nie wystarczają. O tym, kto naprawdę kontroluje dane, decydują nie tylko struktury właścicielskie i jurysdykcja, ale również konkretne mechanizmy techniczne, które działają na najniższym poziomie systemu.

Właśnie tutaj kluczową rolę odgrywają SOV-3 (Data Sovereignty) oraz SOV-4 (Operational Sovereignty) – obszary Cloud Sovereignty Framework, które przekładają pojęcie suwerenności na architekturę danych i operacji.

SOV-3: dane pod realną, a nie umowną kontrolą klienta

W kontekście Cloud Sovereignty Framework zasadnicze pytanie brzmi: czy klient ma wyłączną, efektywną kontrolę kryptograficzną nad swoimi danymi?

Nie chodzi wyłącznie o fakt, że dane są szyfrowane. Znaczenie ma to:

kto posiada klucze kryptograficzne,
kto może je rotować, unieważniać lub odzyskiwać,
czy dostawca ma jakąkolwiek techniczną możliwość dostępu do kluczy kryptograficznych w postaci jawnej.

Model, w którym dostawca „zarządza szyfrowaniem w imieniu klienta”, rzadko spełnia wymagania SEAL-3, a praktycznie nigdy SEAL-4. Kontrola nad kluczami oznacza bowiem wprost kontrolę nad danymi – niezależnie od deklarowanej polityki bezpieczeństwa.

SEAL-3 i SEAL-4: co naprawdę oznaczają w kontekście danych

SEAL-3 oznacza, że:

dane są szyfrowane w sposób ciągły (w spoczynku, w tranzycie, a często także w trakcie przetwarzania),
klient ma realny wpływ na cykl życia kluczy kryptograficznych,
dostęp operacyjny dostawcy jest technicznie ograniczony i podlega kontroli.

SEAL-4 idzie o krok dalej:

tylko klient ma możliwość użycia kluczy do odszyfrowania danych,
dostawca infrastruktury nie dysponuje żadnym mechanizmem „awaryjnego” dostępu,
nawet presja prawna lub operacyjna nie umożliwia osobom trzecim uzyskania dostępu do danych.

Na tym poziomie suwerenność przestaje być pojęciem prawnym, a staje się cechą samego systemu.

SOV-4: suwerenność operacyjna, czyli kto faktycznie wykonuje operacje

SOV-4 rozszerza perspektywę z danych na całość operacji technicznych:

zarządzanie tożsamościami i uprawnieniami,
wykonywanie operacji administracyjnych,
reagowanie na incydenty,
monitoring i audyt.

Z punktu widzenia frameworku suwerenność operacyjna nie istnieje, jeśli:

klient nie ma pełnej widoczności, kto, kiedy i w jakim zakresie ingerował w środowisko.
dostęp uprzywilejowany jest scentralizowany poza UE,
kluczowe operacje realizują podmioty podlegające jurysdykcjom państw trzecich,

Realizacja SOV-3 i SOV-4 w praktyce

W Oktawave suwerenność danych i operacji nie jest efektem pojedynczego mechanizmu, lecz zestawu rozwiązań i praktyk architektonicznych, które wzmacniają kontrolę klienta nad środowiskiem chmurowym i przetwarzanymi danymi.

Zaawansowane zarządzanie kluczami kryptograficznymi (Cloud Keys / vHSM/KMS)
Zapewniamy rozwiązania kryptograficzne, które umożliwiają zarządzanie kluczami szyfrującymi i operacjami szyfrowania danych. Pozwala to kontrolować cykl życia kluczy i operacje kryptograficzne bez konieczności ręcznego wdrażania własnych mechanizmów oraz znacząco podnosi odporność środowiska na nieautoryzowany dostęp. Dodatkowo prace nad wirtualnym modułem bezpieczeństwa (vHSM) i systemem zarządzania kluczami (KMS) w ramach projektu Next Gen Cloud mają zapewnić bezpieczne i skalowalne zarządzanie kluczami bez fizycznych urządzeń HSM.

Szyfrowanie i ochrona danych w całym cyklu życia
Usługi chmurowe Oktawave wykorzystują najlepsze praktyki szyfrowania danych zarówno w spoczynku, jak i w trakcie transmisji oraz przetwarzania. Infrastruktura i standardy bezpieczeństwa, potwierdzone certyfikatami takimi jak ISO/IEC 27001, ISO/IEC 27017 i CSA STAR, zapewniają zgodne z branżowymi normami podejście do ochrony danych w chmurze.

Niezależne zarządzanie tożsamościami i dostępami
Platforma pozwala na precyzyjne zarządzanie politykami dostępu, rolami i uprawnieniami uprzywilejowanymi, dając pełną kontrolę nad tym, kto i w jakim zakresie może wykonywać operacje administracyjne i techniczne w środowisku chmurowym.

Transparentne monitorowanie i pełna audytowalność operacji
W wyniku działań realizowanych w ramach Next Gen Cloud działania związane z operacjami na danych, kluczach czy konfiguracjach będą rejestrowane i dostępne do audytu. Taka transparentność jest kluczowa dla SEAL-3 i SEAL-4, ponieważ audyt stanowi integralny element nie tylko bezpieczeństwa, ale i rozliczalności operacji w chmurze.

Bezpieczeństwo infrastruktury i zgodność z normami
Dane przechowywane są w centrach danych na terenie Polski, spełniających wysokie standardy bezpieczeństwa i zgodne z regulacjami prawnymi. Certyfikaty branżowe oraz zgodność z Komunikatem KNF dodatkowo potwierdzają, że infrastruktura Oktawave została zaprojektowana tak, aby umożliwić kontrolę klienta nad środowiskiem i jego zasobami danych.

Suwerenność jako właściwość architektury

SOV-3 i SOV-4 pokazują, że suwerenność chmurowa nie może opierać się wyłącznie na zaufaniu do dostawcy. Musi wynikać z architektury, w której brak dostępu jest stanem domyślnym, kontrola kryptograficzna pozostaje po stronie klienta, a operacje są transparentne i rozliczalne.

W kolejnych obszarach Cloud Sovereignty Framework te same zasady będą pojawiać się w innych kontekstach – zawsze jako efekt świadomych decyzji projektowych, a nie deklaracji.

FAQ

1. Czym jest SOV-3 (Data Sovereignty) w Cloud Sovereignty Framework?
SOV-3 odnosi się do realnej kontroli nad danymi, w szczególności do tego, kto posiada i kontroluje klucze kryptograficzne. Ocenia, czy dostawca ma techniczną możliwość dostępu do danych w postaci jawnej oraz czy klient ma wyłączną kontrolę nad szyfrowaniem.

2. Czy szyfrowanie danych wystarcza do spełnienia SOV-3?
Nie. Sam fakt szyfrowania danych nie jest wystarczający. Kluczowe znaczenie ma to, kto zarządza kluczami kryptograficznymi, kto może je rotować lub odzyskiwać oraz czy dostawca infrastruktury ma możliwość ich użycia.

3. Co oznacza „efektywna kontrola kryptograficzna”?
Efektywna kontrola kryptograficzna oznacza, że tylko klient może użyć kluczy do odszyfrowania danych. Dostawca nie posiada technicznego ani operacyjnego mechanizmu dostępu do danych w postaci jawnej.

4. Czym różni się SEAL-3 od SEAL-4 w kontekście danych?
SEAL-3 zakłada silne szyfrowanie i ograniczony, kontrolowany dostęp operacyjny dostawcy. SEAL-4 oznacza pełną wyłączność klienta – tylko on ma możliwość użycia kluczy kryptograficznych, a dostawca nie posiada żadnego mechanizmu „awaryjnego” dostępu.

5. Czy dostawca może zarządzać kluczami „w imieniu klienta”?
W modelu zgodnym z SEAL-3 lub SEAL-4 dostawca nie powinien posiadać kontroli nad kluczami. Zarządzanie kluczami przez dostawcę znacząco obniża poziom suwerenności danych i zwykle uniemożliwia osiągnięcie SEAL-4.

6. Czym jest SOV-4 (Operational Sovereignty)?
SOV-4 dotyczy suwerenności operacyjnej, czyli tego, kto wykonuje operacje techniczne w środowisku chmurowym. Obejmuje zarządzanie tożsamościami, dostęp uprzywilejowany, reakcję na incydenty, monitoring oraz audyt.

7. Czy audyt jest wymagany do spełnienia SOV-4?
Tak. Pełna audytowalność operacji jest warunkiem suwerenności operacyjnej. Każda operacja powinna być rejestrowana, możliwa do prześledzenia i odporna na manipulację.

8. Jak HSM wpływa na suwerenność danych?
Dedykowane moduły HSM zlokalizowane w UE zapewniają, że klucze kryptograficzne pozostają poza zasięgiem dostawcy infrastruktury oraz jurysdykcji państw trzecich, co jest kluczowe dla SOV-3 i SEAL-4.

9. Czy suwerenność operacyjna oznacza brak wsparcia ze strony dostawcy?
Nie. Oznacza, że wsparcie operacyjne jest realizowane w sposób kontrolowany, audytowalny i zgodny z jurysdykcją UE, bez nieograniczonego dostępu uprzywilejowanego.

10. Czy lokalizacja data center w UE wystarcza do spełnienia SOV-3 i SOV-4?
Nie. Lokalizacja infrastruktury to warunek konieczny, ale niewystarczający. Kluczowe są mechanizmy techniczne: kontrola kluczy, zarządzanie tożsamościami, dostęp uprzywilejowany i audyt.

11. Jak zamawiający mogą weryfikować SOV-3 i SOV-4 w przetargach?
Poprzez wymagania dotyczące:

wyłącznej kontroli kluczy kryptograficznych,
stosowania HSM w UE,
niezależnego zarządzania tożsamościami,
pełnej audytowalności operacji,
ograniczenia dostępu uprzywilejowanego dostawcy.

12. Dlaczego SOV-3 i SOV-4 są kluczowe dla wysokich poziomów SEAL?
Ponieważ bez realnej kontroli nad danymi i operacjami suwerenność pozostaje deklaratywna. SOV-3 i SOV-4 przekładają wymagania prawne i regulacyjne na mierzalne cechy architektury systemu.

Ostatnie wpisy