מדריך

תכנון כתובות IP עבור פריסות בקנה מידה גדול או בענן היברידי.

→השתמשו ב-custom-mode VPCs. הקצו בלוקי CIDR לא חופפים של RFC 1918 (לדוגמה, 172.16.0.0/12) כדי למנוע התנגשויות עם on-prem (לרוב 10.0.0.0/8). השתמשו ב-100.64.0.0/10 עבור טווחי Pods משניים של GKE.

למה: מונע התנגשויות IP עם on-prem עבור קישוריות היברידית עתידית ומספק שליטה מלאה על מרחב הכתובות, החיוני לקנה מידה ולמניעת תהליכי Re-IP יקרים.

מקור↗

ספקו בידוד רשתי למספר דיירים/סביבות (פיתוח, פרודקשן) תוך ריכוז ניהול הרשת ושירותים משותפים.

→השתמשו ב-Shared VPC. פרויקט המארח (host project) מכיל את ה-VPC, תתי-הרשתות, חומות האש וה-interconnects. דיירים/סביבות הם פרויקטי שירות (service projects) המצורפים לפרויקט המארח.

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

מקור↗

תכנון כתובות IP עבור אשכולות GKE גדולים המשתמשים ברשת VPC-native.

→ב-custom-mode VPC, תכננו שלושה טווחי CIDR: טווח ראשי עבור צמתים (nodes), טווח משני עבור Pods, וטווח נוסף עבור Services. להרחבה, השתמשו ב-discontiguous multi-pod CIDR.

למה: רשת VPC-native דורשת טווחים משניים ייעודיים ולא חופפים עבור Pods ו-Services. תכנון גודל נכון מונע מיצוי IP, בעיה נפוצה ומפריעה באשכולות גדולים.

מקור↗

מכונות וירטואליות (VMs) ללא כתובות IP חיצוניות צריכות לגשת לממשקי API של Google Cloud (לדוגמה, Cloud Storage, BigQuery).

→אפשרו Private Google Access בתת-הרשת. באופן אופציונלי, הגדירו DNS לפתור את `*.googleapis.com` ל-`restricted.googleapis.com` (199.36.153.4/30) כדי לאכוף VPC-SC.

למה: מנתב תעבורה לממשקי API של Google על גבי הרשת הפנימית של Google מבלי לדרוש כתובות IP ציבוריות ב-VMs. שימוש ב-`restricted.googleapis.com` מוסיף שכבה של הגנה מפני דליפת נתונים.

מקור↗

ספקו גישה פרטית לשירות ב-VPC שלכם עבור צרכנים (שותפים, יחידות עסקיות אחרות) שלהם יש VPCs עם טווחי IP חופפים.

→פרסמו את השירות (באמצעות Internal Load Balancer) באמצעות Private Service Connect (PSC) service attachment. צרכנים יוצרים נקודת קצה של PSC ב-VPC שלהם עם IP מטווח הכתובות שלהם.

למה: PSC מפריד בין רשתות היצרן והצרכן, ומשתמש ב-NAT לטיפול בכתובות IP חופפות. הוא מספק גישה מאובטחת ברמת השירות, לא קישוריות רשת מלאה כמו VPC peering.

מקור↗

חברו מספר רב (50+) של VPCs ו/או אתרים מקומיים (on-prem) בטופולוגיית hub-and-spoke לניהול וקישוריות מרכזיים.

→השתמשו ב-Network Connectivity Center. הגדירו את ה-hub וצרפו VPCs כ-VPC spokes וחיבורים מקומיים (VPN/Interconnect) כ-hybrid spokes.

למה: NCC הוא הפתרון המנוהל של Google לטופולוגיות hub-and-spoke בקנה מידה גדול, המפשט את ניהול הניתוב ומתרחב מעבר למגבלת 25 ה-peerings של VPC peering.

פריסת אשכול GKE שבו לצמתים ולמישור הבקרה (control plane) אין כתובות IP ציבוריות לאבטחה משופרת.

