ארכיטקטורות בלי שרת (serverless) מאפשרות לפתח תוכנות ושירותים בלי לספק או לתחזק שרתים. אתם יכולים להשתמש בארכיטקטורות ללא שרת כדי לפתח אפליקציות למגוון רחב של שירותים.
במסמך הזה אנחנו מספקים הנחיות מבוססות-ניסיון למהנדסי DevOps, לאדריכלי אבטחה ולמפתחי אפליקציות, כדי לעזור להם להגן על אפליקציות בלי שרת (serverless) שמשתמשות בפונקציות Cloud Run (דור שני). המסמך הזה הוא חלק מתוכנית אבטחה שכוללת את הרכיבים הבאים:
- מאגר ב-GitHub שמכיל קבוצה של תצורות וסקריפטים של Terraform.
- מדריך לארכיטקטורה, לעיצוב ולאמצעי הבקרה לאבטחה שאתם מטמיעים באמצעות תוכנית האבטחה (המסמך הזה).
אפשר לפרוס את תוכנית הפעולה הזו בלי לפרוס קודם את Google Cloud תוכנית הפעולה של Enterprise Foundations, אבל במסמך הזה מניחים שכבר הגדרתם קבוצה בסיסית של אמצעי בקרה לאבטחה, כמו שמתואר ב Google Cloud תוכנית הפעולה של Enterprise Foundations. הארכיטקטורה שמתוארת במסמך הזה עוזרת לכם להוסיף שכבות של אמצעי בקרה על הבסיס כדי להגן על האפליקציות חסרות השרתים שלכם.
כדי לעזור להגדיר אמצעי בקרה מרכזיים שקשורים לאפליקציות בלי שרת (serverless), Cloud Security Alliance (CSA) פרסמה את 12 הסיכונים הקריטיים המובילים לאפליקציות בלי שרתים. אמצעי האבטחה שבהם נעשה שימוש בתוכנית הזו נועדו לתת מענה לסיכונים שרלוונטיים לתרחישי השימוש השונים שמתוארים במסמך הזה.
תרחישים לדוגמה לשימוש ב-Serverless
התוכנית תומכת בתרחישי השימוש הבאים:
- פריסת ארכיטקטורה ללא שרת באמצעות פונקציות Cloud Run (המסמך הזה)
- פריסת ארכיטקטורה בלי שרת (serverless) באמצעות Cloud Run
ההבדלים בין פונקציות Cloud Run לבין Cloud Run כוללים את הדברים הבאים:
- פונקציות Cloud Run מופעלות על ידי אירועים, כמו שינויים בנתונים במסד נתונים או קבלת הודעה ממערכת העברת הודעות כמו Pub/Sub. הפעלת Cloud Run מתבצעת על ידי בקשות, כמו בקשות HTTP.
- פונקציות Cloud Run מוגבלות לקבוצה של סביבות זמן ריצה נתמכות. אפשר להשתמש ב-Cloud Run עם כל שפת תכנות.
- פונקציות Cloud Run מנהלות את הקונטיינרים ואת התשתית ששולטת בשרת האינטרנט או בזמן הריצה של השפה, כדי שתוכלו להתמקד בקוד. Cloud Run מאפשר לכם להריץ את השירותים האלה בעצמכם, כדי שתוכלו לשלוט בהגדרות של הקונטיינר.
מידע נוסף על ההבדלים בין Cloud Run לבין פונקציות Cloud Run זמין במאמר בחירת אפשרות מחשוב. Google Cloud
ארכיטקטורה
התוכנית הזו משתמשת בארכיטקטורה של VPC משותף, שבה פונקציות Cloud Run נפרסות בפרויקט שירות ויכולות לגשת למשאבים שנמצאים ברשתות VPC אחרות.
התרשים הבא מציג ארכיטקטורה ברמה גבוהה, שמתוארת בפירוט בדוגמאות לארכיטקטורות שמופיעות אחריו.
בארכיטקטורה שמוצגת בתרשים הקודם נעשה שימוש בשילוב של התכונות והשירותים הבאים Google Cloud :
- פונקציות Cloud Run מאפשרות להפעיל פונקציות כשירות ולנהל את התשתית בשמכם. כברירת מחדל, הארכיטקטורה הזו פורסת פונקציות Cloud Run עם כתובת IP פנימית בלבד, ללא גישה לאינטרנט הציבורי.
- אירוע ההפעלה הוא האירוע שמפעיל פונקציות Cloud Run. כפי שמתואר בהמשך בדוגמאות לארכיטקטורות, זה יכול להיות אירוע של Cloud Storage, מרווח זמן מתוזמן או שינוי ב-BigQuery.
- Artifact Registry מאחסן את קונטיינרי המקור של אפליקציית הפונקציות של Cloud Run.
- VPC משותף מאפשר לכם לחבר מחבר של חיבור לרשת (VPC) מאפליקציית serverless בפרויקט השירות לפרויקט המארח. פורסים רשת VPC משותפת נפרדת לכל סביבה (ייצור, לא ייצור ופיתוח). תכנון הרשת הזה מספק בידוד רשת בין הסביבות השונות. רשת VPC משותפת מאפשרת לכם לנהל באופן מרכזי משאבים ברשת משותפת, תוך הקצאת אחריות ניהולית לפרויקט השירות.
מחבר Serverless VPC Access מחבר את אפליקציית ה-serverless לרשת ה-VPC באמצעות Serverless VPC Access. חיבור לרשת (VPC) מאפליקציית serverless עוזר לוודא שבקשות מאפליקציית serverless לרשת VPC לא נחשפות לאינטרנט. בעזרת Serverless VPC Access, פונקציות Cloud Run יכולות לתקשר עם שירותים אחרים, מערכות אחסון ומשאבים שתומכים ב-VPC Service Controls.
אפשר להגדיר חיבור לרשת (VPC) מאפליקציית serverless בפרויקט מארח של VPC משותף או בפרויקט שירות. כברירת מחדל, תוכנית ה-blueprint הזו פורסת חיבור לרשת (VPC) מאפליקציית serverless בפרויקט המארח של ה-VPC המשותף, כדי להתאים למודל ה-VPC המשותף של ריכוז משאבי הגדרת הרשת. מידע נוסף זמין במאמר השוואה בין שיטות ההגדרה.
VPC Service Controls יוצרת מתחם אבטחה היקפית שמבודד את פונקציות Cloud Run, השירותים והמשאבים שלכם באמצעות הגדרת הרשאות, אמצעי בקרה לגישה והחלפת נתונים מאובטחת. גבולות גזרה אלה נועדו לבודד את האפליקציה והשירותים המנוהלים שלכם על ידי הגדרת בקרת גישה ומעקב נוספים, ולהפריד את הניהול של Google Cloud מהאפליקציה. השליטה שלכם כוללת ניהול מפתחות ורישום ביומן.
שירות הצרכן הוא האפליקציה שפונקציות Cloud Run פועלות עליה. שירות הצרכן יכול להיות שרת פנימי או שירות אחר כמו Cloud SQL. Google Cloud בהתאם לתרחיש השימוש, יכול להיות שהשירות הזה נמצא מאחורי Cloud Next Generation Firewall, ברשת משנה אחרת, באותו פרויקט שירות כמו פונקציות Cloud Run או בפרויקט שירות אחר.
Secure Web Proxy נועד לאבטח את תעבורת האינטרנט היוצאת, אם נדרש. הוא מאפשר להגדיר מדיניות גמישה ומפורטת שמבוססת על זהויות בענן ועל אפליקציות אינטרנט. תוכנית האב הזו משתמשת ב-Secure Web Proxy כדי להגדיר מדיניות גישה גרנולרית לתעבורת אינטרנט יוצאת במהלך שלב הבנייה של פונקציות Cloud Run. תוכנית ה-Blueprint מוסיפה רשימה של כתובות URL מותרות לכלל מדיניות האבטחה של שער.
Cloud NAT מספק חיבור יוצא לאינטרנט, אם נדרש. Cloud NAT תומך בתרגום כתובות רשת של מקור (SNAT) למשאבי מחשוב ללא כתובות IP ציבוריות. חבילות תגובה נכנסות משתמשות בתרגום כתובות רשת של יעד (DNAT). אפשר להשבית את Cloud NAT אם פונקציות Cloud Run לא צריכות גישה לאינטרנט. שירות Cloud NAT מטמיע את מדיניות הרשת היוצאת (egress) שמצורפת ל-Secure Web Proxy.
Cloud Key Management Service (Cloud KMS) מאחסן את מפתחות ההצפנה בניהול הלקוח (CMEK) שבהם משתמשים השירותים בתוכנית הזו, כולל האפליקציה ללא שרת, Artifact Registry ופונקציות Cloud Run.
Secret Manager מאחסן את הסודות של פונקציות Cloud Run. התוכנית מציגה סודות כנפח כדי לספק רמת אבטחה גבוהה יותר מאשר העברת סודות כמשתני סביבה.
ניהול זהויות והרשאות גישה (IAM) ומנהל המשאבים עוזרים להגביל את הגישה ולבודד משאבים. אמצעי בקרת הגישה והיררכיית המשאבים פועלים לפי העיקרון של הרשאות מינימליות.
Cloud Logging אוסף את כל היומנים משירותי Google Cloud לאחסון ולאחזור על ידי כלי הניתוח והחקירה שלכם.
Cloud Monitoring אוסף ושומר נתוני ביצועים ומדדים לגביGoogle Cloud שירותים.
דוגמה לארכיטקטורה עם אפליקציה ללא שרת באמצעות Cloud Storage
הדיאגרמה הבאה מציגה איך אפשר להפעיל אפליקציה בלי שרת (serverless) שמתבצעת בה גישה לשרת פנימי כשאירוע מסוים מתרחש ב-Cloud Storage.
בנוסף לשירותים שמתוארים בקטע ארכיטקטורה, הארכיטקטורה לדוגמה הזו משתמשת בשילוב של השירותים והתכונות הבאים של Google Cloud:
- Cloud Storage שולח אירוע כשמשאב בענן, אפליקציה או משתמש יוצרים אובייקט אינטרנט בדלי.
- Eventarc מעביר אירועים ממקורות שונים. Eventarc מצפין אירועים בזמן ההעברה ובזמן האחסון.
- Pub/Sub מכניס לתור אירועים שמשמשים כקלט וכטריגר לפונקציות Cloud Run.
- כללי חומת האש של ענן וירטואלי פרטי (VPC) שולטים בזרימת הנתונים אל רשת המשנה שמארחת את המשאבים שלכם, כמו שרת פנימי.
- השרת הפנימי פועל ב-Compute Engine או ב-Google Kubernetes Engine ומארח את האפליקציה הפנימית שלכם. אם פורסים את פונקציות Cloud Run מאובטחות עם דוגמה של שרת פנימי, פורסים שרת Apache עם דף HTML של Hello World. בדוגמה הזו יש סימולציה של גישה לאפליקציה פנימית שמריצה מכונות וירטואליות או קונטיינרים.
דוגמה לארכיטקטורה עם Cloud SQL
בתרשים הבא מוצג אופן ההפעלה של אפליקציה בלי שרת (serverless) שניגשת לשירות מארח של Cloud SQL במרווח קבוע שמוגדר ב-Cloud Scheduler. אתם יכולים להשתמש בארכיטקטורה הזו כשאתם צריכים לאסוף יומנים, לצבור נתונים וכו'.
בנוסף לשירותים שמתוארים בקטע ארכיטקטורה, הארכיטקטורה לדוגמה הזו משתמשת בשילוב של השירותים והתכונות הבאים של Google Cloud:
- Cloud Scheduler פולט אירועים באופן קבוע.
- Pub/Sub מכניס לתור אירועים שמשמשים כקלט וכטריגר לפונקציות Cloud Run.
- כללי חומת אש של ענן וירטואלי פרטי (VPC) שולטים בזרימת הנתונים אל רשת המשנה שמארחת את המשאבים, כמו נתונים של החברה שמאוחסנים ב-Cloud SQL.
- שרת proxy ל-Cloud SQL Auth שולט בגישה ל-Cloud SQL.
- Cloud SQL מארח שירות שמוגדר כרשת שכנה לרשת ה-VPC, והאפליקציה ללא שרת יכולה לגשת אליו. אם פורסים את הפונקציות המאובטחות של Cloud Run עם הדוגמה של Cloud SQL, פורסים מסד נתונים של MySQL עם מסד נתונים לדוגמה.
דוגמה לארכיטקטורה עם מחסן נתונים של BigQuery
בתרשים הבא מוצג תהליך ההפעלה של אפליקציה בלי שרת (serverless), שמופעלת כשמתרחש אירוע ב-BigQuery (לדוגמה, כשנתונים מתווספים או כשנוצרת טבלה).
בנוסף לשירותים שמתוארים בקטע ארכיטקטורה, הארכיטקטורה לדוגמה הזו משתמשת בשילוב של השירותים והתכונות הבאים של Google Cloud:
- BigQuery מארח מחסן נתונים (data warehouse). אם פורסים את הפונקציות המאובטחות של Cloud Run שהופעלו על ידי BigQuery, פורסים מערך נתונים וטבלה לדוגמה של BigQuery.
- Eventarc מפעיל פונקציות Cloud Run כשמתרחש אירוע מסוים ב-BigQuery.
מבנה ארגוני
מנהל המשאבים מאפשר לקבץ משאבים באופן לוגי לפי פרויקט, תיקייה וארגון.
התרשים הבא מציג היררכיית משאבים עם תיקיות שמייצגות סביבות שונות, כמו bootstrap, common, production, non-production (או testing) ו-development. היררכיית המשאבים הזו מבוססת על ההיררכיה שמתוארת בתוכנית הבסיסית לארגונים.
אתם פורסים את הפרויקטים שמוגדרים בתוכנית הבסיסית בתיקיות הבאות: Common, Production, Non-production ו-Dev.
בקטעים הבאים מוסבר התרשים הזה בפירוט.
תיקיות
אתם משתמשים בתיקיות כדי לבודד את סביבת הייצור ואת שירותי הניהול מסביבות הבדיקה והסביבות שאינן סביבות ייצור. בטבלה הבאה מתוארות התיקיות מתוכנית ה-Blueprint של יסודות הארגון שמשמשות את תוכנית ה-Blueprint הזו.
| תיקייה | תיאור |
|---|---|
Bootstrap
|
מכיל משאבים שנדרשים לפריסת תוכנית הבסיס לארגונים. |
Common
|
מכיל שירותים מרכזיים לארגון, כמו פרויקט האבטחה. |
Production
|
מכיל פרויקטים עם משאבי ענן שנבדקו ומוכנים לשימוש על ידי לקוחות. בתוכנית הזו, התיקייה Production מכילה את פרויקט השירות ואת הפרויקט המארח. |
Non-production
|
מכיל פרויקטים עם משאבי ענן שנמצאים כרגע בבדיקה ובהכנה להשקה. בתוכנית הזו, התיקייה Non-production מכילה את פרויקט השירות ואת הפרויקט המארח. |
Development
|
מכיל פרויקטים עם משאבי ענן שנמצאים כרגע בתהליך פיתוח. בתוכנית הזו, התיקייה Development מכילה את פרויקט השירות ואת הפרויקט המארח. |
אתם יכולים לשנות את השמות של התיקיות האלה כדי להתאים אותם למבנה התיקיות של הארגון, אבל מומלץ לשמור על מבנה דומה. מידע נוסף מופיע במאמר בנושא מבנה ארגוני. למידע על מבני תיקיות אחרים, אפשר לקרוא את המאמר בחירה של היררכיית משאבים לאזור הנחיתה ב- Google Cloud .
פרויקטים
אתם מבודדים משאבים בסביבה שלכם באמצעות פרויקטים. בטבלה הבאה מתוארים הפרויקטים שנדרשים בארגון. אפשר לשנות את השמות של הפרויקטים האלה, אבל מומלץ לשמור על מבנה פרויקט דומה.
| פרויקט | תיאור |
|---|---|
| פרויקט מארח של VPC משותף | הפרויקט הזה כולל את כללי חומת האש של תעבורת נתונים נכנסת (ingress) וכל משאב שיש לו כתובת IP פנימית (כפי שמתואר במאמר חיבור לרשת VPC). כשמשתמשים ב-VPC משותף, מגדירים פרויקט כמארח ומצרפים אליו פרויקט שירות אחד או יותר. כשמחילים את קוד Terraform, מציינים את השם של הפרויקט הזה, והתוכנית פורסת את המחבר של הגישה ל-VPC ללא שרת, את Cloud NAT ואת Cloud Secure Web Proxy. |
| פרויקט שירות של VPC משותף | הפרויקט הזה כולל את האפליקציה שלכם בלי שרת (serverless), פונקציות Cloud Run ומחבר של חיבור לרשת (VPC) מאפליקציית serverless. מצרפים את פרויקט השירות לפרויקט המארח כדי שפרויקט השירות יוכל להשתתף ברשת ה-VPC המשותפת. כשמחילים את קוד Terraform, מציינים את שם הפרויקט הזה. תוכנית האב פורסת פונקציות ושירותים של Cloud Run שנדרשים לתרחיש השימוש שלכם, כמו Cloud SQL, Cloud Scheduler, Cloud Storage או BigQuery. כשמחילים את קוד Terraform, מציינים את שם הפרויקט הזה, והתוכנית פורסת את Cloud KMS. אם משתמשים במודול Secure Serverless Harness בתוכנית הבסיסית ללא שרת לפונקציות של Cloud Run, Artifact Registry נפרס גם הוא. |
| פרויקט אבטחה | הפרויקט הזה כולל את השירותים הספציפיים לאבטחה, כמו Cloud KMS ו-Secret Manager.
שם ברירת המחדל של פרויקט האבטחה הוא אם פורסים כמה מופעים של תוכנית ה-Blueprint הזו בלי תוכנית ה-Blueprint של יסודות הארגון, לכל מופע יש פרויקט אבטחה משלו. |
מיפוי תפקידים וקבוצות לפרויקטים
צריך לתת לקבוצות משתמשים שונות בארגון גישה לפרויקטים שמרכיבים את הארכיטקטורה בלי שרת (serverless). בטבלה הבאה מפורטות ההמלצות לתוכניות Blueprint לגבי קבוצות משתמשים והקצאות תפקידים בפרויקטים שאתם יוצרים. אפשר להתאים אישית את הקבוצות כך שיתאימו למבנה הקיים של הארגון, אבל מומלץ לשמור על הפרדה דומה של התפקידים והקצאת התפקידים.
| קבוצה | פרויקט | תפקידים |
|---|---|---|
| אדמין ללא שרת (serverless) grp-gcp-serverless-admin@example.com |
פרויקט שירות | |
| אדמין לענייני אבטחה ללא שרת grp-gcp-serverless-security-admin@example.com |
פרויקט אבטחה |
|
| מפתח פונקציות Cloud Run grp-gcp-secure-cloud-run-developer@example.com |
פרויקט אבטחה | |
| משתמש בפונקציות Cloud Run grp-gcp-secure-cloud-run-user@example.com |
פרויקט שירות של VPC משותף |
אמצעי בקרה לאבטחה
בקטע הזה מוסבר על אמצעי האבטחה ב- Google Cloud שבהם אתם משתמשים כדי לאבטח את הארכיטקטורה בלי שרת (serverless). עקרונות האבטחה העיקריים שכדאי לקחת בחשבון הם:
- גישה מאובטחת בהתאם לעיקרון של הרשאות מינימליות, שבו ניתנות לחשבונות משתמש רק ההרשאות שנדרשות לביצוע משימות.
- אבטחת חיבורים לרשת באמצעות תכנון גבולות אמון, שכולל פילוח רשת, מדיניות ארגונית ומדיניות חומת אש.
- הגדרת אבטחה לכל אחד מהשירותים.
- לזהות דרישות תאימות או רגולטוריות לתשתית שמארחת עומסי עבודה (workloads) ללא שרת (serverless) ולהקצות רמת סיכון.
- הגדרת מעקב ורישום ביומן שיהיו מספיקים כדי לתמוך בנתיבי ביקורת לפעולות אבטחה ולניהול אירועי אבטחה.
הגדרות של מערכת ה-build
כשפורסים את האפליקציה serverless, משתמשים ב-Artifact Registry כדי לאחסן את קובצי האימג' בקונטיינר ואת הקבצים הבינאריים. שירות Artifact Registry תומך ב-CMEK, כך שאתם יכולים להצפין את המאגר באמצעות מפתחות הצפנה משלכם.
כללי רשת וחומת אש
כללי חומת אש של ענן וירטואלי פרטי (VPC) שולטים בזרימת הנתונים אל המתחמים. אתם יוצרים כללים של חומת אש שחוסמים את כל תעבורת הנתונים היוצאת, למעט חיבורים ספציפיים ביציאת TCP 443 משמות דומיין מיוחדים של restricted.googleapis.com. השימוש בדומיין restricted.googleapis.com מציע את היתרונות הבאים:
- היא עוזרת לצמצם את שטח המתקפה ברשת באמצעות גישה פרטית ל-Google, כשעומסי עבודה מתקשרים עם שירותים ו-Google APIs.
- הוא מוודא שאתם משתמשים רק בשירותים שתומכים ב-VPC Service Controls.
בנוסף, יוצרים רשומת DNS כדי לפתור את *.googleapis.com ל-restricted.googleapis.com.
מידע נוסף זמין במאמר בנושא הגדרת גישה פרטית ל-Google.
אמצעי בקרה להיקף
כפי שמוצג בקטע ארכיטקטורה, המשאבים של האפליקציה בלי שרת (serverless) ממוקמים בגבולות גזרה נפרדים של VPC Service Controls. ההיקף הזה עוזר לצמצם את ההשפעה הרחבה של פגיעה באבטחה של מערכות או שירותים. עם זאת, היקף האבטחה הזה לא חל על תהליך ה-build של פונקציות Cloud Run כש-Cloud Build יוצר באופן אוטומטי קובץ אימג' של קונטיינר מהקוד שלכם ומעביר אותו בדחיפה ל-Artifact Registry. במקרה כזה, צריך ליצור כלל Ingress לחשבון השירות של Cloud Build בגבולות גזרה לשירות.
מדיניות גישה
כדי לוודא שרק גורמים ספציפיים (משתמשים או שירותים) יכולים לגשת למשאבים ולנתונים, צריך להפעיל קבוצות ותפקידים ב-IAM.
כדי לוודא שרק משאבים ספציפיים יוכלו לגשת לפרויקטים שלכם, אתם מפעילים מדיניות גישה לארגון שלכם ב-Google. מידע נוסף זמין במאמר בנושא מאפיינים של רמות גישה.
חשבונות שירות ובקרת גישה
חשבונות שירות הם חשבונות של אפליקציות או של עומסי עבודה ממוחשבים, ולא של משתמשי קצה. כדי להטמיע את העיקרון של הרשאות מינימליות ואת העיקרון של הפרדת תפקידים, צריך ליצור חשבונות שירות עם הרשאות מפורטות וגישה מוגבלת למשאבים. חשבונות השירות הם:
חשבון שירות של פונקציות Cloud Run (
cloudfunction_sa) עם התפקידים הבאים:- בעל הרשאת צפייה ברשת מחשוב (
roles/compute.networkViewer) - Eventarc Event Receiver (
roles/eventarc.eventReceiver) - Cloud Run Invoker (
roles/run.invoker) - Secret Manager Secret Assessor (
roles/secretmanager.secretAccessor)
מידע נוסף זמין במאמר מתן גישה לפונקציות Cloud Run לסוד.
פונקציות Cloud Run משתמשות בחשבון השירות הזה כדי להעניק הרשאה רק לנושאים ספציפיים ב-Pub/Sub, וכדי להגביל את מערכת האירועים של Eventarc ממשאבי מחשוב של פונקציות Cloud Run בארכיטקטורה לדוגמה עם אפליקציה בלי שרת באמצעות Cloud Storage ובארכיטקטורה לדוגמה עם מחסן נתונים של BigQuery.
- בעל הרשאת צפייה ברשת מחשוב (
חשבון של מחבר חיבור לרשת (VPC) מאפליקציית serverless (
gcp_sa_vpcaccess) עם התפקיד משתמש ברשת Compute (roles/compute.networkUser).חשבון שני של מחבר חיבור לרשת (VPC) מאפליקציית serverless (
cloud_services) עם התפקיד 'משתמש ברשת Compute' (roles/compute.networkUser).חשבונות השירות האלה נדרשים למחבר Serverless VPC Access כדי שהוא יוכל ליצור את כללי הכניסה והיציאה של חומת האש בפרויקט המארח. מידע נוסף מופיע במאמר הענקת הרשאות לחשבונות שירות בפרויקטים של שירות.
זהות שירות להרצת פונקציות Cloud Run (
cloudfunction_sa) עם התפקידים [משתמש של חיבור לרשת (VPC) מאפליקציית serverless (roles/vpcaccess.user)](/iam/docs/roles-permissions/vpcaccess#vpcaccess.user)) ומשתמש בחשבון שירות (roles/iam.serviceAccountUser).חשבון שירות עבור Google APIs (
cloud_services_sa) עם התפקיד 'משתמש ברשת Compute' (roles/compute.networkUser) להרצת תהליכים פנימיים של Google בשמכם.זהות שירות לפונקציות Cloud Run (
cloud_serverless_sa) עם התפקיד Artifact Registry Reader (roles/artifactregistry.reader). חשבון השירות הזה מספק גישה ל-Artifact Registry ול-CMEK.זהות שירות ל-Eventarc (
eventarc_sa) עם התפקידים Cloud KMS CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter) ו-Cloud KMS CryptoKey Encrypter (roles/cloudkms.cryptoKeyEncrypter).זהות שירות ל-Artifact Registry (
artifact_sa) עם התפקידים CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter) ו-Cloud KMS CryptoKey Encrypter (roles/cloudkms.cryptoKeyEncrypter).
ניהול מפתחות
כדי לאמת את התקינות ולעזור להגן על הנתונים באחסון, משתמשים ב-CMEK עם Artifact Registry, פונקציות Cloud Run, Cloud Storage ו-Eventarc. מפתחות CMEK מאפשרים לכם שליטה רבה יותר במפתח ההצפנה. נעשה שימוש במפתחות ה-CMEK הבאים:
- מפתח תוכנה ל-Artifact Registry שמאשר את הקוד של האפליקציה חסרת השרתים.
- מפתח הצפנה להצפנת קובצי האימג' של הקונטיינרים שפונקציות Cloud Run פורסות.
- מפתח הצפנה לאירועי Eventarc שמצפין את ערוץ העברת ההודעות במצב מנוחה.
- מפתח הצפנה שיעזור להגן על הנתונים ב-Cloud Storage.
כשמחילים את ההגדרות של Terraform, מציינים את המיקום של CMEK, שקובע את המיקום הגיאוגרפי שבו המפתחות מאוחסנים. צריך לוודא שמפתחות ה-CMEK נמצאים באותו אזור כמו המשאבים. כברירת מחדל, מפתחות CMEK עוברים רוטציה כל 30 יום.
ניהול סודות
פונקציות Cloud Run תומכות ב-Secret Manager לאחסון הסודות שאולי נדרשים לאפליקציה שלכם בלי שרת (serverless). הסודות האלה יכולים לכלול מפתחות API ושמות משתמשים וסיסמאות למסדי נתונים. כדי לחשוף את הסוד כנפח מוטמע, משתמשים במשתני האובייקט service_configs במודול הראשי.
כשפורסים את תוכנית ה-Blueprint הזו עם תוכנית ה-Blueprint של Enterprise Foundations, צריך להוסיף את הסודות לפרויקט הסודות לפני שמחילים את הקוד של Terraform. ה-blueprint יקצה את התפקיד Secret Manager Secret Assessor (roles/secretmanager.secretAccessor) לחשבון השירות של פונקציות Cloud Run. מידע נוסף מפורט במאמר בנושא שימוש בסודות.
מדיניות הארגון
תוכנית ה-blueprint הזו מוסיפה אילוצים לאילוצים של מדיניות הארגון שבהם נעשה שימוש בתוכנית ה-blueprint של התשתית הארגונית. למידע נוסף על המגבלות שמשמשות בתוכנית ה-blueprint של Enterprise Foundations, ראו מגבלות במדיניות הארגון.
בטבלה הבאה מתוארות המגבלות הנוספות של מדיניות הארגון שמוגדרות במודול Secure Cloud Run functions Security של תוכנית האבטחה הזו.
| מגבלת מדיניות | תיאור | הערך המומלץ |
|---|---|---|
הגדרות כניסה מותרות
(פונקציות Cloud Run)
constraints/cloudfunctions.allowedIngressSettings |
אפשר להגדיר שרק שירותים פנימיים או מאזן עומסים חיצוני מסוג HTTP(S) יוכלו לשלוח תעבורת נתונים נכנסת.
ערך ברירת המחדל הוא |
ALLOW_INTERNAL_ONLY
|
דרישה ל-VPC Connector (פונקציות Cloud Run)
constraints/cloudfunctions.requireVPCConnector |
נדרש לציין מחבר של חיבור לרשת (VPC) מאפליקציית serverless כשפורסים פונקציה. כשההגבלה הזו נאכפת, הפונקציות צריכות לציין מחבר של גישה ל-VPC מאפליקציית serverless.
ערך ברירת המחדל הוא |
true
|
הגדרות יציאה מותרות של מחבר VPC
(פונקציות Cloud Run)
cloudfunctions.allowedVpcConnectorEgressSettings |
הגדרת דרישה שכל תעבורת הנתונים היוצאת (egress) של פונקציות Cloud Run תשתמש במחבר Serverless VPC Access.
ערך ברירת המחדל הוא |
ALL_TRAFFIC
|
אמצעי בקרה תפעוליים
אתם יכולים להפעיל רישום ביומן ותכונות של רמת הפרימיום של Security Command Center, כמו Security Health Analytics וזיהוי איומים. אמצעי הבקרה האלה מאפשרים לכם:
- מעקב אחרי הגישה לנתונים.
- מוודאים שמתבצעת ביקורת נאותה.
- תמיכה ביכולות של תפעול אבטחה וניהול אירועי אבטחה בארגון.
רישום ביומן
כדי לעזור לכם לעמוד בדרישות הביקורת ולקבל תובנות לגבי הפרויקטים שלכם, אתם יכולים להגדיר את Google Cloud Observability עם יומני נתונים של השירותים שאתם רוצים לעקוב אחריהם. כדי לוודא שהתוכנית יכולה להגדיר את הרישום ביומן עבור חומת האש, מאזן העומסים ורשת ה-VPC, צריך לפרוס את Cloud Logging בפרויקטים לפני שמחילים את קוד Terraform.
אחרי שמפעילים את תוכנית האב, מומלץ להגדיר את הדברים הבאים:
- יוצרים sink ביומן מצטבר בכל הפרויקטים.
- מוסיפים מפתחות CMEK ליעד של היומן.
לכל השירותים בפרויקטים, צריך לוודא שהיומנים כוללים מידע על כתיבת נתונים ועל גישת אדמין. מידע נוסף על שיטות מומלצות לרישום ביומן זמין במאמר בנושא אמצעי בקרה לגילוי.
מעקב והתראות
אחרי שפורסים את תוכנית האבטחה, אפשר להגדיר התראות כדי להודיע למרכז האבטחה (SOC) שלכם שהתרחש אירוע אבטחה. לדוגמה, אפשר להשתמש בהתראות כדי לעדכן את אנליסטים האבטחה כשמשנים הרשאה בתפקיד IAM. מידע נוסף על הגדרת התראות ב-Security Command Center זמין במאמר בנושא הגדרה של התראות על ממצאים.
לוח הבקרה של Cloud Run functions Monitoring עוזר לכם לעקוב אחרי הביצועים והתקינות של פונקציות Cloud Run. הוא מספק מגוון מדדים ויומנים שבעזרתם אפשר לזהות ולפתור בעיות. מרכז הבקרה כולל גם מספר תכונות שיכולות לעזור לכם לשפר את הביצועים של הפונקציות, כמו האפשרות להגדיר התראות ומכסות.
מידע נוסף זמין במאמר בנושא מעקב אחרי פונקציות Cloud Run.
כדי לייצא התראות, אפשר לעיין במסמכים הבאים:
ניפוי באגים ופתרון בעיות
אפשר להריץ בדיקות קישוריות כדי לנפות באגים בבעיות בהגדרת הרשת בין פונקציות Cloud Run לבין המשאבים ברשת המשנה. בדיקות הקישוריות מדמות את הנתיב הצפוי של מנה (packet) ומספקות פרטים על הקישוריות, כולל ניתוח של הקישוריות בין משאבים.
הקוד של Terraform לא מפעיל את בדיקות הקישוריות, ולכן צריך להגדיר אותן בנפרד. מידע נוסף זמין במאמר בנושא יצירה והרצה של בדיקות קישוריות.
מצבי פריסה של Terraform
בטבלה הבאה מתוארות הדרכים שבהן אפשר לפרוס את תוכנית הניהול הזו, וגם מודולי Terraform שרלוונטיים לכל מצב פריסה.
| מצב פריסה | מודולים של Terraform |
|---|---|
מומלץ לפרוס את התוכנית הזו אחרי פריסת התוכנית של התשתית הארגונית. האפשרות הזו פורסת את המשאבים של תוכנית האב הזו באותו גבול גזרה של VPC Service Controls שבו נעשה שימוש בתוכנית האב של Enterprise Foundations. מידע נוסף זמין במאמר איך להתאים אישית את Foundation v3.0.0 לפריסה מאובטחת של פונקציות Cloud Run. האפשרות הזו משתמשת גם בפרויקט הסודות שיצרתם כשפרסתם את תוכנית האב של Enterprise Foundations. |
משתמשים במודולים הבאים של Terraform: |
התקנה של תוכנית הבסיס הזו בלי להתקין את תוכנית הבסיס לאבטחה. כדי להשתמש באפשרות הזו, צריך ליצור גבולות גזרה של VPC Service Controls. |
משתמשים במודולים הבאים של Terraform:
|
מסכם הכול
כדי להטמיע את הארכיטקטורה שמתוארת במסמך הזה:
- בודקים את הקובץ README של התוכנית כדי לוודא שאתם עומדים בכל הדרישות המוקדמות.
- כדי לראות את התוכנית בפעולה בסביבת הבדיקה, פורסים אחת מהדוגמאות.
הדוגמאות האלה תואמות לדוגמאות של הארכיטקטורה שמתוארות במאמר בנושא ארכיטקטורה.
במסגרת תהליך הבדיקה, כדאי לבצע את הפעולות הבאות:
- אפשר להשתמש ב-Security Command Center כדי לסרוק את הפרויקטים בהתאם לדרישות תאימות נפוצות.
- מחליפים את האפליקציה לדוגמה באפליקציה אמיתית (לדוגמה 1) ומריצים תרחיש פריסה טיפוסי.
- כדאי לעבוד עם צוותי הנדסת האפליקציות והתפעול בארגון כדי לבדוק את הגישה שלהם לפרויקטים, ולוודא שהם יכולים לבצע אינטראקציה עם הפתרון בצורה שהם מצפים לה.
- פורסים את התוכנית בסביבה שלכם.
המאמרים הבאים
- כדאי לעיין בGoogle Cloud תוכנית הבסיס לארגונים כדי ליצור סביבה מאובטחת.
- כדי לראות את פרטי התוכנית, אפשר לקרוא את קובץ ה-README של הגדרות Terraform.
- כדי לפרוס אפליקציה ללא שרת באמצעות Cloud Run, ראו פריסת ארכיטקטורה מאובטחת ללא שרת באמצעות Cloud Run.