VPC מותאם אישית ב-GCP: רשתות מבודדות, חומת אש ועיצוב Cloud NAT

Custom GCP VPC: רשתות מבודדות, Firewall ועיצוב Cloud NAT

בעת הגדרת GCP VPC לסביבת production, ה-VPC ברירת המחדל — עם תתי-רשתות אוטומטיות החושפות פורטים וללא בידוד — מוביל לדליפות מידע ותנועה בלתי מבוקרת. אנו מתכננים VPC מותאם אישית מאפס עם עקרונות deny-by-default, פילוח רשת וגישה מנוהלת דרך IAP. התוצאה היא תשתית חזקה שבה עלויות התנועה יורדות ב-30% בהשוואה לשימוש בכתובות IP חיצוניות בודדות, וזמן חקירת תקלות מצטמצם פי 3 בזכות VPC Flow Logs. בהתבסס על סטטיסטיקות הפרויקטים שלנו, מעבר ל-VPC מותאם אישית מפחית את שטח התקיפה ב-70% וחוסך עד 35% מהוצאות הרשת החודשיות.

מדוע VPC ברירת מחדל אינו מתאים ל-Production?

VPC ברירת המחדל יוצר אוטומטית תתי-רשתות בכל האזורים עם טווח 10.128.0.0/9. כללי ברירת המחדל של ה-Firewall מאפשרים ICMP, SSH (22), RDP (3389) ותנועה פנימית. אף שנוח לבדיקות, ב-production זה פותח פערים: תוקף יכול לסרוק פורטים פתוחים, ומכונות ללא IP חיצוני יכולות לגשת לאינטרנט דרך Cloud NAT ללא בקרה מפורשת. אנו מוחקים את ה-VPC ברירת המחדל ולעולם לא משתמשים בו. השוואה: VPC ברירת מחדל מאפשר פי 10 יותר התקפות מאשר VPC מותאם אישית עם deny-by-default.

כיצד אנו מתכננים VPC מותאם אישית

השלב הראשון הוא תכנון CIDR. אנו מקצים בלוקים נפרדים ליישומים, מסדי נתונים, ניהול ו-Kubernetes (טווחים משניים עבור pods ו-services). Private IP Google Access מופעל ברמת תת-הרשת — גישה ל-Google APIs ללא IP חיצוני. VPC Flow Logs מופעלים עם דגימה של 0.5 כדי להימנע מתשלום יתר על רישום כל התנועה. זה מפחית את זמן חקירת התקלות פי 3. כל סביבה (dev, stage, prod) מקבלת VPC משלה — בידוד מלא.

כללי Firewall: deny-by-default עם חריגים ספציפיים

אנו מיישמים כללים בסדר עדיפויות: תחילה חסימה גלובלית של כל תנועה נכנסת (עדיפות 65534), ולאחר מכן הרשאות ספציפיות לתנועה פנימית (10.0.0.0/8), בדיקות בריאות של Load Balancer ו-IAP SSH. SSH מותר רק מטווח ה-IP של IAP (35.235.240.0/20) — זה מבטל קישוריות אינטרנט ישירה. עבור מארחים פנימיים, אנו משתמשים בתגיות לפילוח. תצורה זו מגבירה את האבטחה פי 10 בהשוואה לכללי ברירת המחדל.

resource "google_compute_firewall" "deny_all_ingress" {
  project = var.project_id
  name = "deny-all-ingress"
  network = google_compute_network.main.name
  priority = 65534
  direction = "INGRESS"
  deny {
    protocol = "all"
  }
  source_ranges = ["0.0.0.0/0"]
}

resource "google_compute_firewall" "allow_internal" {
  project = var.project_id
  name = "allow-internal"
  network = google_compute_network.main.name
  priority = 1000
  direction = "INGRESS"
  allow {
    protocol = "tcp"
  }
  allow {
    protocol = "udp"
  }
  allow {
    protocol = "icmp"
  }
  source_ranges = ["10.0.0.0/8"]
}

resource "google_compute_firewall" "allow_lb_health_check" {
  project = var.project_id
  name = "allow-lb-health-check"
  network = google_compute_network.main.name
  direction = "INGRESS"
  allow {
    protocol = "tcp"
  }
  source_ranges = ["35.191.0.0/16", "130.211.0.0/22"]
  target_tags = ["backend"]
}

resource "google_compute_firewall" "allow_iap_ssh" {
  project = var.project_id
  name = "allow-iap-ssh"
  network = google_compute_network.main.name
  direction = "INGRESS"
  allow {
    protocol = "tcp"
    ports = ["22"]
  }
  source_ranges = ["35.235.240.0/20"]
  target_tags = ["ssh-allowed"]
}

כיצד Cloud NAT משפיע על אבטחה ועלויות?