→צרו אשכול GKE פרטי. זה מקצה רק כתובות IP פנימיות לצמתים ויוצר נקודת קצה פרטית למישור הבקרה. הגדירו רשתות מורשות כדי להגביל את הגישה למישור הבקרה.

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

עומסי עבודה של Serverless (Cloud Run, Functions) צריכים לגשת למשאבים (לדוגמה, Cloud SQL, Memorystore) בתוך VPC.

→צרו מחבר Serverless VPC Access ב-VPC היעד. הגדירו את שירות ה-Serverless להשתמש במחבר זה עבור תעבורת egress.

למה: המחבר פועל כפרוקסי, ומאפשר לשירותי Serverless (הפועלים בסביבה מנוהלת על ידי Google) לשלוח תעבורה ל-VPC מנוהל על ידי לקוח באמצעות כתובות IP פנימיות.

יישום (לדוגמה, HPC, מסחר פיננסי) דורש את השהייה הנמוכה ביותר ברשת בין קבוצת VMs.

→צרו מדיניות מיקום קומפקטית (compact placement policy) והחילו אותה על ה-VMs. השתמשו בסוגי מכונות עם רשת Tier_1.

למה: ריכוז מכונות וירטואליות (VMs) באותו ארון רשת ממזער קפיצות רשת ומרחק פיזי, ובכך מפחית משמעותית את השהייה בהשוואה למיקום VM סטנדרטי.

הטמיעו מודל אבטחת zero-trust עבור מיקרו-שירותים, הדורש זהות חזקה, תקשורת מוצפנת (mTLS) והרשאה מפורטת.

→פרסו Anthos Service Mesh. אפשרו mTLS אוטומטי עבור כל תקשורת בין שירותים. השתמשו במשאבי `AuthorizationPolicy` כדי להגדיר תקשורת מורשית.

למה: Service mesh מפריד את האבטחה מהרשת הבסיסית, ומספק זהות עומס עבודה, mTLS שקוף והרשאת L7, שהם עקרונות ליבה בארכיטקטורת zero-trust.

עומסי עבודה (VMs, GKE pods) ללא כתובות IP ציבוריות זקוקים ל-IP מקור יציב וצפוי עבור חיבורים יוצאים לממשקי API חיצוניים המשתמשים ברשימת היתרים (allow-listing).

→פרסו Cloud NAT. השתמשו באפשרות "manual NAT IP allocation" והקצו כתובות IP חיצוניות סטטיות שמורות לשער ה-NAT.

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

VPC peering הוקם אך VMs אינם יכולים לתקשר בין VPCs מקושרים.

→ודאו שכללי חומת האש בשני ה-VPCs מאפשרים תעבורת ingress מטווח ה-IP של ה-VPC השני. חיבור ה-peering רק קובע ניתוב; הוא אינו יוצר באופן מרומז אישורי חומת אש.

למה: טעות נפוצה היא להניח ש-peering פותח פורטים בחומת האש. כלל ה-deny-all ingress המשתמע חוסם תעבורה עד שנוצר כלל allow מפורש.

ב-Shared VPC, העניקו לצוות/פרויקט שירות הרשאה להשתמש רק בתת-רשת ספציפית, ולא ב-VPC כולו.

→בפרויקט המארח (host project), העניקו את תפקיד ה-IAM `compute.networkUser` לזהות פרויקט השירות (לדוגמה, service account, קבוצה) ברמת משאב תת-הרשת.

למה: תפקידי IAM יכולים להיות מוגבלים למשאבים ספציפיים. החלת `compute.networkUser` ברמת תת-הרשת אוכפת את עקרון הפריבילגיה המינימלית, ומאפשרת שימוש רק באותה תת-רשת.

הטמיעו מיקרו-סגמנטציה ליישום רב-שכבתי (לדוגמה, web, app, db) ב-Compute Engine.

