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

استراتيجية تعدد الحسابات

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

استراتيجية تعدد الحسابات

تصطدم كل مؤسسة هندسية كبيرة تعمل على السحابة العامة في نهاية المطاف بسؤال جوهري: هل تتشارك جميع الفرق حسابًا واحدًا في AWS، أم يحصل كل عبء عمل على حسابه المستقل؟ إجابة Netflix وAirbnb وSpotify وكل مهندس SRE مدرَّب على معايير الشركات الكبرى لا لبس فيها: حسابات متعددة، منظمة بعناية. يشرح هذا الدرس السبب والكيفية وميكانيكيات الإدارة على النطاق الواسع.

لماذا تنهار إعدادات الحساب الواحد عند التوسع؟

يبدو الحساب الواحد في AWS بسيطًا — مكان واحد للمراقبة، وفاتورة واحدة، ومجموعة واحدة من سياسات IAM. لكنه يتحول إلى عبء ما إن تجاوزت فريقين:

نطاق الضرر غير محدود. سياسة خاطئة على حاوية S3 في بيئة التجربة قد تكشف بيانات عملاء الإنتاج. دالة Lambda فائرة في بيئة التطوير قد تستنزف الحصة المشتركة لتنفيذ Lambda، فتتوقف استدعاءات الإنتاج.
حصص الخدمات مشتركة. حدود AWS (وحدات معالجة EC2، عناوين EIP، التنفيذ المتزامن لـLambda، نسخ RDS) تُطبَّق على مستوى الحساب لا الفريق. تجربة فريق واحد تحرم بقية الفرق من الموارد.
IAM يتحول إلى متاهة. مئات المطورين يتشاركون حسابًا واحدًا تعني آلاف السياسات المخصصة. مبدأ أدنى الامتياز يصبح مستحيل التدقيق.
تحديد التكاليف ضرب من التخمين. حتى مع الوسم الدقيق، لا يمكن توزيع تكاليف الطاقة الاحتياطية ونقل البيانات والدعم بدقة على وحدات الأعمال من حساب واحد.
نطاق الامتثال ينتفخ. تتطلب معايير PCI-DSS وHIPAA عزل بيئات بيانات حاملي البطاقات والمعلومات الصحية. إذا كان كل شيء في حساب واحد، يشمل المدقق الحساب بالكامل — بما فيه الأعباء غير ذات الصلة — مما يضاعف تكلفة المراجعة ومخاطرها.

المبدأ الجوهري: الحساب كحد لنطاق الضرر

حساب AWS هو حد عزل صارم — وليس حدًا ناعمًا كـVPC أو سياسة IAM. الموارد في حساب ما لا تصل إلى موارد حساب آخر إلا إذا بنيت صراحةً ثقة عابرة للحسابات (VPC peering، مشاركة RAM، انتحال أدوار IAM). هذه الخاصية هي ما يجعل الحسابات الوحدةَ الصحيحة للعزل. صمم طوبولوجيا حساباتك بالسؤال: لو اختُرق هذا الحساب كليًا أو حُذف بالخطأ، ما أقصى ضرر ممكن؟ أبقِ الجواب صغيرًا.

حساب AWS ≠ مؤسسة AWS: الحساب هو حد فوترة وصلاحيات؛ أما المؤسسة فهي مستوى الإدارة الذي يجمع الحسابات في وحدات تنظيمية، ويطبق SCPs، ويجمّع الفوترة. يجب أن يكون لديك كلاهما.

هيكل المؤسسة المرجعي (معيار الشركات الكبرى)

يوضح المخطط التالي التسلسل الهرمي للمؤسسة الذي تعتمده AWS Landing Zone Accelerator ومعظم المخططات المؤسسية. كل مربع إما حساب AWS أو وحدة تنظيمية (OU).

التسلسل الهرمي لمؤسسة AWS متعددة الحسابات: تفرض الوحدات التنظيمية الضمانات؛ كل حساب ورقي يعزل نطاق الضرر لبيئة واحدة.

