مشروع التخرج: منصة إنتاج بمستوى الشركات الكبرى

الأساس: الحسابات والشبكة وإدارة الهوية والوصول

18 دقيقة الدرس 2 من 30

الأساس: الحسابات والشبكة وإدارة الهوية والوصول

قبل أن يعمل أي حاوية أو ينطلق أي خط أنابيب، ثلاثة أشياء يجب أن تكون صحيحة: هيكل الحسابات، وطوبولوجيا الشبكة، وخط أساس الهوية. في أمازون وجوجل ومايكروسوفت، تقضي فرق المنصات أسابيع في هذه القرارات قبل أن يصلها أي حِمل عمل. أخطئ فيها وستقضي السنتين التاليتين في معالجة تبعاتها. أصبها وستنزلق كل طبقة لاحقة — Kubernetes وCI/CD والمراقبة والأمان — في مكانها بسلاسة.

منطقة الهبوط: استراتيجية تعدد الحسابات

منطقة الهبوط (Landing Zone) هي بيئة متعددة الحسابات معدّة مسبقًا ومزوّدة بحواجز حماية قبل أن يلمسها أي فريق. AWS Control Tower وGCP Landing Zone Fabric وAzure Landing Zones تُقنّن كل منها سنوات من الممارسة المؤسسية في خط أساس قابل للتكرار.

المبدأ الجوهري هو عزل نطاق الضرر عبر فصل الحسابات. تسريب بيانات اعتماد أو خطأ إعداد في حاوية تخزين أو تضخّم تكاليف في حساب واحد لا يمكنه الانتشار إلى حساب آخر. هيكل OU منطقي لمنظمة متوسطة إلى كبيرة يبدو هكذا:

الجذر / حساب الإدارة — جذر AWS Organizations وفوترة موحّدة وصفر أحمال عمل. سياسات التحكم في الخدمات (SCPs) تُرفق هنا كسقف صلاحيات لكل حساب فرعي.
وحدة الأمان (Security OU) — حساب أرشيف السجلات (يستقبل CloudTrail وVPC Flow Logs ولقطات Config من كل حساب مركزيًا) وحساب أدوات الأمان (GuardDuty وSecurity Hub وإدخال SIEM).
وحدة البنية التحتية (Infrastructure OU) — حساب الخدمات المشتركة (Transit Gateway وRoute 53 Resolver وECR وإضافات EKS المشتركة) وحساب الشبكة اختياريًا للوصول المركزي.
وحدة أحمال العمل (Workloads OU) — حساب واحد لكل فريق لكل بيئة (إنتاج، اختبار، تطوير). الفريق الذي يملك ثلاث خدمات صغيرة يشترك في حساب واحد لكل بيئة؛ حسابات منفصلة لكل خدمة تتجاوز حدود الحسابات وتُجزّئ رؤية التكاليف.
وحدة صندوق الرمل (Sandbox OU) — حسابات تطوير فردية بسياسة إنفاق SCP صارمة ($200/شهر)، تُمسح تلقائيًا أسبوعيًا عبر aws-nuke.

SCPs هي سقوف صلاحيات، لا منح. سياسة رفض SCP تتفوق على أي Allow في IAM، حتى Admin. كحدٍّ أدنى، يجب أن تحظر كل وحدة إنتاج: الخروج من AWS Organizations، وتعطيل CloudTrail، وإنشاء مستخدمي IAM طويلي الأمد، وتشغيل موارد خارج المناطق المعتمدة. قنّنها في Terraform وأودعها في مستودع منطقة الهبوط من اليوم صفر — إضافة حواجز الحماية بأثر رجعي على بيئة نشطة أمر مؤلم.

AWS Control Tower يؤتمت إنشاء الحسابات ويطبّق ضوابط إلزامية. Account Factory for Terraform (AFT) يلفّ هذا في خط أنابيب GitOps بحيث يصبح كل حساب جديد طلب سحب (PR):

# aft-account-requests/accounts/payments-prod.tf
# كل حساب جديد = PR واحد هنا؛ AFT CodePipeline يطبّق عند الدمج

module "payments_prod" {
  source = "./modules/aft-account-request"

  control_tower_parameters = {
    AccountEmail              = "aws-payments-prod@company.com"
    AccountName               = "payments-prod"
    ManagedOrganizationalUnit = "Workloads/Platform/Production"
    SSOUserEmail              = "aws-payments-prod@company.com"
    SSOUserFirstName          = "Payments"
    SSOUserLastName           = "Production"
  }

  account_tags = {
    Team        = "payments"
    Environment = "production"
    CostCenter  = "CC-1042"
    DataClass   = "PCI"
  }

  # تخصيصات ما بعد الإنشاء: تثبيت خطوط الأساس وSCPs وقواعد Config
  account_customizations_name = "pci-production-baseline"
}