Cloud NAT מאפשר למכונות ללא IP חיצוני להוריד עדכונים ולגשת ל-APIs חיצוניים. כתובות ה-IP החיצוניות שלו מוקצות אוטומטית או ידנית. אנו משתמשים ב-AUTO_ONLY ורושמים רק שגיאות. NAT אינו הופך מכונות לנגישות מבחוץ — זוהי גישה יוצאת חד-כיוונית. תצורה זו זולה ב-40% משימוש בכתובות IP חיצוניות בודדות לכל VM. בנוסף, Cloud NAT מפחית את שטח התקיפה: ללא IP חיצוני, תוקפים לא יכולים להתחבר ישירות ל-VMs.

resource "google_compute_router" "main" {
  project = var.project_id
  name = "prod-router"
  region = "europe-west1"
  network = google_compute_network.main.id
  bgp {
    asn = 64514
  }
}

resource "google_compute_router_nat" "main" {
  project = var.project_id
  name = "prod-nat"
  router = google_compute_router.main.name
  region = "europe-west1"
  nat_ip_allocate_option = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat = "LIST_OF_SUBNETWORKS"
  subnetwork {
    name = google_compute_subnetwork.app_ew1.id
    source_ip_ranges_to_nat = ["ALL_IP_RANGES"]
  }
  log_config {
    enable = true
    filter = "ERRORS_ONLY"
  }
}

VPC Peering מחבר שני VPCים ישירות עם יכולת להחליף נתיבים. אנו משתמשים בייצוא/ייבוא של נתיבים מותאמים אישית לגמישות. אבל זכרו: peering אינו טרנזיטיבי. אם צריך לחבר יותר משני VPCים, השתמשו ב-Shared VPC או ב-Network Connectivity Center.

resource "google_compute_network_peering" "prod_to_shared" {
  name = "prod-to-shared"
  network = google_compute_network.main.self_link
  peer_network = var.shared_vpc_self_link
  export_custom_routes = true
  import_custom_routes = true
}

Private Service Connect לגישה מאובטחת ל-API

אנו משתמשים ב-Private Service Connect כדי לגשת ל-Google APIs דרך IP פנימי ב-VPC שלנו. זה מפחית השהיה ומגביר אבטחה — התנועה לא יוצאת מרשת Google.

resource "google_compute_global_address" "psc_endpoint" {
  project = var.project_id
  name = "psc-googleapis"
  purpose = "PRIVATE_SERVICE_CONNECT"
  network = google_compute_network.main.id
  address_type = "INTERNAL"
  address = "10.50.0.2"
}

השוואה בין VPC ברירת מחדל ל-VPC מותאם אישית

VPC מותאם אישית מספק פי 10 יותר שליטה על אבטחה — אתם יודעים בדיוק אילו פורטים פתוחים ולמה.

מה כלול בהתקנה ובתהליך העבודה

• ביקורת תשתית הרשת הנוכחית
• תכנון סכמת CIDR ובידוד סביבות
• יצירת VPC מותאם אישית עם תתי-רשתות (app, db, management)
• כללי Firewall: deny-by-default + חריגים (IAP, LB, פנימי)
• הגדרת Cloud NAT עם רישום
• הגדרת VPC Peering או Shared VPC
• Private Service Connect עבור Google APIs (אופציונלי)
• הפעלת VPC Flow Logs עם דגימה 0.5
• תיעוד: דיאגרמת רשת, כללים, גישה
• העברת גישה והדרכת צוות

תהליך:

1. ניתוח וביקורת — יום אחד.
2. תכנון — יום אחד.
3. יישום — 1–2 ימים.
4. בדיקות — 0.5 יום.
5. תיעוד והעברה — 0.5 יום.

סה"כ: 3–5 ימים לתשתית רשת מוכנה ל-production.

לוחות זמנים

העלות מחושבת באופן אישי. להערכה מדויקת, נא לשלוח תיאור של התשתית הנוכחית שלכם. קבלו ייעוץ על הגדרת רשת GCP.

טעויות נפוצות וכיצד להימנע מהן

• שימוש ב-VPC ברירת מחדל ב-production: אנו לעולם לא מאפשרים זאת.
• CIDR רחב מדי (למשל, /16 לכל תתי-הרשתות) — אנו מתכננים עם מקום אך לא עם הקצאת יתר.
• חוסר ב-VPC Flow Logs: ללא לוגים אי אפשר להבין מה קורה ברשת.
• SSH ישיר מהאינטרנט: אנו משתמשים ב-IAP ונמנעים מפורטים פתוחים.

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

למה להפקיד את ההגדרה בידינו

המהנדסים שלנו הם מומחי Google Cloud מוסמכים עם ניסיון של 5+ שנים. בשנה האחרונה בלבד, השלמנו מעל 50 פרויקטים באבטחת רשת ב-GCP. אנו מבטיחים שלאחר ההגדרה, ה-VPC שלכם יעמוד בשיטות המומלצות: deny-by-default, הרשאות מינימליות, רישום מלא של אירועים קריטיים. תיעוד Google Cloud ממליץ בדיוק על גישה זו עבור רשתות production.

רוצים להקים תשתית רשת מאובטחת ב-GCP? צרו קשר לייעוץ — נעריך את הפרויקט שלכם ונציע פתרון אופטימלי. קבלו תכנית הגדרה מפורטת ולוחות זמנים קבועים היום.