Izolacja wielodostępna w obronnym SaaS: oddzielanie niejawnych klientów we współdzielonej infrastrukturze

Platformy obronnego SaaS stają w obliczu strukturalnego napięcia, którego nie zna cywilne oprogramowanie wielodostępne. Komercyjny dostawca SaaS martwi się o logiczną separację danych między klientami, aby zapobiec przypadkowemu ujawnieniu. Dostawca obronnego SaaS musi osiągnąć znacznie silniejszą gwarancję: że dane należące do jednego niejawnego najemcy są dowodliwie nieosiągalne dla innego najemcy, nawet jeśli atakujący przejął kontrolę nad kodem warstwy aplikacji lub uzyskał poświadczenia administratora. Język regulacyjny jest rygorystyczny: nieuprawnione ujawnienie danych SECRET niesprawdzonemu najemcy nie jest incydentem prywatności, lecz zdarzeniem wycieku o konsekwencjach prawnych i operacyjnych. Ten artykuł analizuje, jak izolacja wielodostępna jest projektowana, wdrażana i wykazywana w platformach obronnego SaaS, które obsługują najemców na różnych poziomach klauzuli tajności, o różnych wymaganiach rezydencji danych i niezależnych granicach akredytacji, w ramach niejawnej infrastruktury chmurowej opartej na Kubernetes.

Dlaczego wielodostępność jest złożona, gdy najemcy mają różne poziomy klauzuli tajności

Architektura wielodostępna w oprogramowaniu komercyjnym jest przede wszystkim decyzją ekonomiczną: współdzielenie zasobów obliczeniowych, bazy danych i nakładu operacyjnego między klientami obniża koszt dostarczania na klienta. W obronnym SaaS ekonomia wciąż ma znaczenie, ale wymagania izolacji narzucone przez klauzulę tajności wprowadzają ograniczenia, których komercyjne wzorce wielodostępne nie są w stanie spełnić od razu. Gdy dwaj najemcy działają na różnych poziomach klauzuli tajności, powiedzmy jeden na SECRET, a drugi na UNCLASSIFIED, nie mogą współdzielić silnika bazy danych, puli planowania kontenerów ani kryptograficznej przestrzeni nazw kluczy, ponieważ każda z tych współdzielonych warstw mogłaby stać się kanałem nieuprawnionego transferu danych, czy to przez bezpośrednią błędną konfigurację zapytań, ataki czasowe kanałem bocznym, czy przejęte narzędzia operatorskie.

Różnica poziomów klauzuli tajności nie jest jedynym czynnikiem komplikującym. Nawet najemcy na tym samym poziomie klauzuli tajności mogą mieć niezgodne wymagania wymuszające silną izolację: różne krajowe przepisy o rezydencji danych, różne reguły dotyczące retencji dzienników i dostępu audytowego, różne uprawnione populacje użytkowników oraz różne zatwierdzone zestawy szyfrów. Najemca brytyjskiego Ministerstwa Obrony i najemca amerykańskiego Departamentu Obrony mogą obaj działać na poziomie RESTRICTED/SENSITIVE, lecz na mocy umowy dwustronnej mieć zakaz przetwarzania swoich danych na tym samym sprzęcie fizycznym. Model izolacji musi zatem być projektowany w odniesieniu do macierzy atrybutów najemcy: poziomu klauzuli tajności, jurysdykcji krajowej, organu audytowego i zatwierdzonego materiału kryptograficznego, a nie prostego podziału wysoki/niski.

Ramy regulacyjne podnoszą stawkę. W ramach takich struktur jak amerykański Cloud Computing Security Requirements Guide Departamentu Obrony oraz brytyjskie wytyczne Secure by Design, system, który twierdzi, że izoluje niejawnych najemców, musi wykazać izolację poprzez udokumentowane kontrole, niezależne testowanie i ciągłe monitorowanie, a nie jedynie ją deklarować. Urzędnik autoryzujący poprosi o dowody: przechwycenia ruchu sieciowego pokazujące brak przepływów między najemcami, dzienniki usługi zarządzania kluczami pokazujące brak użycia kluczy między najemcami oraz dzienniki zapytań bazy danych pokazujące brak zbiorów wyników między najemcami. Wybory architektoniczne, które utrudniają wytworzenie tych dowodów, nie są tylko technicznie niewygodne; są blokadami akredytacji.

