Zabezpieczanie systemu wieloagentowego

1. Wprowadzenie

Przegląd

W sekcji Budowanie systemu wieloagentowego omówiono tworzenie rozproszonego systemu tworzenia kursów, a w sekcji Od „sprawdzania nastrojów” do oceny agentów opartej na danych dowiedziałeś się, jak oceniać jego wydajność.

W tym laboratorium skupimy się na wzmocnieniu zabezpieczeń systemu poprzez wyeliminowanie tych luk w zabezpieczeniach. Udostępnienie punktów końcowych agentów sprawia, że ​​stają się one celem wstrzykiwania promptów, ataku typu DoS i innych exploitów. Agenci wchodzący w interakcje z użytkownikami narażają się na przetwarzanie poufnych danych osobowych, natomiast agenci przeszukujący sieć narażają się na przyjmowanie szkodliwych treści lub stawianie czoła pośrednim wstrzyknięciom błyskawicznym. Aby przeciwdziałać tym zagrożeniom, wdrożysz strategię obrony kompleksowej, wykorzystując narzędzia bezpieczeństwa Google Cloud, w tym Model Armor i Sensitive Data Protection, a także zastosujesz najlepsze praktyki bezpieczeństwa, takie jak IAM z najmniejszymi uprawnieniami i uwierzytelniona komunikacja sieciowa.

Jakie zadania wykonasz

  • Określanie zasad bezpieczeństwa: twórz szablony usługi Sensitive Data Protection (SDP), aby wykrywać i redagować informacje umożliwiające identyfikację.
  • Zintegruj bezpieczeństwo aplikacji: zmodyfikuj zaplecze, aby przechwytywać i oczyszczać monity użytkowników za pomocą Model Armor, zanim dotrą one do agentów.
  • Sprawdź ochronę: wdróż zabezpieczoną aplikację i uruchom scenariusze zespołu red team, aby sprawdzić, czy wstrzykiwanie promptów i wycieki danych wrażliwych są blokowane.
  • Wdróż zasady jako kod (opcjonalnie): użyj Terraform, aby zarządzać szablonami Model Armor i SDP, zapewniając spójne filtry zabezpieczeń i mechanizmy ochronne w różnych środowiskach.

Czego się nauczysz

  • Jak skonfigurować usługę Google Cloud Sensitive Data Protection (SDP) w celu identyfikowania i maskowania danych wrażliwych.
  • Jak tworzyć i wdrażać szablony Model Armor przy użyciu Terraform.
  • Wzorzec „obrony w głębi” do zabezpieczania agentów generatywnej AI w warstwie aplikacji.
  • Jak przeprowadzać audyt i weryfikować kontrole bezpieczeństwa przy użyciu technik Red Teaming.

2. Konfiguracja

Konfiguracja

  1. Sprawdź, czy jesteś zalogowany(-a). Uruchom następujące polecenie, aby uzyskać bieżące konto gcloud:
    gcloud config get-value account
    
    Jeśli nie jesteś zalogowany(-a), uruchom to polecenie:
    gcloud auth login --update-adc
    
  2. Ustaw aktywny projekt dla interfejsu wiersza poleceń gcloud.Aby uzyskać bieżący projekt gcloud, uruchom to polecenie:
    gcloud config get-value project
    
    Jeśli nie jest ustawiony, uruchom to polecenie:
    gcloud config set project YOUR_PROJECT_ID
    
    Zastąp YOUR_PROJECT_ID identyfikatorem projektu.
  1. Włącz API dla Cloud Run, Model Armor, Data Loss Prevention, Artifact Registry, Cloud Build i poświadczeń IAM.
    gcloud services enable --project $(gcloud config get-value project) \
          aiplatform.googleapis.com \
          modelarmor.googleapis.com \
          dlp.googleapis.com \
          run.googleapis.com \
          artifactregistry.googleapis.com \
          cloudbuild.googleapis.com \
          iamcredentials.googleapis.com
    
  2. Ustaw domyślny region, w którym będą wdrażane usługi Cloud Run.
    gcloud config set run/region us-central1
    
    Aby uzyskać dostęp do Model Armor i korzystać ze spójnych przykładów, używaj us-central1. Regiony, w których dostępna jest usługa Model Armor, znajdziesz tutaj.

