במסמך הזה מתוארים תקני האבטחה וההגבלות להטמעה של Gemini for Google Cloud ושל Gemini for Government. התקנים האלה עוזרים לכם לעמוד בדרישות של מסגרות מגזר ציבורי כמו FedRAMP High ו-DoD IL5.
למרות ש-Stellar Engine מבצע פריסה אוטומטית של אזור נחיתה בסיסי, אתם צריכים לאכוף אמצעי הגנה ספציפיים לעומסי עבודה רגישים של AI כדי לשמור על ריבונות, למנוע סחף בהגדרות ולצמצם פגיעויות ספציפיות ל-AI.
דרישות מוקדמות
כדי להבטיח מחזור חיים מאובטח של פריסת אפליקציות, חשוב לעמוד בדרישות המוקדמות הבאות לפני שמתחילים בהקצאת משאבים לתשתית:
- אכיפה של תשתית כקוד (IaC): אין יותר צורך בהגדרות ידניות במסוף Google Cloud . כדי למנוע סחף בהגדרות, כדאי להטמיע את כל השינויים בסביבה, פעולות התיקון וההתאמות באמצעות צינורות עיבוד נתונים אוטומטיים של CI/CD.
- שימוש במאגר רשמי: השתמשו במאגרי Stellar Engine הרשמיים. יכול להיות שפיצולים לא מאומתים או וריאציות מותאמות אישית יגרמו לבעיות אבטחה.
- Security Command Center Premium: מפעילים את Security Command Center Premium בכל התיקיות כדי לאפשר זיהוי רציף של איומים וניטור תאימות.
נעילת סביבת הבסיס
כדי לעמוד בדרישות של מסגרות FedRAMP High ו-DoD IL5, צריך לאכוף את אמצעי הבקרה המחמירים הבאים ברמת התיקייה והארגון:
- ארכיטקטורה של שני תיקיות: הפרדה של משאבים באמצעות לפחות שתי תיקיות ייעודיות הכפופות ל-Assured Workloads. תיקייה אחת ל-FedRAMP High ותיקייה אחת ל-FedRAMP Moderate או ל-IL5.
- המיקום של משאבים: נעילת המיקום של משאבים לאזורים בארה"ב שהוסכם עליהם מראש (לדוגמה,
us-east4). - אילוץ מדיניות הארגון: מפעילים את האילוצים הבאים כדי להגביל את הגישה:
-
iam.allowedPolicyMemberDomains: restrict to authorized agency domains. -
compute.vmExternalIpAccess: מניעת הקצאות של כתובות IP ציבוריות במופעים של מכונות וירטואליות. -
compute.restrictVpcPeering: מצמצמים את הסיכונים של תנועה רוחבית; מעבירים את התנועה של הרשתות המקומיות דרך רכזות מרכזיות. -
vertexai.allowedModels: הגבלת הגישה למודלים מורשים (לדוגמה, כדי למנוע את ההטמעה של מודלים חיצוניים או של שותפים שלא אושרו).
-
- בקרת גישה מבוססת-הקשר: נדרש שרת proxy לאימות זהויות (IAP) כדי לאמת את זהות המשתמש ואת מצב האבטחה של המכשיר שלו (באמצעות Access Context Manager) לפני ניתוב תעבורת נתונים לשכבת האפליקציות של Gemini.
רשת מאובטחת
פריסות צריכות לאכוף טופולוגיה של רכזת ונקודות הסתעפות שמנוהלת על ידי Network Connectivity Center ולא על ידי קישור שטוח בין רשתות. לטופולוגיית Hub-and-spoke יש את היתרונות הבאים:
- הפרדת תנועה: בידוד תנועה בין רשתות VPC ייעודיות (לדוגמה,
vpc-trustלניתוב פנימי,vpc-mgmtלניהול מכשירים ו-vpc-untrust). - הגנה על הגבולות: ניתוב ישיר של תעבורת נתונים דרך עננים וירטואליים פרטיים (VPC) ייעודיים לבדיקה, שמצוידים בחומות אש מהדור הבא (NGFW) מקובצות, כדי לנקות את תעבורת הנתונים הנכנסת והיוצאת.
- בידוד לרוחב: הגדרת רכזות NCC כדי לוודא שרשתות מסוג spoke שמשרתות נתוני אפליקציות לא יכולות לתקשר ישירות זו עם זו, וכך למנוע וקטורים של תנועה לרוחב.
שכבות הגנה באפליקציות
כדי להגן על שכבת האפליקציה ועל המודלים הבסיסיים מפני סיכוני הזרקה או זליגה אופייניים, צריך להטמיע את הפעולות הבאות:
- איזון עומסים פרטי: חשיפת אפליקציות קצה באמצעות מאזן עומסים חיצוני אזורי של אפליקציות בלבד, כדי להבטיח שלעולם לא תהיה גישה ישירה אליהן מהאינטרנט.
- IAP: אכיפה של אימות זהות ומצב אבטחה של המכשיר לפני ניתוב התנועה לשכבת האפליקציה של Gemini.
- Model Armor: הפעלת Model Armor לכל מודלי הבסיס שפועלים ב-Gemini Enterprise Agent Platform. נדרשת הגנה מוגברת על המודל כדי לאכוף את הבטיחות של מטען ייעודי (payload) בזמן ריצה, לעמוד בדרישות התאימות לתוכן ולצמצם את נקודות החולשה של החדרת פרומפטים.
הגנה על נתונים וביקורת
כדי להגן על עומסי עבודה ריבוניים, אפשר להטמיע את התכונות הבאות של ביקורת מרכזית ואי-שינוי:
- תוכנית לסיווג נתונים: שילוב עם תוכנית לסיווג נתונים כדי לבצע אופטימיזציה של מיקום אמצעי הבקרה.
- היקפי אבטחה של VPC Service Controls: הטמעת היקפי אבטחה של VPC Service Controls בסביבות של עיבוד ואחסון מידע אישי רגיש כדי למנוע זליגת נתונים. חובה להגדיר היקפים ל-DoD IL5.
- הפרדת סמכויות ב-KMS: אכיפה של הפרדת סמכויות קפדנית לגבי מפתחות קריפטוגרפיים. חשוב לוודא שלאדמינים של אבטחה שמנהלים את מחזירי המפתחות של Cloud Key Management Service בפרויקט האבטחה של שלב 3 אין הרשאות לניהול זהויות והרשאות גישה לפענוח הנתונים.
מאגרי נתונים היררכיים: העברה של טלמטריה ברמת הארגון למאגרי נתונים מובְנים שמוקדשים ל:
- יומני הביקורת Admin Activity ו-Data Access
- אירועים של VPC Service Controls
- אירועים ביומן של Google Workspace ואירועי התחברות
- טלמטריית תאימות ל-CIS
מוודאים שהמשתמשים לא יכולים לעקוף את העברת נתוני הטלמטריה.
הטמעת נתונים ב-SIEM: העברת יומנים באמצעות נושאים ב-Pub/Sub לפרויקטים אדמיניסטרטיביים ייעודיים, שבהם היומנים מוזרמים למאגרי אחסון שלא ניתן לשנות.
זיהוי אנומליות: ניתוח אירועים באמצעות כלי SecOps כמו Google Security Operations כדי לזהות הפרות כמו פרצי API חריגים ב-Agent Platform.
התאמה בין כלים: שילוב טלמטריה עם Google Threat Intelligence, Wiz Security Graph או כלים של צד שלישי כדי לזהות שימוש בכלי AI לא מאושרים או הגדרות רעילות.
תיקון אוטומטי באמצעות SOAR: אפשר להשתמש ב-playbook של SOAR כדי להפעיל אמצעי הגנה בזמן אמת, כמו בידוד של נקודות קצה של מודלים לא מורשים או השבתה של טוקנים שנפרצו.
מעקב ואבטחת AI
כדי לשמור על יכולת צפייה ועל צינורות אוטומטיים להגנה, אפשר להשתמש בתכונות הבאות:
- מעקב אחר השימוש ב-API: יצירת התראות לזיהוי עלייה חדה בשימוש בפונקציות של מודל שפה גדול (לדוגמה,
serviceruntime.googleapis.com/api/request_count). - מאגרי יומנים היררכיים ל-AI: אפשר להגדיר מאגרי יומנים היררכיים כדי לתעד אירועים ספציפיים ל-AI, כמו פרצי נפח חריגים של קריאות ל-API ל-
aiplatform.googleapis.comאו הפרות של נסיעות בלתי אפשריות על ידי חשבונות שירות של AI. צריך לוודא שהיומנים האלה מוזרמים למאגר אחסון שלא ניתן לשינוי (לדוגמה, BigQuery) שאפשר לגשת אליו באמצעות ה-SIEM של הסוכנות. - התאמה ל-Secure AI Framework (SAIF): קישור טלמטרייה לארבעת עמודי התווך הבאים של SAIF:
- יסודות חזקים: אימות ההרשאות ב-IAM והסטטוס של Cloud KMS.
- תוספי זיהוי: עוקבים אחרי הזרקות של הנחיות ונקודות קצה לא מורשות באמצעות סינון יומנים.
- הגנות אוטומטיות: שימוש באוטומציה כדי להסגר או לדחות מטען חריג.
- התאמה בין פלטפורמות: פעולה על סמך מודיעין איומי סייבר (מ-Google Threat Intelligence או מממצאי האבטחה של Wiz).