Jak Microsoft Azure chroni poufne dane w Chat GPT - warstwy ochrony

Microsoft Azure i ochrona danych w Chat GPT - droga jednego zapytania

Firmy obawiają się wycieku, gdy pracownicy wpisują do publicznego chatbota fragmenty umów, zestawienia finansowe lub dane kadrowe. Rozwiązaniem opisywanym przez SoftwareStudio jest prywatna wersja Chat GPT uruchomiona w usłudze Azure OpenAI, w zasobie należącym do firmy. Ochrona nie wynika z jednej funkcji. Składa się z kilku warstw, z których każdą trzeba osobno skonfigurować.

Poniższy tekst opisuje te warstwy na podstawie dokumentacji Microsoftu i wskazuje, co zostaje po stronie firmy. Dokument o prywatności danych i bezpieczeństwie modeli w Azure jest źródłem zasad przytaczanych niżej, a jego treść bywa aktualizowana, więc przy wdrożeniu należy sprawdzić wersję bieżącą.

Etapy zapytania

Zapytanie przechodzi przez pięć miejsc. Tabela pokazuje, gdzie w każdym z nich znajdują się dane i kto je kontroluje.

Według dokumentacji Microsoftu pytania i odpowiedzi nie są dostępne dla innych klientów ani dla OpenAI i nie służą do ulepszania modeli bez zgody klienta. Modele hostuje sam Microsoft w środowisku Azure, bez łączności z usługami OpenAI, takimi jak publiczny ChatGPT. Ogólny opis platformy OpenAI i jej zastosowań w biznesie zawiera artykuł o platformie OpenAI i zastosowaniach API.

Reguła: prywatność Chat GPT w Azure wynika z konfiguracji zasobu i warunków umowy, a nie z samej nazwy usługi. Każdą warstwę trzeba sprawdzić i włączyć.

Prywatna instancja a publiczny chatbot

Różnica dotyczy nie tylko modelu, lecz przede wszystkim tego, kto zarządza otoczeniem. Tabela zestawia obie sytuacje według kryteriów istotnych dla działu bezpieczeństwa.

Lokalizacja przetwarzania i typy wdrożeń

Pytanie o to, gdzie fizycznie przetwarzane są dane, ma wymiar prawny, bo dotyczy ewentualnego przekazania ich poza Europejski Obszar Gospodarczy. Odpowiedź zależy od typu wdrożenia modelu wybranego przy konfiguracji.

Wybór typu wdrożenia jest więc decyzją prawną tak samo jak techniczną. Firma, która chce ograniczyć przetwarzanie do jednego obszaru, nie powinna wybierać wdrożenia globalnego, nawet jeśli oferuje ono większą dostępność modelu. Wpływa to także na rozmowy z inspektorem ochrony danych, który ocenia podstawę przekazywania danych.

Monitorowanie nadużyć i przechowywanie treści

Usługa nie zapisuje zwykłych wywołań w modelu, ale ma własny mechanizm wykrywania nadużyć. Dokumentacja opisuje go wprost: gdy system zauważy sygnały naruszenia zasad użytkowania, może wybrać do przeglądu próbkę pytań i odpowiedzi. Przegląd prowadzą domyślnie automaty, a w razie potrzeby uprawnieni pracownicy Microsoftu, dla wdrożeń w Europejskim Obszarze Gospodarczym znajdujący się w tym obszarze.

Zmodyfikowane monitorowanie nadużyć

Zatwierdzeni klienci mogą wnioskować o wyłączenie zapisu treści na potrzeby przeglądu przez ludzi. Stan ustawienia można sprawdzić w portalu albo w wierszu poleceń. Dokumentacja podaje, że parametr ContentLogging o wartości false pojawia się w opisie zasobu tylko wtedy, gdy zapis został wyłączony.

az cognitiveservices account show -n nazwa-zasobu -g grupa-zasobow

"capabilities": [
  { "name": "ContentLogging", "value": "false" }
]

Wyłączenie zapisu nie oznacza braku kontroli. Automatyczna ocena nadal może działać, a wykrycie poważnych lub powtarzających się nadużyć grozi ograniczeniem dostępu do usługi.

Funkcje z pamięcią rozmowy