→הקצו תגי רשת (network tags) ל-VMs בהתבסס על השכבה שלהם (לדוגמה, `web-server`). צרו כללי חומת אש המשתמשים בתגים אלו כמזהי מקור ויעד.

למה: תגים מספקים אלטרנטיבה גמישה וסקיילבילית לכללים מבוססי IP. מדיניות חומת האש אינה תלויה במספר או בכתובות ה-IP של ה-VMs בשכבה.

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

→אפשרו VPC Flow Logs עם מרווח איגור ארוך יותר (לדוגמה, 10 דקות), קצב דגימה מופחת (לדוגמה, 0.5), וסינון מטא-נתונים כדי להוציא שדות מיותרים.

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

אספקת יישום גלובלי עם שהייה נמוכה, ניתוב משתמשים ל-backend הבריא הקרוב ביותר עם מעבר כשל אוטומטי.

→השתמשו ב-Global External Application Load Balancer (או TCP/SSL Proxy LB עבור non-HTTP). הגדירו backend services/NEGs במספר אזורים. השתמשו ברשת Premium Tier.

למה: כתובת ה-anycast IP של Load Balancer מכוונת משתמשים ל-PoP (נקודת נוכחות) הקרובה ביותר של Google. התעבורה עוברת אז דרך התשתית הפרטית של Google ל-backend הבריא הקרוב ביותר לביצועים אופטימליים.

מקור↗

ניתוב תעבורה פנימית על בסיס נתיב URL או שם מארח, עם סיום SSL, נגיש רק בתוך ה-VPC או מ-on-prem.

→השתמשו ב-Regional Internal Application Load Balancer. הגדירו מפת URL כדי לנתב תעבורה על בסיס כללי host/path. דורש תת-רשת proxy-only.

למה: זהו Load Balancer פנימי L7 מנוהל של Google. הוא מספק תכונות ניתוב מתקדמות שאינן זמינות עם ה-L4 Internal Passthrough Network LB.

השתמשו ב-Cloud CDN כדי לשמור (cache) ולהגיש תוכן פרטי או ספציפי למשתמש מבלי להפוך אותו לציבורי.

→אפשרו Cloud CDN ב-backend פרטי (לדוגמה, GCS bucket). צרו Cloud CDN Signed URLs או Signed Cookies ביישום שלכם כדי להעניק למשתמשים גישה זמנית ומאומתת.

למה: Signed URLs/Cookies מספקים אסימון מאובטח ש-Cloud CDN מאמת לפני הגשת אובייקט שמור (cached object), תוך ניצול caching ב-edge ושמירה על בקרת גישה קפדנית.

אפשרו פתרון DNS דו-כיווני בין רשת on-prem ל-GCP VPC.

→1) On-prem פותר GCP: צרו מדיניות Cloud DNS inbound server. הגדירו את DNS ב-on-prem להעביר לכתובות ה-IP של ה-inbound forwarder. 2) GCP פותר on-prem: צרו Cloud DNS forwarding zone המצביע לשרתי ה-DNS ב-on-prem.

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

יחס פגיעות ה-cache של Cloud CDN נמוך עקב וריאציות URL מיותרות (לדוגמה, פרמטרי מעקב).

→הגדירו מדיניות מפתח cache מותאמת אישית עבור שירות ה-backend. הוציאו פרמטרי שאילתה, cookies וכותרות לא חיוניים ממפתח ה-cache.

למה: כברירת מחדל, ה-URL המלא הוא מפתח ה-cache. נירמול המפתח על ידי הוצאת פרמטרים לא רלוונטיים מונע פיצול cache ומשפר דרמטית את יחס הפגיעות.

פתרון שם DNS ל-IP פנימי עבור לקוחות פנימיים ו-IP ציבורי עבור לקוחות חיצוניים.

→צרו Cloud DNS private zone עבור הדומיין (גלוי ל-VPC שלכם) עם רשומת ה-IP הפנימי. צרו Cloud DNS public zone תואם עם רשומת ה-IP הציבורי.

