7 sposobów na poprawę bezpieczeństwa przepływów pracy uczenia maszynowego

W tym poście dowiesz się, jak używać znanych mechanizmów zabezpieczeń do tworzenia bezpieczniejszych przepływów pracy uczenia maszynowego (ML).

Idealną grupą docelową dla tego postu są tzw. data scientists, którzy chcą nauczyć się podstawowych sposobów poprawy bezpieczeństwa swoich przepływów pracy ML, a także inżynierowie bezpieczeństwa, którzy chcą zająć się zagrożeniami specyficznymi dla wdrożenia ML. Rysunek 1 przedstawia podstawowy przepływ pracy ML.

Rysunek nr 1: Przykład podstawowego przepływu pracy machine learning

Aby chronić każdy etap przepływu pracy ML, od źródła danych do interfejsu API prognozowania, wprowadzimy podstawowe środki bezpieczeństwa, które mają zastosowanie do co najmniej jednego etapu przepływu pracy ML. Te środki bezpieczeństwa mogą chronić przed następującymi lukami specyficznymi dla ML:

• Data poisoning, które występuje, gdy modele ML są uczone na zmodyfikowanych danych, co prowadzi do niedokładnych prognoz modelu.
• Membership inference, czyli możliwość stwierdzenia, czy rekord danych został uwzględniony w zestawie danych używanym do trenowania modelu ML. Może to prowadzić do dodatkowych obaw dotyczących prywatności danych osobowych.
• Model inversion, czyli inżynieria odwrotna cech i parametrów modelu. Wiedza o tym, jak model tworzy prognozy, może prowadzić do generowania próbek typu adversarial, takich jak te pokazane na rysunku 2.

Rysunek nr 2: Porównanie między klasyfikacjami sieci neuronowych uzasadnionych próbek (górny rząd) i odpowiadającymi im próbami kontradyktoryjnymi (dolny rząd). Źródło: Papernot, et al.

W następnych sekcjach omówimy siedem sposobów zabezpieczenia przepływu pracy ML oraz to, jak te środki są istotne w usuwaniu luk w zabezpieczeniach związanych z ML.

Uruchomienie instancji ML w VPC

Bezpieczny przepływ pracy ML rozpoczyna się od ustanowienia izolowanego środowiska obliczeniowego i sieciowego. Instancje notebooków Amazon SageMaker to instancje obliczeniowe ML używane przez analityków danych do prototypowania modeli. Są one domyślnie podłączone do Internetu, jak pokazano na rysunku 3, aby umożliwić pobieranie popularnych pakietów, przykładowych notebooków i łatwe dostosowywanie środowiska programistycznego. Chociaż żaden dostęp przychodzący nie jest domyślnie dozwolony w tych instancjach, dostęp wychodzący może zostać wykorzystany przez oprogramowanie innych firm w celu umożliwienia nieautoryzowanego dostępu do Twojej instancji i danych.

Rysunek 3. Domyślna konfiguracja SageMaker (bez VPC)

Aby uniemożliwić programowi SageMaker domyślne zapewnianie dostępu do Internetu, zalecamy określenie VPC dla notebooka, jak pokazano na rysunku 4. Należy pamiętać, że notebook nie będzie w stanie trenować ani hostować modeli, chyba, że kontrola dostępu do sieci VPC zezwala na połączenia wychodzące.

Rysunek 4. Zalecana konfiguracja SageMakera w VPC

Wdrażanie przepływu pracy ML w VPC zapewnia dogłębną ochronę dzięki następującym funkcjom:

• Możesz kontrolować dostęp do ruchu dla instancji i podsieci, używając odpowiednio grup zabezpieczeń i list kontroli dostępu do sieci (ACL sieci).
• Możesz kontrolować łączność między usługami AWS za pomocą endpointów VPC lub AWS PrivateLink z powiązanymi zasadami uprawnień.
• Możesz monitorować cały ruch sieciowy do i z kontenerów za pomocą VPC Flow Logs.

