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