Część funkcji zapisuje dane w usłudze, na przykład historię rozmowy w interfejsie Responses i wątki asystentów, a także przechowywane odpowiedzi i pliki wysłane do przetwarzania. Tabela pokazuje, co system zapisuje, oraz zasady ochrony tych danych.

Reguła: funkcje z pamięcią rozmowy zapisują dane w zasobie klienta, więc firma odpowiada za plan ich przechowywania i usuwania.

Tożsamość i dostęp - role zamiast kluczy API

Klucz API jest współdzielonym sekretem. Wklejony do kodu trafia do repozytorium i do logów, a także do skryptów kopiowanych między zespołami, więc nie wiadomo, kto go używał. Tożsamość Microsoft Entra ID rozwiązuje ten problem: aplikacja uzyskuje token dla własnej tożsamości zarządzanej, a uprawnienie do wywołań przyznaje rola na zasobie.

Rola i tożsamość zarządzana

Dokumentacja wskazuje, że wywoływanie modelu własną tożsamością wymaga roli Cognitive Services OpenAI User albo szerszej Contributor na zasobie. Wąska rola wystarcza aplikacji, a szeroką przydziela się niewielkiej grupie administratorów, którzy zarządzają wdrożeniami. Instrukcję konfiguracji zawiera dokument o tożsamości zarządzanej w Azure OpenAI.

using Azure.Identity;
using Azure.AI.OpenAI;
using OpenAI.Chat;

var klient = new AzureOpenAIClient(
    new Uri("https://przyklad.openai.azure.com/"),
    new DefaultAzureCredential());

ChatClient czat = klient.GetChatClient("wdrozenie-przyklad");
ChatCompletion wynik = czat.CompleteChat(
    new SystemChatMessage("Odpowiadaj wyłącznie na podstawie dostarczonych fragmentów."),
    new UserChatMessage("Jaki termin płatności wynika z umowy?"));

Console.WriteLine(wynik.Content[0].Text);

Adres zasobu i nazwa wdrożenia w przykładzie są przykładowe. Klasa DefaultAzureCredential uzyskuje token z tożsamości zarządzanej na serwerze, a lokalnie z konta programisty, więc w kodzie nie ma żadnego sekretu.

Uprawnienia użytkowników końcowych

Rola na zasobie odpowiada za aplikację, a nie za osoby korzystające z niej. To, które dokumenty widzi dany pracownik, rozstrzyga warstwa danych, w której działa aplikacja. Kontekst dla modelu składa się więc z uprawnieniami zalogowanej osoby. Asystent raportowy, opisany w artykule o DataFlow AI, przekazuje modelowi tylko pytanie i opis schematu, a wiersze wyniku zostają w bazie. Ten sam mechanizm opisano przy okazji rodziny asystentów w artykułach o SoftwareStudio AI Family oraz o wyborze i pilotażu inteligentnych asystentów.

Sieć prywatna i ograniczenie dostępu

Domyślnie zasób usług AI przyjmuje połączenia z dowolnej sieci, o ile klient ma poprawne poświadczenia. Dokumentacja zaleca, aby najpierw ustawić regułę odmowy dla całego ruchu, także z Internetu, a dopiero potem dodawać wyjątki. Ostrzega też, że bez domyślnej odmowy reguły sieciowe nie mają żadnego skutku.

Reguły sieciowe i prywatny punkt końcowy

Dostęp można ograniczyć do wskazanych adresów IP albo podsieci sieci wirtualnej. Wygodniejszym rozwiązaniem jest prywatny punkt końcowy: zasób dostaje adres z sieci wirtualnej firmy, a ruch przechodzi przez łącze prywatne w sieci Microsoft, bez ekspozycji na Internet publiczny. Zaporę zasobu można wtedy skonfigurować tak, aby blokowała połączenia z punktu publicznego.

az cognitiveservices account network-rule list \
  --resource-group "grupa-zasobow" --name "nazwa-zasobu" --query ipRules

az cognitiveservices account network-rule add \
  --resource-group "grupa-zasobow" --name "nazwa-zasobu" \
  --ip-address "203.0.113.0/24"

Adres 203.0.113.0/24 pochodzi z zakresu zarezerwowanego na dokumentację. Pełny opis konfiguracji, w tym zasady dla sieci wirtualnych, zawiera dokument o sieciach wirtualnych i prywatnych punktach końcowych. Zmiana domyślnej reguły na odmowę odcina wszystkie aplikacje, którym nie dodano wyjątku, dlatego wdraża się ją po przygotowaniu listy klientów usługi.

