שיטות מומלצות לאבטחת עומסי עבודה של AI ב-GKE

המסמך הזה מיועד לצוותי פלטפורמה, למהנדסי אבטחה ולאדריכלי ענן שפורסים עומסי עבודה של AI ב-Google Kubernetes Engine ‏ (GKE). אתם יכולים להשתמש ב-GKE כדי להגן על קניין רוחני (IP) קנייני, כמו משקלים של מודלים, לשמור על המוניטין של המותג באמצעות סינון תוכן ולשפר את התאימות לתקנות.

כדאי להטמיע את השיטות המומלצות האלה בנוסף לשיטות מומלצות אחרות לאבטחת עומסי עבודה ב-GKE וב-AI, כמו:

הסבר על האחריות שלכם בנושא אבטחה

רמת האבטחה של עומסי העבודה של ה-AI תלויה בשכבות שונות של הסביבה שלכם, כמו התשתית Google Cloud והמודלים שבהם אתם משתמשים. בטבלה הבאה מתוארות השכבות האלה, מי אחראי לאבטחת כל שכבה ואחריות האבטחה של כל שכבה:

שכבה תיאור תחומי האחריות
תשתית התשתית הבסיסית, כמו מכונות וירטואליות (VM), רכיבי רשת וחומרת אחסון שעליהם פועלים עומסי העבודה של ה-AI. Google Cloud היא הבעלים של התשתית ומספקת בסיס אבטחה חזק.

אדמינים של הפלטפורמה בארגון מטמיעים אמצעי בקרה כדי לשפר את האבטחה בתחומים הבאים:

  • הגנה מפני מתקפות של החדרת הנחיות
  • הצפנת נתונים
  • אימות משתמשים ועומסי עבודה והרשאות
  • בטיחות הפלט
  • בידוד חומרה ודיירים בסביבות מרובות דיירים
  • הגבלת קצב של יצירת בקשות בסביבות מרובות דיירים
  • איסוף יומנים ומדדים
דגם המודל, משקלי המודל, צינור האימון ומאפייני הבטיחות. אם מריצים מודלים שאומנו או שודרגו, האחריות לאבטחת שכבת המודל חלה עליכם. אם אתם מפעילים מודלים מנוהלים מספקי צד שלישי (כמו Gemini), הספק אחראי לאבטחת המודל.

ברמת המודל, הבעלים של המודל אחראי לאבטחה בתחומים הבאים:

  • מהימנות המודל
  • הגנה על משקל המודל
  • מאפייני בטיחות של מודלים
בקשת הצטרפות ההנחיות, הקוד, הוראות המערכת וחוויית משתמשי הקצה. מפעילים של אפליקציות ואדמינים של פלטפורמות בארגון אחראים על האבטחה בשכבת האפליקציה.

בשכבת האפליקציה, מפעילים, מפתחים ואדמינים של הפלטפורמה אחראים לאבטחה בתחומים הבאים:

  • הגנה מפני מתקפות של החדרת הנחיות
  • טיפול בנתוני האפליקציה
  • בטיחות תוכן בשכבת האפליקציה
  • בידוד של עומסי עבודה והרצה בארגז חול (sandboxing)

