העיקרון הזה בעמוד התווך של האבטחה ב-Google Cloud Well-Architected Framework מספק המלצות לשילוב תכונות, אמצעי בקרה ושיטות אבטחה חזקות בתכנון של האפליקציות, השירותים והפלטפורמות בענן. מהעלאת רעיונות ועד לתפעול, האבטחה יעילה יותר כשהיא מוטמעת כחלק בלתי נפרד מכל שלב בתהליך התכנון.
סקירה כללית של העקרונות
במאמר סקירה כללית על המחויבות של Google לאבטחה מובנית מוסבר שלעיתים קרובות משתמשים במונחים אבטחה כברירת מחדל ואבטחה מובנית באופן חלופי, אבל הם מייצגים גישות שונות ליצירת מערכות מאובטחות. שתי הגישות נועדו לצמצם את נקודות החולשה ולשפר את האבטחה, אבל הן שונות בהיקף ובהטמעה:
- אבטחה כברירת מחדל: התמקדות בהגדרות ברירת המחדל של המערכת כדי לוודא שהן מאובטחות, וכך לצמצם את הצורך של המשתמשים או האדמינים לבצע פעולות לאבטחת המערכת. הגישה הזו נועדה לספק רמת אבטחה בסיסית לכל המשתמשים.
- אבטחה משלב התכנון (secure-by-design): הדגשת השילוב היזום של שיקולי אבטחה לאורך מחזור החיים של פיתוח המערכת. הגישה הזו מתמקדת בחיזוי מוקדם של איומים ונקודות חולשה פוטנציאליים, ובבחירת עיצובים שמפחיתים את הסיכונים. הגישה הזו כוללת שימוש בשיטות קידוד מאובטחות, ביצוע בדיקות אבטחה והטמעת אבטחה לאורך כל תהליך התכנון. הגישה של אבטחה משלב התכנון היא פילוסופיה כוללת שמנחה את תהליך הפיתוח ועוזרת להבטיח שהאבטחה היא לא מחשבה מאוחרת, אלא חלק בלתי נפרד מהתכנון של המערכת.
המלצות
כדי ליישם את העיקרון "אבטחה כחלק מהתכנון" בעומסי העבודה בענן, כדאי לפעול לפי ההמלצות שבקטעים הבאים:
- בחירת רכיבי מערכת שעוזרים לאבטח את עומסי העבודה
- גישת אבטחה רב-שכבתית
- שימוש בתשתית ובשירותים מאובטחים ומאומתים
- הצפנת נתונים במנוחה ובמעבר
בחירת רכיבי מערכת שעוזרים לאבטח את עומסי העבודה
ההמלצה הזו רלוונטית לכל תחומי המיקוד.
אחת ההחלטות החשובות ביותר בנוגע לאבטחה יעילה היא בחירת רכיבי מערכת חזקים – כולל רכיבי חומרה ותוכנה – שמהווים את הפלטפורמה, הפתרון או השירות שלכם. כדי לצמצם את שטח המתקפה ולהגביל את הנזק הפוטנציאלי, חשוב גם לשקול היטב את דפוסי הפריסה של הרכיבים האלה ואת ההגדרות שלהם.
בקוד האפליקציה, מומלץ להשתמש בספריות, בהפשטות ובמסגרות של אפליקציות שהן פשוטות, בטוחות ואמינות, כדי למנוע סוגים שונים של נקודות חולשה. כדי לסרוק נקודות חולשה בספריות תוכנה, אתם יכולים להשתמש בכלים של צד שלישי. אתם יכולים גם להשתמש ב-Assured Open Source Software, שעוזרת לצמצם את הסיכונים לשרשרת אספקת התוכנה באמצעות חבילות של תוכנות קוד פתוח (OSS) ש-Google משתמשת בהן ומאבטחת אותן.
התשתית צריכה להשתמש באפשרויות של רשת, אחסון ומחשוב שתומכות בפעולה בטוחה, ותואמות לדרישות האבטחה ולרמות קבלת הסיכונים שלכם. אבטחת התשתית חשובה גם לעומסי עבודה שפונים לאינטרנט וגם לעומסי עבודה פנימיים.
במאמר הטמעת אבטחה מסוג Shift-left תוכלו לקרוא על פתרונות אחרים של Google שתומכים בהמלצה הזו.
גישת אבטחה רב-שכבתית
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת AI ו-ML
- אבטחת התשתית
- ניהול זהויות והרשאות גישה
- אבטחת מידע
מומלץ להטמיע אבטחה בכל שכבה של האפליקציה ושל מחסנית התשתית, באמצעות גישת הגנה לעומק.
השתמשו באמצעי האבטחה בכל רכיב בפלטפורמה שלכם. כדי להגביל את הגישה ולזהות את גבולות ההשפעה הפוטנציאלית (כלומר, רדיוס הפיצוץ) במקרה של אירוע אבטחה:
- כדאי לפשט את עיצוב המערכת כדי לאפשר גמישות במידת האפשר.
- מתעדים את דרישות האבטחה של כל רכיב.
- לשלב מנגנון אבטחה חזק כדי לעמוד בדרישות של עמידות ושחזור.
כשאתם מתכננים את שכבות האבטחה, בצעו הערכת סיכונים כדי לקבוע אילו אמצעי אבטחה אתם צריכים כדי לעמוד בדרישות האבטחה הפנימיות ובדרישות הרגולטוריות החיצוניות. מומלץ להשתמש במסגרת להערכת סיכונים שתואמת לתקן המקובל בתעשייה, שחלה על סביבות ענן ורלוונטית לדרישות הרגולטוריות שלכם. לדוגמה, Cloud Security Alliance (CSA) מספק את Cloud Controls Matrix (CCM). הערכת הסיכונים מספקת לכם קטלוג של סיכונים ואמצעי אבטחה תואמים כדי לצמצם אותם.
כשאתם מבצעים את הערכת הסיכונים, זכרו שיש לכם הסדר של אחריות משותפת עם ספק שירותי הענן. לכן, הסיכונים בסביבת ענן שונים מהסיכונים בסביבה מקומית. לדוגמה, בסביבה מקומית, צריך לצמצם את נקודות החולשה במקבץ החומרה. לעומת זאת, בסביבת ענן, ספק שירותי הענן נושא בסיכונים האלה. חשוב גם לזכור שהגבולות של האחריות המשותפת משתנים בין שירותי IaaS, PaaS ו-SaaS לכל ספק שירותי ענן.
אחרי שמזהים סיכונים פוטנציאליים, צריך לתכנן וליצור תוכנית לצמצום סיכונים שכוללת אמצעי בקרה טכניים, ניהוליים ותפעוליים, וגם הגנות חוזיות ואישורים של צד שלישי. בנוסף, שיטה למידול איומים, כמו שיטת OWASP למידול איומים באפליקציות, עוזרת לזהות פערים פוטנציאליים ומציעה פעולות לטיפול בהם.
שימוש בתשתית ובשירותים מוקשחים ומאומתים
ההמלצה הזו רלוונטית לכל תחומי המיקוד.
תוכנית אבטחה בשלה מצמצמת את נקודות החולשה החדשות, כפי שמתואר בעדכוני האבטחה הדחופים. תוכנית האבטחה צריכה גם לספק פתרונות לתיקון נקודות חולשה בפריסות קיימות, ולאבטח את קובצי האימג' של המכונות הווירטואליות והקונטיינרים. אתם יכולים להשתמש במדריכי הקשחה שספציפיים למערכת ההפעלה ולאפליקציה של קובצי האימג', וגם באמות מידה כמו אלה שסופקו על ידי Center of Internet Security (CIS).
אם אתם משתמשים בתמונות בהתאמה אישית למכונות הווירטואליות של Compute Engine, אתם צריכים לתקן את התמונות בעצמכם. לחלופין, אתם יכולים להשתמש בקובצי אימג' של מערכת ההפעלה ש-Google מספקת, שמתוקנים באופן קבוע. כדי להריץ קונטיינרים במכונות וירטואליות של Compute Engine, משתמשים בקובצי אימג' של מערכת הפעלה שמותאמת לקונטיינרים שאצרה Google. Google מתקנת ומעדכנת את קובצי האימג' האלה באופן קבוע.
אם אתם משתמשים ב-Google Kubernetes Engine (GKE), מומלץ להפעיל שדרוגים אוטומטיים של צמתים כדי ש-Google תעדכן את צומתי האשכולות שלכם עם התיקונים האחרונים. Google מנהלת את מישורי הבקרה של GKE, שמתעדכנים ומתוקנים באופן אוטומטי. כדי לצמצם עוד יותר את שטח ההתקפה של הקונטיינרים, אתם יכולים להשתמש בתמונות ללא הפצה. תמונות Distroless הן אידיאליות לאפליקציות רגישות לאבטחה, למיקרו-שירותים ולמצבים שבהם חשוב מאוד לצמצם את גודל התמונה ואת שטח המתקפה.
לעומסי עבודה רגישים, השתמשו במכונה וירטואלית מוגנת, שמונעת טעינה של קוד זדוני במהלך מחזור ההפעלה של המכונה הווירטואלית. מכונות וירטואליות מוגנות מספקות אבטחת אתחול, עוקבות אחרי התקינות ומשתמשות ב-Virtual Trusted Platform Module (vTPM).
כדי לאבטח את הגישה ל-SSH, העובדים יכולים להשתמש ב-OS Login כדי להתחבר למכונות הווירטואליות באמצעות הרשאות ניהול זהויות והרשאות גישה (IAM) כמקור המהימנות, במקום להסתמך על מפתחות SSH. לכן, אתם לא צריכים לנהל את מפתחות ה-SSH בכל הארגון. הכלי OS Login מקשר את הרשאת הגישה של האדמין למחזור החיים של העובד, כך שכאשר עובדים מחליפים תפקיד או עוזבים את הארגון, הרשאת הגישה שלהם מבוטלת יחד עם החשבון שלהם. בנוסף, OS Login תומך באימות דו-שלבי של Google, שמוסיף שכבת אבטחה נוספת מפני מתקפות של השתלטות על החשבון.
ב-GKE, מופעי האפליקציות פועלים בקונטיינרים של Docker. כדי להפעיל פרופיל סיכון מוגדר ולהגביל את העובדים מביצוע שינויים בקונטיינרים, ודאו שהקונטיינרים הם ללא שמירת מצב (stateless) ואינם ניתנים לשינוי (immutable). עיקרון חוסר השינוי אומר שהעובדים שלכם לא משנים את הקונטיינר או ניגשים אליו באופן אינטראקטיבי. אם צריך לשנות את הקונטיינר, יוצרים קובץ אימג' חדש ופורסים אותו מחדש. הפעילו גישת SSH לקונטיינרים הבסיסיים רק בתרחישים ספציפיים של ניפוי באגים.
כדי לאבטח את ההגדרות בכל הסביבה, אתם יכולים להשתמש במדיניות הארגון כדי להגדיר אילוצים או אמצעי הגנה על משאבים שמשפיעים על ההתנהגות של הנכסים בענן. לדוגמה, אתם יכולים להגדיר את כללי מדיניות הארגון הבאים ולהחיל אותם באופן גלובלי על כל הארגון ב- Google Cloud , או באופן סלקטיבי ברמת התיקייה או הפרויקט:
- השבתת ההקצאה של כתובות IP חיצוניות למכונות וירטואליות.
- להגביל את יצירת המשאבים למיקומים גיאוגרפיים ספציפיים.
- להשבית את היצירה של חשבונות שירות או המפתחות שלהם.
הצפנת נתונים במנוחה ובמעבר
ההמלצה הזו רלוונטית לתחומים הבאים:
- אבטחת התשתית
- אבטחת מידע
הצפנת נתונים היא אמצעי בקרה בסיסי להגנה על מידע רגיש, והיא חלק מרכזי במשילות מידע (data governance). אסטרטגיה יעילה להגנה על נתונים כוללת בקרת גישה, פילוח נתונים ומיקום גיאוגרפי, ביקורת והטמעת הצפנה שמבוססת על הערכה קפדנית של הדרישות.
כברירת מחדל, Google Cloudמצפין את נתוני הלקוחות שמאוחסנים במצב מנוחה, בלי שאתם צריכים לעשות שום דבר. בנוסף להצפנה שמוגדרת כברירת מחדל, ב-Google Cloud יש אפשרויות להצפנת מעטפה ולניהול מפתחות הצפנה. אתם צריכים לזהות את הפתרונות שהכי מתאימים לדרישות שלכם ליצירת מפתחות, לאחסון ולרוטציה, בין אם אתם בוחרים את המפתחות לאחסון, למחשוב או לעומסי עבודה של Big Data. לדוגמה, אפשר ליצור מפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud Key Management Service (Cloud KMS). מפתחות ה-CMEK יכולים להיות מבוססי-תוכנה או מוגנים באמצעות HSM, כדי לעמוד בדרישות הרגולטוריות או בדרישות התאימות, כמו הצורך להחליף את מפתחות ההצפנה באופן קבוע. באמצעות Cloud KMS Autokey אתם יכולים להקצות ולהגדיר מפתחות CMEK באופן אוטומטי. בנוסף, אתם יכולים להביא מפתחות משלכם ממערכת ניהול מפתחות של צד שלישי באמצעות Cloud External Key Manager (Cloud EKM).
מומלץ מאוד להצפין את הנתונים בזמן ההעברה. Google מצפינה ומאמתת נתונים במעבר בשכבת רשת אחת או יותר, כשהנתונים מועברים אל מחוץ לגבולות הפיזיים שאינם בשליטתה של Google או מטעמה של Google. כל תעבורת הנתונים מ-VM ל-VM בתוך רשת VPC ובין רשתות VPC שמקושרות לרשתות שכנות, עוברת הצפנה. אתם יכולים להשתמש ב-MACsec כדי להצפין את התנועה בחיבורי Cloud Interconnect. IPsec מספק הצפנה לתנועה בחיבורי Cloud VPN. כדי להגן על תעבורת הנתונים בין אפליקציות בענן, אתם יכולים להשתמש באמצעי אבטחה כמו הגדרות TLS ו-mTLS ב-Apigee ו-Cloud Service Mesh לאפליקציות בקונטיינרים.
כברירת מחדל, Google Cloud מצפין נתונים במנוחה ונתונים במעבר ברשת. עם זאת, הנתונים לא מוצפנים כברירת מחדל כשהם בשימוש בזיכרון. אם הארגון שלכם מטפל במידע סודי, אתם צריכים לצמצם את האיומים שפוגעים בסודיות ובתקינות של האפליקציה או של הנתונים בזיכרון המערכת. כדי לצמצם את האיומים האלה, אתם יכולים להשתמש ב-Confidential Computing, שמספק סביבת מחשוב אמינה לעומסי העבודה שלכם. למידע נוסף, קראו את הסקירה הכללית על Confidential VM.