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