אתם מטמיעים אמצעי בקרה כדי לאבטח את השכבות שאתם אחראים להן. בדוגמאות הבאות מוצגים סוגי פריסה נפוצים של לקוחות GKE, ותחומי האחריות בנוגע לאבטחה שמתאימים לפריסות האלה:

  • אתם מפעילים מודל מנוהל, כמו Gemini: אתם מחילים אמצעי בקרה בשכבות התשתית והאפליקציה. גם כשמשתמשים במודל מנוהל עם מסנני בטיחות מובנים, עדיין צריך להגדיר אמצעי הגנה מפני הזרקת הנחיות כדי להגן על הלוגיקה הספציפית של האפליקציה.
  • אתם מפעילים מודל משלכם: אם אתם מפעילים מודל שעבר כוונון עדין, מודל קוד פתוח או מודל שאומן על ידכם, אתם אחראים לאבטחה בכל שכבה.
  • אתם ספק של שירותי AI רב-דיירים: אם אתם מספקים שירותי AI למשתמשי הקצה שלכם על ידי הפעלת המודל ב-GKE וחשיפת נקודות קצה של הסקת מסקנות למספר דיירים, אתם אחראים לאמצעי בקרה נוספים. אמצעי הבקרה האלה כוללים בידוד לוגי ופיזי של הדיירים (כמו מאגרי צמתים ייעודיים, מרחבי שמות ומדיניות רשת), הגבלת קצב לכל דייר והצפנה של נתוני הדיירים במנוחה באמצעות מפתחות הצפנה בניהול הלקוח (CMEK) נפרדים.

שיפור האבטחה בשכבת התשתית

בשכבת התשתית, Google Cloud ו-GKE מספקים מצב אבטחה בסיסי שמיישם כברירת מחדל אמצעי אבטחה שונים. כדי לשפר את האבטחה של התשתית שלכם לעומסי עבודה של AI, אתם יכולים להגדיר אמצעי בקרה נוספים בתחום האבטחה על סמך סוגי עומסי העבודה של ה-AI שאתם מריצים והיעדים הספציפיים שלכם בתחום האבטחה. בקטעים הבאים מתוארים המוצרים והשירותים שבהם אפשר להשתמש כדי להגן על רכיבים שונים בתשתית ה-AI.

הגנה על צומתי GKE

כדי להגן על נתונים רגישים, כמו עומסי עבודה של הסקת מסקנות שמעבדים הנחיות ותשובות או עומסי עבודה של אימון שמקבלים גישה למודלים קנייניים, אפשר להשתמש בשירותים הבאים:

  • הצפנה של נתונים רגישים בשימוש באמצעות אימות חומרה: מריצים את עומסי העבודה של ההסקות ב-Confidential Google Kubernetes Engine Nodes, ומרחיבים את ההצפנה של הזיכרון ברמת החומרה למאיצים, כולל מעבדי GPU ומעבדי TPU, בנוסף למעבדי AMD SEV-SNP או Intel TDX. מומלץ להשתמש ב-Confidential GKE Nodes לפריסות מפוקחות ולעומסי עבודה (workloads) רגישים של הסקת מסקנות. צמתים סודיים של GKE לא מגנים על עומסי עבודה מפני ניצול לרעה ברמת האפליקציה או מפני משתמשים מורשים שיש להם גישה ברמת הצומת.

    לספקים שלקוחותיהם דורשים בידוד קפדני (למשל, עומסי עבודה ריבוניים),‏ GKE Hypercluster מספק אימות קריפטוגרפי שמאפשר לוודא שאפילו מפעיל התשתית הבסיסית,Google Cloud, לא יכול לבדוק את נתוני הדיירים.

  • צמצום הסיכון להתחזות לצומת: הפעלת עומסי עבודה ב צמתים מוגנים של GKE, שמספקים אימותים (attestation) של זהות ושלמות צמתים שניתנים לאימות. מומלץ להשתמש בצומתי GKE מוגנים לכל סוגי העומסים.

  • ביטול השימוש בפרטי כניסה סטטיים לעומסי עבודה: אפשר להשתמש ב Workload Identity Federation for GKE כדי לגשת לשירותי Google Cloud מקוד האפליקציה באמצעות פרטי כניסה מאוחדים לטווח קצר, ולמנוע חשיפה של מטא-נתונים לא חיוניים של Compute Engine לאפליקציות. מומלץ להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE בכל אשכולות הייצור, במיוחד כשצריך לגשת לנתונים שנמצאים בשירותים מחוץ לאשכול.

הטמעת אמצעי בקרה על הרשת

