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

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

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

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

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

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

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

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

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

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

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