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
- Sprawdź, czy jesteś zalogowany(-a). Uruchom następujące polecenie, aby uzyskać bieżące konto gcloud:
Jeśli nie jesteś zalogowany(-a), uruchom to polecenie:gcloud config get-value accountgcloud auth login --update-adc - Ustaw aktywny projekt dla interfejsu wiersza poleceń gcloud.Aby uzyskać bieżący projekt gcloud, uruchom to polecenie:
Jeśli nie jest ustawiony, uruchom to polecenie:gcloud config get-value project Zastąpgcloud config set project YOUR_PROJECT_IDYOUR_PROJECT_IDidentyfikatorem projektu.
- 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 - Ustaw domyślny region, w którym będą wdrażane usługi Cloud Run.
Aby uzyskać dostęp do Model Armor i korzystać ze spójnych przykładów, używajgcloud config set run/region us-central1us-central1. Regiony, w których dostępna jest usługa Model Armor, znajdziesz tutaj.
Kod i zależności
- Sklonuj kod startowy i przejdź do katalogu głównego projektu.
Aby uruchomić obszar roboczy Cloud Shell, uruchom to polecenie:git clone https://github.com/h3xar0n/prai-roadshow-lab-3-starter cd prai-roadshow-lab-3-starter Aby otworzyć nowy terminal, wybierz Terminal > Nowy terminal.cloudshell workspace . - Utwórz plik
.env, wpisując w terminalu te polecenia: W edytorze Cloud Shell wybierz View (Widok) > Toggle Hidden Files (Przełącz ukryte pliki), aby wyświetlić ukryte pliki, np.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.env. - 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ć. 
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.
- W konsoli Google Cloud otwórz Zabezpieczenia > Sensitive Data Protection.
- W menu nawigacyjnym wybierz Konfiguracja > Szablony.
- Kliknij UTWÓRZ SZABLON.
- Skonfiguruj szablon:
- Typ szablonu:
Inspect - Identyfikator szablonu:
sensitive-data-inspector - Typ lokalizacji:
Region - Region:
us-central1(jest to konieczne do pracy z modelem pancerza).
- Typ szablonu:
- Kliknij Dalej.
- W sekcji Skonfiguruj wykrywanie kliknij Zarządzaj obiektami infoType.
- Za pomocą filtra wyszukaj następujące infoTypes i zaznacz pole wyboru obok każdego z nich:
CREDIT_CARD_NUMBERGOVERNMENT_IDPERSON_NAMEEMAIL_ADDRESSSTREET_ADDRESSSECURITY_DATA
- Wybierz też inne, które Cię interesują, i kliknij Gotowe.
- 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ź, 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.
- W konsoli Google Cloud otwórz Zabezpieczenia > Sensitive Data Protection.
- W menu nawigacyjnym kliknij Konfiguracja > Szablony > Usuwanie identyfikacji.
- Kliknij UTWÓRZ SZABLON.
- 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).
- Typ szablonu:
- Kliknij Dalej.
- W sekcji Konfiguracja anonimizacji zdefiniujesz kilka reguł. Reguły dotyczące konkretnych obiektów infoType zastępują regułę domyślną.
- 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.
- Przekształcenie:
- 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...
- Przekształcenie:
- Aby zapisać szablon anonimizacji, kliknij UTWÓRZ.
- 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.

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. 
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. |
- W konsoli Google Cloud użyj paska wyszukiwania u góry, aby wyszukać i otworzyć Model Armor.
- 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.
- Identyfikator szablonu:
- 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ć:
- Na pasku narzędzi terminala Cloud Shell kliknij przycisk Podgląd w przeglądarce.

- Kliknij Zmień port.

- Zmień numer portu na
8000.
- 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.
- W konsoli Google Cloud otwórz Model Armor.
- Kliknij Monitorowanie.
Zobaczysz wykres czasowy z liczbą wykrytych i zablokowanych żądań.

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.