Strategie izolacji bazy danych: schemat-na-najemcę, baza-na-najemcę i instancja-na-najemcę

Warstwa bazy danych jest miejscem, w którym powstaje większość awarii izolacji wielodostępnej. Istnieją trzy wzorce, a właściwy wybór zależy od wymagań klauzuli tajności i audytu populacji najemców. Schemat-na-najemcę umieszcza tabele każdego najemcy w osobnym schemacie w obrębie pojedynczej instancji silnika bazy danych. Kontrola dostępu jest egzekwowana przez role bazy danych ograniczone do każdego schematu, a polityki zabezpieczeń na poziomie wierszy zapewniają wtórną warstwę egzekwowania. Ten wzorzec ma najniższy nakład operacyjny (jeden silnik bazy danych do łatania, monitorowania i tworzenia kopii zapasowych) i jest właściwy, gdy wszyscy najemcy współdzielą ten sam poziom klauzuli tajności, a wymóg izolacji jest logiczny, a nie fizyczny. Słabością jest to, że błędnie skonfigurowana rola, podatność na eskalację uprawnień bazy danych lub zapytanie omijające politykę zabezpieczeń na poziomie wierszy może ujawnić dane między najemcami. W środowiskach niejawnych, gdzie zdarzenie wycieku niesie poważne konsekwencje, poleganie wyłącznie na logicznej izolacji na poziomie schematu jest trudną pozycją do obronienia wobec urzędnika autoryzującego.

Baza-na-najemcę przydziela dedykowaną instancję bazy danych każdemu najemcy, ale pozwala tym instancjom działać na współdzielonej infrastrukturze obliczeniowej. Proces silnika bazy danych jest izolowany na poziomie systemu operacyjnego, więc błędnie skonfigurowany schemat lub przejęte poświadczenie aplikacji nie może dotrzeć do danych innego najemcy bez osobnej eskalacji uprawnień na poziomie OS. Ten wzorzec znacząco redukuje powierzchnię ataku między najemcami i jest minimalnym opłacalnym modelem izolacji dla obronnego SaaS obsługującego najemców na różnych poziomach klauzuli tajności. Koszt operacyjny jest proporcjonalny do liczby najemców: każda instancja bazy danych wymaga własnego harmonogramu kopii zapasowych, konfiguracji monitorowania, przepływu migracji schematu i puli połączeń. Przy dziesiątkach najemców jest to wykonalne dzięki dobrze zaprojektowanej automatyzacji platformy; przy setkach wymaga warstwy abstrakcji bazy danych jako usługi, aby utrzymać nakład operacyjny w ryzach.

Instancja-na-najemcę posuwa separację dalej, dedykując nie tylko proces bazy danych, ale cały węzeł obliczeniowy obciążeniom pojedynczego najemcy. Jest to wymagane, gdy dokumentacja akredytacyjna najemcy żąda separacji fizycznej, gdy czasowe kanały boczne między najemcami stanowią wiarygodny model zagrożenia lub gdy dane najemcy nie mogą nigdy przechodzić przez sieć współdzieloną z innymi najemcami. Kosztem jest pełny rachunek infrastruktury per najemca: dedykowane węzły, dedykowana pamięć masowa, w niektórych konfiguracjach dedykowany sprzęt sieciowy. Dla najemców o najwyższej klauzuli tajności ten koszt nie podlega negocjacjom; wymóg bezpieczeństwa napędza architekturę, a nie ekonomia. Platformy obsługujące mieszankę poziomów klauzuli tajności często wdrażają model warstwowy: schemat-na-najemcę dla UNCLASSIFIED, baza-na-najemcę dla SECRET, instancja-na-najemcę dla TS/SCI, z zautomatyzowanymi potokami udostępniania, które budują właściwą warstwę z pliku konfiguracyjnego wdrażania najemcy.

