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

مشروع: تصميم VPC للإنتاج

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

مشروع: تصميم VPC للإنتاج

كل حمل عمل إنتاجي في شركة جادة يعيش داخل VPC مُصمَّم بعناية فائقة. تأخذك هذه الدرس الختامي خطوة بخطوة عبر تصميم وبناء والتحقق من صحة VPC متعدد مناطق التوافر يمكنك نشره فعلياً في مؤسسة على مستوى FAANG — مع تجزئة شبكية متعددة الطبقات، وصلاحيات IAM بمبدأ الحد الأدنى من الامتيازات، وكتب التشغيل التي تحافظ على استمراريته.

نظرة عامة على المعمارية

التصميم المستهدف هو VPC ثلاثي الطبقات ومزدوج مناطق التوافر: طبقة عامة لموازنات التحميل، وطبقة تطبيقات خاصة للحوسبة، وطبقة بيانات خاصة لقواعد البيانات والتخزين المؤقت. يتدفق الطلب إلى الداخل عبر مسار واحد قابل للتدقيق؛ ولا يصل أي شيء إلى طبقة البيانات دون المرور بطبقة التطبيقات أولاً.

معمارية VPC ثلاثية الطبقات ومزدوجة مناطق التوافر: الطبقة العامة لموازن التحميل، طبقة التطبيقات الخاصة، طبقة البيانات المعزولة، ونقاط نهاية VPC للوصول إلى خدمات AWS دون المرور بالإنترنت.

الخطوة الأولى — تخطيط CIDR وتحديد حجم الشبكات الفرعية

اختر كتلة /16 من فضاء RFC 1918 بحيث لا تتداخل مع أي نطاق محلي أو VPC نظير ستحتاج إلى الاتصال به في أي وقت. قسّمها بحيث تتمكن من التوسع دون إعادة تعيين عناوين IP:

الطبقة العامة (/24 لكل منطقة توافر): صغيرة — تضم فقط موازنات التحميل وبوابات NAT. منطقتا توافر تعنيان /24ين.
طبقة التطبيقات الخاصة (/24 لكل منطقة توافر): مُحجَّمة لمجموعات التوسع التلقائي ومهام ECS. خطط لـ 3–5 أضعاف العدد الحالي من الحاويات.
طبقة البيانات الخاصة (/24 لكل منطقة توافر): RDS متعدد مناطق التوافر يتطلب شبكتين فرعيتين. ElastiCache بوضع المجموعة يحتاج أيضاً إلى توزيع لكل منطقة.
كتل احتياطية: اترك على الأقل 10.0.100.0/22 غير مستخدمة للطبقات المستقبلية.

AWS تحتجز 5 عناوين IP في كل شبكة فرعية (الشبكة، البث، الموجّه، DNS، والمستقبل). الشبكة /27 تعطيك فقط 27 عنواناً قابلاً للاستخدام — وهو عدد غير كافٍ لـ Kubernetes. استخدم /24 أو أكبر لشبكات الحوسبة.

الخطوة الثانية — هيكل Terraform الأساسي

عبّر عن التصميم بالكامل كبرمجيات. المثال الموضّح في الدرس يُنشئ الـ VPC والشبكات الفرعية والتوجيه بطريقة قابلة للتكرار والمراجعة.

# main.tf — هيكل VPC للإنتاج (Terraform ~1.8)
terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.50" }
  }
  backend "s3" {
    bucket         = "myorg-tf-state"
    key            = "networking/prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tf-state-lock"
    encrypt        = true
  }
}

locals {
  azs          = ["us-east-1a", "us-east-1b"]
  public_cidrs = ["10.0.1.0/24",  "10.0.2.0/24"]
  private_app  = ["10.0.11.0/24", "10.0.12.0/24"]
  private_data = ["10.0.21.0/24", "10.0.22.0/24"]
}

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = { Name = "prod-vpc", Env = "prod" }
}

resource "aws_nat_gateway" "nat" {
  count         = 2
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id
  tags          = { Name = "nat-${local.azs[count.index]}" }
  depends_on    = [aws_internet_gateway.igw]
}

لا تستخدم أبداً بوابة NAT مشتركة واحدة عبر مناطق التوافر. إذا توقفت تلك المنطقة، تنقطع كل حركة الخروج من الطبقة الخاصة. استخدم بوابة NAT واحدة لكل منطقة توافر — التكلفة الإضافية الطفيفة تلغي نقطة الفشل الواحدة وتُزيل رسوم نقل البيانات بين المناطق.

الخطوة الثالثة — نقاط نهاية VPC (قطع مسار الإنترنت)

يحتاج كل من طبقتي التطبيقات والبيانات للوصول إلى S3 وECR وSSM وSecrets Manager دون المرور بالإنترنت العام. نقاط نهاية VPC توجّه هذه الحركة عبر الشبكة الداخلية لـ AWS، مما يُزيل عبء بوابة NAT للخدمات عالية الإنتاجية ويُلغي رسوم الخروج لـ S3 وDynamoDB.