Dla wygody bezproblemowego pobierania bibliotek z Internetu do prac programistycznych zalecamy zaimportowanie wymaganych bibliotek zewnętrznych do prywatnego repozytorium, takiego jak AWS CodeArtifact, przed izolacją środowiska. Aby uzyskać więcej informacji na temat konfigurowania prywatnego środowiska sieciowego, jak pokazano na rysunku 4, zobacz moduł Amazon SageMaker Workshop, Building Secure Environments.

Używanie najmniejszych uprawnień, aby kontrolować dostęp do ML artifacts

W przepływie pracy ML jest używanych i tworzonych kilka artefaktów: dane szkoleniowe, modele ML, parametry modelu i wyniki modelu. Artefakty te mogą mieć charakter poufny, zwłaszcza jeśli zawierają dane osobowe lub informacje cenne handlowo. Aby je chronić, należy postępować zgodnie z praktyką bezpieczeństwa polegającą na przyznawaniu najmniejszych uprawnień, czyli nadawaniu tylko uprawnień wymaganych do wykonania zadania. Ogranicza to niezamierzony dostęp i pomaga kontrolować, kto ma dostęp do jakich zasobów.

AWS Identity and Access Management (IAM) umożliwia zarządzanie dostępem do usług i zasobów AWS. Korzystając z IAM, możesz tworzyć użytkowników i grupy AWS, i zarządzać nimi, a następnie używać polityk do definiowania uprawnień do zarządzania ich dostępem do zasobów AWS. Dwa typowe sposoby implementacji dostępu z najniższymi uprawnieniami to zasady identity-based i zasady resource-based:

• Identity-based policies są dołączane do użytkownika, grupy lub roli IAM. Te zasady pozwalają określić, co może zrobić ta tożsamość. Na przykład, dołączając zarządzaną zasadę AmazonSageMakerFullAccess do roli IAM dla data scientists, dajesz im pełny dostęp do usługi SageMaker w celu opracowania modelu.
• Resource-based policies są dołączone do zasobu. Te zasady pozwalają określić, kto ma dostęp do zasobu i jakie czynności może na nim wykonywać. Na przykład możesz dołączyć politykę do bucketu Amazon Simple Storage Service (Amazon S3), przyznając uprawnienia tylko do odczytu dla data scientists, którzy uzyskują dostęp do zasobnika z określonego endpointu VPC. Inną typową konfiguracją zasad dla bucketów S3 jest odmowa dostępu publicznego, aby zapobiec nieautoryzowanemu dostępowi do danych.

Aby zaprojektować te zasady pod kątem najmniejszego dostępu, zalecamy dwa sposoby określenia minimalnego wymaganego dostępu dla różnych użytkowników. Pierwszym sposobem na osiągnięcie tego jest użycie AWS CloudTrail do przeglądania wydarzeń na koncie w Event history. Logi te pomagają w śledzeniu działań i zasobów używanych w przeszłości przez jednostki IAM. Logi można filtrować według user name, aby uzyskać tożsamość użytkownika IAM, roli lub roli usługi, do której odwołuje się zdarzenie. Możesz także pobrać wyniki w formacie CSV lub JSON. Rysunek 5 przedstawia przykład historii zdarzeń przefiltrowanej według nazwy użytkownika.

Rysunek 5. Dziennik historii zdarzeń CloudTrail filtrowany według  user name.

Innym sposobem określenia niezbędnego dostępu byłoby skorzystanie z zakładki Access Advisor w konsoli IAM. Access Advisor wyświetla ostatnio używane informacje dotyczące grup uprawnień IAM, użytkowników, ról i zasad. Rysunek 6 przedstawia przykład Access Advisor wyświetlający uprawnienia usługi przyznane zarządzanym zasadom AdministratorAccess oraz datę ostatniego dostępu do tych usług.

Rysunek 6. Access Advisor wyświetlający zarządzane zasady AdministratorAccess.