Izolacja przestrzeni nazw Kubernetes: RBAC, polityki sieciowe i limity zasobów per najemca

Orkiestracja kontenerów wprowadza własny zestaw wektorów narażenia między najemcami, których sama izolacja bazy danych nie adresuje. W klastrze Kubernetes pod w jednej przestrzeni nazw może domyślnie wysyłać ruch sieciowy do podów w dowolnej innej przestrzeni nazw, wyświetlać zasoby całego klastra, jeśli jego konto usługi ma nadmierne uprawnienia, oraz zużywać CPU i pamięć całego klastra, dopóki nie zagłodzi sąsiadujących obciążeń. Dla platformy obronnego SaaS żadne z tych domyślnych ustawień nie jest akceptowalne. Postawa izolacji musi być stosowana jako obowiązkowa linia bazowa w momencie udostępniania klastra, egzekwowana przez kontrolery dopuszczania, które odrzucają niezgodne definicje obciążeń, oraz walidowana w sposób ciągły przez silnik polityk, który ostrzega o dryfowaniu konfiguracji.

Polityka RBAC dla wielodostępnego obronnego Kubernetes zaczyna się od zasady, że konta usług każdego najemcy mają domyślnie zerową widoczność między przestrzeniami nazw. Role ograniczone do przestrzeni nazw są preferowane nad rolami klastra; powiązania cluster-admin są zabronione poza dedykowaną przestrzenią nazw zarządzania operatora platformy. Zasoby NetworkPolicy wdrażają postawę domyślnej odmowy w każdej przestrzeni nazw najemcy: brak ruchu przychodzącego i wychodzącego, chyba że jawnie dozwolony przez regułę polityki. Dozwolone przepływy są wąskie: pod aplikacji najemcy może komunikować się z własnym podem bazy danych, współdzielonym kontrolerem ruchu przychodzącego i punktem końcowym usługi zarządzania kluczami, i niczym więcej. Zasady architektury sieciowej zero zaufania odwzorowują się bezpośrednio na ten model: każdy przepływ ruchu jest weryfikowany, niczemu nie ufa się domyślnie tylko dlatego, że pochodzi z wnętrza granicy klastra.

Obiekty ResourceQuota uniemożliwiają pojedynczemu najemcy wywołanie stanu odmowy usługi wobec innych najemców poprzez zużycie nieproporcjonalnych zasobów klastra. Każda przestrzeń nazw otrzymuje limity na żądanie i limit CPU, żądanie i limit pamięci, pojemność roszczeń o woluminy trwałe oraz liczbę uruchomionych podów. Obiekty LimitRange ustawiają domyślne żądania zasobów na podach, które ich jawnie nie deklarują, zapobiegając obejściu systemu limitów przez nieograniczone obciążenia. Dla niejawnych obciążeń skażenia węzłów (taints) i tolerancje podów rozszerzają izolację na fizyczną warstwę planowania: węzły dedykowane najemcy na poziomie SECRET noszą skażenie, które uniemożliwia planowanie na nich podów UNCLASSIFIED, a specyfikacje podów najemcy SECRET noszą odpowiadającą tolerancję. Połączenie RBAC przestrzeni nazw, NetworkPolicy, ResourceQuota i skażeń węzłów daje warstwowy model izolacji, który jest audytowalny; każda warstwa jest udokumentowana, testowalna i niezależnie weryfikowalna.

Izolacja kluczy szyfrujących: osobne hierarchie kluczy dla każdego niejawnego najemcy

Szyfrowanie jest kontrolą, która sprawia, że izolacja danych obowiązuje, nawet jeśli izolacja na warstwie infrastruktury zawiedzie. Jeśli dane najemcy SECRET są szyfrowane kluczem, do którego mają dostęp tylko uprawnione procesy tego najemcy, to błędnie skonfigurowana polityka sieciowa lub proces, który wymknął się z kontenera, nie może odczytać danych, nawet jeśli uzyska dostęp do surowych bajtów pamięci masowej. Ta gwarancja wymaga, aby klucze szyfrujące każdego najemcy były zarządzane w kryptograficznej przestrzeni nazw niedostępnej dla innych najemców, nie tylko poprzez politykę na warstwie aplikacji, ale poprzez własne egzekwowanie kontroli dostępu przez usługę zarządzania kluczami.