أنواع الحسابات الأربعة الأساسية

تحتاج كل مؤسسة مؤسسية على الأقل إلى هذه الفئات من الحسابات:

حساب الإدارة — حساب الدفع. يملك مؤسسة AWS، ويفعّل SCPs، ويستلم الفاتورة الموحدة. لا تشغّل أي أعباء عمل هنا. لو اختُرق، يستطيع المهاجم حلّ المؤسسة بالكامل.
حسابات الأمان (Audit + Log Archive) — للقراءة فقط. تتدفق إليها سجلات CloudTrail ونتائج GuardDuty وقواعد Config من جميع الحسابات الأعضاء. فريق الأمان وحده يملك وصول وحدة التحكم؛ حتى مهندسو الإنتاج لا يستطيعون قراءة هذه السجلات أو حذفها.
حسابات البنية التحتية / الخدمات المشتركة — محور Transit Gateway، مناطق Route 53 الخاصة المستضافة، خطوط أنابيب AMI المشتركة، مرايا Artifactory/Nexus. تمركز البنية التحتية للشبكة هنا يعني أن تغييرات VPC لا تستلزم لمس كل حساب تطبيق.
حسابات أعباء العمل — واحد أو أكثر لكل بيئة لكل فريق منتج: payments-prod، payments-staging، payments-dev. خطأ في payments-dev لا يمس payments-prod — الحد يفرض ذلك.

سياسات التحكم بالخدمات: طبقة الضمانات

SCPs سياسات JSON مشابهة لـIAM تُرفق بالوحدات التنظيمية أو الحسابات الفردية. تحدد الحد الأقصى للصلاحيات التي يمكن لأي مبدأ في تلك الحسابات الحصول عليها — لا تمنح صلاحيات، بل تقيّدها. حتى دور AdministratorAccess على مستوى الحساب لا يستطيع تجاوز ما تسمح به SCP.

# SCP: منع تعطيل CloudTrail في وحدة الإنتاج
# أرفقها بوحدة Workloads-Prod في AWS Organizations
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCloudTrailDisable",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail",
        "cloudtrail:PutEventSelectors"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyLeavingOrg",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

مزلق SCP — يطبق على حساب الإدارة أيضًا: SCPs المرفقة بالجذر (Root) تسري على جميع الحسابات باستثناء حساب الإدارة. ارفق SCPs الإنتاج على مستوى الوحدة التنظيمية لا الجذر، حتى تحتفظ بالقدرة على إجراء تغييرات طارئة من حساب الإدارة عند الحاجة.

توفير الحسابات عبر Infrastructure as Code

النقر يدويًا في وحدة التحكم لإنشاء حسابات جديدة لا يتوسع. في AWS وGoogle والشركات الكبرى، إنشاء الحسابات خط إنتاج ذاتي الخدمة: المطور يفتح PR، وحدة Terraform تُنشئ الحساب، تطبق SCPs الأساسية، تُجهّز حاوية حالة CDK/Terraform، وترسل ARN إلى الفريق — كل ذلك في دقائق.

# Terraform: إنشاء وتهيئة حساب عبء عمل جديد
# terraform/modules/workload-account/main.tf

resource "aws_organizations_account" "this" {
  name      = var.account_name          # مثال: "payments-prod"
  email     = var.account_email         # فريد لكل حساب (متطلب AWS)
  parent_id = var.parent_ou_id          # الوحدة التنظيمية المستهدفة

  lifecycle {
    prevent_destroy = true
  }
}

provider "aws" {
  alias  = "member"
  region = var.region
  assume_role {
    role_arn = "arn:aws:iam::${aws_organizations_account.this.id}:role/OrganizationAccountAccessRole"
  }
}

# الخط الأساسي: تفعيل GuardDuty في الحساب الجديد
resource "aws_guardduty_detector" "this" {
  provider = aws.member
  enable   = true
}