Aby uzyskać więcej informacji o tym, jak używać historii zdarzeń CloudTrail i IAM Access Advisor razem w celu doprecyzowania uprawnień dla pojedynczego użytkownika IAM, zobacz przykład Używanie informacji do zmniejszenia uprawnień dla użytkownika IAM w AWS IAM user guide.

Używanie szyfrowania danych

Zalecamy użycie szyfrowania jako pierwszej linii obrony, aby uniemożliwić nieautoryzowanym użytkownikom odczytywanie danych i modelów. Należy szyfrować dane zarówno podczas przesyłania, jak i w stanie spoczynku.

Aby zapewnić bezpieczną komunikację przesyłanych danych w ramach AWS VPC, możesz użyć Transport Layer Security (TLS), szeroko stosowanego protokołu kryptograficznego. Szyfrowanie TLS w wersji 1.2 jest obsługiwane w wywołaniach API do usług AWS.

Do szyfrowania w spoczynku możesz użyć szyfrowania po stronie klienta, w którym szyfrujesz dane przed przesłaniem ich do AWS, lub szyfrowania po stronie serwera, gdzie dane są szyfrowane w miejscu docelowym przez aplikację lub usługę, która je otrzymuje. W przypadku szyfrowania server-side można wybrać jeden z trzech typów niestandardowych kluczy głównych (CMK) udostępnianych przez usługę AWS Key Management Service (KMS). Poniższa tabela zawiera porównanie ich funkcji.

Jeśli pozwalają na to wymagania dotyczące bezpieczeństwa i zgodności, szyfrowanie po stronie serwera jest wygodniejsze, ponieważ uwierzytelnione żądania z wymaganymi uprawnieniami mogą uzyskiwać dostęp do zaszyfrowanych obiektów w taki sam sposób, jak do niezaszyfrowanych obiektów. Jeśli używasz AWS KMS CMK do szyfrowania danych źródłowych i wyjściowych bucketów S3, musisz również upewnić się, że rola wykonawcza notebooka ma niezbędne uprawnienia do szyfrowania i odszyfrowywania za pomocą CMK. Podczas tworzenia instancji notebooka można określić wymaganą rolę, a także włączyć szyfrowanie AWS KMS CMK dla woluminów danych, jak pokazano na rysunku 7. Od tego momentu szyfrowanie można włączyć tylko w momencie tworzenia notebooka.

Rysunek 7. Określanie roli wykonawczej z uprawnieniami do szyfrowania/odszyfrowywania i włączanie szyfrowania dla dołączonych woluminów danych

S3 oferuje domyślne szyfrowanie, które szyfruje wszystkie nowe obiekty za pomocą szyfrowania server-side. Ponadto zalecamy stosowanie polityk bucketu S3, aby zapobiec przesyłaniu niezaszyfrowanych obiektów.

Wraz ze wzrostem rozmiaru danych możesz zautomatyzować proces identyfikacji i ochrony wrażliwych danych na dużą skalę, korzystając z Amazon Macie. Macie nieustannie ocenia twoje buckety S3 i automatycznie generuje spis ich rozmiaru i stanu, który obejmuje dostęp prywatny lub publiczny, dostęp współdzielony z innymi kontami AWS oraz stan szyfrowania. Macie używa również ML i dopasowywania wzorców do identyfikacji, i ostrzegania o danych wrażliwych, takich jak dane osobowe (PII - personally identifiable information), a te alerty można zintegrować z workflowem ML, aby podjąć automatyczne działania naprawcze. Zalecamy włączenie Amazon GuardDuty w celu monitorowania operacji interfejsu API S3 w zdarzeniach CloudTrail pod kątem podejrzanego dostępu do danych w bucketach S3. GuardDuty analizuje również VPC Flow Logs i logi DNS, aby wykryć nieautoryzowaną lub nieoczekiwaną aktywność w Twoim środowisku.

Używanie Secrets Manager do ochrony danych logowania

Aby uzyskać dostęp do danych w celu trenowania, początkujący data scientist może nieumyślnie osadzić dane dostępu do baz danych bezpośrednio w swoim kodzie. Dane te są widoczne dla każdej osoby trzeciej badającej kod.

