העיקרון הזה, שמופיע בעמודת האבטחה של Google Cloud Well-Architected Framework, כולל המלצות לשילוב של תכונות אבטחה חזקות, אמצעי בקרה ושיטות עבודה בעיצוב של אפליקציות, שירותים ופלטפורמות בענן. האבטחה יעילה יותר כשהיא מוטמעת כחלק בלתי נפרד מכל שלב בתהליך התכנון, החל משלב יצירת הרעיון ועד לשלב התפעול.
סקירה כללית של העקרונות
כפי שמוסבר במאמר סקירה כללית על המחויבות של Google לאבטחה מובנית, המונחים אבטחה מובנית ואבטחה כברירת מחדל משמשים לעיתים קרובות לסירוגין, אבל הם מייצגים גישות שונות לבניית מערכות מאובטחות. שתי הגישות נועדו לצמצם את נקודות החולשה ולשפר את האבטחה, אבל הן שונות בהיקף ובאופן ההטמעה:
- מאובטח כברירת מחדל: מתמקד בהבטחה שברירות המחדל של המערכת מוגדרות למצב מאובטח, וכך מצמצם את הצורך של משתמשים או אדמינים לבצע פעולות כדי לאבטח את המערכת. המטרה של הגישה הזו היא לספק רמת אבטחה בסיסית לכל המשתמשים.
- אבטחה משלב התכנון: גישה שבה משלבים באופן יזום שיקולי אבטחה לאורך מחזור החיים של פיתוח המערכת. הגישה הזו מתמקדת בחיזוי מוקדם של איומים ונקודות חולשה פוטנציאליים, ובביצוע בחירות עיצוביות שמצמצמות את הסיכונים. הגישה הזו כוללת שימוש בשיטות קידוד מאובטחות, ביצוע בדיקות אבטחה ושילוב אבטחה בתהליך התכנון. הגישה של אבטחה משלב התכנון (secure-by-design) היא פילוסופיה כוללת שמנחה את תהליך הפיתוח ועוזרת להבטיח שהאבטחה לא תהיה מחשבה משנית, אלא חלק בלתי נפרד מהתכנון של המערכת.
המלצות
כדי להטמיע את העיקרון 'אבטחה מובנית' בעומסי העבודה בענן, כדאי לעיין בהמלצות שבקטעים הבאים:
- בחירת רכיבי מערכת שיעזרו לכם לאבטח את עומסי העבודה
- בניית גישה רב-שכבתית לאבטחה
- שימוש בתשתית ובשירותים מאובטחים ומאומתים
- הצפנה של נתונים באחסון ובתנועה
בחירת רכיבי מערכת שיעזרו לאבטח את עומסי העבודה
ההמלצה הזו רלוונטית לכל תחומי ההתמקדות.
כדי להבטיח אבטחה יעילה, חשוב לבחור רכיבי מערכת חזקים – כולל רכיבי חומרה ותוכנה – שמרכיבים את הפלטפורמה, הפתרון או השירות שלכם. כדי לצמצם את פני השטח של האבטחה ולמזער את הנזק הפוטנציאלי, חשוב גם לשקול בקפידה את דפוסי הפריסה של הרכיבים האלה ואת ההגדרות שלהם.
בקוד האפליקציה, מומלץ להשתמש בספריות, בהפשטות ובמסגרות אפליקציה פשוטות, בטוחות ואמינות כדי למנוע סוגים של נקודות חולשה. כדי לסרוק פרצות אבטחה בספריות תוכנה, אפשר להשתמש בכלים של צד שלישי. אפשר גם להשתמש ב-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. מכונות וירטואליות מוגנות מספקות אבטחת אתחול, מעקב אחרי התקינות ושימוש ב-Virtual Trusted Platform Module (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, שמספק סביבת מחשוב אמינה לעומסי העבודה שלכם. מידע נוסף זמין במאמר סקירה כללית על מכונות וירטואליות חסויות.