הגדרת חומת אש בענן: קבוצות אבטחה ו-NACLs

אנו נתקלים באופן קבוע בפרויקטים שבהם הגדרות שגויות של Security Groups או NACLs מובילות לדליפות מידע או לחוסר זמינות של שירותים. בעיה נפוצה היא השארת SSH (פורט 22) פתוח לכל כתובות ה-IP לאחר בדיקות. או שכחת פורטים אפמריים ב-NACLs שחוסמים תעבורה חוזרת. בואו נראה כיצד לארגן כראוי אבטחת רשת בענן. במהלך השנים האחרונות, ביצענו ביקורת על יותר מ-50 תשתיות ענן: ב-70% מהמקרים מצאנו שגיאות קריטיות בכללי חומת אש. נספר לכם כיצד להימנע מטעויות אלה.

מדוע Security Groups אינם מחליפים NACLs

Security Groups ו-Network ACLs הם שכבות הגנה שונות ב-AWS שלעתים קרובות מבולבלות. Security Group פועל ברמת ה-ENI (ממשק רשת), הוא stateful — תעבורה חוזרת מותרת אוטומטית. NACL פועל ברמת ה-subnet, הוא stateless — יש להגדיר כללים במפורש לשני הכיוונים. רוב הבעיות של "למה זה לא נגיש" ב-AWS נובעות מהגדרות NACL שגויות. הבנת ההבדל היא קריטית: לפי הסטטיסטיקות, 80% מהתקריות קשורות להגדרות NACL שגויות.

ההבדלים המרכזיים מסוכמים בטבלה:

לפי תיעוד AWS, Security Group הוא המחסום הראשון, NACL הוא השני. עם זאת, בפועל רבים מסתפקים רק ב-Security Groups.

כיצד להפוך את ניהול הכללים לאוטומטי עם Terraform?

שימוש ב-Infrastructure as Code (Terraform) מאיץ שינויים פי 3 בהשוואה להגדרה ידנית דרך הקונסולה. קוד Terraform מאפשר ניהול גרסאות של כללים וביצוע ביקורות קוד.

דוגמה למבנה Security Group נכון:

resource "aws_security_group" "web" {
  name = "web-tier"
  description = "HTTP/HTTPS from internet"
  vpc_id = var.vpc_id

  ingress {
    from_port = 443
    to_port = 443
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port = 80
    to_port = 80
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port = 0
    to_port = 0
    protocol = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_security_group" "app" {
  name = "app-tier"
  description = "Traffic from web tier only"
  vpc_id = var.vpc_id

  ingress {
    from_port = 8080
    to_port = 8080
    protocol = "tcp"
    security_groups = [aws_security_group.web.id] # ссылка на SG, не CIDR
  }
}

השימוש ב-resource "aws_security_group" "web" { name = "web-tier" description = "HTTP/HTTPS from internet" vpc_id = var.vpc_id ingress { from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } ingress { from_port = 80 to_port = 80 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } } resource "aws_security_group" "app" { name = "app-tier" description = "Traffic from web tier only" vpc_id = var.vpc_id ingress { from_port = 8080 to_port = 8080 protocol = "tcp" security_groups = [aws_security_group.web.id] # ссылка на SG, не CIDR } } במקום CIDR הוא תבנית מפתח. בעת קנה מידה של שכבת ה-web, מופעים חדשים מקבלים גישה אוטומטית לשכבת ה-app ללא עדכוני כללים ידניים.

NACL: מתי אי אפשר בלעדיהם

NACLs נדרשים בשני מקרים: deny מפורש עבור כתובות IP ספציפיות (Security Group לא יכול לדחות — רק לאפשר), ומחסום נוסף ברמת ה-subnet.

דוגמת קוד Terraform עבור NACL:

resource "aws_network_acl" "private" {
  vpc_id = var.vpc_id
  subnet_ids = var.private_subnet_ids

  # Блокируем подозрительный IP явно
  ingress {
    rule_no = 90
    protocol = "-1"
    action = "deny"
    cidr_block = "198.51.100.0/24"
    from_port = 0
    to_port = 0
  }

  # Разрешаем из VPC
  ingress {
    rule_no = 100
    protocol = "tcp"
    action = "allow"
    cidr_block = var.vpc_cidr
    from_port = 0
    to_port = 65535
  }

  # Ephemeral ports для stateless NACL (обязательно!)
  egress {
    rule_no = 100
    protocol = "tcp"
    action = "allow"
    cidr_block = "0.0.0.0/0"
    from_port = 1024
    to_port = 65535
  }
}

השוואת ספקי ענן

ב-GCP אין NACL — הכל נעשה דרך Firewall Rules ברמת ה-VPC. תכונה חשובה: כללים מוחלים לפי תגיות מופע או חשבונות שירות, לא לפי subnet:

resource "google_compute_firewall" "allow_internal_app" {
  name = "allow-app-from-web"
  network = var.network_name
  allow {
    protocol = "tcp"
    ports = ["8080"]
  }
  source_tags = ["web-tier"]
  target_tags = ["app-tier"]
}

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

ב-Azure, NSG יכול להיות מחובר ל-subnet או ישירות ל-NIC. שימוש בתגיות שירות (security_groups = [sg-id], resource "aws_network_acl" "private" { vpc_id = var.vpc_id subnet_ids = var.private_subnet_ids # Блокируем подозрительный IP явно ingress { rule_no = 90 protocol = "-1" action = "deny" cidr_block = "198.51.100.0/24" from_port = 0 to_port = 0 } # Разрешаем из VPC ingress { rule_no = 100 protocol = "tcp" action = "allow" cidr_block = var.vpc_cidr from_port = 0 to_port = 65535 } # Ephemeral ports для stateless NACL (обязательно!) egress { rule_no = 100 protocol = "tcp" action = "allow" cidr_block = "0.0.0.0/0" from_port = 1024 to_port = 65535 } } ) מפשט את הכללים:

resource "azurerm_network_security_rule" "allow_lb" {
  name                        = "allow-azure-lb"
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "443"
  source_address_prefix       = "AzureLoadBalancer"
  destination_address_prefix  = "*"
  resource_group_name         = var.rg_name
  network_security_group_name = azurerm_network_security_group.app.name
}

טעויות הגדרה אופייניות

• פורט פתוח 0–65535 עבור resource "google_compute_firewall" "allow_internal_app" { name = "allow-app-from-web" network = var.network_name allow { protocol = "tcp" ports = ["8080"] } source_tags = ["web-tier"] target_tags = ["app-tier"] } resource "google_compute_firewall" "deny_all_ingress" { name = "deny-all-ingress" network = var.network_name direction = "INGRESS" priority = 65534 deny { protocol = "all" } source_ranges = ["0.0.0.0/0"] } ב-Security Group יוצא — נתקלים בכך כמעט בכל מקום. תיאורטית מאפשר כל חיבור יוצא מהמופע, כולל הוצאת מידע. בפועל, תעבורה יוצאת מוגבלת רק במקומות שבהם זה מוצדק במורכבות הניהול.
• כללים כפולים ב-NACL עם AzureLoadBalancer שונים — NACL מעבד כללים לפי מספר, ההתאמה הראשונה חלה. כלל 90 עם deny גובר על כלל 100 עם allow עבור אותו CIDR.
• שימוש ב-CIDR במקום הפניות ל-Security Group — דורש עדכונים ידניים בעת קנה מידה.

מה כלול בעבודה

• ביקורת כללים קיימים — זיהוי כללים שאינם בשימוש, מיותרים ומסוכנים. מתן דוח מפורט עם המלצות.
• עיצוב תצורה חדשה — שימוש ב-Terraform לתיאור דקלרטיבי של כל ה-Security Groups וה-NACLs. כל השינויים עוברים ביקורת קוד.
• תיעוד — דיאגרמת רשת עם כל הכללים, תיאור חריגים והצדקות.
• הדרכת צוות — כיצד לתחזק כללים דרך IaC, מה לעשות בעת הוספת מיקרוסרוויס חדש.

תהליך העבודה

1. אנליטיקה — איסוף טופולוגיית הרשת הנוכחית, כללי חומת אש, דרישות תאימות. זיהוי נקודות תורפה קריטיות.
2. עיצוב — פיתוח ארכיטקטורת יעד באמצעות עקרון ההרשאות המינימליות. קביעה אילו כללים ניתן לאחד, היכן נדרשים NACLs.
3. יישום — כתיבת קוד Terraform, יצירת pull request, ביצוע ביקורת קוד. פריסה ראשונה בסביבת staging.
4. בדיקות — אימות קישוריות בין שירותים, הבטחה שתעבורה לגיטימית אינה חסומה. שימוש בתרחישי בדיקה.
5. פריסה לייצור — יישום שינויים לפי לוח זמנים, ניטור שגיאות דרך CloudWatch / Stackdriver.

לוחות זמנים

ביקורת והגדרת Security Groups עבור יישום תלת-שכבתי טיפוסי (web/app/db) בענן אחד — 1-2 ימים. Multi-cloud או ארכיטקטורת מיקרוסרוויסים מורכבת עם עשרות Security Groups — 3-5 ימים. השקעה בביקורת והגדרה בדרך כלל מחזירה את עצמה במניעת תקריות: העלות הממוצעת של דליפת מידע היא 4.35 מיליון דולר לפי IBM. המחיר מחושב באופן אישי לאחר ניתוח הארכיטקטורה הנוכחית.

במהלך השנים, השלמנו יותר מ-50 פרויקטי אבטחת ענן. מהנדסים מוסמכים של AWS ו-Azure מבטיחים שהרשת שלכם מאובטחת לפי השיטות המומלצות. ננתח את כללי האבטחה הנוכחיים שלכם. צרו קשר לביקורת על תשתית הענן שלכם. בקשו ייעוץ עם מהנדס DevOps עכשיו.