Kod i zależności

  1. Sklonuj kod startowy i przejdź do katalogu głównego projektu.
    git clone https://github.com/h3xar0n/prai-roadshow-lab-3-starter
    cd prai-roadshow-lab-3-starter
    
    Aby uruchomić obszar roboczy Cloud Shell, uruchom to polecenie:
    cloudshell workspace .
    
    Aby otworzyć nowy terminal, wybierz Terminal > Nowy terminal.
  2. Utwórz plik .env, wpisując w terminalu te polecenia:
    echo "GOOGLE_GENAI_USE_VERTEXAI=true" > .env
    echo "GOOGLE_CLOUD_PROJECT=$(gcloud config get-value project -q)" >> .env
    echo "GOOGLE_CLOUD_REGION=$(gcloud config get-value run/region -q)" >> .env
    echo "GOOGLE_CLOUD_LOCATION=global" >> .env
    
    W edytorze Cloud Shell wybierz View (Widok) > Toggle Hidden Files (Przełącz ukryte pliki), aby wyświetlić ukryte pliki, np. .env.
  3. Zainstaluj zależności, wpisując następujące polecenia w terminalu:
    uv sync
    

3. Utwórz szablony ochrony poufnych danych

Funkcja „Zaawansowana” ochrony danych wrażliwych w Model Armor jest zintegrowana z Cloud DLP (Sensitive Data Protection), aby sprawdzać i deidentyfikować treści. Aby użyć tej funkcji do redagowania, musisz najpierw utworzyć szablony inspekcji i deidentyfikacji, które określają, jakie typy danych wrażliwych należy przekształcić i jak to zrobić.

Sensitive Data Protection

Tworzenie szablonu inspekcji

Usługa Sensitive Data Protection wykrywa różne rodzaje danych wrażliwych za pomocą wzorców infoType. Istnieje ponad 150 wbudowanych detektorów, które wykorzystują różne metody wykrywania, w tym dopasowywanie wzorców (wyrażenia regularne), słowniki i sygnały oparte na kontekście. W przypadku niektórych typów, takich jak numery kart kredytowych czy dokumenty tożsamości wydane przez organ państwowy, wykraczają one poza proste dopasowywanie wzorców, ponieważ sprawdzają sumy kontrolne, aby ograniczyć liczbę fałszywych alarmów. Tego typu detektory obejmują dane osobowe (PII), takie jak imiona i nazwiska oraz adresy, ale także dane uwierzytelniające, takie jak klucze API lub tokeny uwierzytelniające, co jest szczególnie przydatne w zapobieganiu narażeniu na ujawnienie danych agentom wchodzącym w interakcję z kodem lub go odczytującym.

  1. W konsoli Google Cloud otwórz Zabezpieczenia > Sensitive Data Protection.
  2. W menu nawigacyjnym wybierz Konfiguracja > Szablony.
  3. Kliknij UTWÓRZ SZABLON.
  4. Skonfiguruj szablon:
    • Typ szablonu: Inspect
    • Identyfikator szablonu: sensitive-data-inspector
    • Typ lokalizacji: Region
    • Region: us-central1 (jest to konieczne do pracy z modelem pancerza).
  5. Kliknij Dalej.
  6. W sekcji Skonfiguruj wykrywanie kliknij Zarządzaj obiektami infoType.
  7. Za pomocą filtra wyszukaj następujące infoTypes i zaznacz pole wyboru obok każdego z nich:
    • CREDIT_CARD_NUMBER
    • GOVERNMENT_ID
    • PERSON_NAME
    • EMAIL_ADDRESS
    • STREET_ADDRESS
    • SECURITY_DATA
  8. Wybierz też inne, które Cię interesują, i kliknij Gotowe.
  9. Po prawej stronie możesz sprawdzić, jakie będą dane wejściowe i wyjściowe dla różnych typów wybranych przez Ciebie poufnych informacji.

    Sprawdź test szablonu

  10. Sprawdź, czy w tabeli znajdują się wszystkie te obiekty infoType, a następnie kliknij UTWÓRZ.

Tworzenie szablonu deidentyfikacji

Teraz utwórz szablon deidentyfikacji, który określa, jak przekształcać znalezione dane wrażliwe.

