נקודת מבט על AI ו-ML: אבטחה

Last reviewed 2026-10-29 UTC

המסמך הזה הוא חלק מ-Google Cloud Well-Architected Framework: AI and ML perspective, ובו סקירה כללית של העקרונות וההמלצות שיעזרו לכם לוודא שפריסות ה-AI וה-ML עומדות בדרישות האבטחה והתאימות של הארגון. ההמלצות במסמך הזה תואמות לעקרונות האבטחה של Well-Architected Framework.

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

ההמלצות במסמך הזה ממופות לעקרונות הליבה הבאים:

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

  • ‫Secure AI Framework‏ (SAIF) שלGoogle Cloud הוא מדריך מקיף לפיתוח מערכות AI מאובטחות ואחראיות. הוא מתאר עקרונות מרכזיים ושיטות מומלצות לטיפול בשיקולי אבטחה ותאימות לאורך מחזור החיים של ה-AI.
  • בCompliance resource center מוסבר איך אנחנו ב- Google Cloudפועלים כדי להבטיח שה-AI יהיה אמין.

הגדירו יעדים ודרישות ברורים

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

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

כדי להגדיר יעדים ודרישות ברורים, כדאי לפעול לפי ההמלצות הבאות.

התאמת האבטחה של AI ו-ML ליעדים העסקיים

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

  1. הגדירו יעדים עסקיים ודרישות אבטחה ברורים:

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

  2. איזון בין האבטחה לבין הצרכים העסקיים:

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

זיהוי וקטורי תקיפה וסיכונים פוטנציאליים

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

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

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

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

  • ניהול תנוחת האבטחה בענן: אתם יכולים להשתמש ב-Security Command Center כדי לזהות נקודות חולשה פוטנציאליות והגדרות שגויות בתשתית ה-AI.
  • ציוני חשיפה להתקפות ונתיבי התקפה: שיפור ושימוש בציוני החשיפה להתקפות ובנתיבי ההתקפה שנוצרים על ידי Security Command Center.
  • ‫Google Threat Intelligence: קבלת מידע על איומים חדשים ושיטות תקיפה שנועדו לפגוע במערכות AI.
  • רישום ביומן ומעקב: עוקבים אחרי הביצועים והאבטחה של מערכות ה-AI ומזהים חריגות או פעילויות חשודות. לבצע ביקורות אבטחה באופן קבוע כדי לזהות נקודות חולשה פוטנציאליות בתשתית ובמודלים של ה-AI ולטפל בהן.
  • ניהול נקודות חולשה: הטמיעו תהליך לניהול נקודות חולשה כדי לעקוב אחרי נקודות חולשה באבטחה של מערכות ה-AI ולתקן אותן.

למידע נוסף, קראו את המאמרים אבטחה מובנית ב-Google והטמעת אבטחה מובנית.

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

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

כדי לשמור על אבטחת המידע, כדאי לפעול לפי ההמלצות הבאות.

לפעול בהתאם לעקרונות של הגבלה על איסוף המידע

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

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

אתם יכולים להשתמש בתכונות של Google Cloud כדי לשפר את ההגבלה על איסוף המידע ואת פרטיות הנתונים בתרחישים שונים לדוגמה:

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

במאמר הצפנת נתונים במנוחה ובמעבר ב-Well-Architected Framework מפורטות שיטות מומלצות להטמעת הצפנת נתונים.

מעקב אחרי איסוף נתונים, אחסון וטרנספורמציה

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

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

  • כדי להקים פלטפורמה למשילות מידע (data governance) ברמת הארגון או המחלקה, משתמשים ב-Knowledge Catalog. פלטפורמה ל<משילות מידע (data governance)> יכולה לעזור לכם לגלות, לנהל, ל<מעקב> ולפקח על נתונים ו<פריט מידע שנוצר בתהליך פיתוח (Artifact)>ים של <AI> בכל פלטפורמות הנתונים שלכם. פלטפורמת משילות המידע גם מספקת גישה למשתמשים מהימנים. אתם יכולים לבצע את המשימות הבאות באמצעות Knowledge Catalog:
    • ניהול שושלת נתונים. ב-BigQuery אפשר גם לראות את שושלת היוחסין ברמת העמודה.
    • לנהל בדיקות של איכות הנתונים ופרופילים של נתונים.
    • לנהל את גילוי הנתונים, הניתוח והעיבוד שלהם במאגרי נתונים שונים.
    • ניהול מטא-נתונים של מאפיינים ורכיבי מודלים.
    • יצירת מילון מונחים ארגוני כדי לנהל מטא-נתונים וליצור אוצר מילים סטנדרטי.
    • העשרת המטא-נתונים בהקשר באמצעות היבטים וסוגי היבטים.
    • לאחד את משילות המידע ב-BigLake ובטבלאות בפורמט פתוח כמו Iceberg ו-Delta.
    • בניית רשת נתונים כדי לבזר את הבעלות על הנתונים בין בעלי נתונים מצוותים או מדומיינים שונים. השיטה הזו תואמת לעקרונות של אבטחת מידע, והיא יכולה לעזור לשפר את הנגישות לנתונים ואת היעילות התפעולית.
    • בדיקה ושליחה של תוצאות של נתונים רגישים מ-BigQuery אל Knowledge Catalog.
  • כדי ליצור lakehouse פתוח ומאוחד עם ניהול תקין, אתם יכולים לשלב את אגמי הנתונים ומחסני הנתונים עם שירותי מטא-נתונים מנוהלים כמו Dataproc Metastore וקטלוג ייעודי לזמן ריצה של Lakehouse. ב-lakehouse פתוח נעשה שימוש בפורמטים פתוחים של טבלאות שתואמים למנועים שונים של עיבוד נתונים.
  • כדי לתזמן את המעקב אחרי מאפיינים וקבוצות של מאפיינים, משתמשים ב-Agent Platform Feature Store.
  • כדי לסרוק את מערכי הנתונים של Agent Platform ברמת הארגון, התיקייה או הפרויקט, השתמשו בזיהוי מידע אישי רגיש ב-Agent Platform. אתם יכולים גם לנתח את פרופילי הנתונים שמאוחסנים ב-BigQuery.
  • כדי לתעד יומנים בזמן אמת ולאסוף מדדים שקשורים לפייפליינים, משתמשים ב-Cloud Logging וב-Cloud Monitoring. כדי לאסוף נתיבי ביקורת של קריאות ל-API, השתמשו ביומני הביקורת של Cloud. אל תתעדו פרטים אישיים מזהים או נתונים סודיים בניסויים או בשרתי יומנים שונים.