אתם יכולים להשתמש בתכונות ובמוצרים הבאים כדי לשפר את אבטחת הרשת עבור עומסי עבודה של AI:

  • שימוש בטווחי כתובות IP של כינויים: אשכולות מקוריים של VPC משתמשים בטווחי כתובות IP של כינויים כדי לנתב תעבורה בין Pods במקום להשתמש בנתיבים סטטיים ברשת VPC. תמיד משתמשים באשכולות שמותאמים ל-VPC.

  • הגבלת הגישה לרשת לצמתים: כברירת מחדל, משתמשים בצמתים פרטיים כדי למנוע תעבורה בין הצמתים לבין האינטרנט הציבורי. נקודות קצה של הסקת מסקנות שצריך לחשוף צריכות להיות מנוהלות על ידי שירות כמו Google Cloud Armor, שפועל בין נקודות הקצה לבין האינטרנט.

  • חסימת תנועה בתוך האשכול כברירת מחדל: אפשר להשתמש בKubernetes NetworkPolicies כדי לחסום תנועה בין קבוצות Pod, בין מרחבי שמות ותנועה יוצאת לאינטרנט. לאפשר תנועת נתונים ברשת רק לאפליקציות שנדרשת להן גישה ספציפית.

  • הוספת הגנה בקצה הרשת לנקודות קצה באינטרנט: אפשר להשתמש ב-Google Cloud Armor כדי להגן על נקודות קצה של הסקת מסקנות שחשופות לאינטרנט. לשם כך, מגדירים הגבלת קצב, הגנה מפני מתקפות DDoS, בקרת גישה מבוססת-מיקום גיאוגרפי והפחתת הסיכון למתקפות בשכבה 7. אם יש לכם ממשקי AI API שפונים לציבור, אתם יכולים להשתמש ב-Cloud Armor כדי לטפל בהתקפות נפחיות ובהתקפות בשכבת האפליקציה לפני שההתקפות מגיעות לתשתית המחשוב שלכם. אפשר לשלב את Cloud Armor עם צמתים פרטיים כדי לבצע אופטימיזציה של האבטחה של נקודות קצה של הסקת מסקנות.

  • מניעת זליגת נתונים במהלך מתקפה: אפשר להשתמש ב-VPC Service Controls כדי ליצור מתחם אבטחה היקפית מסביב ל Google Cloud משאבים. גם אם פרטי הכניסה נפרצו, התוקפים לא יכולים להוציא נתונים מחוץ לגבולות. שימוש ב-VPC Service Controls לעומסי עבודה מפוקחים.

ניהול הזהויות והרשאות הגישה

כדי לזהות משתמשים ולשלוט בגישה לאשכולות ולעומסי עבודה, משתמשים במנגנוני ההרשאות הבאים:

  • שליטה בגישה למשאבים: אפשר להשתמש במדיניות הגישה של Google Cloudניהול זהויות והרשאות גישה (IAM) כדי לקבוע אילו חשבונות משתמשים יכולים לבצע אינטראקציה עם אשכולות וצמתים של GKE. Google Cloud

  • שליטה בגישה למשאבי Kubernetes באשכולות: שימוש במדיניות בקרת גישה מבוססת-תפקידים (RBAC) של Kubernetes כדי לקבוע מה גורמים שונים יכולים לעשות למשאבי Kubernetes API בכל אשכול.

  • הגדרה של גישה לפי עקרון אפס האמון לנקודות קצה של הסקת מסקנות ולממשקי אדמין: אפשר להשתמש בשירות כמו Chrome Enterprise Premium כדי להגדיר גישת משתמשים על סמך זהות ומצב המכשיר במקום על סמך טופולוגיית הרשת.

ניהול מפתחות וסודות

