Zabezpieczanie Infrastruktury AI

Nowa Powierzchnia Ataku w Środowisku Wysokiego Ryzyka

Serwery wnioskowania AI znajdują się na niezwykłym skrzyżowaniu: przechowują najbardziej wrażliwe dokumenty, jakie posiada organizacja, przetwarzają zapytania ujawniające, czego ludzie szukają w tych dokumentach, i udostępniają API, których większość zespołów bezpieczeństwa nigdy nie hartowała.

Kancelarie prawne i szpitale mają doświadczenie w ochronie serwerów plików i systemów klinicznych. Mają ustalone procedury kontroli dostępu użytkowników, tworzenia kopii zapasowych i reagowania na incydenty. Ale serwer AI to naprawdę nowa infrastruktura, a podręcznik bezpieczeństwa dla niej nie został jeszcze zapisany w politykach większości organizacji.

Ten artykuł dotyczy tego, co powinien zawierać ten podręcznik — i czego wymagają ramy regulacyjne regulujące dane prawne i medyczne.

Dlaczego Infrastruktura AI Jest Celem Wysokiej Wartości

Trzy charakterystyki sprawiają, że serwery wnioskowania AI są szczególnie atrakcyjne dla atakujących:

Wagi modeli reprezentują miesiące inwestycji: Dostrojone lub dostosowane modele kodują konkretną wiedzę dziedzinową i reprezentują znaczną inwestycję obliczeniową. Eksfiltracja wag modelu — kradzież samych plików modelu — jest kradzieżą własności intelektualnej, która może pozostać niewykryta, dopóki skradziony model nie pojawi się w produkcie konkurenta.

Okna kontekstowe ujawniają zawartość dokumentów: Podczas wnioskowania całe fragmenty dokumentów są ładowane do okna kontekstowego modelu. Atakujący z dostępem do procesów wnioskowania lub pamięci może wydobyć zawartość dokumentów, która nigdy nie była jawnie przechowywana w dostępnym miejscu — dokument jest “w tranzycie” przez model, ale treść jest całkowicie obecna w pamięci.

API wnioskowania umożliwiają ruch boczny: Źle skonfigurowany punkt końcowy API wnioskowania to nieuwierzytelniony punkt wejścia do segmentu sieci, który zazwyczaj ma dostęp do pamięci masowej dokumentów, baz danych wektorowych i systemów tożsamości użytkowników. Skompromitowanie punktu końcowego wnioskowania to nie tylko incydent bezpieczeństwa AI — to przyczółek do szerszego dostępu do sieci.

Krajobraz Regulacyjny

Dla organizacji prawnych i opieki zdrowotnej wdrażających AI on-premises, dwa frameworki są najbardziej istotne: Reguła Bezpieczeństwa HIPAA i norma ISO/IEC 27001:2022.

Reguła Bezpieczeństwa HIPAA

Reguła Bezpieczeństwa HIPAA wymaga od podmiotów objętych i ich partnerów biznesowych wdrożenia zabezpieczeń w trzech kategoriach:

Zabezpieczenia administracyjne: Analiza i zarządzanie ryzykiem, szkolenia pracowników i sankcje, planowanie awaryjne i ocena środków bezpieczeństwa. System AI przetwarzający Chronione Informacje Zdrowotne (PHI) — dokumentację pacjentów, notatki kliniczne, dane rozliczeniowe — uruchamia te wymagania niezależnie od tego, czy jest on-premises czy hostowany w chmurze.

Zabezpieczenia fizyczne: Kontrola dostępu do obiektów, ograniczenia użytkowania stacji roboczych oraz kontrola urządzeń i mediów. Sprzęt AI on-premises podlega tym samym wymaganiom bezpieczeństwa fizycznego, co każdy inny system przechowujący lub przetwarzający PHI.

Zabezpieczenia techniczne: Kontrola dostępu, kontrola audytu, kontrola integralności i bezpieczeństwo transmisji. Są to wymagania najbardziej bezpośrednio istotne dla konfiguracji serwera wnioskowania.

ISO/IEC 27001:2022

ISO 27001 to standard zarządzania bezpieczeństwem informacji, który określa 93 kontrole w czterech tematach. Dla infrastruktury AI, najbardziej istotne kontrole z Załącznika A obejmują:

A.5.9 Inwentaryzacja informacji i innych powiązanych aktywów: Pliki modeli, dane treningowe i konfiguracja muszą być zinwentaryzowane
A.5.15–5.18 Kontrola dostępu: Zarządzanie tożsamością, uwierzytelnianie i prawa dostępu dla punktów końcowych wnioskowania
A.7 Kontrole fizyczne: Fizyczny dostęp do sprzętu serwerowego
A.8.5 Bezpieczne uwierzytelnianie: Uwierzytelnianie wieloskładnikowe dla dostępu administracyjnego
A.8.8 Zarządzanie podatnościami technicznymi: Zarządzanie poprawkami dla sterowników, systemu operacyjnego i stosu wnioskowania
A.8.15 Rejestrowanie: Ścieżka audytu dla dostępu do systemu i użytkowania AI
A.8.24 Stosowanie kryptografii: Wymagania szyfrowania dla danych w spoczynku i w tranzycie

Wymagania Zmapowane na Kontrole

Wymaganie HIPAA	Kontrola ISO 27001	Implementacja
Kontrola dostępu (§164.312(a))	A.5.15, A.8.5	RBAC + MFA dla wszystkich API wnioskowania
Kontrola audytu (§164.312(b))	A.8.15	Logi odporne na manipulację dla wszystkich zapytań wnioskowania
Integralność (§164.312(c))	A.8.11	Logi audytu z łańcuchem HMAC; sumy kontrolne wag modeli
Bezpieczeństwo transmisji (§164.312(e))	A.8.24	Minimum TLS 1.3 dla całej komunikacji serwisowej
Zabezpieczenia fizyczne (§164.310)	A.7	Dostęp przez kartę, wykrywanie ingerencji w obudowę, inwentaryzacja aktywów
Plan awaryjny (§164.308(a)(7))	A.5.29, A.5.30	Udokumentowane procedury DR; przetestowane przywracanie kopii zapasowych

Fizyczne Kontrole Bezpieczeństwa

Bezpieczeństwo fizyczne jest często niedoceniane w planowaniu wdrożeń AI, szczególnie dla organizacji przyzwyczajonych do infrastruktury chmurowej, gdzie bezpieczeństwo fizyczne jest odpowiedzialnością dostawcy chmury.

Kontrola dostępu do serwerowni: Sprzęt AI musi znajdować się w kontrolowanej przestrzeni z udokumentowanymi procedurami dostępu. Dostęp przez kartę z indywidualnymi poświadczeniami użytkownika (nie wspólnymi kodami) zapewnia ścieżkę audytu. Dla środowisk wysokiego bezpieczeństwa, uwierzytelnianie biometryczne (odcisk palca, tęczówka) eliminuje współdzielenie poświadczeń.

Wykrywanie ingerencji w sprzęt: Serwery korporacyjne zawierają wykrywanie ingerencji w obudowę — czujnik rejestrujący otwarcie obudowy serwera. Powinno to być skonfigurowane do generowania alertów. Układy TPM (Trusted Platform Module) zapewniają potwierdzenie na poziomie sprzętu, że system nie został zmodyfikowany; stanowią fundament konfiguracji bezpiecznego rozruchu, które zapobiegają ładowaniu nieautoryzowanego oprogramowania podczas uruchamiania.

Inwentaryzacja aktywów i łańcuch pieczy: Każdy element sprzętu przetwarzającego wrażliwe dane powinien być formalnie zinwentaryzowany: numer seryjny, etykieta aktywu, lokalizacja, przypisany opiekun i konfiguracja bazowa. Gdy sprzęt jest wycofywany z eksploatacji, wymaga bezpiecznych procedur utylizacji — nie tylko wymazania danych, ale udokumentowanego dowodu wymazania lub fizycznego zniszczenia.

Bezpieczeństwo Sieci

Izolacja Sieciowa

Serwer wnioskowania nie powinien znajdować się w tym samym segmencie sieci co stacje robocze użytkowników, drukarki i ogólna infrastruktura biurowa. Segmentacja sieci (przy użyciu sieci VLAN lub fizycznego oddzielenia) ogranicza zasięg kompromitacji.

Odpowiedni stopień izolacji zależy od modelu zagrożeń i wymagań dotyczących zgodności:

Air-gap: Brak połączenia sieciowego w ogóle. Maksymalne bezpieczeństwo, ale uniemożliwia zdalny dostęp, zdalne monitorowanie i aktualizacje oprogramowania przez sieć. Odpowiednie tylko dla najbardziej wrażliwych środowisk, gdzie fizyczny dostęp do wszystkich operacji jest akceptowalny.
Izolowana sieciowo sieć VLAN: Połączona z siecią, ale w dedykowanym segmencie z jawnymi regułami zapory. Umożliwia zdalne administrowanie, monitorowanie i automatyczne łatanie przy jednoczesnym zapobieganiu ruchowi bocznemu. Odpowiednie dla większości wdrożeń prawnych i medycznych.