# الخط الأساسي: إرسال لقطات Config إلى حاوية log-archive المركزية
resource "aws_config_delivery_channel" "this" {
  provider       = aws.member
  name           = "central-config"
  s3_bucket_name = var.log_archive_bucket
  depends_on     = [aws_config_configuration_recorder.this]
}

IAM عابر للحسابات: نموذج الثقة

بعد إنشاء الحسابات، يحتاج البشر وخطوط أنابيب CI/CD إلى عبور الحدود بين الحسابات. النمط دائمًا واحد: دور في الحساب الهدف يمتلك سياسة ثقة تسمح لهوية في حساب المصدر (أو مجموعة صلاحيات IAM Identity Center) بانتحاله. لا تغادر بيانات الاعتماد مصدرها؛ يتلقى المستدعي رموزًا قصيرة العمر (بحد أقصى ساعة، والافتراضي 15 دقيقة) من STS.

مشغّل GitLab أو GitHub Actions في حساب tools-prod ينتحل deployer-role في payments-prod للنشر. المشغّل لا يحمل بيانات اعتماد طويلة الأمد لـpayments-prod. لو اختُرق المشغّل، يقتصر الضرر على ما يستطيع deployer-role فعله — لا الحساب بأكمله.

عزل الفوترة وتوزيع التكاليف

يُسند Cost Explorer في AWS التكاليف إلى الحسابات بشكل أصلي — دون الحاجة لمخطط وسم. كثير من فرق المالية تنشئ حسابًا واحدًا لكل وحدة أعمال (حتى لو احتوى على خدمات متعددة) لتحقيق إسناد تكاليف نظيف. مع كشف تشوهات التكلفة المقيّد بالحساب والميزانيات مع تنبيهات SNS، تحصل على رؤية دقيقة للإنفاق لا تستطيع مقاربة الحساب الواحد بالوسم تحقيقها بشكل موثوق.

ابدأ بعدد حسابات أقل مما تظن أنك تحتاج. عبء إدارة 200 حساب بأسماء سيئة وبدون خط إنتاج IaC وبدون SSO أسوأ بكثير من مؤسسة منظمة بـ20 حسابًا. ابنِ خط توفير الحسابات أولًا؛ إضافة الحسابات لاحقًا رخيصة ومرنة.

أنماط الفشل الشائعة في الواقع

تمدد حساب الإدارة. تبدأ الفرق بنشر أعباء عمل في حساب الإدارة "مؤقتًا." بعد ثلاث سنوات يشغّل 40 دالة Lambda و12 نسخة RDS وحذفه بات مستحيلًا. الحل: لا أعباء عمل في حساب الإدارة عبر SCP منذ اليوم الأول.
هيكل وحدات تنظيمية مسطح. إرفاق SCPs مباشرة بالحسابات بدلًا من الوحدات التنظيمية يعني أن كل حساب جديد يحتاج توصيل SCP يدوي. دفعة مكوّنة بشكل خاطئ تنشئ حسابات بدون ضمانات. استخدم الوحدات التنظيمية؛ الحسابات ترث تلقائيًا.
غياب الخط الأساسي للحساب. حساب جديد بدون GuardDuty، بدون Config، بدون CloudTrail. يظل موجودًا ستة أشهر قبل أن يلاحظ أحد نسخة EC2 تعدن عملة مشفرة. خط توفير الحساب يجب أن يفعّل هذه الخدمات في اليوم صفر.
حسابات sandbox متصلة بقاعدة بيانات الإنتاج. مطور sandbox لديه اتصال VPC peering بشبكة الإنتاج "لاختبار شيء ما." SCPs الـsandbox يجب أن تمنع صراحةً إنشاء VPC peering مع نطاقات CIDR الإنتاج.

استراتيجية تعدد الحسابات ليست بيروقراطية — بل هي الانضباط الهندسي الذي يجعل من الآمن السماح لـ500 مهندس بالتحرك بسرعة دون خوف من التداخل. في الدرس القادم، نُشغّل هذا عمليًا مع AWS Control Tower وLanding Zones التي تؤتمت إعداد المؤسسة بالكامل في ساعات.