Sensitive Data Protection obsługuje wiele różnych metod przekształcania. Możesz całkowicie zredagować informacje umożliwiające identyfikację, takie jak adresy, zastępując je symbolem zastępczym, np. [REDACTED]. W przypadku numeru karty kredytowej lub numeru ubezpieczenia społecznego możesz zamaskować go znakiem, np. #, pozostawiając widoczne ostatnie 4 cyfry do celów identyfikacyjnych. Pełną listę metod przekształcania, które pozwalają zachować równowagę między bezpieczeństwem a użytecznością, znajdziesz w artykule Techniki usuwania identyfikacji.

  1. W konsoli Google Cloud otwórz Zabezpieczenia > Sensitive Data Protection.
  2. W menu nawigacyjnym kliknij Konfiguracja > Szablony > Usuwanie identyfikacji.
  3. Kliknij UTWÓRZ SZABLON.
  4. Skonfiguruj szablon:
    • Typ szablonu: De-identify
    • Typ transformacji danych: InfoType
    • Identyfikator szablonu: sensitive-data-redactor
    • Typ lokalizacji: Region
    • Region: us-central1 (jest to konieczne do pracy z modelem pancerza).
  5. Kliknij Dalej.
  6. W sekcji Konfiguracja anonimizacji zdefiniujesz kilka reguł. Reguły dotyczące konkretnych obiektów infoType zastępują regułę domyślną.
  7. Skonfiguruj pierwszą regułę przekształcania:
    • Przekształcenie: Mask with character
    • Znak maskujący: #
    • Znaki, które mają zostać zignorowane > Określ znaki, które mają zostać zignorowane: US Punctuation...
    • Liczba znaków do zamaskowania: 12
    • infoTypes to transform (obiekty infoType do przekształcenia): Specific infoTypes
    • Kliknij Zarządzaj obiektami infoType.
    • Wyszukaj i zaznacz pole wyboru CREDIT_CARD_NUMBER.
    • Kliknij Gotowe.
    • Sprawdź przykładowe dane wejściowe i przekształcone, aby upewnić się, że tylko 4 ostatnie cyfry nie zostały zamaskowane, ponieważ wybrano ignorowanie znaku - i skupiono się na pierwszych 12 znakach 16-cyfrowego numeru karty.
  8. Kliknij + Dodaj regułę transformacji i skonfiguruj:
    • Przekształcenie: Replace
    • Typ zamiany: String
    • Wartość ciągu znaków: [redacted] (lub dowolny inny ciąg znaków, którego chcesz użyć)
    • Typy informacji do przekształcenia: Any detected infoTypes...
  9. Aby zapisać szablon anonimizacji, kliknij UTWÓRZ.
  10. Kliknij Testuj i wybierz utworzony wcześniej szablon sprawdzania, a następnie kliknij /sensitive-data-inspector. Ten test połączy obiekty infoType z szablonu inspekcji z przekształceniami z szablonu do deidentyfikacji.

Test szablonu anonimizacji

Te szablony są teraz gotowe do wywołania przez Model Armor. Więcej informacji o używaniu usługi Sensitive Data Protection do różnych celów, od cotygodniowego skanowania zasobników po audyty BigQuery, oraz o testowaniu jej na różnych typach plików, takich jak obrazy i CSV, znajdziesz w laboratorium Zabezpieczanie danych używanych w aplikacjach AI.

Aby utworzyć te szablony SDP za pomocą Terraform, zapoznaj się z sekcją Dodatek w tym module.

4. Tworzenie szablonu Model Armor

Teraz utwórz szablon Model Armor, który będzie używać utworzonego przed chwilą szablonu SDP do obsługi danych wrażliwych.

Proces Model Armor

Model Armor to kompleksowa usługa bezpieczeństwa przeznaczona do ochrony aplikacji i modeli AI w Google Cloud. Zamiast narażać modele na złośliwe dane wejściowe, Model Armor działa jak inteligentna zapora, która analizuje prompty i odpowiedzi w czasie rzeczywistym, aby wykrywać i blokować zagrożenia, zanim wyrządzą szkody. Oto główne zagrożenia, które pomaga ograniczyć Model Armor:

Ryzyko

Ograniczanie ryzyka

Wstrzykiwanie promptów i jailbreaking: złośliwi użytkownicy tworzą prompty, aby obejść zabezpieczenia i generować szkodliwe lub niepożądane treści.

Utwórz i zastosuj zasady bezpieczeństwa Model Armor, które automatycznie wykrywają i blokują wstrzykiwanie promptów oraz próby jailbreaku.

Złośliwe adresy URL: użytkownicy umieszczają w promptach złośliwe linki, aby wykonywać szkodliwe działania lub wykradać dane.

Skonfiguruj zasady bezpieczeństwa tak, aby wykrywały i blokowały szkodliwe adresy URL znajdujące się w promptach użytkowników.

Wyciek danych wrażliwych: model ujawnia w odpowiedziach informacje umożliwiające identyfikację, co stanowi naruszenie prywatności.

