شبكات AWS والهوية

مجموعات الأمان وقوائم التحكم في الشبكة

18 دقيقة الدرس 3 من 28

مجموعات الأمان وقوائم التحكم في الشبكة

توفر AWS طبقتين متكاملتين من الجدار الناري: مجموعات الأمان (Security Groups) وقوائم التحكم في الوصول للشبكة (NACLs). فهم الفارق الدقيق بينهما — التصفية ذات الحالة مقابل عديمة الحالة، وأين يُطبَّق كل منهما، وكيف يتكاملان — يمثّل أحد أكثر الفجوات شيوعًا في الحوادث الإنتاجية على AWS. أتقن هذا النموذج ولن تتساءل مرةً أخرى لماذا منفذٌ مفتوح بشكل غامض أو لماذا لا تعمل قاعدة السماح.

التصفية ذات الحالة مقابل عديمة الحالة

الفارق الجوهري الوحيد هو تتبع الاتصال.

مجموعات الأمان ذات حالة (Stateful). عندما تسمح بحركة TCP/443 الواردة، تسمح المجموعة تلقائيًا بحركة المرور العائدة (حزم الاستجابة) حتى دون وجود قاعدة صريحة للحركة الصادرة. يتولى جدول تتبع الاتصال هذا الأمر. والنتيجة العملية: تكتب أقل عدد من القواعد، وتعبّر عن النية لا عن ميكانيكيات الحزم.

قوائم NACL عديمة الحالة (Stateless). تقيّم كل حزمة بشكل مستقل دون ذاكرة للحزم السابقة. إذا سمحت بحركة TCP/443 الواردة، يجب أن تسمح صراحةً بحركة TCP الصادرة ضمن نطاق المنافذ المؤقتة (1024–65535) لكي تخرج الاستجابات من الشبكة الفرعية. نسيان هذا هو الخطأ الأول في إعداد NACL في الإنتاج.

النموذج الذهني: مجموعات الأمان تحمي الموارد (تُربط بواجهات الشبكة ENI). قوائم NACL تحمي حدود الشبكة الفرعية (تُفحص كل حزمة تعبر الحدود). تمر حركة المرور عبر الفلترين معًا — تُفحص قائمة NACL أولًا عند حدود الشبكة الفرعية، ثم مجموعة الأمان عند واجهة الشبكة.

بنية الأمان المتعددة الطبقات

يوضح الرسم البياني أدناه كيف تتكدس الطبقتان في تطبيق ثلاثي الطبقات نموذجي داخل VPC.

تعبر حركة المرور قائمة NACL عند حدود كل شبكة فرعية، ثم مجموعة الأمان عند كل واجهة شبكة — كلا الطبقتين يجب أن تسمحا بالحزمة.

قواعد مجموعات الأمان بعمق

مجموعات الأمان تعمل بنظام السماح فقط — لا يوجد رفض صريح. يُرفض كل حركة المرور الواردة افتراضيًا؛ يُسمح بكل حركة المرور الصادرة افتراضيًا. يمكن للقواعد الإشارة إلى معرفات مجموعات أمان أخرى بدلًا من نطاقات CIDR، وهو النمط المعياري في AWS للتحكم في حركة المرور الداخلية بين الخدمات.

