עיצוב וארכיטקטורה של גבולות גזרה לשירות

במסמך הזה מתוארות ארכיטקטורות מומלצות לפריסה של VPC Service Controls. המסמך הזה מיועד לאדמינים של רשתות, לאדריכלי אבטחה ולמומחים בתפעול ענן שמריצים ומפעילים פריסות גדולות בקנה מידה של ייצור ב- Google Cloud ושרוצים לצמצם את הסיכון לאובדן של נתונים רגישים.

ההגנה של VPC Service Controls משפיעה על הפונקציונליות של שירותי הענן, ולכן מומלץ לתכנן מראש את ההפעלה של VPC Service Controls ולשקול את השימוש בו במהלך תכנון הארכיטקטורה. חשוב שהעיצוב של VPC Service Controls יהיה פשוט ככל האפשר. מומלץ להימנע מתכנוני היקף שמשתמשים בכמה גשרים, בפרויקטים של רשתות היקפיות או בהיקף DMZ, וברמות גישה מורכבות.

שימוש בהיקף אחיד משותף

ההגנה היעילה ביותר מפני זליגת נתונים היא באמצעות היקף משותף ומאוחד, שהוא היקף גדול יחיד, ולא באמצעות היקפים מרובים ומפולחים.

היקף אחיד משותף גם מספק יתרון של תקורה נמוכה יותר לניהול עבור הצוותים שאחראים ליצירה ולתחזוקה של ההיקף. מכיוון ששירותים ומשאבי רשת בתוך גבולות גזרה יכולים לתקשר באופן חופשי עם ההרשאות הנדרשות של IAM ובקרות הרשת, הצוותים שאחראים על ניהול גבולות הגזרה יתמקדו בעיקר בגישה מצפון לדרום, שהיא גישה מהאינטרנט למשאבים בתוך גבולות הגזרה.

כשארגון משתמש בכמה גבולות גזרה קטנים יותר, צוותי ניהול גבולות הגזרה צריכים להקדיש משאבים לניהול תנועת נתונים ממזרח למערב בין גבולות הגזרה של הארגון, בנוסף לתנועת נתונים מצפון לדרום שמגיעה מחוץ לארגון. בהתאם לגודל הארגון ולמספר ההיקפים, התקורה הזו יכולה להיות משמעותית. מומלץ להוסיף שכבת הגנה לגבולות הגזרה באמצעות אמצעי אבטחה נוספים ושיטות מומלצות, למשל לוודא שלמשאבים ברשת ה-VPC אין גישה ישירה לתעבורת נתונים יוצאת (egress) לאינטרנט.

חומות אבטחה לשירותים לא נועדו להחליף את אמצעי הבקרה של IAM או לצמצם את הצורך בהם. כשמגדירים אמצעי בקרה לגישה, מומלץ לוודא שפועלים לפי העיקרון של הרשאות מינימליות ומיישמים את השיטות המומלצות לשימוש ב-IAM.

מידע נוסף מופיע במאמר יצירת היקף שירות.

שימוש בכמה היקפים בארגון אחד

במקרים מסוימים, יכול להיות שארגון יצטרך כמה היקפים. לדוגמה, ארגון שמטפל בנתונים של שירותי בריאות עשוי לרצות להגדיר מתחם אחד לנתונים מהימנים ולא מוצפנים, ומתחם נפרד לנתונים ברמה נמוכה יותר שעברו הסרת פרטים מזהים, כדי לאפשר שיתוף עם גורמים חיצוניים תוך שמירה על הנתונים המהימנים.

אם הארגון שלכם רוצה לעמוד בתקנים כמו PCI DSS, יכול להיות שתרצו ליצור גבולות גזרה נפרדים סביב הנתונים המפוקחים.

אם שיתוף נתונים הוא תרחיש שימוש מרכזי בארגון שלכם, כדאי להשתמש ביותר מגבולות גזרה אחד. אם אתם יוצרים ומשתפים נתונים ברמה נמוכה יותר, כמו נתוני בריאות של מטופלים שעברו הסרת פרטי זיהוי, אתם יכולים להשתמש בגבולות גזרה נפרדים כדי לאפשר שיתוף עם גורמים חיצוניים. מידע נוסף זמין במאמר בנושא דפוסי הפניה להחלפת נתונים מאובטחת.

בנוסף, אם אתם משתמשים בארגון Google Cloud שלכם כדי לארח דיירים עצמאיים של צד שלישי, כמו שותפים או לקוחות, כדאי להגדיר גבולות גזרה לכל דייר. אם אתם רואים בהעברת נתונים מאחד הדיירים האלה לדייר אחר חדירה לא מורשית, מומלץ להטמיע גבולות גזרה נפרדים.

עיצוב היקפי

מומלץ להפעיל את כל השירותים המוגנים כשיוצרים היקף, כדי לצמצם את המורכבות התפעולית ולמזער את הווקטורים הפוטנציאליים של העברת נתונים לא מורשית. השארת ממשקי API לא מוגנים מגדילה את הסיכויים לנקודות חולשה שדרכן אפשר להוציא מידע, ולכן אם הארגון שלכם בוחר להגן על ממשק API אחד ולא על אחר, צריך לבצע בדיקות ולספק הצדקות.

כל הפרויקטים החדשים צריכים לעבור את תהליך הבדיקה וההסמכה שמתואר בקטעים הבאים. כלולים בגבולות הגזרה כל הפרויקטים שעומדים בתנאי הזכאות.

מוודאים שאין נתיב ל-VIP הפרטי מאף אחד מה-VPC בהיקף. אם מאפשרים נתיב רשת ל-private.googleapis.com, ההגנה של VPC Service Controls מפני זליגת נתונים על ידי משתמשים פנימיים לא תהיה תקפה. אם אתם חייבים לאפשר גישה לשירות שלא נתמך, נסו לבודד את השימוש בשירותים שלא נתמכים בפרויקט נפרד, או להעביר את כל עומס העבודה אל מחוץ לגבולות הגזרה.

בדיקה של פרויקטים והתאמה שלהם

בארגון טיפוסי יש הרבה פרויקטים שמייצגים עומסי עבודה ומבנים ברמה גבוהה כמו מישורי בקרה, אגמי נתונים, יחידות עסקיות ושלבים במחזור החיים. בנוסף לארגון הפרויקטים והרכיבים האלה בתיקיות, מומלץ להגדיר אותם כך שיהיו בתוך גבולות גזרה של VPC Service Controls או מחוץ להם. כדי לקבוע את רמת ההסמכה, כדאי לענות על השאלות הבאות:

  • האם יש רכיב שתלוי באופן מוחלט בשירות ש-VPC Service Controls לא תומך בו?

    האכיפה של VPC Service Controls היא חד-משמעית, ולכן יכול להיות שתלות מסוג כזה לא תפעל בהיקף. מומלץ לשנות את עומס העבודה כדי לבודד את הדרישה לשירותים שלא נתמכים בפרויקט נפרד, או להעביר את עומס העבודה אל מחוץ לגבולות גזרה.

  • האם הפרויקט מכיל רק רכיבים שלא כוללים מידע אישי רגיש ולא צורכים מידע אישי רגיש מפרויקטים אחרים?

אם עניתם 'כן' על אחת מהשאלות הקודמות, אנחנו ממליצים שלא תכניסו את הפרויקט לגבולות גזרה. אפשר לעקוף את הבעיה הזו, כמו שמוסבר בנושא עיצוב רשימת ההיתרים. עם זאת, מומלץ לצמצם את המורכבות של גבולות הגזרה.

המאמרים הבאים