تصميم VPC: أساس الشبكة

كل حساب يشغّل أحمال عمل يحصل على VPC مخصص على الأقل. يُحذف VPC الافتراضي عند إنشاء الحساب — يمكن لـ SCP تطبيق ذلك. VPC جاهز للإنتاج في منصة الختام يستخدم نموذج الشبكة الفرعية ثلاثية الطبقات عبر ثلاث مناطق توفر (وليس اثنتين أبدًا — البنية ثنائية المنطقة لديها احتمال 50% للتدهور عند أي حادثة في منطقة واحدة).

هيكل الطبقات وخطة CIDR لـ VPC المنصة في us-east-1 (10.0.0.0/16):

الشبكات الفرعية العامة (/24 لكل منطقة توفر) — موازنات تحميل ALB وبوابات NAT. لا شيء آخر. لا خوادم تطبيقات أبدًا.
الشبكات الفرعية الخاصة / التطبيق (/22 لكل منطقة توفر) — عُقد EKS وخوادم تطبيقات EC2 ودوال Lambda داخل VPC. الإنترنت الصادر عبر NAT Gateway فقط.
شبكات البيانات الفرعية (/24 لكل منطقة توفر) — RDS وElastiCache وMSK. لا مسار إلى الإنترنت على الإطلاق، حتى NAT.

حجّم شبكات طبقة التطبيق للتوسع المستقبلي لعُقد EKS، لا لعددها الحالي. عُقدة EKS تطلب عنوان IP أساسيًا واحدًا وعنوان IP لكل حاوية (مع VPC CNI، كل حاوية تحصل على عنوان IP حقيقي من VPC). عُقدة c5.4xlarge لها حد ENI يبلغ 58 عنوانًا ثانويًا. مجموعة تتوسع إلى 50 عُقدة يمكنها استهلاك 2,900 عنوان IP في منطقة توفر واحدة. الـ /24 (251 عنوانًا صالحًا) سينضب فورًا. استخدم /22 (1,019 عنوانًا صالحًا) أو أكبر لطبقة التطبيق. هذا الخطأ الأكثر شيوعًا في نشر EKS.

الاتصال بين الحسابات يستخدم AWS Transit Gateway (TGW)، لا VPC Peering. الـ Peering شبكة تشابكية — تعقيدها O(n²) مع نمو الحسابات. TGW مركز توزيع؛ جداول التوجيه على TGW تتحكم في أي شبكات VPC تتواصل. VPCs الإنتاج يجب ألا تمتلك مسار TGW إلى VPCs التطوير أبدًا.

# terraform/network/vpc.tf — VPC ثلاثي الطبقات بتغطية 3 مناطق توفر

locals {
  azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
  public_cidrs    = ["10.0.0.0/24",  "10.0.1.0/24",  "10.0.2.0/24"]
  app_cidrs       = ["10.0.16.0/22", "10.0.20.0/22", "10.0.24.0/22"]
  data_cidrs      = ["10.0.48.0/24", "10.0.49.0/24", "10.0.50.0/24"]
}

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

resource "aws_subnet" "public" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.public_cidrs[count.index]
  availability_zone = local.azs[count.index]
  tags = { Name = "public-${local.azs[count.index]}", Tier = "public" }
}

resource "aws_subnet" "app" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.app_cidrs[count.index]
  availability_zone = local.azs[count.index]
  tags = { Name = "app-${local.azs[count.index]}", Tier = "application" }
}

resource "aws_subnet" "data" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.data_cidrs[count.index]
  availability_zone = local.azs[count.index]
  tags = { Name = "data-${local.azs[count.index]}", Tier = "data" }
}

# NAT Gateway — واحد لكل منطقة توفر للتوفر العالي (مكلف لكن إلزامي)
resource "aws_eip" "nat" { count = 3; domain = "vpc" }
resource "aws_nat_gateway" "main" {
  count         = 3
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id
  tags          = { Name = "ngw-${local.azs[count.index]}" }
}

# VPC Flow Logs إلى S3 — حاوية حساب أرشيف السجلات المركزي
resource "aws_flow_log" "main" {
  vpc_id          = aws_vpc.main.id
  traffic_type    = "ALL"
  iam_role_arn    = aws_iam_role.flow_logs.arn
  log_destination = "arn:aws:s3:::company-log-archive-vpc-flowlogs"
  log_destination_type = "s3"
  tags = { Name = "platform-prod-flowlogs" }
}

VPC ثلاثي الطبقات (عام / تطبيق / بيانات) عبر ثلاث مناطق توفر، مع Transit Gateway يوفّر الاتصال بين الحسابات.

خط أساس الهوية في IAM

