במסמך הזה מפורטות שיטות מומלצות לצוותי פלטפורמה, למהנדסי אבטחה ולאדריכלי ענן שפורסים עומסי עבודה של AI ב-Google Kubernetes Engine (GKE). אתם יכולים להשתמש ב-GKE כדי להגן על קניין רוחני (IP) קנייני, כמו משקלים של מודלים, לשמור על המוניטין של המותג באמצעות סינון תוכן ולשפר את העמידה בתקנות.
כדאי להטמיע את השיטות המומלצות האלה בנוסף לשיטות מומלצות אחרות לאבטחת עומסי עבודה של GKE ו-AI, כמו:
הסבר על האחריות שלכם בנושא אבטחה
מצב האבטחה של עומסי העבודה של ה-AI תלוי בשכבות שונות של הסביבה שלכם, כמו התשתית Cloud de Confiance by S3NS והמודלים שבהם אתם משתמשים. בטבלה הבאה מתוארות השכבות האלה, מי אחראי לאבטחת כל שכבה ומהם תחומי האחריות לאבטחה בכל שכבה:
| שכבה | תיאור | תחומי האחריות |
|---|---|---|
| תשתית | התשתית הבסיסית, כמו מכונות וירטואליות (VM), רכיבי רשת וחומרת אחסון שעליהם פועלים עומסי העבודה של ה-AI. Cloud de Confiance היא הבעלים של התשתית ומספקת בסיס אבטחה חזק. | אדמינים של הפלטפורמה בארגון מטמיעים אמצעי בקרה כדי לשפר את האבטחה בתחומים הבאים:
|
| דגם | המודל, משקלי המודל, צינור האימון ומאפייני הבטיחות. אם מריצים מודלים שאומנו או שודרגו, האחריות לאבטחת שכבת המודל היא שלכם. אם אתם מפעילים מודלים מנוהלים מספקי צד שלישי (כמו Gemini), הספק אחראי לאבטחת המודל. | ברמת המודל, הבעלים של המודל אחראי לאבטחה בתחומים הבאים:
|
| בקשת הצטרפות | ההנחיות, הקוד, הוראות המערכת וחוויית משתמש הקצה. מפעילים של אפליקציות ואדמינים של פלטפורמות בארגון אחראים על האבטחה בשכבת האפליקציה. | בשכבת האפליקציה, אופרטורים של אפליקציות, מפתחים ואדמינים של פלטפורמות אחראים על האבטחה בתחומים הבאים:
|
אתם מטמיעים אמצעי בקרה כדי לאבטח את השכבות שאתם אחראים להן. בדוגמאות הבאות מוצגים סוגי פריסה נפוצים של לקוחות GKE, ותחומי האחריות בנוגע לאבטחה שמתאימים לפריסות האלה:
- אתם מפעילים מודל מנוהל, כמו Gemini: אתם מחילים אמצעי בקרה בשכבות התשתית והאפליקציה. גם כשמשתמשים במודל מנוהל עם מסנני בטיחות מובנים, עדיין צריך להגדיר אמצעי הגנה מפני החדרת פרומפטים כדי להגן על הלוגיקה הספציפית של האפליקציה.
- אתם מריצים מודל משלכם: אם אתם מריצים מודל שעבר כוונון עדין, מודל קוד פתוח או מודל שאומן על ידכם, אתם אחראים לאבטחה בכל שכבה.
- אתם ספק של שירותי AI רב-דיירים: אם אתם מספקים שירותי AI למשתמשי הקצה שלכם על ידי הפעלת המודל ב-GKE וחשיפת נקודות קצה של הסקה למספר דיירים, אתם אחראים לאמצעי בקרה נוספים. אמצעי הבקרה האלה כוללים בידוד לוגי ופיזי של הדיירים (כמו מאגרי צמתים ייעודיים, מרחבי שמות ומדיניות רשת), הגבלת קצב לכל דייר והצפנה של נתוני הדיירים במנוחה באמצעות מפתחות הצפנה בניהול הלקוח (CMEK) שונים.
שיפור האבטחה בשכבת התשתית
בשכבת התשתית, Cloud de Confiance ו-GKE מספקים מצב אבטחה בסיסי שמיישם כברירת מחדל אמצעי אבטחה שונים. כדי לשפר את האבטחה של התשתית שלכם עבור עומסי עבודה של AI, אתם יכולים להגדיר אמצעי בקרה נוספים בתחום האבטחה בהתאם לסוג עומסי העבודה של ה-AI שאתם מפעילים וליעדי האבטחה הספציפיים שאתם רוצים להשיג. בקטעים הבאים מפורטים המוצרים והשירותים שבהם אפשר להשתמש כדי להגן על רכיבים שונים בתשתית ה-AI.
הגנה על צומתי GKE
כדי להגן על מידע אישי רגיש, כמו עומסי עבודה של היקש שמעבדים פרומפטים ותשובות או עומסי עבודה של אימון שמקבלים גישה למודלים קנייניים, אפשר להשתמש בשירותים הבאים:
הצפנה של מידע אישי רגיש בשימוש באמצעות אימות חומרה: מריצים את עומסי העבודה של ההסקות ב-Confidential Google Kubernetes Engine Nodes, ומרחיבים את ההצפנה של הזיכרון ברמת החומרה למאיצים, כולל מעבדי GPU ומעבדי TPU, בנוסף למעבדי AMD SEV-SNP או Intel TDX. מומלץ להשתמש ב-Confidential GKE Nodes לפריסות מפוקחות ולעומסי עבודה (workloads) רגישים של הסקת מסקנות. Confidential GKE Nodes לא מגן על עומסי עבודה מפני ניצול לרעה ברמת האפליקציה או מפני משתמשים מורשים שיש להם גישה ברמת הצומת.
לספקים שלקוחותיהם דורשים בידוד קפדני (למשל, עומסי עבודה ריבוניים), GKE Hypercluster מספק אימות קריפטוגרפי שמאפשר לוודא שאפילו אופרטור התשתית הבסיסית,Cloud de Confiance, לא יכול לבדוק את נתוני הדיירים.
צמצום הסיכון להתחזות לצומת: הפעלת עומסי עבודה ב צומתי GKE מוגנים, שמספקים אימותים של זהות ושלמות צמתים שניתנים לאימות. מומלץ להשתמש בצומתי GKE מוגנים לכל סוגי העומסים.
ביטול השימוש בפרטי כניסה סטטיים לעומסי עבודה: אפשר להשתמש ב איחוד זהויות של עומסי עבודה ל-GKE כדי לגשת לשירותי Cloud de Confiance מקוד האפליקציה באמצעות פרטי כניסה מאוחדים לטווח קצר, ולמנוע חשיפה של מטא-נתונים לא חיוניים של Compute Engine לאפליקציות. מומלץ להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE בכל אשכולות הייצור, במיוחד כשצריך לגשת לנתונים שנמצאים בשירותים מחוץ לאשכול.
הטמעת אמצעי בקרה על הרשת
אתם יכולים להשתמש בתכונות ובמוצרים הבאים כדי לשפר את אבטחת הרשת עבור עומסי עבודה של AI:
שימוש בטווחי כתובות IP של כינויים: אשכולות מקוריים של VPC משתמשים בטווחי כתובות IP של כינויים כדי לנתב תעבורת נתונים בין פודים, במקום להשתמש בנתיבים סטטיים ברשת ה-VPC. תמיד להשתמש באשכולות מקוריים של VPC.
הגבלת הגישה לרשת לצמתים: משתמשים בצמתים פרטיים כדי למנוע תעבורה בין הצמתים לבין האינטרנט הציבורי כברירת מחדל. נקודות קצה של הסקת מסקנות שצריך לחשוף צריכות להיות מנוהלות על ידי שירות כמו Google Cloud Armor, שפועל בין נקודות הקצה לבין האינטרנט.
חסימת תנועה בתוך האשכול כברירת מחדל: שימוש ב-Kubernetes NetworkPolicies כדי לחסום תנועה בין קבוצות Pod, בין מרחבי שמות ותנועה יוצאת לאינטרנט. לאפשר תעבורת רשת רק לאפליקציות שנדרשת להן גישה ספציפית.
הוספת הגנה בקצה הרשת לנקודות קצה באינטרנט: אפשר להשתמש ב-Google Cloud Armor כדי להגן על נקודות קצה של הסקת מסקנות שחשופות לאינטרנט. לשם כך, מגדירים הגבלת קצב, הגנה מפני מתקפות DDoS, בקרת גישה מבוססת-מיקום גיאוגרפי והפחתת הסיכון למתקפות בשכבה 7. אם יש לכם ממשקי AI API שפונים לציבור, אתם יכולים להשתמש ב-Cloud Armor כדי לטפל בהתקפות נפחיות ובהתקפות ברמת האפליקציה לפני שההתקפות מגיעות לתשתית המחשוב שלכם. אפשר לשלב את Cloud Armor עם צמתים פרטיים כדי לבצע אופטימיזציה של האבטחה של נקודות קצה של הסקת מסקנות.
מניעת זליגת נתונים במהלך מתקפה: אפשר להשתמש ב-VPC Service Controls כדי ליצור מתחם אבטחה היקפית מסביב ל Cloud de Confiance משאבים. גם אם פרטי הכניסה נפרצו, התוקפים לא יכולים להוציא נתונים מחוץ לגבולות. שימוש ב-VPC Service Controls לעומסי עבודה מפוקחים.
ניהול הזהויות והרשאות הגישה
כדי לזהות משתמשים ולשלוט בגישה לאשכולות ולעומסי עבודה, משתמשים במנגנוני ההרשאה הבאים:
שליטה בגישה למשאבים של Cloud de Confiance : אפשר להשתמש במדיניות הגישה של Cloud de Confianceניהול זהויות והרשאות גישה (IAM) כדי לקבוע אילו חשבונות משתמשים יכולים לבצע אינטראקציה עם אשכולות וצמתים של GKE.
שליטה בגישה למשאבי 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 צריכות.
שיפור האבטחה של שרשרת האספקה
השירותים Cloud de Confiance הבאים יכולים לעזור לכם לשפר את האבטחה בשרשרת האספקה של תוכנות:
- סריקה לאיתור נקודות חולשה בקובצי אימג' של קונטיינרים: אחסון קובצי אימג' של קונטיינרים במאגרי Artifact Registry שבהם מופעלת כברירת מחדל סריקה לאיתור נקודות חולשה. הפעלת זיהוי רציף של CVE בכל תמונה במאגר.
אפשרות להעביר לייצור רק תמונות מאומתות: אפשר להשתמש בBinary Authorization כדי לאכוף הרשאה מבוססת-מדיניות של חתימות תמונות של קונטיינרים בזמן הפריסה. רק תמונות שעברו אימות מגיעות לסביבת הייצור.
הגדרת זיהוי אבטחה וניהול מצב האבטחה: אפשר להשתמש ב-Security Command Center כדי לראות ממצאים של זיהוי איומים וניהול מצב האבטחה שספציפיים ל-AI, כמו נקודות קצה של Gemini Enterprise Agent Platform שהוגדרו בצורה שגויה או מאגרי נתונים לאימון שנחשפו. ב-Security Command Center, הממצאים האלה מבוססי ה-AI משולבים עם נקודות חולשה ב-Artifact Registry ועם ניתוח IAM, כדי לספק תמונה מקיפה של הצי.
מעקב אחרי ארטיפקטים של AI: אפשר להשתמש בכלי BOM (רשימת חומרים) שנועדו לעומסי עבודה של AI ב-Kubernetes, כמו
k8s-aibom, כדי ליצור מלאי מקיף של המודלים, מערכי הנתונים והמסגרות שלכם.
שיפור האבטחה בשכבת המודל
אם אתם מפעילים מודלים שאומנו או שודרגו על ידכם, או מודלים של קוד פתוח שהגדרתם, כדאי להגדיר אמצעי בקרה שונים כדי לשפר את אבטחת המודל. אם אתם מפעילים מודלים מנוהלים מספקי צד שלישי, השכבה הזו לא רלוונטית לכם. בקטעים הבאים מוסבר מה אפשר לעשות כדי לשפר את השלמות, הסודיות והאבטחה של המודלים.
שיפור של תקינות המודל
שיפור השלמות של המודלים כדי שתוכלו למצוא הוכחות לשיבוש לפני שהמודל נגיש בנקודת קצה של הסקה. ההנחיות הבאות יעזרו לכם לשפר את תקינות המודל:
- חתימה על ארטיפקטים של המודל: חתימה קריפטוגרפית על משקלי המודל לפני שמפרסמים את המשקלים במרשם. כשפורסים את המודל, צריך לאמת את החתימה באמצעות Binary Authorization attestations. חתימה ואימות של ארטיפקטים של מודלים עוזרים לזהות אם בוצעו שינויים במודלים במהלך האחסון או ההעברה שלהם, ומספקים שרשרת אימות של משמורת למודלים של ייצור.
- איתור שינויים שבוצעו אחרי האימון: כלי הקוד הפתוח Activation Model Scanner (AMS) מזהה מודלים שעברו שינויים אחרי האימון (לדוגמה, כדי להוסיף דלתות אחוריות, שיבושים במשקלים או כוונונים לא מורשים) על ידי ניתוח חתימות ההפעלה של המודל בהשוואה לנתוני בסיס. כדאי להריץ סורק כמו AMS כחלק מצינור עיבוד הנתונים של CI/CD לפני שמפרסמים את המודלים במאגרי ייצור. במודלים בעלי ערך גבוה או במודלים מפוקחים, כדאי לתזמן סריקות תקופתיות של AMS מול ארטיפקטים של ייצור כדי לזהות שינויים שמתרחשים אחרי הפרסום הראשוני.
הגנה על סודיות המודל
אם יש לכם משקלים רגישים של מודלים, כמו מודלים קנייניים שעברו התאמה אישית, מודלים שאומנו על נתונים בפיקוח או קניין רוחני תחרותי, כדאי להשתמש בהנחיות הבאות כדי להגן על המשקלים:
הצפנת משקלים במנוחה: אחסון משקלים באחסון אובייקטים מוצפן, כמו בקטגוריות של Cloud Storage, עם גישת IAM מוגבלת. כברירת מחדל, Cloud Storage מצפין את התוכן של הלקוחות במצב מנוחה. אפשר להשתמש ב-CMEK כדי להצפין את הנתונים באמצעות מפתחות שאתם שולטים בהם. זו לרוב דרישה בתעשיות מפוקחות. מידע נוסף זמין במאמר אפשרויות להצפנת נתונים במסמכי Cloud Storage.
הגנה על משקלים בשימוש: הפעלת מודלים ב-Confidential GKE Nodes כדי לוודא שהמשקלים מוצפנים בזיכרון במהלך ההסקה. צמתים סודיים של GKE יכולים לעזור לכם להגן על הקניין הרוחני שלכם מפני פריצה ברמת ההיפר-ויז'ור וגישה לא מורשית על ידי מפעיל התשתית. Confidential GKE Nodes לא מגן מפני ניצול לרעה ברמת האפליקציה או מפני משתמשים מורשים עם גישה ברמת הצומת.
שליטה בכל הגישה למשקלים: רישום כל הגישה לארטיפקטים של המודל באחסון. משתמשים במדיניות הגישה ב-IAM כדי להגביל את הגישה לחשבונות שירות ספציפיים ולאנשים שיש להם צורך מתועד בגישה. להגביל באופן משמעותי את הגישה האדמיניסטרטיבית לאשכול, כולל גישת Shell למאגרי קבצים, גישת SSH למכונות וירטואליות של צמתים או ניפוי באגים ברמת הצומת, באמצעות מדיניות Kubernetes RBAC ו-Chrome Enterprise Premium. האמצעים האלה יכולים לעזור לכם להגן על משקלי המודל מפני משתמשים שיש להם גישה ברמת הצומת, שלא נכללת ב-Confidential GKE Nodes.
שיפור מאפייני הבטיחות של המודל
אתם יכולים להטמיע הגדרות אבטחה שונות למודלים במהלך האימון. אם אתם מאמנים או מבצעים כוונון עדין של מודל משלכם, כדאי להשקיע באימון בנושא בטיחות שרלוונטי לתרחיש השימוש במודל. מאפייני הבטיחות של המודלים כוללים התנהגות של סירוב, אימון להתאמה ועמידות מפני פריצות. אם משתמשים במודל שאומן מראש, צריך לבחור מודל עם מאפייני בטיחות שתואמים לדרישות האפליקציה.
מפתחים ומפעילים של אפליקציות יכולים להטמיע אמצעי בקרה שונים בשכבת האפליקציה כדי לשפר את האבטחה בתחומים שהמודל לא יכול לכסות.
שיפור האבטחה בשכבת האפליקציה
שכבת האפליקציה היא המקום שבו למפעילים ולמפתחים יש הכי הרבה שליטה בהגדרות אבטחה ספציפיות ל-AI. בשכבת האפליקציה, אפשר להטמיע אמצעי אבטחה שמגנים על הנתונים, ליצור בקשות תקינות ולהגן על ההנחיות והתשובות. אמצעי הבקרה האלה שימושיים בדרך כלל לעומסי עבודה של הסקת מסקנות, שמטפלים בהנחיות למשתמשים, בסשנים ובתשובות. בקטעים הבאים מתוארים אמצעי בקרה, מוצרים ושירותים שונים שיכולים לעזור לכם להשיג יעדי אבטחה ספציפיים בשכבת האפליקציה.
הגנה מפני איומים בשכבת התוכן
בודקים את כל הפרומפטים והתשובות כדי לאתר בעיות אבטחה כמו החדרת פרומפטים, חשיפה של מידע אישי רגיש ותוכן פוגעני. מכיוון שלצמתים של GKE אין גישה לתוכן, צריך לפרוס את הגנה מוגברת על המודל בין האפליקציה לבין נקודת הקצה של ההיקש. ל-Model Armor יש עקרונות ספציפיים לטיפול בנתונים ולאחסון שלהם, שנועדו לשפר את הפרטיות של הנתונים במהלך הסריקה.
הגנה על פרומפטים למערכת
מסננים את הפלט כדי לזהות דליפות של פרומפטים ומגדירים את התכונה הגנה מוגברת על המודל לזיהוי חילוץ נתונים כדי לזהות דפוסי חילוץ. אם ההוראות רגישות מאוד, צריך לעבד אותן בקריאה לפונקציה שלא מחזירה טקסט למשתמש.
ניהול סשנים וניתוב
כשחושפים נקודות קצה של הסקת מסקנות למשתמשי קצה, משתמשים ב- GKE Inference Gateway. Inference Gateway מרחיב את Gateway API כדי לנתב תנועה על סמך מדדים ונתונים שספציפיים לעומסי עבודה של הסקת מסקנות מ-AI. אתם יכולים להתאים אוטומטית לעומס (autoscale) עומסי עבודה כדי לעמוד בביקוש, ולשלב עם הגנה מוגברת על המודל ו-Apigee לסינון תוכן, לניתוח נתונים ברמת הסשן ולאכיפת מכסות.
שיפור האבטחה של סוכן ה-AI
אם עומס העבודה של ה-AI הוא סוכן, תצטרכו אמצעי בקרה נוספים בשכבת האפליקציה, כמו:
- הגבלת הגישה ל-APIs של Cloud de Confiance : אפשר להשתמש באיחוד זהויות של עומסי עבודה ל-GKE עם מדיניות גישה ל-IAM כדי להגביל את ה-APIs שאליהם יכולים לגשת פודים של עומסי עבודה של סוכנים. משתמשים בחשבון שירות ייעודי של Kubernetes לכל סוכן, ומעניקים לישות המורשית הזו רק את הרשאות ה-IAM שעומס העבודה צריך.
- הפעלת ביצוע קוד או כלים לא מהימנים בארגזי חול: הפעלת סוכנים שמבצעים קוד שנוצר או שמבצעים אינטראקציה עם כלים לא מאומתים של צד שלישי בסביבות ארגז חול באמצעות ארגז החול לסוכנים. ארגז החול לסוכנים משתמש במנגנון בידוד כמו GKE Sandbox או Kata Containers כדי להגן מפני פירצה בקונטיינר.
הגדרה של יכולות ניטור ותגובה לאירועים
איסוף יומנים ומעקב אחרי מדדים שונים כדי לזהות מוקדם מתקפות פוטנציאליות ולהגביל את ההשפעה של ניצול פרצות אבטחה. בקטעים הבאים מפורטות הנחיות שיכולות לעזור לכם לשפר את הזיהוי והתגובה.
איסוף יומנים ומדדים
כדי לזהות איומים במהירות האפשרית, מומלץ להטמיע כמה שיותר מהשיטות המומלצות הבאות בנושא יכולת תצפית:
- איסוף יומני GKE.
- הפעלת יומני ביקורת של גישה לנתונים לפעולות רגישות, כמו שימוש במפתח KMS.
- אל תתעדו תוכן של הנחיות או השלמות, אלא אם המדיניות שלכם מאפשרת זאת באופן מפורש. אם אתם אוספים נתונים של הנחיות ותשובות מרובות-אופנים (גרסת Preview), עליכם למחוק את הנתונים המאוחסנים או להגביל את הגישה אליהם בהתאם למדיניות האבטחה שלכם.
- אוספים מדדים שחשובים למהנדסי ה-SRE.
- הגדרת מעקב אוטומטי אחרי אפליקציות לסוגים ספציפיים של שרתים של מודלים של AI.
- לצבור יומנים ב-Cloud Logging או בפלטפורמה שלכם לניהול אירועים ופרטי אבטחה (SIEM).
- אפשר להשתמש במדדים מבוססי-יומן כדי ליצור מדדים שמבוססים על תוכן היומנים.
זיהוי איומים ספציפיים ל-AI
הגדרת התראות ב-Logging וב-Cloud Monitoring כדי לזהות איומים שונים שספציפיים ל-AI. מדיניות ההתראות הספציפית שתגדירו תלויה בסוגי היומנים שאתם אוספים ובדרישות של הארגון. מידע נוסף על מדיניות ההתראות הזמינה מופיע במאמר השוואה בין אפשרויות ההתראות. הגדרת התראות לגבי איומים ספציפיים ל-AI כמו אלה:
| איומים ואותות ספציפיים ל-AI | |
|---|---|
| החדרת פרומפטים | יומנים של הגנה מוגברת על המודל לניקוי או לדחייה של פרומפטים |
| חילוץ פרומפט מערכת | הגנה מוגברת על המודל ואנומליות של מציאה במטמון (cache hit) |
| חשיפה של מידע אישי רגיש | יומני תשובות של Model Armor |
| ניצול לרעה של עלויות הסקת מסקנות | שימוש באסימונים ברמת הסשן מתוך מדדים של Inference Gateway |
| מניפולציה של סשנים | מהירות של סשנים חדשים לכל דייר מתוך מדדים של שער ההסקה |
| יצירת טביעת אצבע דיגיטלית (fingerprinting) של מודל | תבניות של בדיקת יכולות |
| ערוץ צדדי של תזמון | מיטיגציה ברמת הארכיטקטורה (חלוקת המטמון למחיצות) |
הגדרת תהליך תגובה לתקריות אבטחת מידע
הדרך שבה אתם מגיבים לאירועים שונים תלויה במבנה הארגוני ובדרישות האבטחה שלכם. ההנחיות הבאות מתארות מה צריך לעשות כשמזהים סוגים ספציפיים של איומים על עומסי עבודה של AI:
זיהוי תוכן ב-Model Armor: חסימת הבקשה, תיעוד האירוע והגדרת התראה שתשלח אם הקצב יעלה על סף מסוים. הגדרת הגבלת קצב למשתמשים שביצעו הפרות חוזרות.
זיהויים של היקש: ויסות נתונים של דיירים באמצעות Inference Gateway. סיום סשנים במקרים של ניצול לרעה שאומת.
קורלציה בין שכבות: זיהוי של Model Armor בתוספת דפוס של שימוש לרעה בטוקן מצביע על שימוש לרעה מתואם. מגדירים כללי קורלציה ומזהים סף ודאות שאחריו הסיכון להתראת חיובי כוזב נמוך. אוטומציה של סיום סשנים שחוצים את הסף הזה.
הטמעת אבטחה בכל שלב במחזור החיים של הפריסה
אופטימיזציה של פריסות ה-AI לאבטחה לאורך מחזור החיים של הפריסה. במהלך שלבים ספציפיים במחזור החיים, מטמיעים אמצעי בקרה שמגנים על שכבה אחת או יותר. בקטעים הבאים מפורטות הנחיות לכל שלב במחזור החיים.
פריסת התשתית
כשיוצרים או מעצבים את התשתית שמריצה את עומסי העבודה של ה-AI, כדאי להטמיע כמה שיותר מהאמצעים הבאים:
| קטגוריה | |
|---|---|
| צומתי GKE |
|
| Networking |
|
| ניהול זהויות והרשאות גישה |
|
| ניהול מידע אישי רגיש |
|
| ניראות (observability) |
|
הפעלת עומסי עבודה ותשתית
כשפורסים את עומסי העבודה של ה-AI ומריצים מערכת ייצור, כדאי להטמיע כמה שיותר מאמצעי הבקרה הבאים:
| קטגוריה | |
|---|---|
| אבטחת עומסי עבודה |
|
| Networking |
|
| Sensitive data protection | שימוש ב-CMEK להצפנת נתונים באמצעות מפתחות משלכם בסביבות מפוקחות. |
| ניראות (observability) |
|
שליטה בפריסות בקנה מידה נרחב
ככל שהארגון גדל, כדאי להטמיע את אמצעי הבקרה הבאים כדי לאוטומט את ניהול האבטחה:
- הגדרת שכבות הגנה ברמת הארגון באמצעות שירות מדיניות הארגון.
- אכיפת מדיניות בזמן הכניסה באמצעות Admission Webhooks של Kubernetes.
- אוטומציה של התגובה הראשונה לגבי זיהויים ברמת מהימנות גבוהה.
- יצירת קורלציה בין שכבות שונות של SIEM וקביעת קווי בסיס התנהגותיים לכל דייר.
סיכום השיטות המומלצות
בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במסמך הזה:
| נושא | |
|---|---|
| שיפור האבטחה בשכבת התשתית | הגנה על צמתי GKE, הטמעה של אמצעי בקרה ברשת, ניהול של זהויות וגישה, ניהול של מפתחות וסודות ושיפור האבטחה של שרשרת האספקה. |
| שיפור האבטחה בשכבת המודל | לשפר את השלמות של המודל, להגן על הסודיות של המודל ולשפר את מאפייני הבטיחות של המודל. |
| שיפור האבטחה בשכבת האפליקציה | הגנה מפני איומים בשכבת התוכן, הגנה על הנחיות למערכת, ניהול של סשנים וניתוב, ושיפור האבטחה של סוכני AI. |
| הגדרה של יכולות ניטור ותגובה לאירועים | איסוף יומנים ומדדים, זיהוי איומים ספציפיים ל-AI והגדרת תהליך תגובה לאירועים. |
| הטמעת אבטחה בכל שלב במחזור החיים של הפריסה | פריסת תשתית, הפעלת עומסי עבודה ותשתית וניהול פריסות בהיקף נרחב. |