למה: Cloud DNS מגיש באופן אוטומטי את התגובה מה-private zone ללקוחות בתוך ה-VPC המורשה, ואת התגובה מה-public zone לכל השאר.

יישום פנימי באזור אחד צריך להיות נגיש על ידי לקוחות (VMs, on-prem) באזורים אחרים.

→אפשרו את האפשרות "Global Access" ב-Internal TCP/UDP Load Balancer או ב-Internal Application Load Balancer's forwarding rule.

למה: כברירת מחדל, LBs פנימיים הם אזוריים. Global Access הופך אותם לנגישים מכל אזור בתוך רשת ה-VPC, ומפשט ארכיטקטורות שירות פנימיות רב-אזוריות.

הקמת קישוריות זמינה במיוחד (99.99% SLA), ברוחב פס גבוה (10G+) בין on-prem ל-GCP.

→ספקו מינימום ארבעה חיבורי Dedicated Interconnect, שניים במטרו אחד ושניים באחר, כאשר כל זוג מטרו נמצא בתחומי זמינות (edge availability domains) שונים. הגדירו BGP.

למה: יתירות על פני אזורים מטרופוליטניים נפרדים ותחומי כשל (edge availability domains) נדרשת עבור SLA של 99.99%.

מקור↗

זקוקים לחיבור היברידי מוצפן, אמין (99.9% או 99.99% SLA), וניתן לפריסה מהירה עם רוחב פס בינוני (< 6 Gbps).

→השתמשו ב-HA VPN עם BGP לניתוב דינמי. עבור 99.99% SLA, השתמשו בשני שערי HA VPN. עבור 99.9% SLA, השתמשו בשער יחיד עם שתי מנהרות.

למה: HA VPN מהיר יותר להגדרה מ-Interconnect, מספק SLA חזק, ומציע רוחב פס מספיק עבור מקרי שימוש רבים, מה שהופך אותו לבחירת ברירת המחדל לחיבורים לא פיזיים.

הצפנת כל התעבורה העוברת בקישור Dedicated או Partner Interconnect לצורך ציות.

→הגדירו HA VPN מעל Interconnect. צרו מנהרות HA VPN המשתמשות ב-VLAN attachments של ה-Interconnect עבור התשתית התחבורתית שלהן.

למה: דפוס זה משלב את רוחב הפס הגבוה והשהייה הנמוכה של Interconnect עם הצפנת IPsec של HA VPN, ומספק את הטוב משני העולמות.

הקמת קישוריות ייעודית, פרטית וברוחב פס גבוה בין GCP לספק ענן גדול אחר (AWS, Azure, OCI).

→השתמשו ב-Cross-Cloud Interconnect. ספקו חיבור פיזי ייעודי בין רשת Google לרשת ספק הענן השני. הגדירו BGP עם Cloud Router.

למה: מספק נתיב ישיר, מגובה SLA ובעל שהייה נמוכה בין עננים, הימנעות מהאינטרנט הציבורי ומהביצועים המשתנים של VPNs.

רשת on-prem המחוברת באמצעות Interconnect לאזור GCP אחד צריכה לגשת למשאבים בכל אזורי GCP האחרים.

→אפשרו מצב ניתוב דינמי "Global" ב-VPC. ה-Cloud Router יפרסם אז נתיבים לכל תתי-הרשתות ב-VPC, ולא רק לאלו שבאזור המקומי שלו.

למה: ניתוב גלובלי מאפשר לנקודת חיבור היברידית יחידה לשמש כנקודת גישה לרשת הגלובלית כולה של Google, ובכך מפשט גישה רב-אזורית.

השפעה על בחירת נתיב תעבורה על פני חיבורים היברידיים מיותרים (VPN/Interconnect) באמצעות BGP.

→כדי להשפיע על תעבורת GCP-ל-on-prem, שאו on-prem לפרסם נתיבים ספציפיים יותר או להשתמש ב-AS_PATH קצר יותר לנתיב המועדף. כדי להשפיע על on-prem-ל-GCP, פרסמו מ-Cloud Router עם ערך MED נמוך יותר לנתיב המועדף.