Dziennik operacji i przegląd dostępu

Zasób Azure może kierować dzienniki diagnostyczne do przestrzeni analitycznej, gdzie widać, kto i kiedy wywoływał usługę oraz jakim wdrożeniem. Dziennik wywołań warto skonfigurować tak, aby nie powielał treści pytań w narzędziach do monitoringu, bo dane wrażliwe nie powinny trafiać do kolejnych systemów. Zespół bezpieczeństwa zestawia dziennik z listą ról na zasobie i raz na jakiś czas usuwa uprawnienia, z których nikt nie korzystał. Bez takiego przeglądu lista uprawnień rośnie szybciej niż potrzeby.

Filtry treści i minimalizacja danych przed wysłaniem

Filtry treści oceniają pytanie i odpowiedź pod kątem szkodliwych kategorii i działają synchronicznie. Według dokumentacji nie zapisują ani pytań, ani wygenerowanych treści. Nie ochronią jednak firmy przed wysłaniem do modelu danych, których nie powinien on otrzymać. Tę decyzję podejmuje aplikacja.

Maskowanie identyfikatorów przed wysłaniem

Najprostszym sposobem ograniczenia zakresu danych jest zastąpienie identyfikatorów znacznikami, zanim tekst opuści aplikację. Poniższy przykład zamienia numery PESEL i polskie rachunki bankowe zapisane bez odstępów.

using System.Text.RegularExpressions;

static readonly Regex Pesel = new(@"\b\d{11}\b", RegexOptions.Compiled);
static readonly Regex Iban  = new(@"\bPL\d{26}\b", RegexOptions.Compiled);

static string Zamaskuj(string tekst)
{
    tekst = Pesel.Replace(tekst, "[PESEL]");
    return Iban.Replace(tekst, "[IBAN]");
}

Wyrażenia regularne rozpoznają tylko format. Złapią każdy ciąg jedenastu cyfr, także niebędący numerem PESEL, i pominą numer zapisany z odstępami. Maskowanie zmniejsza ryzyko, ale nie zastępuje klasyfikacji danych. W samej bazie podobną rolę pełni dynamiczne maskowanie danych, które ukrywa wartości przed użytkownikami bez uprawnień.

Polecenia ukryte w dokumentach

Dokument przekazany modelowi do analizy może zawierać tekst udający polecenie, na przykład prośbę o pominięcie wcześniejszych zasad. Model nie odróżnia treści od instrukcji tak wyraźnie jak człowiek. Ryzyko ogranicza się przez traktowanie zawartości dokumentów wyłącznie jako danych, przez brak narzędzi ze skutkami ubocznymi w asystencie czytającym cudze pliki oraz przez zatwierdzenie wyniku przez człowieka, opisane przy asystencie umów.

Odpowiedzialność firmy i zgodność z RODO

Model współdzielonej odpowiedzialności w chmurze dzieli zadania między dostawcę a klienta. Microsoft odpowiada za infrastrukturę, szyfrowanie zapisanych danych i mechanizmy usługi. Klient odpowiada za to, co wysyła, komu przyznaje dostęp i jak długo przechowuje zapisane treści. Zasady omawia dokument o współdzielonej odpowiedzialności w Azure, w tym część dotyczącą obciążeń generatywnej AI.

Dane osobowe w zapytaniach

Wysłanie do modelu danych osobowych jest przetwarzaniem i wymaga podstawy prawnej oraz umowy z dostawcą. Zasady ochrony danych klientów Microsoft opisuje w dodatku o ochronie danych, który reguluje przetwarzanie w usługach, a ich zastosowanie do konkretnego przypadku ocenia inspektor ochrony danych firmy. Praktyczny przykład ograniczania zakresu danych osobowych w kontekście modelu opisano w artykule o CRM z asystentem AI.

Więcej o samym wdrożeniu prywatnej instancji, w tym o jej budowie na API, mówi tekst o własnym Chat GPT na platformie Azure, a porównanie publicznego API i usługi Azure zawiera artykuł o prywatnym Chat GPT i bezpieczeństwie danych. Opis oferty producenta w tym obszarze znajduje się w serwisie SoftwareStudio o Azure i prywatnym Chat GPT, a szersze tło daje strona o sztucznej inteligencji.