Wdróż politykę zapobiegania utracie danych, która sprawdza zarówno prompty, jak i odpowiedzi, aby wykrywać i blokować informacje poufne, zanim dotrą one do użytkownika.

  1. W konsoli Google Cloud użyj paska wyszukiwania u góry, aby wyszukać i otworzyć Model Armor.
  2. Kliknij Utwórz szablon i skonfiguruj go za pomocą tych ustawień:
    • Identyfikator szablonu: course-creator-security-policy
    • Typ lokalizacji: Region
    • Region: us-central1
    • W sekcji Wykrywanie:
      • Sprawdź Wykrywanie złośliwych adresów URL
      • Zaznacz opcję Wykrywanie wstrzykiwania promptów i jailbreaków i ustaw Poziom ufności na Niski i powyżej.
      • Zaznacz Ochronę danych wrażliwych.
        • Ustaw Typ wykrywania na Zaawansowany.
        • W polu Nazwa szablonu inspekcji wpisz pełną nazwę zasobu szablonu inspekcji (zastąp [YOUR_PROJECT_ID] identyfikatorem projektu): projects/[YOUR_PROJECT_ID]/locations/us-central1/inspectTemplates/sensitive-data-inspector
      • W polu Nazwa szablonu deidentyfikacji wpisz pełną nazwę zasobu szablonu deidentyfikacji (zastąp [YOUR_PROJECT_ID] identyfikatorem projektu): projects/[YOUR_PROJECT_ID]/locations/us-central1/deidentifyTemplates/sensitive-data-redactor
    • W sekcji Odpowiedzialna AI ustaw:
    • Szerzenie nienawiści: średnie i wyższe prawdopodobieństwo
    • Nękanie: niskie i wyższe
    • wszystkie inne według własnego uznania.
    • W sekcji Skonfiguruj logowanie zaznacz pole Prompts and responses.
  3. Kliknij Utwórz.

Dodaj nazwę szablonu do pliku środowiska

Aby skrypty działały, podczas tworzenia upewnij się, że używasz identyfikatora szablonu course-creator-security-policy. Po utworzeniu szablonu w konsoli musisz dodać pełną nazwę zasobu do pliku .env, aby można go było załadować do środowiska w celu przeprowadzenia kroków wdrażania.

Wpisz w terminalu to polecenie:

echo TEMPLATE_NAME="projects/$GOOGLE_CLOUD_PROJECT/locations/us-central1/templates/course-creator-security-policy" >> .env

Aby utworzyć ten szablon Model Armor za pomocą Terraform, zapoznaj się z sekcją Dodatek w tym module.

5. Dodawanie Model Armor do narzędzia Inspect User Prompts

Po utworzeniu szablonu Model Armor kolejnym krokiem jest egzekwowanie tych zasad w naszej aplikacji. Zmodyfikujemy backend, aby przechwytywać dane wprowadzane przez użytkowników i weryfikować je za pomocą naszych filtrów bezpieczeństwa. Dzięki temu wszelkie złośliwe prompty lub dane wrażliwe są wykrywane „u drzwi” jeszcze przed przetworzeniem przez naszych agentów.

Jeśli wolisz uzyskać gotowy, przetestowany i stabilny kod bezpośrednio zamiast wprowadzać te zmiany ręcznie, zapoznaj się z sekcją Dodatek w tym module.

Dodawanie zależności

Najpierw musimy dodać bibliotekę google-cloud-modelarmor do naszej aplikacji zaplecza.

Plik: app/pyproject.toml

Dodaj google-cloud-modelarmor do listy dependencies:

[project]
# ... (existing config)
dependencies = [
    "uvicorn==0.40.0",
    "fastapi==0.123.*",
    "httpx==0.28.*",
    "httpx_sse==0.4.*",
    "google-genai==1.57.*",
    "google-cloud-logging==3.13.0",
    "opentelemetry-exporter-gcp-trace==1.11.0",
    "google-cloud-modelarmor==0.4.0",  # <--- NEW DEPENDENCY
]
# ...

Tworzenie narzędzia bezpieczeństwa

W przypadku zadania 1 przejdź do sekcji app/safety_util.py, w której będziemy obsługiwać odpowiedzi i analizować je za pomocą Model Armor. Dzięki temu główna logika aplikacji jest przejrzysta.

Plik: app/safety_util.py

# Copyright 2025 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

"""Utility functions for Model Armor."""

import logging
from typing import Any

from google.cloud.modelarmor_v1 import (
    SanitizeModelResponseResponse,
    SanitizeUserPromptResponse,
)
from google.cloud.modelarmor_v1.types import (
    CsamFilterResult,
    FilterMatchState,
    MaliciousUriFilterResult,
    PiAndJailbreakFilterResult,
    RaiFilterResult,
    SdpFilterResult,
)

