ההמלצות שמופיעות בעמודה 'אבטחה, פרטיות ועמידה בדרישות' בGoogle Cloud מסגרת Well-Architected יעזרו לכם לתכנן, לפרוס ולהפעיל עומסי עבודה בענן שעומדים בדרישות שלכם בנוגע לאבטחה, לפרטיות ולעמידה בדרישות.
המסמך הזה נועד לספק תובנות חשובות ולענות על הצרכים של מגוון אנשי מקצוע ומהנדסים בתחום האבטחה. בטבלה הבאה מתוארים הקהלים שאליהם מיועד המסמך הזה:
| קהל | מה כולל המסמך הזה |
|---|---|
| מנהלי אבטחת מידע (CISO), מנהלי יחידות עסקיות ומנהלי IT | מסגרת כללית להקמה ולתחזוקה של אבטחה מצוינת בענן, ולוודא שיש תצוגה מקיפה של אזורי אבטחה כדי לקבל החלטות מושכלות לגבי השקעות באבטחה. |
| אדריכלים ומהנדסי אבטחה | שיטות עבודה מומלצות לאבטחה בשלבי התכנון והתפעול, שיעזרו לכם לוודא שהפתרונות מתוכננים לאבטחה, ליעילות ולגמישות. |
| צוותי DevSecOps | הנחיות לשילוב אמצעי בקרה כוללים לאבטחה, כדי לתכנן אוטומציה שתאפשר תשתית מאובטחת ומהימנה. |
| קציני תאימות ומנהלי סיכונים | המלצות חשובות בנושא אבטחה שיעזרו לכם לנהל את הסיכונים בצורה מסודרת ולעמוד בדרישות התאימות. |
כדי לוודא שעומסי העבודה שלכם עומדים בדרישות האבטחה, הפרטיות והתאימות, כל בעלי העניין בארגון צריכים לאמץ גישה שיתופית. Google Cloud בנוסף, חשוב להבין שאבטחת הענן היא אחריות משותפת שלכם ושל Google. מידע נוסף זמין במאמר בנושא חלוקת אחריות וגורל משותף ב- Google Cloud.
ההמלצות בעמודה הזו מקובצות לפי עקרונות אבטחה מרכזיים. כל המלצה שמבוססת על עקרון ממופה לאחד או יותר מתחומי המיקוד באבטחת הענן, שעשויים להיות קריטיים לארגון שלכם. כל המלצה כוללת הנחיות לגבי השימוש במוצרים וביכולות שלGoogle Cloud וההגדרה שלהם, כדי לשפר את מצב האבטחה של הארגון.
עקרונות ליבה
ההמלצות בקטגוריה הזו מקובצות לפי עקרונות הליבה הבאים של אבטחה. כל עיקרון בעמודה הזו חשוב. בהתאם לדרישות של הארגון ועומס העבודה, יכול להיות שתבחרו לתת עדיפות לעקרונות מסוימים.
- הטמעת אבטחה כבר בשלב התכנון: שילוב שיקולי אבטחת ענן ואבטחת רשת כבר בשלב התכנון הראשוני של האפליקציות והתשתית.Google Cloud מספקת תוכניות אדריכליות והמלצות שיעזרו לכם ליישם את העיקרון הזה.
- הטמעה של מודל אבטחה של אפס אמון: שימוש בגישה של לא לסמוך, תמיד לאמת, שבה הגישה למשאבים ניתנת על סמך אימות רציף של האמון. Google Cloudתומכת בעיקרון הזה באמצעות מוצרים כמו Chrome Enterprise Premium ו-שרת proxy לאימות זהויות (IAP).
- הטמעת אבטחה מוקדמת (Shift-Left): הטמעת אמצעי בקרה לאבטחה בשלב מוקדם במחזור החיים של פיתוח התוכנה. למנוע פגמים באבטחה לפני ביצוע שינויים במערכת. זיהוי ותיקון של באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן אחרי שהשינויים במערכת נשמרים. 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, 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 לאבטחה מובנית, המונחים אבטחה מובנית ואבטחה כברירת מחדל משמשים לעיתים קרובות לסירוגין, אבל הם מייצגים גישות שונות לבניית מערכות מאובטחות. שתי הגישות נועדו לצמצם את נקודות החולשה ולשפר את האבטחה, אבל הן שונות בהיקף ובאופן ההטמעה:
- מאובטח כברירת מחדל: מתמקד בהבטחה שברירות המחדל של המערכת מוגדרות למצב מאובטח, וכך מצמצם את הצורך של משתמשים או אדמינים לבצע פעולות כדי לאבטח את המערכת. המטרה של הגישה הזו היא לספק רמת אבטחה בסיסית לכל המשתמשים.
- אבטחה משלב התכנון: גישה שבה משלבים באופן יזום שיקולי אבטחה לאורך מחזור החיים של פיתוח המערכת. הגישה הזו מתמקדת בחיזוי מוקדם של איומים ונקודות חולשה פוטנציאליים, ובביצוע בחירות עיצוביות שמצמצמות את הסיכונים. הגישה הזו כוללת שימוש בשיטות קידוד מאובטחות, ביצוע בדיקות אבטחה ושילוב אבטחה בתהליך התכנון. הגישה'אבטחה משלב התכנון' היא פילוסופיה כוללת שמנחה את תהליך הפיתוח ועוזרת להבטיח שהאבטחה לא תהיה מחשבה משנית, אלא חלק בלתי נפרד מהעיצוב של המערכת.
המלצות
כדי להטמיע את העיקרון 'אבטחה מובנית' בעומסי העבודה בענן, כדאי לעיין בהמלצות שבקטעים הבאים:
- בחירת רכיבי מערכת שיעזרו לכם לאבטח את עומסי העבודה
- בניית גישה רב-שכבתית לאבטחה
- שימוש בתשתית ובשירותים מאובטחים ומאומתים
- הצפנה של נתונים באחסון ובתנועה
בחירת רכיבי מערכת שיעזרו לאבטח את עומסי העבודה
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
כדי להבטיח אבטחה יעילה, חשוב לבחור רכיבי מערכת חזקים – כולל רכיבי חומרה ותוכנה – שמרכיבים את הפלטפורמה, הפתרון או השירות שלכם. כדי לצמצם את פני השטח של האבטחה ולמזער את הנזק הפוטנציאלי, חשוב גם לשקול בקפידה את דפוסי הפריסה של הרכיבים האלה ואת ההגדרות שלהם.
בקוד האפליקציה, מומלץ להשתמש בספריות, בהפשטות ובמסגרות אפליקציה פשוטות, בטוחות ואמינות כדי למנוע סוגים של נקודות חולשה. כדי לסרוק פרצות אבטחה בספריות תוכנה, אפשר להשתמש בכלים של צד שלישי. אפשר גם להשתמש ב-Assured Open Source Software, שמאפשר לצמצם את הסיכונים בשרשרת אספקת התוכנה באמצעות שימוש בחבילות של תוכנות קוד פתוח (OSS) ש-Google משתמשת בהן ומאבטחת אותן.
התשתית שלכם צריכה להשתמש באפשרויות של רשת, אחסון ומחשוב שתומכות בפעולה בטוחה, ומתאימות לדרישות האבטחה ולרמות הסיכון המקובלות. אבטחת התשתית חשובה לעומסי עבודה שפונים לאינטרנט ולעומסי עבודה פנימיים.
מידע על פתרונות אחרים של Google שתומכים בהמלצה הזו זמין במאמר הטמעה של אבטחה מוקדמת.
בניית גישה רב-שכבתית לאבטחה
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- אבטחה של AI ו-ML
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
מומלץ להטמיע אבטחה בכל שכבה של ערימת האפליקציות והתשתית באמצעות גישה של הגנה לעומק.
משתמשים בתכונות האבטחה בכל רכיב בפלטפורמה. כדי להגביל את הגישה ולזהות את גבולות ההשפעה הפוטנציאלית (כלומר, רדיוס הפיצוץ) במקרה של אירוע אבטחה, צריך לבצע את הפעולות הבאות:
- כדאי לפשט את עיצוב המערכת כדי לאפשר גמישות ככל האפשר.
- מתעדים את דרישות האבטחה של כל רכיב.
- לשלב מנגנון מאובטח וחזק כדי לעמוד בדרישות של חוסן (resilience) והתאוששות.
כשמתכננים את שכבות האבטחה, כדאי לבצע הערכת סיכונים כדי לקבוע אילו תכונות אבטחה נדרשות כדי לעמוד בדרישות אבטחה פנימיות ודרישות רגולטוריות חיצוניות. מומלץ להשתמש במסגרת להערכת סיכונים לפי תקנים בתעשייה, שרלוונטית לדרישות הרגולטוריות שלכם ומתאימה לסביבות ענן. לדוגמה, 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, שמתעדכנים ומתוקנים באופן אוטומטי. כדי לצמצם עוד יותר את שטח הפנים להתקפה של הקונטיינרים, אפשר להשתמש בתמונות ללא הפצה. תמונות ללא הפצה הן אידיאליות לאפליקציות רגישות לאבטחה, למיקרו-שירותים ולמצבים שבהם צמצום גודל התמונה ושטח הפריצה הוא בעל חשיבות עליונה.
לעומסי עבודה רגישים, כדאי להשתמש ב-מכונה וירטואלית מוגנת, שמונעת טעינה של קוד זדוני במהלך מחזור האתחול של ה-VM. מכונות וירטואליות מוגנות מספקות אבטחת אתחול, מנטרות את התקינות ומשתמשות במודול פלטפורמה וירטואלית מהימנה (vTPM).
כדי לאבטח את הגישה באמצעות SSH, אפשר להשתמש ב-OS Login. כך העובדים יכולים להתחבר למכונות הווירטואליות באמצעות הרשאות לניהול זהויות והרשאות גישה (IAM) כמקור המהימנות, במקום להסתמך על מפתחות SSH. לכן, לא צריך לנהל מפתחות SSH בכל הארגון. הכניסה באמצעות 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. כל תעבורת הנתונים מ-VM ל-VM בתוך רשת VPC ובין רשתות VPC שמקושרות לרשתות שכנות, עוברת הצפנה. אתם יכולים להשתמש ב-MACsec להצפנת תנועה בחיבורי Cloud Interconnect. פרוטוקול IPsec מספק הצפנה לתנועת הנתונים בחיבורים של Cloud VPN. כדי להגן על התעבורה בין אפליקציות בענן, אפשר להשתמש בתכונות אבטחה כמו הגדרות TLS ו-mTLS ב-Apigee ו-Cloud Service Mesh לאפליקציות מבוססות-קונטיינרים.
כברירת מחדל, Google Cloud הנתונים מוצפנים גם כשהם באחסון וגם כשהם מועברים ברשת. עם זאת, הנתונים לא מוצפנים כברירת מחדל בזמן השימוש בהם בזיכרון. אם הארגון שלכם מטפל בנתונים סודיים, אתם צריכים לצמצם את הסיכון לאיומים שפוגעים בסודיות ובשלמות של האפליקציה או של הנתונים בזיכרון המערכת. כדי לצמצם את האיומים האלה, אפשר להשתמש ב-Confidential Computing, שמספק סביבת מחשוב אמינה לעומסי העבודה שלכם. מידע נוסף זמין במאמר סקירה כללית על מכונות וירטואליות חסויות.
הטמעה של מודל אבטחה של אפס אמון
העיקרון הזה, שנכלל בעמודת האבטחה של 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 Service Controls.
- אבטחת היקף: הגנה מפני התקפות DDoS ואיומים על אפליקציות אינטרנט.
- כדי להגן מפני איומים, אפשר להשתמש ב-Google Cloud Armor.
- הגדרת מדיניות אבטחה שמאפשרת, דוחה או מפנה תנועה ב-Google Cloud edge.
- אוטומציה: כדי להקצות תשתית באופן אוטומטי, צריך להשתמש בעקרונות של תשתית כקוד (IaC) ובכלים כמו Terraform, Jenkins ו-Cloud Build. IaC עוזרת להבטיח הגדרות אבטחה עקביות, פריסות פשוטות וחזרה מהירה לגרסה קודמת במקרה של בעיות.
- תשתית מאובטחת: כדי ליצור סביבת אפליקציות מאובטחת, אפשר להשתמש בתוכנית הבסיס של Enterprise. בתוכנית הזו מפורטות הנחיות וסקריפטים לאוטומציה שיעזרו לכם להטמיע שיטות מומלצות לאבטחה ולהגדיר את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 וhardened GKE clusters ב- Google Cloud.
- איתור ותיקון של באגים באבטחה בשלב מוקדם, במהירות ובאופן מהימן אחרי ביצוע שינויים במערכת. כדאי לאמץ שיטות עבודה כמו בדיקות קוד, סריקת נקודות חולשה אחרי הפריסה ובדיקות אבטחה.
העקרונות יישום אבטחה משלב התכנון ואבטחה משמאל קשורים זה לזה, אבל הם שונים בהיקף שלהם. העיקרון של אבטחה מובנית עוזר לכם להימנע מפגמים בסיסיים בעיצוב, שידרשו שינוי ארכיטקטורה של המערכת כולה. לדוגמה, תרגיל של מידול איומים מגלה שהעיצוב הנוכחי לא כולל מדיניות הרשאות, וכל המשתמשים יקבלו את אותה רמת גישה ללא המדיניות. גישת Shift-left security עוזרת לכם להימנע מפגמים בהטמעה (באגים וטעויות בהגדרות) לפני החלת השינויים, ומאפשרת תיקונים מהירים ואמינים אחרי הפריסה.
המלצות
כדי ליישם את עקרון האבטחה 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 אנחנו מספקים את התוכנית של enterprise foundations. התוכנית הזו היא דעה מגובשת של Google לגבי עיצוב, והיא פועלת בהתאם לכל השיטות המומלצות וההגדרות שלנו. התוכנית מספקת הוראות מפורטות להגדרה ולפריסה של טופולוגיית Google Cloud באמצעות Terraform ו-Cloud Build.
אתם יכולים לשנות את הסקריפטים של תוכנית ה-blueprint של Enterprise Foundations כדי להגדיר סביבה שתפעל בהתאם להמלצות של Google ותעמוד בדרישות האבטחה שלכם. אפשר להוסיף עוד תוכניות לתוכנית הקיימת או ליצור אוטומציה משלכם.Google Cloud במרכז הארכיטקטורה יש תוכניות נוספות שאפשר להטמיע בנוסף לתוכנית לניהול יסודות האבטחה. הנה כמה דוגמאות לתוכניות האלה:
- פריסת פלטפורמת פיתוח לארגונים ב- Google Cloud
- פריסת ארכיטקטורה מאובטחת בלי שרת (serverless) באמצעות 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 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 בכל ההיבטים של הגנת סייבר
- הבנה של היתרון של המגן וניצול שלו
- אימות ושיפור מתמשכים של אמצעי ההגנה
- ניהול ותיאום של מאמצי הגנה מפני מתקפות סייבר
שילוב הפונקציות של הגנת סייבר
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
מסגרת היתרון של המגן מזהה שש פונקציות קריטיות של הגנה מפני מתקפות סייבר: מודיעין, זיהוי, תגובה, אימות, חיפוש ושליטה במשימה. כל פונקציה מתמקדת בחלק ייחודי של משימת ההגנה מפני איומי סייבר, אבל הפונקציות האלה צריכות להיות מתואמות היטב ולפעול יחד כדי לספק הגנה יעילה. חשוב להתמקד בבניית מערכת חזקה ומשולבת שבה כל פונקציה תומכת בפונקציות האחרות. אם אתם צריכים גישה מדורגת להטמעה, כדאי לשקול את הסדר המוצע הבא. בהתאם לרמת הבשלות הנוכחית של הענן, לטופולוגיית המשאבים ולנוף האיומים הספציפי, יכול להיות שתעדיפו לתת עדיפות לפונקציות מסוימות.
- Intelligence: הפונקציה הזו מנחה את כל הפונקציות האחרות. הבנת נוף האיומים – כולל התוקפים הסבירים ביותר, הטקטיקות, הטכניקות והנהלים שלהם (TTP) וההשפעה הפוטנציאלית – היא קריטית כדי לתעדף פעולות בכל התוכנית. הפונקציה 'מודיעין' אחראית על זיהוי בעלי עניין, הגדרה של דרישות מודיעין, איסוף נתונים, ניתוח והפצה, אוטומציה ויצירה של פרופיל איומי סייבר.
- זיהוי ותגובה: הפונקציות האלה הן הליבה של ההגנה הפעילה, שכוללת זיהוי של פעילות זדונית וטיפול בה. הפונקציות האלה נחוצות כדי לפעול על סמך המידע שנאסף על ידי פונקציית ה-Intelligence. הפונקציה Detect (זיהוי) דורשת גישה שיטתית שמתאימה את הזיהויים לטקטיקות, לטכניקות ולנהלים (TTP) של התוקף, ומבטיחה רישום חזק ביומן. הפונקציה Respond צריכה להתמקד במיון ראשוני, באיסוף נתונים ובתיקון האירוע.
- אימות: פונקציית האימות היא תהליך מתמשך שמבטיח שסביבת הבקרה של האבטחה מעודכנת ופועלת כמתוכנן. הפונקציה הזו מבטיחה שהארגון יבין את פני השטח של המתקפה, יידע איפה קיימות נקודות חולשה וימדוד את יעילות אמצעי הבקרה. אימות האבטחה הוא גם רכיב חשוב במחזור החיים של הנדסת הזיהוי, וצריך להשתמש בו כדי לזהות פערים בזיהוי וליצור זיהויים חדשים.
- Hunt (ציד): הפונקציה Hunt כוללת חיפוש יזום של איומים פעילים בסביבה. צריך להטמיע את הפונקציה הזו כשהארגון מגיע לרמת בגרות בסיסית בפונקציות 'זיהוי' ו'תגובה'. הפונקציה Hunt מרחיבה את יכולות הזיהוי ועוזרת לזהות פערים וחולשות באמצעי הבקרה. הפונקציה Hunt צריכה להתבסס על איומים ספציפיים. הפונקציה המתקדמת הזו נהנית מיתרונות של יכולות מודיעין, זיהוי ותגובה חזקות.
- Mission Control: הפונקציה Mission Control משמשת כמרכז שמקושרות אליו כל הפונקציות האחרות. הפונקציה הזו אחראית על האסטרטגיה, התקשורת ופעולות נחרצות במסגרת תוכנית ההגנה הקיברנטית שלכם. היא מוודאת שכל הפונקציות פועלות יחד ושהן תואמות ליעדים העסקיים של הארגון. לפני שמשתמשים בפונקציה Mission Control כדי לקשר בין הפונקציות האחרות, חשוב להבין בבירור את המטרה שלה.
שימוש בפונקציית ה-Intelligence בכל ההיבטים של הגנת סייבר
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
בהמלצה הזו מודגש התפקיד של פונקציית ה-Intelligence כחלק מרכזי בתוכנית חזקה להגנה מפני מתקפות סייבר. מודיעין איומי סייבר מספק ידע על גורמי איום, על TTPs שלהם ועל סימנים מחשידים (IoC). הידע הזה צריך להנחות אתכם ולעזור לכם לקבוע סדרי עדיפויות בפעולות שקשורות לכל הפונקציות של הגנה מפני איובר. גישה מבוססת-מודיעין עוזרת לכם להתאים את אמצעי ההגנה כדי להתמודד עם האיומים שסביר להניח שישפיעו על הארגון שלכם. הגישה הזו גם עוזרת להקצות משאבים בצורה יעילה ולתת להם עדיפות.
המוצרים והתכונות הבאים עוזרים לכם להשתמש במודיעין איומי סייבר כדי להנחות את תפעול האבטחה (SecOps) שלכם. Google Cloud אתם יכולים להשתמש בתכונות האלה כדי לזהות איומים, נקודות חולשה וסיכונים פוטנציאליים ולתעדף אותם, ואז לתכנן ולבצע פעולות מתאימות.
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 מרכזת את נתוני האבטחה ומספקת יומנים מועשרים עם ציר זמן. כך המגינים יכולים לזהות באופן יזום פשרות פעילות ולהתאים את אמצעי ההגנה על סמך התנהגות התוקפים.
ניטור הרשת עוזר לזהות פעילות חריגה ברשת שעשויה להצביע על מתקפה, ומספק אינדיקטורים מוקדמים שבעזרתם אפשר לפעול. כדי להגן על הנתונים מפני גניבה, מומלץ לעקוב כל הזמן אחרי זליגת נתונים ולהשתמש בכלים שסיפקנו.
אימות ושיפור אמצעי ההגנה באופן רציף
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
בהמלצה הזו אנחנו מדגישים את החשיבות של בדיקות ממוקדות ותיקוף רציף (CV) של אמצעי הבקרה, כדי להבין את החוזקות והחולשות בכל שטחי ההתקפה. זה כולל אימות של יעילות אמצעי הבקרה, הפעולות והצוות באמצעות שיטות כמו:
- בדיקות חדירה
- תרגילים של הצוות האדום-כחול ושלהצוות הסגול
- תרגילים שולחניים
בנוסף, עליכם לחפש באופן פעיל איומים ולהשתמש בתוצאות כדי לשפר את יכולות הזיהוי והחשיפה. כדי לבדוק ולאמת באופן רציף את אמצעי ההגנה שלכם מפני איומים בעולם האמיתי, אתם יכולים להשתמש בכלים הבאים:
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 ולשרשרת האספקה. כדי לטפל בהמלצה הזו, אפשר לפעול לפי השלבים הבאים:
- הטמעה של סביבה מאובטחת להדרכה ולפריסה של ML
- שימוש בתמונות מאומתות של מאגרי תגים
- הטמעה של ההנחיות בנושא Supply-chain Levels for Software Artifacts (SLSA)
הגנה על מקורות קלט ומעקב אחריהם
ההמלצה הזו רלוונטית לתחומי ההתמקדות הבאים:
- רישום ביומן, ביקורת ומעקב
- תפעול אבטחה (SecOps)
- אבטחה של AI ו-ML
ההמלצה הזו תואמת לרכיב SAIF בנושא הרחבת הזיהוי והתגובה כדי לשלב AI בתהליכי הטיפול באיומים בארגון. כדי למנוע בעיות, חשוב לנהל את ההנחיות למערכות AI גנרטיבי, לעקוב אחרי הקלט ולשלוט בגישת המשתמשים.
המלצות לניהול AI
כל ההמלצות בקטע הזה רלוונטיות לתחום ההתמקדות הבא: ניהול, סיכונים ותאימות בענן.
Google Cloud מציעה קבוצה חזקה של כלים ושירותים שבהם אפשר להשתמש כדי לבנות מערכות AI אחראיות ואתיות. אנחנו מציעים גם מסגרת של מדיניות, נהלים ושיקולים אתיים שיכולים להנחות אתכם בפיתוח, בפריסה ובשימוש במערכות AI.
כפי שמשתקף בהמלצות שלנו, הגישה של Google לפיקוח על AI מבוססת על העקרונות הבאים:
- הוגנות
- שקיפות
- אחריותיות
- פרטיות
- אבטחה
שימוש במדדי הוגנות
Vertex AI יכול לזהות הטיה במהלך תהליך איסוף הנתונים או תהליך ההערכה אחרי האימון. Vertex AI מספק מדדים להערכת מודלים כמו הטיה בנתונים והטיה במודל, כדי לעזור לכם להעריך את המודל שלכם ולבדוק אם יש בו הטיה.
המדדים האלה קשורים להוגנות בקטגוריות שונות כמו גזע, מגדר ומעמד. עם זאת, פירוש סטיות סטטיסטיות הוא לא תרגיל פשוט, כי יכול להיות שההבדלים בין הקטגוריות לא נובעים מהטיה או מהצגת תוכן מזיק.
שימוש ב-Vertex AI ניתן להסברה
כדי להבין איך מודלים של AI מקבלים החלטות, אפשר להשתמש ב-Vertex AI ניתן להסברה. התכונה הזו עוזרת לכם לזהות הטיה פוטנציאלית שעשויה להיות חבויה בלוגיקה של המודל.
תכונת ההסבר הזו משולבת עם BigQuery ML ועם Vertex AI, ומספקת הסברים שמבוססים על מאפיינים. אפשר לבצע הסבר על מודל ב-BigQuery ML או לרשום את המודל ב-Vertex AI ולבצע הסבר על מודל ב-Vertex AI.
מעקב אחר שושלת נתונים
עוקבים אחרי המקור והטרנספורמציה של הנתונים שמשמשים במערכות ה-AI. המעקב הזה עוזר לכם להבין את המסלול של הנתונים ולזהות מקורות פוטנציאליים להטיה או לשגיאה.
Data lineage היא תכונה של Dataplex Universal 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 לוקח על עצמו יותר אחריות למשימת האבטחה.
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.
סקירה כללית של העקרונות
עמידה בדרישות הרגולציה, התאימות והפרטיות היא אתגר שכל העסקים חייבים להתמודד איתו. הדרישות הרגולטוריות ב-Cloud תלויות בכמה גורמים, כולל:
- החוקים והתקנות שחלים על המיקומים הפיזיים של הארגון
- החוקים והתקנות שחלים על המיקומים הפיזיים של הלקוחות שלכם
- הדרישות הרגולטוריות בענף שלכם
תקנות בנושא פרטיות מגדירות איך אפשר לקבל, לעבד, לאחסן ולנהל את הנתונים של המשתמשים. הנתונים שלכם שייכים לכם, כולל הנתונים שאתם מקבלים מהמשתמשים. לכן, הרבה אמצעי בקרה לשמירה על הפרטיות הם באחריותכם, כולל אמצעי בקרה לקובצי Cookie, לניהול סשנים ולקבלת הרשאת משתמש.
ההמלצות ליישום העיקרון הזה מקובצות בקטעים הבאים:
- המלצות לטיפול בסיכונים ארגוניים
- המלצות לטיפול בהתחייבויות רגולטוריות ובהתחייבויות לעמידה בדרישות
- המלצות לניהול ריבונות הנתונים
- המלצות לטיפול בדרישות בנושא פרטיות
המלצות לטיפול בסיכונים ארגוניים
בקטע הזה מפורטות המלצות שיעזרו לכם לזהות סיכונים לארגון ולטפל בהם.
זיהוי סיכונים לארגון
ההמלצה הזו רלוונטית לתחום ההתמקדות הבא: ניהול, סיכונים ותאימות בענן.
לפני שיוצרים ומפריסים משאבים ב- Google Cloud, צריך להשלים הערכת סיכונים. במסגרת ההערכה הזו, צריך לקבוע אילו תכונות אבטחה נדרשות כדי לעמוד בדרישות האבטחה הפנימיות ובדרישות הרגולטוריות החיצוניות.
הערכת הסיכונים מספקת קטלוג של סיכונים ספציפיים לארגון, ומסבירה על היכולת של הארגון לזהות איומי אבטחה ולנטרל אותם. אתם צריכים לבצע ניתוח סיכונים מיד אחרי הפריסה, וגם בכל פעם שיש שינויים בצרכים העסקיים, בדרישות הרגולטוריות או באיומים על הארגון.
כמו שצוין בעקרון הטמעת אבטחה משלב התכנון, הסיכונים לאבטחה בסביבת ענן שונים מהסיכונים בסביבה מקומית. ההבדל הזה נובע ממודל האחריות המשותפת בענן, שמשתנה בהתאם לשירות (IaaS, PaaS או SaaS) ולשימוש שלכם. משתמשים במסגרת להערכת סיכונים שספציפית לענן, כמו מטריצת בקרת הענן (CCM). כדאי להשתמש במידול איומים, כמו OWASP application threat modeling, כדי לזהות נקודות חולשה ולטפל בהן. כדי לקבל עזרה ממומחים בהערכות סיכונים, אפשר לפנות לאיש הקשר האחראי לחשבון 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 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: תיעוד של זרימות תעבורת נתונים ברשת שנשלחות או מתקבלות על ידי מכונות וירטואליות.
- 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. בנוסף, Dataplex Universal 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) או ללא שרת | פונקציות כשירות (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.
גם בתעשיות אחרות (לדוגמה, פיננסים או ייצור) יש תקנות שמגדירות איך אפשר לאסוף, לעבד ולאחסן נתונים. מידע נוסף על חלוקת האחריות בנושאים האלה ועל האופן שבוGoogle Cloud עומדת באחריות שלה זמין במרכז המשאבים בנושא תאימות.
מוגדר לפי מיקום
בהתאם לתרחיש העסקי, יכול להיות שתצטרכו לקחת בחשבון את האחריות שלכם על סמך המיקום של המשרדים העסקיים, הלקוחות והנתונים שלכם. במדינות ובאזורים שונים נוצרו תקנות שמסבירות איך אפשר לעבד ולאחסן את נתוני הלקוחות. לדוגמה, אם לעסק שלכם יש לקוחות שמתגוררים באיחוד האירופי, יכול להיות שתצטרכו לפעול בהתאם לדרישות שמתוארות בתקנה הכללית להגנה על מידע (GDPR), ויכול להיות שתהיו מחויבים לשמור את נתוני הלקוחות שלכם באיחוד האירופי עצמו. במקרה כזה, אתם אחראים לוודא שהנתונים שאתם אוספים יישארו באזוריGoogle Cloud באיחוד האירופי. מידע נוסף על האופן שבו אנחנו עומדים בדרישות של GDPR זמין במאמר בנושא GDPR ו- Google Cloud.
מידע על הדרישות שקשורות לאזור שלכם זמין במאמר הצעות לשמירה על תאימות. אם התרחיש שלכם מורכב במיוחד, מומלץ לדבר עם צוות המכירות שלנו או עם אחד השותפים שלנו כדי לקבל עזרה בהערכת האחריות שלכם בנושא אבטחה.
אתגרים באחריות משותפת
אחריות משותפת עוזרת להגדיר את תפקידי האבטחה שלכם או של ספק שירותי הענן, אבל עדיין יכולים להיות אתגרים בהסתמכות על אחריות משותפת. כדאי להביא בחשבון את התרחישים הבאים:
- רוב הפרצות באבטחת הענן הן תוצאה ישירה של הגדרה שגויה (מופיעה במקום השלישי ב-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. אתם יכולים להשתמש בדיאגרמת האחריות המשותפת כרשימת משימות כדי לוודא שאתם מכירים את אמצעי הבקרה לאבטחה שאתם צריכים לקחת בחשבון.
- יוצרים רשימה של דרישות רגולטוריות שאתם צריכים לעמוד בהן, וניגשים למשאבים בCompliance resource center שקשורים לדרישות האלה.
- במרכז הארכיטקטורה תוכלו לעיין ברשימה של תוכניות וארכיטקטורות זמינות כדי למצוא את אמצעי הבקרה לאבטחה שנדרשים לעומסי העבודה הספציפיים שלכם. התוכניות מספקות רשימה של אמצעי בקרה מומלצים וקוד IaC שנדרש לפריסת הארכיטקטורה הזו.
- כדי לעצב היררכיית משאבים וארכיטקטורת רשת שעונות על הדרישות שלכם, תוכלו להיעזר במסמכי ההסבר על אזור הנחיתה ובהמלצות שבמדריך לשימוש ב-Enterprise Foundations. כדי להאיץ את תהליך הפיתוח, אפשר להשתמש בתוכניות מפורטות של עומסי עבודה, כמו מחסן נתונים מאובטח.
- אחרי שפורסים את עומסי העבודה, צריך לוודא שאתם עומדים באחריות שלכם בנושא אבטחה באמצעות שירותים כמו Cyber Insurance Hub, Assured Workloads, כלים לבקרת מדיניות ו-Security Command Center Premium.
מידע נוסף זמין במאמר CISO's Guide to Cloud Transformation.
המאמרים הבאים
- כדאי לעיין בעקרונות האבטחה המרכזיים.
- חשוב להתעדכן במשאבים בנושא גורל משותף.
- כדאי לעיין בתוכניות שזמינות, כולל התוכנית לניהול יסודות האבטחה ודוגמאות לעומסי עבודה כמו מחסן נתונים מאובטח.
- מידע נוסף על גורל משותף
- במאמר סקירה כללית על תכנון האבטחה בתשתית של Google תוכלו לקרוא על התשתית הבסיסית המאובטחת שלנו.
- כאן Google Cloud (PDF) אפשר לקרוא איך מטמיעים שיטות מומלצות של NIST Cybersecurity Framework.