معمارية السحابة ومناطق الهبوط

Landing Zones و Control Tower

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

Landing Zones و Control Tower

Landing Zone هي بيئة AWS متعددة الحسابات التي تعمل فيها مؤسستك بأكملها. إنها ليست خدمة واحدة أو خانة اختيار — إنها الأساس الآمن والمُدار الذي يرتكز عليه كل عبء عمل، وكل فريق، وكل متطلب امتثال. الخطأ في البداية يعني إضافة ضوابط الأمان على مئات الحسابات تحت ضغط الإنتاج. الصواب يعني أن فريق المنصة يمكنه توفير بيئة فريق جديدة في دقائق مع أمان مضمّن افتراضيًا.

يغطي هذا الدرس الركائز الأربع لـ Landing Zone في الإنتاج: طوبولوجيا الحسابات الأساسية، وتصميم Organizational Units، وسياسات التحكم في الخدمات (SCPs) كضمانات وقائية، والتسجيل المركزي. هذه ليست مفاهيم للشركات الكبيرة فقط — إنها التوقع الأساسي في أي شركة جادة من مرحلة السلسلة B فصاعدًا.

طوبولوجيا الحسابات الأساسية

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

طوبولوجيا أساسية ناضجة تستخدم على الأقل هذه الحسابات المخصصة:

Management Account — يمتلك AWS Organization. تستخدمه فرق المنصة/السحابة فقط. يستضيف AWS Control Tower وAWS Organizations والفوترة الموحدة ولا شيء آخر. تسجيل الدخول البشري نادر ويتطلب MFA وإجراء break-glass.
Log Archive Account — وجهة "اكتب مرة واحدة" لجميع سجلات المؤسسة: CloudTrail وAWS Config وVPC Flow Logs وS3 Access Logs. الحسابات يمكنها الإرسال إليه لكن لا يمكنها الحذف منه. حتى مدراء المؤسسة لا يجب أن يملكوا صلاحية الحذف على بكت السجلات — فرض هذا بسياسة S3 Object Lock.
Audit / Security Tooling Account — يُشغّل Security Hub وGuardDuty الموحد وInspector وتكامل SIEM. يمتلك وصولًا للقراءة فقط عبر الحسابات. فريق الأمن يمتلك هذا الحساب ولا يُشارك مع المطورين.
Shared Services Account — يستضيف البنية التحتية المشتركة مركزيًا: Transit Gateway وRoute 53 Resolver والـ CA الداخلي (ACM PCA) ومسار بناء AMI المشترك ومستودعات الأرتيفاكت (ECR وCodeArtifact). جميع حسابات أعباء العمل تتصل عبره.
Workload Accounts (لكل بيئة) — dev وstaging وprod هي حسابات AWS منفصلة، وليست VPCs منفصلة في نفس الحساب. العزل على مستوى الحساب هو أقوى ضبط لنطاق الضرر تقدمه AWS.
Network Account — يمتلك Transit Gateway وفحص الخروج (Network Firewall أو جهاز طرف ثالث). يُركّز سياسة التوجيه دون إعطاء حسابات أعباء العمل التحكم في بنية الشبكة.

القرار الأمني الأكثر تأثيرًا في Landing Zone هو جعل كل بيئة حسابًا منفصلًا. سياسات IAM والسياسات المستندة إلى الموارد ومجموعات أمان VPC كلها تتوقف عند حدود الحساب. نطاق الضرر الذي يمكن أن يتسبب في اختراق منطقة بأكملها يُختزل في بيئة واحدة عند فصل الحسابات بشكل صحيح.

تصميم OUs: تنظيم الحسابات في سياسات

تُجمّع AWS Organizations الحسابات في Organizational Units (OUs). توجد OUs لسبب واحد: تطبيق SCPs بشكل متسق على مجموعة من الحسابات دون لمس كل حساب على حدة. هرمية OU نظيفة تجعل إدارة SCP قابلة للتحكم عند مئات الحسابات.

هيكل OU قياسي على المستوى الأعلى توصي به AWS وتتبناه معظم المؤسسات الكبيرة:

Root — يطبق SCPs الأساسية على الجميع بما في ذلك قيود حساب الإدارة.
Infrastructure OU — يحتوي على حسابات Log Archive وAudit وShared Services وNetwork. SCPs هنا متساهلة مع أدوات المنصة لكنها تحجب الإجراءات الشبيهة بأعباء العمل.
Workloads OU — مُقسّم إلى SDLC (dev/staging) وProduction. SCPs خاصة بالإنتاج تفرض ضوابط أكثر صرامة: لا تعطيل CloudTrail، لا S3 عامة، لا مغادرة المناطق المسموح بها.
Sandbox OU — حسابات تجريبية للمطورين. حدود تكلفة صارمة عبر SCPs وإنهاء تلقائي للموارد ولا peering مع شبكات الإنتاج.
Suspended OU — حسابات يجري إيقافها. SCP مُرفقة ترفض جميع الإجراءات، مما يجمّد الحساب فعليًا أثناء انتظار الحذف أو التدقيق.