למה: בחירת נתיב BGP עוקבת אחר אלגוריתם ברור. התאמת הקידומת הארוכה ביותר חיונית לתעבורה יוצאת, בעוד ש-MED משפיע על החלטות תעבורה נכנסת.

הגדרת מעבר כשל פעיל/סביל (active/passive failover) בין Dedicated Interconnect ראשי ל-HA VPN גיבוי.

→השתמשו ב-BGP בשניהם. ב-Cloud Router, פרסמו נתיבים מעל Interconnect עם עדיפות בסיסית נמוכה יותר (לדוגמה, 100) ומעל VPN עם עדיפות בסיסית גבוהה יותר (לדוגמה, 200).

למה: GCP מעדיף נתיבי BGP עם ערך עדיפות נמוך יותר (העדפה גבוהה יותר). התעבורה משתמשת ב-Interconnect הראשי. בעת כשל, נתיביו נסוגים, ונתיבי ה-VPN הגיבוי הופכים לפעילים.

מניעת דליפת נתונים משירותי Google Cloud רגישים (לדוגמה, BigQuery, GCS), תוך הבטחת גישה רק מרשתות מורשות.

→הטמיעו VPC Service Controls. צרו היקף שירות (service perimeter) סביב פרויקטים עם נתונים רגישים. הגדירו רמות גישה כדי להגדיר מקורות מורשים (טווחי IP, מצב מכשיר, זהות).

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

מקור↗

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

→הטמיעו Hierarchical Firewall Policies ברמת הארגון או התיקייה. מקמו כללים קריטיים כאן. השתמשו בפעולת `goto_next` כדי להאציל הערכה למדיניות ברמה נמוכה יותר.

למה: מדיניות היררכית מוערכת לפני כללים ברמת VPC ואינה ניתנת לשינוי על ידי בעלי פרויקטים, מה שמבטיח ממשל מרכזי. `goto_next` מספק גמישות.

הגנת יישום אינטרנט מפני פגיעויות OWASP Top 10 והחלת הגבלת קצב (rate limiting) לכל IP של לקוח.

→צרפו Cloud Armor security policy ל-Global External Application LB. החילו כללי WAF מוגדרים מראש (לדוגמה, `sqli-v3.3-stable`) והוסיפו כלל מבוסס קצב.

למה: Cloud Armor מספק אבטחת edge. כללי WAF מוגדרים מראש מציעים הגנה מנוהלת, בעוד שכללים מבוססי קצב ממתנים התקפות DoS ו-brute-force.

הטמיעו אבטחת רשת ברמת Pod עדינה בתוך אשכול GKE על בסיס תוויות.

→אפשרו אכיפת Network Policy באשכול GKE. צרו משאבי Kubernetes `NetworkPolicy` המגדירים כללי ingress/egress עבור Pods באמצעות בוחרי תוויות (label selectors).

למה: Kubernetes NetworkPolicy היא הדרך המקומית ליישם מיקרו-סגמנטציה ברמת ה-Pod, המציעה גרעיניות רבה יותר מכללי חומת אש של VPC הפועלים ברמת הצומת.

בדקו את כל תעבורת ה-inter-VPC או VPC-to-internet באמצעות חומת אש/NVA מרכזית של צד שלישי.

→צרו טופולוגיית hub-and-spoke. פרסו את ה-NVA(ים) ב-VPC hub. הגדירו נתיבים מותאמים אישית ב-spokes המנתבים תעבורה ל-Internal Load Balancer ב-hub כיעד הבא (next-hop).

למה: דפוס זה מכריח תעבורה לעבור דרך נקודת בדיקה מרכזית. ה-ILB מספק IP next-hop יציב וזמין במיוחד עבור ה-NVAs.

ספקו גישה מאובטחת, מבוססת זהות, zero-trust למשתמשים ליישומי אינטרנט פנימיים או VMs ללא שימוש ב-VPN.

