ההמלצות שמופיעות בעמודה 'אבטחה, פרטיות ועמידה בדרישות' בGoogle Cloud מסגרת Well-Architected Framework יעזרו לכם לתכנן, לפרוס ולהפעיל בענן עומסי עבודה שעומדים בדרישות שלכם בנוגע לאבטחה, לפרטיות ולעמידה בדרישות.
המסמך הזה נועד לספק תובנות חשובות ולענות על הצרכים של מגוון אנשי מקצוע ומהנדסים בתחום האבטחה. בטבלה הבאה מתוארים הקהלים שאליהם מיועד המסמך הזה:
| קהל | מה כולל המסמך הזה |
|---|---|
| מנהלי אבטחת מידע (CISO), מנהלי יחידות עסקיות ומנהלי IT | מסגרת כללית להקמה ולתחזוקה של אבטחה מצוינת בענן, ולוודא שיש תמונה מקיפה של תחומים באבטחה כדי לקבל החלטות מושכלות לגבי השקעות באבטחה. |
| אדריכלים ומהנדסים בתחום האבטחה | שיטות אבטחה חשובות לשלבי התכנון וההפעלה, שיעזרו לכם לוודא שהפתרונות מתוכננים לאבטחה, ליעילות ולגמישות. |
| צוותי DevSecOps | הנחיות לשילוב אמצעי בקרה כוללים לאבטחה, כדי לתכנן אוטומציה שתאפשר תשתית מאובטחת ומהימנה. |
| קציני תאימות ומנהלי סיכונים | המלצות חשובות בנושא אבטחה שיעזרו לכם לנהל את הסיכונים בצורה מסודרת ולעמוד בדרישות התאימות. |
כדי לוודא שעומסי העבודה שלכם עומדים בדרישות האבטחה, הפרטיות והתאימות, כל בעלי העניין בארגון צריכים לאמץ גישה שיתופית. Google Cloud בנוסף, חשוב להבין שאבטחת הענן היא אחריות משותפת שלכם ושל Google. מידע נוסף זמין במאמר בנושא חלוקת אחריות וגורל משותף ב- Google Cloud.
ההמלצות בעמודה הזו מקובצות לפי עקרונות אבטחה מרכזיים. כל המלצה שמבוססת על עקרון ממופה לאחד או יותר מתחומי ההתמקדות באבטחת הענן, שעשויים להיות קריטיים לארגון שלכם. כל המלצה כוללת הנחיות לגבי השימוש בGoogle Cloud מוצרים וביכולות וההגדרה שלהם, כדי לשפר את מצב האבטחה של הארגון.
עקרונות ליבה
ההמלצות בקטגוריה הזו מקובצות לפי עקרונות הליבה הבאים של אבטחה. כל עיקרון בעמודה הזו חשוב. בהתאם לדרישות של הארגון ועומס העבודה, יכול להיות שתבחרו לתת עדיפות לעקרונות מסוימים.
- הטמעת אבטחה כבר בשלב התכנון: שילוב שיקולי אבטחת ענן ואבטחת רשת כבר בשלב התכנון הראשוני של האפליקציות והתשתית.Google Cloud מספקת תוכניות אדריכליות והמלצות שיעזרו לכם ליישם את העיקרון הזה.
- הטמעה של מודל אבטחה של אפס אמון: שימוש בגישה של לא לסמוך, תמיד לאמת, שבה הגישה למשאבים ניתנת על סמך אימות רציף של האמון. Google CloudGoogle תומכת בעיקרון הזה באמצעות מוצרים כמו Chrome Enterprise Premium ו-שרת proxy לאימות זהויות (IAP).
- הטמעת אבטחה מוקדמת (shift-left): הטמעת אמצעי בקרה לאבטחה בשלב מוקדם במחזור החיים של פיתוח התוכנה. למנוע פגמים באבטחה לפני ביצוע שינויים במערכת. זיהוי ותיקון של באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן אחרי שהשינויים במערכת נשמרים. Google Cloud תומכת בעיקרון הזה באמצעות מוצרים כמו Cloud Build, Binary Authorization ו-Artifact Registry.
- יישום הגנת סייבר מקדימה: אימוץ גישה פרואקטיבית לאבטחה באמצעות יישום אמצעים בסיסיים חזקים כמו מודיעין איומי סייבר. הגישה הזו עוזרת לבנות בסיס לזיהוי איומים ולתגובה יעילים יותר.Google Cloud's approach to layered security controls תואמת לעיקרון הזה.
- שימוש מאובטח ואחראי ב-AI: פיתוח ופריסה של מערכות AI באופן אחראי ומאובטח. ההמלצות שקשורות לעיקרון הזה תואמות להנחיות שמופיעות בפרספקטיבה של AI ולמידת מכונה ב-Well-Architected Framework וב-Secure AI Framework (SAIF) של Google.
- שימוש ב-AI לאבטחה: שימוש ביכולות AI כדי לשפר את מערכות ותהליכי האבטחה הקיימים באמצעות Gemini in Security ויכולות אבטחה כלליות של הפלטפורמה. שימוש ב-AI ככלי להגברת האוטומציה של עבודת התיקון ולהבטחת היגיינת אבטחה כדי לשפר את האבטחה של מערכות אחרות.
- עמידה בדרישות רגולטוריות, בדרישות תאימות ובדרישות פרטיות: אנחנו פועלים בהתאם לתקנות ספציפיות לתעשייה, לתקני תאימות ולדרישות פרטיות. Google Cloud אנחנו עוזרים לכם לעמוד בהתחייבויות האלה באמצעות מוצרים כמו Assured Workloads, Organization Policy Service וCompliance resource center.
גישה לאבטחה בארגון
מנטליות ארגונית שמתמקדת באבטחה היא חיונית להטמעה ולהפעלה מוצלחות של ענן. הגישה הזו צריכה להיות מושרשת עמוק בתרבות הארגונית שלכם, ולבוא לידי ביטוי בשיטות העבודה שלכם, שמבוססות על עקרונות ליבה של אבטחה כפי שמתואר בהמשך.
התפיסה הארגונית של אבטחה מדגישה את החשיבות של חשיבה על אבטחה במהלך תכנון המערכת, אימוץ מודל אבטחה של אפס אמון ושילוב אמצעי אבטחה לאורך תהליך הפיתוח. במסגרת התפיסה הזו, חשוב גם לחשוב באופן יזום על הגנת סייבר, להשתמש ב-AI באופן מאובטח ולמטרות אבטחה, ולשקול את הדרישות הרגולטוריות, הפרטיות והתאימות. על ידי אימוץ העקרונות האלה, הארגון יכול לפתח תרבות של אבטחה קודמת לכל, שנותנת מענה יזום לאיומים, מגנה על נכסים חשובים ועוזרת להבטיח שימוש אחראי בטכנולוגיה.
תחומי התמקדות באבטחת ענן
בקטע הזה מתוארים התחומים שבהם צריך להתמקד כשמתכננים, מטמיעים ומנהלים את האבטחה של האפליקציות, המערכות והנתונים. ההמלצות בכל עקרון של עמוד התווך הזה רלוונטיות לאחד או יותר מהתחומים האלה. בהמשך המסמך, ההמלצות כוללות את תחומי ההתמקדות הרלוונטיים באבטחה, כדי לספק בהירות והקשר נוספים.
| אזור ההתמקדות | פעילויות ורכיבים | מוצרים, יכולות ופתרונות Google Cloud קשורים |
|---|---|---|
| אבטחת התשתית |
|
|
| ניהול זהויות והרשאות גישה |
|
|
| אבטחת מידע |
|
|
| אבטחת AI ו-ML |
|
|
| תפעול אבטחה (SecOps) |
|
|
| אבטחת אפליקציות |
|
|
| משילות, סיכונים ותאימות בענן |
|
|
| רישום ביומן, ביקורת ומעקב |
|
שותפים ביצירת התוכן
מחברים:
- Wade Holmes | Global Solutions Director
- Hector Diaz | Cloud Security Architect
- Carlos Leonardo Rosario | Google Cloud Security Specialist
- John Bacon | Partner Solutions Architect
- Sachin Kalra | Global Security Solution Manager
תורמי תוכן אחרים:
- Anton Chuvakin | Security Advisor, Office of the CISO
- Daniel Lees | Cloud Security Architect
- Filipe Gracio, PhD | Customer Engineer, AI/ML Specialist
- גארי הרמסון (Gary Harmson) | אדריכל ראשי
- Gino Pelliccia | Principal Architect
- Jose Andrade | Customer Engineer, SRE Specialist
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Laura Hyatt | Customer Engineer, FSI
- Marwan Al Shawi | Partner Customer Engineer
- ניקולא פינטו (Nicolas Pintaux) | Customer Engineer, Application Modernization Specialist
- נואה מקדונלד | יועץ אבטחת ענן
- Osvaldo Costa | Networking Specialist Customer Engineer
- רדיקה קנאקאם | מובילת התוכנית, Google Cloud Well-Architected Framework
- Samantha He | Technical Writer
- Susan Wu | Outbound Product Manager
הטמעה של אבטחה משלב התכנון
העיקרון הזה, שמופיע בעמודת האבטחה של Google Cloud Well-Architected Framework, כולל המלצות לשילוב של תכונות אבטחה חזקות, אמצעי בקרה ושיטות עבודה בעיצוב של אפליקציות, שירותים ופלטפורמות בענן. האבטחה יעילה יותר כשהיא משולבת כחלק בלתי נפרד מכל שלב בתהליך התכנון, החל משלב יצירת הרעיון ועד לשלב התפעול.
סקירה כללית של העקרונות
כפי שמוסבר במאמר סקירה כללית על המחויבות של Google לאבטחה מובנית, המונחים אבטחה מובנית ואבטחה כברירת מחדל משמשים לעיתים קרובות לסירוגין, אבל הם מייצגים גישות שונות לבניית מערכות מאובטחות. שתי הגישות נועדו לצמצם את נקודות החולשה ולשפר את האבטחה, אבל הן שונות בהיקף ובאופן ההטמעה:
- מאובטח כברירת מחדל: מתמקד בהבטחה שברירות המחדל של המערכת מוגדרות למצב מאובטח, וכך מצמצם את הצורך של משתמשים או אדמינים לבצע פעולות כדי לאבטח את המערכת. המטרה של הגישה הזו היא לספק רמת אבטחה בסיסית לכל המשתמשים.
- מאובטח משלב התכנון (secure-by-design): גישה שבה משלבים באופן פרואקטיבי שיקולי אבטחה לאורך מחזור החיים של פיתוח המערכת. הגישה הזו מתמקדת בזיהוי מוקדם של איומים ונקודות חולשה פוטנציאליים, ובביצוע בחירות עיצוביות שמצמצמות את הסיכונים. הגישה הזו כוללת שימוש בשיטות קידוד מאובטחות, ביצוע בדיקות אבטחה ושילוב אבטחה בתהליך העיצוב. הגישה של מאובטח משלב התכנון היא פילוסופיה כוללת שמנחה את תהליך הפיתוח ועוזרת להבטיח שהאבטחה לא תהיה מחשבה משנית, אלא חלק בלתי נפרד מהעיצוב של המערכת.
המלצות
כדי להטמיע את העיקרון 'אבטחה מובנית' בעומסי העבודה בענן, כדאי לעיין בהמלצות שבקטעים הבאים:
- בחירת רכיבי מערכת שיעזרו לאבטח את עומסי העבודה
- בניית גישה רב-שכבתית לאבטחה
- שימוש בתשתית ובשירותים מאובטחים ומאומתים
- הצפנה של נתונים באחסון ובתנועה
בחירת רכיבי מערכת שיעזרו לאבטח את עומסי העבודה
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
החלטה בסיסית לאבטחה יעילה היא בחירה של רכיבי מערכת חזקים – כולל רכיבי חומרה ותוכנה – שמרכיבים את הפלטפורמה, הפתרון או השירות שלכם. כדי לצמצם את פני השטח של התקפות אבטחה ולהגביל את הנזק הפוטנציאלי, אתם צריכים גם לשקול בקפידה את דפוסי הפריסה של הרכיבים האלה ואת ההגדרות שלהם.
כדי למנוע סוגים שונים של נקודות חולשה, מומלץ להשתמש בספריות, בהפשטות ובמסגרות של אפליקציות שהן פשוטות, בטוחות ואמינות בקוד אפליקציה. כדי לסרוק נקודות חולשה בספריות תוכנה, אפשר להשתמש בכלים של צד שלישי. אפשר גם להשתמש ב-Assured Open Source Software, שמאפשר לצמצם את הסיכונים בשרשרת אספקת התוכנה באמצעות חבילות של תוכנות קוד פתוח (OSS) ש-Google משתמשת בהן ומאבטחת אותן.
התשתית שלכם צריכה להשתמש באפשרויות של רשת, אחסון ומחשוב שתומכות בפעולה בטוחה, ותואמות לדרישות האבטחה ולרמות הסיכון המקובלות. אבטחת התשתית חשובה גם לעומסי עבודה שפונים לאינטרנט וגם לעומסי עבודה פנימיים.
מידע על פתרונות אחרים של Google שתומכים בהמלצה הזו זמין במאמר הטמעה של אבטחה מוקדמת.
פיתוח גישה רב-שכבתית לאבטחה
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- אבטחת AI ו-ML
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
מומלץ להטמיע אבטחה בכל שכבה של ערימת האפליקציות והתשתית באמצעות גישה של הגנה לעומק.
משתמשים בתכונות האבטחה בכל רכיב בפלטפורמה. כדי להגביל את הגישה ולזהות את גבולות ההשפעה הפוטנציאלית (כלומר, רדיוס ההשפעה) במקרה של אירוע אבטחה, צריך לבצע את הפעולות הבאות:
- כדאי לפשט את עיצוב המערכת כדי לאפשר גמישות ככל האפשר.
- מתעדים את דרישות האבטחה של כל רכיב.
- לשלב מנגנון מאובטח וחזק כדי לעמוד בדרישות של עמידות ושחזור.
כשמתכננים את שכבות האבטחה, כדאי לבצע הערכת סיכונים כדי לקבוע אילו תכונות אבטחה נדרשות כדי לעמוד בדרישות אבטחה פנימיות ודרישות רגולטוריות חיצוניות. מומלץ להשתמש במסגרת להערכת סיכונים לפי תקן התעשייה שרלוונטית לדרישות הרגולטוריות שלכם ומתאימה לסביבות ענן. לדוגמה, Cloud Security Alliance (CSA) מספקת את Cloud Controls Matrix (CCM). הערכת הסיכונים מספקת קטלוג של סיכונים ואמצעי בקרה תואמים לאבטחה כדי לצמצם אותם.
כשמבצעים הערכת סיכונים, חשוב לזכור שיש לכם הסכם אחריות משותפת עם ספק שירותי הענן. לכן, הסיכונים בסביבת ענן שונים מהסיכונים בסביבה מקומית. לדוגמה, בסביבה מקומית, אתם צריכים לצמצם את נקודות החולשה במערך החומרה. לעומת זאת, בסביבת ענן, ספק שירותי הענן נושא בסיכונים האלה. בנוסף, חשוב לזכור שהגבולות של האחריות המשותפת שונים בין שירותי IaaS, PaaS ו-SaaS עבור כל ספק שירותי ענן.
אחרי שמזהים סיכונים פוטנציאליים, צריך לתכנן וליצור תוכנית לצמצום הסיכונים, שכוללת אמצעי בקרה טכניים, ניהוליים ותפעוליים, וגם הגנות חוזיות ואישורים של צד שלישי. בנוסף, שיטה למידול איומים, כמו שיטת OWASP למידול איומים באפליקציות, עוזרת לזהות פערים פוטנציאליים ומציעה פעולות לטיפול בפערים.
שימוש בתשתית ובשירותים מוקשחים ומאומתים
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
תוכנית אבטחה מפותחת מפחיתה את הסיכון לנקודות חולשה חדשות, כפי שמתואר בחדשות האבטחה. בנוסף, תוכנית האבטחה צריכה לספק פתרונות לתיקון פרצות באבטחה בפריסות קיימות ולאבטח את מכונות ה-VM ואת תמונות הקונטיינרים. אתם יכולים להשתמש במדריכים לחיזוק האבטחה שספציפיים למערכת ההפעלה וליישום של התמונות שלכם, וגם באמות מידה כמו זו שמסופקת על ידי Center of Internet Security (CIS).
אם אתם משתמשים בתמונות מותאמות אישית למכונות ה-VM שלכם ב-Compute Engine, אתם צריכים לתקן את התמונות בעצמכם. אפשרות אחרת היא להשתמש בתמונות של מערכת הפעלה שנאספו על ידי Google, שמתעדכנות באופן קבוע. כדי להריץ קונטיינרים במכונות וירטואליות של Compute Engine, צריך להשתמש בקובצי אימג' של מערכת הפעלה שמותאמת לקונטיינרים שאצרה Google. Google מתקנת ומעדכנת את התמונות האלה באופן קבוע.
אם אתם משתמשים ב-GKE, מומלץ להפעיל שדרוגים אוטומטיים של צמתים כדי ש-Google תעדכן את הצמתים של האשכול עם התיקונים האחרונים. Google מנהלת את מישורי הבקרה של GKE, שמתעדכנים ומתוקנים באופן אוטומטי. כדי לצמצם עוד יותר את שטח הפנים להתקפה של הקונטיינרים, אפשר להשתמש בתמונות ללא הפצה. תמונות ללא הפצה הן אידיאליות לאפליקציות רגישות לאבטחה, למיקרו-שירותים ולמצבים שבהם חשוב לצמצם את גודל התמונה ואת שטח הפנים של המתקפה.
לעומסי עבודה רגישים, מומלץ להשתמש ב-Shielded VM, שמונעת טעינה של קוד זדוני במהלך מחזור האתחול של המכונה הווירטואלית. מכונות וירטואליות מוגנות מספקות אבטחת אתחול, מנטרות את התקינות ומשתמשות ב-Virtual Trusted Platform Module (vTPM).
כדי לאבטח את הגישה ל-SSH, אתם יכולים להשתמש ב-OS Login. כך העובדים יוכלו להתחבר למכונות הווירטואליות באמצעות הרשאות של ניהול זהויות וגישה (IAM) כמקור האמת, במקום להסתמך על מפתחות SSH. לכן, לא תצטרכו לנהל מפתחות SSH בכל הארגון. OS Login מקשר את הגישה של האדמין למחזור החיים של העובד, כך שכאשר עובדים משנים תפקידים או עוזבים את הארגון, הגישה שלהם מבוטלת יחד עם החשבון שלהם. OS Login תומך גם באימות דו-שלבי של Google, שמוסיף שכבת אבטחה נוספת מפני מתקפות השתלטות על חשבונות.
ב-GKE, מופעים של אפליקציות פועלים בתוך קונטיינרים של Docker. כדי להפעיל פרופיל סיכון מוגדר ולהגביל את העובדים כך שלא יוכלו לבצע שינויים בקונטיינרים, צריך לוודא שהקונטיינרים הם חסרי מצב ובלתי ניתנים לשינוי. העיקרון של חוסר שינוי אומר שהעובדים לא משנים את הקונטיינר ולא ניגשים אליו באופן אינטראקטיבי. אם צריך לשנות את הקונטיינר, יוצרים תמונה חדשה ומבצעים פריסה מחדש של התמונה הזו. מפעילים גישת SSH לקונטיינרים הבסיסיים רק בתרחישי ניפוי באגים ספציפיים.
כדי לאבטח את ההגדרות בסביבה שלכם באופן גלובלי, אתם יכולים להשתמש במדיניות הארגון כדי להגדיר אילוצים או אמצעי הגנה על משאבים שמשפיעים על ההתנהגות של נכסי הענן שלכם. לדוגמה, אתם יכולים להגדיר את מדיניות הארגון הבאה ולהחיל אותה באופן גלובלי על Google Cloud הארגון או באופן סלקטיבי ברמת התיקייה או הפרויקט:
- משביתים את ההקצאה של כתובות IP חיצוניות למכונות וירטואליות.
- הגבלת יצירת משאבים למיקומים גיאוגרפיים ספציפיים.
- השבתה של יצירת חשבונות שירות או המפתחות שלהם.
הצפנת נתונים באחסון ובתנועה
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- אבטחת התשתית
- אבטחת מידע
הצפנת נתונים היא אמצעי בקרה בסיסי להגנה על מידע רגיש, והיא חלק מרכזי במשילות מידע. אסטרטגיה יעילה להגנה על נתונים כוללת בקרת גישה, פילוח נתונים ומיקום גיאוגרפי, ביקורת, והטמעה של הצפנה שמבוססת על הערכה מדוקדקת של הדרישות.
כברירת מחדל, 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. כל התנועה בין מכונות וירטואליות ברשת VPC ובין רשתות VPC מקושרות מוצפנת. אפשר להשתמש ב-MACsec להצפנת תנועה בחיבורי Cloud Interconnect. IPsec מספק הצפנה לתנועה בחיבורי Cloud VPN. אפשר להגן על תנועה בין אפליקציות בענן באמצעות תכונות אבטחה כמו הגדרות TLS ו-mTLS ב-Apigee ו-Cloud Service Mesh לאפליקציות מבוססות-קונטיינרים.
כברירת מחדל, Google Cloud מצפין נתונים באחסון ונתונים במעבר ברשת. עם זאת, הנתונים לא מוצפנים כברירת מחדל בזמן השימוש בהם בזיכרון. אם הארגון שלכם מטפל בנתונים סודיים, אתם צריכים לצמצם איומים שפוגעים בסודיות ובתקינות של האפליקציה או של הנתונים בזיכרון המערכת. כדי לצמצם את האיומים האלה, אתם יכולים להשתמש ב-Confidential Computing, שמספקת סביבת מחשוב אמינה לעומסי העבודה שלכם. מידע נוסף זמין במאמר סקירה כללית על Confidential VMs.
הטמעה של מודל אבטחה של אפס אמון
העיקרון הזה, שנכלל בעמודת האבטחה של Google Cloud Well-Architected Framework, עוזר לכם להבטיח אבטחה מקיפה בעומסי העבודה בענן. העיקרון של מודל אבטחה של אפס אמון מדגיש את השיטות הבאות:
- ביטול הרשאות שיתוף משתמעות
- החלת העיקרון של הרשאות מינימליות על בקרת גישה
- אכיפה של אימות מפורש של כל בקשות הגישה
- אימוץ גישה של הנחה של פריצה כדי לאפשר אימות רציף ומעקב אחרי מצב האבטחה
סקירה כללית של העקרונות
במודל אפס אמון, המיקוד באבטחה עובר מאבטחה היקפית לגישה שבה אף משתמש או מכשיר לא נחשבים מהימנים באופן מובנה. במקום זאת, כל בקשת גישה חייבת לעבור אימות, ללא קשר למקור שלה. הגישה הזו כוללת אימות והרשאה של כל משתמש ומכשיר, אימות ההקשר שלהם (מיקום ומצב המכשיר) והענקת הרשאות מינימליות לגישה רק למשאבים הדרושים.
יישום מודל אבטחה של אפס אמון עוזר לארגון לשפר את מצב האבטחה שלו על ידי צמצום ההשפעה של פרצות פוטנציאליות והגנה על מידע אישי רגיש ועל אפליקציות מפני גישה לא מורשית. מודל אפס-אמון עוזר להבטיח את הסודיות, השלמות והזמינות של נתונים ומשאבים בענן.
המלצות
כדי ליישם את מודל אפס-האמון בעומסי העבודה בענן, כדאי לעיין בהמלצות שבקטעים הבאים:
אבטחת הרשת
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת תשתית.
כדי לעבור מאבטחה היקפית מסורתית למודל של אפס אמון, צריך לבצע כמה שלבים. יכול להיות שהארגון שלכם כבר שילב אמצעי בקרה מסוימים של אפס אמון במצב האבטחה שלו. עם זאת, מודל של אפס אמון הוא לא מוצר או פתרון יחיד. במקום זאת, מדובר בשילוב הוליסטי של כמה שכבות אבטחה ושיטות מומלצות. בקטע הזה מתוארות המלצות וטכניקות להטמעה של מודל אבטחה של אפס אמון באבטחת רשת.
- בקרת גישה: אפשר לאכוף בקרות גישה על סמך זהות המשתמש וההקשר שלו באמצעות פתרונות כמו Chrome Enterprise Premium ושרת proxy לאימות זהויות (IAP). כך האבטחה עוברת מהרשת ההיקפית למשתמשים ולמכשירים בודדים. הגישה הזו מאפשרת בקרת גישה פרטנית ומצמצמת את שטח הפנים של המתקפה.
- אבטחת רשת: חיבורי רשת מאובטחים בין סביבות מקומיות, Google Cloudוסביבות מרובות עננים.
- להשתמש בשיטות לקישוריות פרטית מ-Cloud Interconnect ומ-IPsec VPN.
- כדי לאבטח את הגישה ל Google Cloud שירותים ולממשקי API, אפשר להשתמש ב-Private Service Connect.
- כדי לאבטח את הגישה היוצאת מעומסי עבודה שנפרסו ב-Google Kubernetes Engine (GKE) ובמוצרים קשורים, אפשר להשתמש בשערי יציאה של Cloud Service Mesh.
- תכנון הרשת: כדי למנוע סיכוני אבטחה פוטנציאליים, מומלץ למחוק רשתות שמוגדרות כברירת מחדל בפרויקטים קיימים ולהשבית את האפשרות ליצור רשתות שמוגדרות כברירת מחדל בפרויקטים חדשים.
- כדי להימנע מהתנגשויות, חשוב לתכנן בקפידה את הרשת ואת הקצאת כתובות ה-IP.
- כדי לאכוף בקרת גישה יעילה, כדאי להגביל את מספר הרשתות של הענן הווירטואלי הפרטי (VPC) בכל פרויקט.
- סגמנטציה: בידוד עומסי עבודה תוך שמירה על ניהול רשת מרכזי.
- כדי לפלח את הרשת, משתמשים ב-VPC משותף.
- הגדרת מדיניות וכללים של חומת אש ברמת הארגון, התיקייה ורשת ה-VPC.
- כדי למנוע זליגת נתונים, מומלץ להגדיר מתחמי אבטחה מסביב למידע אישי רגיש ולשירותים באמצעות VPC Service Controls.
- אבטחת היקף: הגנה מפני התקפות DDoS ואיומים על אפליקציות אינטרנט.
- כדי להגן על עצמכם מפני איומים, מומלץ להשתמש ב-Google Cloud Armor.
- הגדרת מדיניות אבטחה שמאפשרת, דוחה או מפנה תנועה ב-Google Cloud edge.
- אוטומציה: כדי לבצע אוטומציה של הקצאת משאבי תשתית, כדאי להשתמש בעקרונות של תשתית כקוד (IaC) ובכלים כמו Terraform, Jenkins ו-Cloud Build. תשתית כקוד עוזרת להבטיח הגדרות אבטחה עקביות, פריסות פשוטות וחזרה מהירה לגרסה קודמת במקרה של בעיות.
- תשתית מאובטחת: כדי ליצור סביבת אפליקציות מאובטחת, משתמשים בתוכנית הבסיס של Enterprise Foundations. התוכנית הזו מספקת הנחיות מפורטות וסקריפטים לאוטומציה שיעזרו לכם להטמיע שיטות מומלצות לאבטחה ולהגדיר את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 תומך בשיטות שונות של MFA, כולל מפתחות אבטחה Titan, כדי לשפר את האבטחה.
- לאימות עומסי עבודה, משתמשים ב-OAuth 2.0 או באסימוני JWT (JSON Web Tokens) חתומים.
- הרשאות מינימליות: כדי לצמצם את הסיכון לגישה לא מורשית ולפרצות אבטחה בנתונים, חשוב לאכוף את העקרונות של הרשאות מינימליות והפרדה בין תפקידים.
- חשוב להימנע מהקצאת הרשאות גישה למשתמשים שלא צריכים אותן.
- כדאי להטמיע גישה מורשית בדיוק בזמן לפעולות רגישות.
- רישום ביומן: הפעלת רישום ביומן ביקורת של פעילויות של אדמינים ושל גישה לנתונים.
- כדי לנתח את היומנים ולזהות איומים, אפשר לסרוק אותם באמצעות Security Command Center Enterprise או Google Security Operations.
- הגדרת מדיניות מתאימה לשמירת יומנים כדי לאזן בין צורכי האבטחה לבין עלויות האחסון.
מעקב ותחזוקה של הרשת
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- רישום ביומן, ביקורת ומעקב
- אבטחת אפליקציות
- תפעול אבטחה (SecOps)
- אבטחת התשתית
כשמתכננים ומיישמים אמצעי אבטחה, צריך להניח שתוקף כבר נמצא בתוך הסביבה שלכם. הגישה הפרואקטיבית הזו כוללת שימוש בכמה כלים וטכניקות כדי לספק תובנות לגבי הרשת שלכם:
רישום ביומן ומעקב באופן מרוכז: איסוף וניתוח של יומני אבטחה מכל משאבי הענן באמצעות רישום ביומן ומעקב באופן מרוכז.
- להגדיר ערכי בסיס להתנהגות רגילה ברשת, לזהות אנומליות ולאתר איומים פוטנציאליים.
- ניתוח רציף של זרימות תעבורת הרשת כדי לזהות דפוסים חשודים והתקפות פוטנציאליות.
תובנות לגבי הביצועים והאבטחה של הרשת: אפשר להשתמש בכלים כמו Network Analyzer כדי לעקוב אחרי התנועה ברשת ולזהות פרוטוקולים חריגים, חיבורים לא צפויים או עליות פתאומיות בהעברת הנתונים, שיכולים להעיד על פעילות זדונית.
סריקה של נקודות חולשה ותיקון שלהן: חשוב לסרוק את הרשת והאפליקציות באופן קבוע כדי לאתר נקודות חולשה.
- אפשר להשתמש ב-Web Security Scanner, שמזהה באופן אוטומטי נקודות חולשה במופעי Compute Engine, במאגרי מידע ובאשכולות GKE.
- כדאי לתת עדיפות לתיקון בהתאם לחומרת נקודות החולשה ולהשפעה הפוטנציאלית שלהן על המערכות.
גילוי חדירות: מעקב אחרי תעבורת נתונים ברשת כדי לזהות פעילות זדונית וחסימה אוטומטית של אירועים חשודים, או קבלת התראות על אירועים כאלה באמצעות Cloud IDS ושירות מניעת החדירות Cloud NGFW.
ניתוח אבטחה: מומלץ להטמיע את Google SecOps כדי ליצור קורלציה בין אירועי אבטחה ממקורות שונים, לספק ניתוח בזמן אמת של התראות אבטחה ולסייע בתגובה לאירועים.
הגדרות עקביות: כדי לוודא שיש לכם הגדרות אבטחה עקביות ברשת, כדאי להשתמש בכלים לניהול הגדרות.
הטמעה של אבטחה מוקדמת
העיקרון הזה, שמופיע בעמודת האבטחה של Google Cloud Well-Architected Framework, עוזר לכם לזהות אמצעי בקרה מעשיים שתוכלו להטמיע בשלב מוקדם במחזור החיים של פיתוח התוכנה כדי לשפר את רמת האבטחה. הוא מספק המלצות שיעזרו לכם להטמיע אמצעי הגנה מונעים ואמצעי בקרה לאבטחה אחרי הפריסה.
סקירה כללית של העקרונות
אבטחה מוקדמת (Shift-left security) היא אימוץ של שיטות אבטחה בשלב מוקדם במחזור החיים של פיתוח התוכנה. העיקרון הזה נועד להשיג את המטרות הבאות:
- למנוע פגמים באבטחה לפני ביצוע שינויים במערכת. הטמעת אמצעי הגנה מונעים ואימוץ שיטות עבודה כמו תשתית כקוד (IaC), מדיניות כקוד ובדיקות אבטחה בצינור ה-CI/CD. אפשר גם להשתמש ביכולות אחרות שספציפיות לפלטפורמה, כמו Organization Policy Service ואשכולות GKE מוקשחים ב- Google Cloud.
- איתור ותיקון של באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן אחרי ביצוע שינויים במערכת. כדאי להטמיע שיטות עבודה כמו בדיקות קוד, סריקת נקודות חולשה אחרי הפריסה ובדיקות אבטחה.
העקרונות Implement security by design ו-shift-left security קשורים זה לזה, אבל הם שונים בהיקף שלהם. העיקרון של אבטחה מובנית עוזר לכם להימנע מפגמים בסיסיים בעיצוב, שיחייבו אתכם לתכנן מחדש את כל המערכת. לדוגמה, תרגיל של מידול איומים מגלה שהעיצוב הנוכחי לא כולל מדיניות הרשאות, וכל המשתמשים יקבלו את אותה רמת גישה בלי המדיניות הזו. אבטחה מסוג Shift-left עוזרת לכם להימנע מפגמים בהטמעה (באגים וטעויות בהגדרות) לפני החלת השינויים, ומאפשרת תיקונים מהירים ואמינים אחרי הפריסה.
המלצות
כדי ליישם את עקרון האבטחה shift-left בעומסי העבודה בענן, כדאי לעיין בהמלצות שבקטעים הבאים:
- אימוץ אמצעי בקרה למניעת בעיות אבטחה
- אוטומציה של הקצאת הרשאות וניהול של משאבי ענן
- אוטומציה של הפצת אפליקציות מאובטחות
- מוודאים שפריסת האפליקציות מתבצעת בהתאם לתהליכים שאושרו
- סריקה לאיתור נקודות חולשה מוכרות לפני פריסת האפליקציה
- מעקב אחר קוד האפליקציה כדי לזהות פרצות אבטחה ידועות
שימוש באמצעי בקרה למניעת בעיות אבטחה
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- ניהול זהויות והרשאות גישה
- משילות, סיכונים ותאימות בענן
אמצעי בקרה למניעת סיכונים הם חיוניים לשמירה על רמת אבטחה גבוהה בענן. הם עוזרים לצמצם סיכונים באופן יזום. בעזרתם אפשר למנוע טעויות בהגדרות וגישה לא מורשית למשאבים, לאפשר למפתחים לעבוד ביעילות ולוודא שהם עומדים בתקנים בתעשייה ובמדיניות הפנימית.
אמצעי בקרה למניעת איומים יעילים יותר כשמיישמים אותם באמצעות תשתית כקוד (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.
אתם יכולים לשנות את הסקריפטים של תוכנית ה-blueprint של Enterprise Foundations כדי להגדיר סביבה שתפעל בהתאם להמלצות של Google ותעמוד בדרישות האבטחה שלכם. אפשר להוסיף עוד תוכניות או ליצור אוטומציה משלכם.Google Cloud במרכז הארכיטקטורה יש תוכניות נוספות שאפשר להטמיע בנוסף לתוכנית לניהול יסודות הארגון. הנה כמה דוגמאות לתוכניות כאלה:
- פריסת פלטפורמת פיתוח לארגונים ב- Google Cloud
- פריסת ארכיטקטורה מאובטחת בלי שרת באמצעות Cloud Run
- יצירה ופריסה של מודלים של בינה מלאכותית גנרטיבית ולמידת מכונה בארגון
- ייבוא נתונים מ- Google Cloud למחסן נתונים מאובטח של BigQuery
אוטומציה של פרסום אפליקציות מאובטח
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
בלי כלים אוטומטיים, יכול להיות שיהיה קשה לפרוס, לעדכן ולתקן סביבות מורכבות של אפליקציות כדי לעמוד בדרישות אבטחה עקביות. מומלץ ליצור צינורות עיבוד נתונים אוטומטיים של CI/CD למחזור החיים של פיתוח התוכנה (SDLC). צינורות CI/CD אוטומטיים עוזרים לכם להסיר שגיאות ידניות, לספק לולאות משוב סטנדרטיות לפיתוח ולאפשר איטרציות יעילות של מוצרים. Continuous delivery היא אחת מהשיטות המומלצות שמומלצות במסגרת DORA.
שימוש בצינורות עיבוד נתונים של CI/CD כדי לבצע אוטומציה של הפצת אפליקציות עוזר לשפר את היכולת לזהות ולתקן באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן. לדוגמה, אתם יכולים לסרוק באופן אוטומטי חולשות אבטחה כשנוצרים ארטיפקטים, לצמצם את היקף בדיקות האבטחה ולחזור לגרסה מוכרת ובטוחה. אפשר גם להגדיר מדיניות לסביבות שונות (כמו סביבות פיתוח, בדיקה או ייצור) כדי שרק ארטיפקטים מאומתים ייפרסו.
כדי לעזור לכם לבצע אוטומציה של הפצת אפליקציות ולהטמיע בדיקות אבטחה בצינור ה-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גישה של Google לשינויים.
לוודא שפריסות של אפליקציות מתבצעות בהתאם לתהליכים מאושרים
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
אם תוקף יפרוץ לצינור עיבוד הנתונים של CI/CD, כל חבילת האפליקציות שלכם עלולה להיפגע. כדי לאבטח את צינור הנתונים, כדאי לאכוף תהליך אישור מוגדר לפני פריסת הקוד בסביבת הייצור.
אם אתם משתמשים ב-Google Kubernetes Engine (GKE) או ב-Cloud Run, אתם יכולים להגדיר תהליך אישור באמצעות Binary Authorization. Binary Authorization מצרף חתימות שאפשר להגדיר אותן לקובצי אימג' של קונטיינרים. החתימות האלה (שנקראות גם אישורים) עוזרות לאמת את התמונה. בזמן הפריסה, Binary Authorization משתמש באישורים האלה כדי לקבוע אם תהליך הושלם. לדוגמה, אפשר להשתמש ב-Binary Authorization כדי:
- מוודאים שמערכת build ספציפית או צינור CI יצרו קובץ אימג' של קונטיינר.
- בדיקה שקובץ אימג' של קונטיינר תואם למדיניות חתימה של נקודת חולשה.
- מוודאים שקובץ אימג' של קונטיינר עומד בקריטריונים לקידום לסביבת הפריסה הבאה, למשל מפיתוח לבדיקת איכות.
באמצעות Binary Authorization, אתם יכולים לוודא שרק קוד מהימן יפעל בפלטפורמות היעד שלכם.
סריקה לאיתור פרצות אבטחה מוכרות לפני פריסת האפליקציה
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
מומלץ להשתמש בכלים אוטומטיים שיכולים לבצע באופן רציף סריקות של נקודות חולשה בארטיפקטים של האפליקציה לפני שהם נפרסים בסביבת הייצור.
באפליקציות מבוססות קונטיינרים, אפשר להשתמש ב-Artifact Analysis כדי להריץ באופן אוטומטי סריקות של נקודות חולשה בקובצי אימג' של קונטיינרים. המערכת סורקת קובצי אימג' חדשים כשהם מועלים ל-Artifact Registry. במהלך הסריקה, המערכת מחלצת מידע על חבילות המערכת בקונטיינר. אחרי הסריקה הראשונית, המערכת של Artifact Analysis עוקבת באופן רציף אחרי המטא-נתונים של קובצי אימג' שנסרקו ב-Artifact Registry כדי לאתר נקודות חולשה חדשות. כש-Artifact Analysis מקבלת מידע חדש ומעודכן על נקודות חולשה ממקורות של נקודות חולשה, היא מבצעת את הפעולות הבאות:
- עדכון המטא-נתונים של התמונות הסרוקות כדי לשמור על עדכניות הנתונים.
- יוצרת מקרים חדשים של פגיעות עבור הערות חדשות.
- מוחק מקרים של פגיעויות שכבר לא תקפים.
מעקב אחרי קוד האפליקציה כדי לזהות פרצות אבטחה ידועות
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: אבטחת אפליקציות.
כדאי להשתמש בכלים אוטומטיים כדי לעקוב באופן רציף אחרי קוד האפליקציה ולחפש בו נקודות חולשה מוכרות, כמו אלה שמופיעות בOWASP Top 10. מידע נוסף על מוצרים ותכונות שתומכים בטכניקות לטיפול ב-OWASP Top 10 זמין במאמר אפשרויות לטיפול ב-OWASP Top 10 ב- Google Cloud. 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, כולל המלצות ליצירת תוכניות חזקות להגנה מפני מתקפות סייבר כחלק מאסטרטגיית האבטחה הכוללת שלכם.
העיקרון הזה מדגיש את השימוש במודיעין איומי סייבר כדי להנחות באופן יזום את המאמצים שלכם בפונקציות הליבה של הגנת הסייבר, כפי שמוגדר במאמר היתרון של המגן: מדריך להפעלת הגנת סייבר.
סקירה כללית של העקרונות
כשמגנים על המערכת מפני מתקפות סייבר, יש לכם יתרון משמעותי שלא מנוצל מספיק מול התוקפים. כפי שמייסד Mandiant אומר: "אתם צריכים לדעת יותר על העסק, המערכות, הטופולוגיה והתשתית שלכם מכל תוקף. זה יתרון עצום". כדי לעזור לכם להשתמש ביתרון המובנה הזה, במסמך הזה מפורטות המלצות לגבי שיטות הגנה פרואקטיביות ואסטרטגיות בסייבר, שממופות למסגרת Defender's Advantage.
המלצות
כדי להטמיע הגנה קיברנטית מונעת בעומסי העבודה בענן, כדאי לעיין בהמלצות שבקטעים הבאים:
- שילוב הפונקציות של הגנת סייבר
- שימוש בפונקציית ה-Intelligence בכל ההיבטים של הגנת סייבר
- הבנה של היתרון שלכם כמגינים וניצול שלו
- אימות ושיפור מתמשכים של אמצעי ההגנה
- ניהול ותיאום של מאמצי הגנה מפני מתקפות סייבר
שילוב הפונקציות של הגנת סייבר
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
מסגרת היתרון של המגן מזהה שש פונקציות קריטיות של הגנה מפני איומי סייבר: מודיעין, זיהוי, תגובה, אימות, חיפוש ומרכז בקרה.כל פונקציה מתמקדת בחלק ייחודי של משימת ההגנה מפני איומי סייבר, אבל הפונקציות האלה צריכות להיות מתואמות היטב ולפעול יחד כדי לספק הגנה יעילה. חשוב להתמקד בבניית מערכת חזקה ומשולבת שבה כל פונקציה תומכת באחרות. אם אתם צריכים גישה מדורגת לאימוץ, כדאי לשקול את הסדר המוצע הבא. בהתאם לרמת הבשלות הנוכחית של הענן, לטופולוגיית המשאבים ולנוף האיומים הספציפי, יכול להיות שכדאי לתת עדיפות לפונקציות מסוימות.
- מודיעין: פונקציית המודיעין מנחה את כל הפונקציות האחרות. כדי לתעדף פעולות בכל התוכנית, חשוב להבין את סביבת האיומים – כולל התוקפים הסבירים ביותר, הטקטיקות, הטכניקות והנהלים שלהם (TTP) וההשפעה הפוטנציאלית. פונקציית המודיעין אחראית לזיהוי בעלי העניין, להגדרת דרישות המודיעין, לאיסוף נתונים, לניתוח ולהפצה, לאוטומציה וליצירת פרופיל של איומי סייבר.
- זיהוי ותגובה: הפונקציות האלה מהוות את הליבה של הגנה פעילה, שכוללת זיהוי של פעילות זדונית וטיפול בה. הפונקציות האלה נדרשות כדי לפעול על סמך המידע שנאסף על ידי פונקציית המודיעין. פונקציית הזיהוי דורשת גישה שיטתית שמתאימה את הזיהויים ל-TTP של התוקף ומבטיחה רישום חזק ביומן. פונקציית התגובה צריכה להתמקד במיון ראשוני, באיסוף נתונים ובתיקון האירוע.
- אימות: פונקציית האימות היא תהליך מתמשך שמבטיח שמערכת בקרת האבטחה שלכם עדכנית ופועלת כמתוכנן. הפונקציה הזו מוודאת שהארגון שלכם מבין את משטח התקיפה, יודע איפה קיימים פגיעויות ומודד את יעילות אמצעי הבקרה. אימות האבטחה הוא גם רכיב חשוב במחזור החיים של הנדסת הזיהוי, וצריך להשתמש בו כדי לזהות פערים בזיהוי וליצור זיהויים חדשים.
- חיפוש איומים: הפונקציה הזו כוללת חיפוש יזום של איומים פעילים בסביבה. צריך להטמיע את הפונקציה הזו כשהארגון מגיע לרמת בגרות בסיסית בפונקציות 'זיהוי' ו'תגובה'. הפונקציה הזו מרחיבה את יכולות הזיהוי ועוזרת לזהות פערים וחולשות באמצעי הבקרה. הפונקציה הזו צריכה להתבסס על איומים ספציפיים. כדי להשתמש בפונקציה המתקדמת הזו, צריך יכולות חזקות של מודיעין, זיהוי ותגובה.
- מרכז הבקרה: הפונקציה'מרכז הבקרה' משמשת כמרכז שמקושרות אליו כל הפונקציות האחרות. הפונקציה הזו אחראית לאסטרטגיה, לתקשורת ולפעולה נחרצת במסגרת תוכנית ההגנה מפני איובר בסייבר. היא מוודאת שכל הפונקציות פועלות יחד ושהן תואמות ליעדים העסקיים של הארגון. לפני שמשתמשים בפונקציה הזו כדי לקשר את הפונקציות האחרות, חשוב להבין בבירור את המטרה שלה.
שימוש בפונקציית ה-Intelligence בכל ההיבטים של הגנת הסייבר
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
ההמלצה הזו מדגישה את פונקציית ה-Intelligence כחלק מרכזי בתוכנית חזקה להגנה מפני מתקפות סייבר. מודיעין איומי סייבר מספק ידע על גורמי איום, על שיטות הפעולה שלהם ועל אינדיקטורים לפריצה (IOC). הידע הזה צריך לשמש בסיס לפעולות בכל הפונקציות של הגנת הסייבר, ולקבוע את סדר העדיפויות שלהן. גישה מבוססת-מודיעין עוזרת לכם להתאים את אמצעי ההגנה כדי להתמודד עם האיומים שסביר ביותר שישפיעו על הארגון שלכם. הגישה הזו גם עוזרת להקצות משאבים בצורה יעילה ולתת עדיפות למשאבים חשובים.
המוצרים והתכונות הבאים Google Cloud עוזרים לכם להשתמש במודיעין איומי סייבר כדי להנחות את תפעול האבטחה (SecOps) שלכם. אתם יכולים להשתמש בתכונות האלה כדי לזהות ולתעדף איומים, נקודות חולשה וסיכונים פוטנציאליים, ואז לתכנן וליישם פעולות מתאימות.
Google Security Operations (Google SecOps) עוזרת לכם לאחסן ולנתח נתוני אבטחה באופן מרכזי. אפשר להשתמש ב-Google SecOps כדי למפות יומנים למודל משותף, להעשיר את היומנים ולקשר אותם לציר זמן כדי לקבל תצוגה מקיפה של התקפות. אפשר גם ליצור כללי זיהוי, להגדיר התאמה של IoC ולבצע פעילויות של איתור איומים. הפלטפורמה מספקת גם זיהויים שנערכו, שהם כללים מוגדרים מראש ומנוהלים שעוזרים לזהות איומים. אפשר גם לשלב את Google SecOps עם Mandiant frontline intelligence. Google SecOps משלב באופן ייחודי AI מוביל בתעשייה, יחד עם מודיעין איומי סייבר מ-Mandiant ו-Google VirusTotal. השילוב הזה חיוני להערכת איומים ולהבנה של הגורמים שמטרגטים את הארגון שלכם וההשפעה הפוטנציאלית.
Security Command Center Enterprise, שמבוסס על AI מבית Google, מאפשר לאנשי מקצוע בתחום האבטחה להעריך, לחקור ולטפל בבעיות אבטחה ביעילות בסביבות ענן מרובות. אנשי מקצוע בתחום האבטחה שיכולים להפיק תועלת מ-Security Command Center כוללים אנליסטים במרכז האבטחה (SOC), אנליסטים של נקודות חולשה ושל מצב האבטחה ומנהלי תאימות. Security Command Center Enterprise מעשיר את נתוני האבטחה, מעריך את הסיכון ונותן עדיפות לפגיעויות. הפתרון הזה מספק לצוותים את המידע שהם צריכים כדי לטפל בפגיעויות בסיכון גבוה ולתקן איומים פעילים.
Chrome Enterprise Premium מציע הגנה על נתונים מפני איומים, ועוזר להגן על משתמשים מפני סיכוני חילוץ נתונים ומונע מתוכנות זדוניות להיכנס למכשירים שמנוהלים על ידי הארגון. בנוסף, Chrome Enterprise Premium מספק תובנות לגבי פעילות לא בטוחה או פעילות שעלולה להיות לא בטוחה שיכולה להתרחש בדפדפן.
ניטור הרשת, באמצעות כלים כמו Network Intelligence Center, מאפשר לראות את ביצועי הרשת. ניטור הרשת יכול גם לעזור לכם לזהות דפוסי תנועה חריגים או לזהות כמויות של העברת נתונים שעשויות להצביע על ניסיון תקיפה או על ניסיון להוצאת נתונים.
הבנה של היתרון של המגן וניצול שלו
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
כמו שציינו קודם, יש לכם יתרון על התוקפים אם אתם מבינים היטב את העסק, המערכות, הטופולוגיה והתשתית שלכם. כדי לנצל את היתרון הזה, כדאי להשתמש בנתונים האלה לגבי הסביבות שלכם במהלך תכנון ההגנה מפני מתקפות סייבר.
Google Cloud מספק את התכונות הבאות כדי לעזור לכם לקבל תובנות באופן יזום, לזהות איומים, להבין סיכונים ולהגיב בזמן כדי לצמצם נזק פוטנציאלי:
Chrome Enterprise Premium עוזר לכם לשפר את האבטחה של מכשירים ארגוניים על ידי הגנה על משתמשים מפני סיכוני גניבת נתונים. הוא מרחיב את שירותי Sensitive Data Protection לדפדפן ומונע תוכנות זדוניות. הוא כולל גם תכונות כמו הגנה מפני תוכנות זדוניות ופישינג, כדי למנוע חשיפה לתוכן לא בטוח. בנוסף, היא מאפשרת לכם לשלוט בהתקנה של תוספים כדי למנוע התקנה של תוספים לא בטוחים או לא בדוקים. היכולות האלה עוזרות לכם לבסס תשתית מאובטחת לפעילות שלכם.
Security Command Center Enterprise מספק מנוע סיכונים רציף שמציע ניתוח וניהול מקיפים של סיכונים. התכונה 'מנוע סיכונים' מעשירה את נתוני האבטחה, מעריכה את הסיכון ונותנת עדיפות לפגיעויות כדי לעזור לפתור בעיות במהירות. בעזרת Security Command Center הארגון יכול לזהות חולשות באופן יזום וליישם אמצעים לצמצום הסיכון.
Google SecOps מרכזת את נתוני האבטחה ומספקת יומנים מועשרים עם ציר זמן. כך יכולים אנשי ההגנה לזהות באופן יזום פשרות פעילות ולהתאים את ההגנות על סמך התנהגות התוקפים.
ניטור הרשת עוזר לזהות פעילות חריגה ברשת שעשויה להצביע על מתקפה, ומספק אינדיקטורים מוקדמים שבעזרתם אפשר לפעול. כדי להגן על הנתונים מפני גניבה באופן יזום, צריך לעקוב כל הזמן אחרי זליגת נתונים ולהשתמש בכלים שזמינים.
אימות ושיפור של אמצעי ההגנה באופן שוטף
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
ההמלצה הזו מדגישה את החשיבות של בדיקות ממוקדות ותיקוף רציף של אמצעי הבקרה כדי להבין את נקודות החוזק והחולשה בכל שטח המתקפה. זה כולל אימות של היעילות של אמצעי הבקרה, הפעולות והצוות באמצעות שיטות כמו:
- בדיקות חדירה
- תרגילים של צוות אדום-כחול ושל צוות סגול
- תרגילים שולחניים
בנוסף, עליכם לחפש באופן פעיל איומים ולהשתמש בתוצאות כדי לשפר את יכולות הזיהוי והחשיפה. כדי לבדוק ולאמת באופן רציף את אמצעי ההגנה מפני איומים בעולם האמיתי, אפשר להשתמש בכלים הבאים:
Security Command Center Enterprise מספק מנוע סיכונים רציף להערכת נקודות חולשה ולתעדוף של פעולות לתיקון, וכך מאפשר הערכה שוטפת של מצב האבטחה הכולל. באמצעות תעדוף בעיות, Security Command Center Enterprise עוזר לכם לוודא שהמשאבים מנוצלים בצורה יעילה.
Google SecOps מציע יכולות של איתור איומים וזיהויים שנבחרו בקפידה, שמאפשרים לכם לזהות באופן יזום חולשות באמצעי הבקרה שלכם. היכולת הזו מאפשרת לכם לבצע בדיקות שיטתיות ולשפר את היכולת שלכם לזהות איומים.
Chrome Enterprise Premium מספק תכונות להגנה על נתונים מפני איומים שיכולות לעזור לכם להתמודד עם איומים חדשים ומתפתחים, ולעדכן באופן רציף את אמצעי ההגנה שלכם מפני סיכוני חדירה ותוכנות זדוניות.
Cloud Next Generation Firewall (Cloud NGFW) מספק ניטור של הרשת וניטור של גניבת נתונים. היכולות האלה יכולות לעזור לכם לאמת את האפקטיביות של מצב האבטחה הנוכחי ולזהות חולשות פוטנציאליות. המעקב אחר העברת נתונים לא מורשית עוזר לכם לאמת את עוצמת מנגנוני ההגנה על הנתונים של הארגון ולבצע התאמות יזומות במקומות שבהם יש צורך בכך. כשמשלבים ממצאי איומים מ-Cloud NGFW עם Security Command Center ו-Google SecOps, אפשר לבצע אופטימיזציה של זיהוי איומים מבוסס-רשת, אופטימיזציה של תגובה לאיומים ואוטומציה של תוכניות פעולה. מידע נוסף על השילוב הזה זמין במאמר איחוד אמצעי ההגנה בענן: Security Command Center ו-Cloud NGFW Enterprise.
ניהול ותיאום של מאמצי הגנה מפני איומי סייבר
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
כפי שמתואר קודם בקטע שילוב הפונקציות של הגנת הסייבר, הפונקציה Mission Control מקשרת בין הפונקציות האחרות של תוכנית הגנת הסייבר. הפונקציה הזו מאפשרת תיאום וניהול מאוחד של התוכנית. היא גם עוזרת לכם לתאם עם צוותים אחרים שלא עובדים על אבטחת סייבר. הפונקציה Mission Control מקדמת העצמה ואחריותיות, מאפשרת גמישות ומומחיות, ומגבירה את האחריות והשקיפות.
המוצרים והתכונות הבאים יכולים לעזור לכם להטמיע את הפונקציה של מרכז הבקרה:
- Security Command Center Enterprise משמש כמרכז לתיאום ולניהול של פעולות ההגנה בסייבר. הוא מאגד כלים, צוותים ונתונים, וכולל את יכולות התגובה המובנות של Google SecOps. ב-Security Command Center אפשר לראות בבירור את מצב האבטחה של הארגון, ולזהות בעיות בהגדרות האבטחה במשאבים שונים.
- Google SecOps מספקת פלטפורמה לצוותים כדי להגיב לאיומים באמצעות מיפוי יומנים ויצירת ציר זמן. אפשר גם להגדיר כללי זיהוי ולחפש איומים.
- Google Workspace ו-Chrome Enterprise Premium עוזרים לכם לנהל ולשלוט בגישת משתמשי הקצה למשאבים רגישים. אתם יכולים להגדיר בקרות גישה מפורטות על סמך זהות המשתמש וההקשר של הבקשה.
- ניטור הרשת מספק תובנות לגבי הביצועים של משאבי הרשת. אתם יכולים לייבא תובנות לגבי ניטור רשת ל-Security Command Center ול-Google SecOps כדי לבצע ניטור ומתאם מרכזיים מול נקודות נתונים אחרות שמבוססות על ציר זמן. השילוב הזה עוזר לכם לזהות שינויים פוטנציאליים בשימוש ברשת שנגרמים מפעילות זדונית, ולהגיב להם.
- מעקב אחרי זליגת נתונים עוזר לזהות אירועים אפשריים של אובדן נתונים. התכונה הזו מאפשרת לכם לגייס ביעילות צוות לתגובה לאירועים, להעריך את הנזקים ולהגביל את המשך חילוץ הנתונים. אפשר גם לשפר את המדיניות ואמצעי הבקרה הקיימים כדי להבטיח הגנה על הנתונים.
סיכום מוצר
בטבלה הבאה מפורטים המוצרים והתכונות שמתוארים במסמך הזה, וההמלצות והיכולות שקשורות לאבטחה.
| המוצר שלGoogle Cloud | המלצות רלוונטיות |
|---|---|
| Google SecOps | שימוש בפונקציית ה-Intelligence בכל ההיבטים של הגנת סייבר:
הפונקציה מאפשרת לאתר איומים ולהתאים אותם ל-IoC, והיא משתלבת עם Mandiant לצורך הערכה מקיפה של האיומים. הבנה של היתרון של המגן וניצול היתרון הזה: המערכת מספקת גלאים מוכנים מראש ומרכזת את נתוני האבטחה כדי לזהות פשרות באופן יזום. אימות ושיפור מתמשכים של אמצעי ההגנה: מאפשר בדיקה ושיפור מתמשכים של יכולות זיהוי האיומים.ניהול ותיאום של מאמצי הגנה מפני איומי סייבר באמצעות Mission Control: מספק פלטפורמה לתגובה לאיומים, לניתוח יומנים וליצירת ציר זמן. |
| Security Command Center Enterprise | שימוש בפונקציית ה-Intelligence בכל ההיבטים של הגנת סייבר:
השימוש ב-AI מאפשר להעריך את הסיכון, לתת עדיפות לנקודות חולשה ולספק תובנות פרקטיות לתיקון. הבנה של היתרון של המערכת שלכם והפקת תועלת ממנו: ניתוח סיכונים מקיף, קביעת סדרי עדיפויות לפגיעויות וזיהוי פרואקטיבי של נקודות חולשה. אימות ושיפור מתמשכים של אמצעי ההגנה: הערכה שוטפת של מצב האבטחה ותעדוף של משאבים.ניהול ותיאום של מאמצי ההגנה מפני מתקפות סייבר באמצעות Mission Control: משמש כמרכז לניהול ותיאום של פעולות הגנה מפני מתקפות סייבר. |
| Chrome Enterprise Premium |
שימוש בפונקציית ה-Intelligence בכל ההיבטים של הגנת הסייבר:
הגנה על משתמשים מפני סיכוני חילוץ נתונים, מניעת תוכנות זדוניות ומתן תובנות לגבי פעילות לא בטוחה בדפדפן.
הבנה של היתרון של מערכת ההגנה וניצול שלו: שיפור האבטחה של מכשירים ארגוניים באמצעות הגנה על נתונים, מניעת תוכנות זדוניות ושליטה בתוספים. אימות ושיפור מתמשכים של אמצעי ההגנה: התמודדות עם איומים חדשים ומתפתחים באמצעות עדכונים שוטפים של אמצעי ההגנה מפני סיכוני חדירה ותוכנות זדוניות.ניהול ותיאום של מאמצי הגנה מפני מתקפות סייבר באמצעות Mission Control: ניהול ושליטה בגישה של משתמשי קצה למקורות רגישים, כולל אמצעי בקרה מפורטים לגישה. |
| Google Workspace | ניהול ותיאום של מאמצי הגנה מפני מתקפות סייבר באמצעות Mission Control: ניהול ושליטה בגישה של משתמשי קצה למקורות רגישים, כולל אמצעי בקרה מפורטים לגישה. |
| Network Intelligence Center | שימוש בפונקציית ה-Intelligence בכל ההיבטים של הגנת הסייבר: מספקת תובנות לגבי ביצועי הרשת ומזהה דפוסי תעבורה או העברות נתונים חריגים. |
| 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 ב- Google Cloudזמינה בפרספקטיבה של AI ו-ML ב-Well-Architected Framework.
הגדרת יעדים ודרישות ברורים לשימוש ב-AI
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- משילות, סיכונים ותאימות בענן
- אבטחת AI ו-ML
ההמלצה הזו תואמת לרכיב SAIF שעוסק בהצגת הסיכונים למערכות AI בהקשר של התהליכים העסקיים שסובבים אותן. כשמעצבים ומפתחים מערכות AI, חשוב להבין את היעדים העסקיים הספציפיים, הסיכונים ודרישות התאימות.
שמירה על אבטחת הנתונים ומניעת אובדן או טיפול לא תקין
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
- אבטחת אפליקציות
- אבטחת AI ו-ML
ההמלצה הזו תואמת לרכיבי ה-SAIF הבאים:
- הרחבה של תשתיות אבטחה יעילות לסביבה העסקית של AI. האלמנט הזה כולל איסוף נתונים, אחסון, בקרת גישה והגנה מפני הרעלת נתונים.
- הצגת הסיכונים למערכות AI בהקשר. הדגשת אבטחת מידע כדי לתמוך ביעדים העסקיים ובתאימות.
שמירה על צינורות ה-AI מאובטחים ועמידים בפני שינויים לא מורשים
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
- אבטחת אפליקציות
- אבטחת AI ו-ML
ההמלצה הזו תואמת לרכיבי ה-SAIF הבאים:
- הרחבה של תשתיות אבטחה עוצמתיות לסביבה העסקית של AI. כחלק חשוב מהקמת מערכת AI מאובטחת, חשוב לאבטח את הקוד ואת ארטיפקטים של המודל.
- התאמה של אמצעי הבקרה כדי ליצור לולאות משוב מהירות יותר. חשוב לעקוב אחרי הנכסים והרצות של צינורות הנתונים כדי לצמצם את הסיכונים ולתת מענה לאירועים.
פריסת אפליקציות במערכות מאובטחות באמצעות כלים וחפצים מאובטחים
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
- אבטחת אפליקציות
- אבטחת AI ו-ML
שימוש במערכות מאובטחות ובכלים ובארטיפקטים מאומתים באפליקציות מבוססות-AI תואם לרכיב SAIF בנושא הרחבת תשתיות אבטחה חזקות לסביבה העסקית של AI ולשרשרת האספקה. כדי לטפל בהמלצה הזו, אפשר לפעול לפי השלבים הבאים:
- הטמעה של סביבה מאובטחת להדרכה ולפריסה של למידת מכונה
- שימוש בתמונות מאומתות של קונטיינרים
- יישום ההנחיות של Supply-chain Levels for Software Artifacts (SLSA)
הגנה על מקורות קלט ומעקב אחריהם
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- רישום ביומן, ביקורת ומעקב
- תפעול אבטחה (SecOps)
- אבטחת AI ו-ML
ההמלצה הזו תואמת לרכיב SAIF בנושא הרחבת יכולות הזיהוי והתגובה כדי לשלב AI ביקום האיומים של הארגון. כדי למנוע בעיות, חשוב לנהל את ההנחיות למערכות AI גנרטיבי, לעקוב אחרי נתוני הקלט ולשלוט בגישת המשתמשים.
המלצות לניהול AI
כל ההמלצות בקטע הזה רלוונטיות לתחום ההתמקדות הבא: ניהול, סיכונים ותאימות ב-Cloud.
Google Cloud מציעה חבילה מקיפה של כלים ושירותים שבהם אפשר להשתמש כדי לבנות מערכות AI אחראיות ואתיות. אנחנו גם מציעים מסגרת של מדיניות, נהלים ושיקולים אתיים שיכולים להנחות אתכם בפיתוח, בפריסה ובשימוש במערכות AI.
כפי שמשתקף בהמלצות שלנו, הגישה של Google לפיקוח על AI מבוססת על העקרונות הבאים:
- הוגנות
- שקיפות
- אחריותיות
- פרטיות
- אבטחה
שימוש ב-Fairness Indicators
Vertex AI יכול לזהות הטיה במהלך תהליך איסוף הנתונים או הערכה אחרי האימון.Vertex AI מספק מדדי הערכת מודלים כמו הטיית נתונים והטיית מודלים כדי לעזור לכם להעריך את המודל שלכם ולזהות בו הטיה.
המדדים האלה קשורים להוגנות בקטגוריות שונות כמו גזע, מגדר ומעמד. עם זאת, פירוש סטיות סטטיסטיות הוא לא תרגיל פשוט, כי יכול להיות שההבדלים בין הקטגוריות לא נובעים מהטיה או מהצגת תוכן מזיק.
שימוש ב-Vertex Explainable AI
כדי להבין איך מודלים של AI מקבלים החלטות, אפשר להשתמש ב-Vertex AI ניתן להסברה. התכונה הזו עוזרת לכם לזהות הטיה פוטנציאלית שעשויה להיות חבויה בלוגיקה של המודל.
תכונת ההסבר הזו משולבת עם BigQuery ML ועם Vertex AI, ומספקת הסברים שמבוססים על פיצ'רים. אפשר לבצע הסבר ב-BigQuery ML או לרשום את המודל ב-Vertex AI ולבצע הסבר ב-Vertex AI.
מעקב אחר שושלת נתונים
עוקבים אחרי המקור והשינוי של הנתונים שמשמשים במערכות ה-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: כלים מבוססי-AI, כמו Gemini, משפרים את הפרודוקטיביות של בני אדם על ידי סיכום מידע, יצירת תובנות והמלצות.
- חצי אוטונומי: ה-AI אחראי בעיקר למשימות אבטחה רבות, ומעביר את האחריות לבני אדם רק כשנדרש.
- אוטונומי: ה-AI פועל כעוזר מהימן שמניע את מחזור החיים של האבטחה על סמך היעדים וההעדפות של הארגון, עם התערבות אנושית מינימלית.
המלצות
בקטעים הבאים מתוארות ההמלצות לשימוש ב-AI לצורכי אבטחה. בנוסף, מצוין איך ההמלצות תואמות ליסודות הליבה של Secure AI Framework (SAIF) של Google, ואיך הן רלוונטיות לרמות של אוטונומיה באבטחה.
- שיפור הזיהוי והתגובה לאיומים באמצעות AI
- אבטחה פשוטה למומחים ולמי שאינם מומחים
- אוטומציה של משימות אבטחה שגוזלות זמן באמצעות AI
- שילוב AI בתהליכי ניהול סיכונים ופיקוח
- הטמעת שיטות פיתוח מאובטחות למערכות AI
שיפור זיהוי האיומים והתגובה לאיומים באמצעות AI
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- תפעול אבטחה (SecOps)
- רישום ביומן, ביקורת ומעקב
AI יכול לנתח כמויות גדולות של נתוני אבטחה, לספק תובנות לגבי התנהגות של גורמי איום ולבצע אוטומציה של ניתוח קוד שעלול להיות זדוני. ההמלצה הזו תואמת לרכיבי SAIF הבאים:
- שילוב AI בתהליכי הטיפול באיומים בארגון, משלב הזיהוי ועד שלב התגובה.
- אוטומציה של אמצעי הגנה במטרה לעמוד בקצב של איומים קיימים וחדשים.
בהתאם להטמעה, ההמלצה הזו יכולה להיות רלוונטית לרמות האוטונומיה הבאות:
- בעזרת AI: ה-AI עוזר בניתוח ובזיהוי של איומים.
- חצי אוטונומי: ה-AI לוקח על עצמו יותר אחריות למשימת האבטחה.
Google Threat Intelligence, שמשתמש ב-AI כדי לנתח את ההתנהגות של גורמי איום וקוד זדוני, יכול לעזור לכם ליישם את ההמלצה הזו.
אבטחה פשוטה למומחים ולמי שאינם מומחים
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- תפעול אבטחה (SecOps)
- משילות, סיכונים ותאימות בענן
כלים מבוססי-AI יכולים לסכם התראות ולהמליץ על צעדים לצמצום הסיכונים, והיכולות האלה יכולות להפוך את האבטחה לנגישה יותר למגוון רחב יותר של אנשי צוות. ההמלצה הזו תואמת לרכיבי ה-SAIF הבאים:
- אוטומציה של אמצעי הגנה במטרה לעמוד בקצב של איומים קיימים וחדשים.
- יצירת איזון והרמוניה בין אמצעי הבקרה ברמת הפלטפורמה כדי לשמור על אבטחה עקבית בכל חלקי הארגון.
בהתאם להטמעה, ההמלצה הזו יכולה להיות רלוונטית לרמות האוטונומיה הבאות:
- בעזרת AI: ה-AI עוזר לכם לשפר את הנגישות של מידע האבטחה.
- חצי אוטונומי: AI עוזר לשפר את שיטות האבטחה לטובת כל המשתמשים.
Gemini ב-Security Command Center יכול לספק סיכומים של התראות לגבי הגדרות שגויות ונקודות חולשה.
אוטומציה של משימות אבטחה שגוזלות זמן באמצעות AI
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- אבטחת התשתית
- תפעול אבטחה (SecOps)
- אבטחת אפליקציות
AI יכול להפוך משימות לאוטומטיות, כמו ניתוח תוכנות זדוניות, יצירת כללי אבטחה וזיהוי הגדרות שגויות. היכולות האלה יכולות לעזור לצמצם את עומס העבודה על צוותי האבטחה ולזרז את זמני התגובה. ההמלצה הזו תואמת לרכיב SAIF בנושא אוטומציה של אמצעי הגנה במטרה לעמוד בקצב של איומים קיימים וחדשים.
בהתאם להטמעה, ההמלצה הזו יכולה להיות רלוונטית לרמות האוטונומיה הבאות:
- בעזרת AI: ה-AI עוזר לכם להפוך משימות לאוטומטיות.
- חצי אוטונומי: ה-AI אחראי בעיקר למשימות אבטחה, ומבקש עזרה מבני אדם רק כשצריך.
Gemini ב-Google SecOps יכול לעזור לבצע אוטומציה של משימות שדורשות מאמץ רב, לסייע לאנליסטים, לאחזר הקשר רלוונטי ולהמליץ על השלבים הבאים.
שילוב של AI בתהליכי ניהול סיכונים ופיקוח
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: ניהול, סיכונים ותאימות בענן.
אתם יכולים להשתמש ב-AI כדי ליצור מלאי של מודלים ופרופילים של סיכונים. אפשר גם להשתמש ב-AI כדי להטמיע מדיניות בנושא פרטיות נתונים, סיכוני סייבר וסיכונים מצד שלישי. ההמלצה הזו תואמת לרכיב SAIF בנושא הצגת הסיכונים למערכות AI בהקשר של התהליכים העסקיים שסובבים אותן.
בהתאם להטמעה, ההמלצה הזו יכולה להיות רלוונטית לרמת האוטונומיה החלקית. ברמה הזו, AI יכול לתזמן סוכני אבטחה שמריצים תהליכים כדי להשיג את יעדי האבטחה המותאמים אישית שלכם.
הטמעת שיטות פיתוח מאובטחות למערכות AI
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- אבטחת אפליקציות
- אבטחת AI ו-ML
אתם יכולים להשתמש ב-AI כדי לתכנת בצורה מאובטחת, לנקות נתוני אימון ולאמת כלים וארטיפקטים. ההמלצה הזו תואמת לרכיב SAIF בנושא הרחבת בסיסי אבטחה חזקים למערכת האקולוגית של ה-AI.
ההמלצה הזו רלוונטית לכל רמות האוטונומיה של האבטחה, כי צריך להטמיע מערכת 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) ולשימוש שלכם. משתמשים במסגרת להערכת סיכונים שספציפית לענן, כמו מטריצת בקרת הענן (CCM). כדאי להשתמש במידול איומים, כמו OWASP application threat modeling, כדי לזהות נקודות חולשה ולטפל בהן. כדי לקבל עזרה ממומחים בהערכות סיכונים, אפשר לפנות לאיש הקשר האחראי לחשבון Google או לעיין ב 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 האישורים ומכתבי האימות (attestation) העדכניים, אפשר להיכנס אל Compliance resource center.
המלצות לטיפול בחובות רגולטוריות ובחובות שקשורות לעמידה בדרישות
תהליך הטיפול בתאימות כולל בדרך כלל שלושה שלבים: הערכה, תיקון פערים ומעקב מתמשך. בקטע הזה מפורטות המלצות שיכולות לעזור לכם בכל אחד מהשלבים האלה.
הערכת צורכי התאימות
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: ניהול, סיכונים ותאימות בענן.
הערכת התאימות מתחילה בבדיקה יסודית של כל החובות הרגולטוריות שלכם ושל האופן שבו העסק שלכם מיישם אותן. כדי לעזור לכם להעריך את השירותים, תוכלו להיעזר במרכז המשאבים בנושא תאימות. Google Cloud באתר הזה מופיע מידע על הנושאים הבאים:
- תמיכה בשירותים עבור תקנות שונות
- 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 Flow Logs: רישום של זרימות תעבורת נתונים ברשת שנשלחות או מתקבלות על ידי מכונות וירטואליות.
- 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 מציע שירות קטלוג שמאפשר לאחסן את המטא-נתונים, לנהל אותם ולגשת אליהם. למידע נוסף ולדוגמה של סיווג נתונים והסרת פרטים מזהים, אפשר לעיין במאמר הסרת פרטים מזהים וזיהוי מחדש של פרטים אישיים מזהים (PII) באמצעות Sensitive Data Protection.
נעילת הגישה למידע אישי רגיש
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- אבטחת מידע
- ניהול זהויות והרשאות גישה
כדי להציב מידע אישי רגיש בגבולות גזרה לשירות משלו, אפשר להשתמש ב-VPC Service Controls. VPC Service Controls משפר את היכולת שלכם לצמצם את הסיכון להעתקה או להעברה לא מורשות של נתונים (זליגת נתונים) משירותים שמנוהלים על ידי Google. בעזרת VPC Service Controls, אתם יכולים להגדיר גבולות גזרה לאבטחה מסביב למשאבים של השירותים שמנוהלים על ידי Google, כדי לשלוט בתנועת הנתונים בתוך הגבולות. מגדירים אמצעי בקרה לגישה לנתונים האלה באמצעות ניהול הזהויות והרשאות הגישה (IAM) של Google. הגדרת אימות רב-שלבי (MFA) לכל המשתמשים שנדרשת להם גישה למידע אישי ורגיש.
אחריות משותפת וגורל משותף ב- Google Cloud
במסמך הזה מתוארים ההבדלים בין מודל האחריות המשותפת לבין גורל משותף ב- Google Cloud. המאמר מתייחס לאתגרים ולניואנסים של מודל האחריות המשותפת. במסמך הזה מתואר המושג 'גורל משותף' ומוסבר איך אנחנו משתפים פעולה עם הלקוחות שלנו כדי להתמודד עם אתגרי אבטחה בענן.
חשוב להבין את מודל האחריות המשותפת כדי לקבוע איך הכי טוב להגן על הנתונים ועומסי העבודה ב- Google Cloud. מודל האחריות המשותפת מתאר את המשימות שמוטלות עליכם בכל הנוגע לאבטחה בענן, ומסביר איך המשימות האלה שונות עבור ספקי שירותי ענן.
עם זאת, לפעמים קשה להבין את האחריות המשותפת. המודל הזה דורש הבנה מעמיקה של כל שירות שבו אתם משתמשים, של אפשרויות ההגדרה שכל שירות מספק ושל הפעולות ש- Google Cloudמבצע כדי לאבטח את השירות. לכל שירות יש פרופיל להעלאת הגדרות אישיות שונה, ולכן יכול להיות שיהיה קשה לקבוע את הגדרת האבטחה הטובה ביותר. Google מאמינה שמודל האחריות המשותפת לא מספיק כדי לעזור ללקוחות ענן להשיג תוצאות אבטחה טובות יותר. במקום אחריות משותפת, אנחנו מאמינים בגורל משותף.
הגורל המשותף כולל את בניית פלטפורמת ענן מהימנה והפעלתה עבור עומסי העבודה שלכם. אנחנו מספקים הנחיות לגבי שיטות מומלצות וקוד תשתית מאובטח ומאושר שבו אפשר להשתמש כדי לפרוס את עומסי העבודה בצורה מאובטחת. אנחנו משיקים פתרונות שמשלבים מגוון שירותים כדי לפתור בעיות אבטחה מורכבות, ומציעים אפשרויות ביטוח חדשניות שיעזרו לכם למדוד ולצמצם את הסיכונים שאתם צריכים לקחת על עצמכם. Google Cloud במודל של גורל משותף, אנחנו מקיימים אינטראקציה הדוקה יותר איתכם בזמן שאתם מאבטחים את המשאבים שלכם ב-Google Cloud.
אחריות משותפת
אתם המומחים שמכירים את דרישות האבטחה והרגולציה של העסק שלכם, ואת הדרישות להגנה על הנתונים והמשאבים הסודיים שלכם. כשמריצים את עומסי העבודה ב- Google Cloud, צריך לזהות את אמצעי הבקרה שצריך להגדיר ב- Google Cloud כדי להגן על הנתונים הסודיים ועל כל עומס עבודה. כדי להחליט אילו אמצעי בקרה להטמיע, צריך לקחת בחשבון את הגורמים הבאים:
- המחויבויות שלכם לעמידה בדרישות רגולטוריות
- תקני האבטחה ותוכנית ניהול הסיכונים של הארגון
- דרישות האבטחה של הלקוחות והספקים שלכם
מוגדר על ידי עומסי עבודה
באופן מסורתי, האחריות מוגדרת על סמך סוג עומס העבודה שמופעל ועל סמך שירותי הענן שנדרשים. שירותי הענן כוללים את הקטגוריות הבאות:
| שירות ענן | תיאור |
|---|---|
| תשתית כשירות (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 functions היא אפליקציית FaaS. |
בתרשים הבא מוצגים שירותי הענן ומוסבר איך האחריות מתחלקת בין ספק שירותי הענן לבין הלקוח.
כפי שאפשר לראות בתרשים, ספק הענן תמיד אחראי לרשת ולתשתית הבסיסיות, והלקוחות תמיד אחראים למדיניות הגישה ולנתונים שלהם.
מוגדר על ידי התעשייה והמסגרת הרגולטורית
בתעשיות שונות יש מסגרות רגולטוריות שמגדירות את אמצעי האבטחה שצריכים להיות במקום. כשמעבירים את עומסי העבודה לענן, חשוב להבין את הנקודות הבאות:
- אמצעי האבטחה שבאחריותכם
- אילו אמצעי אבטחה זמינים כחלק מהשירות בענן
- אילו אמצעי אבטחה שמוגדרים כברירת מחדל עוברים בירושה
אמצעי בקרה שמועברים בירושה (כמו ההצפנה שמוגדרת כברירת מחדל ואמצעי הבקרה של התשתית) הם אמצעי בקרה שאתם יכולים לספק כחלק מההוכחות למצב האבטחה שלכם לביקורת ולרגולטורים. לדוגמה, בתקן אבטחת הנתונים המקובל בתעשיית כרטיסי התשלום (PCI DSS) מוגדרים תקנות למעבדי תשלומים. כשמעבירים את העסק לענן, התקנות האלה משותפות לכם ולספק שירותי הענן (CSP). כדי להבין איך האחריות לתקן PCI DSS מתחלקת ביניכם לביןGoogle Cloud, אפשר לעיין במאמר Google Cloud: מטריצת חלוקת האחריות לתקן PCI DSS.
דוגמה נוספת: בארצות הברית, חוק היבילות ואחריות הדיווח של ביטוח בריאות (HIPAA) קובע תקנים לטיפול במידע רפואי אישי אלקטרוני (PHI). האחריות הזו חלה גם על ספק שירותי הענן וגם עליך. מידע נוסף על האופן שבו Google Cloud עומדת באחריות שלה לפי חוק HIPAA זמין במאמר בנושא HIPAA – תאימות.
גם בתעשיות אחרות (לדוגמה, פיננסים או ייצור) יש תקנות שמגדירות איך אפשר לאסוף, לעבד ולאחסן נתונים. מידע נוסף על אחריות משותפת בנושאים האלה ועל האופן שבוGoogle Cloud עומדת באחריות שלה זמין בCompliance resource center.
מוגדר לפי מיקום
בהתאם לתרחיש העסקי, יכול להיות שתצטרכו לקחת בחשבון את האחריות שלכם על סמך המיקום של המשרדים העסקיים, הלקוחות והנתונים שלכם. במדינות ובאזורים שונים נוצרו תקנות שמסבירות איך אפשר לעבד ולאחסן את נתוני הלקוחות. לדוגמה, אם לעסק שלכם יש לקוחות שמתגוררים באיחוד האירופי, יכול להיות שהעסק שלכם יצטרך לפעול בהתאם לדרישות שמתוארות בתקנה הכללית להגנה על מידע (GDPR), ויכול להיות שתהיו מחויבים לשמור את נתוני הלקוחות שלכם באיחוד האירופי עצמו. במקרה כזה, אתם אחראים לוודא שהנתונים שאתם אוספים יישארו באזוריםGoogle Cloud באיחוד האירופי. מידע נוסף על האופן שבו אנחנו עומדים בהתחייבויות שלנו בהתאם ל-GDPR זמין במאמר בנושא GDPR ו- Google Cloud.
מידע על הדרישות שקשורות לאזור שלכם זמין במאמר הצעות לשמירה על תאימות. אם התרחיש שלכם מורכב במיוחד, מומלץ לדבר עם צוות המכירות שלנו או עם אחד השותפים שלנו כדי לקבל עזרה בהערכת האחריות שלכם בנושא אבטחה.
אתגרים שקשורים לאחריות משותפת
אף על פי שמודל האחריות המשותפת עוזר להגדיר את תפקידי האבטחה שיש לכם או לספק שירותי ענן, ההסתמכות על מודל האחריות המשותפת עדיין עלולה ליצור אתגרים. כדאי לעיין בתרחישים הבאים:
- רוב הפרצות באבטחת הענן הן תוצאה ישירה של הגדרות שגויות (מופיע כמספר 3 ב-Pandemic 11 Report של Cloud Security Alliance), והמגמה הזו צפויה להתגבר. מוצרי Cloud משתנים כל הזמן, ואנחנו משיקים מוצרים חדשים באופן קבוע. התעדכנות בשינויים מתמידים יכולה להיות משימה מורכבת. הלקוחות צריכים מספקי ענן שיספקו להם שיטות מומלצות מבוססות-דעות כדי לעזור להם להתעדכן בשינויים, החל משיטות מומלצות כברירת מחדל ועד להגדרת אבטחה בסיסית.
- חלוקת הפריטים לפי שירותי ענן היא מועילה, אבל להרבה ארגונים יש עומסי עבודה שדורשים כמה סוגים של שירותי ענן. במקרה כזה, צריך לבדוק איך אמצעי אבטחה שונים בשירותים האלה פועלים יחד, כולל אם יש חפיפה בין השירותים. לדוגמה, יכול להיות שיש לכם אפליקציה מקומית שאתם מעבירים ל-Compute Engine, שאתם משתמשים ב-Google Workspace לדואר אלקטרוני ארגוני, וגם מפעילים את BigQuery כדי לנתח נתונים ולשפר את המוצרים שלכם.
- העסק והשווקים שלכם משתנים כל הזמן. למשל, כשנכנסים לשווקים חדשים או כשרוכשים חברות אחרות. יכול להיות שבשווקים החדשים שלכם יש דרישות שונות, ושהחברה החדשה שרכשתם מארחת את עומסי העבודה שלה בענן אחר. כדי להתמודד עם השינויים התמידיים, צריך להעריך מחדש את פרופיל הסיכון באופן קבוע וליישם אמצעי בקרה חדשים במהירות.
- ההחלטה איך ומאיפה לנהל את המפתחות להצפנת נתונים (DEK) היא חשובה וקשורה לאחריות שלכם להגן על הנתונים. האפשרות שתבחרו תלויה בדרישות הרגולטוריות, בשאלה אם אתם מפעילים סביבת ענן היברידית או שעדיין יש לכם סביבה מקומית, וברמת הרגישות של הנתונים שאתם מעבדים ומאחסנים.
- ניהול אירועים הוא תחום חשוב, שלעתים קרובות לא מקבל מספיק תשומת לב, שבו לא קל להגדיר את האחריות שלכם ושל ספק שירותי הענן. הרבה אירועים דורשים שיתוף פעולה הדוק ותמיכה מספק שירותי הענן כדי לחקור אותם ולצמצם את ההשפעה שלהם. אירועים אחרים יכולים לנבוע ממשאבי ענן שהוגדרו בצורה לא טובה או מפרטי כניסה גנובים, ויכול להיות מאתגר לוודא שאתם פועלים בהתאם לשיטות המומלצות לאבטחת המשאבים והחשבונות שלכם.
- איומים מתמשכים מתקדמים (APTs) ונקודות חולשה חדשות יכולים להשפיע על עומסי העבודה שלכם בדרכים שאולי לא חשבתם עליהן כשמתחילים את המעבר לענן. קשה להתעדכן בשינויים שחלים בתחום, ולדעת מי אחראי לצמצום האיומים, במיוחד אם לעסק אין צוות אבטחה גדול.
גורל משותף
פיתחנו את המודל 'גורל משותף' 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, שמספק תובנות שמבוססות על נתונים. התובנות האלה יכולות לעזור לכם להבין טוב יותר את מצב האבטחה שלכם בענן. אם אתם מחפשים כיסוי ביטוחי מפני סיכוני סייבר, אתם יכולים לשתף את התובנות האלה ממרכז ביטוח הסייבר ישירות עם חברות הביטוח השותפות שלנו כדי לקבל הצעת מחיר. מידע נוסף זמין במאמר בנושא Google Cloud התוכנית להגנה מסיכונים זמינה עכשיו בגרסת Preview.
עזרה בפריסה ובניהול
האחריות המשותפת עוזרת גם בניהול השוטף של הסביבה. לדוגמה, אנחנו מתמקדים במוצרים כמו:
- Assured Workloads, שמאפשר לעמוד בחובות התאימות.
- Security Command Center Premium, שמשתמש במודיעין איומים, בזיהוי איומים, בסריקת אינטרנט ובשיטות מתקדמות אחרות כדי לנטר ולזהות איומים. בנוסף, הוא מספק דרך לפתור הרבה מהאיומים האלה במהירות ובאופן אוטומטי.
- כללי מדיניות של הארגון והגדרות משאבים שמאפשרים להגדיר כללי מדיניות בכל היררכיית התיקיות והפרויקטים.
- כלים לבקרת מדיניות שמספקים תובנות לגבי גישה לחשבונות ולמשאבים.
- Confidential Computing, שמאפשרת להצפין נתונים בשימוש.
- Sovereign Controls by Partners, שזמינים במדינות מסוימות ועוזרים לאכוף את הדרישות בנוגע למיקום הנתונים.
יישום של אחריות משותפת וגורל משותף
כחלק מתהליך התכנון, כדאי לבצע את הפעולות הבאות כדי להבין את אמצעי האבטחה המתאימים ולהטמיע אותם:
- צריך ליצור רשימה של סוגי עומסי העבודה שתארחו ב-Google Cloud, ולציין אם הם דורשים שירותי IaaS, PaaS ו-SaaS. אפשר להשתמש בתרשים חלוקת האחריות כרשימת משימות כדי לוודא שאתם מכירים את אמצעי הבקרה לאבטחה שאתם צריכים לקחת בחשבון.
- יוצרים רשימה של דרישות רגולטוריות שאתם צריכים לעמוד בהן, וניגשים למשאבים במרכז המשאבים בנושא תאימות שקשורים לדרישות האלה.
- במרכז הארכיטקטורה תוכלו לעיין ברשימה של תוכניות וארכיטקטורות זמינות כדי למצוא את אמצעי הבקרה לאבטחה שדרושים לעומסי העבודה הספציפיים שלכם. בתוכניות מפורטים אמצעי הבקרה המומלצים וקוד ה-IaC שדרוש לפריסת הארכיטקטורה.
- כדי לעצב היררכיית משאבים וארכיטקטורת רשת שעונות על הדרישות שלכם, תוכלו להיעזר במסמכי ההסבר על אזור הנחיתה ובהמלצות שבמדריך היסודות לארגונים. כדי להאיץ את תהליך הפיתוח, תוכלו להשתמש בתוכניות מפורטות לעומסי עבודה, כמו מחסן נתונים מאובטח.
- אחרי שפורסים את עומסי העבודה, צריך לוודא שאתם עומדים באחריות שלכם בנושא אבטחה באמצעות שירותים כמו Cyber Insurance Hub, Assured Workloads, כלים לבקרת מדיניות ו-Security Command Center Premium.
מידע נוסף זמין במאמר בנושא המדריך של מנהל אבטחת המידע (CISO) למעבר לענן.
המאמרים הבאים
- כדאי לעיין בעקרונות האבטחה המרכזיים.
- חשוב להתעדכן במשאבים בנושא גורל משותף.
- כדאי לעיין בתוכניות שזמינות, כולל התוכנית לניהול יסודות האבטחה ודוגמאות לעומסי עבודה כמו מחסן נתונים מאובטח.
- מידע נוסף על גורל משותף
- במאמר סקירה כללית על תכנון האבטחה בתשתית של Google תוכלו לקרוא על התשתית הבסיסית המאובטחת שלנו.
- כאן Google Cloud (PDF) אפשר לקרוא איך מטמיעים שיטות מומלצות של NIST Cybersecurity Framework.