העמודה "אבטחה, פרטיות ותאימות" ב-Google Cloud Well-Architected Framework כוללת המלצות שיעזרו לכם לתכנן, לפרוס ולהפעיל עומסי עבודה בענן שעומדים בדרישות שלכם בנושאי אבטחה, פרטיות ותאימות.
המסמך הזה נועד להציע תובנות חשובות ולענות על הצרכים של מגוון מהנדסים ומומחי אבטחה. בטבלה הבאה מפורטים קהלי היעד של המסמך הזה:
| קהל | מה כולל המסמך הזה |
|---|---|
| מנהלי אבטחת מידע (CISO), מנהלי יחידות עסקיות ומנהלי IT | מסגרת כללית להקמה ולתחזוקה של אבטחה מעולה בענן, ולהבטחת תצוגה מקיפה של תחומי האבטחה כדי לקבל החלטות מושכלות לגבי השקעות באבטחה. |
| אדריכלי ומהנדסי אבטחה | שיטות אבטחה חשובות לשלבי התכנון והתפעול, כדי לוודא שהפתרונות מתוכננים לאבטחה, ליעילות וליכולת התרחבות. |
| צוותי DevSecOps | הנחיות לשילוב אמצעי בקרה מקיפים לאבטחה כדי לתכנן אוטומציה שמאפשרת תשתית מאובטחת ואמינה. |
| קציני ציות ומנהלי סיכונים | המלצות אבטחה חשובות לניהול סיכונים בגישה מובנית, עם אמצעי הגנה שעוזרים לעמוד בדרישות התאימות. |
כדי לוודא ש Google Cloud עומסי העבודה עומדים בדרישות האבטחה, הפרטיות והתאימות, כל בעלי העניין בארגון צריכים לאמץ גישה של שיתוף פעולה. בנוסף, חשוב לזכור שאבטחת הענן היא אחריות משותפת שלכם ושל Google. אחריות משותפת וגורל משותף ב- Google Cloud
ההמלצות בעמוד התווך הזה מקובצות לפי עקרונות אבטחה מרכזיים. כל המלצה שמבוססת על עקרונות ממופה לאחד או יותר מתחומי המיקוד של אבטחה בענן, שיכולים להיות קריטיים לארגון שלכם. כל המלצה מדגישה הנחיות לגבי השימוש וההגדרה של מוצרים ויכולות שלGoogle Cloud , כדי לשפר את מצב האבטחה של הארגון.
הערכת עומסי עבודה באמצעות סקיל אג'נטי
כדי לאפשר לסוכני AI להעריך את עומסי העבודה בענן בהתאם לעקרונות ולהמלצות שבעמוד התווך הזה, אתם יכולים להשתמש במיומנות google-cloud-waf-security שזמינה במאגר Google Agent Skills ב-GitHub.
כדי להתקין את המיומנות, מריצים את הפקודה הבאה בטרמינל או בלקוח של הנציג:
npx skills add google/skills --skill google-cloud-waf-security
כשמוצגת בקשה, מציינים את סוכני ה-AI שרוצים להתקין בשבילם את המיומנות ומגדירים את היקף ההתקנה (פרויקט או גלובלי).
אם כבר התקנתם את המיומנות, אתם יכולים לעדכן אותה לגרסה העדכנית ביותר על ידי הפעלת הפקודה הבאה:
npx skills update
עקרונות הליבה
ההמלצות בחלק הזה מקובצות לפי עקרונות הליבה הבאים של אבטחה. כל עיקרון בעמוד התווך הזה חשוב. בהתאם לדרישות של הארגון ושל עומס העבודה, יכול להיות שתבחרו לתת עדיפות לעקרונות מסוימים.
- הטמעת אבטחה כבר בשלב התכנון: שלבו שיקולים של אבטחת ענן ואבטחת רשת כבר בשלב התכנון הראשוני של האפליקציות והתשתית. Google Cloud מספקת תוכניות ארכיטקטורה והמלצות שיעזרו לכם ליישם את העיקרון הזה.
- הטמעת מודל אבטחה של אפס אמון: השתמשו בגישה של לא לסמוך, תמיד לאמת, שבה הגישה למשאבים ניתנת על סמך אימות מתמשך של אמון. Google Cloudתומכת בעיקרון הזה באמצעות מוצרים כמו Chrome Enterprise Premium ו-Identity-Aware Proxy (IAP).
- הטמעת אבטחה בשלב מוקדם: הטמיעו אמצעי בקרה לאבטחה בשלב מוקדם במחזור החיים של פיתוח התוכנה. למנוע פגמי אבטחה לפני שמבצעים שינויים במערכת. זיהוי ותיקון של באגים באבטחה בשלב מוקדם, במהירות ובאמינות אחרי שהשינויים במערכת בוצעו. Google Cloud תומך בעיקרון הזה באמצעות מוצרים כמו Cloud Build, Binary Authorization ו-Artifact Registry.
- הטמעת הגנת סייבר מונעת: כדאי לאמץ גישה יזומה לאבטחה על ידי הטמעת אמצעים בסיסיים חזקים כמו מודיעין איומי סייבר. הגישה הזו עוזרת לכם לבנות בסיס לזיהוי איומים ולתגובה יעילה יותר. הגישה שלGoogle Cloud לאמצעי בקרת אבטחה רב-שכבתיים תואמת לעיקרון הזה.
- שימוש ב-AI באופן מאובטח ואחראי: פיתוח ופריסה של מערכות AI באופן אחראי ומאובטח. ההמלצות לעיקרון הזה תואמות להנחיות בנקודת המבט של AI ו-ML ב-Well-Architected Framework וב-Secure AI Framework (SAIF) של Google.
- שימוש ב-AI לאבטחה: שימוש ביכולות של AI כדי לשפר את מערכות ותהליכי האבטחה הקיימים באמצעות Gemini in Security ויכולות אבטחה כוללות של הפלטפורמה. השתמשו ב-AI ככלי להגברת האוטומציה של עבודת התיקון, והקפידו על היגיינת אבטחה כדי להפוך מערכות אחרות למאובטחות יותר.
- עמידה בדרישות רגולטוריות, דרישות תאימות ודרישות פרטיות: עמידה בתקנות, בתקני תאימות ובדרישות פרטיות שספציפיים לתחום. Google Cloud עוזר לכם לעמוד בדרישות האלה באמצעות מוצרים כמו Assured Workloads, שירות מדיניות הארגון וCompliance resource center.
תפיסת האבטחה של הארגון
כדי להטמיע ולהפעיל את הענן בהצלחה, חשוב מאוד שהארגון יתמקד באבטחה. הגישה הזו צריכה להיות מושרשת עמוק בתרבות הארגונית ולהשתקף בשיטות העבודה, שמונחות על ידי עקרונות האבטחה הבסיסיים שתוארו קודם.
תפיסת אבטחה ארגונית מדגישה את החשיבה על אבטחה במהלך תכנון המערכת, הנחת אפס אמון ושילוב אמצעי אבטחה לאורך תהליך הפיתוח. בגישה הזו, אתם גם חושבים באופן יזום על אמצעי הגנת סייבר, משתמשים ב-AI באופן מאובטח ולמטרות אבטחה, ומביאים בחשבון את דרישות הרגולציה, הפרטיות והתאימות. אם תאמצו את העקרונות האלה, תוכלו לטפח בארגון תרבות שמתמקדת באבטחה, שבה מתמודדים עם איומים באופן יזום, מגינים על נכסים חשובים ומשתמשים בטכנולוגיה בצורה אחראית.
תחומי התמקדות באבטחת ענן
בקטע הזה מתוארים התחומים שבהם צריך להתמקד כשמתכננים, מטמיעים ומנהלים את האבטחה של האפליקציות, המערכות והנתונים. ההמלצות בכל עיקרון של הנדבך הזה רלוונטיות לאחד או יותר מתחומי המיקוד האלה. כדי להבהיר את ההקשר, בשאר ההמלצות במסמך הזה מצוינים תחומי האבטחה הרלוונטיים.
| נושא שכדאי להתמקד בו | פעילויות ורכיבים | Google Cloud מוצרים, יכולות ופתרונות קשורים |
|---|---|---|
| אבטחת התשתית |
|
|
| ניהול זהויות והרשאות גישה |
|
|
| אבטחת מידע |
|
|
| אבטחה של AI ו-ML |
|
|
| תפעול אבטחה (SecOps) |
|
|
| אבטחת אפליקציות |
|
|
| משילות, סיכונים ותאימות בענן |
|
|
| רישום ביומן, ביקורת ומעקב |
|
שותפים ביצירת התוכן
מחברים:
- Wade Holmes | Global Solutions Director
- הקטור דיאז | ארכיטקט אבטחה בענן
- קרלוס לאונרדו רוסאריו | מומחה אבטחה ב-Google Cloud
- ג'ון בייקון | ארכיטקט פתרונות לשותפים
- סאצ'ין קלרה | מנהל פתרונות אבטחה גלובליים
תורמים אחרים:
- אנטון צ'ובקין | יועץ אבטחה, משרד ה-CISO
- דניאל ליס | ארכיטקט אבטחה בענן
- Filipe Gracio, PhD | Customer Engineer, AI/ML Specialist
- גארי הרמסון | אדריכל ראשי
- ג'ינו פליצ'ה | אדריכל ראשי
- חוסה אנדרדה | מהנדס לקוחות, מומחה SRE
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Laura Hyatt | Customer Engineer, FSI
- Marwan Al Shawi | Partner Customer Engineer
- ניקולס פינטו | מהנדס לקוחות, מומחה למודרניזציה של אפליקציות
- נוח מקדונלד | יועץ אבטחה בענן
- אוסבלדו קוסטה | Customer Engineer שמתמחה ברשתות
- Radhika Kanakam | מובילת תוכנית, Google Cloud Well-Architected Framework
- סמנתה הי | כותבת טכנית
- סוזן וו | מנהלת מוצר יוצאת
הטמעת אבטחה משלב התכנון (security-by-design)
העיקרון הזה בעמוד התווך של האבטחה ב-Google Cloud Well-Architected Framework מספק המלצות לשילוב של אמצעי אבטחה, אמצעי בקרה ושיטות עבודה חזקים בתכנון של האפליקציות, השירותים והפלטפורמות בענן. מהעלאת רעיונות ועד לתפעול, האבטחה יעילה יותר כשהיא מוטמעת כחלק בלתי נפרד מכל שלב בתהליך התכנון.
סקירה כללית של העקרונות
כמו שמוסבר במאמר סקירה כללית על המחויבות של Google לאבטחה כבר בשלב התכנון, לעיתים קרובות משתמשים במונחים אבטחה כברירת מחדל ואבטחה כבר בשלב התכנון כאילו הם זהים, אבל הם מייצגים גישות שונות ליצירת מערכות מאובטחות. שתי הגישות נועדו לצמצם את נקודות החולשה ולשפר את האבטחה, אבל הן שונות בהיקף ובהטמעה:
- אבטחה כברירת מחדל: מתמקדת בהגדרת ברירת המחדל של המערכת למצב מאובטח, כדי לצמצם את הצורך של המשתמשים או האדמינים לבצע פעולות לאבטחת המערכת. הגישה הזו נועדה לספק רמת אבטחה בסיסית לכל המשתמשים.
- אבטחה משלב התכנון: הדגשת החשיבות של שילוב יזום של שיקולי אבטחה לאורך מחזור החיים של פיתוח המערכת. הגישה הזו מתמקדת בחיזוי מוקדם של איומים ונקודות חולשה פוטנציאליים, ובבחירת עיצובים שמפחיתים את הסיכונים. הגישה הזו כוללת שימוש בשיטות קידוד מאובטחות, ביצוע בדיקות אבטחה והטמעת אבטחה לאורך כל תהליך התכנון. הגישה של אבטחה משלב התכנון היא פילוסופיה כוללת שמנחה את תהליך הפיתוח ועוזרת להבטיח שהאבטחה היא לא מחשבה מאוחרת, אלא חלק בלתי נפרד מהתכנון של המערכת.
המלצות
כדי ליישם את העיקרון "אבטחה כחלק מהתכנון" בעומסי העבודה בענן, כדאי לפעול לפי ההמלצות שבקטעים הבאים:
- בחירת רכיבי מערכת שעוזרים לאבטח את עומסי העבודה
- גישת אבטחה רב-שכבתית
- שימוש בתשתית ובשירותים מאובטחים ומאומתים
- הצפנת נתונים במנוחה ובמעבר
בחירת רכיבי מערכת שעוזרים לאבטח את עומסי העבודה
ההמלצה הזו רלוונטית לכל תחומי המיקוד.
אחת ההחלטות החשובות ביותר לאבטחה יעילה היא בחירת רכיבי מערכת חזקים – כולל רכיבי חומרה ותוכנה – שמהווים את הפלטפורמה, הפתרון או השירות שלכם. כדי לצמצם את שטח המתקפה ולהגביל את הנזק הפוטנציאלי, חשוב גם לשקול היטב את דפוסי הפריסה של הרכיבים האלה ואת ההגדרות שלהם.
בקוד האפליקציה, מומלץ להשתמש בספריות, בהפשטות ובמסגרות אפליקציה פשוטות, בטוחות ואמינות כדי למנוע סוגים שונים של נקודות חולשה. כדי לסרוק נקודות חולשה בספריות תוכנה, אתם יכולים להשתמש בכלים של צד שלישי. אתם יכולים גם להשתמש ב-Assured Open Source Software, כדי להפחית את הסיכונים לשרשרת אספקת התוכנה באמצעות חבילות של תוכנות קוד פתוח (OSS) ש-Google משתמשת בהן ומאבטחת אותן.
התשתית שלכם צריכה להשתמש באפשרויות של רשת, אחסון ומחשוב שתומכות בפעולה בטוחה, ותואמות לדרישות האבטחה ולרמות קבלת הסיכונים שלכם. אבטחת התשתית חשובה גם לעומסי עבודה שפונים לאינטרנט וגם לעומסי עבודה פנימיים.
במאמר הטמעת אבטחה מסוג Shift-Left תוכלו לקרוא על פתרונות אחרים של Google שתומכים בהמלצה הזו.
גישת אבטחה רב-שכבתית
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחה של AI ו-ML
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
מומלץ להטמיע אבטחה בכל שכבה של האפליקציה ושל מחסנית התשתית, באמצעות גישת הגנה לעומק.
השתמשו באמצעי האבטחה בכל רכיב בפלטפורמה שלכם. כדי להגביל את הגישה ולזהות את גבולות ההשפעה הפוטנציאלית (כלומר, רדיוס הפיצוץ) במקרה של אירוע אבטחה:
- כדאי לפשט את עיצוב המערכת כדי לאפשר גמישות במידת האפשר.
- מתעדים את דרישות האבטחה של כל רכיב.
- לשלב מנגנון אבטחה חזק כדי לעמוד בדרישות של עמידות ושחזור.
כשאתם מתכננים את שכבות האבטחה, בצעו הערכת סיכונים כדי לקבוע אילו אמצעי אבטחה אתם צריכים כדי לעמוד בדרישות האבטחה הפנימיות ובדרישות הרגולטוריות החיצוניות. מומלץ להשתמש במסגרת להערכת סיכונים שמקובלת בתחום, שחלה על סביבות ענן ורלוונטית לדרישות הרגולטוריות שלכם. לדוגמה, Cloud Security Alliance (CSA) מספקת את Cloud Controls Matrix (CCM). הערכת הסיכונים מספקת לכם קטלוג של סיכונים ואמצעי אבטחה תואמים לצמצום הסיכונים.
כשאתם מבצעים את הערכת הסיכונים, זכרו שיש לכם הסדר אחריות משותפת עם ספק שירותי הענן. לכן, הסיכונים בסביבת ענן שונים מהסיכונים בסביבה מקומית. לדוגמה, בסביבה מקומית, צריך לצמצם את נקודות החולשה במחסנית החומרה. לעומת זאת, בסביבת ענן, ספק שירותי הענן נושא בסיכונים האלה. חשוב גם לזכור שהגבולות של האחריות המשותפת משתנים בין שירותי IaaS, PaaS ו-SaaS לכל ספק שירותי ענן.
אחרי שמזהים סיכונים פוטנציאליים, צריך לתכנן וליצור תוכנית לצמצום סיכונים שכוללת אמצעי בקרה טכניים, ניהוליים ותפעוליים, וגם הגנות חוזיות ואישורים של צד שלישי. בנוסף, שיטה למידול איומים, כמו השיטה של OWASP למידול איומים באפליקציות, עוזרת לזהות פערים פוטנציאליים ומציעה פעולות לטיפול בהם.
שימוש בתשתית ובשירותים מוקשחים ומאומתים
ההמלצה הזו רלוונטית לכל תחומי המיקוד.
תוכנית אבטחה מקיפה מצמצמת את נקודות החולשה החדשות, כפי שמתואר בעדכוני האבטחה הדחופים. תוכנית האבטחה צריכה גם לספק פתרונות לתיקון נקודות חולשה בפריסות קיימות, ולאבטח את קובצי האימג' של המכונות הווירטואליות והקונטיינרים. אתם יכולים להשתמש במדריכי הקשחה שספציפיים למערכת ההפעלה ולאפליקציה של קובצי האימג', וגם באמות מידה כמו אלה שסופקו על ידי Center of Internet Security (CIS).
אם אתם משתמשים בתמונות בהתאמה אישית למכונות הווירטואליות של Compute Engine, אתם צריכים לתקן את התמונות בעצמכם. לחלופין, אתם יכולים להשתמש בקובצי אימג' של מערכת ההפעלה ש-Google מספקת, שמתעדכנים באופן קבוע. כדי להריץ קונטיינרים במכונות וירטואליות של Compute Engine, משתמשים בקובצי אימג' של מערכת הפעלה שמותאמת לקונטיינרים, שנאספו על ידי Google. Google מתקנת ומעדכנת את קובצי האימג' האלה באופן קבוע.
אם אתם משתמשים ב-GKE, מומלץ להפעיל שדרוגים אוטומטיים של צמתים כדי ש-Google תעדכן את צומתי האשכולות שלכם עם התיקונים האחרונים. Google מנהלת את מישורי הבקרה של GKE, שמתעדכנים ומתוקנים באופן אוטומטי. כדי לצמצם עוד יותר את שטח ההתקפה של הקונטיינרים, אפשר להשתמש בתמונות ללא הפצה. תמונות Distroless הן אידיאליות לאפליקציות שרגישות לאבטחה, למיקרו-שירותים ולמצבים שבהם חשוב מאוד לצמצם את גודל התמונה ואת שטח המתקפה.
לעומסי עבודה רגישים, השתמשו במכונה וירטואלית מוגנת, שמונעת טעינה של קוד זדוני במהלך מחזור ההפעלה של המכונה הווירטואלית. מכונות וירטואליות מוגנות מספקות אבטחת אתחול, עוקבות אחרי התקינות ומשתמשות ב-Virtual Trusted Platform Module (vTPM).
כדי לאבטח את הגישה ל-SSH, העובדים יכולים להשתמש ב-OS Login כדי להתחבר למכונות הווירטואליות באמצעות הרשאות ניהול זהויות והרשאות גישה (IAM) כמקור המהימנות, במקום להסתמך על מפתחות SSH. לכן אין צורך לנהל מפתחות SSH בכל הארגון. הכלי OS Login מקשר את הגישה של האדמין למחזור החיים של העובד, כך שכאשר עובדים מחליפים תפקיד או עוזבים את הארגון, הגישה שלהם מבוטלת יחד עם החשבון שלהם. בנוסף, OS Login תומך באימות דו-שלבי של Google, שמוסיף שכבת אבטחה נוספת נגד מתקפות של השתלטות על החשבון.
ב-GKE, מכונות של אפליקציות פועלות בקונטיינרים של Docker. כדי להפעיל פרופיל סיכון מוגדר ולהגביל את העובדים מביצוע שינויים בקונטיינרים, ודאו שהקונטיינרים הם ללא שמירת מצב (stateless) ואינם ניתנים לשינוי (immutable). עיקרון חוסר השינוי אומר שהעובדים שלכם לא משנים את הקונטיינר ולא ניגשים אליו באופן אינטראקטיבי. אם צריך לשנות את הקונטיינר, יוצרים קובץ אימג' חדש ופורסים אותו מחדש. הפעילו גישת SSH לקונטיינרים הבסיסיים רק בתרחישים ספציפיים של ניפוי באגים.
כדי לאבטח את ההגדרות בכל הסביבה, אתם יכולים להשתמש במדיניות הארגון כדי להגדיר אילוצים או אמצעי הגנה על משאבים שמשפיעים על ההתנהגות של הנכסים בענן. לדוגמה, אתם יכולים להגדיר את כללי מדיניות הארגון הבאים ולהחיל אותם באופן גלובלי על כל הארגון ב- Google Cloud , או באופן סלקטיבי ברמת התיקייה או הפרויקט:
- השבתת ההקצאה של כתובות IP חיצוניות למכונות וירטואליות.
- להגביל את יצירת המשאבים למיקומים גיאוגרפיים ספציפיים.
- להשבית את היצירה של חשבונות שירות או המפתחות שלהם.
הצפנת נתונים במנוחה ובמעבר
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת התשתית
- אבטחת מידע
הצפנת נתונים היא אמצעי בקרה בסיסי להגנה על מידע רגיש, והיא חלק מרכזי במשילות מידע (data governance). אסטרטגיה יעילה להגנה על נתונים כוללת בקרת גישה, פילוח נתונים ומיקום גיאוגרפי, ביקורת והטמעת הצפנה שמבוססת על הערכה קפדנית של הדרישות.
כברירת מחדל, Google Cloud מצפין את נתוני הלקוחות שמאוחסנים במצב מנוחה, בלי שאתם צריכים לעשות שום דבר. בנוסף להצפנה שמוגדרת כברירת מחדל, ב-Google Cloud יש אפשרויות להצפנת מעטפה ולניהול מפתחות הצפנה. אתם צריכים לזהות את הפתרונות שהכי מתאימים לדרישות שלכם ליצירת מפתחות, לאחסון ולרוטציה, בין אם אתם בוחרים את המפתחות לאחסון, למחשוב או לעומסי עבודה של Big Data. לדוגמה, אפשר ליצור מפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud Key Management Service (Cloud KMS). מפתחות ה-CMEK יכולים להיות מבוססי-תוכנה או מוגנים באמצעות HSM, כדי לעמוד בדרישות הרגולטוריות או בדרישות התאימות, כמו הצורך להחליף את מפתחות ההצפנה באופן קבוע. באמצעות Cloud KMS Autokey אתם יכולים להקצות ולהגדיר מפתחות CMEK באופן אוטומטי. בנוסף, אתם יכולים להביא מפתחות משלכם ממערכת ניהול מפתחות של צד שלישי, באמצעות Cloud External Key Manager (Cloud EKM).
מומלץ מאוד להצפין את הנתונים בזמן ההעברה. Google מצפינה ומאמתת נתונים במעבר בשכבת רשת אחת או יותר, כשהנתונים מועברים אל מחוץ לגבולות הפיזיים שאינם בשליטתה של Google או מטעמה של Google. כל תעבורת הנתונים מ-VM ל-VM בתוך רשת VPC ובין רשתות VPC שמקושרות לרשתות שכנות, עוברת הצפנה. אתם יכולים להשתמש ב-MACsec כדי להצפין את התנועה בחיבורי Cloud Interconnect. IPsec מספק הצפנה לתנועה בחיבורי Cloud VPN. כדי להגן על התנועה בין אפליקציות בענן, אתם יכולים להשתמש באמצעי אבטחה כמו הגדרות TLS ו-mTLS ב-Apigee ו-Cloud Service Mesh לאפליקציות בקונטיינרים.
כברירת מחדל, Google Cloud מצפינה נתונים במנוחה ונתונים במעבר ברשת. עם זאת, הנתונים לא מוצפנים כברירת מחדל כשהם בשימוש בזיכרון. אם הארגון שלכם מטפל במידע סודי, אתם צריכים לצמצם את האיומים שפוגעים בסודיות ובתקינות של האפליקציה או של הנתונים בזיכרון המערכת. כדי לצמצם את האיומים האלה, אתם יכולים להשתמש ב-Confidential Computing, שמספק סביבת מחשוב אמינה לעומסי העבודה שלכם. למידע נוסף, קראו את הסקירה הכללית על Confidential VM.
הטמעת מודל אבטחה של אפס אמון
העיקרון הזה, שמופיע בעמוד התווך של האבטחה ב-Google Cloud Well-Architected Framework, עוזר לכם לוודא שהאבטחה בעומסי העבודה בענן היא מקיפה. העיקרון של מודל אבטחה של אפס אמון מדגיש את השיטות הבאות:
- ביטול האמון המשתמע
- יישום העיקרון של הרשאות מינימליות לבקרת גישה
- אכיפת אימות מפורש של כל בקשות הגישה
- אימוץ גישה של הנחת פריצה כדי לאפשר אימות רציף ומעקב אחרי מצב האבטחה
סקירה כללית של העקרונות
במודל אפס אמון, המיקוד של האבטחה עובר מאבטחה היקפית לגישה שבה אף משתמש או מכשיר לא נחשבים מהימנים באופן מובנה. במקום זאת, צריך לאמת כל בקשת גישה, בלי קשר למקור שלה. בגישה הזו, כל משתמש ומכשיר עוברים אימות ואישור, ההקשר שלהם (מיקום ומצב המכשיר) מאומת, וניתנת להם גישה עם הרשאות מינימליות רק למשאבים הנדרשים.
הטמעת מודל אבטחה של אפס אמון עוזרת לארגון לשפר את מצב האבטחה שלו, על ידי צמצום ההשפעה של פרצות פוטנציאליות והגנה על נתונים ואפליקציות רגישים מפני גישה לא מורשית. מודל האבטחה "אפס אמון" עוזר להבטיח את הסודיות, התקינות והזמינות של הנתונים והמשאבים בענן.
המלצות
כדי להטמיע את מודל האבטחה "אפס אמון" בעומסי העבודה בענן, כדאי לפעול לפי ההמלצות שבקטעים הבאים:
אבטחת הרשת
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת התשתית.
המעבר מאבטחה היקפית רגילה למודל של אפס אמון דורש כמה שלבים. יכול להיות שהארגון שלכם כבר שילב אמצעי בקרה מסוימים של אבטחה ללא אמון במצב האבטחה שלו. עם זאת, מודל אבטחה של אפס אמון הוא לא מוצר או פתרון יחיד. במקום זאת, מדובר בשילוב הוליסטי של כמה שכבות אבטחה ושיטות מומלצות. בקטע הזה מפורטות המלצות ושיטות להטמעת מודל אפס אמון עבור אבטחת רשת.
- בקרת גישה: אכיפה של בקרות גישה על סמך זהות המשתמש וההקשר, באמצעות פתרונות כמו Chrome Enterprise Premium ושרת proxy לאימות זהויות (IAP). כך אתם מעבירים את האבטחה מהיקף הרשת למשתמשים ולמכשירים ספציפיים. הגישה הזו מאפשרת בקרת גישה פרטנית ומצמצמת את שטח המתקפה.
- אבטחת רשת: חיבורי רשת מאובטחים בין הסביבה המקומית, Google Cloudוסביבות מרובות-עננים.
- להשתמש בשיטות החיבור המבודד של Cloud Interconnect ושל IPsec VPN.
- כדי לאבטח את הגישה לשירותים ולממשקי ה-API של Google Cloud , אתם יכולים להשתמש ב-Private Service Connect.
- כדי לאבטח את הגישה החוצה מעומסי עבודה שנפרסו ב-Google Kubernetes Engine (GKE) ובמוצרים קשורים, אתם יכולים להשתמש בשערי יציאה של Cloud Service Mesh.
- תכנון הרשת: כדי למנוע סיכוני אבטחה פוטנציאליים, מוחקים את רשתות ברירת המחדל בפרויקטים קיימים ומשביתים את היצירה של רשתות ברירת מחדל בפרויקטים חדשים.
- כדי להימנע מהתנגשויות, תכננו בקפידה את הרשת ואת הקצאת כתובות ה-IP.
- כדי לאכוף בקרת גישה יעילה, הגבילו את מספר הרשתות של הענן הווירטואלי הפרטי (VPC) בכל פרויקט.
- סגמנטציה: בידוד עומסי העבודה תוך שמירה על ניהול רשת ריכוזי.
- כדי לפלח את סביבות הרשת, אתם יכולים להשתמש בכמה רשתות VPC ולהגדיר מדיניות חומת אש וכללים ברמת הארגון, התיקייה ורשת ה-VPC.
- כדי לרכז את ניהול הרשת של משאבים שנמצאים בפרויקטים נפרדים, משתמשים ב-VPC משותף. לדוגמה, אדמינים של פרויקט שירות יכולים ליצור מכונות של Compute Engine שמשתמשות בתת-רשתות שאושרו מהפרויקט שמארח רשת VPC משותפת שמנוהלת באופן מרכזי.
- כדי למנוע זליגת נתונים, הגדירו מתחמי אבטחה היקפית מסביב לממשקי API ולשירותים רגישים של Google Cloud באמצעות VPC Service Controls, והשתמשו בכללי חומת אש מחמירים לתעבורת נתונים יוצאת כדי להגביל את תעבורת הנתונים לאינטרנט.
- אבטחה היקפית: הגנה מפני התקפות DDoS ואיומים על אפליקציות אינטרנט.
- כדי להגן מפני איומים, השתמשו ב-Google Cloud Armor.
- הגדרת מדיניות אבטחה כדי לאשר, לדחות או להפנות מחדש תנועה בקצה שלGoogle Cloud .
- אוטומציה: כדי להפוך את הקצאת התשתית לאוטומטית, כדאי לאמץ את העקרונות של תשתית כקוד (IaC) ולהשתמש בכלים כמו Terraform, Jenkins ו-Cloud Build. בעזרת IaC אפשר לוודא שהגדרות האבטחה עקביות, לפשט את הפריסות ולבצע החזרות מהירות למצב קודם במקרה של בעיות.
- תשתית מאובטחת: יצירת סביבת אפליקציה מאובטחת באמצעות Enterprise foundations blueprint. התוכנית הזו כוללת הנחיות מפורטות וסקריפטים אוטומטיים שיעזרו לכם ליישם שיטות מומלצות לאבטחה ולהגדיר את המשאבים ב-Google Cloud בצורה מאובטחת.
אימות מפורש של כל ניסיון גישה
ההמלצה הזו רלוונטית לתחומים הבאים:
- ניהול זהויות והרשאות גישה
- תפעול אבטחה (SecOps)
- רישום ביומן, ביקורת ומעקב
הטמיעו מנגנוני אימות והרשאה חזקים לכל משתמש, מכשיר או שירות שמנסים לגשת למשאבים שלכם בענן. אל תסתמכו על המיקום או על גבולות הרשת כאמצעי בקרה לאבטחה. לא לתת אמון אוטומטי באף משתמש, מכשיר או שירות, גם אם הם כבר נמצאים בתוך הרשת. במקום זאת, כל ניסיון לגשת למשאבים חייב לעבור אימות והרשאה קפדניים. אתם צריכים להטמיע אמצעים חזקים לאימות זהות, כמו אימות רב-שלבי (MFA). אתם צריכים גם לוודא שההחלטות לגבי מתן הרשאת גישה מבוססות על כללי מדיניות מפורטים, שמתחשבים בגורמים שונים שקשורים להקשר, כמו תפקיד המשתמש, מצב המכשיר והמיקום.
כדי ליישם את ההמלצה הזו, אפשר להשתמש בשיטות, בכלים ובטכנולוגיות הבאים:
- ניהול זהויות מאוחד: שימוש בספק זהויות (IdP) אחד כדי להבטיח ניהול זהויות עקבי בכל הארגון.
- Google Cloud תומך באיחוד עם רוב ספקי הזהויות, כולל Active Directory מקומי. איחוד מאפשר לכם להרחיב את התשתית הקיימת לניהול זהויות ל- Google Cloud , ולהפעיל כניסה יחידה (SSO) למשתמשים.
- אם אין לכם IdP קיים, כדאי להשתמש ב-Cloud Identity Premium או ב-Google Workspace.
- הרשאות מוגבלות לחשבונות שירות: השתמשו בחשבונות שירות בזהירות, ופעלו לפי העיקרון של הרשאות מינימליות.
- תנו רק את ההרשאות שנדרשות לכל חשבון שירות כדי לבצע את המשימות שהוקצו לו.
- כדי לגשת למשאבים באופן מאובטח, השתמשו באיחוד שירותי אימות הזהות של עומסי עבודה באפליקציות שפועלות ב-Google Kubernetes Engine (GKE) או מחוץ ל-Google Cloud .
- תהליכים חזקים: עדכון תהליכי הזהות בהתאם לשיטות המומלצות לאבטחה בענן.
- כדי לעמוד בדרישות הרגולטוריות, כדאי להטמיע ניהול זהויות כדי לעקוב אחרי הגישה, הסיכונים והפרות המדיניות.
- לבדוק ולעדכן את התהליכים הקיימים להקצאה ולביקורת של תפקידים והרשאות לבקרת גישה.
- אימות חזק: הטמיעו SSO לאימות משתמשים והטמיעו MFA לחשבונות עם הרשאות.
- Google Cloud תומך בשיטות שונות לאימות רב-שלבי, כולל מפתחות אבטחה Titan, כדי לשפר את האבטחה.
- כדי לאמת עומסי עבודה, השתמשו ב-OAuth 2.0 או באסימוני JWT (JSON Web Tokens) חתומים.
- הרשאות מינימליות: כדי לצמצם את הסיכון לגישה לא מורשית ולפרצות באבטחת מידע, חשוב לאכוף את העקרונות של הרשאות מינימליות והפרדת תפקידים.
- אל תתנו למשתמשים יותר מדי הרשאות גישה.
- כדאי להטמיע גישה מיוחדת בדיוק בזמן (JIT) לפעולות רגישות.
- רישום ביומן: הפעלת רישום ביומן הביקורת של פעילויות אדמין וגישה לנתונים.
- כדי לנתח ולזהות איומים, סורקים את היומנים באמצעות Security Command Center Enterprise או Google Security Operations.
- הגדירו כללי מדיניות מתאימים לשמירת יומנים כדי לאזן בין צורכי האבטחה לבין עלויות האחסון.
מעקב אחרי הרשת ותחזוקה שלה
ההמלצה הזו רלוונטית לתחומים הבאים:
- רישום ביומן, ביקורת ומעקב
- אבטחת אפליקציות
- תפעול אבטחה (SecOps)
- אבטחת התשתית
כשאתם מתכננים ומיישמים אמצעי אבטחה, תניחו שהתוקף כבר נמצא בתוך הסביבה שלכם. הגישה היזומה הזו כוללת שימוש בכלים ובשיטות הבאים כדי לספק תובנות לגבי הרשת:
רישום מרכזי ביומן ומעקב: איסוף וניתוח של יומני אבטחה מכל משאבי הענן באמצעות רישום מרכזי ביומן ומעקב.
- להגדיר ערכי בסיס להתנהגות רגילה ברשת, לזהות אנומליות ולזהות איומים פוטנציאליים.
- לנתח באופן קבוע את זרימת התנועה ברשת כדי לזהות דפוסים חשודים והתקפות פוטנציאליות.
תובנות לגבי הביצועים והאבטחה של הרשת: שימוש בכלים כמו Network Analyzer. עוקבים אחרי התנועה כדי לזהות פרוטוקולים חריגים, חיבורים לא צפויים או עליות חדות פתאומיות בהעברת הנתונים, שיכולים להצביע על פעילות זדונית.
בדיקת נקודות חולשה ותיקון: סורקים באופן קבוע את הרשת והאפליקציות כדי לאתר נקודות חולשה.
- להשתמש ב-Web Security Scanner, שיכול לזהות באופן אוטומטי נקודות חולשה במכונות הווירטואליות של Compute Engine, בקונטיינרים ובאשכולות GKE.
- תעדפו את התיקון לפי חומרת נקודות החולשה וההשפעה הפוטנציאלית שלהן על המערכות שלכם.
זיהוי פריצות: מעקב אחרי התנועה ברשת כדי לזהות פעילות זדונית, וחסימה אוטומטית של אירועים חשודים או קבלת התראות לגביהם באמצעות Cloud IDS ושירות מניעת הפריצות של Cloud NGFW.
ניתוח אבטחה: כדאי להטמיע את Google SecOps כדי ליצור קורלציה בין אירועי אבטחה ממקורות שונים, לספק ניתוח בזמן אמת של התראות אבטחה ולסייע בתגובה לאירועים.
הגדרות עקביות: כדי לוודא שהגדרות האבטחה עקביות בכל הרשת, כדאי להשתמש בכלים לניהול הגדרות.
הטמעת אבטחה מוקדמת (shift-left)
העיקרון הזה, שמופיע בעמוד התווך של האבטחה ב-Google Cloud Well-Architected Framework, עוזר לכם לזהות אמצעי בקרה מעשיים שאפשר להטמיע בשלב מוקדם במחזור החיים של פיתוח התוכנה כדי לשפר את מצב האבטחה. הוא מספק המלצות שעוזרות לכם להטמיע אמצעי הגנה למניעת איומי אבטחה ואמצעי בקרה לאבטחה אחרי הפריסה.
סקירה כללית של העקרונות
אבטחה מסוג Shift-left היא אימוץ של שיטות אבטחה בשלב מוקדם במחזור החיים של פיתוח התוכנה. העיקרון הזה כולל את היעדים הבאים:
- למנוע פגמי אבטחה לפני שמבצעים שינויים במערכת. הטמיעו אמצעי הגנה מונעים ואמצו שיטות כמו תשתית כקוד (IaC), מדיניות כקוד ובדיקות אבטחה בצינור עיבוד הנתונים של CI/CD. אתם יכולים גם להשתמש ביכולות אחרות שספציפיות לפלטפורמה, כמו שירות מדיניות הארגון ואשכולות GKE מוקשחים ב- Google Cloud.
- לזהות ולתקן באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן אחרי שבוצעו שינויים במערכת. כדאי לאמץ שיטות כמו סקרי קוד, בדיקת נקודות חולשה אחרי הפריסה ובדיקות אבטחה.
העיקרון הטמעת אבטחה משלב התכנון והעיקרון "אבטחה משמאל" קשורים זה לזה, אבל הם שונים בהיקף שלהם. העיקרון של אבטחה מובנית עוזר לכם להימנע מפגמים בסיסיים בתכנון, שעלולים לחייב אתכם לתכנן מחדש את כל המערכת. לדוגמה, תרגיל של מידול איומים מגלה שהעיצוב הנוכחי לא כולל מדיניות הרשאות, ובלעדיה לכל המשתמשים תהיה אותה רמת גישה. אבטחה מסוג "הקדמת בדיקות" עוזרת למנוע פגמים בהטמעה (באגים והגדרות שגויות) לפני שמחילים את השינויים, ומאפשרת תיקונים מהירים ואמינים אחרי הפריסה.
המלצות
כדי ליישם את עקרון האבטחה "להקדים בדיקות" בעומסי העבודה בענן, כדאי לפעול לפי ההמלצות שבקטעים הבאים:
- הטמעת אמצעי בקרה למניעת פרצות אבטחה
- הקצאה וניהול אוטומטיים של משאבי ענן
- אוטומציה של גרסאות אפליקציה מאובטחות
- לוודא שפריסות של אפליקציות מתבצעות לפי תהליכים מאושרים
- סריקה לאיתור נקודות חולשה ידועות לפני פריסת האפליקציה
- מעקב אחרי קוד האפליקציה כדי לזהות נקודות חולשה ידועות
שימוש באמצעי בקרה למניעת פרצות אבטחה
ההמלצה הזו רלוונטית לתחומים הבאים:
- ניהול זהויות והרשאות גישה
- משילות, סיכונים ותאימות בענן
אמצעי בקרה למניעת פרצות אבטחה הם חיוניים לשמירה על מצב אבטחה חזק בענן. אמצעי הבקרה האלה עוזרים לכם לצמצם סיכונים באופן יזום. כך תוכלו למנוע הגדרות שגויות וגישה לא מורשית למשאבים, לאפשר למפתחים לעבוד ביעילות ולעמוד בתקנים בתחום ובמדיניות הפנימית.
אמצעי בקרה מונעים יעילים יותר כשמטמיעים אותם באמצעות תשתית כקוד (IaC). ב-IaC, אמצעי בקרה למניעת פרצות אבטחה יכולים לכלול בדיקות מותאמות אישית יותר של קוד התשתית לפני פריסת השינויים. בשילוב עם אוטומציה, אמצעי בקרה למניעה יכולים לפעול כחלק מהבדיקות האוטומטיות של צינור עיבוד הנתונים של CI/CD.
המוצרים והיכולות הבאים של Google Cloud יכולים לעזור לכם להטמיע אמצעי בקרה מונעים בסביבה שלכם:
- אילוצים של שירות מדיניות הארגון: הגדרת אילוצים מוגדרים מראש ואילוצים בהתאמה אישית עם שליטה מרוכזת.
- VPC Service Controls: יצירת גבולות גזרה מסביב לשירותי Google Cloud .
- ניהול זהויות והרשאות גישה (IAM), Privileged Access Manager ומדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB): הגבלת הגישה למשאבים.
- Policy Controller ו-Open Policy Agent (OPA): אכיפת אילוצי IaC בצינור עיבוד הנתונים של CI/CD ומניעת הגדרות שגויות בענן.
בעזרת IAM אתם יכולים להגדיר מי יכול לבצע פעולות במשאבים מסוימים, בהתאם להרשאות. מידע נוסף זמין במאמר בקרת גישה למשאבים של הארגון באמצעות IAM.
שירות מדיניות הארגון מאפשר להגדיר הגבלות על משאבים כדי לקבוע איך אפשר להגדיר אותם. לדוגמה, אתם יכולים להשתמש במדיניות הארגון כדי:
- הגבלת שיתוף המשאבים על סמך הדומיין.
- הגבלת השימוש בחשבונות שירות.
- להגביל את המיקום הפיזי של משאבים חדשים שנוצרו.
בנוסף לשימוש במדיניות הארגון, אתם יכולים להגביל את הגישה למשאבים בדרכים הבאות:
- תגים עם IAM: מקצים תג לקבוצת משאבים ואז מגדירים את הגישה לתג עצמו, במקום להגדיר את הרשאות הגישה לכל משאב.
- תנאי IAM: הגדרת בקרת גישה מותנית למשאבים, על סמך מאפיינים.
- הגנה לעומק: שימוש ב-VPC Service Controls כדי להגביל עוד יותר את הגישה למשאבים.
מידע נוסף על ניהול משאבים מופיע במאמר בחירה של היררכיית משאבים לאזור הנחיתה ב- Google Cloud .
הקצאה וניהול אוטומטיים של משאבים בענן
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת אפליקציות
- משילות, סיכונים ותאימות בענן
כדי להפוך את ההקצאה והניהול של משאבים ועומסי עבודה בענן לאוטומטיים, יעיל יותר להשתמש ב-IaC דקלרטיבי, ולא בסקריפטים אימפרטיביים. IaC הוא לא כלי או שיטה לאבטחה בפני עצמו, אבל הוא עוזר לשפר את האבטחה של הפלטפורמה. השימוש ב-IaC מאפשר ליצור תשתית שניתן לחזור עליה, ומספק לצוות התפעול מצב תקין וידוע. בנוסף, IaC משפר את היעילות של החזרות למצב קודם, שינויים בביקורת ופתרון בעיות.
כשמשלבים את IaC עם צינורות עיבוד נתונים של CI/CD ואוטומציה, אפשר גם לאמץ שיטות כמו מדיניות כקוד באמצעות כלים כמו OPA. אתם יכולים לבדוק את השינויים בתשתית לאורך זמן ולהריץ בדיקות אוטומטיות על קוד התשתית לפני פריסת השינויים.
כדי להפוך את פריסת התשתית לאוטומטית, אתם יכולים להשתמש בכלים כמו Config Controller, Terraform, Jenkins ו-Cloud Build. כדי לעזור לכם ליצור סביבת אפליקציות מאובטחת באמצעות IaC ואוטומציה,Google Cloud מספק את תוכנית היסודות לארגונים. התוכנית הזו היא העיצוב המומלץ של Google, והיא כוללת את כל השיטות המומלצות וההגדרות שלנו. התוכנית כוללת הוראות מפורטות להגדרה ולפריסה של הטופולוגיה של Google Cloud באמצעות Terraform ו-Cloud Build.
אתם יכולים לשנות את הסקריפטים של תוכנית האב ליסודות הארגון כדי להגדיר סביבה שתואמת להמלצות של Google ועומדת בדרישות האבטחה שלכם. אתם יכולים להוסיף לתבנית תבניות נוספות או ליצור אוטומציה משלכם. ב-Google Cloud מרכז הארכיטקטורה יש תוכניות אחרות שאפשר להטמיע בנוסף לתוכנית היסודות לארגונים. הנה כמה דוגמאות לתבניות האלה:
- פריסת פלטפורמת פיתוח לארגונים ב- Google Cloud
- פריסת ארכיטקטורה מאובטחת בלי שרת (serverless) באמצעות Cloud Run
- פיתוח ופריסה של מודלים של למידת מכונה ו-AI גנרטיבי בארגון
- ייבוא נתונים מ- Google Cloud למחסן נתונים (data warehouse) מאובטח של BigQuery
אוטומציה של גרסאות מאובטחות של אפליקציות
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
בלי כלים אוטומטיים, יכול להיות קשה לפרוס, לעדכן ולתקן סביבות מורכבות של אפליקציות כדי לעמוד בדרישות אבטחה עקביות. מומלץ לבנות צינורות עיבוד נתונים אוטומטיים של CI/CD למחזור החיים של פיתוח התוכנה (SDLC). תהליכי CI/CD אוטומטיים עוזרים לכם להימנע משגיאות ידניות, מספקים לולאות משוב סטנדרטיות לפיתוח ומאפשרים איטרציות יעילות של מוצרים. פיתוח רציף הוא אחת מהשיטות המומלצות של DORA framework.
אוטומציה של גרסאות האפליקציה באמצעות צינורות עיבוד נתונים של CI/CD עוזרת לשפר את היכולת לזהות ולתקן באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן. לדוגמה, אתם יכולים לסרוק באופן אוטומטי כדי לאתר נקודות חולשה באבטחה כשנוצרים פריטי מידע שנוצרו בתהליך הפיתוח (Artifact), לצמצם את היקף בדיקות האבטחה ולחזור לגרסה מוכרת ובטוחה. אתם יכולים גם להגדיר כללי מדיניות לסביבות שונות (כמו סביבות פיתוח, בדיקה או ייצור) כדי לפרוס רק פריטי מידע מאומתים.
כדי לעזור לכם להפוך את ההשקות של האפליקציות לאוטומטיות ולהטמיע בדיקות אבטחה בצינור עיבוד הנתונים של CI/CD,ב- Google Cloud יש כמה כלים, כולל Cloud Build, Cloud Deploy, Web Security Scanner ו-Binary Authorization.
כדי ליצור תהליך שמאמת כמה דרישות אבטחה ב-SDLC, השתמשו במסגרת Supply-chain Levels for Software Artifacts (SLSA) שהוגדרה על ידי Google. במסגרת SLSA, נדרשות בדיקות אבטחה של קוד המקור, תהליך ה-build ומקור הקוד. אפשר לכלול הרבה מהדרישות האלה בצינור עיבוד נתונים אוטומטי של CI/CD. כדי להבין איך Google מיישמת את השיטות האלה באופן פנימי, קראו את המאמר הגישה שלGoogle Cloudלשינוי.
לוודא שפריסות של אפליקציות מתבצעות לפי תהליכים שאושרו
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
אם תוקף יפרוץ לצינור עיבוד הנתונים של CI/CD, כל מחסנית האפליקציות שלכם עלולה להיפגע. כדי לאבטח את צינור עיבוד הנתונים, צריך לאכוף תהליך אישור מוגדר לפני פריסת הקוד בסביבת הייצור.
אם אתם משתמשים ב-Google Kubernetes Engine (GKE) או ב-Cloud Run, אתם יכולים להגדיר תהליך אישור באמצעות Binary Authorization. Binary Authorization מצרף חתימות שניתנות להגדרה לקובצי אימג' של קונטיינרים. החתימות האלה (שנקראות גם אישורים) עוזרות לאמת את התמונה. בזמן הפריסה, Binary Authorization משתמשת באישורים האלה כדי לקבוע אם התהליך הושלם. לדוגמה, אתם יכולים להשתמש ב-Binary Authorization כדי:
- לוודא שמערכת build ספציפית או צינור עיבוד נתונים של CI יצרו קובץ אימג' של קונטיינר.
- אימות שקובץ אימג' של קונטיינר תואם למדיניות חתימה על נקודות חולשה.
- לוודא שקובץ אימג' של קונטיינר עומד בקריטריונים לקידום לסביבת הפריסה הבאה, למשל מפיתוח ל-QA.
באמצעות Binary Authorization, אתם יכולים לאכוף שרק קוד מהימן יפעל בפלטפורמות היעד שלכם.
סריקה לאיתור נקודות חולשה ידועות לפני פריסת האפליקציה
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
מומלץ להשתמש בכלים אוטומטיים שיכולים לבצע בדיקת נקודות חולשה רציפה בארטיפקטים של האפליקציה לפני הפריסה שלהם בסביבת הייצור.
באפליקציות בקונטיינרים, אפשר להשתמש ב-Artifact Analysis כדי להריץ באופן אוטומטי סריקות לאיתור נקודות חולשה בקובצי אימג' של קונטיינרים. Artifact Analysis סורק תמונות חדשות כשהן מועלות ל-Artifact Registry. הסריקה מחלצת מידע על חבילות המערכת במאגר. אחרי הסריקה הראשונית, Artifact Analysis עוקב באופן רציף אחרי המטא-נתונים של קובצי האימג' שנסרקו ב-Artifact Registry כדי לאתר נקודות חולשה חדשות. כש-Artifact Analysis מקבל מידע חדש ומעודכן על נקודות חולשה ממקורות של נקודות חולשה, הוא מבצע את הפעולות הבאות:
- מעדכן את המטא-נתונים של קובצי האימג' שנסרקו כדי לשמור על עדכניות הנתונים.
- יצירת מופעים חדשים של נקודות חולשה להערות חדשות.
- מוחק מופעים של נקודות חולשה שכבר לא תקפים.
מעקב אחרי קוד האפליקציה כדי לזהות פרצות אבטחה ידועות
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
השתמשו בכלים אוטומטיים כדי לעקוב באופן קבוע אחרי קוד האפליקציה ולזהות נקודות חולשה ידועות, כמו OWASP Top 10. מידע נוסף על מוצרים ותכונות של Google Cloud שתומכים בטכניקות לצמצום הסיכונים של OWASP Top 10 זמין במאמר צמצום הסיכונים של OWASP Top 10:2025 ב- Google Cloud.
אתם יכולים להשתמש ב-Web Security Scanner כדי לזהות פרצות אבטחה באפליקציות האינטרנט של App Engine, Compute Engine ו-GKE. הסורק סורק את האפליקציה, עוקב אחרי כל הקישורים בהיקף של כתובות ה-URL ההתחלתיות ומנסה להפעיל כמה שיותר קלט של משתמשים וגורמים מטפלים באירועים. הוא יכול לסרוק ולזהות באופן אוטומטי נקודות חולשה נפוצות, כולל פרצת אבטחה XSS (cross-site scripting), הזרקת קוד, תוכן מעורב וספריות מיושנות או לא מאובטחות. הכלי Web Security Scanner מאפשר לזהות בשלב מוקדם את נקודות החולשה האלה, בלי להסיח את דעתכם עם תוצאות חיוביות כוזבות.
בנוסף, אם אתם משתמשים ב-GKE כדי לנהל קבוצות של אשכולות Kubernetes, בלוח הבקרה של מצב האבטחה מוצגות המלצות ממוקדות ופרקטיות שיעזרו לכם לשפר את מצב האבטחה של הקבוצה.
הטמעת הגנת סייבר מונעת
העיקרון הזה, שמופיע בעמוד התווך של האבטחה ב-Google Cloud Well-Architected Framework, מספק המלצות לבניית תוכניות חזקות להגנת סייבר כחלק מאסטרטגיית האבטחה הכוללת.
העיקרון הזה מדגיש את השימוש במודיעין איומי סייבר כדי להנחות באופן יזום את המאמצים שלכם בפונקציות הליבה של הגנת הסייבר, כפי שמוגדר במדריך The Defender's Advantage: A guide to activating cyber defense.
סקירה כללית של העקרונות
כשאתם מגינים על המערכת מפני התקפות סייבר, יש לכם יתרון משמעותי על פני התוקפים, אבל אתם לא תמיד מנצלים אותו. כמו שמייסד Mandiant אומר, "אתם צריכים לדעת יותר על העסק, המערכות, הטופולוגיה והתשתית שלכם מכל תוקף. זה יתרון מדהים". כדי לעזור לכם להשתמש ביתרון המובנה הזה, במסמך הזה מפורטות המלצות לגבי שיטות פרואקטיביות ואסטרטגיות להגנת סייבר, שממופות למסגרת Defender's Advantage.
המלצות
כדי להטמיע הגנת סייבר מונעת בעומסי העבודה בענן, כדאי לפעול לפי ההמלצות שבקטעים הבאים:
- שילוב הפונקציות של הגנת סייבר
- שימוש בפונקציית המודיעין בכל ההיבטים של הגנת סייבר
- הבנה וניצול של יתרון המגן
- אימות ושיפור ההגנות באופן קבוע
- ניהול ותיאום של מאמצי הגנת הסייבר
לשלב את הפונקציות של הגנת סייבר
ההמלצה הזו רלוונטית לכל תחומי המיקוד.
במסגרת Defender's Advantage מזוהות שש פונקציות קריטיות של הגנת סייבר: מודיעין, זיהוי, תגובה, אימות, איתור ומרכז בקרה. כל פונקציה מתמקדת בחלק ייחודי של משימת הגנת הסייבר, אבל הפונקציות האלה חייבות להיות מתואמות היטב ולפעול יחד כדי לספק הגנה יעילה. התמקדו ביצירת מערכת חזקה ומשולבת שבה כל פונקציה תומכת בפונקציות האחרות. אם אתם צריכים גישה הדרגתית להטמעה, כדאי לשקול את הסדר הבא. בהתאם לרמת הבשלות הנוכחית שלכם בענן, לטופולוגיית המשאבים ולנוף האיומים הספציפי, יכול להיות שתרצו לתעדף פונקציות מסוימות.
- מודיעין: פונקציית המודיעין מנחה את כל שאר הפונקציות. כדי לתעדף פעולות בכל התוכנית, חשוב להבין את נוף האיומים – כולל התוקפים הסבירים ביותר, השיטות, הטכניקות והפעולות (TTPs) שלהם וההשפעה הפוטנציאלית. פונקציית המודיעין אחראית על זיהוי בעלי העניין, הגדרת דרישות המודיעין, איסוף הנתונים, הניתוח וההפצה, האוטומציה ויצירת פרופיל של איומי סייבר.
- זיהוי ותגובה: הפונקציות האלה מהוות את הליבה של ההגנה הפעילה, שכוללת זיהוי של פעילות זדונית וטיפול בה. הפונקציות האלה נדרשות כדי לפעול על סמך המידע שנאסף על ידי פונקציית המידע. הפונקציה Detect דורשת גישה שיטתית שמתאימה את הזיהויים ל-TTP של התוקף ומבטיחה רישום חזק ביומן. הפונקציה "תגובה" צריכה להתמקד במיון ראשוני, באיסוף נתונים ובטיפול באירוע.
- אימות: פונקציית האימות היא תהליך מתמשך שמוודא שסביבת בקרת האבטחה שלכם עדכנית ופועלת כמתוכנן. הפונקציה הזו מבטיחה שהארגון שלכם מבין את שטח המתקפה, יודע איפה יש נקודות חולשה ומודד את היעילות של אמצעי הבקרה. אימות האבטחה הוא גם רכיב חשוב במחזור החיים של הנדסת הזיהוי, וצריך להשתמש בו כדי לזהות פערים בזיהוי וליצור זיהויים חדשים.
- איתור: הפונקציה "איתור" כוללת חיפוש יזום של איומים פעילים בסביבה. צריך להטמיע את הפונקציה הזו כשהארגון מגיע לרמת בגרות בסיסית בפונקציות "זיהוי" ו"תגובה". פונקציית ה-Hunt מרחיבה את יכולות הזיהוי ועוזרת לזהות פערים וחולשות באמצעי הבקרה. פונקציית החיפוש חייבת להתבסס על איומים ספציפיים. הפונקציה המתקדמת הזו נהנית מיכולות חזקות של מודיעין, זיהוי ותגובה.
- Mission Control: הפונקציה Mission Control פועלת כמרכז שמחבר את כל הפונקציות האחרות. התפקיד הזה אחראי על האסטרטגיה, התקשורת והפעולות המכריעות בתוכנית הגנת הסייבר. היא מבטיחה שכל הפונקציות פועלות יחד ושהן תואמות ליעדים העסקיים של הארגון. חשוב להבין היטב את המטרה של פונקציית מרכז הבקרה לפני שמשתמשים בה כדי לחבר את הפונקציות האחרות.
שימוש בפונקציית המודיעין בכל ההיבטים של הגנת סייבר
ההמלצה הזו רלוונטית לכל תחומי המיקוד.
ההמלצה הזו מדגישה את פונקציית המודיעין כחלק מרכזי בתוכנית חזקה להגנת סייבר. מודיעין איומי סייבר מספק מידע על גורמים זדוניים, על ה-TTP שלהם ועל סימנים מחשידים (IoC). הידע הזה אמור להנחות את הפעולות בכל פונקציות הגנת הסייבר ולתעדף אותן. גישה מבוססת-מודיעין עוזרת לכם להתאים את ההגנות לאיומים שהכי סביר שישפיעו על הארגון שלכם. הגישה הזו גם עוזרת להקצות משאבים ולתעדף אותם בצורה יעילה.
המוצרים והתכונות הבאים של Google Cloud עוזרים לכם להשתמש במודיעין איומי סייבר כדי לנהל את פעולות האבטחה. אתם יכולים להשתמש בתכונות האלה כדי לזהות איומים, נקודות חולשה וסיכונים פוטנציאליים, לתעדף אותם, ואז לתכנן וליישם פעולות מתאימות.
Google Security Operations (Google SecOps) עוזר לאחסן ולנתח נתוני אבטחה באופן מרוכז. אתם יכולים להשתמש ב-Google SecOps כדי למפות יומנים למודל משותף, להעשיר את היומנים ולקשר אותם לצירי זמן כדי לקבל תצוגה מקיפה של ההתקפות. אתם יכולים גם ליצור כללי זיהוי, להגדיר התאמה של IoC ולבצע פעילויות של איתור איומים. בפלטפורמה יש גם גלאים מוכנים מראש, שהם כללים מוגדרים מראש ומנוהלים שעוזרים לזהות איומים. אפשר גם לשלב את Google SecOps עם מודיעין קו החזית של Mandiant. Google SecOps משלב באופן ייחודי AI מוביל בתחום, יחד עם מודיעין איומי סייבר מ-Mandiant ו-Google VirusTotal. השילוב הזה חיוני להערכת איומים ולהבנה מי מטרגט את הארגון שלכם ומה ההשפעה הפוטנציאלית.
Security Command Center, שמבוסס על Google AI, מאפשר לאנשי מקצוע בתחום האבטחה להעריך, לחקור ולהגיב ביעילות לבעיות אבטחה בסביבות ענן מרובות. מומחי האבטחה שיכולים להפיק תועלת מ-Security Command Center כוללים אנליסטים של מרכז תפעול אבטחה (SOC), אנליסטים של נקודות חולשה ושל מצב האבטחה ומנהלי תאימות. Security Command Center מעשיר את נתוני האבטחה, מעריך את הסיכונים ומתעדף את נקודות החולשה. הפתרון הזה מספק לצוותים את המידע שהם צריכים כדי לטפל בנקודות חולשה בסיכון גבוה ולתקן איומים פעילים.
Chrome Enterprise Premium מציע הגנה על נתונים מפני איומים, שעוזרת להגן על המשתמשים מפני סיכונים של זליגת נתונים ומונעת מתוכנות זדוניות להגיע למכשירים שמנוהלים על ידי הארגון. בנוסף, Chrome Enterprise Premium מספק תובנות לגבי פעילות לא בטוחה או פעילות שעלולה להיות לא בטוחה בדפדפן.
מעקב אחרי הרשת, באמצעות כלים כמו Network Intelligence Center, מאפשר לראות את ביצועי הרשת. מעקב אחרי הרשת יכול גם לעזור לכם לזהות דפוסי תנועה חריגים או כמויות של העברת נתונים שעשויות להצביע על מתקפה או על ניסיון לחילוץ נתונים.
הבנת היתרון של המגן וניצול שלו
ההמלצה הזו רלוונטית לכל תחומי המיקוד.
כמו שצוין קודם, יש לכם יתרון על פני התוקפים אם אתם מכירים לעומק את העסק, המערכות, הטופולוגיה והתשתית שלכם. כדי לנצל את היתרון הזה, השתמשו בנתונים האלה על הסביבות שלכם כשאתם מתכננים את הגנת הסייבר.
Google Cloud מספק את התכונות הבאות כדי לעזור לכם לזהות איומים, להבין את הסיכונים ולהגיב בזמן כדי לצמצם נזקים פוטנציאליים:
Chrome Enterprise Premium עוזר לשפר את האבטחה במכשירים של הארגון ומגן על המשתמשים מפני סיכונים של זליגת נתונים. הוא מרחיב את שירותי Sensitive Data Protection לדפדפן ומונע תוכנות זדוניות. הוא גם מציע תכונות כמו הגנה מפני תוכנות זדוניות ופישינג, כדי למנוע חשיפה לתוכן לא בטוח. בנוסף, היא מאפשרת לכם לשלוט בהתקנת תוספים כדי למנוע התקנה של תוספים לא בטוחים או לא מאומתים. היכולות האלה עוזרות לכם לבסס בסיס מאובטח לפעולות שלכם.
ב-Security Command Center יש מנוע סיכונים שפועל באופן רציף ומאפשר לנתח ולנהל סיכונים בצורה מקיפה ומתמשכת. התכונה "מנוע הסיכונים" מעשירה את נתוני האבטחה, מעריכה את הסיכון ומתעדפת את נקודות החולשה כדי לעזור לפתור בעיות במהירות. בעזרת Security Command Center, הארגון יכול לזהות נקודות חולשה באופן יזום וליישם פתרונות.
ב-Google SecOps, נתוני האבטחה מרוכזים במקום אחד ויומנים מועשרים עם צירי זמן. כך המגינים יכולים לזהות באופן יזום פרצות פעילות ולהתאים את ההגנות על סמך התנהגות התוקפים.
ניטור הרשת עוזר לזהות פעילות חריגה ברשת שעשויה להצביע על מתקפה, ומספק אינדיקטורים מוקדמים שמאפשרים לכם לפעול. כדי להגן על הנתונים שלכם מפני גניבה, חשוב לעקוב באופן רציף אחרי זליגת נתונים ולהשתמש בכלים שסופקו.
אימות ושיפור ההגנות באופן רציף
ההמלצה הזו רלוונטית לכל תחומי המיקוד.
ההמלצה הזו מדגישה את החשיבות של בדיקות ממוקדות ואימות רציף של אמצעי הבקרה כדי להבין את החוזקות והחולשות בכל שטח המתקפה. האימות כולל בדיקה של יעילות אמצעי הבקרה, הפעולות והצוות, בשיטות כמו:
- בדיקות חדירה
- תרגילים של צוות אדום-כחול וצוות סגול
- תרגילים תיאורטיים
אתם צריכים גם לחפש איומים באופן פעיל ולהשתמש בתוצאות כדי לשפר את הזיהוי והחשיפה. אתם יכולים להשתמש בכלים הבאים כדי לבדוק ולאמת באופן קבוע את ההגנות שלכם מפני איומים בעולם האמיתי:
ב-Security Command Center יש מנוע סיכונים רציף שמעריך את נקודות החולשה ומתעדף את התיקון שלהן, וכך מאפשר להעריך באופן שוטף את מצב האבטחה הכולל. ב-Security Command Center הבעיות מתועדפות, כדי שתוכלו להשתמש במשאבים בצורה יעילה.
ב-Google SecOps יש כלים לאיתור איומים וגלאים מוכנים מראש שמאפשרים לזהות באופן יזום נקודות חולשה באמצעי הבקרה. היכולת הזו מאפשרת לבדוק ולשפר באופן רציף את היכולת לזהות איומים.
Chrome Enterprise Premium מספק תכונות להגנה על נתונים מפני איומים, שיכולות לעזור לכם להתמודד עם איומים חדשים ומתפתחים, ולעדכן באופן קבוע את ההגנות מפני סיכונים של זליגת נתונים ותוכנות זדוניות.
Cloud Next Generation Firewall (Cloud NGFW) מספק מעקב אחרי הרשת ואחרי זליגת נתונים. היכולות האלה יכולות לעזור לכם לאמת את היעילות של מצב האבטחה הנוכחי ולזהות נקודות חולשה פוטנציאליות. מעקב אחרי זליגת נתונים עוזר לכם לבדוק את היעילות של מנגנוני ההגנה על הנתונים בארגון, ולבצע שינויים יזומים לפי הצורך. כשמשלבים את ממצאי האיומים מ-Cloud NGFW עם Security Command Center ו-Google SecOps, אפשר לשפר את זיהוי האיומים ברשת, לשפר את התגובה לאיומים ולהפוך את הפלייבוקים לאוטומטיים.
לנהל ולתאם את מאמצי הגנת הסייבר
ההמלצה הזו רלוונטית לכל תחומי המיקוד.
כמו שמתואר בקטע שילוב הפונקציות של הגנת הסייבר, פונקציית בקרת המשימה מקשרת בין הפונקציות האחרות של תוכנית הגנת הסייבר. הפונקציה הזו מאפשרת תיאום וניהול מאוחד של התוכנית. הוא גם עוזר לכם לתאם עם צוותים אחרים שלא עובדים בתחום אבטחת הסייבר. הפונקציה Mission Control מקדמת העצמה ואחריותיות, מאפשרת גמישות ומומחיות ומניעה אחריות ושקיפות.
המוצרים והתכונות הבאים יכולים לעזור לכם להטמיע את הפונקציה Mission Control:
- Security Command Center משמש כמרכז לתיאום ולניהול של פעולות הגנת הסייבר. הוא מאחד כלים, צוותים ונתונים, וכולל יכולות תגובה מובנות של Google SecOps. ב-Security Command Center אפשר לראות בבירור את מצב האבטחה של הארגון, ולזהות הגדרות אבטחה שגויות במשאבים שונים.
- Google SecOps מספקת פלטפורמה שמאפשרת לצוותים להגיב לאיומים על ידי מיפוי יומנים ויצירת צירי זמן. אתם יכולים גם להגדיר כללי זיהוי ולחפש איומים.
- Google Workspace ו-Chrome Enterprise Premium עוזרים לכם לנהל ולבקר את הגישה של משתמשי הקצה למשאבים רגישים. אתם יכולים להגדיר בקרת גישה מפורטת על סמך זהות המשתמש וההקשר של בקשה.
- מעקב אחרי הרשת מספק תובנות לגבי הביצועים של משאבי הרשת. אתם יכולים לייבא תובנות ממעקב אחרי הרשת ל-Security Command Center ול-Google SecOps כדי לעקוב אחרי הנתונים באופן מרוכז ולבצע קורלציה עם נקודות אחרות על הגרף שמבוססות על ציר הזמן. השילוב הזה עוזר לזהות שינויים פוטנציאליים בשימוש ברשת שנגרמו כתוצאה מפעילות זדונית, ולהגיב להם.
- מעקב אחרי זליגת נתונים עוזר לזהות אירועים אפשריים של אובדן נתונים. בעזרת התכונה הזו, אתם יכולים להפעיל ביעילות צוות תגובה לאירועים, להעריך את הנזקים ולהגביל זליגת נתונים נוספת. אתם יכולים גם לשפר את כללי המדיניות ואמצעי הבקרה הקיימים כדי להגן על הנתונים.
סיכום מוצר
בטבלה הבאה מפורטים המוצרים והתכונות שמתוארים במסמך הזה, והם ממופים להמלצות וליכולות האבטחה המשויכות.
| המוצר שלGoogle Cloud | המלצות רלוונטיות |
|---|---|
| Google SecOps |
שימוש בפונקציית המודיעין בכל ההיבטים של הגנת סייבר:
מאפשרת איתור איומים והתאמת IoC, ומשתלבת עם Mandiant להערכת איומים מקיפה.
הבנה וניצול של יתרון ההגנה: מספק גלאים מוכנים מראש ומרכז את נתוני האבטחה כדי לזהות פריצות באופן יזום. אימות ושיפור מתמשך של ההגנות: מאפשר בדיקה ושיפור מתמשכים של יכולות זיהוי האיומים.ניהול ותיאום של מאמצי הגנת הסייבר באמצעות Mission Control: פלטפורמה לתגובה לאיומים, ניתוח יומנים ויצירת ציר זמן. |
| Security Command Center |
שימוש בפונקציית המודיעין בכל ההיבטים של הגנת סייבר:
שימוש ב-AI כדי להעריך סיכונים, לתעדף נקודות חולשה ולספק
תובנות פרקטיות לתיקון.
הבנה וניצול של יתרון המגן: ניתוח סיכונים מקיף, תעדוף נקודות חולשה וזיהוי יזום של נקודות חולשה. אימות ושיפור מתמשכים של ההגנות: הערכה שוטפת של מצב האבטחה ותעדוף משאבים.ניהול ותיאום של מאמצי הגנת הסייבר באמצעות Mission Control: משמש כמרכז לניהול ולתיאום של פעולות הגנת הסייבר. |
| Chrome Enterprise Premium |
שימוש בפונקציית המודיעין בכל ההיבטים של הגנת הסייבר:
הגנה על המשתמשים מפני סיכונים של זליגת מידע, מניעת תוכנות זדוניות
וקבלת תובנות לגבי פעילות לא בטוחה בדפדפן.
הבנה וניצול של יתרון ההגנה: שיפור האבטחה של מכשירים ארגוניים באמצעות הגנה על נתונים, מניעת תוכנות זדוניות ושליטה בתוספים. אימות ושיפור מתמשך של ההגנות: התמודדות עם איומים חדשים ומתפתחים באמצעות עדכונים שוטפים של ההגנות מפני סיכונים של זליגת מידע ותוכנות זדוניות.ניהול ותיאום של מאמצי הגנת הסייבר באמצעות Mission Control: ניהול ובקרת גישה של משתמשי הקצה למשאבים רגישים, כולל בקרת גישה מפורטת. |
| Google Workspace | ניהול ותיאום של מאמצי הגנת הסייבר באמצעות Mission Control: ניהול ובקרת גישה של משתמשי הקצה למשאבים רגישים, כולל בקרת גישה מפורטת. |
| Network Intelligence Center | שימוש בפונקציית המודיעין בכל ההיבטים של הגנת סייבר: מספקת תצוגה של ביצועי הרשת ומזהה דפוסי תנועה או העברות נתונים חריגים. |
| Cloud NGFW | אימות ושיפור ההגנות באופן רציף: אופטימיזציה של זיהוי איומים ברשת והתגובה אליהם באמצעות שילוב עם Security Command Center ו-Google SecOps. |
שימוש ב-AI באופן מאובטח ואחראי
העיקרון הזה, שמופיע בעמוד התווך של האבטחה ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לאבטח את מערכות ה-AI שלכם. ההמלצות האלה תואמות ל-Secure AI Framework (SAIF) של Google, שמספקת גישה מעשית לטיפול בבעיות אבטחה וסיכונים במערכות AI. SAIF היא מסגרת רעיונית שמטרתה לספק סטנדרטים כלל-תעשייתיים ליצירה ולפריסה של מערכות AI באופן אחראי.
סקירה כללית של העקרונות
כדי לוודא שמערכות ה-AI עומדות בדרישות האבטחה, הפרטיות והתאימות, צריך לאמץ אסטרטגיה הוליסטית שמתחילה בתכנון הראשוני ונמשכת עד לפריסה ולתפעול. כדי ליישם את האסטרטגיה הכוללת הזו, צריך להשתמש בששת יסודות הליבה של SAIF.
Google משתמשת ב-AI כדי לשפר את אמצעי האבטחה, למשל זיהוי איומים, אוטומציה של משימות אבטחה ושיפור יכולות הזיהוי, תוך שמירה על האדם שבתהליך בהחלטות קריטיות.
Google מדגישה את הגישה השיתופית לקידום אבטחת ה-AI. הגישה הזו כוללת שיתוף פעולה עם לקוחות, תעשיות וממשלות כדי לשפר את ההנחיות של SAIF ולהציע משאבים מעשיים ושימושיים.
ההמלצות ליישום העיקרון הזה מקובצות בקטעים הבאים:
המלצות לשימוש מאובטח ב-AI
כדי להשתמש ב-AI בצורה מאובטחת, צריך גם אמצעי בקרה בסיסיים לאבטחה וגם אמצעי בקרה לאבטחה שספציפיים ל-AI. בקטע הזה מפורטות המלצות שיעזרו לכם לוודא שהפריסות של ה-AI וה-ML עומדות בדרישות האבטחה, הפרטיות והתאימות של הארגון. במאמר נקודת המבט של AI ו-ML ב-Well-Architected Framework מופיעה סקירה כללית של עקרונות והמלצות לארכיטקטורה שספציפיים לעומסי עבודה של AI ו-ML ב- Google Cloud.
הגדירו יעדים ודרישות ברורים לשימוש ב-AI
ההמלצה הזו רלוונטית לתחומים הבאים:
- משילות, סיכונים ותאימות בענן
- אבטחה של AI ו-ML
ההמלצה הזו תואמת לרכיב של SAIF שעוסק בהצגת הסיכונים למערכות AI בהקשר של התהליכים העסקיים שסובבים אותן. כשאתם מתכננים ומפתחים מערכות AI, חשוב שתבינו את היעדים העסקיים, הסיכונים ודרישות התאימות הספציפיים שלכם.
שמירה על אבטחת מידע ומניעת אובדן או טיפול שגוי
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
- אבטחת אפליקציות
- אבטחה של AI ו-ML
ההמלצה הזו תואמת לרכיבים הבאים של SAIF:
- הרחבה של תשתיות אבטחה יעילות לסביבה העסקית של AI. הרכיב הזה כולל איסוף נתונים, אחסון, בקרת גישה והגנה מפני הרעלת נתונים.
- הצגת הסיכונים למערכות AI בהקשר של התהליכים העסקיים שסובבים אותן. להדגיש את אבטחת המידע כדי לתמוך ביעדים העסקיים ובתאימות.
שמירה על אבטחה וחוזק של צינורות עיבוד נתונים (pipeline) של AI מפני שיבושים
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
- אבטחת אפליקציות
- אבטחה של AI ו-ML
ההמלצה הזו תואמת לרכיבים הבאים של SAIF:
- הרחבה של תשתיות אבטחה יעילות לסביבה העסקית של AI. כחלק מרכזי בהקמת מערכת AI מאובטחת, צריך לאבטח את הקוד ואת פריטי המידע שנוצרו בתהליך הפיתוח של המודל.
- התאמה של אמצעי הבקרה כדי ליצור לולאות משוב מהירות יותר. חשוב לעקוב אחרי הנכסים והרצות הצינורות, כי זה עוזר להפחית את הסיכון ולהגיב לאירועים.
פריסת אפליקציות במערכות מאובטחות באמצעות כלים וארטיפקטים מאובטחים
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
- אבטחת אפליקציות
- אבטחה של AI ו-ML
שימוש במערכות מאובטחות ובכלים ובפריטי מידע מאומתים באפליקציות מבוססות-AI תואם לרכיב של SAIF בנושא הרחבה של תשתיות אבטחה עוצמתיות לסביבה העסקית ולשרשרת האספקה של AI. כדי ליישם את ההמלצה הזו, צריך לבצע את הפעולות הבאות:
- הטמעת סביבה מאובטחת לאימון ולפריסה של למידת מכונה
- שימוש בקובצי אימג' מאומתים של קונטיינרים
- יישום ההנחיות של רמות של שרשרת אספקה לארטיפקטים של תוכנה (SLSA)
הגנה על מקורות קלט ומעקב אחריהם
ההמלצה הזו רלוונטית לתחומים הבאים:
- רישום ביומן, ביקורת ומעקב
- תפעול אבטחה (SecOps)
- אבטחה של AI ו-ML
ההמלצה הזו תואמת לרכיב של SAIF בנושא הרחבת הזיהוי והתגובה כדי להכניס את ה-AI לעולם האיומים של הארגון. כדי למנוע בעיות, חשוב מאוד לנהל את ההנחיות למערכות ה-AI הגנרטיבי, לעקוב אחרי הקלט ולשלוט בגישה של המשתמשים.
המלצות לאמצעי הפיקוח על AI
כל ההמלצות בקטע הזה רלוונטיות לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
Google Cloud מציעה מגוון רחב של כלים ושירותים שבעזרתם אתם יכולים לפתח מערכות AI אחראיות ואתיות. אנחנו מציעים גם מסגרת של כללי מדיניות, נהלים ושיקולים אתיים שיכולים להנחות את הפיתוח, הפריסה והשימוש במערכות AI.
כפי שמשתקף בהמלצות שלנו, הגישה של Google לאמצעי הפיקוח על AI מבוססת על העקרונות הבאים:
- הוגנות
- שקיפות
- אחריותיות
- פרטיות
- אבטחה
שימוש ב-Fairness Indicators
Gemini Enterprise Agent Platform יכול לזהות הטיה במהלך איסוף הנתונים או תהליך ההערכה שאחרי האימון. ב-Agent Platform יש מדדים להערכת מודלים כמו הטיה בנתונים והטיה במודל, שעוזרים לכם להעריך את ההטיה במודל.
המדדים האלה קשורים להוגנות בקטגוריות שונות כמו גזע, מגדר ומעמד. עם זאת, לא פשוט לפרש סטיות סטטיסטיות, כי יכול להיות שההבדלים בין הקטגוריות לא נובעים מהטיה או מנזק.
שימוש ב-Vertex Explainable AI
כדי להבין איך מודלים של AI מקבלים החלטות, אתם יכולים להשתמש ב-Vertex Explainable AI. התכונה הזו עוזרת לזהות הטיות פוטנציאליות שעשויות להיות מוסתרות בלוגיקה של המודל.
תכונת ההסבר הזו משולבת עם BigQuery ML ועם Vertex AI ניתן להסברה, שמספקים הסברים שמבוססים על מאפיינים. אתם יכולים להסביר את המודל ב-BigQuery ML או לרשום את המודל ב-Agent Platform ולהסביר אותו ב-Agent Platform.
מעקב אחרי שושלת נתונים
עוקבים אחרי המקור והטרנספורמציה של הנתונים שמשמשים את מערכות ה-AI. המעקב הזה עוזר להבין את מסלול הנתונים ולזהות מקורות פוטנציאליים להטיה או לשגיאה.
שושלת נתונים היא תכונה של Knowledge Catalog שמאפשרת לעקוב אחרי תנועת הנתונים במערכות: מאיפה הם מגיעים, לאן הם מועברים ואילו טרנספורמציות מוחלות עליהם.
הגדרת אחריות
צריך להגדיר בצורה ברורה את תחומי האחריות לפיתוח, לפריסה ולתוצאות של מערכות ה-AI.
משתמשים ב-Cloud Logging כדי לתעד אירועים מרכזיים והחלטות שמתקבלות על ידי מערכות ה-AI. היומנים מספקים נתיב ביקורת שעוזר להבין את ביצועי המערכת ולזהות תחומים לשיפור.
להשתמש ב-Error Reporting כדי לנתח באופן שיטתי שגיאות שנוצרו על ידי מערכות ה-AI. הניתוח הזה יכול לחשוף דפוסים שמצביעים על הטיות בסיסיות או על תחומים שבהם צריך לשפר את המודל.
הטמעת פרטיות דיפרנציאלית
במהלך אימון המודל, מוסיפים רעש לנתונים כדי שיהיה קשה לזהות נקודות ספציפיות על הגרף, אבל עדיין לאפשר למודל ללמוד ביעילות. באמצעות SQL ב-BigQuery, אתם יכולים לשנות את תוצאות השאילתה באמצעות צבירות עם פרטיות דיפרנציאלית.
שימוש ב-AI לאבטחה
העיקרון הזה בעמוד התווך של האבטחה ב-Google Cloud Well-Architected Framework מספק המלצות לשימוש ב-AI כדי לשפר את האבטחה של עומסי העבודה בענן.
בגלל המספר ההולך וגדל של מתקפות סייבר והתחכום שלהן, חשוב לנצל את הפוטנציאל של AI כדי לשפר את האבטחה. ה-AI יכול לעזור לצמצם את מספר האיומים, להפחית את המאמץ הידני שנדרש ממומחי אבטחה ולפצות על המחסור במומחים בתחום אבטחת הסייבר.
סקירה כללית של העקרונות
להשתמש ביכולות של AI כדי לשפר את מערכות האבטחה והתהליכים הקיימים. אתם יכולים להשתמש ב-Gemini in Security וגם ביכולות ה-AI המובנות בשירותי Google Cloud .
יכולות ה-AI האלה יכולות לשנות את האבטחה על ידי מתן סיוע בכל שלב במחזור החיים של האבטחה. לדוגמה, אתם יכולים להשתמש ב-AI כדי:
- לנתח ולהסביר קוד שעלול להיות זדוני בלי הנדסה הפוכה.
- צמצום העבודה שחוזרת על עצמה למומחים בתחום אבטחת הסייבר.
- אפשר להשתמש בשפה טבעית כדי ליצור שאילתות ולקיים אינטראקציה עם נתונים של אירועי אבטחה.
- להציג מידע לפי הקשר.
- להציע המלצות לתשובות מהירות.
- עזרה בתיקון אירועים.
- לסכם התראות בעדיפות גבוהה לגבי הגדרות שגויות ונקודות חולשה, להדגיש השפעות פוטנציאליות ולהמליץ על דרכים לצמצום הסיכונים.
רמות של אוטונומיית אבטחה
כשמתמודדים עם איומי אבטחת סייבר שמתפתחים כל הזמן, AI ואוטומציה יכולים לעזור לכם להשיג תוצאות אבטחה טובות יותר. שימוש ב-AI לאבטחה מאפשר לכם להגיע לרמות גבוהות יותר של אוטונומיה בזיהוי איומים ובמניעה שלהם, ולשפר את מצב האבטחה הכולל. Google מגדירה ארבע רמות של אוטונומיה כשמשתמשים ב-AI לאבטחה, והן מתארות את התפקיד ההולך וגדל של AI בסיוע למשימות אבטחה, ובסופו של דבר בניהול שלהן:
- ידני: בני אדם מפעילים את כל משימות האבטחה (מניעה, זיהוי, תעדוף ותגובה) לאורך כל מחזור החיים של האבטחה.
- סיוע: כלי AI, כמו Gemini, משפרים את הפרודוקטיביות של בני האדם על ידי סיכום מידע, יצירת תובנות שנוצרו על ידי AI ומתן המלצות.
- חצי אוטונומי: ה-AI אחראי על רוב משימות האבטחה, ומעביר אותן לבני אדם רק כשצריך.
- אוטונומי: ה-AI פועל כעוזר אישי מהימן שמנהל את מחזור החיים של האבטחה על סמך היעדים וההעדפות של הארגון, עם התערבות אנושית מינימלית.
המלצות
בקטעים הבאים מפורטות ההמלצות לשימוש ב-AI לצורכי אבטחה. בנוסף, בכל חלק מצוין איך ההמלצות תואמות ליסודות הליבה של Secure AI Framework (SAIF) של Google, ואיך הן רלוונטיות לרמות האוטונומיה של האבטחה.
- שיפור הזיהוי של איומים והתגובה אליהם באמצעות AI
- אבטחה פשוטה למומחים ולמי שאינם מומחים
- אוטומציה של משימות אבטחה שגוזלות זמן באמצעות AI
- שילוב AI בתהליכי ניהול סיכונים ופיקוח
- הטמעת שיטות פיתוח מאובטחות למערכות AI
שיפור הזיהוי של איומים והתגובה אליהם באמצעות AI
ההמלצה הזו רלוונטית לתחומים הבאים:
- תפעול אבטחה (SecOps)
- רישום ביומן, ביקורת ומעקב
ה-AI יכול לנתח כמויות גדולות של נתוני אבטחה, להציע תובנות לגבי ההתנהגות של גורמים זדוניים ולנתח באופן אוטומטי קוד שעלול להיות זדוני. ההמלצה הזו תואמת לרכיבים הבאים של SAIF:
- שילוב AI בתהליכי הטיפול באיומים בארגון, משלב הזיהוי ועד שלב התגובה.
- אוטומציה של אמצעי הגנה במטרה לעמוד בקצב של איומים קיימים וחדשים.
בהתאם להטמעה, ההמלצה הזו יכולה להיות רלוונטית לרמות האוטונומיה הבאות:
- סיוע: ה-AI עוזר לנתח ולזהות איומים.
- אוטונומי למחצה: ה-AI לוקח על עצמו יותר אחריות על משימת האבטחה.
כדי ליישם את ההמלצה הזו, אתם יכולים להשתמש ב-Google Threat Intelligence, שמשתמש ב-AI כדי לנתח את ההתנהגות של גורמי האיום ואת הקוד הזדוני.
אבטחה פשוטה למומחים ולמי שאינם מומחים
ההמלצה הזו רלוונטית לתחומים הבאים:
- תפעול אבטחה (SecOps)
- משילות, סיכונים ותאימות בענן
כלים מבוססי-AI יכולים לסכם התראות ולהמליץ על דרכים לצמצום הסיכונים, והיכולות האלה יכולות להפוך את האבטחה לנגישה יותר למגוון רחב יותר של אנשי צוות. ההמלצה הזו תואמת לרכיבים הבאים של SAIF:
- אוטומציה של אמצעי הגנה במטרה לעמוד בקצב של איומים קיימים וחדשים.
- יצירת איזון והרמוניה בין אמצעי הבקרה ברמת הפלטפורמה כדי לשמור על אבטחה עקבית בכל חלקי הארגון.
בהתאם להטמעה, ההמלצה הזו יכולה להיות רלוונטית לרמות האוטונומיה הבאות:
- סיוע: ה-AI עוזר לשפר את הנגישות של מידע האבטחה.
- חצי אוטונומי: ה-AI עוזר לשפר את היעילות של נוהלי האבטחה לכל המשתמשים.
Gemini ב-Security Command Center יכול לספק סיכומים של התראות על הגדרות שגויות ונקודות חולשה.
אוטומציה של משימות אבטחה שדורשות זמן באמצעות AI
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת התשתית
- תפעול אבטחה (SecOps)
- אבטחת אפליקציות
ה-AI יכול להפוך משימות לאוטומטיות, כמו ניתוח תוכנות זדוניות, יצירת כללי אבטחה וזיהוי הגדרות שגויות. היכולות האלה יכולות לעזור להפחית את עומס העבודה של צוותי האבטחה ולקצר את זמני התגובה. ההמלצה הזו תואמת לרכיב של SAIF בנושא אוטומציה של אמצעי הגנה במטרה לעמוד בקצב של איומים קיימים וחדשים.
בהתאם להטמעה, ההמלצה הזו יכולה להיות רלוונטית לרמות האוטונומיה הבאות:
- סיוע: ה-AI עוזר לכם לבצע משימות באופן אוטומטי.
- חצי אוטונומי: ה-AI אחראי בעיקר על משימות האבטחה, ומבקש עזרה אנושית רק כשצריך.
Gemini ב-Google SecOps יכול לעזור לאנליסטים להפוך משימות מורכבות לאוטומטיות, לאחזר הקשר רלוונטי ולהמליץ על השלבים הבאים.
שילוב AI בתהליכי ניהול סיכונים ומשילות
ההמלצה הזו רלוונטית לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
אתם יכולים להשתמש ב-AI כדי ליצור מלאי של מודלים ופרופילי סיכון. אתם יכולים גם להשתמש ב-AI כדי להטמיע מדיניות בנושא פרטיות נתונים, סיכוני סייבר וסיכונים מצד שלישי. ההמלצה הזו תואמת לרכיב של SAIF בנושא הצגת הסיכונים למערכות AI בהקשר של התהליכים העסקיים שסובבים אותן.
בהתאם להטמעה, ההמלצה הזו יכולה להיות רלוונטית לרמת האוטונומיה החצי-אוטונומית. ברמה הזו, ה-AI יכול לתזמר סוכני אבטחה שמריצים תהליכים כדי להשיג את יעדי האבטחה המותאמים אישית שלכם.
הטמעת שיטות פיתוח מאובטחות למערכות AI
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת אפליקציות
- אבטחה של AI ו-ML
אתם יכולים להשתמש ב-AI כדי לכתוב קוד מאובטח, לנקות נתוני אימון ולאמת כלים ופריטי מידע שנוצרו בתהליך הפיתוח. ההמלצה הזו תואמת לרכיב של SAIF בנושא הרחבה של תשתיות אבטחה יעילות לסביבה העסקית של AI.
ההמלצה הזו יכולה להיות רלוונטית לכל רמות האוטונומיה של האבטחה, כי צריך מערכת AI מאובטחת כדי להשתמש ב-AI ביעילות לצורכי אבטחה. ההמלצה הכי רלוונטית לרמת הסיוע, שבה נוהלי האבטחה משופרים באמצעות AI.
כדי ליישם את ההמלצה הזו, צריך לפעול לפי ההנחיות של Supply-chain Levels for Software Artifacts (SLSA) לגבי פריטי AI, ולהשתמש בקובצי אימג' מאומתים של קונטיינרים.
עמידה בדרישות הרגולציה, התאימות והפרטיות
העיקרון הזה, שמופיע בעמוד התווך של האבטחה ב-Google Cloud Well-Architected Framework, עוזר לכם לזהות את הדרישות בנושא רגולציה, תאימות ופרטיות בפריסות בענן ולעמוד בהן. הדרישות האלה משפיעות על הרבה מההחלטות שצריך לקבל לגבי אמצעי הבקרה לאבטחה שבהם צריך להשתמש בעומסי העבודה ב-Google Cloud.
סקירה כללית של העקרונות
כל העסקים מתמודדים עם האתגר של עמידה בדרישות הרגולציה, התאימות והפרטיות. הדרישות הרגולטוריות בענן תלויות בכמה גורמים, כולל:
- החוקים והתקנות שחלים על המיקומים הפיזיים של הארגון
- החוקים והתקנות שחלים על המיקומים הפיזיים של הלקוחות שלכם
- הדרישות הרגולטוריות בתחום שלכם
תקנות בנושא פרטיות מגדירות איך אתם יכולים לקבל, לעבד, לאחסן ולנהל את נתוני המשתמשים שלכם. הנתונים שלכם שייכים לכם, כולל הנתונים שאתם מקבלים מהמשתמשים. לכן, אתם אחראים על הרבה אמצעי בקרה על פרטיות, כולל אמצעי בקרה על קובצי Cookie, ניהול סשנים וקבלת הרשאות ממשתמשים.
ההמלצות ליישום העיקרון הזה מקובצות בקטעים הבאים:
- המלצות לטיפול בסיכונים ארגוניים
- המלצות לטיפול בהתחייבויות רגולטוריות ובהתחייבויות לעמידה בתנאים
- המלצות לניהול ריבונות הנתונים
- המלצות לעמידה בדרישות בנושא פרטיות
המלצות לטיפול בסיכונים בארגון
בקטע הזה מפורטות המלצות שיעזרו לכם לזהות סיכונים בארגון ולטפל בהם.
זיהוי סיכונים לארגון
ההמלצה הזו רלוונטית לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
לפני שיוצרים ופורסים משאבים ב- Google Cloud, צריך להשלים הערכת סיכונים. ההערכה הזו אמורה לקבוע אילו אמצעי אבטחה נדרשים כדי לעמוד בדרישות האבטחה הפנימיות ובדרישות הרגולטוריות החיצוניות.
הערכת הסיכונים מספקת קטלוג של סיכונים ספציפיים לארגון, ומספקת מידע על היכולת של הארגון לזהות איומי אבטחה ולנטרל אותם. אתם צריכים לבצע ניתוח סיכונים מיד אחרי הפריסה, ובכל פעם שיש שינויים בצרכים העסקיים, בדרישות הרגולטוריות או באיומים על הארגון.
כפי שצוין בעיקרון הטמעת אבטחה משלב התכנון, סיכוני האבטחה בסביבת ענן שונים מהסיכונים בסביבה מקומית. ההבדל הזה נובע ממודל האחריות המשותפת בענן, שמשתנה בהתאם לשירות (IaaS, PaaS או SaaS) ולאופן השימוש שלכם. השתמשו במסגרת להערכת סיכונים שספציפית לענן, כמו Cloud Controls Matrix (CCM). השתמשו במידול איומים, כמו מידול איומים באפליקציות של OWASP, כדי לזהות נקודות חולשה ולטפל בהן. כדי לקבל עזרה ממומחים בהערכות סיכונים, פנו לאיש הקשר האחראי לחשבון Google או עיינו במאגר הסוכנויות המוסמכות של Partners של Google Cloud.
אחרי שמקטלגים את הסיכונים, צריך להחליט איך לטפל בהם – כלומר, אם אתם רוצים לקבל, להימנע, להעביר או לצמצם את הסיכונים. בקטע הבא מפורטים אמצעי בקרה שאתם יכולים להטמיע כדי לצמצם את הסיכונים.
צמצום הסיכונים
ההמלצה הזו רלוונטית לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
כשאתם מאמצים שירותי ענן ציבורי חדשים, אתם יכולים לצמצם את הסיכונים באמצעות אמצעי בקרה טכניים, הגנות חוזיות ואימותים או אישורים של צד שלישי.
אמצעי בקרה טכניים הם תכונות וטכנולוגיות שמשמשות להגנה על הסביבה. הם כוללים אמצעי בקרה מובנים לאבטחה בענן, כמו חומות אש ורישום ביומן. אמצעי בקרה טכניים יכולים לכלול גם שימוש בכלים של צד שלישי כדי לחזק או לתמוך באסטרטגיית האבטחה שלכם. יש שני סוגים של אמצעי בקרה טכניים:
- אתם יכולים להטמיע את אמצעי הבקרה של Google Cloudכדי לצמצם את הסיכונים שרלוונטיים לסביבה שלכם. לדוגמה, אתם יכולים לאבטח את החיבור בין הרשתות המקומיות לרשתות בענן באמצעות Cloud VPN ו-Cloud Interconnect.
- ל-Google יש אמצעי בקרה וביקורת פנימיים חזקים כדי להגן על נתוני הלקוחות מפני גישה של גורמים פנימיים. יומני הביקורת שלנו מספקים לכם יומנים כמעט בזמן אמת של גישת אדמין של Google ב- Google Cloud.
הגנות חוזיות הן ההתחייבויות המשפטיות שלנו לגבי שירותיGoogle Cloud . Google מחויבת לשמור על תיק התאימות שלה ולהרחיב אותו. בנספח לעיבוד נתונים ב-Cloud (CDPA) מפורטות המחויבויות שלנו לגבי עיבוד הנתונים שלכם והאבטחה שלהם. בנוסף, ב-CDPA מפורטות בקרות הגישה שמגבילות את הגישה של מהנדסי התמיכה של Google לסביבות של הלקוחות, ומתואר תהליך הרישום ביומן והאישור הקפדני שלנו. מומלץ לבדוק את אמצעי הבקרה החוזיים של Google Cloudעם מומחים משפטיים ורגולטוריים, ולוודא שהם עומדים בדרישות שלכם. אם אתם צריכים מידע נוסף, פנו לאיש הקשר האחראי לחשבון הטכני שלכם.
אימותים או אישורים של צד שלישי מתייחסים למצב שבו ספק חיצוני בודק את ספק שירותי הענן כדי לוודא שהוא עומד בדרישות התאימות. לדוגמה, כדי לקבל מידע על אישורים בנוגע להנחיות ISO/IEC 27017, קראו את המאמר ISO/IEC 27017 – תאימות. Google Cloud במרכז המשאבים בנושא תאימות תוכלו לראות את Google Cloud האישורים והצהרות האימות הנוכחיים.
המלצות לטיפול בהתחייבויות רגולטוריות ובהתחייבויות לעמידה בתנאים
תהליך טיפוסי של תאימות כולל שלושה שלבים: הערכה, תיקון פערים ומעקב מתמשך. בקטע הזה מפורטות המלצות לכל אחד מהשלבים האלה.
הערכת צורכי התאימות שלכם
ההמלצה הזו רלוונטית לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
הערכת התאימות מתחילה בבדיקה יסודית של כל המחויבויות הרגולטוריות שלכם ואיך העסק מיישם אותן. כדי להעריך את השירותים של Google Cloud , אתם יכולים להיעזר ב-Compliance resource center. באתר הזה יש מידע על:
- תמיכה בשירותים בהתאם לתקנות שונות
- אישורים והצהרות שלGoogle Cloud
כדי להבין טוב יותר את מחזור החיים של התאימות ב-Google ואיך אפשר לעמוד בדרישות שלכם, אתם יכולים לפנות למכירות ולבקש עזרה ממומחה תאימות של Google. אפשר גם לפנות למנהל החשבון ב-Google Cloud כדי לבקש סדנה בנושא תאימות.
במאמר הבטחת תאימות בענן תוכלו לקרוא מידע נוסף על כלים ומשאבים שאפשר להשתמש בהם כדי לנהל את האבטחה והתאימות של עומסי העבודה ב- Google Cloud .
הטמעה אוטומטית של דרישות תאימות
ההמלצה הזו רלוונטית לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
כדי לעמוד בתקנות המשתנות, כדאי לבדוק אם אפשר להפוך את יישום דרישות התאימות לאוטומטי. אתם יכולים להשתמש גם ביכולות של Google Cloud שמתמקדות בתאימות וגם בתוכניות שמבוססות על הגדרות מומלצות למשטר תאימות מסוים.
Assured Workloads – מתבסס על אמצעי הבקרה ב- Google Cloud כדי לעזור לכם לעמוד בדרישות התאימות. בעזרת Assured Workloads אפשר:
- בוחרים את משטר התאימות. לאחר מכן, הכלי מגדיר באופן אוטומטי את בקרות הגישה הבסיסיות של אנשי הצוות למשטר שנבחר.
- מגדירים את מיקום הנתונים באמצעות מדיניות הארגון, כדי שהנתונים במנוחה והמשאבים יישארו רק באזור הזה.
- בוחרים את האפשרות לניהול מפתחות (כמו תקופת רוטציית המפתחות) שהכי מתאימה לדרישות האבטחה והתאימות שלכם.
- בוחרים את קריטריוני הגישה של צוות התמיכה של Google כדי לעמוד בדרישות רגולטוריות מסוימות, כמו FedRAMP Moderate. לדוגמה, אתם יכולים לבחור אם צוות התמיכה של Google השלים את בדיקות הרקע המתאימות.
- משתמשים ב- Google-owned and Google-managed encryption keys שתואמים ל-FIPS-140-2 ול-FedRAMP Moderate. כדי להוסיף עוד שכבת שליטה ולהפריד בין התפקידים, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK). מידע נוסף על מפתחות זמין במאמר הצפנת נתונים במנוחה ובמעבר.
בנוסף ל-Assured Workloads, אתם יכולים להשתמש בתוכניות של Google Cloudשרלוונטיות למשטר התאימות שלכם. אתם יכולים לשנות את התוכניות האלה כדי לשלב את מדיניות האבטחה שלכם בפריסות התשתית.
כדי לעזור לכם ליצור סביבה שתומכת בדרישות התאימות שלכם, המדריכים לפתרונות והתבניות של Google כוללים הגדרות מומלצות ומספקים מודולים של Terraform. בטבלה הבאה מפורטים שרטוטים שעוסקים באבטחה ובהתאמה לדרישות התאימות.
| דרישה | תוכניות ניהול ומדריכים לפתרונות |
|---|---|
| FedRAMP | |
| HIPAA |
מעקב אחרי התאימות
ההמלצה הזו רלוונטית לתחומים הבאים:
- משילות, סיכונים ותאימות בענן
- רישום ביומן, מעקב וביקורת
רוב התקנות דורשות מעקב אחרי פעילויות מסוימות, כולל פעילויות שקשורות לגישה. כדי לעזור לכם במעקב, אתם יכולים להשתמש בכלים הבאים:
- Access Transparency: צפייה ביומנים שמתעדכנים כמעט בזמן אמת כשהאדמינים של Google Cloud ניגשים לתוכן שלכם.
- ניהול כללי חומת אש: תיעוד של חיבורי TCP ו-UDP בתוך רשת VPC לכל הכללים שאתם יוצרים. היומנים האלה יכולים לשמש לביקורת של הגישה לרשת, או כדי לספק אזהרה מוקדמת על כך שהרשת משמשת באופן לא מאושר.
- יומני זרימה של VPC: מתעדים את זרימת התנועה ברשת שנשלחת או מתקבלת על ידי מכונות וירטואליות.
- Security Command Center Premium: מעקב אחרי התאימות לתקנים שונים.
- OSSEC (או כלי אחר בקוד פתוח): מתעד את הפעילות של אנשים שיש להם הרשאת אדמין לסביבה שלכם.
- הצדקות גישה למפתחות: הצגת הסיבות לבקשת גישה למפתח.
- התראות של Security Command Center: קבלת התראות כשמתרחשות בעיות של אי-תאימות. לדוגמה, לקבל התראות כשמשתמשים משביתים את האימות הדו-שלבי או כשחשבונות שירות מקבלים יותר מדי הרשאות. אתם יכולים גם להגדיר תיקון אוטומטי להתראות ספציפיות.
המלצות לניהול ריבונות הנתונים
ההמלצה הזו רלוונטית לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
ריבונות הנתונים מספקת לכם מנגנון שמונע מ-Google לגשת לנתונים שלכם. אתם מאשרים גישה רק להתנהגויות של ספקים שאתם מסכימים שהן נחוצות. לדוגמה, אתם יכולים לנהל את ריבונות הנתונים בדרכים הבאות:
- לאחסן ולנהל מפתחות הצפנה מחוץ לענן.
- לתת גישה למפתחות האלה על סמך הצדקות גישה מפורטות.
- הגנה על נתונים בשימוש באמצעות Confidential Computing.
ניהול הריבונות התפעולית
ההמלצה הזו רלוונטית לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
ריבונות תפעולית מבטיחה שעובדי Google לא יוכלו לפגוע בעומסי העבודה שלכם. לדוגמה, אתם יכולים לנהל את הריבונות התפעולית בדרכים הבאות:
- להגביל את הפריסה של משאבים חדשים לאזורים ספציפיים של ספקים.
- הגבלת הגישה של צוות Google על סמך מאפיינים מוגדרים מראש, כמו אזרחות או מיקום גיאוגרפי.
ניהול ריבונות התוכנה
ההמלצה הזו רלוונטית לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
ריבונות על תוכנה מבטיחה שתוכלו לשלוט בזמינות של עומסי העבודה שלכם ולהריץ אותם בכל מקום שתרצו. בנוסף, אתם יכולים לשלוט בנתונים בלי להיות תלויים בספק שירותי ענן אחד או להיות כבולים אליו. ריבונות תוכנה כוללת את היכולת לשרוד אירועים שבהם צריך לשנות במהירות את המקום שבו פורסים את עומסי העבודה, ואת רמת החיבור החיצוני שמותרת.
לדוגמה, כדי לעזור לכם לנהל את ריבונות התוכנה, Google Cloudתומך בפריסות היברידיות ובפריסות בכמה עננים. אם אתם בוחרים בפריסות מקומיות מסיבות שקשורות לריבונות הנתונים, Google Distributed Cloud הוא שילוב של חומרה ותוכנה שמביא את Google Cloud למרכז הנתונים שלכם.
המלצות לעמידה בדרישות בנושא פרטיות
Google Cloud כולל את אמצעי הבקרה הבאים לשמירה על הפרטיות:
- הצפנה כברירת מחדל של כל הנתונים במנוחה, במעבר ובזמן העיבוד.
- אמצעי הגנה מפני גישה של גורמים פנימיים.
- תמיכה בתקנות רבות בנושא פרטיות.
ההמלצות הבאות מתייחסות לאמצעי בקרה נוספים שאפשר להטמיע. מידע נוסף זמין במרכז המידע בנושא פרטיות.
שליטה במיקום אחסון הנתונים
ההמלצה הזו רלוונטית לתחום המיקוד הבא: פיקוח, סיכונים ותאימות בענן.
מיקום אחסון הנתונים מתאר את המיקום שבו הנתונים שלכם מאוחסנים במצב מנוחה. הדרישות לגבי מיקום אחסון הנתונים משתנות בהתאם ליעדי התכנון של המערכת, לשיקולים רגולטוריים בתחום, לחוקים במדינה, להשלכות המס ואפילו לתרבות.
כדי לשלוט במיקום אחסון הנתונים, צריך להתחיל בפעולות הבאות:
- להבין את סוג הנתונים ואת המיקום שלהם.
- בדקו אילו סיכונים קיימים לנתונים שלכם ואילו חוקים ותקנות חלים עליהם.
- אתם יכולים לקבוע איפה הנתונים שלכם יאוחסנו או לאן הם יועברו.
כדי לעזור לכם לעמוד בדרישות של מיקום אחסון הנתונים, Google Cloud מאפשר לכם לקבוע איפה הנתונים יאוחסנו, איך תתבצע הגישה אליהם ואיך הם יעובדו. אתם יכולים להשתמש בכללי מדיניות לגבי מיקום המשאבים כדי להגביל את המיקום שבו נוצרים המשאבים ואת המיקום שבו הנתונים משוכפלים בין אזורים. אתם יכולים להשתמש במאפיין המיקום של המשאב כדי לזהות איפה השירות פרוס ומי מתחזק אותו. למידע נוסף, קראו את המאמר שירותים נתמכים במיקומי משאבים.
סיווג של מידע סודי
ההמלצה הזו רלוונטית לתחום המיקוד הבא: אבטחת מידע.
אתם צריכים להגדיר אילו נתונים הם סודיים, ולוודא שהם מוגנים כמו שצריך. נתונים סודיים יכולים לכלול מספרי כרטיסי אשראי, כתובות, מספרי טלפון ופרטים אישיים מזהים (PII) אחרים. בעזרת Sensitive Data Protection, אתם יכולים להגדיר סיווגים מתאימים. אחרי זה תוכלו לתייג את הנתונים ולהמיר אותם לאסימונים לפני שתאחסנו אותם ב- Google Cloud. בנוסף, Knowledge Catalog מציע שירות קטלוג שמספק פלטפורמה לאחסון המטא-נתונים, לניהול שלהם ולגישה אליהם. למידע נוסף ולדוגמה לסיווג נתונים ולהסרת פרטים מזהים, ראו הסרת פרטים מזהים וזיהוי מחדש של פרטים אישיים מזהים באמצעות Sensitive Data Protection.
נעילת הגישה למידע אישי רגיש
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת מידע
- ניהול זהויות והרשאות גישה
להציב מידע אישי רגיש בגבולות גזרה לשירות משלו באמצעות VPC Service Controls. בעזרת VPC Service Controls אתם יכולים לצמצם את הסיכון להעתקה או להעברה לא מורשית של נתונים (זליגת נתונים) משירותים שמנוהלים על ידי Google. בעזרת VPC Service Controls אתם יכולים להגדיר מתחמי אבטחה היקפית מסביב למשאבים של השירותים שמנוהלים על ידי Google, כדי לשלוט בתנועת הנתונים במתחם. להגדיר אמצעי בקרת גישה לנתונים האלה באמצעות Google Identity and Access Management (IAM). להגדיר אימות רב-גורמי (MFA) לכל המשתמשים שצריכים גישה למידע אישי רגיש.
אחריות משותפת וגורל משותף ב- Google Cloud
במאמר הזה נסביר על ההבדלים בין מודל האחריות המשותפת לבין מודל הגורל המשותף ב- Google Cloud. הוא דן באתגרים ובניואנסים של מודל האחריות המשותפת. במאמר הזה מוסבר מהו גורל משותף ואיך אנחנו משתפים פעולה עם הלקוחות שלנו כדי להתמודד עם אתגרי האבטחה בענן.
חשוב להבין את מודל האחריות המשותפת כדי לקבוע איך הכי טוב להגן על הנתונים ועומסי העבודה שלכם ב- Google Cloud. מודל האחריות המשותפת מתאר את המשימות שלכם בכל הקשור לאבטחה בענן, ואת ההבדלים בין המשימות האלה לבין המשימות של ספקי שירותי הענן.
עם זאת, הבנת האחריות המשותפת יכולה להיות מאתגרת. כדי להשתמש במודל, צריך להבין לעומק כל שירות שאתם משתמשים בו, את אפשרויות ההגדרה שכל שירות מספק ומה Google Cloudעושה כדי לאבטח את השירות. לכל שירות יש פרופיל הגדרות שונה, ויכול להיות שיהיה קשה לקבוע מהי הגדרת האבטחה הכי טובה. אנחנו ב-Google מאמינים שמודל האחריות המשותפת לא מספיק כדי לעזור ללקוחות הענן להשיג תוצאות אבטחה טובות יותר. במקום אחריות משותפת, אנחנו מאמינים בגורל משותף.
גורל משותף כולל את הפיתוח וההפעלה של פלטפורמת ענן מהימנה לעומסי העבודה שלכם. אנחנו מספקים הנחיות לשיטות מומלצות וקוד תשתית מאובטח ומאומת, שבעזרתם תוכלו לפרוס את עומסי העבודה שלכם בצורה מאובטחת. אנחנו משיקים פתרונות שמשלבים שירותים שונים של Google Cloud כדי לפתור בעיות אבטחה מורכבות, ומציעים אפשרויות ביטוח חדשניות שיעזרו לכם למדוד ולצמצם את הסיכונים שאתם חייבים לקבל. במסגרת המודל הזה, אנחנו מקיימים איתכם אינטראקציה הדוקה יותר בזמן שאתם מאבטחים את המשאבים שלכם ב-Google Cloud.
אחריות משותפת
אתם המומחים שמכירים את דרישות האבטחה והרגולציה של העסק שלכם, ואת הדרישות להגנה על הנתונים והמשאבים הסודיים שלכם. כשמריצים את עומסי העבודה ב- Google Cloud, צריך לזהות את אמצעי האבטחה שצריך להגדיר ב- Google Cloud כדי להגן על הנתונים הסודיים ועל כל עומס עבודה. כדי להחליט אילו אמצעי אבטחה להטמיע, צריך להביא בחשבון את הגורמים הבאים:
- המחויבויות שלכם לעמידה בתקנות
- תקני האבטחה ותוכנית ניהול הסיכונים של הארגון
- דרישות האבטחה של הלקוחות והספקים שלכם
מוגדר לפי עומסי עבודה (workloads)
באופן מסורתי, תחומי האחריות מוגדרים על סמך סוג עומס העבודה שאתם מריצים ושירותי הענן שאתם צריכים. שירותי הענן כוללים את הקטגוריות הבאות:
| שירות בענן | תיאור |
|---|---|
| תשתית כשירות (IaaS) | שירותי IaaS כוללים את Compute Engine, Cloud Storage ושירותי רשת כמו Cloud VPN, Cloud Load Balancing ו-Cloud DNS.
ב-IaaS הלקוחות מקבלים שירותי מחשוב, אחסון ורשתות לפי דרישה, ומשלמים רק על מה שהם צורכים. אתם יכולים להשתמש ב-IaaS אם אתם מתכננים להעביר עומס עבודה קיים מקומית לענן באמצעות שיטת Lift-and-shift (העברה בלי שינויים), או אם אתם רוצים להריץ את האפליקציה במכונות וירטואליות מסוימות, באמצעות מסדי נתונים או הגדרות רשת ספציפיים. ב-IaaS, רוב האחריות על האבטחה היא שלכם, והאחריות שלנו מתמקדת בתשתית הבסיסית ובאבטחה הפיזית. |
| פלטפורמה כשירות (PaaS) | שירותי PaaS כוללים את App Engine, Google Kubernetes Engine (GKE) ו-BigQuery.
ב-PaaS אתם מקבלים סביבת זמן ריצה שבה אתם יכולים לפתח ולהריץ את האפליקציות שלכם. אתם יכולים להשתמש ב-PaaS אם אתם מפתחים אפליקציה (כמו אתר) ורוצים להתמקד בפיתוח ולא בתשתית הבסיסית. ב-PaaS, אנחנו אחראים על יותר אמצעי בקרה מאשר ב-IaaS. בדרך כלל, זה משתנה בהתאם לשירותים ולתכונות שבהם אתם משתמשים. אתם חולקים איתנו את האחריות המשותפת על אמצעי הבקרה ברמת האפליקציה ועל ניהול ה-IAM. אתם עדיין אחראים לאבטחת מידע ולהגנה על הלקוחות. |
| תוכנה כשירות (SaaS) | אפליקציות SaaS כוללות את Google Workspace, את Google Security Operations ואפליקציות SaaS של צד שלישי שזמינות ב-Google Cloud Marketplace.
SaaS מספק אפליקציות אונליין שאפשר להירשם אליהן או לשלם עליהן בדרך כלשהי. אתם יכולים להשתמש באפליקציות SaaS כשלארגון שלכם אין את המומחיות הפנימית או את הדרישה העסקית לבנות את האפליקציה בעצמו, אבל הוא צריך את היכולת לעבד עומסי עבודה. ב-SaaS, רוב תחומי האחריות על האבטחה הם שלנו. אתם עדיין אחראים על אמצעי בקרת הגישה ועל הנתונים שאתם בוחרים לאחסן באפליקציה. |
| פונקציה כשירות (FaaS) או בלי שרת (serverless) | FaaS מספק למפתחים פלטפורמה להרצת קוד קטן למטרה יחידה (שנקרא פונקציות) שפועל בתגובה לאירועים מסוימים. משתמשים ב-FaaS כשרוצים שדברים מסוימים יקרו על סמך אירוע מסוים. לדוגמה, אתם יכולים ליצור פונקציה שפועלת בכל פעם שנתונים מועלים ל-Cloud Storage, כדי לסווג אותם. ל-FaaS יש רשימת אחריות משותפת דומה לזו של SaaS. פונקציות Cloud Run הן אפליקציית FaaS. |
בתרשים הבא מוצגים שירותי הענן ומוגדרת חלוקת האחריות בין ספק שירותי הענן לבין הלקוח.
כפי שמוצג בתרשים, ספק שירותי הענן תמיד אחראי לרשת ולתשתית הבסיסית, והלקוחות תמיד אחראים למדיניות הגישה ולנתונים שלהם.
מוגדרת לפי התחום והמסגרת הרגולטורית
בתעשיות שונות יש מסגרות רגולטוריות שמגדירות את אמצעי הבקרה שצריך להפעיל. כשמעבירים את עומסי העבודה לענן, חשוב להבין את הדברים הבאים:
- אילו אמצעי אבטחה נמצאים באחריותכם
- אילו אמצעי אבטחה זמינים כחלק מהשירות בענן
- אילו אמצעי אבטחה מוגדרים כברירת מחדל ועוברים בירושה
אמצעי בקרה לאבטחה שעוברים בירושה (כמו הצפנת ברירת המחדל ואמצעי הבקרה לתשתית) הם אמצעי בקרה שאתם יכולים לספק למבקרים ולרגולטורים כחלק מההוכחות למצב האבטחה שלכם. לדוגמה, תקן אבטחת הנתונים המקובל בתעשיית כרטיסי תשלום (PCI DSS) מגדיר תקנות למעבדי תשלומים. כשמעבירים את העסק לענן, התקנות האלה חלות גם עליכם וגם על ספק שירותי הענן. כדי להבין איך האחריות על PCI DSS מתחלקת ביניכם לביןGoogle Cloud, קראו את המאמר Google Cloud: מטריצת האחריות המשותפת של PCI DSS.
דוגמה נוספת: בארצות הברית, חוק היבילות ואחריות הדיווח של ביטוח בריאות (HIPAA) קובע תקנים לטיפול במידע רפואי אישי (PHI) אלקטרוני. גם תחומי האחריות האלה משותפים לכם ולספק שירותי הענן. למידע נוסף על האופן שבו Google Cloud עומד באחריות שלנו במסגרת HIPAA, קראו את המאמר HIPAA – תאימות.
גם בתעשיות אחרות (למשל, פיננסים או ייצור) יש תקנות שמגדירות איך אפשר לאסוף, לעבד ולאחסן נתונים. ב-Compliance resource center מוסבר בהרחבה על האחריות המשותפת שקשורה לנושאים האלה, ואיךGoogle Cloud עומדת באחריות שלה.
מוגדר לפי מיקום
בהתאם לתרחיש העסקי, יכול להיות שתצטרכו להביא בחשבון את תחומי האחריות שלכם על סמך המיקום של משרדי העסק, הלקוחות והנתונים שלכם. במדינות ובאזורים שונים יש תקנות שונות לגבי עיבוד ואחסון של נתוני לקוחות. לדוגמה, אם לעסק שלכם יש לקוחות שמתגוררים באיחוד האירופי, יכול להיות שהעסק צריך לעמוד בדרישות שמתוארות ב-General Data Protection Regulation (התקנות הכלליות להגנה על מידע, GDPR), ויכול להיות שאתם מחויבים לשמור את נתוני הלקוחות באיחוד האירופי עצמו. במקרה כזה, אתם צריכים לוודא שהנתונים שאתם אוספים נשארים בGoogle Cloud אזורים באיחוד האירופי. למידע נוסף על האופן שבו אנחנו עומדים בהתחייבויות שלנו בנושא GDPR, קראו את המאמר GDPR ו- Google Cloud.
במאמר הצעות לשמירה על תאימות תוכלו לקרוא על הדרישות שקשורות לאזור שלכם. אם התרחיש שלכם מורכב במיוחד, מומלץ לדבר עם צוות המכירות או עם אחד מהשותפים שלנו כדי לקבל עזרה בהערכת תחומי האחריות שלכם בנושא אבטחה.
אתגרים באחריות המשותפת
למרות שהאחריות המשותפת עוזרת להגדיר את תפקידי האבטחה שלכם או של ספק שירותי הענן, ההסתמכות על אחריות משותפת עדיין יכולה ליצור אתגרים. לצורך המחשה, נבחן את התרחישים הבאים:
- הרבה פרצות אבטחה בענן הן תוצאה ישירה של הגדרה שגויה. מוצרי הענן משתנים כל הזמן, ומוצרים חדשים מושקים כל הזמן. ההתמודדות עם השינויים התכופים יכולה להיות מאתגרת. הלקוחות צריכים שספקי שירותי הענן יספקו להם שיטות מומלצות מוגדרות מראש, כדי לעזור להם לעמוד בקצב השינויים, החל משיטות מומלצות כברירת מחדל ועד להגדרת אבטחה בסיסית.
- למרות שחלוקת הפריטים לפי שירותי ענן היא שימושית, לארגונים רבים יש עומסי עבודה שדורשים כמה סוגים של שירותי ענן. במצב כזה, צריך להביא בחשבון את האינטראקציה בין אמצעי הבקרה השונים לאבטחה בשירותים האלה, כולל אם יש חפיפה בין השירותים. לדוגמה, יכול להיות שיש לכם אפליקציה מקומית שאתם מעבירים ל-Compute Engine, אתם משתמשים ב-Google Workspace לאימייל של החברה, וגם מריצים את BigQuery כדי לנתח נתונים ולשפר את המוצרים שלכם.
- העסק והשווקים שלכם משתנים כל הזמן, למשל כשהתקנות משתנות, כשאתם נכנסים לשווקים חדשים או כשאתם רוכשים חברות אחרות. יכול להיות שבשווקים החדשים יהיו דרישות שונות, ושהחברה החדשה שרכשתם מארחת את עומסי העבודה שלה בענן אחר. כדי להתמודד עם השינויים התמידיים, צריך להעריך מחדש את פרופיל הסיכון באופן קבוע ולהיות מסוגלים להטמיע אמצעי בקרה חדשים במהירות.
- ההחלטה איך ואיפה לנהל את מפתחות ההצפנה של הנתונים היא החלטה חשובה שקשורה לאחריות שלכם להגן על הנתונים. האפשרות שתבחרו תלויה בדרישות הרגולטוריות, בסביבה שבה אתם פועלים (סביבת ענן היברידית או סביבה מקומית) וברגישות של הנתונים שאתם מעבדים ומאחסנים.
- ניהול אירועים הוא תחום חשוב, שלעיתים קרובות מתעלמים ממנו, שבו לא קל להגדיר את תחומי האחריות שלכם ושל ספק שירותי הענן. במקרים רבים, כדי לחקור אירועים ולצמצם את ההשפעה שלהם, נדרש שיתוף פעולה הדוק ותמיכה מצד ספק שירותי הענן. אירועים אחרים יכולים להיגרם כתוצאה מהגדרה שגויה של משאבי ענן או מגניבת פרטי כניסה. לא תמיד קל לעמוד בשיטות המומלצות לאבטחת המשאבים והחשבונות.
- תקיפות סייבר מתמשכות (APT) ונקודות חולשה חדשות יכולות להשפיע על עומסי העבודה בדרכים שאולי לא חשבתם עליהן כשהתחלתם את המעבר לענן. קשה להתעדכן בשינויים בתחום ולדעת מי אחראי לצמצום האיומים, במיוחד אם אין בעסק צוות אבטחה גדול.
גורל משותף
פיתחנו את מודל הגורל המשותף ב- Google Cloud כדי להתחיל להתמודד עם האתגרים שמודל האחריות המשותפת לא נותן להם מענה. גורל משותף מתמקד באופן שבו כל הצדדים יכולים לקיים אינטראקציה טובה יותר כדי לשפר את האבטחה באופן רציף. מודל הגורל המשותף מתבסס על מודל האחריות המשותפת, כי הוא רואה את הקשר בין ספק שירותי הענן לבין הלקוח כשותפות מתמשכת לשיפור האבטחה.
גורל משותף הוא לקיחת אחריות על הפיכת Google Cloudלמאובטח יותר. גורל משותף כולל עזרה בהתחלת העבודה עם אזור נחיתה מאובטח, ומתן מידע ברור, מבוסס דעה ושקוף לגבי אמצעי בקרה, הגדרות ושיטות מומלצות מומלצים לאבטחה. אנחנו עוזרים לכם לכמת ולנהל את הסיכונים בצורה טובה יותר באמצעות ביטוח סייבר, במסגרת התוכנית להגנה מסיכונים. אנחנו רוצים להשתמש בגורל משותף כדי להתקדם ממודל האחריות המשותפת הרגיל למודל טוב יותר, שיעזור לכם לאבטח את העסק ולבנות אמון ב- Google Cloud.
בקטעים הבאים מתוארים רכיבים שונים של גורל משותף.
עזרה בתחילת העבודה
רכיב מרכזי בגורל המשותף הוא המשאבים שאנחנו מספקים כדי לעזור לכם להתחיל לעבוד בהגדרה מאובטחת ב- Google Cloud. התחלה עם הגדרה מאובטחת עוזרת לצמצם את הבעיה של הגדרות שגויות, שהן הגורם העיקרי לרוב פרצות האבטחה.
מקורות המידע שלנו כוללים את:
- תוכנית יסודות האבטחה לארגונים, שבה מפורטות בעיות האבטחה העיקריות וההמלצות המובילות שלנו.
תבניות מאובטחות שמאפשרות לפרוס ולתחזק פתרונות מאובטחים באמצעות תשתית כקוד (IaC). ההמלצות שלנו בנושא אבטחה מופעלות כברירת מחדל בתבניות. הרבה מהתבניות נוצרות על ידי צוותי האבטחה של Google ומנוהלות כמוצרים. התמיכה הזו כוללת עדכונים שוטפים, תהליך בדיקה קפדני ואישורים מקבוצות בדיקה של צד שלישי. התוכניות כוללות את התוכנית ליסודות הארגון ואת התוכנית למחסן נתונים מאובטח.
המלצות של Google Cloud Well-Architected Framework להטמעת אבטחה בתכנונים שלכם.
מדריכים לניווט באזורי נחיתה, שמפרטים את ההחלטות החשובות ביותר שצריך לקבל כדי לבנות בסיס מאובטח לעומסי העבודה, כולל היררכיית משאבים, הוספת זהויות, אבטחה וניהול מפתחות ומבנה הרשת.
התוכנית להגנה מסיכונים
גורל משותף כולל גם את התוכנית להגנה מסיכונים, שעוזרת לכם להשתמש בכוח של Google Cloud כפלטפורמה לניהול סיכונים, במקום לראות בעומסי העבודה בענן רק עוד מקור לסיכון שצריך לנהל. התוכנית להגנה מסיכונים היא שיתוף פעולה בין Google Cloud לבין שתי חברות מובילות בתחום ביטוח הסייבר: Munich Re ו-Allianz Global & Corporate Speciality.
התוכנית להגנה מסיכונים כוללת את Cyber Insurance Hub, שמספק תובנות שמבוססות על נתונים. אתם יכולים להשתמש בתובנות האלה כדי להבין טוב יותר את מצב האבטחה שלכם בענן. אם אתם מחפשים כיסוי ביטוחי לסייבר, אתם יכולים לשתף את התובנות האלה מ-Cyber Insurance Hub ישירות עם חברות הביטוח השותפות שלנו כדי לקבל הצעת מחיר.
עזרה בפריסה ובפיקוח
גורל משותף עוזר גם בניהול השוטף של הסביבה שלכם. לדוגמה, אנחנו מתמקדים במוצרים כמו:
- Assured Workloads, שעוזר לכם לעמוד בדרישות התאימות.
- Security Command Center Premium, שמשתמש במודיעין איומי סייבר, בזיהוי איומים, בסריקת אינטרנט ובשיטות מתקדמות אחרות כדי לעקוב אחרי איומים ולזהות אותם. הוא גם מספק דרך לפתור הרבה מהאיומים האלה במהירות ובאופן אוטומטי.
- כללי מדיניות של הארגון והגדרות של משאבים, שמאפשרים להגדיר כללי מדיניות בכל היררכיית התיקיות והפרויקטים.
- כלים לבקרת מדיניות שנותנים לכם תובנות לגבי הגישה לחשבונות ולמשאבים.
- Confidential Computing, שמאפשר להצפין נתונים בשימוש.
- Sovereign Controls by Partners, שזמין במדינות מסוימות ועוזר לאכוף את הדרישות לגבי מיקום אחסון הנתונים.
יישום בפועל של אחריות משותפת וגורל משותף
כחלק מתהליך התכנון, כדאי לבצע את הפעולות הבאות כדי להבין ולהטמיע אמצעי אבטחה מתאימים:
- צרו רשימה של סוגי עומסי העבודה שתארחו ב-Google Cloud, וציינו אם הם דורשים שירותי IaaS, PaaS ו-SaaS. אתם יכולים להשתמש בתרשים האחריות המשותפת כרשימת משימות, כדי לוודא שאתם מכירים את אמצעי הבקרה לאבטחה שצריך להביא בחשבון.
- צרו רשימה של דרישות רגולטוריות שאתם צריכים לעמוד בהן, וגשו למשאבים שקשורים לדרישות האלה בCompliance resource center.
- ב-מרכז הארכיטקטורה תוכלו לעיין ברשימה של תוכניות וארכיטקטורות זמינות, כדי לבחור את אמצעי בקרת האבטחה שאתם צריכים לעומסי העבודה הספציפיים שלכם. התבניות מספקות רשימה של אמצעי בקרה מומלצים וקוד IaC שנדרש כדי לפרוס את הארכיטקטורה הזו.
- כדי לתכנן היררכיית משאבים וארכיטקטורת רשת שעומדות בדרישות שלכם, השתמשו במסמכי התיעוד של אזור הנחיתה ובהמלצות שבמדריך ליסודות של Google Cloud לארגונים. כדי להאיץ את תהליך הפיתוח, אתם יכולים להשתמש בתבניות המומלצות של עומסי עבודה, כמו מחסן נתונים מאובטח.
- אחרי שפורסים את עומסי העבודה, צריך לוודא שאתם עומדים באחריות שלכם בנושא אבטחה באמצעות שירותים כמו Cyber Insurance Hub, Assured Workloads, כלים לבקרת מדיניות ו-Security Command Center Premium.
מידע נוסף זמין במאמר המדריך של CISO לטרנספורמציה בענן.
המאמרים הבאים
- עקרונות האבטחה העיקריים
- כדאי להכיר את התוכניות הזמינות, כולל התוכנית לניהול יסודות האבטחה ודוגמאות לעומסי עבודה כמו מחסן הנתונים המאובטח.
- מידע נוסף על גורל משותף
- במאמר סקירה כללית על תכנון האבטחה בתשתית של Google תוכלו לקרוא על התשתית המאובטחת שלנו.
- בודקים את Google Cloud אמצעי הבקרה שתואמים לדרישות של NIST Cybersecurity Framework.