הטמעת בקרות גישה מבוססות-תפקידים עם עקרונות של הרשאות מינימליות

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

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

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

  • כדי להטמיע רמת פירוט של גישה, כדאי להשתמש באפשרויות הבאות:

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

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

  • כדי להגביל את הגישה למשאבים מסוימים, אתם יכולים להשתמש בכללי מדיניות של גבולות גישה של חשבונות משתמשים (PAB). אתם יכולים גם להשתמש ב-Privileged Access Manager כדי לשלוט בהעלאת רמת ההרשאות באופן זמני ובדיוק בזמן לחשבונות משתמשים נבחרים. בהמשך תוכלו לראות את יומני הביקורת של הפעילות הזו ב-Privileged Access Manager.

  • כדי להגביל את הגישה למשאבים על סמך כתובת ה-IP ומאפייני המכשיר של משתמש הקצה, אתם יכולים להרחיב את כללי מדיניות הגישה של שרת proxy לאימות זהויות (IAP).

  • כדי ליצור דפוסי גישה לקבוצות שונות של משתמשים, אתם יכולים להשתמש בבקרת גישה של Agent Platform עם IAM כדי לשלב את התפקידים המוגדרים מראש או בהתאמה אישית.

  • כדי להגן על מכונות Workbench של Gemini Enterprise Agent Platform באמצעות אמצעי בקרה של בקרת גישה מבוססת-הקשר, משתמשים ב-Access Context Manager וב-Chrome Enterprise Premium. בגישה הזו, הגישה נבדקת בכל פעם שמשתמש מאמת את עצמו במכונה.

הטמעת אמצעי אבטחה להעברת נתונים

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

כדי למנוע זליגה ואובדן של נתונים ב- Google Cloud, אתם יכולים להשתמש בשילוב של כלים ושירותים לאבטחה.

כדי להטמיע הצפנה, כדאי:

  • כדי לקבל יותר שליטה על מפתחות ההצפנה, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud Key Management Service. כשמשתמשים במפתחות CMEK, השירותים הבאים שמשולבים עם CMEK מצפינים את הנתונים במנוחה:
  • כדי להגן על הנתונים שלכם ב-Cloud Storage, אתם יכולים להשתמש בהצפנה בצד השרת כדי לאחסן את מפתחות ה-CMEK. אם אתם מנהלים את מפתחות ה-CMEK בשרתים שלכם, הצפנה בצד השרת יכולה לעזור להגן על מפתחות ה-CMEK והנתונים שמשויכים אליהם, גם אם מערכת האחסון של מפתחות ה-CMEK נפרצה.
  • כדי להצפין נתונים במעבר, צריך להשתמש ב-HTTPS לכל הקריאות ל-API לשירותי AI ו-ML. כדי לאכוף את השימוש ב-HTTPS באפליקציות ובממשקי ה-API, השתמשו במאזני עומסים ב-HTTPS.

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

כדי להטמיע היקפים, כדאי:

  • כדי ליצור גבול אבטחה מסביב למשאבי ה-AI וה-ML ולמנוע זליגת נתונים מהענן הפרטי הווירטואלי (VPC), אתם יכולים להשתמש ב-VPC Service Controls כדי להגדיר גבולות גזרה לשירות. לכלול במתחם את משאבי ה-AI וה-ML ואת המידע האישי הרגיש. כדי לשלוט בזרימת הנתונים, מגדירים כללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) לגבולות הגזרה.
  • כדי להגביל את תעבורת הנתונים הנכנסת והיוצאת למשאבי ה-AI וה-ML, מגדירים כללים של חומת אש. הטמיעו כללי מדיניות שדוחים את כל התנועה כברירת מחדל, ומאפשרים באופן מפורש רק את התנועה שעומדת בקריטריונים שלכם. לדוגמה למדיניות, ראו דוגמה: דחיית כל החיבורים החיצוניים מלבד ליציאות ספציפיות.

