מנוע Stellar Engine מתוכנן עם שלבים בשכבות כדי ליישם בידוד של תלות, הגנה על המידע ופריסות שניתן לחזור עליהן. המאגר מחולק לארבעה שלבים עוקבים, וכל שלב אחראי לדומיין ספציפי של אזור הנחיתה.
שלב 0: אתחול
בשלב האתחול מתבצעת אתחול של התשתית המינימלית הנדרשת לניהול תהליך הפריסה עצמו, והיא משמשת כבסיס מהימן לצינור ה-IaC.
בשלב הזה נעשה שימוש בעיקרון של הרשאות מינימליות עבור חשבון השירות של הפורס הראשוני, והפרדה קפדנית של ההיררכיה האדמיניסטרטיבית.
המטרה בשלב הזה היא ליצור את הפריטים הבאים:
- קרן אדמיניסטרטיבית
- ניהול מצב מרחוק
- היקף האבטחה הראשוני
המשאבים הבאים נוצרים:
- חיבורים לחשבון חיוב מרכזי והתראות לגבי תקציבים
- פרויקט IaC ייעודי לאדמין לאירוח חשבונות שירות לפריסה
- קטגוריות Cloud Storage מאובטחות לאחסון מצב של Terraform במיקום מרוחק עם ניהול גרסאות של אובייקטים
- יעדי יומני ביקורת גלובליים שמשולבים עם דלי Cloud Logging מרכזי
- הגדרת אנשי קשר חיוניים כדי לוודא שהתראות בנושא אבטחה, טכני וחיוב יועברו רק לדומיינים של סוכנויות מורשות
שלב 1: ניהול המשאבים
בשלב ניהול המשאבים נוצרת ההיררכיה הארגונית, גבולות הגישה והפרדה בין דיירים.
המטרה של השלב הזה היא להגדיר את התיקיות, הפרויקטים והתפקידים המותאמים אישית של ניהול זהויות והרשאות גישה שנדרשים למסגרות רגולטוריות ספציפיות.
בשלב הזה נעשה שימוש בעיקרון של הפרדת תפקידים בין דומיינים אדמיניסטרטיביים שונים, ובידוד קפדני של משאבים.
המשאבים הבאים נוצרים:
- היררכיית תיקיות שתואמת לדרישות התאימות (לדוגמה,
Prod,Non-Prod,Securityו-Shared) - פרויקטים ייעודיים של דיירים שמבודדים לפי סביבה ופונקציה
- תפקידים מותאמים אישית וקשירת תפקידי IAM ברמת גרנולריות גבוהה כדי לאכוף הרשאות מינימליות
שלב 2: יצירת קשרים
בשלב Networking מוקצים נתיבי התקשורת, אמצעי בקרה לאבטחת הגבולות וקישוריות היברידית. מנוע Stellar תומך בכמה מודולים של רשתות, כולל FedRAMP High ו-IL5 NGFW.
המטרה של השלב הזה היא ליצור תבניות קישוריות מאובטחות, סינון מנות (packet) ובקרות כניסה או יציאה.
בשלב הזה מתמקדים בהגנה קפדנית על הגבולות, בבדיקה מרכזית של התנועה ובסינון עמוק של מנות מידע. אחרי שמריצים את השלב הזה, משלבים פתרון SIEM כדי לעקוב אחרי המשאבים. פילוח של מערכת SIEM בפרויקטGoogle Cloud נפרד וב-VPC נפרד מהמקום שבו היא אוספת נתונים.
המשאבים הבאים נוצרים:
- טופולוגיות של VPC משותף מסוג Hub-and-spoke או ארכיטקטורות של Network Connectivity Center שמצמצמות את החשיפה לציבור
- קישור בין רשתות VPC שכנות (peering), Cloud VPN או חיבורי Dedicated Interconnect לעומסי עבודה היברידיים
- ניתוב VPC רגיל או שרשור שירותים מתקדם באמצעות חומות אש מהדור הבא (NGFW) מסדרת Palo Alto VM (נדרש למובלעות DoD IL5) ב-VPC ייעודי לבדיקה
שלב 3: אבטחה וביקורת
בשלב האבטחה והביקורת מופעלות אכיפות הצפנה, נעילות סופיות ואחריותיות של השירות.
המטרה של השלב הזה היא לשפר את ההגנה על הנתונים, את יכולת המעקב אחר ביקורות ואת הריבונות הקריפטוגרפית.
השלב הזה מתמקד בריבונות במצב מנוחה, בריבונות בשימוש ובבידוד קריפטוגרפי קפדני של הנתונים.
המשאבים הבאים נוצרים:
- מפתחות וטבעות מפתחות של Cloud Key Management Service (Cloud KMS) כדי לעמוד בדרישות של מפתחות הצפנה בניהול הלקוח (CMEK) לכל שירותי האחסון
- סקריפטים של נעילת אבטחה ואילוצים של שירות מדיניות הארגון שמוחלים על חשבונות השירות שמשמשים במהלך הפריסה
- נושאים להודעות ללא מוצא והתראות על הטמעה שנכשלה של יומן ביקורת
עקרונות הפריסה
בטבלה הבאה מתוארים העקרונות שבהם נעשה שימוש ב-Stellar Engine בתהליך הפריסה.
| עקרונות | תיאור |
|---|---|
| בידוד של מצב |
קובצי המצב של Terraform מופרדים באופן מוחלט לפי שלב. לדוגמה, באג או פגיעה במצב בשלב 2 לא יכולים לגשת למצב הליבה או לפרטי הכניסה של שלב 0 או שלב 1, או לפגוע בהם. |
| הצמדת גרסת מודול |
התוכניות מתייחסות לתלויות מודולריות באמצעות תגי Git מוצמדים או גיבובים של קומיטים. הצמדה עוזרת לוודא ששינויים במעלה הזרם במאגר המודולים לא מוצגים אוטומטית בסביבות היעד בלי בדיקה מפורשת. |
| הגבלת ההשפעה |
העדכונים מבוצעים באופן מקומי בספריות של השלב. הגבלת ההשפעה עוזרת לוודא ששינוי בקוד של כללי חומת האש בשלב 2 לא ישפיע על מפתחות Cloud KMS בשלב 3. |
| הכלה של כשלים |
קטגוריות של מצב Cloud Storage מוגדרות עם ניהול גרסאות של אובייקטים. אם שינוי קוד שגוי או עריכה ידנית של מצב משחיתים את קובץ המצב, אפשר לשחזר את הקובץ באופן מיידי לגרסה קודמת. |