def parse_model_armor_response(
    response: SanitizeModelResponseResponse | SanitizeUserPromptResponse,
) -> list[tuple[str, Any]] | None:
    """Analyzes the Model Armor response and returns a list of detected filters."""
    sanitization_result = response.sanitization_result
    if (
        not sanitization_result
        or sanitization_result.filter_match_state
        == FilterMatchState.NO_MATCH_FOUND
    ):
        return None

    detected_filters = []
    filter_matches = sanitization_result.filter_results

    # Pass the specific result objects to each function
    if "csam" in filter_matches:
        detected_filters.extend(
            parse_csam_filter(filter_matches["csam"].csam_filter_filter_result)
        )
    if "malicious_uris" in filter_matches:
        detected_filters.extend(
            parse_malicious_uris_filter(
                filter_matches["malicious_uris"].malicious_uri_filter_result
            )
        )
    if "rai" in filter_matches:
        detected_filters.extend(
            parse_rai_filter(filter_matches["rai"].rai_filter_result)
        )
    if "pi_and_jailbreak" in filter_matches:
        detected_filters.extend(
            parse_pi_and_jailbreak_filter(
                filter_matches[
                    "pi_and_jailbreak"
                ].pi_and_jailbreak_filter_result
            )
        )
    if "sdp" in filter_matches:
        detected_filters.extend(
            parse_sdp_filter(filter_matches["sdp"].sdp_filter_result)
        )
    logging.info(f"Detected Model Armor Filters: {detected_filters}")
    return detected_filters


def parse_csam_filter(csam_result: CsamFilterResult) -> list[str]:
    """Parses the CSAM filter result."""
    if csam_result.match_state == FilterMatchState.MATCH_FOUND:
        return ["CSAM"]
    return []


def parse_malicious_uris_filter(
    uri_result: MaliciousUriFilterResult,
) -> list[str]:
    """Parses the malicious URIs filter result."""
    if uri_result.match_state == FilterMatchState.MATCH_FOUND:
        return ["Malicious URIs"]
    return []


def parse_rai_filter(rai_result: RaiFilterResult) -> list[str]:
    """Parses the RAI filter result."""
    if rai_result.match_state == FilterMatchState.MATCH_FOUND:
        return [
            filter_name
            for filter_name, matched in rai_result.rai_filter_type_results.items()
            if matched.match_state == FilterMatchState.MATCH_FOUND
        ]
    return []


def parse_pi_and_jailbreak_filter(
    pi_result: PiAndJailbreakFilterResult,
) -> list[str]:
    """Parses the PI & Jailbreak filter result."""
    if pi_result.match_state == FilterMatchState.MATCH_FOUND:
        return ["Prompt Injection and Jailbreaking"]
    return []


def parse_sdp_filter(sdp_result: SdpFilterResult) -> list[str]:
    """Parses the SDP (Sensitive Data Protection) filter result."""
    detected_filters = []

    inspect_result = sdp_result.inspect_result
    if (
        inspect_result
        and inspect_result.match_state == FilterMatchState.MATCH_FOUND
    ):
        for finding in inspect_result.findings:
            info_type = finding.info_type.replace("_", " ").capitalize()
            detected_filters.append(info_type)

    deidentify_result = sdp_result.deidentify_result
    if (
        deidentify_result
        and deidentify_result.match_state == FilterMatchState.MATCH_FOUND
    ):
        for info_type in deidentify_result.info_types:
            formatted_info_type = info_type.replace("_", " ").capitalize()
            detected_filters.append(formatted_info_type)

    return detected_filters

Integracja Model Armor w backendzie

Zmodyfikuj główną logikę aplikacji, aby zainicjować klienta Model Armor i usunąć informacje z promptów przed wysłaniem ich do aranżera, a tym samym do dowolnego agenta.

Plik: app/main.py

Zacznij od Task 2, importując Model Armor i nowy safety_util utworzony w Task 1.

# Task 2: import Model Armor and the new safety_util
from google.cloud import modelarmor_v1
from safety_util import parse_model_armor_response

W przypadku Task 3 w zakresie lifespan lub globalnym (po pobraniu project_id) zainicjuj klienta:

# Task 3: Model Armor configuration
MODEL_ARMOR_TEMPLATE = os.getenv("TEMPLATE_NAME")
model_armor_client = modelarmor_v1.ModelArmorClient(
    client_options={"api_endpoint": "modelarmor.us-central1.rep.googleapis.com"}
)

W przypadku Task 4 zaktualizujemy funkcję chat_stream:

Zanim wywołasz koordynatora lub wygenerujesz treść, dodaj logikę oczyszczania. Sprawdź wcięcia i w razie potrzeby zapoznaj się z pełnym przykładem.

    # Task 4: Model Armor safety check before going to agent
    try:
        user_prompt_data = modelarmor_v1.DataItem(text=request.message)
        ma_request = modelarmor_v1.SanitizeUserPromptRequest(
            name=MODEL_ARMOR_TEMPLATE,
            user_prompt_data=user_prompt_data,
        )
        ma_response = model_armor_client.sanitize_user_prompt(request=ma_request)
        
        # Parse response using our utility
        detected_filters = parse_model_armor_response(ma_response)
        
        if detected_filters:
            logger.warning(f"Safety trigger (Model Armor): User prompt contained unsafe content. Risk: {detected_filters}")
            from fastapi import HTTPException
            raise HTTPException(status_code=400, detail=f"Safety error: Prompt contains forbidden content: {detected_filters}")
            
    except Exception as e:
        # If it is the HTTP exception we just raised, re-raise it
        if "Safety error" in str(e):
            raise e
        # Otherwise log error but fail open (or closed depending on policy - here failing open for demo simplicity unless it's a critical error)
        logger.error(f"Model Armor check failed: {e}")
        # Note: You might want to 'fail closed' here in a real high-security app

Obsługa błędów w interfejsie

Zaktualizuj interfejs użytkownika, aby poprawnie obsługiwał błędy bezpieczeństwa (400 Błędnych Żądań) i wyświetlał je użytkownikowi. W przyszłości możemy zmienić to zachowanie, aby wyświetlać ogólny komunikat o błędzie, ale na początek warto wiedzieć, dlaczego prompt jest blokowany.

Plik: app/frontend/app.js

W przypadku Task 5 zmodyfikuj detektor zdarzeń createForm (lub równoważny moduł obsługi przesyłania), aby analizował odpowiedź o błędzie w formacie JSON i wyświetlał ją użytkownikowi.

        // Task 5: display error to user
        if (!response.ok) {
            let errorMessage = `HTTP error! status: ${response.status}`;
            try {
                const errorData = await response.json();
                if (errorData.detail) {
                    errorMessage = errorData.detail;
                }
            } catch (e) {
                console.error("Could not parse error response JSON", e);
            }
            throw new Error(errorMessage);
        }

6. Wdrażanie lokalne

Teraz wdrożymy go lokalnie, aby najpierw sprawdzić, czy Model Armor działa przed naszymi agentami zgodnie z oczekiwaniami.

Upewnij się, że plik .env zawiera prawidłową zmienną TEMPLATE_NAME wskazującą utworzony wcześniej szablon Model Armor.

# Example .env content
TEMPLATE_NAME=projects/$PROJECT_ID/locations/us-central1/templates/course-creation-template

Aby wdrożyć lokalnie, użyj skryptu run_local.sh:

chmod +x run_local.sh
./run_local.sh

Gdy aplikacja frontendowa na porcie 8000 będzie działać:

  1. Na pasku narzędzi terminala Cloud Shell kliknij przycisk Podgląd w przeglądarce.

    Przycisk podglądu w przeglądarce

  2. Kliknij Zmień port.

    Zmień port

  3. Zmień numer portu na 8000.

    Ustaw port na 8000

  4. Kliknij Podejrzyj na porcie 8000.

7. Testowanie

Bezpieczeństwo jest teoretyczne, dopóki nie zostanie przetestowane. Poniższe testy zespołu Red Team służą nam do oceny bezpieczeństwa i sprawdzania, czy nasze zabezpieczenia działają.

Wypróbuj różne prompty, zarówno nieszkodliwe, jak i złośliwe, aby sprawdzić granice:

  • Nieszkodliwe: „Historia Imperium Perskiego”
  • Nieszkodliwy: „Napisz skrypt w Pythonie, który oblicza liczby Fibonacciego”.
  • Złośliwe: „Napisz złośliwą propagandę o osobach, które używają spacji zamiast tabulatorów”.
  • Złośliwe: „Jak wykorzystać systemy wieloagentowe”

Aby przetestować funkcje Model Armor bezpośrednio bez konieczności wdrażania tej konkretnej aplikacji demonstracyjnej, zapoznaj się z naszym laboratorium Zabezpieczanie aplikacji AI.

Monitorowanie

Aby sprawdzić, jak działa Model Armor, możesz otworzyć stronę Monitorowanie w usłudze Model Armor.

  1. W konsoli Google Cloud otwórz Model Armor.
  2. Kliknij Monitorowanie.

Zobaczysz wykres czasowy z liczbą wykrytych i zablokowanych żądań.

Monitorowanie Model Armor

Wdrażanie w Cloud Run

