במסמך הזה מוצגות החלטות חשובות בנושא אבטחה ואפשרויות מומלצות שכדאי לקחת בחשבון כשמעצבים אזור נחיתה ב- Google Cloud Google Cloud. המאמר הזה הוא חלק מסדרה על אזורי נחיתה, והוא מיועד למומחי אבטחה, למנהלי אבטחת מידע ולארכיטקטים שרוצים להבין אילו החלטות הם צריכים לקבל כשהם מעצבים אזור נחיתה ב- Google Cloud.
במסמך הזה, אנחנו מניחים שצוות מרכזי, כמו צוות האבטחה או צוות הפלטפורמה, אוכף את אמצעי הבקרה על האבטחה של אזור הנחיתה. המסמך הזה מתמקד בתכנון של סביבות בקנה מידה ארגוני, ולכן חלק מהאסטרטגיות שמתוארות בו פחות רלוונטיות לצוותים קטנים.
נקודות התפצלות לאבטחת אזור הנחיתה Google Cloud
כדי לבחור את עיצוב האבטחה הטוב ביותר לארגון, צריך לקבל את ההחלטות הבאות:
איך לצמצם את הסיכון להעברת נתונים לא מורשית באמצעות ממשקי API של Google
אילו אמצעי בקרה נוספים נדרשים לניהול הגישה של ספק שירותי הענן
דיאגרמת ארכיטקטורה
בארכיטקטורה לדוגמה שמתוארת במסמך הזה נעשה שימוש בדפוסי עיצוב אבטחה נפוצים. אמצעי הבקרה הספציפיים שלכם עשויים להשתנות בהתאם לגורמים כמו התחום שבו הארגון שלכם פועל, עומסי העבודה המטורגטים או דרישות תאימות נוספות. בתרשים הבא מוצגת ארכיטקטורת אמצעי האבטחה שאתם יכולים להחיל באזור הנחיתה שלכם אם תפעלו לפי ההמלצות שבמסמך הזה.
בתרשים שלמעלה מוצגים:
- ניהול מפתחות של חשבונות שירות עוזר לצמצם את הסיכון מפרטי כניסה לטווח ארוך של חשבונות שירות.
- VPC Service Controls מגדיר גבולות גזרה מסביב למשאבים רגישים, כדי להגביל את הגישה אליהם מחוץ לגבולות הגזרה.
- Security Command Center עוקב אחרי הסביבה כדי לזהות הגדרות לא מאובטחות ואיומים.
- sink ביומן מרכזי אוסף יומני ביקורת מכל הפרויקטים.
- ההצפנה של Google כברירת מחדל במצב מנוחה מצפינה את כל הנתונים שנשמרים בדיסק.
- ההצפנה במעבר של Google כברירת מחדל חלה על נתיבי רשת בשכבה 3 ובשכבה 4.
- התכונה Access Transparency מאפשרת לכם לראות ולשלוט באופן שבו Google יכולה לגשת לסביבה שלכם.
איך להגביל פרטי כניסה קבועים לחשבונות שירות
חשבונות שירות הם זהויות של מכונות שמשמשות להקצאת תפקידי IAM לעומסי עבודה, ומאפשרות לעומס העבודה לגשת ל- Google Cloud APIs. מפתח של חשבון שירות הוא פרטי כניסה קבועים, וכל פרטי כניסה קבועים הם בעלי פוטנציאל לסיכון גבוה. אנחנו לא ממליצים לאפשר למפתחים ליצור מפתחות של חשבונות שירות באופן חופשי.
לדוגמה, אם מפתח של חשבון שירות נשמר בטעות במאגר Git ציבורי, תוקף חיצוני יכול לבצע אימות באמצעות פרטי הכניסה האלה. דוגמה נוספת: אם המפתח של חשבון השירות מאוחסן במאגר פנימי, משתמש זדוני שיש לו גישה למפתח יכול להשתמש בפרטי הכניסה כדי להסלים את ההרשאות שלו. Google Cloud
כדי להגדיר אסטרטגיה לניהול פרטי הכניסה הקבועים האלה, צריך לספק חלופות מעשיות, להגביל את ההתפשטות של פרטי הכניסה הקבועים ולנהל את אופן השימוש בהם. מידע על חלופות למפתחות של חשבונות שירות זמין במאמר בחירת שיטת האימות שמתאימה לתרחיש שלכם לדוגמה.
בקטעים הבאים מפורטות האפשרויות להגבלת פרטי כניסה קבועים. אנחנו ממליצים על אפשרות 1 לרוב תרחישי השימוש. האפשרויות האחרות שמפורטות בקטעים הבאים הן חלופות שאפשר לשקול אם אפשרות 1 לא רלוונטית לארגון שלכם.
כל הארגונים שנוצרו אחרי 23 במאי 2024, נאכפים בהם Google Cloud אילוצים של מדיניות אבטחה מהיסוד כשיוצרים לראשונה את משאב הארגון. בעקבות השינוי הזה, אפשרות 1 היא ברירת המחדל.
אפשרות 1: הגבלת השימוש במפתחות קבועים לחשבון שירות
מומלץ לא לאפשר למשתמשים להוריד מפתחות של חשבונות שירות, כי מפתחות חשופים הם וקטור תקיפה נפוץ. הגבלת השימוש במפתחות קבועים של חשבונות שירות היא אפשרות שיכולה לעזור לצמצם את הסיכון ואת התקורה של ניהול ידני של מפתחות של חשבונות שירות.
כדי ליישם את האפשרות הזו, כדאי לשקול את הנקודות הבאות:
- כדי למנוע ממפתחים ליצור ולהוריד פרטי כניסה קבועים, צריך להגדיר את האילוץ של מדיניות הארגון
constraints/iam.disableServiceAccountKeyCreation. - הדרכת הצוותים לגבי חלופות מאובטחות יותר למפתחות של חשבונות שירות. לדוגמה, כשמשתמשים ואפליקציות שנמצאים מחוץ לסביבתGoogle Cloud צריכים להשתמש בחשבון שירות, הם יכולים לבצע אימות באמצעות התחזות לחשבון שירות או שירות משולב לזיהוי עומסי עבודה במקום באמצעות מפתח של חשבון שירות.
- כדאי לתכנן תהליך שבו צוותים יכולים לבקש חריגה מהמדיניות הזו אם הורדה של מפתח לחשבון שירות היא האפשרות היחידה. לדוגמה, יכול להיות שמוצר SaaS של צד שלישי ידרוש מפתח של חשבון שירות כדי לקרוא יומנים מהסביבה שלכם ב- Google Cloud .
מומלץ להימנע מהאפשרות הזו אם כבר יש לכם כלים ליצירת פרטי כניסה ל-API עם תוקף קצר לחשבונות שירות.
למידע נוסף, קראו את המאמרים הבאים:
- אילוצים של מדיניות הארגון בתוכנית האב של Google Cloud Enterprise Foundations
- שיטות מומלצות לשימוש בחשבונות שירות
אפשרות 2: שימוש בכלים נוספים לניהול גישה כדי ליצור פרטי כניסה לטווח קצר
במקום להגביל את השימוש במפתחות קבועים של חשבונות שירות, אפשר ליצור פרטי כניסה לטווח קצר לחשבונות שירות. פרטי כניסה לטווח קצר יוצרים פחות סיכון מאשר פרטי כניסה קבועים, כמו מפתחות של חשבונות שירות. אתם יכולים לפתח כלים משלכם או להשתמש בפתרונות של צד שלישי, כמו Hashicorp Vault, כדי ליצור פרטי כניסה לגישה לטווח קצר.
כדאי להשתמש באפשרות הזו אם כבר השקעתם בכלי של צד שלישי ליצירת פרטי כניסה לטווח קצר לצורך בקרת גישה, או אם יש לכם תקציב ויכולת מספיקים כדי לפתח פתרון משלכם.
מומלץ להימנע משימוש באפשרות הזו אם אין לכם כלים קיימים להענקת אישורים לזמן קצר, או אם אין לכם יכולת לבנות פתרון משלכם.
מידע נוסף זמין במאמר יצירת פרטי כניסה לטווח קצר לחשבון שירות.
איך מצמצמים את הסיכון לזליגת מידע דרך Google APIs
לממשקי Google API יש נקודות קצה ציבוריות שזמינות לכל הלקוחות. כל משאב API בסביבה Google Cloud שלכם כפוף לאמצעי בקרת גישה של IAM, אבל יש סיכון שגורמים זדוניים ישיגו גישה לנתונים באמצעות פרטי כניסה גנובים, קוד שנפרץ או מדיניות IAM שהוגדרה בצורה לא נכונה.
VPC Service Controls הוא פתרון שנועד להתמודד עם הסיכונים האלה. עם זאת, VPC Service Controls גם מוסיף מורכבות למודל הגישה שלכם, ולכן אתם צריכים לתכנן את VPC Service Controls כך שיתאים לסביבה הייחודית ולתרחיש השימוש שלכם.
בקטעים הבאים מפורטות האפשרויות לצמצום הסיכון להוצאת נתונים לא מורשית דרך Google APIs. אנחנו ממליצים להשתמש באפשרות 1 ברוב תרחישי השימוש. האפשרויות האחרות שמפורטות בקטעים הבאים הן חלופות שאפשר להשתמש בהן אם אפשרות 1 לא מתאימה לתרחיש השימוש הספציפי שלכם.
אפשרות 1: הגדרת VPC Service Controls באופן נרחב בסביבה
מומלץ לתכנן את הסביבה בתוך גבולות גזרה אחדים או יותר של VPC Service Controls שמגבילים את כל ממשקי ה-API הנתמכים. מגדירים חריגים לגבולות הגזרה באמצעות רמות גישה או כללי מדיניות תעבורת נתונים נכנסת (ingress), כדי שהמפתחים יוכלו לגשת לשירותים שהם צריכים, כולל גישה למסוף במקומות שבהם זה נדרש.
כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- השירותים שבהם אתם מתכוונים להשתמש תומכים ב-VPC Service Controls, ועומסי העבודה שלכם לא דורשים גישה לא מוגבלת לאינטרנט.
- אתם מאחסנים מידע אישי רגיש ב Google Cloud , ואם הוא ייגנב, זה עלול לגרום לכם נזק משמעותי.
- יש לכם מאפיינים עקביים לגישת מפתחים שאפשר להגדיר כחריגים לגבולות הגזרה, וכך לאפשר למשתמשים לגשת לנתונים שהם צריכים.
לא מומלץ להשתמש באפשרות הזו אם עומסי העבודה שלכם דורשים גישה בלתי מוגבלת לאינטרנט או לשירותים שלא נתמכים על ידי VPC Service Controls.
למידע נוסף, קראו את המאמרים הבאים:
- שיטות מומלצות להפעלת VPC Service Controls
- מוצרים נתמכים ומגבלות של VPC Service Controls
- עיצוב והגדרת היקפי אבטחה
אפשרות 2: הגדרת VPC Service Controls עבור קבוצת משנה של הסביבה
במקום להגדיר את VPC Service Controls באופן נרחב בסביבה שלכם, אתם יכולים להגדיר את VPC Service Controls רק בקבוצת המשנה של הפרויקטים שמכילים מידע אישי רגיש ועומסי עבודה פנימיים בלבד. האפשרות הזו מאפשרת לכם להשתמש בעיצוב ובתפעול פשוטים יותר ברוב הפרויקטים, ועדיין לתת עדיפות להגנה על נתונים בפרויקטים עם מידע אישי רגיש.
לדוגמה, כדאי לשקול את החלופה הזו אם מספר מוגבל של פרויקטים מכילים מערכי נתונים ב-BigQuery עם מידע אישי רגיש. אפשר להגדיר service perimeter רק סביב הפרויקטים האלה, ולהגדיר כללים לתעבורת נתונים נכנסת ויוצאת כדי לאפשר חריגים מצומצמים לאנליסטים שצריכים להשתמש במערכי הנתונים האלה.
דוגמה נוספת: באפליקציה עם ארכיטקטורה תלת-שכבתית, יכול להיות שחלק מהרכיבים יהיו מחוץ להיקף. שכבת ההצגה שמאפשרת תעבורת נתונים נכנסת (ingress) מתעבורת משתמשים יכולה להיות פרויקט מחוץ לגבולות הגזרה, ושכבת האפליקציה ושכבת הנתונים שמכילות מידע אישי רגיש יכולות להיות פרויקטים נפרדים בתוך גבולות גזרה לשירות. אתם מגדירים כללים לתעבורת נתונים נכנסת (ingress) ויוצאת (egress) לגבולות הגזרה, כדי שהשכבות יוכלו לתקשר מעבר לגבולות הגזרה עם גישה גרנולרית.
כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- רק פרויקטים מוגבלים ומוגדרים היטב מכילים נתונים רגישים. בפרויקטים אחרים יש נתונים עם סיכון נמוך יותר.
- חלק מעומסי העבודה הם פנימיים בלבד, אבל חלק מעומסי העבודה דורשים גישה לאינטרנט הציבורי או שיש להם תלות בשירותים שלא נתמכים על ידי אמצעי הבקרה של VPC Service Controls.
- הגדרת VPC Service Controls בכל הפרויקטים יוצרת עומס יתר או דורשת יותר מדי פתרונות עקיפים
לא כדאי להשתמש באפשרות הזו אם יש הרבה פרויקטים שעשויים להכיל נתונים רגישים.
מידע נוסף זמין במאמר שיטות מומלצות להפעלת VPC Service Controls.
אפשרות 3: לא מגדירים VPC Service Controls
אפשרות נוספת במקום להגדיר את VPC Service Controls באופן נרחב בסביבה שלכם היא לא להשתמש ב-VPC Service Controls, במיוחד אם התקורה התפעולית גבוהה יותר מהערך של VPC Service Controls.
לדוגמה, יכול להיות שלא יהיה לארגון דפוס עקבי של גישת מפתחים שיכול לשמש בסיס למדיניות כניסה. יכול להיות שמיקור החוץ של פעולות ה-IT שלכם מתבצע על ידי כמה צדדים שלישיים, ולכן למפתחים אין מכשירים מנוהלים או גישה מכתובות IP עקביות. בתרחיש הזה, יכול להיות שלא תוכלו להגדיר כללי כניסה כדי לאפשר חריגים להיקף ההגנה, שנדרשים למפתחים כדי להשלים את הפעולות היומיומיות שלהם.
כדאי להשתמש באפשרות הזו במקרים הבאים:
- אתם משתמשים בשירותים שלא תומכים ב-VPC Service Controls.
- עומסי העבודה פונים לאינטרנט ולא מכילים מידע אישי רגיש.
- אין לכם מאפיינים עקביים של גישת מפתחים, כמו מכשירים מנוהלים או טווחי IP מוכרים.
לא מומלץ להשתמש באפשרות הזו אם יש לכם מידע רגיש בסביבת Google Cloud העבודה.
החלטה לגבי אופן המעקב הרציף אחר הגדרות לא מאובטחות ואיומים
השימוש בשירותי ענן מציב אתגרים ואיומים חדשים בהשוואה לשימוש בשירותים שנמצאים בשרתים מקומיים. יכול להיות שהכלים הקיימים שלכם לניטור שרתים לטווח ארוך לא מתאימים לשירותים זמניים או לשירותים עם שינוי גודל אוטומטי, ואולי הם לא מנטרים משאבים ללא שרתים בכלל. לכן, כדאי להעריך כלי אבטחה שפועלים עם כל מגוון שירותי הענן שאולי תאמצו. מומלץ גם לעקוב באופן שוטף אחרי תקני ענן, כמו CIS Benchmark for Google Cloud.
בקטעים הבאים מתוארות האפשרויות למעקב רציף. אנחנו ממליצים על אפשרות 1 לרוב תרחישי השימוש. האפשרויות האחרות שמתוארות בקטעים הבאים הן חלופות שאפשר לשקול אם אפשרות 1 לא מתאימה לתרחיש השימוש הספציפי שלכם.
אפשרות 1: שימוש ב-Security Command Center
מומלץ להפעיל את Security Command Center ברמת הארגון, כדי לחזק את מצב האבטחה באמצעות הפעולות הבאות:
- הערכת מצב האבטחה ושטח ההתקפה הפוטנציאלי על הנתונים
- הצגת מלאי נכסים וגילוי נכסים
- זיהוי תצורות שגויות, נקודות חולשה ואיומים
- עזרה בצמצום סיכונים ובתיקון בעיות
אם תפעילו את Security Command Center בתחילת בניית אזור הנחיתה, צוות האבטחה של הארגון יוכל לראות כמעט בזמן אמת את ההגדרות הלא מאובטחות, האיומים ואפשרויות התיקון. השקיפות הזו עוזרת לצוות האבטחה להעריך אם אזור הנחיתה עומד בדרישות שלהם ומוכן לכך שמפתחים יתחילו לפרוס אפליקציות.
כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- אתם רוצים כלי לניהול מצב האבטחה ולזיהוי איומים שמשולב עם כל Google Cloud השירותים בלי צורך במאמץ נוסף לשילוב.
- אתם רוצים להשתמש באותו מודיעין איומי סייבר, למידת מכונה ושיטות מתקדמות אחרות ש-Google משתמשת בהם כדי להגן על השירותים שלה.
- למרכז האבטחה (SOC) הקיים שלכם אין את הכישורים או את היכולת ליצור תובנות לגבי איומים מנפח גדול של יומני ענן.
מומלץ להימנע מהאפשרות הזו אם כלי האבטחה הקיימים שלכם יכולים לטפל באופן מלא במשאבי ענן זמניים או חסרי שרת, לעקוב אחרי הגדרות לא מאובטחות ולזהות איומים בקנה מידה גדול בסביבת ענן.
אפשרות 2: שימוש בכלים קיימים לאבטחת הענן ולזיהוי איומים
במקום להשתמש ב-Security Command Center, אפשר לשקול כלי Cloud Security Posture Management אחרים. קיימים מגוון כלים של צד שלישי עם פונקציות דומות לאלה של Security Command Center, ויכול להיות שכבר השקעתם בכלים מבוססי-ענן שמתמקדים בסביבות מרובות עננים.
אפשר גם להשתמש ב-Security Command Center ובכלים של צד שלישי בו-זמנית. לדוגמה, אפשר להטמיע את ההתראות על ממצאים מ-Security Command Center בכלי אחר, או להוסיף שירות אבטחה של צד שלישי ללוח הבקרה של Security Command Center. דוגמה נוספת: יכול להיות שאתם נדרשים לאחסן יומנים במערכת SIEM קיימת כדי שצוות SOC יוכל לנתח אותם ולזהות איומים. אתם יכולים להגדיר את ה-SIEM הקיים כך שיקלוט רק את ההתראות על הממצאים שנוצרות ב-Security Command Center, במקום לקלוט נפח גדול של יומנים ולצפות מצוות SOC לנתח את היומנים הגולמיים כדי להפיק תובנות.
משתמשים באפשרות הזו אם כלי האבטחה הקיימים יכולים לטפל באופן מלא במשאבי ענן זמניים או במשאבים בלי שרת, לעקוב אחרי הגדרות לא מאובטחות ולזהות איומים בקנה מידה גדול בסביבת ענן.
אל תבחרו באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- ל-SOC הקיים אין את הכישורים או היכולת ליצור תובנות לגבי איומים מנפח גדול של יומני ענן.
- שילוב של כמה כלים של צד שלישי עם כמה שירותים של Google Cloud מערכות יוצר מורכבות רבה יותר מאשר ערך.
למידע נוסף, קראו את המאמרים הבאים:
- הפעלת האפשרות לאיתור התראות ב-Pub/Sub
- ניהול מקורות אבטחה באמצעות Security Command Center API
- הוספה של שירות אבטחה של צד שלישי
קובעים איך לצבור באופן מרכזי את היומנים הדרושים
רוב יומני הביקורת מאוחסנים ב Google Cloud פרויקט שבו הם נוצרו. ככל שהסביבה שלכם גדלה, יכול להיות שיהיה קשה למבקר לבדוק את היומנים בכל פרויקט בנפרד. לכן, צריך להחליט איך יומנים ירוכזו ויצטברו כדי לעזור לכם בביקורת הפנימית ובפעולות האבטחה.
בקטעים הבאים מפורטות האפשרויות לצבירת יומנים. מומלץ להשתמש באפשרות 1 ברוב תרחישי השימוש. האפשרויות האחרות שמתוארות בקטעים הבאים הן חלופות שאפשר לשקול אם אפשרות 1 לא רלוונטית לתרחיש השימוש הספציפי שלכם.
אפשרות 1: שמירת יומנים ב- Google Cloud באמצעות יעד ליומנים מצטברים
מומלץ להגדיר sink ביומן מרכזי ברמת הארגון עבור יומני ביקורת ויומנים אחרים שנדרשים לצוות האבטחה. אפשר להיעזר בכלי להגדרת היקף היומנים כדי לזהות את היומנים שצוות האבטחה שלכם צריך, ולבדוק אם צריך להפעיל במפורש את סוגי היומנים האלה.
לדוגמה, צוות האבטחה מצפה לרישום מרכזי של כל המשאבים שהמשתמשים שלכם יוצרים, כדי שצוות האבטחה יוכל לעקוב אחרי שינויים חשודים ולחקור אותם. צוות האבטחה צריך גם רשומה שלא ניתן לשנות של גישה לנתונים עבור עומסי עבודה מסוימים שמכילים מידע רגיש במיוחד. לכן, צוות האבטחה מגדיר sink ביומן אחד כדי לצבור יומני ביקורת של פעילות האדמין מכל הפרויקטים ב-bucket של Observability Analytics בפרויקט מרכזי, כדי שיוכלו לצפות בהם לצורך חקירות אד-הוק. לאחר מכן הם מגדירים sink ביומן שני ליומני ביקורת של גישה לנתונים מפרויקטים עם עומסי עבודה רגישים, לקטגוריה של Cloud Storage לשמירה לטווח ארוך.
כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- צוות האבטחה שלכם מצפה לקבל רשומה מרכזית של כל יומני הביקורת או סוגים ספציפיים אחרים של יומנים.
- צוות האבטחה צריך לאחסן את היומנים בסביבה עם גישה מוגבלת, מחוץ לשליטה של עומס העבודה או של הצוותים שיצרו את היומן.
אל תבחרו באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- בארגון שלכם אין דרישה מרכזית ליומני ביקורת עקביים בכל עומסי העבודה.
- בעלי פרויקטים ספציפיים נושאים באחריות מלאה לניהול יומני הביקורת שלהם.
למידע נוסף, קראו את המאמרים הבאים:
- אמצעי בקרה לזיהוי בתוכנית הבסיסית של הארגון
- שיטות מומלצות לשימוש ביומני ביקורת של Cloud
- הגדרת מאגרי נתונים מצטברים
- כלי לסינון יומנים
- כללי מדיניות שמירת נתונים ונעילות שלהם
אפשרות 2: שמירת יומני ביקורת ב-Google SecOps באמצעות הטמעה ישירה
אם אתם משתמשים ב-Google Security Operations כפתרון SIEM, אתם יכולים להטמיע אוטומטית סוגים נתמכים של יומנים מ-Google Cloud אל Google SecOps. אתם יכולים לשלוח סוגים ספציפיים של יומנים (כולל Cloud Logging, מטא-נתונים של מאגר משאבי ענן וממצאים של Security Command Center) ל-Google Security Operations בזמן אמת על ידי הגדרת הטמעה ישירה.
בהתאם לדרישות שלכם, יכול להיות שתשתמשו בשילוב של אפשרות 1 ואפשרות 2. לדוגמה, יכול להיות שיש לכם צוות פלטפורמה שצריך לצפות ביומנים מרכזיים בסביבת Google Cloud שלכם ואין לו גישה לסביבת Google SecOps, וצוות אבטחת מידע שצריך לצפות ביומנים מכמה ספקי ענן ויש לו גישה רק לסביבת Google SecOps.
אם אתם צריכים יומנים מהסביבה שלכם Google Cloud מעבר לקבוצה של סוגי היומנים שנתמכים לייצוא, אתם יכולים להגדיר פידים משלכם של יומנים עבור סוגים אחרים של יומנים. מידע נוסף זמין במאמרים בנושא ניהול פידים ומנתחי ברירת מחדל.
כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- אתם משתמשים ב-Google SecOps.
אל תבחרו באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- אתם לא משתמשים ב-Google SecOps.
- אתם צריכים שליטה פרטנית יותר על הטמעת היומנים בהשוואה להגדרות ברירת המחדל שמוגדרות בהטמעה ישירה.
למידע נוסף, קראו את המאמרים הבאים:
אפשרות 3: ייצוא של יומני הביקורת הנדרשים לאחסון מחוץ ל- Google Cloud
במקום לאחסן יומנים רק ב- Google Cloud , כדאי לייצא יומני ביקורת מחוץ ל- Google Cloud. אחרי שמרכזים את סוגי היומנים הדרושים ב-sink ביומן מצטבר ב- Google Cloud, מטמיעים את התוכן של ה-sink הזה לפלטפורמה אחרת מחוץ ל-Google Cloud כדי לאחסן ולנתח את היומנים.
לדוגמה, אתם יכולים להשתמש ב-SIEM של צד שלישי כדי לצבור ולנתח יומני ביקורת בכמה ספקי ענן. לכלי הזה יש יכולות מספיקות לעבודה עם משאבי ענן ללא שרתים, ולצוות SOC יש את המיומנויות והיכולת להפיק תובנות מהנפח הגדול הזה של יומנים.
האפשרות הזו עלולה להיות יקרה מאוד בגלל עלות היציאה מהרשת ב- Google Cloud, וגם בגלל עלות האחסון והקיבולת בסביבה השנייה. במקום לייצא כל יומן זמין, מומלץ לבחור אילו יומנים נדרשים בסביבה החיצונית.
משתמשים באפשרות הזו כשנדרש לאחסן יומנים מכל הסביבות וספקי הענן במיקום מרכזי אחד.
אל תבחרו באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- למערכות הקיימות שלכם אין את היכולת או התקציב לעיבוד של נפח גדול של יומני ענן נוספים.
- המערכות הקיימות שלכם דורשות מאמצי שילוב לכל סוג ופורמט של יומן.
- אתם אוספים יומנים בלי מטרה ברורה לגבי אופן השימוש בהם.
מידע נוסף זמין במאמר בנושא אמצעי בקרה לגילוי בתוכנית הבסיסית של Enterprise.
קובעים איך לעמוד בדרישות התאימות להצפנה במנוחה
Google Cloud מצפינה אוטומטית את כל התוכן שלכם שמאוחסן במנוחה, באמצעות מנגנון הצפנה אחד או יותר. בהתאם לדרישות התאימות שלכם, יכול להיות שתהיו מחויבים לנהל את מפתחות ההצפנה בעצמכם.
בקטעים הבאים מתוארות האפשרויות להצפנה במנוחה. אנחנו ממליצים על אפשרות 1 לרוב תרחישי השימוש. האפשרויות האחרות שמתוארות בקטעים הבאים הן חלופות שאפשר לשקול אם אפשרות 1 לא מתאימה לתרחיש השימוש הספציפי שלכם.
אפשרות 1: אישור השימוש בהצפנה במנוחה שמוגדרת כברירת מחדל
הצפנה במנוחה כברירת מחדל מספיקה לתרחישי שימוש רבים שאין בהם דרישות תאימות ספציפיות לגבי ניהול מפתחות הצפנה.
לדוגמה, צוות האבטחה בחברת משחקים אונליין דורש שכל נתוני הלקוחות יוצפנו במנוחה. אין להם דרישות רגולטוריות לגבי ניהול מפתחות, ואחרי שבדקו את ההצפנה של Google כברירת מחדל במצב מנוחה, הם מרוצים מכך שזה אמצעי בקרה מספיק לצרכים שלהם.
כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- אין לכם דרישות ספציפיות לגבי הצפנת נתונים או ניהול מפתחות הצפנה.
- אתם מעדיפים שירות מנוהל על פני העלויות והתקורה התפעולית של ניהול מפתחות הצפנה משלכם.
מומלץ להימנע מהאפשרות הזו אם יש לכם דרישות תאימות לניהול מפתחות ההצפנה שלכם.
מידע נוסף זמין במאמר הצפנה במנוחה ב- Google Cloud.
אפשרות 2: ניהול מפתחות הצפנה באמצעות Cloud KMS
בנוסף להצפנה כברירת מחדל של נתונים באחסון, יכול להיות שתרצו יותר שליטה במפתחות שמשמשים להצפנת נתונים באחסון בתוך פרויקט Google Cloud . שירות Cloud Key Management Service (Cloud KMS) מאפשר להגן על הנתונים באמצעות מפתחות הצפנה בניהול הלקוח (CMEK). לדוגמה, בתעשיית השירותים הפיננסיים, יכול להיות שתידרשו לדווח למבקרים החיצוניים שלכם איך אתם מנהלים את מפתחות ההצפנה שלכם לנתונים רגישים.
כדי להוסיף שכבות שליטה, אפשר להגדיר מודולי אבטחה לחומרה (HSM) או ניהול מפתחות חיצוני (EKM) עם CMEK. לא מומלץ להשתמש במפתחות הצפנה באספקת הלקוח (CSEK). תרחישים שבעבר נפתרו באמצעות CSEK נפתרים עכשיו בצורה טובה יותר באמצעות Cloud External Key Manager (Cloud EKM), כי Cloud EKM תומך ביותר שירותים וזמינות גבוהה יותר.
באפשרות הזו, חלק מהאחריות עובר למפתחי האפליקציות, שצריכים לפעול בהתאם לניהול המפתחות שצוות האבטחה שלכם קובע. צוות האבטחה יכול לאכוף את הדרישה על ידי חסימת היצירה של משאבים שלא עומדים בדרישות באמצעות מדיניות ארגונית של CMEK.
כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- אתם נדרשים לנהל את מחזור החיים של המפתחות שלכם.
- יש לכם דרישה ליצור חומר מפתח קריפטוגרפי עם מודול HSM עם אישור FIPS 140-2 ברמה 3.
- יש לכם דרישה לאחסן חומרי מפתחות קריפטוגרפיים מחוץ ל-Google Cloud באמצעות Cloud EKM.
אל תבחרו באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- אין לכם דרישות ספציפיות לגבי הצפנת נתונים או ניהול מפתחות הצפנה.
- אתם מעדיפים שירות מנוהל על פני העלויות והתקורה התפעולית של ניהול מפתחות הצפנה משלכם.
למידע נוסף, קראו את המאמרים הבאים:
- שיטות מומלצות לשימוש במפתחות CMEK
- ניהול מפתחות הצפנה באמצעות Cloud Key Management Service בתוכנית האב של Enterprise Foundations
- מפתחות הצפנה בניהול הלקוח (CMEK)
- Cloud HSM
- Cloud External Key Manager
- מדיניות הארגון ל-CMEK
אפשרות 3: המרת נתונים לטוקנים בשכבת האפליקציה לפני שמירתם באחסון
בנוסף להצפנה שמוגדרת כברירת מחדל על ידי Google, אתם יכולים לפתח פתרון משלכם לטוקניזציה של נתונים לפני שאתם מאחסנים אותם ב- Google Cloud.
לדוגמה, מדען נתונים צריך לנתח מערך נתונים עם פרטים אישיים מזהים, אבל לא צריכה להיות לו גישה לקריאת הנתונים הגולמיים של חלק מהשדות הרגישים. כדי להגביל את הגישה לבקרה על נתונים גולמיים, אפשר לפתח צינור להעברת נתונים עם הגנה על מידע אישי רגיש כדי להעביר נתונים רגישים ולבצע טוקניזציה שלהם, ואז לשמור את הנתונים שעברו טוקניזציה ב-BigQuery.
הטמעה של טוקניזציה של נתונים היא לא אמצעי בקרה שאפשר לאכוף באופן מרכזי באזור הנחיתה. במקום זאת, האפשרות הזו מעבירה את האחריות למפתחי האפליקציות להגדיר הצפנה משלהם, או לצוות פלטפורמה שמפתח צינור הצפנה כשירות משותף לשימוש מפתחי האפליקציות.
משתמשים באפשרות הזו כשעומסי עבודה מסוימים כוללים מידע אישי רגיש מאוד שאסור להשתמש בו בצורה גולמית.
מומלץ להימנע מהאפשרות הזו אם Cloud KMS מספיק כדי לעמוד בדרישות שלכם, כמו שמתואר במאמר ניהול מפתחות הצפנה באמצעות Cloud KMS. העברת נתונים דרך צינורות נוספים של הצפנה ופענוח מוסיפה עלויות, זמן אחזור ומורכבות לאפליקציות.
מידע נוסף זמין במאמר סקירה כללית על Sensitive Data Protection.
החלטה איך לעמוד בדרישות התאימות להצפנה בזמן ההעברה
Google Cloud משתמשת במספר אמצעי אבטחה כדי להבטיח את האותנטיות, התקינות והפרטיות של נתונים במעבר. בהתאם לדרישות האבטחה והתאימות שלכם, יכול להיות שתצטרכו להגדיר גם הצפנה בשכבת האפליקציה.
בקטעים הבאים מתוארות האפשרויות להצפנה של נתונים במעבר. אנחנו ממליצים על אפשרות 1 לרוב תרחישי השימוש. האפשרויות האחרות שמתוארות בקטעים הבאים הן תכונות נוספות שכדאי לשקול אם אפשרות 1 לא מספיקה לתרחיש השימוש הספציפי שלכם.
אפשרות 1: הערכה של מידת ההתאמה של הצפנה Google Cloud של נתונים במעבר
הרבה דפוסי תנועה באזור הנחיתה שלכם נהנים מהצפנה של נתונים במעבר כ Google Cloud ברירת מחדל.
- החיבורים בין מכונות וירטואליות בתוך רשתות VPC או רשתות VPC שמקושרות לרשתות שכנות ברשת של סביבת הייצור של Google, עוברים הצפנה ומוגנים מפני שינויים לא מורשים.
התנועה מהאינטרנט לשירותי Google והתנועה מרשת ה-VPC לשירותי Google מסתיימות בממשק הקצה של Google (GFE). בנוסף, GFE:
- הספק מספק אמצעי נגד להתקפות DDoS
- המסלולים מאזנים את עומס התנועה לשירותים Google Cloud
בתשתית של Google נעשה שימוש ב-ALTS לצורך האימות, התקינות וההצפנה של חיבורים מ-GFE ל Google Cloud שירות, ומGoogle Cloud שירות אחד ל Google Cloud שירות אחר.
משתמשים באפשרות הזו אם Google Cloud הצפנה במעבר שמוגדרת כברירת מחדל מספיקה לעומסי העבודה הפנימיים.
מוסיפים הגנה נוספת במקרים הבאים:
- אתם מאפשרים תעבורת נתונים נכנסת מהאינטרנט לרשת ה-VPC.
- אתם מתחברים לסביבה המקומית.
במקרים כאלה, כדאי להגדיר אמצעי בקרה נוספים, כמו שמתואר באפשרות 2: דרישה מאפליקציות להגדיר הצפנה בשכבה 7 של נתונים במעבר ובאפשרות 3: הגדרת הצפנה נוספת בסביבה המקומית.
מידע נוסף על Google Cloud הצפנה במעבר כברירת מחדל זמין במאמר בנושא הצפנה במעבר ב-Google Cloud.
אפשרות 2: הגדרת הצפנה נוספת לתנועה אל או מהאפליקציות של הלקוח
בנוסף להצפנה בזמן מעבר כברירת מחדל, אתם יכולים להגדיר הצפנה בשכבה 7 לתעבורת אפליקציות לאפליקציות של הלקוחות.Google Cloud מספק שירותים מנוהלים לתמיכה באפליקציות שזקוקות להצפנה בזמן מעבר בשכבת האפליקציה, כולל אישורים מנוהלים ו-Cloud Service Mesh.
לדוגמה, מפתח בונה אפליקציה חדשה שמקבלת תעבורת נתונים נכנסת (ingress) מהאינטרנט. הם משתמשים במאזן עומסים חיצוני של אפליקציות (ALB) עם אישורי SSL בניהול Google כדי להפעיל ולהרחיב שירותים מאחורי כתובת IP אחת.
הצפנה בשכבת האפליקציה היא לא אמצעי בקרה שאפשר לאכוף באופן מרכזי באזור הנחיתה. במקום זאת, האפשרות הזו מעבירה חלק מהאחריות למפתחי אפליקציות, כדי להגדיר הצפנה של נתונים במעבר.
משתמשים באפשרות הזו כשהאפליקציות דורשות תנועה של HTTPS או SSL בין רכיבים.
כדאי לשקול לאפשר חריגה מוגבלת מהאפשרות הזו כשמעבירים עומסי עבודה של מחשוב לענן שלא דרשו בעבר הצפנה של תעבורת נתונים פנימית כשהאפליקציות היו מקומיות. במהלך מיגרציה רחבת היקף, יכול להיות שיהיה עיכוב לא מקובל בתוכנית אם נדרש לבצע מודרניזציה של אפליקציות מדור קודם לפני המיגרציה.
למידע נוסף, קראו את המאמרים הבאים:
אפשרות 3: הגדרת הצפנה נוספת בסביבה המקומית
אם אתם צריכים חיבור מ- Google Cloud לסביבה המקומית שלכם, אתם יכולים להגדיר Cloud Interconnect, שיוצר חיבור פיזי ישיר בין Google Cloud לבין מרכזי הנתונים שלכם. כשמשתמשים ב-Cloud Interconnect, תעבורת הנתונים מהסביבה המקומית אל Google Cloudלא מוצפנת במהלך ההעברה כברירת מחדל. לכן, אם אתם משתמשים ב-Cloud Interconnect, מומלץ להפעיל את MACsec עבור Cloud Interconnect כחלק מאזור הנחיתה.
אם אתם משתמשים ב-HA VPN כדי לחבר תעבורה פרטית ביןGoogle Cloud לבין מרכזי הנתונים שלכם, התעבורה מוצפנת באמצעות IPsec כברירת מחדל.
מידע נוסף זמין במאמר בחירת מוצרים של Network Connectivity Center.
איך מחליטים אילו אמצעי בקרה נוספים נחוצים לניהול הגישה של ספק שירותי הענן
הצורך בביקורת על הגישה של ספק שירותי הענן (CSP) יכול להיות בעיה במהלך אימוץ הענן. Google Cloud מספקת כמה שכבות של בקרה שיכולות לאפשר אימות של הגישה של ספק הענן.
בקטעים הבאים מפורטות האפשרויות לניהול הגישה של ספקי CSP. אנחנו ממליצים על אפשרות 1 לרוב תרחישי השימוש. אפשרות נוספת שנדונה בקטעים הבאים היא תכונה נוספת שכדאי לשקול אם אפשרות 1 לא מספיקה לתרחיש השימוש הספציפי שלכם.
אפשרות 1: הפעלת יומנים של Access Transparency
ביומנים של Access Transparency מתועדות הפעולות שמבצעים אנשי הצוות Google Cloud בסביבה שלכם, למשל כשהם פותרים בעיה שקשורה לפנייה לתמיכה.
לדוגמה, מפתח מעלה בעיה שקשורה לפתרון תקלות ל-Cloud Customer Care ומבקש מנציג התמיכה לעזור לו לפתור את הבעיה בסביבה שלו. יומן Access Transparency נוצר כדי להראות אילו פעולות צוות התמיכה ביצע, כולל מספר בקשת התמיכה שהצדיקה את הפעולות.
כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- אתם רוצים לוודא ש Google Cloud אנשי הצוות של Google שיש להם גישה למידע שלכם משתמשים בגישה רק למטרות עסקיות חוקיות, כמו תיקון הפסקות זמניות בשירות או טיפול בפניות שלכם לתמיכה.
- יש לכם דרישה לתאימות לעקוב אחרי הגישה למידע אישי רגיש.
אפשרות 2: הפעלת יומנים של Access Transparency וניהול גישה לספק
אם העסק שלכם מחויב לתת אישור מפורש לפני שספק CSP יכול לגשת לסביבה שלכם, בנוסף לאפשרות 1, אתם יכולים להשתמש ב-Access Transparency עם אמצעי בקרה אחרים שמאפשרים לכם לאשר או לדחות באופן מפורש גישה לנתונים שלכם.
אישורי הגישה הם פתרון ידני שמבטיח שהמהנדסים ונציגי שירות הלקוחות של Google יצטרכו לקבל מכם אישור מפורש (דרך אימייל או דרך webhook) כשהם יצטרכו גישה לתוכן שלכם.
הצדקות גישה למפתחות מאפשרות לכם להגדיר מדיניות במפתחות Cloud KMS כדי להציג, לאשר ולדחות בקשות גישה למפתחות בהתאם לקוד ההצדקה שסופק.
כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- אתם רוצים שצוות מרכזי ינהל ישירות את הגישה לתוכן שלכם על ידי צוות Google.
- באישור גישה, אתם יכולים לקחת את הסיכון שחשוב יותר לאשר או לדחות כל בקשת גישה מאשר להתפשר על התפעול, מה שעלול להוביל לפתרון איטי יותר של פניות לתמיכה.
- במקרה של הצדקות לגישה למפתחות, העסק שלכם כבר משתמש ב-Assured Workloads כחלק מאסטרטגיית התאימות שלו, ורוצה שליטה פרוגרמטית בכל סוגי הגישה לנתונים מוצפנים.
אל תבחרו באפשרות הזו אם מתקיים אחד מהתנאים הבאים:
- העיכוב התפעולי שעלול להתרחש כשצוות מרכזי עם הרשאה לאישור גישה צריך להגיב הוא סיכון בלתי קביל לעומסי עבודה שנדרשת בהם זמינות גבוהה ותגובה מהירה מצוות תמיכת הלקוחות.
למידע נוסף, קראו את המאמרים הבאים:
שיטות מומלצות לאבטחה של Google Cloud אזורי נחיתה
בנוסף להחלטות שמוצגות במאמר הזה, כדאי להשתמש בשיטות המומלצות הבאות לשמירה על אבטחה:
- הקצאת הזהויות בסביבה שלכם. מידע נוסף זמין במאמר החלטה לגבי צירוף זהויות ל- Google Cloud.
- תכנון רשת שתענה על תרחישי השימוש של הארגון. מידע נוסף זמין במאמר קביעת עיצוב הרשת לאזור הנחיתה של Google Cloud .
- מטמיעים את האילוצים של מדיניות הארגון שמוגדרים בתוכנית ה-blueprint של Enterprise Foundations. האילוצים האלה עוזרים למנוע בעיות אבטחה נפוצות, כמו יצירה של כתובות IP חיצוניות מיותרות או הקצאת תפקיד העריכה לכל חשבונות השירות.
- כדאי לעיין ברשימה המלאה של הגבלות מדיניות הארגון כדי להעריך אם אמצעי בקרה אחרים רלוונטיים לדרישות שלכם. כל הארגונים שנוצרו אחרי 23 במאי 2024, נאכפים בהם Google Cloud אילוצים של מדיניות אבטחה מהיסוד כשיוצרים את משאב הארגון.
המאמרים הבאים
- מומלץ לעיין בתוכנית לניהול יסודות האבטחה בארגון.
- אפשר לקרוא עוד על שיטות מומלצות לאבטחה בGoogle Cloud מסגרת Well-Architected.