Praktyczna implementacja wykorzystuje hierarchiczną strukturę kluczy. U korzenia znajduje się klucz szyfrujący klucze (KEK) specyficzny dla najemcy, przechowywany w partycji sprzętowego modułu bezpieczeństwa (HSM) lub przestrzeni nazw usługi zarządzania kluczami ograniczonej do kont usług tego najemcy. KEK opakowuje zestaw kluczy szyfrujących dane (DEK) używanych przez aplikację do szyfrowania określonych kategorii danych: jeden DEK dla rekordów operacyjnych, jeden dla dzienników audytowych, jeden dla załączników i tak dalej. DEK są przechowywane zaszyfrowane obok danych, które chronią; mogą być rozpakowane tylko przez proces, któremu przyznano dostęp do KEK najemcy. Jeśli atakujący przejmie pojedynczy DEK, może odszyfrować tę kategorię danych. Jeśli przejmie KEK, może potencjalnie odszyfrować wszystkie dane najemcy, ale nie może go użyć do uzyskania dostępu do danych innego najemcy, ponieważ KEK innego najemcy znajduje się w osobnej partycji HSM lub przestrzeni nazw zarządzania kluczami z całkowicie niezależnymi politykami dostępu. Środowiska poufnego przetwarzania rozszerzają ten model, chroniąc samą operację rozpakowywania DEK wewnątrz sprzętowo weryfikowanego zaufanego środowiska wykonawczego.

Polityka rotacji kluczy jest równie ważna jak struktura kluczy. Najemca, którego KEK nie był rotowany od dwóch lat, ma rozszerzający się promień rażenia: każde poświadczenie, które zostało przejęte w dowolnym momencie ostatnich dwóch lat, potencjalnie wciąż przyznaje dostęp do wszystkich danych zaszyfrowanych pod tym KEK. Platformy obronnego SaaS powinny egzekwować zautomatyzowaną rotację KEK według harmonogramu określonego przez organ klauzuli tajności najemcy (zazwyczaj corocznie dla SECRET, częściej dla wyższych klauzul) i zapewniać ślad audytowy rotacji widoczny podczas przeglądów akredytacyjnych. Samo zdarzenie rotacji musi być rejestrowane w strumieniu audytowym najemcy, opatrzone znacznikiem czasu i przypisane do zautomatyzowanej polityki rotacji lub do konkretnego konta operatora, które ją wywołało.

Egzekwowanie rezydencji danych: utrzymywanie danych najemcy w obrębie uprawnionych jurysdykcji

Wymagania rezydencji danych dla najemców obronnych są często wiążącymi obowiązkami prawnymi, a nie preferencjami. Najemca działający na mocy ustawodawstwa o bezpieczeństwie narodowym może mieć zakaz przetwarzania lub przechowywania swoich danych na infrastrukturze zlokalizowanej poza jego jurysdykcją krajową, niezależnie od umownych zapewnień dostawcy chmury. Egzekwowanie tych wymagań w wielodostępnej platformie SaaS wymaga więcej niż oznaczania danych etykietą jurysdykcji; wymaga kontroli architektonicznych zapobiegających fizycznemu opuszczeniu uprawnionego regionu przez dane, w połączeniu z dowodami audytowymi, że te kontrole działały prawidłowo przez cały okres retencji danych.