# Terraform: سلسلة SG ثلاثية الطبقات — ALB → App → DB
resource "aws_security_group" "alb" {
  name   = "sg-alb"
  vpc_id = var.vpc_id

  ingress {
    from_port   = 443
    to_port     = 443
    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   = "sg-app"
  vpc_id = var.vpc_id

  # قبول الحركة من ALB فقط — بالإشارة إلى معرف SG لا CIDR
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_security_group" "db" {
  name   = "sg-db"
  vpc_id = var.vpc_id

  # قبول MySQL من طبقة التطبيق فقط
  ingress {
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

استخدم معرفات SG بدلًا من CIDR للحركة الداخلية. عندما تُشير إلى sg-app في قواعد الوارد لـ sg-db، يُسمح تلقائيًا لأي نسخة جديدة تنضم إلى sg-app — لن تضطر أبدًا لتتبع نطاقات الشبكة الفرعية عند التوسع. هذا النمط هو المعيار على نطاق الإنتاج.

قواعد NACL بعمق

تعالج قوائم NACL القواعد بترتيب رقمي تصاعدي وتتوقف عند أول تطابق (مثل قوائم ACL في الموجّهات التقليدية). يوجد دائمًا رفض ضمني * DENY ALL في النهاية. الأرقام تصل إلى 32766؛ العرف هو مضاعفات 100 لإتاحة إدراج قواعد لاحقًا. كل قائمة NACL مرتبطة بشبكة فرعية واحدة أو أكثر.

# Terraform: NACL للشبكة الفرعية الخاصة
resource "aws_network_acl" "private" {
  vpc_id     = var.vpc_id
  subnet_ids = [var.private_subnet_id]

  # السماح بحركة HTTP الواردة من ALB (CIDR الشبكة العامة)
  ingress {
    rule_no    = 100
    protocol   = "tcp"
    action     = "allow"
    cidr_block = "10.0.1.0/24"
    from_port  = 8080
    to_port    = 8080
  }

  # السماح بحركة HTTPS الواردة من الشبكة العامة
  ingress {
    rule_no    = 110
    protocol   = "tcp"
    action     = "allow"
    cidr_block = "10.0.1.0/24"
    from_port  = 443
    to_port    = 443
  }

  # السماح بحركة الاستجابة: نطاق المنافذ المؤقتة
  egress {
    rule_no    = 100
    protocol   = "tcp"
    action     = "allow"
    cidr_block = "10.0.1.0/24"
    from_port  = 1024
    to_port    = 65535
  }

  # السماح بـ HTTPS الصادر (لـ SSM, ECR, S3)
  egress {
    rule_no    = 110
    protocol   = "tcp"
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 443
    to_port    = 443
  }
}

المنافذ المؤقتة هي القاتل الصامت. إذا أضفت NACL صارمة إلى شبكة فرعية موجودة ونسيت نطاق المنافذ المؤقتة الصادرة (TCP 1024–65535) للاستجابات، ستبدو الاتصالات القائمة وكأنها تنقطع بدلًا من إغلاق نظيف. يبدو هذا كخدمة متقطعة لا كإعداد خاطئ للجدار الناري، ويضيع ساعات في الإنتاج. أضف دائمًا قواعد خروج 1024–65535 باتجاه أي CIDR يبادر بالاتصالات إلى شبكتك الفرعية.

متى تستخدم كل طبقة

في حساب AWS مُصمَّم جيدًا، كلا الطبقتين تعملان في آنٍ واحد لكنهما تخدمان أغراضًا مختلفة:

مجموعات الأمان — التحكم الأساسي الدقيق. استخدم مراجع معرفات SG لكل حركة المرور الداخلية. طبّق أقل صلاحية للخروج (قيّد الحركة الصادرة بالمنافذ والوجهة). راجع بقاعدة AWS Config: restricted-ssh وvpc-sg-open-only-to-authorized-ports.
قوائم NACL — حاجز احتياطي خشن على مستوى الشبكة الفرعية. استخدمها لفرض سياسات تنظيمية صارمة: حجب CIDR بأكمله تعرّض للاختراق، أو ضمان أن الشبكة الفرعية لقاعدة البيانات لا تتواصل أبدًا مع الإنترنت، أو رفض صريح لنطاق مشبوه حتى لو أُضيفت قاعدة SG عن طريق الخطأ. كثير من الفرق تشغّل قوائم NACL بإعداد "السماح للجميع" (الافتراضي) وتشدّدها فقط للامتثال أو الاستجابة للحوادث.

الرفض الصريح متاح فقط في قوائم NACL. لا تستطيع مجموعة الأمان رفض IP محدد صراحةً — يمكنك فقط حذف السماح. إذا احتجت لحجب IP هجوم بعينه على مستوى الشبكة دون لمس كل مجموعة أمان في الحساب، أضف قاعدة NACL DENY برقم أعلى من قواعد السماح الموجودة.

تقييم القواعد: مسار حركة المرور

لحزمة تنتقل من الإنترنت إلى نسخة RDS، ترتيب التقييم هو:

يوجّه IGW الحزمة إلى داخل VPC.
NACL-Public (وارد) — هل TCP/443 مسموح به واردًا للشبكة العامة؟ نعم → متابعة.
sg-alb (وارد) — هل TCP/443 مسموح به لهذه الواجهة؟ نعم → يستقبل ALB الحزمة.
ALB يُنهي TLS ويفتح اتصال TCP جديد لطبقة التطبيق.
NACL-Public (صادر) — هل TCP/8080 مسموح به صادرًا من الشبكة العامة؟ (عديم الحالة — يجب أن يكون صريحًا) → نعم → متابعة.
NACL-Private (وارد) — هل TCP/8080 من 10.0.1.0/24 مسموح به واردًا؟ نعم → متابعة.
sg-app (وارد) — هل TCP/8080 من sg-alb مسموح به؟ نعم → يستقبل التطبيق الطلب.

كل اتجاه عند كل حدود هو فحص مستقل. إحصاء خطوة واحدة بشكل خاطئ هو السبب في أن "فتحت المنفذ لكنه لا يزال لا يعمل" هي تذكرة الدعم الأكثر شيوعًا على AWS.

أفضل الممارسات الإنتاجية

سمِّ كل مجموعة أمان بتسمية واضحة: sg-{env}-{tier}، مثل sg-prod-app. المجموعات غير المسماة كابوس للامتثال.
لا تستخدم 0.0.0.0/0 في قواعد الوارد لمجموعات الأمان إلا لموازنات التحميل العامة (المنفذ 443/80 فقط).
فعّل سجلات تدفق VPC (الإجراء: الكل) على كل VPC إنتاجي. تسجّل سجلات التدفق قرارات NACL/SG وهي أساسية للتحقيق الجنائي. أرسلها إلى CloudWatch Logs أو S3، ثم استعلم عبر Athena.
استخدم AWS Network Firewall أو Gateway Load Balancer مع نظام كشف تسلل خارجي عندما تحتاج فحص الحزم بعمق أو حجبًا جغرافيًا يتجاوز قدرات قوائم NACL.
شغّل دوريًا الأمر التالي في كل منطقة لاكتشاف مجموعات الأمان ذات الصلاحيات المفرطة.

# تدقيق: إيجاد جميع SGs التي تسمح بـ 0.0.0.0/0 واردًا على أي منفذ
aws ec2 describe-security-groups \
  --query "SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]].{ID:GroupId,Name:GroupName,VPC:VpcId}" \
  --output table