כדי להגביל את העברת הנתונים, כדאי:

  • כדי לשתף נתונים ולהרחיב את הפעילות מעבר לגבולות הפרטיות בסביבה מאובטחת, השתמשו בשיתוף ב-BigQuery ובחדרים נקיים לנתונים ב-BigQuery, שמספקים מסגרת אבטחה ופרטיות חזקה.
  • כדי לשתף נתונים ישירות ליעדים מובנים ממרכזי בקרה של בינה עסקית, השתמשו ב-Looker Action Hub, שמספק סביבת ענן מאובטחת.

הגנה מפני הרעלת נתונים

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

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

Google Cloud יכולות לעזור לכם להטמיע אמצעי הגנה נוספים מפני הרעלת נתונים:

  • כדי לאמת את תקינות הנתונים, כדאי:

    • לפני שמשתמשים בנתונים לאימון, חשוב להטמיע בדיקות אימות נתונים קפדניות. בודקים את הפורמטים, הטווחים וההתפלגויות של הנתונים. אתם יכולים להשתמש ביכולות האוטומטיות של Knowledge Catalog לבדיקת איכות הנתונים.
    • כדי ליהנות מיכולות מקיפות למניעת אובדן נתונים, אתם יכולים להשתמש ב-Sensitive Data Protection עם "הגנה מוגברת על המודל". מידע נוסף מופיע במאמר סקירה כללית על Model Armor. Sensitive Data Protection עם Model Armor מאפשר לכם לגלות, לסווג ולהגן על מידע רגיש, כמו קניין רוחני. היכולות האלה יכולות לעזור לכם למנוע חשיפה לא מורשית של מידע אישי רגיש באינטראקציות עם מודלים מסוג LLM.
    • כדי לזהות חריגות בנתוני האימון שעשויות להצביע על הרעלת נתונים, השתמשו בזיהוי חריגות ב-BigQuery באמצעות שיטות סטטיסטיות או מודלים של למידת מכונה.

  • כדי להתכונן לאימון מקיף, צריך לבצע את הפעולות הבאות:

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

  • כדי לשלב בדיקה אנושית של נתוני אימון או פלט מהמודל:

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

כדי לקרוא על שיטות מומלצות ליצירת פלטפורמות נתונים שמתמקדות באבטחת התשתית והנתונים, קראו את העיקרון הטמעת אבטחה באמצעות תכנון ב-Well-Architected Framework.

שמירה על אבטחה וחוזק של צינורות עיבוד נתונים (pipeline) של AI מפני שיבושים

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

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

שימוש בשיטות קידוד מאובטחות

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

כדי להטמיע אימות קפדני, כדאי:

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

    • משתמשים ב-Model Armor או במודלי LLM שעברו כוונון כדי לסנן באופן אוטומטי הנחיות ותשובות עם סיכונים נפוצים.
    • הטמיעו אימות נתונים בסקריפטים של הטמעת הנתונים ושל העיבוד המקדים, כדי לוודא שסוגי הנתונים, הפורמטים והטווחים תקינים. ב-Gemini Enterprise Agent Platform Pipelines או ב-BigQuery, אתם יכולים להשתמש ב-Python כדי להטמיע את אימות הנתונים הזה.
    • להשתמש בסוכני LLM לעזרה בתכנות, כמו CodeMender, כדי לשפר את אבטחת הקוד. חשוב שיהיה אדם בתהליך שיאמת את השינויים שהמערכת מציעה.

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

  • כדי לצמצם את הסיכונים לאורך מחזור החיים של ה-AI, אתם יכולים להשתמש בניהול סיכונים במערכות AI כדי:

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

כדי לאבטח את יחסי התלות של הקוד והפריטים ב-pipeline של ה-CI/CD:

  • כדי לטפל בסיכונים שתלויות של ספריות קוד פתוח יכולות להציג בפרויקט, אתם יכולים להשתמש ב-Artifact Analysis עם Artifact Registry כדי לזהות נקודות חולשה ידועות. להשתמש בגרסאות המאושרות של הספריות ולתחזק אותן. אחסון חבילות ML בהתאמה אישית ויחסי תלות שנבדקו במאגר פרטי ב-Artifact Registry.
  • כדי להטמיע סריקת יחסי תלות בצינורות עיבוד הנתונים של MLOps ב-Cloud Build, משתמשים ב-Binary Authorization. לאכוף כללי מדיניות שמאפשרים פריסות רק אם קובצי האימג' של הקונטיינרים של הקוד עוברים את בדיקות האבטחה.
  • כדי לקבל מידע על האבטחה של שרשרת האספקה של התוכנה, אתם יכולים להשתמש במרכזי הבקרה במסוף Google Cloud שמספקים פרטים על מקורות, גרסאות build, פריטי מידע שנוצרו בתהליך הפיתוח (Artifact), פריסות וזמני ריצה. המידע הזה כולל פרצות אבטחה בארטיפקטים של גרסאות build, אישור המקור של Build ורשימות של יחסי תלות של רשימת רכיבי תוכנה (SBOM).
  • כדי להעריך את רמת הבשלות של אבטחת שרשרת האספקה של התוכנה, אתם יכולים להשתמש במסגרת Supply chain Levels for Software Artifacts‏ (SLSA).

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

  • כדי למנוע חשיפה של מידע אישי רגיש מאינטראקציות עם המודל, אתם יכולים להשתמש ב-Logging עם Sensitive Data Protection. כשמשתמשים במוצרים האלה ביחד, אפשר לקבוע אילו נתונים יתועדו ביומן על ידי אפליקציות ה-AI ורכיבי צינור עיבוד הנתונים, ולהסתיר נתונים רגישים.
  • כדי ליישם את העקרון של הרשאות מינימליות, ודאו שלחשבונות השירות שאתם משתמשים בהם למשימות ייעודיות, לפייפליינים ולמודלים שנפרסו ב-Agent Platform יש רק את הרשאות ה-IAM המינימליות הנדרשות. מידע נוסף זמין במאמר הטמעה של בקרות גישה מבוססות-תפקידים עם עקרונות של הרשאות מינימליות.
  • כדי לאבטח ולהגן על צינורות עיבוד הנתונים ועל פריטי המידע שנוצרו בתהליך פיתוח התוכנה, חשוב להבין את הגדרות האבטחה (VPC ו-VPC Service Controls) בסביבה שבה הקוד פועל.