Podstawową kontrolą jest topologia infrastruktury: instancje bazy danych, zasobniki pamięci masowej i pule węzłów obliczeniowych specyficzne dla najemcy są udostępniane wyłącznie w regionie chmury uprawnionej jurysdykcji. Replikacja międzyregionalna jest wyłączona na warstwach pamięci masowej i bazy danych dla najemców z ograniczeniami rezydencji, nawet na potrzeby odzyskiwania po awarii; replika w nieuprawnionej jurysdykcji stanowi naruszenie rezydencji niezależnie od jej celu. Model odzyskiwania po awarii dla tych najemców musi wykorzystywać redundancję wewnątrz jurysdykcji: wdrożenia wielostrefowe w obrębie pojedynczego krajowego regionu chmury, z synchroniczną replikacją między strefami. To ograniczenie zmusza architektów obronnego SaaS do traktowania najemców z ograniczeniami rezydencji jako odrębnych partycji infrastruktury, a nie jako parametrów w ujednoliconym globalnym modelu wdrażania.

Kontrole wtórne adresują ścieżki danych, które są mniej oczywiście istotne dla rezydencji: przekazywanie dzienników, telemetria monitorowania i narzędzia wsparcia. Platforma, która prawidłowo ogranicza przechowywanie danych do uprawnionego regionu, ale przekazuje dzienniki aplikacji do SIEM obsługiwanego w innym kraju, ma lukę rezydencji. Podobnie sesje zdalnej administracji przechodzące przez stację roboczą inżyniera wsparcia w nieuprawnionej jurysdykcji mogą przenosić fragmenty danych w stanie sesji. Platformy obronnego SaaS muszą prześledzić każdą ścieżkę danych, nie tylko podstawową ścieżkę danych aplikacji, i zastosować do nich wszystkich kontrole rezydencji. Zazwyczaj wymaga to osobnej infrastruktury monitorowania na strefę rezydencji oraz ścisłych kontroli, które konta operatorów mogą inicjować sesje administracyjne wobec których środowisk najemców.

Zarządzanie granicami akredytacji: kto jest właścicielem ATO, gdy najemcy współdzielą infrastrukturę

Granice autoryzacji do działania (ATO) stają się strukturalnie niejednoznaczne w wielodostępnej platformie obronnego SaaS. Dostawca platformy obsługuje współdzieloną infrastrukturę (płaszczyznę sterowania Kubernetes, usługę zarządzania kluczami, sieć, dostawcę tożsamości) i posiada ATO obejmujące te komponenty. Każdy najemca obsługuje obciążenia aplikacji i dane, które znajdują się na szczycie tej infrastruktury, i może posiadać osobne ATO dla własnej granicy systemu. Pytanie, gdzie kończy się ATO platformy, a zaczyna ATO najemcy, nie jest kwestią teoretyczną: określa, kto jest odpowiedzialny za każdą kontrolę bezpieczeństwa, kto jest urzędnikiem autoryzującym zmiany tej kontroli i kto ponosi odpowiedzialność, jeśli kontrola zawiedzie.

Standardowym modelem jest warstwowa macierz odpowiedzialności. ATO dostawcy platformy obejmuje wszystkie kontrole na warstwie infrastruktury: bezpieczeństwo fizyczne obiektów centrum danych, łatanie hipernadzorcy i środowiska wykonawczego kontenerów, konfigurację grup zabezpieczeń sieci, dostępność i rejestrowanie dostępu usługi zarządzania kluczami oraz udokumentowane powyżej kontrole izolacji. Program ciągłego monitorowania dostawcy platformy musi wytwarzać dowody, że te kontrole działają prawidłowo dla wszystkich najemców jednocześnie, bez ujawniania danych monitorowania jednego najemcy innemu. ATO każdego najemcy dziedziczy kontrole platformy przez odniesienie; plan bezpieczeństwa systemu najemcy cytuje pakiet ATO platformy jako dowód, że kontrole infrastruktury są spełnione, i dokumentuje tylko kontrole specyficzne dla najemcy: konfigurację bezpieczeństwa na warstwie aplikacji, oznaczenia klauzuli tajności danych, uprawnioną populację użytkowników i politykę kluczy szyfrujących specyficzną dla najemcy.