# نقاط نهاية Gateway — مجانية، تعتمد على جدول التوجيه (S3 & DynamoDB فقط)
resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.us-east-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = concat(
    aws_route_table.private_app[*].id,
    aws_route_table.private_data[*].id
  )
  tags = { Name = "vpce-s3" }
}

# نقاط نهاية Interface — ENIs داخل شبكات التطبيقات الخاصة
locals {
  interface_services = ["ssm", "ssmmessages", "ec2messages",
                        "ecr.api", "ecr.dkr",
                        "secretsmanager", "logs"]
}

resource "aws_vpc_endpoint" "interface" {
  for_each            = toset(local.interface_services)
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.us-east-1.${each.key}"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private_app[*].id
  security_group_ids  = [aws_security_group.vpce.id]
  private_dns_enabled = true
  tags = { Name = "vpce-${each.key}" }
}

الخطوة الرابعة — IAM بمبدأ الحد الأدنى لـ EC2 وECS

كل مورد حوسبي يحصل على IAM Instance Profile أو Task Role — لا بيانات اعتماد مُضمَّنة أبداً في الكود. صمّم الأدوار بالصلاحيات الدنيا اللازمة لأداء المهمة، ثم ارفض أي صلاحية أوسع على مستوى SCP.

# iam.tf — دور المهمة لطبقة التطبيقات (مثال ECS)
data "aws_iam_policy_document" "app_task_policy" {
  # قراءة الأسرار — فقط أسرار هذه الخدمة
  statement {
    actions   = ["secretsmanager:GetSecretValue"]
    resources = ["arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/myapp/*"]
  }
  # كتابة السجلات — بدون wildcard على مجموعات السجل
  statement {
    actions   = ["logs:CreateLogStream", "logs:PutLogEvents"]
    resources = ["arn:aws:logs:us-east-1:123456789012:log-group:/prod/myapp:*"]
  }
  # S3 — قراءة فقط على بادئة التطبيق الخاصة
  statement {
    actions   = ["s3:GetObject", "s3:ListBucket"]
    resources = [
      "arn:aws:s3:::myorg-prod-assets",
      "arn:aws:s3:::myorg-prod-assets/myapp/*"
    ]
  }
  # رفض صريح لأي إجراء تدميري (دفاع متعدد الطبقات)
  statement {
    effect    = "Deny"
    actions   = ["s3:DeleteObject", "s3:DeleteBucket",
                 "rds:DeleteDBInstance", "rds:DeleteDBCluster"]
    resources = ["*"]
  }
}

استخدم IAM Access Analyzer بصورة مستمرة. يكشف عن الأدوار التي لم تُمارَس صلاحياتها خلال الـ 90 يوماً الماضية — استخدمه كجولة ربع سنوية لتضييق الصلاحيات وإعادة الالتزام بمبدأ الحد الأدنى.

الخطوة الخامسة — التحقق من صحة التصميم

البنية التحتية لا تكتمل حين يعود terraform apply بنجاح. تحقق من كل حد أمني:

الاتصال: أطلق نسخة مُدارة بـ SSM في كل شبكة تطبيقات خاصة. شغّل curl -I https://ecr.aws — يجب أن يُحلَّل إلى عنوان IP خاص (نقطة نهاية VPC).
عزل طبقة البيانات: من شبكة البيانات الخاصة، تحقق من أن curl https://checkip.amazonaws.com ينتهي بمهلة — لا يوجد مسار للإنترنت.
مراجعة Security Groups: الـ SG الوحيد الذي يجب أن يحمل قاعدة دخول عامة هو SG الـ ALB على المنفذ 443.
محاكاة IAM: شغّل aws iam simulate-principal-policy للتحقق من أن الدور لا يستطيع تنفيذ إجراءات تدميرية على موارد الإنتاج.

مراجعة VPC الإنتاجي في شركة ناضجة تتضمن نموذج تهديد: لكل مسار بيانات في المخطط، اسأل "ماذا يحدث إذا اختُرق هذا المكوّن؟" اختراق الشبكة العامة لا يجب أن يمنح وصولاً جانبياً لطبقة البيانات — هذا ما تفرضه Security Groups وNACLs وحدود IAM بشكل مستقل عن بعضها البعض.

أساسيات كتيب التشغيل

ضع علامات (Tags) على كل شيء بصورة متسقة — العلامات التي تضعها في Terraform تصبح أساس تخصيص التكاليف وتحديد نطاق الحوادث والتحكم في الوصول. كحد أدنى: Env، Service، Team، ManagedBy=terraform. فعّل VPC Flow Logs إلى CloudWatch Logs أو S3 منذ اليوم الأول — لا يمكنك إعادة بناء حادثة شبكة بأثر رجعي دون سجلات. فعّل CloudTrail في جميع المناطق مع حماية مجموعة S3 المخصصة له من الحذف.

هذه المعمارية هي الأساس. من هنا تضيف: Transit Gateway للتوجيه متعدد الحسابات، AWS Network Firewall لفحص الحزم العميق، PrivateLink لعرض الخدمات لـ VPCs أخرى، وGuardDuty لاكتشاف التهديدات في وقت التشغيل. نمط الثلاث طبقات يتوسع من 5 مهندسين إلى 5,000.