חשוב לשמור את כל מפתחות ההצפנה והמידע הרגיש, כמו מפתחות API ופרטי כניסה, מחוץ לאשכול. המוצרים הבאים יכולים לעזור לכם לאחסן את המשאבים האלה:

  • ניהול מפתחות הצפנה: אפשר להשתמש ב-Cloud Key Management Service כדי לנהל את כל מפתחות ההצפנה. אפשר גם ליצור מפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud KMS כדי להצפין נתונים באמצעות מפתחות שאתם שולטים בהם. זו לרוב דרישה בתעשיות עם רגולציה.

  • אחסון נתונים רגישים של אפליקציות: אפשר להשתמש ב-Secret Manager כדי לאחסן נתונים רגישים שמשמשים לעומסי עבודה, כמו סודות של אפליקציות, מפתחות API ופרטי כניסה. כדי לקרוא את הנתונים האלה מקבוצות Pod, משתמשים ב- Workload Identity Federation for GKE כדי להעניק לזהויות ספציפיות של עומסי עבודה גישה רק למשאבים שקבוצות ה-Pod צריכות.

שיפור האבטחה של שרשרת האספקה

השירותים הבאים יכולים לעזור לכם לשפר את האבטחה בשרשרת האספקה של תוכנות: Google Cloud

  • סריקה לאיתור נקודות חולשה בקובצי אימג' של קונטיינרים: אחסון קובצי אימג' של קונטיינרים במאגרי Artifact Registry שבהם מופעלת כברירת מחדל סריקה לאיתור נקודות חולשה. הפעלת זיהוי רציף של CVE בכל תמונה במאגר.

  • אפשרות להעביר לייצור רק תמונות מאומתות: אפשר להשתמש באישור בינארי כדי לאכוף הרשאה מבוססת-מדיניות של חתימות תמונות של קונטיינרים בזמן הפריסה. רק תמונות שעברו אימות מגיעות לסביבת הייצור.

  • הגדרת זיהוי אבטחה וניהול מצב האבטחה: אפשר להשתמש ב-Security Command Center כדי לראות ממצאים של זיהוי איומים וניהול מצב האבטחה שספציפיים ל-AI, כמו נקודות קצה של Gemini Enterprise Agent Platform שהוגדרו בצורה לא נכונה או מאגרי נתונים לאימון שנחשפו. ב-Security Command Center, הממצאים האלה מבוססי ה-AI משולבים עם נקודות חולשה ב-Artifact Registry וניתוח IAM, כדי לספק תמונה מקיפה של הצי.

  • מעקב אחרי ארטיפקטים של AI: אפשר להשתמש בכלי BOM (רשימת חומרים) שנועד לעומסי עבודה של AI ב-Kubernetes, כמו k8s-aibom, כדי ליצור מלאי מקיף של המודלים, מערכי הנתונים והמסגרות שלכם.

שיפור האבטחה בשכבת המודל

אם אתם מריצים מודלים שאומנו או שודרגו על ידכם, או מודלים של קוד פתוח שהגדרתם, כדאי להגדיר אמצעי בקרה שונים כדי לשפר את אבטחת המודל. אם אתם מפעילים מודלים מנוהלים מספקי צד שלישי, השכבה הזו לא רלוונטית לכם. בקטעים הבאים מוסבר מה אפשר לעשות כדי לשפר את השלמות, הסודיות והאבטחה של המודלים.

שיפור שלמות המודל