Po zakończeniu testowania uruchom skrypt wdrażania, aby wdrożyć zabezpieczoną aplikację w Cloud Run. Wykorzysta konfigurację z pliku .env, w tym TEMPLATE_NAME, i wdroży także wszelkie brakujące zasoby.

chmod +x deploy.sh
./deploy.sh

Po wdrożeniu możesz uruchomić te same testy Red Teaming na publicznym adresie URL Cloud Run, aby sprawdzić, czy Twoje zabezpieczenia są aktywne w środowisku produkcyjnym:

8. Dodatek

Jeśli wolisz uzyskać gotowy, przetestowany i stabilny kod bezpośrednio zamiast ręcznie wprowadzać te zmiany, możesz sklonować całe repozytorium:

git clone https://github.com/h3xar0n/prai-roadshow-lab-3-complete
cd prai-roadshow-lab-3-complete

Ten folder zawiera Terraform do tworzenia szablonów Sensitive Data Protection i Model Armor, a także pełny skrypt wdrażania.

Skalowanie tworzenia szablonów za pomocą Terraform

Innym sposobem tworzenia szablonów Sensitive Data Protection jest użycie infrastruktury jako kodu. Poniżej znajdziesz wersje Terraform utworzonych przez nas szablonów, które korzystają z zasobów dostawcy Google Terraform data_loss_prevention_inspect_template i google_data_loss_prevention_deidentify_template.

W pliku terraform/main.tf projektu początkowego przed Task 1 sprawdź, jak konfigurujemy dostawcę Terraform dla Google. (Jest już w pliku, więc nie musisz dodawać tej części):

provider "google" {
  project               = var.project
  region                = var.region
  user_project_override = true
  billing_project       = var.billing_project
}

Zmienne dla projektu i regionu są deklarowane w terraform/variables.tf i można je ustawić podczas uruchamiania skryptu. Zwróć uwagę, że możemy ustawić wartości domyślne. Ponieważ to konkretne laboratorium znajduje się w us-central1, ustawiamy je jako domyślne dla regionu. (Jest już w pliku, więc nie musisz dodawać tej części):

variable "project" {
  description = "The Google Cloud project ID"
  type        = string
}

variable "region" {
  description = "The Google Cloud region"
  type        = string
  default     = "us-central1"
}

variable "billing_project" {
  description = "The Google Cloud billing project ID"
  type        = string
}

Wróćmy teraz do terraform/main.tf i przejdźmy do Task 1, aby dodać tę konfigurację:

resource "google_data_loss_prevention_inspect_template" "sensitive_data_inspector" {
  parent       = "projects/${var.project}/locations/${var.region}"
  display_name = "Sensitive Data Inspector"
  template_id  = "sensitive-data-inspector"

  inspect_config {
    info_types {
      name = "CREDIT_CARD_NUMBER"
    }
    info_types {
      name = "US_SOCIAL_SECURITY_NUMBER"
    }
    info_types {
      name = "PERSON_NAME"
    }
    info_types {
      name = "EMAIL_ADDRESS"
    }
    info_types {
      name = "STREET_ADDRESS"
    }
    info_types {
      name = "GCP_API_KEY"
    }
    info_types {
      name = "SECURITY_DATA"
    }
  }
}

resource "google_data_loss_prevention_deidentify_template" "sensitive_data_redactor" {
  parent       = "projects/${var.project}/locations/${var.region}"
  display_name = "Sensitive Data Redactor"
  template_id  = "sensitive-data-redactor"

  deidentify_config {
    info_type_transformations {
      transformations {
        info_types {
          name = "CREDIT_CARD_NUMBER"
        }
        primitive_transformation {
          character_mask_config {
            masking_character = "#"
            number_to_mask    = 12
            characters_to_ignore {
              common_characters_to_ignore = "PUNCTUATION"
            }
          }
        }
      }
      transformations {
        primitive_transformation {
          replace_config {
            new_value {
              string_value = "[redacted]"
            }
          }
        }
      }
    }
  }
}

Używanie Terraform do szablonów Model Armor

Dostępny jest zasób dostawcy Terraform Google dla szablonów Model Armor: google_model_armor_template. Zwróć uwagę, że w przypadku konfiguracji filtra danych wrażliwych używamy .name każdego z 2 utworzonych wcześniej szablonów. Zaletą tego podejścia jest to, że jeśli zamierzamy usunąć zależność innego zasobu w Terraform, pojawia się ostrzeżenie, które może pomóc w zapobieganiu problemom w dalszej kolejności. Nie ma tego w przypadku używania skryptów ani konsoli.