הגנה על צינורות עיבוד נתונים ופריטי מידע שנוצרו במודל מפני גישה לא מורשית

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

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

  • כדי להגן על פריטי מידע שנוצרו במודל ועל קבצים רגישים אחרים, הצפינו אותם באמצעות Cloud KMS. ההצפנה הזו עוזרת להגן על נתונים במנוחה ובמעבר, גם אם האחסון הבסיסי נפגע.
  • כדי לאבטח את הגישה לקבצים, כדאי לאחסן אותם ב-Cloud Storage ולהגדיר אמצעי בקרת גישה.
  • כדי לעקוב אחרי הגדרות שגויות או לא מספיקות וכל חריגה מהסטנדרטים שהגדרתם, אתם יכולים להשתמש ב-Security Command Center כדי להגדיר מצבי אבטחה.
  • כדי להפעיל בקרת גישה מפורטת והצפנה במנוחה, צריך לאחסן את פריטי המודל ב-מרשם המודלים ב-Gemini Enterprise Agent Platform. כדי להגביר את האבטחה, צרו חתימה דיגיטלית לחבילות ולקונטיינרים שנוצרים במהלך תהליכי ה-build שאושרו.
  • כדי ליהנות מהאבטחה ברמה שמתאימה לארגונים של Google Cloud, צריך להשתמש במודלים שזמינים ב-Model Garden. ב-Model Garden יש מודלים קנייניים של Google ומודלים של צד שלישי משותפים נבחרים.

  • כדי לאכוף ניהול מרכזי של כל מחזורי החיים של המשתמשים והקבוצות, וכדי לאכוף את העיקרון של הרשאות מינימליות, צריך להשתמש ב-IAM.

    • יוצרים חשבונות שירות ייעודיים עם הרשאות מינימליות לצינורות עיבוד הנתונים של MLOps, ומשתמשים בהם. לדוגמה, לחשבון השירות של צינור עיבוד הנתונים לאימון יש הרשאות לקרוא נתונים רק מקטגוריה ספציפית של Cloud Storage, ולכתוב פריטי מידע שנוצרו בתהליך הפיתוח (Artifact) של המודל ב-Model Registry.
    • להשתמש בתנאי IAM כדי לאכוף בקרת גישה מותנית שמבוססת על מאפיינים. לדוגמה, תנאי שמאפשר לחשבון שירות להפעיל צינור עיבוד נתונים של Agent Platform רק אם הבקשה מגיעה מטריגר לפיתוח גרסת Build מהימן של Cloud Build.

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

  • כדי לנהל את שלבי ה-MLOps בשירותים ובמשאבים של Google Cloud , אתם יכולים להשתמש ב-Agent Platform Pipelines, שאפשר לשלב עם שירותים אחרים ולקבל גישה ברמה נמוכה לבקרת גישה. כשמפעילים מחדש את צינורות עיבוד הנתונים, חשוב לבצע הערכות של יכולת ההסבר (כמו שיוך תכונות) ובדיקות של AI אחראי לפני שפורסים את פריטי המידע שנוצרו בתהליך הפיתוח של המודל. הבדיקות האלה יכולות לעזור לכם לזהות או למנוע את בעיות האבטחה הבאות:

    • שינויים לא מורשים, שיכולים להצביע על פגיעה במודל.
    • פרצת אבטחה XSS‏ (cross-site scripting), שיכולה להצביע על קובצי אימג' של קונטיינרים או יחסי תלות שנפגעו.
    • נקודות קצה לא מאובטחות, שיכולות להצביע על הגדרה שגויה של תשתית ההצגה.

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

  • כדי להפוך את המעקב אחרי שינויים בקוד לאוטומטי, השתמשו ב-Git לניהול קוד המקור, ושלבו את ניהול הגרסאות עם פייפליינים חזקים של CI/CD.

מידע נוסף זמין במאמר Secure AI Framework ‏(SAIF).

אכיפת שושלת ומעקב

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