לשפר את השלמות של המודלים כדי למצוא הוכחות לשיבוש לפני שהמודל נגיש בנקודת קצה של הסקת מסקנות. ההנחיות הבאות יעזרו לכם לשפר את שלמות המודל:

  • חתימה על ארטיפקטים של המודל: חותמים על משקלי המודל באופן קריפטוגרפי לפני שמפרסמים את המשקלים במרשם. כשפורסים את המודל, צריך לאמת את החתימה באמצעות אישורים של הרשאות בינאריות. חתימה על ארטיפקטים של מודלים ואימות שלהם עוזרים לכם לזהות אם בוצעו שינויים במודלים במהלך האחסון או ההעברה שלהם, ומספק לכם שרשרת אימות של בעלות על מודלים לייצור.
  • איתור שינויים שבוצעו אחרי האימון: Activation Model Scanner (AMS)‎ הוא כלי קוד פתוח שמנתח את חתימות ההפעלה של המודל בהשוואה לנתוני בסיס, כדי לזהות מודלים שעברו שינויים אחרי האימון (לדוגמה, כדי להוסיף דלתות אחוריות, שיבושים במשקלים או כוונונים לא מורשים). כדאי להריץ סורק כמו AMS כחלק מצינור ה-CI/CD לפני שמפרסמים את המודלים במאגרי ייצור. במודלים בעלי ערך גבוה או במודלים מפוקחים, כדאי לתזמן סריקות תקופתיות של AMS על ארטיפקטים של ייצור כדי לזהות שינויים שמתרחשים אחרי הפרסום הראשוני.

הגנה על סודיות המודל

אם יש לכם משקלים רגישים של מודלים, כמו כוונונים מדויקים קנייניים, מודלים שאומנו על נתונים בפיקוח או קניין רוחני תחרותי, כדאי להשתמש בהנחיות הבאות כדי להגן על המשקלים:

  • הצפנת משקלים במנוחה: אחסון משקלים באחסון אובייקטים מוצפן, כמו בקטגוריות של Cloud Storage, עם גישת IAM מוגבלת. כברירת מחדל, Cloud Storage מצפין את התוכן של הלקוחות במצב מנוחה. אפשר להשתמש ב-CMEK כדי להצפין את הנתונים באמצעות מפתחות שאתם שולטים בהם. זו לרוב דרישה בתעשיות מפוקחות. מידע נוסף זמין במאמר אפשרויות להצפנת נתונים במסמכי Cloud Storage.

  • הגנה על משקלים בשימוש: הפעלת מודלים ב-Confidential GKE Nodes כדי לוודא שהמשקלים מוצפנים בזיכרון במהלך ההסקה. צמתים סודיים של GKE יכולים לעזור לכם להגן על הקניין הרוחני שלכם מפני פריצה ברמת ההיפר-ויז'ור וגישה לא מורשית של מפעיל התשתית. התכונה 'צמתים סודיים של GKE' לא מגנה מפני ניצול לרעה ברמת האפליקציה או מפני משתמשים מורשים עם גישה ברמת הצומת.

  • שליטה בכל הגישה למשקלים: רישום כל הגישה לארטיפקטים של המודל באחסון. משתמשים במדיניות הגישה ב-IAM כדי להגביל את הגישה לחשבונות שירות ספציפיים ולאנשים שיש להם צורך מתועד בגישה. להגביל באופן משמעותי את הגישה האדמיניסטרטיבית לאשכול, כולל גישת Shell למאגרי נתונים, גישת SSH למכונות וירטואליות של צמתים או ניפוי באגים ברמת הצומת, באמצעות כללי מדיניות של Kubernetes RBAC ו-Chrome Enterprise Premium. האמצעים האלה יכולים לעזור לכם להגן על משקלי המודל מפני משתמשים שיש להם גישה ברמת הצומת, שלא נכללת ב-Confidential GKE Nodes.

שיפור מאפייני הבטיחות של המודל

אתם יכולים להטמיע הגדרות אבטחה שונות במודלים במהלך האימון. אם אתם מאמנים או מבצעים כוונון עדין של מודל משלכם, כדאי להשקיע באימון בנושא בטיחות שרלוונטי לתרחיש השימוש במודל. מאפייני הבטיחות של המודלים כוללים התנהגות של סירוב, אימון להתאמה ועמידות מפני פריצות. אם אתם משתמשים במודל שאומן מראש, בחרו מודל עם מאפייני בטיחות שתואמים לדרישות האפליקציה שלכם.