Zalecamy użycie AWS Secrets Manager do przechowywania swoich danych logowania, a następnie udzielenie uprawnień do roli SageMaker IAM w celu uzyskania dostępu do Secrets Manager z notebooka. Rysunek 8 przedstawia przykład przechowywania tych danych w Secrets Manager w konsoli.

Rysunek 8. Przechowywanie danych dostępu do bazy danych RDS w konsoli Secrets Manager

Secrets Manager umożliwia zastąpienie zakodowanych sekretów w kodzie, takich jak dane dostępu, wywołaniem interfejsu API do programu Secrets Manager w celu programowego odszyfrowania i odzyskania obiektu secret. Konsola zawiera przykładowy kod, który pobiera wpis w aplikacji, jak pokazano na rysunku 9.

Rysunek 9. Przykładowy kod w konsoli Secrets Manager pobierający dane wrażliwe

Powinieneś także skonfigurować Secrets Managera, aby automatycznie wymuszał zmianę hasła dostępu, zgodnie z określonym harmonogramem. Umożliwia to zastąpienie długoterminowych danych krótkoterminowymi, co może znacznie zmniejszyć ryzyko ujawnienia poświadczeń.

Monitorowanie danych wejściowych i wyjściowych

Po wdrożeniu modelu ML ważne jest, aby stale monitorować zarówno jego dane wejściowe, jak i wyjściowe. Model może stracić dokładność prognoz, gdy statystyczny charakter danych wejściowych, które model otrzymuje podczas produkcji, odbiegnie od statystycznego charakteru danych, na których był trenowany. Konieczne są dalsze badania w celu ustalenia, czy te dryfty odzwierciedlają zmiany w świecie rzeczywistym lub wskazują na możliwość tzw. data poisoning.

Aby monitorować modele w produkcji, należy używać Amazon SageMaker Model Monitor do wykrywania i ostrzegania o zmianach w danych i wydajności modelu. Po obliczeniu początkowych planów bazowych można zaplanować zadania monitorowania zarówno dla danych wejściowych, jak i wyjściowych modelu. Aby pomóc Ci w jakości danych, SageMaker Model Monitor oferuje predefiniowane statystyki, takie jak liczba brakujących danych, a także statystyki specyficzne dla każdego typu zmiennej (np. średnia i odchylenie standardowe dla zmiennych numerycznych, liczniki kategorii dla zmiennych łańcuchowych). Możesz także zdefiniować własne statystyki niestandardowe. Aby pomóc Ci w jakości modelu, SageMaker Model Monitor oferuje wspólne metryki oceny dla regresji, klasyfikacji binarnej i problemów z wieloma klasami. Rysunek 10 przedstawia przykład, w jaki sposób wyniki zadań monitorowania pojawiają się w Amazon SageMaker Studio. 

Rysunek 10: Dryfty wydajności SageMaker Model Monitor wyświetlane w SageMaker Studio

Aby uzyskać więcej informacji na temat korzystania z SageMaker Model Monitor, w tym instrukcje określania podstawowych statystyk i wskaźników, które chcesz monitorować, zobacz Monitor Data Quality i Monitor Model Quality w Amazon SageMaker Developer Guide.

SageMaker Model Monitor przechowuje wyniki monitorowania w Amazon CloudWatch. Możesz skonfigurować alarmy CloudWatch za pomocą konsoli CloudWatch lub SageMaker notebook, aby otrzymywać powiadomienia, gdy jakość modelu odchyli się od progów linii bazowej. Możesz wyświetlić stan alarmów CloudWatch z konsoli, jak pokazano na rysunku 11.

Rysunek 11. Nowo utworzony alarm CloudWatch w stanie INSUFFICIENT_DATA

Po utworzeninu alarm CloudWatch  pokazuje stan początkowy INSUFFICIENT_DATA. Z biegiem czasu będzie wyświetlał stan OK lub ALARM, jak pokazano to na rysunku 12.

Rysunek 12. Alarm CloudWatch w stanie ALARM