כדי לאכוף ביעילות את השושלת והמעקב ב- Google Cloud, כדאי להשתמש בכלים ובשירותים הבאים:

  • כדי לעקוב אחרי שושלת היוחסין של מודלים, מערכי נתונים ופריטי מידע שנוצרו בתהליך הפיתוח (artifacts) שמוצפנים באופן אוטומטי במנוחה, משתמשים במטא-נתונים של למידת מכונה ב-Agent Platform. מתעדים מטא-נתונים על מקורות נתונים, טרנספורמציות, פרמטרים של מודלים ותוצאות של ניסויים.
  • כדי לעקוב אחרי שושלת היוחסין של פריטי המידע שנוצרו בתהליך מ-Agent Platform Pipelines, ולחפש משאבים של מודלים וקבוצות נתונים, אתם יכולים להשתמש ב-Knowledge Catalog. מעקב אחרי פריטי מידע שנוצרו בתהליך (artifacts) ספציפיים של צינור עיבוד הנתונים, כשרוצים לבצע ניפוי באגים, לפתור בעיות או לנתח את שורש הבעיה. כדי לעקוב אחרי כל צינור עיבוד הנתונים של MLOps, כולל שושלת היוחסין של פריטי המידע שנוצרו בתהליך, משתמשים ב-Agent Platform ML Metadata. בעזרת Agent Platform ML Metadata אתם יכולים גם לנתח את המשאבים וההרצות. במרשם המודלים מוחלות ומנוהלות הגרסאות של כל מודל שאתם מאחסנים.
  • כדי לעקוב אחרי קריאות ל-API ופעולות ניהוליות, צריך להפעיל את יומני הביקורת של Agent Platform. ניתוח יומני ביקורת באמצעות Observability Analytics כדי להבין מי ניגש לנתונים ולמודלים או שינה אותם, ומתי. אפשר גם לנתב יומנים ליעדים של צד שלישי.

פריסה במערכות מאובטחות באמצעות כלים ופריטי מידע שנוצרו בתהליך הפיתוח (artifacts) מאובטחים

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

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

אימון ופריסה של מודלים בסביבה מאובטחת

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

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

כדי לאמן את מודלי ה-ML שלכם בסביבה עם אבטחה משופרת, השתמשו בשירותים מנוהלים ב- Google Cloud כמו Cloud Run,‏ Google Kubernetes Engine (GKE) ו-Managed Service for Apache Spark. אפשר גם להשתמש באימון ללא שרת (serverless) ב-Agent Platform.

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

כדי לאבטח את הסביבה ואת גבולות האבטחה:

כדי לאבטח את הפריסה:

  • כשפורסים מודלים, משתמשים ב-Model Registry. אם אתם פורסים מודלים בקונטיינרים, השתמשו ב-GKE Sandbox ובמערכת הפעלה שמותאמת לקונטיינרים כדי לשפר את האבטחה ולבודד עומסי עבודה. להגביל את הגישה למודלים מ-Model Garden בהתאם לתפקידים ולתחומי האחריות של המשתמשים.
  • כדי לאבטח את ממשקי ה-API של המודלים, אתם יכולים להשתמש ב-Apigee או ב-API Gateway. כדי למנוע ניצול לרעה, כדאי להטמיע מפתחות API, אימות, הרשאה והגבלת קצב של יצירת בקשות. כדי לשלוט בגישה לממשקי ה-API של המודל, השתמשו במפתחות API ובמנגנוני אימות.
  • כדי לאבטח את הגישה למודלים במהלך החיזוי, השתמשו ב-Gemini Enterprise Agent Platform Inference. כדי למנוע זליגת נתונים, השתמשו בהיקפים של VPC Service Controls כדי להגן על נקודות קצה פרטיות ולנהל את הגישה למודלים הבסיסיים. אתם משתמשים בנקודות קצה פרטיות כדי לאפשר גישה למודלים ברשת VPC. IAM לא מוחל ישירות על נקודת הקצה הפרטית, אבל שירות היעד משתמש ב-IAM כדי לנהל את הגישה למודלים. לחיזוי אונליין, מומלץ להשתמש ב-Private Service Connect.
  • כדי לעקוב אחרי קריאות ל-API שקשורות לפריסת מודלים, צריך להפעיל את יומני הביקורת של Cloud ב-Agent Platform. קריאות רלוונטיות ל-API כוללות פעילויות כמו יצירת נקודת קצה, פריסת מודל ועדכוני הגדרות.
  • כדי להרחיב את התשתית של Google Cloud למיקומי קצה, כדאי להשתמש בפתרונות של Google Distributed Cloud. כדי להשתמש בפתרון מנותק לחלוטין, אתם יכולים להשתמש ב-Distributed Cloud air-gapped, שלא דורש קישוריות ל- Google Cloud.
  • כדי ליצור סטנדרטיזציה של פריסות ולהבטיח תאימות לדרישות רגולטוריות וצורכי אבטחה, השתמשו ב-Assured Workloads.

לפעול לפי הנחיות SLSA לגבי פריטי מידע שנוצרו על ידי AI