מפתחי אפליקציות ומפעילים יכולים להטמיע אמצעי בקרה שונים בשכבת האפליקציה כדי לשפר את האבטחה בתחומים שהמודל לא יכול לכסות.

שיפור האבטחה בשכבת האפליקציה

שכבת האפליקציה היא המקום שבו למפעילים ולמפתחים יש הכי הרבה שליטה בהגדרות אבטחה ספציפיות ל-AI. בשכבת האפליקציה, אפשר להטמיע אמצעי בקרה לאבטחה שמגנים על נתונים, ליצור בקשות תקינות ולהגן על הנחיות ותשובות. אמצעי הבקרה האלה שימושיים בדרך כלל לעומסי עבודה של הסקת מסקנות, שמטפלים בהנחיות למשתמשים, בסשנים ובתשובות. בקטעים הבאים מתוארים אמצעי בקרה, מוצרים ושירותים שונים שיכולים לעזור לכם להשיג יעדי אבטחה ספציפיים בשכבת האפליקציה.

הגנה מפני איומים בשכבת התוכן

בודקים את כל ההנחיות והתשובות כדי לזהות בעיות אבטחה כמו החדרת הנחיות, חשיפה של מידע אישי רגיש ותוכן פוגעני. כי הצמתים של GKE לא אמורים לקבל גישה לתוכן, צריך לפרוס את Model Armor בין האפליקציה לבין נקודת הקצה של ההסקה. ל-Model Armor יש עקרונות ספציפיים לטיפול בנתונים ולאחסון שלהם, שמטרתם לשפר את הפרטיות של הנתונים במהלך הסריקה.

הגנה על הנחיות למערכת

מסננים את הפלט כדי לזהות דליפות של הנחיות ומגדירים את זיהוי זליגת הנתונים ב-Model Armor כדי לזהות דפוסי חילוץ. אם ההוראות רגישות מאוד, צריך לעבד אותן בקריאה שלא מחזירה טקסט למשתמש.

ניהול סשנים וניתוב

כשחושפים נקודות קצה של הסקת מסקנות למשתמשי קצה, משתמשים ב- GKE Inference Gateway. ‫Inference Gateway מרחיב את Gateway API כדי לנתב תנועה על סמך מדדים ונתונים שספציפיים לעומסי עבודה של הסקת מסקנות מ-AI. אתם יכולים להגדיר שינוי אוטומטי של קנה מידה של עומסי עבודה כדי לעמוד בדרישות, ולשלב עם Model Armor ו-Apigee כדי לסנן תוכן, לקבל נראות ברמת הסשן ולאכוף מכסות.

שיפור האבטחה של סוכן ה-AI

אם עומס העבודה של ה-AI הוא סוכן, תצטרכו אמצעי בקרה נוספים בשכבת האפליקציה, כמו:

  • הגבלת הגישה ל-APIs של Google Cloud : אפשר להשתמש באיחוד זהויות של עומסי עבודה ל-GKE עם מדיניות גישה ל-IAM כדי להגביל את הגישה של ה-Pods של עומס העבודה של הסוכן ל-APIs. משתמשים בחשבון שירות ייעודי של Kubernetes לכל סוכן, ומעניקים לישות המורשית הזו רק את הרשאות ה-IAM שעומס העבודה צריך.
  • הפעלת ביצוע קוד או כלים לא מהימנים בארגזי חול: הפעלת סוכנים שמבצעים קוד שנוצר או שמבצעים אינטראקציה עם כלים לא מאומתים של צד שלישי בסביבות ארגז חול באמצעות ארגז החול לסוכנים. ארגז החול לסוכנים משתמש במנגנון בידוד כמו ארגז החול של GKE או Kata Containers כדי להגן מפני פריצה למאגר.

הגדרה של יכולות ניטור ותגובה לאירועים

איסוף יומנים ומעקב אחרי מדדים שונים כדי לזהות מוקדם מתקפות פוטנציאליות ולהגביל את ההשפעה של ניצול פרצות אבטחה. בקטעים הבאים מפורטות הנחיות שיכולות לעזור לכם לשפר את יכולות הזיהוי והתגובה.