Po utworzeniu alarmu można ustawić działania zaradcze, które mają zostać podjęte w przypadku tych alertów, takie jak ponowny trening modelu lub aktualizacja danych szkoleniowych.

Włączanie logowania w celu uzyskania dostępu do modelu

Po zbudowaniu i wdrożeniu modelu ML można go obsługiwać za pomocą Amazon API Gateway, aby umożliwić użytkownikom końcowym wywoływanie go w celu prognozowania w czasie rzeczywistym. Aby zbadać wzorce dostępu swojego API, należy przyznać API Gateway uprawnienia do odczytu i zapisu logów w CloudWatch, a następnie włączyć CloudWatch Logs za pomocą API Gateway. Access logging prowadzi rejestr tego, kto uzyskał dostęp do interfejsu API oraz w jaki sposób wywołujący uzyskał dostęp do interfejsu API. Możesz utworzyć własną grupę logów lub wybrać istniejącą grupę logów zarządzaną przez API Gateway. Poniżej przedstawiono przykładowe dane wyjściowe logu dostępu:

Możesz włączyć rejestrowanie dostępu za pomocą konsoli API Gateway, jak pokazano na rysunku 13. Aby uzyskać więcej informacji, zobacz Setting up CloudWatch logging for a REST API in API Gateway.

Rysunek 13. Udostępnianie logów w konsoli API Gateway

Luki w zabezpieczeniach specyficzne dla ML, takie jak membership inference i model inversion, czasami obejmują powtarzające się wywołania interfejsu API w celu uzyskania informacji o zestawie danych szkoleniowych lub modelu. Aby ograniczyć, kto może korzystać z modelu, zalecamy ochronę API Gateway za pomocą AWS WAF, który umożliwia konfigurowanie reguł w celu blokowania żądań z określonych adresów IP lub ograniczenia liczby żądań internetowych dozwolonych przez każdy adres IP klienta w końcowym przedziale czasowym.

Używanie kontroli wersji dla model artifacts

Zalecamy korzystanie z kontroli wersji do śledzenia kodu lub innych tzw. model artifacts. Jeśli zostaną one zmodyfikowane lub usunięte, przypadkowo lub celowo, kontrola wersji umożliwia przywrócenie poprzedniej stabilnej wersji. Może to być wykorzystane w przypadku, gdy nieautoryzowany użytkownik uzyska dostęp do Twojego środowiska i dokona zmian w Twoim modelu.

Jeśli model artifacts są przechowywane w Amazon S3, należy włączyć przechowywanie wersji w nowym lub istniejącym buckecie S3. Zalecamy również sparowanie wersji Amazon S3 z usuwaniem z uwierzytelnianiem wieloskładnikowym (MFA), aby mieć pewność, że tylko użytkownicy uwierzytelnieni za pomocą usługi MFA mogą trwale usunąć wersję obiektu lub zmienić stan wersji zasobnika.

Innym sposobem włączenia kontroli wersji jest powiązanie repozytoriów Git z nowymi lub istniejącymi notebook instancjami SageMaker. SageMaker obsługuje AWS CodeCommit, GitHub i inne repozytoria oparte o Git. Korzystając z CodeCommit, możesz dodatkowo zabezpieczyć repozytorium,  korzystając z rotating credentials i włączając usługę MFA.

Podsumowanie

W tym poście podsumowano podstawowe mechanizmy zabezpieczeń, nad którymi data scientists i security engineers mogą współpracować, aby zbudować bezpieczniejszą infrastrukturę ML.

Aby uzyskać więcej informacji na temat zabezpieczania ML workflow w AWS, zobacz następujące zasoby:

• Machine learning best practices in financial services na blogu AWS Machine Learning
• Secure deployment of Amazon SageMaker resources na blogu AWS Security
• Build a secure ML environment with SageMaker w Amazon SageMaker Workshop
• Provision a secure ML environment with SageMaker and run an end-to-end example w Amazon SageMaker Workshop
• Amazon SageMaker with Guardrails on AWS Quick Start

źródło: AWS