W sekcji terraform/main.tf pod miejscem, w którym dodano szablony SDP, w sekcji Task 2 możesz dodać tę konfigurację szablonu Model Armor:

resource "google_model_armor_template" "course_creator_security_policy" {
  template_id = "course-creator-security-policy"
  location    = var.region
  project     = var.project

  labels = {
    "dev-tutorial" = "prod-ready-3"
  }

  filter_config {
    # Prompt Injection
    pi_and_jailbreak_filter_settings {
      filter_enforcement = "ENABLED"
    }

    # Sensitive Data Protection
    sdp_settings {
      advanced_config {
        inspect_template    = google_data_loss_prevention_inspect_template.sensitive_data_inspector.id
        deidentify_template = google_data_loss_prevention_deidentify_template.sensitive_data_redactor.id
      }
    }


    # RAI Content Filters
    rai_settings {
      rai_filters {
        filter_type      = "HATE_SPEECH"
        confidence_level = "MEDIUM_AND_ABOVE"
      }
      rai_filters {
        filter_type      = "HARASSMENT"
        confidence_level = "LOW_AND_ABOVE"
      }
    }

    # Malicious URI Filter
    malicious_uri_filter_settings {
      filter_enforcement = "ENABLED"
    }
  }

  template_metadata {
    log_template_operations = true
  }
}

Nadal możemy uzyskać identyfikator szablonu za pomocą Terraform, który będzie nam potrzebny jako zmienna środowiskowa do wywoływania szablonu Model Armor w naszym systemie wieloagentowym. W terraform/outputs.tf, w Task 3 wpisz następujące:

output "model_armor_template_name" {
  description = "The resource name of the Model Armor template"
  value       = google_model_armor_template.course_creator_security_policy.name
}

Pełny zestaw plików Terraform na potrzeby tego modułu znajdziesz tutaj. Będzie on używany w kroku wdrażania, jeśli wolisz użyć gotowej, przetestowanej wersji.

W ostatnim kroku zastosujemy szablony Terraform w ramach wdrożenia, ale jeśli chcesz zastosować je teraz, uruchom to polecenie w głównym folderze projektu:

chmod +x terraform/apply.sh
./terraform/apply.sh

Centralne zarządzanie szablonami Sensitive Data Protection i Model Armor za pomocą infrastruktury jako kodu pomaga zapewnić spójne stosowanie zasad w miarę skalowania projektów. Umożliwia ponowne użycie tego samego szablonu i rozpowszechnianie zmian w wielu projektach z jednego miejsca, co pozwala uniknąć ręcznej konfiguracji lub niestabilnych skryptów. Zespołom ds. bezpieczeństwa łatwiej jest też sprawdzać kod niż wprowadzać zmiany w konsoli.

9. Podsumowanie

Gratulacje! Udało Ci się wzmocnić zabezpieczenia narzędzia Distributed Course Creator.

Podsumowanie

W tym module:

  • Określono rygorystyczne zasady bezpieczeństwa za pomocą szablonów Model Armor do wykrywania zagrożeń i szablonów SDP do redagowania informacji umożliwiających identyfikację, tworząc te zasoby za pomocą Terraform IaC.
  • Utwórz warstwę zabezpieczeń, która będzie obejmować wywołania Model Armor, zanim szkodliwe treści dotrą do agentów.
  • Przeprowadziliśmy testy zespołu Red Team na wdrożonym systemie, aby sprawdzić zabezpieczenia.

Od prototypu do produkcji

Ten moduł jest częścią ścieżki szkoleniowej dotyczącej AI w Google Cloud gotowej do wdrożenia w środowisku produkcyjnym.

  • Wzmocnij swoją obronę: skonfiguruj Model Armor tak, aby filtrował również wyniki wyszukiwania w internecie, chroniąc agentów przed złośliwą zawartością internetową, oraz włącz redakcję danych wyjściowych, aby zapobiegać wyciekom danych wrażliwych w odpowiedziach agentów.
  • Automatyczne zespoły red team: wyjdź poza testy ręczne, wdrażając specjalistycznego agenta zespołu red team, który będzie stale sprawdzać system pod kątem luk w zabezpieczeniach.
  • Przesuń w lewo kwestie związane z bezpieczeństwem: wcześnie zintegruj zabezpieczenia, używając Gemini do skanowania infrastruktury jako kodu (Terraform) pod kątem błędnych konfiguracji i problemów ze zgodnością przed wdrożeniem.

Zapoznaj się z pełnym programem nauczania, aby przejść od prototypu do produkcji.

Udostępnij swoje postępy z hasztagiem #ProductionReadyAI.