في اليوم صفر، لخط أساس الهوية هدفان: إزالة بيانات الاعتماد طويلة الأمد وتطبيق مبدأ أقل الامتيازات في افتراض الأدوار. كل هوية بشرية يجب أن تُصادق عبر موفّر الهوية (Okta أو Entra ID أو Google Workspace) من خلال AWS IAM Identity Center (SSO)، لا عبر مستخدمي IAM. لا مهندس يجب أن يملك مفتاح وصول في ~/.aws/credentials في الإنتاج.

الأنماط الرئيسية على مستوى كبار الشركات التقنية:

مجموعات الصلاحيات في IAM Identity Center — تُعيَّن إلى أدوار IAM في كل حساب. حدّد أربعة مستويات: ReadOnly وDeveloper وPowerUser وAdministrator. أرفق SCPs حتى مجموعة Administrator لا تستطيع تعطيل CloudTrail أو تعديل خط الأساس.
ثقة OIDC لـ CI/CD — GitHub Actions وGitLab CI وArgoCD تفترض أدوار IAM عبر اتحاد OIDC. لا أسرار ثابتة في CI أبدًا. أداة aws-actions/configure-aws-credentials تتولى تبادل الرمز المميز تلقائيًا.
هوية أحمال عمل EC2 وEKS — ملفات تعريف نسخ EC2 وIRSA لـ EKS (أدوار IAM لحسابات الخدمة) تمنح أحمال العمل بيانات اعتماد محدودة النطاق بدون إدارة مفاتيح. كل حساب خدمة يحصل على دوره الخاص بحاويات S3 وجداول DynamoDB التي يحتاجها فقط.
SCPs كضمانات — احظر iam:CreateUser وiam:CreateAccessKey (إلا لحساب أتمتة الطوارئ) وحماية الوصول العام لـ S3.

# سياسة ثقة OIDC لـ GitHub Actions — لا أسرار ثابتة في CI
# انشر هذا مرة واحدة لكل حساب؛ كل خطوط الأنابيب تشير إلى الدور بـ ARN

data "aws_iam_openid_connect_provider" "github" {
  url = "https://token.actions.githubusercontent.com"
}

resource "aws_iam_role" "github_deploy" {
  name = "github-actions-deploy"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Federated = data.aws_iam_openid_connect_provider.github.arn }
      Action    = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringLike = {
          "token.actions.githubusercontent.com:sub" =
            "repo:company-org/platform:*"
        }
        StringEquals = {
          "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
        }
      }
    }]
  })
}

# النطاق: الدفع إلى ECR والنشر على EKS فقط — لا شيء آخر
resource "aws_iam_role_policy_attachment" "github_ecr" {
  role       = aws_iam_role.github_deploy.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser"
}

الجمع معًا: تسلسل بناء الأساس

الترتيب الصحيح للإنشاء مهم لأن الطبقات اللاحقة تعتمد على السابقة:

تفعيل AWS Organizations، تعيين SCPs الجذر (حظر المنطقة، حماية CloudTrail، حظر مستخدمي IAM).
تشغيل Control Tower مع AFT؛ إنشاء حسابات Security OU أولًا (أرشيف السجلات، أدوات الأمان).
إعداد IAM Identity Center، الربط بموفّر الهوية، تحديد مجموعات الصلاحيات — قبل أن يسجّل أي إنسان دخوله إلى حساب أحمال العمل.
إنشاء حسابات أحمال العمل عبر AFT؛ كل تخصيص أساس يشغّل Terraform ينشئ VPC والشبكات الفرعية ومرفق TGW وFlow Logs وقواعد Config ودور IAM للـ OIDC.
إنشاء سجل CIDR — جدول DynamoDB بسيط أو Terraform State في حاوية S3 مركزية يسجّل كل تخصيص CIDR لـ VPC. بدونه، سيختار فريقان نطاقات متداخلة ويكتشفان ذلك فقط عند محاولة الاتصال.

وحدة Terraform الأساسية لحساب جديد يجب أن تكون خاملة التطبيق وأقل من 300 سطر. إن كانت أطول من ذلك، فأنت تُقنّن افتراضات كثيرة جدًا. أبقِ الأساس محدودًا (VPC وأدوار OIDC وقواعد Config وتسجيل Security Hub) وأدفع بنية الأساس الخاصة بكل حِمل عمل إلى مستودعات الفرق. فريق المنصة يملك منطقة الهبوط؛ الفرق تملك كل شيء فوقها.

مع عزل الحسابات وتقسيم الشبكات إلى طبقات وتوجيه الهوية عبر موفّر الهوية بدون بيانات اعتماد طويلة الأمد في أي مكان، لقد أزلت أكثر الأسباب الجذرية شيوعًا لحوادث أمان السحابة. الدرس الثالث يبني منصة Kubernetes فوق هذا الأساس.