איסוף יומנים ומדדים

כדי לזהות איומים במהירות האפשרית, מומלץ להטמיע כמה שיותר מהשיטות המומלצות הבאות בנושא יכולת תצפית:

זיהוי איומים ספציפיים ל-AI

הגדרת התראות ב-Logging וב-Cloud Monitoring כדי לזהות איומים שונים שספציפיים ל-AI. מדיניות ההתראות הספציפית שתגדירו תלויה בסוגי היומנים שאתם אוספים ובדרישות של הארגון. מידע נוסף על מדיניות ההתראות הזמינה מופיע במאמר השוואה בין אפשרויות ההתראות. הגדרת התראות לגבי איומים ספציפיים ל-AI כמו אלה:

איומים ואותות ספציפיים ל-AI
החדרת פרומפטים יומנים של Model Armor לניקוי או לדחייה של הנחיות
חילוץ הנחיות למערכת הגנה מוגברת על המודל ואנומליות של מציאה במטמון (cache hit)
חשיפה של מידע אישי רגיש יומני התגובות של Model Armor
התנהלות פוגעת שקשורה לעלויות של הסקת מסקנות שימוש באסימונים ברמת הסשן מתוך מדדים של Inference Gateway
מניפולציה של סשנים מהירות של סשנים חדשים לכל דייר מתוך מדדים של Inference Gateway
יצירת טביעת אצבע דיגיטלית של מודל תבניות של בדיקת יכולות
ערוץ צדדי של תזמון מיטיגציה ברמת הארכיטקטורה (חלוקת מטמון למחיצות)

יצירת תהליך תגובה לתקריות אבטחה

הדרך שבה אתם מגיבים לאירועים שונים תלויה במבנה הארגוני ובדרישות האבטחה שלכם. ההנחיות הבאות מתארות מה צריך לעשות כשמזהים סוגים ספציפיים של איומים על עומסי העבודה של ה-AI:

  • זיהוי תוכן ב-Model Armor: חסימת הבקשה, תיעוד האירוע והגדרת התראה כדי לקבל הודעה אם הקצב חורג מסף מסוים. הגדרת הגבלת קצב למשתמשים שביצעו הפרות חוזרות.

  • זיהויים של הסקה: הגבלת קצב הבקשות של דיירים באמצעות Inference Gateway. סיום סשנים במקרים של ניצול לרעה שאומת.

  • קורלציה בין שכבות: זיהוי של Model Armor בתוספת דפוס של ניצול לרעה של טוקנים מצביע על ניצול לרעה מתואם. מגדירים כללי קורלציה ומזהים סף מהימנות שאחריו הסיכון להתראת שווא נמוך. אוטומציה של סיום סשנים שחוצים את הסף הזה.

הטמעת אבטחה לאורך מחזור החיים של הפריסה

אופטימיזציה של פריסות ה-AI לאבטחה לאורך מחזור החיים של הפריסה. במהלך שלבים ספציפיים במחזור החיים, מטמיעים אמצעי בקרה שמגנים על שכבה אחת או יותר. בקטעים הבאים מפורטות הנחיות לכל שלב במחזור החיים.

פריסת התשתית

כשיוצרים או מעצבים את התשתית שמריצה את עומסי העבודה של ה-AI, כדאי להטמיע כמה שיותר מהאמצעים הבאים:

קטגוריה
צומתי GKE
  • מפעילים את איחוד הזהויות של עומסי עבודה ל-GKE בכל אשכולות הייצור.
  • הגדרת Confidential GKE Nodes לעומסי עבודה רגישים של הסקת מסקנות.
  • הפעלת צומתי GKE מוגנים לכל עומסי העבודה.