Zarządzanie zmianami na warstwie platformy wyzwala obowiązki ponownej akredytacji kaskadujące na najemców. Gdy dostawca platformy modyfikuje współdzielony komponent (aktualizuje wersję Kubernetes, zmienia mechanizm egzekwowania polityki sieciowej, modyfikuje model polityki dostępu usługi zarządzania kluczami), urzędnik autoryzujący każdego najemcy musi przejrzeć zmianę i potwierdzić, że odziedziczone kontrole najemcy są nadal ważne. To tworzy nakład koordynacyjny rosnący wraz z liczbą najemców: pojedyncza aktualizacja platformy może wymagać powiadomienia i uzyskania potwierdzenia od dziesiątek niezależnych urzędników autoryzujących. Platformy obronnego SaaS, które dobrze sobie z tym radzą, inwestują w sformalizowany proces komunikacji zmian, uzgodnione z wyprzedzeniem terminy powiadamiania oraz wzorcowy język, którego urzędnicy autoryzujący najemców mogą używać do dokumentowania swoich decyzji o ponownej akredytacji przy minimalnym nakładzie pracy.

Rejestrowanie audytu per najemca: segregowane ślady audytowe dla śledztwa między najemcami

Rejestrowanie audytu w wielodostępnym środowisku niejawnym musi spełniać dwa pozornie sprzeczne wymagania. Dzienniki audytowe każdego najemcy muszą być izolowane (dostępne dla uprawnionych audytorów tego najemcy, a nie dla żadnego innego najemcy), a operator platformy musi zachować dostęp do dzienników wszystkich najemców na potrzeby reagowania na incydenty na poziomie platformy i śledztwa kryminalistycznego. Rozwiązanie tego napięcia wymaga jasnego modelu danych: dzienniki audytowe najemcy są danymi należącymi do najemcy, dostęp do których przez operatora platformy jest sam w sobie rejestrowanym, rozliczalnym działaniem podlegającym tym samym wymaganiom audytowym co każde inne zdarzenie uprzywilejowanego dostępu.

Wzorcem architektonicznym jest ujście dziennika per najemca z kontrolami niezmienności i rejestrowaniem dostępu na poziomie ujścia. Zdarzenia aplikacji i infrastruktury każdego najemcy są kierowane do dedykowanej grupy dzienników lub partycji pamięci obiektowej z polityką tylko do zapisu dla warstwy aplikacji i polityką tylko do odczytu dla uprawnionych audytorów najemcy. Polityki object-lock zapobiegają usuwaniu lub modyfikowaniu rekordów dziennika przez cały okres retencji. Operator platformy posiada osobną rolę administracyjną przyznającą dostęp do odczytu wszystkich ujść dzienników najemców, ale każde wykonanie tej roli generuje zdarzenie dostępu dopisywane do własnego strumienia audytowego najemcy, widoczne dla audytorów najemcy podczas następnego przeglądu. Ten projekt oznacza, że najemca zawsze może odpowiedzieć na pytanie "czy ktoś spoza naszej organizacji odczytał nasze dzienniki audytowe?", badając własny strumień audytowy.

Śledztwo kryminalistyczne między najemcami (rekonstrukcja incydentu, który mógł obejmować wielu najemców) wymaga, aby operator platformy skorelował zdarzenia w kilku izolowanych ujściach dzienników. Ta korelacja musi być przeprowadzana przy użyciu narzędzi z uprawnieniami operatora platformy, które same generują rekordy audytowe, a nie poprzez scalanie strumieni dzienników najemców do współdzielonej warstwy pamięci masowej. Współdzielona baza danych audytu przechowująca zdarzenia od wielu najemców odtworzyłaby problem mieszania danych między najemcami, któremu zapobiegać miała architektura izolowanych ujść dzienników. Zamiast tego narzędzia kryminalistyczne odpytują ujście dziennika każdego najemcy niezależnie i składają oś czasu między najemcami w pamięci, w środowisku operatora odizolowanym od wszystkich środowisk najemców i samym podlegającym rejestrowaniu audytu. Ten wzorzec zachowuje izolację dzienników najemców, jednocześnie umożliwiając zdolność kryminalistyczną na poziomie platformy, której wymagają zespoły operacji bezpieczeństwa.