פועלים לפי ההנחיות הרגילות של Supply-chain Levels for Software Artifacts‏ (SLSA) לגבי פריטי ה-AI, כמו מודלים וחבילות תוכנה.

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

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

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

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

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

    • בקרת מקור: משתמשים במערכת לניהול גרסאות כמו Git כדי לעקוב אחרי שינויים בקוד ובהגדרות.
    • תהליך ה-build: השתמשו בשירות שעוזר לאבטח את גרסאות ה-build, כמו Cloud Build, וודאו שתהליך ה-build מבוסס על סקריפטים או אוטומטי.
    • יצירת נתוני מקור: יצירת מטא-נתונים של מקור שמתעדים פרטים על האופן שבו נוצרו פריטי המידע, כולל תהליך ה-build, קוד המקור והתלויות. לפרטים, ראו מעקב אחרי מטא-נתונים ומעקב אחרי הפעלות ופריטי מידע שנוצרו בתהליך הפיתוח (artifacts).
    • חתימה על פריטי מידע שנוצרו בתהליך הפיתוח (Artifact): חתימה על פריטי המידע שנוצרו בתהליך הפיתוח כדי לאמת את האותנטיות והתקינות שלהם.
    • ניהול נקודות חולשה: סריקה קבועה של פריטי המידע שנוצר בתהליך הפיתוח (Artifact) והתלויות כדי לאתר נקודות חולשה. משתמשים בכלים כמו Artifact Analysis.
    • אבטחת פריסה: הטמעת שיטות פריסה שעוזרות לאבטח את המערכות, כמו השיטות שמתוארות במסמך הזה.

  5. שיפור מתמשך: עוקבים אחרי הטמעת ה-SLSA ומשפרים אותה כדי להתמודד עם איומים ונקודות חולשה חדשים, ושואפים להגיע לרמות SLSA גבוהות יותר.

שימוש בקובצי אימג' מאומתים של קונטיינרים מוגדרים מראש

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

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

  • הקצו בארגון צוות פלטפורמה מרכזי שיבנה וינהל קונטיינרים בסיסיים סטנדרטיים.
  • להרחיב את קובצי האימג' של הקונטיינרים שנוצרו מראש, ש-Agent Platform מספקת במיוחד ל-AI ול-ML. ניהול קובצי האימג' של הקונטיינרים במאגר מרכזי בארגון.

ב-Agent Platform יש מגוון קונטיינרים מובְנים לאימון ולהסקה, ואפשר גם להשתמש בקונטיינרים בהתאמה אישית. במודלים קטנים יותר, אפשר להפחית את זמן האחזור של ההסקה אם טוענים מודלים בקונטיינרים.

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

  • משתמשים ב-Artifact Registry כדי ליצור, לאחסן ולנהל מאגרים של קובצי אימג' של קונטיינרים בפורמטים שונים. ב-Artifact Registry, בקרת הגישה מתבצעת באמצעות IAM, והוא כולל תכונות משולבות של ניראות והערכת נקודות חולשה. ב-Artifact Registry אתם יכולים להפעיל אמצעי אבטחה של קונטיינרים, לסרוק קובצי אימג' של קונטיינרים ולחקור נקודות חולשה.
  • מריצים שלבים של אינטגרציה רציפה (CI) ויוצרים קובצי אימג' של קונטיינרים באמצעות Cloud Build. בשלב הזה אפשר להדגיש בעיות שקשורות לתלות. אם רוצים לפרוס רק את קובצי האימג' שנוצרו על ידי Cloud Build, אפשר להשתמש ב-Binary Authorization. כדי למנוע התקפות על שרשרת האספקה, פורסים את קובצי האימג' שנוצרו על ידי Cloud Build ב-Artifact Registry. לשלב כלי בדיקה אוטומטיים כמו SonarQube,‏ PyLint או OWASP ZAP.
  • להשתמש בפלטפורמת קונטיינרים כמו GKE או Cloud Run, שמותאמות ל-GPU או ל-Cloud TPU לעומסי עבודה של AI ו-ML. כדאי לבדוק את האפשרויות לסריקת נקודות חולשה בקונטיינרים באשכולות GKE.

שימוש ב-Confidential Computing ל-GPU

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

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

אם הגדרתם Confidential Computing, כדאי לשקול את האפשרויות הבאות:

  • לעומסי עבודה של AI ו-ML למטרות כלליות, השתמשו במכונות וירטואליות חסויות עם מעבדי GPU מסוג NVIDIA T4. במכונות הווירטואליות האלה, הנתונים שבשימוש מוצפנים באמצעות חומרה.
  • לעומסי עבודה בקונטיינרים, השתמשו ב-Confidential Google Kubernetes Engine Nodes. הצמתים האלה מספקים סביבה מאובטחת ומבודדת לפודים שלכם.
  • כדי לוודא שעומס העבודה פועל במובלעת אמיתית ומאובטחת, אמתו את דוחות האימות ש-Confidential VM מספק.
  • כדי לעקוב אחרי הביצועים, ניצול המשאבים ואירועי האבטחה, אתם יכולים להשתמש ב-Monitoring וב-Logging כדי לעקוב אחרי המשאבים של Confidential Computing ו-Confidential GKE Nodes.

אימות והגנה על קלט

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

כדי לאמת את הקלט ולהגן עליו, כדאי לפעול לפי ההמלצות הבאות.

הטמעת שיטות שעוזרות לאבטח מערכות AI גנרטיבי

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

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

כדי לשפר את האבטחה של תכנון והנדסת ההנחיות, כדאי לפעול לפי השיטות הבאות:

  • מבנה הנחיות ברור: תכננו ובדקו את כל ההנחיות שלכם באמצעות יכולות ניהול ההנחיות של Agent Studio ב-Gemini Enterprise Agent Platform. ההנחיות צריכות להיות ברורות וחד-משמעיות. הגדירו תפקיד, כללו פרומפט עם כמה דוגמאות (few-shot) ותנו הוראות ספציפיות ומוגבלות. השיטות האלה מפחיתות את הסיכון שהמודל יפרש באופן שגוי את הקלט של המשתמש, באופן שיוצר פרצת אבטחה.

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

    • בדיקות פאזינג (fuzzing).
    • בדיקה ישירה של פרטים אישיים מזהים, קלט רגיש והזרקות SQL.
    • סריקת קלט מולטי-מודאלי שיכול להכיל תוכנות זדוניות או להפר את המדיניות בנושא הנחיות.

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

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