→עבור יישומי אינטרנט, אפשרו IAP ב-backend service של External HTTPS LB. עבור SSH/RDP, השתמשו ב-IAP עבור העברת TCP. העניקו למשתמשים תפקידי IAM מתאימים של IAP.

למה: IAP מעביר את בקרת הגישה מהיקף הרשת לזהות המשתמש, מאמת ומאשר כל בקשה. זהו מרכיב ליבה במודל ה-zero-trust של BeyondCorp של Google.

הטמיעו מניעת איומים (IDS/IPS) לתעבורת inter-VPC או VPC-to-internet, כולל זיהוי תוכנות זדוניות ובדיקת TLS.

→השתמשו ב-Cloud NGFW. שייכו firewall policy ל-VPC, צרו כללים עם פרופילי אבטחה למניעת איומים, ואפשרו באופן אופציונלי בדיקת TLS.

למה: Cloud NGFW הוא שירות חומת האש המנוהל והמבוזר של Google המספק יכולות בדיקת L7 מתקדמות מ-Palo Alto Networks, המשולבות ישירות ב-VPC.

בדקו, רשמו ובקרו באופן מרכזי את כל תעבורת ה-egress לכיוון האינטרנט מ-VPC לצורך אבטחה וציות.

→פרסו Secure Web Proxy. הגדירו מדיניות אבטחה לסינון URL ובדיקת TLS. נתבו תעבורה מתתי-רשתות לפרוקסי באמצעות נתיבים מותאמים אישית.

למה: זהו הפתרון המנוהל של Google עבור egress מאובטח, המספק נראות ובקרה ברמת L7 מבלי לדרוש צי פרוקסי בניהול עצמי.

אבחנו במהירות כשל קישוריות בין שתי נקודות קצה בתוך GCP (לדוגמה, VM-ל-VM, VM-ל-Cloud SQL).

→השתמשו ב-Connectivity Tests של Network Intelligence Center. ציינו את המקור והיעד, והוא ינתח את כל הנתיב המוגדר עבור בעיות.

למה: כלי לא פולשני זה מספק ניתוח מובהק של הנתיב, ומצביע על נקודת הכשל המדויקת (חומת אש, ניתוב וכו') הרבה יותר מהר מבדיקה ידנית.

סשן BGP מעל חיבור היברידי מתאפס לסירוגין ("flapping").

→בדקו אי-התאמה בטיימרי keepalive/hold של BGP. אם הטיימרים פגים תחת עומס, הגדילו אותם (לדוגמה, 60 שניות keepalive, 180 שניות hold). כמו כן, בדקו הגדרות MTU ואפשרו BFD.

למה: טיימרים לא תואמים או אגרסיביים מדי הם גורם נפוץ לתנודות BGP, מכיוון שגודש רשת חולף עלול לעכב חבילות keepalive מעבר לזמן ה-hold.

חקירת דיווחים על עלייה בשהייה עבור תעבורה בין אזורי GCP.

→השתמשו ב-Performance Dashboard של Network Intelligence Center כדי להציג מדדי שהייה ואובדן חבילות היסטוריים ובזמן אמת בין כל זוגות האזורים של GCP.

למה: כלי זה מספק נראות ישירה לביצועי רשת הליבה של Google, ומסייע להבחין בין בעיית יישום לבעיית תשתית רשת.

VMs המשתמשים ב-Cloud NAT חווים כשלים לסירוגין בחיבורים יוצאים, ויומני NAT מראים נפילות `OUT_OF_RESOURCES`.

→זה כנראה מיצוי פורטים של NAT. הגדילו את מספר כתובות ה-NAT IP שהוקצו, הגדילו את "Minimum ports per VM instance", ו/או אפשרו Dynamic Port Allocation.

למה: שיעורי חיבור גבוהים מ-VMs רבים יכולים למצות את מאגר פורטי המקור שהוקצו לכל IP של NAT. הקצאת משאבים נוספים היא התיקון הנדרש.