هرمية OU في Landing Zone: الحسابات مُجمّعة حسب حدود السياسة، مع تسجيل مركزي غير قابل للتعديل مشترك عبر المؤسسة.

سياسات التحكم في الخدمات: الضمانات الوقائية

Service Control Policies (SCPs) هي سياسات JSON بصيغة IAM مُرفقة بالجذر أو OU أو حساب فردي في AWS Organizations. تحدد الحد الأقصى من الصلاحيات لكل شخص في نطاقها — بما في ذلك المستخدم الجذر للحساب. SCP لا تمنح صلاحيات؛ بل تُصفّي ما يمكن لسياسات IAM داخل الحساب السماح به.

أنماط SCP الحرجة التي يجب أن تنفّذها كل Landing Zone:

# SCP: منع مغادرة المؤسسة أو تعطيل CloudTrail
# مُرفق بـ Root OU — يطبق على كل حساب بما في ذلك الإدارة
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrg",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "DenyDisableCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyDisableGuardDuty",
      "Effect": "Deny",
      "Action": [
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "guardduty:StopMonitoringMembers"
      ],
      "Resource": "*"
    }
  ]
}

# SCP: تقييد مناطق AWS المعتمدة فقط (لـ Production OU)
# مُرفق بـ Workloads/Production OU
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "budgets:*",
        "waf:*",
        "cloudfront:*",
        "sts:*",
        "support:*",
        "trustedadvisor:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "eu-west-1"
          ]
        }
      }
    },
    {
      "Sid": "DenyPublicS3",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:DeletePublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "s3:PublicAccessBlockConfiguration/RestrictPublicBuckets": "false"
        }
      }
    }
  ]
}

تستخدم SCPs نموذج الرفض الضمني مع السماح الصريح المُعطى بواسطة SCP المُدارة FullAWSAccess التي تُرفقها AWS بكل OU جديدة. إذا أزلت FullAWSAccess وأضفت فقط SCPs القيود، يجب أن تسمح صراحةً لكل إجراء تريد السماح به. معظم الفرق تقفل فريق المنصة نفسه عن طريق الخطأ. النهج الآمن: احتفظ بـ FullAWSAccess كأساس وأضف SCPs للحجب فقط فوقه.

AWS Control Tower: أتمتة Landing Zone

AWS Control Tower هو الخدمة المُدارة التي تُوفّر وتُحكّم Landing Zone. إنه يُنشئ هيكل OU الأساسي، وينشر حسابات مُهيأة مسبقًا (Log Archive وAudit)، ويُفعّل CloudTrail trail على مستوى المؤسسة، ويوفر كتالوج من الضمانات — مزيج من SCPs (وقائية) وقواعد AWS Config (كاشفة).

الأوليات الأساسية لـ Control Tower:

Account Factory — منتج Service Catalog يُوفّر حسابًا عضوًا جديدًا من قالب، ويضعه في OU الصحيح، ويطبق إعدادات على مستوى الحساب (أدوار IAM الأساسية وتنبيهات الميزانية وإعدادات VPC)، ويُسجّله في جميع الخدمات على مستوى المؤسسة. Account Factory for Terraform (AFT) هو النسخة Infrastructure-as-Code — كل حساب هو terraform apply.
الضمانات (Guardrails) — ضوابط جاهزة مصنّفة كـ Mandatory (لا يمكن تعطيلها)، وStrongly Recommended، وElective. حتى 2025، يوفر Control Tower أكثر من 450 ضمانة. فعّل مجموعة Strongly Recommended الكاملة من اليوم الأول.
Control Tower Dashboard — يعطي عرضًا لوضع الامتثال عبر جميع الحسابات المُسجّلة. تظهر الموارد غير الممتثلة هنا قبل أن تتحول إلى حوادث.

# Account Factory for Terraform (AFT) — استدعاء وحدة توفير الحساب
# كل block يُوفّر حسابًا AWS جديدًا مع التسجيل الكامل في الضمانات

module "team_alpha_prod" {
  source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"

  control_tower_parameters = {
    AccountEmail              = "aws+alpha-prod@yourcompany.com"
    AccountName               = "alpha-prod"
    ManagedOrganizationalUnit = "Workloads/Production"
    SSOUserEmail              = "platform@yourcompany.com"
    SSOUserFirstName          = "Platform"
    SSOUserLastName           = "Team"
  }

  # تخصيصات الحساب المطبقة بعد التوفير
  account_customizations_name = "production-baseline"