כדי לסנן הנחיות ותשובות באופן אוטומטי, כדאי:

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

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

  • הטמעת ניהול גרסאות להנחיות: התייחסו לכל ההנחיות בסביבת הייצור כמו לקוד אפליקציה. השתמשו במערכת לניהול גרסאות כמו Git כדי ליצור היסטוריה מלאה של השינויים, לאכוף סטנדרטים של שיתוף פעולה ולאפשר החזרה למצב קודם לגרסאות קודמות. השיטה הבסיסית הזו של MLOps יכולה לעזור לכם לשמור על מערכות AI יציבות ומאובטחות.
  • ניהול הנחיות מרוכז: אתם יכולים להשתמש במאגר מרכזי כדי לאחסן, לנהל ולפרוס את כל ההנחיות עם הגרסאות. האסטרטגיה הזו אוכפת עקביות בין הסביבות ומאפשרת עדכונים בזמן ריצה בלי צורך לפרוס מחדש את האפליקציה.
  • ביצוע בדיקות קבועות ובדיקות של צוות אדום: בודקים את ההגנות של המערכת באופן קבוע כדי לזהות נקודות חולשה ידועות, כמו אלה שמפורטות ברשימת OWASP Top 10 for LLM Applications. כמהנדסי AI, אתם צריכים להיות פרואקטיביים ולבצע בדיקות צוות אדום באפליקציה שלכם כדי לגלות ולתקן נקודות חולשה לפני שתוקפים יוכלו לנצל אותן.

מניעת שאילתות זדוניות למערכות ה-AI שלכם

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

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

  • שכבות מאובטחות של רשתות ואפליקציות: הגנה רב-שכבתית לכל נכסי ה-AI.

    • כדי ליצור מתחם אבטחה היקפית שמונע זליגת נתונים של מודלים מ-Model Registry או של נתונים רגישים מ-BigQuery, אתם יכולים להשתמש ב-VPC Service Controls. תמיד כדאי להשתמש במצב פרימטר לבדיקות כדי לבדוק את ההשפעה של פרימטר לפני שאוכפים אותו.
    • כדי להגן על כלים מבוססי-אינטרנט כמו Notebooks, השתמשו ב-IAP.
    • כדי לאבטח את כל נקודות הקצה להסקת מסקנות, השתמשו ב-Apigee לאבטחה ופיקוח ברמה שמתאימה לארגונים. אפשר גם להשתמש ב-API Gateway לאימות פשוט.

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

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

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

מעקב, הערכה והכנה לתגובה לפלטים

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

כדי לשמור על התוצרים, כדאי לפעול לפי ההמלצות הבאות.

הערכת הביצועים של המודל באמצעות מדדים ואמצעי אבטחה

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

כדי להעריך את החוסן ואת מצב האבטחה של המודל, כדאי לפעול לפי ההמלצות הבאות:

  • הטמיעו חתימה ואימות של מודלים בצינור עיבוד הנתונים של MLOps.

    • במודלים בקונטיינרים, משתמשים ב-Binary Authorization כדי לאמת חתימות.
    • במודלים שנפרסים ישירות בנקודות קצה של Agent Platform, צריך להשתמש בבדיקות בהתאמה אישית בסקריפטים של הפריסה כדי לבצע אימות.
    • בכל מודל, משתמשים ב-Cloud Build לחתימה על המודל.

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

    • בכל המודלים, בודקים אם יש פגיעות נפוצות בנתונים ושינויים זדוניים פוטנציאליים בנתונים. כדי לתזמר את הבדיקות האלה, אתם יכולים להשתמש ב-Agent Platform Managed Training או ב-Agent Platform Pipelines.
    • במודלים שבהם האבטחה היא קריטית, כדאי לבצע סימולציות של מתקפות יריב כדי להבין את נקודות החולשה הפוטנציאליות.
    • במודלים שנפרסים בקונטיינרים, משתמשים ב-Artifact Analysis ב-Artifact Registry כדי לסרוק את קובצי האימג' הבסיסיים לאיתור נקודות חולשה.

  • אתם יכולים להשתמש ב-Model Monitoring ב-Gemini Enterprise Agent Platform כדי לזהות סטיות ושינויים במודלים שנפרסו. לאחר מכן, מזינים את התובנות האלה בחזרה למחזורי ההערכה מחדש או האימון מחדש.

  • שימוש בהערכות מודלים מ-Agent Platform כרכיב צינור עיבוד נתונים באמצעות Agent Platform Pipelines. אפשר להריץ את רכיב הערכת המודל לבד או עם רכיבי צינור עיבוד נתונים אחרים. משווים בין גרסאות המודל לבין המדדים וקבוצות הנתונים שהגדרתם. מתעדים את תוצאות ההערכה ב-Agent Platform ML Metadata לצורך מעקב ושושלת נתונים.

  • להשתמש בשירות ההערכה של AI גנרטיבי או להרחיב אותו כדי להעריך את המודלים שבחרתם או להטמיע תהליכי עבודה מותאמים אישית של הערכה אנושית.

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

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

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

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