Networking
  • שימוש באשכולות המותאמים ל-VPC.
  • הפעלת צמתים פרטיים.
  • דחיית תנועת אשכול כברירת מחדל באמצעות NetworkPolicies.
  • יוצרים אזורים של VPC Service Controls לעומסי עבודה מפוקחים.
  • פריסת Model Armor לנקודות קצה של היקש.
  • הגדרת Inference Gateway לאיזון עומסים ולניהול סשנים.
ניהול זהויות והרשאות גישה
  • שימוש ב-Chrome Enterprise Premium לגישת אדמין אנושית.
  • שימוש במדיניות גישה ב-IAM וב-Kubernetes RBAC להרשאה.
ניהול מידע אישי רגיש
  • אחסון כל הסודות, כמו מפתחות API, ב-Secret Manager.
  • אחסון קובצי אימג' של קונטיינרים ב-Artifact Registry והפעלת סריקה לאיתור נקודות חולשה.
ניראות (observability)
  • מפעילים את Security Command Center.
  • הגדרת רישום ביומן ומעקב.
  • קובעים תהליך תגובה לתקריות אבטחה.

הפעלת עומסי עבודה ותשתית

כשפורסים את עומסי העבודה של ה-AI ומריצים מערכת ייצור, כדאי להטמיע כמה שיותר מאמצעי הבקרה הבאים:

קטגוריה
אבטחת עומסי עבודה
  • אכיפת מדיניות בנושא קובצי אימג' של קונטיינרים באמצעות Binary Authorization.
  • חתימה ואימות של ארטיפקטים של מודלים בזמן הפריסה.
  • מריצים את AMS בצינור ה-CI של המודל.
  • אימות של כל הפלטים המובנים.
  • בידוד סוכנים שמריצים קוד בארגזי חול.
Networking
  • שיפור פרופילים של הגנה מוגברת על המודל.
  • שינוי ההגדרות של שער ההסקה.
Sensitive data protection שימוש ב-CMEK להצפנת נתונים באמצעות מפתחות משלכם בסביבות מפוקחות.
ניראות (observability)
  • הגדרה וצבירה של רישום ביומן ביקורת.
  • יצירת מלאי של שרשרת אספקה באמצעות AI.

שליטה בפריסות בקנה מידה נרחב

ככל שהארגון גדל, כדאי להטמיע את אמצעי הבקרה הבאים כדי לאוטומט את ניהול האבטחה:

  • הגדרת שכבות הגנה ברמת הארגון באמצעות Organization Policy Service.
  • אכיפת מדיניות בזמן הכניסה באמצעות Admission Webhooks של Kubernetes.
  • אוטומציה של התגובה הראשונה לגבי זיהויים ברמת מהימנות גבוהה.
  • יצירת קורלציה בין שכבות שונות של SIEM וקביעת קווי בסיס התנהגותיים לכל דייר.

סיכום השיטות המומלצות

בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במסמך הזה:

נושא
שיפור האבטחה בשכבת התשתית הגנה על צמתי GKE, הטמעה של אמצעי בקרה ברשת, ניהול של זהויות וגישה, ניהול של מפתחות וסודות ושיפור האבטחה של שרשרת האספקה.
שיפור האבטחה בשכבת המודל לשפר את שלמות המודל, להגן על סודיות המודל ולשפר את מאפייני הבטיחות של המודל.
שיפור האבטחה בשכבת האפליקציה הגנה מפני איומים בשכבת התוכן, הגנה על הנחיות למערכת, ניהול של סשנים וניתוב, ושיפור האבטחה של סוכני AI.
הגדרה של יכולות ניטור ותגובה לאירועים איסוף יומנים ומדדים, זיהוי איומים ספציפיים ל-AI והגדרת תהליך תגובה לאירועים.
הטמעת אבטחה לאורך מחזור החיים של הפריסה פריסת תשתית, הפעלת עומסי עבודה ותשתית וניהול פריסות בקנה מידה גדול.

המאמרים הבאים