Komunikacja Między Serwisami

W ramach wdrożenia wiele serwisów komunikuje się ze sobą: brama API wywołuje silnik wnioskowania, silnik wnioskowania odpytuje bazę danych wektorowych, system rejestrowania audytu zapisuje do magazynu logów. Każde z tych połączeń powinno być szyfrowane i wzajemnie uwierzytelniane.

mTLS (wzajemny TLS) jest standardem dla tego celu: obie strony każdego połączenia przedstawiają certyfikaty, potwierdzając swoją tożsamość przed wymianą danych. Zapobiega to podszyciu się skompromitowanego serwisu pod inny i uniemożliwia nieautoryzowanym klientom łączenie się z wewnętrznymi serwisami, nawet jeśli są w tym samym segmencie sieci.

Kontrole Wychodzącego Ruchu Sieciowego

Naprawdę prywatne wdrożenie on-premises nie powinno wymagać wychodzącej łączności internetowej dla operacji wnioskowania. Jawne reguły zapory dla ruchu wychodzącego — domyślnie blokuj-wszystko dla segmentu sieciowego serwera wnioskowania — wymuszają to i czynią to audytowalnym.

Ma to znaczenie, ponieważ źle skonfigurowane frameworki wnioskowania mogą nawiązywać połączenia wychodzące do repozytoriów modeli lub punktów końcowych telemetrii bez wyraźnego wskazania. Blokowanie całego ruchu wychodzącego z jawnymi wyjątkami dla określonych miejsc docelowych (serwery aktualizacji oprogramowania, NTP) zapobiega niezamierzonej transmisji danych.

Kontrola Dostępu i Tożsamość

Kontrola Dostępu Oparta na Rolach dla API Wnioskowania

Nie każdy, kto może dotrzeć do serwera wnioskowania, powinien móc odpytywać go dowolnymi danymi wejściowymi, uzyskiwać dostęp do funkcji administracyjnych lub przeglądać logi audytu. Kontrola dostępu oparta na rolach (RBAC) przypisuje konkretne uprawnienia konkretnym rolom:

Użytkownicy końcowi: Mogą wysyłać zapytania; nie mogą uzyskiwać dostępu do konfiguracji ani logów
Operatorzy: Mogą monitorować stan systemu; mogą dostosowywać parametry obsługi; nie mogą uzyskiwać dostępu do zawartości zapytań użytkowników
Administratorzy: Pełny dostęp; wszystkie działania rejestrowane; wymagają MFA i uzasadnienia dla wrażliwych operacji

API wnioskowania powinno wymuszać RBAC na poziomie aplikacji, nie opierać się wyłącznie na kontroli dostępu na poziomie sieci.

Uwierzytelnianie Wieloskładnikowe

Cały dostęp administracyjny — SSH do serwera, dostęp do interfejsu zarządzania, dostęp do przechowywania logów audytu — powinien wymagać uwierzytelniania wieloskładnikowego. Dostęp oparty wyłącznie na haśle jest niewystarczający dla systemów przechowujących uprzywilejowane dane klientów lub PHI.

MFA powinno być wymagane przy logowaniu, a nie raz na sesję. Limity czasu trwania sesji (automatyczne wylogowanie po bezczynności) zmniejszają okno ekspozycji w przypadku przejęcia uwierzytelnionej sesji.

Zasada Najmniejszych Uprawnień dla Kont Serwisowych

Serwisy działające na serwerze wnioskowania (silnik wnioskowania, baza danych wektorowych, potok przetwarzania dokumentów) wymagają poświadczeń dostępu do innych serwisów i pamięci masowej. Te konta serwisowe powinny mieć minimalne uprawnienia niezbędne do ich konkretnej funkcji.

Silnik wnioskowania potrzebuje dostępu do odczytu katalogu wag modeli i dostępu do zapisu w logu zapytań. Nie potrzebuje dostępu do zapisu wag modeli, dostępu do interfejsu administratora ani dostępu do dokumentów innych użytkowników. Ograniczenie uprawnień kont serwisowych zmniejsza potencjalne szkody w przypadku skompromitowania któregokolwiek z serwisów.

Ochrona Danych

Szyfrowanie Danych w Spoczynku

Każdy magazyn danych powiązany z systemem wnioskowania powinien być zaszyfrowany w spoczynku:

Wagi modeli: Duże pliki, często przechowywane w dedykowanych katalogach. Powinny znajdować się na zaszyfrowanych woluminach (dm-crypt/LUKS w systemie Linux), które wymagają materiału klucza do zamontowania.
Osadzenia wektorowe: Baza danych wektorowych Qdrant przechowuje osadzenia dokumentów reprezentujące semantyczną zawartość dokumentów. Jeśli atakujący może wyodrębnić osadzenia, może zrekonstruować przybliżoną zawartość dokumentów poprzez ataki inwersji. Osadzenia powinny być traktowane jako wrażliwe dane, a nie tylko oryginalne dokumenty.
Logi konwersacji i zapytań: Każdy log zapytania wnioskowania to zapis tego, o co pytają użytkownicy w odniesieniu do jakich dokumentów. Jest to wysoce wrażliwa informacja i powinna być szyfrowana w spoczynku z taką samą rygoryzmem jak same dokumenty.

Szyfrowanie Danych w Tranzycie

Cała komunikacja sieciowa między serwisami oraz między użytkownikami a systemem powinna używać co najmniej TLS 1.3. TLS 1.2 jest absolutnym minimum; starsze wersje mają znane podatności i powinny być jawnie wyłączone.

Zarządzanie certyfikatami — generowanie certyfikatów, śledzenie wygaśnięcia, odnawianie przed upływem terminu ważności — powinno być zautomatyzowane. Wygasłe certyfikaty są częstą przyczyną zakłóceń usług i, gdy zespoły spieszą się z ich naprawą, częstą przyczyną tymczasowych obniżeń poziomu bezpieczeństwa.

Zarządzanie Kluczami

Szyfrowanie jest tak mocne, jak ochrona kluczy szyfrowania. Klucze przechowywane na tym samym dysku co dane, które szyfrują, zapewniają znacznie słabszą ochronę niż osobno zarządzane klucze.

Dla środowisk wysokiego bezpieczeństwa, Sprzętowe Moduły Bezpieczeństwa (HSM) zapewniają przechowywanie kluczy w sprzęcie odpornym na ingerencję: klucze prywatne są generowane wewnątrz HSM, nigdy nie eksportowane, a operacje wymagające klucza są wykonywane wewnątrz HSM. Znacznie utrudnia to eksfiltrację klucza nawet dla atakującego z pełnym dostępem do systemu.

Co najmniej, klucze szyfrowania powinny być przechowywane oddzielnie od danych, które chronią, rotowane zgodnie z zdefiniowanym harmonogramem i archiwizowane przy użyciu procesu, który nie ujawnia materiału klucza.

Rejestrowanie Audytu i Monitorowanie

Co Rejestrować

Kompleksowe rejestrowanie audytu dla systemu wnioskowania AI wymaga zapisywania:

Każdego zapytania wnioskowania: Znacznik czasu, tożsamość użytkownika, zawartość zapytania (lub jej hash), użyta wersja modelu, latencja odpowiedzi
Każdego działania administracyjnego: Zmiany konfiguracji, aktualizacje modeli, zmiany polityki dostępu, tworzenie i usuwanie kont
Zdarzeń uwierzytelniania: Udane logowania, nieudane logowania, monity MFA, tworzenie i zakańczanie sesji
Zdarzeń systemowych: Uruchamianie i zatrzymywanie serwisów, warunki błędów, zmiany pojemności pamięci masowej, odnowienia certyfikatów

Wyzwaniem jest to, że pełne rejestrowanie zapytań wnioskowania (rejestrowanie rzeczywistej zawartości zapytania i odpowiedzi) tworzy wtórny wrażliwy magazyn danych, który sam musi być chroniony. Organizacje powinny jawnie zdecydować, czy rejestrować pełną zawartość (do celów audytu i debugowania), czy hashowane identyfikatory (dla rozliczalności bez ujawniania zawartości), i chronić odpowiednio.

Logi Odporne na Manipulację

System logów, który może być modyfikowany przez atakującego po fakcie, ma ograniczoną wartość audytową. Rejestrowanie odporne na manipulację — gdzie każdy wpis logu kryptograficznie odwołuje się do poprzedniego wpisu — sprawia, że retrospektywna modyfikacja jest wykrywalna.

System Tacitus implementuje logi audytu z łańcuchem HMAC: każdy wpis logu zawiera HMAC zawartości poprzedniego wpisu, tworząc łańcuch, w którym każda modyfikacja historycznych rekordów łamie łańcuch i jest natychmiast wykrywalna przy weryfikacji. Bezpośrednio adresuje to wymaganie integralności HIPAA i kontrole rejestrowania ISO 27001.