  account_tags = {
    Team        = "alpha"
    Environment = "production"
    CostCenter  = "eng-alpha"
  }
}

# يُشغّل AFT بعد ذلك تخصيصات الحساب — CodePipeline يُشغّل Terraform
# لتطبيق: أساس VPC، أدوار IAM، تنبيهات الميزانية،
# قواعد Security Group الافتراضية، وتجاوزات قواعد Config.

هندسة التسجيل المركزي

كل استدعاء API وتغيير في الموارد وتدفق شبكي في مؤسستك يجب أن يصل إلى حساب Log Archive في مخزن غير قابل للتلاعب وغير قابل للتغيير. هذا ليس اختياريًا — إنه سلسلة الأدلة لحوادث الأمن وعمليات التدقيق للامتثال والـ post-mortems.

مجموعة التسجيل الصحيحة:

AWS CloudTrail — Organization Trail: trail واحد مُفعّل من حساب الإدارة يلتقط أحداث الإدارة من جميع الحسابات الأعضاء الحالية والمستقبلية في بكت S3 الخاص بـ Log Archive. فعّل أحداث البيانات لـ S3 وLambda بشكل انتقائي (إنها عالية الحجم ومكلفة عند التقاطها بالكامل).
AWS Config — Organization Aggregator: يُسجّل حالة التهيئة والتغييرات لجميع أنواع الموارد عبر جميع الحسابات والمناطق. يتغذى في Config Rules لتقييم الامتثال.
VPC Flow Logs: مُفعّل على مستوى VPC في كل حساب أعباء عمل، ومُسلّم إلى بكت السجل المركزي. استخدم تنسيق v5 للتقاط بيانات تعريف حركة المرور بما في ذلك أعلام TCP وإحصائيات مستوى الحزمة.
S3 Object Lock: يجب أن يستخدم بكت السجلات وضع COMPLIANCE من Object Lock مع احتجاز لا يقل عن 90 يومًا. في وضع COMPLIANCE، لا يمكن لأي مستخدم — بما في ذلك الجذر — حذف أو تقصير فترة الاحتجاز.

على نطاق المؤسسات الكبيرة، يمكن أن تصل السجلات من مؤسسة كبيرة إلى petabytes سنويًا. استخدم S3 Intelligent-Tiering على بكت السجلات — يتم الوصول إلى السجلات بكثافة في الـ 30 يومًا الأولى (الاستجابة للحوادث) ونادرًا بعد 90 يومًا (الأرشفة للامتثال). هذا وحده يُخفّض تكاليف تخزين السجلات طويل المدى بنسبة 40–60% بدون أي تعقيد تشغيلي.

تفعيل CloudTrail على مستوى المؤسسة من حساب الإدارة باستخدام Terraform:

# Terraform: Organization CloudTrail يُرسل إلى حساب Log Archive
resource "aws_cloudtrail" "org_trail" {
  name                          = "org-management-trail"
  s3_bucket_name                = "acme-log-archive-cloudtrail"  # bucket في حساب Log Archive
  include_global_service_events = true
  is_multi_region_trail         = true
  is_organization_trail         = true       # يلتقط جميع الحسابات الأعضاء
  enable_log_file_validation    = true        # ملخص SHA-256 كل ساعة
  kms_key_id                    = aws_kms_key.cloudtrail.arn

  event_selector {
    read_write_type           = "All"
    include_management_events = true

    # أحداث بيانات S3 انتقائية — بكت السجلات والأرتيفاكت فقط
    data_resource {
      type   = "AWS::S3::Object"
      values = [
        "arn:aws:s3:::acme-artifacts/",
      ]
    }
  }

  insight_selector {
    insight_type = "ApiCallRateInsight"   # معدلات استدعاء API الشاذة
  }

  tags = {
    ManagedBy = "platform-terraform"
  }
}

# بكت S3 في حساب Log Archive — Object Lock يُطبّق WORM
resource "aws_s3_bucket_object_lock_configuration" "log_lock" {
  bucket = "acme-log-archive-cloudtrail"

  rule {
    default_retention {
      mode = "COMPLIANCE"
      days = 90
    }
  }
}

فعّل التحقق من ملف السجل في CloudTrail (enable_log_file_validation = true). هذا يُنشئ ملف ملخص SHA-256 كل ساعة يربط كل ملف سجل بسلسلة. إذا حذف مهاجم ملف سجل أو عدّله، تنكسر سلسلة الملخص — أمر aws cloudtrail validate-logs سيكتشف التلاعب حتى لو حذف المهاجم ملفات الملخص أيضًا، لأن السلسلة لا يمكن إعادة بنائها بدون المفتاح الخاص الذي تتحكم فيه AWS.