כדי לעקוב אחרי הפלט של מערכת ה-AI ולזהות חריגות, איומים וירידה באיכות, מומלץ:

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

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

  • זיהוי ניסיונות גישה לא מורשים למודלים של AI, למערכי נתונים ב-Cloud Storage או ב-BigQuery, או לרכיבים של צינור עיבוד נתונים של MLOps. חשוב במיוחד לזהות שינויים לא צפויים או לא מורשים בהרשאות IAM למשאבי AI. כדי לעקוב אחרי הפעילויות האלה ולבדוק אם יש בהן דפוסים חשודים, אתם יכולים להשתמש ביומני הביקורת של פעילות אדמין וביומני הביקורת של גישה לנתונים ב-Cloud Audit Logs. לשלב את הממצאים מ-Security Command Center, שיכול לסמן הגדרות אבטחה שגויות ואיומים פוטנציאליים שרלוונטיים לנכסי ה-AI שלכם.
  • עוקבים אחרי הפלטים כדי לזהות נפחים גדולים של בקשות או בקשות ממקורות חשודים, שיכולים להצביע על ניסיונות להנדסה הפוכה של מודלים או על זליגת נתונים. אתם יכולים גם להשתמש ב-Sensitive Data Protection כדי לעקוב אחרי זליגה של מידע שעלול להיות רגיש.
  • לשלב יומנים בפעולות האבטחה. אתם יכולים להשתמש ב-Google Security Operations כדי לזהות איומי סייבר במערכות ה-AI, לתזמר אותם ולהגיב להם.

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

  • לזהות בעיות תפעוליות שיכולות להשפיע על אספקת השירות או על ביצועי המודל.
  • עוקבים אחרי נקודות הקצה של Agent Platform כדי לזהות זמן אחזור, שיעורי שגיאות ודפוסי תנועה.
  • לעקוב אחרי צינורות עיבוד נתונים של MLOps כדי לבדוק את סטטוס ההפעלה ולחפש שגיאות.
  • להשתמש ב-Monitoring, שמספק מדדים מוכנים. אתם יכולים גם ליצור מרכזי בקרה בהתאמה אישית כדי לזהות בעיות כמו הפסקות בנקודות הקצה או כשלים בצינור עיבוד הנתונים.

הטמעת נהלים להתראות ולתגובה לאירועים

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

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

  • להגדיר התראות לפעולה כדי להודיע לצוותים הרלוונטיים, על סמך פעילויות המעקב של הפלטפורמה. לדוגמה, אפשר להגדיר התראות שיופעלו כשבמעקב אחרי המודל ב-Agent Platform מזוהות אנומליות משמעותיות בחיזוי, בסטייה או בהטיה. אפשר גם להגדיר התראות שיופעלו כשכללי המעקב המותאמים אישית או Model Armor יסמנו קלט זדוני או פלט לא בטוח.
  • הגדירו ערוצי התראות ברורים, שיכולים לכלול את Slack, אימייל או SMS באמצעות שילובים של Pub/Sub. התאימו אישית את ערוצי ההתראות לפי חומרת ההתראה והצוותים האחראים.

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

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

    • מזהים נכסי AI קריטיים, כמו מודלים, מערכי נתונים ומשאבים ספציפיים של Agent Platform, כמו נקודות קצה או מכונות של Feature Store.
    • מזהים את מצבי הכשל או את וקטורי התקיפה הפוטנציאליים של הנכסים.

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

      • החזרה למצב קודם של מודל באמצעות ניהול גרסאות ב-מרשם המודלים.
      • תהליך אימון מחדש למקרי חירום ב-Agent Platform Managed Training.
      • בידוד של מקור נתונים שנפגע ב-BigQuery או ב-Cloud Storage.

    • להשתמש ב-IAM כדי לוודא שלצוותי התגובה יש את הגישה המינימלית הנדרשת לכלים שדרושים במהלך אירוע.

  • זיהוי ומיון: שימוש בהתראות שהוגדרו כדי לזהות ולאמת אירועים פוטנציאליים. הגדירו קריטריונים וספים ברורים לחקירה או להכרזה של הארגון על תקרית שקשורה ל-AI. כדי לבצע חקירה מפורטת ולאסוף ראיות, השתמשו ב-Logging ליומני אפליקציות וליומני שירות, וב-Cloud Audit Logs לפעילויות אדמין ולדפוסי גישה לנתונים. צוותי אבטחה יכולים להשתמש ב-Google SecOps כדי לבצע ניתוחים מעמיקים יותר של נתוני טלמטריה באבטחה.

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

    • משביתים את נקודת הקצה הבעייתית ב-Agent Platform.
    • לבטל הרשאות IAM ספציפיות.
    • עדכון כללי חומת האש או כללי מדיניות Google Cloud Armor.
    • להשהות צינור עיבוד נתונים של Agent Platform שלא פועל כמו שצריך.

  • מיגור: זיהוי והסרה של שורש הבעיה. השלב הזה יכול לכלול את המשימות הבאות:

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

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

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

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

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

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

שותפים ביצירת התוכן

מחברים:

תורמים אחרים:

הקודם
מצוינות תפעולית
הבא
אמינות