Reagowanie na Incydenty dla Systemów AI

Standardowe podręczniki reagowania na incydenty wymagają rozszerzeń specyficznych dla AI:

Sprawdzenie integralności wag modelu: Gdy wystąpi incydent, jak weryfikujesz, że wagi modelu nie zostały zmodyfikowane? (Odpowiedź: kryptograficzne sumy kontrolne plików wag, porównane z manifestem znanych dobrych wartości.)
Zachowanie logów wnioskowania: Logi z okresu incydentu są dowodem; powinny być zachowane w stanie tylko do odczytu i chronione przed modyfikacją przez osoby reagujące na incydent.
Ocena ekspozycji okna kontekstowego: Jeśli atakujący miał dostęp do działającego procesu wnioskowania, jakie dokumenty były w aktywnych oknach kontekstowych w tym okresie? Logi wnioskowania powinny dostarczać tej informacji.
Rotacja kluczy: Jeśli poświadczenia dostępu są potencjalnie skompromitowane, jaka jest procedura rotacji kluczy kont serwisowych, certyfikatów TLS i kluczy szyfrowania bez wyłączania systemu?

Luka Zgodności, Którą Większość Zespołów Pomija

Najczęstszym błędnym przekonaniem wśród organizacji wdrażających AI on-premises jest to, że “on-premises = zgodność”. Wymagania regulacyjne są takie same niezależnie od modelu hostingu.

HIPAA nie rozróżnia między przetwarzaniem PHI hostowanym w chmurze a on-premises. Jeśli Twój system AI przetwarza PHI, wszystkie wymagania Reguły Bezpieczeństwa HIPAA mają zastosowanie — w tym dotyczące analizy ryzyka, szkoleń pracowników, planowania awaryjnego i opisanych powyżej zabezpieczeń technicznych. Bycie on-premises eliminuje jedno ryzyko (poziom bezpieczeństwa dostawcy chmury), ale nie eliminuje wymogu adresowania pozostałych.

Podobnie, jeśli Twój dostawca AI ma dostęp do Twojego systemu dla zdalnego wsparcia, konserwacji lub monitorowania, może kwalifikować się jako Partner Biznesowy (Business Associate) zgodnie z HIPAA — i powinien podpisać z Tobą Umowę Partnera Biznesowego niezależnie od tego, czy sprzęt znajduje się w Twoim budynku.

Certyfikacja ISO 27001 wymaga udokumentowanych dowodów wdrożenia kontroli, regularnych wewnętrznych audytów i przeglądu zarządzania. System AI, który nie jest uwzględniony w zakresie Twojego ISMS (Information Security Management System), jest niezaudytowanym systemem obsługującym wrażliwe dane — jest to ustalenie, które zostanie poruszone w każdym poważnym audycie.

Jak Wygląda Profesjonalne Wdrożenie

Kontrole opisane w tym artykule nie są nadzwyczajne. Są bazą, której wymaga poważny framework zgodności, zastosowaną do infrastruktury wystarczająco nowej, że wiele organizacji nie opracowało jeszcze praktyk operacyjnych do ich wdrożenia.

Baza bezpieczeństwa Tacitus buduje te kontrole na poziomie projektu, zamiast traktować je jako listę kontrolną po wdrożeniu:

Izolacja sieciowa i mTLS są skonfigurowane w manifeście wdrożenia, a nie dodawane później
RBAC jest częścią architektury aplikacji, nie dołączana poprzez reguły sieciowe
Rejestrowanie audytu z łańcuchem HMAC jest podstawową funkcją systemu, a nie wtyczką
Szyfrowanie w spoczynku jest konfigurowane jako część aprowizacji pamięci masowej, nie po tym, gdy dane są już na miejscu
Wymagania bezpieczeństwa fizycznego są udokumentowane w przewodniku wdrożenia i wbudowane w dobór sprzętu

Ma to znaczenie, ponieważ kontrole bezpieczeństwa dodawane po uruchomieniu systemu mają tendencję do posiadania luk. Kontrole będące częścią projektu systemu od początku są kompleksowe i spójne.

Jeśli wdrażasz AI w regulowanym środowisku i chcesz zrozumieć, jak wygląda zgodne wdrożenie z bazą bezpieczeństwa dla Twoich konkretnych wymagań, techniczny briefing jest właściwym punktem wyjścia.

Poproś o briefing, aby omówić swoje wymagania dotyczące zgodności i bezpieczeństwa z zespołem Tacitus.